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 przyjęcie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonego przyjęcia 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 systemu.” W tym wpisie na blogu przedstawiam krótkie wprowadzenie do MBSE.
Prawdę mówiąc "zabraniam" przynoszenia komputerów na moje szkolenia, wymagam papieru i ołówka. Powody są dwa: Narzędzia CASE pomagają tylko wtedy gdy diagramów jest wiele i model jest złożony, na szkoleniach takich modeli się…
Do napisania tego artykułu "zmusiła" mnie kolejna przygoda z korepetycjami, w której tym razem dostałem od studenta pełną treść zadania wraz ze wskazówkami. Nie będę pisał o jaką uczelnię chodzi i kim jest tenże wykładowca bo nie jest moim celem krytyka osoby czy uczelni. To co pisze, wydaje mi się, jest zjawiskiem powszechnym (w miarę czasu jakim dysponuje, udzielam często korepetycji studentom różnych uczelni). [...] to tylko przykład "zadania dla studenta", takich "zadań" i ich zaliczeń znam multum. Ktoś tak "wykształcony" pojawia się na rynku pracy i ma pretensje, że ma kłopoty ze znalezieniem pracy albo na podstawie dyplomu prestiżowej uczelni zostaje zatrudniony, i sieje spustoszenie w projektach nie raz ogromnej wartości. Jest nie raz gorzej, bo buduje stereotyp "nieprzydatnej i kosztownej pracy analityka". Powyższy przykład to praca wykładowcy na prestiżowej w naszym kraju uczelni na kierunku Analiza Biznesowa.
Wymagania na oprogramowanie są często dokumentowane z pomocą Przypadków Użycia (PU), zwanych w "oryginale" Use Case (UC). Wygodą stosowanie tej konwencji jest traktowanie Systemu jako tak zwanej czarnej skrzynki, czyli czegoś, czego wewnętrznej budowy nie znamy, ale znamy reakcje na bodźce. W przypadku oprogramowania, nie wiemy jak jest ono zbudowane (w momencie zamawiania go, może ono jeszcze nie istnieć), ale wiemy jak reaguje na "polecenia". Jest to uznanie zasady, że zamawiający definiuje CO oprogramowanie ma robić a nie to JAK ono to robi. W przypadku gotowego oprogramowania, lub na etapie poprzedzającym projektowanie, ma to sens, jednak należy pamiętać, że przypadki użycia nie determinują tego co tak na prawdę dostaniemy, co opisałem w artykule o tym co na prawdę opisują przypadki użycia. Generalnie diagram PU jest bardzo dobrym "korzeniem" do analizy i tworzenia pozostałych modeli, ale bez powstającego "natychmiast" modelu dziedziny nie jest możliwe zaprojektowanie granic (bounded context) dla komponentów. Spotykam się w literaturze z tezami, które uważam za słuszne, że jeden system (podsystem) nie powinien przekraczać 50 klas biznesowych w dziedzinie (liczba bliska 100 to ogromny system). Praca nad oprogramowaniem powinna zacząć się od analizy i rozbicia problemu na "strawne" kawałki. Najpierw podział na podsystemy, potem na komponenty, a na końcu konkretne klasy i ich realizacje. Nie ma tu mowy o podziale z perspektywy aktora, bo jeżeli wiemy jaka jest konstrukcja zaprojektowanego młotka albo kalkulatora, to nie możemy ograniczyć (bo nie mamy podstaw) liczby ich użytkowników, bo każdy ma swoje uzasadnione powody by wziąć do ręki np. młotek....
Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić? Opisać strategie rynkową firmy, Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów), Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych, Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści, Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi. Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. - SOA) Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.
Dosyć często spotykam się z modelowaniem struktur organizacyjnych czy nawet ról w procesach, z pomocą diagramów przypadków użycia i hierarchii aktorów z użyciem dziedziczenia. Jest to moim zdaniem kompletne nieporozumienie i fałszywe. Zawiłe diagramy struktur organizacyjnych w postaci aktorów dziedziczących po sobie (nie przytoczę tu żadnego, każdy taki jest w zasadzie zły), na których przełożony dziedziczy po podwładnym (lub podobne konstrukcje), są niemalże zawsze gruntu fałszywe. Studiowanie zakresów obowiązków pracowników firm jawnie pokazuje, że to nie prawda. Z zasady wielu menedżerów działów nie ma kompetencji swoich podwładnych, nie raz szef działu prawnego nie ma, i nie musi mieć, uprawnień radcowskich czy adwokackich, w wielu większych sekretariatach, upoważnienia do pewnych podpisów są przydzielane indywidualnie i szef (szefowa) nie ma tych wszystkich upoważnień. Szef kancelarii tajnej może mieć uprawnienia do informacji tajnej nadane przez ABW, których to uprawnień nie ma nie raz, jego przełożony. Przykładów na fałszywość dziedziczenia uprawnień w strukturze organizacyjnej można podać tak ogromną ilość, że dość częste stosowanie tej konstrukcji wydaje mi się niezrozumiałe. projektują oprogramowanie także, z reguły nieprawdą, jest dziedziczenie praw dostępu. Nie przypadkiem w praktyce stosuje metody macierzowe zarządzania prawami dostępu (niewydolne i nie prawdziwe w sensie biznesowym) lub kontekstowe (dużo lepsze).