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 taksonomia lub model informacyjny. Z tym drugim jednak ostrożnie, bo chodzi o informacje opisujące organizację a nie informacje przetwarzane.  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ę.

Model dziedziny to projekt

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.

Programistom polecam także te strony.

Tagi: diagram klas, entropia, model dziedziny, model informacyjny, pragmatyka, semantyka, syntaktyka, system pojęciowy, UML