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/

Dylematy z aktorami

Wprowadzenie

Pojęcie kon­tek­stu pro­jek­tu i dia­gram przy­pad­ków uży­cia jako narzę­dzie, nadal rodzi wie­le pytań. Spowodowane jest to tym, że dia­gram przy­pad­ków uży­cia to naj­czę­ściej wyko­rzy­sty­wa­ny dia­gram, naj­czę­ściej też nie­le­gal­nie prze­cią­ża­ny” infor­ma­cja­mi o archi­tek­tu­rze wewnętrz­nej (związ­ki «inc­lu­de» i «extend»). Jest to tak­że naj­bar­dziej abs­trak­cyj­ny dia­gram w nota­cji UML. Postanowiłem odpo­wiedź publicz­nie” na pyta­nie, któ­re w róż­nych for­mach, czę­sto pada w pro­jek­tach, na szko­le­niach i w mailach do mnie kie­ro­wa­nych. Przykład jed­ne­go z nich:

Mam pyta­nie, któ­re drę­czy mnie od jakie­goś cza­su i teraz zmo­bi­li­zo­wa­łam się by je zadać. 

W arty­ku­le Jarosław Żeliński (9 paź­dzier­ni­ka 2012) pisze Pan: Inny System, jeże­li ini­cju­je akcję czy­li żąda usłu­gi tak­że jest akto­rem, ale System reali­zu­ją­cy na nasze zle­ce­nie jakieś usłu­gi nie jest akto­rem, jest tyl­ko wywo­ły­wa­ny, sam z sie­bie nie ini­cju­je żad­nej akcji. On reali­zu­je jakąś potrzeb­ną nam funkcję.” 

