Wprowadzenie

Bardzo często można w książkach i na blogach spotkać opisy wzorców architektonicznych, wzorców projektowych, dobrych praktyk. Jednak bardzo rzadko autorzy piszą o tym kiedy je stosować. Sam fakt, że jakiś wzorzec “rozwiązuje jakiś problem”, co jest celem tworzenia i stosowania danego wzorca, nie mówi nic o tym jak często i kiedy dany problem się pojawia.

Komputer może być częścią firmy, samochodu, lodówki, telewizora, może być platformą dla oprogramowania użytkowego albo dla gier komputerowych, ale te – użyte – staja sie częścią tego komputera (gramy na komputerze a nie na grze). Oprogramowanie użytkowe czy gry komputerowe (to też oprogramowanie) mają pewne cechy. Kluczową cechą jest zmienność mechanizmu działania lub całkowity brak takiej zmienności. W efekcie inne problemy rozwiązuje projektant gry czy systemu operacyjnego (tu w zasadzie nic sie zmienia), a inne projektant aplikacji której zadaniem jest np. zgodne z prawem fakturowanie wyprodukowanych wyrobów czy zrealizowanych usług (tu zmiany mogą zachodzić nawet kilka razu w roku).

Tak więc owszem, software to “słoń w pokoju” inżynierii [zotpressInText item=”{5085975:Y3KLU3JX}”].

Komputer

Komputer to generalnie procesor, pamięć i program. Jako materialna całość stanowi sobą jednak dość skomplikowane urządzenie zawierające także porty i urządzenia wejścia i wyjścia, a także elektromechaniczną część czyli zasilanie, obudowę, klawiaturę, ekran, mysz, wentylację itp. Nie zmienia to faktu, że jest to urządzanie realizujące określony mechanizm, jego zachowanie się “jest programowane”, czyli zachowanie się tego urządzenia jest efektem wykonywania przez procesor komputera kodu programu przechowywanego w pamięci, ten zaś jest niczym innym jak procedurą (zestawem procedur). Dlatego mówimy, że komputer to uniwersalny mechanizm [zotpressInText item=”{5085975:ZCXJ2S7U}”].

Urządzeniami wejścia i wyjścia mogą być nawet bardzo skomplikowane konstrukcje elektromechaniczne a całość może być nie tylko maszyną do pisania ale także robotem przemysłowym czy autonomicznym samochodem. Większe systemy (mechanizmy) dzieli się często na mniejsze części: komponenty, a te – każdy – może być samodzielnym urządzeniem zawierającym komputer. Notebook, który prawdopodobnie czytelnik tego tekstu ma teraz przed sobą, to złożone urządzenie. Wiele jego komponentów: dysk twardy, karta graficzna, klawiatura, ma swój procesor.

Wiele urządzeń, pierwotnie w 100% elektromechanicznych, ewoluuje do hybrydy: urządzenie elektromechaniczne + komputer, nazywamy to urządzeniem “mechatronicznym”. Prostym i typowym przykładem są zegary i programatory mechaniczne (np. pralki, obrabiarki). Bardziej wyrafinowane są urządzenia przetwarzające sygnały (zamiana analogowych urządzeń na cyfrowe), np. telefonia i telewizja. Proces ten postępuje (np. zegar obecnie może być w 100% komputerem). System ERP to też takie urządzenie.

Poniżej wykres pokazujący rosnący udział kosztów oprogramowania w urządzeniach, odpowiada to temu, że coraz więcej funkcji w tych urządzeniach realizuje (przejmuje) komputer [zotpressInText item=”{5085975:I7N5YSN4}”]. Trend ten nie jest nowy [zotpressInText item=”{5085975:2JAV96GM}”]. Więcej [zotpressInText item=”{5085975:NLT4Z5MI}”].

Jeżeli, kiedyś zegar odmierzał czas z pomocą wahadła i kół zębatych, a teraz role te pełnią procedury wykonywane przez procesor, to znaczy że komputer ma tę samą funkcjonalność co klasyczny zegar, ale nadal mechanizm pomiaru czasu to sekundy, minuty i godziny (patrz Zegar). Wielu autorów nazywa to wirtualizacją tego mechanizmu [zotpressInText item=”{5085975:5MQBZYDU}”].

Schematycznie urządzenie mechatroniczne mozna pokazać tak:

Są tu trzy kluczowe warstwy:

• hardware – sprzęt elektromechaniczny,
• firmware – sterowniki (ang. drivery) czyli interfejsy oferowane pomiędzy częścią elektromechaniczną a programową,
• software – funkcje systemowe i aplikacyjne, czyli właściwy kod, tu dobrą praktyką (wzorcem architektonicznym) jest wydzielenie (oddzielenie kodu, implementacji) kodu logiki dziedzinowej, reszta to tak zwane środowisko systemowe: system operacyjny i jego otoczenie.

Znakomita większość tej układanki to standardowe produkty, które praktycznie nie są modyfikowane od momentu ich wytworzenia. Są to: sprzęt oraz sterowniki dostarczane wraz z nim, systemy operacyjne i środowiska programistyczne (system operacyjny, biblioteki programistyczne, kompilatory). Pozostaje clue czyli wirtualizowany mechanizm co pokazano poniżej:

Jeżeli więc wirtualizujemy jakiś mechanizm jako program komputera, to kodowanie (pisanie kodu w jakimś języku programowania) de facto jest konfigurowaniem zachowania tego komputera. Pozostaje jedynie wcześniej opisać lub zaprojektować wirtualizowany mechanizm (opracować dokument zawierający modele np. w notacji UML).

Model systemu i ochrona wartości intelektualnych

Z perspektywy dziedziny zwanej informatyką lub technologią informatyczną, najczęściej mamy do czynienia z oprogramowaniem określanym jako aplikacje biznesowe. Jest to oprogramowanie wspomagające zarządzanie takie jak CRM, ERP, workflow itp. ale także sklepy internetowe czy kasy samoobsługowe. Aplikacje te często pochodzą z różnych źródeł i wtedy są integrowane (patrz Integracja ERP).

Struktura systemu informatycznego w średniej wielkości organizacji może schematycznie wyglądać jak pokazano poniżej:

Warto tu zwrócić uwagę na kwestię tego czym tu są, i czyje są, chronione wartości intelektualne (ang. IP, Intellectual Properties). Na powyższym diagramie w zasadzie każdy element może być licencjonowany od innej firmy. Coraz częściej jednak zdarza się, że organizacja, w pewnym obszarze, cechuje się pewną własną, unikalną logiką działania. Rzadko jest to więcej niż 10% całości mechanizmów działania danej organizacji gdyż większość wymuszają prawo i standardy branżowe. Jednak organizacje, szczególnie te które wyróżniają sie na rynku, cechują się pewna specyfiką, unikalnym elementem sposobu swojego działania. Wtedy powstaje potrzeba stworzenia dedykowanego oprogramowania (Custom Application). Wymaganiem wobec oprogramowania, czyli de facto komputera, jest ten specyficzny mechanizm działania, który musi zostać opisany aby możliwa była jego ochrona jako ww. wartości intelektualne i jego odtworzeniem z pomocą komputera (wirtualizacja). Np. archiwum treści w postaci e-booków to nic innego jak zwirtualizowane archiwum papierowe wraz z zasadami dostępu do zasobów, rejestracją udostępniania itp.

Od wielu lat toczą się spory na temat tego czy i jak chronić to powyżej opisano. Aktualne prawodawstwo powoli ale systematycznie zmierza jednak do tego, by chronić opis mechanizmu a nie kod, który go implementuje:

Prawa autorskie, chociaż nie doprowadziły do tak wielu jawnie absurdalnych zgłoszeń, zostały mocno rozciągnięte przez sądy. Pojęcie, pierwotnie mające na celu ochronę prac literackich, zostało tak rozszerzone, iż zawiera takie pisarskie „prace” jak programy komputerowe czy nawet kod maszynowy i kod wynikowy, którym bliżej do elementów maszyn, takich jak krzywka, niż do prac literackich. [zotpressInText item=”{5085975:QAHTAUZ4},{5085975:Y4W6IFZI}”]

Na tym tle ciekawe jest:

