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. Warto 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: