Wprowadzenie

Oprogramowanie na obecnym rynku, w ogromnej ilości, nadal stanowią produkty powstałe ponad dwie dekady temu (legacy systems). Znakomita większość powstawała ewolucyjnie. Lata 90-te to bardzo często monolity budowane w oparciu o EJB, JavaEE i nieco później Microsoft .NET. Są to wzorce powstała na bazie relacyjnego modelu danych i skryptów transakcyjnych.

“W anemicznym projekcie domeny logika biznesowa jest zwykle implementowana w oddzielnych klasach, które przekształcają stan obiektów domeny. Fowler nazywa takie zewnętrzne klasy skryptami transakcyjnymi. Ten wzorzec jest powszechnym podejściem w aplikacjach Java, wspieranym przez technologie takie jak wczesne wersje Entity Beans EJB, a także w aplikacjach .NET zgodnych z architekturą Three-Layered Services Application, gdzie takie obiekty należą do kategorii “Business Entities” (chociaż Business Entities mogą również zawierać zachowanie).” https://en.wikipedia.org/wiki/Anemic_domain_model

“Jest to jeden z tych anty-wzorców, który istnieje już od dłuższego czasu, ale wydaje się, że obecnie przeżywa szczególny rozkwit. Rozmawiałem na ten temat z Ericiem Evansem i obaj zauważyliśmy, że wydają się one być coraz bardziej popularne. Jako świetni zwolennicy właściwego modelu domeny, nie jest to dobra rzecz.” (M.Fowler) https://martinfowler.com/bliki/AnemicDomainModel.html
https://martinfowler.com/eaaCatalog/transactionScript.html

Z powyższych powodów nadal powstają diagramy jak ten poniżej:

W artykule Ten straszny diagram klas opisałem przyczyny, dla których jest to bardzo zły (anemiczny) model: powyższy diagram tak na prawdę nie jest dokumentacją działającego oprogramowania (o ile w ogóle ten diagram powstanie i ktoś go aktualizuje).

Od dłuższego czasu kolejne firmy zgłaszają podobny problem: mamy nieudokumentowaną aplikację a jej autorzy odchodzą na emerytury, czy można coś z tym zrobić?

Czym jest architektura aplikacji?

W artykule Architektura kodu aplikacji, opisywałem komponentowe i obiektowe wzorce projektowe. Komponentowo zorientowane oprogramowane ma standardowo cztery poziomy budowania architektury:

1. aplikacja zbudowana jest z komponentów,
2. komponenty zbudowane są z klas,
3. klasy zbudowane są z operacji,
4. operacja to nazwa procedury, zbudowanej z poleceń wyrażonych w określonym języku (metoda).

Graficznie można to zilustrować tak:

Na powyższym diagramie pokazano wymienione poziomy architektury. Oprogramowanie to kod, lista instrukcji dla procesora. Z perspektywy kodu (i kodera) są to setki i tysiące linii kodu, który stanowi sobą ciąg instrukcji dla procesora. Razem (procesor i kod w pamięci) stanowią komputer, który realizuje określony mechanizm [zotpressInText item=”{5085975:ZCXJ2S7U}”].

Jest to odpowiednik tak zwanego V-Modelu:

Problem w tym, że tego mechanizmu, jako całości, nie widać z perspektywy kodu. Dlatego zaprojektowanie oprogramowania realizującego złożone mechanizmy wymaga pracy od ogółu do szczegółu. Uzyskany efekt to setki procedur wyrażone w postaci kodu, ale przemyślane i przetestowane jeszcze przed pisaniem kodu, które to kodowanie jest najkosztowniejszą częścią w inżynierii oprogramowania [zotpressInText item=”{5085975:3T3PUJZL}”].

Problem w tym, że sam kod źródłowy to tekstowy opis. Proszę sobie wyobrazić tekstowy opis konstrukcji i zasady działania okrętu, samochodu czy nawet tylko zwykłej pralki. Na pewno można opisać prozą istniejącą obserwowaną działającą konstrukcję, ale raczej nie uda się jej bezbłędne zaprojektowanie w ten sposób za pierwszym razem. Zawsze bezie to kosztowne pasmo prób i błędów.

Dlatego: grupujemy procedury w klasy (operacja klas), klasy grupujemy w komponenty, całość testujemy na modelach (diagramy sekwencji). To wszystko jako całość, po wykonaniu implementacji, stanowi sobą działającą aplikację.

Mamy aplikację ale nie mamy jej dokumentacji

Kodowanie z pominięciem projektowania i jego skutki opisywałem nie raz. A jeżeli aplikacja istnieje? Skoro istnieje i działa (bez wnikania ile kosztowało jej powstanie) to znaczy, że można ją opisać. Działający komputer to “czarna skrzynka”, w której wykonywane są procedury (oprogramowanie). Bez dokumentacji nie jesteśmy w stanie “odkryć” jej architektury, ale analizując wejścia i wyjścia (formularze, zrzuty ekranowe, wydruki), można podjąć próbę odtworzenia procedur [zotpressInText item=”{5085975:H5Z2U363}”].

