Związki między elementami w modelach systemów – zawieranie, dekompozycja i zależności

Wprowadzenie

Tym razem arty­kuł na temat typów związ­ków mię­dzy ele­men­ta­mi w mode­lach sys­te­mów. Modele tego typu to hie­rar­chicz­na struk­tu­ra mają­ca kil­ka róż­nych per­spek­tyw, pozio­mów abs­trak­cji i pozio­mów dekom­po­zy­cji. Do tego docho­dzą fizycz­ne i logicz­ne powią­za­nia mię­dzy ele­men­ta­mi oraz fakt, że każ­dy sys­tem to okre­ślo­ne mate­rial­ne” ele­men­ty uło­żo­ne w hie­rar­chicz­ną struk­tu­rę. Każdy sys­tem skła­da się ze skoń­czo­nej licz­by ele­men­tów o skoń­czo­nej licz­bie typów. 

Na to wszyst­ko nakła­da się struk­tu­ra wyma­gań na sys­tem, oraz koniecz­ność wyka­za­nia zgod­no­ści pro­jek­tu sys­te­mu z tymi wyma­ga­nia­mi .

Bardzo czę­sto jestem pyta­ny o to, jak orga­ni­zo­wać repo­zy­to­rium pro­jek­tu w narzę­dziu CASE. Jak mode­lo­wać sys­te­my i zarzą­dzać tymi mode­la­mi, wie­dząc, że fizycz­na struk­tu­ra może być tyl­ko jed­na? Ten tekst to uzu­peł­nie­nie arty­ku­łu Modelowanie archi­tek­tu­ry HLD i LLD usług apli­ka­cji – mode­lo­wa­nie pod­sys­te­mów.

UWGA! Nie nale­ży mylić pojęć rela­cja” i zwią­zek”. Relacja to sta­ły zwią­zek mie­dzy czymś a czymś”, jest to poję­cie mate­ma­tycz­ne, sto­so­wa­ne tak­że w teo­rii rela­cyj­nych baz danych (rela­cja to trwa­łem połą­cze­nie tabel). Związek (aso­cja­cja) to poję­cie zna­cze­nio­we z obsza­ru logi­ki i rachun­ku zdań. Fundamentem nota­cji UML jest poję­cie kla­sy­fi­ka­tor” (defi­ni­cja ele­men­tów zbio­ru zorien­to­wa­na na cechy ele­men­tów) i kla­sa” (nazwa tego zbio­ru) oraz instan­cja kla­sy (ele­ment, obiekt zbio­ru) (patrz UML 2.5.1. rozdz. 9 Classification ). Tak więc powie­my, że pies korzy­sta z budy (po to by się schro­nić)”, zarów­no pies” jak i buda” to kla­sy (ogól­ne nazwy). Słowo korzy­sta z” to zwią­zek poję­cio­wy (aso­cja­cja) two­rzą­cy popraw­ne i praw­dzi­we zda­nie z tych dwóch pojęć (nazw) czy­li pre­dy­kat. Konkretne obiek­ty to Azor” i buda w zagro­dzie Nowaków”. Ale nie powie­my tu, że jest jakaś rela­cja” psa do budy lub odwrot­nie. Zdanie ist­nie­je rela­cja mię­dzy kom­po­nen­tem Licznik doku­men­tów a kom­po­nen­tem Repozytorium Dokumentów” jest nie­po­praw­ne, mię­dzy inny­mi z tego powo­du, że co do zasa­dy ele­men­ty sys­te­mów są luź­no powią­za­ne” a nie trwa­le połą­czo­ne” (kom­po­nen­ty moż­na kupić osob­no i w dowol­nym momen­cie wymie­nić każ­dy z nich na inny). Tu kolej­na uwa­ga: nie nale­ży sank­cjo­no­wać ogra­ni­czeń posia­da­nych narzę­dzi CASE, jeże­li jakieś narzę­dzie nie pozwa­la two­rzyć popraw­nych mode­li, suge­ru­ję zmie­nić narzę­dzie, nagi­na­nie zasad do ogra­ni­czeń narzę­dzia to śle­pa ulicz­ka, bo taki model sta­je się nie­wa­li­do­wal­ny i nie­moż­li­wy do wymia­ny z inny­mi narzę­dzia­mi (a powinny). 

