Gdybym miał ocenić statystycznie diagram klas opisywany w książkach o UML , projektach jakie widuję nie tylko w pracach studentów, to powiedział bym, że jest jakiś problem z nimi. Dlaczego? Pokaże to, co moim zdaniem jest chyba nie tak. Szczególnie jak ktoś uważa, że diagram klas do model danych co wprost prowadzi do antywzorca obiektowego o nazwie anemiczny model dziedziny ^?*?Ten artykuł to kontynuacja poprzedniego artykułu o modelach dziedziny systemu.

Co można i należy pokazać w wynikach analizy – taksonomia

Przede wszystkim analiza to nie projekt, powinna pokazać obiektywny stan faktyczny. Druga rzecz, o tym już niektórzy zapominają: wynikiem analizy jest dokumentacja zrozumienia, tak więc model analityczny nie może być modelem pokazującym stan po uproszczeniach. To powinien być model rzeczywistości z naniesionymi, zastosowanymi lokalnie, ograniczeniami i uproszczeniami.  Innymi słowy: dla fabryki spodni budujemy kompletny model człowieka (manekin) z komentarzem, że tu w użyciu jest część od pasa w dół a nie wmawiamy nikomu, że w tej fabryce człowiek składa sie wyłącznie z bioder i nóg. W przeciwnym wypadku, przyszła rozbudowa systemu będzie co najmniej problematyczna.

Produkt analizy przekazuje informację o tym co zastano, opisuje pojęcia i reguły jakie nimi rządzą. Tak na prawdę, opisać firmę (organizację) to znaczy stworzyć listę pojęć jakimi się w niej operuje (jakimi można ją opisać) i reguły jakie ograniczają swobodę użycia (funkcjonowania) tych pojęć. Model pojęciowy (ich specyfikacja) to semantyka systemu, ograniczenia swobody ich wzajemnego kojarzenia to syntaktyka, i na koniec dziedzinowe ograniczenie swobody ich użycia to pragmatyka.  Wkrada się tu także przydatne pojęcie jakim jest entropia czyli miara nieuporządkowania. Tak więc mamy system pojęć, jego entropia (stopień nieuporządkowania)  jest ograniczona syntaktyką i pragmatyką specyficzną dla dziedziny i miejsca (organizacji). Co to oznacza dla analizy przedwdrożniowej?

Jednym z celów tej analizy jest odkrycie i zapisanie wiedzy o podmiocie „informatyzowanym”. Jak ją zapisać? Ano właśnie tak: zbudować listę pojęć i wskazać opisane ograniczenia. Doskonałym narzędziem do tego jest diagram klas (odradzam diagram ERD, można go później zbudować w oparciu o model pojęciowy, jeżeli zajdzie taka potrzeba, ale nie należy tych dwóch modeli stosować zamiennie). Diagram klas opisujący taki system pojęciowy to tak zwana przestrzeń pojęciowa (namespace) . Jak to wygląda:

Od razu uwaga: powyższy diagram jest nadmiarowy, w realnym projekcie bym tego tak nie narysował,  ale po kolei.^???

Podstawowe pojęcia (semantyka) analizowanego systemu to klasy oznaczone niebieskim kolorem. Bardzo często zdarza się, że pewne pojęcia można lub należy poklasyfikować, by przekazać informację o istnieniu tej klasyfikacji. Diagram ten można wiec uzupełnić na dwa sposoby: stosując tak zwane superklasy (uogólnienie, zebranie kilku wspólnych cech) oraz tak zwane stereotypy, czyli znacząc dodatkowo klasy. Klasa uogólniana nazywana jest specjalizacją. Na powyższym diagramie Zamówienie (specjalizacja) jest specyficznym rodzajem Dokumentu (uogólnienie) a każdy dokument to coś będącego jakąś treścią np. na papierze. Zamówienie jednak jest także 'obiektem biznesowym’, utrwalonym i zrozumiałym pojęciem (bytem) w firmie, do czegoś konkretnego służy.