Jak rozwiązać problem długu informacyjnego (patrz: Dług informacyjny)? Należy opisać mechanizm działania aplikacji abstrahując całkowicie od jej architektury, której niestety nie znamy a nakłady na jej odtworzenie na bazie analizy kodu (code review) były by wyższe niż napisanie całości od zera. Wiele aplikacji jest niestety słabo napisana, ich kod jest trudny do zrozumienia (What is Bad Code?), więc taka analiza kodu najczęściej nie ma uzasadnienia ekonomicznego. Nie ma też żadnego sensu tworzenie diagramów klas takich jak ten na początku tego artykułu.

Bardzo często słyszę, że analityk nie ma wpływu na architekturę modelu dziedziny, bo robi to deweloper, i niestety często jest to prawdą. Analogiczny problem:

Jak zaprojektować (opisać) system nie mając wpływu na architekturę?

Jak w UML dokumentować model systemu, którego budowy nie znamy?

Patrząc na wcześniej przytoczony diagram opisujący poziomy abstrakcji architektury, pomijamy dwie środkowe warstwy: HLD i LLD. Wtedy zostają nam do udokumentowania: przypadki użycia i ich scenariusze oraz procedury.

W efekcie tworzymy:

1. diagram Przypadków Użycia (PU) reprezentujący komu i do czego ta aplikacja służy (co ma powstać, czego aktor oczekuje jako efekt),
2. dla każdego PU:
   • przyporządkowujemy formularz/dokument (szablon ekranu, graficzna forma, zalecana forma to diagram struktur złożonych UML),
   • dokumentujemy dialog (scenariusz) aktor-system w postaci listy wypunktowanej (to także test odbiorczy),
   • każdy scenariusz odwzorowujemy na diagramie aktywności jako łańcuch procedur:
     • każdą procedurę dokumentujemy na osobnym diagramie UML,
     • jest możliwe, że procedury te będą wielokrotnie wykorzystywane w różnych scenariuszach różnych przypadków użycia.

W repozytorium narzędzia CASE powstaje hierarchia diagramów:
– Diagram Przypadków Użycia
— scenariusz PU 1 (łańcuch procedur)
— procedura 1 (kroki procedury, algorytmy)
— procedura 2 (kroki procedury, algorytmy)
— procedura 3 (kroki procedury, algorytmy)
— scenariusz PU 2(łańcuch procedur)
— procedura 3(kroki procedury, algorytmy)
— procedura 4 (kroki procedury, algorytmy)
— procedura 5 (kroki procedury, algorytmy)
— scenariusz PU 3 (łańcuch procedur)
— procedura 6 (kroki procedury, algorytmy)
— procedura 7 (kroki procedury, algorytmy)
— procedura 8 (kroki procedury, algorytmy)

Możliwe jest reużywanie procedur (dlatego maja unikalne nazwy). Mona je grupowa osobno (stos procedur) i wywoływać niezależnie ze scenariuszy PU. Taki model nie zawiera diagramów klas (wyjątkiem jest diagram struktur złożonych jako model formularza/komunikatu), komponentów, sekwencji.

Przykład

Co do zasady Diagram Przypadków Użycia to zakres projektu.

UseCases są sposobem na uchwycenie wymagań systemów, tj. tego, co systemy mają robić. Kluczowymi pojęciami
w tym rozdziale są aktorzy, UseCases i przedmiot modelowania (system). Kontekstem każdego UseCase jest rozważany system, do którego, do którego odnosi się UseCase. Użytkownicy i wszelkie inne systemy, które mogą wchodzić w interakcje z systemem, są reprezentowane jako aktor. [zotpressInText item=”{5085975:DCYU6XZJ}”]

Poniżej prosty model: zakres projektu “System Fakturowanie Zamówień”.

Przypadek użycia Faktury ma tu następujący scenariusz:

Na tym poziomie tworzymy Diagramy Aktywności:

Aktywności mogą opisywać obliczenia proceduralne, tworząc hierarchie działań wywołujących inne działania lub, w modelu obiektowym, mogą być wywoływane pośrednio jako metody związane z operacjami, które są bezpośrednio wywoływane. […]
Aktywności mogą być również wykorzystywane do modelowania systemów informatycznych w celu określenia procesów na poziomie systemu. [zotpressInText item=”{5085975:DCYU6XZJ}”]

Diagram Aktywności reprezentujący powyższy scenariusz:

