Wprowadzenie

Wśród wielu stron WWW jest także ta: Modeling Languages (źródło poniżej). Tym razem autorka w tekście “On comparing modelling languages”, porównuje kilka wybranych, jak je nazwała, “języków modelowania”. Autorka nazywa modelem urządzenia diagramy map myśli i modele pojęciowe, co jest moim zdaniem złym podejściem. Teza, że ontologia to projekt oprogramowania też nie wytrzymuje prostych testów.

Modelowanie

Najpierw sprawdźmy co oznaczają w literaturze pojęcia model i modelowanie:

modelować coś, aby stworzyć kopię lub opis działania, sytuacji itp., aby móc je przeanalizować przed przystąpieniem do prawdziwego działania.

https://www.oxfordlearnersdictionaries.com/definition/english/model_2?q=modeling

W poprzednim artykule na powiązany temat pisałem:

Graficznie ten model poję­cio­wy mozna zobra­zo­wać jako diagram: Pojęcia: dia­gram, model i mecha­nizm oraz regu­lu­ją­ce je obsza­ry pra­wa (opr. wła­sne autora)

żr.: Mechanizm działania vs model systemu vs diagram – Jarosław Żeliński IT-Consulting

W komentowanym tekście skupię się na poniższej grafice:

Figure 1. Two example diagrams about espresso machines: a mind map and a conceptual data model. If you have no idea about what or how to compare yet: before reading about the comparisons, can you describe differences between these two examples?

Source: On comparing models

Jak zawsze, warto uporządkować znaczenie pojęć używanych w opracowaniu:

konceptualizacja: stworzyć w umyśle wyobrażenie o czymś
koncepcja: idea lub zasada związana z czymś abstrakcyjnym
pojęcie: słowo lub wyrażenie używane jako nazwa czegoś, zwłaszcza związane z określonym typem języka
model pojęciowy (the conceptual model): jest reprezentacją systemu, zjawiska lub problemu, który pokazuje kluczowe pojęcia, zmienne, relacje i założenia. Może być wyrażony za pomocą słów, diagramów lub innych form i pomaga kierować pytaniami badawczymi, hipotezami, metodami i analizą
ontologia: lista pojęć i kategorii w obszarze tematycznym, która pokazuje relacje między nimi

na podstawie https://www.oxfordlearnersdictionaries.com/

Jak widać, model pojęciowy to sposób wyrażenia ontologii. To bardzo ważne w tym, i nie tylko tym tekście.

Poniżej tak zwana mapa myśli, często stosowane narzędzie do notowania wyników burz mózgów

Powyższy diagram nic nie mówi o tym jak działa to urządzenie i jak je skonstruować.

Automatyczny ekspres do kawy

Realnie taki express wygląda tak:

Schemat blokowy opisujący działanie ekspresu do kawy:

Elementy z jakich zbudowany jest zaparzacz kawy:

Powyższe to jedno zdjęcie i dwa diagramy. Zdjęcie obrazuje realne urządzenie. Schematy pokazują odpowiednio: mechanizm działania oraz części składowe realnego urządzenia.

Prosze zwrócić uwagę, że każdy z tych obrazów ma inny cel. Każda z tych grafik, jako określona forma wyrażenia pewnej treści, to przedmiot prawa autorskiego. Mechanizm działania, wyrażony jako model, z pomocą diagramu jak wyżej, może być np. przedmiotem patentu, jednak hipotetyczny wniosek patentowy nie mógłby zawierać ani zdjęcia ani listy elementów określonej konstrukcji (wcielenie wynalazku w życie). Musiał by zawierać opis mechanizmu działania wyrażony np. w postaci jak powyżej [zotpressInText item=”{5085975:Y86V5TMQ}”].

To co nazwano “software design”

Czym jest powyższy model? Jeżeli, jak uważa autorka jet to “koncepcyjny model danych”, to spodziewam się atrybutów każdego z tych pojęć. Powyższy diagram nie opisuje tego co można zapisać w jakiejkolwiek bazie danych (związek zawierania sie generalizacja). Odtworzenie tej konstrukcji w kodzie z pomocą języka takiego jak C++/C# czy Java jest możliwe, o ile elementy na tym diagramie będą zawierały operacje pozwalające skorzystać z tej konstrukcji, pozostaje pytanie jak. Owszem jest to możliwe ale bardzo trudne i skomplikowane (prostym testem będzie próba narysowania diagramu sekwencji dla tej architektury), dlatego powyższy schemat, odtworzony w kodzie, nie będzie symulatorem takiego ekspresu, będzie bardzo kosztowną atrapą.

