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:

Diagram klas, taksonomia

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:

Diagram klas, model dziedziny systemu

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

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.

Ten post ma 8 komentarzy

  1. Hania Wesołowska

    Czyli taksonomię (niebieskie) przygotowujemy na wczesnym etapie i zatwierdzamy z zamawiającym, a model dziedziny (żółte) przygotowujemy dla siebie (nie pokazujemy klientowi, ale przekazujemy zespołowi wykonawców)?

    1. Jarek Żeliński

      mniej więcej, chociaż coraz częściej zastępuję taksonomię w postaci diagramu klas, sformalizowanym słownikiem pojęciowym i specyfikacją reguł biznesowych, sprawdza się znacznie lepiej (to klient powinien ze zrozumieniem zatwierdzić, diagram klas tu niestety nie jest łatwy dla biznesu), z tego klient potrafi korzystać (np. uporządkowanie zarządzeń wewnętrznych otp..) http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules

  2. Piotrek

    Z jakich relacji należy korzystać przy budowaniu modelu pojęciowym (taksonomii)? Na przedstawionym schemacie są tylko asocjacje i uogólnienia. Czy zaznaczanie na tym etapie kompozycji czy agregacji jest zasadne?
    I druga sprawa – na ile głęboko schodzić na etapie modelu pojęciowego. Przykład: zarówno Zamówienie jak i Faktura składa się z pozycji. Na podanym przykładzie zostało to pominięte. Pytanie czy celowo czy dla uproszczenia?

    1. Jarek Żeliński

      Model pojęciowy to nic innego jak słownikowe podejście “do tematu” podobne do podręcznikowej klasyfikacji roślin czy psów. Stosując diagram klas do tego, należy się wystrzegać “choroby relacyjnej” czyli traktowania pojęć (klas) jak encji (tabel) na diagramach baz danych (ERD) bo mają tu one zupełnie inny sens. Przedstawiony przykład pokazuje wyłącznie logikę pojęciową więc Faktura “jest jakoś” powiązana logicznie z Zamówieniem. Ale! Tu (model pojęciowy) Faktura i Zamówienie to nie “dokumenty” z ich treścią, a pojęcia np. Faktura do “dokument, który…”.

      Głębokość uszczegółowienia. Więc wyjaśniło się jedno: na modelu pojęciowym Faktura to zdefiniowane pojęcie – termin, więc nie ma żadnych pozycji faktury itp. Można zdefiniować pojęcie “produkt” itp. ale wtedy diagram klas jako model pojęciowy (chcąc pokazać każdy związek logiczny) stanie się nieczytelnym “talerzem spagetti” albo będzie niekompletny (w zasadzie w biznesie wszystkie pojęcia jakoś się ze sobą wiążą). Dlatego od jakiegoś czasu diagramu klas nie używam do modelowania systemu pojęć, poprzestając na słowniku pojęć i specyfikacji dokumentów (obiektów biznesowych). Diagramów klas używam wyłącznie do modelowania dziedziny stylem opisanym jako DDD, czasami do zobrazowania metamodeli.

  3. MikeR

    Mam pytanie ponieważ w książce B. Bruegge i A.H. Duttoit “Inżynieria oprogramowania w ujęciu obiektowym” autorzy wspominają o modelach dziedziny aplikacyjnej i realizacyjnej. Na stronie 40 piszą, że: “Istotą podejścia zorientowanego obiektowo jest połączenie modeli obu dziedzin(…)”. Czy zatem wspomniany w tym artykule (i innych artykułach na tym blogu) model dziedziny mamy utożsamiać z obydwoma modelami ze wspomnianego opracowania?

    1. Jaroslaw Zelinski

      Hm… dobre pytanie… Generalnie mamy model logiki “systemu” czyli jego “mechanizm działania”. Myślę, że intencją autora było oddzielnie logiki “systemu” od logiki “interakcji z nim”. Jeżeli tak, to odpowiada temu wzorzec MVC-MV-VM. Model dziedziny to taki e”prawa fizyki w tym systemie”. To podstawa jego działania. Ale już “model” interakcji z aplikacją na komputerze a model interakcji na smartfonie mają swoją specyfikę.

    2. MikeR

      Dzięki za info. Teraz jest to dla mnie bardziej jasne.

Możliwość dodawania komentarzy nie jest dostępna.