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
Object Management Group. (2017, December 8). Systems Modeling Language (SysML). http://​www​.omg​sy​sml​.org/
Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Object Management Group. (2014, January). Business Process Model and Notation (BPMN). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Object Management Group. (2016, October). MetaObject Facility (MOF). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​MOF
Object Management Group. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/

Jarosław Żeliński

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.

Ten post ma 2 komentarzy

  1. Po kil­ku pyta­niach, uzu­peł­ni­łem arty­kuł o źró­dło­we infor­ma­cje o pakie­tach, kon­te­ne­ry­za­cji i partycjonowaniu.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.