Natomiast w innych miejscach,np. w doku­men­ta­cji Generatora ofert dla Kancelarii Senatu (Jarosław Żeliński, 22 paź­dzier­ni­ka 2019) , czy w Swojej książ­ce ( ( s.31) obra­zu­je Pan zewnętrz­ny sys­tem ofe­ru­ją­cy usłu­gę sym­bo­lem Aktora. Być może to zale­ży od kon­tek­stu, ja jed­nak nie dostrze­gam jakie­goś niu­an­su, czy może Pan wyja­śnić ten dyle­mat? I dru­gie pytanie. 

W książ­ce ( s.54, pierw­szy aka­pit pod Rys.8.5) natknę­łam się na zda­nie : Powyższy model to struk­tu­ry danych dla pojęć opi­su­ją­cych spo­tka­nia”. Można go spo­rzą­dzić tak­że w nota­cji obiek­to­wej (UML), czy­li dia­gra­mem klas, jed­nak tu dla uprosz­cze­nia pomi­nię­to tę wer­sję i poka­za­no model danych (model obiek­to­wy ma inne zasa­dy two­rze­nia i będzie opi­sa­ny w dal­szej czę­ści książ­ki)”. O jaki model w nota­cji obiek­to­wej (UML) cho­dzi? model dzie­dzi­ny? (w dal­sze czę­ści książ­ki jest on opisany)

Byłabym wdzięcz­na za odpowiedź

na to pyta­nie (w zasa­dzie pyta­nia) odpo­wiem z pomo­cą przy­kła­du wraz z objaśnieniami. 

Specyfikacja UML

Na począ­tek kil­ka klu­czo­wych pojęć z UML. Rozdział 18 Use Case w pierw­szym aka­pi­cie infor­mu­je nas, że:

UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors.

To zna­czy, że: 1. Przypadki Użycia to spo­sób na uchwy­ce­nie [a nie peł­ne opi­sa­nie! przyp. auto­ra] wyma­gań wobec sys­te­mu, tj. tego Co sys­tem ma zro­bić. 2. Kluczowymi poję­cia­mi są tu: Aktor, Przypadek Użycia i Przedmiot [sys­tem jako przed­miot opi­su, przyp. auto­ra]. 3. Przedmiot repre­zen­tu­je ana­li­zo­wa­ny sys­tem, któ­re­go wyko­rzy­sta­nie [jego cel] repre­zen­tu­je Przypadek Użycia. 4. Użytkownicy i wszel­kie inne sys­te­my, któ­re mogą wcho­dzić w inte­rak­cje z Przedmiotem [opi­su], są repre­zen­to­wa­ni [na dia­gra­mach przy­pad­ków uży­cia] jako Aktorzy. Bardzo waż­nym sło­wem są tu inte­rak­cje. Akapit 18.1.3.1. tej specyfikacji: 

A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the subject.

Czyli: Przypadek Użycia może doty­czyć (być powią­za­ny z) dowol­nej licz­by Przedmiotów opi­su (kon­tek­stów). Jeżeli Przypadek Użycia jest sko­ja­rzo­ny z okre­ślo­nym Przedmiotem, ozna­cza to, że okre­śla jego zestaw zacho­wań, co z kolei daje (opi­su­je) obser­wo­wal­ny wynik (efekt, pro­dukt), któ­ry ma war­tość dla okre­ślo­nych akto­rów lub innych inte­re­sa­riu­szy. Warto tu zwró­cić uwa­gę na dwie rze­czy: Przypadek Użycia to abs­trak­cja repre­zen­tu­ją usłu­gę rozu­mia­ną jako okre­ślo­ny efekt, tak więc Fakturowane może być cechą wie­lu apli­ka­cji w tym samym pro­jek­cie (np. i w CRM i W FK). Po dru­gie inte­re­sa­riu­szem apli­ka­cji może być, poza bez­po­śred­nim użyt­kow­ni­kiem, każ­da oso­ba lub byt zależ­ny nawet pośred­nio, od dane­go Przedmiotu. 

Wyjaśnienie na przykładzie

Poniżej opis pro­ste­go zin­te­gro­wa­ne­go sys­te­mu skła­da­ją­ce­go się z trzech kom­po­nen­tów oraz przy­kła­dy trzech róż­nych kon­tek­stów hipo­te­tycz­ne­go projektu. 

Model złożonego systemu

Na dia­gra­mie poni­żej (UML, dia­gram kom­po­nen­tów) zobra­zo­wa­no archi­tek­tu­rę zło­żo­ną z trzech sys­te­mów: Użytkownik uży­wa Systemu A, System A korzy­sta z usług (jest zale­ży od) Systemu B, System B korzy­sta z usług Systemu C. System C jest tu sys­te­mem niezależnym. 

Model archi­tek­tu­ry inte­gra­cji (źr. autor)

Powyższy zło­żo­ny sys­tem może być przed­mio­tem kil­ku róż­nych pro­jek­tów o róż­nych zakresach. 

Trzy konteksty

Poniżej przy­kła­do­we zakre­sy pro­jek­tów wyra­żo­ne z pomo­cą dia­gra­mów przy­pad­ków użycia. 

Zakres pro­jek­tu obej­mu­je tyl­ko System A, sys­tem B świad­czy mu usługi.
Zakres pro­jek­tu obej­mu­je tyl­ko System B, któ­ry świad­czy usłu­gi dla Systemu A i jest zależ­ny od Systemu C. 
Zakres pro­jek­tu obej­mu­je tyl­ko System C, któ­ry świad­czy usłu­gi sys­te­mo­wi B

(ste­reo­ty­py «human» i «appli­ca­tion» to czę­sto przyj­mo­wa­na kon­wen­cja, nie są one czę­ścią spe­cy­fi­ka­cji UML). 

Powyższe trzy dia­gra­my obra­zu­ją zakre­sy trzech odręb­nych pro­jek­tów. Są to trzy róż­ne kon­tek­sty ana­li­zy i pro­jek­to­wa­nia dla tego same­go zło­żo­ne­go sys­te­mu jako cało­ści. Aktor co do zasa­dy (nota­cja UML) jest bytem zewnętrz­nym w sto­sun­ku do sys­te­mu będą­ce­go przed­mio­tem opi­su (kon­tek­stem pro­jek­tu doku­men­to­wa­nia wyma­gań). Przypadki uży­cia to wyłącz­nie abs­trak­cje usług (w obiek­to­wym para­dyg­ma­cie z zasa­dy na mode­lu przy­pad­ków uży­cia nie uży­wa­my związ­ków «extend» i «inc­lu­de», uza­sad­nia­łem to w arty­ku­le Jarosław Żeliński (6 stycz­nia 2019)). Na dia­gra­mie przy­pad­ków uży­cia, zwią­zek mię­dzy akto­rem (któ­ry może być czło­wie­kiem «human», lub innym sys­te­mem «appli­ca­tion») a usłu­gą, któ­rą dla nie­go świad­czy sys­tem będą­cy przed­mio­tem opi­su, jest aso­cja­cja (linia cią­gła). Jeżeli chce­my poka­zać, że nasz System musi korzy­stać z usług inne­go zewnętrz­ne­go sys­te­mu (jest od nie­go zależ­ny), to łączy­my opi­sy­wa­ny System i ten zewnętrz­ny (akto­ra) związ­kiem uży­cia (zależ­ność: nasz sys­tem jest uza­leż­nio­ny od zewnętrz­ne­go) wska­zu­ją­cym na źró­dło uzależnienia. 

UWAGA! Integracja z sys­te­mem zewnętrz­nym, któ­ry świad­czy usłu­gi, nie jest Przypadkiem Użycia sys­te­mu modelowanego!

Podsumowanie

Powyższe przy­kła­dy obra­zu­ją waż­ne poję­cie jakim jest kon­tekst pro­jek­tu. Nie raz dia­gra­my takie są nazy­wa­ne (i słusz­nie) mode­lem zakre­su pro­jek­tu. Moga one być kon­ty­nu­owa­ne w trak­cie reali­za­cji pro­jek­tu (nad­zór autorski).

Można więc zobra­zo­wać tak­że to, że nasz sys­tem (jego abs­trak­cja) będzie miał (lub już ma) zna­ną nam imple­men­ta­cję. Wtedy korzy­sta­my ze związ­ku reali­za­cji jak na przy­kła­dzie poniżej. 

Model oto­cze­nia Systemu CRM zawie­ra­ją­cy infor­ma­cję o implementacji

Na dia­gra­mie poka­za­no, że Systemem CRM któ­ry wdro­ży­my, będzie apli­ka­cja wFirma​.pl co poka­za­no związ­kiem reali­za­cji (apli­ka­cja wFirma​.pl – kom­po­nent UML – reali­zu­je wyma­ga­nia na System CRM). 

Powyższy dia­gram czy­ta­my: Użytkownik (czło­wiek) korzy­sta z Systemu CRM w celu wysta­wia­nia Faktur i reje­stro­wa­nia Zamówień (deta­le usług doku­men­tu­je­my osob­no jako warun­ki począt­ko­we i koń­co­we, sce­na­riu­sze przy­pad­ków uży­cia i struk­tu­ry doku­men­tów Faktura i Zamówienia, np. z pomo­cą dia­gra­mu struk­tur zło­żo­nych UML, co opi­sa­łem w Jarosław Żeliński (2 grud­nia 2019)). Nasz sys­tem CRM korzy­sta z API ofe­ro­wa­ne­go przez Główny Urząd Statystyczny (GUS) do pobie­ra­nia danych firm na pod­sta­wie ich nume­ru NIP (to nie jest przy­pa­dek uży­cia nasze­go Systemu CRM, szcze­gó­ły tej inte­gra­cji zawie­ra sce­na­riusz przy­pad­ku uży­cia Zamówienia lub Faktury oraz opis akto­ra GUS). Wygląda to tak:

Dlaczego na dia­gra­mie apli­ka­cja wFirma​.pl to kom­po­nent a nie aktor UML? Aktor to abs­trak­cyj­ny byt poza sys­te­mem, mają­cy z nim inte­rak­cję, więc poka­za­nie na dia­gra­mie przy­pad­ków uży­cia imple­men­ta­cji sys­te­mu (sym­bol) nie może być akto­rem, bo zwią­zek abs­trak­cji i jej reali­za­cji nie jest inte­rak­cją (reali­za­cja i uży­cie to są zależ­no­ści ale róż­ne). [auto­ko­rek­ta 2020-03-18, 20:40].

Konstrukcje uży­te w pro­jek­cie Generator Ofert opi­sa­łem i sko­men­to­wa­łem w Jarosław Żeliński (22 paź­dzier­ni­ka 2019).

O tym, że Czas nie jest akto­rem sys­te­mu pisa­łem tu: Jarosław Żeliński (27 listo­pa­da 2011).

Źródła

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Żeliński, J. (2017). Analiza biz­ne­so­wa: prak­tycz­ne mode­lo­wa­nie orga­ni­za­cji (Grupa Wydawnicza Helion, Ed.). Wydawnictwo Helion.

Paradygmat obiektowy i Przypadki Użycia

Przypadki uży­cia w nota­cji UML1 to jed­na z naj­star­szych metod doku­men­to­wa­nia wyma­gań i nadal budzi wie­le kon­tro­wer­sji w kwe­stii ich popraw­ne­go użycia.

Obiektowy paradygmat i pojęcie systemu

Słownik j.polskiego mówi:

para­dyg­mat ?przy­ję­ty spo­sób widze­nia rze­czy­wi­sto­ści w danej dzie­dzi­nie, dok­try­nie itp.?

obiekt ?rzecz abs­trak­cyj­na, np. cecha lub poję­cie?, ?przed­miot, któ­ry moż­na zoba­czyć lub dotknąć?

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?, ?zespół wie­lu urzą­dzeń, dróg, prze­wo­dów itp., funk­cjo­nu­ją­cych jako całość?

Ludwig von Bertalanffy w swo­jej Ogólnej Teorii Systemów?2? określa 

sys­tem: sta­no­wią­cy okre­ślo­ną całość byt, zło­żo­ny z mają­cych inte­rak­cje elementów. 

Pojęciami powią­za­ny­mi są tu pod­sys­tem i super sys­tem. Są to poję­cia względ­ne, ich zna­cze­nie odno­si się do sys­te­mu ana­li­zo­wa­ne­go. Innymi sło­wy: dany sys­tem skła­da się z pod­sys­te­mów oraz jest czę­ścią sys­te­mu nad­rzęd­ne­go czy­li super sys­te­mu. Paradygmat obiek­to­wy, w swej isto­cie, nawią­zu­je do teo­rii sys­te­mów: sys­tem (ana­li­zo­wa­ny lub pro­jek­to­wa­ny) skła­da się z współ­pra­cu­ją­cych obiektów.

Cechą pod­sta­wo­wą obiek­to­we­go para­dyg­ma­tu jest her­me­ty­za­cja, któ­ra ozna­cza, że obiekt nie udo­stęp­nia swo­je­mu oto­cze­niu (nie udo­stęp­nia) swo­jej struk­tu­ry (budo­wy), ma z oto­cze­niem wyłącz­nie okre­ślo­ne inte­rak­cje, zwa­ne ope­ra­cja­mi. Innymi sło­wy obiekt reagu­je w okre­ślo­ny spo­sób na okre­ślo­ne bodź­ce igno­ru­jąc wszel­kie pozo­sta­łe, a zbiór tych ope­ra­cji nazy­wa­my inter­fej­sem obiek­tu. Jedynym spo­so­bem pozy­ska­nie infor­ma­cji o obiek­cie jest zapy­ta­nie go o to”. Cechą ele­men­tów sys­te­mu, czy­li obiek­tów, jest to, że poszcze­gól­ne z nich są mię­dzy sobą bar­dzo luź­no powią­za­ne ale wewnątrz sie­bie są one bar­dzo spój­ne. Jedno z wie­lu opra­co­wań na ten temat mówi:

Cohesion and Coupling deal with the quali­ty of an OO design. Generally, good OO design sho­uld be loose­ly coupled and high­ly cohe­si­ve. Lot of the design prin­ci­ples, design pat­terns which have been cre­ated are based on the idea of ?Loose coupling and high cohe­sion?.3

Konsekwencją her­me­ty­za­cji jest poli­mor­fizm. Znamy jedy­nie nazwę bodź­ca, meto­da powsta­nia reak­cji obiek­tu ma bodziec jest ukry­ta, co zna­czy, że nazwa bodź­ca okre­śla sku­tek z nie to jak powstał. 

Podsumowując, obiek­to­wy para­dyg­mat mówi nam, że przed­miot ana­li­zy lub pro­jek­to­wa­nia, przed­sta­wia­my jako sys­tem, czy­li okre­ślo­ną struk­tu­rę skła­da­ją­cą się z okre­ślo­nych ele­men­tów, ele­men­ty te współ­pra­cu­ją (mają inte­rak­cje) w okre­ślo­ny spo­sób.

Paradygmat obiek­to­wy: Jedynym związ­kiem mię­dzy obiek­ta­mi sys­te­mu jest wza­jem­na współ­pra­ca czy­li inte­rak­cja. Hermetyzacja ozna­cza, że obiek­ty ukry­wa­ją swo­ją budo­wę i nie współ­dzie­lą nicze­go. Polimorfizm ozna­cza, że istot­na jest nazwa pole­ce­nia, a nie meto­da jego wyko­na­nia, bo te mogą być różne. 

Co piszą w sieci i książkach

W sie­ci i w lite­ra­tu­rze moż­na spo­tkać róż­ne wyja­śnie­nia i opi­sy tego co popu­lar­nie nazy­wa się (moim zda­niem nie­słusz­nie) podej­ściem obiek­to­wym”. W zależ­no­ści od tego czy celem jest opi­sa­nie bada­ne­go przed­mio­tu czy jego zapro­jek­to­wa­nie, mówi­my o ana­li­zie zorien­to­wa­nej obiek­to­wo lub pro­jek­to­wa­niu zorien­to­wa­nym obiektowo.

W sie­ci spo­tka­my bar­dzo czę­sto opi­sy takie jak ten:

Object-Oriented Analysis
A method of ana­ly­sis which descri­bes the pro­blem doma­in in terms of clas­ses and objects.
OOA feeds OOD which then can be imple­men­ted with OOP.?4?

Jest to dość powszech­nie spo­ty­ka­na i nie­praw­dzi­wa teza, mówią­ca że ana­li­za obiek­to­wa (obiek­to­we meto­dy ana­li­zy) pole­ga na opi­sa­niu pro­ble­mu z uży­ciem klas i obiek­tów. Nie jest tak­że praw­dą, że z zasa­dy” atry­bu­ty to dane (rozu­mia­ne tak jak pola w bazach danych, UML – dia­gram klas – abso­lut­nie nie słu­ży do mode­lo­wa­nia danych!). Analiza obiek­to­wa może pro­wa­dzić do obiek­to­we­go pro­jek­to­wa­nia a potem do obiek­to­wej implementacji.

Większość tek­stów na temat metod obiek­to­wych wycho­dzi z rąk pro­gra­mi­stów. Ci opi­su­ją ją z per­spek­ty­wy imple­men­ta­cji z uży­ciem tak zwa­nych obiek­to­wo zorien­to­wa­nych języ­ków pro­gra­mo­wa­nia. Tak zwa­na obiek­to­wa orien­ta­cja języ­ka pro­gra­mo­wa­na spro­wa­dza się do tego, że ele­men­ty pro­gra­mu są orga­ni­zo­wa­ne w kla­sy, a te zawie­ra­ją atry­bu­ty i ope­ra­cje. Atrybuty to ele­men­ty zapa­mię­ty­wa­ne a ope­ra­cje to wywo­ły­wa­ne funk­cje (meto­dy, pro­ce­du­ry). Innymi sło­wy jest to kolej­na struk­tu­ral­na meto­da pisa­nia oprogramowania.

To czy pro­jekt jest fak­tycz­nie obiek­to­wy” zale­ży od jego archi­tek­tu­ry a nie od fak­tu, że uży­to obiek­to­wo zorien­to­wa­ne­go języ­ka pro­gra­mo­wa­nia (nawet w assem­ble­rze moż­na pro­gra­mo­wać obiektowo).

Inny przy­kład:

Programowanie obiek­to­we (ang. object-orien­ted pro­gram­ming, OOP) ? para­dyg­mat pro­gra­mo­wa­nia, w któ­rym pro­gra­my defi­niu­je się za pomo­cą obiek­tów ? ele­men­tów łączą­cych stan (czy­li dane, nazy­wa­ne naj­czę­ściej pola­mi) i zacho­wa­nie (czy­li pro­ce­du­ry, tu: meto­dy). Obiektowy pro­gram kom­pu­te­ro­wy wyra­żo­ny jest jako zbiór takich obiek­tów, komu­ni­ku­ją­cych się pomię­dzy sobą w celu wyko­ny­wa­nia zadań.

Podejście to róż­ni się od tra­dy­cyj­ne­go pro­gra­mo­wa­nia pro­ce­du­ral­ne­go, gdzie dane i pro­ce­du­ry nie są ze sobą bez­po­śred­nio zwią­za­ne. Programowanie obiek­to­we ma uła­twić pisa­nie, kon­ser­wa­cję i wie­lo­krot­ne uży­cie pro­gra­mów lub ich fragmentów.

Największym atu­tem pro­gra­mo­wa­nia, pro­jek­to­wa­nia oraz ana­li­zy obiek­to­wej jest zgod­ność takie­go podej­ścia z rze­czy­wi­sto­ścią ? mózg ludz­ki jest w natu­ral­ny spo­sób naj­le­piej przy­sto­so­wa­ny do takie­go podej­ścia przy prze­twa­rza­niu infor­ma­cji.5

Ad. pierw­szy aka­pit. Przede wszyst­kim pisa­ny przez pro­gra­mi­stę pro­gram zawie­ra dekla­ra­cje klas, te zawie­ra­ją atry­bu­ty i ope­ra­cje. Na pod­sta­wie tych klas (dekla­ra­cji) powsta­ną w pamię­ci kom­pu­te­ra obiek­ty, ale dopie­ro wte­dy gdy pro­gram ten będzie się wyko­ny­wał w pamię­ci komputera.

Ad. dru­gi aka­pit. Praktycznie podział pro­gra­mu na dekla­ra­cje klas to inna for­ma struk­tu­ry­za­cji kodu pro­gra­mu. Pisanie, kon­ser­wa­cja i wie­lo­krot­ne uży­cie nie jest pro­stą kon­se­kwen­cją fak­tu uży­cia obiek­to­we­go języ­ka pro­gra­mo­wa­nia. Podział pro­gra­mu na kla­sy, i to jak ten podział zosta­nie prze­pro­wa­dzo­ny, to wyłącz­nie inwen­cja archi­tek­ta lub pro­gra­mi­sty, nie ma takie­go obo­wiąz­ku (prze­czy­taj o Boskim obiek­cie).

Ad. trze­ci aka­pit. Najpierw przy­po­mnij­my, że pra­ce nad opro­gra­mo­wa­niem prze­bie­ga­ją w nastę­pu­ją­cej kolej­no­ści: Analiza obiek­to­wa, Projektowanie obiek­to­we, Programowanie obiek­to­we. Tak więc pro­gra­mo­wa­nie to ostat­ni etap i jedy­nie imple­men­ta­cja pro­jek­tu. Pomysł na archi­tek­tu­rę kodu pro­gra­mu to pro­jek­to­wa­nie. Jeżeli mówić o tym do cze­go jest przy­zwy­cza­jo­ny ludz­ki mózg, to do obiek­to­we­go postrze­ga­na oto­cze­nia, ale na dość wyso­kim pozio­mie abs­trak­cji (widzi­my ludzi lub samo­cho­dy, ale mało kto postrze­ga je jako sys­tem współ­dzia­ła­ją­cych obiektów”).

Człowiek postrze­ga swo­je oto­cze­nie jako okre­ślo­ne obiek­ty, ale rzad­ko zna i rozu­mie ich wewnętrz­ną struk­tu­rę i mecha­nizm dzia­ła­nia. I tu docho­dzi­my do poję­cia Przypadek Użycia w nota­cji UML

Przypadki użycia – czym są?

Z uwa­gi na to, że przy­tła­cza­ją­ca więk­szość (dekla­ro­wa­nych) zasto­so­wań poję­cia przy­pa­dek uży­cia ma swo­je źró­dło w nota­cji UML, sku­pie się na tej nota­cji. Od 2015 roku mamy UML 2.5, ostat­nia aktu­ali­za­cja do 2.5.1. mia­ła miej­sce w grud­niu 2017. Czytamy tam:

18.1.1 Summary
UseCases are a means to cap­tu­re the requ­ire­ments of sys­tems, i.e., what sys­tems are sup­po­sed to do. The key con­cepts spe­ci­fied in this clau­se are Actors, UseCases, and sub­jects. Each UseCase?s sub­ject repre­sents a sys­tem under con­si­de­ra­tion to which the UseCase applies. Users and any other sys­tems that may inte­ract with a sub­ject are repre­sen­ted as Actors.1

Ogólnie: Przypadki Użycia są spo­so­bem na opi­sa­nie wyma­gań wobec sys­te­mu, rozu­mia­nych jako to, co sys­tem ma robić. Kluczowe poję­cia z tym zwią­za­ne to Aktor, Przypadek Użycia, przed­miot opi­su. Każdy Przypadek Użycia repre­zen­tu­je sys­tem z per­spek­ty­wy celu jego uży­cia. Każdy czło­wiek lub inny zewnętrz­ny sys­tem mają­cy z nim inte­rak­cje, nazy­wa­my Aktorem tego systemu.

Tak więc Przypadek Użycia to reak­cja sys­te­mu na bodź­ce, któ­rych źró­dłem jest aktor systemu. 

18.1.3.1 Use Cases and Actors
A UseCase may apply to any num­ber of sub­jects. When a UseCase applies to a sub­ject, it spe­ci­fies a set of beha­viors per­for­med by that sub­ject, which yields an obse­rva­ble result that is of value for Actors or other sta­ke­hol­ders of the sub­ject.1

Generalizując Przypadek Użycia sys­te­mu repre­zen­tu­je (spe­cy­fi­ku­je) zacho­wa­nie sys­te­mu (zestaw, łań­cuch jego zacho­wań) w odpo­wie­dzi na okre­ślo­ny bodziec, efek­tem tego zacho­wa­nia jest okre­ślo­ny rezul­tat przed­sta­wia­ją­cy war­tość dla Aktora. 

Tak więc Przypadek Użycia to abs­trak­cja repre­zen­tu­ją­ca efekt inte­re­su­ją­cy z punk­tu widze­nia akto­ra, ten efekt to reak­cja sys­te­mu ini­cjo­wa­na dzia­ła­niem aktora. 

W spe­cy­fi­ka­cji UML opi­sa­no dwie spe­cy­ficz­ne konstrukcje:

Rozszerzenie (18.1.3.2. Extend) 

Extend is inten­ded to be used when the­re is some addi­tio­nal beha­vior that sho­uld be added, possi­bly con­di­tio­nal­ly, to the beha­vior defi­ned in one or more UseCases.1

Używane w celu poka­za­nia, że okre­ślo­ny Przypadek Użycia, może cecho­wać się pew­ny­mi dodat­ko­wy­mi, warun­ko­wy­mi zacho­wa­nia­mi (może ono doty­czyć wię­cej niż jed­ne­go przy­pad­ku użycia).

Włączenie (18.1.3.3 Includes)

The Include rela­tion­ship is inten­ded to be used when the­re are com­mon parts of the beha­vior of two or more UseCases. This com­mon part is then extrac­ted to a sepa­ra­te UseCase, to be inc­lu­ded by all the base UseCases having this part in com­mon.1

Używane jest w celu wyłą­cze­nia (poka­za­nia) na zewnątrz, pew­nej okre­ślo­nej wspól­nej czę­ści, dwóch lub więk­szej licz­by Przypadków użycia.

Dwa klu­czo­we wnioski:

  1. zarów­no inc­lu­de jak i extent są to kon­struk­cje ujaw­nia­ją­ce wnę­trze archi­tek­tu­ry kodu, a więc łamią­ce zasa­dę hermetyzacji,
  2. inc­lu­de to wyłą­czo­na część wspól­na co naj­mniej dwóch przy­pad­ków uży­cia, więc: 
    1. nie ma sen­su łącze­nie akto­ra do przy­pad­ku wyłą­czo­ne­go, bo do nie­sa­mo­dziel­ny frag­ment scenariusza,
    2. nie ma sen­su kon­struk­cja z jed­nym przy­pad­kiem uży­cia i jed­nym lub wie­lo­ma przy­pad­ka­mi połą­czo­ny­mi związ­kiem inc­lu­de.

Jeżeli dekla­ru­je­my, że pro­jekt jest zgod­ny z para­dyg­ma­tem obiek­to­wym, kon­struk­cje te nie mają zasto­so­wa­nia. Są zabro­nio­ne, bo łamią pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Obie te kon­struk­cje (inc­lu­de i extend) mają rodo­wód z metod struk­tu­ral­nych, a są to lata 80-te, gdzie sto­so­wa­nie poję­cia pod­pro­gra­mu było stan­dar­do­wą kon­struk­cją re-uży­cia kodu. Litera U w akro­ni­mie UML ozna­cza uni­fied” czy­li ujed­no­li­co­ny, UML jest więc ujed­no­li­co­nym i uni­wer­sal­nym narzę­dziem, co sami auto­rzy UML wska­zu­ją, tłu­ma­cząc dla­cze­go te kon­struk­cje zosta­ły utrzy­ma­ne w spe­cy­fi­ka­cji UML.:

This is becau­se UseCases may be spe­ci­fied in vario­us for­mats such as natu­ral lan­gu­age, tables, tre­es, etc.

Nie mniej jed­nak nadal poja­wia­ją się, łamią­ce fun­da­men­ty obiek­to­we­go para­dyg­ma­tu, kurio­zal­ne pomy­sły na mode­lo­wa­nie archi­tek­tu­ry sys­te­mu z uży­ciem Przypadków Użycia, takie jak te opi­sa­ne tu:

Decomposing Use Cases Towards Logical Architecture Design6

Innym przy­kła­dem sto­so­wa­nia przy­pad­ków uży­cia w spo­sób nie­zgod­ny z UML, jest bar­dzo popu­lar­na książ­ka Alistair’a Cockburna zaty­tu­ło­wa­na Stosowanie Przypadków Użycia7.

UML has had lit­tle impact on the­se ide­as – and vice ver­sa. Gunnar Overgaard, a for­mer col­le­ague of Jacobson?s, wro­te most of the UML use case mate­rial, and kept Jacobson?s heri­ta­ge. However, the UML stan­dards gro­up has a strong dra­wing-tools influ­en­ce, with the effect that the textu­al natu­re of use cases was lost in the stan­dard. Gunnar Overgaard and Ivar Jacobson discus­sed my ide­as, and assu­red me that most of what I have to say abo­ut a use case fits within one of the UML ellip­ses, and hen­ce neither affects nor is affec­ted by what the UML stan­dard has to say. That means you can use the ide­as in this book quite com­pa­ti­bly with the UML 1.3 use case stan­dard. On the other hand, if you only read the UML stan­dard, which does not discuss the con­tent or wri­ting of a use case, you will not under­stand what a use case is or how to use it, and you will be led in the dan­ge­ro­us direc­tion of thin­king that use cases are a gra­phi­cal, as oppo­sed to textu­al, con­struc­tion. Since the goal of this book is to show you how to wri­te effec­ti­ve use cases, and the stan­dard has lit­tle to say in that regard, I have iso­la­ted my remarks abo­ut UML to Appendix A.7

Cockburn wyty­ka nota­cji UML ogra­ni­cze­nia metod gra­ficz­nych opar­tych na ryso­wa­niu elips, jed­nak pomi­ja fakt, że przy­pad­ki uży­cia to cele akto­rów (i wyma­ga­nia czy­li umo­wa z zama­wia­ją­cym) a nie final­na wer­sja sys­te­mu oraz fakt, że UML zawie­ra mię­dzy inny­mi dia­gram sekwen­cji, któ­re­go celem sto­so­wa­nia jest wła­śnie deta­licz­ne doku­men­to­wa­nie sce­na­riu­szy przy­pad­ków uży­cia. w swo­im Dodatku A roz­pi­su­je się na temat tego, jak związ­ka­mi inc­lu­de, extend, dzie­dzi­cze­niem roz­pi­sy­wać deta­le tek­sto­wych (i tabe­la­rycz­nych) spe­cy­fi­ka­cji przy­pad­ków uży­cia, ale nie tyl­ko w moich oczach, pogłę­bia pro­blem łama­nia zasad para­dyg­ma­tu obiektowego.

Na zakoń­cze­nie, war­to zwró­cić uwa­gę na pra­ce takie jak ta: User Story to Use Case sce­na­rio8, gdzie korzy­sta­jąc z tego, że tak zwa­ne user sto­ry w wer­sji sfor­ma­li­zo­wa­nej to zapi­sy w rodzaju:

  • jako ? oso­ba, przy­pi­sa­na rola,
  • chcę ? cecha, funk­cjo­nal­ność, czynność,
  • ponie­waż ? uza­sad­nie­nie, rezul­tat, korzyść.

moż­li­we jest gene­ro­wa­ne (wypro­wa­dza­nie) przy­pad­ków uży­cia z user sto­ry wg. schematu:

  • aktor ? oso­ba,
  • przy­pa­dek uży­cia ? funkcjonalność,
  • rezul­tat sce­na­riu­sza przy­pad­ku uży­cia ? rezul­tat

Podejście to ma jed­nak poważ­ną wadę, jest nią zigno­ro­wa­nie fak­tu, że aktor to kla­sa użyt­kow­ni­ków a nie użyt­kow­nik. Innymi sło­wy np. sys­tem CRM prze­zna­czo­ny jest do pra­cy w dzia­le sprze­da­ży, akto­rem jest każ­dy pra­cow­nik tego dzia­łu (sys­tem CRM ma w swej pod­sta­wo­wej dzie­dzi­nie, jaką jest obsłu­ga kon­tak­tów z klien­ta­mi, jed­ne­go akto­ra: pra­cow­ni­ka dzia­łu sprze­da­ży, upraw­nie­nia kon­kret­nych osób to kon­se­kwen­cja ich sta­no­wisk i reguł biz­ne­so­wych). Dlatego powyż­sza meto­da i tak wyma­ga póź­niej­sze­go skla­sy­fi­ko­wa­nia osób w aktorów.

Konstrukcje w posta­ci dia­gra­mów, na któ­rych mamy mul­tum Przypadków Użycia, połą­czo­nych związ­kiem inc­lu­de z jed­nym przy­pad­kiem nazwa­nym Logowanie?9?, zali­czam do jed­nych z naj­bar­dziej kurio­zal­nych. Czytając taki dia­gram zgod­nie z UML, nale­ży uznać, że wszyst­kie sce­na­riu­sze zawie­ra­ją w sobie owo logo­wa­nie, inny­mi sło­wy, każ­da wyko­ny­wa­na czyn­ność z apli­ka­cją skła­da się mie­dzy innym z logo­wa­nia. Warto wie­dzieć, że w UML nie było i nie ma cze­goś o nazwie: biz­ne­so­we czy sys­te­mo­we przy­pad­ki Przypadki Użycia. 

A na zakoń­cze­nie cie­ka­we zesta­wie­nie błędów:

Use case model­ling is the most power­ful requ­ire­ments model­ling tech­ni­que to model solu­tion requ­ire­ments if applied cor­rec­tly. I have come across many BA teams (inc­lu­ding my own) that made lot of com­mon mista­kes in use case model­ling. By avo­iding the top 10 mista­kes iden­ti­fied in this paper, BA teams can not only save lot of efforts in use case model­ling but also signi­fi­can­tly enhan­ce the value deli­ve­red and impro­ve the satis­fac­tion of sta­ke­hol­ders. Source: Top 10 mista­kes in Use Case Modelling

(artykuł uzupełniony 2019-09-21)

Żródła

  1. 1.
    Unified Modeling Language. ABOUT THE UNIFIED MODELING LANGUAGE SPECIFICATION VERSION 2.5.1. https://​www​.omg​.org/​s​p​e​c​/​U​M​L​/​A​b​o​u​t​-​U​ML/. Published December 16, 2017. Accessed January 5, 2019.
  2. 2.
  3. 3.
  4. 4.
  5. 5.
  6. 6.
    Santos N. Modeling in Agile Software Development: Decomposing Use Cases Towards Logical Architecture Design. SpringerLink. 10.1007/978 – 3‑030 – 03673-7_31” target=„_blank” rel=„noopener noreferrer”>https://link.springer.com/chapter/" target="_blank" rel="noopener noreferrer">10.1007/978 – 3‑030 – 03673-7_31. Published November 3, 2018. Accessed January 5, 2019.
  7. 7.
    WRITING EFFECTIVE USE CASES, Alistair Cockburn, Addison-Wesley, c. 2001.
  8. 8.
  9. 9.
    Szwed P. io:zadanie_3. [Piotr Szwed]. http://home.agh.edu.pl/~pszwed/wiki/doku.php?id=io:zadanie_3. Published November 4, 2012. Accessed January 6, 2019.

Blockchain – system czy technologia?

Coraz czę­ściej poja­wia­ją­cy się ostat­nio buz­zword to blockchain:

System, któ­re­go nie da się zła­mać. Sam zaś może zmie­nić obli­cze wie­lu branż. Blockchain rewo­lu­cjo­ni­zu­je spo­sób zawie­ra­nia, roz­li­cza­nia i zapi­sy­wa­nia trans­ak­cji. […] Technologia ta…1

Ostatnio raczej wła­śnie w takim tonie coraz czę­ściej moż­na spo­tkać się z hasłem block­cha­in. Tego typu nagłów­ki i tre­ści wyszły z pra­sy bran­żo­wej IT i poja­wia­ją się w pra­sie z obsza­ru finan­sów, eko­no­mii gospo­dar­ki, blo­gach mene­dżer­skich. Lawinowy wzrost kur­su bit­co­in’a spo­wo­do­wał, że każ­de koja­rzo­ne z nim poję­cie natych­miast poja­wia się w nagłówkach…

Cóż to takie­go? Kwestię kryp­to-walu­ty, jaką jest bit­co­in, pomi­nę tu cał­ko­wi­cie, pomi­nę tak­że deta­le tech­no­lo­gii wyko­rzy­sta­nych w imple­men­ta­cji kryp­to­wa­lu­ty bit­co­in, gdyż nie ma ona wpły­wu na przed­miot tego tek­stu. Kluczowe pyta­nie brzmi: block­cha­in to tech­no­lo­gia czy sys­tem oraz gdzie to się może przydać?

Najpierw klu­czo­we pojęcia:

tech­no­lo­gia
1. ?meto­da prze­pro­wa­dza­nia pro­ce­su pro­duk­cyj­ne­go lub prze­twór­cze­go?
2. ?dzie­dzi­na tech­ni­ki zaj­mu­ją­ca się opra­co­wy­wa­niem nowych metod pro­duk­cji wyro­bów lub prze­twa­rza­nia surowców?

pro­ce­du­ra
1. ?okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub praw­nym?
2. ?w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu?

algo­rytm mat. ?ści­śle okre­ślo­ny ciąg czyn­no­ści, któ­rych wyko­na­nie pro­wa­dzi do roz­wią­za­nia jakie­goś zada­nia?

sce­na­riusz
1. ?tekst sta­no­wią­cy pod­sta­wę fil­mu, przed­sta­wie­nia lub audycji?
2. ?szcze­gó­ło­wo przy­go­to­wa­ny pro­gram jakiejś impre­zy lub jakie­goś spotkania?
3. ?zapla­no­wa­ny lub prze­wi­dy­wa­ny roz­wój wyda­rzeń?

wła­sność
1. ?to, co ktoś posiada?
2. ?pra­wo do roz­po­rzą­dza­nia rze­czą z wyłą­cze­niem innych osób, w gra­ni­cach okre­ślo­nych przez usta­wy i zasa­dy współ­ży­cia społecznego?

sys­tem ?układ ele­men­tów mają­cy okre­ślo­ną struk­tu­rę i sta­no­wią­cy logicz­nie upo­rząd­ko­wa­ną całość?

Na począ­tek tro­szecz­kę reguł doty­czą­cych doty­czą­cych pra­wa wła­sno­ści, gdyż wszel­kie trans­ak­cje wymia­ny cze­go­kol­wiek, nie tyl­ko w eko­no­mii, moż­na w zasa­dzie spro­wa­dzić do poję­cia wymia­ny, prze­nie­sie­nia wła­sno­ści środ­ków sta­no­wią­cych walu­tę, sta­no­wią­cych zapła­tę za prze­ka­za­ny towar lub usłu­gę. W komu­ni­ka­cji elek­tro­nicz­nej spro­wa­dza się to prak­tycz­nie do prze­nie­sie­nia danych i wia­ry­god­no­ści tej transakcji.

Pojęcie wła­sno­ści” to poję­cie z dzie­dzi­ny pra­wa. Pojęcie posia­dać coś (wziąć w posia­da­nie) ozna­cza ode­bra­nie innym pod­mio­tom pra­wa do dys­po­no­wa­nia tym czymś. Tak więc powie­dzieć, że się ma jakieś bit­co­iny ozna­cza, że nikt, poza nami, nie ma pra­wa nimi dys­po­no­wać (czym by nie były). Przekazanie komuś pra­wa wła­sno­ści (sprze­da­nie) cze­goś, ozna­cza, że sprze­da­ją­cy tra­ci pra­wo dys­po­no­wa­nia przed­mio­tem trans­ak­cji a nabyw­ca zysku­je je. To są pra­wa pod­mio­to­we do przed­mio­tu, tak zwa­ne poję­cia pier­wot­ne w pra­wie, poję­ciem wtór­nym jest tu przed­miot i wska­za­nie wła­ści­cie­la pod­mio­tu mają­ce­go wyłącz­ne pra­wo dys­po­no­wa­nia: pra­wa przed­mio­to­we (do przed­mio­tu). Innymi sło­wy na co dzień nie mówi­my, że nikt poza nami nie ma pra­wa dys­po­no­wa­nia danym przed­mio­tem, mówi­my że jeste­śmy posia­da­czem tego przed­mio­tu.2 Kluczowy jest tu fakt, że przed­miot może mieć w danym momen­cie tyl­ko jed­ne­go wła­ści­cie­la (tak­że zbio­ro­we­go, wte­dy ma on nazwę) lub nie mieć go wca­le (niko­mu nie ogra­ni­czo­no pra­wa wła­da­nia przed­mio­tem). Procedura reali­za­cji trans­ak­cji sprze­da­ży (prze­nie­sie­nia praw wła­sno­ści) for­mal­nie wyglą­da tak: (1) pozba­wie­nie pra­wa wła­sno­ści oso­by sprze­da­ją­ce­go, (2) nada­nie pra­wa wła­sno­ści oso­bie kupu­ją­ce­go. Jak widać jest tu moment gdy nikt nie jest wła­ści­cie­lem przed­mio­tu. Musi tak być, bo nie jest logicz­nie moż­li­we jed­no­cze­sne wła­da­nie przed­mio­tem przez dwa podmioty.

Tyle logi­ka :). Kluczem do dal­szej czę­ści jest pro­ce­du­ra reali­za­cji trans­ak­cji sprze­da­ży. To – chwi­lo­wy brak wła­ści­cie­la – poka­zu­je, że potrzeb­na jest tu albo zaufa­na trze­cia stro­na (np. bank pośred­nik), albo uczci­wość uczest­ni­ków trans­ak­cji (jak np. my kupu­jąc coś w skle­pie), albo pro­ce­du­ra unie­moż­li­wia­ją­ca nie­uczci­we zacho­wa­nie uczest­ni­ków transakcji.

Sama idea zabez­pie­cze­nia trans­ak­cji bez trze­ciej stro­ny zaufa­nia (nie chce­my wśród sie­bie niko­go o tak uprzy­wi­le­jo­wa­nej pozy­cji) jest wbrew pozo­rom pro­sta: trans­ak­cja prze­pro­wa­dza­na jest przy świad­kach (sprze­daż odby­wa się publicz­nie na oczach wie­lu) i zawar­to umo­wę, że nikt nie przy­własz­czy sobie przed­mio­tu w trak­cie trans­ak­cji. To two­rzy zało­że­nie, że nikt nie ma inte­re­su w tym by jaw­nie oszu­kać. Wyzwaniem jest tu jed­nak odwzo­ro­wa­nie roli publicz­no­ści w spo­sób pozwa­la­ją­cy, mimo wszyst­ko, zacho­wać w tajem­ni­cy stro­ny i przed­miot trans­ak­cji (co sta­no­wi tu jed­nak łyżecz­kę dzieg­ciu w becz­ce mio­du). Czyli sprzecz­ność? Troszkę tak…

Prosta wer­sja opi­sa­ne­go wyżej mecha­ni­zmu to roz­pro­sze­nie śla­du trans­ak­cji. Najprostszą meto­dą jest zasa­da: doku­ment opi­su­ją­cy trans­ak­cję – fak­tu­ra – jest prze­cho­wy­wa­ny w dwóch miej­scach: u sprze­da­ją­ce­go i u kupu­ją­ce­go. Sfałszowanie tego doku­men­tu wyma­ga­ło by zmo­wy obu stron (co jest mało praw­do­po­dob­ne), bo w przy­pad­ku fak­tur ta zmo­wa jest trud­na, z uwa­gi na sprzecz­ny inte­res obu stron: kupu­ją­cy chce zaksię­go­wać koszt zaku­pu co mu obni­ży poda­tek, sprze­da­ją­cy musi (nie­chęt­nie :)) zaksię­go­wać przy­chód do opo­dat­ko­wa­nia. Nie ist­nie­je tu kom­pro­mis więc pozo­sta­je zacho­wa­ne sta­nu (war­tość trans­ak­cji) fak­tycz­ne­go, ta sama treść fak­tu­ry w dwóch miej­scach o sprzecz­nym inte­re­sie, pozwa­la uznać, że iden­tycz­ność tre­ści sta­no­wi potwier­dze­nie prawdziwości.

Wadą tego podej­ścia, jest to że kon­tro­la wszyst­kich doku­men­tów jed­ne­go pod­mio­tu jest cza­so­chłon­na bo wyma­ga kon­tak­tu z wie­lo­ma pod­mio­ta­mi (dru­gi­mi stro­na­mi każ­dej trans­ak­cji). Nie ma pro­ble­mu gdy trans­ak­cja jest bez­po­śred­nia. Problem zaczy­na się wte­dy, gdy potrzeb­ne jest zaufa­nie do kon­tra­hen­ta odle­głe­go. Skoro pro­ce­du­ra reali­za­cji prze­nie­sie­nia wła­sno­ści ma trzy sta­ny (wła­ści­ciel A, brak wła­ści­cie­la, wła­ści­ciel B) to nie ist­nie­je jed­no­cze­sność więc usta­le­nie co naj­pierw: prze­ka­zać pro­dukt czy prze­ka­zać pie­nią­dze, sta­je się grą ana­lo­gicz­ną do dyle­ma­tu więź­nia (nie­uczci­wy wygry­wa)3.

Tak więc mecha­nizm uży­cia dużej publicz­no­ści, dla pary pod­mio­tów reali­zu­ją­cej trans­ak­cję sprze­da­ży, daje dużą pew­ność, ale jest pro­blem z kryp­to­wa­lu­ta­mi: stro­ny trans­ak­cji i publicz­ność chcą pozo­stać ano­ni­mo­wi. Dlatego mecha­nizm został wzbo­ga­co­ny o kon­tak­ty z publicz­no­ścią (obser­wa­to­rzy trans­ak­cji czy­li Ci któ­rzy ją uwia­ry­gad­nia­ją) meto­dą kodo­wa­nych blo­ków danych z uży­ciem roz­pro­szo­nej bazy danych. Pokazano to na poniż­szym dia­gra­mie4:

How block­cha­in works

Cała idea bazu­je na przy­ję­ciu wer­sji, że naj­pierw pie­nią­dze a potem towar (a nie odwrot­nie), gdzie towa­rem (tu) są np. bit­co­iny. Zmorą tego sys­te­mu jest jed­nak wymóg ano­ni­mo­wo­ści, któ­ry zaowo­co­wał dodat­ko­wą zło­żo­no­ścią z powo­du potrze­by imple­men­ta­cji auto­ry­za­cji i przy­ję­cia rela­tyw­nie dużej, uwia­ry­god­nie­nie przez publicz­ność, licz­by pod­mio­tów auto­ry­zu­ją­cych trans­ak­cje. Wikipedia poda­je, że z tego powo­du trans­ak­cje cechu­je wyso­ki koszt ener­ge­tycz­ny każ­dej z nich (podob­no zuży­cie ener­gii elek­trycz­nej per trans­ak­cja odpo­wia­da dzien­ne­mu zapo­trze­bo­wa­niu przez typo­we ame­ry­kań­skie gospo­dar­stwo domo­we), sto­sun­ko­wo dłu­gi czas zatwier­dza­nia trans­ak­cji, niska wydajność.

Jednak pomi­ja­jąc deta­le, sama meto­da opar­ta na zaufa­niu budo­wa­nym poprzez dys­try­bu­cję ryzy­ka i odpo­wie­dzial­no­ści ma wszel­kie zna­mio­na powo­dze­nia jako meto­da two­rze­nia zaufa­nej (wia­ry­god­nej) komu­ni­ka­cji elek­tro­nicz­nej, bez potrze­by sto­so­wa­nia wyra­fi­no­wa­nych, kosz­tow­nych metod kodo­wa­nia ska­zu­ją­cych pomysł na kon­kret­ną tech­no­lo­gię i algo­ryt­my… Takie zabez­pie­cze­nie to sys­tem pod­mio­tów bio­rą­cych udział w trans­ak­cjach i usta­lo­na kolej­ność kro­ków dzia­ła­nia, któ­ry moż­na zaim­ple­men­to­wać jako pro­ce­du­rę a nie jako technologię.

Tak więc czy block­cha­in to tech­no­lo­gia? Jeżeli mamy na myśli kon­kret­ne roz­wią­za­nie zasto­so­wa­ne na ryn­ku bit­co­ina, to są to kon­kret­ne tech­no­lo­gie uży­te do reali­za­cji pro­ce­du­ry sprze­da­ży. Jeżeli uzna­my, że jest to pro­ce­du­ral­ne zabez­pie­cze­nie trans­ak­cji, to jest to pro­ce­du­ra a nie tech­no­lo­gia. Jeżeli pisze­my o bloch­cha­in jako o meto­dzie auto­ry­zo­wa­nia trans­ak­cji elek­tro­nicz­nych to mamy na myśli pro­ce­du­rę a nie tech­no­lo­gię. Ciekawe jest to, że o jakim­kol­wiek łama­niu zabez­pie­czeń moż­na mówić wyłącz­nie wte­dy, gdy ele­men­tem sys­te­mu będzie jakie­kol­wiek np. szy­fro­wa­nie czy pod­pi­sy­wa­nie. Jeżeli sys­tem będzie jaw­ny i zosta­nie opar­ty wyłącz­nie na pro­ce­du­rach, zni­ka­ją tech­no­lo­gicz­ne zabez­pie­cze­nia i szy­fry a więc nie ma cze­go łamać…

Tak więc wyda­je się, że pro­ce­du­ral­ne meto­dy gwa­ran­to­wa­nia trans­ak­cji jed­nak są lep­sze od pod­pi­sów elek­tro­nicz­nych, bo łatwiej­sze w imple­men­ta­cji i odpor­niej­sze na nie­uczci­wość w sie­ci. Każdy typ trans­ak­cji zapew­ne będzie miał swo­ją pro­ce­du­rę, gdyż to ryzy­ko wyrzą­dze­nia szko­dy przez oszu­sta i wiel­kość tej szko­dy powin­ny decy­do­wać o kosz­tach zabez­pie­cze­nia a nie uzna­nie, że sto­su­je­my z zasa­dy meto­dy naj­bez­piecz­niej­sze czy­li naj­kosz­tow­niej­sze. Tu po raz kolej­ny przy­to­czę przy­kład rocz­nych dekla­ra­cji podat­ko­wych w Polsce: rezy­gna­cja z e‑podpisu spo­wo­do­wa­ła lawi­no­wy wzrost licz­by dekla­ra­cji skła­da­nych dro­gą elek­tro­nicz­ną przy prak­tycz­nie zero­wej licz­bie nad­użyć i bez kosz­tów posia­da­nia kwa­li­fi­ko­wa­ne­go pod­pi­su elek­tro­nicz­ne­go5.

Model dziedziny jako mechanizm

W 2013 roku, arty­kuł o tym czym jest model dzie­dzi­ny, zakoń­czy­łem słowami:

Metody obiek­to­we pole­ga­ją na mode­lo­wa­nia świa­ta rze­czy­wi­ste­go (dome­ny sys­te­mu), w efek­cie nie tra­ci­my żad­nej wie­dzy mode­lu­jąc (zapi­su­jąc) ?świat? w posta­ci mode­lu dzie­dzi­ny. Tu war­to zwró­cić uwa­gę, że wie­dzę o tym jak wyglą­da fak­tu­ra jako doku­ment, musi jakiś obiekt posia­dać: to obiekt fak­tu­ra, posia­da­ją­cy np. ope­ra­cję (meto­dę) ?dru­kuj?. Ale to temat na inny wpis :). (Źródło: Czym jest a czym nie jest tak zwa­ny model dzie­dzi­ny sys­te­mu | | Jarosław Żeliński IT-Consulting).

Mamy rok 2017, więc czte­ry lata czekało 😉 … 

Czytaj dalej… Model dzie­dzi­ny jako mecha­nizm”
złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Cynefin czyli co…

Od cza­su do cza­su spo­ty­kam się w pro­jek­tach z poję­ciem cyne­fin”. Najpierw typo­wy opis z jakim moż­na się zetknąć w sieci:

Cynefin jest swo­istą teo­rią, któ­rą moż­na wyko­rzy­stać do opi­su dzia­ła­nia skom­pli­ko­wa­nych sys­te­mów takich jak róż­ne­go rodza­ju przed­się­wzię­cia czy nawet rela­cje i pro­ble­my mię­dzy­na­ro­do­we. Jako model tłu­ma­czy i pró­bu­je pomóc w wybo­rze stra­te­gii dzia­ła­nia, wska­zu­jąc jed­no­cze­śnie wzor­ce postę­po­wa­nia, któ­re powin­ny być zde­cy­do­wa­nie inne w zależ­no­ści od tego w jakiej sytu­acji się znaj­du­je się fir­ma. W prak­ty­ce moż­na korzy­stać z Cynefin jako narzę­dzia wspie­ra­ją­ce­go zarzą­dza­nie pro­jek­tem, zespo­łem lub nawet orga­ni­za­cją. Od jakie­goś cza­su Cynefin prze­bi­ja się tak­że do ruchu agile’owego.

Model Cynefin ma pięć obsza­rów. Pierwsze czte­ry obsza­ry to:

Prosty – zwią­zek mię­dzy przy­czy­ną a skut­kiem jest dla wszyst­kich oczy­wi­sty. Proponowany sche­mat dzia­ła­nia: odczuj-kla­sy­fi­kuj-reaguj. Można sto­so­wać naj­lep­sze praktyki.

Skomplikowany – zwią­zek mię­dzy przy­czy­ną a skut­kiem wyma­ga ana­li­zy lub innej for­my badań i/lub zasto­so­wa­nia wie­dzy eks­per­tów. Proponowany sche­mat dzia­ła­nia: odczuj-ana­li­zuj-reaguj. Można sto­so­wać dobre praktyki.

Złożony – zwią­zek mię­dzy przy­czy­ną a skut­kiem mogą być dostrze­żo­ny w retro­spek­cji (z per­spek­ty­wy cza­su), ale nie da się go prze­wi­dzieć. Proponowany sche­mat dzia­ła­nia: son­duj-odczuj-reaguj. Możemy wykryć nową praktykę.

Chaos – nie ma żad­ne­go związ­ku mię­dzy przy­czy­ną a skut­kiem na pozio­mie sys­te­mów. Proponowany spo­sób dzia­ła­nia: dzia­łaj-odczuj-reaguj. Możemy odkryć powie­ścio­wą praktykę

Piąta dome­na zwa­na nie­po­rząd­kiem” to stan nie­wie­dzy o rodza­ju ist­nie­ją­cej przy­czy­no­wo­ści, w któ­rej oso­by wra­ca­ją do wła­snej stre­fy kom­for­tu pod­czas podej­mo­wa­nia decy­zji. (Źródło: Cynefin)

inne źró­dło podaje:

Model: Cynefin
Problem: Jakiego typu podej­ście zasto­so­wać w zależ­no­ści od kon­tek­stu?
Rozwiązanie: Użyj mode­lu Cynefin jako mode­lu decy­zyj­ne­go.
Opis tech­ni­ki: Główna myśl mode­lu Cynefin jest nastę­pu­ją­ca: zagad­nie­nia, z któ­ry­mi mamy do czy­nie­nia, nie są sobie rów­ne i może­my je podzie­lić ze wzglę­du na ich zło­żo­ność. Stosuj podej­ścia ade­kwat­ne do pozio­mu zło­żo­no­ści two­jej dzie­dzi­ny.
Proste (ang. sim­ple) ? to sys­te­my, w któ­rych jed­no­znacz­nie moż­na powią­zać przy­czy­nę ze skut­kiem. Do tego obsza­ru nale­żą dobrze roz­po­zna­ne, opi­sa­ne dzie­dzi­ny pro­ble­mo­we, gdzie dostęp­na jest wie­dza, gdzie wystę­pu­ją­ce pro­ble­my nie wyma­ga­ją zło­żo­nej inter­pre­ta­cji czy doświad­cze­nia.
Skomplikowane (ang. com­pli­ca­ted) ? są to sys­te­my, w któ­rych ist­nie­je powią­za­nie mię­dzy przy­czy­ną a skut­kiem, ale nie jest ono pro­ste do wykry­cia. Znalezienie roz­wią­za­nia pro­ble­mu wyma­ga wie­dzy eks­perc­kiej, duże­go doświad­cze­nia oraz zło­żo­nej ana­li­zy. Ponadto sys­tem tego typu jest sta­tycz­ny lub przy­naj­mniej mało zmien­ny (zmien­ność moż­na prze­wi­dzieć i prze­ana­li­zo­wać).
Złożone (ang. com­plex) ? są to sys­te­my, w któ­rych nie ma jed­no­znacz­nych powią­zań mię­dzy przy­czy­ną a skut­kiem, gdyż zmie­nia­ją się one w cza­sie ? moż­na je wykryć poprzez eks­pe­ry­men­ty i docie­ka­nia obec­ne­go sta­nu rze­czy. Posiadanie wie­dzy eks­perc­kiej nie jest wystar­cza­ją­ce, aby zna­leźć roz­wią­za­nie pro­ble­mu. Potrzebne są eks­pe­ry­men­ty i ana­li­za efek­tów podej­mo­wa­nych dzia­łań.. System tego typu to sys­tem żywy, orga­nicz­ny, zmien­ny w cza­sie.
Choatyczne (ang. cha­otic) ? są to sys­te­my w któ­rych bra­ku­je powią­zań mię­dzy przy­czy­ną i skut­kiem. Wszelkie sytu­acje alar­mo­we, poża­ry, kata­stro­fy są przy­kła­da­mi takich sys­te­mów.
Nieporządek (ang. disor­der) ? to sytu­acja, w któ­rej nie jeste­śmy w sta­nie okre­ślić, z jakie­go typu sys­te­mem mamy do czy­nie­nia. (Źródło: Model Cynefin)

