Ten często aktualizowany przeze mnie wpis, stał się niemalże kompletnym opisem metodyki projektowania oprogramowania. Nie jest to moja metodyka, to metodyka z której ja także korzystam. Artykuł zaopatrzyłem w bogaty spis literatury źródłowej i kilka ciekawych referatów konferencyjnych. Polecam szczególnie moim obecnym i potencjalnym klientom, bo to opis produktu jaki ode mnie dostaną (polecam także wpis: Moja rola w projektach). 

Wprowadzenie

Opisany tu pro­ces mode­lo­wa­nia sta­ra sie odpo­wie­dzieć na powyż­sze pytania.

Często spo­ty­ka­na nazwa: ICONIX, przy­lgnę­ła do metod zorien­to­wa­nych na przy­pad­ki uży­cia za spra­wą publi­ka­cji Use Case Driven Object Modeling with UML . Nie jest to jed­nak ani patent ani jedy­na meto­da z uży­ciem UML. Wielu innych auto­rów opi­su­je to stan­dar­do­we podej­ście po pro­stu jako ​„meto­dy kom­po­nen­to­we pro­jek­to­wa­nia zorien­to­wa­ne na przy­pad­ki uży­cia” . Będę uży­wał nazwy ICONIX w dal­szej czę­ści tyl­ko dla wygody. 

Głównym wyróż­ni­kiem pro­ce­sów takich jak ICONIX jest wypeł­nie­nie luki pomię­dzy ana­li­zą potrzeb 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życia. 

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 stan­dard kom­po­nen­to­we­go, zorien­to­wa­ne­go obiek­to­wo, na przy­pad­ki uży­cia i inter­fej­sy kom­po­nen­tów, pro­ce­su pro­jek­to­wa­nia 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 .

Bardzo istot­ne jest tu tak­że zro­zu­mie­nie róż­ni­cy mię­dzy inży­nie­rem opro­gra­mo­wa­nia (sys­te­mu) a dewe­lo­pe­rem (kode­rem): zain­te­re­so­wa­nym naj­pierw pole­cam lek­tu­rę arty­ku­łu: Software Engineer Vs. Programmer: What?s the Difference? To co robi inży­nier bywa nazy­wa­ne ​„Diagrams as Code” bo:

Programming is not sole­ly abo­ut con­struc­ting software?programming is abo­ut desi­gning software.

UWAGA! Identyczny efekt (dia­gra­my) da pro­jekt udo­ku­men­to­wa­nia ist­nie­ją­cej apli­ka­cji! Taka ​„rewers-inży­nie­ria” wyma­ga jedy­nie ści­słej współ­pra­cy zespo­łu, któ­ry napisał/zna kod. 

ICONIX

Modelowanie pole­ga na abs­tra­ho­wa­niu od szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mecha­nizm.(Craver & Tabery, 2019)

Nie jest żaden nowy czy inny sys­tem nota­cyj­ny. ICONIX to, uży­ta pierw­szy raz w latach 90-tych, nazwa usys­te­ma­ty­zo­wa­ne­go pro­ce­su ana­li­zy i pro­jek­to­wa­nia obiek­to­we­go z uży­ciem ​„czy­stej” nota­cji UML. Od same­go począt­ku ICONIX jest pro­mo­wa­ny jako ​„Zwinność bez skraj­no­ści”. Ten, opi­sa­ny tu, pro­ces ana­li­zy i pro­jek­to­wa­nia jest sze­ro­ko opi­sy­wa­ny w pod­ręcz­ni­kach tak­że bez nazwy wła­snej ICONIX .

Na stro­nie auto­rów 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.

https://​ico​ni​xpro​cess​.word​press​.com/​a​b​o​ut/

Zwięzły opis, na pod­sta­wie źró­deł, poda­je tak­że 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 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:

ICONIX dzisiaj