Więcej o teo­rii sys­te­mów obiek­to­wych, o poję­ciach kla­sy, kla­sy­fi­ka­to­ra i instan­cji kla­sy w tek­ście: Obiektowy model sys­te­mu.

Założenia

Czym jest struk­tu­ra mode­lu sys­te­mu? Tak na praw­dę mamy trzy odręb­ne struktury: 

  1. struk­tu­ra pojęć w mode­lu pojęciowym,
  2. struk­tu­ra dekla­ro­wa­nych typów elementów,
  3. struk­tu­ra sys­te­mu zbu­do­wa­ne­go z kon­kret­nych, nazwa­nych ele­men­tów ww. typów.

(Uwaga! Każdy z powyż­szych dia­gra­mów to dia­gram klas, więc zada­nie: nary­suj dia­gram klas dla pro­jek­tu” nie ma więk­sze­go sensu).

Pierwsza struk­tu­ra to słow­nik pojęć wraz ze związ­ka­mi poję­cio­wy­mi (ten dia­gram klas, w nota­cji SBVR, nosi nazwę dia­gra­mem fak­tów). Kolejna struk­tu­ra to dekla­ra­cja typów kloc­ków”, czy­li typów ele­men­tów sys­te­mu (z nich budu­je­my archi­tek­tu­rę). Trzecia struk­tu­ra to dopie­ro opis kon­struk­cji zbu­do­wa­nej z kloc­ków okre­ślo­ne­go typu (archi­tek­tu­ra sys­te­mu). Widać to np. na przy­sło­wio­wych już meblach z IKEA: mamy spis ele­men­tów oraz rysu­nek zło­że­nio­wy. Na pierw­szym są typy ele­men­tów (tu tak­że ich ilo­ści w pacz­kach), na dru­gim zło­że­nie czy­li kon­struk­cja (archi­tek­tu­ra kon­kret­nej sza­fy). Domyślnym słow­ni­kiem jest ten w jakim napi­sa­no tę instruk­cję, np. język polski. 

Skoro zaś mowa o narzę­dziach CASE, to do zilu­stro­wa­nia oma­wia­nych związ­ków uży­je­my nota­cji UML. Notacja UML nie narzu­ca tu nicze­go, co czę­sto jest wska­zy­wa­ne jako jej wada (nie­wie­le rze­czy moż­na w UML wali­do­wać). Jednak już w pro­fi­lu UML, jakim jest nota­cja SysML (System Modeling Language ), wyżej opi­sa­na dys­cy­pli­na” mode­lo­wa­nia jest narzu­co­na. Omówię też przy­kła­dy dla nota­cji eEPC i BPMN. Warto pamię­tać, że UML i BPMN to nota­cje, któ­re łączy wspól­ny meta­mo­del jakim jest MOF (Meta Object Facility).

Typy związków w UML

Taksonomia związków

W nota­cji UML, uzna­wa­nej obec­nie za stan­dard nota­cyj­ny w obsza­rze mode­lo­wa­nia sys­te­mów, mamy trzy pod­sta­wo­we typy związ­ków: związ­ki poję­cio­we (pre­dy­ka­ty czy­li związ­ki zda­nio­twór­cze), związ­ki struk­tu­ral­ne oraz związ­ki repre­zen­tu­ją­ce zależ­no­ści mię­dzy ele­men­ta­mi mode­lu :

Podstawowe typy związ­ków w nota­cji UML: tak­so­no­mia (opra­co­wa­nie wła­sne, na pod­sta­wie pro­fi­lu UML 2.5.)

Repozytorium pro­jek­tu sys­te­mu (jego struk­tu­ra) odwzo­ro­wu­je wyłącz­nie związ­ki struk­tu­ral­ne. Pozostałe związ­ki moż­na zobra­zo­wać tyl­ko na dia­gra­mach lub w posta­ci macie­rzy zależ­no­ści (przy­po­mi­nam, że od roku 2015, czy­li od wer­sji 2.5. nota­cji UML, nie mamy w UML związ­ku dzie­dzi­cze­nia ani agregacji). 

