Ten często aktualizowany przeze mnie wpis, stał się niemalże kompletnym opisem metodyki projektowania oprogramowania. Zaopatrzyłem go w bogaty spis literatury źródłowej i kilka ciekawych referatów konferencyjnych. Polecam szczególnie moim obecnym i potencjalnym klientom. 

Wprowadzenie

„The Unified Modeling Language User Guide” autor­stwa Grady’ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że ​„możesz wyko­nać 80% mode­lo­wa­nia za pomo­cą 20% UML” gdzieś po stro­nie 400. Zaoszczędziliby bran­ży wie­le milio­nów (miliar­dów?) dola­rów i prze­ra­ża­ją­cych przy­pad­ków para­li­żu ana­li­tycz­ne­go [?], gdy­by powie­dzie­li to we Wstępie, ale tego nie zro­bi­li. Aby spo­tę­go­wać prze­stęp­stwo, nigdy nie mówią nam, któ­re 20% UML jest uży­tecz­ną częścią”.

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 nazwa wła­sna, wie­lu 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 . Dla wygo­dy będę uży­wał jed­nak tej nazwy w dal­szej części. 

Głównym wyróż­ni­kiem 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ż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.

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

Nie jest żaden nowy sys­tem nota­cyj­ny. ICONIX to usys­te­ma­ty­zo­wa­ny pro­ces 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 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:

Kamienie milowe procesu ICONIX

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ń (Analiza Biznesowa). 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 (patrz tak­że: Struktury for­mu­la­rzy jako for­ma wyra­ża­nia wyma­gań).

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 (logi­ka) archi­tek­tu­ry oraz jej 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 popraw­ne. Tu mapu­je­my wszyst­kie wyma­ga­nia na przy­pad­ki uży­cia, uzu­peł­nia­my ewen­tu­al­ne bra­ki. Powstaje archi­tek­tu­ra HLD.

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 sekwen­cji. Powstaje archi­tek­tu­ra LLD. 

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ę, opra­co­wu­je reali­za­cję wyma­gań poza­funk­cjo­nal­nych, powsta­je kod z wyko­rzy­sta­niem ww. opi­sa­nych dia­gra­mów i wybra­nej przez deve­lo­pe­ra tech­no­lo­gii (patrz poni­żej archi­tek­tu­ra hek­sa­go­nal­na i C4). Deweloper reali­zu­je imple­men­ta­cję kolej­nych przy­pad­ków użycia.

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, ​„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 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.
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. 

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 ana­li­za 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ł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. 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 .

Jednak cie­ka­we jest tu to, ż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 to nadal ostat­ni roz­dział o obję­to­ści 30 stron. Praktycznie cały 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 nadal domi­nu­je na uczelniach. 

Jednak kolej­ny opis pro­ce­su, od przy­pad­ku uży­cia przez archi­tek­tu­rę i sce­na­riusz opi­su­ją­cy współ­pra­cę jej ele­men­tów do mode­lu dzie­dzi­ny, nadal jest zgod­ny z fun­da­men­tem jakim jest ocze­ki­wa­ny efekt, archi­tek­tu­ra i zacho­wa­nie systemu: 

Ciekawe jest tak­że to, że SysML jako pro­fil UML sto­so­wa­ny w MBSE (Model-Based System Engineering) jest zbu­do­wa­ny 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 prak­tycz­nie wyklu­cza two­rze­nie mono­li­tycz­nych sys­te­mów, głów­nie 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

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

C4 Model to kolej­ne wcie­le ​„tego same­go pomy­słu”. Model 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, skle­py z dany­mi, mikro­ser­wi­sy, itp.), kom­po­nen­tów i kodu. Uwzględnia rów­nież ludzi, któ­rzy korzy­sta­ją z budo­wa­nych przez nas sys­te­mów oprogramowania.

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

Od sie­bie dodam, że na wyż­szych pozio­mach tak­że moż­na uży­wać UML co bar­dzo popra­wia czy­tel­ność i spój­ność cało­ści. 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