Zapraszam wszystkich, którzy szukają pomocy, wiedzy oraz wsparcia w swoich projektach informatyzacji. Działam od 1991 roku, mój Blog działa nieprzerwanie od 1998 roku.
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.
Wstęp Od lat spotykam się w literaturze z zakresu zarządzania, z krytyką poczty elektronicznej jako narzędziem zarządzania czymkolwiek (patrz: Sabotaż...2013). Poczta elektroniczna (podobnie jak pakiety biurowe w ogóle) jest typowym przykładem maksymy: ułatwienie nie zawsze jest ulepszeniem. W kliencie poczty elektronicznej zarówno treść jak i sposób adresowania (co i do kogo, kopia, itp.) nie podlega żadnej standaryzacji ani restrykcji (poczta elektroniczna często służy do wyprowadzania danych z firmy). Jak dodać do tego fakt, że załączniki są niewidoczne w narzędziach do lokalnego wyszukiwania, że mamy na serwerach filtry antyspamowe których reguły…
Od czasu do czasu wpadają mi maile z pytaniami jak to:
Chcę zamodelować dynamiczne zachowanie / stany smartfona (np. wyłączenie smartfona, inicjalizacja, tryb czuwania, użycie) w diagramie maszyny stanów SysML. Dla stanu użytkowania istnieją również podstany takie jak dzwonienie, latarka lub robienie zdjęć. Nie jestem pewien czy powinienem modelować te podstany, a jeśli tak, to jak mogę je modelować (szczególnie biorąc pod uwagę fakt, że każdy z tych podstanów może zmieniać się w inny, jak również mogą one działać równolegle). Moim zdaniem są różne opcje: 1.) Po prostu uwzględnić je jako aktywność w użyciu stanu 2.) Wymodelować je w oddzielnym diagramie maszyny stanów 3.) Modelować je w oddzielnym diagramie aktywności (czy mozna użyć diagramu aktywności zamiast diagramu maszyny stanowej?)
Takie i podobne pytania pojawiają się w mailach do mnie często, ale zanim na nie odpowiem tu, opiszę czym jest model (diagram) maszyny stanowej. Pokażę także dlaczego, np. próby wdrażania obiegów dokumentów na bazie wzorca “maszyny stanowej” sprawiają ogromne kłopoty, lub po prostu się nie udają.
Na początek to, co znajdziemy np. w Longman English Dictionary:
status: a situation at a particular time, especially in an argument, discussion etc. (sytuacja w określonym czasie, zwłaszcza w kłótni, dyskusji itp.) state: the physical or mental condition that someone or something is in (stan fizyczny lub psychiczny, w jakim znajduje się ktoś lub coś)
źr.: Longman English Dictionary https://www.ldoceonline.com/
Tak więc generalnie status to ogląd obiektu z zewnątrz, stan to cecha obiektu. Innymi słowy moja choroba to mój stan, ale moja niezdolność do pracy to aktualny mój status (wynika on nie z choroby, a z ustalenia, że chorzy nie pracują, to nie to samo). Zapraszam do lektury.
Zostałem niedawno zapytany czy pomogę bo “mamy już ponad 150 przypadków użycia w dokumentacji…”. Myślę sobie, to niemożliwe, nie ma tak wielkich systemów (wycena okazała się w efekcie pięciokrotnie zawyżona tylko dlatego, że użyto metody zorientowanej na “user story”).
W artykule o aplikacjach webowych, ponad rok temu, pisałem:
Generalnie kluczową cechą micro-serwisów, czyniącą z nich tak zwaną zwinną architekturę, jest całkowita wzajemna niezależność implementacji poszczególnych usług aplikacyjnych. (źr.: Aplikacje webowe i mikroserwisy czyli architektura systemów webowych).
Przy innej okazji pisałem o wzorcach:
Wzorce projektowe to bardzo ważna część ??zawodu? analityka i architekta oprogramowania. […] Generalnie wzorce są to skatalogowane standardy i dobre praktyki . (Obiektowe wzorce projektowe )
Szkolenia dla analityków poprzedzam ankietami przed szkoleniowymi, jak do tej pory żadna nie zawierała pytań o wzorce projektowe: ani tego że są używane ani tego, że są celem szkolenia, niemalże każdy deklaruje albo, że używa UML lub, że chce zacząć używać UML, nawet gdy są to programiści. Zauważyłem, że wzorce projektowe w świadomości analizy biznesowej i projektowania (OOAD) “nie istnieją”. Wśród programistów, jeżeli jest spotykana, to wiedza o wzorcach przydatnych w tworzeniu bibliotek i narzędzi, często też powielane są wyuczone stare i złe praktyki programistyczne rodem z lat 60-tych (np. praktyki SmallTalk, patrz dalej).
Autor recenzowanego tekstu odnosi sie do skutków ekonomicznych, pomija jednak całkowicie skutki prawne kastomizacji kodu oprogramowania, które mają wpływ na koszty i ochronę wartości intelektualnych. Autor pisze we wstępie:
Celem niniejszego opracowania jest analiza możliwych metod kastomizacji systemów informatycznych zarządzania przeprowadzona z ekonomicznego punktu widzenia, w tym w szczególności opłacalności stosowania oprogramowania standardowego i wykorzystania poszczególnych metod jego adaptacji. […] Kastomizację systemu informatycznego ogólnie należy rozumieć jako jego adaptację do potrzeb konkretnego podmiotu. M. Flasiński określił kastomizację, jako ?konfigurację systemu, osadzenie w systemie za pomocą prac programistycznych dodatkowych funkcjonalności oraz modyfikację istniejących funkcjonalności systemu?
Dostarczanie oprogramowania i jego wdrażanie, wiąże się jego ewentualnym dostosowaniem do potrzeb użytkownika. Autor powyższego opracowania, stosując nieprecyzyjne definicje pojęć, wprowadza czytelnika w błąd, opisując przyczyny i konsekwencje związane z szeroko pojętym dostosowaniem oprogramowania do potrzeb użytkownika.
Niestety z tego dokumentu korzysta wielu prawników, nazywając go nie raz nawet “wykładnią”.
W toku szkoleń, a także audytów, powstają nie raz spory o interpretacje znaczenia symboli notacji: ich semantyki i syntaktyki (co oznaczają i jak je można łączyć z innymi). Dzisiaj o dość częstym sporze czyli bramki OR (inclusive) i XOR (exclusive) w notacji BPMN oraz o tym, że z 380 stron specyfikacji BPMN, w modelach analitycznych stosujemy tylko niecałe 40 stron rozdziału 7., pozostałe rozdziały służą wyłącznie lepszemu zrozumieniu teorii i modelom wykonywalnym. Czyli dlaczego w analizach stosujemy kilka, a nie kilkadziesiąt symboli notacji BPMN.
Dzisiejszy wpis to efekt lektury artykułu Pani Mec. Marty Pasztaleniec na stronie IP Procesowo. Kluczowe dla dzisiejszego wpisu jego fragmenty to:
Programy komputerowe w świetle krajowego prawa autorskiego korzystają ze szczególnej ochrony. Z uwagi na ich specyfikę wyłączono stosowanie niektórych regulacji z ogólnej części prawa autorskiego, w szczególności przepisów dotyczących dozwolonego użytku, który umożliwia w ściśle określonych okolicznościach korzystanie z utworów bez zgody twórcy, a nawet wbrew takiej zgodzie. Co do zasady zatem jakiekolwiek zwielokrotnienie programu komputerowego wymaga zgody twórcy. […] Spór ma swą genezę w 2005 r. kiedy to Google nabył startup Android Inc i rozpoczął starania by wejść na rynek smartfonów, tworząc platformę do budowy systemów dla urządzeń mobilnych. Platforma w swym założeniu miała być nieodpłatna po to by popularyzować środowisko Google. Jako że język programistyczny Java był wówczas jednym z najbardziej popularnych i powszechnych wśród programistów, Google podjął rozmowy z Sun Microsystems ? twórcą Java ? na temat licencjonowania całej platformy Java. Ostatecznie zdecydował się jednak na budowę własnej platformy. Aby jednak zapewnić jej powszechność i łatwość stosowania wśród programistów zastosowano w nim nazwy funkcji i formatów danych charakterystyczne dla języka Javy. Google de facto opracował własne odpowiedniki funkcji Javy i nadał im nazwy takie same jak w Javie. Oracle, po przejęciu spółki Sun Microsystems, pozwał w 2010 r. Google o naruszenie przysługujących Oracle praw autorskich i patentów. Zarzucono Google skopiowanie blisko 11 500 linii deklaracji API programu Java (co stanowiło 0,4 % deklaracji). […] Sąd uznał, że działanie Google było ?zgodne z kreatywnym ?postępem?, który jest podstawowym konstytucyjnym celem samego prawa autorskiego?. Według sądu dozwolony użytek pełni więc istotną rolę w rozwoju oprogramowania, a prawo autorskie nie powinno hamować tego rozwoju. (żr.: Dozwolony użytek programów komputerowych ? jak Google pokonał Oracle w USA).
Powyższy tekst wskazuje na dwa ciekawe aspekty oprogramowania, o których dzisiaj napiszę. Pierwszy to tak zwany dozwolony użytek, bardzo często przywoływany w sporach o bezpłatne użycie oprogramowania i zakres tego użycia. Najczęściej dotyczy gier komputerowych ale nie tylko. Drugi to charakter oprogramowania, jakim jest kod źródłowy będący tekstem, oraz efekt ostateczny, jakim jest “komputer realizujący określony mechanizm”, gdzie komputer definiujemy jako “procesor, pamięć i program” . Warto tu zwrócić uwagę na pewien “drobiazg”: autorka (jak wielu innych prawników) traktuje treść programu jako “tekst” i nie raz stosuje analogię do typowych utworów pisanych takich jak proza czy poezja, co jest poważnym błędem. Fragmenty tekstów (esej, praca doktorska, powieść, itp.) bardzo często mają wartość, czego o nie można powiedzieć o oprogramowaniu (nie działa w kawałkach). Owszem, można potraktować fragmenty kodu “literaturowo”, jako przykłady jego struktry i składni (np. literatura na temat wzorców projektowych w inżynierii oprogramowania), jednak nie można mówić o fragmencie kodu, że to “oprogramowanie”, gdyż to z zasady “musi działać”, a jest to możliwe tylko wtedy gdy do komputera załadujemy kompletny program a nie “cytowany fragment”.
Od czasu do czasu jestem pytany o to, kiedy używać diagramu aktywności UML. Od 2015 roku specyfikacja UML wskazuje, że diagramy te są narzędziem modelowania metod czyli logiki kodu (dla Platform Independent Model): aktywności (activities) to nazwy metod, zadania/kroki (actions) to elementy kodu (przykłady w dalszej części).
Gdy powstawał UML, diagramy aktywności były używane także do modelowanie procesów biznesowych. W roku 2004 opublikowano specyfikację notacji BPMN, która w zasadzie do roku 2015 “przejęła” po UML funkcję narzędzia modelowania procesów biznesowych. W 2015 roku formalnie opublikowano specyfikację UML 2.5, gdzie generalnie zrezygnowano z używania UML do modeli CIM. Obecnie Mamy ustabilizowaną sytuację w literaturze przedmiotu: BPMN wykorzystujemy w modelach CIM (modele biznesowe), UML w modelach PIM i PSM jako modele oprogramowania (a modele systemów: SysML, profil UML).
Na przełomie lat 80/90-tych rozpoczęto prace nad standaryzację notacji modelowania obiektowego, w 1994 opublikowano UML 0.9, w 2001 roku pojawiają się pierwsze publikacje o pracach nad notacją BPMN, jednocześnie pojawia się Agile Manifesto, od 2004 roku ma miejsce spadek zainteresowania dokumentowaniem projektów programistycznych, w 2004 rok publikowano specyfkację BPMN 1.0, od tego roku ma miejsce wzrost zainteresowania modelowaniem procesów biznesowych, powoli stabilizuje się obszar zastosowania notacji UML. W 2015 roku opublikowano UML 2.5, stosowanie analizy (CIM) i i projektowania (PIM), jako etapu poprzedzającego implementacje, stało się standardem (źr. wykresu: Google Ngram).
Tak więc obecnie:
Nie używamy diagramów aktywności do modelowania procesów biznesowych. Do tego służy notacja BPMN!
Diagram aktywności może być modelem kodu na wysokim lub niskim poziomie abstrakcji, operujemy wtedy odpowiednio aktywnościami (activity) lub działaniami (actions). Te ostatnie to w zasadzie reprezentacja poleceń programu.
Nie ma czegoś takiego jak “proces systemowy”, oprogramowanie realizuje “procedury”.
Projektując oprogramowanie zgodnie ze SPEM , powstaje Platform Independent Model. W praktyce już na tym etapie programujemy, bo tworzymy logikę i obraz przyszłego kodu. Taka forma dokumentowania pozwala także lepiej chronic wartości intelektualne zamawiającego.
Tym razem artykuł adresowany do zaawansowanych analityków.
Ta specyfikacja (SPEM) jest datowana na 2008 rok. Stanowi sobą tło dla MDA oraz uzasadnia wzorce projektowane oparte na przypadkach użycia (mikroserwisy, Use Case 2.0, inne podobne). Podstawowa różnica między specyfikacją SPEM a specyfikacją UML polega na tym, że UML to profile MOF stanowiące opisy notacji i systemów pojęciowych. SPEM to metamodel procesu wytwórczego oprogramowania czyli generalne zasady budowania procesów wytwarzania i dostarczania oprogramowania.
Z zamiarem napisania tego tekstu noszę się już od kilku lat i za każdym razem mówiłem sobie: "ok, jeszcze tylko skończę ten jeden projekt i zobaczymy czy faktycznie ma to sens". I tak od kilku lat. W końcu jednak udało się. Wprowadzenie Popularność podejścia do modeli procesów biznesowych, polegającego na "pokazaniu różnicy", trwa od czasów popularyzacji re-inżynierii procesów biznesowych (lata 90-te) . Umowy na usługi, zawierające w zakresie opracowanie modelu 'as-is' i 'to-be' nadal są podpisywane. Zakładam, że decyzje o zakresie projektu to indywidualne potrzeby zamawiających. Ja opiszę swoje doświadczenia…
W Sobotę 22 maja 2021, na konferencji Be IT 2021 organizowanej przez Koło Naukowe Zarządzanie IT Politechniki Gdańskiej, poprowadziłem warsztat: Analiza i projektowanie struktury informacji. Z uwagi na tematykę: rzeczy dla uczestników nowe, takie jak chmurowe repozytoria i dokumentowe bazy danych NoSQL, poprowadziłem go jako konwersatorium omawiając przykłady repozytoriów NoSQL oferowane w chmurze publicznej oraz omawiając wcześniej przygotowany prosty przykład aplikacji dla Biblioteki, zbudowany z użyciem omówionych wzorców dla baz dokumentowych i notacji UML. Jak co roku otrzymałem ankietę i jak zawsze postanowiłem się z niej wytłumaczyć, a także przyjąć…
Wprowadzenie Zarówno w projektach jak i w dyskusjach np. na konferencjach czy na LinkedIn, pojawia się stale pewne nieporozumienie: "projektowanie to waterfall". Myśli tak każdy, kto wyobraża sobie, że projekt czegoś to jakaś masa wszystkich możliwych detali. Jednocześnie nie ja jeden widuję "Dokumenty analizy biznesowej" albo "Dokumenty wymagań" zawierające setki pozycji o treści "system powinien...", nie raz wykonane przez krytyków "water fall", którzy reprezentując developera deklarującego metody "agile", "zabezpieczają się" przez odpowiedzialnością za zakres projektu. Pierwsza ważna uwaga: projekt systemu to nie jest ani zestaw dziesiątków "user story" ani detaliczna…
