UML a model pojęć

airMail XSList od czytelnika

Na początku tego tygodnia przeprowadziłem ciekawą dyskusję dotyczącą zasadności stosowania diagramu klas języka UML do tworzenia modelu pojęć. Modelu pojęć dla całej organizacji. Za zgodą autora, publikuję najistotniejszy fragment listu, który dyskusję zapoczątkował.

[…]  postanowiłem sprawdzić, co w Internecie piszą na ten temat. Okazało się, że w większości są to ogólniki. […] Na jednej z polskich stron znalazłem kilka wpisów, z których jeden wprost krytykuje taki pomysł. Nie mam bardzo dużego doświadczenia w analizie biznesowej, gdyż na co dzień pełnię rolę analityka i architekta systemów, więc ciężko mi się do niego odnieść. […] Moje doświadczenia w tym względzie wynikają przede wszystkim z kontaktów z architektami oraz efektami prac analityków biznesowych. […] W mojej organizacji podjęto decyzję o usystematyzowaniu prac analityków biznesu oraz analityków systemów […] i z naszej strony uczestniczę w pracach zespołu, który ma to (metodę przyp. aut.) wykonać. […] Z Pana wpisów wynika, iż UML można stosować do stworzenia takiego modelu. Mógłbym prosić o uzasadnienie, dlaczego Państwo wybraliście UML?

Dyskusja bardzo szybko została przeniesiona z platformy mejlowej na telekomunikacyjną, dzięki czemu udało się wymienić spostrzeżeniami, opiniami i wyciągnąć wnioski. Poniżej, przedstawiam ich krótkie podsumowanie.

Standard

UML to standard jeśli chodzi o język służący do opisu struktur informacyjnych. Celowo unikam określenia „struktur danych”, gdyż zastosowanie UML nie ogranicza się do tego aspektu prac analitycznych. Skoro to standard, to jest spore prawdopodobieństwo, że będzie zrozumiały dla stosunkowo szerokiej grupy odbiorców. Skoro to standard, to z pewnością będzie wspierany przez dużą część dostawców narzędzi do modelowania. Z tych dwóch powodów, UML jest najprawdopodobniej najlepszym wyborem w przypadku przedsięwzięć, w którym liczba różnych grup interesariuszy modelu oraz osób go wykorzystujących jest niemała.

Istota

Trzy elementy stanowią clue modelu pojęć: wyrażenie reprezentujące pojęcie, definicja oraz zależności (fakty) łączące pojęcia. Teoretycznie, można przyjąć, iż reprezentacja pojęcia nie musi być li tylko wyrażeniem słownym – może to być na przykład ikona. W praktyce można jednak założyć, iż inne reprezentacje niż wyrażenia tekstowe nie wystąpią. Skoro mamy słowa, to powinniśmy mieć i ich znaczenie. Znaczenie jest określane definicją. I ten element stanowi jeśli nie najtrudniejszy, to jeden z najtrudniejszych aspektów modelu pojęć. To właśnie od błędnych, bądź nieistniejących definicji wyrażeń tekstowych, jakimi posługują się specjaliści biznesowi, rozpoczynają się problemy komunikacyjne. Początkowo, jedynie podczas opisu sposobu funkcjonowania biznesu, a następnie przekładają się i multiplikują na etapie planowania rozwiązań IT. Ostatni z elementów to zależności pomiędzy pojęciami (w pewnym sensie, także będące pojęciami), oddające swoją nazwą oraz ewentualną definicją, logiczny ich charakter.

Cel

Po co tworzymy model pojęć? Po to, by zapisać wiedzę o jakiejś dziedzinie. Po to, by się na tej podstawie skutecznie i efektywnie komunikować . I to wszystko. Żadnych systemów, żadnych baz danych, żadnych procesów.

W przypadku analizy biznesowej, ogólne określenie wiedza najczęściej  doprecyzowuje się określeniem wiedzy dziedzinowej, czy wiedzy biznesowej.

Jak może wyglądać taki model?

Może na przykład przyjąć formę tekstową, a przykładowe zapisy mogłyby brzmieć na przykład tak. Wiedza analityczna służy analitykom biznesowym. Wiedza analityczna jest pozyskiwana od specjalistów dziedzinowych. Specjalista dziedzinowy zna obszar dziedzinowy. Specjalista dziedzinowy wspiera analityka biznesowego. Analityk biznesowy posługuje się technikami analitycznymi. Modelowanie procesów jest technika analityczną. Inżynieria reguł biznesowych jest techniką analityczną.

Jak wyglądałby taki model w notacji dedykowanej modelom pojęciowym?

CMap. To technika dedykowana takim zastosowaniom. Model wyglądałby następująco.

CMcmap.PNG

Przykładowy model w notacji CMap

Standardem UML można go zastąpić?

Tak. Poniżej odpowiednik.

CMuml

Model pojęć w notacji UML

Czy wszyscy go dobrze przeczytają?

Tak. Być może trzeba będzie poświęcić 20 minut więcej na wytłumaczenie kilku symboli UML. Może nawet 40 minut. A w przypadku stosowania zaawansowanych konwencji, może i 60 minut więcej niż w przypadku CMap, czy jakiejkolwiek innej notacji dedykowanej mapom pojęć. Ale jest to czas pomijalny z punktu widzenia przedsięwzięć polegających na wdrożeniu ogólnoorganizacyjnych modeli pojęć. Całkowicie pomijalny.

