Wprowadzenie

Diagramy UML i spo­sób ich uży­cia, od same­go począt­ku ist­nie­nia tej nota­cji, budzą emo­cje i fale sprzecz­nych komen­ta­rzy. Powodem jest wyso­ki poziom abs­trak­cji eta­pu ana­li­zy i mode­lo­wa­nia jako dys­cy­pli­ny, oraz dość powszech­ne nie­zro­zu­mie­nie isto­ty ten nota­cji. Na to nakła­da się ogrom­na róż­ni­ca mię­dzy tym co nazy­wa­my ana­li­zą i pro­jek­to­wa­niem obiek­to­wym (OOAD) a obiek­to­wo-zorien­to­wa­ny­mi języ­ka­mi pro­gra­mo­wa­nia (OOP).

Notacja UML jest przez wie­lu ludzi błęd­nie trak­to­wa­na jako kolej­ny zestaw sym­bo­li do two­rze­nia ilu­stra­cji. Większość zna­nych mi dewe­lo­pe­rów uwa­ża, że te dia­gra­my im w niczym nie poma­ga­ją i gene­ral­nie mają racje, gdyż jakość i treść znacz­nej czę­ści doku­men­ta­cji powsta­ją­cej z uży­ciem UML, jest niska, i doku­men­ta­cja taka fak­tycz­nie jest nie­przy­dat­na dla dostaw­cy oprogramowania. 

Dlaczego tak jest? Moim zda­niem jest to nie­zro­zu­mie­nie tego czym jest opro­gra­mo­wa­nie, szcze­gól­nie gdy mówi­my o opro­gra­mo­wa­niu wspie­ra­ją­cym tak zwa­ny biz­nes, czy­li sze­ro­ko poj­mo­wa­ne zarzą­dza­nie infor­ma­cją. Na to nakła­da się nie­zro­zu­mie­nie róż­ni­cy mię­dzy onto­lo­gią sys­te­mu a samym sys­te­mem, oraz tego czym tak na praw­dę jest jego mecha­ni­zmem działania.

Notacja UML, podob­nie jak i inne, to meto­da komu­ni­ko­wa­nia wie­dzy, jed­nak komu­ni­ka­cja ta jest sku­tecz­na pod warun­kiem popraw­ne­go sto­so­wa­nia nota­cji. Wspólne sto­so­wa­nie nota­cji to stan­da­ry­za­cja komunikacji:

Standaryzacja jest dobrą prak­ty­ką we wszyst­kim, co robi­my w życiu. Oznacza to zatem, że korzy­sta­nie ze stan­dar­do­wych dia­gra­mów UML pomo­że uspraw­nić two­rze­nie opro­gra­mo­wa­nia ze wzglę­du na łatwe zro­zu­mie­nie mię­dzy pro­gra­mi­sta­mi. Ponadto, zro­zu­mie­nie abs­trak­cyj­ne­go cha­rak­te­ru logi­ki pro­gra­mu jest nie­zbęd­ne przy ryso­wa­niu dia­gra­mów UML. Co wię­cej, koniecz­ne jest szko­le­nie pro­gra­mi­stów, któ­rzy nie są zazna­jo­mie­ni z korzy­sta­niem z narzę­dzi pro­jek­to­wych wspo­ma­ga­nych przez UML. Można z łatwo­ścią stwier­dzić, że dobre dia­gra­my UML poma­ga­ją w dobrym roz­wo­ju opro­gra­mo­wa­nia i moż­na to osią­gnąć, jeśli mode­lo­wa­nie dowol­ne­go sys­te­mu przy uży­ciu pro­jek­tu UML odby­wa się w zro­zu­mia­ły i przej­rzy­sty spo­sób, tak aby każ­dy pro­gra­mi­sta mógł łatwo zro­zu­mieć dia­gra­my UML.

