Wprowadzenie

Modele UML są czę­sto postrze­ga­ne jako nie­zro­zu­mia­łe dia­gra­my. Do napi­sa­nia tego arty­ku­łu skło­nił mnie pewien wpis na LinkedIn, w któ­rym poka­za­no cie­ka­wy sche­mat blokowy:

Nie tyl­ko moim zda­niem jest to bar­dzo obra­zo­we poka­za­nie tego jak dzia­ła­ją te sys­te­my płat­no­ści, szcze­gól­nie, że bar­dzo dobrze jest dobra­ny poziom abs­trak­cji: auto­ro­wi uda­ło sią poka­zać isto­tę mecha­ni­zmu reali­za­cji tych płat­no­ści bez zbęd­nych detali.

Pierwsze moje wra­że­nie, gdy zoba­czy­łem ten dia­gram to: to jest dia­gram komu­ni­ka­cji UML a obra­zo­we iko­ny na tym dia­gra­mie to stereotypy. 

Stereotyp czyli typ elementu

UML to tak na praw­dę roz­dział 7. spe­cy­fi­ka­cji: poję­cie kla­sy i związ­ku mię­dzy kla­sa­mi oraz obiekt jako instan­cja kla­sy. Klasyfikator to kla­sa wraz z cecha­mi (atry­bu­ty i zacho­wa­nia), sta­no­wią­cy sobą real­ną defi­ni­cję obiek­tów danej kla­sy (defi­ni­cje dzie­li­my na opi­so­we i real­ne ). To co na danym dia­gra­mie ozna­cza kla­sy­fi­ka­tor to kon­tekst tego dia­gra­mu a mogą to być albo poję­cia języ­ka (np. pol­skie­go) albo nazwy i cechy real­nych ele­men­tów nasze­go mate­rial­ne­go oto­cze­nia (kom­pu­ter z opro­gra­mo­wa­niem to tak­że real­ny byt). Innymi sło­wy ​„pies” to zarów­no pozy­cja w słow­ni­ku języ­ka pol­skie­go jak i repre­zen­ta­cja zwie­rzę­cia zwa­ne­go psem. Definicja opi­so­wa psa brzmi (SJP):

pies ?zwie­rzę domo­we hodo­wa­ne m.in. dla przy­jem­no­ści lub do polowań?

Jest bez pro­ble­mu zro­zu­mia­ła dla czło­wie­ka, jed­nak cał­ko­wi­cie nie­przy­dat­na do auto­ma­tycz­ne­go prze­twa­rza­nia (patrz sys­tem infor­ma­cyj­ny vs. infor­ma­tycz­ny). Dlatego, tam gdzie mowa o sys­te­mach, tam musi­my posłu­gi­wać się defi­ni­cja­mi atry­bu­to­wy­mi, bo tyl­ko takie są moż­li­we do prze­twa­rza­nia jako dane.

Rysując sche­ma­ty blo­ko­we moż­na uży­wać ​„pro­sto­ką­tów i łączą­cych je linii”, więk­szość sche­ma­tów blo­ko­wych tak wła­śnie wygląda: 

Widać, że auto­rzy podej­mu­ją sta­ra­nia by jakoś dodat­ko­wo ozna­czyć pew­ne gru­py sym­bo­li, np. pro­sto­kąt to coś (np. dzia­ła­nie), romb to decy­zja. jeże­li był­by to sche­mat orga­ni­za­cyj­ny moż­na na takim sche­ma­cie blo­ko­wym odróż­niać kształ­tem komór­ki orga­ni­za­cyj­ne od ról pra­cow­ni­ków. Czyli jest potrze­ba kate­go­ry­za­cji kształ­tów uży­wa­nych na sche­ma­tach blo­ko­wych. Zwyczajowo robi­my to sto­su­jąc róż­ne figu­ry geo­me­trycz­ne, cza­sa­mi za pomo­cą róż­nych ikon. Całość opi­su­je­my legen­dą sym­bo­li czy­li listą uży­tych kształ­tów i ich zna­czeń. Te róż­ne kształ­ty to wła­śnie ste­reo­ty­py: np. pro­sto­kąt to komór­ka orga­ni­za­cyj­na a elip­sa do rola, na sche­ma­cie organizacyjnym.

