Wprowadzenie

Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas…). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako “zbioru możliwych kliknięć” co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji ? podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją diagramów przypadków użycia po prostu psuje strukturę projektu w narzędziach CASE, czyniąc ją praktycznie bezużyteczną w projektowania architektury systemu. Alistair Cockburn, zwany ojcem opisowych przypadków użycia , napisał pięć lat później:

“A common mistake is to write use cases to contain intimate knowledge of the technology sitting outside each port. These use cases have earned a justifiably bad name in the industry for being long, hard-to-read, boring, brittle, and expensive to maintain.”

Tym razem najpierw opiszę krótko diagram przypadków użycia posługując sie cytatami z oryginalnej specyfikacji. Później opiszę typowe, nadal popełniane, błędy.

Czym jest Diagram Przypadków Użycia

Kluczowe są tu wyjaśnienia wstępu do rozdziału UseCases Specyfikacji UML :

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.
[…]
18.1.3 Semantics
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. A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure.

Powyższe wytłuszczenia zebrałem poniżej, uwagi oznaczone “[…]” są moje:

1. Przypadki użycia są sposobem na uchwycenie [wskazanie] wymagań stawianych systemom, tzn. tego, co systemy mają robić [powody, dla których one powstaną, co będą realizowały na rzecz i na żądanie Aktora].
2. Każdy Przypadek Użycia reprezentuje określony cel (powód), dla którego System jest projektowany.
3. Przypadek Użycia jest rodzajem klasyfikatora behawioralnego, który reprezentuje deklarację zbioru oferowanych zachowań. [to znaczy, że grupuje określony kontekstowo powiązany zbiór zachowań, są to alternatywne scenariusze tego samego przypadku użycia].
4. Przypadki Użycia definiują oferowane zachowania [modelowanego] systemu bez odwoływania się do jego wewnętrznej struktury. (!)

Są to pryncypia budowy tych diagramów.

Związki między Przypadkami Użycia

Extend

Specyfikacja UML:

An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. 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.

Związku ‘extend’ można użyć do pokazania, że pewne elementy zachowania Systemu realizowane są warunkowo. Te dodatkowe zachowania są jednak z zasady częścią bazowego Przypadku Użycia.

Autorzy specyfikacji UML jasno piszą, że: “Szczegółowy sposób określania położenia punktu rozszerzeń jest celowo nieokreślony. Wynika to z faktu, że Przypadki użycia mogą być specyfikowane w różnych formatach, takich jak język naturalny, tabele, drzewa itp. […] Zazwyczaj, przypadek użycia z ExtensionPoints składa się z zestawu drobnoziarnistych opisów fragmentów zachowania (scenariusze), które są najczęściej wykonywane w pewnej sekwencji. Taka segmentowa struktura tekstu opisu danego przypadku użycia pozwala na rozszerzenie pierwotnego opisu zachowania przez dołączanie dodatkowych opisów, fragmentów zachowania, w odpowiednich punktach wstawiane pomiędzy pierwotne fragmenty (punkty rozszerzeń). Tak więc, rozszerzenie UseCase składa się zwykle z jednego lub więcej opisów fragmentów zachowania, które mają być wstawione w odpowiednie miejsca rozszerzanego przypadku użycia. Rozszerzenia są więc specyfikacją wszystkich różnych punktów rozszerzeń w danym przypadku użycia, w których można umieścić dodatkowe zachowania.”

Innymi słowy, formalnie można na Diagramie Przypadków Użycia pokazać, to że scenariusz przypadku użycia jest podzielony na fragmenty, które są wykonywane warunkowo. Jest to jednak modelowanie scenariusza zawierającego instrukcje “if … then”. Tu przypomnę więc kluczową zasadę, zapisaną w specyfikacji UML: “Przypadki Użycia definiują oferowane zachowania [modelowanego] przedmiotu bez odwoływania się do jego wewnętrznej struktury”. Dlatego wielu autorów zwraca uwagę na pewne, ,takie jak ta, niekonsekwencje w specyfikacji.

Include

Specyfikacja UML:

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. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa.