Model ekspresu

Przypomnijmy schemat:

Pytanie: który z powyższych diagramów opisuje (wyjaśnia) mechanizm działania ekspresu do kawy? Wygląda na to, że żaden. Więc jaki model powinien powstać?

Przyjętym w inżynierii systemów (MBSE) sposobem postępowania jest dwuetapowy proces:

1. definiowanie typów bloków funkcjonalnych: powstaje Block Definition Diagram,
2. oraz projektowanie wewnętrznej konstrukcji systemu (tu urządzania), powstaje Internal Block Diagram

Poniżej oba te diagramy:

Diagram definicji bloków bywa nazywany metamodelem systemu na wzór diagramów klas w UML. Jednak w terminologii notacji SysML [zotpressInText item=”{5085975:E9MDNWLY}”] to pojęcie nie jest używane. Poniżej model urządzenia:

Po uzupełnieniu go diagramem aktywności byłby pełnym opisem mechanizmu jego działania. Jedynym miejscem, gdzie mógł by się tu pojawić komputer (i programowanie) jest moduł realizujący wybór receptury i jej wykonanie (sterowanie zaparzaczem).

Kończąc, przyznam, że nie wiem co autorka miała na myśli pisząc, że jej diagram to model danych…

Bibliografia

[zotpressInTextBib style=”apa” sortby=”author” 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”]

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

Nie używamy notacji BPMN do modelowania tego co się dzieje na produkcji. Skoro nie BPMN to czego używamy?

Wprowadzenie

Analityczne modele BPMN to łańcuchy aktywności reprezentujących procedury oraz ich produkty czyli dokumenty (dane). Na tych modelach aktywność to abstrakcja reprezentująca (całą) pracę, której efekt (wynik) jest prezentowany jako treść (DataObject), czyli aktywność kopania rowu kończy się pisemnych stwierdzeniem, że rów wykopano, z ewentualnym opisem parametrów tego rowu (patrz specyfikacja BPMN i definicja atomowej aktywności w procesach [zotpressInText item=”{5085975:QJUPRFNR}”]).

A gdzie dokładny opis machania łopatą albo obsługi koparki? Ten opis to procedura, instrukcja stanowiskowa lub instrukcja obsługi urządzenia (patrz Procesy a procedury).

Do modelowania produkcji używamy notacji SysML i korzystamy z tego, że znakomita większość dzisiejszego oprogramowania wspomagającego produkcję została zbudowana w oparciu o normę ANSI ISA-95. Struktura integracji w systemach tego typu wygląda tak:

Niedawno cytowałem:

SLIM (Systems LIfecycle Management) jest śro­do­wi­skiem dla zin­te­gro­wa­nej inży­nie­rii sys­te­mów opar­tej na mode­lach, nota­cji SysML (OMG Systems Modeling Language) i pro­duk­tach PLM (Product Lifecycle Management). Dzięki temu podej­ściu inży­nie­ro­wie zło­żo­nych sys­te­mów mogą opra­co­wy­wać i zarzą­dzać wyso­ko­po­zio­mo­wą archi­tek­tu­rą systemu/produktu w SysML i jed­no­cze­śnie łączyć się, komu­ni­ko­wać i syn­chro­ni­zo­wać ze szcze­gó­ło­wy­mi wyma­ga­nia­mi, czę­ścia­mi…

Source: Inteligentna pralka czyli czym jest mechatronika – Jarosław Żeliński IT-Consulting

W czym rzecz? W tym, że produkcja to złożony system powiązanych ze sobą maszyn, obsługujących je ludzi (ale nie zawsze, bo są roboty) oraz produktów jakie powstają z ich użyciem. To co się dzieje na takiej hali to nie procesy biznesowe, hala produkcyjna to pewien złożony mechanizm wytwarzania lub przetwarzania określonych rzeczy. Wyzwaniem jest tu stworzenie modelu tej hali i tych rzeczy [zotpressInText item=”{5085975:8BLSMKW4}”]. Opisuje to między innymi specyfikacja ANSI/ISA-95 [zotpressInText item=”{5085975:3NTCEURC}”]. Na jej podstawie można także opisać jakimi danymi zarządzamy i jak integrujemy dziedzinowe podsystemy zarządzające produkcją [zotpressInText item=”{5085975:WCZIC2ZZ}”].