Pisałem bar­dzo dużo o mode­lo­wa­niu i zarzą­dza­niu infor­ma­cją, tu opi­szę pod­sta­wo­we poję­cia doty­czą­ce mode­lo­wa­nia i klu­czo­we dia­gra­my UML od stro­ny ich kla­sy­fi­ka­cji i zastosowania.

Taksonomia diagramów UML

Pojęcie ​„dia­gram w UML” ozna­cza okre­ślo­ny typ sche­ma­tu blo­ko­we­go. Taksonomię tych dia­gra­mów (kla­sy­fi­ka­cja rodza­jo­wa) poka­za­no poniżej:

Klasyfikacja rodza­jo­wa to powyż­szy podział: dia­gra­my dzie­li­my na te, któ­re opi­su­ją struk­tu­ry i te któ­re opi­su­ją­ce zacho­wa­nia. W UML jest jed­nak tak­że wyróż­nio­na kla­sy­fi­ka­cja ze wzglę­du na zasto­so­wa­nie w mode­lo­wa­niu, któ­ra ma trzy głów­ne obsza­ry semantyczne. 

Diagramy

Diagram w nota­cji UML to obszar zawie­ra­ją­cy (gru­pu­ją­cy) ele­men­ty (iko­ny) nota­cji oraz ich związ­ki. Jest obra­mo­wa­ny i zawie­ra fisz­kę z nagłów­kiem, ta zawie­ra sym­bol typu dia­gra­mu i jego tytuł. Pojęcie dia­gram w UML jest ści­śle powią­za­ne z poję­ciem model (repo­zy­to­rium). Notacja wpro­wa­dza róż­ne typy dia­gra­mów UML. Model UML skła­da się z ele­men­tów takich jak pakie­ty, kla­sy i aso­cja­cje. Odpowiadające im dia­gra­my UML to gra­ficz­ne repre­zen­ta­cje czę­ści mode­lu UML, dia­gram – jako ele­ment gru­pu­ją­cy – jest typem pakietu.

Diagramy w UML zosta­ły pogru­po­wa­ne na trzy obsza­ry semantyczne:

• struk­tu­ry: mamy tu takie poję­cia jak war­to­ści, kla­sy i pakiety
• zacho­wa­nia: mamy takie poję­cia jak maszy­ny sta­no­we, aktyw­no­ści, inte­rak­cje, zada­nia (akcje),
• dia­gra­my pomoc­ni­cze: mamy tu takie poję­cia jak przy­pad­ki uży­cia, wdro­że­nie (roz­lo­ko­wa­nie), prze­pływ informacji. 

Modele sys­te­mów słu­żą do wyra­że­nia tego jak sys­tem ma sie zacho­wy­wać (mecha­nizm) w odpo­wie­dzi na okre­ślo­ne bodź­ce. Podstawowe obsza­ry mode­lo­wa­nia sys­te­mów to: wyma­ga­nia, struk­tu­ra (archi­tek­tu­ra) sys­te­mu, oraz zacho­wa­nia sys­te­mu (to jak on i jego ele­men­ty, reagu­je na bodź­ce). Wyodrębnione dia­gra­my pomoc­ni­cze w UML moż­na uznać za meto­dy wyra­ża­nia wymagań. 

Szczególnym i bar­dzo waż­nym dia­gra­mem jest – pomoc­ni­czy – dia­gram przy­pad­ków uży­cia, któ­ry gru­pu­je wyma­ga­nia funk­cjo­nal­ne przy­po­rząd­ko­wu­jąc je do mode­li zacho­wa­nia sys­te­mu, oraz orga­ni­zu­je pozo­sta­łe mode­le: każ­dy przy­pa­dek uży­cia to sce­na­riu­sze opi­su­ją­ce inte­rak­cje i zacho­wa­nia ele­men­tów archi­tek­tu­ry sys­te­mu. Całość moż­na zobra­zo­wać jak poniżej: 

