Tym razem recen­zje dwóch ksią­żek w jed­nym 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. 2^nd Edition. By Doug Rosenberg , Matt Stephens

Pierwsza wyda­na w 2005 roku, dru­ga 2013 r. Pierwsza meto­dę ICONIX opi­su­je na przy­kła­dach, w kon­tek­ście zwin­nych metod, pro­ces pro­jek­to­wa­nia i two­rze­nia opro­gra­mo­wa­nia bazu­ją­cy na mode­lach. Są to:

1. Model przy­pad­ków uży­cia spe­cy­fi­ku­ją­cy wyma­ga­ne zacho­wa­nia aplikacji.
2. Dziedzinowy model pojęciowy 
3. Model dzie­dzi­ny (archi­tek­tu­ra).
4. „Robustness dia­gram” abs­trak­cyj­ny model zacho­wa­nia bazu­ją­cy na jed­no­znacz­nych tyl­ko biz­ne­so­wych poję­ciach (dia­gram komunikacji).
5. Diagram sekwen­cji obra­zu­ją­cy zacho­wa­nia się ele­men­tów archi­tek­tu­ry sys­te­mu w toku reali­za­cji sce­na­riu­szy przy­pad­ków użycia. 

W ramach opi­sa­ne­go pro­ce­su ICONIX model przy­pad­ków uży­cia jest kla­sycz­nym mode­lem zna­nym z UML. Przypadek uży­cia jest tu defi­nio­wa­ny zgod­nie z UML czy­li jest to: inte­rak­cja akto­ra (oso­ba lub zewnętrz­ny sys­tem) z sys­te­mem, sekwen­cja aktyw­no­ści pro­wa­dzą­ca do osią­gnię­cia celu akto­ra (biz­ne­so­we­go celu, dla któ­re­go użył on tego systemu).

Model dzie­dzi­ny u auto­rów, to model odwzo­ro­wu­ją­cy powsta­ją­cy kod apli­ka­cji (jego architektura).

Robustness dia­gram tu, to dia­gram komu­ni­ka­cji ope­ru­ją­cy na abs­trak­cyj­nych trzech ste­reo­ty­pach boun­da­ry, con­trol, enti­ty. Jest to zna­ny tu i opi­sa­ny wzo­rzec BCE.

Diagram ten (dia­gram komu­ni­ka­cji) cza­sa­mi jest sto­so­wa­ny jako pomoc­ni­czy dia­gram na eta­pie ana­liz, jed­nak prak­ty­ka poka­zu­je, że dia­gram sekwen­cji w zupeł­no­ści wystar­czy do udo­ku­men­to­wa­nia zacho­wa­nia się ele­men­tów archi­tek­tu­ry systemu. 

Diagram sekwen­cji to typo­wy dla UML dia­gram, opi­sa­ny to nie raz.

Proces pro­jek­to­wa­nia bazu­je na sekwen­cji mode­li: mock-up’y ekra­nu i sko­ja­rzo­ne z nimi przy­pad­ki uży­cia. Każdy przy­pa­dek uży­cia ma sko­ja­rzo­ny z nim dia­gram sekwen­cji oraz test. Na bazie prze­te­sto­wa­ne­go mode­lu archi­tek­tu­ry two­rzo­ny jest model kodu i kod.

Książka wyda­na w 2005 roku, zawie­ra wie­le odnie­sień do ówcze­snej ​„sta­rej” wer­sji UML, robust­ness dia­gram jest trak­to­wa­ny jako ​„cos inne­go” niż UML.

Druga książ­ka to tak na praw­dę kolej­ne wcie­le­nie tej pierw­szej. Tytuł zmie­nio­no, prze­or­ga­ni­zo­wa­no i ​„uno­wo­cze­śnio­no” nie­co treść (UML v.2.xx). Autorami dru­giej są dwaj, z trzech auto­rów pierw­szej książ­ki. Obaj są pro­gra­mi­sta­mi. Generalnie pierw­szej, moim zda­niem, nie ma sen­su kupo­wać gdyż dru­ga to jej now­sze, znacz­nie ulep­szo­ne, wcielenie.

