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 studentom oraz obecnym i potencjalnym klientom, bo to opis produktu jaki ode mnie dostaną (polecam także wpis: Moja rola w projektach). 

Programming is not solely about constructing software—programming is about designing software.

[Programowanie nie polega wyłącznie na tworzeniu oprogramowania – programowanie polega na projektowaniu oprogramowania.]

[zotpressInText item=”{5085975:NZCQDD79}”]

Wprowadzenie

Opisany tu proces modelowania stara sie odpowiedzieć na powyższe pytania.

Często spotykana nazwa: ICONIX, przylgnęła do metod zorientowanych na przypadki użycia za sprawą publikacji Use Case Driven Object Modeling with UML [zotpressInText item=”{5085975:7NUD7FFT}”]. Nie jest to jednak ani patent ani jedyna metoda z użyciem UML. Wielu innych autorów opisuje to standardowe podejście po prostu jako “metody komponentowe projektowania zorientowane na przypadki użycia” [zotpressInText item=”{5085975:IENSXKK5},{5085975:GMJDZZJ4}”] oraz [zotpressInText item=”{5085975:6GN76ZK6}”]. Będę używał nazwy ICONIX w dalszej części tylko dla wygody.

Głównym wyróżnikiem procesów takich jak ICONIX jest wypełnienie luki pomiędzy analizą potrzeb a implementacją. Lukę tę wypełniamy od razu modelując mechanizm realizacji przypadków użycia.

O podobnej 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

“The Unified Modeling Language User Guide” autorstwa Grady’ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że “możesz wykonać 80% modelowania za pomocą 20% UML” gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią”.

[zotpressInText item=”{5085975:KID8ZABH}”]

ICONIX to w zasadzie standard komponentowego, zorientowanego obiektowo, na przypadki użycia i interfejsy komponentów, procesu projektowania oprogramowania [zotpressInText item=”{5085975:KID8ZABH},{5085975:7NUD7FFT},{5085975:NARCC3BJ},{5085975:P7WIX63W}”]. Jest to od samego początku swojego istnienia, metoda klasyfikowana jako zwinna [zotpressInText item=”{5085975:BVNB2XAR},{5085975:AK85VTS2}”]. Orientacja na Przypadki Użycia (use case driven) to obecnie kanon projektowania [zotpressInText item=”{5085975:XSXM2FP8},{5085975:CBDVJZQB},{5085975:CG4K6N4J}”]. Coraz popularniejszy wzorzec jakim są mikroserwisy staje się “normą” w projektowaniu architektury [zotpressInText item=”{5085975:ECD9XUND},{5085975:LBWZRGBD},{5085975:ADM6A5A3}”].

Bardzo istotne jest tu także zrozumienie różnicy między inżynierem oprogramowania (systemu) a deweloperem (koderem): zainteresowanym najpierw polecam lekturę artykułu: Software Engineer Vs. Programmer: What?s the Difference? To co robi inżynier bywa nazywane “Diagrams as Code” bo:

Programming is not solely about constructing software?programming is about designing software.

[zotpressInText item=”{5085975:NZCQDD79}”]

UWAGA! Identyczny efekt (diagramy) da projekt udokumentowania istniejącej aplikacji! Taka “rewers-inżynieria” wymaga jedynie ścisłej współpracy zespołu, który napisał/zna kod.

ICONIX

Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm.(Craver & Tabery, 2019)

Nie jest żaden nowy czy inny system notacyjny. ICONIX to, użyta pierwszy raz w latach 90-tych, nazwa usystematyzowanego procesu analizy i projektowania obiektowego z użyciem “czystej” notacji UML. Od samego początku ICONIX jest promowany jako “Zwinność bez skrajności“. Ten, opisany tu, proces analizy i projektowania jest szeroko opisywany w podręcznikach także bez nazwy własnej ICONIX [zotpressInText item=”{5085975:GMJDZZJ4}”].

Na stronie autorów 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.

https://iconixprocess.wordpress.com/about/

Zwięzły opis, na podstawie źródeł, podaje także anglojęzyczna WIKI (wpis oparty na publikacjach Rosenberg‘a [zotpressInText item=”{5085975:KID8ZABH},{5085975:P7WIX63W}”]):

Podobnie jak RUP, proces ICONIX jest oparty na przypadkach użycia UML, ale jest bardziej lekki niż RUP. ICONIX dostarcza więcej dokumentacji 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:

ICONIX dzisiaj

