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żynier systemów biznesowych i projektant oprogramowania. Jestem pomostem między biznesem a deweloperem.
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.
Booch, G. (1994). Object-oriented Analysis and Design with Applications. 2nd Edition, the Benjamin/Cummings Publishing Company, Inc.
Wprowadzenie Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn: "People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you?ve worked through a set of user stories? No. Not even close!" ["Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!".] (https://www.linkedin.com/posts/rossronald_people-love-stories-are-user-stories-helpful-activity-6935627008265633793-Bpzb/) Świat od dekad boryka…
Wprowadzenie Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji ? podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…
Architektura Projekty informatyczne się rozrastają, cała branża ewoluuje. Ostatnie 20 lat doświadczeń pokazało, że owszem sztuką jest stworzyć i wdrożyć oprogramowanie, ale jeszcze większą sztuką jest je konserwować, zmieniać i rozwijać. Wiele firm boryka się z powtarzanymi długotrwałymi i kosztownymi "analizami przedwdrożeniowymi" poprzedzającymi każdy kolejny projekt wdrażania zmian. To skutek braku aktualnej dokumentacji posiadanego systemu. To jak planowanie nowej budowy w mieście nie mając aktualnych planów urbanistycznych tego miasta: każdy nowy projekt to ponowne dokumentowanie stanu obecnego, tylko dlatego, że ktoś nie udokumentował zmian wprowadzonych ostatnim razem (być może poprzednio…
Artykuł ma dwie części. Pierwsza część jest adresowana do kadr zarządczych, cały artykuł (obie części) do osób zajmujących się projektowaniem rozwiązań.
Wstęp
Mamy ogólnoświatową sieć Internet, aplikacje lokalne i w chmurze, aplikacje naszych kontrahentów i aplikacje centralnych urzędów. Wszystkie one współpracują i wymieniają dane, czyli są zintegrowane. Dlatego integracja stała się cechą każdego systemu informatycznego.
Wyjątkowo na początku (poniżej) umieszczam cały ten ciekawy referat, można bo pominąć i czytać dalej, jednak jeżeli ktoś chce poznać przewidywania z roku 2016 i ma czas, polecam (teraz lub później):
The Future of Software Engineering ? Mary Poppendieck ? GOTO 2016
Obecnie kluczowym pytaniem jest: Jak zintegrować, a nie: Czy zintegrować.
Pogodzenie się z tym, że świat systemó ERP już nigdy nie będzie tak prosty jak w czasach mainframe’ów, czyli jednej centralnej aplikacji, jest nieuniknione.
Czym jest obecnie integracja? To wymiana danych a nie ich współdzielenie: dane z urzędem wymieniamy, dane z kontrahentem wymieniamy, nie współdzielimy żadnych danych z tymi podmiotami, każdy ma swoje własne, bezpieczne bazy danych, i to wszystko ładnie działa! Idea zbudowania wszystkich funkcjonalności jako zintegrowanej aplikacji na jednej współdzielonej bazie danych w czasach obecnych jest utopią. Taką samą jak hipotetyczna centralna baza danych dla wszystkich sklepów internetowych, firm kurierskich i banków, a one są jednak zintegrowane: one wymieniają dane a nie współdzielą!
ERP to (ang.) Enterprise Resource Planning czyli Planowanie Zasobów Przedsiębiorstwa. To system wykorzystywany przez firmy do zarządzania i integrowania ważnych elementów ich działalności. Ale kto powiedział, że to ma być monolit od jednego producenta?
Nadal spotykam pejoratywne określenia “system pointegrowany” jako krytykę budowy systemu ERP z komponentów i integracji jako wymiany danych. Autor tego określenia najprawdopodobniej nadal żyje w świecie mainframe.
Chociaż dostawcy systemów ERP oferują aplikacje dla przedsiębiorstw i twierdzą, że ich zintegrowany system jest najlepszym rozwiązaniem, wszystkie moduły w jednym systemie ERP rzadko kiedy są najlepsze z najlepszych.
Produktem modelowania procesów biznesowych są jakieś diagramy, i z tym jesteśmy oswojeni. Od czasu do czasu można usłyszeć o symulacjach procesów, lecz to już jednak znacznie rzadziej. O symulacjach procesów pisze się mniej: Google Scholar (literatura naukowa) pokazuje ok. 5 mln publikacji na temat modelowania procesów biznesowych, na temat ich symulacji 2 mln mniej. Ale już Google (“cały Internet”) odpowiednio: 2,3 mld. i 282 mln. Jak widać w powszechnym obiegu symulacje, jako temat, to trzy rzędy (tysiąckrotnie) mniejsza ilość tekstów! (wyszukiwane były hasła ang. ‘business process modeling’ oraz ‘business process simulation’). Zastanówmy się dlaczego i co można osiągnąć symulacją.
Ronald G. Ross Ronald G. Ross jest autorem lub współautorem wielu opracowań na temat modeli pojęciowych i zarządzania wiedzą . Jest także współzałożycielem Business Rule Solution LLC, oraz współtwórcą specyfikacji i notacji SBVR . Książka Najnowsze z powyższych opracowań to rodzaj podsumowania pewnej części dorobku autora. Modele pojęciowe są często mylone z projektowaniem relacyjnego modelu danych, a bywa gorzej, gdy są utożsamiane z "modelem dziedziny systemu" w projektach dotyczących tworzenia aplikacji określanych jako"obiektowe". Książka traktuje o modelach pojęciowych, i autor definiuje je jako: model pojęciowy: uporządkowany zbiór pojęć i związków…
Practical Event-Driven Microservices Architecture Building Sustainable and Highly Scalable Event-Driven MicroservicesHugo Rocha ma prawie dziesięcioletnie doświadczenie w pracy z wysoce rozproszonymi, sterowanymi zdarzeniami architekturami mikroserwisów. Obecnie jest szefem inżynierii w wiodącej globalnej platformie ecommerce dla produktów luksusowych (Farfetch), świadczącej usługi dla milionów aktywnych użytkowników, wspieranej przez architekturę sterowaną zdarzeniami z setkami mikroserwisów przetwarzających setki zmian na sekundę. Wcześniej pracował dla kilku referencyjnych firm telekomunikacyjnych, które przechodziły od aplikacji monolitycznych do architektur zorientowanych na mikroserwisy. Hugo kierował kilkoma zespołami, które każdego dnia bezpośrednio stykają się z ograniczeniami architektur sterowanych zdarzeniami. Zaprojektował…
This time a short article about an interesting construction. It was described by Rebecca Wirfs-Brock in 1999 (Miller & Wirfs-Brock, 1999) . The idea did not gain much popularity at the time, but now, in the era of patterns based on microservices and micro applications, it has a chance to come back into favour. I've been using it for a long time (see interface-oriented design). The abbreviations HLD and LLD are High-Level Design and Low-Level Design, respectively. These are the levels of abstraction in the PIM model. It is also a description of the design style of an interface-oriented system architecture (interface-oriented architecture).
Lektura na Nowy Rok... Co prawda wydana w 2007 roku, ale właśnie sobie o niej przypomniałem.. Ta książka Yourdona leży u mnie na półce niemalże od dnia jej wydania, gdy ją przypadkiem upolowałem, zaraz po jej ukazaniu się w księgarniach. Napisanie o niej odkładam od lat, bo praktycznie nie ma tam obrazków UML, opisów wzorców itp.. Od jej przeczytania mówię sobie: jutro o niej napiszę... i to trwało do tego momentu. To książka w całości napisana prozą, bez obrazków, w której autor dzieli sie swoimi przemyśleniami na temat architektury systemów,…
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”).
![Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]](https://it-consulting.pl/wp-content/uploads/2022/05/image-14-590x397.png)
