Mapowanie przypadku użycia

Opracowanie modelu użycia ma na celu udokumentowanie w fazie analizy szczegółowych wymagań dotyczących funkcjonalności budowanego rozwiązania. W tym celu definiowani są aktorzy, którzy wchodzą w interakcję z systemem oraz przypadki użycia, które opisują wykorzystywaną przez nich funkcjonalność.

Jednakże analiza systemów informatycznych oprócz modelu funkcjonalnego obejmuje również inne obszary, takie jak:

• zarządzanie wymaganiami,
• modelowanie procesów biznesowych,
• modelowanie danych (logiczny model danych / model domeny),
• modelowanie interfejsu użytkownika. 

Ponadto analiza nie może istnieć w oderwaniu od innych zadań projektowych, takich jak:

• zarządzanie zakresem projektu,
• zarządzanie ryzykiem,
• zarządzanie problemami,
• zarządzanie zmianą,
• projektowanie,
• implementacja,
• testy.

Częstą praktyką jest chociażby opracowywanie scenariuszy i przypadków testowych przez analityków, które są wykorzystywane przez testerów. Dzieje się tak, gdyż przypadki testowe bazują w głównej mierze na przypadkach użycia, a analityk zna je najlepiej.

Zatem, wskazane jest stworzenie i utrzymywanie określonych powiązań elementów modelu użycia z elementami innych obszarów.

Jak wysłać komuś link do diagramu w modelu?

Czy byliście kiedyś w sytuacji, gdy ktoś prosił o znalezienie i wskazanie konkretnego diagramu w jakimś modelu? Czasem nie wystarczy zapisać taki diagram w formie pliku graficznego (na przykład PNG) i wysłać go mailem.
Często konieczne bywa wskazanie miejsca, gdzie taki model się znajduje (może to być współdzielony plik EAP lub baza danych EA) oraz opisać miejsce, gdzie poszukiwany diagram znajduje się w strukturze pakietowej. Skomplikowane i czasochłonne, prawda? Zwłaszcza, gdy odbiorca dzwoni jeszcze z narzekaniem, że mimo wszystko nie może znaleźć albo samego modelu, albo diagramu...

Import wymagań z Linked Document

Enterprise Architect jest wyposażony w mechanizm, dzięki któremu możliwe jest stworzenie biblioteki dokumentów. Elementy typu Document Artifact (tak naprawdę elementy dowolnego typu, ale na potrzeby tego przykładu skupiam się tylko na elementach tego typu) mogą służyć do przechowywania w modelu kompletnych dokumentów w formacie MS Word.
W tym artykule opisuję jeden z praktycznych sposobów wykorzystania tego mechanizmu.

Opis przykładu

Naszym przykładem będzie realizacja projektu mającego na celu informatyzację biblioteki miejskiej. Do tego celu wykonawca projektu w narzędziu Enterprise Architect tworzy i utrzymuje model. Projekt jest w fazie analizy. W ramach projektu odbywa się szereg spotkań projektowych. Z każdego spotkania sporządzana jest notatka. Zapisy z notatek są istotne zarówno z  punktu widzenia kierownictwa projektu, jak również z punktu widzenia analityków. W trakcie takich spotkań mogą być zgłaszane określone wymagania. Kierownik projektu nalega na uczestników spotkań, żeby każde nowe wymaganie zgłaszane przez klienta było rejestrowane. Oczekiwanie kierownika projektu ma na celu takie zarządzanie wymaganiami, aby każda sygnalizowana potrzeba klienta była odpowiednio zaadresowana. Kierownik projektu chce uniknąć niezręcznych sytuacji, gdy po pewnym czasie, w następnych etapach projektu klient robi wyrzuty typu "Przecież już dawno mówiliśmy Wam o tym..", a analitycy odpowiadają "Nic takiego sobie nie przypominamy..." Znacie z własnego doświadczenia takie sytuacje?

Konektory rysowane linią krzywą

Powiązania (connectors) pomiędzy elementami mogą być prezentowane na diagramie przy użyciu różnych styli. Najczęściej stosowane style to: Custom, Direct oraz Auto Routing. Nie każdy jednak wie, że to nie wszystkie dostępne style dla powiązań. Konektory mogą być też rysowane linią krzywą.
Najpierw poświęcę trochę miejsca na opisanie standardowo dostępnych styli linii powiazań, a w dalszej części pokażę jak uzyskać linię krzywą.

Orientacja w powiązaniach na diagramie

Istnieją zalecenia dotyczące tworzenia diagramów mówiące o tym, że dobry diagram nie powinien zawierać zbyt dużej ilości elementów i powinien najlepiej mieścić w czytelnej postaci na jednej stronie formatu A4.
W praktyce okazuje się, że istnieje wiele sytuacji, gdy nie można być w zgodzie z takim zaleceniem. Projektanci tworzą diagramy zawierające dużą ilość elementów i powiązań pomiędzy tymi elementami.
Osoba, która próbuje się zorientować w zawartości skomplikowanego diagramu po jego otwarciu robi najpierw większe oczy, nabiera głęboko powietrza, a na usta jej cisną się słowa przywołania istoty najwyższej ewentualnie nazwy najstarszego zawodu świata...

Okazuje się, że Sparx, producent programu Enterprise Architect wprowadził w tym zakresie udogodnienie.
Otóż, jeśli wskażemy na diagramie, czyli klikniemy na jakiś element, a następnie naciśniemy na klawiaturze klawisz L, wówczas wszystkie powiązania (connectors) którymi jest ten element powiązany z innymi elementami na diagramie zostaną pokolorowane. Widoczne to jest na poniższym rysunku.

Kolorowanie linków po naciśnięciu klawisza L

Kolorem zielonym oznaczone są wszystkie powiązania wychodzące od tego elementu, czyli te, dla których wybrany element jest źródłem (source element).

Kolorem czerwonym oznaczone są wszystkie powiązania przychodzące do tego elementu, czyli te, dla których wybrany element jest elementem docelowym (target element).

Kolorem żółtym oznaczone są wszystkie powiązania wskazujące na siebie, czyli te, dla których wybrany element jest zarówno elementem źródłowym i docelowym.

Proste, prawda? Aby lepiej to zapamiętać, warto skojarzyć nazwę klawisza L ze słowem Link. Jeszcze prościej by było, gdyby ten skrót klawiaturowy nie był tak ukryty przed użytkownikami.