W poprzednich artykułach z serii pisałem, że czym innym jest pojęcie a czym innym rzecz (instancja, egzemplarz), którą to pojęcie oznacza.

Egzemplarzami pojęć rzeczownikowych są obiekty, np. dla pojęcia dom instancją może być ten dwupiętrowy budynek przy ul. Czereśniowej 14.

W przypadku pojęć czasownikowych ich egzemplarzami są fakty (m.in. konkretne zdarzenia). Np. instancją pojęcia klient składa zamówienie jest jedno, określone złożenie zamówienia w dniu 1 marca o 12:34.

Drodzy zwolennicy Event Sourcingu, Event Stormingu i w ogóle współczesnego DDD: tak, tu chodzi o eventy. Każdy event jest instancją pojęcia czasownikowego. W dalszej części artykułu weźmiemy je pod lupę teorii.

I co my robimy z tymi pojęciami?

Rozpatrując tworzenie pojęć czasownikowych w relacji do ich instancji, możemy wyróżnić dwa przypadki:

• tworzymy pojęcie, gdy jego fakty już istnieją,
• tworzymy pojęcie przed pojawieniem się pierwszej instancji.

W pierwszym przypadku opisujemy przeszłość i teraźniejszość. Nazywamy to, co już się dzieje. Drugi przypadek to podwaliny rozmów o przyszłości. Np. gdy projektujemy nowe funkcje systemu lub opisujemy proces TO-BE.

W obu przypadkach, precyzyjnie określone pojęcia czasownikowe usprawniają komunikację. Bo same rzeczowniki nie wystarczą do budowy zdań. A bez zdań nie da się przekazać wiedzy. Ostatecznie uzyskujemy lepsze zrozumienie: od analizy aż po raporty z produkcji.

Ironclad rule pojęć czasownikowych

Istnieje pewna żelazna reguła¹ dotycząca pojęć czasownikowych, która zachodzi zawsze i od której nie ma żadnych wyjątków:

Prosty przykład: jeśli mamy pojęcie czasownikowe złodziej kradnie samochód, to nie może być mowy ani o kradzieży samochodu, którego nie ma, ani o takiej, której dokonał nieistniejący złodziej.

Przy czym zauważmy, że instancje pojęć rzeczownikowych nie muszą istnieć przed powstaniem instancji pojęcia czasownikowego. Mogą powstać razem. Np. w relacji klient składa zamówienie. Przed wystąpieniem takiego zdarzenia na pewno musi istnieć konkretny klient. Ale tworzonego zamówienia jeszcze nie ma. Jednak zasada wciąż jest spełniona, bo w każdej dowolnej chwili po złożeniu zamówienia istnieją wszystkie trzy instancje (klient, zamówienie, złożenie zamówienia).

Definicje

W poprzednim artykule pisałem o definicjach pojęć rzeczownikowych. A czy pojęcia czasownikowe też można zdefiniować? Okazuje się, że tak. Poniżej wyjaśnię jak. Jednak najpierw warto się zastanowić: czy w ogóle warto?

Ross pisze w [2], że często można sobie ten wysiłek darować. Po pierwsze dlatego, że definicje użytych pojęć rzeczownikowych zazwyczaj dość precyzyjnie nadają znaczenie czasownikowi. Po drugie, praktyka wskazuje, że dobrze dobrany czasownik mówi sam za siebie. Lecz najważniejsze jest, że samo spisanie pojęć czasownikowych eliminuje większość nieporozumień, które biorą się przez brak precyzji i spójności w tym jak budujemy zdania.

Są jednak przypadki, gdy pojęcie budzi wątpliwości. Poniżej przykład z życia: w jednym z projektów byłem pewien, że rozliczenie umowy o dzieło robi się na koniec umowy, gdy trzeba rozliczyć wykonawcę z wykonanej roboty. Dość szybko okazało się jednak, że w naszym dziale kadr panowało inne rozumienie.

Definicja musi zawierać odniesienia do wszystkich zaangażowanych pojęć rzeczownikowych. Definicja opisuje instancje (konkretne zdarzenia), więc rzeczowniki nie są jakieś ale dane. W języku angielskim oznacza to stosowanie w definicji przedimka określonego (the).

