Zapraszam wszystkich, którzy szukają pomocy, wiedzy oraz wsparcia w swoich projektach informatyzacji. Działam od 1991 roku, mój Blog działa nieprzerwanie od 1998 roku.
Jarosław Żeliński – Senior Architekt IT – Kontraktor
W niedawnym artykule SBVR czyli reguły biznesowe i słownik pisałem o diagramie faktów, o regułach i o słowniku pojęć, dzisiaj co nieco o pojęciach (tych ze słownika pojęć ;)).
Ostatnia wersja specyfikacji SBVR v.1.3. z maja tego roku, zawiera rozszerzony rozdział: 8 Linguistic Foundations, 8.1 Things, Meanings, and Expressions, 8.1.1 Semiotic/Semantic Triangle in SBVR Terms rozpoczynający się tak:
This sub clause introduces the concepts that comprise one leg, ?meaning corresponds to thing?, of the Semiotic/Semantic Triangle which was first introduced by Charles Sanders Peirce at the beginning of the twentieth century and later by (Ogden and Richards 1923). See ?Ontology, Metadata, and Semiotics? [Sowa].
Semiotic/Semantic Triangle in SBVR Terms
The Semiotic/Semantic Triangle is the theoretic basis for SBVR?s linguistics-based architecture in general and for the fundamental separation of representation (expression) from meanings in SBVR?s architecture. Being a linguisitic-based standard the instances of concepts are the things in the universe of discourse, i.e., the world of the organization that uses the SBVR Business Vocabulary, and not concepts in the SBVR model. (Źródło: SBVR)
Generalnie semantyka, semiotyka i pragmatyka to trzy kluczowe elementy lingwistyki: pojęcie (termin) mające swoja definicję (semantyka), dalej byty znaczone przez te pojęcia (pojęcie znaczy-denotuje “to coś”) to semiotyka, oraz wyrażenia zawierającego to pojęcie, które nadaje mu kontekst (pragmatyka). Nauka o tym jak rozumiemy znaki, semiotyka (słowa są także znakami), mówi że znaczenie terminu wskazuje na zbiór rzeczywistych elementów (bytów), słowo [kot] definiowane jest jak pewien typ ssaka, denotuje wszystkie zwierzęta rozpoznawane przez nas jako koty. Denotacja wynika jednak z kontekstu, czyli tego w jakim “otoczeniu znaczeniowym” słowo (znak) został użyty. Np. kształt “trójkąt” w zeszycie do geometrii oznacza abstrakcyjną figurę geometryczną, ten sam znak na drzwiach w długim korytarzy oznacza (spodziewamy się tego) męską toaletę. Dlatego stosuje się (buduje się) wyrażenia (expression) tworzące kontekst (do terminów dodaje się fakty z nimi powiązane, co wskazuje na konkretne znaczenie), zawierające dany (definiowany) termin (słowo), dla doprecyzowania znaczenia tego terminu (trójkąt umieszczany w zeszycie do geometrii, lub trójkąt umieszczany na drzwiach toalety, wyrażenie (w SBVR “wording”) “umieszczany w…” to fakt nadający pojęciu “trójkąt” kontekst).
Takimi kontekstami są tak zwane diagramy faktów. Są to diagramy, na których pojęcia zawarte w słowniku pojęć, są przedstawiane wraz z opisem, faktami, doprecyzowującymi ich znaczenie poprzez użycie w określonym kontekście. Ten kontekst, opisanie go, w toku analizy, ma jeszcze dodatkowe znaczenie: pozwala skupić się wyłącznie na tym jednym kontekście, a jest nim kontekst TEGO projektu. Z zupełnie innej strony spotykamy się z tym samym problemem przy okazji modelowania “dziedziny systemu” (lub komponentu) przy okazji projektowania komponentów, tak zwanych mikroserwisów, czy metodyki i wzorca Domain Driven Design. Pojęcie “bounded context” to nic innego jak konieczność ograniczenia analizowanego problemu do jednego kontekstu, właśnie dla zachowania spójności i jednoznaczności modelu systemu oraz jego “odpowiedzialności”, stanowiącego wymaganie np. wobec oprogramowania. Model to nic innego jak opis mechanizmu działania serca każdego systemu (core domain).
Tworząc oprogramowanie świadomie dzielimy je na komponenty bo zbyt duży (szeroki) zakres funkcjonalny prowadzi do tego, że nie możliwe jest uniknięcie niejednoznaczności. Jeden poprawnie zaprojektowany komponent obsługuje wyłącznie “jeden kontekst”, gwarantuje to spójność pojęć i spójność “modelu domeny”. Widać ten problem w zbyt dużych systemach ERP:
jeżeli chcemy obsłużyć np. takie pojęcie jak “maszyna”, to zupełnie inne ma to pojęcie znaczenie na liście środków trwałych (pozycja kosztowa, jedna z wielu, z jej cechami księgowymi) a inne na liście wyposażenia hali produkcyjnej (maszyna mająca cechy konstrukcyjne i określona przydatność), oba te byty “zachowują się” inaczej w obu tych kontekstach, każdy jest powiązany z innymi faktami w organizacji (kupiony określonym kosztem, tu nie różni się od kupionych usług, oraz jest smarowany by nie uległ awarii, tu jest to ewidentnie złożony podzespół). Tu pojawia się problem normalizacji dużych baz danych relacyjnych: próba jednokrotnego użycia każdego pojęcia (normalizacja) w wielo-kontekstowym systemie, kłóci się z wieloma kontekstami jakimi są poszczególne moduły tematyczne aplikacji. To dlatego jeden znormalizowany model danych dla dużego zintegrowanego systemu nigdy nie będzie poprawny, zawsze będzie szkodliwym kompromisem. Systemy składające się z całkowicie odseparowanych komponentów (nie współdzielą żadnych danych we wspólnej bazie danych!) są znacznie lepsze w użyciu.
Jakość biznesowego słownika terminów wyznacza wręcz jakość całej analizy, a potem projektu. Wszelkie niejednoznaczności pojęciowe prowadzą do niejednoznaczności logiki tekstu (opisu), na podstawie takiego tekstu nie da się stworzyć poprawnie działającego mechanizmu działania (np. kodu programu). Pierwszym miejscem, w którym widać te problemy są umowy i słowniki pojęć na ich początku. Poprawnie zbudowany słownik to czysta logika: definicje pojęć w słowniku powinny się wzajemnie wykluczać (zasada wyłączonego środka w logice) zaś w ramach jednego słownika (poziomu definiowanych pojęć) definicje pojęć nie mogą zawierać pojęć definiowanych.
Tak więc podejmując się analizy, warto robić to “dobrze”, można to nazwać metodą naukową i nie będzie w tym przesady. Reguły biznesowe, rygory ich tworzenia, słownik pojęć, model pojęciowy, to wszystko służy poprawie jakości wyników analizy, dokumentacji, późniejszego projektu. Specyfikacja SBVR bardzo w tym pomaga. (o formalizacji modeli)
Jeżeli mieliście kiedyś problem z projektem, to jest bardzo prawdopodobne, że jedną z kluczowych tego przyczyn był zły (lub jego brak) model pojęciowy.
Jarosław Żeliński: 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: dostęp do treści Bloga jest bezpłatny, jednak wszelka pomoc oraz wyjaśnienia dotyczące treści artykułów autora bloga, udzielane są wyłącznie w ramach płatnych konsultacji.
