W tym krótkim wpisie chciałbym zaprezentować sposób modelowania przypadków użycia (Use Case) z wykorzystaniem oprogramowania Enterprise Architect (EA) oraz wbudowanego w nie narzędzia o nazwie Structured Scenarios.

Weźmy na warsztat najprostszy przykład dotyczący logowania.

Zaczynamy do zdefiniowania Aktorów:

Następnie zamodelujmy logowanie w naszym systemie. Podczas logowania będziemy realizować uwierzytelnienie i autoryzację oraz opcjonalnie (w zależności od ustawień użytkownika) również uwierzytelnienie dodatkowe, czyli tzw. 2 Factor Authentication (2FA):

Dla przypomnienia relacją include oznaczmy funkcjonalności realizowane obligatoryjnie, a relacja extend funkcjonalności, które zostaną zrealizowane opcjonalnie (po spełnieniu pewnych warunków).

Na tym etapie poza wrzuceniem „jajeczek” na diagram i utworzeniu relacji między nimi, nic jeszcze nie mamy. Możemy natomiast na chwilę zatrzymać się przy sposobie nazywania samych przypadków użycia (UC). Osobiście stosuję taki wzór:

UC.<skrót nazwy modułu/podsystemu/systemu>.<autonumerator> - <nazwa funkcjonalności>, gdzie:

UC – skrót od Use Case (przypadek użycia)

 

<skrót nazwy modułu/podsytemu/systemu> – w naszym przykładzie będzie to moduł Uwierzytelniania i Autoryzacji, w skrócie UiA.

<autonumerator> – kolejny numer generowany przez EA. Szczegóły w dokumentacji do EA.

<nazwa funkcjonalności> – w naszym przypadku to Logowanie, ale nazwy modelowanych funkcjonalności mogą być bardziej ogólne jak np. Weryfikacja biznesowa lub bardziej szczegółowe jak np. Wysłanie do użytkownika kodu SMS weryfikacji dwuskładnikowej.

Jeśli zastanawiasz się dlaczego w ramach logowania wydzieliłem uwierzytelnienie oraz autoryzację, to przypomnę, że:

• Uwierzytelnianie – polega na zweryfikowaniu czy osoba wskazująca swoją tożsamość jest faktycznie tą za którą się podaje.
• Autoryzacja – polega na ustaleniu czy osoba z potwierdzoną tożsamością (uwierzytelniona) posiada uprawnienia do realizacji konkretnej akcji.

Obie te funkcjonalności mogą być realizowane w dowolny (różny) sposób, dlatego potrzeby niniejszego wpisu nie będziemy ich opisywać, a skupimy się tylko przypadku użycia Logowanie.

Ok, wróćmy do meritum, czyli jak przy użyciu Structured Scenarios opisać sposób realizacji przypadku użycia Logowanie?

Wjedźmy we właściwości UC.UiA.0001 - Logowanie, przejdźmy na Scenarios [1], a następnie uruchamiamy Structure Editor [2]. Tak jak to zostało pokazane na rysunku:

W kreatorze wpisujemy kolejne kroki dla scenariusza głównego (Basic Path):

• Krok 1: Wejście na stronę logowania
• Krok 2: Wprowadzenie login i hasło
• Krok 3: Przygotowanie żądania i wywołanie backend w celu przeprowadzenia uwierzytelnienia i autoryzacji Użytkownik’a
• Krok 4: Otrzymanie żądania uwierzytelnienia Użytkownik’a
• Krok 5: Ponieważ wywołujemy inny UC obsługujący uwierzytelnienie, to musimy w tym kroku to zamodelować wciskając na wierszu 5 prawy przycisk myszy i wybierając Link Step to UseCase, a następnie <include> UseCase i wskazujemy wcześniej utworzone „jajeczko” UC.UiA.0002 - Uwierzytelnienie. Treść kroku zostanie automatycznie wypełniona.

• Krok 6: Sprawdzenie czy dla danego Użytkownik’a wymagane jest uwierzytelnienie dwuskładnikowe (2FA). Jeśli NIE, to przejście do kolejnego kroku, a jeśli TAK to realizowany jest scenariusz alternatywny. Po wpisaniu tekstu w kroku, należy z pod prawego przycisku myszy wybrać opcję Add Alternate Path oraz wpisać nazwę scenariusza alternatywnego i wcisnąć OK.

