Wprowadzenie

Modele UML są często postrzegane jako niezrozumiałe diagramy. Do napisania tego artykułu skłonił mnie pewien wpis na LinkedIn, w którym pokazano ciekawy schemat blokowy:

Nie tylko moim zdaniem jest to bardzo obrazowe pokazanie tego jak działają te systemy płatności, szczególnie, że bardzo dobrze jest dobrany poziom abstrakcji: autorowi udało sią pokazać istotę mechanizmu realizacji tych płatności bez zbędnych detali.

Pierwsze moje wrażenie, gdy zobaczyłem ten diagram to: to jest diagram komunikacji UML a obrazowe ikony na tym diagramie to stereotypy.

Stereotyp czyli typ elementu

UML to tak na prawdę rozdział 7. specyfikacji: pojęcie klasy i związku między klasami oraz obiekt jako instancja klasy. Klasyfikator to klasa wraz z cechami (atrybuty i zachowania), stanowiący sobą realną definicję obiektów danej klasy (definicje dzielimy na opisowe i realne ). To co na danym diagramie oznacza klasyfikator to kontekst tego diagramu a mogą to być albo pojęcia języka (np. polskiego) albo nazwy i cechy realnych elementów naszego materialnego otoczenia (komputer z oprogramowaniem to także realny byt). Innymi słowy “pies” to zarówno pozycja w słowniku języka polskiego jak i reprezentacja zwierzęcia zwanego psem. Definicja opisowa psa brzmi (SJP):

pies ?zwierzę domowe hodowane m.in. dla przyjemności lub do polowań?

Jest bez problemu zrozumiała dla człowieka, jednak całkowicie nieprzydatna do automatycznego przetwarzania (patrz system informacyjny vs. informatyczny). Dlatego, tam gdzie mowa o systemach, tam musimy posługiwać się definicjami atrybutowymi, bo tylko takie są możliwe do przetwarzania jako dane.

Rysując schematy blokowe można używać “prostokątów i łączących je linii”, większość schematów blokowych tak właśnie wygląda:

Widać, że autorzy podejmują starania by jakoś dodatkowo oznaczyć pewne grupy symboli, np. prostokąt to coś (np. działanie), romb to decyzja. jeżeli byłby to schemat organizacyjny można na takim schemacie blokowym odróżniać kształtem komórki organizacyjne od ról pracowników. Czyli jest potrzeba kategoryzacji kształtów używanych na schematach blokowych. Zwyczajowo robimy to stosując różne figury geometryczne, czasami za pomocą różnych ikon. Całość opisujemy legendą symboli czyli listą użytych kształtów i ich znaczeń. Te różne kształty to właśnie stereotypy: np. prostokąt to komórka organizacyjna a elipsa do rola, na schemacie organizacyjnym.

Jeżeli schematy blokowe są na tyle proste, że kilka różnych kształtów wystarczy do rozróżnienia ich elementów nie ma problemu, jednak każdy większy diagram, lub ich zestaw, szybko doprowadzi do wyczerpania liczby możliwych prostych figur geometrycznych. Pomocą mogą być piktogramy, czyli proste graficzne symbole, jednak to szybko prowadzi do uznaniowości interpretacji takich schematów: zaczynają być tak samo niejednoznaczne jak język potoczny.

W UML opracowano prosty system: wszystko jest prostokątem (klasą), znaczenie kształtu jest określane słownie, a słowo to jest wpisywane w prostokąt nad opisem w podwójnym łamanym nawiasie: ‘stereotyp’. Dla ułatwienia posługiwania się notacją, wybrane kluczowe nazwy (stereotypy) dostały swoje ikony np. aktor, przypadek użycia, komponent, interfejs itp..

A co z resztą? Używamy stereotypów. Np. do odwzorowania struktury organizacyjnej możemy umówić się, że nazwy elementów struktury organizacyjnej (unit) oznaczymy dodatkowo słowem ‘organizational entity’ a role w nich słowem ‘role’:

Powyższy diagram to utworzona (zadeklarowana) taksonomia pojęcia “unit”, użyty związek to generalizacja. Na bazie takiej umowy można utworzyć schemat:

Powyższe to standardowe podejście do poszerzania zakresu symboli w UML. Notacja UML, jako Unified Modeling Language, nadaje się doskonale do tworzenia wszelkich schematów blokowych, nie tylko “informatycznych”. Wystarczy zbudować słownik dziedzinowy (model pojęciowy) i wybrane pojęcia zadeklarować jako Profil (zwany czternastym typem diagramu w UML). Takie diagramy (sformalizowane, proste, niepokolorowane, itp.) jednak nadal są przez wielu traktowane jako “mało profesjonalne”. Przemawia do mnie to, że schematy blokowe UML, adresowane do nieprofesjonalistów, faktycznie mogą się wydawać “nudne i niezrozumiałe”. Jednak poważne analizy i projekty, nie raz za miliony a nawet miliardy złotych, nie powinny być tylko “ładne”.

