Tym razem recenzje dwóch książek w jednym wpisie:

1. Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens
2. Use Case Driven Object Modeling with UML. Theory and Practice. 2nd Edition. By Doug Rosenberg , Matt Stephens

Pierwsza wydana w 2005 roku, druga 2013 r. Pierwsza metodę ICONIX opisuje na przykładach, w kontekście zwinnych metod, proces projektowania i tworzenia oprogramowania bazujący na modelach. Są to:

1. Model przypadków użycia specyfikujący wymagane zachowania aplikacji.
2. Dziedzinowy model pojęciowy
3. Model dziedziny (architektura).
4. “Robustness diagram” abstrakcyjny model zachowania bazujący na jednoznacznych tylko biznesowych pojęciach (diagram komunikacji).
5. Diagram sekwencji obrazujący zachowania się elementów architektury systemu w toku realizacji scenariuszy przypadków użycia.

W ramach opisanego procesu ICONIX model przypadków użycia jest klasycznym modelem znanym z UML. Przypadek użycia jest tu definiowany zgodnie z UML czyli jest to: interakcja aktora (osoba lub zewnętrzny system) z systemem, sekwencja aktywności prowadząca do osiągnięcia celu aktora (biznesowego celu, dla którego użył on tego systemu).

Model dziedziny u autorów, to model odwzorowujący powstający kod aplikacji (jego architektura).

Robustness diagram tu, to diagram komunikacji operujący na abstrakcyjnych trzech stereotypach boundary, control, entity. Jest to znany tu i opisany wzorzec BCE.

Diagram ten (diagram komunikacji) czasami jest stosowany jako pomocniczy diagram na etapie analiz, jednak praktyka pokazuje, że diagram sekwencji w zupełności wystarczy do udokumentowania zachowania się elementów architektury systemu.

Diagram sekwencji to typowy dla UML diagram, opisany to nie raz.

Proces projektowania bazuje na sekwencji modeli: mock-up’y ekranu i skojarzone z nimi przypadki użycia. Każdy przypadek użycia ma skojarzony z nim diagram sekwencji oraz test. Na bazie przetestowanego modelu architektury tworzony jest model kodu i kod.

Książka wydana w 2005 roku, zawiera wiele odniesień do ówczesnej “starej” wersji UML, robustness diagram jest traktowany jako “cos innego” niż UML.

Druga książka to tak na prawdę kolejne wcielenie tej pierwszej. Tytuł zmieniono, przeorganizowano i “unowocześniono” nieco treść (UML v.2.xx). Autorami drugiej są dwaj, z trzech autorów pierwszej książki. Obaj są programistami. Generalnie pierwszej, moim zdaniem, nie ma sensu kupować gdyż druga to jej nowsze, znacznie ulepszone, wcielenie.

Pewną wadą w obu książkach jest małe odejście od UML w stronę własnej konwencji na diagramach. Dotyczy to szczególnie diagramu robustness, klas i przypadków użycia, gdzie użyto niekonwencjonalnych konstrukcji. Na diagramach przypadków użycia nowy stereotyp asocjacji <<invoke>> oraz przypadki użycia modelujące proste ekrany takie jak login i logout, nietypowe związki pomiędzy przypadkami użycia. Ta autorska, niezgodna z UML, konwencja jest na szczęście opisana i wyjaśniona, jednak konsekwencją jest to o czym nie raz pisałem: adresat dokumentacji musi znać, poza UML, także tę niestandardową konwencję. Niestety nie jest ona zgodna ze standardowym profilem UML, gdyż zmienia znaczenia istniejących elementów UML^???. Drugą “nowinką” są diagramy klas: modele dziedziny, bazujące na dziedziczeniu i agregacjach. Dziedziczenia nie należy stosować w modelu dziedziny  PIM, zaś o agregacjach (zwanych czasami “słabymi kompozycjami”) pisałem nie raz, UML 2.5 od nich odszedł.

W ICONIX można z powodzeniem stosować “czysty” UML, zignorować robustness diagram, użyć poprawnie modelu dziedziny jako architektury (co nie raz opisywałem przy okazji wzorca BCE), nie “psuć” diagramów przypadków użycia zbędnymi (diagram sekwencji pokazuje wszelkie wywołania wewnętrznych komponentów) nadmiarowymi konstrukcjami (asocjacja <<invokes>>).

Obie książki zawierają wiele przykładowych diagramów. Książka druga zawiera ich więcej, są lepiej zharmonizowane z UML i bazują na wzorcu MVC i znanych frameworkach (m.in. Spring, Tomcat).

Tak więc z uwagami jak wyżej, warto zapoznać sie z drugą:  Use Case Driven Object Modeling with UML. Theory and Practice. 2nd Edition. By Doug Rosenberg , Matt Stephens. W stosunku do bałaganu jaki widzę w wielu dokumentach,  jest to ogromny postęp. Przykłady realnych zastosowań UML budują wiarę w skuteczność korzystania z modeli zamiast rozwlekłych i niejednoznacznych opisów.

Osobiście używam tej metodyki od lat, bazuję na “czystym UML” dzięki czemu bez problemu mogę korzystać ze standardowego oprogramowania CASE a adresat znający tylko UML nie ma problemu z interpretacją. Zainteresowanych zapraszam na szkolenie :). Zbliżony, w zasadzie analogiczny, proces opisuje  Craig Larman w UML i wzorce projektowe.

Wadą jest jednak odejście od UML i komplikowanie opisu. Autorzy opisują “swoje postrzeganie” procesu projektowania, w 2015 roku UML sie nieco “uprościł i uporządkował”, używanie przypadków użycia to pokazania wszelkich kontekstów aktora jest niezgodne z UML (w UML przypadek użycia to “to do czego powstał system” a nie “to do czego aktor używa systemu”.

1. ^?*?
   komentarz dodany po własnych badaniach autora tego artykułu, nad rozszerzonym wzorcem BCE (2019)
2. ^???
   w UML dopuszcza się dodawanie nowych elementów wyłącznie poprzez tworzenie nowych stereotypów dla elementów już istniejących, innymi słowy można dodawać nowe typy elementów notacji UML, ale nie wolno redefiniować już istniejących