Jak wyjść z długu technologicznego jakim jest centralny monolityczny system

Na temat tego jakim uciążliwym długiem technologicznym jest monolityczny system napisano wiele, dzisiaj kolejne dwie ciekawe pozycje literatury: CMMI Compliant Modernization Framework to Transform Legacy Systems oraz Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices . Pierwsza publikacja opisuje metodę zaplanowania wyjścia z długu technologicznego z perspektywy analizy biznesowej, druga opisuje możliwą realizację techniczną z perspektywy architektury aplikacji i ewolucyjnej migracji z architektury monolitycznej do komponentowej (mikro-serwisy). Czym jest monolit? Jest to system, którego architektura stanowi jeden niepodzielny blok realizujący funkcje biznesowe. Kluczową cechą i zarazem wadą,…

Czytaj dalejJak wyjść z długu technologicznego jakim jest centralny monolityczny system

Koncepcja rozszerzenia wzorca projektowego BCE

Streszczenie: W pracy przedstawiono metodę projektowania architektury oprogramowania od ogółu do szczegółu z pomocą metamodeli definiowanych jako profili UML. Pokazano zaletę jaką jest możliwość szybkiego rozpoczęcia prac projektowych i testowania efektów mimo braku detalicznej wiedzy o danych. Metoda zakłada, że dane są zorganizowane z nazwane dokumenty o określonej strukturze. W trakcie prac analitycznych i projektowych wystarczającą wiedzą jest to jakie dokumenty są (będą) przetwarzane, zrozumienie ich celu i opis zawartości. Detaliczne szablony dokumentów (pola i ich zawartość) mogą pozostawać nieznane prawie do końca analizy i projektowania, wymagane są dopiero na…

Czytaj dalejKoncepcja rozszerzenia wzorca projektowego BCE

Plansza do gry w szachy czyli analiza i projektowanie

Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

(wię­cej…)

Czytaj dalejPlansza do gry w szachy czyli analiza i projektowanie

Semantic Core czyli bat na szczegóły

Bardzo często zastanawiam się, nad przyczynami porażek projektów, przyczynami tego, że jedne są lepsze inne gorsze, a gorszy to taki, który wymyka się spod kontroli a ostateczny efekt (produkt), uzyskany po znacznie dłuższym czasie niż planowano, jest zaskoczeniem dla wszystkich. Na to nakłada się problem przekazywania wiedzy pomiędzy kolejnymi etapami projektu, gdzie największym ryzykiem jest zrozumienie problemu i przekazywanie wiedzy przez samego zamawiającego. Gdzie problem? Ten artykuł polecam "biznesowi" który szuka przyczyn swoich problemów, i tym (nie tylko analitykom), którzy mają ambicje robić coś w kierunku poprawy tego stanu rzeczy, zamiast uznawać obecne statystyki za pewnik bo "takie są fakty". [...] Ktoś może powiedzieć: biznes tego (notacje, modele itp.) nie rozumie. I ma racje, bo to narzędzia a nie produkty analiz. Produktem analizy dla biznesu są zawsze rekomendacje (wymagania na oprogramowanie to także rodzaj rekomendacji brzmiącej: zalecam by takie warunki spełniało to oprogramowanie). Zamawianie przez biznes modeli jako takich, to jakieś koszmarne nieporozumienie. To tak jak by np. prawnik, jako produkt zlecenia "opinia prawna" oddał wybrany stos kodeksów z komentarzami. Nie, dobry prawnik oddaje jedna stronę rekomendacji: opinie prawną. To, że skorzystał z tych kodeksów to jego narzędzie pracy, możliwe, że załączy je do tej tej opinii (ale raczej jako materiał dla innego prawnika lub audytora).

Czytaj dalejSemantic Core czyli bat na szczegóły

Pojęcia, reguły i fakty czyli o czym oni mówią…

Słownik pojęć (często występuje w dokumentach jako czysto polskie słowo glossariusz ;)) bywa często przedmiotem burzliwych negocjacji, bo nie raz (a w zasadzie zawsze ;)) biznes stosuje slang, w którym to samo słowo ma różne znaczenie, zależnie od kontekstu użycia. Może to mieć sens w języku mówionym gdy pełna treść wypowiedzi daje ten kontekst, ale na poziomie analizy i projektu każde pojęcie musi mieć jedno unikalne znacznie mimo braku kontekstu (tym bardziej, że np. nazwy klas nie są elementami pełnych zdań ani opowieści :)).[...] Biznes także musi zrozumieć, że ma dwa różne elementy opisu swoich działań: praca z dokumentami i tworzenie dokumentów. Jednak uznanie tego faktu to jedno, nie wierzę w to, że biznes się tego nauczy, bo nie nauczył się formalnego opisu lub modelowania procesów podczas wdrożeń ISO, jednak uważam, że biznes nie ma takiej potrzeby. Moim zdaniem od dobrego analityka nie ma ucieczki, to inna kompetencja. Nie ma ucieczki od projektantów mody mimo istnienia kobiet chcących mieć ładne sukienki i bardzo dobrych krawców. Nikt tu nikogo nie zastąpi.

Czytaj dalejPojęcia, reguły i fakty czyli o czym oni mówią…

Domain Driven Design UML Stereotypes – rozszerzenie w narzędziach Microsoft