Ikona jako stereotyp

Notacja UML, wbrew pozorom, ma dość bogaty kontekstowy zestaw symboli:

Mają one jednak głównie zastosowanie dla schematów z dziedziny technologii informatycznych. Przytoczony na początku schemat realizacji płatności co prawda jest takim schematem, ale autor zaadresował tę wiedzę do szerszego grona odbiorców. Czy można podobny zbudować w UML i po co? Cel (po co) to skorzystanie z całego mechanizmu walidacji i śladowania narzędzi CASE.

Jak? Najpierw budujemy model pojęciowy czyli profil dla symboli użytych na diagramie:

Poniżej efekt:

Niewątpliwie dla niezawodowców diagram po lewej jest atrakcyjniejszy (choć oba niosą identyczną informację). Jednak diagram prawej, sama próba jego opracowania, natychmiast pozwoli wyłapać pominiecie informacji czym jest komunikat między Apple serwer a Financial institution (nieopisana strzałka). Laikowi to nie przeszkadza, dla zawodowca jest to groźna luka w specyfikacji. To także powód, dla którego do analiz używamy sformalizowanych systemów notacyjnych a nie “nieformalnych obrazków”.

Czy można nasz sformalizowany model uatrakcyjnić? tak, bo UML pozwala zastąpić każdy stereotyp ikonką, należy jedna zadbać o ich jednoznaczność (zdefiniować je). Możemy dobrać ikony jak poniżej:

Po podstawieniu ikon w miejsce stereotypów diagram wygląda tak:

Na powyższym diagramie schemat po prawej stronie to cały czas ten sam schemat. Zapewne ten po lewej dla wielu jest atrakcyjniejszy ale poświęcając więcej czasu na dobór ikon (ja na poświęciłem tylko 15 minut) zapewne można osiągnąc lepszy efekt.

Podsumowanie

Ktoś zapyta: Po co to wszystko? Rzecz w tym, że zarządzanie grafiką prezentacyjną (spójność modeli, śladowanie, itp.) jest praktycznie niemożliwe: każda zmiana wymaga ingerencji w schematy blokowe i pracochłonne ponowne wstawianie ich do raportu z analizy (pisałem o tym w artykule o narzędziach CASE). Takie grafiki są nieprzenoszalne między narzędziami inaczej niż jako nieedytowalne bitmapy. Jednak jeżeli ktoś uzna, że schematy blokowe wyrażone bardziej “przyjaznymi” symbolami wnoszą wartość do projektu, może to zrobić. UML przewiduje to i wiele narzędzi na to pozwala (ja użyłem Visual-Paradigm).

Poniżej jeden z moich modeli w dokumentacji systemu CRM dla jednego z klientów, wykonany w UML (Visual-Paradigm). Adresatem tego rozdziału był zarząd firmy klienta i komitet sterujący projektu:

Dodatek

Rozbudowa notacji nie jest sama z siebie prosta, wymaga świadomego używania warstw MOF (Meta Object Facility), opracowania dodatkowej taksonomii dla pojęć dziedzinowych.

Poniżej cztery podstawowe warstwy MOF, notacja UML to warstwa M1 (diagramy obiektów i połączenia miedzy nimi) i warstwa M2 (diagramy klas i asocjacje jako klasy tych połączeń). Takie elementy jak aktor, komponent itp. to klasy elementów stereotypy klas, zestaw opisany w specyfikacji UML to tak zwany profil standardowy (stereotypy zdefiniowane jako standardowe elementy notacji, nie wolne ich redefiniować). Należy zwrócić uwagę, że M0 to instancje, M1 to specyfikacje instancji, M2 to klasy (pojęcia instancja i specyfikacja instancji są niestety często mylone lub nierozróżniane).

Przykład. Standardowo w UML mamy pojęcia aktora na diagramie przypadków użycia (aktor to klasa oznaczona stereotypem ‘actor’). W specyfikacji pokazano trzy dopuszczalne formy prezentacji stereotypu ‘actor’:

Bardzo często na modelach aktorem są i ludzie i inne systemy. Aby to pokazać możemy rozszerzyć stereotyp ‘actor’ o typy aktorów:

To pozwoli na opracowanie poniższego diagramu przypadków użycia:

Źródła