Na diagramie pozostawiono numery linii ze scenariusza opisanego tekstem, dla ułatwienia porównania ich ze sobą. Powyższe to pierwszy poziom modelowania mechanizmu działania systemu. Czynność “2. SYSTEM wyświetla Formularz Lista Zamówień został oznaczony symbolem “grabie” (prawy dolny róg). Podobnie jak 4. SYSTEM wyświetla wstępnie wypełniony Formularz Faktura. Oznacza to, że istnieje detaliczny opis tego zadania. Wygląda on tak:

oraz

Dokładny opis tworzenia powyższych konstrukcji zawiera rozdz. 16 spec. UML:

Pozostaje udokumentowanie elementów “Object Node” (prostokąty reprezentujące formularze i komunikaty). Najwygodniej w narzędziu CASE użyć do tego Diagramu Struktur Złożonych notacji UML, gdyż pozwala to na pełną kontrolę spójności modeli:

Oba powyższe formularze (komunikaty) mają wczesną formę, są ogólne i zawierają obszary danych. W toku projektu są one doprowadzane do postaci detalicznie opisującej treść tych dokumentów i ich walidacje.

Przykład tworzenia nowego zamówienia:

Podsumowanie

Jako ludzie używamy komputerów (ogólnie różnych urządzeń, komputer jest jednym z nich) a nie oprogramowania. Komputer to procesor, pamięć i program [zotpressInText item=”{5085975:ZCXJ2S7U}”]. Oprogramowanie to skrypty konfigurujące zachowanie się tego urządzenia jakim jest komputer. Każda aplikacja jest reprezentowana w postaci kodu (maszynowego), który powstaje z pomocą (za pośrednictwem) języków programowania wysokiego poziomu (Pyton, Java, C, PHP, itp.). Ten kod to procedury.

Proste rozwiązania to kilkanaście do kilkudziesięciu procedur, które mieszczą sie na kilkunastu stronach wydruku. Jednak większe systemy to setki powiązanych ze sobą procedur. Zapamiętanie i zrozumienie ich wzajemnych powiązań jest dla człowieka praktycznie niemożliwe, dlatego już w latach 80-tych powstały koncepcje podziału dużych systemów na moduły, a późnej w latach 90-tych, na komponenty [zotpressInText item=”{5085975:3T3PUJZL}”]. Moduł to tematycznie powiązane procedury, które nadal stanowią sobą jedną całość (monolit).

Komponent to wydzielona, odseparowana od reszty ich grupa procedur, stanowiąca sobą odrębną zamkniętą całość [zotpressInText item=”{5085975:HPRRUHDL},{5085975:NSJBENX9}”]. Tak budowane są systemy zorientowane obiektowo (komponent to także obiekt). Tu przypomnę, że tak zwany paradygmat obiektowy to “hermetyczne komponenty i komunikacja między nimi” a nie “dziedziczenie i łączenie funkcji i danych w obiekty” (polecam referat: Object Oriented Programming vs Functional Programming).

Odpowiedź na tytułowe pytanie: Jak udokumentować monolit, brzmi: przeanalizować jego działanie na podstawie danych (dokumentów) wprowadzanych oraz danych (dokumentów) jakie on tworzy, i udokumentować wyniki tej analizy tak jak pokazano powyżej. Na pewno się okaże, że jest to duży i skomplikowany system, więc już na etapie analizy, od początku jej prowadzenia, grupujemy dokumenty i procedury na tematyczne grupy (moduły). Jeżeli zapadnie decyzja o wykonaniu tego systemu jeszcze raz, projektujemy jego architekturę HLD, i prowadzony projekt metodami obiektowymi (nie mylić z dziedziczeniem i łączeniem danych i funkcji w obiekty), bo to podejście pozwala “opanować” złożoność takiego systemu a projekt architektury grupujący wszystkie procedury w komponentu i klasy, stanowi doskonała dokumentację całości [zotpressInText item=”{5085975:64KN4B9L}”].

Polecam artykuł Jak wyjść z długu technologicznego jakim jest centralny monolityczny system, jako kontynuacje tego tekstu.

Źródła

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

Wprowadzenie

Zanim napiszę dlaczego prawnik to świetny analityk biznesowy, opiszę problem jaki jest do rozwiązania. O prawniku będzie w drugiej części.

Od ponad 20 lat prowadzę analizy biznesowe, projektuję informatyczne systemy przetwarzania danych, zarządzające przepływem informacji. Obserwuję stały postęp narzędzi oraz rozwój metod prowadzenia analiz, ale także brak (ale nie w 100%) postępu w uzyskiwanych efektach [zotpressInText item=”{5085975:D7P3QCSP}”]:

