Wprowadzenie

Właśnie zostałem zapytany:

Witam Pana, czy interesował się Pan Use Case 2.0 ?

Tak. Od czasu do czasu wpadają mi w ręce takie opisy. Ta idea jest ciekawym i pragmatycznym podejściem do etapu dokumentowania zakresu projektu. Warto jednak pamiętać, że przypadki użycia mają swój kontekst (są osadzone) w tym co robią użytkownicy, bez tego kontekstu są niestety ryzykownym narzędziem, bo deklaratywnym (skąd wiemy, że osoba A ma coś robić skoro nie wiemy jak wygląda cały proces biznesowy, czy mamy polegać tylko na subiektywnej deklaracji tej osoby?).

Dość często spotykam się z tezami, że użycie przypadków użycia nie wymaga modelowania procesów i odwrotnie, albo że są to ?narzędzia? oferujące podobne lub takie same korzyści (źr.: Przypadki użycia czy model procesu, czego używać?)

Niestety nie…  Standardem jest wyprowadzanie (transformacja) przypadków użycia z modeli procesów biznesowych:

Przypadki użycia są ograniczane ich stanem początkowym i końcowym, mają aktora, mają jeden lub więcej alternatywnych scenariuszy. Warto tu zwrócić uwagę, że stan początkowy i końcowy przypadku użycia oraz wejście i wyjście elementarnego procesu biznesowego, to analogiczne ? odpowiadające sobie ?  pojęcia. (źr.: Transformacja modelu procesów biznesowych na model przypadków użycia)

o czym pisałem także przy okazji MDA.

Autor pytania przywołał tę prezentację:

Autor prezentacji pisze, że są to te przypadki użycia, które znamy z UML i tak będę je tu traktował: na tle specyfikacji UML. Dodam, że od 2015 roku mamy UML 2.5¹, dość istotnie odbiegający od UML z roku 2011, gdy powstała ta prezentacja (powyższy PDF pochodzi z 2012 roku, ale nie ma tu istotnych różnić). Poniżej kilka kluczowych tez tej prezentacji i moje komentarze, gdyż wokół przypadków użycia narosło wiele nieporozumień wynikających z bardzo popularnej książki zatytułowanej Stosowanie przypadków użycia (Alistair Cockburn), której autor sam deklaruje, że nie uznaje notacji UML a przypadki użycia rozumie inaczej, o czym niestety wielu zapomina lub nie wie, pisałem o tym już w 2011 roku:

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: (1) nieformalny opis ? kilka luźnych zdań ogólnie opisujących przypadek, (2) formalny opis ? kilka paragrafów, podsumowanie, (3) pełen opis ? formalny dokument. (ŹR : Przypadki użycia systemu czyli co?)

Ale po kolei…

Przypadki użycia

Skalowanie

Czym tu jest skalowalność? Chyba tylko tym, że dokumentacja UC rośnie liniowo w miarę ich przyrostu, jednak nie jest prawdą, że złożoność systemu liniowo opisują przypadki użycia (o czym pisałem tu: Przypadki użycia nie znają swojej realizacji) . Warto pamiętać, że czym innym jest “system pozwala na zarządzanie kartotekami książek w bibliotece” a “system pozwana na zamianę obrazu tekstu na plik rtf (czyli OCR)”.

Historia

Warto pamiętać, że przypadki użycia, jako technika opisu, mają swój rodowód w czasach analizy strukturalnej (lata 80’te). Do UML zostały włączone, gdy ten powstawał w 1996 roku, jednocześnie zostały użyte w metodyce Rational Unified Process przejętej (RUP) z jej autorem (Kruchten) w 1998 roku przez IBM. Tu też powstały “wynalazki” takie jak systemowe czy biznesowe przypadki użycia, których nigdy nie było w formalnym UML.

Obecnie mamy UML v.2.5.1. i przypadki użycia (UC) nadal i co do zasady, to specyfikacja wymagań¹ (specyfikacja systemu) pisana z perspektywy systemu czyli opisujemy to co i jak system ma robić, a nie to do czego posłuży:

18 UseCases
18.1 Use Cases
18.1.1 Summary
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase?s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.
A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

Przypadki użycia jako diagram, to (powinien być) prosty schemat blokowy obrazujący abstrakcję modelowanego systemu (subject) oraz usługi jakie oferuje (Use Case) zewnętrznym  bytom, jakimi są korzystający z jego (systemu) usług ludzie i inne systemy (actor).

