Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
"Jeżeli nie potrafisz czegoś narysować, to znaczy że nadal tego nie rozumiesz…"
Ronald G. Ross jest autorem lub współautorem wielu opracowań na temat modeli pojęciowych i zarządzania wiedzą . Jest także współzałożycielem Business Rule Solution LLC, oraz współtwórcą specyfikacji i notacji SBVR .
Książka
Najnowsze z powyższych opracowań to rodzaj podsumowania pewnej części dorobku autora.
Modele pojęciowe są często mylone z projektowaniem relacyjnego modelu danych, a bywa gorzej, gdy są utożsamiane z “modelem dziedziny systemu” w projektach dotyczących tworzenia aplikacji określanych jako”obiektowe”.
Książka traktuje o modelach pojęciowych, i autor definiuje je jako:
model pojęciowy: uporządkowany zbiór pojęć i związków między nimi
Podstawowym związkiem między pojęciami (nazwami) jest fakt (predykat: związek zdaniotwórczy) łączący pojęcia w poprawne i prawdziwe zdania.
Przykład: pojęcia ‘pies’ oraz ‘listonosz’ to nazwy słownikowe. Połączone faktem (predykatem) tworzą zdanie, np.: “‘Pies’ szczeka na ‘listonosza'” (z uwzględnieniem polskiej fleksji, ‘szczeka (na)’ to fakt – predykat). Jest to zdanie poprawne a także zdanie prawdziwe: jest prawdą, że “pies szczeka na listonosza” (to relacja), albo: jest możliwe, że “pies szczeka na listonosza” (jest prawdą to, że to może się to wydarzyć). Ważna rzecz: pojęcia to nie słowa, to to co opisują definicje tych pojęć (patrz: trójkąt semiotyczny i semiotyka).
Budowanie takich zdań to kontrola (testowanie) poprawności modelu pojęciowego, test spójności, kompletności i niesprzeczności modelu pojęciowego. Poprawny model pojęciowy (namespace) to podstawowy warunek np. późniejszej spójności całego systemu zarządzania informacją (także danymi), dokumentami (gromadzą dane), metadanymi (opisują dane).
Podtytuł książki to: About Vocabulary & Concept Models (O słownictwie i modelach pojęciowych). Warto wiedzieć, że znakomita większość nieudanych projektów i wdrożeń oprogramowania to skutek błędów w modelach pojęciowych (nazewnictwo).
Nazewnictwo to nie tylko nazwy dokumentów, tabel i pól (etykiet danych), to także same dane czyli nazwy stanowiące wartości pól formularzy: nazwy miast, nazwiska, nazwy przedmiotów, produktów, itp. Dawno temu już skończyły się czasy, gdy “komputery tylko liczyły” (to wtedy powstała idea relacyjnego modelu danych). Obecnie komputery przetwarzają dane nie będące liczbami, dane niestrukturalne.
Zarządzanie wiedzą to nie są obliczenia.
Autor pisze: akt tworzenia danych (zapisywanie informacji) to akt komunikacji: to przekaz (wiadomość) dla przyszłych czytelników, odbiorców tych danych. Dlatego komunikat (treść), musi (powinen) być zrozumiały i jednoznaczny. Jedynym sposobem zagwarantowania tego jest poprawność użytego zasobu pojęć (słownictwa). To właśnie jest miejsce na analizy i projektowanie: najpierw modeli pojęciowych a potem modeli i struktur danych.
Pewną wadą moim zdaniem jest wprowadzenie przez autora nowej symboliki dla generalizacji (budowanie taksonomii) w postaci “pogrubionej linii”. Jednak każdy kto zna UML i pozna SBVR, moim zdaniem, bez problemu sobie z tym poradzi (Visual Paradigm tak właśnie zrobił: generalizacje na modelach faktów obrazowane są jako strzałki z zamkniętym grotem, znane z UML, podejście to opisuje Dodatek C do specyfikacji SBVR).
Modele pojęciowe
Modele pojęciowe są bardzo często mylone z modelem procesów. Jest to konsekwencja stosowania związków skierowanych (asocjacje skierowane w UML, modele pojęciowe są wyrażane jako kontekstowe diagramy klas). Zdanie “pies szczeka na listonosza” to nie process (biznesowy), to zdanie sprawdzające poprawność użytych nazw (pies, listonosz) i rozumienia tych pojęć (komunikat) oraz prawdziwość zdania jako takiego. Przykład:
Diagram faktów notacji SBVR, przykład weryfikacji pojęć pies i listonosz oraz zdania “pies szczeka na listonosza”. (diagramy opracowane z użyciem Visual Paradigm).
Powyższy diagram zawiera dwa pojęcia słownikowe: pies, listonosz (formalnie powinny być także w słowniku i mieć swoje jednoznaczne definicje). Górna część diagramu to graficzna forma, omówionego wyżej, zdania “pies szczeka na listonosza”. Typowe zdania to co najmniej dwie nazwy połączone predykatem (faktem: szczekanie to fakt). Dolna część diagramu to zdanie zbudowane z jednej nazwy i predykatu: “Pies szczeka”. To także jest poprawne zdanie. Metoda i system notacyjny, tworzenia modeli pojęciowych (oparta na logice predykatów) została opisana i opublikowana jako standard SBVR (patrz także OWL: Web Ontology Language) .
Autor w książce dokładnie opisuje różnicę między modelem pojęciowym a modelem danych: model pojęciowy i model danych do różne modele!
Model danych i model pojęciowy to nie to samo!
Autor pokazuje także zastosowanie diagramów faktów do modelowania ontologii.
Na zakończenie
Słownik jest bardzo ważny bo stanowi fundament logiki biznesowej wyrażonej w postaci reguł biznesowych (business rules, patrz artykuł z 2015 roku: Reguły biznesowe, decyzje i pojęcia). Autor dokładnie opisuje metody tworzenia słowników i diagramów faktów, w dodatkach jest omówiony przykład kompletnego modelu wraz ze słownikiem. Tu, jako uzupełnienie, polecam książkę prof. Hołówki o logice i tworzeniu definicji pojęć .
Gorąco zachęcam do lektury tej książki, moim zdaniem jest to typowa pozycja “must have” dla każdego analityka i projektanta systemów informacyjnych. Więcej na ten temat napisałem w 2016 roku w artykule: Model pojęciowy, model danych, model dziedziny systemu.
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
Al-Fedaghi, S. (2020). Conceptual Modeling of Time for Computational Ontologies. 14.
Hołówka, T. (2012). Kultura logiczna w przykładach (Wydawnictwo Naukowe PWN, Ed.). Wydawnictwo Naukowe PWN.
Ross, R. G. (2013). Business rule concepts: getting to the point of knowledge (4th Ed). Business Rule Solutions.
Ross, R. G., & Lam, G. S. W. (2011). Building business solutions: business analysis with business rules. Business Rule Solutions.
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: 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 nieetatowy wykładowca akademicki, 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).