2.6. Wystarczające ujawnienie
Opis wynalazku powinien przedstawiać (ujawniać) wynalazek na tyle jasno i wyczerpująco, aby znawca mógł ten wynalazek urzeczywistnić, a ekspert mógł dokonać rzeczowej analizy porównawczej z dotychczasowym stanem techniki. Za „znawcę z danej dziedziny” uważa się przeciętnego praktyka dysponującego przeciętną, ogólnie dostępną wiedzą z danej dziedziny w odpowiednim czasie, który dysponuje typowymi środkami i możliwościami prowadzenia prac i doświadczeń. Przyjmuje się, że specjalista taki ma dostęp do stanu techniki; tzn. informacji zawartych w podręcznikach, monografiach, książkach. Zna także informacje zawarte w opisach patentowych i publikacjach naukowych, jeżeli wynalazek dotyczy rozwiązań, które są na tyle nowe, że nie są zawarte w książkach. Ponadto, potrafi korzystać ze stanu techniki w działalności zawodowej do rozwiązywania problemów technicznych. Przedstawiony wynalazek powinien więc nadawać się do odtworzenia bez dodatkowej twórczości wynalazczej. Pod pojęciem tym należy rozumieć dodatkową działalność umysłową, eksperymentalną związaną z niepełną informacją techniczną zawartą w opisie wynalazku, a także konieczność dodatkowych uzupełniających badań naukowych, niezbędnych do realizacji rozwiązania według wynalazku w pełnym zakresie żądanej ochrony. Odtworzenie wynalazku powinno być możliwe na podstawie przeciętnej wiedzy specjalisty w danej dziedzinie, bez nadmiernego wysiłku. [zotpressInText item=”{5085975:Y86V5TMQ}”].

Z perspektywy tematu tego tekstu w miejsce słowa “wynalazek” wystarczy wstawić słowo “produkt” (lub komputer). Dlatego niektórzy autorzy operują pojęciem “testu urzędu patentowego: “czy to COŚ można zgłosić jako patent”, i niestety żaden kod źródłowy nie spełnia twego warunku. Tu autor wynalazku (produktu) to projektant, zaś znawca zdolny do jego urzeczywistnienia, to deweloper.

Bezpieczeństwo

Kilka słów o bezpieczeństwie. W obszarze tak zwanego cyberbezpieczeństwa mówi się o podatnościach:

Podatności to luki w systemach informatycznych, które mogą być wykorzystane przez atakujących do uzyskania nieautoryzowanego dostępu do danych lub systemów. Mogą one wynikać z błędów w oprogramowaniu, niewłaściwej konfiguracji systemów, słabych haseł czy też zaniedbania w aktualizowaniu oprogramowania. Podatności stanowią poważne zagrożenie dla bezpieczeństwa, ponieważ mogą być wykorzystane do przeprowadzenia różnorodnych ataków, takich jak kradzież danych, przejęcie kontroli nad systemami, czy też zakłócenie działania usług.

W praktyce podatności mogą przyjmować różne formy. Przykłady obejmują exploity wykorzystujące luki w oprogramowaniu, ataki typu SQL Injection, które wykorzystują słabe zabezpieczenia baz danych, czy też błędy w konfiguracji serwerów, które pozwalają na nieautoryzowany dostęp. Każda z tych podatności może prowadzić do poważnych konsekwencji, w tym utraty danych, naruszenia prywatności, a nawet strat finansowych. (https://nflo.pl/baza-wiedzy/czym-jest-zarzadzanie-podatnosciami-it-vulnerability-management-i-dlaczego-jest-kluczowe-dla-cyberbezpieczenstwa/)

Definicje, taka jak powyższa, skupiają się na “systemie informatycznym” jednak należy odróżnić wadliwość zaimplementowanego mechanizmu od wadliwości jego implementacji (błędy w kodzie) oraz celowego działania dewelopera (exploity). Innymi słowy podatnościami mogą być:

• niskiej jakości projekt (złe procedury w mechanizmie działania aplikacji),
• niskiej jakości implementacja (błędy koderów),
• celowe działania projektanta i/lub dewelopera.

Powyższe może dotyczyć każdej ww. warstwy. Czy certyfikaty chronią? Paradoksalnie bardzo słabo: wiele znanych z prasy włamań, a w dużych instytucjach wszystkie, to włamania do organizacji i ich systemów, które miały certyfikaty.

Bardzo niebezpieczne (stwarzają ogromne ryzyko) są monolityczne aplikacje (jeden błąd i cały system jest otwarty). Najskuteczniejszą metodą ochrony jest dzielenie systemu na komponenty bo mogą one kontrolować się wzajemnie, a podatność zamknie się jednym komponencie, czyli w razie ataku nie “padnie” cały system a jeden jego komponent. Te komponenty nie powinny pochodzić z jednej fabryki. Podział systemu na dziedzinowe aplikacje i ich integracja powoduje, że żaden dostawca nie ma “władzy” nad całością.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

W 2017 roku napisałem referat na pewną konferencję naukową studentów. Artykuł dotyczył architektury kodu. Jedną z ilustracji była ta:

Artykuł kończyłem słowami:

Nie chodzi więc o to by podzielić oprogramowanie na “składowe, które łączą w sobie możliwość przechowywania danych oraz wykonywania operacji”. Chodzi o to by mechanizm, o dowiedzionej poprawności, zaimplementować w określonej wybranej technologii.Chodzi też o to by nie udawać, że programowanie jako “podzielone na obiekty” partie kodu, nadal korzystające z jednej wspólnej bazy danych, różni się czymkolwiek od “strukturalnego kodu”. Chodzi o to by kod programu faktycznie implementował określony (zbadany i opisany) mechanizm. (źr.: Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania – Jarosław Żeliński IT-Consulting)

W 2021 roku opisałem Architektoniczne wzorce projektowe w analizie i projektowaniu modelu dziedziny systemu. Artykuł jest ukierunkowany na ich definicje i modelowanie. Tu kilka słów na temat tego “skąd się biorą i po co”.

(more…)

Wprowadzenie

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 [zotpressInText item=”{5085975:GCFN2QGC}”] oraz Practical Event-Driven Microservices Architecture: Building Sustainable and Highly Scalable Event-Driven Microservices [zotpressInText item=”{5085975:ADM6A5A3}”]. 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).

Jedno jest ważne: analiza tabel SQL w starym systemie jest najmniej efektywna metodą wyjścia z takiej aplikacji.

Czym jest monolit?

Jest to system, którego architektura stanowi jeden niepodzielny blok realizujący funkcje biznesowe. Kluczową cechą i zarazem wadą, monolitu jest wewnętrzna “zależność wszystkiego od wszystkiego”. Każda modernizacja z zasady dotyczy całego systemu, jest więc i bardzo kosztowna i bardzo ryzykowna.

W efekcie użytkownik jest uzależniony od jednego dostawcy, jakakolwiek zmiana organizacyjna pociąga za sobą prace porównywalne z nakładem środków i czasu jak w pierwotnym wdrożeniu tego systemu, a nie raz te koszty są większe. Upgrade takiego systemu, jeżeli był kastomizowany, zawsze wymaga powtórzenia całego wdrożenia od początku.

Jest to architektura rodem z lat 80-tych ubiegłego wieku (dlatego nazywana jest legacy system czyli system przestarzały), jej ogólna postać:

Architektura ta jest nadal główną cechą wielu systemów ERP na rynku, nawet tych bardzo znanych. W obecnych czasach jest to źródłem wielu kłopotów organizacji, które wdrożyły taki system i muszą szybko reagować na zmiany na rynku.

Wdrożenie w firmie jednego monolitycznego systemu ERP to tak zwany “big bang”, czyli wszystko albo nic, co w zasadzie nikomu sie nadal nie udało. Dlatego coraz częściej podejmowane są próby ewolucyjnego, bezpiecznego dla całej organizacji, płynnego wyjścia z tego długu jakim jest monolityczna architektura systemu IT. Jak to zrobić?

Etap 1: Analiza biznesowa

Na tym etapie należy zebrać dokumenty operacyjne: te opisujące posiadany “monolit” i te będące jego produktami (wydruki, formularze itp.). Analiza ich powinna zaowocować analitycznym modelem procesów biznesowych (modelowanie procesów). Dysponując tymi wszystkimi dokumentami oraz zebranymi oczekiwaniami interesariuszy, opracowujemy dokument wymagań wobec nowego systemu, w tym także jego ogólną architekturę:

