Tech MeetING#2 - Modele pojęciowe – tworzenie i analiza w notacji UML

04.04.2023 |  Maciej Węgierek

Zapraszamy do zapoznania się z drugim odcinkiem z cyklu Tech MeetING, w trakcie których ekspercka wiedza IT spotyka się z bankowością. Podczas spotkania wystąpił Maciej Węgierek z Centrum Eksperckiego - Touchpoint, który poruszył tematykę modeli pojęciowych, tworzenia i analizy w notacji UML. 

Zapraszamy do obejrzenia relacji i zapisów na kolejne spotkania. Pełny harmonogram Tech MeetING dostępny jest tutaj.

 

 

Wstęp

Tworzenie modeli pojęciowych jest jedną z podstawowych aktywności, którymi analityk powinien zająć się w procesie opracowywania analizy biznesowej. Model taki definiuje pojęcia pewnego zagadnienia / obszaru / „biznesu” oraz relacje i fakty łączące owe pojęcia. Można powiedzieć, że jest to pewne uzupełnienie słownika pojęć, które kładzie duży nacisk na wskazanie relacji między opisywanymi bytami.

 

Czym jest model pojęciowy

Model pojęciowy można budować na wiele sposobów i przy użyciu wielu notacji. My skoncentrujemy się na notacji UML. Na warsztat weźmiemy diagram klas, który posłuży nam do stworzenia modelu oraz ukazania jego graficznej reprezentacji. W tym miejscu należy mocno podkreślić, że model pojęciowy nie jest diagramem klas – tego diagramu używamy jedynie do reprezentacji modelu pojęciowego.

Model pojęciowy nie jest też: modelem dziedziny (nie opisujemy w nim procesów biznesowych), modelem bazy danych, modelem danych ani modelem struktury systemu. Należy pamiętać, że modele pojęciowe abstrahują od implementacji. Co więcej na bazie modelu pojęciowego może wcale nie powstać żadna implementacja w senesie informatycznym. Zamodelowany przez nas „biznes” może być zrealizowany przez ludzi, bez użycia komputerów, a model pojęciowy może jedynie posłużyć do lepszego zrozumienia zagadnienia, którymi ci ludzie się zajmują.

Padło już słowo „służy do”. Czyli powiedzmy sobie wprost – do czego model pojęciowy służy. Model pojęciowy stanowi podstawę do komunikacji między interesariuszami projektu. Chodzi nam o to, abyśmy te same byty nazywali tak samo oraz mieli taką samą świadomość relacji między nimi. W przeciwnym wypadku napotkamy na mnóstwo nieporozumień wynikających z odmiennych języków którymi operujemy. Na bazie modelu pojęciowego mogą powstawać modele systemu oraz jego implementacja – chodzi nam o to byśmy tworząc nazwy diagramów, pakietów, komponentów, klas, zmiennych, graficznych interfejsów itd. używali tego samego słownictwa.

 

Notacja

W dalszej części przedstawię wybrane elementy notacji UML 2.5.1 [OMG UML 2.5.1], które są najczęściej wykorzystywane do budowy modeli pojęciowych. Wedle mojej najlepszej wiedzy, nie istnieje jeden sposób budowy takich modeli, który jasno i bezsprzecznie wskazywałby których elementów języka UML używać, a których nie. Przedstawię zatem metodę opartą na moim doświadczeniu oraz zainspirowaną pracami: [Mireault 2016], [Szlenk 2005], [Wazlawick 2014], [Żeliński 2022].

Pierwszy element to klasa – byt, który będzie reprezentował pojęcie słownikowe. Klasa może być opisana zbiorem atrybutów. Pamiętajmy jednak, że w modelach pojęciowych nie używamy operacji – te przydadzą się nam na innych poziomach modelownia. Diagram 1 prezentuje graficzną reprezentację klasy Samochód z przykładowymi atrybutami.

Diagram 1 - Przykład graficznej reprezentacji klasy języka UML