Innymi słowy: jeżeli dwa Przypadki Użycia mają pewne wspólne fragmenty zachowania, można taki fragment “wyjąć przed nawias”, ten fragment jest na diagramie reprezentowany także jako Przypadek Użycia, jednak jest to niesamodzielny fragment, stanowiący część wspólną co najmniej dwóch PU bazowych i on sam z siebie nie reprezentuje samodzielnego zachowania. Ten wspólny, wyłączony fragment, łączymy z PU bazowymi związkiem ‘include’.

Tak więc związki ‘include’ i ‘extend’ owszem nadal są w specyfikacji UML, jednak “Wynika to z faktu, że Przypadki użycia mogą być specyfikowane w różnych formatach, takich jak język naturalny, tabele, drzewa itp.” i ktoś może chcieć taki tekstowy format zobrazować na Diagramie.

Konsekwencje

Diagram Przypadków użycia ma rodowód w metodyce strukturalnej (stosowanie instrukcji “go to” i “subroutine” w programowaniu strukturalnym). Związki ‘extend’ i ‘include’ mają właśnie taki rodowód i nadal są w notacji UML, gdyż Diagram Przypadków Użycia jest nadal popularnym narzędziem w metodach strukturalnych. Jest też niekonsekwencją specyfikacji UML, co widać w jej treści, gdzie na początku rozdziału autorzy specyfikacji UML zwracają jednak uwagę, że “Przypadki Użycia definiują oferowane zachowania przedmiotu bez odwoływania się do jego wewnętrznej struktury”. Więc stosowanie powyższych związków jest reliktem metod strukturalnych, i nie należy ich stosować w projektach zorientowanych obiektowo, tym bardziej, że jest to łamanie podstawowej zasady paradygmatu obiektowego jaką jest hermetyzacja.

Autorzy specyfikacji notacji UML, takim oto przykładem podsumowują rozdział 18. Przypadki Użycia:

Jak widać celem projektowania bankomatu są: Wypłata, Wpłata, Przelew, a także: Rejestrowanie bankomatu (w sieci) i Udostępnianie listy transakcji. Detale tych działań i kolejność ich realizacji nie są przedmiotem tego modelu, nie ma tu związków ‘include’ ani ‘extend’, mimo, że np. trzy kluczowe operacje wymagają użycia karty płatniczej i kodu PIN (owszem, wspólna część, ale są to jednak detale scenariuszy a nie osobne PU).

Traktując więc PU zgodnie z jego podstawową, przytoczoną powyżej definicją, jako: “określony cel (powód), dla którego System jest projektowany”, uznajemy, że celem aplikacji biznesowej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że “Drukujemy dokument”, “szukamy faktury” czy “wprowadzamy NIP kontrahenta”. Pokazanie drukowania jako wyłączonej części wspólnej, lub rozszerzenia, PU Faktura i Zamówienie (stosując związek ‘include’ lub ‘extend’), czy też wydzielanie na diagramie PU “Wybór klienta z listy kontrahentów”, to projektowanie architektury i droga do klęski tego diagramu. To, że komponent realizujący drukowanie będzie osobnym elementem architektury tego systemu zapewne jest prawdą, ale Diagram PU, jak już wiemy, to nie jest model architektury systemu. Nie jest to także specyfikacja procesu biznesowego.

Obiektowo-zorientowane modelowanie systemu

W artykule Use Case 2.0 opisywałem koncepcję obiektowego podejścia w projektowaniu zorientowanym na Przypadki Użycia, opracowaną przez jednego z współtwórców UML: Ivara Jacobsona . W artykule Aplikacje webowe i mikroserwisy czyli architektura systemów webowych opisałem projektowanie oprogramowania oparte na obiektowym paradygmacie i wzorcach projektowych takich jak mikroserwisy. Cytowałem między innymi ten diagram:

Po prawej stronie powyższego widzimy architekturę zorientowaną na mikroserwisy. Jest to typowe i znane od lat komponentowe podejście z hermetyzacją komponentów, realizujących usługi aplikacji . Bloki [MS] (microservices) to nic innego jak komponenty realizujące Przypadki Użycia tego systemu. Każdy PU ma własną implementację (i bazę danych, dane [DB] także nie są współdzielone między przypadkami użycia). Komponent [UI] to zagregowane na jednym ekranie wywołania usług, czyli główne menu systemu. Tak więc Diagram Przypadków Użycia, to model tego głównego menu systemu, a nie model implementacji usług (nie architektura kodu i nie proces biznesowy).

Podsumowanie

Na poniższym diagramie po lewej stronie, pokazano formalnie poprawny diagram przypadków użycia. Z perspektywy projektowania zorientowanego na komponenty, oraz zachowania zasady mówiącej, że ten diagram nie służy do modelowania wewnętrznej architektury systemu, poprawna projektowo jest wersja pokazana po prawej stronie:

Warto też wiedzieć, że w konsekwencji powyższego, łączenie Aktora z wydzielonymi, niesamodzielnymi, opisami zachowań reprezentowanymi przez przypadki użycia 4 i 5, jest pozbawione logiki (podobnie jak tylko jeden PU połączony związkiem ‘include’).

Więc jak i gdzie pokazać owe scenariusze PU? Osobno na diagramach aktywności (role komponentów) lub na diagramach sekwencji (wywoływane operacje interfejsów). Polecam artykuł: Diagram aktywności ? kiedy oraz praktyczny projekt pokazujący, że ma ‘extend’ a jest walidacja, udostępniony na stronie: F.A.Q. czyli jak zamodelować.

Powyższa forma (diagram po prawej stronie) ma także praktyczną zaletę: Zamawiający zrozumie ten diagram. Diagram o po lewej, jest już praktyczną utratą komunikacji z Zamawiającym, bo mało który z nich studiuje specyfikację UML. Specyfikacja po lewej prowadzi także do ogromnego zawyżania oszacowania wycen, gdyż miary oparte na tak zwanych punktach funkcyjnych, traktują każdy PU jako samodzielną, kompletną jedną jednostkę kosztową.

Typowe błędy

A co możemy znaleźć w sieci? Poniżej kilka przykładów wraz ze źródłami:

przykład 1

Błędy: w notacji UML nie ma i nigdy nie było pojęcia “biznesowy przypadek użycia”, to pojęcie jest reliktem metody RUP, Rational Unified Process, z czasów gdy nie było notacji BPMN i BMM.

przykład 2

Błędy: ‘include’ musi mieć co najmniej dwa PU bazowe (bo jest częścią wspólną), nie łączymy aktora z PU włączanym ‘include’.

przykład 3

Błędy: jak powyżej, tu dwukrotnie (Checkout, View items).

przykład 4

Błędy: PU Wyszukanie połączony z aktorem, dziedziczenie (nie ma w UML od 2015 roku), poprawne było by podłączenie aktora do konkretnych rezerwacji a pojęcie ogólne Rezerwacja “wyrzucone” do modelu pojęciowego lub pokazane tu jako abstrakcja (i nie połączone z aktorem). Asocjacje na diagramie PU nie są związkami skierowanymi. Dla porównania do pobrania: Biblioteka.

przykład 5

Błąd: Tu jest kompletna sieczka… pojedyncze ‘include’ łączone z ‘extend’, jeżeli cokolwiek jest tu poprawne, to aktor i trzy PU z jakimi jest połączony.

przykład 6

Błąd: kaskadowe łączenie ‘include’ i ‘extend’, połączenie aktora z Potwierdź tożsamość który jest PU ‘include’, dziedziczenie (patrz poprzedni przykład)

przykład 7

Przypadek użycia to wymagana usługa oferowana przez system dlatego, 1. tu nie używamy dziedziczenia, 2. dziedziczenie usunięto z UML w 2015 roku (nie ma dziedziczenia w UML, zaś generalizacja to związek pojęciowy a nie architektoniczny).

___

Przykładowe rozwiązanie problemu “Jak pokazać kilka przypadków użycia z rozszerzeniami?” znajdziesz na stronie F.A.Q. Czyli jak to zamodelować. Na koniec polecam też artykuł: Ile przypadków użycia?

Źródła