ICONIX and Use Case Driven Object Modeling with UML

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. 2nd 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 opi­su­ją­cy wyma­ga­ne zacho­wa­nia aplikacji.
  2. Model dzie­dzi­ny bazu­ją­cy na obiek­tach świa­ta rze­czy­wi­ste­go i związ­kach mię­dzy nimi (struk­tu­ra kodu).
  3. Robustness dia­gram” abs­trak­cyj­ny model dzie­dzi­ny, obiek­to­wy model bazu­ją­cy na jed­no­znacz­nych tyl­ko biz­ne­so­wych pojęciach.
  4. Diagram sekwen­cji obra­zu­ją­cy zacho­wa­nia każ­de­go obiek­tu mode­lu robust­ness”.

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 aplikacji.

Robustness dia­gram tu, to nie­ty­po­wy dia­gram klas ope­ru­ją­cy na abs­trak­cyj­nych trzech ste­reo­ty­pach boun­da­ry, con­trol, enti­ty. Jest to (obec­nie) dia­gram klas UML zna­ny tu i opi­sa­ny jako wzo­rzec BCE.

ICONIX_RobustnessDiagram
Może i duży bała­gan ale jest 🙂 (źr. Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens)

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 bazu­ją­cy na mode­lu robust­ness oraz test. Na bazie prze­te­sto­wa­ne­go mode­lu two­rzo­ny jest model kodu i kod.

ICONIX_Process
(źr. Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens)

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.

W tym miej­scu war­to powie­dzieć, że to co auto­rzy nazy­wa­ją
robust­ness dia­gram”, to model dzie­dzi­ny, rozu­mia­ny jako Model we wzor­cu MVC. Wyrażenie go wzor­cem BCE bar­dzo poma­ga w utrzy­ma­niu dys­cy­pli­ny: w Modelu dzie­dzi­ny umiesz­cza­my wyłącz­nie i całą logi­kę biz­ne­so­wą (dzie­dzi­no­wą).?*?

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 speł­nia ona roli pro­fi­lu 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, uznać że robust­ness dia­gram to nic inne­go jak stan­dar­do­wy dia­gram klas UML – model dzie­dzi­ny (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. 2nd 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. 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

Inne artykuły na podobny temat

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.