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”]

Ten artykuł jest adresowany do wszystkich. Biznes (prawnicy także) może przekonać się, że oprogramowanie można narysować i zrozumieć. Analitycy i programiści, że to możliwe, a deweloperzy, że nikt im nie odbiera pracy a raczej pomaga.

Wprowadzenie

W dzisiejszym świecie inżynierii największą wartość mają czas i zasoby. Czas to jak najszybsze oddanie rozwiązania (produktu) do użytku (szybka komercjalizacja), zasoby to koszt jakim się to odbędzie. Kluczem są koszty: “time to market”, tu kosztem jest opóźnienie komercjalizacji (niezrealizowane przychody), kosztem jest także samo powstawania oprogramowania. Praktycznie od początku inżynierii oprogramowania zależność kosztów od dyscypliny i etapu pracy się nie zmienia, wygląda to jak poniżej:

Od samego początku prac nad oprogramowaniem tak naprawdę rozwiązujemy problemy: począwszy od problemów z odkryciem co tak naprawdę jest rozwiązaniem problemu (a problem trzeba najpierw zidentyfikować), przez problemy związane z właściwym zaprojektowaniem rozwiązania (algorytmy, architektura kodu), do problemów wyboru technologii i implementacji. Patrząc od końca: pomyłki są bardzo kosztowne dla organizacji (sponsor projektu). Development (kodowanie i testy) to praca zespołów ludzi, są bardzo kosztowne. Najtańsza jest tu praca (etap) analityka-projektanta, to jednak także czas (pamiętamy “time to market”).

Tak więc “waterfall” nie wchodzi w grę. Praktyka jednak pokazuje, że rozpoczęcie od razu od kodowania nie rozwiązuje żadnego problemu bo złe pomysły są i będą, korygowane dopiero na etapie kodowania generują bardzo duże koszty. Lekarstwem jest odejście o monolitycznej architektury na rzecz samodzielnych komponentów, czy wręcz mikroserwisów (jednostki implementacji to pojedyncze przypadki użycia UML, tu rozumiane jako niezależne mikro-aplikacje [zotpressInText item=”{5085975:IENSXKK5},{5085975:XSXM2FP8}”]). Dlatego optymalne wydaje sie podejście: 1. analiza, 2. projektowanie HLD: komponenty, 3. iteracyjne projektowanie LLD komponentów i ich development. Osiągamy ważną rzecz: najdroższe zasoby: development, dostają do implementacji przemyślane rozwiązanie, nie tracimy czasu i środków na kolejne prototypy w kodzie.

MDA czyli cykl życia aplikacji

Ponad 10 lat temu organizacja Object Management Group opublikowania specyfikacje MDA (Model Driven Architecture, architektura zorientowana na modele [zotpressInText item=”{5085975:FX3SVDIW},{5085975:ARDKHW9J}”]). Opisuje ona proces od analizy, przez modele rozwiązania, aż do jego implementacji. Proces ten wygląda tak:

Czy to jest waterfall (technika wodospadowa)? To zależy od zaprojektowanej architektury oprogramowania. Jeżeli będzie to funkcyjny monolit budowany na centralnej relacyjnej, bazie danych (RDBMS) to będzie to waterfall. Jeżeli jednak będzie to komponentowa architektura zorientowana na micro aplikacje (micro serwisy), będzie to zwinna, iteracyjno-przyrostowa, implementacja i rozwój, gdyż na podstawie modelu PIM (także polityka podziału na komponenty i usługi) wykonywane są przyrostowo i niezależnie od siebie, kolejne implementacje usług aplikacji (PSM->Code). Tak więc wszystko rozstrzyga się na poziomie modeli PIM. PIM (Platform Independent Model) to projekt oprogramowania niezależny od technologii (czyli także od użytego języka programowania).

Mikro-serwisy

O mikro-aplikacjach pisałem nie raz, tu tylko przypomnienie:

Tak więc wszystko zależy od architektury, zwinność także. Po prawej stronie (diagram powyżej) pokazano ideę podziału aplikacji na niezależne komponenty, każdy z własnym repozytorium (bazą danych). Komponenty te można developować i oddawać do użytku w dowolnej kolejności [zotpressInText item=”{5085975:ECD9XUND}”].

Program to abstrakcja rozwiązania, określony kod to jedna z wielu możliwych implementacji

Złożoność systemów rośnie z każdym rokiem. Oprogramowanie (komputery) jest częścią coraz większej ich liczby. Development jest najkosztowniejszą fazą wytwarzania oprogramownia, dlatego coraz znowu częściej poprzedza się go projektowaniem czyli “tworzeniem programu jako logiki” [zotpressInText item=”{5085975:NZCQDD79}”]. Nie da się “z marszu” napisać tysięcy linii kodu, nie popełniając błędów w kodzie czy na poziomie samej architektury i logiki działania.

Tworzenie systemów zawierających oprogramowanie obejmuje wiele poziomów abstrakcji, prowadzących od wymagań do kodu. Posiadanie abstrakcyjnych koncepcji pomaga zdefiniować kod i upewnić się, że komponenty oprogramowania zachowują się w oczekiwany sposób. Istnieje luka, która nie może być wypełniona przez zwykłe metody programowania, ale która może być wypełniona, jeśli programowanie jest wspierane przez odpowiednie ramy modelowania.

[zotpressInText item=”{5085975:4XDEIZGV}”]

Program komputerowy może zostać wyrażony z pomocą kodu, ale także, w sposób równoprawny, “z pomocą schematów blokowych, algorytmów i wzorów matematycznych” (http://www.ipblog.pl/2017/03/programy-komputerowe-co-podlega-ochronie/). Zgodnie z powyższym i z MDA mamy:

Przykład czyli programujemy obrazkowo

Zakres projektu

Opracujemy program wspierający proces obsługi klientów przychodni weterynaryjnej. Wygląda on tak:

Jak widać nie jest specjalnie wyrafinowany: Jeżeli potrzebna jest wizyta ze swoim pupilem u weterynarza, umawiamy termin, przychodzimy na wizytę, opuszczamy przychodnie z receptą i zaleceniami. Faza analizy i opracowania architektury została opisana w artykule Projekt aplikacji. Tu skupimy się na “programowaniu”.

Od kilku już dekad w podręcznikach inżynierii oprogramowania nadal można spotkać sentencję:

algorytmy + struktury danych = programy

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

Poza technologią i paradygmatami, nic sie nie zmieniło. To znaczy, że bez względu na architekturę, paradygmat i język programowania, ‘programy’ to ‘algorytmy + struktury danych’. Innymi słowy: programowanie to projektowanie algorytmów i struktur danych, dalej jest już tylko implementacja (kodowanie) tych programów.

Każdy “program” to deklaracja zmiennych + działania na nich. Może to być poprzedzone pobraniem tych danych i zakończone zwróceniem danych (parametrów). Można to (fragment programu prezentowana jako “czynność” w UML) wyrazić pseudokodem:

Lub w formie bardziej przystępnej dla laika, “obrazkowej”:

Od początków “człowieczej biurokracji” standardową formą przechowywania danych są formularze, czy szerzej rzecz ujmując, dokumenty. W roku 1972 Codd opublikował swoja pracę, w której opisał relacyjny model danych, jednak celem było zarządzanie zbiorami danych a nie “informacją” [zotpressInText item=”{5085975:HQR8QPVJ}”]. Powstało wiele implementacji tego modelu i niestety model ten zdominował branże. W czasie gdy powstawał liczyła się optymalizacja tych zbiorów od strony objętości (to był główny czynnik kosztowy). Jednak po latach okazało się, że:

Relacyjny model danych jest nieelastyczny. Cechuje się precyzyjnie zdefiniowaną strukturą danych, która jednak bardzo ją ogranicza. Musimy zdefiniować stałą strukturę jak kolumny i wiersze tabel oraz określić ich relacje, co jest później trudne do zmiany. Ponadto, jeśli dziedzina pojęciowa jest głęboko zagnieżdżona, użycie modelu relacyjnego dla niej będzie wymagało wielu tabel i złączeń. Relacyjne bazy danych mają słabą skalowalność poziomą. Mogą być skalowane w pionie poprzez dodanie większej ilości zasobów, takich jak procesor i pamięć RAM. Ale nie mogą być skalowane poziomo, tzn. łączyć wielu maszyn i tworzyć klastrów. Wynika to z wymagań dotyczących spójności. Baza danych zorientowana na dokumenty rozwiązuje niektóre z tych problemów, z którymi boryka się baza danych w modelu relacyjnym.

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

Główną wadą relacyjnego modelu danych w systemach biznesowych jest zapisywanie danych w postaci współdzielonych znormalizowanych struktur pojęciowych, pozbawionych redundancji, co powoduje, że dane są pozbawione kontekstu [zotpressInText item=”{5085975:4XIV4RNM}”], a w konsekwencji model ten nie sprawdza się w systemach zarządzających dokumentami i ich treścią.

Dokumenty biznesowe (dowody księgowe ale także umowy, oferty i wiele innych) to złożone agregaty danych, więc zapytania SQL do tabel relacyjnych (do ich zapisu i odczytu) to bardzo złożone struktury kodu, powodujące że tak zorganizowane bazy szybko stają się niewydajne (zasoby takie jak procesor i RAM są ograniczone a skalowanie poziomie RDBMS jest niemożliwe). Dodatkowo dokument, w sensie fizycznym nie może być generowaną dynamicznie strukturą (zapytania SQL do bazy relacyjnej), bo jest wtedy tylko wirtualnym chwilowym bytem, nie stanowi także dokumentu w sensie prawnym (Kodeks Cywilny), nie da się też zarządzać jego cyklem życia.

To powoduje, że od 20 lat mamy możliwość korzystania z baz zorientowanych na dokumenty (bazy NoSQL). Struktury danych bardzo łatwo i efektywnie można projektować od razu jako szkielety dokumentów: agregaty [zotpressInText item=”{5085975:GGPUJMUW}”]:

Powyższy diagram to klasyczny agregat, który z innej perspektywy wygląda tak:

Powyższe łatwo zapisać jako jedna strukturę XML (lub JSON) i zachować jako wartość jednego atrybutu obiektu [zotpressInText item=”{5085975:Y3EUPEA9}”]. Każdy element tego agregatu (atrybut) ma adresowalną unikalną postać, np. data planowanej wizyty:

Karta Wizyty.data := 22-10-02
Karta Wizyty.Rezerwacja.data := 22-10-16

Gdzie nazwa dokumentu jest początkiem ścieżki (nazwy dokumentów-agregatów muszą być unikalne). Dzięki temu atrybuty, jako typy danych, definiowane są raz (np. tu data), zaś kontekst nadaje im położenie w strukturze dokumentu. Powyższy przykład to dwie różne daty: data dokonania rezerwacji (data założenia Karty wizyty) i data samej wizyty. Tu 2 października umówiono sie na wizytę w dniu 16 października. Ale typ ‘data’ definiujemy raz, nie musimy definiować tylu dat ile jest ich rodzajów (data_rezerwacji, data_wizyty, itp…)

Tą metodą jednym prostym krokiem pobieramy dane z takiego agregatu [zotpressInText item=”{5085975:ZIIDU6A9}”], następnie opisujemy jakie operacje mają zostać na nich wykonane, wynik zwracamy jako ten sam agregat (wyliczono wartości pustych atrybutów, zwracamy wypełnione) lub inny agregat (wynik wyliczeń to nowy formularz/agregat) i możemy go np. przekazać innemu komponentowy do utrwalenia, lub zwrócić jako wynik do pokazanie na ekranie (patrz także starszą formę wzorca envelope: DTO).

Przykładowy opis tworzenia nowej karty wizyty:

Tak więc zaprojektowanie aplikacji, przetestowanie spójności i kompletności logiki jej działania, przed kodowaniem jest nie tylko możliwe ale i pożądane, pomijam, że odbywa sie znacznie mniejszym kosztem i szybciej (praktyka pokazuje, że powyższe na diagramach jest o ponad rząd wielkości szybsze i tańsze niż praca od razu na kodzie).

Podsumowanie

Od początku inżynierii oprogramowania wiadomo, że programowanie to nie koniecznie kodowanie. Już na studiach najpierw “rysowałem” oprogramowanie a potem dopiero kodowałem to np. w Fortranie. Powód zawsze był ten sam: prace koncepcyjne są wielokrotnie tańsze na schematach blokowych niż na żywej maszynie. Ten sam program można było zawsze uruchomić na różnych komputerach, konieczny był jedynie wybór właściwego języka dla danej maszyny. Owszem, można “od razu w kodzie”, jest to jednak najbardziej nieefektywna metoda tworzenia oprogramowania. Wbrew potocznemu postrzeganiu manifestu agile, opisane tu schematy blokowe to nie jest “nadmiarowa dokumentacja” a “istota działania systemu”. Po drugie ani urząd patentowy w USA, ani europejski sąd w sprawie ochrony know-how, nie będzie analizował kodu źródłowego tylko jego sformalizowany opis.

Jak definiujemy role?

CZYM ZAJMUJE SIĘ INŻYNIER OPROGRAMOWANIA?
Inżynierowie oprogramowania oceniają potrzeby klienta lub firmy w połączeniu z potrzebami użytkownika i metodycznie konceptualizują i wyrażają rozwiązanie.

https://builtin.com/recruiting/software-engineer-vs-programmer

CZYM ZAJMUJE SIĘ PROGRAMISTA?
Programiści piszą kod i debugują błędy w programach i oprogramowaniu na podstawie instrukcji od inżynierów oprogramowania. Są zaangażowani w pojedynczy etap cyklu rozwoju i koncentrują się na jednym komponencie naraz.

https://builtin.com/recruiting/software-engineer-vs-programmer

Źródła

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

Wprowadzenie

Pojęcie ‘system’ stało się bardzo popularne, głównie za sprawą “systemów informatycznych”, jednak jego rodowód jest starszy i pochodzi nie od technologii a od biologii [zotpressInText item=”{5085975:CHQUCPGA}”]. Poza IT mamy systemy bezpieczeństwa, system ubezpieczeń, system emerytalny, system prawa, i wiele innych. Słownik języka polskiego podaje taką definicję pojęcia system:

1. układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość
2. zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość
3. narządy lub inne części żywego organizmu pełniące razem określoną funkcję
4. uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię
5. określony sposób wykonywania jakiejś czynności lub zasady organizacji czegoś
6. forma ustroju państwowego
7. zespół skał powstałych w ciągu jednego okresu geologicznego
8. log. całościowy i uporządkowany zespół zdań połączonych ze sobą stosunkami logicznego wynikania

Jak widać jest to pojęcie bardzo uniwersalne dziedzinowo, jednak generalnie wszystkie te definicje to szczególne rodzaje tej pierwszej. My skupimy sie na pierwszych dwóch: pierwsza z uwagi na jej ogólność, druga z uwagi na fakt, że komputer to system będący urządzeniem, a w zasadzie zespołem urządzeń.

Organizacje, firmy w szczególności, to złożone “systemy systemów”. Poniżej model firmy po raz pierwszy opublikowany w 1985 roku:

Model ten jest nada aktualny i wykładany na studiach MBA. Pokazuje, że żadna firma nie jest organizacyjnym monolitem.

w 1998 roku M.E.Porter, w kolejnym wydaniu swojej książki [zotpressInText item=”{5085975:9MPPQESP}”], dodał rozdział o systemach informatycznych, w którym zwrócił uwagę na to, że system informatyczny firmy powinien architektonicznie odpowiadać wyżej zobrazowanej strukturze firmy, jeżeli to wystąpi zjawisko tak zwanego “niedopasowania oporu” czyli niezgodność systemu jakim jest firma, z systemem jakim jest oprogramowanie ją wspierające.

Teza jakoby monolityczny system informatyczny, z jedną centralną bazą danych, był adekwatny dla firm, już wtedy została praktycznie obalona (najbardziej znane dziś systemy ERP powstały znacznie przed 1998 roku, do tej pory rozwijana jest jedynie technologia ich implementacji a nie architektura, to dlatego ich kompleksowe wdrażanie to od wielu lat serie porażek).

Z książki Portera można wyciągnąć ważny wniosek: system informatyczny powinien stanowić odwzorowanie ww. procesów z tą uwagą, że procesy wspierające, jako najczęściej regulowane prawem, nie budujące przewagi rynkowej, i z tego powodu rzadko będące także tajemnicą przedsiębiorstwa, powinny (mogą być) wspierane jedną standardową aplikacją. Pozostałe, jako unikalny w każdej firmie proces operacyjny (na schemacie Primary), powinny być wspierane przez samodzielne, dedykowane dziedzinowo, zintegrowane na poziomie logiki przepływu danych, aplikacje.

Ten artykuł to wyjaśnienie czym jest tak zwany “system systemów” [zotpressInText item=”{5085975:5B9ZHAYU}”] i jak sie to ma do firm. Zainteresowanym polecam także [zotpressInText item=”{5085975:78G4HG9Z}”]. Poniżej troszkę teorii, praktyki i przykładów.

Modele i meta-modele

Pojęcie model i meta-model jest bardzo ważne zarówno w analizach jak i w modelowaniu systemów. Słownik języka polskiego definiuje pojęcie model jako (w naszym obszarze dziedzinowym): ?konstrukcja, schemat lub opis ukazujący działanie, budowę, cechy, zależności jakiegoś zjawiska lub obiektu?. Przedrostek meta- oznacza: ?pierwszy człon wyrazów złożonych wskazujący na wyższy stopień, następstwo lub zmienność czegoś?.

Modelowanie jest ważne, jednak wiele modeli, pozbawionych ich meta-modeli, jest wadliwa gdyż ich tworzenie i jednoznaczna interpretacja mogą być niemożliwe [zotpressInText item=”{5085975:3PJSCD8F},{5085975:4U34KY6A}”]. OMG.org publikuje specyfikację MOF, o której już pisałem. Jest to standardowy opis warstw abstrakcji, modelowania i meta-modelowania:

Schemat powyższy obrazuje podstawowe cztery poziomy abstrakcji. Licząc od dołu mamy:

• M0 – warstwa podstawowa, jest to to co jest (może być) modelowane: realny świat, urządzenie, system aktów prawnych, działające oprogramowanie w pamięci komputera, komputer, itp. na tym poziomie mówimy o obiektach (entity), to realne byty.
• M1 – jest to model świata istniejącego w warstwie M0, tu byty rzeczywiste są reprezentowane z pomoca absgtrakcyjnych, prostych symboli na schematach blokowych (jeden do jednego: symbol – obiekt rzeczywisty).
• M2 – jest to meta-model wartswy M0, są to klasy (typy) elementów z jaki zbudowany jest świat M0.
• M3 – jest to meta-meta-model, są to definicje pojęć, użytych do powstania metamodelu, jest to np. definicja notacji, jakiej użyjemy to modelowania warstwy M2.

Warstwa M0 to analizowany świat (system). Warstwa M3 to metoda modelowania (typy elementów na diagramach modeli). Warstwa M2 i M1 to np. modele w notacji UML (i jej pochodnych): M2 to diagramy klas a M1 to diagramy obiektów (specyfikacje instancji tych klas). W dalszej części będziemy korzystali z warstw udostępnianych przez UML.

Notacja SysML

Notacja UML jest bardzo nadmiarowa, jako Unified Modeling Language (Ujednolicony Język Modelowania) jest ogólna, i nie precyzuje zastosowania swoich elementów, specyfikuje ich znaczenie (np. klasa ma swoją definicję w UML, ale to czy użyjemy pojęcia klasy do modelowania komponentów, ich interfejsów, czy systemu pojęć, to samodzielna decyzja użytkownika UML). UML niesie z sobą piętno inżynierii oprogramowania, gdyż pierwotnie notacja ta powstała jako narzędzie służące do projektowania w inżynierii oprogramowania. Jednak szybko odkryto, że pojęcia modeli i meta-modeli są bardzo przydatne, więc schematy blokowe w tej notacji zaczęły dominować w publikacjach traktujących o systemach i ich modelach. Kilka lat po opublikowaniu specyfikacji UML pojawiła się zawężona i uporządkowana specyfikacja: notacji SysML (System Modeling Language, [zotpressInText item=”{5085975:E9MDNWLY}”]), stanowiącej profil UML i jego podzbiór:

Diagramy wykorzystywane do modelowania systemów:

Notacja ta szybko zdobyła sobie uznanie w przemyśle, doskonale nadaje się do modelowania szerzej rozumianych systemów np. samochodów [zotpressInText item=”{5085975:JJUK9U4T}”], a generalnie tak zwanych urządzeń mechatronicznych, czyli złożonych elektromechanicznych urządzeń, których częścią są także komputery (więc także oprogramowanie). Korzyści ze stosowania abstrakcyjnych modeli tego typu systemów są na tyle duże, że notacja SysML staje się przemysłowym standardem w systemach zarządzania produktami i ich produkcją [zotpressInText item=”{5085975:KQHL22X8}”].

Mechanizm

Słownik języka polskiego definiuje pojęcie mechanizm jako: sposób, w jaki coś powstaje, przebiega lub działa, np. sposób działania organizacji, oprogramowania. W nauce mechanizmy są obiektami o określonych własnościach i procesami zorganizowanymi w taki sposób, że powodują one regularne zmiany, począwszy od początku, czy też warunków początkowych, aż do zakończenia działania lub warunków końcowych.

Statystycznie określona korelacja nie jest modelem mechanizmu, nie określa ona związku przyczynowo-skutkowego, jest jedynie stwierdzeniem statystycznej powtarzalności [zotpressInText item=”{5085975:LCAP9JJ4}”]. Cytując Cravera, możemy powiedzieć: ?mechanizm jest wyjaśnieniem powiązania, którego Hume szukał między przyczyną a skutkiem?, ?mechanizm zachowania jest złożonym systemem, który opisuje to zachowanie poprzez interakcję wielu komponentów, przy czym interakcję między komponentami można opisać jako związki uogólnień (generalizacji) komponentów tego systemu? [zotpressInText item=”{5085975:LKGQJ85W}”].

Tak więc model może opisywać (wyjaśniać) mechanizm powstawania czegoś (zachowania się czegoś). Innymi słowy jeżeli jakiś np. schemat blokowy coś wyjaśnia, to znaczy, że jest on modelem tego czegoś. Jeżeli to coś ma dopiero powstać, do model ten jest projektem tego czegoś. I tu pojawia się pojęcie MBSE: Model-based System Engineering.

Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone zainteresowanie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonej akceptacji MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemów.”

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

Metody określane jako MBSE sprawdzają się bardzo dobrze jako narzędzie specyfikowania wymagań, tu wymaganiem jest właśnie model czyli projekt systemu [zotpressInText item=”{5085975:63PW4WQU}”].

Systemy – analiza i modelowanie

Jak już wspomniano, komputer jest coraz częściej elementem nadrzędnej konstrukcji. Dlatego pod pojęciem ‘model systemu’ rozumiemy coś więcej niż oprogramowanie:

Praktyka pokazuje, że podejście to doskonale sprawdza się w projektowaniu systemów informatycznych, które z zasady są częścią nadrzędnego bytu, jakim jest organizacja, będąca ich (przyszłym) użytkownikiem.

W notacji SysML modele systemów są ograniczone wyłącznie do ich abstrakcji, dlatego znaczna część elementów notacji UML nie jest tu stosowana (dotyczy to głównie część UML służącej do revers-inżynierii kodu i do generowania kodu z diagramów). Mamy tu cztery filary modelowania:

1. Modele struktury, 2. modele zachowania, 3. modele wymagań, 4. Model parametryczny. Od końca:

Model parametryczny to nowy typ diagramu. Jest to narzędzie modelowania wielkości fizycznych przepływających między elementami systemu, np. przekazywany moment obrotowy wału silnika czy napięcie i prąd zasilania (ale także sygnały i komunikaty czyli informacje). Modele wymagań to strukturalna forma prezentacji potrzeb, generalnie rozumianych tu jako potrzeby interesariuszy oraz zewnętrzne cechy systemu. Modele zachowania to typowe dla UML diagramy maszyny stanowej, aktywności i sekwencji.

Modele struktury w SysML mają jednak pewną specyfikę: to co w UML jest co najwyżej “dobrą praktyką modelowania” w SysML jest obligatoryjne: deklarowanie typów elementów systemu (metamodel systemu) przed ich użyciem, zaś określony system jest instancją tego metamodelu. Pierwszy do Block Definition Diagram, drugi to Internal Block Diagram. Model parametryczny budowany jest jako uzupełnienie drugiego.

Przykady:

Powyższy diagram to dziedzinowy metamodel systemu: deklarujemy tu z jakiego typu elementów będzie (jest) zbudowany system. Jest to drzewiasta struktura dekompozycji systemu oraz jednostki miary. Konkretny system, strukturę fizyczną systemu, modelujemy jako instancję tego metamodelu:

Powyższy model to specyfikacje instancji typów elementów (klas elementów) zadeklarowanych na Diagramie Definicji Bloków. Jeżeli chcemy wyrazić wielkości fizyczne opisujące system stosujemy Diagram Parametryczny:

Diagram parametryczny pozwala uruchomić symulację systemu.

Jak modelujemy firmy

W artykule Przeciążanie BPMN czyli jak nie modelować produkcji opisałem jak modelować część produkcyjnę fabryki. Tu przedstawię nieco bardziej szerszą perspektywę [zotpressInText item=”{5085975:L53UAHAG}”].

Typy elementów to klasy (rodzaje) komponentów, urządzeń:

Typy elementów (całych bloków) deklarujemy by planować ich przyszłe wykorzystanie ale także pozyskanie (zlecenie wykonania, zakup). Typowe bloki to: napędy, sterowniki, budowle, maszyny specjalistyczne itp. Jednym z wielu jest komputer. Przypominam, że komputer to: procesor, pamięć i program. Tak więc tam gdzie pojawia się “oprogramowanie” realnie będzie to komputer i jakiś styk z nim (człowiek lub np. cyfrowo-sterowane urządzenie).

Mając zadeklarowane typy elementów możemy przystąpić do świadomego projektowania (analizy i modelowania istniejącego) zakładu:

Takie podejście pozwala opisać całość systemu jakim jest np. zakład produkcyjny [zotpressInText item=”{5085975:WGVB6SZI},{5085975:MEPY6AUS}”]. Może on zawierać maszyny, urządzenia i systemy sterujące wielu dostawców, system ERP itp. Zrozumienie i zaprojektowanie całości oszczędza ogromne ilości czasu i pieniędzy: pozwala zaprojektować nie tylko określone aplikacje, ale zaplanować to które kupić jako COTS (ang. commercial off-the-shelf, gotowe oprogramowanie dostępne na rynku), które jako zlecić jako dedykowane, zaprojektować interfejsy i od razu wszystko ładnie uruchomić. Pozwala “oczyścić” nasze pomysły z wszelkich błędów niespójności, niekompletności rozwiązania. Usuwanie błędów na etapie projektowania jest to o kilka rzędów tańsze niż ich odkrywanie i usuwanie w toku wdrożeń.

Niezależnie od tego czy chcemy zaprojektować i zrozumieć zmywarkę, samolot, czy ubojnię (tak, analizowałem taką i dokumentowałem) zawsze mamy do czynienia z czymś więcej niż tylko komputer i aplikacje biznesowe. Teza, że wdrożenia systemów ERP to tylko oprogramowanie i wymaganie na nie było może prawdziwa kilka dekad temu, teraz ‘system’ to przedsiębiorstwo a nie raz kraj (system transportu krajowego, albo planowany KseF).

Tak więc zajmując się tylko “wymaganiami na oprogramowanie”, zajmujesz się pewna małą częścią większej całości, jaką jest organizacja. To zaś oznacza, że nie masz zrozumienia wpływu tego oprogramowania na tę całość, i jest bardzo prawdopodobne, że nieświadomie szkodzisz całej tej organizacji. Jeżeli zaś jakiś dostawca, jednego z typów tych systemów, nie znając tej organizacji, uważa że jego rozwiązanie jest dobre, to po prostu nie wie co mówi.

Posiadanie takiej dokumentacji to także wiedza dla przyszłych pracowników, a nie raz chronine know-how. Bardzo często komponenty tak projektowanych systemów trafiają później celowo do różnych podwykonawców, co zapobiega ryzyku przejęcia know-how (znajomości i zrozumienia całości systemu) przez potencjalną konkurencję.

Podsumowanie

Pojęcie mechanizm jest w powszechnym użyciu, jednak w analizie i nauce ma ono specyficzne znaczenie: to wyjaśnienie działania czegoś, to abstrakcja [zotpressInText item=”{5085975:LCAP9JJ4},{5085975:LKGQJ85W}”]. Z perspektywy zarówno organizacji jak i oprogramowania, postrzeganych jako systemy, pojawia się drugie pojęcie jakim jest “to z czego system się składa” (composition) [zotpressInText item=”{5085975:IWBHW8XL}”]. Mechanizm nigdy nie jest jednym elementem, jednak jako wyjaśnienie jest abstrakcją, czyli “ukrywa” (abstrachuje od) szczegóły: mechanizm, jako opis, jest idealizacją [zotpressInText item=”{5085975:LKGQJ85W}”].

Od wielu lat do opisu organizacji stosuje się poniższy, trójwarstwowy model:

Wierzchołek to strategia organizacji, jej rola w otoczeniu w jakim sie znajduje. Dolna, trzecia warstwa, to aktualny opis tej organizacji. Tu jest “wszystko to co istnieje” (zasoby i detaliczne procedury). Środkowa warstwa to właśnie MODEL DZIAŁANIA ORGANIZACJI, abstrakcyjny opis tego “co i po co” się dzieje a nie “jak i dlaczego”.

Chcąc zrozumieć, dlaczego organizacja tak a nie inaczej się zachowuje, musimy jej opis doprowadzić do takiego poziomu abstrakcji, by możliwe było skupienie się wyłącznie na mechaniźmie jej działania. Jest to możliwe jedynie traktując organizację jako system [zotpressInText item=”{5085975:EMPAJKU9},{5085975:6J8ZX2MR}”].

Czym są więc wymagania na oprogramowanie? To ta część mechanizmu działania organizacji, którą chcemy zacząć realizować jako działające oprogramowanie lub jego element. Wymagania na oprogramowanie to nie są cele użytkowników! Wymagania na oprogramowanie to mechanizm ich osiągania.

Czy można opisać przyszły system suchym opisem dotychczasowych faktów? Nie! Trzeba go zaprojektować czyli stworzyć coś czego nie było!

Gilotyna Hume’a – nazwa problemu sformułowanego przez szkockiego filozofa Davida Hume’a dotyczącego niemożności wnioskowania, co powinno być, na podstawie tego, co jest (ang. is-ought problem).

D. Hume, A Treatise of Human Nature, Oxford, Clarendon Press 1965 (reprint I wydania), s. 469

Bo sam opis stanu obecnego i wywiady z pracownikami nie stanowią sobą przyszłych rozwiązań.

Źródła

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