Jest to drugi artykuł z mini serii o modelach pojęciowych. W poprzednim artykule wyjaśniłem czym ten model jest. Teraz pokażę jak go można narysować, przy okazji wyjaśniając po drodze z jakich elementów się składa.

Posługuję się prostym modelem, w którym są ludzie i samochody. Ja ten model znam, mam go w głowie. Po doczytaniu artykułu pojawi się też w Twojej 🙂 Rysuję go w notacji ConceptSpeak™.

Elementy modelu

W skład modeli wchodzą dwa rodzaje pojęć: pojęcia rzeczownikowe (noun concepts) oraz pojęcia czasownikowe (verb concepts).

Pojęcia rzeczownikowe

W naszym modelu mamy dwa główne pojęcia rzeczownikowe: samochód i osoba. Na diagramie przedstawiamy je wpisując termin określający pojęcie w prostokąt:

Instancjami tych pojęć są konkretne obiekty domeny:

Opel Astra KR123 (ten, który właśnie zaparkował pod Twoim blokiem)
Green Mercedes (ten, który stoi w Twoim garażu)
Jan Nowak
Anna Kowalska

Pojęcia czasownikowe

Na pojęciach rzeczownikowych zbudowane są pojęcia czasownikowe, służące do opisu stanu rzeczy (state of affairs). Innymi słowy, możemy dzięki nim określać fakty. Przedstawiamy je na diagramie jako linie łączące odpowiednie prostokąty, z umieszczonym obok linii wyrażeniem.

Poniżej są narysowane dwa pojęcia czasownikowe. Jedno oznacza, że człowiek prowadzi auto a drugie określa czy auto jest sprawne.

Dodanie czasowników pozwala nam wyrażać fakty:

Green Mercedes is driven by Anna Kowalska
Jan Nowak drives Opel Astra KR123 that is not operational.

Zmieniając w powyższych wyrażeniach poszczególne instancje na korespondujące z nimi pojęcia, uzyskujemy szablony do budowania zdań (czyli predykaty lub funktory zdaniotwórcze):

A car is driven by a person
A person drives a car that is not operational.

Zazwyczaj można je czytać w dwie strony (drives lub is driven by) ale nie zawsze: niektórych pojęć czasownikowych się nie odwraca, bo brzmiałyby źle. Nie jest też zasadą, że sformułowanie odwrotne powstaje przez użycie strony biernej czasownika (np. PM prowadzi projekt ale Projekt ma PMa – to są wyrażenia tego samego pojęcia czasownikowego). Kierunek czytania wyznacza na diagramie strzałka.

Liczba argumentów

Takie predykaty mogą być unarne (x is operational), binarne (x drives y) lub n-arne, czyli takie gdzie występują więcej niż dwa pojęcia rzeczownikowe. W przypadku tej trzeciej przedstawia się to na diagramie nieco inaczej:

Uprzedmiotowienie

Pojęcia czasownikowe mogą wchodzić ze sobą w więcej niż jedną relację a zatem linii między prostokątami będzie więcej. W dodatku czasami warto jest uprzedmiotowić (ang. objectification) jakąś relację. W efekcie powstaje nowe pojęcie rzeczownikowe – coś na wzór rzeczowników odczasownikowych. Jego instancje będą równoważne instancjom pojęcia czasownikowego, czyli faktom. Na diagramie rysuje się to w ten sposób:

Role w pojęciach czasownikowych

W niektórych relacjach pojęcia rzeczownikowe występują w rolach. Dzięki temu zdania lepiej brzmią – lepiej wyrażają znaczenie, wyraźniej przenoszą intencję. Zaznaczamy to na diagramie przy odpowiednim prostokącie, obok linii wskazanej relacji. W poniższym przykładzie mamy zatem A thief steals a car bo to lepiej brzmi niż A person steals a car.

Standardowe relacje

Pojęcia rzeczownikowe wchodzą w relacje tylko przy pomocy czasowników. Ale jeden czasownik jest tak wyjątkowy, że zasługuje na specjalne traktowanie. Z tego powodu uzyskał swoje własne elementy notacji graficznej.

Tym czasownikiem jest słowo: być.

Klasyfikacja

Jedno ze znaczeń czasownika być odnosi się do relacji jaka zachodzi między obiektem domeny a oznaczającym go pojęciem (lub między egzemplarzem a szablonem). Ta relacja oznacza, że coś jest czymś. Np. że Adam Nowak jest osobą. Albo że jest mężczyzną. Albo że jest nauczycielem.

Gdy mając konkretny obiekt (lub sytuację) zastanawiamy się jak go zaszufladkować (czyli do którego koncepcyjnego pudełka pasuje) wówczas dokonujemy klasyfikacji (co, nawiasem mówiąc, czasem nie jest takie trywialne).

Zaklasyfikowanych obiektów zwykle nie prezentuje się na diagramie modelu pojęciowego, ale jest to możliwe. Autorzy notacji wybrali do tego celu coś takiego:

Może się to przydać jeśli jakieś konkretne obiekty pełnią szczególną rolę w naszej domenie i dlatego chcemy je wskazać/wyróżnić na diagramie. Np. jeśli z jakiegoś powodu chcemy zakazać kierowcom wjazdu do Londynu. Ja kiedyś rysowałem diagram różnych rodzajów usług zaufania i zaznaczyłem na nim gdzie konkretnie znajduje się usługa firmy, w której pracowałem. Dzięki temu wiadomo było czym ta usługa jest a czym (jeszcze) nie jest.

Kategoryzacja

Kiedy czasownik być sam staje się pojęciem czasownikowym, tzn łączy relacją dwa różne pojęcia, też mówimy, że coś jest czymś ale na poziomie pojęć. Np. w domenie gry w szachy można mówić, że hetman jest figurą oraz figura jest bierką. W matematyce mówimy, że kwadrat jest prostokątem itd.

Generalnie, mówiąc po informatycznemu, chodzi mniej więcej o dziedziczenie.

W naszym modelu mamy pojęcia car, person i city więc tutaj trudno o przykład (A car is a person po prostu nie jest poprawnym połączeniem, to nie jest domena Transformersów). Dlatego w celu zobrazowania jak tego typu relacja jest przedstawiana na diagramie, odkrywam nowe pojęcia:

Samochody mogą się dzielić na wiele różnych rodzajów w zależności od tego na co zwracamy uwagę. Budując taksonomię dokonujemy kategoryzacji pojęć (grupowania w kategorie). Połączenie pojęć grubą czarną linią oznacza, że każdy egzemplarz pojęcia niżej jest jednocześnie egzemplarzem pojęcia wyżej.

Zagadnienie kategoryzacji jest szerokie, nie będę tutaj wchodził w szczegóły. Na razie chcę tylko zwrócić uwagę, że w prawdziwym świecie często jest tak, że jakiś obiekt da się zaklasyfikować jako więcej niż jedno pojęcie, w różnych kategoriach. A zatem nasz Green Mercedes może być zarówno autem elektrycznym jak i SUVem. I nagle słownictwo się bardzo ubogaca. Możemy już mówić o elektrycznym sedanie czy o benzynowych hatchbackach: wystarczy zdefiniować każde z tych pojęć jako auto będące jednocześnie w obu wskazanych kategoriach.

Polimorfizm

Powyższa zdolność do bycia kilkoma rzeczami jednocześnie jest niejako wrodzona dla obiektów, w tym sensie, że wynika z ich istoty. W każdej chwili można powiedzieć o czymś do jakich kategorii się to coś klasyfikuje.

Czasami jednak nazywamy obiekty nie ze względu na ich istotę lecz ze względu na to co aktualnie robią, tzn w jakich relacjach występują. To jest właśnie opisany wcześniej aspekt ról w pojęciach czasownikowych. Ktoś może być jednocześnie osobą (pojęcie Person), mężczyzną, blondynem, programistą (możliwe kategorie względem płci, kolorów włosów, zawodu) ale gdy tylko zwiąże się z jakimś autem relacją steals, wówczas będzie go można nazwać złodziejem (rola Thief).

Tę zdolność do bycia jednocześnie wieloma rzeczami my programiści nazywamy polimorfizmem i uznajemy za jedną z podstawowych zasad programowania obiektowego. Zrozumienie skąd biorą się te różne oblicza obiektów (wskazanie w modelu) może nam pomóc w ich implementacji.

Pełen diagram

Cały model rzadko kiedy jest sens pokazywać na jednym diagramie. W pewnym momencie po prostu linie zaczynają się krzyżować i wszystko się robi nieczytelne. Ale diagram nie przedstawia procesu, nie ma początku ani końca czy jakkolwiek ustalonej kolejności czytania. Dlatego można go pociąć na mniejsze elementy i pokazać na kilku rysunkach.

Choć diagram nie narzuca kolejności czytania (można zacząć w dowolnym miejscu) to określa możliwą strukturę wypowiedzi. Wyobraźmy sobie, że wodzimy palcem między prostokątami, czytając na głos ich nazwy i czasowniki pomiędzy nimi. W ten sposób buduje się zdania w języku domeny.

Warto również pamiętać, że połączenia na diagramie oznaczają to co się może wydarzyć, nie to co się zdarzyło. Model określa co można powiedzieć, jakie zdania budować. I tylko tyle. W szczególności do niczego nie przymusza. Czyli jeśli mamy połączenie A thief steals a car to nie znaczy, że wszyscy muszą kraść samochody ani że coś takiego się wydarzyło. To znaczy tylko tyle, że takie zdarzenie jest potencjalnie możliwe.

Bez dalszych wprowadzeń poniżej przedstawiam pełen model pojęciowy domeny, w której ludzie mogą posiadać, kraść i prowadzić auta różnego rodzaju do różnych miast.

Notacja ConceptSpeak™