Dokumentacja i utrzymanie wymagań:
KP 1.1 Przygotowanie Macierzy Śledzenia Wymagań w celu śledzenia spójnosci ich zmian
KP 1.2 Ustalenie ról i odpowiedzialności wszystkich uczestników projektu
KP 1.3 Omówienie potrzeb z interesariuszami i metod rozwiązania problemów
KP 1.4 Opracowana [w toku analizy] dokumentacja wymagań podpisana przez wszystkich interesariuszy

[zotpressInText item=”{5085975:GCFN2QGC}”]

Etap 2: Realizacja

Tu polecam drugą publikację. Jest to jedna z ciekawszych pozycji na mojej półce. Opisuje ona metodę migracji z monolitycznej do bardziej otwartej i zwinnej architektury. Odbywa się to powoli, i na początek raczej w głowach projektantów, później dopiero w projektach i wdrożeniach.

Jak już wspomniano wyżej, kluczową wadą monolitów jest ich ociężałość, skutkująca tym, że ich rozwój i rozbudowa bardzo szybko zmienia się w walkę w ich wielkością. Powodem tego jest właśnie owa silna wewnętrzna “zależność wszystkiego od wszystkiego”.

Pewnym postępem jest wewnętrzne “upilnowanie” dziedzinowej separacji modułów, jednak separacja ta ma miejsce wyłącznie w części kodu podzielonego na moduły, jednak “pod spodem” nadal jest monolit czyli współdzielona baza danych.

W czasach obecnych, gdy firmy i ich otoczenie, zmieniają sie szybko, kula u nogi w postaci współdzielonego zbioru danych powoduje, że podział aplikacji na odrębne moduły nie wnosi zbyt wielkiej wartości. Owszem poprawia zarządzalność kodem i ułatwia wprowadzanie nieznacznych zmian, ale nadal jest to monolit.

Pojawia się więc kwestia migracji z monolitu do bardziej zwinnej architektury mikro serwisów. Jak nie trudno się domyśleć, rewolucja nie jest dobrym pomysłem, dlatego autorzy opisują jak dokonać takiej migracji ewolucyjnie.

Natychmiast pojawia się pytanie jak to zrobić bezpiecznie dla biznesu? Odpowiedź jest prosta (patrz początek tego artykułu): należy zrozumieć mechanizm działania firmy, czyli opracować model procesów biznesowych na poziomie pozwalającym zidentyfikować kluczowe dziedzinowe aktywności i każdej z nich przyporządkować mikro serwis, a następnie odwzorować logikę biznesową aplikacji odwzorowując przepływ dokumentów jako przepływ komunikatów.

Stan docelowy będzie odwzorowywał aktualną logikę biznesową.

Każda usługa – mikroserwis – wspiera określoną aktywność biznesową. Fakt, że każdy mikroserwis sam zarządza swoimi danymi nie współdzieląc ich z innymi, powoduje, że wskazana wyżej główna wada monolitów, zwana “wszystko zależy od wszystkiego”, tu po prostu nie występuje. To z czym najczęściej walczą posiadacze monolitów podzielonych na komponenty to postać i liczba wzajemnych odwołań (radzimy sobie z tym wzorcami np. Saga, które już opisywałem).

Tak więc “tak wygląda problem”. Nie jest tu moim zamiarem streszczanie tych publikacji. Sposób narracji oraz wiele schematów blokowych i kodu, czyni je obie rarytasem i dla koderów i dla analityków, projektantów, architektów.

Gorąco polecam pierwszą publiakcje (dostępna bepłatnie) i zakup drugiej pozycji.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Szukasz pomocy?

Pomogę, zapraszam do kontaktu: NAPISZ DO MNIE.

Wprowadzenie

Tym razem krótka recenzja pewnej książki z roku 2006, a raczej jej polecenie każdemu projektantowi i architektowi dzisiaj. Na końcu polecam także kolejną nowszą pozycję jako uzupełnienie. Adresatami tej recenzji są głównie analitycy i projektanci, jednak adresuję ten wpis także do developerów, zakładam że dla nich nie jest to “coś nowego”, ale być może mają jakieś rady dla projektantów.