Jest pewna semantyczna różnica pomiędzy super-klasą a stereotypem, gdyż uważam, że tych pojęć nie można stosować zamiennie. Super-klasa pokazuje, że pewne byty są uogólniane (mają one jakieś wspólne cechy zebrane w tym uogólnieniu) i uogólnienie to – jako pojęcie – jest stosowane „w rozmowie”. Stereotyp wskazuje na pewne istniejące i istotne (chcemy to zakomunikować w dokumentacji) rozróżnienie pomiędzy pojęciami jednak nie jest ono stosowane „w rozmowie”. Można więc uznać, że pojęcie Dokument funkcjonuje „w rozmowie” na równi z pojęciem Zamówienie choć jest to pojęcie (Dokument) abstrakcyjne. Nie istnieje coś takiego jak „ogólny dokument” ale pojęcie to jest powszechnie stosowane w firmach, abstrakcje takie oznaczamy pisząc nazwę takiej  klasy kursywą. Można także powiedzieć, że Zamówienie jest <<obiektem biznesowym>> (coś istotnego,  używanego) jednak raczej nikt nie używa tego pojęcia na co dzień. Ten stereotyp informuje czytelnika analizy, że to coś istotnego (jakimś kontekście).

Wpłata jest zdarzeniem, jednak zdarzenie to coś, co na co dzień nie jest traktowane jako równoprawne „słowo” w biznesie. Dlatego w tym przypadku w modelu użyłbym tylko stereotypu <<zdarzenie>>, by wskazać, że jest to coś innego niż <<obiekt biznesowy>> ale już nie użył bym, abstrakcyjnej superklasy Zdarzenie. Jeżeli jednak w toku projektowania (etap po analizie) uznamy, że chcemy przetwarzać dane o tych zdarzeniach zaprojektujemy dla systemu klasę Zdarzenie.

Obiektem biznesowym jest jednak Dowód Wpłaty (tak na prawdę reprezentuje on to zdarzenie ale nie jest to tożsame pojęcie: stwierdzenie wpłaty nie jest dowodem wpłaty). Te niuanse są bardziej oczywiste (mam nadzieję :)) na przykładzie klas Klient, Osoba, Pracownik, Sprzedawca. Widać tu także ewidentnie, że Klient jest wyłącznie Osobą.

Diagram ten zawiera także pewne reguły biznesowe (ograniczenia entropii, czyli swobody). Są to liczebności naniesione na skojarzenia (asocjacje), linie łączące klasy. Zaznaczono np. że Sprzedawca może mieć pod opieką klientów, także żadnego, jednak klient musi mieć i tylko jednego opiekuna. Brak linii łączącej dwie klasy świadczy zaś o tym, że nie ograniczają się one nawzajem w żaden sposób np. Wpłaty w żaden sposób nie wpływają na Sprzedawcę i odwrotnie. Istnieje jedynie pośredni związek mówiący, że można skojarzyć Wpłatę ze Sprzedawcą, elementem kojarzącym jest Faktura i jest ona także kontekstem tego skojarzenia: Faktura jest produktem procesu Sprzedaży, za który odpowiada Sprzedawca. To jest powód, dla którego model procesów powinien także powstać jako jeden z produktów takiej analizy bo to on zawiera tę właśnie informację.

Przykład:

Cechą produktu jest kolor a barwa to wartość. Atrybut i cecha w języku potocznym to synonimy, ale:

• cechą samochodu jest jego kolor
• cechą samochodu jest także to, że ma koła

Dlatego analizując daną dziedzinę trzeba wiedzieć czym są tak zwane cechy definiujące produktu:

• kolor nie czyni przedmiotu samochodem
• ale posiadanie kół owszem

Jednak w przypadku flagi lub logo firmy, kolor jest cechą definiującą i to jest jeden z wielu powodów, dla których nie należy dawać koderom etapu analizy i projektowania, bo myślą tylko kodem (klasa i atrybut).

Dlatego używanie pojęcia klasy wymaga „zastanowienia” bo to ma więcej niż jeden kontakt:

• inny w kodzie
• inny w ontologii

a tu i tu używamy pojęcia klasy i klasyfikatora.

Model dziedziny to model mechanizmu działania