Norma ANSI/ISA-95

Kluczem do napisania tego artykułu jest warstwowa struktura zarządzania produkcją opisana w normie ANSI/ISA-95:

Dlatego granica między modelem procesów biznesowych (tu używamy notacji BPMN) a modelem systemu produkcji (tu używamy notacji SysML) jest granica miedzy Level 4 a Level e3. Systemy MES operują w warstwie Level 3. Śledzenie i kolekcjonowanie danych to Levels 2, 1,0. (patrz także: OPC Foundation. (2024). ISA-95 Common Object Model—4 Concept [Organisation]. OPC Foundation. https://reference.opcfoundation.org/ISA-95/v100/docs/4)

Polecam także ten krótki film:

Proces biznesowy

Zgodnie z definicją BPMN proces biznesowy to aktywność i jej produkt, złożoność aktywności nie ma znaczenia, ten symbol to abstrakcja dowolnej pracy ograniczonej materialnym (dokument) wejściem i wyjściem (więcej na stronie Notacja BPMN…).

Poniżej dwa kluczowe dla produkcji procesy biznesowe: przyjęcie zamówienia i uzupełnienie niedoboru.

Co do zasady nie łączymy tych procesów w jeden, bo liczba zamówień nie musi być równa liczbie zleceń produkcyjnych: możemy mieć produkcję na zapas, łączenie zamówień w jedno zlecenie produkcji itp.. Na to nakłada się zarządzanie partiami produkcyjnymi.

Powyższe diagramy to typowe modele analityczne procesów. Liczba aktywności nie może być większa niż liczba dokumentów lub zmiany ich statusów (zgodnie z definicją BPMN elementarny proces to aktywność i jej produkt, mogą nim dwa dokumenty, ale analitycznym modelu nie dopuszczamy aktywności bez produktu).

Proces rejestracji i weryfikacji Zamówień jest z reguły realizowany przez system ERP/MRPII: osoba odpowiedzialna za przyjmowanie zamówień rejestruje je i weryfikuje. Wadliwe zamówienia są anonsowane zamawiającemu, pozostałe są rejestrowane ze statusem [przyjęte] (patrz stan vs status dokumentu).

A gdzie są te wszystkie potrzebne detale?

Integracja systemów

Proces uruchamiający zlecenia produkcyjne jest sterowany niedoborem produktów a nie zamówieniem od klienta, gdyż na takim zamówieniu może być wiele produktów, każdy o innym cyklu życia i produkcji.

Tu pojawia się “magiczna” granica między modelami procesów biznesowych, opartych na zadaniach i dokumentach biznesowych, a modelem “fabryki”, czyli złożonego mechanizmu wytwarzającego produkty. Tą fabryką steruje się komunikatami. Są one wysyłane z systemów informatycznych przetwarzających informacje z Zamówień na komunikaty sterujące realizacją zadań na maszynach (generalnie na gniazdach produkcyjnych).

Tu ma miejsce zamiana treści Zamówienia na sekwencję określonych w czasie zleceń produkcyjnych określonych produktów (indeksów). Są to niedobory. Pojawienie się niedoboru (w magazynie) jest wychwytywane w systemie ERP (magazyny, coraz częściej ERP sprawdza to w odrębnym systemie WMS, nie pokazano go tu). Niedobór jest zgłaszany do MOM (Manufacturing Operation Management), składający się z trzech kluczowych podsystemów: planowanie, sterowanie produkcją i zarzadzanie informacją o produktach. Realizacja uzupełnienia niedoboru to sekwencja jak poniżej:

Po prawej, wg, typowej obecnej nomenklatury są to odpowiednio systemy: APS (Advanced Planning & Scheduling), MES (Manufacturing Execution System), PLM (Product Lifecycle Management). Fabryką steruje bezpośrednio system MES, interfejsem jest tu system komunikatów przekazywanych np. na panele dotykowych operatorów stanowisk lub jako komunikaty NX do maszyn CNC sterowanych cyfrowo.

Maszyny, zasoby i produkty

W większości wdrożeń kluczowym systemem jest MES, gdyż tu powstają komunikaty sterujące “fabryką”. Na rynku mamy dość duży ich wybór, jedną z cech tych systemów jest ich branżowość, czyli branże dla których każdy z nich się szczególnie nadaje (patrz porównanie: https://www.gartner.com/reviews/market/manufacturing-execution-systems).

System MES to “wielki koordynator zadań”. Każde zadanie to także komunikat wysłany i zwrotny komunikat odebrany, innymi słowy MES zleca zdania i śledzi ich postęp. W tym miejscu technologia (opisana w PLM) jest zamieniana (przeliczana) na sekwencję zadań dla określonych stanowisk (cell) w fabryce.

Podstawową informacją dla MES jest technologia i wymagane zasoby (BOM, BOR). Poniżej poglądowy schemat:

Modelowanie struktury produktu, jako jego definicji, to modelowanie wraz z pracochłonnością jego wykonania (SysML). Innymi słowy model kosztowy lodów z perspektywy budki z lodami, to gałki lodów, rożek i praca wymagana do przygotowania i wydania loda. Poniżej ogólna struktura pojęć związanych z wytwarzaniem produktów.

Wytwarzanie ich wymaga zarzadzania pokaźną ilością danych:

Jak widać mamy do czynienia z dość poważną złożonością. I tu z pomocą przychodzi traktowanie fabryki wraz z tym co wytwarza jak systemu i notacja SysML bardzo pomaga tu w modelowaniu [zotpressInText item=”{5085975:ZXMTN7WR}”].

Zaczynamy od zapoznania się z dokumentacją opisująca fabrykę (zakład produkcyjny) i tworzymy bibliotekę typów komponentów systemu

Mając przygotowany “zestaw typów klocków” możemy przystąpić do modelowania konkretnego zakładu produkcyjnego i produktów. Można zbudować model ciągu produkcyjnego dla określonego produktu:

Np. stanowisko zbudowane z elementów których typy są na powyższym diagramie może wyglądać tak:

Jeżeli dla lepszego zrozumienia chcemy pokazać jakie zadania są realizowane na tym stanowisku używamy diagramu aktywności:

Nieco bardziej wyrafinowany przykład opisu stanowiska:

Powyżej cytowany model jest precyzyjny, gdyż może posłużyć do symulacji (ww. źródło zawiera komplet modeli opisujących pewną fabrykę). W przypadku typowego wdrożenia systemu MES celem zidentyfikowanie stanowisk, ich wyposażenia i etapów produkcji wraz z przezbrojeniami oraz strukturę opisu technologii wykonania produktu, czyli musimy zidentyfikować dane wymagane do parametryzacji systemu na etapie wdrożenia. Opisywany powyżej model to kolejny “digital twin” fabryki na poziomie abstrakcji pozwalającym bezbłędnie i za pierwszym razem przygotować informacje wymagane by skonfigurować i uruchomić system MES a później zarządzać zmianą.

Podsumowanie

Opisano krótko metody i notacje używane do modelowania systemu produkcji. Celem tych modeli jest skompletowanie danych potrzebnych do skonfigurowania systemów: CAD, CAM, MES, APS, PLM. Gdzie te dane? To atrybuty i ich wartości. Atrybuty elementów tych modeli (bloki funkcjonalne i ich instancje). Opis produktu to struktura treści składająca sie z elementów opisujących nie tylko listę składników BOM, ale także listę operacji wraz z ewentualnymi przezbrojeniami na stanowiskach realizujących kolejne operacje w toku wytwarzania. Kolejne stanowiska, ich wyposażenie, operacje jakie są realizowane na każdym z nich, pozwalają dokonać sprawdzenia, czy wszystko rozumiemy.

Kluczowe są także modele samych produktów, detale powstaję z pomocą aplikacji CAD, ale abstrakcje opisujące ich architekturę to SysML. Mając takie modele możemy upewnić się, że całość jest spójna, kompletna i niesprzeczna. Mamy też możliwość dokonania świadomych optymalizacji, które na modelach odbywają się to wielokrotnie niższym kosztem niż “na żywym ciele” w toku wdrożenia [zotpressInText item=”{5085975:FI9PGYD7},{5085975:LSFREFR4},{5085975:29NZ6BRG}”].

Całość jest nazywana Design Chain Management (DCM), czyli zarządzanie łańcuchem projektowym, rozumianym tu jako ciąg zdarzeń (prac, czynności) od zaprojektowania produktu, przez jego wytworzenie do dostarczenia zamawiającemu.

Jak widać musimy zarządzać zmiennością funkcjonalności, zmiennością struktury produktu, zmiennością procesów produkcji, zmiennością procesów w logistyce. To wszystko cechuje sie określonymi parametrami. Łańcuch projektowania i wytwarzania płynnie przechodzi w łańcuch dostaw. Jednak CAŁOŚĆ opiera sie na zarządzaniu informacją. Dlaczego? Bo systemy informatyczne nie produkują kół zębatych, one jedynie przechowują i przetwarzają informacje o całym tym procesie. WSZYSTKIE.

Dlaczego więc nie tylko BPMN? Dlaczego inne systemy notacyjne? A jak w BPMN opisać wszystko powyższe? Zakład produkcyjny to skomplikowany system, nie da się go skutecznie opisać używając jedynie nazw aktywności. Zresztą detaliczne prace wykonywane przy maszynach i ich kolejność, materialne elementy, które w toku produkcji nie są “wydaniem z magazynu i przyjęciem na magazyn”.

BPMN to tylko biznesowy model łańcucha pracy i jej produktów: informacji (dokumentów). To co wytwarzamy to systemy: od prostych sterowników klimatyzacji, przez sprzęt AGD, do samochodów i samolotów. To wszystko to mieszanka podzespołów mechanicznych, elektromechanicznych i komputerów (programator pralki i sterownik wtrysku silnia spalinowego to komputery) [zotpressInText item=”{5085975:8G9TUWIG}”]:

System informatyczny zarządzający tym wszystkim to informacje zarówno o produkowanych produktach jak i o samych same halach produkcyjnych i tym co sie tam dzieje. Model BPMN tu to tylko malutki wierzchołek góry lodowej, to czwarty poziom (Level4) hierarchii modeli.

Znane są próby wdrożenia produkcji jako sekwencji dokumentów MM między stanowiskami w fabryce, albo kastomizacja systemu ERP z prostej operacji kompletacji w obsługę produkcji. No nie są to sukcesy… świat tak nie robi. Jak? Zalecenia ANSI/ISA-95 to zbiór dobrych praktyk i modeli, który warto poznać i zrozumieć. Głównie dlatego, że oprogramowanie czołowych producentów na świecie jest budowane na bazie tych standardów. To zaś oznacza, że łamanie tych standardów w toku wdrożeń tych aplikacji, może się tylko źle skończyć, tak samo jak wciskanie kwadratowego korka w okrągła szyjkę butelki.

Źródła

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

Wprowadzenie

Ten artykuł to krótki wpis o tak zwanym V-modelu. Jest to model wytwarzania oparty na pętli analizy, projektowania, testowania i przekazania do użytku. Oparty jest połączeniu dwóch cykli życia: projektowania i wytwarzania. jest stosowany w szeroko pojętej inżynierii systemów, nie koniecznie oprogramowania.

W branży IT znana jego postać wygląda np. tak:

Niedawno w innej wersji v-model publikowałem, pisząc o tym czym jest mechatronika [zotpressInText item=”{5085975:NMVF5IRQ}”]:

Czy V-model to waterfall

Bardzo często autorzy piszą, że jest to skompromitowany, tak zwany wodospadowy (waterfall), system wytwarzania oprogramowania. Była by to prawda, gdy zawsze chodziło o hipotetyczny “cały system”. Jednak V-model, jako metoda, nie precyzuje skali projektu. W przypadku większości dawnych konstrukcji mechanicznych była by to prawda, jednak modułowość to od lat cecha każdej konstrukcji inżynierskiej. Model ten więc nie koniecznie musi być tym “złym wodospadem”. Pojawiają się od czasu do porównania między wodospadem, v-modelem a agile, jako metodami, jednak ich autorzy nie precyzują tego, czy w danym przypadku chodzi o moduł czy o cały system. Model ten jest stale przedmiotem poszukiwań poprawy jakości i większej “zwinności” [zotpressInText item=”{5085975:TJ5CWSPX}”].

Myślę, że klasyczny wodospad, jako metoda prowadzenia powoli odchodzi w niepamięć (powinien). Nie zapominajmy jednak, że rozpoczynanie tworzenia oprogramowania od projektowania wspólnego (relacyjnego) modelu danych to taki właśnie klasyczny strukturalny wodospad. Więc jak?

Modułowe systemy to w zasadzie zagnieżdżone dwa v-modele. Najpierw projektujemy architekturę całości: powstaje model komponentowy. Kolejne etapy to iteracyjne dostarczanie poszczególnych komponentów. W konstrukcjach elektromechanicznych i tak musimy czekać na ukończenie całości (samochód czy pralka albo jest w całości, albo nie mamy czego używać). W przypadku oprogramowania możemy skupić sie na pojedynczych komponentach.

Poprawnie zaprojektowane oprogramowanie to samodzielne usługi aplikacyjne. Złożone nie raz, aplikacje powstają jako zbiory takich usług, na rynku widzimy je jako gotowe wielomodułowe systemy. Jednak dedykowane projekty nie mają rygoru “oddania w całości”. Usługi aplikacyjne mogą być oddawane jedna po drugiej. Wtedy opisywany tu v-model to najpierw lewa strona: tak zwana “architektura wysokiego poziomu”, a następnie iteracyjno-przyrostowe realizacje kolejnych komponentów i usług. Każda kolejna usługa (komponent) to projektowanie, implementacja, testy i oddanie do użytku.

Podejścia znane jako Use Case 2.0 czy Microservice, to właśnie takie modułowe

Jednak nadal na etapie analiz i projektowania autorzy tych projektów bardzo często nadal poprzestają na opisu idei, czyli procesu biznesowego i nazwanych usług, nie jest to jednak projektowanie systemu a co najwyżej biznesowe wymagania [zotpressInText item=”{5085975:RBGFRQ7H}”]. V-model opiera się na tym, że implementacja jest poprzedzana projektowaniem, czyli swoistym studium wykonalności. Jest to sprawdzona metoda z każdej innej inżynierii:

zanim zaczniesz budować, upewnij się, że wiesz co powinno powstać.

Tak więc v-model wygląda na dobrą metodę-proces. To czy jest to wodospad czy nie, zależy od architektury całości (monolit czy komponenty) a nie od faktu poprzedzania implementacji projektowaniem.

Poniżej schemat obrazujący V-model z perspektywy dzisiejszych systemów mechatronicznych:

Godna podkreślenia jest tu granica między architekturą a implementacja oraz fakt, że architektura to komponenty multidiscyplinarne: komponent systemu może być konstrukcją mechaniczną, elektromechaniczną, itp.. może być komputerem. Tu ważna uwaga: powszechnie mówi sie o oprogramowaniu jako komponencie, jednak jest to pewne uproszczenie, gdyż komponentem systemów są komputery a nie “oprogramowanie”. Elementem sterującym w samochodzie czy pralce jest umieszczony w nich i zintegrowany z resztą komputer, a nie “oprogramowanie”.

Skoro system z zasady jest tworem składającym się elementów to znaczy, że także z zasady ma wewnętrzna architekturę. Rakieta, samochód czy pralka to systemy, jest jednak istotna różnica między systemem jakim jest np. samochód a systemem jakim jest grupa ludzi, umeblowanie mieszkania czy aplikacja jak element komputera. Samochód albo jest kompletny albo nie jest działającym samochodem. Jednak każdy element systemu umeblowania mieszkania sam z siebie posiada określoną i niezależną od pozostałych elementów tego systemu funkcjonalność: każdy mebel do czegoś służy. Można nie mieć w pełni umeblowanego salonu mając już jednak jeden fotel i siedzieć w nim by odpocząć.

Identyczną sytuację mamy w przypadku złożonego oprogramowania, jednak pod warunkiem, że nie jest ono (jego architektura) monolitem. Jeżeli ma architekturę prawdziwie komponentową (komponent są od siebie realnie niezależne), budowa takiego systemu to dwupoziomowy V-model jaki pokazano poniżej:

O systemach projektowanych realnie komponentowo pisałem w artykule Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy. Tu skupimy się na samym fakcie, że system jest komponentowy.

Mając projekt HLD systemu mamy zdefiniowane jego komponenty a konkretnie ich interfejsy i wymaganą logikę działania (funkcję jaką pełnią w systemie). W efekcie każdy komponent, na swoim poziomie, ma wymagania (zdefiniowane interfejsy) i powstaje także w procesie V-model. Z uwagi na wyżej opisaną specyfikę systemów jaką jest oprogramowanie, często komponenty pojedynczo posiadają przydatną użytkownikowi aplikacji funkcjonalność. To oznacza, że można je dostarczać niezależnie i w ustalonej kolejności. Tak właśnie, iteracyjnie-przyrostowo, powstaje złożone oprogramowanie podzielone na niezależne komponenty [zotpressInText item=”{5085975:5B9ZHAYU}”].

Konflikt interesu czyli role w projekcie

Pierwszy cytowany diagram w tym tekście pokazuje V-model jako model pracy developera. Jednak w zarządzaniu projektami inżynierskimi coraz częściej podkreśla się kwestie jakości, a tam gdzie pojawia się pojęcie jakości i nadzoru pojawia sie pojęcie konfliktu interesu.

Czym jest konflikt interesu? Jest “starym jak świat problemem”:

Nemoiudexincausasua– nikt nie może być sędzią we własnej sprawie. Nullus idoneus testis in re sua intellegitur – nikt nie może być wiarygodnym świadkiem we własnej sprawie.

starorzymskie paremie prawnicze [zotpressInText item=”{5085975:F76UHJTY}”]

Dlatego diagram ten uzupełniłem pokazując trzy kluczowe role w projekcie inżynierskim:

Główny konflikt interesu to zamawiający vs. wykonawca – klasyczna sprzeczność ceny i jakość oraz zakresu: zamawiającemu zależy na maksymalizacji funkcjonalności a wykonawcy na: minimalizacji kosztów (projekt fixed-price) lub maksymalizacji kosztów (projekt T&M).

Dlatego po stronie zamawiającego angażujemy projektanta bo:

• zamawiający nie ma tej kompetencji,
• odbieramy te role wykonawcy z powodu ww. konfliktu interesu.

Potencjalny konflikt interesu między projektantem (ustala zakres projektu) a przyszłymi użytkownikami (podwładni zamawiającego maksymalizujący ten zakres) rozwiązujemy “umocowując” projektanta “na poziomie” sponsora projektu.

Praktyka pokazuje, że brak separacji ww. ról jest jedną z głównych przyczyn niepowodzeń projektów w branży IT:

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 (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Podsumowanie

Jak pokazano można projektować, nawet bardzo duże, systemy informatyczne nie robiąc tego metodą mityczne wodospadu (waterfall). Waterfall to metoda (model) wytwarzania oprogramowania “w jednym przebiegu”, czyli przy założeniu, że prace implementacyjne rozpoczynają się dopiero po opracowaniu ostatecznej specyfikacji systemu. Taki model wytwarzania jest cechą systemów o monolitycznej architekturze. Tu warto podkreślić, że monolitem jest także modułowy systemy zbudowany na jednej, centralnej bazie danych w modelu relacyjnym.

Podział systemu na komponenty w pierwszym etapie analizy i projektowania (architektura wysokiego poziomu) to dekompozycja problemu i opracowanie rozwiązania problemu. Kolejne prace to “raz z razem”, projektowanie detali kolejnego określonego komponentu (architektura niskiego poziomu), jego integracja z już istniejącymi, i wdrażanie. Tak powstają bardzo sprawnie, iteracyjnie przyrostowo, nawet bardzo duże systemy i nie ma to nic wspólnego z metodą zwana “waterfall”.

Podkreślić tu należy, że kluczowe dla procesu V-model, jest to, że z zasady implementacja poprzedzana jest projektowaniem. Jest to ogromna zaleta tej metody, gdyż na dowolnym etapie mamy dokumentacje opisująca działanie systemu. Ta (ta sama) dokumentacja jest wymaganiem na początku i opisem technicznych na końcu.

Jednym z największych problemów w branży informatycznej jest nieaktualna dokumentacja oprogramowania lub jej brak (patrz artykuł Dług informacyjny). V-model to proces usuwający te wadę. Po drugie prace koncepcyjno-projektowe na modelach (a nie na kodzie) są znacznie efektywniejsze i tańsze. Praktyka tworzenia dokumentacji dopiero po oddaniu oprogramowania do użytku, jest bardzo kosztowna i nieefektywna, oraz obarczona dużym ryzykiem, pominięć.

Kluczem zaś jest separowanie ról z konfliktem interesu.

Poniżej tak zwana pętla zarządzania jakością SDLC:

I powstaje pytanie: jeżeli nie było etapu analizy i projektowania co to i na jakiej podstawie jest przedmiotem testów?

Źródła

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