Logowanie - w kontekście przypadków użycia

Niedawno spotkałem się z pytaniem dotyczącym modelowania przypadków użycia i diagramów aktywności. Jeden z użytkowników zastanawiał się nad kwestią umieszczenia na diagramach aktywności wielokrotnie występujących czynności, takich jak logowanie. Jego problem dotyczył tego, czy operacja logowania użytkownika może być zdefiniowana w jednym miejscu w modelu i wstawiana wielokrotnie na różnych diagramach.


Zdecydowanie, utworzenie takiej czynności jednokrotnie i wykorzystanie jej w różnych diagramach w modelu jest dobrym podejściem. Dzięki temu możliwe jest na przykład śledzenie zależności, a ewentualną zmianę nazwy czynności wystarczy zrobić jednokrotnie.

Ale przyjrzyjmy się bliżej nie samej zasadzie umieszczania na wielu diagramach tego samego elementu, tylko kwestii modelowania czynności logowania do systemu.
Czy zasadne jest traktowanie logowania jako krok w scenariuszu? Piszę o scenariuszu, gdyż diagramy aktywności często są stosowane do zobrazowania przebiegu przypadku użycia. Poza tym łatwo wygenerować diagram aktywności na podstawie scenariusza.
Czy logowanie może być reprezentowane tylko przez jedną akcję? Chyba nie do końca, bo przecież logowanie może się zakończyć niepowodzeniem, użytkownik może wprowadzić niepoprawne dane itd.

Z tego punktu widzenia logowanie powinno stanowić osobny przypadek użycia, który byłby połączony relacją <<include>> z innymi (głównymi) przypadkami użycia. W scenariuszu takiego głównego przypadku użycia powinien się zatem również pojawić krok, w którym następuje wywołanie przypadku logowania. A zatem wracamy do początku, czyli do umieszczenia na diagramie aktywności czynności logowania, tylko tym razem taka czynność może być odpowiednio oznaczona, aby wskazywać na przypadek użycia dotyczący logowania.

Logowanie jako przypadek użycia można znaleźć również w EA User Guide. Tu akurat ten przypadek jest rozszerzany dodatkowo o możliwość zarejestrowania się, gdy brak konta użytkownika.

Źródło: Sparxystems EA User Guide

Gdybyśmy mieli do czynienia tylko z pojedynczym krokiem scenariusza, wówczas na diagramie aktywności należałoby logowanie zamodelować jako action, gdy jednak traktujemy logowanie jako złożoną czynność, wówczas oznacza to, że lepiej umieścić logowanie jako activity. Element typu activity pozwala nam traktować to jako złożony proces, który może być zamodelowany przy użyciu podrzędnego diagramu aktywności. Dzięki temu możemy dysponować dwoma diagramami aktywności:

• dla głównego przypadku użycia - w którym jako jeden z kroków pojawia się Logowanie (jako activity);
• dla przypadku użycia Logowanie - którego przebieg również jest zamodelowany w postaci kroków.

No dobrze, ale jeśli mamy na przykład takie główne przypadki użycia:

• Wyszukanie pozycji w katalogu,
• Złożenie zamówienia,
• Zmiana zamówienia,
• Anulowanie zamówienia,

to czy za każdym razem użytkownik musi się logować do systemu? 

Przecież użytkownik mógł się już uprzednio zalogować... Można odnieść wrażenie, że taki model nie odpowiada do końca rzeczywistości.

Wróćmy zatem do początku, czyli do pytania: Jak zamodelować czynność logowania?

W każdym przypadku użycia można określić tzw. warunki początkowe (pre-conditions). Może zatem zamiast umieszczać krok w scenariuszu polegający na wywołaniu przypadku użycia Logowanie, dodać warunek początkowy w stylu "Użytkownik jest zalogowany do systemu"?

Takie podejście ma już większy związek z rzeczywistością, bo jeśli użytkownik nie jest zalogowany, to nie może wykonać żadnego przypadku użycia, oprócz logowania. A gdy jest już zalogowany, wówczas może wykonywać wiele innych operacji. 

A co, gdy projektowany system wymaga logowania do wykonania jakiejkolwiek akcji, a przypadków użycia jest kilkaset? Czy w każdym przypadku użycia (oprócz logowania) powinniśmy umieszczać taki warunek początkowy? 

Dodatkowo, w przypadku złożonego systemu oprócz logowania użytkownika (uwierzytelnienia) możemy mieć do czynienia z rolami, do których są przypisane określone uprawnienia. W związku z tym, należałoby zapewne oprócz uwierzytelnienia sprawdzić, czy użytkownik jest zautoryzowany (posiada odpowiednie uprawnienia do wykonania operacji). A w konsekwencji dopisać kolejny warunek początkowy w stylu "Użytkownik posiada uprawnienia do wykonania operacji". Oznaczałoby to, że każdy główny przypadek użycia zawierałby dwa takie same warunki początkowe dotyczące uwierzytelnienia i autoryzacji. 

Kwestia uwierzytelnienia i autoryzacji to zagadnienie związane z bezpieczeństwem, a bezpieczeństwo to w dużej mierze sprawa wymagań niefunkcjonalnych. Czy jest dobrym pomysłem wstawianie tego typu warunków początkowych?

Moim zdaniem w przypadku projektowania systemu z uprawnieniami, należy odpowiednio zaadresować problem zarządzania uprawnieniami. Na przykład stworzyć macierz uprawnień, w której znalazłoby się co najmniej mapowanie ról na przypadki użycia.

Reasumując:

• Dla czynności logowania można stworzyć osobny przypadek użycia, aby opisać w jaki sposób ma przebiegać logowanie (jak obsłużyć podanie nieprawidłowego hasła, czy logowanie może się odbywać tylko przy użyciu loginu i hasła, czy alternatywnie certyfikatu, jak obsłużyć sytuację resetowania i zmiany hasła itd.).
• W przypadku, gdy niektóre operacje można wykonać bez uwierzytelnienia, a inne z uwierzytelnieniem, należy do właściwych przypadków użycia dołączyć warunek początkowy w stylu "Użytkownik jest zalogowany do systemu".
• W przypadku, gdy wszystkie operacje wymagają zalogowania - nie dołączałbym warunku początkowego dotyczącego logowania.
  Jako ekwiwalent analiza powinna zawierać model zarządzania uprawnieniami użytkowników. Warto jednak gdzieś w dokumentacji modelu użycia zamieścić ogólną informację, mówiącą o tym, że wykonanie wszystkich przypadków użycia ma miejsce tylko w kontekście zalogowanego użytkownika.
  Jeśli oprócz uwierzytelnienia, niezbędne jest posiadanie określonych uprawnień, wówczas analiza powinna być wzbogacona o macierz uprawnień. Można wówczas (acz niekoniecznie) dodać warunek początkowy do wszystkich przypadków użycia "Użytkownik posiada uprawnienia do wykonania operacji."
• Przypadku użycia dotyczącego logowania nie łączyłbym żadnymi relacjami z głównymi przypadkami użycia, bo utrudniałoby to czytelność.
• W scenariuszu głównego przypadku użycia nie umieszczałbym kroku polegającego na wywołaniu przypadku użycia logowania, bo ta kwestia byłaby zaadresowana w modelu zarządzania uprawnieniami.
• Elementu activity dotyczący logowania nie umieszczałbym jako krok na diagramie aktywności innych przypadków użycia, bo wystarczy raz się uwierzytelnić, aby móc wykonywać wiele różnych czynności.