Wprowadzenie

O podob­nej porze roku, w 2015 roku pisałem: 

W ICONIX moż­na z powo­dze­niem sto­so­wać​„czy­sty” UML

źr.: : ICONIX and Use Case Driven Object Modeling with UML – Jarosław Żeliński IT-Consulting

ICONIX to w zasa­dzie fun­da­ment obiek­to­we­go, zorien­to­wa­ne­go na przy­pad­ki uży­cia, pro­jek­to­wa­nie opro­gra­mo­wa­nia . Jest to od same­go począt­ku swo­je­go ist­nie­nia, meto­da kla­sy­fi­ko­wa­na jako zwin­na . Orientacja na Przypadki Użycia (use case dri­ven) to obec­nie kanon pro­jek­to­wa­nia . Coraz popu­lar­niej­szy wzo­rzec jakim są mikro­ser­wi­sy sta­je się ​„nor­mą” w pro­jek­to­wa­niu archi­tek­tu­ry .

Od same­go począt­ku ICONIX jest pro­mo­wa­ny jako ​„Zwinność bez skraj­no­ści”. Polecam też stro­nę ICONIX Proces (This websi­te is a col­la­bo­ra­tion betwe­en Matt Stephens and Doug Rosenberg, authors of Use Case Driven Object Modeling with UML – Theory and Practice, Agile Development with ICONIX Process, and Extreme Programming Refactored: The Case Against XP.)

ICONIX

Zwięzły opis, na pod­sta­wie źró­deł, poda­je anglo­ję­zycz­na WIKI (wpis opar­ty na publi­ka­cjach Rosenberg​’a ):

Podobnie jak RUP, pro­ces ICONIX jest opar­ty na przy­pad­kach uży­cia UML, ale jest bar­dziej lek­ki niż RUP. ICONIX dostar­cza wię­cej doku­men­ta­cji wyma­gań i pro­jek­tu niż XP i ma na celu unik­nię­cie para­li­żu ana­li­tycz­ne­go. Proces ICONIX wyko­rzy­stu­je tyl­ko czte­ry dia­gra­my opar­te na UML w czte­ro­stop­nio­wym pro­ce­sie, któ­ry pro­wa­dzi od przy­pad­ków uży­cia do dzia­ła­ją­ce­go kodu.

Głównym wyróż­ni­kiem ICONIX jest wypeł­nie­nie luki pomię­dzy ana­li­zą a imple­men­ta­cją. Lukę tę wypeł­nia­my od razu mode­lu­jąc mecha­nizm reali­za­cji przy­pad­ków uży­cia. Proces ten spra­wia, że przy­pad­ki uży­cia są znacz­nie szyb­ciej pro­jek­to­wa­ne, testo­wa­ne i implementowane.

Zasadniczo Proces ICONIX opi­su­je pod­sta­wo­wy, ​„logicz­ny” pro­ces ana­li­zy i mode­lo­wa­nia zorien­to­wa­ne­go na projektowanie. 

na pod­sta­wie: https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​I​C​O​NIX

Wyżej wymie­nio­na lite­ra­tu­ra tak pre­zen­tu­je pier­wot­ną wer­sję tego procesu:

W ory­gi­na­le (dia­gram powy­żej) pro­ces wyglą­da następująco:

Kamień milowy 1: Przegląd wymagań

Przed roz­po­czę­ciem pro­ce­su ICONIX musi być prze­pro­wa­dzo­na ana­li­za wyma­gań. Na pod­sta­wie tej ana­li­zy moż­na ziden­ty­fi­ko­wać przy­pad­ki uży­cia, stwo­rzyć poję­cio­wy model dzie­dzi­ny i wyko­nać kil­ka pro­to­ty­pów GUI (for­mu­la­rze).

Kamień milowy 2: Wstępny przegląd projektu

