Mam problem z przypadkami

użycia, a właściwie z UML-owym diagramem przypadków użycia.

Na początek małe zastrzeżenie: mówię o diagramach przypadków użycia a nie przypadkach użycia. Przypadki użycia to całkiem niezłe narzędzie, któremu poświęcę trochę uwagi dalej. Zwracam też uwagę, że mówię tu o czystym UMLu, bez wchodzenia w tematykę metodologii, frameworków modeli itp. Wracając do naszych dzisiejszych bohaterów – sądzę, że diagramy przypadków to bardzo niebezpieczne narzędzie, które może łatwo wyrządzić więcej szkód niż przynieść pożytków.

Co to ja nie jestem

Przy pierwszym zetknięciu się z UMLem dostajemy informację „(model) diagram przypadków użycia służy do opisu wymagań”. Komunikat jest tym wyraźniejszy im komunikujący ma większy związek ze standardem lub mniejsze doświadczenia praktyczne. Co prawda coraz częściej wspomina się że „model wymagań” musi zostać uzupełniony takimi rzeczami jak opis scenariuszy, warunków brzegowych, współdziałania ze sobą i dostarczanych wartości. Jednak informacja jaką się otrzymuje prowadzi do wniosku, że  diagram UC to główny sposób analizy i zapisu wymagań, do którego można ewentualnie, jak ktoś chce, dodać inne elementy jak ktoś chce. Oczywiście na dodatki nigdy nie ma czasu ani zasobów, a że sprawa jest załatwiona bo „mamy przecież już diagram przypadków użycia”, to na nich się poprzestaje.

W efekcie powstają „opisy” wymagań, składające się z rysunków pełnych jajeczek i ludzików z patyczków które w zasadzie nie wnoszą żadnej informacji a tylko zaciemniają obraz, bo

Juz kajs jaki jest każdy widzi

Typowy diagram UC wygląda tak – parę ludzików z patyków, czasem jeszcze powiązanych dziedziczeniem(!?), trochę elips powiązanych kreskami z ludzikami (czasem z dodatkowym efektem „spagetti”) i trochę tekstu. Tekst najczęściej ogranicza się do nazw przypadków użycia. Czyli: mamy spory rysunek, którego istotna treść ogranicza się do kilku, 3-4 wyrazowych opisów. Opisów, które każdy z czytających rozumie inaczej. Bo co właściwie znaczy „wprowadzenie zamówienia” albo „weryfikacja poprawności wniosku”? Nawet jeżeli mamy określone z czego się składa takie zamówienie czy wniosek, to każdy wyobrazi sobie inaczej scenariusz wprowadzania,warunki brzegowe, ograniczenia, warunki początkowe itd. W efekcie przedstawiając wymagania wyłącznie jako diagram przypadków użycia, uzyskujemy taki rezultat – klient zamawia coś, analityk opisuje coś innego, a programista tworzy całkiem coś innego.

Do tego dochodzi jeszcze problem zaśmiecenia diagramów przez zbędne lub mało istotne elementy. Przykład – w zasadzie aktorzy, ich rodzaje, zależności między nimi, są mało ważnymi elementami. Z punktu widzenia programisty czy użytkownika istotne jest CO system będzie robił (czyli jak UC działa) a nie kto będzie z tego UC korzystał. Tego rodzaju informacja jest tak naprawdę istotna dla udziałowców lub właścicieli biznesowych(podział zadań), specjalistów bezpieczeństwa i projektantów GUI.

Podsumowując – mamy diagram na którym zamieszczona jest w większości niepotrzebna lub nieistotna informacja, a istotne aspekty są albo ukryte, albo nie są w ogóle opisane. W zasadzie sam pomysł diagramu przypadków użycia jako elementu UML jest kiepski. Taki trochę

Frak do kaloszy

Po chwili zastanowienia się widać, że ten rodzaj diagramów nie spina się z pozostałymi, jest z trochę innej bajki. Pozostałe rodzaje diagramów, w ten lub inny sposób, są ze sobą powiązane. W zasadzie dowolny element UMLa można powiązać z dowolnym klasyfikatorem(klasy mają inne klasy, pakiety mają klasy, klasy są w komponentach, obiekty/klasy mają stany i przejścia między nimi, komponenty są deployowane itd) i będzie to miało sens. Przypadki użycia w UML nie mają prostego i ścisłego powiązania z pozostałą częścią modelu. Owszem można zdefiniować powiązanie UC z dowolnym klasyfikatorem, ale już sposób realizacji tego powiązania, jego znaczenie i sens jest słabo określone (sformułowania typu „can”, „may”, patrz: UML Superstructure str. 596). Do tego, ta definicja nie ma (przynajmniej w większości narzędzi) prostego sposobu prezentacji.

