Oprogramowanie Generator Ofert zostało zaprojektowane przeze mnie dla Biura Polonijnego Kancelarii Senatu. Zadanie jakie dostałem to opracowanie wymagań (Opis Przedmiotu Zamówienia) na aplikację, która:
pozwala składać wnioski na dofinansowanie projektów Polonii z całego świata,
składać wnioski stanowiące formularze o bardzo rozbudowanej i zmiennej w czasie strukturze, przechowywać ich kolejne wersje,
prowadzić proces oceny wniosków przez ekspertów Bura Polonii Kancelarii Senatu,
tworzyć i zawierać umowy, w których te wnioski są załącznikiem,
śledzić rozliczanie tych umów.
prowadzi archiwum tych dokumentów,
Analizę i projekt zrealizowałem zdalnie sam, w ciągu miesiąca (komunikacja). W toku przetargu nie było żadnych skarg na treść OPZ do KIO. Implementacja wykonana w ciągu pięciu miesięcy w planowanym budżecie i terminie, pod moim nadzorem (nadzór autorski).
Łącznie (analiza plus prace developera) zajęły mniej niż 6 miesięcy kosztem ok. 500tys. Aplikacja nadal działa i jest rozwijana.
Całość jest na AZURE. Aplikacja działa do dziś w dobrej kondycji, jest relatywnie tania w utrzymaniu mimo corocznych zmian przepisów (w tym formularzy). Poprzednie wyceny (niektóre na bazie metod opartych o punkty funkcyjne, inne na bazie wielodniowych warsztatów z pracownikami Kancelarii Senatu czy te na bazie setek stron modeli UML baz danych i niezrozumiałych diagramów UC), dawały wielokrotnie (bywały ponad 10 krotnie) wyższe prognozy kosztów.
Z uwagi na to, że miewam pytania o konstrukcję niektórych schematów blokowych w tym dokumencie, omówię je tu pokrótce.
Między innymi całkowicie zrezygnowałem z SQL i relacyjnego modelu danych dla formularzy, dzięki czemu wielokrotnie spadła pracochłonność wytworzenia oraz późniejsze koszty utrzymania i rozwoju (między innymi co roku nieco zmienione formularze).
W takich projektach bardzo ważny jest nadzór autorski, czyli tu mój udział w projekcie w toku implementacji:
nadzoruję pracę dewelopera,
na bieżąco wyjaśniam wątpliwości developera co do dokumentacji,
na bieżąco uzupełniam dokument o nowe elementy (czas się nie zatrzymuje w dniu ogłoszenia przetargu i podpisaniu umowy z wykonawcą),
na bieżąco aktualizuję dokumentację o wszelkie podjęte decyzje architektoniczne,
w dniu oddania aplikacji do użytku, stale aktualizowany OPZ, stanowi aktualną dokumentację powstałego systemu, tu na koniec nadzoru, miał nieco ponad 80 stron.
(Dokument OPZ został w całości wykonany z użyciem oprogramowania Visual-Paradigm: wbudowanego edytora DocComposer pakietu Visual-Paradigm. Cały cykl pracy nad wymaganiami i ich dokumentowaniem nie wymaga użycia żadnych narzędzi biurowych typu Office.)
Zakres projektu
Na tym diagramie kolorami pokazano zakres odpowiedzialności Zamawiającego i Wykonawcy. Kolor niebieski oznacza produkty, które ma dostarczyć Wykonawca. Jest to diagram przypadków użycia notacji UML, na wczesnym etapie zwany Modelem kontekstu (zakresu) projektu. Zależności (uzależnienia) zostały zamodelowane standardowym związkiem zależności w UML. UWAGA! Notacja UML nie zabrania umieszczania na tym diagramie innych symboli niż aktor, system i przypadek użycia, można to robić pod warunkiem zachowania poprawności semantyki i syntaktyki używanych symboli.
Cele biznesowe
Powyższy diagram to model motywacji biznesowej (BMM). Jest to bardzo ważny diagram w projekcie: służy do określenia celu biznesowego. Jest używany do selekcji zgłaszanych wymagań biznesowych. Do zakresu projektu powinny być kwalifikowane wyłącznie wymagania wspierające cele biznesowe projektu. Pozwala to skutecznie zarządzać zakresem projektu i nie popaść w zjawisko zwane “utrata panowania na zakresem projektu” (szybko rosnąca niekontrolowana liczba wymagań).
Słownik i model pojęciowy
Co do zasady projekt powinien mieć Biznesowy słownik pojęć. Jest to lista pojęć wraz z ich definicjami, której celem jest zagwarantowanie jednoznaczności treści całej dokumentacji. Są to pojęcia dziedzinowe a słownik ten stanowi przestrzeń pojęciową dla innych diagramów. Diagram ten standardowo wykonuję jako Model Faktów notacji SBVR, ale jest to tak naprawdę diagram klas składający się wyłącznie z klas (nazw), związków generalizacji i skierowanych asocjacji. Celem jego budowy jest zagwarantowanie spójności i niesprzeczności pojęć w słowniku. Cechą tego diagramu (metodą kontroli jego poprawności) jest to, że każde dwa połączone pojęcia tworzą (muszą) poprawne zdanie w języku naturalnym np. “metryka zawiera fakty z historii sprawy” czy “umowa jest szczególnym typem pisma”. Nazwy klas, atrybutów, operacji, aktorów itp. na modelach architektury muszą pochodzić z tej przestrzeni pojęciowej!
Poglądowa mapa procesów biznesowych
Bardzo przydatnym diagramem jest nieformalny schemat blokowy obrazujący procesy biznesowe operacyjne. Każdy “pagonik” to abstrakcja procesu, którego detale pokazane zostaną na podrzędnych diagramach w notacji BPMN. Można taki diagram także wykonać w notacji BPMN, jednak jego adresatem są sponsorzy projektu, którzy rzadko mają łatwość posługiwania sie notacją BPMN.
Podmioty w otoczeniu Kancelarii
Diagram współpracy notacji BPMN jest tworzony w celu inwentaryzacji podmiotów zaangażowanych w procesach obsługi wniosków. Nazwy tych podmiotów stanowią potencjalne wartości atrybutów metadanych dokumentów, będą także użyte jako pule na diagramach BPMN.
Zarządzanie przepływem dokumentów
Diagram BPMN, na którym pokazano czynności związane z pracą z dokumentami. W takich przypadkach, gdzie ludzie wykonują czynności sami dobierając ich kolejność wg. ustalonych reguł (np. w instrukcjach) nie ma sensu modelowanie wszelkich wariantów z użyciem wielkiej ilości bramek i możliwych przepływów (specyfikacja BPMN 2.0.2, Figury 10.35, 10.36, 10.37).
Jeżeli przepływ pracy jest bardziej deterministyczny powstają diagramy jak poniżej.
Przypadki użycia czyli usługi aplikacyjne
Diagram przypadków użycia ma pokazać usługi aplikacyjne i interesariuszy systemu (ludzi) oraz ewentualnych aktorów będących innymi aplikacjami (integracje).
Tu wyjątkowo użyłem dość rzadkiej konstrukcji jaką jest generalizacja (a nie dziedziczenie! którego nie ma w UML od 2015 roku, od wersji 2.5), pokazująca że zarówno recenzenci jaki referenci to pracownicy Kancelarii. To uogólnienie to słownikowy zabieg mający na celu uproszczenie diagramu (jeden związek zależności do generalizacji zamiast dwóch do jej instancji). Jest to zabieg słownikowy, analogiczny to tego, w którym mówimy “weterynarz leczy zwierzęta” zamiast mówić “weterynarz leczy psy, koty, świnki morskie” (słowo zwierzęta jest słownikową generalizacją konkretnych zwierząt). Tej rzadko używanej konstrukcji użyłem tylko z powodu presji czasu i odradzam ją. Lepszą konstrukcją była by tu strukturalna metaklasa zamiast uogólnienia i związki ‘instanceOf’ zamiast pojęciowej generalizacji, a jeszcze prościej: pokazać te zależności wyłącznie na modelu pojęciowym.
Model dziedziny
Został wykonany z użyciem standardowego wzorca BCE, nie raz już opisywanego na tym blogu, po prawej stronie, pokazano wybrane detale struktury repozytoriów jako realizacje.
Powyższe to wybrane kluczowe elementy projektu.
Podsumowanie
Pozostałe elementy OPZ dla Kancelarii Senatu wydają mi się dość oczywiste, tu starałem się skomentować te elementy tego dokumentu, które budzą najwięcej pytań i emocji. Są to bardzo przydatne i niedoceniane konstrukcje zarówno w notacji UML jak i BPMN. Kompletny dokument można także pobrać tu:
Na temat tak zwanych metod obiektowych często można spotkać teksty takie jak ten z wikipedii:
Programowanie obiektowe (ang. object-oriented programming, OOP) ? paradygmat programowania, w którym programy definiuje się za pomocą obiektów ? elementów łączących stan (czyli dane, nazywane najczęściej polami) i zachowanie (czyli procedury, tu: metody). Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. Podejście to różni się od tradycyjnego programowania proceduralnego, gdzie dane i procedury nie są ze sobą bezpośrednio związane. Programowanie obiektowe ma ułatwić pisanie, konserwację i wielokrotne użycie programów lub ich fragmentów
Portal mFiles podaje:
Programowanie obiektowe lub inaczej programowanie zorientowane obiektowo (ang. object-oriented programing, OOP) to paradygmat programowania przy pomocy obiektów posiadających swoje właściwości jak pola (dane, informacje o obiekcie) oraz metody (zachowanie, działania jakie wykonuje obiekt). Programowanie obiektowe polega na definiowaniu obiektów oraz wywoływaniu ich metod, tak aby współdziałały wzajemnie ze sobą. (źr.: Programowanie obiektowe ? Encyklopedia Zarządzania)
Albo takie jak ten ze strony JavaStart:
Programowanie obiektowe jest paradygmatem programowania, który opiera się o tworzenie aplikacji w taki sposób, aby jak najlepiej odzwierciedlać otaczającą nas rzeczywistość i aby model danych oddawał sposób postrzegania świata przez człowieka (czyli, że na przykład że jabłko jest owocem, a nie kolorową kulą). […] Poznasz tu zagadnienia między innymi takie jak klasa, obiekt, interfejs, czy klasa abstrakcyjna i dziedziczenie. (Java – Programowanie Obiektowe | JavaStart)
Bardzo wielu autorów powiela schemat:
Założenia programowania obiektowego ?Abstrakcja ?Hermetyzacja danych (enkapsulacja) ?Dziedziczenie ?Polimorfizm
Programowanie obiektowe zakłada łączenie danych i funkcji w jednym obiekcie.
(wiele materiałów w sieci, na ten temat, podobnie jak i ten, nie zawiera danych autorów ani daty publikacji)
Przykłady z dość powszechnie wykorzystywanych materiałów dydaktycznych:
Abstrakcyjną ideą programowania obiektowego jest powiązanie stanu (danych, które określane są zwykle polami) i zachowania (algorytmy związane ze stanem i całym obiektem, określane słowem metody). Program korzystający z obiektowości wyrażony jest jako zbiór takich obiektów, komunikujących się pomiędzy sobą w celu wykonywania zadań. W pewien sposób jest to najbardziej intuicyjne podejście do rozwiązywania problemów, bo w taki sposób ? traktując zagadnienia jako obiekty wraz ze stanem i metodami; do rozwiązywania problemów podchodzi ludzki mózg. Typy obiektów nazywamy klasami. (źr. TI/Wstęp do programowania obiektowego ? Brain-wiki)
(ten tekst także nie zawiera danych autora ani źródeł)
Programowanie zorientowane obiektowo polega na intuicyjnym, naturalnym pisaniu programów, poprzez modelowanie obiektów świata rzeczywistego, ich atrybutów i zachowań odpowiednikami oprogramowania. Programowanie zorientowane obiektowo modeluje także komunikację pomiędzy obiektami przez wiadomości. Obiekty mają atrybuty (dane) i wykazują zachowanie (funkcje, metody). Obiekty są elementami oprogramowania do ponownego użycia, tworzone są z ?planów?zwanych klasami. Różne obiekty mogą mieć wiele takich samych atrybutów i podobne zachowania. (źr. dydaktyka.polsl.pl ? kwmimkm )
W programowaniu obiektowym programy definiuje się za pomocą obiektów określających dane rzeczywiste i funkcji na nich operujących. Obiektowy program komputerowy wyrażony jest jako zbiór takich obiektów, komunikujących się między sobą w celu wykonywania określonych zadań.
Dziedziczenie porządkuje i wspomaga polimorfizm i inkapsulację dzięki umożliwieniu definiowania i tworzenia specjalizowanych obiektów na podstawie bardziej ogólnych. Dla obiektów specjalizowanych nie trzeba redefiniować całej funkcjonalności, lecz tylko tę, której nie ma obiekt ogólniejszy.
W typowym przypadku powstają grupy obiektów zwane klasami oraz grupy klas zwane drzewami. Odzwierciedlają one wspólne cechy obiektów. Każdy obiekt może (choć nie musi) mieć przodka, od którego się wywodzi. Np. każdy człowiek ma swojego przodka w postaci rodzica. W zależności od przyjętej metodologii obiekt może mieć jednego lub wielu przodków. O ile może istnieć ograniczenie w postaci jednego przodka, o tyle takiego ograniczenia nie ma co do liczby potomków, których dany obiekt jest przodkiem. Fakt posiadania przodka wiąże się ściśle z dziedziczeniem.
Dziecko jako obiekt może dziedziczyć po swoich przodkach takie atrybuty, jak kolor oczu, wzrost itp. Obiekt może oprócz dziedziczenia atrybutów odziedziczyć metody, czyli ? analogicznie ? w naszym przykładzie dziecko może po swoich przodkach odziedziczyć takie ?metody? (zachowania), jak skłonność do palenia papierosów, talent w wybranych dziedzinach życia, wczesne wstawanie itp. ?(Gryglewicz-Kacerka & Duraj, 2013)?
Ta próbka jest moim zdaniem reprezentatywna, jeśli chodzi o treść publikacji na ten temat. Autorzy tych treści, najczęściej programiści, skupiają się na funkcjach, danych, i tak na prawdę traktują pojęcie “obiektowego paradygmatu” jak kolejne wcielenie strukturalnego kodu, tyle, że wg, innych zasad (obiekt łączący dane i funkcje, dziedziczenie itp.), co jest ogromnym uproszczeniem. Sam fakt zastosowania wymienianych wyżej konstrukcji języków zorientowanych obiektowo nie czyni programu obiektowym, to kolejne wcielenie programowania strukturalnego, gdzie bloki i podprogramy zyskały nazwę obiektów a re-użycie kodu nazwę dziedziczenia. Paradygmat obiektowy to przede wszystkim architektura.
Jednak paradygmat to tylko umowa, pozostaje stosowanie wzorców i dobrych praktyk w toku projektowania.
Największe nieporozumienie
Prawie nikt nie pisze o analizie i projektowaniu zorientowanym obiektowo, a cała idea polega tu na zaczynaniu od analizy i projektowania, potem dopiero się programuje. Nie przypadkiem najpopularniejszym skrótem w literaturze przedmiotu jest OOAD (ang. Object-Oriented Analysis and Design, Obiektowo Zorientowane Analiza i Projektowanie).
Największym, moim zdaniem, nieporozumieniem albo niezrozumieniem, jest utożsamianie oprogramowania z modelem świata. Popatrzmy na poniższy prosty diagram:
Realny świat . Opisujemy go modelem pojęciowym, który stanowi przestrzeń pojęciową: słownik dla projektu. Jeżeli jest taka potrzeba, tworzymy obiektowy model określonego fragmentu dziedziny, by go lepiej zrozumieć. Np. do poprawnego stworzenia oprogramowania zarządzającego produkcją, może być konieczny model produktu i model hali produkcyjnej, w której jest on produkowany. Powodem jest to, że system MES przetwarza dane o produkcji a nie produkty i nie hale produkcyjną. Największym błędem będzie odtwarzanie tego modelu w oprogramowaniu z użyciem obiektowo zorientowanych języków programowania.
Oprogramowanie przetwarza dane opisujące Realny świat, a nie Realny świat. Oprogramowanie, w większości, to nie gry komputerowe, to systemy zarządzające danymi. Z perspektywy człowieka jest to zarządzanie informacją o świecie a nie światem. Dlatego np. system CRM przechowuje dane o klientach a nie klientów. Warto tu także podkreślić, że jako ludzie, a także maszyny między sobą, komunikujemy sie wymieniając komunikaty, a nie współdzieląc bazy danych.
W konsekwencji projektowania oprogramowania to opracowywanie struktury komunikatów i metod ich przetwarzania, do tego dochodzi opracowanie architektury całości, bo nigdy nie jest to monolit. Projekt oprogramowania to model mechanizmu przetwarzania danych pogrupowanych w odrębne komunikaty, które jako ludzie nazywamy formularzami i dokumentami (patrz artykuł: ICONIX jako zwinny proces projektowania oprogramowania z użyciem UML).
Istotą obiektowego paradygmatu w inżynierii oprogramowania jest to, że model mechanizmu działania jest zarazem projektem systemu!
Paradygmat obiektowy, w swej istocie, nawiązuje do teorii systemów: system (analizowany lub projektowany) składa się z współpracujących obiektów. Cechą obiektów jest ich hermetyzacja, która oznacza, że obiekt nie udostępnia (i nie współdzieli) swojej wewnętrznej struktury (implementcji), ma z otoczeniem wyłącznie określone interakcje: wykonywane operacje. Innymi słowy obiekt reaguje w określony sposób na określone bodźce, ignorując wszelkie pozostałe, a zbiór tych bodźców (operacji) nazywamy interfejsem obiektu. Jedynym sposobem pozyskanie informacji o obiekcie jest ?zapytanie go o to?.
Generalnie więc:
Paradygmat obiektowy to przyjęcie zasady: system składa się ze współpracujących i niezależnych obiektów, obiekty cechuje określona odpowiedzialność, współpraca obiektów polega na wzajemnym wywoływaniu (call) operacji w celu uzyskania określonego efektu. Obiekty udostępniają operacje, jest to interfejs publiczny obiektu nazywany także jego kontraktem (odpowiedzialność). Obiekty ukrywają przed otoczeniem swoją wewnętrzną budowę (hermetyzacja) a kontrakt gwarantuje, że ta sama operacja zawsze da ten sam efekt, niezależnie od użytego w danej chwili do jej realizacji algorytmu (metody), co nazywamy polimorfizmem. (patrz także [zotpressInText item=”{5085975:E5R9AI4N},{5085975:IQ5RZP6G}”]).
Związek dziedziczenia jest stosowany w obiektowych językach programowania ale nie jest on elementem (cechą) paradygmatu obiektowego jako takiego (został nawet usunięty z notacji UML w 2015 roku patrz UML 2.5). Związek dziedziczenia to sposób re-użycia kodu w językach zorientowanych obiektowo i stanowi sobą łamanie podstawowej cechy obiektów jaką jest niezależność i hermetyzacja (niewspółdzielenie i nie ujawnianie niczego).
Jeden z najczęściej publikowanych przykładów diagramu klas UML (źr. materiały dydaktyczne)
Powyższa konstrukcja jest bardzo łatwa do implementacji w językach zorientowanych obiektowo, jest bardzo często podawana jako przykład, jednak łamie podstawowe cechy paradygmatu obiektowego: niezależność obiektów i hermetyzację. Kod reprezentowany klasą Figura_Geometryczna jest wspólną częścią konstrukcji Okrąg i Kwadrat, w efekcie wszystkie trzy klasy są z sobą ściśle powiązane (zależne od siebie) co przeczy zasadzie projektowania obiektowego zwanej loose coupling (luźne powiązanie).
Kluczową cechą obiektowej architektury systemu jest współpraca hermetycznych i luźno powiązanych obiektów, więc podstawowym związkiem pomiędzy obiektami jest zależność (związek użycia) a nie asocjacja czy kompozycja, bo te to związki strukturalne. Wszystkie obiekty MUSZĄ mieć operacje, bez których nie ma mowy o jakiejkolwiek komunikacji czyli także współpracy. Od lat znany jest antywzorzec obiektowy o nazwie “anemiczny model dziedziny”. Jest to struktura trwale (asocjacje) powiązanych klas (obiektów) pozbawionych operacji ?(Fowler, 2003)?. Taki model, jak ten poniżej, nie jest modelem obiektowym:
(źr.https://en.wikipedia.org/wiki/Domain_model)
Kluczowe wady powyższego diagramu to: brak operacji i w konsekwencji brak związków użycia, trwałe powiązania oraz dziedziczenie (jego wady opisano wcześniej): te obiekty nie komunikują się w żaden sposób. Diagram zorientowany jest na dane.
Mitem wyrządzającym chyba najwięcej szkód jest teza o modelowaniu danych z użyciem UML (“UML łączy najlepsze cechy: modelowania danych ERD, modelowania czynności DFD., […]”, materiały dydaktyczne: Modelowanie z wykorzystaniem UML, Politechnika Poznańska) oraz teza, że podstawowa idea obiektu to “łączenie danych i funkcji je przetwarzających”. Tu warto wiedzieć, że jednym z podstawowych wzorców projektowych i dobrych praktyk architektury jest separowanie tworzenia elementów informacji, składowania informacji, i przetwarzania informacji (odrębne komponenty: fabryka, repozytorium, usługa) ?(Evans, 2015)?. Atrybuty obiektu to nie są pola bazy danych a stan obiektu to nie aktualna wartość jego wszystkich atrybutów.
Nie mniej wadliwe są często publikowane diagramy przypadków użycia składające się z dużej ich liczby, wielu związków include i extend a nie raz i owego dziedziczenia, ale ten temat już opisałem w artykule Paradygmat obiektowy i Przypadki Użycia (więcej o szkodliwości dziedziczenia: Why inheritance is bad?).
UML: klasa, klasyfikator, obiekt
Modele obiektowe dokumentuje się z użyciem notacji UML (Unified Modeling Notation?*?). Notacja ta nie powstała do dokumentowania kodu (jak piszą niektórzy autorzy) a do dokumentowania wyników analizy i projektowania (OOAD, Object Oriented Analysis and Design, Analiza i Projektowanie Zorientowane Obiektowo). Zostało to opisane w OMG (Object Management Group???) jako proces MDA (Model Driven Architecture???). Kolejność powstawania oprogramowania to: analiza i model biznesowy, decyzja o zakresie projektu czyli wymagania, model logiki systemu (Platform Independent Model) czyli opis rozwiązania i dopiero projekt implementacji (Platform Specific Model). Wszystkie te modele (jeżeli dotyczą tego samego systemu) muszą korzystać z tej samej przestrzeni pojęciowej (jednolity słownik pojęć). Pokazano to poniżej:
Model projektu obiektowego, strzałki do związki zależności i wskazują na źródłowe informacje.
Niektórzy autorzy jednak piszą:
Proces projektowania systemu informatycznego obejmuje następujące główne etapy: ? programowanie (tworzenie kodu programu w wybranym języku programowania), ? opracowywanie dokumentacji (opisywanie wszystkich elementów składowych systemu, zależności zachodzących między nimi, a także opracowywanie szczegółowej instrukcji użytkownika), ? wdrażanie systemu do pracy (jest to proces odpowiedzialny, złożony i długotrwały obejmujący: instalację systemu w miejscu przeznaczenia, uruchamianie, testowanie oraz szkolenie personelu obsługującego system).
Projektowanie systemu informatycznego wymaga określenia: ? modelu danych (Data Model), ? interfejsu użytkownika (User Interface, Front-End). Model danych określa zbiór ogólnych zasad posługiwania się danymi.
?(Gryglewicz-Kacerka & Duraj, 2013)?
Autorzy tu całkowicie pominęli etap analizy i projektowania co przeczy tytułowi tej publikacji: Projektowanie obiektowe systemów informatycznych. Padają tu także słowa o modelu danych, od których paradygmat obiektowy całkowicie abstrahuje.
Notacja UML operuje trzema kluczowymi pojęciami: klasa (nazwa), klasyfikator (znaczenie, definicja obiektów), obiekty (desygnaty, mające tożsamość egzemplarze). Pojęcia te są oparte na tak zwanym trójkącie semiotycznym:
trójkąt semiotyczny (źr. Logika ogólna, Grzegorz Malinowski, PWN 2010).
Trójkąt semiotyczny to kontekstowe powiązanie pojęć: znak (słowo), definicja, przedmiot. Określony znak (nazwa) wskazuje (denotuje) przedmiot (używamy nazwy/znaku do wskazania/nazwania przedmiotu). Wszystkie przedmioty zgodne z określonym opisem (desygnaty danej nazwy) można nazwać (oznaczyć) tym słowem (nazwa). Np. “każde stworzenie, które szczeka” (znaczenie/opis) można nazwać słowem “pies” i są to “te wszystkie psy” (konkretne znane nam psy czyli desygnaty słowa pies). W notacji UML “klasa” to pojęcie: “nazwa”, klasyfikator do definicja, a obiekty to desygnaty (instancje klasyfikatora, tu UWAGA: z uwagi na niejednoznaczność pewnych zapisów w UML, instancje – obiekty – ma klasyfikator a nie klasa, klasa to tylko nazwa zbioru).
W modelach pojęciowych używane są związki semantyczne (asocjacja) i definicyjne (generalizacja). Związek generalizacji jest kluczowym narzędziem tworzenia definicji sprawozdawczych (patrz przypis na stronie Słownik pojęć). W notacji UML stosowany jest także związek kompozycji (związek strukturalny całość – część), służy do dokumentowania tak zwanych klasyfikatorów złożonych zwanych także agregatami.
Tak więc projekt obiektowy to udokumentowany zestaw współpracujących w określonym celu obiektów (komponentów). Wymaganym i kluczowym elementem projektu jest słownik pojęć, czyli znaczenia i struktura nazw użytych w tym projekcie (nazwy klas, atrybutów i ich wartości, operacji, parametrów itp.). Jest to tak zwana przestrzeń pojęciowa systemu (słownik, namespace) przedstawiana jako model pojęciowy (taksonomie). Jeżeli dany atrybut przyjmuje skończoną liczbę wartości jako skutków określonych faktów, dokumentujemy to diagramem maszyny stanowej. Kolejnym elementem projektu obiektowego są scenariusze (modele) opisujące współpracę (dynamikę) elementów systemu (obiektów), której efektem są oczekiwane rezultaty (przypadki użycia oraz ich scenariusze, jako diagramy sekwencji UML).
Model obiektowy systemu
Należało by raczej powiedzieć, zorientowany obiektowo lub zgodny z obiektowym paradygmatem. Oznacza to, że struktura systemu (jego model) składa się z samodzielnych obiektów, które razem jako system, realizują określone zadania. System jako taki może być także obiektem, mogącym współpracować z innym systemem. Innymi słowy każdy obiekt sam z siebie jest prostym (atomowym, elementarnym) systemem.
Omówię tu przykład projektu prostej aplikacji. Projekt zostanie udokumentowany z użyciem notacji UML. Pominę etap tworzenia modeli CIM (procesy biznesowe).
Zakres projektu to usługa rejestracji wizyt u weterynarza oraz usługa prezentowania weterynarzom ich podstawowych danych a także terminów wizyt im przyporządkowanych. Zakres udokumentowano z użyciem diagramu przypadków użycia notacji UML.
Z aplikacji będą korzystali weterynarze. Aplikacja świadczy dwie usługi: zarządzanie wizytami oraz profile weterynarzy. Można zapisać informacje o planowanych wizytach, karta wizyty będzie zawierała także podstawowe dane przyporządkowanego weterynarza, pobrane z profilu tego weterynarza. Każdy weterynarz będzie prowadził swój profil: podając kluczowe informacje o sobie np. imię, nazwisko, specjalizacja, kontakt do siebie. Będzie także widział swój kalendarz wizyt. Pełny projekt zawierałby detaliczne szablony tych formularzy. W ramach wymagań spisano reguły biznesowe czyli logikę biznesową systemu:
Wizyty nie mogą być umawiane w dni wolne od pracy
Weterynarz może mieć tylko jedną zaplanowana wizytę w danym terminie
Profil określonego weterynarza może edytować wyłącznie on sam
(reguły biznesowe i słownik pojęć, patrz specyfikacja SBVR: Semantics Of Business Vocabulary and Rules?§?). Reguł biznesowych nie dokumentujemy w UML bo nie do tego służy.
Do kontroli pola Data wizyty, zaplanowano sprawdzanie danych o dniach wolnych od pracy w zewnętrznym systemie, udostępniającym dane o dniach wolnych od pracy (na diagramie aktor po prawej stronie, taka sytuacja to nie przypadek użycia! a związek zależności od aktora).
Kluczowa część projektu to analiza pojęciowa i opracowanie modelu pojęciowego czyli słownika pojęć, ich taksonomii i definicji.
Model pojęciowy (diagram klas UML lub diagram faktów SBVR)
Słownik pojęć stanowi podstawowe źródło nazw wszystkich elementów modelu dziedziny systemu. Jak widać słownik to tylko klasy (same nazwy) połączone asocjacjami (związki semantyczne) i związkami generalizacji (łączą pojęcia ogólniejsze i ich typy). Pojęcia ogólne są często kandydatami na nazwy klasyfikatorów (komponentów systemu) i ich atrybutów, typy pojęć (liście taksonomii) są kandydatami na nazwy wartości atrybutów (ich słowniki). To nie jest ani model danych ani model architektury tego systemu!
Zaprojektowano komponent Model (model dziedzinowy) systemu (patrz opis wzorca MVC: Model, View, Controller), jego architektura jest zgodna z opisanym obiektowym paradygmatem i ma cechy dobrej architektury (zasady SOLID). Dla uproszczenia pominąłem na diagramie implementację rejestru weterynarzy).
Architektura komponentu Model Dziedziny systemu (diagram klas UML).
Przedstawiony przykład nie ma poważnej wady architektonicznej (wręcz plagi), polegającej na “wyciąganiu” zawartości atrybutów obiektu serią poleceń Get/Set dla każdego atrybutu. Powoduje to bardzo silnie uzależnienie obiektu pobierającego dane od obiektu będącego ich źródłem (wadę tę opisał dokładnie Fowler we wzorcu DTO. Operacje zapisz i przywołaj powodują zapisanie i przywołanie całej karty wizyty (wszystkich jej danych).
Jak widać mamy pełną hermetyzację komponentów i luźne powiązania między nimi (tylko związki użycia). Oddzielono logikę biznesową od repozytorium. Nie ma tu żadnego dziedziczenia (nie ma go w UML od 2015 roku). Każdy komponent (klasyfikator) ma operacje. Pola gatunek i wielkość mają zdefiniowane słowniki (enumerator). Nazwy te są zdefiniowane w odrębnym modelu pojęciowym (bo do tego on między innymi służy). Model powyższy jest jednak nadal dość “tradycyjny” (przestarzały) bo atrybuty reprezentują poszczególne pola formularzy (od czego się odchodzi!).
Wadą tego “przestarzałego” pomysłu jest to, że każda modyfikacja formularzy będzie wymagała refaktoringu tego systemu (atrybuty klasyfikatorów i metody). Dlatego pokazałem alternatywne nowocześniejsze podejście (różowe tło), w którym klasyfikator Wizyty2 ma identyczny interfejs, nadal odpowiada za przechowywanie informacji o wizytach, ale tu są one – cała karta wizyty – przechowywane jako treść jednego atrybutu: tu w postaci tekstu XML. Dzięki temu zmiana struktury formularza nie będzie wymagała refaktoryzacji, a jedynie wymiany szablonów XML i XSD. Polimorfizm i hermetyzacja pozwoli na wymianę implementacji z Wizyty na Wizyty2 bez konsekwencji dla reszty systemu (klasa Wizyty2 ma identyczny interfejs).
Aktualne wartości atrybutów nie są “stanem obiektu” (kolejny mit). Obiekt Wizyty to repozytorium kart wizyt, stanem (statusem) danej wizyty jest jedna informacja (wartość jednego atrybutu). Wizyta jako taka ma statusy, zmieniają się one automatycznie.
Zmiany wartości atrybutu status_wizyty (maszyna stanów UML)
Aby udokumentować przypadek użycia (jego scenariusz) oraz jednocześnie przetestować tę architekturę (udokumentować dynamikę systemu) tworzymy diagram sekwencji.
Scenariusz realizacji usługi Wizyta (diagram sekwencji UML).
Myślę, że nie wymaga on komentarza. Warto wiedzieć, że używanie do tego celu diagramów aktywności jest mało efektywne, a w UML 2.5 diagramy aktywności są zarezerwowane już wyłącznie do modelowania kodu programu.
Cały projekt ma następującą strukturę:
Pełna dokumentacja zawierałaby:
model pojęciowy (jeden lub kilka diagramów klas),
jeden diagram przypadków użycia,
jeden lub więcej (alternatywne) scenariuszy dla każdego przypadku użycia (diagramy sekwencji),
jeden model dziedziny systemu czyli model architektury komponentu Model dla wzorca MVC (diagram klas, duży system to diagram komponentów, każdy z osobnym modelem swojej wewnętrznej architektury),
dla każdego obiektu w modelu dziedziny, mającego statusy, model maszyny stanowej opisujący wartości atrybutu reprezentującego stan obiektu (może ich być więcej niż jeden).
struktury tak zwanych obiektów transferowych czyli struktury danych wymieniane pomiędzy obiektami (agregaty, najczęściej XML).
Do tego bogatszy opis kontekstu, makiety formularzy, pełną specyfikację reguł biznesowych.
Model taki nadaje się (pomijając potrzebę zaprojektowania grafiki i środowiska wykonawczego) do implementacji wprost, stanowi więc bardzo precyzyjne wymaganie.
Korzyści
Najczęściej jako korzyści ze stosowania metod obiektowych wskazywane jest re-użycie kodu, łatwe korzystanie z bibliotek, podział pracy na zespoły. A tak na prawdę kluczową korzyścią są skutki hermetyzacji i polimorfizmu: system podzielony na całkowicie niezależne (hermetyzacja) komponenty i całkowita niezależność od ich wewnętrznej budowy (polimorfizm) powoduje, że rozwój i wprowadzanie zmian dla systemu jest szybkie, łatwe i niemalże pozbawione ryzyka. To jak rower, jeżeli nie jest spawany a złożony ze standardowych elementów łączonych na unormowane zaciski i śrubki (standaryzacja interfejsów), modyfikujemy go w dowolnym momencie, małym nakładem pracy, w miarę zmian naszych potrzeb i nawyków. W 2013 pisałem:
Opisałem tam obiektowy model gry w szachy spełniający powyższą zasadę.
Na zakończenie
Mam nadzieję, że ten artykuł wyjaśni wiele wątpliwości. Wiele różnych przykładowych diagramów można znaleźć w literaturze i w sieci internet. Wiele z nich, mimo że są zgodne z notacją UML, to nie modele obiektowe a strukturalne. Niestety wiele zawiera także błędy notacyjne. Dodam także, co bardzo ważne: specyfikacja UML to nie jest podręcznik analizy i modelowania a tylko specyfikacja notacji. Zawiera poprawne konstrukcje UML ale nie koniecznie są to zawsze dobre wzorce architektury.
Warto wiedzieć, że to co nazywamy paradygmatem obiektowym to aksjomat a nie dogmat. Dlatego notacja UML nie narzuca niczego poza zasadami jej stosowania, jednak jeżeli już piszemy, że nasz projekt jest obiektowy, to musimy (wypadało by) uznać aksjomat: system to współpracujące samodzielne obiekty (a więc uznać konsekwentnie hermetyzację i polimorfizm). Dobre praktyki architektury to już konsekwencje dotyczące cyklu życia systemu, w szczególności kosztu jego utrzymania i rozwoju.
Ciekawostką jest także to, że o opisanych tu zaletach architektury obiektowej pisano już w 1994 roku (i później też nie raz). Wiedza, którą tu prezentuję ma 25 lat:
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994
by Steve Cook (Author), John Daniels (Author))
Na zakończenie powiedzmy sobie wprost: nie ma czegoś takiego jak “obiektowy model danych”!.
Dane to informacje (znaki), które mogą zostać zorganizowane w określone nazwane struktury, one same z siebie nic nie robią. Obiekt to “coś co ma określone zachowanie”, więc określenie “obiektowy model danych” jest pozbawione sensu… Jednym z najbardziej znanych antywzorców obiektowych jest tak zwany ‘anemicznym model dziedziny‘. Jest to model który składa się z klas mających atrybuty, ale niezawierających żadnych metod, co powoduje, że nie jest obiektowy.
https://youtu.be/wyABTfR9UTU?t=365
Dla mających więcej czasu:
Alan Kay at OOPSLA 1997 – The computer revolution hasnt happened yet
Jak zawsze zachęcam do zadawania pytań…
?*?
https://www.uml.org
???
https://www.omg.org
???
https://www.omg.org/mda/
?§?
https://www.omg.org/spec/SBVR/About-SBVR/
Cytaty
Evans, E. (2015). Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym. Gliwice: HELION.
Gryglewicz-Kacerka, W., & Duraj, A. (2013). Projektowanie obiektowe systemów informatycznych. Włocławek: Państwowa Wyższa Szkoła Zawodowa we Włocławku.
26 września na stadionie Legii w Warszawie odbyła się VII edycja dorocznego spotkania elity polskiego IT, poświęcona technologiom dla biznesu. Każdy z nas miał szansę dowiedzieć się, co naprawdę napędza branżę IT. Firmy prezentowały aktualne trendy w rozwoju technologii dla biznesu. Jak co roku, uczestnicy mogli wymienić się doświadczeniami oraz pozyskać cenną wiedzę oraz nowych Partnerów Biznesowych.
W targach wzięło udział szerokie gremium ekspertów i specjalistów z całej branży IT. Dzięki temu, udało nam się stworzyć idealną atmosferę networkingową. Wyselekcjonowane grono Liderów IT oraz kluczowych ekspertów branżowych, umożliwiło uczestnikom wymianę merytorycznej i trudno dostępnej wiedzy.
Oprócz firm z Polski, w roli wystawców zaprezentowały się również firmy z zagranicy, co bez wątpienia sprzyjało licznej frekwencji. IT Future Expo jest imprezą międzynarodową, co raz bardziej rozpoznawalną i cenioną również na rynkach zagranicznych.
25 września, inauguracją targów była jak zawsze – Gala IT Future Awards, która wyłoniła najlepsze rozwiązania i usługi IT na polskiej arenie informatycznej. Już po raz szósty, firmy technologiczne przystąpiły do wielkiej rywalizacji o miano Lidera IT. Kolejna edycja Konkursu, była podsumowaniem dokonań całej branży technologicznej w bieżącym roku.
Laureaci dowiedzieli się o swoim zwycięstwie podczas GaliIT Future Awards 25 września na Stadionie Legii. Wówczas odebrali statuetki za dokonane osiągnięcia. Goście wydarzenia mieli okazję poznać przodujące firmy sektora IT w Polsce i Europie, a także spotkać przedstawicieli kadry zarządzającej oraz innych, ważnych reprezentantów otoczenia branży informatycznej.
? Niezmiernie miło jest nam przedstawić tegorocznych Laureatów Konkursu Liderzy IT 2019:
? AI FORCE 1 z produktem Chatbot – Panel Trenera, narzędzie do wirtualizacji pracowników, w kategorii BI Trends ? Pirxon z produktem Pirxon Robot w kategorii BPM Leader ? 3S Data Center z produktem 3S Cloud2B Backup w kategorii Cloud Computing ? Agraf Systemy Interaktywne z Monitorem Interaktywnym Newline VN w kategorii Computer & Equipment Technology ? HSC z z systemem okablowania strukturalnego AIM FUTURE-PATCH TKM wraz z oprogramowaniem DCIM PATCH MANAGER w kategorii Data Center Leader ? Samito – formerlySaveCart z produktem rozpoznawania obrazów dla e-commerce w kategorii E-commerce Innovation ? wfirma.pl – Księgowość Online z produktem wFirma.pl w kategorii ERP Trends ? CRIF India z produktem Credit Check System Wymiany Informacji, w kategorii Industry Dedicated IT Solutions ? ATEN Poland z produktem ATEN KVM over IP Matrix System w kategorii Infrastructure Innovation ? Cloudware Polska Sp. z o.o. z produktem Next Vision One w kategorii Innowacja Roku 2019 ? Cypherdog Security z produktem Cypherdog w kategorii IT Security ? Matrix42_de z produktem Matrix42 Workspace Management w kategorii IT Services Leader ? SOTI Inc. z produktem SOTI ONE Platform – Enterprise Mobility Management w kategorii Mobile Trends ? Archman z produktem Business Navigator w kategorii Workflow Management
Gratulujemy wygranej i życzymy dalszych sukcesów!
Jak co roku, kluczowym punktem merytorycznym podczas Gali IT Future Awards była Debata Liderów Branżowych ? Bezpieczeństwo w erze cyfrowej transformacji. W debacie wzięło udział 6 Panelistów. Moderatorem był Pan Damian Klimas.
Po wnikliwej dyskusji odbył się bankiet, w trakcie którego Goście mieli czas na zacieśnienie relacji biznesowych i chwilę relaksu.
Wieczór został wzbogacony o część artystyczną. W tym roku, swym pięknym głosem oczarowała widownię Patrycja Malinowska. Wokalistka wprowadziła uczestników w przyjemny nastrój i choć na chwilę zmniejszyła napięcie, które towarzyszyło w oczekiwaniu na wyniki konkursu Liderzy IT 2019.
Podczas samych targów, uczestnicy mogli zdobyć cenne informacje m.in. z zakresu cyberbezpieczeństwa, przetwarzania danych, infrastruktury IT, elektronicznego obiegu dokumentów, czy złożonych procesów biznesowych. Wystawcy dzielili się swoimi doświadczeniami, chętnie udzielali porad i odpowiadali na pytania techniczne.
Jak co roku, tradycją była strefa 3D, gdzie uczestnicy mogli podziwiać technologie drukarek 3D.
Gościem Specjalnym eventu był znany Autor Bloga ? Artur Kurasiński, który przybliżył nam tematykę sztucznej inteligencji. Słuchacze mogli dowiedzieć się dlaczego tak wiele osób boi się sztucznej inteligencji o co niesie za sobą ta technologia w przyszłości dla całej populacji jak i biznesu. Prelegent przedstawił fakty oraz mity dotyczące AI.
Wydarzenie odbyło się pod Patronatem Honorowym Ministerstwa Cyfryzacji, Ministerstwa Przedsiębiorczości i Technologii, a także Polskiego Towarzystwa Informatycznego.
Sponsorem Strategicznym targów była firma Archman, która przygotowała zjawiskowe stoisko wystawiennicze, co bez wątpienia przykuło uwagę odwiedzających. Pan Marcin Kowalski – Prezes firmy Archman, podczas swojego wystąpienia, opowiedział o budowie aplikacji biznesowych. Prelekcja była na wysokim poziomie merytorycznym, o czym świadczyła frekwencja słuchaczy.
Wydarzeniem wiodącym pod względem merytorycznym, był niewątpliwie IT Future Congress. Nie zabrakło prelekcji z zakresu bezpieczeństwa IT, data center, BPM, czy sztucznej inteligencji. Pan Michał Kurek rozpoczął wykład inauguracyjny i przykuł uwagę słuchaczy prelekcją o metodach ochrony przed zaawansowanymi cyberatakami. Bardzo dobrze ocenioną prelekcją wśród uczestników był wykład Pana Grzegorza Filarowskiego z firmy LOG Systems, który opowiedział o wzroście roli systemów ITSM w działach biznesowych.
Najbardziej kluczowym punktem kongresu była Debata – Czy warto robotyzować procesy biznesowe? Moderatorem był Pan Jarosław Żeliński, a w dynamicznej dyskusji wzięli udział Paneliści:
Wojciech Szremski, RPA CoE Head / Schaeffler Global Services
Sebastian Drzewiecki, Dyrektor Zarządzający ? GSK
Agnieszka Belowska-Gosławska, Group Head of Robotics ? Nordea Bank Abp
Marcin Basaj, Dyrektor IT- Fraikin
Michał Marlinga, Senior Vice President ? Citi
Marcin Kowalski, Prezes Zarządu ? Archman Sp. z o.o.
Jan Karasek, Partner, Management Consulting ? KPMG Advisory Spółka z ograniczoną odpowiedzialnością sp.k.
Wszechstronne spektrum zagadnień poruszonych podczas kongresu, przyciągnęło bardzo liczne grono odpowiednio stargetowanych odbiorców.
Tegoroczną edycję targów odwiedzili m.in.: Dyrektorzy IT, IT Managerowie, osoby odpowiedzialne za bezpieczeństwo IT, Właściciele firm, a także Prezesi i Członkowie Zarządów. Wśród uczestników znaleźli się przedstawiciele wielu branż m.in.:
Administracji Publicznej
Energii i Surowców
Finansów
FMCG oraz Retail
Motoryzacji
Nauki i Edukacji
Przemysłu i Produkcji
Telekomunikacji
Transportu
Taki dobór grupy docelowej sprawił, iż łatwiej było nawiązywać relacje biznesowe Wystawcom. A poniżej kilka opinii:
Jesteśmy bardzo zadowoleni z targów. Nawiązaliśmy wiele nowych kontaktów i przeprowadziliśmy ciekawe rozmowy na temat nowych, potencjalnych projektów. Umiejscowienie naszego stoiska było bardzo dobre. Wszystko co zamówiliśmy było na miejscu. Dziękujemy za organizację i przygotowanie targów.
innovaphone AG
Bardzo dziękuję za kolejny rok goszczenia nas na tak fajnym wydarzeniu. Zmianę miejsca targów oceniam bardzo pozytywnie. W moim subiektywnym odczuciu było więcej odwiedzających 🙂 Gratuluję organizacji.
MTT Polska
Ogólnie stwierdzamy, że były to pierwsze targi, po których mamy konkretne spotkania handlowe i początki dyskusji z kilkoma znaczącymi sieciami handlowymi, na których nam najbardziej zależy.
Xnet Communications, Ltd.
W imieniu Organizatora – Wszystkim Wystawcom oraz zwycięzcom Konkursu życzymy samych sukcesów w dalszej pracy i doskonaleniu swoich rozwiązań, a Sponsorom i Patronom Medialnym dziękujemy za wsparcie imprezy! Dziękujemy za liczne przybycie oraz aktywne uczestnictwo wszystkim Zwiedzającym i Słuchaczom i do zobaczenia już niebawem!