Mamy rok 2022, nie ma żadnej rewolucji, “robustness diagram” to diagram komunikacji (lub 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.

Biorąc pod uwagę aktualny stan notacji na OMG.org “kamienie milowe” procesu to odpowiednio etapy i ich produkty:

1. Mając wynik analizy biznesowej w postaci map procesów biznesowych, modeli pojęciowych i listy reguł biznesowych oraz potrzeby biznesowe (cele projektu), opracowujemy listę przypadków użycia (UC) oraz wstępne szablony (makiety) formularzy na bazie dokumentów opisanych w procesach biznesowych.
2. Mając przypadki użycia i makiety formularzy, projektujemy scenariusze opisujące planowane/wymagane interakcje aktor-system. Omawiamy je z Zamawiającym. Na tym etapie można dodatkowo udokumentować algorytmy (metody) przetwarzania/walidacji treści formularzy (szczególnie, gdy początkowo zakładamy zakup standardowego oprogramowania spełniającego tak opisane wymagania). Jeżeli nie, projektowane jest oprogramowanie dedykowane.
3. Kolejny etap to zaprojektowanie architektury HLD aplikacji, czyli układu komponentów realizujących poszczególne UC oraz diagramy sekwencji opisujące współdziałanie tych komponentów w toku realizacji scenariuszy UC.
4. Od tego momentu, iteracyjnie-przyrostowo, projektowane są realizacje UC jako ich architektury LLD i diagramy sekwencji opisujące ich wewnętrzne działanie, tak opisane realizacje przekazywane są kolejno do implementacji.

Kluczowy jest pkt.1. gdyż to formularze (dokumenty) są kluczowym nośnikiem informacji czyli danych i ich kontekstu. Ten etap to korzystanie z wyników analizy biznesowej: identyfikacja dokumentów oraz ich formalizacja i standaryzacja:

Kluczowe reguły: (1) dokument jest klasyfikowany albo jako opis obiektu albo faktu, (2) opis faktu nie może być modyfikowany a obiektu tak (aktualizacja stanu faktycznego), (3) modyfikacja opisu obiektu jest faktem (który można dokumentować), (4) opis faktu musi dotyczyć co najmniej jednego obiektu.

źr.: Dokument jako nośnik danych i metoda zarządzania danymi ? agregat doskonały

Punkt 2. to projektowanie realizacji wymagań biznesowych i modelowanie systemu jako “czarnej skrzynki”, to umowa (zakres produktu) z zamawiającym.

Punkty 3. i 4. są realizowane w pętli aż do oddania do użytku całej aplikacji.

Diagramy UML

Całość dokumentowana jest z użyciem notacji UML.

Pierwszy diagram jaki powstaje to Diagram Przypadków Użycia. Jest to jeden diagram definiujący kontekst i zakres projektu oraz jego otoczenie: użytkowników i zewnętrzne, integrowane aplikacje.

Dla każdego przypadku użycia (UC) projektujemy bazowy formularz, na bazie odpowiadającego mu dokumentu z modelu procesów biznesowych. Najlepiej użyć do tego Diagramu Struktur Złożonych (jest to zorientowany na dokumenty model danych). Każdy UC należy opisać dialogiem aktor-system opisującym “co system ma robić”.

Jeżeli dane (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ć algorytmem lub scenariuszem opisującym współdziałania komponentów na wyższym poziomie abstrakcji, stosujemy Diagramy Aktywności.

Kolejny diagram to Diagram Komponentów, na którym opisujemy wewnętrzną, komponentową architekturą aplikacji (tu korzystamy głownie z wzorców: Mikro-serwisy i Saga) oraz adaptery integracyjne dla zewnętrznych aplikacji (patrz Diagram Przypadków Użycia jako kontekst).

Ostatecznie dla każdego komponentu (mikro-serwis) tworzymy jego architekturę LLD z użyciem Diagramu Klas i także Diagramu Sekwencji.

Diagram Przypadków Użycia to deklaracja zakresu systemu dla przyszłego użytkownika: “czarna skrzynka”. Diagramy komponentów i klas to statyczna architektura systemu, diagramy aktywności i sekwencji opisują jego zachowanie. Ten model nazywamy to “białą skrzynką”.

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. Dostępna jako Use CAse 2.0 [zotpressInText item=”{5085975:IENSXKK5},{5085975:XSXM2FP8}”] lub w wersji akademickiej bez własnej nazwy jako proces projektowania [zotpressInText item=”{5085975:GMJDZZJ4}”]:

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 [zotpressInText item=”{5085975:IENSXKK5},{5085975:XSXM2FP8}”].

Ciekawostką jest, że powyższy podręcznik ma 594 strony, nadal jest w użyciu na wielu uczelniach, a metody obiektowe zorientowane na przypadki użycia to nadal tylko jeden ostatni rozdział o objętości 30 stron. Praktycznie cały podręcznik traktuje o metodach strukturalnych i relacyjnym modelu danych. Taka struktura nauczania inżynierii oprogramowania nadal dominuje na uczelniach, co moim zdaniem tłumaczy nadal powszechne, strukturalne podejście deweloperów do tworzenia aplikacji (mimo, że używają tak zwanych obiektowo-zorientowanych języków programowania).

Inny przykład tej samej idei poniżej:

Dla porównania notacja SysML, jako profil UML, stosowana w MBSE (Model-Based System Engineering) oraz proces projektowania w SysML, są zbudowane na niemalże identycznych założeniach: wymagania, przypadki użycia i mechanizm ich realizacji oraz współpraca komponentów. SysML jako podejście do projektowania ogólnie systemów mechatronicznych, praktycznie wyklucza tworzenie monolitycznych systemów. Głównie dlatego, że z zasady są to duże i multi-dziedzinowe projekty (duże projekty inżynieryjne są interdyscyplinarne).

A gdzie są user story

User Story to wizja potrzeb wyrażona z perspektywy użytkownika. Mam nadzieję, że poniższy diagram odpowiada na to pytanie:

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. Jak już wspomniano, tak zwany “robustness diagram” nie był nowym, innym diagramem UML.

Continuous delivery

Od ok. piętnastu lat mówi się, że “żaden system nie jest ukończony” lecz nie chodzi o to że ma błędy i stale je poprawiamy (jak czasami słyszę od niektórych deweloperów). Chodzi o iteracyjne aktualizowanie go o kolejne potrzebne nowe lub zaktualizowane usługi i funkcjonalności [zotpressInText item=”{5085975:C98LIU6F},{5085975:KSPQPHW7}”]. Proces ten chroni także co chroni także przed zaciąganiem długu technologicznego.

Continuous Delivery (Ciągłe Dostarczanie) jest podejściem do inżynierii oprogramowania, w którym oprogramowanie (system) jest budowane jako dostarczane, w relatywnie krótkich cyklach, nowe lub zaktualizowane komponenty. Aby było to możliwe cały system musi spełniać pewien zestaw wymagań architektonicznych, takich jak możliwość niezależnego wdrażania komponentów, ich modyfikowalność i testowalność (hermetyzacja). Wymagania architektoniczne są tu fundamentem, którego nie mozna pominąć.

Jednym z najczęściej wykorzystywanych tu wzorców architektonicznych są orientacja na interfejsy oraz mikroserwisy i adaptery integracyjne. Pozwalają na niezależność wdrażania komponentów, krótszy czas ich wdrażania, prostsze procedury wdrażania i wdrażanie bez przestojów. W efekcie uzyskujemy: krótszy czas cyklu dla małych przyrostowych zmian funkcjonalnych, łatwiejsze zmiany w wyborze technologii.

Na tle powyższego ICONIX wraz z Use Case 2.0 [zotpressInText item=”{5085975:IENSXKK5}”] oraz podejście zorientowane na komponenty [zotpressInText item=”{5085975:NI8AM7JP},{5085975:ZXMTN7WR},{5085975:ZT6SQRP6}”] wydaje się wręcz idealnym

O architekturze i paradygmatach

“A software system?s architecture is the set of principal design decisions made about the system.”

[zotpressInText item=”{5085975:WRM97AIW}”]

BCE: wzorzec projektowy zorientowany na odpowiedzialność klas

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 często 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 tu budowana w oparciu o wzorzec “class responsibility” [zotpressInText item=”{5085975:CDZ44929},{5085975:VNQDV6CQ}”]. Inne polecane tu analityczne wzorce architektoniczne to: ł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ę LLD zbudowaną z odrębnych obiektów, odpowiedzialnych odpowiednio za: komunikację z otoczeniem (boundary), realizacje logiki dziedzinowej (control) i przechowywanie danych (entity), dane przechowujemy jako całe komunikaty (envelope). Poniżej ilustracja z 2002 roku:

Powyższe dzisiaj narysowali byśmy to jak poniżej:

Element ‘Entity’ na powyższym diagramie reprezentuje obiekt przechowujący dowolnie złożony strukturalny dokument jako agregat (patrz opisany wyżej wzorzec envelope, więcej na ten temat w artykule: Dokument jako nośnik danych i metoda zarządzania danymi). Projektowanie na poziomie LLD bardzo dobrze opisuje Ousterhout [zotpressInText item=”{5085975:IWBHW8XL}”].

Architektura heksagonalna

Termin “Hexagonal Architecture” (Architektura Heksagonalna) pojawia się już od dawna. Na tyle długo, że podstawowe źródło na ten temat było przez jakiś czas offline i dopiero niedawno zostało uratowane z archiwów [zotpressInText item=”{5085975:IQ3YKX86}”]. Schematycznie autor przedstawia to tak:

Autor powyższego pisze:

Jednym z wielkich błędów aplikacji przez lata było przenikanie logiki biznesowej do kodu interfejsu użytkownika. Problem, który to powoduje jest potrójny:

• Po pierwsze, system nie może być zgrabnie przetestowany za pomocą zautomatyzowanych pakietów testowych, ponieważ część logiki wymagającej przetestowania zależy od często zmieniających się szczegółów wizualnych, takich jak rozmiar pola i rozmieszczenie przycisków;
• Z tego samego powodu niemożliwe staje się przejście z systemu sterowanego przez człowieka na system działający w trybie wsadowym;
• Z tego samego powodu, trudne lub niemożliwe staje się umożliwienie prowadzenia programu przez inny program, gdy staje się to atrakcyjne.

Innymi słowy separujemy “motor logiki biznesowej” (PIM) od środowiska (framework) w jakim apliakcja powstaja i funkcjonuje. Poniższa prezentacja obrazuje to tak:

Dlatego to co opisano w tym artykule (model logiki dziedzinowej aplikacji), z perspektywy architektury heksagonalnej, nazwiemy Aplikacją (Application core). Z perspektywy MDA (patrz OMG.org/MDA) jest to właśnie Platform Independent Model (PIM) i komponent Model w MVC.

Architektura C4

Model w architekturze C4 opisuje statyczne struktury systemu oprogramowania w kategoriach kontenerów (aplikacje, składy z danymi, mikroserwisy, itp.), komponentów i kodu. Jest to perspektywa stosu technologicznego. Jest to bardzo dobry sposób na udokumentowanie środowiska w jakim wykonuje sie aplikacja (która tu będzie “klockiem na poziomie komponentów). Ta architektura i taka dokumentacja jest bardzo dobra metodą na projektowanie i dokumentowanie implementacji.

W WIKI można znaleźć komentarz:

Code diagrams (level 4): provide additional details about the design of the architectural elements that can be mapped to code. The C4 model relies at this level on existing notations such as Unified Modelling Language (UML), Entity Relation Diagrams (ERD) or diagrams generated by Integrated Development Environments (IDE).

https://en.wikipedia.org/wiki/C4_model

C4 to jednak tylko statyczna struktura, autor pomija kwestie zachowania sie systemu, dlatego C4 może stanowić opis architektury dla dewelopera, ale ani nie wyjaśnia ani nie weryfikuje dynamiki systemu.

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

To parafraza tytułu referatu z 2012 roku. Bardzo często pod nazwą “agile” oferuje się formę tak zwanego programowania ekstremalnego, czyli szybkiego kodowania tylko na podstawie oczekiwań przyszłego użytkownika. Poniżej jeden z ogromnej liczby krytycznych referatów o tak pojmowanym agile. Projekty, do których jestem angażowany, to często projekty trudne, rozpoczynane po raz drugi po nieudanym pierwszym podejściu. Dlatego ich sponsorzy teraz dbają o podział na role i odpowiedzialność każdej strony projektu. Prelegentka poniżej zwraca na to uwagę tak:

never ask your users what they want, never ask your developer what they think the users want? [nigdy nie pytaj użytkowników, czego chcą, nigdy nie pytaj deweloperów, co myślą, że użytkownicy chcą?]

Tak więc zwinność owszem, ale agile rozumiane jako pospolite ruszenie bazujące na burzach mózgów na pewno nie!

Podsumowanie

To, że ICONIX, jako proces, jest stosunkowo rzadko używany (to się jednak zmienia od kilku lat), ma swoje podłoże w tym, że przede wszystkim wymaga zrozumienia procesu tworzenia komponentowo-zorientowanej architektury, wymaga też znajomości i zrozumienia pojęcia architektury heksagonalnej i powiązanego z nią wzorca MVC. Wymaga poznania i zrozumienia wielu innych obiektowych wzorców projektowych, wymaga przede wszystkim umiejętności abstrakcyjnego myślenia i modelowania (UML). Wymaga zrozumienia tego, że z kodowanie należy poprzedzać projektowaniem, bo “projektowanie” w kodzie jest najmniej efektywną formą projektowania [zotpressInText item=”{5085975:4XDEIZGV}”].

Proces ten wspiera także podział na etapy analizy i projektowania oraz implementacji (patrz powyższy schemat: Struktura ról i produktów projektu w procesie ICONIX). ICONIX bywa 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ż to, że niestety świat został, już w latach 90-tych, mocno “zepsuty” przez C++ i Javę (architektury budowane na kaskadach dziedziczenia). 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 tworzenia aplikacji. Framework EJB do dziś jest opisywany jako źródło obiektowego antywzorca projektowego o nazwie “anemiczny model dziedziny“. Jednak rosnące od kilku lat zainteresowanie deweloperów modelem C4 pokazuje, że analiza i modelowanie są potrzebne i cichutko wchodzą tylnymi drzwiami…

Osobom zainteresowanym architekturą kodu polecam artykuł: Projektowanie czyli architektura kodu aplikacji c.d..

Dodatek: Analiza obiektowa i projektowanie obiektowe czyli co?

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 szkolenia i warsztaty, oferuje także mentoring.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Miło mi poinformować, że moja publikacja naukowa (tu była zapowiedź) na temat syntezy wzorców architektonicznych i wzorców projektowych, systemów obiektowo-zorientowanych zatytułowana:

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

po długim procesie selekcji i recenzowania, została zakwalifikowana do publikacji i właśnie się ukazała jako jeden z rozdziałów książki:

Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities.

Jeszcze milej mi poinformować, że – jako współautor – mogę Wam zaoferować kod promocyjny dający 40% zniżki na zakup: IGI40.

Poniżej informacje o książce i o wydawcy.

O książce

DescriptionIn today?s modernized environment, a growing number of software companies are changing their traditional engineering approaches in response to the rapid development of computing technologies. As these businesses adopt modern software engineering practices, they face various challenges including the integration of current methodologies and contemporary design models and the refactoring of existing systems using advanced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivotal reference source that provides vital research on the development of modern software practices that impact maintenance, design, and developer productivity. While highlighting topics such as augmented reality, distributed computing, and big data processing, this publication explores the current infrastructure of software systems as well as future advancements. This book is ideally designed for software engineers, IT specialists, data scientists, business professionals, developers, researchers, students, and academicians seeking current research on contemporary software engineering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global

O wydawcy

IGI Global is a leading international academic publisher committed to facilitating the discovery of pioneering research that enhances and expands the body of knowledge available to the research community. Working in close collaboration with expert researchers and professionals from leading institutions, including Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global disseminates quality content across 350+ topics in 11 core subject areas. Source: About IGI Global | IGI Global

Streszczenie: W pracy przedstawiono metodę projektowania architektury oprogramowania od ogółu do szczegółu z pomocą metamodeli definiowanych jako profili UML. Pokazano zaletę jaką jest możliwość szybkiego rozpoczęcia prac projektowych i testowania efektów mimo braku detalicznej wiedzy o danych. Metoda zakłada, że dane są zorganizowane z nazwane dokumenty o określonej strukturze. W trakcie prac analitycznych i projektowych wystarczającą wiedzą jest to jakie dokumenty są (będą) przetwarzane, zrozumienie ich celu i opis zawartości. Detaliczne szablony dokumentów (pola i ich zawartość) mogą pozostawać nieznane prawie do końca analizy i projektowania, wymagane są dopiero na etapie implementacji.

1. Wstęp

Wśród architektonicznych wzorców projektowych dominują wzorce opisujące elementy techniczne oprogramowania (Larman 2004) oraz wzorce opisujące ogólnie tworzenie dziedzinowych komponentów, tu najbardziej znany to wzorzec DDD (Evans 2003). Znane jest także podejście oparte na metodzie określanej jako “projektowanie zorientowane na odpowiedzialność klas” (Wirfs-Brock 2003).

Wzorzec DDD to wzorzec uniwersalny (dziedzina nie ma tu znaczenia), oparty na technicznych odpowiedzialnościach komponentów. Wirfs-Brock zaś opisuje podejście do projektowania architektury ale nie wskazuje konkretnych wzorców ani metamodeli, skupia sie na metodzie analizy i projektowania.

Artykuł ten to propozycja poszerzenia powyższych metod o podejście uwzględniające dziedzinę problemu oraz aktualne trendy w projektowaniu architektury dużych systemów (jednym z ciekawszych jest automatyzacja (Sobczak 2019). Celem jest dodanie warstwy abstrakcyjnej na jak najwcześniejszym etapie projektowania, by odsunąć w czasie prace ze szczegółami takimi jak atrybuty i wewnętrzne (prywatne) operacje komponentów. Innymi słowy celem jest poprzedzanie projektowania architektury oprogramowania studiami związanymi z dziedziną problemu, w celu opracowania profilu dla wybranej technologii lub projektu oraz słownictwa dla nazw elementów modeli, opisującego jednoznacznie role nazywanych komponentów.

Jest to idea znana z innych dziedzin np. zawodnicy drużyny piłki nożnej mają określone role, są klasyfikowani jako np. zawodnik obrony lub ataku, co informuje nas dość precyzyjnie o możliwych zachowaniach danego zawodnika a nie wymaga mimo to znajomości detali jego umiejętności (operacji), możemy długo nie wiedzieć kto konkretnie będzie grał na tej pozycji.

Do sporządzania schematów blokowych wykorzystano notację UML oraz SBVR (źr. omg.org).

2. Co zbadano?

Przedmiotem badań były projekty analityczne dokumentowane z użyciem notacji UML klasyfikowane przez autorów tych dokumentów jako obiektowe (o obiektowej architekturze).

3. Wyniki

Opracowano rozszerzenie wzorca BCE i opisano metodę jego rozszerzania. Zbudowanie rozszerzonego metamodelu wzorca BCE wymaga spójnego systemu pojęć.

3.1. Pojęcia agenta i robota

Diagram: Pojęcia agenta i robota

Opracowanie spójnego metamodelu wymagało włączenia do niego pojęć, które już są używane w inżynierii oprogramowania: agent i robot.

W słowniku języka polskiego aplikacja jest definiowana jako komputerowy program użytkowy zaś komponent jako część składowa czegoś. Kolejne pojęcia to robot jako urządzenie zastępujące człowieka przy wykonywaniu niektórych czynności oraz agent jako przedstawiciel jakiejś firmy. Pojęcia te funkcjonują już zarówno w branży zarządzania jak i w inżynierii oprogramowania, jednak nadal nie maja ścisłych definicji. Z uwagi na potrzebę ścisłego zdefiniowania tych pojęć w tej pracy, uwzględniając obecne już publikacje z tego zakresu, przyjęto tu model przedstawiony na diagramie Pojęcia agenta i robota:

1. komponent aplikacyjny jest typem komponentu,
2. aplikacja może być zbudowana z (zawiera) komponentów aplikacyjnych,
3. agent jest samodzielnym typem aplikacji,
4. aplikacja użytkowa jest oprogramowaniem dla użytkownika,
5. robot jest typem komponentu aplikacyjnego

Tak określone znaczenia tych pojęć są zgodne z przyjętymi w literaturze znaczeniami: agent to samodzielny program (aplikacja), robot jest automatem (postrzeganym jako “mniej inteligentny” od agenta, a więc niesamodzielnym). Takie definicje wzajemnie się wykluczają więc spełniają wymagania dla definicji w przestrzeni pojęciowej (namespace), nie kolidują także z przyjętymi w literaturze przedmiotu.

3.2. Wzorzec architektoniczny BCE

Wzorzec BCE (Boundary, Control, Entity) w swojej pierwotnej wersji (Rosenberg 2005) zakłada, że komponenty aplikacyjne mają (realizują) jedną z trzech odpowiedzialności:

1. Boundary to interfejs komponentu,
2. Control to logika biznesowa,
3. Entity to utrwalanie.

Wzorzec ten był często niesłusznie interpretowany jako trójwarstwowe podejście do aplikacji (odpowiednio: interfejs, logika, dane) zgodnie z podejściem “aplikacja to funkcje i dane”. Później rozszerzono zastosowanie wraz ze wzorcem MVC (Rosenberg 2007). Wzorzec ten jednak jest bardzo ogólny i nie pozwala na precyzyjniejsze modelowanie ról. Z tego powodu bardzo szybko projektanci przechodzili do modelowania detali takich jak operacje i atrybuty klas i do implementacji, co w dużych projektach często prowadzi do szybkiego “zalania” projektu szczegółami.

There is some similarity between ECB and model–view–controller (MVC): entities belong to the model, and views belongs to boundaries. However the role of the ECB-control is very different from MVC-controller, since it encapsulates also use-case business logic whereas the MVC controller processes user input which would be of the responsibility of the boundary in ECB. The ECB control increases separation of concerns in the architecture by encapsulating business logic that is not directly related to an entity. https://en.wikipedia.org/wiki/Entity%E2%80%93control%E2%80%93boundary

Zadaniem było opracowanie metody i rozbudowy wzorca BCE w sposób nie kolidujący z jego podstawową ogólną formą (dla zachowania kompatybilności z historycznymi przypadkami jego użycia), dający możliwość projektowania zorientowanego na odpowiedzialność komponentów. Narzędziem jest tworzenie profili UML oraz budowanie modeli pojęciowych.

3.3. Profil UML dla rozszerzonego wzorca BCE

Diagram: Profil UML dla rozszerzonego wzorca BCE

Podstawowy zestaw stereotypów (stereotyp to dodatkowa klasyfikacja określonych elementów w notacji UML) to: boundary, control, entity. Rozszerzenie przestrzeni pojęciowej pozwala uzyskać profil zobrazowany na diagramie Profil UML dla rozszerzonego wzorca BCE.

Centralnym elementem jest pojęcie Stereotyp, jako dodatkowy klasyfikator dla nazwanych elementów Class (patrz OMG.org/MOF oraz OMG.org/UML). Dla komponentów (<<component>>) wprowadzono dwa stereotypy (dwie klasy komponentów): agentoraz aplikacja użytkownika. Celem jest wskazanie, że aplikacja może zostać zaprojektowana jako oprogramowanie dla jego użytkownika (będącego człowiekiem) lub oprogramowanie autonomiczne (reaguje na szerokopojęte otoczenie), działające samodzielnie. Oba te typy aplikacji mogę być projektowane z użyciem wzorca MVC więc komponent logiki dziedzinowej jest w oby typach aplikacji modelowany w ten sam sposób.

Trzyelementowy wzorzec BCE został poszerzony w ten sposób, że każdy z trzech jego elementów zyskał specjalizacje:

1. boundary: callAdapter, API oraz GUI,
2. control: robot oraz onDemand,
3. entity: description oraz businessObject.

Komponent boundary to interfejs pomiędzy aplikacją a jej otoczeniem. Usługi są udostępniane aktorom, zależnie od typu aktora, interfejsem GUI lub API 9interfejs oferowany). Jeżeli jest to przypadek interfejsu wymaganego, “wyjście na świat” deklarujemy jako callAdapter (nie dopuszczamy by jakiekolwiek komponent z wnętrza aplikacji wywoływał bezpośrednio usługi z poza aplikacji).

Komponent control realizuje usługi dziedzinowe na żądanie jako onDemand, albo działa samoczynnie jako “demon” robot. W literaturze pojęcie demon jest często stosowane jako nazwa automatu uruchamiającego polecenia wg. harmonogramu, dlatego celowo użyto pojęcia robot, na nazwę komponentu zachowującego pełną autonomię w tym jakie funkcje i jak realizuje. Komponent entity odpowiada za utrwalane dane. Dla rozróżnienia description odpowiada za przechowywanie wszelkich opisów konfiguracji, z reguły jest singletonem (singleton to klasa mająca jedną instancją). Te oznaczone businessObject reprezentują wszelkie strukturyzowane dane takie jak formularze, dokumenty, multimedia itp. Warto tu nadmienić, że obiekty typu entity nie reprezentują interfejsu do bazy danych wg. wzorca active records lub active table (Larman 2004). Dokument może tu być rozumiany jako ciąg znaków XMl przechowywany jako wartość jednego atrybuty klasy.

3.4. Przykład użycia rozszerzonego wzorca BCE

Diagram: Przykład użycia rozszerzonego wzorca BCE

Na diagramie Przykład użycia rozszerzonego wzorca BCE pokazano architekturę prostej aplikacji wspomagającej sprzedaż. Jest to model jej dziedziny.

Aplikacja jest oprogramowaniem typu aplikacja użytkownika gdyż powstała by wspomagać prace użytkownika jakim jest Sprzedawca. Użytkownik Prawnik jest tu wyłącznie osobą parametryzującą (np. okresowo) zachowanie robota Obsługa windykacji. Celem aplikacji jest wystawianie faktur oraz bieżące prowadzenie tak zwanej miękkiej windykacji.

Standardową usługą tej aplikacji jest wystawianie faktur na postawie zamówień pobieranych z aplikacji System CRM.

System kontrolingu ma dostęp do faktur przez interfejs Dostęp do statusów faktur, pobiera dane o fakturach, dla których miękka windykacja była nieskuteczna.

Z uwagi na żmudną pracę związaną z miękką windykacją (załóżmy, że wcześniej robiło to call center), zautomatyzowaną ją dodając do aplikacji komponent Obsługa windykacji pracujący jako robot. Jest to komponent zawierający kompletną procedurą, która cyklicznie realizuje scenariusz: sprawdź status faktury, sprawdź czy wpłynęła dla niej płatność, zależnie od tego oznacz ją jako zapłaconą lub wyślij monit, stosownie do tego, które jest to wezwanie do zapłaty.

Na tym etapie, opracowanie architektury zorientowane na odpowiedzialność klas, nie jest potrzebne wiedza o danych, zupełnie wystarczy wiedza o rolach poszczególnych komponentów. Kolejnym krokiem było by tu ustalenie wszystkich potrzebnych statusów i ich nośników, a na końcu dopiero ustalenia wymaga struktura faktury, monitu i dowodu wpłaty.

Rozszerzony wzorzec BCE, jako metamodel i zarazem wzorzec architektoniczny, pozwala od razu zbudować szkielet tej aplikacji, stanowi wspólny język. Można przyjąć założenie, że zrozumienie pojęć jakimi nazwano role poszczególnych komponentów (stereotypy) pozwala zrozumieć zobrazowany mechanizm działania (formalnie powinny powstać także diagramy sekwencji, które pomięto by nie zwiększać objętości tego tekstu).

Opisana aplikacja z zewnątrz jest dla użytkownika relatywnie prostym programem użytkowym. Ma tylko jednego użytkownika (Sprzedawca), Użytkownikiem jest także Prawnik, który sporadycznie ustawia parametry pracy komponentu oznaczonego jako robot.

Na diagramie Aplikacja Faktury Usługi i wymagania zobrazowano aplikację Aplikacja Faktury z użyciem diagramu przypadków użycia notacji UML. Należy tu zwrócić uwagę, że diagram ten służy wyłącznie do dokumentowania celu tworzenia aplikacji. Diagram ten nie służy do opisu szczegółów jej funkcjonowania. Dlatego ten diagram w notacji UML bywa nazywany kontraktem lub kontekstem projektu. A typowym procesie analizy i projektowania ten diagram powstaje jako pierwszy.

4. Dyskusja

W toku przeglądu dostępnych autorowi dokumentacji projektowych, stwierdzono, że powszechna praktyką jest rozpoczynanie analiz i projektowania od tworzeniu modelu danych (diagramu ERD) lub szczegółowych diagramów klas bazujących na wzorcu active records lub active table (klasa i jej atrybuty reprezentują wiersze tabel baz danych, zaś związki między klasami relacje między tymi tablicami). Przykładem takiego podejścia jest próba stworzenia wzorców bazujących na detalicznych danych w dokumentach biznesowych (Arlow Neustadt 2004).

Autor proponuje całkowicie inne podejście, oparte na doświadczeniach z wzorcami BCE i DDD: budowanie dziedzinowych metamodeli w postaci profili abstrahujących całkowicie od detalicznej wiedzy o dokumentach (businessObject) a skupiających się na mechanizmie działania, tu jedynymi wymaganymi atrybutami są te, które obsługują logikę biznesową, są to metadane i statusy (nie pokazane w tym dokumencie). Trwają prace nad testowaniem tej metody. Spodziewane są małe zmiany definicji poszczególnych elementów.

 5. Literatura

Arlow Neustadt 2004	Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Jim Arlow; Ila Neustadt, ISBN-13: 9780321112309, 2004
Dzieszko i inni 2013	ROCZNIKI GEOMATYKI 2013 m TOM XI m ZESZYT 4(61), MODELOWANIE AGENTOWE NOWOCZESNA KONCEPCJA MODELOWANIA W GIS, Piotr Dzieszko, Katarzyna Bartkowiak, Katarzyna Gie?da-Pinas, Uniwersytet im. Adama Mickiewicza w Poznaniu, Wydzia? Nauk Geograficznych i Geologicznych, Instytut Geoekologii i Geoinformacji, Zakład Geoekologii
Evans 2003	Domain Driven Design Tackling Complexity in the Heart of Software by Evans, Eric. Published by Addison Wesley,2003,
Larman 2004	Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Craig Larman, Prentice Hall, October 30, 2004, ISBN-10: 0131489062
Rosenberg 2005	Rosenberg, Don, Collins-Cope, Mark, Stephens, Matt, Agile Development with ICONIX Process, Apress 2005, ISBN 978-1-59059-464-3
Rosenberg 2007	Use Case Driven Object Modeling with UMLTheory and Practice, Theory and Practice, Rosenberg, Don, Stephens, Matt, Apress 2007
Sobczak 2019	Sobczak Andrzej, Czym jest robot programowy (software robot) – próba definicji (https://robonomika.pl/czym-jest-robot-programowy-software-robot-proba-definicji). 19 kwiecień 2019
Wirfs-Brock 2003	Object Design: Roles, Responsibilities, and Collaborations, Rebecca J Wirfs-Brock and Alan McKean, Addison- Wesley, 2003 (also: http://wirfs-brock.com/Design.html)
Żeliński 2019	Synthesis of MOF, MDA, PIM, MVC and BCE notions and patterns, Self publishing , 2019, Jarosław Żeliński

Tym razem recenzje dwóch książek w jednym wpisie:

1. Agile Development with ICONIX Process. People, Process, and Pragmatism. By Doug Rosenberg , Mark Collins-Cope, Matt Stephens
2. Use Case Driven Object Modeling with UML. Theory and Practice. 2nd Edition. By Doug Rosenberg , Matt Stephens

Pierwsza wydana w 2005 roku, druga 2013 r. Pierwsza metodę ICONIX opisuje na przykładach, w kontekście zwinnych metod, proces projektowania i tworzenia oprogramowania bazujący na modelach. Są to:

1. Model przypadków użycia specyfikujący wymagane zachowania aplikacji.
2. Dziedzinowy model pojęciowy
3. Model dziedziny (architektura).
4. “Robustness diagram” abstrakcyjny model zachowania bazujący na jednoznacznych tylko biznesowych pojęciach (diagram komunikacji).
5. Diagram sekwencji obrazujący zachowania się elementów architektury systemu w toku realizacji scenariuszy przypadków użycia.

(more…)

Dwa tygodnie temu, na konferencji o jakości systemów IT, prezentowałem między innymi dwa poniższe wykresy:

Pierwszy wykres jest bardzo popularny w literaturze przedmiotu, tu jeden z wielu przykładów. Powołam się na niego później.

Drugi jest wynikiem moich studiów literatury , własnych badan i doświadczenia i właśnie o nim nieco więcej. Wyjaśnię jak powstał.

W zasadzie wystarczy uznać, że jeżeli spełnienie zasady “[[open closed principle in object oriented software]]” (architektura systemu jest otwarta na rozszerzenia i zamknięta na zmiany) jest możliwe, to kod tak zbudowanej aplikacji  “rośnie” liniowo, a koszt rozwoju podobnie. Początkowy koszt, to koszt opracowania szkieletu (zwanego [[core domain]]). To właśnie – w aplikacjach konstruowanych zgodnie z [[zasadami SOLID]] – powoduje, że koszt początkowy jest relatywnie wyższy niż koszt architektury budowanej “ad-hoc” (oznaczonej ???).

Nie mam ambicji tworzenia przykładu “brzydkiej architektury”, chyba już nie umiem 😉 dlatego poniżej tylko struktura aplikacji (architektura komponentu Model/MVC) w obiektowym paradygmacie (aplikacja to współpracujące obiekty) zgodna z SOLID:

Model ten powstał z użyciem bloków funkcjonalnych wzorca BCE (opisałem go tu: Wzorzec analityczny Boundary Control Entity). Dla wyjaśnienia: powyższy diagram to w pełni poprawny Model dziedziny wykonany z użyciem diagramu klas UML, klasy mają stereotypy boundary, control i entity (powyżej od lewej do prawej), stereotypy te są reprezentowane symbolami opisanymi (ikonami) w BCE. Kilka cech tej architektury:

1. każdy przypadek użycia ma dedykowaną klasę (ta połączona z aktorem) odpowiedzialną za jego interfejs i scenariusz (ale nie logikę biznesową!),
2. scenariusz przypadku użycia to “recepta” na to, kiedy i czego wewnątrz aplikacji należy użyć do realizacji celu użytkownika,
3. to co “potrafi” aplikacja to usługi wewnętrzne (logika biznesowa),
4. to co aplikacja musi “wiedzieć”  zapamiętało się (jest przechowywane) w repozytoriach,
5. żadne informacje nie są, logicznie ani w szczególności fizycznie, współdzielone: każde repozytorium, powyżej są trzy,  jest w 100% hermetyzowane (implementacja repozytoriów to absolutnie! nie jest jedna współdzielona relacyjna baza danych i mapowanie ORM!).

Widać (mam nadzieję na tym dość prostym schemacie), że każdy przypadek użycia to odrębny “serwis”, praktycznie niezależna usługa (u Fowlera nazywane mikroserwisami).  Są od siebie całkowicie odseparowane, co najwyżej korzystają z tych samych specjalizowanych usług wewnętrznych (np. z generatora plików PDF będzie korzystała każda usługa operująca na dokumentach do druku). Dodanie kolejnego przypadku użycia  w ogóle nie wpływa na resztę  aplikacji (zaleta hermetyzacji), ewentualne redundancje są raczej zbawieniem niż wadą, gdyż każda usługa ma swój kontekst i własny cykl życia, i jakiekolwiek współdzielenie treści (nie mylić z wykorzystaniem tych samych) raczej zmusi do (zgniłego) kompromisu.

Współdzielenie danych najczęściej przynosi szkody, np. współdzielenie listy produktów pomiędzy zamówieniem i fakturą powoduje zależność uniemożliwiającą wystawienie faktury na produkty inne (w innej ilości) niż na tym zamówienia (nie takie rzadkie zjawisko w dostępnych na rynku systemach ERP). Utworzenie faktury poprzez skopiowanie (wykorzystanie) zawartości Zamówienia, pozwala na jej (faktury) dowolną modyfikację bez potrzeby zmiany Zamówienia (żądania powtórnego jego przysłania lub o zgrozo, wewnętrznej korekty!). Współdzielenie danych firm pomiędzy np. fakturami i rejestrem kontrahentów, skutkuje problemem gdy aktualizacja adresu kontrahenta przenosi się na historyczne faktury. Owszem może nam się przytrafić koszt nowej usługi wewnętrznej, ale zrobimy to bez jakiejkolwiek ingerencji w dotychczasową logikę (i kod).

Aplikacje, których architektura wewnętrzna bazuje na współdzielonych danych, relacyjnej jednej bazie danych (jeden spójny system tablic relacyjnej bazy danych “pod” aplikacją), gęstej sieci wewnętrznych zależności, wymagają – dla dodania nowej usługi lub zmiany istniejącej – prawie zawsze częściowego lub całkowitego re-faktoringu, a w skrajnych przypadkach nawet migracji danych do nowej ich struktury. W efekcie, to co użytkownik postrzega jako rozszerzenie, dla dewelopera stanowi pracochłonny refaktoring, tym bardziej pracochłonny im większa ta aplikacja. Z tego powodu koszty wprowadzania zmian do tak stworzonej aplikacji są tym większe im większa i złożona jest ta aplikacja (czerwona linia na wykresie kosztu rozszerzenia funkcjonalności).

Pisanie oprogramowania ad-hoc, bez przemyślanej logiki i architektury całości, prowadzi do powstawania tak zwanego “[[długu architektonicznego]]” (analogicznie do [[dług technologiczny]]). To dlatego bardzo często źle pojmowane “agile” pozwala bardzo szybko uzyskać pierwsze efekty, niestety okupione bardzo kosztownym późniejszym utrzymaniem i rozwojem  takiej aplikacji. Chyba, że produkt taki potraktowany zostanie jako efemeryda albo jako prototyp odrzucany.

Niestety wiele systemów ERP i i nie tylko, powstało w latach 90’tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i “nad nią” funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie – jak to zachwalają ich dostawcy – zaletą…