Kompletność modelu użycia

Model użycia (use case model) w wielkim skrócie służy do przedstawienia funkcjonalności rozwiązania poprzez zastosowanie przypadków użycia, aktorów oraz relacji pomiędzy nimi.
Z reguły początkujący analitycy dysponują przynajmniej teoretyczną wiedzą o regułach tworzenia modelu użycia. Wraz z każdym zrealizowanym projektem umiejętności te rosną, ale mimo to dostarczany model użycia często nie jest idealny. Warto zatem pokusić się o stworzenie krótkiego podsumowania w tym zakresie.

Obszary funkcjonalne

Tworząc model użycia dobrą praktyką jest wydzielenie obszarów funkcjonalnych. Nawet prosta aplikacja może realizować funkcjonalności w kilku obszarach.

Takimi obszarami mogą być na przykład:

• Obsługa wprowadzania danych,
• Obsługa generowania raportów,
• Administracja, itd.

Podział na obszary funkcjonalne może wynikać z podziału systemu na podsystemy, ale nie musi. Bywa, że wyspecyfikowane przez analityka obszary stanowią bazę dla programistów, na podstawie której dzielą się pracą czy specyfikują określone komponenty. Ewentualny błąd w fazie analizy polegający na nieprawidłowym określeniu obszarów funkcjonalnych może skutkować później utrudnieniami w utrzymaniu kodu aplikacji. Gdyby się okazało, że dwie podobne funkcjonalności są realizowane w dwóch różnych obszarach funkcjonalnych, to mogą być one implementowane przez dwóch różnych programistów. Kod napisany przez nich może się znacząco różnić. Gdyby obie funkcjonalności znalazły się w jednym obszarze, wówczas jeden programista ma szansę zastosować odpowiednie mechanizmy w kodzie, które służą uspójnieniu na przykład poprzez wykorzystanie odpowiednich wzorców projektowych.

Technicznie w modelu Enterprise Architect obszar funkcjonalny może odpowiadać pakietowi. Taki pakiet ze względu na czytelność można opatrzyć stereotypem <<Obszar>> lub <<Obszar funkcjonalny>>.
Każdy z takich pakietów może zawierać jeden lub więcej diagramów przypadków użycia oraz katalog przypadków użycia, czyli elementów typu use case.

Wskazówki do identyfikacji przypadków użycia

Gdy obszary funkcjonalne zostały już zidentyfikowane kolejnymi krokami są:

• zidentyfikowanie przypadków użycia,
• odpowiednie nazwanie przypadków użycia.

Każda funkcja realizowana przez aplikację, w której bierze udział jakiś aktor powinna znaleźć swoje odzwierciedlenie jako przypadek użycia.
Jeśli chodzi o nazewnictwo przypadków użycia, to istnieją dwie konwencje:

• tryb rozkazujący, np. "Dodaj nowy tytuł",
• rzeczownik odczasownikowy, np. "Dodanie nowego tytułu".

Wybór konwencji zależy od ustaleń projektowych. Wybraną konwencję należy jednak bezwzględnie stosować, aby utrzymać porządek w modelu.

Model aktorów

Należy pamiętać, że model użycia oprócz przypadków użycia powinien zawierać również model aktorów.

Częstym błędem jest potraktowanie modelu aktorów po macoszemu. Mam na myśli traktowanie aktorów jako dodatek do modelu przypadków użycia.

Opracowanie odpowiedniego modelu aktorów pozwala spojrzeć na funkcjonalność systemu z punktu widzenia określonego typu użytkownika. Poza tym odpowiednia identyfikacja aktorów może się przełożyć na opracowanie modelu uprawnień w tworzonej aplikacji.

Dobrą praktyką, którą warto stosować, jest wydzielenie katalogu aktorów w osobnym pakiecie np. o nazwie 'Aktorzy'.

W pakiecie tym powinien znaleźć się diagram aktorów. Diagram ten może zawierać relacje pomiędzy aktorami takie jak Generalization.
Aby umieścić na diagramie przypadków użycia aktorów z tego katalogu wystarczy przeciągnąć go na diagram z okna Project Browser. Dzięki temu ten sam aktor może występować na wielu diagramach, redukując w modelu ilość elementów typu Actor opisujących tę samą rolę lub funkcję.
Każdy aktor powinien być opatrzony opisem, który precyzuje jakie akcje aktor wykonuje w systemie, można również zawrzeć ograniczenia, czyli opisać akcje, których aktor nie wykonuje.

Opisywany system, którego dotyczą przypadki użycia nie jest aktorem. Aktorem mogą być użytkownicy i systemy zewnętrzne, które wchodzą w interakcje z systemem.

Przykładowa struktura modelu użycia

Poniższy rysunek przedstawia przykładową strukturę modelu użycia zawierającą katalog aktorów oraz podział przypadków użycia na obszary funkcjonalne.

Relacje pomiędzy przypadkami użycia

Elementy modelu użycia wchodzą ze sobą w relacje, które zostały opisane w specyfikacji notacji UML. Pomiędzy aktorem a przypadkiem użycia stosuje się relację Association. Możliwe relacje pomiędzy przypadkami użycia to:

• Generalization/Specialization,
• Include,
• Extend.

Dodatkowo, poza specyfikacją UML w EA dostępne są inne relacje, które można traktować jako swoiste rozszerzenie standardu UML:

• Invokes,
• Precedes.

Pierwsza z nich (invokes) oznacza, że jeden przypadek użycia wywołuje inny. Można stosować tę relację na przykład w odniesieniu do funkcjonalności implementowanych jako usługi SOA.
Druga (precedes), oznacza, że w odróżnieniu od extend, czy include przebieg jednego przypadku musi się zakończyć przed rozpoczęciem przebiegu drugiego przypadku.