Czemu tak sie dzieje? Metody realizowania projektów przez większość dostawców IT nie zmieniły sie od 30 lat: rozmowy, wywiady, kodowanie, kosztowne narzędzia (C++, Java). Od 20 lat wiemy, że napisanie programu w C++/Java to dwukrotnie większa pracochłonność w porównaniu do identycznego efektu uzyskanego językami skryptowymi [zotpressInText item=”{5085975:34FM6E6Z},{5085975:HJESQZTY}”]. Stała popularność C++/Java ma swoje źródło: większość dużych systemów w branży fin/tech powstała w latach 90-tych, nie są unowocześniane a jedynie uzupełniane są o kolejne funkcjonalności mimo, że nie jest tajemnicą jak dokonać migracji do nowszych techniologii i architektur [zotpressInText item=”{5085975:GLLQAIV8}”].

Powody są dość prozaiczne: dopóki jest popyt, dostawcy technologii nie mają żadnego interesu w unowocześnianiu swoich produktów i sprzedają permanentny dług technologiczny [zotpressInText item=”{5085975:J24HY9A9}”].

Skąd się u wielu użytkowników technologii IT bierze dług technologiczny już w momencie podpisania umowy na wdrożenie? Stąd, że zlecono analizę przedwdrożeniową wymagań dostawcy technologii, a w jego interesie jest dostarczyć to co ma, a nie to czego potrzebuje klient.