Po ziden­ty­fi­ko­wa­niu przy­pad­ków uży­cia moż­na opra­co­wać ogól­ne sce­na­riu­sze tego jak użyt­kow­nik i sys­tem będą ze sobą współ­dzia­łać. Przeprowadzana jest ana­li­za i pro­jek­to­wa­nie bazo­wej archi­tek­tu­ry oraz jej logi­ki dzia­ła­nia (robust­ness ana­ly­sis), aby zna­leźć poten­cjal­ne błę­dy w sce­na­riu­szach przy­pad­ków uży­cia, a poję­cio­wy model dzie­dzi­ny jest odpo­wied­nio aktu­ali­zo­wa­ny. Opisy przy­pad­ków uży­cia są waż­ne dla okre­śle­nia, jak użyt­kow­ni­cy będą wcho­dzić w inte­rak­cje z pro­jek­to­wa­nym sys­te­mem. Zapewniają one rów­nież opis, któ­ry moż­na poka­zać Klientowi i zwe­ry­fi­ko­wać, czy wyni­ki ana­li­zy wyma­gań były poprawne.

Kamień milowy 3: Szczegółowy Przegląd Projektu

Podczas tego eta­pu pro­ce­su ICONIX poję­cio­wy model dzie­dzi­ny i sce­na­riu­sze przy­pad­ków uży­cia są wyko­rzy­sty­wa­ne do zapro­jek­to­wa­nia archi­tek­tu­ry budo­wa­ne­go sys­te­mu (reali­za­cja logi­ki biz­ne­so­wej). Tworzony jest model archi­tek­tu­ry, a opi­sy i sce­na­riu­sze przy­pad­ków uży­cia wyko­rzy­sty­wa­ne są do two­rze­nia dia­gra­mów sekwencji.

Kamień milowy 4: Wdrożenie

Testy jed­nost­ko­we są pisa­ne w celu spraw­dze­nia, czy sys­tem będzie zgod­ny z opi­sem przy­pad­ków uży­cia i dia­gra­ma­mi sekwen­cji. Developer wybie­ra tech­no­lo­gię, powsta­je kod z wyko­rzy­sta­niem ww. opi­sa­nych dia­gra­mów i wybra­nej przez deve­lo­pe­ra technologii.

Kamienie milo­we 3 i 4 są reali­zo­wa­ne ite­ra­cyj­nie dla każ­de­go przy­pad­ku użycia. 

ICONIX dzisiaj

Mamy rok 2022, nie ma żad­nej rewo­lu­cji, nie ma obo­wiąz­ku sto­so­wa­nia ​„robust­ness dia­gram” (jego role peł­nią dia­gra­my archi­tek­tu­ry: kom­po­nen­tów, klas), jest mniej pro­zy na rzecz dia­gra­mów UML:

Poprzedzamy wszyst­ko ana­li­zą biz­ne­so­wą: opra­co­wu­je­my mode­le pro­ce­sów biz­ne­so­wych. Z ich pomo­cą zbie­ra­my wyma­ga­nia, jako potrze­by Zamawiającego. Stają się one kan­wą pro­jek­to­wa­ne­go sys­te­mu. Analiza Biznesowa sta­no­wi wsad dla Kamienia milo­we­go 1. 

Opisane wcze­śniej ​„kamie­nie milo­we” to odpo­wied­nio etapy:

1. Na pod­sta­wie ana­li­zy pro­ce­sów biz­ne­so­wych, mając mode­le poję­cio­we i regu­ły biz­ne­so­we oraz potrze­by, opra­co­wu­je­my listę przy­pad­ków uży­cia i wstęp­ne sza­blo­ny (makie­ty) formularzy. 
2. Mając przy­pad­ki uży­cia i makie­ty for­mu­la­rzy, pro­jek­tu­je­my sce­na­riu­sze opi­su­ją­ce inte­rak­cje aktor-sys­tem. Omawiamy je z Zamawiającym. 
3. Kolejny etap to pro­jek­to­wa­nie archi­tek­tu­ry LLD kolej­nych przy­pad­ków uży­cia oraz testu­ją­ce je dia­gra­my sekwen­cji. Na bie­żą­co jest aktu­ali­zo­wa­na archi­tek­tu­ra wewnętrz­nej inte­gra­cji HLD (nie ma tu potrze­by two­rze­nia nie­ty­po­we­go ​„robust­ness diagram”).
4. Od tego momen­tu, ite­ra­cyj­nie przy­ro­sto­wo, kolej­no zapro­jek­to­wa­ne i prze­te­sto­wa­ne na dia­gra­mach sekwen­cji, przy­pad­ki uży­cia są prze­ka­zy­wa­ne do deve­lop­men­tu, a w tym cza­sie powsta­ją pro­jek­ty LLD kolejnych. 