Po drugie definicja musi pasować do szablonu:

Fakt, że [pojęcie czasownikowe] oznacza, że [definicja].

A dla pojęć w języku angielskim³:

A fact that [verb concept] is a fact that [definition]

lub

A [verb concept] if and only if [definition]².

Mowa potoczna

Istniejące pojęcie czasownikowe informuje nas o tym co się może wydarzyć i jak możemy to zakomunikować. A zatem brak pojęcia czasownikowego w słowniku może być wskazówką, że coś się nie może wydarzyć lub nie możemy tego tak nazwać.

Np. słownik jakiejś firmy może nie zawierać sformułowania zaakceptować umowę i to dobrze, bo w tej firmie nie ma czegoś takiego jak akceptowanie umów (umowy są rezultatem zaakceptowania wniosku – może o to chodziło?).

I może być tak, że mamy w firmie ten super słownik: pełny, spójny i pięknie logiczny. Ale ludzie w organizacji i tak mówią po swojemu. Tzn. w użyciu są słowa i sformułowania, których słownik nie przewidział. W takiej sytuacji trzeba się zastanowić: czy oni mówią źle, czy może warto ich posłuchać i zaktualizować słownik?

Skróty myślowe

Sunąc palcem po diagramie faktów możemy tworzyć precyzyjne zdania. Możemy w ten sposób połączyć każde słowo z każdym. Czasem jednak kończy się to długimi zdaniami, których nie da się używać w praktyce. Najczęściej z tego powodu pracownicy będą wymyślać nowe, krótsze określenia.

Można to wspierać pewną sprytną techniką: można stworzyć nowe pojęcie czasownikowe, na bazie istniejących. Zapisujemy w jaki sposób wygodnie się mówi o pewnych sytuacjach i spisujemy definicję używając innych pojęć czasownikowych.

Takie pojęcia czasownikowe nie wnoszą nowych znaczeń. Nie da się przy ich pomocy wyrazić niczego, czego nie dałoby się powiedzieć innymi słowami. Ale ułatwiają komunikację.

Zobaczmy to na przykładach.

Nie zawsze skróty myślowe są poprawne

Sztandarowym przykładem bardzo popularnego acz nieprawidłowego, skrótu myślowego, jest kupowanie podpisu kwalifikowanego.

Podpisy to są dane elektroniczne dodane lub logicznie powiązane z innymi danymi. Podpis powstaje w chwili jego złożenia na dokumencie. Jego odpowiednikiem z modelu tradycyjnego jest tusz wsiąknięty w papier.

Mimo to, dużo jest ofert kupna podpisu kwalifikowanego, np. na rok. Jest to bardzo popularne sformułowanie. Czy zatem można przyjąć pojęcie czasownikowe: klient kupuje podpis kwalifikowany?

Odpowiedź jest niestety negatywna… Teoria jest tutaj nieubłagana: zgodnie z żelazną regułą wspomnianą wyżej, nie byłoby możliwe utworzenie instancji takiego pojęcia. Podpis bowiem nie istnieje ani nie tworzy się w chwili zakupu lecz później, podczas jego składania na dokumencie.

Co zatem można zrobić w takiej sytuacji? Widzę dwa wyjścia:

• wybrać inne określenie (np. klient kupuje certyfikat kwalifikowany) i edukować klientów od samego początku (co może przynieść korzyść później, np. na etapie obsługi w zespole wsparcia),
• stworzyć unarne pojęcie czasownikowe: klient kupuje podpis kwalifikowany (nie łączymy klienta z istniejącym pojęciem rzeczownikowym lecz tworzymy nowe, całkowicie niezależne).

Wybór rozwiązań powinien się wiązać ze świadomą oceną potrzeb sprzedażowych z jednej strony i kosztów nieporozumień z drugiej.

Przykład ten podaję, by wyraźnie zaznaczyć, że:

• nie zawsze da się poprawnie zrobić dowolne skróty myślowe,
• teoria ma realny i praktyczny wpływ na modelowanie naszego języka.

