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 . 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:
- układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość
- zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość
- narządy lub inne części żywego organizmu pełniące razem określoną funkcję
- uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię
- określony sposób wykonywania jakiejś czynności lub zasady organizacji czegoś
- forma ustroju państwowego
- zespół skał powstałych w ciągu jednego okresu geologicznego
- 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 , 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” i jak sie to ma do firm. Zainteresowanym polecam także . 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 . 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, ), 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 , 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ą .
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 . 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? .
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.”
Metody określane jako MBSE sprawdzają się bardzo dobrze jako narzędzie specyfikowania wymagań, tu wymaganiem jest właśnie model czyli projekt systemu .
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ę .
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 . 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 . 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) . Mechanizm nigdy nie jest jednym elementem, jednak jako wyjaśnienie jest abstrakcją, czyli “ukrywa” (abstrachuje od) szczegóły: mechanizm, jako opis, jest idealizacją .
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 .
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ń.