A teraz model dziedziny, przytoczę diagram użyty w poprzednim artykule:

Jak widać jest pomiędzy nimi istotna różnica. Jej źródłem jest to, że taksonomia to model pojęciowy zaś model dziedziny (w rozumieniu Model z wzorca MVC) to opis przetwarzania. Przede wszystkim model dziedziny nie zawiera pojęć abstrakcyjnych. Dlaczego? No bo ich nie zapisujemy i nie przetwarzamy :)! Po drugie pewne pojęcia zniknęły z modelu (Klient, jest aktorem) bo Klient nie jest przetwarzany, ale dane klienta będą atrybutami (nie zaznaczono) Zamówienia: jest on tu, Klient, zamawiającym. Czytaj więcej o tworzeniu i testowaniu modelu dziedziny.

Tak więc warto zwrócić uwagę na to, że diagram klas diagramowi nie równy, to samo narzędzie może posłużyć do dwóch różnych celów w tej samej dokumentacji. Widać także (mam nadzieję), że próba pokazania na jednym diagramie zarówno systemu pojęć jak i sposobu ich przetwarzania, jako informacji w systemach informatycznych, jest raczej błędnym podejściem. Wydaje mi się, że podejmowanie takich prób świadczy o niezrozumieniu różnicy pomiędzy systemem pojęciowym a modelem przetwarzania informacji. W szczególności gdy dotyczy to systemów obiektowych.

C++, Java i podobne języki

Paradygmat obiektowy to hermetyzacja i komunikacja, a nie „dziedziczenie i łączenie danych i funkcji w obiekty”. C++/C# czy Java nie są reprezentacją obiektowego paradygmatu i niosą ze sobą narastający dług technologiczny:

Popatrzmy także na to:

W tym filmie przedstawiamy niektóre z technik stosowanych przez autorów kompilatorów w celu osiągnięcia mechanizmów języków obiektowych. Ciekawie jest zobaczyć, jak blisko C++ jest do C i jak proste są te mechanizmy pod maską. Chociaż film koncentruje się na C++, podobne techniki są stosowane przez wirtualną maszynę Javy, wirtualną maszynę .Net w C# i wiele innych języków OO.

https://youtu.be/HClSfuT2bFA?si=b5W7dLOkjRTPLGbf

Od pewnego czasu [2024] słyszę od deweloperów: Teraz w Javie króluje Spring. Słyszał pan o nim? Jestem ciekaw opinii

Tak, słyszałem:

„The Spring Framework is an application framework and inversion of control container for the Java platform.[2] The framework’s core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE (Enterprise Edition) platform. The framework does not impose any specific programming model.[citation needed]. The framework has become popular in the Java community as an addition to the Enterprise JavaBeans (EJB) model.[3] The Spring Framework is free and open source software.[4]: 121–122 [5]”

[https://en.wikipedia.org/wiki/Spring_Framework]

Czym jest Enterprise JavaBeans (EJB) model?

„Java Beans, As part of the standardization, all beans must be serializable, have a zero-argument constructor, and allow access to properties using getter and setter methods.”

[https://en.wikipedia.org/wiki/JavaBeans]

To oceniane jako najgorsze metody w postaci „access to properties using getter and setter methods”.

„Every getter and setter in your code represents a failure to encapsulate and creates unnecessary coupling. A profusion of getters and setters (also referred to as accessors, accessor methods, and properties) is a sign of a poorly-designed set of classes.”

[https://typicalprogrammer.com/doing-it-wrong-getters-and-setters]

(patrz także: https://www.infoworld.com/article/2073723/why-getter-and-setter-methods-are-evil.html)

„Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji – znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób.”

https://pl.wikipedia.org/wiki/Antywzorzec_projektowy

znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu (patrz https://martinfowler.com/bliki/AnemicDomainModel.html, programistom polecam także te strony). Warto też pamiętać, że w 2015 roku zmieniła się specyfikacja UML, usunięto pojęcie dziedziczenia i agregacji, sugeruję uzupełnić wiedzę wpisami na blogu, które powstały po 2015 roku.

Źródła