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.

 


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Architektoniczne problemy w analizie biznesowej

Tytuł może się jednoznacznie kojarzyć, ale chciałbym spojrzeć nań z perspektywy tej starszej architektury. Jakiś czas temu miałem okazję rozmawiać ze znajomym architektem, z którym znamy się od czasu mojego nie do końca legalnego zamieszkiwania w akademiku okupowanym przez studentów tegoż kierunku. Nie widzieliśmy się dawno, więc w takiej czy innej formie musiało paść pytanie „A co u Ciebie?”.

Ponieważ lat kilka minęło, więc odpowiedź była dość długa, przeplatana barwnymi opowieściami z zawodowej praktyki. Jedno z zawodowych spostrzeżeń wzbudziło moje szczególne zainteresowanie. Otóż w pewnym momencie kolega stwierdził „Wiesz, najfajniej byłoby, gdyby architekt wykonywał swoją pracę na końcu przedsięwzięcia budowlanego. Na moje „???”,  odparł „Problem architektów bardzo często polega na tym, iż na początku projektu inwestor bardzo liczy każdą złotówkę. To są początki wydatków, i świadom tego, że duże pieniądze będą potrzebne później, stara się jak najwięcej budżetu zachować na te trudne chwile. W efekcie, budżet oraz czas przeznaczony na pracę architekta jest mocno ograniczony w stosunku do rzeczywistych potrzeb. Oczywiście, na końcu inwestor otrzymuje poprawny projekt, aczkolwiek jego funkcje nie zawsze odpowiadają przyszłym potrzebom, dlatego, że nie było możliwości ich rozpoznania. Czasu za mało, budżet za mały”.

Oczy zaczęły mi się świecić, podczas gdy kolega dalej tłumaczył „Najciekawsze w tym wszystkim jest to, że podczas trwania budowy znacznie większe środki są przeznaczane na korekty – tu zburzymy ścianę, tam poprowadzimy drogę, tylko trzeba studzienki przenieść, jednak zrezygnujemy z betonowych schodów, na rzecz drewnianych, tylko trzeba troszkę zmienić klatkę schodową – a już najciekawsze jest to, że tych pieniędzy prawie się nie zauważa, jednym śmiałych ruchem zwiększając wielkość przyznanego kredytu. A są one często o kilka rzędów wyższe od wydatków, jakie należałoby ponieść na etapie prac architektonicznych”.

Analogie do analizy biznesowej i systemowej w ramach procesu wytwórczego oprogramowania są oczywiste. Najciekawsze jest to, że bardzo często na wszelkiego rodzaju spotkaniach, konferencjach czy wykładach z obszaru IT podaje się budownictwo jako przykład inżynierii dużo bardziej uporządkowanej. A tu proszę, taki kamyczek do tegoż ogródka.

Czyżby więc nie tylko IT cierpiało na deficyt planowania? Czy właśnie się okazuje, że król jest nagi? To byłby smutny wniosek, gdyż tym sposobem IT utraciłoby kilkudziesięcioletni autorytet, jakim było dla niego budownictwo. Może tylko kolega ma pecha… Pewnie tak. Tak, na pewno tak.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Model pojęć – dlaczego tak trudno napotkać go w przyrodzie? Ciąg dalszy.

IdeaModel pojęć, wydawałoby się, jeden z kluczowych aspektów szeroko pojętej architektury biznesowej, jest chyba jednym z najrzadziej spotykanych w modelach rodzajów artefaktów. Pisałem o problemie we wpisie Definicja pojęcia. Odcinek 3 i do niego chciałbym teraz nawiązać. Szukając poprzednio przyczyn takiego stanu rzeczy, wymieniłem cztery, które przychodziły mi do głowy:

  • brak świadomości znaczenia modelu pojęć dla działań analitycznych,
  • niezrozumienia pojęcia „model pojęć”,
  • brak umiejętności tworzenia modelu pojęć,
  • brak umiejętności poprawnego definiowania pojęć.

W dalszym ciągu podpisuję się pod nimi, aczkolwiek niedawno, w ramach refleksji nad przeprowadzonymi pracami, do głowy przyszedł mi kolejny powód, jakim jest „oczywista oczywistość”. Oczywista oczywistość, że wiemy kto to jest Klient (od lat ich obsługujemy). Oczywista oczywistość, że wiemy czym się różni Klient potencjalny od Klienta. Oczywista oczywistość, że nie można zdefiniować ostrej granicy pomiędzy Klientem potencjalnym a Klientem. Oczywista oczywistość, że nie ma sensu definiować tych pojęć. Oczywista oczywistość, że wszyscy wiedzą jaka jest różnica pomiędzy tymi pojęciami.

Oczywiście, oczywistość „oczywistych oczywistości” w praktyce taka oczywista nie jest. Bo w praktyce, przy okazji sporej liczby projektów, w których terminologiczna nieścisłość sprawia zauważalny problem, o problemie się dyskutuje. To zajmuje czas. Ponieważ często problemy terminologiczne potrafią być złożone, może się zdarzyć, że osiągnięta zostanie wystarczająco dobra, jak na potrzeby tego, konkretnego projektu postać definicji, albo ustalone zostanie, że problem jest ważny i oczywiście należy się nim zająć, ale w jakimś kolejnym projekcie. I oby do następnej kadencji, pardon, projektu.

Oczywistą oczywistością jest natomiast to, że bez jasno określonych znaczeń niektórych pojęć, komunikacja staje się:

  • utrudniona (poprzez powracające pytania),
  • nieoptymalna (poprzez powracające pytania),
  • niepewna (nie mamy pewności, czy wszystkie strony tak samo rozumieją pojęcia).

A jeśli szwankuje komunikacja, to z pewnością odbije się to czkawką przy tak zwanej innej okazji (procesy będą niewłaściwie skonstruowane, decyzje będą bazowały na niewłaściwych założeniach, systemy będą wymagały poważnych zmian, gdy okaże się, że trzeba na wrażliwy aspekt pojęć spojrzeć z innej strony). I wydawałoby się, że argumenty te powinny działać na korzyść podejmowania trudu tworzenia modeli pojęć – niestety, w większości znanych mi przypadków nie działają. Natomiast broni składać nie można. Być może, argumentem będzie dostarczenie innej, bezdyskusyjnej wartości, do wytworzenia której niezbędnie niezbędny będzie model pojęć? Ale o tym już następnym razem…


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.