Przedstawiona tutaj notacja pochodzi z ConceptSpeak™ – zbioru wytycznych i technik opracowanych przez Business Rules Solutions. To co tu napisałem (ale nieco szerzej) możesz przeczytać w serii 5 artykułów:

Dlaczego lubię tę notację?

Modele pojęciowe istnieją w naszych głowach i będziemy o nich rozmawiać niezależnie od tego czy je narysujemy czy nie. W dodatku rysunki nie są głównym sposobem dokumentowania wiedzy. Ale rysowanie bardzo pomaga się dogadać bo obraz to więcej niż tysiąc słów. Kiedyś, przed pandemią, dużo się stało przy tablicy i smarowało markerami różne rysunki. Dziś jest tego mniej, ale wszyscy i tak czujemy, że tryb graficzny pomaga.

Notację ConceptSpeak™ lubię, po pierwsze dlatego, bo ją poznałem pierwszą. Ale przekonują mnie jej zalety. Jest minimalistyczna, dzięki czemu jest czytelna. Nie ma żadnych magicznych i skomplikowanych oznaczeń typu cyferki lub gwiazdki przy końcach linii. Ma niski próg wejścia. Owszem: trzeba ją poznać, żeby w niej swobodnie narysować dowolną rzecz. Jednak sam odbiór jest możliwy bez żadnego wprowadzenia. Dlatego nasz biznes będzie się mógł szybko włączyć w prace nad dokumentem lub go weryfikować.

Nieco kontrowersyjna może się wydawać decyzja twórców, by w kategoryzacji nie wskazać pojęcia nadrzędnego. Tutaj bazuje się na założeniu, że powinno być ono narysowane powyżej podrzędnego – to czasem może być kłopotliwe. Przyzwyczailiśmy się, że w UML robi się to, przy pomocy strzałki z pustym grotem (dziedziczenie). Dlaczego nie zdecydowano się zrobić w ten sposób w ConceptSpeak™? Bo tutaj autorom zależało, by nie dało się sugerować żadnego flow. Diagramy modeli pojęciowych nie niosą ze sobą żadnej semantyki dotyczącej procesu, sekwencji itd. Użycie strzałek mogłoby sugerować kolejność czytania.

Czy jest to jedyna notacja? Co z UML?

Niektórzy mówią, że diagram modelu pojęciowego to nic innego jak po prostu diagram klas UML. Nigdy się z tym zdaniem nie zgadzałem ale sprawa nie jest taka oczywista.

W standardzie SBVR pojęcia zostały graficznie przedstawione przy pomocy symboli, przypominających notację UML. Aneks C do standardu opisuje jak takie diagramy rysować.

W wersji 1.4 standardu (z maja 2017 r.) aneks nosił tytuł Use of UML Notation in a Business Context to Represent SBVR-Style Vocabularies. We wstępie napisano, że przedstawione diagramy są modelami UML. Elementy UMLa zostały wykorzystane do prezentacji słownictwa.

Co ciekawe to podejście się zmieniło w wersji 1.5, wydanej w grudniu 2019 r. Aneks zmienił tytuł na Conventions for Representing an SBVR-Style Vocabulary as a Concept Model Diagram (nie ma już w nim słowa UML). A we wstępie czytamy:

Some of the conventions used for concept model diagramming (…) may appear familiar to users of UML, but they do not represent UML and carry absolutely no UML semantics. Thus, the diagrams should not be interpreted through UML eyes.
Źródło: SBVR, Annex C – Conventions for Representing an SBVR-
Style Vocabulary as a Concept Model Diagram, 2019

Różnica polega na tym, że w 2017 r. autorzy pisali: pojęcie rzeczownikowe reprezentowane jest przez klasę z UML (wygląd na diagramie wynikał z zasad rysowania klas). Natomiast w 2019 r. stwierdzili już tylko, że pojęcia rzeczownikowe są przedstawiane jako prostokąty oznaczone terminem.

W mojej ocenie ta subtelna zmiana jest słuszna bo skoro noun concept z SBVR można reprezentować jako classifier z UML to mogłoby oznaczać, że obie te rzeczy są tym samym. I tu i tu mamy bowiem do czynienia z modelowaniem. To dlaczego zatem dwa standardy?

Poza tym, jeśli używamy UML do narysowania modelu pojęciowego SBVR, to musimy być zgodni z semantyką, którą UML narzuca. Co by to miało znaczyć, gdyby ktoś na pojęciu dopisał <<interface>> i między dwoma pojęciami zrobił przerywaną strzałkę (implements)? To jest semantyka, której w SBVR nie ma.

Dlatego ja zawsze mówię, że diagram klas != diagram modelu pojęciowego.

Niemniej, niezależnie od powyższych dygresji, SBVR definiuje swoją notację graficzną, więc jak ktoś chce poznać alternatywę do ConceptSpeak™ to zapraszam do lektury aneksu C. Poniżej kilka przykładów:

WordPress

Model pojęciowy: Diagram