(https://it-consulting.pl/2011/11/20/czego-najwieksze-firmy-technologiczne-nie-mowia-swoim-klientom/)

Dlatego nadal mówi się i pisze, by nie powierzać dostawcom technologii prac nad analizami wymagań i zarządzania wdrożeniami:

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

(https://www.techradar.com/news/what-hertz-v-accenture-teaches-us-about-failure-in-systems-development-projects)

Tak więc pozostaje zrobić to samemu, ale jak? Wiemy też na pewno, że nie jest dobrym pomysłem przeprowadzenie wewnętrznych warsztatów z pracownikami i samodzielne spisanie “wymagań”, gdyż tak powstają najbardziej niespójne i niekompletne opisy wymagań [zotpressInText item=”{5085975:LXK8VA68}”]. Więc jak?

Ideałem jest zaangażowanie zewnętrznego analityka projektanta, z zastrzeżeniem że nie może on być dostawcą systemu. Jest to metoda znana od lat, ale nadal rzadko stosowana z uwagi na to, że “mało kto tak robi”, oraz z powodu powszechnego przekonania, że “dostawca ma lepszego analityka i projektanta” (mimo, że teza taka nie ma żadnego uzasadnienia w faktach [zotpressInText item=”{5085975:D2Z2R2DG}”]). Powodem jest także to, że zaufanie do osób z zewnątrz w wielu firmach jest bardzo małe, co powoduje, że nie każdy zarząd decyduje się na taką współpracę.

Orientacja na artefakty

Jak już wspomniano wywiady z pracownikami dają jako produkt niespójny i niekompletny opis organizacji. Dlatego od wielu lat mówi się, że organizacje doskonale opisują artefakty jakie ona ona wytwarza i to na ich podstawie, a nie na podstawie wywiadów, należy prowadzić analizy i projektować systemy. Czym są te artefakty?

Artefakt to konkretny, możliwy do zidentyfikowania, samoopisujący się fragment informacji, który może być wykorzystany przez osobę prowadzącą działalność gospodarczą do jej prowadzenia. Czasami określamy artefakty jako dokumentację biznesową, a niektórzy ludzie biznesu wydają się preferować tę terminologię. Aby artefakty były przydatne do rzeczywistego prowadzenia biznesu, w przeciwieństwie do abstrakcyjnego modelu do analizy, muszą być rozpoznawalne; to znaczy, muszą zawierać informacje w jednym miejscu. Wszyscy słyszeliśmy zwykłe stwierdzenie frustracji: “Ale ja nie mam tu wszystkich potrzebnych informacji”. Wymagania dotyczące bycia wrażliwym na potrzeby biznesu i samoopisującym się są napędzane bardzo mocno z perspektywy poznawczej właściciela biznesu. Artefakty są traktowane jako jedyna jawna informacja zawarta w biznesie; to znaczy, że jest to zbiór zapisów biznesowych reprezentujących zawartość informacyjną biznesu.

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

Innymi słowy: artefakty to dokumenty operacyjne i ich treść, przetwarzane i wytwarzane w toku funkcjonowania organizacji, oraz wszelkie ślady i skutki tego przetwarzania.

Podejście skoncentrowane na artefaktach biznesowych traktuje dane jako integralną część procesów biznesowych, a procesy biznesowe i ich operacje definiuje w kategoriach współdziałających kluczowych artefaktów biznesowych (BA, business artifact). Każdy typ BA jest charakteryzowany przez model informacyjny i model cyklu życia. Model informacyjny rejestruje wszystkie istotne z punktu widzenia biznesu informacje o instancji BA w miarę jej przemieszczania się w przedsiębiorstwie. Cykl życia określa wszystkie możliwe ewolucje instancji BA w czasie. Jako przykład BA, rozważmy bank CheckingAccount, który rejestruje wszystkie informacje o koncie od momentu jego otwarcia przez klienta do momentu jego ostatecznego zamknięcia i zarchiwizowania, z cyklem życia rejestrującym wszystkie istotne stany konta, możliwe przejścia, operacje, itp.

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

Metody analizy i projektowania oparte na artefaktach są także w literaturze opisywane jako evidence-based system engineering [zotpressInText item=”{5085975:MG2IRJC4}”].

Klasyczna metoda prowadzenia analizy nadal w cenie i nie raz już tu była opisana, a czy jest jakaś alternatywa? Tak! Jest światełko w tunelu!

Prawnik jako analityk

Tak! Od kilku lat eksperymentuję z Regulaminami (regulaminy sprzedaży, świadczenia usług, itp.) jako podstawowymi źródłami potrzeb biznesowych. I okazuje się, że bardzo często stanowią one prawie doskonałą specyfikację potrzeb, na podstawie której można nie raz zaprojektować nawet 80-90% całości systemu! Owszem bywają niespójne regulaminy, ale to się zdarza bardzo rzadko. Najczęściej opracowanie takiego regulaminu zleca się prawnikom, a Ci bardzo skrupulatnie analizują wszelkie obowiązki i ryzyka na każdym etapie realizacji obsługi klientów czy też realizacji zadań wewnętrznych (poza regulaminami obsługi klientów mamy też różne regulaminy wewnętrzne).

W efekcie zamiast pracować z niespójna i pełną sprzeczności (typowe efekty warsztatów i burz mózgów) listą życzeń pracowników organizacji, znaczenie efektywniej pracuje się z Regulaminem. Jeżeli ma powstać sklep internetowy będzie to np. Regulamin Sklepu Internetowego, jeżeli ma postać system CRM doskonały materiałem będzie wewnętrzny Regulamin Obsługi Klienta. Jeżeli ma powstać system zarządzania przepływem faktur kosztowych należy zacząć prace od opracowania Regulaminu Przepływu Faktur Kosztowych (tu raczej dział księgowości będzie wiódł prym).

Przyjęcie założenia, że na podstawie regulaminów można zaprojektować oprogramowanie jest sprawdzone, warunkiem jest: (1) zakres projektu to obszar opisany tymi regulaminami, (2) zakres projektu to obszar administracyjny (obsługa zapytań i zamówień to też ten obszar, nie przypadkiem zwany nie raz back-office), (3) regulaminy nie odnoszą się do (nie zawierają w treści) nazw i cech narzędzi i oprogramowania a jedynie do czynności, reguł ich wykonania i wzorów dokumentów. Ten ostatni warunek jest najważniejszy i niestety często nie jest spełniony, w toku analizy staje rekomendacją do zmiany.

Dwa alternatywne warianty:

Wariant 1 to standardowe podejście: decyzja o projekcie i planowanie i analiza biznesowa. Na podstawie wyników analizy biznesowej i rekomendacji prawnicy (Organizacja analizowana) opracowują Regulamin (usługi, portalu itp.), całość stanowi sobą wymagania i projektowany jest docelowy system. Tu opracowanie Regulaminu polega na wykorzystaniu wyników analizy biznesowej.

Wariant 2 to rzadsze podejście, polegające na wykorzystaniu wcześniej wykonanej pracy nad opracowaniem Regulaminu. To sytuacja w której taki wypracowany Regulamin już istnieje, albo – do czego nie raz zachęcam moich klientów – Regulamin jest opracowany celowo jako element przygotowania materiałów do analizy. Dość często w organizacji jest dział prawny lub ma ona stałą obsługę prawną. Są to osoby znające firmę, i praktyka pokazuje, że mają duża wiedzę o swoim kliencie. Mają też tę zaletę nie są to emocjonalnie związani z firmą jej menedżerowie. Prosze nie zapominać, że pracownicy firmy zaangażowani w proces zbierania wymagań na przyszły system informatyczny są emocjonalnie związani ze swoim obecnym stanowiskiem i dotychczasowym stylem pracy, mają więc pewien konflikt interesu i nie zawsze są obiektywni. Czy to ich zła wola? Nie, to emocje które są ryzykiem projektu, a nie złą wolą tych ludzi.

Podsumowanie

Ścisła współpraca z działem prawnym firmy analizowanej potrafi przynieść duże korzyści. Bardzo często są to ludzie dobrze znający firmę, obyci w opracowywaniu zasad świadczenia usług, reguł postępowania. Regulaminy to dokumenty na dość wysokim poziomie formalizacji, co bardzo pomaga w pracy z nimi. Projektowanie na ich podstawie logiki biznesowej systemu informatycznego jest znacznie łatwiejsze niż na podstawie opisów przygotowanych przez tak zwany “biznes”.

Od kilku lat testuję tę metodę projektowania systemów, w ww. obszarach sprawdza się bardzo dobrze. W czasie prowadzenia zajęć laboratoryjnych ze studentami na kierunku Inżynieria Oprogramowania uczą się oni wychwytywania w Regulaminach sformułowań, które stanowią materiał na słownik pojęć i reguły biznesowe, na aktorów i nie raz nawet na moduły aplikacji. Są to metody oparte na ontologicznych analizach tekstowych [zotpressInText item=”{5085975:2JAV96GM}”]. W połączeniu z metodami opisu reguł biznesowych z użyciem tablic decyzyjnych, stanowią bardzo dobre narzędzie do pracy nad artefaktami jakimi są teksty biznesowe, a regulaminy do takich należą [zotpressInText item=”{5085975:K6WH5VWQ}”].

Przykładowe projekt i analiza na podstawie Regulaminu

Poniżej do pobrania dwa pliki pdf, opracowania wykonane w całości tylko na podstawie Regulaminu.”

[wpdm_package id=’37614′]

Drugi to wynik analizy Regulaminu i rekomendacje do poprawy jego jakości:

[wpdm_package id=’33833′]

Źródła

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

Organizacje to wielkie mechanizmy, złożone z funkcjonalnych bloków (komórki organizacyjne), te z mniejszych elementów, a te zaś wymagają zasobów: są nimi ludzie i narzędzia jakich używają, nawet te w pełni zautomatyzowane. Koszt systemów komputerowych to w 2020 roku ok. 8% przychodów firm (ok. 10% w branży finansowej). Udział ten stale rośnie, a to oznacza, że jakość tych systemów ma stale rosnący wpływ na marże i konkurencyjność firm (https://www.flexera.com/blog/technology-value-optimization/it-spending-by-industry/).

Wprowadzenie

Trzy lata temu pisałem o projektowaniu urządzeń zawierających bloki funkcjonalne realizowane przez komputer. Komputery coraz częściej (tam gdzie to tylko możliwe) zastępują swoje mechaniczne funkcjonalne odpowiedniki, zgodnie z tezą “komputer to uniwersalny mechanizm” [zotpressInText item=”{5085975:ZCXJ2S7U}”]. Poniżej publikowany wcześniej uproszczony schemat blokowy pralki. Elementy zaznaczone kolorem pomarańczowym zostały zastąpione komputerem (komputer to: procesor, pamięć, program).

Niedawno opisywałem systemowe podejście do całych organizacji pokazując ich model (tu jeden dział pionu produkcji) w duchu MBSE [zotpressInText item=”{5085975:RA6YBH48}”]:

Artykuł powyższy kończyłem słowami:

Czym są więc wyma­ga­nia na opro­gra­mo­wa­nie? To ta część mecha­ni­zmu dzia­ła­nia orga­ni­za­cji, któ­rą chce­my zacząć reali­zo­wać jako dzia­ła­ją­ce opro­gra­mo­wa­nie lub jego ele­ment. Wymagania na opro­gra­mo­wa­nie to nie są cele użyt­kow­ni­ków! Wymagania na opro­gra­mo­wa­nie to mecha­nizm ich osiągania.

źr.: Modelowanie systemów – organizacja jako mechanizm – Jarosław Żeliński IT-Consulting

Oprogramowanie “w czymś” czyli embedded software

Pod pojęciem “oprogramowanie wbudowane” (ang. embedded software) rozumiemy:

Oprogramowanie wbudowane to oprogramowanie, które nie jest bezpośrednio widoczne lub wywoływane przez ludzkiego użytkownika, ale jest częścią systemu. Na przykład oprogramowanie osadzone jest w telewizorach, samolotach i grach wideo. Oprogramowanie wbudowane jest używane do sterowania funkcjami urządzeń sprzętowych.

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

Autor zwraca uwagę, że jest to “oprogramowanie wbudowane to oprogramowanie, które nie jest bezpośrednio widoczne lub wywoływane przez ludzkiego użytkownika” jednak w drugiej części zdania generalizuje, że to oprogramowanie, które “jest częścią systemu”. W streszczeniu pisze:

Nauka o obliczeniach systematycznie abstrahowała od świata fizycznego. Systemy oprogramowania wbudowanego, jednakże, angażują świat fizyczny. […] Obowiązujące abstrakcje systemów obliczeniowych pomijają “niefunkcjonalne” aspekty. [wyjaśniamy] dlaczego oprogramowanie wbudowane nie jest tylko oprogramowaniem na małe komputery i dlaczego potrzebuje fundamentalnie nowego spojrzenia […]. [autor] Proponuje architektury komponentów oparte na zasadzie zwanej “projektowaniem zorientowanym na aktora” […]. Następnie sugeruje, że aktorzy mogą definiować interfejsy, które deklarują dynamiczne aspekty, które są istotne dla oprogramowania wbudowanego […]. Te interfejsy mogą być zorganizowane w “system”, który wspiera rodzaj sprawdzania w czasie projektowania i w czasie działania, z którego korzysta konwencjonalne oprogramowanie.

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

Tu już widać ogólniejsze, i zorientowane na użytkownika, podejście bardziej “holistyczne”. Najczęściej nadal jednak pod pojęciem oprogramowanie wbudowane uznajemy, że “Oprogramowanie wbudowane jest używane do sterowania funkcjami urządzeń sprzętowych.” co oczywiście jest prawdą.

Rosnący udział oprogramowania w urządzeniach pokazano na poniższym wykresie:

Jak widać funkcje realizowane przez oprogramowanie stanowią co najmniej 80% całości kosztów. Tu autorzy badali co prawda roboty przemysłowe, jednak jak już wspomniano oprogramowanie wbudowane jest także “osadzone jest w telewizorach, samolotach i grach wideo” [zotpressInText item=”{5085975:TZ4JHR35}”]. Wystarczy spojrzeć na smartfon, który jako telefon, był kiedyś w 100% urządzeniem elektromechanicznym, później elektronicznym, obecnie jest to system składający się z urządzeń peryferyjnych (nadajnik, odbiornik, głośnik, ekran video, zasilacz) [zotpressInText item=”{5085975:I7N5YSN4}”]. Trend nie jest taki nowy [zotpressInText item=”{5085975:2JAV96GM}”]. Więcej [zotpressInText item=”{5085975:NLT4Z5MI}”].

Robert C. Martin, w swojej książce Czysta Architektura [zotpressInText item=”{5085975:PUGG63YC}”], wskazuje na konieczność projektowania oprogramowania w taki sam sposób jak urządzenia i firmy, którego jest ono częścią (patrz rozdz. 29: Clean Embedded Architecture).

Oprogramowanie w organizacji

Do napisania tego artykułu skłonił mnie wpis “Software ? the Elephant in the MBSE Living Room” Douga Rosenberga (tak, to między innymi ten od ICONIX) [zotpressInText item=”{5085975:Y3KLU3JX}”]. “Słoń w pokoju” to popularny w j. angielskim idiom oznaczający

?? ważny lub ogromny temat, pytanie lub kontrowersyjna kwestia, o której wszyscy wiedzą, ale nikt o niej nie wspomina lub nie chce o niej rozmawiać, ponieważ sprawia, że przynajmniej niektórzy z nich czują się niekomfortowo ??

https://dictionary.cambridge.org/dictionary/english/elephant-in-the-room

W naszym języku popularnie mówi się “temat tabu” lub, zależnie od kontekstu, “temat zamiatany pod dywan”. Takim tematem jest oprogramowanie jako część czegoś większego. Dlaczego to taki temat tabu? Moim zdaniem dlatego, że od dekad wmawiano nam, że oprogramowanie (inżynieria oprogramowania) rządzi sie jakimiś innymi prawami niż “klasyczne inżynierie”. Mamy rok 2023 i okazuje, że raczej nie, i okazuje się że dowodem jest to, że oprogramowanie zawsze jest częścią czegoś większego, a ta większa część to nic innego jak produkt “tradycyjnej inżynierii”. Skoro więc pralka, telefon, telewizor czy samolot powstają w cyklu: wymagania, projekt, testy, prototyp, produkcja, to znaczy, że rygor ten dotyczy także każdej części składowej: komputera z jego oprogramowaniem także. Trudno będzie przekonać np. producenta samolotów, że Auto Pilot (obecnie komputer), będzie powstał z pominięciem któregokolwiek z tych etapów.

Takim nadrzędnym bytem dla oprogramowania jest także każda firma, urząd itp. Nigdzie oprogramowanie nie jest samodzielnym wolnostojącymi bytem, organizację inwestują w “oprogramowanie wspomagające zarządzanie”. Innymi słowy, każdy system informatyczny to coś co zastępuje urządzenie (jego fragment) lub w człowieka, w pracach możliwych do opisania (model) określonym mechanizmem.

Wbrew temu co wielu ludzi pisze, organziacje sa i będa silosami z prostego powodu: i ekonomia i organizacje, i urządzenia, i ludzie są zorganizowane zasobowo. Patrząc na to: organizacje budują ekonomię, a ludzie i ich narzędzia budują organizacje. Więc gdzie są te mityczne procesy? To nic innego ja spojrzenie na silosy z perspektywy tego, co i w jakiej kolejności powstaje wewnątrz organizacji. Każdy elementarny proces biznesowy to nic innego jak produkt wytworzony z pomocą określonego zasobu: ludzi i ich narzędzi. To dlatego każdy system modelowany z użyciem notacji UML/SysML, jest modelowany z perspektywy swojej wewnętrznej struktury (architektura systemu) oraz z perspektywy zachowań siebie i swoim komponentów.

Poniżej, bardzo dobrze znany diagram opisujący wewnętrzny łańcuch wartości: kluczowe procesy biznesowe i zasoby w firmie.

Warto tu zwrócić uwagę na to, że wyraźnie oddzielono część operacyjną od części zabezpieczającej zasoby. Warto także zwrócić uwagę że to silosy. Modelując np. firmę skorzystamy z poniższego jej metamodelu: każda firma podzielona jest (składa się z) na komórki organizacyjne, te zaś grupują ludzi i ich narzędzia (zasoby):

Mając zdefiniowane typy bloków systemu jakim jest firma, można zbudowac jej model:

Na powyższym modelu pokazano kluczowe bloki funkcjonalne czyli komórki organizacyjne. Pełny model tej firmy byłby bogatszy, jednak byłaby to hierarchia kilku czytelnych diagramów. Tak zobrazowane przepływy pokazują mechanizm działania firmy jako systemu. Na kolejnych modelach, od ogółu do szczegółu, można pokazać nawet poszczególne stanowiska produkcyjne (tak zwane cele). Na innych modelach, w tej samej notacji ale z innej perspektywy, można pokazać strukturę produktów do modelowania BOM. Te modele to nie są modele procesów biznesowych, to modele organizacji z perspektywy mechanizmu jej działania. Pamiętajmy, że model np. samochodu czy nawet całej ich floty, nie jest modelem korporacji taksówkowej.

A gdzie procesy biznesowe? Osobno, na kolejny kilku prostych modelach BPMN przepływ pracy rozumiany jako odbierane, tworzone i wysyłane dokumenty. A wszystko to powiązane “śladowaniem” czyli macierzami pokazującymi związki zasobów z procesami, dokumentami itp. Pamietajmy, że np. na produkcji fizycznie przemieszczają określone np. dobra konsumpcyjne a zupełnie osobne dowody księgowe (dokumenty) opisujące gdzie i do czego doszło. Nie da sie na jednym diagraie (typie diagramu) pokazać na raz wszystkiego.

Bardzo ważne jest dobieranie właściwych metod i narzędzie modelowania (notacja, paradygmat) do celu jaki chcemy zrealizować w toku przygotowania do wdrożenia. Tam gdzie mamy do czynienia z dokumentami tworzymy analityczne modele z użyciem notacji BPMN (np. obszar finansów, sprzedaży, itp.). Tam gdzie mamy do czynienia z projektowaniem produktów CAD/CAM ich produkcją (dowolny poziom) stosujemy modele systemowe MBSE i notacje SysML (np. systemy MES, PLM, tu warto znać podstawy normy ISA-95). Tam gdzie chcemy modelować blok będący komputerem wraz z oprogramowaniem (wymagania na oprogramowanie), stosujemy UML [zotpressInText item=”{5085975:WCZIC2ZZ},{5085975:8G9TUWIG}”].

Poniżej poglądowy schemat tych zależności:

A gdzie gdzie jest słoń?

Popatrzmy na kolejny poniższy diagram:

Nasz słoń jest tu zasobem: to komputer i oprogramowanie. Systemy IT to integralna część organizacji: to nasze “oprogramowanie wbudowane” w nią. Każdy podsystem np. FK, workflow, WMS czy MES, to takie właśnie “embedded systems” firmy, i nie ma żadnego uzasadnienia do traktowanie tych systemów inaczej niż pozostałych zasobów. Innymi słowy: nie należy patrzeć na oprogramowanie ERP jak na “coś innego”, oprogramowanie jest integralną częścią nadrzędnego bytu jakim jest organizacja.

Podsumowanie

Powoli kończy się era “świętych krów” inżynierii. Inżynieria oprogramowania, po prawie 20 latach “zwinnego” podejścia do tej gałęzi inżynierii, zaczyna dojrzewać do bycia “prawdziwą inżynieria” z analizami, projektowaniem i testowaniem na “desce kreślarskiej”, jaką są systemy CASE i podejście MBSE, jakimi stanowią uniwersalne systemowe podejście do multidyscyplinarnej inżynierii (mechatromnika) [zotpressInText item=”{5085975:Y3KLU3JX}”].

Organizacje to też systemy i ich inżynieria: mamy inżynierię procesów biznesowych, inżynierię zasobów, inżynierie finansową. Organizacje to systemy i tak należy je traktować i modelować [zotpressInText item=”{5085975:NHWMP6KJ}”]. Koszty utrzymania i rozwoju systemów IT to już ponad 8% przychodów firmy i wartość ta powoli ale nadal stale rośnie. Rośnie także dyscyplina ich tworzenia, wdrażania i zarządzania ich kosztami.

Z perspektywy organizacji i rynku, oprogramowanie wbudowane to jest to oprogramowanie, którego używa się wewnątrz firmy ale którego nie widzą, nie mają z nim kontaktu, klienci tej firmy.

Żródla

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