Na slajdzie 6, uderzyła mnie teza, że UC to także modelowanie dziedziny systemu, co jest niestety nieprawdą, mając na uwadze specyfikację UML, tym bardziej, że autor tej prezentacji także ją przywołuje. Dziedzina systemu to pojęcia i reguły (logika), a gdzie w UC miejsce na logikę (pamiętamy, że w UML mamy jeszcze diagramy klas i sekwencji)?

Use Case 2.0

Jeżeli autor uważa, że UC można przedstawić na diagramie UML to znaczy, że zna i akceptuje reguły tej notacji. Czy UC to tylko opisowa wersja wymagań? W UML przypadki użycia są kojarzone w ich scenariuszami (diagram sekwencji). Jest to opis ale formalny, nie mniej jednak większość chyba narzędzi CASE (Computer Aided System Engineering) pozwala opisać UC “prozą” na początek.  Niewątpliwie jest zaletą to, że poziom i jakość opisu można dostosować do etapu projektu oraz wiedzy adresata dokumentacji.

Niewątpliwą zaletą stosowania tych diagramów, jest to że są zrozumiałe dla zamawiającego (sponsora projektu), o ile oczywiście nie nadużyjemy symboli i wyobraźni np. traktując jako UC każdego tknięcia klawiatury, np. UC jako “system po kliknięciu prawym klawiszem myszy wyświetla opadająca listę kontrahentów”, co jest kompletnym nieporozumieniem, to jest co najwyżej element scenariusza UC.

Slajd 11 zwraca uwagę na ważną rzecz: odejście (lub wskazanie, że to zła praktyka) od długich wariantowych UC. UC jest definiowany stanem początkowym i końcowym, zaś scenariuszy – wariantowych – przejścia od początku do końca, może być więcej niż jeden, takie podejście po pierwsze bardzo upraszcza dokumentację, po drugie ułatwia zarządzanie implementacją (implementowane scenariusze traktowane jako kolejne edycje tworzenia aplikacji) .

Praktyka

Ta prezentacja to kolejny przykład uznania UC za technikę zwinną, z czym tu się akurat zgadzam: mało dokumentacji, zrozumiała dla klienta, pozwala zarządzać zakresem projektu, da się mapować na sprinty, backlog.

Ale byłbym bardzo ostrożny z uznaniem, że UC to jednostki outsourcingu. Wzorzec projektowy mikroserwisy stosujemy tak, że każdy UC ma swoją implementację (pamiętamy o hermetyzacji w metodach obiektowych), jednak nie można z góry uznać, że jakiś komponent nie będzie współużytkowany.

Podsumowanie

Prezentacja jest bardzo ciekawa. Jest wartościowa z dwóch głównych powodów: pokazuje, że UC to bardzo dobre narzędzie komunikacji oraz dobre narzędzie do zarządzania zakresem i realizacją projektu. Pokazuje także, że liczy się prostota (jedna z nielicznych prezentacji, która całkowicie pomija niepotrzebnie komplikujące diagramy, związki extend i include).

Z drugiej strony był bym jednak bardzo ostrożny z utożsamianiem use case z user story. Pierwsze mają ścisłą definicję w UML, drugie to bardzo nieformalne zapisy wizji użytkowników. Tych drugich jest z reguły znacznie więcej, gdyż operują kontekstem użytkownika:

1. usługa systemu kart bibliotecznych (przypadek użycia): zarządzanie kartami indeksowymi książek,
2. kontekst użytkownika:
   1. sprawdź autora tytułu
   2. znajdź tytuły dla autora
   3. sprawdź datę wydania tytułu
   4. sprawdź nazwę wydawcy tytułu
   5. …

Jak widać, kontekst użytkownika może istotnie zafałszować zakres projektu. Należy się wystrzegać takich opisów, co do zasady przypadki użycia opisują system z perspektywy tego systemu a nie z perspektywy aktora, co mam nadzieję tu pokazałem. Dlatego model przypadków użycia jest znacznie bezpieczniejszy dla projektu, jeżeli powstaje jako transformacja modelu procesów biznesowych po ustaleniu zakresu projektu.

Generalnie idea uczynienia z przypadków użycia szkieletu projektu jest bardzo wygodna, tym bardziej, że przystaje do idei mikroserwisów. Uznanie, że przypadek użycia, rozumiany jako usługa aplikacyjna powiązana z określonym zestawem danych (dokument/formularz), jest “jednostką wdrożeniową” z ewentualnymi iteracjami (w prezentacji slices), jest bardzo wygodnym narzędziem zarządzania zakresem projektu. Załączam także link do dokumentu: