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/

Business Knowledge Blueprints

Ronald G. Ross 

Ronald G. Ross jest auto­rem lub współ­au­to­rem wie­lu opra­co­wań na temat mode­li poję­cio­wych i zarzą­dza­nia wie­dzą . Jest tak­że współ­za­ło­ży­cie­lem Business Rule Solution LLC, oraz współ­twór­cą spe­cy­fi­ka­cji i nota­cji SBVR .

Książka

Najnowsze z powyż­szych opra­co­wań to rodzaj pod­su­mo­wa­nia pew­nej czę­ści dorob­ku autora.

Modele poję­cio­we są czę­sto mylo­ne z pro­jek­to­wa­niem rela­cyj­ne­go mode­lu danych, a bywa gorzej, gdy są utoż­sa­mia­ne z mode­lem dzie­dzi­ny sys­te­mu” w pro­jek­tach doty­czą­cych two­rze­nia apli­ka­cji okre­śla­nych jako„obiektowe”.

Książka trak­tu­je o mode­lach poję­cio­wych, i autor defi­niu­je je jako: 

model poję­cio­wy: upo­rząd­ko­wa­ny zbiór pojęć i związ­ków mię­dzy nimi

Podstawowym związ­kiem mię­dzy poję­cia­mi (nazwa­mi) jest fakt (pre­dy­kat: zwią­zek zda­nio­twór­czy) łączą­cy poję­cia w popraw­ne i praw­dzi­we zdania. 

Przykład: poję­cia «pies» oraz «listo­nosz» to nazwy słow­ni­ko­we. Połączone fak­tem (pre­dy­ka­tem) two­rzą zda­nie, np.: „ «Pies» szcze­ka na «listo­no­sza» ” (z uwzględ­nie­niem pol­skiej flek­sji, «szcze­ka (na)» to fakt – pre­dy­kat). Jest to zda­nie popraw­ne a tak­że zda­nie praw­dzi­we: jest praw­dą, że pies szcze­ka na listo­no­sza” (to rela­cja), albo: jest moż­li­we, że pies szcze­ka na listo­no­sza” (jest praw­dą to, że to może się to wyda­rzyć). Ważna rzecz: poję­cia to nie sło­wa, to to co opi­su­ją defi­ni­cje tych pojęć (patrz: trój­kąt semio­tycz­nysemio­ty­ka).

Budowanie takich zdań to kon­tro­la (testo­wa­nie) popraw­no­ści mode­lu poję­cio­we­go, test spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści mode­lu poję­cio­we­go. Poprawny model poję­cio­wy (name­spa­ce) to pod­sta­wo­wy waru­nek np. póź­niej­szej spój­no­ści całe­go sys­te­mu zarzą­dza­nia infor­ma­cją (tak­że dany­mi), doku­men­ta­mi (gro­ma­dzą dane), meta­da­ny­mi (opi­su­ją dane). 

Podtytuł książ­ki to: About Vocabulary & Concept Models (O słow­nic­twie i mode­lach poję­cio­wych). Warto wie­dzieć, że zna­ko­mi­ta więk­szość nie­uda­nych pro­jek­tów i wdro­żeń opro­gra­mo­wa­nia to sku­tek błę­dów w mode­lach poję­cio­wych (nazew­nic­two).

Nazewnictwo to nie tyl­ko nazwy doku­men­tów, tabel i pól (ety­kiet danych), to tak­że same dane czy­li nazwy sta­no­wią­ce war­to­ści pól for­mu­la­rzy: nazwy miast, nazwi­ska, nazwy przed­mio­tów, pro­duk­tów, itp. Dawno temu już skoń­czy­ły się cza­sy, gdy kom­pu­te­ry tyl­ko liczy­ły” (to wte­dy powsta­ła idea rela­cyj­ne­go mode­lu danych). Obecnie kom­pu­te­ry prze­twa­rza­ją dane nie będą­ce licz­ba­mi, dane niestrukturalne. 

Zarządzanie wie­dzą to nie są obliczenia.

Autor pisze: akt two­rze­nia danych (zapi­sy­wa­nie infor­ma­cji) to akt komu­ni­ka­cji: to prze­kaz (wia­do­mość) dla przy­szłych czy­tel­ni­ków, odbior­ców tych danych. Dlatego komu­ni­kat (treść), musi (powi­nen) być zro­zu­mia­ły i jed­no­znacz­ny. Jedynym spo­so­bem zagwa­ran­to­wa­nia tego jest popraw­ność uży­te­go zaso­bu pojęć (słow­nic­twa). To wła­śnie jest miej­sce na ana­li­zy i pro­jek­to­wa­nie: naj­pierw mode­li poję­cio­wych a potem mode­li i struk­tur danych. 

Pewną wadą moim zda­niem jest wpro­wa­dze­nie przez auto­ra nowej sym­bo­li­ki dla gene­ra­li­za­cji (budo­wa­nie tak­so­no­mii) w posta­ci pogru­bio­nej linii”. Jednak każ­dy kto zna UML i pozna SBVR, moim zda­niem, bez pro­ble­mu sobie z tym pora­dzi (Visual Paradigm tak wła­śnie zro­bił: gene­ra­li­za­cje na mode­lach fak­tów obra­zo­wa­ne są jako strzał­ki z zamknię­tym gro­tem, zna­ne z UML, podej­ście to opi­su­je Dodatek C do spe­cy­fi­ka­cji SBVR). 

Modele pojęciowe

Modele poję­cio­we są bar­dzo czę­sto mylo­ne z mode­lem pro­ce­sów. Jest to kon­se­kwen­cja sto­so­wa­nia związ­ków skie­ro­wa­nych (aso­cja­cje skie­ro­wa­ne w UML, mode­le poję­cio­we są wyra­ża­ne jako kon­tek­sto­we dia­gra­my klas). Zdanie pies szcze­ka na listo­no­sza” to nie pro­cess (biz­ne­so­wy), to zda­nie spraw­dza­ją­ce popraw­ność uży­tych nazw (pies, listo­nosz) i rozu­mie­nia tych pojęć (komu­ni­kat) oraz praw­dzi­wość zda­nia jako takie­go. Przykład: 

Diagram fak­tów nota­cji SBVR, przy­kład wery­fi­ka­cji pojęć pies i listo­nosz oraz zda­nia pies szcze­ka na listo­no­sza”. (dia­gra­my opra­co­wa­ne z uży­ciem Visual Paradigm).

Powyższy dia­gram zawie­ra dwa poję­cia słow­ni­ko­we: pies, listo­nosz (for­mal­nie powin­ny być tak­że w słow­ni­ku i mieć swo­je jed­no­znacz­ne defi­ni­cje). Górna część dia­gra­mu to gra­ficz­na for­ma, omó­wio­ne­go wyżej, zda­nia pies szcze­ka na listo­no­sza”. Typowe zda­nia to co naj­mniej dwie nazwy połą­czo­ne pre­dy­ka­tem (fak­tem: szcze­ka­nie to fakt). Dolna część dia­gra­mu to zda­nie zbu­do­wa­ne z jed­nej nazwy i pre­dy­ka­tu: Pies szcze­ka”. To tak­że jest popraw­ne zda­nie. Metoda i sys­tem nota­cyj­ny, two­rze­nia mode­li poję­cio­wych (opar­ta na logi­ce pre­dy­ka­tów) zosta­ła opi­sa­na i opu­bli­ko­wa­na jako stan­dard SBVR (patrz tak­że OWL: Web Ontology Language) .

Autor w książ­ce dokład­nie opi­su­je róż­ni­cę mię­dzy mode­lem poję­cio­wym a mode­lem danych: model poję­cio­wy i model danych do róż­ne modele!

Model danych i model poję­cio­wy to nie to samo!

Autor poka­zu­je tak­że zasto­so­wa­nie dia­gra­mów fak­tów do mode­lo­wa­nia ontologii.

Na zakończenie

Słownik jest bar­dzo waż­ny bo sta­no­wi fun­da­ment logi­ki biz­ne­so­wej wyra­żo­nej w posta­ci reguł biz­ne­so­wych (busi­ness rules, patrz arty­kuł z 2015 roku: Reguły biz­ne­so­we, decy­zje i poję­cia). Autor dokład­nie opi­su­je meto­dy two­rze­nia słow­ni­ków i dia­gra­mów fak­tów, w dodat­kach jest omó­wio­ny przy­kład kom­plet­ne­go mode­lu wraz ze słow­ni­kiem. Tu, jako uzu­peł­nie­nie, pole­cam książ­kę prof. Hołówki o logi­ce i two­rze­niu defi­ni­cji pojęć .

Gorąco zachę­cam do lek­tu­ry tej książ­ki, moim zda­niem jest to typo­wa pozy­cja must have” dla każ­de­go ana­li­ty­ka i pro­jek­tan­ta sys­te­mów infor­ma­cyj­nych. Więcej na ten temat napi­sa­łem w 2016 roku w arty­ku­le: Model poję­cio­wy, model danych, model dzie­dzi­ny sys­te­mu.

Literatura

OMG​.org. (2019). Semantics of Business Vocabulary and Business Rules (SBVR). 334. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
OMG​.org. (2014, September). Ontology Definition Metamodel (ODM).
Al-Fedaghi, S. (2020). Conceptual Modeling of Time for Computational Ontologies. 14.
Hołówka, T. (2012). Kultura logicz­na w przy­kła­dach (Wydawnictwo Naukowe PWN, Ed.). Wydawnictwo Naukowe PWN.
Ross, R. G. (2013). Business rule con­cepts: get­ting to the point of know­led­ge (4th Ed). Business Rule Solutions.
Ross, R. G., & Lam, G. S. W. (2011). Building busi­ness solu­tions: busi­ness ana­ly­sis with busi­ness rules. Business Rule Solutions.

Czym nie jest poprawna analiza i modelowanie procesów

Wstęp

Jako ana­li­tyk i pro­jek­tant, w pro­jek­tach któ­re nad­zo­ru­ję to ja jestem auto­rem doku­men­tów, moje pro­ble­my to raczej tłu­ma­cze­nie deve­lo­pe­rom tre­ści tych doku­men­tów (mimo tego, że każ­dy(!) deve­lo­per skła­da­jąc ofer­tę, oświad­cza że zna i posłu­gu­je się nota­cja­mi BPMN ?(?Business Process Model and Notation,? 2014)? i UML ?(?Unified Modeling Language,? 2017)?, prak­ty­ka jed­nak poka­zu­je, że bar­dzo czę­sto kłamią).

Jako wykła­dow­ca aka­de­mic­ki, oso­ba pro­wa­dzą­ca bada­nia nad two­rze­niem i sto­so­wa­niem mode­li, a tak­że jako oso­ba audy­tu­ją­ca cudze doku­men­ty, lub udzie­la­ją­ca po pro­stu kon­sul­ta­cji stu­den­tom innych uczel­ni, mam poważ­ny pro­blem z argu­men­ta­mi a tu (jakaś publi­ka­cja) jest tak napi­sa­ne”. Przywykłem do tego, że tam fak­tycz­nie jest tak napi­sa­ne”. Problem poja­wia się gdy oka­zu­je się, że auto­rem tego co tak jest napi­sa­ne” jest uty­tu­ło­wa­ny pra­cow­nik uczel­ni lub uty­tu­ło­wa­na fir­ma doradcza. 

Ten arty­kuł będzie o niskiej jako­ści nie­któ­rych doku­men­tów. W czym pro­blem z kiep­skiej jako­ści ana­li­za­mi i mode­la­mi? W tym, że ich auto­rzy podej­mu­ją pró­by doda­wa­nia nowych sym­bo­li do nota­cji, psu­jąc spój­ność i jed­no­znacz­ność dia­gra­mów, sto­su­ją sym­bo­le nota­cji nie­zgod­nie z nada­ny­mi im zna­cze­nia­mi, czy­li łamią zasa­dy seman­ty­ki i syn­tak­ty­ki nota­cji, albo łamią zasa­dę wyłą­czo­ne­go środ­ka mówią­cą w uprosz­cze­niu, że jeże­li coś jest czymś to zna­czy, że nie jest już niczym innym (np. jeże­li coś jest zda­rze­niem to na pew­no nie jest ani czyn­no­ścią, ani dany­mi, ani regu­łą decy­zyj­ną).?(Żeliński, 2011)?

W cią­gu dosłow­nie dwóch dni, wpa­dły mi w ręce trzy, dostęp­ne publicz­nie, opracowania:

  • doc.1. Analiza pro­ce­sów biz­ne­so­wych pew­ne­go urzę­du, wyko­na­na przez dużą, zna­ną fir­mą dorad­czą, jest to załącz­nik do SIWZ (publi­ka­cja na BIP tego urzę­du), opra­co­wa­nie z 2012 roku,
  • doc.2. Wynik i opis mapo­wa­nia pro­ce­sów biz­ne­so­wych, któ­re­go celem było przy­go­to­wa­nie do wdro­że­nia zin­te­gro­wa­ne­go sys­te­mu zarzą­dza­nia w pew­nej fir­mie, publi­ka­cja nauko­wa oso­by z tytu­łem dok­to­ra inż. pew­nej zna­nej poli­tech­ni­ki, publi­ka­cja z 2018 r. 
  • doc.3. Wynik i opis mapo­wa­nia pro­ce­sów biz­ne­so­wych, któ­re­go celem było wspar­cie ana­li­zy kon­ku­ren­cyj­no­ści i ryzy­ka, publi­ka­cja nauko­wa oso­by z tytu­łem dok­to­ra inż. pew­nej zna­nej poli­tech­ni­ki, publi­ka­cja z 2016 r.

Nie jest tu moim celem recen­zo­wa­nie tych prac, celem jest wska­za­nie dość powszech­nie popeł­nia­nych błę­dów. Do celów tego arty­ku­łu zano­ni­mi­zo­wa­łem te pra­ce (choć cyta­ty są nie do uniknięcia). 

Doc.1.

Słownik pojęć zawie­ra jedy­nie osiem pozy­cji, w tym: czym jest BPMN, czym jest IT, defi­ni­cję pro­ce­su i pro­ce­su biz­ne­so­we­go, zbli­żo­ną do defi­ni­cji umiesz­czo­nej w Dodatku C spe­cy­fi­ka­cji nota­cji BPMN ?(?Business Process Model and Notation,? 2014)?, zde­fi­nio­wa­no poję­cia Wykonawca i Zamawiający. 

Dokument zawie­ra listę pro­ce­sów uzna­nych za klu­czo­we, pogru­po­wa­ną w obsza­ry tema­tycz­ne, jed­nak nie poda­no ani źró­dła tej listy ani meto­dy jej opra­co­wa­nia ani opi­su meto­dy gru­po­wa­nia i selek­cji. Innymi sło­wy treść ta nie może pod­le­gać żad­nej oce­nie popraw­no­ści, po pro­stu jest dobra” z powo­du, że ją poda­no. Jedyne poda­ne uza­sad­nie­nie kształ­tu tej lisy jest pod­ję­ta decy­zja” (czy­li dowód z auto­ry­te­tu). Dokument ma 55 stron, powstał w 5 tygo­dni, mode­le i opi­sy pro­ce­sów sta­no­wią ok. poło­wę obję­to­ści. W czę­ści Metodyka nie opi­sa­no metod, poda­no wła­sne defi­ni­cje ele­men­tów nota­cji BPMN, nie­zgod­ne nie raz z ory­gi­na­łem: poję­cie pro­ces w BPMN ozna­cza popraw­ny dia­gram BPMN a nie logicz­ny ciąg czyn­no­ści nie­zbęd­nych do prze­kształ­ce­nia sta­nu wej­ścio­we­go w wyj­ścio­wy”, to doda­tek C zawie­ra definicję: 

Business Process: A defi­ned set of busi­ness acti­vi­ties that repre­sent the steps requ­ired to achie­ve a busi­ness objec­ti­ve. It inc­lu­des the flow and use of infor­ma­tion and reso­ur­ces. (ang. Proces biz­ne­so­wy: zde­fi­nio­wa­ny zestaw aktyw­no­ści biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go. Obejmuje prze­pły­wy, wyko­rzy­sta­nie infor­ma­cji i zasobów.)

Warto wie­dzieć, że nota­cja BPMN nie zawie­ra sym­bo­lu defi­nio­wa­ne­go jako pro­ces biz­ne­so­wy”. I dalej: doku­ment zawie­ra definicję: 

Czynność (acti­vi­ty) ? jeden ele­ment dia­gra­mu pro­ce­su, repre­zen­tu­ją­cy
jeden krok w pro­ce­sie; łączy się z inny­mi czyn­no­ścia­mi poprzez połą­cze­nia (con­nec­tion lines) opi­su­ją­ce kie­ru­nek prze­pły­wu transakcji,

Oryginał w BPMN:

An Activity is a gene­ric term for work that com­pa­ny per­forms (see page 151) in a Process. An Activity can be ato­mic or nona­to­mic (com­po­und). The types of Activities that are a part of a Process Model are: Sub-
Process and Task, which are roun­ded rec­tan­gles. (ang. Aktywność jest pod­sta­wo­wym pro­stym ter­mi­nem okre­śla­ją­cym pra­cę jaką w fir­mie się wyko­nu­je (patrz stro­na 151) w ramach pro­ce­su. Aktywność może być ato­mo­wa lub nie­ato­mo­wa (zło­żo­na). Typy aktyw­no­ści wcho­dzą­ce w skład mode­lu pro­ce­su to: Sub-Proces (pod-pro­ces) i zada­nie, któ­re są zobra­zo­wa­ne jako zaokrą­glo­ne prostokąty.

A Task is an ato­mic Activity that is inc­lu­ded within a Process (see page 156). A Task is used when the work in the Process is not bro­ken down to a finer level of Process deta­il. (ang. Zadanie jest ato­mo­wą (ele­men­tar­ną, nie­po­dziel­ną) aktyw­no­ścią zawar­tą w pro­ce­sie (patrz stro­na 156). Zadanie jest uży­wa­ne [w mode­lu] , gdy dana pra­ca w [mode­lo­wa­nym] pro­ce­sie nie jest już dzie­lo­na na kolej­ne pod pozio­my procesu.)

Dla wyja­śnie­nia z dodat­ku C:

Atomic Activity: An acti­vi­ty not bro­ken down to a finer level of Process Model deta­il. It is a leaf in the tree-struc­tu­re hie­rar­chy of Process acti­vi­ties. Graphically it will appe­ar as a Task in BPMN. (ang. Aktywność ato­mo­wa: Aktywność nie­dzie­lo­na na kolej­ne pozio­my szcze­gó­łów mode­lu pro­ce­su. Jest liściem w hie­rar­chii struk­tu­ry aktyw­no­ści dane­go pro­ce­su. Graficznie jest to zada­nie [task] w BPMN).

Warto wie­dzieć, że poję­cie trans­ak­cja (autor tego doku­men­tu uży­wa go zamien­nie z poję­ciem pro­ces) w BPMN jest zastrze­żo­ne (dla mode­li wyko­ny­wal­nych), i oznacza: 

A trans­ac­tion is a Sub-Process that is sup­por­ted by a spe­cial pro­to­col that insu­res that all par­ties invo­lved have com­ple­te agre­ement that the acti­vi­ty sho­uld be com­ple­ted or can­cel­led (see page 178). (ang. Transakcja to pod­pro­ces obsłu­gi­wa­ny przez spe­cjal­ny pro­to­kół [w sys­te­mie BPMS, przyp. mój], któ­ry zapew­nia, że ??wszyst­kie aktyw­no­ści będą zakoń­czo­ne lub nie, i wte­dy ich pośred­nie efek­ty zosta­ną anu­lo­wa­ne (patrz stro­na 178). 

Definicja poję­cia zda­rze­nie w oryginale:

An Event is some­thing that ?hap­pens? during the cour­se of a Process (ang. Wydarzenie to coś [fakt], co ?wyda­rzy­ło się? w trak­cie procesu).

zaś auto­rzy doku­men­tu piszą: Zdarzenie (event) ? stan jaki poja­wia się pod­czas prze­bie­gu pro­ce­su biz­ne­so­we­go. I w takim samym sty­lu przede­fi­jio­wa­no” BPMN w pozo­sta­łej czę­ści opra­co­wa­nia. Stwierdzenie zaś, że Czynnościami w mode­lu pro­ce­su mogą być: Proces, Podproces, Zadanie.” to już czy­sta here­zja (w BPMN nie ma sym­bo­lu o nazwie pro­ces). W dodat­ku C mamy:

Process: A sequ­en­ce or flow of Activities in an orga­ni­za­tion with the objec­ti­ve of car­ry­ing out work. In BPMN, a Process is depic­ted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flow that adhe­re to a fini­te exe­cu­tion seman­tics. (ang. Proces: sekwen­cja lub prze­pływ dzia­łań w orga­ni­za­cji mają­ca na celu dostar­cze­nie efek­tu pra­cy. W BPMN pro­ces jest przed­sta­wia­ny jako dia­gram zło­żo­ny z ele­men­tów prze­pły­wu, któ­re są zesta­wem dzia­łań, zda­rzeń, bra­mek i sekwen­cji prze­pły­wu, któ­re są zgod­ne z [okre­ślo­ną] seman­ty­ką reali­za­cji procesu.)

Innymi sło­wy pro­ces w BPMN to popraw­ny dia­gram (sche­mat blo­ko­wy zgod­ny z seman­ty­ką i syn­tak­ty­ką notacji). 

Diagramy czy­li igno­ro­wa­ne defi­ni­cje. Najpierw jed­nak pew­na uwa­ga, już w 2013 roku pisałem: 

Pro­ce­sy mode­lu­je­my więc po to, by zro­zu­mieć jak dzia­ła orga­ni­za­cja oraz po to, by prze­wi­dzieć jak się ona zacho­wa, jeże­li jakiś pro­ces zmie­ni­my, bo może się nie raz oka­zać, że nie war­to się pew­nych pro­jek­tów podej­mo­wać z uwa­gi na skut­ki. Mode­lo­wa­nie, jak widać, nie jest pro­ce­sem obraz­ko­we­go zapi­su tego co wie­my od pra­cow­ni­ków tej czy innej fir­my, bo to jest ste­no­ty­pia. Mode­lo­wa­nie to trud­ny pro­ces odkry­wa­nia praw­dzi­wej logi­ki dzia­ła­nia orga­ni­za­cji. ?(Żeliński, 2013)?

Co do zasa­dy, zgod­nie z przy­to­czo­ny­mi defi­ni­cja­mi, mamy pew­ne wbu­do­wa­ne ogra­ni­cze­nie na poziom szcze­gó­ło­wo­ści mode­li. Te ogra­ni­cze­nia to defi­ni­cje ato­mo­wej aktyw­no­ści (zada­nie) i pro­ce­su biz­ne­so­we­go (aktyw­ność two­rzą­ca pro­dukt). Innymi sło­wy model pro­ce­su powi­nien się skła­dać z ele­men­tar­nych aktyw­no­ści, z któ­rych każ­da ma wska­za­ny pro­dukt (ocze­ki­wa­ny efekt). W BPMN jedy­nym ele­men­tem mode­lu­ją­cym (słu­żą­cym do zobra­zo­wa­nia) jakich­kol­wiek efek­tów zadań (pro­duk­tów pra­cy) jest Data Object (Obiekt Danych, gene­ral­nie repre­zen­tu­je zestaw danych czy­li doku­ment), któ­ry to – naj­waż­niej­szy – ele­ment, auto­rzy pomi­nę­li przy opi­sie nota­cji. Rozbudowane dia­gra­my w oma­wia­nym doku­men­cie, zawie­ra­ją wie­le róż­nych pro­stych aktyw­no­ści i bar­dzo mało ich efek­tów. Na jed­nym z dia­gra­mów mamy np. Zadanie Powzięcie infor­ma­cji o błęd­nej dekla­ra­cji” nie mają­ce żad­ne­go wej­ścia ani pro­duk­tu! (a jest tam takich sytu­acji wie­le). Takie ele­men­ty na dia­gra­mach, w lite­ra­tu­rze przed­mio­tu (auto­rzy piszą­cy o BPMN), są nazy­wa­ne śmie­cio­we czyn­no­ści na dia­gra­mach”, są to ele­men­ty dia­gra­mu nie wno­szą­ce żad­nej war­to­ści doda­nej w łań­cu­chu pro­ce­su, sta­no­wią­ce oczy­wi­ste stwier­dze­nia (jak np. prze­ka­za­nie doku­men­tu”). Więcej o tym pisa­łem w arty­ku­le Poziomy mode­lo­wa­nia pro­ce­sów ?(Żeliński, 2013)?. Wszystkie mode­le pro­ce­sów w tej doku­men­ta­cji zawie­ra­ją zada­nia w więk­szo­ści nie sko­ja­rzo­ne z żad­nym infor­ma­cja­mi. Jeżeli tytuł opra­co­wa­nia zawie­ra Analiza pro­ce­sów biz­ne­so­wych […] zwią­za­nych z prze­twa­rza­niem infor­ma­cji […]” to nie wiem cze­go się dowie adre­sat tego doku­men­tu o tych­że infor­ma­cjach i ich przetwarzaniu. 

Kwiatkiem na sam koniec, jest zastrze­że­nie praw autor­skich do doku­men­tu (bene­fi­cjent, któ­ry pokrył kosz­ty tej ana­li­zy nie dostał praw mająt­ko­wych do jej efek­tu). Dokument nie zawie­ra imion i nazwisk auto­ra (auto­rów).

Dok.2.

Zacznijmy od popraw­no­ści cyto­wa­nia źró­deł: autor poda­je: Strona domo­wa fir­my XXX, www​.XXX​.com​.pl, dostęp 08.01.2018, rzecz w tym, że to stro­na tytu­ło­wa, dotar­cie do miej­sca skąd pobra­no cyto­wa­ną treść gra­ni­czy z cudem. Po dru­gie autor piszą­cy o nota­cjach, uży­wa­ją­cy defi­ni­cji nota­cyj­nych, któ­ry to autor nie powo­łu­je się na (i nie umiesz­cza w spi­sie lete­ra­tu­ry!) ich ory­gi­nal­nej spe­cy­fi­ka­cji wyka­zu­je poważ­ne bra­ki metodologiczne. 

Dokument zaty­tu­ło­wa­ny jest Mapowanie pro­ce­sów przy­go­to­wa­nia ofer­ty… a jego celem jest opi­sa­nie metod (meto­dy?) mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Z uwa­gi na ano­ni­mi­za­cję nie wkle­ję z ory­gi­na­łu, ale: przy­to­cze­nie jako przy­kła­du dwóch dia­gra­mów UML bez poda­nia ich nazwy (UML to trzy­na­ście nazwa­nych typów dia­gra­mów, ?(?Unified Modeling Language,? 2017)?) jest poważ­nym uchy­bie­niem. Publikacja trak­tu­je o mode­lo­wa­niu pro­ce­sów, a autor jako przy­kła­dy poda­je nota­cję UML, a jako przy­kła­do­we mode­le UML podał aku­rat te, nie­ma­ją­ce z mode­lo­wa­niem pro­ce­sów nic wspól­ne­go (maszy­na sta­no­wa i dia­gram komu­ni­ka­cji), war­to też wie­dzieć, że od 2015 jaw­nie w spe­cy­fi­ka­cji UML zosta­ło napi­sa­ne, że ta nota­cja słu­ży wyłącz­nie do mode­li sys­te­mów ?(?Meta Object Facility,? 2016)?, i nie nale­ży jej uży­wać do mode­li biz­ne­so­wych. Modele biz­ne­so­wa CIM, (Computation Independent Model, ?(?MDA Foundation Model,? 2006)?) od tego są nota­cje BPMN ?(?Business Process Model and Notation,? 2014)? oraz SBVR ?(?Semantics Of Business Vocabulary and Rules,? 2017)?.

W tej pra­cy, na dia­gra­mach mode­li pro­ce­sów, popeł­nio­no wszyst­kie błę­dy opi­sa­ny dla Doc.1., ale poja­wił kolej­ny, wręcz kurio­zal­ny: autor naniósł (roz­cią­gnął) jed­ną aktyw­ność na dwa tory (jed­no zada­nie ma dwo­je odpo­wie­dzial­nych??) co jest nie­do­pusz­czal­ne w BPMN. 

źr. publi­ka­cja nauko­wa, zano­ni­mi­zo­wa­ny autor.

Doc.3.

W tytu­le tej pra­cy mamy: Mapowanie pro­ce­sów biz­ne­so­wych jako tech­ni­ka wspie­ra­ją­ca… „. W roz­dzia­le Metoda badaw­cza, nie ma ani sło­wa o meto­dzie mapo­wa­nia pro­ce­sów (?) a następ­ny roz­dział jest zaty­tu­ło­wa­ny Mapowanie pro­ce­sów biz­ne­so­wych. Rozdział ten zawie­ra sche­ma­ty blo­ko­we pozba­wio­ne legen­dy a więc nie­czy­tel­ne i raczej trud­ne do inter­pre­ta­cji. Jeżeli autor two­rzy wła­sną nota­cją, to tym bar­dzie nale­ży ją zde­fi­nio­wać przed uży­ciem. Schematy blo­ko­we (bez opi­su i legen­dy!) kształ­tem nawią­zu­ją do tak zwa­nej meto­dy swim lanes” mode­lo­wa­nia prze­pły­wu pra­cy, gdzie tory repre­zen­tu­ją oso­by odpo­wie­dzial­ne lub fizycz­nych wyko­naw­ców, cza­sa­mi komór­ki orga­ni­za­cyj­ne. ?(Rummler & Brache, 2000)?. Jednak i tu jed­na aktyw­ność roz­cią­gnię­ta na twa tory co jest łama­niem zasad. 

Poziom mery­to­rycz­ny (sto­so­wa­nie metod a raczej ich brak), brak cyto­wa­nia kano­nu lite­ra­tu­ry na temat pro­ce­sów biz­ne­so­wych i ich mode­lo­wa­nia, zasto­so­wa­nie, bez uza­sad­nie­nia, wła­snej i nie­zde­fi­nio­wa­nej nota­cji, w XXI wie­ku, w zesta­wie­niu z tym, że jest to pro­dukt dok­to­ra inży­nie­ra zna­nej uczel­ni tech­nicz­nej w roku 2015, sta­wia tak­że tego auto­ra w sła­bym świetle. 

Podsumowanie

Jak już wspo­mnia­łem na począt­ku, celem moim było poka­za­nie tego, że pra­ce zali­cza­ne do pro­fe­sjo­nal­nych pro­duk­tów firm dorad­czych, czy też będą­ce tak zwa­ny­mi publi­ka­cja­mi nauko­wy­mi, powin­ny cecho­wać się tym samym wyso­kim pozio­mem mery­to­rycz­nym, a nauko­we tak­że meto­do­lo­gicz­nym. Z przy­kro­ścią muszę tu napi­sać, że recen­zje jak powyż­sza, są moim sta­łym zaję­ciem zarów­no jako bie­głe­go jak i nauczy­cie­la aka­de­mic­kie­go. Bo nie ma dla mnie zna­cze­nia to, czy doku­men­ty, takie jak powy­żej, przy­wo­łu­je mój dyplo­mant czy też robi stro­na skar­żą­ca usłu­go­daw­cę. Znaczenie ma to, że one powsta­ją, a ich auto­rzy otrzy­mu­ją za nie, nie raz sowi­te, wynagrodzenie. 

Często sły­szę od auto­rów: bo klient chciał żeby tak nary­so­wać”. Wiem, klien­ci nie raz tak chcą, ale zada­niem pro­fe­sjo­na­li­sty jest zagwa­ran­to­wać poziom mery­to­rycz­ny swo­ich doku­men­tów i ich jakość, a przede wszyst­kim ich póź­niej­szą przy­dat­ność, a ta w takich sytu­acjach bywa bar­dzo wątpliwa. 

Klient nasz Pan? Często to sły­szę. Otóż nie. Klient zama­wia pro­dukt, jeże­li jest nim opra­co­wa­nie eks­perc­kie, to nie klient a expert, jest jego auto­rem i to eks­pert decy­du­je o tre­ści (pod któ­rą praw­dzi­wy eks­pert pod­pi­su­je się imie­niem i nazwi­skiem!). Taksówkarze też dzie­lą się na dwie gru­py: Ci któ­rzy łamią prze­pi­sy ruchu dro­go­we­go jak klient pro­si (bo się np. spie­szy) i Ci, któ­rzy tego nie robią. Warto pamię­tać, że ewen­tu­al­ne man­da­ty pła­cą kie­row­cy a nie pasażerowie. 

Źródła

  1. Business Process Model and Notation. (2014). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
  2. MDA Foundation Model. (2006). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​c​g​i​-​b​i​n​/​d​o​c​?​o​r​m​s​c​/10 – 09-06
  3. Meta Object Facility. (2016). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​s​p​e​c​/​MOF
  4. Rummler, G. A., & Brache, A. P. (2000). Podnoszenie efek­tyw­no­ści orga­ni­za­cji. Jak zarzą­dzać ?bia­ły­mi pla­ma­mi? w struk­tu­rze orga­ni­za­cyj­nej? Warszawa: Polskie Wydawnictwo Ekonomiczne.
  5. Semantics Of Business Vocabulary and Rules. (2017). Retrieved 2019, from OMG​.org websi­te: https://​www​.omg​.org/​s​p​e​c​/​S​B​V​R​/​A​b​o​u​t​-​S​B​VR/
  6. Unified Modeling Language. (2017). Retrieved 2019, from OMG​.org​.pl websi­te: https://​www​.omg​.org/​s​p​e​c​/​U​M​L​/​A​b​o​u​t​-​U​ML/
  7. Żeliński, J. (2011, November 15). Logika wnio­sko­wa­nia deduk­cyj­ne­go czy­li czym jest popraw­na ana­li­za i mode­lo­wa­nie. Retrieved September 13, 2019, from IT​-Consulting​.pl websi­te: https://it-consulting.pl//2011/11/15/trzy-zasady-nazywane-czasem-najwyzszymi-prawami-myslenia-czyli-czym-jest-poprawna-analiza/
  8. Żeliński, J. (2013). Poziomy mode­lo­wa­nia pro­ce­sów. Retrieved 2019, from IT​-Consulting​.pl websi­te: https://it-consulting.pl//2013/07/04/poziomy-modelowania-procesow/

rfc2119 – Słowa kluczowe reguł

Od cza­su do cza­su spo­ty­kam się z zasko­cze­niem, gdy mówię, że pew­ne sło­wa klu­czo­we w spe­cy­fi­ka­cjach są stan­da­ry­zo­wa­ne”. Otóż spe­cy­fi­ka­cje nota­cji na OMG​.org mają narzu­co­ne pew­ne słow­nic­two. Przykładem niech będzie spe­cy­fi­ka­cja nota­cji BPMN v.2.0.2, zawie­ra ona taki oto roz­dział :

3.2 Normative
OMG UML
? OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 -
(jest już UML 2.5.)
OMG MOF
? Object Management Group – Meta Object Facility (MOF) Core Specification, V2.0
http://​www​.omg​.org/​s​p​e​c​/​M​O​F​/​2.0
RFC-2119
? Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, IETF RFC 2119, March 1997
http://​www​.ietf​.org/​r​f​c​/​r​f​c​2​1​1​9​.​txt

Oznacza to, że do popraw­nej inter­pre­ta­cji spe­cy­fi­ka­cji nota­cji nale­ży znać spe­cy­fi­ka­cje: MOF, UML oraz tak­że RFC-2119. O MOF i UML pisa­łem nie raz, dzi­siaj kil­ka słów o tej ostatniej. 

Jest to doku­ment opi­su­ją­cy reko­men­do­wa­ny spo­sób for­mu­ło­wa­nia wyma­gań (np. w sto­sun­ku do ele­men­tów dia­gra­mu i ich uży­cia). Wymagania są tu rozu­mia­ne sze­ro­ko, jako sfor­mu­ło­wa­nia nor­ma­tyw­ne. Słowa klu­czo­we do wyko­rzy­sta­nia, w RFC do wska­za­nia pozio­mów wyma­gań” to sło­wa i zwro­ty o tu usta­lo­nym zna­cze­niu :

This docu­ment spe­ci­fies an Internet Best Current Practices for the Internet Community, and requ­ests discus­sion and sug­ge­stions for impro­ve­ments. Distribution of this memo is unli­mi­ted.?(?Key words for use in RFCs to Indicate Requirement Levels,? 1997)?

Wymienione sło­wa klu­czo­we odno­szą się do for­mu­ło­wa­nia reguł (przy sto­so­wa­niu okre­ślo­nych zasad będą­cych wyma­ga­nia­mi) i oznaczają:

  1. MUSI (oryg. MUST) ozna­cza, że to zacho­wa­nie (okre­ślo­na regu­ła, wyma­ga­nie) jest abso­lut­nym wymo­giem, alter­na­tyw­nie: WYMAGA SIĘ, NALEŻY 
  2. NIE MOŻE (oryg. MUST NOT) ozna­cza, że okre­ślo­ne zacho­wa­nie jest abso­lut­nie zaka­za­ne, alter­na­tyw­nie: NIE NALEŻY
  3. POWINIEN (oryg. SCHOULD) ozna­cza, że okre­ślo­ne zacho­wa­nie jest reko­men­do­wa­ne, a więc jedy­nie w ści­śle okre­ślo­nych oko­licz­no­ściach, jeże­li ist­nie­ją okre­ślo­ne powo­dy, okre­ślo­ne zacho­wa­nie może być pomi­nię­te, alter­na­tyw­nie: REKOMENDUJE SIĘ,
  4. NIE POWINIEN (oryg. SHOULD NOT) ozna­cza, że pew­ne zacho­wa­nia odra­dza się (reko­men­du­je się nie wyko­ny­wać okre­ślo­ne­go zacho­wa­nia), a więc zacho­wa­nie to jest dopusz­czal­ne jedy­nie w okre­ślo­nych oko­licz­no­ściach, alter­na­tyw­nie: ODRADZA SIĘ, NIE REKOMENDUJE SIĘ, 
  5. MOŻE (oryg. MAY) ozna­cza, że okre­ślo­ne zacho­wa­nie jest opcjo­nal­ne, a więc skut­ki tego reali­za­cji lub pomię­cia okre­ślo­ne­go zacho­wa­nia są cał­ko­wi­cie neu­tral­ne, alter­na­tyw­nie: OPCJONALNIE

Powyższe odno­si się do wszel­kich wyma­gań, do decy­zji o zasto­so­wa­niu cze­goś (np. okre­ślo­nej kon­struk­cji w danej nota­cji). Pod poję­ciem zacho­wa­nia (się)” rozu­mie­my inter­pre­ta­cję zapi­sów np. o sto­so­wa­niu lub wyma­ga­niu cze­goś lub nie. 

Biorąc pod uwa­gę fakt, że defi­ni­cje pojęć to kla­sy­fi­ka­to­ry i sta­no­wią one sobą regu­ły (coś jest lub nie jest czymś) sło­wa te sta­no­wią tak­że bazo­wy ele­ment skład­ni tre­ści reguł biz­ne­so­wych (ele­men­ty pre­dy­ka­tów), np. kie­row­ca NIE MOŻE prze­kra­czać dozwo­lo­nej pręd­ko­ści”, kie­row­ca POWINIEN zacho­wać bez­piecz­ną odle­głość od poprze­dza­ją­ce­go go pojaz­du”, kie­row­ca MOŻE prze­wo­zić pasa­że­rów”, a ogól­nie rzecz bio­rąc kie­row­ca MUSI prze­strze­gać zasad Kodeksu Drogowego”, a ten to nic inne­go jak wła­śnie zbiór reguł.

Źródła

OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Network Working Group. (1997, March). Key words for use in RFCs to Indicate Requirement Levels. Https://​Www​.Ietf​.Org/. https://​www​.ietf​.org/​r​f​c​/​r​f​c​2​1​1​9​.​txt

Od zapytania do realizacji zamówienia czyli jak to się robi z BPMN

Wprowadzenie

Ostatnio poja­wi­ła się w pra­sie i mediach inter­ne­to­wych dys­ku­sja na temat tego czym jest fak­tu­ra, nie­ste­ty bar­dzo wie­le z tych opi­nii jest pozba­wio­na pod­staw mery­to­rycz­nych i praw­nych, są nie­jed­no­krot­nie po pro­stu nie­praw­dzi­we. Biorąc pod uwa­gę fakt, że wie­le tych opi­nii to opi­nie wygła­sza­ne przez przed­się­bior­ców, wyła­nia się smut­ny obraz jako­ści infor­ma­cji zbie­ra­nej meto­dą wywia­dów w toku ana­liz biz­ne­so­wych. Studiowanie lite­ra­tu­ry, cudzych opra­co­wań w roli audy­to­ra, ana­li­za pytań i uwag moich klien­tów to ogrom­ne doświad­cze­nie. Rok temu w arty­ku­le Mit o nota­cji BPMN pisa­łem o szko­dli­wo­ści nad­mia­ru szcze­gó­łów na mode­lach. To wszyst­ko razem skło­ni­ło mnie tym razem do opra­co­wa­nia przy­kła­du dia­gra­mu obra­zu­ją­ce­go pro­ces biz­ne­so­wy wyko­na­ny w nota­cji BPMN1.

Celem tego arty­ku­łu jest poka­za­nie jak opra­co­wać model pro­ce­su biz­ne­so­we­go bazu­jąc wyłącz­nie na pra­wie i tego jak to zro­bić zgod­nie z nota­cją BPMN. Pokazano tak­że, że nota­cja BPMN nie jest narzę­dziem doku­men­to­wa­nia wszyst­kie­go co wie­my o pro­ce­sie”. Istotne jest tak­że to, że nota­cja BPMN to język wyra­zu – narzę­dzie – a nie meto­dy­ka, oraz to że spe­cy­fi­ka­cja BPMN to nie pod­ręcz­nik mode­lo­wa­nia a jedy­nie opis pojęć i ich zna­czeń oraz przy­kła­dy kon­struk­cji (seman­ty­ka i syn­tak­ty­ka nota­cji) co nie zna­czy, że są to wzor­ce pro­jek­to­we. Uważam, że wzor­ców takich nie ma takich w biz­ne­sie, pro­ce­sów refe­ren­cyj­nych” też nie ma. Biznes to pra­wo oraz indy­wi­du­al­ne wewnętrz­ne regulacje.

W ramach wpro­wa­dze­nia opi­sa­no naj­pierw zasa­dy two­rze­nia mode­li ana­li­tycz­nych z uży­ciem nota­cji BPMN.

Notacja BPMN a MDA i UML

Kilka uwag na temat nota­cji BPMN i klu­czo­wych jej cech. Celem stwo­rze­nia tej nota­cji była komunikacja:

The pri­ma­ry goal of BPMN is to pro­vi­de a nota­tion that is readi­ly under­stan­da­ble by all busi­ness users, from the busi­ness ana­ly­sts that cre­ate the ini­tial dra­fts of the pro­ces­ses, to the tech­ni­cal deve­lo­pers respon­si­ble for imple­men­ting the tech­no­lo­gy that will per­form tho­se pro­ces­ses, and final­ly, to the busi­ness people who will mana­ge and moni­tor tho­se pro­ces­ses. Thus, BPMN cre­ates a stan­dar­di­zed brid­ge for the gap betwe­en the busi­ness pro­cess design and pro­cess imple­men­ta­tion.[BPMN c.1.1. 1]

Generalnie rzecz bio­rąc (patrz moje wytłusz­cze­nie): dia­gra­my te powin­ny być zro­zu­mia­łe dla tak zwa­nych ludzi biz­ne­su (bo jeże­li nie są, to są bez­u­ży­tecz­ne), sta­no­wią (sfor­ma­li­zo­wa­ny) szkic dla ludzi odpo­wie­dzial­nych za ich imple­men­ta­cję. Modele pro­ce­sów biz­ne­so­wych sta­no­wią ele­ment mode­li CIM (Computational Independent Model, model nie­za­leż­ny od tech­no­lo­gii IT2).

Poniżej cytu­ję aka­pit opi­su­ją­cy isto­tę podzia­łu mode­li na pozio­my abs­trak­cji (dokład­no­ści).

As an alter­na­ti­ve to full Process Modeling Conformance, the­re are three con­for­man­ce sub-clas­ses defined:

  • Descriptive
  • Analytic
  • Common Executable

Descriptive is con­cer­ned with visi­ble ele­ments and attri­bu­tes used in high-level mode­ling. It sho­uld be com­for­ta­ble for ana­ly­sts who have used BPA flow­char­ting tools.

Analytic con­ta­ins all of Descriptive and in total abo­ut half of the con­structs in the full Process Modeling Conformance Class. It is based on expe­rien­ce gathe­red in BPMN tra­ining and an ana­ly­sis of user-pat­terns in the Department of Defense Architecture Framework and plan­ned stan­dar­di­za­tion for that framework.

Both Descriptive and Analytic focus on visi­ble ele­ments and a mini­mal sub­set of sup­por­ting attributes/elements.

Common Executable focu­ses on what is needed for exe­cu­ta­ble pro­cess models.

Elements and attri­bu­tes not in the­se sub-clas­ses are con­ta­ined in the full Process Modeling Conformance class. The ele­ments for each sub-class are defi­ned in the next sub clau­se. [BPMN c.2.2.1.1]

Istotą mode­lo­wa­nia pro­ce­sów z uży­ciem BPMN jest więc wła­ści­wy dobór pozio­mu szcze­gó­ło­wo­ści. Powyższe ma zna­cze­nie w kon­tek­ście umiesz­cze­nia tych typów mode­li na tle MDA (Model Driven Architecture2) i sko­re­lo­wa­nia z mode­la­mi UML.

Na pozio­mie CIM powsta­ją mode­le opi­su­ją­ce mecha­nizm dzia­ła­nia orga­ni­za­cji w cał­ko­wi­tym ode­rwa­niu od tech­no­lo­gii IT wspie­ra­ją­cych tę orga­ni­za­cję. Notacja BPMN jest tu wspie­ra­na spe­cy­fi­ka­cją SBVR3 (biz­ne­so­wy słow­nik pojęć i regu­ły biz­ne­so­we). Są to wyłącz­nie mode­le poglą­do­we i analityczne.

Kolejny krok to opra­co­wa­nie mode­li wyko­ny­wal­nych czy­li mode­li imple­men­ta­cji pro­ce­sów (wyra­żo­nych w BPMN) z uży­ciem sys­te­mów BPMS (Business Process Management Systems, są to śro­do­wi­ska wyko­naw­cze mode­li BPMN com­mon exe­cu­ta­ble). W prak­ty­ce te mode­le mają wer­sję PIM (wyko­na­ne na bazie stan­dar­du BPMN/BPEL/XPDL) i PSM czy­li dosto­so­wa­ne do śro­do­wi­ska BPMS kon­kret­ne­go pro­du­cen­ta plat­for­my. Jest to ścież­ka bazu­ją­ca cał­ko­wi­cie na nota­cji BPMN i plat­for­mach wyko­naw­czych BPMS.

Proces tra­dy­cyj­ny” inży­nie­rii opro­gra­mo­wa­nia opar­ty na MDA tak­że zaczy­na się powsta­nia mode­lu CIM. Kolejny etap (model) to zawar­cie umo­wy na zakres pro­jek­tu czy­li okre­śle­nie wyma­gań. Do tego słu­ży model przy­pad­ków uży­cia (w UML od wer­sji 2.5 jest jaw­nie okre­śla­ny jako dodat­ko­wy”, patrz Figure 6.1 Semantic Areas of UML4):

Rys. Semantic are­as of UML 2.5.1

Biorąc pod uwa­gę zmia­ny jakie wpro­wa­dzo­no do UML w v.2.5. w zasa­dzie książ­ki i pod­ręcz­ni­ki UML napi­sa­ne przed 2015 rokiem (wej­ście 2.5. UML), moż­na wyrzu­cić do kosza.

Po okre­śle­niu zakre­su pro­duk­tu, powsta­je model PIM sta­no­wią­cy model mecha­ni­zmu dzia­ła­nia opro­gra­mo­wa­nia. Ten model to spe­cy­fi­ka­cja logi­ki dzia­ła­nia (czę­sto sta­no­wi know-how zama­wia­ją­ce­go). Po doko­na­niu wybo­ru dostaw­cy, ten – mając na uwa­dze tech­no­lo­gię któ­rej uży­je, two­rzy model PSM i reali­zu­je imple­men­ta­cję (w prak­ty­ce, pomi­ja się model PSM, naj­czę­ściej powsta­je od razu kod na bazie archi­tek­tu­ry opi­sa­nej w mode­lu PIM).

Zostało to zobra­zo­wa­ne na dia­gra­mie poniżej:

Rys. Struktura mode­li zgod­nie z MDA.

Proces realizacji potrzeb przedsiębiorstwa

Proces reali­za­cji potrzeb przed­się­bior­stwa (orga­ni­za­cji) jest ini­cjo­wa­ny stwier­dze­niem owej potrze­by (wyma­ga­na usłu­ga, przed­miot, inne) a koń­czy się roz­li­cze­niem jej reali­za­cji (dostar­cze­nia). Standardowy pro­ces świad­cze­nia usłu­gi lub dostar­cze­nia pro­duk­tu jest opi­sa­ny w Kodeksie Cywilnym5 (zle­ce­nie lub dzie­ło). Co do zasa­dy więc, na pew­nym okre­ślo­nym pozio­mie szcze­gó­ło­wo­ści, pro­ces ten jest moż­li­wy do opi­sa­nia bez jakich­kol­wiek kon­sul­ta­cji z kim­kol­wiek, treść usta­wy wystarczy.

Opis pro­ce­su: Pojawianie się potrze­by skut­ku­je opra­co­wa­niem zapy­ta­nia ofer­to­we­go (opis przed­mio­tu zamó­wie­nia jakim może być usłu­ga lub pro­dukt). Z regu­ły przy­bie­ra for­mę Zapytania ofer­to­we­go. Zapytanie takie prze­ka­zy­wa­ne jest poten­cjal­ne­mu dostaw­cy, któ­ry opra­co­wu­je ofer­tę na reali­za­cję tego co opi­sa­no w Zapytaniu. Oferta taka jest ana­li­zo­wa­na, jeże­li zosta­nie przy­ję­ta, sta­je się umo­wą pomię­dzy Nabywcą a Dostawcą. Umowa ta sta­no­wi pod­sta­wę Realizacji zamó­wie­nia (jakim jest zaak­cep­to­wa­na ofer­ta). Po zre­ali­zo­wa­niu Zamówienia Dostawca zgła­sza goto­wość prze­ka­za­na przed­mio­tu zamó­wie­nia, nastę­pu­je odbiór. Po odbio­rze jest wysta­wia­na fak­tu­ra na kwo­tę wska­za­ną w Ofercie, w okre­ślo­nym ter­mi­nie ma miej­sce płat­ność. Zamówienie jest zre­ali­zo­wa­ne i rozliczone.

Opisane aktyw­no­ści są uza­leż­nio­ne od okre­ślo­nych ter­mi­nów. Biorąc pod uwa­gę fakt, że udział bio­rą w tym pro­ce­sie dwa pod­mio­ty, a całość jest syn­chro­ni­zo­wa­na ter­mi­na­mi (muszą one być usta­la­ne) pro­ces ten moż­na opi­sać takim modelem:

Rys. Proces reali­za­cji potrze­by w orga­ni­za­cji. Notacja BPMN.

Powyższy dia­gram to model ana­li­tycz­ny. Model poglą­do­wy były­by uprosz­czo­ny do aktyw­no­ści i doku­men­tów, zapew­ne były by to dwa odręb­ne pro­ste mode­le (dla Dostawcy i dla Zamawiającego).

Jak widać uwzględ­nio­no na tym mode­lu (model ana­li­tycz­ny) klu­czo­we fak­ty jaki­mi są ter­mi­ny i momen­ty dorę­cze­nia. Wszelkie deta­le poszcze­gól­nych aktyw­no­ści sta­no­wią naj­czę­ściej spe­cy­fi­kę kon­kret­nych pod­mio­tów i są opi­sa­ne pro­ce­du­ra­mi (np. pro­ce­du­ra­mi ISO z god­nie ze sto­sow­ną nor­mą). Dokumentowanie tych deta­li z uży­ciem kolej­nych, szcze­gó­ło­wych dia­gra­mów w nota­cji BPMN z regu­ły nie ma sen­su, gdyż ich adre­sa­ta­mi (recen­zen­ta­mi) byli by (są) wyko­naw­cy tych prac, a Ci raczej bez pro­ble­mu posłu­gu­ją się pro­ce­du­ra­mi w typo­wej posta­ci zna­nej z norm (testy), a nie dia­gra­ma­mi BPMN. Umieszczanie dodat­ko­wych deta­li wprost na tym dia­gra­mie dopro­wa­dzi do powsta­nia mon­stru­al­ne­go arku­sza, trud­ne­go w użyciu.

Na mode­lach ana­li­tycz­nych posłu­gu­je­my dwo­ma klu­czo­wy­mi poję­cia­mi (BPMN, Annex C Glossary1):

Atomic Activity – An acti­vi­ty not bro­ken down to a finer level of Process Model deta­il. It is a leaf in the tree-struc­tu­re hie­rar­chy of Process acti­vi­ties. Graphically it will appe­ar as a Task in BPMN.

Business Process – A defi­ned set of busi­ness acti­vi­ties that repre­sent the steps requ­ired to achie­ve a busi­ness objec­ti­ve. It inc­lu­des the flow and use of infor­ma­tion and resources.

Atomowym zada­niem, sta­no­wią­cym abs­trak­cję całej aktyw­no­ści biz­ne­so­wej pro­wa­dzą­cej do osią­gnię­cia celu tej pra­cy, jest aktyw­ność two­rzą­ca okre­ślo­ny pro­dukt, mode­lo­wa­ny w BPMN jako DataObject (nota­cja BPMN jest opar­ta na zało­że­niu, że wszel­kie efek­ty pra­cy są doku­men­to­wa­ne). Innymi sło­wy nie umiesz­cza­my na mode­lach pro­ce­sów deta­licz­nych skła­do­wych zadań sta­no­wią­cych ele­men­ty pro­ce­du­ry danej aktyw­no­ści. Procedury mode­lu­je­my na osob­nych dia­gra­mach lub po pro­stu opi­su­je­my tek­stem w odręb­nej doku­men­ta­cji i powo­łu­je­my się na nie.

Co do zasa­dy na mode­lach ana­li­tycz­nych sto­su­je­my pod­sta­wo­wy, mini­mal­ny zestaw sym­bo­li opi­sa­ny w spe­cy­fi­ka­cji, co gwa­ran­tu­je ich czy­tel­ność i zro­zu­mia­łość przez typo­we­go adre­sa­ta jakim jest oso­ba, któ­rej pra­cę opi­sa­no. Korzystanie z roz­sze­rzo­ne­go zesta­wu sym­bo­li (np. sym­bo­le deta­licz­nych zadań z iko­na­mi w lewym gór­nym roku, dodat­ko­we zda­rze­nia itp.) nie ma sen­su na pozio­mie mode­li ana­li­tycz­nych, gdyż sym­bo­le te powsta­ły dla mode­li wyko­ny­wal­nych, prze­cięt­ny adre­sat doku­men­ta­cji ana­li­tycz­nej nie pora­dzi sobie z ich inter­pre­ta­cją. W efek­cie po pro­stu utra­ci­my komu­ni­ka­cję w pro­jek­cie, co jest nie­ste­ty bar­dzo czę­stym zja­wi­skiem i przy­czy­ną więk­szo­ści pro­ble­mów w projektach.

Podsumowanie

Na począt­ko­wym, biz­ne­so­wym, eta­pie pro­jek­tów ana­li­tycz­nych celem doku­men­ta­cji pro­ce­sów biz­ne­so­wych jest opi­sa­nie mecha­ni­zmu dzia­ła­nia orga­ni­za­cji bez zbęd­nych deta­li (te zmie­nia­ją się dość czę­sto). Jeżeli doku­men­ta­cja pro­ce­sów biz­ne­so­wych wyma­ga aktu­ali­za­cji czę­ściej niż raz w roku (a lepiej raz na pięć lat) jest to sygnał, że jest to zła, zbyt szcze­gó­ło­wa dokumentacja.

Literatura nauko­wa jest peł­na opra­co­wań wska­zu­ją­cych, że pro­ce­sy biz­ne­so­we i logi­ka biz­ne­so­wa to odręb­ne obsza­ry opi­su i mode­lo­wa­nia. Notacja BPMN słu­ży do mode­lo­wa­nia pro­ce­sów. Logikę biz­ne­so­wą opi­su­je­my z uży­ciem reguł biz­ne­so­wych3, tablic decy­zyj­nych (patrz arty­kuł SBVR…), tu jeden z wie­lu przy­kła­dów takich komen­ta­rzy:6.

Model pro­ce­sów biz­ne­so­wych jest czę­sto, w lite­ra­tu­rze przed­mio­tu, nazy­wa­ny mode­lem wewnętrz­ne­go łań­cu­cha war­to­ści, a nie raz po pro­stu wewnętrz­ną stra­te­gią reali­za­cji celów ryn­ko­wych. Skoro jest to stra­te­gia, to nie powin­na się ona czę­sto zmie­niać. W powyż­szym mode­lu, uszcze­gó­ło­wie­nia może wyma­gań aktyw­ność reali­za­cji zamó­wie­nia, gdyż w zależ­no­ści od pod­mio­tu, może to być reali­za­cja nie­try­wial­nej usłu­gi lub wytwo­rze­nia pro­duk­tu. Była by to tak zwa­na dekom­po­zy­cja i powsta­nie dru­gi poziom szcze­gó­ło­wo­ści. Pozostałe aktyw­no­ści to two­rze­nie okre­ślo­nych doku­men­tów, a spo­sób ich powsta­wa­nia jest okre­ślo­ny pro­ce­du­rą i tym jakie pola zawie­ra dana for­mat­ka DataObject. Ten poziom szcze­gó­łów opi­su­je­my słow­ni­kiem i regu­ła­mi biz­ne­so­wy­mi (SBVR3).

Biorąc pod uwa­gę fakt, że ser­we­ry BPMS są bar­dzo rzad­ko wyko­rzy­sty­wa­ne, dia­gra­my BPMN na pozio­mie com­mon exe­cu­ta­ble prak­tycz­nie nie są two­rzo­ne. Jeżeli celem two­rze­nia mode­li pro­ce­sów biz­ne­so­wych jest ana­li­za przed­wdro­że­nio­wa, po mode­lu ana­li­tycz­nym powsta­je umo­wa w posta­ci dia­gra­mu Przypadków Użycia. Przypadek uży­cia (patrz arty­kuł Transformacja…) to odpo­wied­nik ato­mo­wej aktyw­no­ści. Innymi sło­wy Przypadki Użycia (UML), jako usłu­gi apli­ka­cyj­ne, wspie­ra­ją okre­ślo­ne aktyw­no­ści (a kon­kret­nie powsta­wa­nie lub prze­twa­rza­nie kon­kret­nych doku­men­tów mode­lo­wa­nych w BPMN jako obiek­ty DataObject), co opi­sa­no na pierw­szym diagramie.

Faktura. Diagram pro­ce­su biz­ne­so­we­go poka­zu­je tak­że, że fak­tu­ra jako doku­ment, nie jest zobo­wią­za­niem. Zobowiązaniem Dostawcy jest zawar­ta umo­wa na dosta­wę a zobo­wią­za­niem Nabywcy jest płat­ność po otrzy­ma­niu przed­mio­tu zamó­wie­nia. Zobowiązanie Nabywcy powsta­je dopie­ro po (z regu­ły pisem­nym) ode­bra­niu przed­mio­tu zamó­wie­nia, fak­tu­ra jest wyłącz­nie tak zwa­nym dowo­dem księ­go­wym, czy­li doku­men­tem stwier­dza­ją­cy jakie kwo­ty zaksięgować.

________________________________
1.
About the Business Process Model And Notation Specification Version 2.0.2. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/. Published January 13, 2014. Accessed February 10, 2019.
2.
MDA Specifications | Object Management Group. https://​www​.omg​.org/​m​d​a​/​s​p​e​c​s​.​htm. Published June 1, 2014. Accessed February 11, 2019.
3.
About the Semantics Of Business Vocabulary and Rules Specification Version 1.4. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/. Published May 1, 2017. Accessed February 11, 2019.
4.
About the Unified Modeling Language Specification Version 2.5.1. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​U​ML/. Published December 1, 2017. Accessed February 11, 2019.
6.
Domain-Specific Conceptual Modeling Concepts, Methods and Tools, Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.), ISBN 978 – 3‑319 – 39417‑6, str. 405.

Co nowego w Visual Paradigm 15.2

26 Listopada zosta­ła opu­bli­ko­wa­na wer­sja 15.2 pakie­tu CASE Visual-Paradigm (VP) ofe­ro­wa­ne­go przez fir­mę o tej samej nazwie. (źr.: What’s New in Visual Paradigm?).

Numer wer­sji zmie­nił się po prze­cin­ku” więc rewo­lu­cji nie ma ale poja­wi­ły się rozszerzenia:

  1. Business Process Reengineering Canvas – sza­blon dla pro­jek­tów rein­ży­nie­rii pro­ce­sów. Szablony pro­jek­to­we w VP to kom­plet­ne zesta­wy pro­ce­sów biz­ne­so­wych, meto­dy­ki, wzo­ry doku­men­tów. Co praw­da uży­wa­ne są rzad­ko ale każ­dy ele­ment sza­blo­nu może być wyko­rzy­sta­ny samo­dziel­nie wedle uzna­nia użyt­kow­ni­ka, dla­te­go te sza­blo­ny speł­nia­ją rolę stan­da­ry­za­cji pra­cy (co poma­ga i to bardzo).
  2. Rozszerzona sza­blo­ny dla meto­dy­ki SCRUM, zwo­len­ni­cy tej meto­dy­ki znaj­dą wie­le pomoc­nych opcji.
  3. Poszerzono sza­blo­ny dla meto­dyk two­rze­nia Architektury Korporacyjnej opar­tych o TOGAF.
  4. Wireflow Diagram – A wire­fra­me-based flow­chart – poja­wi­ły się kolej­ne roz­sze­rze­nia dla funk­cji pro­jek­to­wa­nia i pre­zen­to­wa­nia makiet ekra­nów i ani­mo­wa­nych scenariuszy.
  5. UX Prototyping tool – nowe narzę­dzie do pro­to­ty­po­wa­nia sza­ty gra­ficz­nej i inte­rak­cji apli­ka­cji webowych.
  6. Bi-Directional ERD syn­chro­ni­za­tion – roz­sze­rzo­no wspar­cie dla pro­jek­tan­tów rela­cyj­nych baz danych.
  7. Enhanced SysML 1.5 sup­port – posze­rzo­ne i zak­tu­ali­zo­wa­ne wspar­cie dla SysML.
  8. Poszerzone wspar­cie dla pro­jek­to­wa­nia API i zesta­wów webserwisów.
  9. Process Map Designer – posze­rzo­ne wspar­cie dla pro­jek­to­wa­nia map pro­ce­sów wyso­kie­go poziomu.
  10. Wiele nowych sza­blo­nów dia­gra­mów biz­ne­so­wych i info­gra­fi­ki biznesowej.

Tak więc opro­gra­mo­wa­nie Visual-Paradigm sta­je się peł­nym zesta­wem narzę­dzi dla pro­jek­tów archi­tek­tu­ry biz­ne­so­wej, pro­jek­to­wa­nia sys­te­mów, w szcze­gól­no­ści infor­ma­tycz­nych. Ogromny nacisk fir­my Visual-Paradigm na jakość for­ma­li­za­cji i jej zgod­ność ze spe­cy­fi­ka­cja­mi OMG czy­ni z tego narzę­dzia dosko­na­łe wspar­cie dla prac nauko­wych bazu­ją­cych na for­ma­li­za­cjach ikonicznych.

Polecam testy pakietu 🙂 …