Punkty 3. i 4. są reali­zo­wa­ne w pętli aż do odda­nia do użyt­ku całe­go sys­te­mu. Jeżeli jest taka potrze­ba, moż­na opra­co­wać wstęp­nie wszyst­kie przy­pad­ki uży­cia do wyce­ny, a potem dopra­co­wy­wać je w toku dal­szej pracy. 

Jeżeli infor­ma­cje (for­mu­la­rze) cechu­ją się sta­no­wo­ścią lub, jako doku­men­ty mają sta­tu­sy, to two­rzy­my dodat­ko­wo dia­gra­my maszy­ny sta­no­wej dla tych doku­men­tów. Wszędzie tam, gdzie logi­kę (mecha­nizm) dzia­ła­nia nale­ży udo­ku­men­to­wać algo­ryt­me­mem lub sce­na­riu­szem opi­su­ją­cym współ­dzia­ła­nia kom­po­nen­tów na wyż­szym pozio­mie abs­trak­cji, sto­su­je­my dia­gra­my aktywności.

Scenariusz ite­ra­cyj­ne­go wytwa­rza­nia w pro­ce­sie ICONIX:

Idea pro­ce­su ana­li­zy i pro­jek­to­wa­nia zorien­to­wa­ne­go na przy­pad­ki uży­cia i ich reali­za­cje jest aktu­al­na i kul­ty­wo­wa­na, nie zawsze pod nazwą ICONIX :

Powyższa struk­tu­ra pro­jek­tu obiek­to­wo-zorien­to­wa­ne­go (albo jak kto woli na kom­po­nen­ty i inter­fej­sy) jest nadal aktu­al­nym ele­men­tem wie­lu pod­ręcz­ni­ków z zakre­su inży­nie­rii opro­gra­mo­wa­nia oraz opra­co­wań i metod takich jak Use Case 2.0 .

Struktura procesu wytwarzania oprogramowania

Całość tego pro­ce­su pro­jek­to­wa­nia od ogó­łu do szcze­gó­łu moż­na zobra­zo­wać tak:

Sam pro­ces ICONIX nie jest niczym spe­cjal­nym ani wyjąt­ko­wym, w sen­sie nota­cyj­nym. Tak zwa­ny ​„robust­ness dia­gram” nie był nowym, innym dia­gra­mem UML, to był dia­gram komu­ni­ka­cji (com­mu­ni­ca­tion dia­gram UML). Jedyną jego ​„wadą” było tu jego przed­wcze­sne uży­cie w pro­ce­sie: był uży­wa­ny na począt­ku pra­cy jako biz­ne­so­wy model pro­ce­su prze­pły­wu danych. ​„Robustness dia­gram” sto­so­wa­ny był ana­lo­gicz­nie do dia­gra­mów DFD w meto­dach strukturalnych. 

Wzorzec BCE

ICONIX to bar­dzo sku­tecz­na, zwin­na meto­da pro­jek­to­wa­nia opro­gra­mo­wa­nia zorien­to­wa­na na mode­le (ang. MDD, Model Driven Development). Mimo sto­so­wa­nia UML, jest lek­ka, bo korzy­sta­my z kil­ku pod­sta­wo­wych typów dia­gra­mów UML i ich pro­stych form. ICONIX jest koja­rzo­ny głów­nie z iko­na­mi ste­reo­ty­pów BCE (Boundary, Control, Entity). Stereotypy te w posta­ci gra­ficz­nej są dostęp­ne w wie­lu narzę­dziach CASE, w tym EA SPARX i Visual-Paradigm. Architektura LLD przy­pad­ków uży­cia, jest obec­nie budo­wa­na w opar­ciu o ten wzo­rzec oraz dobrze już pozna­ne inne pod­sta­wo­we wzor­ce pro­jek­to­we. Należą do nich: łań­cuch odpo­wie­dzial­no­ści, saga, mikro­ser­wi­sy, repo­zy­to­rium, koper­ta (enve­lo­pe, DTO). BCE to wzo­rzec zakła­da­ją­cy, że kom­po­nent reali­zu­ją­cy przy­pa­dek uży­cia, będzie archi­tek­tu­rę zbu­do­wa­ną z odręb­nych kom­po­nen­tów, odpo­wie­dzial­nych za: komu­ni­ka­cje z oto­cze­niem (bouda­ry), reali­za­cje logi­ki dzie­di­zno­wej (con­trol) i prze­cho­wy­wa­nie danych (enti­ty), dane prze­cho­wu­je­my jako całe komu­ni­ka­ty (enve­lo­pe).