Dobrą prak­ty­ką jest two­rze­nie zawsze trzech pod­sta­wo­wych mode­li: model poję­cio­wy, dekla­ra­cje typów oraz wła­ści­wy model sys­te­mu, któ­ry zbu­do­wa­ny jest z ele­men­tów okre­ślo­ne­go typu, a któ­rych nazwy są pobie­ra­ne z mode­lu poję­cio­we­go (ze słow­ni­ka). W nota­cji SysML model sys­te­mu (Internal Block Diagram) jest mode­lem pod­le­głym mode­lu dekla­ra­cji typów (Block Definition Diagram) .

Struktura słow­ni­ka w repozytorium

Z uwa­gi na odręb­ność mode­lu poję­cio­we­go (słow­ni­ka) i mode­lu struk­tu­ry sys­te­mu (nadal jest bar­dzo wie­le nie­po­ro­zu­mień z okre­śle­niem tego co to jest model dzie­dzi­ny w UML), słow­nik jako model poję­cio­wy i swo­ista kon­struk­cja, mode­lo­wa­ny z uży­ciem dia­gra­mu klas, opi­sa­no osob­no w spe­cy­fi­ka­cji nota­cji SBVR (Semantics of Business Vocabulary and Business Rules) .

Po lewej stro­nie poka­za­no widok dia­gra­mu (mode­lu) poję­cio­we­go w repo­zy­to­rium narzę­dzia CASE. Jak wspo­mnia­no związ­ki inne niż struk­tu­ral­ne (a zwią­zek gene­ra­li­za­cji nie jest związ­kiem struk­tu­ral­nym a poję­cio­wym) moż­na poka­zać wyłącz­nie na dia­gra­mie lub w macie­rzy zależ­no­ści, dla­te­go struk­tu­ra pojęć w repo­zy­to­rium jest pła­ska, ale dia­gram obra­zu­ją­cy tak­so­no­mię ma struk­tu­rę drze­wa (patrz wyżej). Poniżej związ­ki gene­ra­li­za­cji poka­za­ne w posta­ci macierzy:

Macierz związ­ków gene­ra­li­za­cji mię­dzy poję­cia­mi słow­ni­ka (wyko­na­no z uży­ciem Visual Paradigm)

Jak widać w tym przy­pad­ku for­ma macie­rzy jest trud­niej­sza w per­cep­cji, poka­za­nie drze­wia­stej struk­tu­ry tak­so­no­mii na dia­gra­mie jest efektywniejsze. 

Związki logiczne i zawieranie

Zupełnie inna sytu­acja poja­wia się gdy chce­my poka­zać (zwe­ry­fi­ko­wać ich spój­ność i kom­plet­ność) związ­ki uży­cia («use») czy śla­do­wa­nie («tra­ce»). Są to związ­ki logicz­ne np. pomię­dzy aktyw­no­ścia­mi na mode­lach pro­ce­sów biz­ne­so­wych a przy­pad­ka­mi uży­cia (model przy­pad­ków uży­cia) lub związ­ki pomię­dzy wyma­ga­nia­mi na sys­tem a ele­men­ta­mi sys­te­mu reali­zu­ją­cy­mi te wyma­ga­nia. Mogą to być związ­ki jeden do jed­ne­go, jeden do wie­lu jak i wie­le do wie­lu. Te związ­ki efek­tyw­nie poka­zu­je­my na macier­zach jak wyżej. 

Niektóre narzę­dzia CASE (np. Visual Paradigm) pozwa­la­ją łączyć logicz­nie dowol­ne ele­men­ty struk­tu­ry mode­lu (np. śla­do­wa­nie wyma­gań) związ­ka­mi logicz­ny­mi, bez potrze­by ich odwzo­ro­wy­wa­nia na dia­gra­mach, takie związ­ki są budo­wa­ne jako wła­sność refe­ren­cji do” (jest to cecha ele­men­tu dia­gra­mu, a nie zwią­zek obra­zo­wa­ny na dia­gra­mie), a ich zilu­stro­wa­nie i kon­tro­lę w dowol­nym momen­cie moż­na spraw­dzić gene­ru­jąc macierz ana­lo­gicz­ną do powyższej. 