Mamy rok 2022, nie ma żad­nej rewo­lu­cji, ​„robust­ness dia­gram” to dia­gram komu­ni­ka­cji (lub 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 systemu. 

Biorąc pod uwa­gę aktu­al­ny stan nota­cji na OMG​.org ​„kamie­nie milo­we” pro­ce­su to odpo­wied­nio eta­py i ich produkty:

1. Mając wynik ana­li­zy biz­ne­so­wej w posta­ci map pro­ce­sów biz­ne­so­wych, mode­li poję­cio­wych i listy reguł biz­ne­so­wych oraz potrze­by biz­ne­so­we (cele pro­jek­tu), opra­co­wu­je­my listę przy­pad­ków uży­cia (UC) oraz wstęp­ne sza­blo­ny (makie­ty) for­mu­la­rzy na bazie doku­men­tów opi­sa­nych w pro­ce­sach biznesowych.
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 planowane/wymagane inte­rak­cje aktor-sys­tem. Omawiamy je z Zamawiającym. Na tym eta­pie moż­na dodat­ko­wo udo­ku­men­to­wać algo­ryt­my (meto­dy) przetwarzania/walidacji tre­ści for­mu­la­rzy (szcze­gól­nie, gdy począt­ko­wo zakła­da­my zakup stan­dar­do­we­go opro­gra­mo­wa­nia speł­nia­ją­ce­go tak opi­sa­ne wyma­ga­nia). Jeżeli nie, pro­jek­to­wa­ne jest opro­gra­mo­wa­nie dedykowane. 
3. Kolejny etap to zapro­jek­to­wa­nie archi­tek­tu­ry HLD apli­ka­cji, czy­li ukła­du kom­po­nen­tów reali­zu­ją­cych poszcze­gól­ne UC oraz dia­gra­my sekwen­cji opi­su­ją­ce współ­dzia­ła­nie tych kom­po­nen­tów w toku reali­za­cji sce­na­riu­szy UC.
4. Od tego momen­tu, ite­ra­cyj­nie-przy­ro­sto­wo, pro­jek­to­wa­ne są reali­za­cje UC jako ich archi­tek­tu­ry LLD i dia­gra­my sekwen­cji opi­su­ją­ce ich wewnętrz­ne dzia­ła­nie, tak opi­sa­ne reali­za­cje prze­ka­zy­wa­ne są kolej­no do implementacji. 

Kluczowy jest pkt.1. gdyż to for­mu­la­rze (doku­men­ty) są klu­czo­wym nośni­kiem infor­ma­cji czy­li danych i ich kon­tek­stu. Ten etap to korzy­sta­nie z wyni­ków ana­li­zy biz­ne­so­wej: iden­ty­fi­ka­cja doku­men­tów oraz ich for­ma­li­za­cja i standaryzacja: 

Kluczowe regu­ły: (1) doku­ment jest kla­sy­fi­ko­wa­ny albo jako opis obiek­tu albo fak­tu, (2) opis fak­tu nie może być mody­fi­ko­wa­ny a obiek­tu tak (aktu­ali­za­cja sta­nu fak­tycz­ne­go), (3) mody­fi­ka­cja opi­su obiek­tu jest fak­tem (któ­ry moż­na doku­men­to­wać), (4) opis fak­tu musi doty­czyć co naj­mniej jed­ne­go obiektu. 

źr.: Dokument jako nośnik danych i meto­da zarzą­dza­nia dany­mi ? agre­gat doskonały

Punkt 2. to pro­jek­to­wa­nie reali­za­cji wyma­gań biz­ne­so­wych i mode­lo­wa­nie sys­te­mu jako ​„czar­nej skrzyn­ki”, to umo­wa (zakres pro­duk­tu) z zamawiającym.

Punkty 3. i 4. są reali­zo­wa­ne w pętli aż do odda­nia do użyt­ku całej aplikacji. 

Diagramy UML

Całość doku­men­to­wa­na jest z uży­ciem nota­cji UML.

Pierwszy dia­gram jaki powsta­je to Diagram Przypadków Użycia. Jest to jeden dia­gram defi­niu­ją­cy kon­tekst i zakres pro­jek­tu oraz jego oto­cze­nie: użyt­kow­ni­ków i zewnętrz­ne, inte­gro­wa­ne aplikacje.

Dla każ­de­go przy­pad­ku uży­cia (UC) pro­jek­tu­je­my bazo­wy for­mu­larz, na bazie odpo­wia­da­ją­ce­go mu doku­men­tu z mode­lu pro­ce­sów biz­ne­so­wych. Najlepiej użyć do tego Diagramu Struktur Złożonych (jest to zorien­to­wa­ny na doku­men­ty model danych). Każdy UC nale­ży opi­sać dia­lo­giem aktor-sys­tem opi­su­ją­cym ​„co sys­tem ma robić”.

Jeżeli dane (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 Diagramy Maszyny Stanowej 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­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 Diagramy Aktywności.

Kolejny dia­gram to Diagram Komponentów, na któ­rym opi­su­je­my wewnętrz­ną, kom­po­nen­to­wą archi­tek­tu­rą apli­ka­cji (tu korzy­sta­my głow­nie z wzor­ców: Mikro-ser­wi­sy i Saga) oraz adap­te­ry inte­gra­cyj­ne dla zewnętrz­nych apli­ka­cji (patrz Diagram Przypadków Użycia jako kontekst).

Ostatecznie dla każ­de­go kom­po­nen­tu (mikro-ser­wis) two­rzy­my jego archi­tek­tu­rę LLD z uży­ciem Diagramu Klas i tak­że Diagramu Sekwencji. 

Diagram Przypadków Użycia to dekla­ra­cja zakre­su sys­te­mu dla przy­szłe­go użyt­kow­ni­ka: ​„czar­na skrzyn­ka”. Diagramy kom­po­nen­tów i klas to sta­tycz­na archi­tek­tu­ra sys­te­mu, dia­gra­my aktyw­no­ści i sekwen­cji opi­su­ją jego zacho­wa­nie. Ten model nazy­wa­my to ​„bia­łą skrzynką”. 

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. Dostępna jako Use CAse 2.0 lub w wer­sji aka­de­mic­kiej bez wła­snej nazwy jako pro­ces pro­jek­to­wa­nia :

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 .

Ciekawostką jest, że powyż­szy pod­ręcz­nik ma 594 stro­ny, nadal jest w uży­ciu na wie­lu uczel­niach, a meto­dy obiek­to­we zorien­to­wa­ne na przy­pad­ki uży­cia to nadal tyl­ko jeden ostat­ni roz­dział o obję­to­ści 30 stron. Praktycznie cały pod­ręcz­nik trak­tu­je o meto­dach struk­tu­ral­nych i rela­cyj­nym mode­lu danych. Taka struk­tu­ra naucza­nia inży­nie­rii opro­gra­mo­wa­nia nadal domi­nu­je na uczel­niach, co moim zda­niem tłu­ma­czy nadal powszech­ne, struk­tu­ral­ne podej­ście dewe­lo­pe­rów do two­rze­nia apli­ka­cji (mimo, że uży­wa­ją tak zwa­nych obiek­to­wo-zorien­to­wa­nych języ­ków programowania). 

Dla porów­na­nia nota­cja SysML, jako pro­fil UML, sto­so­wa­na w MBSE (Model-Based System Engineering) oraz pro­ces pro­jek­to­wa­nia w SysML, są zbu­do­wa­ne na nie­mal­że iden­tycz­nych zało­że­niach: wyma­ga­nia, przy­pad­ki uży­cia i mecha­nizm ich reali­za­cji oraz współ­pra­ca kom­po­nen­tów. SysML jako podej­ście do pro­jek­to­wa­nia ogól­nie sys­te­mów mecha­tro­nicz­nych, prak­tycz­nie wyklu­cza two­rze­nie mono­li­tycz­nych sys­te­mów. Głównie dla­te­go, że z zasa­dy są to duże i mul­ti-dzie­dzi­no­we pro­jek­ty (duże pro­jek­ty inży­nie­ryj­ne są interdyscyplinarne).

A gdzie są user story

User Story to wizja potrzeb wyra­żo­na z per­spek­ty­wy użyt­kow­ni­ka. Mam nadzie­ję, że poniż­szy dia­gram odpo­wia­da na to pytanie:

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. Jak już wspo­mnia­no, tak zwa­ny ​„robust­ness dia­gram” nie był nowym, innym dia­gra­mem UML. 

Continuous delivery

Od ok. pięt­na­stu lat mówi się, że ​„żaden sys­tem nie jest ukoń­czo­ny” lecz nie cho­dzi o to że ma błę­dy i sta­le je popra­wia­my (jak cza­sa­mi sły­szę od nie­któ­rych dewe­lo­pe­rów). Chodzi o ite­ra­cyj­ne aktu­ali­zo­wa­nie go o kolej­ne potrzeb­ne nowe lub zak­tu­ali­zo­wa­ne usłu­gi i funk­cjo­nal­no­ści . Proces ten chro­ni tak­że co chro­ni tak­że przed zacią­ga­niem dłu­gu tech­no­lo­gicz­ne­go.

Continuous Delivery (Ciągłe Dostarczanie) jest podej­ściem do inży­nie­rii opro­gra­mo­wa­nia, w któ­rym opro­gra­mo­wa­nie (sys­tem) jest budo­wa­ne jako dostar­cza­ne, w rela­tyw­nie krót­kich cyklach, nowe lub zak­tu­ali­zo­wa­ne kom­po­nen­ty. Aby było to moż­li­we cały sys­tem musi speł­niać pewien zestaw wyma­gań archi­tek­to­nicz­nych, takich jak moż­li­wość nie­za­leż­ne­go wdra­ża­nia kom­po­nen­tów, ich mody­fi­ko­wal­ność i testo­wal­ność (her­me­ty­za­cja). Wymagania archi­tek­to­nicz­ne są tu fun­da­men­tem, któ­re­go nie mozna pominąć.

Jednym z naj­czę­ściej wyko­rzy­sty­wa­nych tu wzor­ców archi­tek­to­nicz­nych są orien­ta­cja na inter­fej­sy oraz mikro­ser­wi­sy i adap­te­ry inte­gra­cyj­ne. Pozwalają na nie­za­leż­ność wdra­ża­nia kom­po­nen­tów, krót­szy czas ich wdra­ża­nia, prost­sze pro­ce­du­ry wdra­ża­nia i wdra­ża­nie bez prze­sto­jów. W efek­cie uzy­sku­je­my: krót­szy czas cyklu dla małych przy­ro­sto­wych zmian funk­cjo­nal­nych, łatwiej­sze zmia­ny w wybo­rze technologii.

Na tle powyż­sze­go ICONIX wraz z Use Case 2.0 oraz podej­ście zorien­to­wa­ne na kom­po­nen­ty wyda­je się wręcz idealnym 

O architekturze i paradygmatach

„A softwa­re system?s archi­tec­tu­re is the set of prin­ci­pal design deci­sions made abo­ut the system.”

BCE: wzorzec projektowy zorientowany na odpowiedzialność klas

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 czę­sto 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 tu budo­wa­na w opar­ciu o wzo­rzec ​„class respon­si­bi­li­ty” . Inne pole­ca­ne tu ana­li­tycz­ne wzor­ce archi­tek­to­nicz­ne to: ł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ę LLD zbu­do­wa­ną z odręb­nych obiek­tów, odpo­wie­dzial­nych odpo­wied­nio za: komu­ni­ka­cję z oto­cze­niem (boun­da­ry), reali­za­cje logi­ki dzie­dzi­no­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). Poniżej ilu­stra­cja z 2002 roku:

Powyższe dzi­siaj nary­so­wa­li byśmy to jak poniżej:

Element «Entity» na powyż­szym dia­gra­mie repre­zen­tu­je obiekt prze­cho­wu­ją­cy dowol­nie zło­żo­ny struk­tu­ral­ny doku­ment jako agre­gat (patrz opi­sa­ny wyżej wzo­rzec enve­lo­pe, wię­cej na ten temat w arty­ku­le: Dokument jako nośnik danych i meto­da zarzą­dza­nia dany­mi). Projektowanie na pozio­mie LLD bar­dzo dobrze opi­su­je Ousterhout .

Architektura heksagonalna

Termin ​„Hexagonal Architecture” (Architektura Heksagonalna) poja­wia się już od daw­na. Na tyle dłu­go, że pod­sta­wo­we źró­dło na ten temat było przez jakiś czas offli­ne i dopie­ro nie­daw­no zosta­ło ura­to­wa­ne z archi­wów . Schematycznie autor przed­sta­wia to tak:

Autor powyż­sze­go pisze: 

Jednym z wiel­kich błę­dów apli­ka­cji przez lata było prze­ni­ka­nie logi­ki biz­ne­so­wej do kodu inter­fej­su użyt­kow­ni­ka. Problem, któ­ry to powo­du­je jest potrójny:

• Po pierw­sze, sys­tem nie może być zgrab­nie prze­te­sto­wa­ny za pomo­cą zauto­ma­ty­zo­wa­nych pakie­tów testo­wych, ponie­waż część logi­ki wyma­ga­ją­cej prze­te­sto­wa­nia zale­ży od czę­sto zmie­nia­ją­cych się szcze­gó­łów wizu­al­nych, takich jak roz­miar pola i roz­miesz­cze­nie przycisków;
• Z tego same­go powo­du nie­moż­li­we sta­je się przej­ście z sys­te­mu ste­ro­wa­ne­go przez czło­wie­ka na sys­tem dzia­ła­ją­cy w try­bie wsadowym;
• Z tego same­go powo­du, trud­ne lub nie­moż­li­we sta­je się umoż­li­wie­nie pro­wa­dze­nia pro­gra­mu przez inny pro­gram, gdy sta­je się to atrakcyjne.

Innymi sło­wy sepa­ru­je­my ​„motor logi­ki biz­ne­so­wej” (PIM) od śro­do­wi­ska (fra­me­work) w jakim apliak­cja powsta­ja i funk­cjo­nu­je. Poniższa pre­zen­ta­cja obra­zu­je to tak:

Dlatego to co opi­sa­no w tym arty­ku­le (model logi­ki dzie­dzi­no­wej apli­ka­cji), z per­spek­ty­wy archi­tek­tu­ry hek­sa­go­nal­nej, nazwie­my Aplikacją (Application core). Z per­spek­ty­wy MDA (patrz OMG​.org/​MDA) jest to wła­śnie Platform Independent Model (PIM) i kom­po­nent Model w MVC.

Architektura C4

Model w archi­tek­tu­rze C4 opi­su­je sta­tycz­ne struk­tu­ry sys­te­mu opro­gra­mo­wa­nia w kate­go­riach kon­te­ne­rów (apli­ka­cje, skła­dy z dany­mi, mikro­ser­wi­sy, itp.), kom­po­nen­tów i kodu. Jest to per­spek­ty­wa sto­su tech­no­lo­gicz­ne­go. Jest to bar­dzo dobry spo­sób na udo­ku­men­to­wa­nie śro­do­wi­ska w jakim wyko­nu­je sie apli­ka­cja (któ­ra tu będzie ​„kloc­kiem na pozio­mie kom­po­nen­tów). Ta archi­tek­tu­ra i taka doku­men­ta­cja jest bar­dzo dobra meto­dą na pro­jek­to­wa­nie i doku­men­to­wa­nie implementacji.

W WIKI moż­na zna­leźć komentarz: 

Code dia­grams (level 4): pro­vi­de addi­tio­nal deta­ils abo­ut the design of the archi­tec­tu­ral ele­ments that can be map­ped to code. The C4 model relies at this level on exi­sting nota­tions such as Unified Modelling Language (UML), Entity Relation Diagrams (ERD) or dia­grams gene­ra­ted by Integrated Development Environments (IDE).

https://​en​.wiki​pe​dia​.org/​w​i​k​i​/​C​4​_​m​o​del

C4 to jed­nak tyl­ko sta­tycz­na struk­tu­ra, autor pomi­ja kwe­stie zacho­wa­nia sie sys­te­mu, dla­te­go C4 może sta­no­wić opis archi­tek­tu­ry dla dewe­lo­pe­ra, ale ani nie wyja­śnia ani nie wery­fi­ku­je dyna­mi­ki systemu. 

Jeśli ​„agile” jest tak dobre, to dlaczego jest tak źle? 

To para­fra­za tytu­łu refe­ra­tu z 2012 roku. Bardzo czę­sto pod nazwą ​„agi­le” ofe­ru­je się for­mę tak zwa­ne­go pro­gra­mo­wa­nia eks­tre­mal­ne­go, czy­li szyb­kie­go kodo­wa­nia tyl­ko na pod­sta­wie ocze­ki­wań przy­szłe­go użyt­kow­ni­ka. Poniżej jeden z ogrom­nej licz­by kry­tycz­nych refe­ra­tów o tak poj­mo­wa­nym agi­le. Projekty, do któ­rych jestem anga­żo­wa­ny, to czę­sto pro­jek­ty trud­ne, roz­po­czy­na­ne po raz dru­gi po nie­uda­nym pierw­szym podej­ściu. Dlatego ich spon­so­rzy teraz dba­ją o podział na role i odpo­wie­dzial­ność każ­dej stro­ny pro­jek­tu. Prelegentka poni­żej zwra­ca na to uwa­gę tak:

never ask your users what they want, never ask your deve­lo­per what they think the users want? [nigdy nie pytaj użyt­kow­ni­ków, cze­go chcą, nigdy nie pytaj dewe­lo­pe­rów, co myślą, że użyt­kow­ni­cy chcą?]

Tak więc zwin­ność owszem, ale agi­le rozu­mia­ne jako pospo­li­te rusze­nie bazu­ją­ce na burzach mózgów na pew­no nie!

Podsumowanie

To, że ICONIX, jako pro­ces, jest sto­sun­ko­wo rzad­ko uży­wa­ny (to się jed­nak zmie­nia od kil­ku lat), 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 poję­cia archi­tek­tu­ry hek­sa­go­nal­nej i powią­za­ne­go z nią wzor­ca MVC. Wymaga pozna­nia i zro­zu­mie­nia wie­lu innych 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 i mode­lo­wa­nia (UML). Wymaga zro­zu­mie­nia tego, że z kodo­wa­nie nale­ży poprze­dzać pro­jek­to­wa­niem, bo ​„pro­jek­to­wa­nie” w kodzie jest naj­mniej efek­tyw­ną for­mą pro­jek­to­wa­nia .

Proces ten wspie­ra tak­że podział na eta­py ana­li­zy i pro­jek­to­wa­nia oraz 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 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ż to, że nie­ste­ty świat został, już w latach 90-tych, moc­no ​„zepsu­ty” przez C++ i Javę (archi­tek­tu­ry budo­wa­ne na kaska­dach dzie­dzi­cze­nia). 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 two­rze­nia apli­ka­cji. 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”. Jednak rosną­ce od kil­ku lat zain­te­re­so­wa­nie dewe­lo­pe­rów mode­lem C4 poka­zu­je, że ana­li­za i mode­lo­wa­nie sa potrzeb­ne i cichut­ko wcho­dzą tyl­ny­mi drzwiami… 

Dodatek: Analiza obiektowa i projektowanie obiektowe czyli co?

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 szko­le­nia i warsz­ta­ty, ofe­ru­je tak­że men­to­ring.

Źródła