Niedawno pisałem, że lubię i polecam styl DDD. Dlaczego? Bo nawet jak nie znamy przyszłych zmian (nowych wymagań) to na pewno projekt będzie się dało rozbudować zamiast zmieniać. Dlaczego? Bo jeśli projekt dobrze ?modeluje? rzeczywistość to znaczy, że jeśli tylko coś zmieni się w tej rzeczywistości, to będzie to możliwe do takiego samego odwzorowania w projekcie (Domain-Driven Design ? nie metoda a styl?.). Można o tym także przeczytać na blogu MSDN: Domain Driven Design (DDD) is especially suitable for creating long-term LOB Apps, but usually, DDD is presented as a very…

Czytaj dalejDomain Driven Design UML Stereotypes – rozszerzenie w narzędziach Microsoft

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Kim więc jest dobry analityk? Jest to projektant, który potrafi analizowaną organizację "rozłożyć na elementy składowe". Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie "rysunek". Jest modelem w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję i zasady wzajemnego łączenia. Analiza Biznesowa to rozłożenie analizowanego "przedmiotu" na skończony zestaw elementów, który z określoną dokładnością zachowuje się jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania. Poziomy szczegółowości wymagań to: cele biznesowe (produkty procesów biznesowych) opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania) opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)

Czytaj dalejPoziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Czym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.

zły model to złe oprogramowanie.... Duży system ERP to setki i tysiące jego przypadków użycia, nie ma sensu ich specyfikowanie podobnie jak nie ma sensu pytanie o nie przyszłych użytkowników tego systemu bo nie są w stanie ich wyliczyć. Ma jednak sens zrozumienie tego jak firma działa. Po raz kolejny posłużę się metaforą [[Martina Fowlera]]: grę w snookera można opisać relacjonując (zapisując) setki kolejnych partii, ale i tak nigdy nie wyspecyfikujemy nawet ułamka możliwych zagrań. Zdecydowanie lepszą metodą jest przyjrzenie się kilku partiom i wychwycenie cech bili, ich ilości, wymiarów stołu oraz reguł gry, bo to będzie zgodne nie tylko z historią odegranych partii snookera ale z każda przyszłą partią. Dlatego zamiast prowadzenia żmudnych wywiadów i tworzenie nieskutecznej listy setek szczegółowych opisów możliwego użycia oprogramowania, lepiej jest zrozumieć organizację, stworzyć jej model (dziedziny) i wyspecyfikować jakie usługi ma to oprogramowanie świadczyć użytkowników teraz (bo tak należy rozumieć pojęcie przypadku użycia systemu). Poprawny model dziedziny pozwoli także na obsługę przyszłych wymagań mimo, że nie znamy ich teraz. Podobnie jak stół bilardowy: nie zna przyszłych uderzeń ale wiemy, że na pewno zostaną "obsłużone".

Czytaj dalejCzym jest to co modelujesz w oprogramowaniu? Model dziedziny systemu jako wymaganie.

Hurtownie danych czyli Systemy od historii”

Hurtownia danych to model stworzony pod kątem przetwarzania faktów historycznych na prostym modelu danych (diagram powyżej, górny, to tak zwana kostka OLAP). Opracowanie takiego modelu wymaga specjalnej analizy i projektu, ale nie zapominajmy: analizę się robi raz a raporty stale... Tak więc szanowni Państwo. Jeśli tylko Wasza firma jest bliżej czołówki niż ogona rankingu rynku w Waszej branży, nie dajcie się namówić na jeden zintegrowany ERP i jakiś model referencyjny, bo nawet jak uda się go wdrożyć, to zmiana czegokolwiek będzie trudna a upgrade do nowszej wersji niemożliwy. Opracowanie projektu systemu składającego się z komponentów, pozwoli Wam dobrać najlepiej spełniające Wasze wymagania aplikacje. Jak z klocków LEGO złożycie "dedykowany system" pomagający utrzymać przewagę na rynku, a nie cofający Waszą firmą do poziomu "innych podmiotów w branży".

Czytaj dalejHurtownie danych czyli Systemy od historii”

Czas nie jest aktorem dla Systemu c.d. czyli projekt

aktorem absolutnie nie jest Czas, aktorem jest inny system, tu źródło sygnału czasu. Diagram UC jest zgodny ze standardem a my "zrozumieliśmy istotę rzeczy". Stosowanie w analizie standardów prowadzi do rozumienia i ma taką właśnie zaletę: analiza i modelowanie prowadzi do zrozumienia problemu, łamanie zasad notacji ukrywa niezrozumienie problemu (o co chodzi z tym oczekiwanym przez klienta czasem).

Czytaj dalejCzas nie jest aktorem dla Systemu c.d. czyli projekt
Cykl tworzenia oprogramowania metodą zorientowaną na modele (Model Driven Development)
MDA Development Sequence (źr. Business Process Trend Newsletter, Maj 2004 nr. 5)

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że "nie święci garnki lepią") dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi "projektowania" czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści. Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to: Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu. Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu. Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: "wiedza organizacji" tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalejHej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Domain-Driven Design – nie metoda a styl.…

Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: "Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku." Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak ta metoda i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie." (źr. [[Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997]]).

Czytaj dalejDomain-Driven Design – nie metoda a styl.…

Koniec treści

Nie ma więcej stron do załadowania