Diagram przypadków użycia stale budzi wiele kontrowersji.  Bywa, że nafaszerowany związkami <<include>> i <<exclude>> wygląda jak talerz winogron.

Considering that the main rationale of use cases is to provide a conceptual bridge between business value and system capabilities, it’s not the role of business analysts to weld their concrete, and specific requirements into the consistent and stable functional architecture implemented by software classes. (źr. Use Cases should know nothing about classes | LinkedIn).

Powyższy cytat pochodzi z pewnej dyskusji. “Świat się spiera” na temat tego do czego służy diagram przypadków użycia. Dyskusja na LinkedIn pokazała, że “świat jest w tej kwestii podzielony”. Skąd problem?

W 2011 roku napisałem, nie pierwszy  i pewnie nie ostatni raz, że to ma być prosty diagram. Jego celem jest  określenie zakresu projektu w postaci, zrozumiałego dla zamawiającego, diagramu pokazującego  kto i do czego  będzie używał aplikacji. I nic ponad to. NIe przypadkiem jest często uznawany za tak zwany “[[model czarnej skrzynki]]”. Tak często spotykane, modele nafaszerowane szczegółami projektu wywleczonymi na wierzch z pomocą związków <<include>> i <<extend>>, stanowią zbędne (i przedwczesne) ujawnianie architektury wewnętrznej, zaś dziedziczenie na tych diagramach to  dla odmiany zbędne wplatanie tu modeli pojęciowych. Komplikowanie tego diagramu niszczy jego podstawową rolę: kontrakt zamawiającego z dostawcą oprogramowania: zamawiający zawiera świadomie ten kontrakt gdy zrozumie ten diagram.

…proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika (czytaj Przypadki użycia…).

Specyfikacja UML owszem zawiera opis, nie tylko, związków <<include>> i <<extend>> ale i dziedziczenia, należy jednak pamiętać, że specyfikacja zachowuje kompatybilność wstecz (aż do lat 90-tych!) i to, że pomysłodawca tego diagramu (obecny UML to zlepek trzech notacji) nie znał diagramu klas, wiec musiał sobie jakość poradzić z pokazaniem choćby namiastki wewnętrznej struktury aplikacji. Dysponując jednak lepszym do tego narzędziem, jakim jest diagram klas lub komponentów, komplikowanie diagramów przypadków użycia nie ma większego sensu. Polecam tu niedawno napisaną recenzje książki UML for Java programmers:

Drugim powodem jest postępująca standaryzacja modeli pojęciowych różnych  notacji rodem z OMG, między innymi z powodu rosnącego znaczenia (i korzyści z…)  całościowego podejścia do modelowania organizacji zwanego architekturą korporacyjna lub biznesową (lub po protu [[podejściem systemowym do analizy organizacji]]). Ta standaryzacja to między innymi “zrównanie” pojęcia “aktywność” w procesie biznesowym (BPMN) z pojęciem Przypadek Użycia (UML), gdzie jest to elementarna usługa, wspierająca aktywność aktora, mająca stan początkowy i końcowy (a proces ma wejście i wyjście), stan końcowy cechuje określona wartość  dla aktora (UML) lub odbiorcy (BPMN), z pojęciem usługa aplikacyjna w architekturze SOA (i w architekturze korporacyjnej).

Obecnie przypadki użycia stanowią pomost pomiędzy perspektywą biznesową widząca przypadki użycia jako “usługi aplikacji” a perspektywą aplikacji, która oferuje je (przypadki użycia) jako usługi aplikacyjne. Poniżej “klasyczny”, od lat znany, diagram obrazujący model SOA ([[Service Oriented Architecture]]):

Na tym diagramie widać (nie sugerujmy się kształtem ikon ;)) warstwę Business Servces, która stanowi ni mniej ni więcej tylko właśnie przypadki użycia aplikacji (Components) umieszczonych w warstwie poniżej. Na dzisiaj procesy biznesowe modelujemy notacją BPMN (twardziele nadal robią to diagramem aktywności UML ;)), a resztę poniżej notacją UML (mapując 1:1 atomowe procesy biznesowe na przypadki użycia, niektóre programy CASE robią to nawet automatycznie):

The most effective way to develop a quality software that can streamline and blend well with users’ daily operations is to begin by analyzing users’ daily work flows with care and precision and, to understand how parties work together to get jobs done. By doing so, you can find out the functions that the software should provide in order to help the users. (From Business process to Use Case…)

Jeżeli nad procesami umieścić model motywacji biznesowej (notacja BMM, nie ma tej warstwy na powyższym diagramie) to otrzymamy model architektury korporacyjnej (po kilku próbach zastosowania nadal uważam, że [[notacja ArchiMate]] nie wnosi żadnej wartości dodanej, jest to – pomysł na nowa notację – raczej zaprzeczeniem zasady “nie mnóż bytów ponad potrzebę” znanej jako [[brzytwa Ockhama]]).