Przypadkom użycia brakuje konkretności pozostałych elementów UMLa, a raczej możliwości ścisłego zdefiniowania. Tak w skrócie – definicja UC nigdy nie może się zbliżyć szczegółowością do np. definicji interfejsu. Pozostałe diagramy UMLowe mogą być uzupełnione bardzo szczegółowymi informacjami, ograniczeniami. W przypadku diagramów UC nie da rady tego zrobić.

Z drugiej strony, w diagramach UC nie ma prostej, zdefiniowanej drogi pozwalającej odwzorować hierarchię wymagań, różne poziomy wymagań (systemowy, biznesowy, funkcję). Diagram umożliwia powiązanie wzajemne UC ale raczej na jednym poziomie. W przypadku bardziej złożonych systemów, wprowadza to spore ograniczenie lub wymusza kombinowanie, wprowadzanie własnych rozszerzeń lub interpretacji standardu UML.

Swoją drogą, z diagramami UC jest jestem poważny problem – UML nie wskazuje jak interpretować zapis, jak powiązać wymaganie z jego realizacją (ale to jest problem całego UMLa – nie ma tak naprawdę semantyki i ma tak ogólny syntax że wszystko i nic można w nim napisać). ¹

Co robić? Co robić?

Przede wszystkim – należy wielkimi literami wypisać sobie, że diagram UC nie służy do zbierania wymagań. To jest tylko narzędzie (jedno z wielu) do wspierania tegoż zbierania. Główna część zadania pt. „analiza wymagań” odbywa się całkiem gdzie indziej, diagram UC może służyć raczej do prezentacji, w skrócony sposób, informacji opisanych gdzie indziej. W większości przypadków nie jest jednak niezbędny lub może być zastąpiony czymś lepszym, bardziej dostosowanym do naszych potrzeb.

Kiedy już sobie to uświadomimy, można przejść dalej. Zapewne ktoś już przed nami trafił na taki problem, przemyślał go i coś od siebie wyprodukował na ten temat. Warto sprawdzić co sądzą inni, jak rozwiązali ten problem. Szczęśliwi ci, którzy wykorzystują gotową metodologię – twórcy większości z nich przemyśleli problem zbierania wymagań i w jakiś sposób odnieśli się do diagramów UC, choć nie zawsze uczynili to na wystarczającym poziomie szczegółowości. Niektórzy, jak twórcy i fanatycy metodyk „agile”, zignorowali to narzędzie, stwierdzając, że do niczego nie jest im potrzebne. Inni, zwłaszcza projektanci RUP, wręcz wprasowali diagramy UML na stałe w swoją metodykę. Więc w skrócie – jeżeli stosujesz już jakąś gotową metodykę, to prawie na pewno otrzymałeś też sugestie dotyczące sposobów zastosowania diagramów przypadków użycia.

Jeżeli jednak, wskazówki czy sugestie zaproponowane przez metodykę są niewystarczające, można przejść do czegoś bardziej konkretnego – frameworków modeli. Przykładowy model matrycy Zachmana zawiera w sobie „ścieżkę” wiążącą wymagania biznesowe, cele, z wymaganiami systemowymi, ich realizacja i wdrożeniem, wspierając się (tu akurat zależy od implementacji) diagramami UML, w tym przypadków użycia. Podobnie inne standardy, szablony, frameworki takie jak np. TOGAF, wskazują i ułatwiają zastosowanie diagramów przypadków użycia w modelowaniu wymagań.

Idąc krok dalej można jeszcze inaczej – opracować własny sposób zastosowania diagramów przypadków użycia i trzymać się go. Tutaj drogi realizacji są bardzo różne – od całkowitej rezygnacji z diagramów UC do strategii szczegółowego uzupełniania informacji przy użyciu innych elementów UMLa, jak np. diagramy stanów, interakcji sekwencji itd. Można także wesprzeć się takimi koncepcjami jak schemat tekstowego opisu przypadków użycia zaproponowany przez Alistaira Cockburna, Xpowe scenariusze użytkownika.

Na koniec jeszcze trochę uwag o ogólnej sensowności diagramów przypadków użycia. Jeżeli już musimy ich używać to warto się zastanowić do czego. W mojej opinii to narzędzie dobrze nadaje się do modelowania wymagań systemowych, czyli niższym niż faktycznie wymagania biznesowe. Na poziomie realizacji zaczynają nabierać większego sensu powiązania między przypadkami użycia, zależności aktorów od przypadków użycia. Do modelowania wymagań biznesowych znacznie bardziej nadaje się BPMN, opisy tekstowe, makiety(prototypy).