Warto także podkreślić, że pomiędzy OOP a OOAD jest coraz większa różnica i podział na role: analiza i projektowanie oraz implementacja, a także postępująca separacja tych ról, stają się standardem w inżynierii oprogramowania [zotpressInText item=”{5085975:NZCQDD79}”]:

Programming is not solely about constructing software, programming is about designing software.

[zotpressInText item=”{5085975:NZCQDD79}”]

Kolejna warta zwrócenia uwagi rzecz: projektowanie integracji systemów w organizacji to nic innego model systemu zorientowany na interfejsy (patrz wcześniejszy wpis: Integracja systemów ERP jako źródło przewagi rynkowe).

Zanim jednak wczytacie się Państwo z detale, polecam krótki referat Martina Fowlera z 2015 roku:

Recenzja

Interface-Ofriented Design [zotpressInText item=”{5085975:DQ85BDLN}”], to książka o architekturze i jej projektowaniu. We wstępie autor pisze (oryg):

Autor, na wielu przykładach pokazuje jak można projektować (tworzyć) oprogramowanie budując je ze współpracujących komponentów.

Wiele się mówi o programowaniu obiektowym a mało o projektowaniu zorientowanym na komponenty (moduły). Ważna rzecz: projektowanie zorientowane na interfejsy koncentruje się na komponentach i ich interfejsach, komponenty te mogą, ale nie muszą, być implementowane za pomocą języków obiektowych. Projekty, które skupiają się na komponentach i ich interfejsach mają ogromną zaletę: precyzyjnie opisują co ma program robić a jednocześnie nie narzucają narzędzia implementacji.

Kolejna rzecz to fakt, że obecnie znacznie bardziej niż w czasach gdy książka była pisana (ukazała się w 2006 roku), nabiera znaczenia rozproszona architektura: realnie nie ma już monolitów, mamy integracje systemów między partnerami handlowymi, z rejestrami publicznymi, między lokalnymi i chmurowymi infrastrukturami. Rozproszone przetwarzanie to architektury zorientowane na usługi, które kładą szczególny nacisk na interfejsy.

Interfejsy mogą być zorientowane na procedury (takie jak zdalne wywołania funkcji) lub na dokumenty (serwisy internetowe i integracje z protokołem RESTful API). Autor opisuje także wzorce i metody projektowania bazujące na luźnych powiązaniach, które są kluczowe dla budowania systemów rozproszonych. Więcej o interfejsach zorientowanych na dokumenty w moich projektach,

Ważna rzecz, na którą autor także zwraca szczególną uwagę: dziedziczenie jest często trudną do osiągnięcia techniką, jest to także często jedna z najbardziej nadużywanych cech języków obiektowych. Nacisk autora na interfejsy może wydawać się nieco ekstremalny, jednak (świeże w 2006 roku) spojrzenie na projektowanie architektury zorientowane na komponenty i ich odpowiedzialność, daje zaskakująco dobre efekty, a pamiętajmy, że generalnie liczy się cykl życia aplikacji (patrz także artykuł Znaczenie na cykl życia…) czyli koszty jej utrzymania i rozwoju, a nie samo jej wytworzenie. Warto pamiętać, że dziedziczenie z zasady łamie zasadę hermetyzacji i zalecane jest zastępowane go stosowaniem szablonów lub po prostu rezygnuje się z tej techniki na rzecz typów danych i kompozycji.

Podsumowując: Kluczowym przesłaniem autora jest “odejście” od “programowania obiektowego” (orientacja kodu na dziedziczenie oraz łączenie funkcji i danych w obiekty, OOP) na rzecz “projektowania zorientowanego na niezależne, luźno powiązane komponenty” (polimorfizm i hermetyzacja), cechującego się pełną separacją komponentów, luźnymi powiązaniami (tylko wywołania operacji) i pojedynczą odpowiedzialnością (OOAD).

