Przypadki użycia to temat niekończących się debat. Diagram przypadków użycia może mieć swój początek bez przypadków użycia (Udziałowcy projektu…). Ale czym one, przypadki użycia, są?
Alistair Cockburn jest “use case guru” dla wielu analityków i projektantów, pisze:
Wyróżniamy 3 poziomy szczegółowości przypadków użycia:
- nieformalny opis ? kilka luźnych zdań ogólnie opisujących przypadek
- formalny opis ? kilka paragrafów, podsumowanie
- pełen opis ? formalny dokument
Przypadek użycia (źr. WIKI) powinien:
- opisywać w jaki sposób system powinien być używany przez aktora w celu osiągnięcia konkretnego celu
- być pozbawiony szczegółów dotyczących implementacji oraz interfejsu użytkownika
- opisywać system na właściwym poziomie szczegółowości
- Functional requirements: Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
- Non-functional requirements: Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
- Domain requirements: Requirements that come from the application domain of the system and that reflect characteristics of that domain.
Definicja Sommerville’a, wymagań funkcjonalnych: wymaganie funkcjonalne to usługa świadczona przez system. Jest to praktycznie tożsame z definicją przypadku użycia systemu (parz zakończenie artykułu) i taki jest właśnie ich sens. Idąc tym tropem…
W 1986 Ivar Jacobson, informatyk zaangażowany w tworzenie [[Unified Modeling Language]] (UML) oraz [[Rational Unified Process]] (RUP) opisał technikę do specyfikowania przypadków użycia. Z początku używał określeń: scenariusz użytkowania (usage scenarios) i przypadki użytkowania (usage case). I tu widzę światełko w tunelu. Wymagania są dzielone na następujące kategorie (źr. WIKI):
- Wymagania funkcjonalne opisują funkcjonalność, którą system ma realizować, na przykład formatowanie tekstu lub modulowanie sygnału. Czasami są znane jako możliwości.
- Wymagania pozafunkcjonalne specyfikują kryteria osądzania działania systemu. Są one znane jako wymagania jakościowe.
- Wymagania ograniczeń określają granice rozwiązania. Niezależnie od tego jak problem jest rozwiązany, ograniczenia muszą być respektowane.
W 2006 roku napisałem:
Po wielu podejściach do tworzenia przypadków użycia uznałem, że należy najpierw opisać co jest w ogóle celem tworzenia tego systemu, co on ma wspomagać lub automatyzować. Jak? Należy najpierw zamodelować tę wspomaganą czynność w zupełnym oderwaniu od systemów. Jak już zdefiniujemy i zoptymalizujemy samą czynność można zabierać się do wyszczególniania przypadków użycia czyli tak na prawdę zaprojektować tę ?druga stronę lustra?. (Przypadki użycia i UML | Analiza biznesowa i projektowanie – Jarosław Żeliński – blog).
Po kilku latach kolejnych doświadczeń upewniam się, że proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika. Usługa ta jednak może mieć warianty.
Przykład: jeżeli jakiś system, miedzy innymi, umożliwia wprowadzanie danych z formularza, wzorów formularza jest kilkadziesiąt to ile mamy przypadków użycia? Jeden, który pozwala na wprowadzanie danych do “jakiegoś” formularza, to jaki to jest formularz to parametr. Scenariusz ma między innymi krok: wyświetl formularz do wypełnienia. jaki formularz? Wynika to albo z kontekstu, który może być efektem poprzednio wykonanych operacji albo z bezpośredniego wyboru Aktora. Tak więc dobry projekt raczej nie ma odrębnego przypadku użycia dla każdego wzoru formularza. Dobry projekt ma jeden przypadku użycia, wzór formularza to efekt wyboru np. w poprzednim kroku. Jak taki przypadek użycia jest realizowany? Opisze to kiedyś 🙂 przy okazji wzorca Strategia i praktyk projektowania DDD.
Jaki z tego ma pożytek sponsor projektu? Koszt, projekt ma kilkanaście lub kilkadziesiąt a nie setki przypadków użycia i jest łatwiejszy w implementacji.
A gdzie przypadki systemowe? Nie ma takich. Pojęcie Aktora ma jasną definicję (osoba lub inny system mający interakcję z Systemem), pojęcie przypadku użycia także (specyfikacja działań Systemu w odpowiedzi na działania aktora lub innego podmiotu “zainteresowanego” Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych definicji nie tylko psuje standard bo nie pasuje do spójnej przestrzeni nazw. Wymyślanie swoich znaczeń po protu psuje zrozumiałość, niszczy role komunikacyjną modeli (języka ich tworzenia). Niestety Pan Cockbourn jest w moich oczach takim “dorabiaczem” i psującym sens prostego i jak widać trudnego zarazem, narzędzia jakim jest model przypadków użycia systemu.
O tym jak można psuć i komplikować proste rzeczy (Pan Cockbourn) napisałem w Po brzytwie… (diagram poniżej to wręcz antywzorzec… 😉 a widuje takie niestety w projektach). Zaryzykuję nawet tezę, że ktoś kto poprawia wypracowany system pojęciowy jakim jest np. UML po prostu nie rozumie ani tego systemu ani tego czym jest system pojęciowy i język modelowania. UML, owszem, można rozszerzać (stereotypy), ale to wymaga zrozumienia go, bo samo mnożenie stereotypów bez zachowania pewnych zasad rządzących przestrzenią nazw jaką się UML, prowadzi to bełkotu.
Mnożenie bytów na diagramach to poniższa “[[puszka pandory]]”. Za coś podobnego jak poniżej nie płacimy!