Na koniec omó­wi­my związ­ki kom­po­zy­cji, złą­cze­nia (con­nec­tion) i zawierania. 

Związki struk­tu­ral­ne (UML v.2.5.1.)
Związek zawie­ra­nia się, widok w repozytorium

Prawdopodobnie część czy­tel­ni­ków jest zasko­czo­na związ­kiem złą­cze­nia”. Otóż linia cią­gła w nota­cji UML ‑aso­cja­cja – na mode­lu poję­cio­wym ozna­cza zwią­zek poję­cio­wy zwa­ny pre­dy­ka­tem. Jednak na mode­lu struk­tu­ry sys­te­mu jest to opis (zwią­zek) kon­struk­cji” (con­nec­tion). Powyższe (dia­gram) czytamy:

  1. Klasa 2 jest czę­ścią skła­do­wą Klasy 1
  2. Klasa 3 i Klasa 4 są ze sobą (trwa­le) połączone
  3. Klasa 5 jest zawar­ta w Pakiecie (dwie rów­no­praw­ne for­my zobra­zo­wa­nia), mini-gra­fi­ka po lewej to widok tego związ­ku w repo­zy­to­rium. Dlatego czę­sto pakiet jest nazy­wa­ny jest kon­te­ne­rem, gdyż sam z sie­bie nie słu­ży do nicze­go poza gru­po­wa­niem (nie ma ani atry­bu­tów ani ope­ra­cji, ma jedy­nie nazwę i ewen­tu­al­nie ste­reo­typ, MOF 2.5.1. rozdz. 8.3 Using Packages to Partition and Extend Metamodels ) oraz UML v.2.5.1. rozdz. 12 Packages .

Np. opi­su­jąc samo­chód powie­my, że sil­nik i koła są czę­ścią samo­cho­du, ale nie powie­my, że koła są czę­ścią sil­ni­ka ani, że sil­nik jest czę­ścią kół, powie­my jed­nak, że są one połą­czo­ne ze sobą”:

Przykład złą­cze­nia dwóch ele­men­tów (UML 2.5.1 rys. 11.5.). W tej posta­ci związ­ki pomię­dzy mię­dzy Car i Wheel oraz Car i Engine, to kom­po­zy­cje (tu Wheel i Engine to atrybuty). 

Jednak powie­my też, że sil­nik krę­ci koła­mi, bo con­nec­tor” też ma okre­ślo­ny kie­ru­nek dzia­ła­nia” (jest to zwią­zek inwariantny). 

I tu bar­dzo waż­na rzecz: nie ma w UML związ­ku dekom­po­zy­cji” ale w repo­zy­to­rium jest to obra­zo­wa­ne tak samo jako zawie­ra­nie się. Przykład: 

Diagram kom­po­nen­tów UML

Powyższy dia­gram to dia­gram kom­po­nen­tów UML obra­zu­ją­cy kom­po­nent i jego inter­fejs ofe­ro­wa­ny (archi­tek­tu­ra HLD). Ten kom­po­nent został w deta­lach opi­sa­ny jako dekom­po­zy­cja (dia­gram klas):

Architektura wewnętrz­na Komponentu (dia­gram klas UML)

Powyższy dia­gram to dia­gram klas obra­zu­ją­cy archi­tek­tu­rę LLD Komponentu. Dokonano tu tak­że pew­ne­go zabie­gu porząd­ku­ją­ce­go: ele­men­ty archi­tek­tu­ry Komponentu umiesz­czo­no w pakie­cie o nazwie Komponent, pakiet ten jest pro­duk­tem prze­kształ­ce­nia Komponentu w pakiet o nazwie Komponent (zwią­zek śla­do­wa­nia okre­śla­ny jako «trans­it to»). Po pierw­sze porząd­ku­je to widok w repo­zy­to­rium, po dru­gie w repo­zy­to­rium sepa­ru­je od sie­bie ele­men­ty róż­nych kom­po­nen­tów (widok repo­zy­to­rium rys. po prawej).

