Wprowadzenie
O podobnej porze roku, w 2015 roku pisałem:
W ICONIX można z powodzeniem stosować„czysty” UML
źr.: : ICONIX and Use Case Driven Object Modeling with UML – Jarosław Żeliński IT-Consulting
ICONIX to w zasadzie fundament obiektowego, zorientowanego na przypadki użycia, projektowanie oprogramowania . Jest to od samego początku swojego istnienia, metoda klasyfikowana jako zwinna . Orientacja na Przypadki Użycia (use case driven) to obecnie kanon projektowania . Coraz popularniejszy wzorzec jakim są mikroserwisy staje się „normą” w projektowaniu architektury .
Od samego początku ICONIX jest promowany jako „Zwinność bez skrajności”. Polecam też stronę ICONIX Proces (This website is a collaboration between 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 podstawie źródeł, podaje anglojęzyczna WIKI (wpis oparty na publikacjach Rosenberg’a ):
Podobnie jak RUP, proces ICONIX jest oparty na przypadkach użycia UML, ale jest bardziej lekki niż RUP. ICONIX dostarcza więcej dokumentacji wymagań i projektu niż XP i ma na celu uniknięcie paraliżu analitycznego. Proces ICONIX wykorzystuje tylko cztery diagramy oparte na UML w czterostopniowym procesie, który prowadzi od przypadków użycia do działającego kodu.
Głównym wyróżnikiem ICONIX jest wypełnienie luki pomiędzy analizą a implementacją. Lukę tę wypełniamy od razu modelując mechanizm realizacji przypadków użycia. Proces ten sprawia, że przypadki użycia są znacznie szybciej projektowane, testowane i implementowane.
Zasadniczo Proces ICONIX opisuje podstawowy, „logiczny” proces analizy i modelowania zorientowanego na projektowanie.
na podstawie: https://en.wikipedia.org/wiki/ICONIX
Wyżej wymieniona literatura tak prezentuje pierwotną wersję tego procesu:

W oryginale (diagram powyżej) proces wygląda następująco:
Kamień milowy 1: Przegląd wymagań
Przed rozpoczęciem procesu ICONIX musi być przeprowadzona analiza wymagań. Na podstawie tej analizy można zidentyfikować przypadki użycia, stworzyć pojęciowy model dziedziny i wykonać kilka prototypów GUI (formularze).
Kamień milowy 2: Wstępny przegląd projektu
Po zidentyfikowaniu przypadków użycia można opracować ogólne scenariusze tego jak użytkownik i system będą ze sobą współdziałać. Przeprowadzana jest analiza i projektowanie bazowej architektury oraz jej logiki działania (robustness analysis), aby znaleźć potencjalne błędy w scenariuszach przypadków użycia, a pojęciowy model dziedziny jest odpowiednio aktualizowany. Opisy przypadków użycia są ważne dla określenia, jak użytkownicy będą wchodzić w interakcje z projektowanym systemem. Zapewniają one również opis, który można pokazać Klientowi i zweryfikować, czy wyniki analizy wymagań były poprawne.
Kamień milowy 3: Szczegółowy Przegląd Projektu
Podczas tego etapu procesu ICONIX pojęciowy model dziedziny i scenariusze przypadków użycia są wykorzystywane do zaprojektowania architektury budowanego systemu (realizacja logiki biznesowej). Tworzony jest model architektury, a opisy i scenariusze przypadków użycia wykorzystywane są do tworzenia diagramów sekwencji.
Kamień milowy 4: Wdrożenie
Testy jednostkowe są pisane w celu sprawdzenia, czy system będzie zgodny z opisem przypadków użycia i diagramami sekwencji. Developer wybiera technologię, powstaje kod z wykorzystaniem ww. opisanych diagramów i wybranej przez developera technologii.
Kamienie milowe 3 i 4 są realizowane iteracyjnie dla każdego przypadku użycia.
ICONIX dzisiaj
Mamy rok 2022, nie ma żadnej rewolucji, nie ma obowiązku stosowania „robustness diagram” (jego role pełnią diagramy architektury: komponentów, klas), jest mniej prozy na rzecz diagramów UML:
Poprzedzamy wszystko analizą biznesową: opracowujemy modele procesów biznesowych. Z ich pomocą zbieramy wymagania, jako potrzeby Zamawiającego. Stają się one kanwą projektowanego systemu. Analiza Biznesowa stanowi wsad dla Kamienia milowego 1.
Opisane wcześniej „kamienie milowe” to odpowiednio etapy:
- Na podstawie analizy procesów biznesowych, mając modele pojęciowe i reguły biznesowe oraz potrzeby, opracowujemy listę przypadków użycia i wstępne szablony (makiety) formularzy.
- Mając przypadki użycia i makiety formularzy, projektujemy scenariusze opisujące interakcje aktor-system. Omawiamy je z Zamawiającym.
- Kolejny etap to projektowanie architektury LLD kolejnych przypadków użycia oraz testujące je diagramy sekwencji. Na bieżąco jest aktualizowana architektura wewnętrznej integracji HLD (nie ma tu potrzeby tworzenia nietypowego „robustness diagram”).
- Od tego momentu, iteracyjnie przyrostowo, kolejno zaprojektowane i przetestowane na diagramach sekwencji, przypadki użycia są przekazywane do developmentu, a w tym czasie powstają projekty LLD kolejnych.
Punkty 3. i 4. są realizowane w pętli aż do oddania do użytku całego systemu. Jeżeli jest taka potrzeba, można opracować wstępnie wszystkie przypadki użycia do wyceny, a potem dopracowywać je w toku dalszej pracy.
Jeżeli informacje (formularze) cechują się stanowością lub, jako dokumenty mają statusy, to tworzymy dodatkowo diagramy maszyny stanowej dla tych dokumentów. Wszędzie tam, gdzie logikę (mechanizm) działania należy udokumentować algorytmemem lub scenariuszem opisującym współdziałania komponentów na wyższym poziomie abstrakcji, stosujemy diagramy aktywności.
Scenariusz iteracyjnego wytwarzania w procesie ICONIX:
Idea procesu analizy i projektowania zorientowanego na przypadki użycia i ich realizacje jest aktualna i kultywowana, nie zawsze pod nazwą ICONIX :

Powyższa struktura projektu obiektowo-zorientowanego (albo jak kto woli na komponenty i interfejsy) jest nadal aktualnym elementem wielu podręczników z zakresu inżynierii oprogramowania oraz opracowań i metod takich jak Use Case 2.0 .
Struktura procesu wytwarzania oprogramowania
Całość tego procesu projektowania od ogółu do szczegółu można zobrazować tak:

Sam proces ICONIX nie jest niczym specjalnym ani wyjątkowym, w sensie notacyjnym. Tak zwany „robustness diagram” nie był nowym, innym diagramem UML, to był diagram komunikacji (communication diagram UML). Jedyną jego „wadą” było tu jego przedwczesne użycie w procesie: był używany na początku pracy jako biznesowy model procesu przepływu danych. „Robustness diagram” stosowany był analogicznie do diagramów DFD w metodach strukturalnych.
Wzorzec BCE

ICONIX to bardzo skuteczna, zwinna metoda projektowania oprogramowania zorientowana na modele (ang. MDD, Model Driven Development). Mimo stosowania UML, jest lekka, bo korzystamy z kilku podstawowych typów diagramów UML i ich prostych form. ICONIX jest kojarzony głównie z ikonami stereotypów BCE (Boundary, Control, Entity). Stereotypy te w postaci graficznej są dostępne w wielu narzędziach CASE, w tym EA SPARX i Visual-Paradigm. Architektura LLD przypadków użycia, jest obecnie budowana w oparciu o ten wzorzec oraz dobrze już poznane inne podstawowe wzorce projektowe. Należą do nich: łańcuch odpowiedzialności, saga, mikroserwisy, repozytorium, koperta (envelope, DTO). BCE to wzorzec zakładający, że komponent realizujący przypadek użycia, będzie architekturę zbudowaną z odrębnych komponentów, odpowiedzialnych za: komunikacje z otoczeniem (boudary), realizacje logiki dziediznowej (control) i przechowywanie danych (entity), dane przechowujemy jako całe komunikaty (envelope).
Podsumowanie
To, że ICONIX jest stosunkowo rzadko używany, szczególnie pod tą nazwą, ma swoje podłoże w tym, że przede wszystkim wymaga zrozumienia procesu tworzenia komponentowo-zorientowanej architektury, wymaga też znajomości i zrozumienia UML, wymaga poznania i zrozumienia obiektowych wzorców projektowych, wymaga przede wszystkim umiejętności abstrakcyjnego myślenia. Wszystko to jednak jest rekompensowane bardzo szybkim tworzeniem wysokiej jakości oprogramowania.
Proces ten wspiera także rozdział projektowania i implementacji (patrz powyższy schemat: Struktura ról i produktów projektu w procesie ICONIX). ICONIX bywa też niesłusznie kojarzony z „ciężkim” procesem wytwarzania oprogramowania, jakim jest Rational Unified Process (o którym praktycznie nie pisałem na swoim blogu).
Powodem rzadkiego stosowania ICONIX, jest te z to, że niestety świat został, już w latach 90-tych, mocno „zepsuty” przez C++ i Javę. Są to często ciężkie, monolityczne frameworki oparte na relacyjnym modelu danych, gdzie nie ma ścisłego podziału na logikę dziedzinową i środowisko (MVC). Java to nadal jedna z najkosztowniejszych i najmniej efektywnych metod pracy. Framework EJB do dziś jest opisywany jako źródło obiektowego antywzorca projektowego o nazwie „anemiczny model dziedziny”.
Analiza obiektowa i projektowanie
Od dawna toczą sie dyskusje na temat tego czym jest OOP i OOAD. Definiowanie paradygmatu obiektowego jako dziedziczenia i łączenia danych i funkcji w obiekty zostały zdyskredytowane już pod koniec lat 90-tych przez samego „autora pomysłu” (Alan Kay), który podkreśla, że istotą obiektowości jest podział na samodzielne komponenty (obiekty) oraz ich wzajemna komunikacja (w tym polimorfizm).
ICONIX jest jedną z pierwszych obiektowych, zwinnych metod analizy i projektowania: całe oprogramowanie składa się z komunikujących się obiektów (komponenty i diagramy sekwencji). Do modelowania wykorzystywany jest minimalny zestaw diagramów UML w ich minimalnej postaci. Dalej już oddam głos deweloperom:
Zainteresowanych zapraszam na warsztaty.
https://www.youtube.com/watch?v=AOmidC_K20c polecam objrzeć – nie oceniam tylko wydaje mi się ciekawy głos w dyskusji
Autorzy rozmawiają w stylu: „agile się sprawdza i to wiemy”, rzecz w tym, że poparli tej tezy żadnym faktem: skąd to wiemy i co to znaczy? Jak na razie fakty pokazują co innego, kluczowym jest to, że od 2001 roku (Agile Manifesto) statystyki jakości w branży IT nie „poszły w górę”. Ta rozmowa ma w 100% życzeniowy charakter, na poziomie „Bóg istnieje i nie kwestionujemy tego, porozmawiajmy o korzyściach z modlitwy”. Argumentowanie, że jakaś metoda pracy jest najlepsza ale (prawie)nigdzie się nie sprawdza tylko dlatego, że „ludzie ją źle stosują” jest dość kuriozalne. To, że „Agile i Scrum to rak toczący IT” słychać na świecie coraz częściej od dobrych 10 lat (polecam referaty konferencyjne dostępne na YT, w tym cytowany „Skoro Agile jest taki dobry to dlaczego nasze produkty są tak złe?”)… Pan Białko prowadzi szkolenia na temat Agile, w agendzie używa między innymi pojęcia „zwinne wymagania” jednak nie podał ich definicji (materiały nie są publiczne). Ale popatrzmy tu, materiał o zwinności jak wiele, pojęcie „wymagania” zostało użyte 13 razy („wymagania zwinne” raz), i nie wiadomo o czym jest ten tekst bo autor nie podał definicji tych pojęć: https://oditk.pl/pl/wiedza/artykul/zobacz/wymagania-w-projektach-zwinnych-dzialasz-agile-czy-tylko-o-tym-mowisz/