Diagramy wdro­że­nia (roz­lo­ko­wa­nia) i prze­pły­wu infor­ma­cji moż­na potrak­to­wać jako model wyma­gań pozafunkcjonalnych. 

Należy tu pod­kre­ślić, że sło­wo wyma­ga­nia ozna­cza ocze­ki­wa­nia wobec sys­te­mu, cele inte­re­sa­riu­szy to ich potrze­by mapo­wa­ne na model systemu. 

Np. potrze­bą inte­re­sa­riu­sza może być moż­li­wość spraw­dze­nia adre­su kon­tra­hen­ta, jej zaspo­ko­je­niem może być dostęp do histo­rii fak­tur, gdyż na fak­tu­rach są adre­sy kon­tra­hen­tów. Wymaganiem wobec sys­te­mu jest ist­nie­nie tego adre­sy na fak­tu­rach (tego aku­rat wyma­ga tak­że pra­wo, więc jest to tak­że wyma­ga­nie praw­ne). Wymaganie to doku­men­tu­je­my two­rząc struk­tu­ral­ny model fak­tu­ry (dia­gram struk­tur złożonych).

Elementy modeli

Podstawowym poję­ciem w UML jest ele­ment (ele­ment mode­lu) oraz jego spe­cy­ficz­ne typy: zwią­zek, zwią­zek skie­ro­wa­ny oraz komen­tarz. Elementy mogą zawie­rać sie­bie nawza­jem, co do zasa­dy komen­tarz jest zawar­ty w ele­men­cie komen­to­wa­nym (jest jego czę­ścią, rozdz.7, Figure 7.1 Root). [w nawia­sach poda­no nume­ry odpo­wied­nich roz­dzia­łów w spe­cy­fi­ka­cji UML, 2.5.1. z 5 maja 2017 roku), co obra­zu­je poniż­szy diagram:

Specjalnym typem kla­sy jest war­tość (Value, rozdz. 8). Jest to kla­sa, któ­rej obiek­ty nie mają toż­sa­mo­ści (odpo­wied­nik value object we wzor­cu DDD). 

Klasa to pod­sta­wo­wy ele­ment mode­lo­wa­nia w UML. Służy do mode­lo­wa­nia struk­tur poję­cio­wych (name­spa­ce) lub struk­tur opi­su­ja­cych archi­tek­tu­ry sys­te­mów na róż­nych pozio­mach abs­trak­cji. Klasa to nazwa­ny ele­ment mode­lu, kla­sy­fi­ka­tor to defi­ni­cja obiek­tów danej kla­sy (tak zwa­na defi­ni­cja real­na) czy­li cechy obiek­tów tej kla­sy: atry­bu­ty i ope­ra­cje (rozdz. 9). 

Klasyfikator może być pro­sty (rozdz. 10). Proste kla­sy­fi­ka­to­ry stan­dar­do­wo są uży­wa­ne do defi­nio­wa­nia struk­tu­ral­nych typów danych. Klasyfikator zło­żo­ny zawie­ra drze­wia­sta struk­tu­rę zagnież­dże­nia. Jeżeli kla­sa repre­zen­tu­je zło­żo­ny wewnętrz­nie ele­ment archi­tek­tu­ry sys­te­mu, moż­na na dia­gra­mach użyć jej uprosz­czo­nej for­my jakim jest kom­po­nent (rozdz. 11).

Pakiet to ele­ment gru­pu­ją­cy. Jego cechą jest to, że nie ma on instan­cji. Pakiet słu­ży do orga­ni­zo­wa­nia ele­men­tów mode­lu. Specjalnym typem pakie­tu jest Model. Jest to pakiet gru­pu­ją­cy wszyst­kie ele­men­ty mode­lu okre­ślo­ne­go sys­te­mu, jego per­spek­ty­wy lub pozio­mu abs­trak­cji (rozdz.12).

Zachowania to opis tego jak zacho­wu­ją się i współ­pra­cu­ją ze sobą ele­men­ty struk­tu­ry sys­te­mu, jego kom­po­nen­ty. Zachowanie okre­ślo­ne­go ele­men­tu sys­te­mu to jego reak­cja na bodź­ce: ope­ra­cje. Operacja to spo­sób jej wywo­ła­nie (nazwa bodź­ca), mecha­nizm two­rzą­cy odpo­wiedź to meto­da ope­ra­cji (pro­ce­du­ra, algo­rytm) (rozdz. 13).

Zachowania ele­men­tu mogą zale­żeć od jego aktu­al­ne­go sta­nu i mogą tak­że powo­do­wać zmia­ny tego sta­nu. Nośnikiem war­to­ści sta­nu są okre­ślo­ne atry­bu­ty (rozdz. 14). Operacje i ich łań­cu­chy moż­na mode­lo­wać na wyż­szym pozio­mie abs­trak­cji jako aktyw­no­ści (rozdz. 15). Na pozio­mie metod są to pro­ce­du­ry i algo­ryt­my zło­żo­ne z ele­men­tar­nych kro­ków (rozdz. 16). Diagramy aktyw­no­ści mogą posłu­żyć tak­że do mode­lo­wa­nia prze­pły­wu danych (obiek­tów nio­są­cych treść). 

Scenariusze opi­su­ją­ce współ­dzia­ła­nie ele­men­tów sys­te­mu (wza­jem­ne wywo­ła­nia ope­ra­cji przez obiek­ty, pro­to­kół komu­ni­ka­cyj­ny) mode­lo­wa­ne są jako inte­rak­cje. Interakcje naj­czę­ściej mode­lu­je­my z uży­ciem dia­gra­mu sekwen­cji, rza­dziej z uży­ciem dia­gra­mu komu­ni­ka­cji (rozdz. 17). 

Kluczową róż­ni­cą mie­dzy aktyw­no­ścią a inte­rak­cją, jest to, że aktyw­no­ści repre­zen­tu­ją odpo­wie­dzial­ność klas i kom­po­nen­tów, a inte­rak­cje repre­zen­tu­ją wywo­ła­nia ope­ra­cji i ich parametry.

W celu poka­za­nia sys­te­mu z per­spek­ty­wy inte­re­sa­riu­szy i bez­po­śred­nie­go oto­cze­nia tego sys­te­mu, sto­su­je­my pomoc­ni­czy dia­gram, jakim jest dia­gram przy­pad­ków uży­cia. Celem two­rze­nia tego dia­gra­mu jest zobra­zo­wa­nie zakre­su (gra­ni­cy) sys­te­mu, jego inte­re­sa­riu­szy (aktor), oraz tego do cze­go sys­tem słu­ży (przy­pa­dek uży­cia). Diagram ten słu­ży do udo­ku­men­to­wa­nia tego CO sys­tem robi, a nie JAK to robi (rozdz. 18). To jak sys­tem to robi opi­su­je­my z pomo­cą innych mode­li (sekwen­cji, aktywności).

Techniczne śro­do­wi­sko sys­te­mu opi­su­je­my jako jego obec­ne, lub pla­no­wa­ne, roz­lo­ko­wa­nie: sprzęt, sys­te­mu ope­ra­cyj­ne, śro­do­wi­ska wyko­naw­cze, fra­me­wor­ki, kom­po­nen­ty apli­ka­cyj­ne (roz­dział 19). Aby poka­zać prze­pły­wy danych na tym pozio­mie moż­na dodat­ko­wo użyć mode­li prze­pły­wu infor­ma­cji (roz­dzał 20).

Modele

Podręcznikowa struk­tu­ra mode­li opi­su­ją­cych sys­tem to struk­tu­ra, któ­rej korze­niem są ofe­ro­wa­ne inte­re­sa­riu­szom usłu­gi sys­te­mu: przy­pad­ki uży­cia. Diagram przy­pad­ków uży­cia to model sys­te­mu wyra­żo­ny jako ​„czar­na skrzyn­ka” .