Innymi sło­wy, moż­na powie­dzieć, że dekom­po­zy­cja ozna­cza, że nad­rzęd­ny (w mode­lu) ele­ment dekom­po­no­wa­ny jest na ele­men­ty skła­do­we, a te dla porząd­ku umiesz­cza­my w osob­nym kontenerze.

Komponent jest tu szczy­tem swo­jej hie­rar­chii, dekom­po­zy­cja, czy­li jego wewnętrz­na archi­tek­tu­ra, zosta­ła poka­za­na na dia­gra­mie Komponent Class Diagram”, jest na nim pakiet Komponent (kon­te­ner) oraz zawar­te w nim kla­sy repre­zen­tu­ją­ce wewnętrz­ne ele­men­ty jego archi­tek­tu­ry. Gdyby nie było pakie­tu (kon­te­ne­ra) Komponent, kla­sy będą­ce ele­men­tem jego archi­tek­tu­ry mie­sza­ły­by się” z kla­sa­mi innych kom­po­nen­tów w repo­zy­to­rium, co w dużych pro­jek­tach utrud­nia zarzą­dza­nie mode­lem i korzy­sta­niem z niego. 

Związki w modelach procesów

Związki logicz­ne (prze­pły­wy i aso­cja­cje) opi­sa­łem w Notacja EPCNotacja BPMN. Tym razem sku­pi­my się wyłącz­nie na dekom­po­zy­cji i grupowaniu. 

eEPC

Notacja eECP nie ope­ru­je poję­ciem kon­te­ne­ra co jest jej poważ­ną wadą (nie ma narzę­dzia do gru­po­wa­nia ele­men­tów takich jak pule i tory) moż­na jed­nak użyć dekom­po­zy­cji. Dwa dia­gra­my eEPC:

Dekompozycję pro­ce­sów ozna­czy­my jako całość część (dia­gram pod­rzęd­ny jest czę­ścią całe­go mode­lu procesu). 

W repo­zy­to­rium wyglą­da to tak:

Elementy mode­lu eEPC w repo­zy­to­rium. W repo­zy­to­rium ele­ment Funkcja” jest kon­te­ne­rem dla ele­men­tów dia­gra­mu podrzędnego. 

BPMN

W spe­cy­fi­ka­cji BPMN zaś czytamy:

Definicje puli i torów w spe­cy­fi­ka­cji nota­cji BPMN. 

Tak więc pule i tory to kon­te­ne­ry służ­ce do gru­po­wa­nia aktyw­no­ści (przy­po­mi­nam, że związ­ki logicz­ne i arte­fak­ty nie są partycjonowane). 

Definicja (dia­gram pro­fi­lu UML) poję­cia kon­te­ner w spe­cy­fi­ka­cji BPMN . (Uwaga, w BPMN for­mal­nie kon­te­ne­rem jest tak­że dia­gram czy­li pro­ces, jed­nak w komen­ta­rzach zale­ca się sto­so­wa­nie puli jako miej­sca na umiesz­cze­nie procesu)

Poniżej pro­sty model procesu:

Model pro­ce­su biz­ne­so­we­go (nota­cja BPMN)

W repo­zy­to­rium wyglą­da to tak:

Proces biz­ne­so­wy, widok w repozytorium.

Tu mała cie­ka­wost­ka” i od razu wyja­śnie­nie. Na począt­ku napi­sa­no, że for­mal­nie budu­je­my: struk­tu­rę typów ele­men­tów oraz struk­tu­rę sys­te­mu zbu­do­wa­ne­go z kon­kret­nych ele­men­tów ww. typów. Na powyż­szym dia­gra­mie czyn­ność «Archiwizacja doku­men­tu» poja­wia się dwu­krot­nie: archi­wi­za­cji pod­le­ga i Faktura i Dokument WZ. Jest to więc taka sama pro­ce­du­ra wyko­ny­wa­na w dwóch róż­nych dzia­łach. Oznacza to, że w repo­zy­to­rium raz dekla­ru­je­my czyn­ność «Archiwizacja doku­men­tu» i może­my jej uży­wać wie­lo­krot­nie, na róż­nych dia­gra­mach w róż­nych pulach i torach, gdy tyl­ko praw­dą jest, że poja­wia się w jakimś pro­ce­sie aktyw­ność «Archiwizacja dokumentu». 

