Wprowadzenie

Bardzo często na szkoleniach, a także na zajęciach laboratoryjnych z przedmiotu Inżynieria oprogramowania, jestem pytany o przypadki użycia i ich scenariusze. Szczególnie często pada pytanie czy przypadek użycie reprezentuje tylko jeden scenariusz.

Przypadki użycia w UML to “dzieło” Ivara Jacobsona . Pierwotnie było to narzędzie do opisu zewnętrznych cech (zachowań) systemu, rozumianych jako jego oczekiwane zachowania, czyli wymagania wobec systemu. Był to tak zwany “opis czarnej skrzynki”. Problemem było to, że “czarna skrzynka” mówi CO ale nie mówi JAK. Jacobson opisywał przypadki użycia z pomocą warunków (stanów początkowego i końcowego) oraz tekstowymi scenariuszami. Po włączeniu tego narzędzia (typ diagramu) do notacji UML, stało się możliwe specyfikowanie tego JAK to ma być realizowane w sposób bardziej sformalizowany. Przypadki użycia w UML zostały sformalizowane a ich dokumentowanie w UML (scenariusze) realizowane jest z pomocą skojarzonych z nimi diagramów sekwencji, a czasami w początkowych etapach projektowania, diagramem aktywności (poglądowe opisy celowościowe).

Jacobson, podobnie jak A. Cockburnem , nadal rozwija przypadki użycia (metodę) niezależnie od UML i OMG.org, jako swoją koncepcję Use Case 2.0 . Zamykając się na scenariuszach i zwinnych metodach ich opisu. Jednak nawet on nadal wskazuje, że jeden przypadek użycia ma (może mieć) warianty. Poniżej fragment jednej z jego późniejszych publikacji:

W czym problem i o co ludzie kruszą kopie?

Co mówi specyfikacja notacji UML

Popatrzmy na aktualną specyfikację notacji UML:

18.1.3 Semantyka
18.1.3.1 Przypadki użycia i aktorzy
Przypadek użycia może odnosić się do dowolnej liczby aktorów. UseCase określa zestaw zachowań realizowanych przez opisywany wymaganiami przedmiot (system), które dają obserwowalny wynik, wartościowy dla powiązanych z nim Aktorów.
Każdy UseCase określa pewne zachowanie, które system może wykonać we współpracy z jednym lub większą liczbą aktorów. UseCase definiuje oferowane Zachowania systemu bez odniesienia do jego wewnętrznej struktury. Zachowania te, obejmujące interakcje między Aktorami i systemem, mogą skutkować zmianami jego stanu i komunikacją z jego otoczeniem. UseCase może zawierać możliwe warianty swojego podstawowego zachowania, w tym wyjątkowe zachowanie i obsługę błędów.

Co wynika z powyższego? Co znaczą oznaczone (pogrubienia moje) fragmenty:

1. (jeden) Przypadek Użycia to zestaw zachowań, więc jest możliwe, że jest ich więcej niż jedno dla jednego Przypadku Użycia.
2. Dają one jednak (Przypadki Użycia, każdy) jeden określony efekt (wynik), bo Przypadek Użycia to oczekiwany cel a nie możliwy wariant.
3. Przypadki użycia (diagram) to nie jest model wewnętrznej architektury systemu.

Ta definicja Przypadku Użycia (semantyka to definicje) pokazuje, że UML bardziej formalnie traktuje przypadki użycia niż Jacobson czy Cockburn. Diagram Przypadków Użycia jest “spisem treści” pozostałej specyfikacji systemu.

W konsekwencji przypadkiem użycia (celem aktora) będzie np. Faktura (jej utworzenie), i jak nie trudno się domyśleć także jej zachowanie i łatwe przywołanie w przyszłości. To, że mając taką usługę można sprawdzić co sprzedano, kiedy, można sprawdzić wcześniejszy (historyczny) adres nabywcy (bo mamy dostęp do historycznych faktur) itp. to możliwości jakie ma tu aktor, a nie kolejne przypadki użycia. Owszem, Faktura ma strukturę, reguły walidacji, prawa dostępu, i to właśnie jest realizowane przez wewnętrzne komponenty systemu (inne, powiązane z przypadkami użycia diagramy).

Kwestie tego czego i jak użyć w modelowaniu dowolnego systemu bardzo porządkuje SysML, który jest profilem UML. Z perspektywy modelowania systemu mamy trzy perspektywy do opisania:

Patrząc na to jakich diagramów używamy i do czego, można zbudować taki model pojęciowy:

Tak więc:

1. diagram przypadków użycia pokazuje wyłącznie to, komu i do czego system może posłużyć,
2. scenariusze opisują jak wygląda to użycie z perspektywy interakcji aktor-system,
3. architektura systemu pokazuje na jakie części (komponenty) podzielono ten system,
4. sekwencje pokazują współdziałanie tych elementów w toku realizacji ww. scenariuszy,
5. operacje (nazwy metod) są dokumentowane jako algorytmy i procedury,
6. kluczowym elementem system jest przetwarzana treść (struktura formularzy i komunikatów), jest ona elementem architektury systemu, gdyż są to dane przechowywane, a może to robić (przechowywanie) tylko jakiś określony komponent.

Tak więc pokazana wyżej “kostka” to zestaw powiązanych diagramów. Diagramy te “do czegoś służą”.

Podsumowanie

Ten krótki artykuł to uzupełnienie wcześniejszych arctykułów:

1. Diagramy w notacji UML,
2. Diagram przypadków użycia UML.
3. Modelowanie architektury HLD i LLD.

Generalnie pojęcie przypadku użycia i deklaracja ich użycia to umowa. Jednak jeżeli już ktoś “umawia się”, że “używa UML”, to powinien stosować się do “umowy” opisanej w specyfikacji UML. Jeżeli czyiś Model Przypadków Użycia UML nie da się w sposób spójny i kompletny kontynuować jako kolejne podległe, spójne i kompletne modele, to jest to Zły Model Przypadków Użycia UML.

Jeżeli wiec ktoś popełni coś takiego:

lub cos takiego:

To faktycznie lepiej niech tego nie robi… bo w specyfikacji UML jako poprawny przykład znajdziemy np. to:

Źródła