Przypadki użycia w notacji UML¹ to jedna z najstarszych metod dokumentowania wymagań i nadal budzi wiele kontrowersji w kwestii ich poprawnego użycia.

Obiektowy paradygmat i pojęcie systemu

Słownik j.polskiego mówi:

paradygmat ?przyjęty sposób widzenia rzeczywistości w danej dziedzinie, doktrynie itp.?

obiekt ?rzecz abstrakcyjna, np. cecha lub pojęcie?, ?przedmiot, który można zobaczyć lub dotknąć?

system ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość?, ?zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość?

Ludwig von Bertalanffy w swojej Ogólnej Teorii Systemów^?2? określa

system: stanowiący określoną całość byt, złożony z mających interakcje elementów.

Pojęciami powiązanymi są tu podsystem i super system.  Są to pojęcia względne, ich znaczenie odnosi się do systemu analizowanego. Innymi słowy: dany system składa się z podsystemów oraz jest częścią systemu nadrzędnego czyli super systemu. Paradygmat obiektowy, w swej istocie, nawiązuje do teorii systemów: system (analizowany lub projektowany) składa się z współpracujących obiektów.

Cechą podstawową obiektowego paradygmatu jest hermetyzacja, która oznacza, że obiekt nie udostępnia swojemu otoczeniu (nie udostępnia) swojej struktury (budowy), ma z otoczeniem wyłącznie określone interakcje, zwane operacjami. Innymi słowy obiekt reaguje w określony sposób na określone bodźce ignorując wszelkie pozostałe, a zbiór tych operacji nazywamy interfejsem obiektu. Jedynym sposobem pozyskanie informacji o obiekcie jest “zapytanie go o to”. Cechą elementów systemu, czyli obiektów, jest to, że poszczególne z nich są między sobą bardzo luźno powiązane ale wewnątrz siebie są one bardzo spójne. Jedno z wielu opracowań na ten temat mówi:

Cohesion and Coupling deal with the quality of an OO design. Generally, good OO design should be loosely coupled and highly cohesive. Lot of the design principles, design patterns which have been created are based on the idea of ?Loose coupling and high cohesion?.³

Konsekwencją hermetyzacji jest polimorfizm. Znamy jedynie nazwę bodźca, metoda powstania reakcji obiektu ma bodziec jest ukryta, co znaczy, że nazwa bodźca określa skutek z nie to jak powstał.

Podsumowując, obiektowy paradygmat mówi nam, że przedmiot analizy lub projektowania, przedstawiamy jako system, czyli określoną strukturę składającą się z określonych elementów, elementy te współpracują (mają interakcje) w określony sposób.

Paradygmat obiektowy: Jedynym związkiem między obiektami systemu jest wzajemna współpraca czyli interakcja. Hermetyzacja oznacza, że obiekty ukrywają swoją budowę i nie współdzielą niczego. Polimorfizm oznacza, że istotna jest nazwa polecenia, a nie metoda jego wykonania, bo te mogą być różne.

Co piszą w sieci i książkach

W sieci i w literaturze można spotkać różne wyjaśnienia i opisy tego co popularnie nazywa się (moim zdaniem niesłusznie) “podejściem obiektowym”. W zależności od tego czy celem jest opisanie badanego przedmiotu czy jego zaprojektowanie, mówimy o analizie zorientowanej obiektowo lub projektowaniu zorientowanym obiektowo.

W sieci spotkamy bardzo często opisy takie jak ten:

Object-Oriented Analysis
A method of analysis which describes the problem domain in terms of classes and objects.
OOA feeds OOD which then can be implemented with OOP.^?4?

Jest to dość powszechnie spotykana i nieprawdziwa teza, mówiąca że analiza obiektowa (obiektowe metody analizy) polega na opisaniu problemu z użyciem klas i obiektów. Nie jest także prawdą, że “z zasady” atrybuty to dane (rozumiane tak jak pola w bazach danych, UML – diagram klas – absolutnie  nie służy do modelowania danych!). Analiza obiektowa może prowadzić do obiektowego projektowania a potem do obiektowej implementacji.

Większość tekstów na temat metod obiektowych wychodzi z rąk programistów. Ci opisują ją z perspektywy implementacji z użyciem tak zwanych obiektowo zorientowanych języków programowania. Tak zwana obiektowa orientacja języka programowana sprowadza się do tego, że elementy programu są organizowane w klasy, a te zawierają atrybuty i operacje. Atrybuty to elementy zapamiętywane a operacje to wywoływane funkcje (metody, procedury). Innymi słowy jest to kolejna strukturalna metoda pisania oprogramowania.

