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.

Poniższy rysunek przedstawia mapowanie przypadku użycia z innymi aspektami analizy i zarządzania projektem.

Opis zastosowanych relacji:

• Przypadek użycia realizuje wymaganie(a) - relacja Realization.
  Te powiązania pozwalają upewnić się, czy wszystkie zatwierdzone przez klienta wymagania zostały uwzględnione w określonych funkcjonalnościach.
• Przypadek użycia jest uwarunkowany przez określony proces biznesowy - relacja Trace.
  Najczęściej przypadek użycia jest wykorzystywany do realizacji określonego kroku w procesie biznesowym. Dzięki temu powiązaniu możliwe jest ustawienie przypadku użycia w kontekście biznesowym, a nie tylko systemowym.
• W zakresie zarządzania projektem do przypadku użycia mogą być zgłaszane problemy (Issue) - relacja Trace.
  Dzięki temu można utrzymywać tzw. Issue Log wprost w Enterprise Architect i efektywnie realizować zarządzanie problemami w kontekście określonych elementów funkcjonalnych.
• Przypadek użycia implementuje w swoim przebiegu reguły biznesowe - relacja Dependency.
  Istnieje kilka różnych podejść do zarządzania regułami biznesowymi. Według najprostszej z nich - reguła biznesowa opisuje sposób przetwarzania danych w krokach przypadku użycia. Reguły biznesowe są modelowane jako niezależne elementy, aby ich nie duplikować w kilku miejscach, gdyż mogą być wykorzystywane w kilku różnych przypadkach użycia.
• Przypadek użycia operuje na danych - relacja Dependency.
  To funkcjonalność systemu realizuje tworzenie, zmianę i usuwanie określonych danych. Obiekt określonej klasy danych może być wykorzystany na wejściu do danego kroku przypadku użycia (Uses) lub być rezultatem wykonania danego kroku (Result).
• Funkcjonalność aplikacji dostępna jest dla aktora będącego człowiekiem poprzez interfejs użytkownika. Określony ekran lub kontrolka na tym ekranie powiązana jest relacją Dependency.
  W przypadku aktora będącego systemem funkcjonalność dostępna jest poprzez interfejs aplikacyjny, w takim przypadku element typu Interface lub Component łączymy również relacją Dependency.
• Implementacja w systemie przypadku użycia powinna być sprawdzana poprzez zdefiniowane i uruchamiane przypadki testowe - relacja Trace.
  Dzięki tym relacjom możliwe jest efektywne zarządzanie testami i upewnienie się, czy wszystkie funkcjonalności są objęte testami.

Co daje tworzenie relacji do przypadku użycia?

Podstawową korzyścią jest możliwość śledzenia zależności na różnych etapach projektu. W fazie analizy możliwe jest upewnienie się, że wszystkie wymagania zostały pokryte przypadkami użycia. Nie bez znaczenia jest również nadanie kontekstu biznesowego, gdyż dzięki temu analityk ma szansę naszkicować przyszłą funkcjonalność rozwiązania w taki sposób, aby najlepiej spełniała potrzeby biznesowe.

Powiązania z modelem interfejsu użytkownika są w miarę oczywiste. Często model ten powstaje równolegle z przypadkami użycia i w ich kontekście. Jednak w przypadku budowy bardzo dużych systemów oraz w fazie ich utrzymania powiązania te ułatwiają start w projekcie nowych członków zespołu projektowego.

Śledzenie powiązań na styku model danych <-> model użycia ułatwia szybkie wykrywanie zależności, dzięki czemu w procesie zarządzania zmianą możliwe jest uniknięcie popełnienia kosztownych błędów.

Powiązania z przypadkami testowymi są niezwykle istotne, gdyż ewentualne niedopatrzenie może wpływać na zakres testów integracyjnych czy akceptacyjnych, co w rezultacie przekłada się na wzrost kosztów.

Jak śledzić zależności?

Technicznych możliwości śledzenia zależności w EA jest wiele. Należy wybrać takie, które najlepiej odpowiada potrzebom. Można wykorzystać w tym celu na przykład:

• okno Treceability,
• Relationship Matrix,
• generowanie raportów wraz z relacjami.

Powiązania zobrazowane przy użyciu na przykład macierzy powiązań (Relationship Matrix) mogą zostać zapisane w postaci pliku CSV, który zaimportowany w arkuszu MS Excel doskonale nadaje się do prezentacji oraz dalszej analizy.