Nic nie stoi na przeszkodzie, aby przypadki użycia łączyć odpowiednimi relacjami również z innymi typami elementów, np. z wymaganiami, czy klasami z modelu domeny.
Dobrą praktyką jest, gdy dla wszystkich wymagań funkcjonalnych istnieją mapowania z przypadkami użycia przy użyciu relacji Realization.

Cechy przypadku użycia

Opis przypadku użycia powinien zawierać przynajmniej następujące cechy:

• Unikalny identyfikator.
• Nazwa przypadku użycia.
• Opis przypadku użycia - krótka informacja w języku zrozumiałym przez użytkownika biznesowego.
• Warunki początkowe - co musi być spełnione, żeby akcja mogła się wydarzyć.
• Przebieg główny - lista kroków, których sekwencyjne wykonanie warunkuje osiągnięcie stanu opisanego przez warunki końcowe; przebieg ten opisuje najbardziej typowe wykorzystanie funkcjonalności opisanej przez przypadek.
• Przebieg(i) alternatywne - lista kroków, których sekwencyjne wykonanie również warunkuje osiągnięcie stanu opisanego przez warunki końcowe, jednak różni się od typowego przebiegu (głównego); przebieg taki stanowi "odgałęzienie" od przebiegu głównego.
• Sytuacje wyjątkowe -  opis sytuacji, gdy na skutek określonego warunku nie jest możliwe osiągniecie stanu końcowego przebiegu głównego. Wystąpienie sytuacji wyjątkowej często kończy się wyświetleniem komunikatu o błędzie, kończy przebieg i nie zachodzą warunki końcowe.
• Warunki końcowe - co się wydarzy, gdy akcja zakończy się pomyślnie.

Dodatkowo dla przypadku użycia można zdefiniować zestaw reguł biznesowych, które są wykorzystywane w określonych krokach przebiegów. Ponadto istnieje również szereg innych cech, którym są przypisywane wartości domyślne podczas tworzenia przypadku użycia, takie jak złożoność, status, wersja, autor itd. Atrybuty te mogą być wykorzystywane do śledzenia cyklu życia przypadku lub wyceny złożoności oprogramowania.

Przebiegi przypadku użycia

Pełny opis przypadku użycia powinien zawierać przebieg główny, może być tylko jeden przebieg główny. Przebiegi alternatywne i sytuacje wyjątkowe nie są wymagane. Mogą być przypadki użycia, w których jest opisany tylko przebieg główny, ale warto, aby upewnić się, czy nie istnieje żadna okoliczność, która może w sprawić, że nie zawsze będzie możliwe przejście do następnego kroku.  Na przykład jeden krok może być sformułowany następująco "System wyświetla listę znalezionych tytułów", a następny krok "Użytkownik wybiera tytuł z listy". Zadajmy sobie pytanie: Co ma się wydarzyć, jeśli system zwróci pustą listę tytułów? Użytkownik nie będzie mógł niczego wybrać, typowa sytuacja opisywana w przebiegu głównym wówczas nie zaistnieje, potrzebny jest przebieg alternatywny.
Przypadek użycia powinien uwzględniać tego sytuacje i opisywać w jaki sposób powinna przebiegać interakcja pomiędzy systemem a użytkownikiem.

Kroki przebiegów najczęściej opisują akcje wykonywane naprzemiennie przez aktora i system.

Ale błędem jest narzucanie wymogu, że kroki muszą być wykonywane naprzemiennie. Nie zawsze jest możliwa zgodność z taką zasadą.

Przebiegi są zwane również scenariuszami. Termin scenariusz rodzi słuszne skojarzenia ze scenariuszem filmowym.

Dobrą praktyką jest, aby przebieg nie miał zbyt wielu kroków. Powiedzmy - maksymalnie 10. Choć nie należy traktować tego jako sztywną regułę. Gdy kroków jest zbyt wiele, należy zastanowić się, czy przypadek nie powinien zostać rozbity na dwa lub więcej przypadków użycia.

Można się umówić, że przebiegi, czy scenariusze nie są opisywane tekstowo, tylko za pomocą diagramów aktywności lub interakcji.

Dobrą praktyką jest jednak unikanie redundancji opisu, czyli dla tego samego przypadku użycia nie stosujemy jednocześnie opisu tekstowego, jak i diagramu.

Technicznie w programie Enterprise Architect od wersji 8.0 możliwe jest stosowanie tzw. Structured Scenarios, które pozwalają na stworzenie czytelnej listy kroków wraz z przejściami pomiędzy różnymi scenariuszami. Czyli np. krok 4 przebiegu głównego może zawierać krok 4a, który oznacza, że gdy spełniony zostaje określony warunek (opisany słowem "Jeżeli..."), wówczas następuje uruchomienie przebiegu alternatywnego lub sytuacji wyjątkowej. Z przebiegu alternatywnego może nastąpić w którymś z kolejnych kroków powrót do przebiegu głównego.

Z sytuacji wyjątkowej powrót do przebiegu głównego jest traktowany jako błąd modelowania. Podobnie nie ma również możliwości przejścia z jednego przebiegu alternatywnego do innego przebiegu alternatywnego. Program Enterprise Architect uniemożliwia tego typu sytuacje.
Gdyby zaszła potrzeba wywołania jednego przebiegu alternatywnego w drugim przebiegu alternatywnym, wówczas jest to sygnał, że taki przypadek użycia należy rozbić na dwa osobne i powiązać je przy użyciu odpowiedniej relacji.

Scenariusz opisany za pomocą Structured Scenarios umożliwia automatyczne wygenerowanie jednego lub kilku rodzajów diagramów, które mogą być aktualizowane w oparciu o zmiany opisu przebiegów.