Źródło: opracowanie własne 

 

W drugiej kolejności zwróćmy uwagę na relacje między pojęciami. Pierwszym z nich jest generalizacja / specjalizacja. Relacja ta służy do budowania kategoryzacji (taksonomii) pojęć. Możemy przedstawiać kategoryzację ze względu na różne aspekty. Na diagramach 2 i 3 zaprezentowano kategoryzację Samochodów ze względu na rodzaj silnika oraz na zastosowanie. Mówiąc o tym związku należy podkreślić, że jest on często mylony z dziedziczeniem, które jest pojęciem programistycznym i odnosi się do jednego z możliwych sposobów realizacji generalizacji / specjalizacji. Sposobów jest jednak więcej. Na etapie tworzenia modelu pojęciowego nie należy narzucać sposobu realizacji systemu informatycznego, w tym paradygmatu języka programowania. Model pojęciowy abstrahuje od realizacji systemu.

 

Diagram 2 - Generalizacja / specjalizacja – kategoryzacja Samochodów ze względu na silnik

Źródło: opracowanie własne 

 

Diagram 3 - Generalizacja / specjalizacja - kategoryzacja Samochodów ze względu na zastosowanie

Źródło: opracowanie własne 

 

Kolejnym elementem jest asocjacja. Dzięki temu powiązaniu możemy wskazać na istnienie „jakiejś” relacji między pojęciami. Może to być bardzo ogólna relacja, nie ujawniająca szczegółów. Może jednak wskazywać na liczność powiązanych ze sobą elementów, rolę pełnioną przez elementy w danym związku lub samo znaczenie występowania danej zależności. Diagram 4 obrazuje powiązanie pomiędzy Samochodem elektrycznym a Domem – wskazuje, że Samochód jest garażowany w Domu. Etykieta asocjacji opisuje sens tej relacji, zaś czarny grot wskazuje na kierunek czytania etykiety.

 

Diagram 4 - Asocjacja wraz z etykietą

Źródło: opracowanie własne 

 

Diagram 5 obrazuje relację Domu, Samochodu elektrycznego i Przyczepy kempingowej. Zobrazowane zostało też wykorzystanie symbolu liczności. Samochód może być powiązany z wieloma przyczepami. Sens wskazanych relacji odzwierciedlają etykiety zwane rolami. Samochód elektryczny może pełnić dwojaką funkcję: może być biorcą energii elektrycznej z domu, lub źródłem energii elektrycznej dla przyczep kempingowych.

 

Diagram 5 - Asocjacja - role i liczności

Źródło: opracowanie własne 

 

Kolejnym elementem jest kompozycja. Dzięki tej relacji możemy wskazać elementy składowe danego pojęcia. Element komponujący zawiera w sobie elementy komponowane. Istotą tej relacji jest to, że usunięcie elementu komponującego niesie za sobą usunięcie elementu komponowanego. Innymi słowy – element komponowany nie może istnieć bez elementu komponującego. Diagram 6 wskazuje na to, że Samochód elektryczny jest złożony z od 1 do 4 Silników elektrycznych oraz przynajmniej jednego akumulatora.

 

Diagram 6 - Kompozycja i liczności

Źródło: opracowanie własne 

 

Kompozycja jest wizualizowana poprzez odcinek zakończony pełnym rąbem. Na diagramach UMLa możemy spotkać też rąby jasne bądź puste. Oznaczają one relację agregacji – słabszej wersji kompozycji, w której element agregowany może istnieć bez elementu agregującego. Jest to jednak relacja coraz rzadziej wykorzystywana, a sama specyfikacja UML 2.5.1 bardzo mało o niej mówi. Nie wskazuje też przykładu jej użycia. Jest to prawdopodobnie związane z faktem dość płynnej granicy pomiędzy agregacją a zwykłą asocjacją. W mojej opinii użycie agregacji wymaga uzasadnienia i wskazania co mamy na myśli i co chcemy uzyskać poprzez zastosowanie tego powiązania. Nadużywanie tej relacji może prowadzić do nieporozumień.

 