Architekturę HLD (High Level Design) całe­go sys­te­mu mode­lu­je­my dia­gra­mem kom­po­nen­tów. Wewnętrzną archi­tek­tu­rę kom­po­nen­tów (model struk­tu­ry LLD) reali­zu­ją­cych usłu­gi apli­ka­cji (przy­pad­ki uży­cia) mode­lu­je­my z uży­ciem dia­gra­mów klas (tu wyra­ża­ją one archi­tek­tu­rę a nie pojęcia). 

Współdziałanie kom­po­nen­tów sys­te­mu mode­lu­je­my dia­gra­ma­mi inte­rak­cji. Metody i sce­na­riu­sze ich wywo­ły­wa­nia mode­lu­je­my (jeże­li jest taka potrze­ba) z uży­ciem dia­gra­mów aktyw­no­ści. Automatyczne zmia­ny war­to­ści wybra­nych atry­bu­tów mode­lu­je­my z uży­ciem maszyn sta­no­wych. W uprosz­cze­niu struk­tu­rę tych mode­li moż­na zobra­zo­wać tak:

Powyższy sche­mat pomi­ja bar­dzo waż­ny ele­ment jakim jest prze­strzeń poję­cio­wa. To co nazy­wa­my mode­lem dzie­dzi­ny, to model poję­cio­wy: dia­gram klas, na któ­rym kla­sy repre­zen­tu­ją poję­cia z języ­ka natu­ral­ne­go a aso­cja­cje związ­ki mię­dzy nimi. Nie są to ele­men­ty archi­tek­tu­ry sys­te­mu. Mylenie tych rze­czy: nazwy i ele­men­ty sys­te­mu, to powszech­nie popeł­nia­ny błąd. Prawdopodobnie jest to skut­kiem nale­cia­ło­ści z mode­li ERD opi­su­ja­cych rela­cyj­ne mode­le danych. Jednak nale­ży pamię­tać, że model danych nie jest mode­lem sys­te­mu, i budo­wa­nie dia­gra­mów klas w celu mode­lo­wa­nia danych jest poważ­nym błę­dem .

Spójny pro­ces ana­li­zy i pro­jek­to­wa­nia opi­sa­li Doug Rosenberg i Matt Stephens . Wskazali któ­re dia­gra­my UML, kie­dy i do cze­go należ użyć:

Tu jaw­nie wska­za­no, że koniecz­ny jest model poję­cio­wy (Domain Model), któ­ry dopie­ro zosta­nie wyko­rzy­sta­ny do budo­wy archi­tek­tu­ry kodu obiek­to­we­go (Class Model).

Związki mię­dzy ele­men­ta­mi dia­gra­mów dzie­li­my na dwa rodza­je: związ­ki poję­cio­we i związ­ki archi­tek­to­nicz­ne (rozdz.9). Asocjacje i gene­ra­li­za­cje to związ­ki poję­cio­we (mode­le poję­cio­we, «doma­in model»). Związkami struk­tu­ral­ny­mi na mode­lach archi­tek­tu­ry sys­te­mu, są: zależ­ność, jej szcze­gól­ny typ: zwią­zek uży­cia, oraz realizacja. 

Z uwa­gi na to, że dia­gra­my kom­po­nen­tów i struk­tur zło­żo­nych pozwa­la­ją na bar­dziej intu­icyj­ne umiesz­cza­nie ele­men­tów nie­któ­rych mode­li wewnątrz sie­bie, sto­so­wa­nie związ­ków kom­po­zy­cji i aso­cja­cji na mode­lach archi­tek­tu­ry (struk­tur) powo­li tra­ci zasto­so­wa­nie. Poniższy przy­kład (rozdz.11.) poka­zu­je dwa spo­so­by poka­za­nie tej samej tre­ści na mode­lach struk­tu­ry systemów:

Struktura (i) po lewej powsta­ła z uży­ciem klas i związ­ków aso­cja­cyj­nych, w tym kom­po­zy­cji (dia­gram klas). Po pra­wej (ii) mamy to samo, ale wyra­żo­ne z uży­ciem dia­gra­mu struk­tur złożonych. 

Podsumowanie

Celem tego arty­ku­łu jest poka­za­nie UML z per­spek­ty­wy typów dia­gra­mów. Jednak spe­cy­fi­ka­cja UML to opis języ­ka, a nie pod­ręcz­nik ana­li­zy i mode­lo­wa­nia OOAD. Dlatego waż­ne jest nie tyl­ko pozna­nie nota­cji UML, ale tak­że stu­dio­wa­nie para­dyg­ma­tów, wzor­ców archi­tek­to­nicz­nych i dobrych prak­tyk mode­lo­wa­nia systemów. 

Nie przy­ta­cza­łem w tym tek­ście przy­kła­dów dia­gra­mów, jest wie­le publi­ka­cji na ten temat (w tym moja ). Nie opi­sa­łem tu wszyst­kich czter­na­stu typów dia­gra­mów, gdyż sku­pi­łem się na tych, któ­re są wyko­rzy­sty­wa­ne w codzien­nej prak­ty­ce pro­jek­to­wa­nia. Powyższe to nie­ca­łe 10% całej nota­cji UML, wyko­rzy­sty­wa­ne w 99% pro­jek­tów z uży­ciem tej nota­cji (moim zda­niem). Ich sto­so­wa­nie opi­sa­łem w arty­ku­le na temat ICONIX.

Gorąco odra­dzam książ­ki i mate­ria­ły, napi­sa­ne przed 2015 roku (rok publi­ka­cji UML v.2.5), moim zda­niem w więk­szo­ści (poza nie­któ­ry­mi pra­ca­mi ogól­ny­mi) przy­no­szą one wie­le szkód i powo­du­ją ogrom nieporozumień. 

Na koniec: po co nam te mode­le i dokumenty:

Udokumentowanie pro­ble­mu, dostęp­nych roz­wią­zań i pla­nu dostar­cze­nia war­to­ści pozwa­la wszyst­kim osią­gnąć suk­ces. Przynajmniej w ten spo­sób sta­je się jasne, jaki pro­blem ty i twój zespół pró­bu­je­cie roz­wią­zać i jakie roz­wią­za­nia są dostęp­ne – i któ­re z nich wybra­łeś – spra­wia, że jest jasne dla każ­de­go, kto to czy­ta (zespół, inte­re­sa­riu­sze, zarząd, klient), w jaki spo­sób zamie­rzasz dostar­czyć war­tość. Jeśli nie możesz tego zapi­sać i uzy­skać zgo­dy inte­re­sa­riu­szy, i tak musisz wyko­nać tę pra­cę: po pro­stu zanur­ku­jesz w kodo­wa­nie mając nadzie­ję, że wszyst­ko się uło­ży. Jednak nadzie­ja nie jest dobrą strategią.

Z per­spek­ty­wy pro­jek­tów reali­zo­wa­nych w zgo­dzie z MBSE, pro­jek­to­wa­nie opro­gra­mo­wa­nia (apli­ka­cji) zorien­to­wa­ne na przy­pad­ki uży­cia, reali­zo­wa­ne jako mikro-usłu­gi (mikro­ser­wi­sy), a te jako mają­ce kom­po­nen­to­wą archi­tek­tu­re ele­men­ty sys­te­mu, moż­na przed­sta­wić jak poniżej:

Poster: struk­tu­ra opi­su tech­nicz­ne­go kodu aplikacji:

Polecam tak­że cie­ka­wy refe­rat o mode­lo­wa­niu i diagramach:

Źródła