• Krok 7: W tym kroku również wywołujemy inny przypadek użycia (obsługujący autoryzację), dlatego należy powtórzyć czynności opisane w kroku 5, tylko tym razem wskazać UC.UiA.0003 - Autoryzacja.
• Krok 8: Przygotowanie i odesłanie odpowiedzi do komponentu wywołującego
• Krok 9: Odebranie odpowiedzi i wyświetlenie Użytkownikowi komunikatu o poprawnym uwierzytelnieniu i autoryzacji
• Krok 10: Użytkownik klika przycisk OK i wyświetla mu się zawartość dostępna po zalogowaniu

Wróćmy na chwilę do scenariusza alternatywnego (krok 6). Aktualnie krok 6a, który utworzył się poniżej jako Alternate kończy przetwarzanie w przypadku użycia. Musimy to zmienić, ponieważ po pozytywnym wykonaniu UC.UiA.0004 - Uwierzytelnienie dwuskładnikowe, chcemy żeby scenariusz główny (Basic Path) był kontynuowany od kroku 7. W tym celu musimy zmienić End na 7 w kolumnie Join:

Mamy już prawie wszystko. W rzeczywistości za równo UC.UiA.0002 - Uwierzytelnienie jak i UC.UiA.0003 - Autoryzacja może zwrócić błąd, dlatego na tą okoliczność dla kroku 9 musimy dodać jeszcze dwie sytuacje wyjątkowe (Exception). Żeby to zamodelować, klikamy prawym przyciskiem myszy w wiersz 9 i wybieramy opcję Add Exception Path i wpisujemy Błąd uwierzytelniania. Ponawiamy akcję, tylko za drugim razem wpisujemy Błąd autoryzacji:

Po uzupełnieniu treści w poszczególnych krokach, warto jeszcze wskazać kto odpowiada za wykonanie poszczególnego kroku, czy użytkownik (jeśli tak to jaki) czy może jakiś komponent, moduł, aplikacja, czy system. W tym celu w kolumnie Uses dla kroku 1 z menu prawego przycisku myszy wybieramy Insert context reference i wskazujemy wcześniej utworzonego aktora. Z kolei w kroku 3 w tej samej kolumnie wpisujemy Aplikacja Kliencka, również zaznaczmy cały wpisany tekst i z menu prawego przycisku myszy wybieramy Create, a następnie New Element from Selection. W nowym oknie wybieramy Component dla pola Toolset oraz Type i zatwierdzamy wszystko wciskając przycisk Save. Analogicznie postępujemy w korku 4.

Oba komponenty powinny utworzyć się w pakiecie z przypadkiem użycia. Proponuję od razu zadbać o porządek i utworzyć pakiet Architektura, a w nim pakiet Komponenty i tam przenieść oba utworzone obiekty architektury.

Po wprowadzeniu wszystkich kroków scenariusza głównego, dodaniu ścieżki alternatywnej oraz wyjątków powinniśmy mieć tak wypełniony UC:

Zastanawiacie się pewnie dlaczego brakuje wypełnienia kolumny Uses w krokach 5-8? Otóż ja mam taką praktykę, że jeśli kolejny krok realizowany jest przez ten sam system/aktora, to nie uzupełniam kolejnych kroków, aż do momentu wystąpienia innego aktora/systemu.

Modelowanie scenariusza alternatywnego (Alternate) oraz sytuacji wyjątkowych (Exception) realizowane jest analogicznie, dlatego nie będę już ich opisywał w szczegółach. Dodaję tylko screeny, które pokazują efekt końcowy.

Scenariusz alternatywny: Uwierzytelnienie drugim kanałem.

Sytuacja wyjątkowa: Błąd uwierzytelnienia.

Sytuacja wyjątkowa: Błąd autoryzacji.

Na koniec mając zamodelowany przypadek użycia z wykorzystaniem Structure Editor, możemy np. wygenerować diagram aktywności klikając ikonę drzewka, a następnie wybierając Activity with Action:

Wygenerowany automatycznie diagram aktywności prezentuje się tak:

W następnychwpisach będę chciał przedstawić kolejno:

• Modelowanie logów
• Modelowanie komunikatów oraz innych obiektów takich jak np. okna GUI
• Modelowanie interfejsów i mapowanie UC na operacje
• Wywołanie operacji na diagramach sekwencji
• Przygotowanie modelu architektury i jej widoku wdrożeniowego w wariancie HA
• Generowanie definicji operacji REST (Swagger) na podstawie zamodelowanego interfejsu