To czy projekt jest faktycznie “obiektowy” zależy od jego architektury a nie od faktu, że użyto obiektowo zorientowanego języka programowania (nawet w assemblerze można programować obiektowo).

Inny przykład:

Programowanie obiektowe (ang. object-oriented programming, OOP) ? paradygmat programowania, w którym programy definiuje się za pomocą obiektów ? elementów łączących stan (czyli dane, nazywane najczęściej polami) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań.

Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i wielokrotne użycie programów lub ich fragmentów.

Największym atutem programowania, projektowania oraz analizy obiektowej jest zgodność takiego podejścia z rzeczywistością ? mózg ludzki jest w naturalny sposób najlepiej przystosowany do takiego podejścia przy przetwarzaniu informacji.⁵

Ad. pierwszy akapit. Przede wszystkim pisany przez programistę program zawiera deklaracje klas, te zawierają atrybuty i operacje. Na podstawie tych klas (deklaracji) powstaną w pamięci komputera obiekty, ale dopiero wtedy gdy program ten będzie się wykonywał w pamięci komputera.

Ad. drugi akapit. Praktycznie podział programu na deklaracje klas to inna forma strukturyzacji kodu programu. Pisanie, konserwacja i wielokrotne użycie nie jest prostą konsekwencją faktu użycia obiektowego języka programowania. Podział programu na klasy, i to jak ten podział zostanie przeprowadzony,  to wyłącznie inwencja architekta lub programisty, nie ma takiego obowiązku (przeczytaj o Boskim obiekcie).

Ad. trzeci akapit. Najpierw przypomnijmy, że prace nad oprogramowaniem przebiegają w następującej kolejności: Analiza obiektowa, Projektowanie obiektowe, Programowanie obiektowe. Tak więc programowanie to ostatni etap i jedynie implementacja projektu. Pomysł na architekturę kodu programu to projektowanie. Jeżeli mówić o tym do czego jest przyzwyczajony ludzki mózg, to do obiektowego postrzegana otoczenia, ale na dość wysokim poziomie abstrakcji (widzimy ludzi lub samochody, ale mało kto postrzega je jako “system współdziałających obiektów”).

Człowiek postrzega swoje otoczenie jako określone obiekty, ale rzadko zna i rozumie ich wewnętrzną strukturę i mechanizm działania. I tu dochodzimy do pojęcia Przypadek Użycia w notacji UML

Co na to sam autor pomysłu Alan Kays?

Obiektowy paradygmat programowania to:

1. Wszystko jest obiektem.
2. Obiekty komunikują się poprzez wysyłanie i odbieranie wiadomości (w sensie obiektów).
3. Obiekty mają własną pamięć (w sensie obiektów).
4. Każdy obiekt jest instancją klasy (która musi być obiektem).
5. Klasa przechowuje wspólne zachowanie dla swoich instancji (w postaci obiektów na liście programu)
6. Aby wywołać listę programów, sterowanie przekazywane jest do pierwszego obiektu, a reszta traktowana jest jako jego komunikat.

https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Nie ma dziedziczenia a jest hermetyzacja i komunikacja!

Przypadki użycia – czym są?

Z uwagi na to, że przytłaczająca większość (deklarowanych) zastosowań pojęcia przypadek użycia ma swoje źródło w notacji UML, skupie się na tej notacji. Od 2015 roku mamy UML 2.5, ostatnia aktualizacja do 2.5.1. miała miejsce w grudniu 2017. Czytamy tam:

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.¹

Ogólnie: Przypadki Użycia są sposobem na opisanie wymagań wobec systemu, rozumianych jako to, co system ma robić. Kluczowe pojęcia z tym związane to Aktor, Przypadek Użycia, przedmiot opisu. Każdy Przypadek Użycia reprezentuje system z perspektywy celu jego użycia. Każdy człowiek lub inny zewnętrzny system mający z nim interakcje, nazywamy Aktorem tego systemu.

Tak więc Przypadek Użycia to reakcja systemu na bodźce, których źródłem jest aktor systemu.

18.1.3.1 Use Cases and Actors
A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.¹

Generalizując Przypadek Użycia systemu reprezentuje (specyfikuje) zachowanie systemu (zestaw, łańcuch jego zachowań) w odpowiedzi na określony bodziec, efektem tego zachowania jest określony rezultat przedstawiający wartość dla Aktora.

Tak więc Przypadek Użycia to abstrakcja reprezentująca efekt interesujący z punktu widzenia aktora, ten efekt to reakcja systemu inicjowana działaniem aktora.

W specyfikacji UML opisano dwie specyficzne konstrukcje:

Rozszerzenie (18.1.3.2. Extend) 

Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.¹

Używane w celu pokazania, że określony Przypadek Użycia, może cechować się pewnymi dodatkowymi, warunkowymi zachowaniami (może ono dotyczyć więcej niż jednego przypadku użycia).