Podsumowanie

To, że ICONIX jest sto­sun­ko­wo rzad­ko uży­wa­ny, szcze­gól­nie pod tą nazwą, ma swo­je pod­ło­że w tym, że przede wszyst­kim wyma­ga zro­zu­mie­nia pro­ce­su two­rze­nia kom­po­nen­to­wo-zorien­to­wa­nej archi­tek­tu­ry, wyma­ga też zna­jo­mo­ści i zro­zu­mie­nia UML, wyma­ga pozna­nia i zro­zu­mie­nia obiek­to­wych wzor­ców pro­jek­to­wych, wyma­ga przede wszyst­kim umie­jęt­no­ści abs­trak­cyj­ne­go myśle­nia. Wszystko to jed­nak jest rekom­pen­so­wa­ne bar­dzo szyb­kim two­rze­niem wyso­kiej jako­ści oprogramowania.

Proces ten wspie­ra tak­że roz­dział pro­jek­to­wa­nia i imple­men­ta­cji (patrz powyż­szy sche­mat: Struktura ról i pro­duk­tów pro­jek­tu w pro­ce­sie ICONIX). ICONIX bywa też nie­słusz­nie koja­rzo­ny z ​„cięż­kim” pro­ce­sem wytwa­rza­nia opro­gra­mo­wa­nia, jakim jest Rational Unified Process (o któ­rym prak­tycz­nie nie pisa­łem na swo­im blogu). 

Powodem rzad­kie­go sto­so­wa­nia ICONIX, jest te z to, że nie­ste­ty świat został, już w latach 90-tych, moc­no ​„zepsu­ty” przez C++ i Javę. Są to czę­sto cięż­kie, mono­li­tycz­ne fra­me­wor­ki opar­te na rela­cyj­nym mode­lu danych, gdzie nie ma ści­słe­go podzia­łu na logi­kę dzie­dzi­no­wą i śro­do­wi­sko (MVC). Java to nadal jed­na z naj­kosz­tow­niej­szych i naj­mniej efek­tyw­nych metod pra­cy. Framework EJB do dziś jest opi­sy­wa­ny jako źró­dło obiek­to­we­go antyw­zor­ca pro­jek­to­we­go o nazwie ​„ane­micz­ny model dzie­dzi­ny”.

Analiza obiektowa i projektowanie

Od daw­na toczą sie dys­ku­sje na temat tego czym jest OOP i OOAD. Definiowanie para­dyg­ma­tu obiek­to­we­go jako dzie­dzi­cze­nia i łącze­nia danych i funk­cji w obiek­ty zosta­ły zdys­kre­dy­to­wa­ne już pod koniec lat 90-tych przez same­go ​„auto­ra pomy­słu” (Alan Kay), któ­ry pod­kre­śla, że isto­tą obiek­to­wo­ści jest podział na samo­dziel­ne kom­po­nen­ty (obiek­ty) oraz ich wza­jem­na komu­ni­ka­cja (w tym polimorfizm). 

ICONIX jest jed­ną z pierw­szych obiek­to­wych, zwin­nych metod ana­li­zy i pro­jek­to­wa­nia: całe opro­gra­mo­wa­nie skła­da się z komu­ni­ku­ją­cych się obiek­tów (kom­po­nen­ty i dia­gra­my sekwen­cji). Do mode­lo­wa­nia wyko­rzy­sty­wa­ny jest mini­mal­ny zestaw dia­gra­mów UML w ich mini­mal­nej posta­ci. Dalej już oddam głos deweloperom:

Zainteresowanych zapra­szam na warsztaty. 

Źródła