Autor zwraca uwagę na sprawdzone wzorce, kluczowe: to fabryka (zwana także metodą wytwórczą, jest to separacja metod tworzenia obiektów od ich utrwalania), adapter (separacja współpracujących komponentów o niedopasowanych interfejsach). Co do zasady też (wzorce) separujemy przetwarzanie danych od ich samych (wzorzec repozytorium [zotpressInText item=”{5085975:ZIIDU6A9},{5085975:NVN9AR49},{5085975:ZBEHPADF},{5085975:8P6M5STE}”]). Dzisiaj dominujące są więc mikro serwisy i mikro aplikacje, natomiast łączenie danych i metod je przetwarzających w jednej klasie to antywzorzec.

Początek lat 2000 to nie tylko manifest Agile, to także już kilka lat po nim, nawoływanie sygnatariuszy Agile do porządku w inżynierii oprogramowania [zotpressInText item=”{5085975:P5PE3C3R}”]. Poza omawianą tu książką pojawiły się, w tamtym okresie, między innymi opis budowy komponentowej architektury [zotpressInText item=”{5085975:NSJBENX9}”], opis projektowania zorientowanego na odpowiedzialność komponentów [zotpressInText item=”{5085975:VNQDV6CQ}”].

Autor zwraca także szczególną uwagę na dokumentowe modele budowy interfejsów i integracji. Dokumentowe czyli zorientowane na przekazywanie między komponentami całych agregatów danych (zwanych dokumentami) zamiast wyników działania poszczególnych funkcji. Znakomicie upraszcza to architekturę, powoduje mniejsze uzależnienia, w konsekwencji cykl życia takiego systemu jest znacznie tańszy. O tym aspekcie architektury integracji pisał także znany autor Martin Fowfer [zotpressInText item=”{5085975:3BRMMXGI}”].

Zachęcam do lektury tej książki, porządkuje wiedzę, być może wielu z Was znajdzie coś nowego. Od siebie powiem, że podejście takie stosuję od czasów lektury Systemów zorientowanych komponentowe Souzy, czyli od ponad 15 lat…

A architekturze

Doskonałym i aktualnym uzupełnieniem tej książki jest napisana później Czysta architektura [zotpressInText item=”{5085975:QEGGUWKX}”]:

Dobrzy architekci ostrożnie oddzielają szczegóły od reguł biznesowych, robiąc to tak dokładnie, że reguły te nie mają żadnej wiedzy o szczegółach i w żaden sposób od nich nie zależą. Dobrzy architekci tak projektują reguły systemu, żeby wszystkie decyzje dotyczące szczegółów można było podejmować tak późno, jak to tylko możliwe.

Przy tej okazji polecam także prezentację opartą na treści książki [zotpressInText item=”{5085975:IWBHW8XL}”], szczególnie część o interfejsach, głębokości i płytkości klas: A Philosophy of Software Design | John Ousterhout | Talks at Google

OOP i OOAD czyli co dalej?

[2023-01-07]

Od wielu lat obserwuję rynek i projekty z zakresu inżynierii oprogramowania. Pojęcia OOP (programowanie obiektowe) oraz OOAD (analiza obiektowa i projektowanie) oddalają się od siebie. Techniki organizacji kodu rodem z C++/Java (mają współny rodowód) zdeterminowały pojmowanie pojęcia “programowania obiektowego”. Są to ciężkie metody pracy, oparte na starych wodospadowych założeniach (monolityczna architektura oparta na relacyjnym modelu danych) sprawdzają się tam, gdzie zmienność wymagań jest mała.

C++ znajduje zastosowanie w tworzeniu systemów operacyjnych (np. Windows XP czy Vista), a także podczas budowy aplikacji desktopowych (pakietu Office bądź produktów Adobe). Z wykorzystaniem C++ można spotkać się także podczas budowy baz danych oraz serwerów. Popularność C++ zdecydowanie nie słabnie wśród twórców gier. Sprawdza się świetnie nie tylko podczas produkcji prostych projektów 2D, ale także gier typu AAA.

Język Java stosuje się przede wszystkim w backendowej części budowy internetowych aplikacji. Wykorzystuje się go także w projektowaniu aplikacji desktopowych, korporacyjnych, a nawet całych serwerów aplikacji. Język Java stanowi podstawę działania aplikacji mobilnych oraz gier dla systemu Android. Java stosowana jest także w systemach bankowych i giełdowych.