Włączenie (18.1.3.3 Includes)

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common.¹

Używane jest w celu wyłączenia (pokazania) na zewnątrz, pewnej określonej wspólnej części, dwóch lub większej liczby Przypadków użycia.

Dwa kluczowe wnioski:

1. zarówno include jak i extent są to konstrukcje ujawniające wnętrze architektury kodu, a więc łamiące zasadę hermetyzacji,
2. include to wyłączona część wspólna co najmniej dwóch przypadków użycia, więc:
   1. nie ma sensu łączenie aktora do przypadku wyłączonego, bo do niesamodzielny fragment scenariusza,
   2. nie ma sensu konstrukcja z jednym przypadkiem użycia i jednym lub wieloma przypadkami połączonymi związkiem include.

Jeżeli deklarujemy, że projekt jest zgodny z paradygmatem obiektowym, konstrukcje te nie mają zastosowania. Są zabronione, bo łamią podstawową zasadę paradygmatu obiektowego jaką jest hermetyzacja.

Obie te konstrukcje (include i extend) mają rodowód z metod strukturalnych, a są to lata 80-te, gdzie stosowanie pojęcia podprogramu było standardową konstrukcją re-użycia kodu.  Litera U w akronimie UML oznacza “unified” czyli ujednolicony, UML jest więc ujednoliconym i uniwersalnym narzędziem, co sami autorzy UML wskazują, tłumacząc dlaczego te konstrukcje zostały utrzymane w specyfikacji UML.:

This is because UseCases may be specified in various formats such as natural language, tables, trees, etc.

Nie mniej jednak nadal pojawiają się, łamiące fundamenty obiektowego paradygmatu, kuriozalne pomysły na modelowanie architektury systemu z użyciem Przypadków Użycia, takie jak te opisane tu:

Decomposing Use Cases Towards Logical Architecture Design⁶

Innym przykładem stosowania przypadków użycia w sposób niezgodny z UML, jest bardzo popularna książka Alistair’a Cockburna zatytułowana Stosowanie Przypadków Użycia⁷.

UML has had little impact on these ideas – and vice versa. Gunnar Overgaard, a former colleague of Jacobson?s, wrote most of the UML use case material, and kept Jacobson?s heritage. However, the UML standards group has a strong drawing-tools influence, with the effect that the textual nature of use cases was lost in the standard. Gunnar Overgaard and Ivar Jacobson discussed my ideas, and assured me that most of what I have to say about a use case fits within one of the UML ellipses, and hence neither affects nor is affected by what the UML standard has to say. That means you can use the ideas in this book quite compatibly with the UML 1.3 use case standard. On the other hand, if you only read the UML standard, which does not discuss the content or writing of a use case, you will not understand what a use case is or how to use it, and you will be led in the dangerous direction of thinking that use cases are a graphical, as opposed to textual, construction. Since the goal of this book is to show you how to write effective use cases, and the standard has little to say in that regard, I have isolated my remarks about UML to Appendix A.⁷

Cockburn wytyka notacji UML ograniczenia metod graficznych opartych na rysowaniu elips, jednak pomija fakt, że przypadki użycia to cele aktorów (i wymagania czyli umowa z zamawiającym) a nie finalna wersja systemu oraz fakt, że UML zawiera między innymi diagram sekwencji, którego celem stosowania jest właśnie detaliczne dokumentowanie scenariuszy przypadków użycia. w swoim Dodatku A rozpisuje się na temat tego, jak związkami include, extend, dziedziczeniem rozpisywać detale tekstowych (i tabelarycznych) specyfikacji przypadków użycia, ale nie tylko w moich oczach, pogłębia problem łamania zasad paradygmatu obiektowego.

Na zakończenie, warto zwrócić uwagę na prace takie jak ta: User Story to Use Case scenario⁸, gdzie korzystając z tego, że tak zwane user story w wersji sformalizowanej to zapisy w rodzaju:

• jako ? osoba, przypisana rola,
• chcę ? cecha, funkcjonalność, czynność,
• ponieważ ? uzasadnienie, rezultat, korzyść.

możliwe jest generowane (wyprowadzanie) przypadków użycia z user story wg. schematu:

• aktor ? osoba,
• przypadek użycia ? funkcjonalność,
• rezultat scenariusza przypadku użycia ? rezultat