A teraz porów­naj­my to ze zna­ną od lat ogól­na teo­rią Systemów, któ­ra tak kla­sy­fi­ku­je systemy:

System bywa tak­że nazy­wa­ny ?zor­ga­ni­zo­wa­ną zło­żo­no­ścią?. Klasyczna ogól­na teo­ria sys­te­mów opar­ta jest na mate­ma­tycz­nych mode­lach (rów­na­niach), opi­su­ją­cych reak­cję każ­de­go ele­men­tu sys­te­mu, i sys­te­mu jako całość, na okre­ślo­ne bodź­ce. Mechanizm dzia­ła­nia (zacho­wa­nia się) sys­te­mu to wyni­ko­wy ?wzór?. W meto­dzie nauko­wej zestaw takich mate­ma­tycz­nych rów­nań nazy­wa się ?mode­lem? lub po pro­stu teo­rią wyja­śnia­ją­cą. Równania opi­su­ją­ce te ele­men­ty to, zależ­nie od zło­żo­no­ści sys­te­mu, rów­na­nia linio­we (pro­ste) lub rów­na­nia nie­li­nio­we.

GeneralSystemTheoryMathematicalProblems

?Banalnie pro­ste? sys­te­my moż­na opi­sać jed­nym, pro­stym rów­na­niem linio­wym. Systemy uzna­wa­ne za ?łatwe? do ana­li­zy to te, dają­ce się opi­sać pro­stym ukła­dem kil­ku rów­nań linio­wych lub jed­nym rów­na­niem róż­nicz­ko­wym. Systemy wyma­ga­ją­ce do ich opi­su (zamo­de­lo­wa­nia) ukła­du bar­dzo wie­lu rów­nań linio­wych lub nawet kil­ku poje­dyn­czych róż­nicz­ko­wych, sta­ją bar­dzo trud­ne, a w mia­rę rosną­cej ilo­ści rów­nań (zło­żo­no­ści sys­te­mu), są po pro­stu nie­moż­li­we do roz­wią­za­nia meto­dą inną niż sta­ty­stycz­na (ite­ra­cje i bada­nie rezul­ta­tów). Pisząc ?ana­li­za? mamy tu na myśli moż­li­wość nie tyl­ko opi­sa­nia tymi rów­na­nia­mi sys­te­mu (bo to nie musi być trud­ne) ale ich (tych rów­nań) roz­wią­za­nie (przy­po­mi­nam: to wie­le rów­nań z wie­lo­ma zmien­ny­mi). (źr. Ogólna Teoria Systemów).

Od sie­bie dodam, że model sys­te­mu to struk­tu­ra obra­zu­ją­ca współ­pra­cu­ją­ce (mają­ce ze sobą inte­rak­cje) obiek­ty a owe rów­na­nia linio­we i nie­li­nio­we” to odpo­wie­dzi na bodź­ce (mówiąc języ­kiem metod obiek­to­wych są to meto­dy, reak­cje, odpo­wie­dzi, tych obiek­tów). Odpowiedź całe­go sys­te­mu moż­na więc opi­sać jed­nym rów­na­niem, dla­te­go w tytu­le tabe­li nazwa­no sys­tem pro­ble­mem mate­ma­tycz­nym, zło­żo­ność rów­na­nia opi­su­ją­ce­go odpo­wiedź sys­te­mu obra­zu­je sto­pień zło­żo­no­ści tego sys­te­mu. Dodam też, że ana­li­za obiek­to­wa pozwa­la posłu­gi­wać się cało­ścią lub poszcze­gól­ny­mi obiek­ta­mi zależ­nie od przy­ję­te­go pozio­mu abs­trak­cji. A teraz po raz kolej­ny defi­ni­cja systemu:

System: zło­żo­ny obiekt wyróż­nio­ny w bada­nej rze­czy­wi­sto­ści, sta­no­wią­cy całość two­rzo­ną przez zbiór obiek­tów ele­men­tar­nych (ele­men­tów) i powią­zań (związ­ków i rela­cji) mię­dzy nimi (Sienkiewicz, 1994) (Źródło: Słownik Pojęć | Jarosław Żeliński IT-Consulting)

Napisanie więc, że są sys­te­my, w któ­rych nie ma jed­no­znacz­nych powią­zań mię­dzy przy­czy­ną a skut­kiem” albo w któ­rych bra­ku­je powią­zań mię­dzy przy­czy­ną i skut­kiem”, świad­czy o zwy­kłej nie­wie­dzy, o nie­zro­zu­mie­niu two­rzo­ne­go sys­te­mu (a nawet o nie­zro­zu­mie­niu defi­ni­cji same­go poję­cia sys­tem) a nie o tym, że nie ma w nim powią­zań”, bo gdy­by ich nie było nie był by to jeden sys­tem. Skrajność to stan w któ­rym nie jeste­śmy w sta­nie okre­ślić, z jakie­go typu sys­te­mem mamy do czy­nie­nia” czy­li nic nie kumam” i to moim zda­niem okre­śla całe podej­ście zwa­ne cyne­fin”.

To wła­snie to, co nie raz widu­ję w pra­cy nazy­wa­nej czę­sto agi­le”: podej­mo­wa­nie się pro­jek­tów przy cał­ko­wi­tym bra­ku zro­zu­mie­nia dzie­dzi­ny pro­ble­mu. To, czy nazwie­my to cha­osem, czy znaj­dzie­my nową mądrą” nazwę CYNEFIN, nicze­go nie zmie­nia. Po pro­stu brzy­twa Ockhama” po raz kolej­ny szy­der­czo się uśmie­cha… A pró­by napi­sa­nia opro­gra­mo­wa­nia w sytu­acji bra­ku zro­zu­mie­nia jaki ma być mecha­nizm jego dzia­ła­nia to po pro­stu szu­ka­nie kło­po­tów… i nie­ste­ty nadal czę­sto spo­ty­ka­ne zja­wi­sko czy­li szczur w labiryncie”… 

[doda­tek]

Ciekawostką jest tak­że archi­tek­tu­ra C4” (czy­taj opis). Jest to Cała teo­ria i meto­da” w któ­rej jest 100% tech­no­lo­gii i ZERO o biz­ne­so­wej dzie­dzi­nie i jej logi­ce… Bardzo czę­sto deve­lo­pe­rzy nie­ste­ty obie­cu­ję, ze sami napi­szą” to opro­gra­mo­wa­nie, a potem mozol­nie po omac­ku, wie­lo­ma pró­ba­mi, usi­łu­ją stwo­rzyć opro­gra­mo­wa­nie reali­zu­ją­ce logi­kę biz­ne­so­wą… jak szczur w labi­ryn­cie któ­ry któ­ry na każ­dą rzecz któ­rej nie rozu­mie znaj­du­je nową nazwę: raz CYNEFIN, raz C4… (tak na praw­dę C4 to co naj­wy­żej tyl­ko nowy pro­fil do UML, jed­na stro­na łącz­nie z komentarzami).