UWAGA! W roz­bu­do­wa­nych pro­jek­tach war­to naj­pierw dekla­ro­wać aktyw­no­ści (repre­zen­tu­ją one pro­ce­du­ry) a potem dopie­ro uży­wać ich na dia­gra­mach. Takie dekla­ra­cje (nowe ele­men­ty) moż­na two­rzyć bez­po­śred­nio w repo­zy­to­rium (jako np. biblio­te­kę) lub na spe­cjal­nie zade­kla­ro­wa­nym dia­gra­mie (podob­nie DataObject jako doku­men­ty i ich biblio­te­kę). Poniżej przy­kład takie­go podejścia:

Repozytorium z podzia­łem na Biblioteki i dia­gra­my Procesów
Model pro­ce­su utwo­rzo­ny z ele­men­tów zade­kla­ro­wa­nych w powyż­szej Bibliotece

W VP domyśl­nie, utwo­rze­nie nowe­go ele­men­tu np. two­rząc dia­gram (ale moż­na to zro­bić bez­po­śred­nio w repo­zy­to­rium), sta­no­wi jego dekla­ra­cję w mode­lu (VP ozna­cza to zna­kiem M” jako Master), każ­de kolej­ne uży­cie tego ele­men­tu to jego kolej­ne zobra­zo­wa­nie (VP ozna­cza to zna­kiem a” jako auxi­lia­ry). Identycznie wyglą­da to w każ­dym innym mode­lu (np. UML). Dlatego repo­zy­to­rium mode­lu to wła­śnie dekla­ra­cje typów i ich hie­rar­chia, dia­gra­my to wido­ki i wła­ści­we mode­le, budo­wa­ne z ele­men­tów zade­kla­ro­wa­nych w repo­zy­to­rium ele­men­tów mode­li. Dekompozycja w BPMN będzie wyglą­da­ła ana­lo­gicz­nie jak poka­za­na dla eEPC.

Podsumowanie

Korzystając z narzę­dzi CASE war­to ich uży­wać z peł­nym zro­zu­mie­niem mecha­ni­zmu ich dzia­ła­nia i zro­zu­mie­niem nota­cji jakiej się uży­wa. Każde zanie­dba­nie, nie­umie­jęt­ne lub wręcz nie­wła­ści­we uży­wa­nie związ­ków na dia­gra­mach, pro­wa­dzi do cha­osu i bra­ku czy­tel­no­ści. Konsekwencją są nie­spój­ność i brak moż­li­wo­ści jej kon­tro­li. Niestety nie­któ­re narzę­dzia mają repo­zy­to­ria zbu­do­wa­ne na rela­cyj­nym mode­lu i nie pozwa­la­ją np. umiesz­cze­nie dwóch takich samych ele­men­tów na jed­nym dia­gra­mie. Moja suge­stia: zmień narzędzie.

Warto wie­dzieć, że opi­sa­ne tu związ­ki mają sens i nabie­ra­ją zna­cze­nia dopie­ro w okre­ślo­nym kon­tek­ście (obec­nie dia­gra­my w UML czy BPMN to kon­tek­sto­we wido­ki ele­men­tów hie­rar­chii typów ele­men­tów). Do tego ten sam sym­bol może mieć inne zna­cze­nie w innym kon­tek­ście, np. cią­gła linia pro­sta jest związ­kiem poję­cio­wym na mode­lu poję­cio­wym (pre­dy­kat: pies” śpi w budzie”), albo jest złą­cze­niem (con­nec­tor) na mode­lu struk­tu­ry (koła samo­cho­du są połą­czo­ne z napędem). 