Jeżeli sche­ma­ty blo­ko­we są na tyle pro­ste, że kil­ka róż­nych kształ­tów wystar­czy do roz­róż­nie­nia ich ele­men­tów nie ma pro­ble­mu, jed­nak każ­dy więk­szy dia­gram, lub ich zestaw, szyb­ko dopro­wa­dzi do wyczer­pa­nia licz­by moż­li­wych pro­stych figur geo­me­trycz­nych. Pomocą mogą być pik­to­gra­my, czy­li pro­ste gra­ficz­ne sym­bo­le, jed­nak to szyb­ko pro­wa­dzi do uzna­nio­wo­ści inter­pre­ta­cji takich sche­ma­tów: zaczy­na­ją być tak samo nie­jed­no­znacz­ne jak język potoczny. 

W UML opra­co­wa­no pro­sty sys­tem: wszyst­ko jest pro­sto­ką­tem (kla­są), zna­cze­nie kształ­tu jest okre­śla­ne słow­nie, a sło­wo to jest wpi­sy­wa­ne w pro­sto­kąt nad opi­sem w podwój­nym łama­nym nawia­sie: «ste­reo­typ». Dla uła­twie­nia posłu­gi­wa­nia się nota­cją, wybra­ne klu­czo­we nazwy (ste­reo­ty­py) dosta­ły swo­je iko­ny np. aktor, przy­pa­dek uży­cia, kom­po­nent, inter­fejs itp.. 

A co z resz­tą? Używamy ste­reo­ty­pów. Np. do odwzo­ro­wa­nia struk­tu­ry orga­ni­za­cyj­nej może­my umó­wić się, że nazwy ele­men­tów struk­tu­ry orga­ni­za­cyj­nej (unit) ozna­czy­my dodat­ko­wo sło­wem «orga­ni­za­tio­nal enti­ty» a role w nich sło­wem «role»:

Powyższy dia­gram to utwo­rzo­na (zade­kla­ro­wa­na) tak­so­no­mia poję­cia ​„unit”, uży­ty zwią­zek to gene­ra­li­za­cja. Na bazie takiej umo­wy moż­na utwo­rzyć schemat:

Powyższe to stan­dar­do­we podej­ście do posze­rza­nia zakre­su sym­bo­li w UML. Notacja UML, jako Unified Modeling Language, nada­je się dosko­na­le do two­rze­nia wszel­kich sche­ma­tów blo­ko­wych, nie tyl­ko ​„infor­ma­tycz­nych”. Wystarczy zbu­do­wać słow­nik dzie­dzi­no­wy (model poję­cio­wy) i wybra­ne poję­cia zade­kla­ro­wać jako Profil (zwa­ny czter­na­stym typem dia­gra­mu w UML). Takie dia­gra­my (sfor­ma­li­zo­wa­ne, pro­ste, nie­po­ko­lo­ro­wa­ne, itp.) jed­nak nadal są przez wie­lu trak­to­wa­ne jako ​„mało pro­fe­sjo­nal­ne”. Przemawia do mnie to, że sche­ma­ty blo­ko­we UML, adre­so­wa­ne do nie­pro­fe­sjo­na­li­stów, fak­tycz­nie mogą się wyda­wać ​„nud­ne i nie­zro­zu­mia­łe”. Jednak poważ­ne ana­li­zy i pro­jek­ty, nie raz za milio­ny a nawet miliar­dy zło­tych, nie powin­ny być tyl­ko ​„ład­ne”.

Ikona jako stereotyp

Notacja UML, wbrew pozo­rom, ma dość boga­ty kon­tek­sto­wy zestaw symboli:

Mają one jed­nak głów­nie zasto­so­wa­nie dla sche­ma­tów z dzie­dzi­ny tech­no­lo­gii infor­ma­tycz­nych. Przytoczony na począt­ku sche­mat reali­za­cji płat­no­ści co praw­da jest takim sche­ma­tem, ale autor zaadre­so­wał tę wie­dzę do szer­sze­go gro­na odbior­ców. Czy moż­na podob­ny zbu­do­wać w UML i po co? Cel (po co) to sko­rzy­sta­nie z całe­go mecha­ni­zmu wali­da­cji i śla­do­wa­nia narzę­dzi CASE. 

Jak? Najpierw budu­je­my model poję­cio­wy czy­li pro­fil dla sym­bo­li uży­tych na diagramie:

Poniżej efekt:

Niewątpliwie dla nie­za­wo­dow­ców dia­gram po lewej jest atrak­cyj­niej­szy (choć oba nio­są iden­tycz­ną infor­ma­cję). Jednak dia­gram pra­wej, sama pró­ba jego opra­co­wa­nia, natych­miast pozwo­li wyła­pać pomi­nie­cie infor­ma­cji czym jest komu­ni­kat mię­dzy Apple ser­wer a Financial insti­tu­tion (nie­opi­sa­na strzał­ka). Laikowi to nie prze­szka­dza, dla zawo­dow­ca jest to groź­na luka w spe­cy­fi­ka­cji. To tak­że powód, dla któ­re­go do ana­liz uży­wa­my sfor­ma­li­zo­wa­nych sys­te­mów nota­cyj­nych a nie ​„nie­for­mal­nych obrazków”. 