Pewną wadą w obu książ­kach jest małe odej­ście od UML w stro­nę wła­snej kon­wen­cji na dia­gra­mach. Dotyczy to szcze­gól­nie dia­gra­mu robust­ness, klas i przy­pad­ków uży­cia, gdzie uży­to nie­kon­wen­cjo­nal­nych kon­struk­cji. Na dia­gra­mach przy­pad­ków uży­cia nowy ste­reo­typ aso­cja­cji «invo­ke» oraz przy­pad­ki uży­cia mode­lu­ją­ce pro­ste ekra­ny takie jak login i logo­ut, nie­ty­po­we związ­ki pomię­dzy przy­pad­ka­mi uży­cia. Ta autor­ska, nie­zgod­na z UML, kon­wen­cja jest na szczę­ście opi­sa­na i wyja­śnio­na, jed­nak kon­se­kwen­cją jest to o czym nie raz pisa­łem: adre­sat doku­men­ta­cji musi znać, poza UML, tak­że tę nie­stan­dar­do­wą kon­wen­cję. Niestety nie jest ona zgod­na ze stan­dar­do­wym pro­fi­lem UML, gdyż zmie­nia zna­cze­nia ist­nie­ją­cych ele­men­tów UML^???. Drugą ​„nowin­ką” są dia­gra­my klas: mode­le dzie­dzi­ny, bazu­ją­ce na dzie­dzi­cze­niu i agre­ga­cjach. Dziedziczenia nie nale­ży sto­so­wać w mode­lu dzie­dzi­ny PIM, zaś o agre­ga­cjach (zwa­nych cza­sa­mi ​„sła­by­mi kom­po­zy­cja­mi”) pisa­łem nie raz, UML 2.5 od nich odszedł.

W ICONIX moż­na z powo­dze­niem sto­so­wać ​„czy­sty” UML, zigno­ro­wać robust­ness dia­gram, użyć popraw­nie mode­lu dzie­dzi­ny jako archi­tek­tu­ry (co nie raz opi­sy­wa­łem przy oka­zji wzor­ca BCE), nie ​„psuć” dia­gra­mów przy­pad­ków uży­cia zbęd­ny­mi (dia­gram sekwen­cji poka­zu­je wszel­kie wywo­ła­nia wewnętrz­nych kom­po­nen­tów) nad­mia­ro­wy­mi kon­struk­cja­mi (aso­cja­cja «invo­kes»).

Obie książ­ki zawie­ra­ją wie­le przy­kła­do­wych dia­gra­mów. Książka dru­ga zawie­ra ich wię­cej, są lepiej zhar­mo­ni­zo­wa­ne z UML i bazu­ją na wzor­cu MVC i zna­nych fra­me­wor­kach (m.in. Spring, Tomcat).

Tak więc z uwa­ga­mi jak wyżej, war­to zapo­znać sie z dru­gą: Use Case Driven Object Modeling with UML. Theory and Practice. 2^nd Edition. By Doug Rosenberg , Matt Stephens. W sto­sun­ku do bała­ga­nu jaki widzę w wie­lu doku­men­tach, jest to ogrom­ny postęp. Przykłady real­nych zasto­so­wań UML budu­ją wia­rę w sku­tecz­ność korzy­sta­nia z mode­li zamiast roz­wle­kłych i nie­jed­no­znacz­nych opisów.

Osobiście uży­wam tej meto­dy­ki od lat, bazu­ję na ​„czy­stym UML” dzię­ki cze­mu bez pro­ble­mu mogę korzy­stać ze stan­dar­do­we­go opro­gra­mo­wa­nia CASE a adre­sat zna­ją­cy tyl­ko UML nie ma pro­ble­mu z inter­pre­ta­cją. Zainteresowanych zapra­szam na szko­le­nie :). Zbliżony, w zasa­dzie ana­lo­gicz­ny, pro­ces opi­su­je Craig Larman w UML i wzor­ce pro­jek­to­we.

Wadą jest jed­nak odej­ście od UML i kom­pli­ko­wa­nie opi­su. Autorzy opi­su­ją ​„swo­je postrze­ga­nie” pro­ce­su pro­jek­to­wa­nia, w 2015 roku UML sie nie­co ​„upro­ścił i upo­rząd­ko­wał”, uży­wa­nie przy­pad­ków uży­cia to poka­za­nia wszel­kich kon­tek­stów akto­ra jest nie­zgod­ne z UML (w UML przy­pa­dek uży­cia to ​„to do cze­go powstał sys­tem” a nie ​„to do cze­go aktor uży­wa systemu”. 

1. ^?*?
   komen­tarz doda­ny po wła­snych bada­niach auto­ra tego arty­ku­łu, nad roz­sze­rzo­nym wzor­cem BCE (2019)
2. ^???
   w UML dopusz­cza się doda­wa­nie nowych ele­men­tów wyłącz­nie poprzez two­rze­nie nowych ste­reo­ty­pów dla ele­men­tów już ist­nie­ją­cych, inny­mi sło­wy moż­na doda­wać nowe typy ele­men­tów nota­cji UML, ale nie wol­no rede­fi­nio­wać już istniejących