Jeżeli jed­nak mode­lu­je­my archi­tek­tu­rę opro­gra­mo­wa­nia zorien­to­wa­ną obiektowo/komponentowo, gdzie kom­po­nen­ty nie są z sobą trwa­le połą­czo­ne a jedy­nie wywo­łu­ją się wza­jem­nie, to uży­wa­nie złą­cze­nia (cią­gła linia) na tych dia­gra­mach na nie ma żad­ne­go sen­su. Ma jed­nak sens zgru­po­wa­nie okre­ślo­nych ele­men­tów w pakie­cie, dla poka­za­nia gra­ni­cy kom­po­nen­tów czy modu­łów, i ich zawar­to­ści w repozytorium. 

Źródła

Escalona, M.-J., Koch, N., & Garcia-Borgoñon, L. (2022). Lean requ­ire­ments tra­ce­abi­li­ty auto­ma­tion ena­bled by model-dri­ven engi­ne­ering. PeerJ Computer Science, 8, e817. https://​doi​.org/​1​0​.​7​7​1​7​/​p​e​e​r​j​-​c​s​.​817
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
OMG​.org. (2016, October). MetaObject Facility (MOF). https://​www​.omg​.org/​s​p​e​c​/​MOF
OMG​.org. (2017, December 8). Systems Modeling Language (SysML). http://​www​.omg​sy​sml​.org/
OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/

UML version 2.5

Co praw­da for­mal­na publi­ka­cja wer­sji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie uto­nie (spo­koj­ne prze­brnię­cie tych 794 stron wyma­ga cza­su i cier­pli­wo­ści), czy­li wzmian­ka i kil­ka słów z pierw­szych wra­żeń. Specyfikacja do pobra­nia tu:

Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5

Zdaję sobie spra­wę z tego, że poniż­sze nie wszyst­kim z Was wszyst­ko wyja­śni ale ten aku­rat wpis adre­su­ję dla tych z Was, któ­rzy korzy­sta­ją już z UML, nawet w bar­dzo pro­sty sposób.

Wersja 2.5 UML to wer­sja chy­ba prze­ło­mo­wa, bo:

  • zre­zy­gno­wa­no w koń­cu z podzia­łu na dwie czę­ści Infrastructure i Superstructure,
  • upo­rząd­ko­wa­no cały sys­tem poję­cio­wy nota­cji: jest to w koń­cu jed­na w peł­ni spój­na nota­cja (sys­tem kla­sy­fi­ka­to­rów, kie­dyś Infrastructure) oraz zestaw pre­de­fi­nio­wa­nych grup ste­reo­ty­pów z ich dedy­ko­wa­ną seman­ty­ką i syn­tak­ty­ką (kie­dyś Superstructure).
  • dia­gram jako poję­cie, obec­nie sta­no­wi jedy­nie kon­tekst a nie, jak kie­dyś zamknię­tą sub­no­ta­cję” (UML zaczy­nał w latach 90-tych jako zle­pek kil­ku nota­cji trzech autorów).

Obecnie mamy osiem typów dia­gra­mów (kopia z oryginału):

UML dia­grams may have the fol­lo­wing kinds of fra­me names as part of the heading:
? acti­vi­ty
? class
? com­po­nent
? deploy­ment
? inte­rac­tion
? pac­ka­ge
? sta­te machi­ne
? use case
In addi­tion to the long form names for dia­gram heading types, the fol­lo­wing abbre­via­ted forms can also be used:
? act (for acti­vi­ty fra­mes)
? cmp (for com­po­nent fra­mes)
? dep (for deploy­ment fra­mes)
? sd (for inte­rac­tion fra­mes)
? pkg (for pac­ka­ge fra­mes)
? stm (for sta­te machi­ne fra­mes)
? uc (for use case frames)

Jak widać, trzy­li­tro­wych skró­tów ozna­cza­ją­cych dia­gra­my jest o jeden mniej (sie­dem). To wyni­ka z tego, że wszyst­kie dia­gra­my w UML to tak na praw­dę dia­gra­my klas (ten typ dia­gra­mu nie ma swo­je­go dedy­ko­wa­ne­go skró­tu), z tym że sta­no­wią one kon­tek­sto­we pro­fi­le. Struktura poję­cio­wa tych dia­gra­mów (ich [[tak­so­no­mia]]):