Czy moż­na nasz sfor­ma­li­zo­wa­ny model uatrak­cyj­nić? tak, bo UML pozwa­la zastą­pić każ­dy ste­reo­typ ikon­ką, nale­ży jed­na zadbać o ich jed­no­znacz­ność (zde­fi­nio­wać je). Możemy dobrać iko­ny jak poniżej:

Po pod­sta­wie­niu ikon w miej­sce ste­reo­ty­pów dia­gram wyglą­da tak:

Na powyż­szym dia­gra­mie sche­mat po pra­wej stro­nie to cały czas ten sam sche­mat. Zapewne ten po lewej dla wie­lu jest atrak­cyj­niej­szy ale poświę­ca­jąc wię­cej cza­su na dobór ikon (ja na poświę­ci­łem tyl­ko 15 minut) zapew­ne moż­na osią­gnąc lep­szy efekt. 

Podsumowanie

Ktoś zapy­ta: Po co to wszyst­ko? Rzecz w tym, że zarzą­dza­nie gra­fi­ką pre­zen­ta­cyj­ną (spój­ność mode­li, śla­do­wa­nie, itp.) jest prak­tycz­nie nie­moż­li­we: każ­da zmia­na wyma­ga inge­ren­cji w sche­ma­ty blo­ko­we i pra­co­chłon­ne ponow­ne wsta­wia­nie ich do rapor­tu z ana­li­zy (pisa­łem o tym w arty­ku­le o narzę­dziach CASE). Takie gra­fi­ki są nie­prze­no­szal­ne mię­dzy narzę­dzia­mi ina­czej niż jako nie­edy­to­wal­ne bit­ma­py. Jednak jeże­li ktoś uzna, że sche­ma­ty blo­ko­we wyra­żo­ne bar­dziej ​„przy­ja­zny­mi” sym­bo­la­mi wno­szą war­tość do pro­jek­tu, może to zro­bić. UML prze­wi­du­je to i wie­le narzę­dzi na to pozwa­la (ja uży­łem Visual-Paradigm).

Poniżej jeden z moich mode­li w doku­men­ta­cji sys­te­mu CRM dla jed­ne­go z klien­tów, wyko­na­ny w UML (Visual-Paradigm). Adresatem tego roz­dzia­łu był zarząd fir­my klien­ta i komi­tet ste­ru­ją­cy projektu:

Dodatek

Rozbudowa nota­cji nie jest sama z sie­bie pro­sta, wyma­ga świa­do­me­go uży­wa­nia warstw MOF (Meta Object Facility), opra­co­wa­nia dodat­ko­wej tak­so­no­mii dla pojęć dziedzinowych. 

Poniżej czte­ry pod­sta­wo­we war­stwy MOF, nota­cja UML to war­stwa M1 (dia­gra­my obiek­tów i połą­cze­nia mie­dzy nimi) i war­stwa M2 (dia­gra­my klas i aso­cja­cje jako kla­sy tych połą­czeń). Takie ele­men­ty jak aktor, kom­po­nent itp. to kla­sy ele­men­tów ste­reo­ty­py klas, zestaw opi­sa­ny w spe­cy­fi­ka­cji UML to tak zwa­ny pro­fil stan­dar­do­wy (ste­reo­ty­py zde­fi­nio­wa­ne jako stan­dar­do­we ele­men­ty nota­cji, nie wol­ne ich rede­fi­nio­wać). Należy zwró­cić uwa­gę, że M0 to instan­cje, M1 to spe­cy­fi­ka­cje instan­cji, M2 to kla­sy (poję­cia instan­cja i spe­cy­fi­ka­cja instan­cji są nie­ste­ty czę­sto mylo­ne lub nierozróżniane).

Przykład. Standardowo w UML mamy poję­cia akto­ra na dia­gra­mie przy­pad­ków uży­cia (aktor to kla­sa ozna­czo­na ste­reo­ty­pem «actor»). W spe­cy­fi­ka­cji poka­za­no trzy dopusz­czal­ne for­my pre­zen­ta­cji ste­reo­ty­pu «actor»:

Bardzo czę­sto na mode­lach akto­rem są i ludzie i inne sys­te­my. Aby to poka­zać może­my roz­sze­rzyć ste­reo­typ «actor» o typy aktorów:

To pozwo­li na opra­co­wa­nie poniż­sze­go dia­gra­mu przy­pad­ków użycia:

Źródła