Podejście to ma jednak poważną wady. Zignorowanie faktu, że aktor to klasa użytkowników a nie użytkownik. Innymi słowy np. system CRM przeznaczony jest do pracy w dziale sprzedaży, aktorem jest każdy pracownik tego działu (system CRM ma w swej podstawowej dziedzinie, jaką jest obsługa kontaktów z klientami, jednego aktora: pracownika działu sprzedaży, uprawnienia konkretnych osób to konsekwencja ich stanowisk i reguł biznesowych). Kolejna wada to fakt, że user story to perspektywa użytkownika, a use case to usługa aplikacji a to nie to samo: jeden use case może posłużyć do realizacji wielu celów: treść faktury może posłużyć do sprawdzenia kto i kiedy coś kupił, do sprawdzenia jaki adres siedziby miał kiedyś kontrahent, do sprawdzenia historycznych cen produktów itp.

Dlatego user story to raczej materiał do opracowania modelu przypadków użycia: user story to potrzeba użytkownika, use case to funkcja (usługa) systemu.

Konstrukcje w postaci diagramów, na których mamy multum Przypadków Użycia, połączonych związkiem include z jednym przypadkiem nazwanym Logowanie^?9?, zaliczam do jednych z najbardziej kuriozalnych. Czytając taki diagram zgodnie  z UML, należy uznać, że wszystkie scenariusze zawierają w sobie owo logowanie, innymi słowy, każda wykonywana czynność z aplikacją składa się miedzy innym z logowania.

Tak więc logowanie nie jest przypadkiem użycia aplikacji. Patrząc na architekturę heksagonalną, logowanie jest funkcją środowiska, a nie aplikacji. Logujemy się do MS Windows, a nie do MS Word. Dlatego podczas modelowania aplikacji w UML “zalogowany” jest warunkiem początkowym dla przypadku użycia, a nie oddzielnym przypadkiem użycia. Warto także wiedzieć, że w UML nie było i nie ma czegoś o nazwie: biznesowe czy systemowe przypadki Przypadki Użycia.

A na zakończenie ciekawe zestawienie błędów:

Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use case modelling but also significantly enhance the value delivered and improve the satisfaction of stakeholders. Source: Top 10 mistakes in Use Case Modelling

I wiele mówiący referat:

Żródła

1. 1.

   Unified Modeling Language. ABOUT THE UNIFIED MODELING LANGUAGE SPECIFICATION VERSION 2.5.1. https://www.omg.org/spec/UML/About-UML/. Published December 16, 2017. Accessed January 5, 2019.
2. 2.

   Bertalanffy L. General System Theory. Google Books. https://books.google.pl/books/about/General_System_Theory.html?id=N6k2mILtPYIC&source=kp_cover&redir_esc=y. Published May 1, 2003. Accessed January 5, 2019.
3. 3.

   Cohesion and Coupling: Two OO Design Principles. Experiences Unlimited. https://sanaulla.info/2008/06/26/cohesion-and-coupling-two-oo-design-principles/. Published June 25, 2008. Accessed January 5, 2019.
4. 4.

   The OO Paradigm | Atomic Object. Atomic Object. https://atomicobject.com/resources/oo-programming/the-oo-paradigm. Published January 5, 2019. Accessed January 5, 2019.
5. 5.

   Programowanie obiektowe. Wikipedia. https://pl.wikipedia.org/wiki/Programowanie_obiektowe. Published January 5, 2019. Accessed January 5, 2019.
6. 6.

   Santos N. Modeling in Agile Software Development: Decomposing Use Cases Towards Logical Architecture Design. SpringerLink. 10.1007/978-3-030-03673-7_31″ target=”_blank” rel=”noopener noreferrer”>https://link.springer.com/chapter/

   7.

   WRITING EFFECTIVE USE CASES, Alistair Cockburn, Addison-Wesley, c. 2001.
7. 8.

   Gilson3.84University of Canterbury F, Irwin C. (PDF) From User Stories to Use Case Scenarios – Towards a Generative Approach. ResearchGate. https://www.researchgate.net/publication/329718572_From_User_Stories_to_Use_Case_Scenarios_-_Towards_a_Generative_Approach. Published April 1, 2016. Accessed January 5, 2019.
8. 9.

   Szwed P. io:zadanie_3. [Piotr Szwed]. http://home.agh.edu.pl/~pszwed/wiki/doku.php?id=io:zadanie_3. Published November 4, 2012. Accessed January 6, 2019.

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ę:

https://www.slideshare.net/MikeSorokin/use-case20

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:

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

Przypadek użycia (źr. WIKI) powinien:

1. opisywać w jaki sposób system powinien być używany przez aktora w celu osiągnięcia konkretnego celu
2. być pozbawiony szczegółów dotyczących implementacji oraz interfejsu użytkownika
3. opisywać system na właściwym poziomie szczegółowości

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):

1. 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.
2. Wymagania pozafunkcjonalne specyfikują kryteria osądzania działania systemu. Są one znane jako wymagania jakościowe.
3. 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!