UML The taxonomy of structure and behavior diagrams

W sto­sun­ku do UML 2.4 dia­gram pro­fi­lu jest teraz rów­no­praw­nym typem dia­gra­mu (czter­na­sty). Wszystkie poję­cia UML (con­structs) zosta­ły przy­dzie­lo­ne kon­tek­sto­wo to typów diagramów:

The con­structs con­ta­ined in each of the UML dia­grams are descri­bed in the clau­ses indi­ca­ted below.
? Activity Diagram – Activities
? Class Diagram – Structured Classifiers
? Communication Diagram – Interactions
? Component Diagram – Structured Classifiers
? Composite Structure Diagram – Structured Classifiers
? Deployment dia­gram – Deployments
? Interaction Overview Diagram – Interactions
? Object Diagram – Classification
? Package Diagram – Packages
? Profile Diagram – Packages
? State Machine Diagram – State Machines
? Sequence Diagram – Interactions
? Timing Diagram – Interactions
? Use Case Diagram – Use Cases

Należy to rozu­mieć w ten spo­sób: dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py acti­vi­ties” (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla kla­sy­fi­ka­to­rów struk­tu­ral­nych”, itd.

Warto przy­pa­trzeć się swo­im narzę­dziom CASE, gdyż nie­ste­ty nie wszyst­kie mają wbu­do­wa­ny powyż­szy kla­so­wy” para­dyg­mat (w UML wszyst­ko jest kla­są). Wiele z nich nadal hoł­du­je zasa­dzie dia­gra­my jako odręb­ne nota­cje, obec­nie w UML w każ­dym typie dia­gra­mu moż­na użyć każ­de­go ele­men­tu nota­cji, dia­gram jako poję­cie to wyłącz­nie kon­te­ner nio­są­cy głów­ny kon­tekst dane­go mode­lu, bo przy­po­mi­nam, że dia­gram w UML to wyłącz­nie widok cało­ści lub czę­ści mode­lu z okre­ślo­nej per­spek­ty­wy i na okre­ślo­nym pozio­mie abstrakcji.

[uzu­peł­nie­nie 2015-11-21] Z pew­ną satys­fak­cją odkry­łem” (pier­wot­nie, pisząc ten arty­kuł mie­siąc temu, nie zwró­ci­łem na to uwa­gi), że zre­zy­gno­wa­no w koń­cu z poję­cia agre­ga­cji, zwa­nej w czę­ści lite­ra­tu­ry sła­bą kom­po­zy­cją”. Ta kurio­zal­na kon­struk­cja poję­cio­wa kłó­ci­ła się z poję­ciem i aso­cja­cji jako takiej i kom­po­zy­cji jako związ­ku całość część”. Nie ja jeden, jak śle­dzę dys­ku­sje człon­ków OMG na listach LinkedIn, dekla­ro­wa­łem, że nie rozu­miem” czym jest agre­ga­cja (chy­ba pierw­szym, któ­ry to gło­śno mówił był Martin Fowler). Na szczę­ście widać, że defi­ni­cja tego poję­cia nie wytrzy­ma­ła boju z logi­ką. Co praw­da sym­bol aso­cja­cji z pustym rom­bem” jest (tyl­ko) na liście sym­bo­li w dodat­ku B.6 (str. 718) jed­nak widać, że to relikt kom­pa­ty­bil­no­ści wstecz, w tre­ści całej spe­cy­fi­ka­cji to poję­cie nie jest w ogó­le uży­wa­ne. Generalnie mamy zwią­zek kom­po­zy­cji (peł­ny romb), a ele­ment skom­po­no­wa­ny może być rze­czy­wi­sty (part) lub abs­trak­cyj­ny (patrz rozdz. 11.2.3.2 Parts and Roles oraz 11.2.3.3 Connectors). Podobnie z dzie­dzi­cze­niem: nie ma dzie­dzi­cze­nia (korek­ta gru­dzień 2017, UML 2.5.1.).

Polecam całą spe­cy­fi­ka­cję, znacz­nie krót­sza od poprzedniej :).