Jest tu  jeszcze jedna ciekawa rzecz: nie ma danych na tych modelach. “Staromodne” podejście mówi, że oprogramowanie to struktury danych i funkcje. I tak jest od strony technicznej ale to nie ma nic wspólnego z biznesem. Biznes jest zainteresowany faktem sprzedaży, a to, że dokumentujemy do fakturą VAT to  “szczegóły”. Dlatego na tym poziomie abstrakcji (uogólnienia)  nie ma sensu robienie modeli danych, ma sens robienie specyfikacji obiektów biznesowych, na poziomie ich nazw. Takie podejście nazywa się zarządzaniem poziomem szczegółowości projektu (od ogółu do szczegółu), na poziomie modelowania takiej architektury nie ma znaczenia to, ile danych jest na fakturze, znaczenie ma, to  że zaistniał fakt sprzedaży i na czymś (nośnik danych, obiekt bezsensowy z nazwą) go  udokumentowano.

Tak więc na tytułowe pytanie obecnie należało by odpowiedzieć: nie, przypadki użycia nie znają swoich realizacji… W dokumentacji na etapie modelowania przypadków użycia, tworzymy prosty diagram złożony z trzech typów elementów: aktor, przypadek i system. Bez pomijania elementu “system” (prostokąt będący kontenerem ma przypadki użycia), który stanowi podstawę tego diagramu: wskazuje granice systemu.  Jakiekolwiek szczegóły, w tym modele danych, to ostatni etap pracy jakim jest projektowanie i wykonanie implementacji. Wszelkie bazy danych modelujemy na samym końcu.

Kolejny wniosek: przypadków użycia nie są setki a o rząd a nawet dwa rzędy mniej. Specyfikacje na setki przypadków użycia to jakieś totalne nieporozumienie (albo niezrozumienie). Usługa aplikacji świadczona aktorowi (kompletna) to nie wstawienie adresu na fakturze, a wystawienie (utworzenie) kompletnej faktury. Wstawianie adresów, produktów itp. to elementy scenariusza przypadku użycia (wywołania na diagramie sekwencji albo opis współdziałania aktora z ekranem aplikacji).

Nie ma też np. czegoś takiego jak “[[systemowe przypadki użycia]]”, anie czego takiego jak “[[biznesowe przypadki użycia]]” (to relikt z metodyki RUP z lat 90’tych przed pojawieniem się notacji BPMN). Wiem, wiem, że często się pojawiają w literaturze i na stronach znanych blogów, jednak nigdzie tam nie znalazłem definicji tych pojęć odróżniających te twory od “normalnych” przypadków użycia, interfejsów komponentów czy procesów biznesowych. Prowadzenie nowego pojęcia powinno mieć jakieś podstawy i wartość dodaną bez tego są tylko urywaniem niezrozumienia modelowanej istoty rzeczy i łamaniem zasady ekonomii myślenia, tej prostej zasady “nie twórz bytów ponad miarę” (przypominam [[brzytwa Ockhama]]) (niestety firma SPARX, producent bardzo popularnej i taniej aplikacji: Enterprise Architect, ma w zwyczaju wymyślanie różnych dziwnych bytów tego typu, między innymi “czas jako aktor systemu” nadając mu dedykowany stereotyp). Bo zastanówcie się, gdzie na powyższym diagramie SOA wstawić owe systemowe czy biznesowe przypadki użycia???

Owszem, można przyjąć dowolna konwencję tworzenia modeli ale wtedy należy ją opisać od strony pojęciowej. Bez tego model staje się zwykłym obrazkiem, nie jest modelem. Ale pytanie po co, skoro w BPMN/UML to wszystko jest, wraz z opisem jak “gładko” przejść z modelu biznesowego, przez model przypadków użycia do modelu architektury systemu… Owszem notacja UML zawiera wszystkie opisane tu pojęcia i symbole, ale nie wolno zapominać, że notacja to wyłącznie język czyli same słowa i gramatyka, sens maja dopiero zdania. Tak wiec pisząc “Krowa z silnikiem odrzutowym, jelita na czerwono, jądrowymi kopytami, wyprawiona na buty skóra, zniszczyła metro, wypadek samochodowy, przelatując nad Warszawą, liczba płyt chodnikowych to 1347, a następnie wylądowała w Elektrociepłowni Żerań, załadunek węgla w południe wykonany przez Kowalskiego, i pożywiła się węglem popijając wodę z Wisły” to poprawne gramatycznie, bezbłędnie napisane zdanie w języku polskim, ale nikt nie ma chyba wątpliwości, że kompletnie pozbawione sensu. Tak samo można poprawnie, zgodnie z zasadami notacji, narysować diagram UML …