Nowe pojęcia rzeczownikowe

Pojęcia czasownikowe mogą być źródłem, z którego powstają nowe pojęcia rzeczownikowe.

Po pierwsze możemy uprzedmiotowić relację, o czym pisałem w artykule o diagramie modelu pojęciowego. Drugi sposób polega na wyróżnianiu pojęć, dla których zaistniał jakiś fakt.

Na przykład możemy mieć pojęcie zarejestrowany użytkownik. Oznacza osobę, która założyła u nas konto. Następnie określamy relację: zarejestrowany użytkownik potwierdza adres email. Teraz chcemy przyjąć reguły, że coś innego się dzieje dla użytkownika, który potwierdził a coś innego dla tego, który nie potwierdził adresu email. Ale powtarzanie w kółko słów tego pojęcia czasownikowego jest niepraktyczne. W takiej sytuacji możemy wprowadzić nowe pojęcie: użytkownik zweryfikowany, i zdefiniować je jak poniżej.

W ten sposób można m.in. obsłużyć statusy procesów. Definiujemy pojęcia typu proces zawieszony, zamówienie zakończone, zgłoszenie odrzucone poprzez odniesienie do zaistnienia konkretnych zdarzeń, np.: proces w trakcie to taki proces, który został wystartowany oraz nie został zakończony.

Fakty a zdarzenia

Przypomnijmy sobie przykład ze wstępu:

• pojęcie czasownikowe: klient składa zamówienie
• przykładowe instancje:
  • Jan Kowalski złożył zamówienie nr 123
  • Anna Nowak złożyła zamówienie nr 456.

Takie instancje często modeluje się w systemach IT jako zdarzenia. Dość naturalnie jest zaprojektować klasę OrderPlacedEvent i tworzyć jej egzemplarze za każdym razem, gdy dojdzie do złożenia zamówienia.

Powiązanie zdarzenia z udokumentowanym pojęciem czasownikowym da wiele korzyści:

• Usprawni komunikację między programistami a biznesem.
• Pomoże programistom lepiej zrozumieć znaczenie i kontekst zdarzenia.
• Dodatkowo zweryfikuje model dzięki zastosowaniu ww. żelaznej reguły.
• Pozwoli na powiązanie zdarzenia z odpowiednimi regułami biznesowymi.

Czy zdarzenia i fakty są tym samym?

Ale czy faktycznie instancje pojęć czasownikowych (fakty) są równoważne eventom? W powyższym przypadku wydaje się, że tak właśnie jest. Ale czy można to uznać za ogólną zasadę? Wg mnie: nie. Wszystkie zdarzenia to fakty. Ale nie wszystkie fakty są zdarzeniami.

Rozróżniam trzy rodzaje faktów, w podziale ze względu na sposób ich implementacji:

• Fakty, które powstają bezpośrednio w wyniku działań.
  Np. ww. złożenie zamówienia, które staje się rzeczywistością w bezpośrednim następstwie akcji podjętej przez klienta.
• Fakty zastane czyli fragmenty rzeczywistości, które „po prostu są”.
  Np. to, że Ziemia krąży wokół Słońca jest faktem, który powstał wiele lat przed naszą aplikacją i będzie prawdziwy (miejmy nadzieję) jeszcze wiele lat po niej. Tak samo jak to, że hetman jest figurą. Tego typu fakty możemy na sztywno zapisać w kodzie jako stałe lub wyrazić w strukturze klas.
• Fakty wywnioskowane.
  Te fakty nie są tworzone bezpośrednio w wyniku czyjegoś działania, lecz jako reakcja pośrednia. Np. mamy zdarzenie: klient złożył zamówienie. Jeśli wcześniej prawdziwy był fakt, że dany klient ma 9 złożonych zamówień oraz istnieje reguła, że każdy klient z 10-ma zamówieniami jest klientem premium, wówczas możemy wywnioskować fakt, że dany klient jest klientem premium.

Uważam, że tylko fakty pierwszej kategorii należy modelować jako zdarzenia.

Jak namierzyć zdarzenia?

