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 Rosenberga ):

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:

ICONIX – struk­tu­ra mode­li (opr. autora)

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:

ICONIX sce­na­riusz two­rze­nia i roz­wo­ju apli­ka­cji (opra­co­wa­nie autora)

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 :

architektura ICONIX
(źr. SYSTEM ANALYSIS AND DESIGN John Wiley & Sons, Inc. http://​www​.wiley​.com/​c​o​l​l​e​g​e​/​d​e​n​nis Fifth Edition ALAN DENNIS Indiana University BARBARA HALEY WIXOM University of Virginia ROBERTA M. ROTH University of Northern Iowa)

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:

Struktura pro­duk­tów pro­jek­tu w pro­ce­sie ICONIX

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

Ikony ste­reo­ty­pów UML: Boundary, Control, Entity

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

Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems ana­ly­sis and design (5th ed). John Wiley.
Mairon, K. (n.d.). THE AGILE MODEL-DRIVEN METHOD. 194.
Mairon, K., Buchheit, M., Knahl, M., & Atkinson, S. (2018). Making MDD Agile : The Agile Model-Driven Method. https://​doi​.org/​1​0​.​5​1​2​1​/​c​s​i​t​.​2​0​1​8​.​8​0​508
Newman, S. (2015). Building micro­se­rvi­ces: desi­gning fine-gra­ined sys­tems (First Edition). O’Reilly Media.
Oliveira Rocha, H. F. (2022). Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices. Apress. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 1‑4842 – 7468‑2
Park, G., Fellir, F., Hong, J.-E., Garrido, J. L., Noguera, M., & Chung, L. (2017). Deriving use cases from busi­ness pro­ces­ses: a goal-orien­ted trans­for­ma­tio­nal appro­ach. Proceedings of the Symposium on Applied Computing – SAC 17, 1288 – 1295. https://​doi​.org/​1​0​.​1​1​4​5​/​3​0​1​9​6​1​2​.​3​0​1​9​789
Rosenberg, D., & Scott, K. (1999). Use case dri­ven object mode­ling with UML. Springer.
Rosenberg, D., & Stephens, M. (2007). Introduction to ICONIX Process. Use Case Driven Object Modeling with UML: Theory and Practice, 1 – 20.
Rosenberg, D., Stephens, M., & Collins-Cope, M. (2005). Agile deve­lop­ment with ICONIX pro­cess: people, pro­cess, and prag­ma­tism. Apress.
Rosenberger, P., Gerhard, D., & Dumss, S. (2019). Modelling the Behaviour of Context-awa­re Systems: State-of-the-Art Analysis and Introduction of a Customized UML Profile. MODELSWARD, 519 – 526.

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Masz pytania to treści artykułu? Kliknij tu i umów się na krótkie konsultacje.

Ten post ma 2 komentarzy

    1. Jarosław Żeliński

      Autorzy roz­ma­wia­ją w sty­lu: agi­le się spraw­dza i to wie­my”, rzecz w tym, że popar­li tej tezy żad­nym fak­tem: skąd to wie­my i co to zna­czy? Jak na razie fak­ty poka­zu­ją co inne­go, klu­czo­wym jest to, że od 2001 roku (Agile Manifesto) sta­ty­sty­ki jako­ści w bran­ży IT nie poszły w górę”. Ta roz­mo­wa ma w 100% życze­nio­wy cha­rak­ter, na pozio­mie Bóg ist­nie­je i nie kwe­stio­nu­je­my tego, poroz­ma­wiaj­my o korzy­ściach z modli­twy”. Argumentowanie, że jakaś meto­da pra­cy jest naj­lep­sza ale (prawie)nigdzie się nie spraw­dza tyl­ko dla­te­go, że ludzie ją źle sto­su­ją” jest dość kurio­zal­ne. To, że Agile i Scrum to rak toczą­cy IT” sły­chać na świe­cie coraz czę­ściej od dobrych 10 lat (pole­cam refe­ra­ty kon­fe­ren­cyj­ne dostęp­ne na YT, w tym cyto­wa­ny Skoro Agile jest taki dobry to dla­cze­go nasze pro­duk­ty są tak złe?”)… Pan Białko pro­wa­dzi szko­le­nia na temat Agile, w agen­dzie uży­wa mię­dzy inny­mi poję­cia zwin­ne wyma­ga­nia” jed­nak nie podał ich defi­ni­cji (mate­ria­ły nie są publicz­ne). Ale popa­trz­my tu, mate­riał o zwin­no­ści jak wie­le, poję­cie wyma­ga­nia” zosta­ło uży­te 13 razy („wyma­ga­nia zwin­ne” raz), i nie wia­do­mo o czym jest ten tekst bo autor nie podał defi­ni­cji tych pojęć: https://​oditk​.pl/​p​l​/​w​i​e​d​z​a​/​a​r​t​y​k​u​l​/​z​o​b​a​c​z​/​w​y​m​a​g​a​n​i​a​-​w​-​p​r​o​j​e​k​t​a​c​h​-​z​w​i​n​n​y​c​h​-​d​z​i​a​l​a​s​z​-​a​g​i​l​e​-​c​z​y​-​t​y​l​k​o​-​o​-​t​y​m​-​m​o​w​i​sz/

Dodaj komentarz

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