W praktyce, można sobie wyobrazić konstrukcje występujące w dedykowanych językach do modelowania pojęć, które nie dadzą się wprost zaprezentować notacją UML, aczkolwiek wystarczy zastosować proste konwencje, które bez utraty informacji i łamania jakichkolwiek zasad języka UML, pozwolą na ich reprezentację w standardzie. Dlatego uważam, iż nie ma praktycznych przeciwwskazań do stosowania UML w tym zakresie, natomiast jest kilka silnych argumentów za tym przemawiających, o których napisałem na wstępie.

Odrobina teorii dla wnikliwych

Ale czy przypadkiem UML nie został zastosowany jako obrazek, w tle łamiąc semantykę pojęć takich jak np. klasa, czy asocjacja? Nie, brzmi odpowiedź. Powołując się na autorytet w dziedzinie map pojęciowych, jakim jest profesor Joseph Novak, można przytoczyć jego definicję słowa concept, rozumianego w niniejszym wpisie jako pojęcie(*).

Concept is a perceived regularity in events or objects, or records of events or objects, designated by a label.

Pojęcie jest więc czymś, co jesteśmy sobie w stanie wyobrazić, podać jego cechy i czasami definicję, czego reprezentacją jest wyrażenie tekstowe.

Klasa w języku UML jest pośrednio wyprowadzona z pojęcia klasyfikator (ang. classifier), z którym w specyfikacji UML 2.5 skojarzono następującą definicję.

A Classifier represents a classification of instances according to their Features.

Klasyfikator obejmuje więc swoim zakresem instancje, które są zgodne co do swoich właściwości (features). Podobieństwo to można bezpośrednio przełożyć na regularność (regularity), występującą w definicji „concept”. Dalsze specjalizacje (StructuredClassifier, EncapsulatedClassifier, Class) nie zmieniają jakościowo tej definicji, dając możliwość skojarzenia z klasą dodatkowych cech, aczkolwiek żadna z tych cech nie jest obligatoryjna (rysunek poniżej) . Sama klasa zdefiniowana jest następująco.

A Class classifies a set of objects and specifies the features that characterize the structure and behavior of those objects.

 

UMLmetamodelclass

Fragment metamodelu UML 2.5 dotyczący metaklasy Class

Powyższe rozważania pokazują, iż zastąpienie dedykowanych notacji do tworzenia diagramów pojęć, diagramami klas języka UML nie wypacza w żaden sposób intencji twórców UML.

(*) Model pojęć i model koncepcji w dziedzinie analizy biznesowej są traktowane jako określenia tożsame.

 

Reklamy

OMG nie tylko dla IT – SBVR, Semantics of Business Vocabulary and Rules

Semantics of Business Vocabulary and Rules

Business Vocabulary, teoretycznie jeden z ważniejszych artefaktów architektury biznesowej, w praktyce albo nie występuje, albo występuje w postaci szczątkowej, w formach, które należy uznać za niepielęgnowalne z inżynierskiego punktu widzenia. Z moich obserwacji wynika, iż pojęcia dziedzinowe definiowane są częściej przez specjalistów dziedzinowych (sic!), odpowiedzialnych za tworzenie wewnątrzorganizacyjnych procedur, niźli analityków biznesowych firm doradczych, uczestniczących w przedsięwzięciach mających na celu usprawnienie organizacji.

Zagadnienie definiowania pojęć, a szerzej temat ujmując, tworzenia modelu koncepcji, należy traktować jako fundamentalne dla rozumienia funkcjonowania organizacji oraz jej opisu w formie modeli, bez względu na to, czy będą to modele tworzone z wykorzystaniem specjalizowanych języków modelowania (na przykład, BPMN, BMM, UML), czy tez języka naturalnego wspieranego wszystkomogącymi edytorami tekstów oraz arkuszami kalkulacyjnymi. Rzecz bowiem o rozumieniu słów, których interpretacja (czytaj: znaczenie) determinować może inne działania związane z opisywaniem pryncypiów biznesu.

Jeden na-przykład

Styczeń 2014, opisywanie przebiegów procesów biznesowych zgodnych z istniejącą architekturą procesów. Na sali dwoje konsultantów oraz Dyrektor Pionu HR. Rozmowa dotyczy procesu rekrutacji, który … kiedyś powinien się zakończyć. Omawiany scenariusz:

  • zakład produkcyjny przesyła zapotrzebowanie na pracowników liniowych,
  • dział HR umieszcza ogłoszenia w mediach, z którymi współpracuje,
  • napływają życiorysy zawodowe, na bieżąco oceniane przez pracowników Działu HR,
  • czas płynie, kandydatów zgłasza się coraz mniej i mniej,
  • zapotrzebowanie nie zostało w pełni zrealizowane.

Pojawia się oczywiste pytanie, czy kolejne działania rekrutacyjne, mające na celu realizację zapotrzebowania, będą prowadzone w ramach uruchomionej instancji procesu, czy instancji nowej. W zasadzie każdy scenariusz jest dobry, aczkolwiek martwić może fakt, iż nie ma żadnych wskazówek, które mogłyby pomóc w przesądzeniu. Pada więc, ze strony konsultantów, fundamentalne pytanie „A jak rozumiane jest w Firmie pojęcie rekrutacja?„. Odpowiedź „Hmm…dobre pytanie.

W trakcie kolejnych kilkunastu minut zdefiniowano znaczenie słowa, dzięki czemu jasno określono granice procesu oraz rozwiązano dylemat. Tylko tyle i aż tyle.

Semantics of Business Vocabulary and Rules proponuje między innymi ontologię dla opisu znaczenia słów. Więcej o zagadnieniu i podejściu do tworzenia modeli koncepcji w kolejnych wpisach.