źr.: https://work4.dev/blog/28/Czy-C-i-Java-sa-do-siebie-podobne.html

Systemy określane jako “biznesowe” to zupełnie inna klasa oprogramowania, to aplikacje budowane w oparciu o reguły biznesowe i odrębne dokumenty. Jedne i drugie szybko sią zmieniają, stosowaniu tu metod i narzędzi adekwatnych do budowy gier i systemów operacyjnych (one się zmieniają rzadko i nie służą do zarządzania danymi) prowadzi to do powstawania bardzo kosztownych w utrzymaniu i rozwoju systemów. Dlatego równolegle rozwijają się takie języki jak JavaScript, Ruby, PHP, Pyton, HTML czy Perl.

Analiza i projektowanie “obiektowe”, pierwotnie oparte na idei hermetyzacji, luźnych powiązaniach i interfejsach, tak na prawdę sprowadza się do poprzedzania kodowania projektowaniem architektury, a to “tylko” komponenty i ich współpraca, bez wnikania w technologie ich powstania, tym bardziej, że wiele z nich (komponenty) można kupić jako COTS (ang. Commercial off-the-shelf, gotowe komponenty z półki) bez wiedzy o ich wewnętrznej strukturze (czyli hermetyzacja).

Developerzy często posługują sie pojęciem klasy mając na myśli konstrukcje znane im z C++ czy Java. Poniekąd słusznie, bo faktycznie ich używają tworząc implementacją (pisząc kod). Na etapie analiz i projektowania detale kodu nie mają znaczenia, liczy się realizowana logika i architektura.

A gdzie tu UML? Mityczne generowanie kodu z UML nie wyszło poza mury akademickich entuzjastów tego pomysłu. Więc gdzie? Po oczyszczeniu z nadmiaru (redukcja UML), jest to doskonałe narzędzie do modelowania systemów i tworzenia sformalizowanych schematów blokowych. Czym jest klasa w UML? Wszystkim, a to co jest klasą w C++/Java to malutka część tego “wszystkiego”. Czy na etapie projektowania (model PIM) mamy na myśli klasy w rozumieniu konstrukcji kodu C++/Java? Nie, na tym etapie mamy komponenty (ale w UML wszystko jest klasą, komponent też), w zasadzie czarne skrzynki z interfejsami, które trzeba (wystarczy) opisać. To co opisze projektant zależy od niego: tam gdzie uzna, że daje swobodę deweloperowi poprzestanie na komponentach, ich interfejsach i procedurach (algorytmach) realizowanych przez te komponenty. Tam gdzie uzna, że to ważne, narzuca wybrane szczegóły (patrz Kto jest programistą).

Dlatego od bardzo dawna (patrz opisywana wyżej książka) mówi się i pisze, że projektowanie systemów to właśnie projektowanie zorientowane na komponenty i ich interfejsy. Implementacja jest zawsze wtórna. A to co można nadal spotkać w wielu podręcznikach i analizach pod nazwą “diagram klas”, to często poprawne i zarazem bezwartościowe diagramy w UML (Patrz UML dla programistów Java).

Na zakończenie ciekawa prezentacja: najpierw projektowanie, kod na końcu.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC” cite=”yes”]

Wprowadzenie

Tym razem krótki artykuł na temat pewnej ciekawej konstrukcji. Została ona opisana przez Rebekę Wirfs-Brock w 1999 roku [zotpressInText item=”{5085975:CIUPGVGN}”]. Pomysł nie zdobył sobie wtedy raczej zbyt dużej popularności, jednak obecnie, w dobie wzorców opartych o mikroserwisy i mikro aplikacje, ma szansę wrócić do łask. Ja stosuję go już od dłuższego czasu (patrz: projektowanie zorientowane na interfejsy). Skróty HLD i LLD to odpowiednio: High-Level Design (projekt wysokiego poziomu) i Low-Level Design (projekt niskiego poziomu). Są to poziomy abstrakcji w modelu PIM. Jest to także opis stylu projektowania architektury systemu zorientowanego na interfejsy (architektura zorientowana na interfejsy).

(more…)