Przykład modelu pojęciowego

Diagram 7 stanowi przykład modelu pojęciowego definiującego terminy związane z grą w warcaby. Zawiera on pojęcia słownikowe i relacje między nimi. Będą to terminy, którymi możemy posłużyć się by opowiedzieć drugiemu graczowi o zasadach gry, ale też wykonać analizę będącą punktem wyjścia do zaprojektowania systemu informatycznego przeprowadzającego rozgrywkę. Tak więc na tym etapie nie mówimy nic o realizacji prezentowanych koncepcji. Nie mówimy nic o implementacji, gdyż nawet nie wiemy, czy ów diagram posłuży drugiemu graczowi do zrozumienia czym są warcaby czy deweloperowi chcącemu zinformatyzować rozgrywkę. Być może na tej podstawie powstanie aplikacja umożliwiająca dwóm osobom grę w warcaby przez Internet, a może oprogramowanie fizycznego robota, który będzie chwytał bierki i ustawiał je na odpowiednich polach planszy.

Drugą cechą zaprezentowanego modelu jest koncentracja na pojęciach specyficznych dla opisywanej gry. Model ten moglibyśmy wzbogacić o informacje wskazujące na to, że plansza leży na stole, jest wykonana z drewna, bierki zaś są ozdobione kamieniami szlachetnymi, pole jasne ma kolor beżowy, zaś ciemne kolor brązowy, a gracze grają na stojąco. Są to jednak informacje zupełnie zbędne z punktu widzenia opisania czym jest gra w warcaby. Można powiedzieć, że jest to oczywiste – fakt, ale problem koncentracji na terminach istotnych staje się bardziej złożony w przypadku opisywania nieco bardziej skomplikowanych „biznesów”.

Diagram został stworzony tak by osoba znająca podstawowe elementy notacji UMLa związane z diagramami klas nie miała kłopotów z jego rozszyfrowaniem. Można oczywiście wzbogacić diagram o opis słowny, ale w gruncie rzeczy wszystko da się odczytać z rysunku. Wątpliwości może budzić zastosowanie zwykłej asocjacji pomiędzy Polem ciemnym a Planszą, podczas gdy pomiędzy Planszą a Zestawem do gry w warcaby zastosowano kompozycję. W tym miejscu kierowałem się tym, że zarówno Plansza jak i Bierka jasna oraz ciemna są fizycznymi elementami, które wchodzą w skład Zestawu, podczas gdy Pola ciemne i jasne są jedynie wyznaczonymi obszarami na Planszy.

 

Diagram 7 - Graficzna reprezentacja modelu pojęciowego gry w warcaby

Źródło: opracowanie własne 

 

Podsumowanie

Modele pojęciowe są jednym z filarów analizy biznesowej. Dzięki nim jesteśmy w stanie uwspólniać nomenklaturę i lepiej zrozumieć zagadnienie, którym się zajmujemy. Notacja UMLa jest jedną z wielu notacji za pomocą których możemy tworzyć takie modele, ale ze względu na jej popularność stanowi ona wspólny język opisu, zrozumiały dla wielu interesariuszy projektów IT.

 

Źródła:

[Mireault 2016] P. Mireault, Structured Spreadsheet Modelling and Implementation: A Methodology for Creating Effective Spreadsheets, SSMI International 2016

[Szlenk 2005] M. Szlenk, Formalna semantyka i wnioskowanie o pojęciowym diagramie klas w UML, rozprawa doktorska

[Wazlawick 2014] R. S Wazlawick, Object-Oriented Analysis and Design for Information Systems – Modeling with UML, OCL, and IFML, ELSEVIER 2014

[Żeliński 2022] J. Żeliński, Analiza Biznesowa – Praktyczne modelowanie organizacji, Onepress 2022

[OMG UML 2.5.1] Specyfikacja języka UML 2.5.1 – www.omg.org/spec/UML