Powstaje zatem pytanie: jak wyłapać zdarzenia spośród pojęć czasownikowych określonych w słowniku? Jak je odróżnić od pozostałych rodzajów faktów?

Kluczowa wg mnie jest wyraźna obecność jakiegoś działania. Jeśli czasownik da się wyrazić jako polecenie (można z niego stworzyć nazwę metody albo command 5), wówczas mamy do czynienia z eventem.

Przykład

Dla przykładu rozpatrzmy model z artykułu o diagramach modeli pojęciowych. Mamy tam pojęcie czasownikowe person owns car. Z jakiegoś powodu ten typ faktów jest ważny dla biznesu (możliwe np., że istnieje reguła biznesowa, która się na nim opiera), więc chcemy przechowywać instancje tego pojęcia (fakty o posiadaniu samochodów).

Czy taki fakt jest eventem? Wg mnie nie bardzo… Bo trudno jest tutaj wyrazić działanie, które miałoby skutkować powstaniem zdarzenia. Czy dobrze brzmi metoda person.doOwn(car); ? Czytalibyśmy to: osobo, zawłasnościuj ten samochód. Coś tu nie gra…

I w sumie słusznie. Bo fakt, że osoba jest właścicielem auta, jest pochodną innego działania, np. gdy ktoś kupił samochód lub otrzymał go w prezencie. Takie działanie łatwiej jest wyrazić w formie polecenia person.buy(car); a jego skutek przedstawić jako zdarzenie PersonBoughtCarEvent.

A zatem widzimy, że na poziomie implementacji, fakty i zdarzenia nie są tym samym, chociaż w modelu pojęciowym oba są reprezentowane jako pojęcia czasownikowe:

• person owns car,
• person buys car.

Katalog zdarzeń

Coraz częściej w tworzeniu aplikacji stosowane są architektury event driven, czyli oparte na zdarzeniach. Ich zwolennicy zwracają uwagę na pozytywny efekt uboczny takich rozwiązań: wraz z działającą aplikacją powstaje katalog eventów, czyli zbiór wszystkich zdarzeń, które obsługuje system.

Katalog pozwala przeglądać typy zdarzeń, dokumentować ich znaczenie, porządkować i zarządzać. Powstaje żywa dokumentacja systemu i biznesu. Może być czymś tak prostym jak lista wszystkich zdarzeń w systemie. Ale może też być rozbudowaną skarbnicą wiedzy, rozwijaną w oparciu o specjalne narzędzia (np. takie jak app.eventcatalog.dev).

Jakże idealnie te potrzeby, adresowane przez społeczność IT, współgrają z teorią modeli pojęciowych. Jest to po prostu inne oblicze tego samego zagadnienia. Katalog zdarzeń, dla każdego eventu, może zawierać (poza strukturą danych, numerem wersji, nazwą klasy itd.) odniesienie do odpowiadającego pojęcia czasownikowego, określonego w modelu pojęciowym.

Podsumowanie

Pojęcia czasownikowe są tym, co najbardziej odróżnia modele pojęciowe od zwykłych słowników.

To czasowniki powodują, że modele naprawdę mają sens. Poszczególne słowa zaczynają się ze sobą łączyć w prostych orzeczeniach. Te z kolei zaczynają tworzyć zdania i tak powstaje język. Wszędobylski język, którym posługujemy się na co dzień.

Narzucenie na ten język struktury, jest jak budowa rusztowania, dzięki któremu możemy budować wydajniej i bezpieczniej, bo z mniejszym ryzykiem nieporozumień.

Przypisy i bibliografia

1. Reguła pochodzi z [2].

2. Ross, R.: Business Knowledge Blueprints, Enabling Your Data to Speak the Language of the Business. Wyd. 2. 2020.

3. Oba szablony dla j. angielskiego pochodzą z Dodatku A do [4].

4. SBVR 1.5. Grudzień 2019. Semantics Of Business Vocabulary And Business Rules [online] Dostęp w internecie: https://www.omg.org/spec/SBVR/1.5

5. To, czy ten command jest wykonywany przez usera czy jest triggerowany czasem lub innym zdarzeniem, nie ma tutaj znaczenia.