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.
Dzień Dobry Od dość dawna śledzę Pańskie materiały (strona www, książka) i trafił mi się taki materiał (link poniżej), pomyślałem sobie że się podzielę. https://www.youtube.com/watch?v=voq_hz4LZLA Should I Build a Monolith or Microservices? jestem ciekawy Pańskiego komentarza, oczywiście w wolnej chwili na linkedinie albo na stronie Dzień Dobry Kolejny przypadek tego jak "koderzy" potrafią niezrozumieć i zniszczyć pierwotny pomysł, a największymi niszczycielami są Ci od C++/JavaEE (kaskady dziedziczenia i kompozycji). Dlaczego? Przede wszystkim nie mam na myśli autora cytowanego przez Pana referatu :), on opisuje konsekwencje. Mam na myśli tych, którzy z mikroserwisów zrobili…
(źr.: https://codersociety.com/blog/articles/contract-testing-pact)
Wprowadzenie Pięć lat temu artykuł o różnicy między stanem a statusem obiektu kończyłem słowami: Powyższe to jeden z wielu powodów, dla których metody takie jak “event storming” są bardzo nieskuteczne jako analiza i projektowanie logiki działania oprogramowania, szczególnie tak zwanego “biznesowego”. (Stan obiektu to nie jest jego status – JZ IT Consulting Limited – PL Blog) Dzisiaj kontynuacja. Coraz częściej słyszę buzzword "Event-Driven Architecture". Co to jest? To założenie, że aplikacja to maszyna stanowa, że obiekty reagują i zmieniają swój stan pod wpływem zdarzeń (zmiana stanu innych obiektów) w ich…
ERP, CRM, Inventory, problem.
https://dataedo.com/cartoon
Wprowadzenie To pytanie zadaje sobie każdy kto planuje tę inwestycję. Czy to łatwy wybór? Nie. Na początek ważny fakt: wdrożenia monolitów: Co jest powodem? Kluczowym jest architektura: relacyjne bazy danych tych systemów mają kilka tysięcy powiązanych tabel, zapytania SQL do tych tabel to setki linii kodu na każde zapytanie, a zapytań tych są setki, kod tych aplikacji jest jeszcze bardziej złożony (mowa o milionach linii kodu). Razem wygląda tak jak poniżej: Struktura monolitycznego ERP Efekt? Kastomizacja tak złożonego kodu to praktycznie pewna porażka, a niestety oferują to w zasadzie wszystkie…
Ponieważ projekty informatyczne są traktowane jako projekty technologiczne i najczęściej zlecane dostawcom technologii. To największy błąd, jaki można popełnić. W tym miejscu chciałbym zwrócić uwagę, że wymagania dzielą się na funkcjonalne i niefunkcjonalne. Wymagania niefunkcjonalne nigdy nie stanowiły problemu, ale wymagania funkcjonalne zawsze są problemem. Dlaczego więc zarządzanie projektami powierza się dostawcom technologii? Architektura korporacyjna – stary model SOA Poniższy schemat (Street, K. (2006). Budowanie architektury zorientowanej na usługi z wykorzystaniem BPM i MDA. 2(1), 8.) ilustruje kluczowe warstwy (poziomy) opisu organizacyjnego: procesy biznesowe usługi biznesowe (wymagane przez biznes) komponenty…
Zależnie od szacunków (czyli od tego jak zdefiniowano sukces) 60 - 80% projektów IT to nieudane projekty. Pod pojęciem projektu IT rozumiemy tu systemy dla firm: szeroko pojęte systemy biznesowe. Na świecie każdego dnia inicjowanych są setki tysięcy projektów IT dla firm, śladowe ilości nowych gier i w zasadzie żaden nowy system operacyjny (co najwyżej jego drobne rozszerzenia i aktualizacje). Dlatego nie ma sensu by w projektach biznesowych stosować wzorce i metody sprawdzone w tworzeniu gier czy środowisk technologicznych. Dlatego zlecanie projektów biznesowych od razu deweloperom ma bardzo nikłe szanse…
Wprowadzenie W roku 2024 pisałem: Jak widać czasami łatwo pomylić pojęcia model i mechanizm, można jednak powiedzieć, że model to schemat obrazujący coś, zaś mechanizm to wyjaśnienie zjawiska (tego jak coś powstaje jak działa). Mechanizm można zobrazować w postaci modelu. Jeżeli dążymy by model był idealizacją, to wtedy właśnie:"Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm." (Craver & Tabery, 2019) Patrz: Mechanizm działania vs model systemu vs diagram – Jarosław Żeliński IT-Consulting A co z komputerami…
Wprowadzenie W kwietniu 2024 roku opisywałem API Artykuł powyższy polecam osobom zainteresowanym stroną techniczną projektowania integracji i API. Dzisiaj odpowiem na problemy jakie zgłaszają prawnicy, czyli co jest przedmiotem umowy gdy przedmiotem tym jest mityczne API. (https://it-consulting.pl/2024/04/05/api-to-cos-innego-nie/) Wtedy problemem była próba traktowania oryginalnego API systemu ERP jak dedykowanej aplikacji, czy odrębnego kodu (licencja na API). Problemem jest często także poprawne nazewnictwo tego "o czym mowa", są to nieporozumienia (lub celowe działanie) wywoływane ukrywaniem architektury przez dostawcę oprogramowania. W między czasie trafiła się dzisiaj ciekawa, krótka dyskusja o API na "Anonimowy…
Wprowadzenie Aplikacje Jira i Confluence firmy Atlassian są bardzo popularne nie tylko w działach IT. Obie wspierają między innymi prace analityczne i projektowe na poziomie zadań (Jira) i treści (Confluence). Producent pakietu CASE Visual Paradigm, od wersji 17.3 wspiera integrację swojego pakietu z tymi aplikacjami, w efekcie w tych środowiskach możliwa stała się pełna integracja zespołu projektowego wykonawczego z analitykami i projektantami. Płynna integracja z Atlassian Confluence Zastosowanie: Agile Development: Udostępnianie zaktualizowanych przepływów pracy i diagramów UML w dokumentacji sprintu. Zarządzanie produktem: Osadzanie modeli procesów na stronach specyfikacji produktu. Architektura…
Wprowadzenie Jedną z największych pomyłek inżynierii oprogramowania jest dziedziczenie, czyli odtwarzanie w kodzie taksonomii modeli pojęciowych. Nie mniejszą pomyłką jest teza, że OO to łączenie funkcji i danych w obiekty (to jest antywzorzec projektowy, patrz np. DDD czy BCE). Obiektowy paradygmat to wymiana komunikatów między obiektami. Komputer nie przetwarza ani ludzi ani przedmiotów, więc odtwarzanie w architekturze kodu tego, że np. koń to rodzaj ssaka nie ma żadnego sensu, za to znakomicie komplikuje architekturę kodu. Utrwalanie tego w setkach powiązanych relacyjnie tabel dodatkowo komplikuje wszystko (kolejne setki linii kodu SQL).…
(źr.: https://www.redhat.com/en/topics/microservices/what-are-microservices)
Wprowadzenie Często spotykaną definicją mikro-serwisów jest W inżynierii oprogramowania architektura mikro-serwisów to wzorzec architektoniczny, który organizuje aplikację w zbiór luźno powiązanych, drobnoziarnistych usług, które komunikują się za pośrednictwem lekkich protokołów. Wzorzec ten charakteryzuje się możliwością niezależnego opracowywania i wdrażania usług, poprawiając modułowość, skalowalność i zdolność adaptacji. Wprowadza on jednak dodatkową złożoność, szczególnie w zarządzaniu systemami rozproszonymi i komunikacją między usługami, czyniąc początkową implementację trudniejszą w porównaniu do architektury monolitycznej. (https://en.wikipedia.org/wiki/Microservices) To samo źródło dalej: Nie istnieje jedna, powszechnie uzgodniona definicja mikro-serwisów. Ogólnie jednak charakteryzują się one skupieniem na modułowości, a…
Wprowadzenie W marcu 2021 w artykule Struktury formularzy jako forma wyrażania wymagań skupiłem się na detalach treści formularzy ekranowych, jako elementach specyfikowania przypadków użycia. Artykuł ten sprowokował pytania o związki między formularzami, ich przepływy oraz niekończące się pytania o cel stosowania związków extend i include używane często niepoprawnie w celu pokazania "przepływu ekranów". Dlatego napisałem post będący rodzajem kontynuacji tego tekstu. W toku analizy biznesowej, a potem projektowania oprogramowania, powstają różne produkty: modele procesów biznesowych, modele architektury systemów, scenariusze integracji, definicje interfejsów, i inne. Większość ich jest niezrozumiała dla przeciętnego…
Wprowadzenie W branży IT dość często mylone są pojęcia dotyczące techniki i technologii. Dobrym więc ruchem było uporządkowanie tego. Na stronie Rady Języka przy Prezydium Polskiej Akademii Nauk ukazała się ciekawa publikacja (jako, że to definicje, które omówię, cytuję w całości) : Definicje podstawowych pojęć związanych z techniką i technologią Komunikat Zespołu Terminologii Informatycznej RJP Nr 2/2021 z 16 czerwca 2021 roku Definicje podstawowych pojęć: {technika|technologia}{informacyjna|przetwarzania informacji|informatyczna|cyfrowa} Wychodząc od zasady, że częścią pojęcia „technika” jest „technologia”, a z kolei w definicji „technologii” należy się odwołać do użytych technik (tzw. definicja rekurencyjna), przedstawiamy zestaw tych definicji.…
