Ile scenariuszy ma Use Case i dlaczego nie jeden?

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:

Bajaj, M., Cole, B., & Zwemer, D. (2016, September 13). Architecture To Geometry – Integrating System Models With Mechanical Design. AIAA SPACE 2016. AIAA SPACE 2016, Long Beach, California. https://doi.org/10.2514/6.2016-5470

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

UML: diagramy i ich zastosowanie, model pojęciowy (opr. własne autora)

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:

(źr.: http://www.bawiki.com/blog/20140321_Do_We_Really_Need_Use_Case_Diagrams.html)

lub cos takiego:

(źr.: https://softwareengineering.stackexchange.com/questions/395944/is-my-use-case-uml-diagram-too-complicated)

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

Źródła

Tagi: ,

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 wykładowca akademicki wizytujący (nieetatowy), 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). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.

Ten post ma 2 komentarzy

  1. Michał Stachura 12 lutego 2024

    Opisany w definicji “UseCase określa zestaw zachowań” odczytuję jako opis działania “skomplikowanego” czarnego pudełka realizującego zapis i obróbkę wprowadzonych danych wejściowych przez różnych aktorów.
    Zakładam, że sprowadzenie formularzy do jak najprostszych form ostatecznie realizowałoby jeden scenariusz, niezależnie od tego ilu ludzi by go wypełniało… Tak wiem na końcu przychodzi użytkownik i w polu “Podaj plik pdf” załącza pdf.docx ale to już walidacja powinna odrzucić, uniemożliwiając realizację UseCase naszego czarnego pudełeczka 🙂

    1. Jarosław Żeliński 12 lutego 2024

      Czarna skrzynka to pudło mające w menu jakieś usługi do wyboru. Wewnętrzna złożoność to stos metod (procedury, algorytmy), np. jako jeden stos funkcji, albo podzielony na komponenty. Stos funkcji będzie serią poleceń wśród których będą “if .. then …” i “go to”. Jeżeli jednak podzielimy ten wielki stos funkcji na odpowiednio dobrane kawałki, nadamy im nazwy i pozwolimy na wysyłanie komunikatów między nimi, otrzymamy komponentową (obiektową) architekturę kodu.

      “Sprowadzenie formularzy do jak najprostszych form” to chyba jeden z najgorszych pomysłów. One powinny być realnymi dla ludzi (aktorów) bytami takimi jak Faktura, Zamówienia, Profil Klienta. Dzięki temu przyszły użytkownik w zasadzie nie musi sie niczego nowego uczyć, bo jedynie przechodzi “z papieru na monitor”. Jednak niewątpliwie konieczna jest weryfikacja treści tych formularzy, bo na papierze często używa się rzeczy zbędnych, nadmiarowych, a nie raz bywa, że faktycznie nielogicznych (ktoś sobie coś kiedyś wymyślił). Np. Faktura z dodrukiem aktualnego salda klienta (bardzo kiepski pomysł bo miesza dziedziny i strasznie komplikuje kod gerenerujący te fakturę).

      Wystawienie Faktury to np. 1. scenariusz tworzenia jej od zera, 2. scenariusz tworzenia na bazie zmówienia (jeśli takie istnieje), ale w obu przypadkach powstaje taka sama faktura z taką samą jej walidacją i ląduje w tym samym repozytorium.

      “walidacja powinna odrzucić, uniemożliwiając realizację UseCase naszego czarnego pudełeczka 🙂” i po to są walidacje by system był głupoto-odporny 🙂

Możliwość dodawania komentarzy nie jest dostępna.