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.

Jeżeli chcesz poznać na przykładzie problem rozszerzeń, czym one nie są i jak je opisać/modelować (plik z modelami UML wraz z komentarzem)[simpay id=”44152″]

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

Major elements of business use case UML diagram.

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

Major elements of UML use case diagram.

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

(źr.: Podstawy modelowania w języku UML, dr hab. Bożena Woźna-Szcześniak, prof. UJD, Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie,

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

(źr.

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

(źr.: Projektowanie Systemów Komputerowych, Laboratoria/Projekty, Krzysztof Regulski, AGH, WIMiIP, DIAGRAM PRZYPADKÓW UŻYCIA ? USE CASE MODEL, https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf)

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

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 4 komentarzy

  1. Adam

    https://www.lucidchart.com/pages/pl/diagram-przypadk%C3%B3w-u%C5%BCycia-UML
    nawet powyżsi nie słuchają Pana Jarka i łączą PU z aktorami.
    Gdyby zastosować się do tego co Pan Jarek nakazuje można by te bazgroły z wolnego rysunku wreszcie zredukować do standardowej hierarchii. Ten może to a tamten tamto. Ąle żodyn, powtarzam żodyn, nie powinien mieć tfu asocjacji do includowanego przypadku!

    1. Jarosław Żeliński

      dodam, że logowanie (ogólnie identyfikacja) to funkcja środowiska aplikacji a nie projektowanej aplikacji … 😉

  2. Artur

    Wielokrotnie powtarza Pan, że nie łączymy PU <> z aktorem. Tymczasem spec. UML nic na ten temat nie mówi. Dodatkowo w OCUP2 Certyfication Guide, M.J.Chonoles wskazuje, że jest to możliwe, w przypadku gdy ten włączany PU, wymaga danego aktora (str. 218)

    Ponadto wskazuje Pan, że PU nie podlegają generalizacji. To nie prawda. Use Case w UML jest typem Classifier, ktory podlega generalizacji. W Spec UML 2.5.1 str. 652 widać przykład generalizacji UC. We wskazanej wyżej książce M.J. Chonoles poświęca temu zagadnieniu cały rozdział (12.2.1 str. 217). Dodam, że książka jest z 2018 roku i bazuje na spec UML 2.5

    Uwaga dot. biznesowego przypadku użycia; z jednej strony to prawda, że UML nie definiuje takiego bytu. Ale z drugiej strony poprzez profile i stereotypy, a więc mechanizmy rozszerzalności, możliwe jest takie właśnie rozszerzenie.

    1. Jarosław Żeliński

      Jeżeli Pan doczyta to:
      – związki extend i include to związki strukturalne (odpowiedniki podprogramów typu “go to”)
      – ale kluczowy zapis w spec to “UseCases define the offered Behaviors of the subject without reference to its internal structure.” (18.1.3.1 Use Cases and Actors)
      – generalizacja jest związkiem pojęciowym a nie strukturalnym (dotyczy pojęć a nie elementów architektury), w UML wszystko jest klasą, jednak definiowane byty mają ograniczenia ich użycia
      – certyfikacja OCUP nadal jest oparta na UML 2.4.xx? (jeżeli jest dziedziczenie to jest stara)

      A czy potrafi Pan podać definicję biznesowego przypadku użycia?

      Stereotypy i profile owszem, można tworzyć, ale najpierw musi Pan wykazać niesprzeczność pojęciową tworzonego profilu: stereotypy to poszerzone taksonomie istniejących pojęć w UML a nie ich redefiniowanie (to element warstwy M2 wg. MOF).

      Prostym testem na poprawność modeli jest próba ich literalnego odwzorowania w kodzie… Np. generalizowany lub biznesowy przypadek użycia.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.