W tym roku ukazała się książka, której autorem jest Mark Wilkins: Amazon Web Services: podstawy korzystania z chmury AWS [zotpressInText item=”{5085975:SFA9HCDB}”]:
Książka sprawia wrażenie bardzo technicznej, ale pisana jest jasnym językiem i bogato ilustrowana. Na 464 stronach opisano usługi chmurowe oferowane przez Amazon. Autor na szczęście nie miał ambicji zastąpienia swoją książką oryginalnej dokumentacji, nastawił się (moim zdaniem) na wyjaśnienie mechanizmów działania poszczególnych usług i to właśnie wzbudziło moją sympatię do autora. Jeżeli po książkę sięgną developerzy to pewnie dlatego, że ją po prostu znaleźli w toku zawodowych poszukiwań.
Ja polecam tę książkę architektom bo pozwala zrozumieć to co robią developerzy. Polecam ją także analitykom, którzy w zasadzie także są architektami, co mechanizmów biznesowych aplikacji ale jednak to także już architektura. Analitycy pewnie nie małą część tej książki przewiną jak taśmę filmu z wesela przyjaciół, jednak początkowe rozdziały opisujące ogólnie te usługi, oraz te dotyczące magazynowania danych, są bardzo pouczające. To ostatnie polecam szczególnie tym z Was, którzy nadal są wyznawcami religii SQL/relacyjnej … Dowiedzą się paru ciekawych rzeczy 🙂 o bazach NoSQL.
Tym razem dwie książki formalnie adresowana przez autora dla programistów (autor książki jest znany w sieci jako Uncle Bob) [zotpressInText item=”{5085975:PUGG63YC},{5085975:64KN4B9L}”]. Długo się nad nimi zastanawiałem ale w końcu kupiłem i nie żałuję mimo, że UML napisana w 2003, czysto kod to “nówka” z 2018 roku.
Po pierwsze jako projektant muszę (no powinienem ;)) znać język koderów/programistów. Po drugie jako analityk, nie raz sprawujący nadzór autorski nad developerem, muszę (no powinienem ;)) mieć z tymi ludźmi wspólny język.
Dlatego są to książki także dla “analityków biznesowych” bo adresatami ich dokumentów są właśnie deweloperzy chcący (a nie raz po prostu muszą) z nich skorzystać!
Agile jest definiowane jako odnosząca się do, lub oznaczająca metoda zarządzania projektami, stosowana zwłaszcza do tworzenia oprogramowania, która charakteryzuje się podziałem zadań na krótkie etapy pracy oraz częstą ponowną oceną i dostosowywaniem planów. Powszechnie uważa się, metody zwinne zastępują projektowanie na wysokim poziomie częstym przeprojektowywaniem (źr.: Dictionary Definitions from Oxford Languages).
Robert C. Martin to jeden z sygnatariuszy Agile Manifesto, który bardzo szybko zorientował się, że wraz z kolegami, obudzili hydrę i już po dwóch latach od ogłoszenia Manifestu, zaczęli publikować książki o projektowaniu poprzedzającym kodowanie. Czysty kod to wydana w 2018 roku książka, w której autor jeszcze dobitniej wskazuje na potrzebę tworzenia architektury HLD przed kodowaniem i na stosowanie standardu komunikacji i dokumentacji jakim jest notacja UML. Tworzenie modeli UML dopiero po powstaniu kodu to najbardziej pozbawiona sensu praca. Martin przytacza znane już w 2018 roku dane z rynku o efektach agile (15 lat agile na rynku): drastyczne pogorszenie jakości i wzrost kosztów.
UML for Java programmers
Książka doskonale pokazuje to co zawsze mówię na szkoleniach: UML jako notacja jest nadmiarowa i nie wolno o tym zapominać (czasem mam wrażenie, że autorzy wielu diagramów, jako zadanie, postawili sobie użycie za wszelka cenę wszystkich symboli UML jakie zobaczyli).
Przypadki użycia
Jednym z najbardziej (po diagramie klas) nadużywanym jest diagram przypadków użycia. Na każdym szkoleniu zawsze mówię: to ma być prosty diagram, wszelkie extends, include, dziedziczenie to dzisiaj bełkot UML-owy (te związki powstały w latach 80-tych, gdy diagram UC był samodzielnym tworem, nie znającym diagramów klas czy komponentów… ).
Po drugie kolejna ważna rzecz: w toku procesu tworzenia oprogramowania powstają modele pojęciowe (tak conceptual znaczy pojęciowy a nie konceptualny czy koncepcyjny!) oraz modele logiki i architektury. Autor książki opisuje dwa ostatnie, w końcu to książka dla programistów, ale nie zakazana dla analityków. Od siebie dodam, że w ramach analiz wymagań powstają modele pojęciowe i (nie raz uproszczone) architektura + logika (algorytmy, scenariusze).
O modelowaniu
Po co modelować?
Clean architecture
To pozycja w 100% dla architektów-projektantów realizacji wymagań funkcjonalnych aplikacji. Ta książka jest także dostępna w wersji polskiej [zotpressInText item=”{5085975:QEGGUWKX}”]. Generalnie jest jeden z najlepszych, ilustrowanych modelami UML, podręczników projektowania architektury aplikacji.
We wstępie autor pisze:
Świat fizyczny jest miejscem, w którym żyjemy my, nasze firmy i nasze gospodarki. Daje nam to kolejną kalibrację, dzięki której możemy zrozumieć architekturę oprogramowania, inne mniej fizyczne siły i wielkości, za pomocą których możemy rozmawiać i rozumować. “Architektura reprezentuje istotne decyzje projektowe, które kształtują system, gdzie istotność jest mierzona kosztem zmiany.” -Grady Booch. Czas, pieniądze i wysiłek dają nam poczucie skali, aby odróżnić rzeczy duże od małych, aby odróżnić rzeczy architektoniczne od reszty. Ta miara mówi nam również, w jaki sposób możemy określić, czy architektura jest dobra, czy nie: Dobra architektura nie tylko spełnia potrzeby użytkowników, programistów i właścicieli w danym momencie, ale także spełnia je w czasie. “Jeśli uważasz, że dobra architektura jest droga, wypróbuj złą architekturę.” -Brian Foote i Joseph Yoder
W pierwszym rozdziale Martin przytacza znane w czasie pisania książki efekty agile (kodowanie z pominięciem planowania i budowania architektury HLD): drastyczne pogorszenie jakości i wzrost kosztów utrzymania i rozwoju: owszem MVP powstaje szybko i efektywnie, ale potem jest już tylko coraz gorzej:
Produktywność w kolejnych wersjach:
[zotpressInText item=”{5085975:PUGG63YC}”]
Koszty developmentu w kolejnych wersjach:
[zotpressInText item=”{5085975:PUGG63YC}”]
W całej książce Martin, do ilustrowania jej treści, używa czasami pseudokodu ale przede wszystkim diagramów UML (głównie diagramy komponentów, czasami diagramy klas i przypadków użycia).
Książka zawiera w zasadzie pełne kompendium zagadnień związanych z architekturą: paradygmaty, kluczowe wzorce projektowe i najlepsze praktyki oraz wiele, wiele przykładów.
Nie jest moją ambicją streszczanie tu tej książki, to pozycja z gatunku “must have”. Polecam ją nie tylko z powodu jej treści, ale także z powodu daty napisania: 2018. Jest to – jak na warunki cyklu wydawniczego takich książek – świeża pozycja, na dodatek bardzo wartościowa patrząc na doświadczenie i dorobek R.C. Martina.
Na zakończenie
Gorąco polecam programistom, by w ogóle zaczęli korzystać z UML a analitykom, by wyleczyli się z wielu mitów o UML rozpowszechnianych niestety na wielu, nie zawsze tanich, szkoleniach i w wielu kiepskich “poradnikach UML” (pisanych nie raz nawet przez uczelnianych doktorów i nie tylko)….. Może wtedy przestaną tworzyć nieprzydatne dokumentacje.
Poniżej także – o dziwo jest dostępna – wersja pdf do pobrania.
UML for Java Programmers, June 6, 2003 by Robert C. Martin (Author): papierowe wydanie na Amazonie i do pobrania pdf (pobieżne przejrzenie wersji pdf wskazuje że jest troszkę uboższa).
Temat cloud computing jest coraz gorętszy. Z jednej strony podgrzewają atmosferę firmy oferujące różne formy dzierżawy zasobów a z drugiej technologie i architektury zwane “chmurowymi”, prowadzą do stale malejących kosztów integracji (chmura prywatna).
Tak zwane technologie webowe (np. RESTful/REST API itp.) dotyczące integracji, powstały co prawda już nawet w 2000 roku, jednak dopiero teraz można mówić o dostępnych, przetestowanych bibliotekach, czyniących tego rodzaju projekty tańszymi, np. omawiane w artykule “Wymagania pozafunkcjonalne ? integracja” integracja z pomocą API to dzisiaj już taki sam koszt jak “spawanie” z pomocą SQL, wystarczy, że zatrudnimy kogoś (firmę) kto potrafi, a nie kogoś kto za nasze pieniądze będzie się dopiero zwinnie uczył, składając ofertę mimo braku kompetencji. Opór wielu firm przed przed tymi rozwiązaniami, z mojego doświadczenia, wynika z: braku wiedzy i kompetencji (wiele znanych firm IT nadal operuje metodami i technologiami z przed nawet 30 lat!), kurczowego trzymania się modelu biznesowego “dostarczamy jeden monolityczny system”, który silnie uzależnia klienta od dostawcy.
No i stosowanie metod opartych o tak zwane usługi “webservis”, wymaga całkowitego odejścia od metod strukturalnych projektowania (jednolite bazy danych w modelu relacyjnym i sterta funkcji) na rzecz metod obiektowych i komponentowych (Large system architecture).
Znamienne jest to, że gdy np. przeszukamy Internet pod kątem SOA, zobaczymy, iż w ostatnich kilku latach sporo publikacji poświęcono odejściu od tradycyjnego sposobu rozwoju systemów informatycznych ? od rozbudowanych rozwiązań autonomicznych do struktur złożonych z różnego rodzaju rozproszonych usług, ukierunkowanych na obsługę wybranych procesów biznesowych czy choćby pojedynczych działań. Równolegle, za Oceanem dynamicznie rozwija się Cloud Computing. Czymże innym jest to zjawisko, jak nie możliwością dobierania do organizacji (infrastruktury IT i modelu biznesowego) usług, które są niezbędne do efektywniejszej pracy (?do obsługi wybranych procesów biznesowych czy choćby pojedynczych działań?). I tak jak w ostatnich latach szyny integracyjne służyły integrowaniu wewnętrznej infrastruktury IT, tak w najbliższej przyszłości będą się rozwijać do łączenia również zewnętrznych usług z Chmury. (INTEGRACJA ROZWIĄZAŃ Z CHMURY TO WYZWANIE?).
Osobiście nie demonizował bym konieczności posiadania “szyny integracyjnej”, jak autorzy cytowanego powyżej artykułu (firma TIBCO jest dostawcą takiego produktu), jednak trend w kierunku rezygnacji z monolitycznych aplikacji już się zaznacza, a to czy taka “szyna” będzie, raczej jest konsekwencją architektury. Dobrze zaprojektowana architektura całego systemu aplikacji (komponentów) to struktura hierarchiczna: tak zwany “front end” to aplikacje, których odpowiedzialnością jest zarządzanie procesami, przepływem pracy (wprowadzanie danych i korzystanie z nich). Głębiej są dziedzinowe aplikacje stanowiące referencyjne składy i źródła danych. W takiej architekturze komunikacja (wywołania) jest jednostronna (zawsze mamy jasny podział usługobiorca-usługodawca. Szyny integracyjnej, jako dodatkowego komponentu, wymagają skomplikowane systemy i raczej dotyczy to większych korporacji, firmy naszego sektora MSP rzadko kiedy.
Internetowe metody integracji (np. wspomniany REST) to wymiana poleceń i obiektów a nie “funkcja vs. baza danych” (patrz wspomniany artykuł o integracji, dziwią mnie developerzy narzekający np. na “skomplikowane mapowanie obiektowo-relacyjne”, bo ono nie ma prawa być skomplikowane, a jeżeli jest, to jest to pierwszy sygnał, że to zły projekt!).
Tak więc chmury owszem, to chyba przyszłość, bez wnikania w to czy to chmury publiczne czy prywatne. Autonomiczne, duże systemy ERP? Nie wróżę im kariery, w obecnej postaci mega-aplikacje umrą, odwlekanie tej śmierci z pomocą perswazyjnych reklam i kampanii dużych korporacji i ich sprzedawców, to tylko sztuczne przedłużanie życia inwestycji w duże ERP, przez producentów tych rozwiązań, dawanie sobie czasu na (mam nadzieję) ich refaktoring. Mamy np. takie kolosy jak Google czy Amazon, które pokazują, że chmurowe, wysoce skalowalne architektury zasobowe mają sens. Systemy ERP oparte na relacyjnych bazach danych i ich wewnętrzna integracja poprzez współdzielenie danych, nie mają nawet szansy z tego skorzystać.
