Visual Paradigm v.17

Właśnie skoń­czył się mi insta­lo­wać upgra­de Visual Paradigm v.17. To narzę­dzie towa­rzy­szy mi od 2005 roku, ale po kolei. 

W zasa­dzie od począt­ku swo­jej karie­ry w bran­ży IT mode­le two­rzy­łem wyłącz­nie z uży­ciem sfor­ma­li­zo­wa­nych nota­cji. Kluczowym powo­dem zawsze były: kon­tro­lo­wal­na popraw­ność i logi­ka tych mode­li oraz stan­da­ry­za­cja. To trosz­kę jak z mate­ma­ty­ką: wie­my, że dwa i dwa to zawsze czte­ry a do zako­mu­ni­ko­wa­nia tego innym uży­wa­my stan­dar­do­wej for­my zapi­su: 2+2=4. W zasa­dzie z mate­ma­ty­ką nie mamy pro­ble­mu, pro­ble­mem są sche­ma­ty blo­ko­we: wie­lu ludzi uwa­ża, że to tyl­ko obraz­ki, któ­re moż­na sobie ryso­wać po swo­je­mu a ikon­ki nota­cji to tyl­ko biblio­te­ka faj­nych sym­bo­li. Niestety nic bar­dziej myl­ne­go: sfor­ma­li­zo­wa­na nota­cja to język z jego regu­ła­mi i mają­cy­mi okre­ślo­ne zna­cze­nie zna­ka­mi. Nie będę tu tego wąt­ku kon­ty­nu­ował, na moim blo­gu jest wie­le arty­ku­łów na ten temat, dzi­siaj o narzędziach.

Moja przy­go­da z mode­la­mi zaczę­ła w latach 90-tych gdy jako ana­li­tyk pro­jek­tant musia­łem zacząć porząd­nie doku­men­to­wać wyni­ki ana­liz i pro­jek­to­wa­ne sys­te­my. Bardzo szyb­ko sie nauczy­łem, że wszel­kie zanie­dba­nia z mojej stro­ny, szcze­gól­nie brak pre­cy­zji w opi­sy­wa­niu firm klien­tów czy pro­jek­to­wa­nych roz­wią­zań, to po pro­stu brak sza­cun­ku dla cza­su moich kole­ża­nek i kole­gów z dzia­łu developmentu. 

Pierwsze mode­le jakie robi­łem to były mode­le pro­ce­sów i prze­pły­wy danych robio­ne z uży­ciem nota­cji DFD (nadal zda­rza się, że jej uży­wam) oraz IDEF0. W dru­giej poło­wie lat 90-tych poja­wia się nota­cja UML, któ­ra w moich pro­jek­tach (sys­te­my kom­po­nen­to­we zorien­to­wa­ne obiek­to­wo) zaczę­ła zaj­mo­wać miej­sce DFD. Podstawowym narzę­dziem począt­ko­wo był Staffware (obec­nie TIBCO), ale z uwa­gi na jego cięż­kość” i kosz­ty, prze­nio­słem sie na Visio Sampler” (po prze­ję­ciu przez Microsoft obec­nie MS Visio). 

I tak to trwa­ło do 2005 roku, gdy w dużym pro­jek­cie dla Echo Investment SA, oka­za­ło, że pra­co­chłon­ność zwią­za­na z aktu­ali­za­cją mode­li i całę­go rapor­tu z ana­li­zy, czy­li doku­men­tu Analiza Biznesowa i Projekt Systemu, z uży­ciem MS Visio, sta­je się ogrom­nych poże­ra­czem cza­su, a ja mam kon­trakt fixed-pri­ce”. Tak więc pew­ne­go razu, w hote­lu Łysogóry” w Kielcach, po pół­no­cy, z wizją nie­do­trzy­ma­nia ter­mi­nów, usia­dłem do kom­pu­te­ra i zaczą­łem szu­kać w Internecie zba­wie­nia”, porów­na­nie kil­ku pro­duk­tów zaowo­co­wa­ło wybo­rem Visual Paradigm. Głównym kon­ku­ren­tem wte­dy był EA SPARX, jed­nak fakt, że goły EA bez plu­gi­nów nie nada­je się do zbyt wie­lu rze­czy, ma nie­zgod­no­ści ze spe­cy­fi­ka­cja­mi BPMN i UML (export XMI, nie pozwa­la na wie­lo­krot­ne umiesz­cza­nie tych samych ele­men­tów na jed­nym dia­gra­mie itp.), sama insta­la­cja i kon­fi­gu­ra­cja wer­sji demo zaj­mo­wa­ła ponad godzi­nę, brak (wte­dy) moż­li­wo­ści natych­mia­sto­wej akty­wa­cji po opła­cie kar­tą kre­dy­to­wą (następ­ne­go dnia rano musia­łem coś poka­zać i nie mogła to być wer­sja ewa­lu­acyj­na i jej zna­ki wod­ne), spo­wo­do­wa­ły, że na pla­cu boju został VP, któ­re­go insta­la­cja i akty­wa­cja zaj­mu­je kil­ka minut, po któ­rych nada­je się natych­miast do pracy.

Okazało się, że pra­ca z VP nie wyma­ga nicze­go poza zna­jo­mo­ścią spe­cy­fi­ka­cji nota­cji: jak coś jest w spe­cy­fi­ka­cji to jest tak­że w VP. Do tego suport VP dzia­ła natych­miast (odpi­su­ją na maile, w skraj­nym przy­pad­ku wcho­dzą” zdal­nie na kom­pu­ter). Z EA mie­wa­łem kil­ka przy­gód jako pod­wy­ko­naw­ca w pro­jek­tach, i za każ­dym razem wnio­sek był ten sam: nie rezy­gnu­ję z VP.

Jak się z tym narzę­dziem pra­cu­je? Swego cza­su na żywo pokazywałem: 

Obecnie mamy wer­sje 17. Kolejna doj­rzal­sza wer­sja, bogat­sza o kil­ka nowi­nek w sto­sun­ku do poprzed­niej 16.3.: https://​www​.visu​al​-para​digm​.com/​w​h​a​t​s​-​n​ew/

Kluczowe moim zda­niem cechy tego narzę­dzia to:

  1. prak­tycz­nie peł­na zgod­ność wspie­ra­nych nota­cji z ich spe­cy­fi­ka­cja­mi na OMG​.org,
  2. potęż­ny gene­ra­tor rapor­tów (nie uży­wam do tego celu MS Office od 2007 roku), pra­co­chłon­ność opra­co­wy­wa­nia i aktu­ali­za­cji doku­men­tów wyni­ko­wych (PDF/docx) spa­dła nie­mal­że do zera,
  3. ser­wer pra­cy gru­po­wej (Teamwork Server) w chmu­rze to:
    1. peł­ne wer­sjo­no­wa­nie (iden­tycz­nie jak wer­sjo­no­wa­nie kodu na ser­we­rach Subversion i podob­nych), moż­li­wość budo­wa­nia gałę­zi pro­jek­tu, powro­tu do dowol­nej wcze­śniej­szej revi­zji”, itp. 
    2. pra­ca gru­po­wa na hie­rar­chicz­nym repo­zy­to­rium (nie jest to baza SQL, pra­ca off-line gwa­ran­tu­je peł­ne bezpieczeństwo),
    3. kon­tro­lo­wa­ny dostęp do wglą­du (rola recen­zen­ta doku­men­ta­cji) oby­wa się bez dodat­ko­wych opłat (moduł Postmania),
    4. syn­chro­ni­za­cja sko­ja­rzo­ne­go z pro­jek­tem fide­ru pli­ków (wszel­kie załącz­ni­ki, np. doku­men­ty źródłowe),
  4. moż­li­wość two­rze­nia dia­gra­mów on-line.

To tyl­ko wybra­ne cechy, w obec­nej wer­sji 17. mię­dzy inny­mi doda­no nowe funk­cjo­nal­no­ści do gene­ra­to­ra doku­men­ta­cji i ele­men­tów zarza­dza­nia pro­jek­tem. Tak! VP ma potęż­ne narzę­dzie do zarzą­dza­nia pro­jek­tem na eta­pie nad­zo­ru nad imple­men­ta­cję: nie­za­leż­ne wer­sjo­no­wa­nie wszyst­kich ele­men­tów mode­li i gene­ro­wa­nie rapor­tów róż­nic mię­dzy com­mi­ta­mi”. Dokumentowanie przy­pad­ków uży­cia zgod­ne z Use Case 2.0, zgod­ność ze SCRUM i wspar­cie dla zwin­nych metod pra­cy (pra­ca z user sto­ry, kan­ban, i wie­le innych). 

Od same­go począt­ku VP to tak­że wspar­cie dla naj­waż­niej­szych obiek­to­wych wzor­ców pro­jek­to­wych (Rebeka Wirfbrock i jej książ­ka Wirfs-Brock, R., & McKean, A. (2009). Object design: Roles, respon­si­bi­li­ties, and col­la­bo­ra­tions. Addison-Wesley) i mode­lo­wa­nia struk­tur XML, SOA, RESTfull API, itp. 

I na koniec mój dru­gi wewnętrz­ny idol” to cała sek­cja UX Design and Wireframe Tools czy­li two­rze­nie makiet ekra­nów Low Fidelity oraz High Fidelity, a tak­że map i ani­mo­wa­nych mode­li ich prze­pły­wu. Więcej tu: Makiety.

Tak więc mając Visual Paradigm, nicze­go wię­cej nie potrze­bu­ję i z przy­jem­no­ścią powi­ta­łem na moim kom­pu­te­rze wer­sję 17.0 do cze­go zachę­cam innych użyt­kow­ni­ków VP. Pozostałych zaś infor­mu­ję, że jest takie narzędzie ;). 

Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Wprowadzenie

Tym razem krót­ka recen­zja pew­nej książ­ki z roku 2006, a raczej jej pole­ce­nie każ­de­mu pro­jek­tan­to­wi i archi­tek­to­wi dzi­siaj. Na koń­cu pole­cam tak­że kolej­ną now­szą pozy­cję jako uzu­peł­nie­nie. Adresatami tej recen­zji są głów­nie ana­li­ty­cy i pro­jek­tan­ci, jed­nak adre­su­ję ten wpis tak­że do deve­lo­pe­rów, zakła­dam że dla nich nie jest to coś nowe­go”, ale być może mają jakieś rady dla projektantów. 

Warto tak­że pod­kre­ślić, że pomię­dzy OOP a OOAD jest coraz więk­sza róż­ni­ca i podział na role: ana­li­za i pro­jek­to­wa­nie oraz imple­men­ta­cja, a tak­że postę­pu­ją­ca sepa­ra­cja tych ról, sta­ją się stan­dar­dem w inży­nie­rii opro­gra­mo­wa­nia :

Programming is not sole­ly abo­ut con­struc­ting softwa­re — pro­gram­ming is abo­ut desi­gning software.

Kolejna war­ta zwró­ce­nia uwa­gi rzecz: pro­jek­to­wa­nie inte­gra­cji sys­te­mów w orga­ni­za­cji to nic inne­go model sys­te­mu zorien­to­wa­ny na inter­fej­sy (patrz wcze­śniej­szy wpis: Integracja sys­te­mów ERP jako źró­dło prze­wa­gi ryn­ko­we).

Recenzja

Interface-Ofriented Design , to książ­ka o archi­tek­tu­rze i jej pro­jek­to­wa­niu. We wstę­pie autor pisze (oryg):

Autor, na wie­lu przy­kła­dach poka­zu­je jak moż­na pro­jek­to­wać (two­rzyć) opro­gra­mo­wa­nie budu­jąc je ze współ­pra­cu­ją­cych komponentów. 

Wiele się mówi o pro­gra­mo­wa­niu obiek­to­wym a mało o pro­jek­to­wa­niu zorien­to­wa­nym na kom­po­nen­ty (modu­ły). Ważna rzecz: pro­jek­to­wa­nie zorien­to­wa­ne na inter­fej­sy kon­cen­tru­je się na kom­po­nen­tach i ich inter­fej­sach, kom­po­nen­ty te mogą, ale nie muszą, być imple­men­to­wa­ne za pomo­cą języ­ków obiek­to­wych. Projekty, któ­re sku­pia­ją się na kom­po­nen­tach i ich inter­fej­sach mają ogrom­ną zale­tę: pre­cy­zyj­nie opi­su­ją co ma pro­gram robić a jed­no­cze­śnie nie narzu­ca­ją narzę­dzia implementacji.

Kolejna rzecz to fakt, że obec­nie znacz­nie bar­dziej niż w cza­sach gdy książ­ka była pisa­na (uka­za­ła się w 2006 roku), nabie­ra zna­cze­nia roz­pro­szo­na archi­tek­tu­ra: real­nie nie ma już mono­li­tów, mamy inte­gra­cje sys­te­mów mię­dzy part­ne­ra­mi han­dlo­wy­mi, z reje­stra­mi publicz­ny­mi, mię­dzy lokal­ny­mi i chmu­ro­wy­mi infra­struk­tu­ra­mi. Rozproszone prze­twa­rza­nie to archi­tek­tu­ry zorien­to­wa­ne na usłu­gi, któ­re kła­dą szcze­gól­ny nacisk na interfejsy. 

Interfejsy mogą być zorien­to­wa­ne na pro­ce­du­ry (takie jak zdal­ne wywo­ła­nia funk­cji) lub na doku­men­ty (ser­wi­sy inter­ne­to­we i inte­gra­cje z pro­to­ko­łem RESTful API). Autor opi­su­je tak­że wzor­ce i meto­dy pro­jek­to­wa­nia bazu­ją­ce na luź­nych powią­za­niach, któ­re są klu­czo­we dla budo­wa­nia sys­te­mów roz­pro­szo­nych. Więcej o inter­fej­sach zorien­to­wa­nych na doku­men­ty w moich pro­jek­tach,

Ważna rzecz, na któ­rą autor tak­że zwra­ca szcze­gól­ną uwa­gę: dzie­dzi­cze­nie jest czę­sto trud­ną do osią­gnię­cia tech­ni­ką, jest to tak­że czę­sto jed­na z naj­bar­dziej nad­uży­wa­nych cech języ­ków obiek­to­wych. Nacisk auto­ra na inter­fej­sy może wyda­wać się nie­co eks­tre­mal­ny, jed­nak (świe­że w 2006 roku) spoj­rze­nie na pro­jek­to­wa­nie archi­tek­tu­ry zorien­to­wa­ne na kom­po­nen­ty i ich odpo­wie­dzial­ność, daje zaska­ku­ją­co dobre efek­ty, a pamię­taj­my, że gene­ral­nie liczy się cykl życia apli­ka­cji czy­li kosz­ty jej utrzy­ma­nia i roz­wo­ju, a nie samo jej wytwo­rze­nie. Warto pamię­tać, że dzie­dzi­cze­nie z zasa­dy łamie zasa­dę her­me­ty­za­cji i jest zastę­po­wa­nie sto­so­wa­niem sza­blo­nów lub po pro­stu rezy­gnu­je się z tej tech­ni­ki na rzecz agregatów. 

Podsumowując: Kluczowym prze­sła­niem auto­ra jest odej­ście” od pro­gra­mo­wa­nia obiek­to­we­go” (orien­ta­cja kodu na dzie­dzi­cze­nie oraz łącze­nie funk­cji i danych w obiek­ty, OOP) na rzecz pro­jek­to­wa­nia zorien­to­wa­ne­go na nie­za­leż­ne, luź­no powią­za­ne kom­po­nen­ty” (poli­mor­fizm i her­me­ty­za­cja), cechu­ją­ce­go się peł­ną sepa­ra­cją kom­po­nen­tów, luź­ny­mi powią­za­nia­mi (tyl­ko wywo­ła­nia ope­ra­cji) i poje­dyn­czą odpo­wie­dzial­no­ścią (OOAD). Autor zwra­ca uwa­gę na spraw­dzo­ne wzor­ce, klu­czo­we: to fabry­ka (zwa­na tak­że meto­dą wytwór­czą, jest to sepa­ra­cja metod two­rze­nia obiek­tów od ich utrwa­la­nia), adap­ter (sepa­ra­cja współ­pra­cu­ją­cych kom­po­nen­tów o nie­do­pa­so­wa­nych inter­fej­sach). Co do zasa­dy też (wzor­ce) sepa­ru­je­my prze­twa­rza­nie danych od ich samych (wzo­rzec repo­zy­to­rium ). Dzisiaj domi­nu­ją­ce są więc mikro ser­wi­sy i mikro apli­ka­cje, nato­miast łącze­nie danych i metod je prze­twa­rza­ją­cych w jed­nej kla­sie to antywzorzec. 

Początek lat 2000 to nie tyl­ko mani­fest Agile, to tak­że już kil­ka lat po nim, nawo­ły­wa­nie sygna­ta­riu­szy Agile do porząd­ku w inży­nie­rii opro­gra­mo­wa­nia . Poza oma­wia­ną tu książ­ką poja­wi­ły się, w tam­tym okre­sie, mię­dzy inny­mi opis budo­wy kom­po­nen­to­wej archi­tek­tu­ry , opis pro­jek­to­wa­nia zorien­to­wa­ne­go na odpo­wie­dzial­ność kom­po­nen­tów .

Autor zwra­ca tak­że szcze­gól­ną uwa­gę na doku­men­to­we mode­le budo­wy inter­fej­sów i inte­gra­cji. Dokumentowe czy­li zorien­to­wa­ne na prze­ka­zy­wa­nie mię­dzy kom­po­nen­ta­mi całych agre­ga­tów danych (zwa­nych doku­men­ta­mi) zamiast wyni­ków dzia­ła­nia poszcze­gól­nych funk­cji. Znakomicie uprasz­cza to archi­tek­tu­rę, powo­du­je mniej­sze uza­leż­nie­nia, w kon­se­kwen­cji cykl życia takie­go sys­te­mu jest znacz­nie tań­szy. O tym aspek­cie archi­tek­tu­ry inte­gra­cji pisał tak­że zna­ny autor Martin Fowfer .

Zachęcam do lek­tu­ry tej książ­ki, porząd­ku­je wie­dzę, być może wie­lu z Was znaj­dzie coś nowe­go. Od sie­bie powiem, że podej­ście takie sto­su­ję od cza­sów lek­tu­ry Systemów zorien­to­wa­nych kom­po­nen­to­we Souzy, czy­li od ponad 15 lat… 

Doskonałym i aktu­al­nym uzu­peł­nie­niem tej książ­ki jest napi­sa­na póź­niej Czysta archi­tek­tu­ra :

Dobrzy archi­tek­ci ostroż­nie oddzie­la­ją szcze­gó­ły od reguł biz­ne­so­wych, robiąc to tak dokład­nie, że regu­ły te nie mają żad­nej wie­dzy o szcze­gó­łach i w żaden spo­sób od nich nie zale­żą. Dobrzy archi­tek­ci tak pro­jek­tu­ją regu­ły sys­te­mu, żeby wszyst­kie decy­zje doty­czą­ce szcze­gó­łów moż­na było podej­mo­wać tak póź­no, jak to tyl­ko możliwe.

Źródła

Ambler, S. W. (2004). The object pri­mer. Agile Model-Driven Development with UML 2.0 (Third Edition). Cambridge University Press. Cite
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116. Cite
Evans, E. (2003). Domain-Driven Design. Pearson Education (US). Cite
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley. Cite
Gamma, E. (Ed.). (1995). Design pat­terns: ele­ments of reu­sa­ble object-orien­ted softwa­re. Addison-Wesley. Cite
Martin, R. C. (2018). Czysta archi­tek­tu­ra Struktura i design opro­gra­mo­wa­nia Przewodnik dla pro­fe­sjo­na­li­stów (W. Moch, Trans.). Helion SA. Cite
Martin Fowler, & Martin Fowler. (2013). bli­ki: TellDontAsk [Martinfowler​.com]. Martinfowler​.Com. https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​T​e​l​l​D​o​n​t​A​s​k​.​h​tml Cite
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049 Cite
Pugh, K. (2006). Interface-orien­ted design. Pragmatic Bookshelf. Cite
Steimann, F., & Mayer, P. (2005). Patterns of Interface-Based Programming. Journal of Object Technology, 4, 75 – 94. https://​doi​.org/​1​0​.​5​3​8​1​/​j​o​t​.​2​0​0​5​.​4​.​5​.a1 Cite
Wirfs-Brock, R., & McKean, A. (2006). Object Design: Roles, Responsibilities and Collaborations,. 88. Cite

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/

Notacja EPC

Wprowadzenie

Notacja EPC (Event-dri­ven Process Chain) zosta­ła opra­co­wa­na w 1992 roku w ramach pro­jek­tu badaw­czo-roz­wo­jo­we­go z udzia­łem SAP AG na University of Saarland w Niemczech, a jej twór­cą jest dr August-Wilhelm Scheer. Stanowi ona klu­czo­wy ele­ment kon­cep­cji mode­lo­wa­nia SAP R/3 w zakre­sie inży­nie­rii biz­ne­so­wej i dosto­so­wa­nia tego sys­te­mu do potrzeb klien­ta, zosta­ła włą­czo­na tak­że do sys­te­mu NetWeaver fir­my SAP. 

Ostatni duży pro­jekt z jej uży­ciem reali­zo­wa­łem w 2008 roku dla pol­skie­go oddzia­łu nie­miec­kie­go ban­ku WestLB Bank Polska SA. Później już jedy­nie oka­zjo­nal­ne wspar­cie mery­to­rycz­ne i audy­ty, nadal się zdarzają. 

EPC to nota­cja mode­lo­wa­nia wspie­ra­na przez narzę­dzie ARIS Process Platform, któ­re zapew­nia zin­te­gro­wa­ny zestaw narzę­dzi do pro­jek­to­wa­nia, wdra­ża­nia i kon­tro­lo­wa­nia pro­ce­sów biz­ne­so­wych. EPC opie­ra się na kon­cep­cjach sie­ci sto­cha­stycz­nych i sie­ci Petriego, jed­nak sto­so­wa­nie nota­cji EPC nie wyma­ga zbyt­nie­go for­ma­li­zmu, nota­cja ta nie roz­róż­nia np. poję­cia pro­duk­tu aktyw­no­ści i ele­men­tu ste­ro­wa­nia prze­pły­wem pro­ce­su, ponie­waż wystę­pu­ją one jako skon­so­li­do­wa­ne Zdarzenie. .

Moim zda­niem jest to nie­ste­ty powód, dla któ­re­go nota­cja ta nie pozwa­la na poka­za­nie np. tego, że pro­duk­tem danej pra­cy (aktyw­ność) jest fak­tu­ra a ele­men­tem ste­ru­ją­cym pro­ce­sem jest jej war­tość brut­to. Wady tej nie ma opra­co­wa­na póź­niej, otwar­ta nota­cja BPMN, gdzie ope­ru­je­my i poję­ciem obiek­tu danych i poję­ciem zda­rze­nia, fak­tu, lub warunku.

Notacja EPC nie nakła­da tak­że sztyw­nych ogra­ni­czeń syn­tak­tycz­nych, poza gene­ral­ną zasa­dą, że na linii ste­ro­wa­nia pro­ce­sem funk­cje muszą wystę­po­wać naprze­mien­nie ze zda­rze­nia­mi. W efek­cie wali­da­cja dia­gra­mów zawie­ra­ją­cych takie dodat­ko­we ele­men­ty jak: role, komór­ki orga­ni­za­cyj­ne, sys­te­my i infor­ma­cje, jest czę­sto uznaniowa.

Notacja EPC jest nadal spo­ty­ka­na w pro­jek­tach, w któ­rych sto­so­wa­ne są sys­tem SAP ERP i narzę­dzie ARIS Toolset (ofe­ru­je ono obec­nie tak­że moż­li­wość korzy­sta­nia z innych nota­cji, mie­dzy inny­mi BPMN i UML). Notację EPC moż­na też nadal spo­tkać na nie­któ­rych uczel­niach, opro­gra­mo­wa­nie ARIS jest nadal dostęp­ne na ryn­ku. Notacja EPC to war­tość inte­lek­tu­al­na nadal chro­nio­na jako wła­sność fir­my IDS Scheer.

Semantyka i syntaktyka eEPC

Legenda sym­bo­li nota­cji EPC (eEPC)

Notacja EPC pier­wot­nie zawie­ra­ła tyl­ko ele­men­ty prze­pły­wu (bram­ki logicz­ne, funk­cje i zda­rze­nia) oraz sztyw­ną syn­tak­ty­kę (obli­ga­to­ryj­ną prze­mien­ność funk­cji i zda­rzeń na linii prze­pły­wu ste­ro­wa­nia i zda­rze­nie jako począ­tek i koniec pro­ce­su). Szybko zosta­ła wzbo­ga­co­na o sym­bo­le pozwa­la­ją­ce na mode­lo­wa­nie ele­men­tów orga­ni­za­cji (sys­te­my, infor­ma­cje, role, komór­ki orga­ni­za­cyj­ne). Dlatego obec­nie moż­na spo­tkać tak­że skrót eEPC (exten­ded EPC).

Przepływ ste­ro­wa­nia jest mode­lo­wa­ny jako linia kre­sko­wa skie­ro­wa­na, przy­po­rząd­ko­wa­nie funk­cji jako zada­nia komór­ki orga­ni­za­cyj­nej (linia cią­gła nie­skie­ro­wa­na) oraz prze­pływ infor­ma­cji (linia cią­gła skie­ro­wa­na). Symbol Ścieżka Procesu to wska­za­nie (link) na kolej­ny dia­gram sta­no­wią­cy kon­ty­nu­ację pro­ce­su. Można tą meto­dą agre­go­wać dia­gram do sym­bo­lu na dia­gra­mie nad­rzęd­nym, zacho­wu­jąc jed­nak zasa­dę prze­mien­no­ści funk­cji i zda­rzeń (sym­bol Ścieżka Procesu na dia­gra­mie ma wte­dy taką samą syn­tak­ty­kę jak funk­cja na dia­gra­mie pod­rzęd­nym). Symbol Ścieżka Procesu bywa uży­wa­ny tak­że jako przeniesienie/kontynuacja pro­ce­su na kolej­nym dia­gra­mie, wte­dy jest uzna­wa­ny za zda­rze­nie (dla­te­go iko­na ta, to wła­śnie zło­że­nie funk­cji i zda­rze­nia). Poniżej opi­sa­ne sym­bo­le na przy­kła­do­wym dia­gra­mie pro­ce­su (frag­ment diagramu):

Syntaktyka eEPC (opr. własne)

Notacja pozwa­la na dość pre­cy­zyj­ne mode­lo­wa­nie pro­ce­sów biz­ne­so­wych co jed­nak wyma­ga pew­nej dys­cy­pli­ny. Notacja eEPC nie ma sfor­ma­li­zo­wa­nej spe­cy­fi­ka­cji, nale­ży korzy­stać z opra­co­wań fir­mo­wa­nych przez auto­ra (AW. Scheer), któ­ry podej­mu­je pró­by porząd­ko­wa­nia seman­ty­ki i syn­tak­ty­ki :

Każdy model EPC musi od same­go począt­ku prze­strze­gać pew­nych pro­stych zasad pro­jek­to­wa­nia, aby unik­nąć lub ogra­ni­czyć nie­po­żą­da­ne zacho­wa­nia, takie jak np. mar­twe punk­ty. Dlatego nie pro­po­nu­je się rygo­ry­stycz­ne­go i zło­żo­ne­go sys­te­mu reguł i wzor­ców pro­jek­to­wych, ponie­waż uni­ka­nie wszyst­kich moż­li­wych kon­flik­tów zbyt­nio ogra­ni­cza­ło­by użyt­kow­ni­ka. Reguły te są następujące:

  1. Trzema pod­sta­wo­wy­mi węzła­mi w mode­lach EPC są aktyw­no­ści (funk­cje), zda­rze­nia i łącz­ni­ki [bram­ki logiczne].
  2. Nazwa zda­rze­nia powin­na odzwier­cie­dlać jego cha­rak­te­ry­sty­kę jako punk­tu w cza­sie, na przy­kład: ele­ment ukoń­czo­ny”. Jest ono repre­zen­to­wa­ne przez sześciokąt.
  3. Nazwa aktyw­no­ści powin­na uwzględ­niać kon­sump­cje cza­su, na przy­kład: pro­du­ko­wa­nie przed­mio­tu”. Czynność jest przed­sta­wio­na w posta­ci pro­sto­ką­ta o zaokrą­glo­nych rogach.
  4. Łączniki [bram­ki logicz­ne] są repre­zen­to­wa­ne przez okrąg. Wewnątrz okrę­gu typ łącz­ni­ka [logi­ka OR, XOR, AND] jest okre­ślo­ny za pomo­cą odpo­wied­nie­go sym­bo­lu. Łącznik może być podzie­lo­ny na część gór­ną i dol­ną, by odzwier­cie­dlić róż­ni­ce mię­dzy regu­ła­mi połą­czeń przy­cho­dzą­cych i wycho­dzą­cych [lub łączy­my kaska­do­wo pro­ste poje­dyn­cze bramki].
  5. Aby jasno okre­ślić, kie­dy pro­ces biz­ne­so­wy ma się roz­po­cząć i jaki jest jego wynik koń­co­wy, każ­dy dia­gram EPC roz­po­czy­na się i koń­czy jed­nym lub kil­ko­ma zdarzeniami.
  6. Diagram EPC zawie­ra co naj­mniej jed­ną czynność.
  7. Model EPC może skła­dać się z kil­ku dia­gra­mów EPC.
  8. Krawędzie [linie prze­pły­wu ste­ro­wa­nia] są skie­ro­wa­ne i zawsze łączą dwa ele­men­ty odpo­wia­da­ją­ce sekwen­cji aktywacji.
  9. Zdarzenie nie może być poprzed­ni­kiem ani następ­ni­kiem inne­go zdarzenia.
  10. Czynność nie może być poprzed­ni­kiem ani następ­ni­kiem innej czynności.
  11. Każde zda­rze­nie i każ­da czyn­ność mają tyl­ko jed­ną kra­wędź [linia prze­pły­wu ste­ro­wa­nia] przy­cho­dzą­cą i/lub jed­ną kra­wędź wychodzącą.”

Przykłady modeli

Poniżej przy­kła­do­wy model pro­ce­su reje­stra­cji fak­tur kosztowych. 

Proces księ­go­wa­nia fak­tur kosz­to­wych (opr. własne)

Używanie ele­men­tów roz­sze­rza­ją­cych nie jest obli­ga­to­ryj­ne, dla­te­go wystę­pu­ją na dia­gra­mach tam gdzie autor mode­lu uzna, że chce je zobra­zo­wać. Notacja eEPC nie ope­ru­je poję­ciem sta­tu­su więc fak­tu­ra zaak­cep­to­wa­na i zaksię­go­wa­na to dwa osob­ne ele­men­ty infor­ma­cyj­ne. Powyższy model pro­ce­su Księgowania fak­tur kosz­to­wych może być pod­pro­ce­sem w pro­ce­sie Obsługi płatności:

Proces biz­ne­so­wy nad­rzęd­ny Obsługa płat­no­ści: tu sym­bol Ścieżka Procesu peł­ni rolę funk­cji dekom­po­no­wa­nej (opr. własne) 

Symboli eEPC moż­na for­mal­nie użyć w innym kon­tek­ście, np. budu­jąc dodat­ko­wy model struk­tu­ry organizacyjnej;

Struktura orga­ni­za­cyj­na wyra­żo­na z uży­ciem nota­cji eEPC (opr. autora)

Autor nota­cji pro­po­nu­je wie­le form sto­so­wa­nia swo­jej nota­cji, łącz­nie z warian­ta­mi nie­uwzględ­nia­ją­cy­mi zasa­dy prze­mien­no­ści funk­cja-zda­rze­nie” (łamiąc wła­sne zasa­dy), co poka­zu­je dość swo­bod­ne podej­ście twór­cy nota­cji do mode­lo­wa­nia, jak np. na poniż­szym diagramie:

Podsumowanie

Notacja eEPC i meto­da ARIS zdo­by­ły sobie szyb­ko dużą popu­lar­ność w obsza­rze ana­liz i wdro­żeń sys­te­mów ERP, za spra­wą związ­ków fir­my IDS Scheer z fir­mą SAP AG. Jednak po ok. 10 latach ist­nie­nia EPC oka­za­ło się, że jej nie­do­stat­ki for­ma­li­za­cyj­ne powo­do­wa­ły dość niską jakość mode­li za spra­wą ich nie­jed­no­znacz­no­ści (ww. brak formalizmu). 

W odpo­wie­dzi na powyż­sze powsta­ła znacz­nie lepiej dopra­co­wa­na nota­cja BPMN. Notacja BPMN zosta­ła pier­wot­nie opra­co­wa­ny przez orga­ni­za­cję Business Process Management Initiative (BPMI). Wersja 1.0 zosta­ła udo­stęp­nio­na publicz­nie w maju 2004 roku. W czerw­cu 2005 r. BPMI połą­czy­ło się z OMG (Object Management Group). Formalna spe­cy­fi­ka­cja BPMN zosta­ła wyda­na przez OMG w lutym 2006 roku (https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/). Co cie­ka­we, w pra­cach nad BPMN bra­ły udział, mię­dzy inny­mi, fir­my IDS Scheer, Software AG i SAP AG.

Moim zda­niem roz­po­czy­na­nie pro­jek­tów z jej uży­ciem w obec­nych cza­sach ma uza­sad­nie­nie tyl­ko tam, gdzie wie­le zain­we­sto­wa­no w zaso­by i gro­ma­dzo­no kom­pe­ten­cje wokół narzę­dzi ARIS. Co jed­nak nie zmia­nia fak­tu, że pozo­sta­wa­nie w tej niszy rodzi poważ­ne ryzy­ko budo­wa­nia dłu­gu tech­no­lo­gicz­ne­go i tak zwa­ne­go ven­dor lock-in. 

Repozytoria ARIS budo­wa­ne są w mode­lu rela­cyj­nym a struk­tu­ra bazy jest obję­ta tajem­ni­cą pro­du­cen­ta, do tego nie ma spe­cy­fi­ka­cji XMI dla eEPC (XML Metadata Interchange) więc migra­cja mode­li do innych narzę­dzi jest prak­tycz­nie nie­moż­li­wa (moż­na je prze­ry­so­wać” w nowym narzę­dziu). Do tego wer­sje same­go ARIS’a bywa­ją nie­kom­pa­ty­bil­ne mię­dzy sobą (prze­cho­dze­nie na now­szą wer­sję wyma­ga­ło już w histo­rii sto­so­wa­nia skom­pli­ko­wa­nych pro­ce­dur). Nadal, od cza­su do cza­su podej­mo­wa­ne są pró­by napra­wy tej sytuacji: 

Mimo tego, że w ostat­nich deka­dach do mode­lo­wa­nia pro­ce­sów powszech­nie sto­su­je się język EPC, brak ofi­cjal­ne­go stan­dar­du pro­wa­dzi do coraz częst­sze­go jego pomi­ja­nia. Spójny meta­mo­del jest pod­sta­wą do okre­śle­nia języ­ków mode­lo­wa­nia pro­ce­sów. W związ­ku z tym, niniej­sza pra­ca budu­je pod­sta­wy dla dal­szej stan­da­ry­za­cji poprzez dostar­cze­nie zin­te­gro­wa­ne­go meta­mo­de­lu dla EPC. Uzyskany w ten spo­sób meta­mo­del wspie­ra oży­wie­nie EPC poprzez uła­twie­nie przy­szłych wysił­ków standaryzacyjnych.

Narzędzie ARIS to obec­nie roz­bu­do­wa­ny pakiet CASE, nadal obec­ny na ryn­ku, mię­dzy inny­mi jako kon­ty­nu­acja wie­lu pro­jek­tów zapo­cząt­ko­wa­nych przed powsta­niem nota­cji BPMN (z pomo­cą tego narzę­dzia powsta­ło wie­le doku­men­ta­cji pro­jek­to­wych, nadal utrzy­my­wa­nych). Jednak, z uwa­gi na to, że nota­cja BPMN, jako znacz­nie lepiej dopra­co­wa­na i funk­cjo­nu­ją­ca jako otwar­ty stan­dard public doma­in, sta­ła się szyb­ko stan­dar­dem de fac­to, eEPC to obec­nie mała nisza i chy­ba już nic tego nie zmieni. 

Notacja EPC jest dostęp­na nie tyl­ko w narzę­dziu ARIS, powyż­sze dia­gra­my powsta­ły z uży­ciem Visual Paradigm, udo­stęp­nia­ją­cym tak­że (nie­stan­dar­do­wą) moż­li­wość ich expor­tu do for­ma­tu XMI. Możliwe jest tu tak­że auto­ma­tycz­ne wyge­ne­ro­wa­nie dia­gra­mów BPMN z dia­gra­mów EPC.

Notacja eEPC, obok BPMN i UML, nadal jest przed­mio­tem naucza­nia na nie­któ­rych uczel­niach w Polsce. 

Źródła

Jannaber, S., Karhof, A., Riehle, D. M., Thomas, O., Delfmann, P., & Becker, J. (2016). Invigorating Event-dri­ven Process Chains – Towards an inte­gra­ted meta model for EPC stan­dar­di­za­tion. 10.
Scheer, A.-W., & Emminghaus, F. (1994). ARIS-tool­set. IDS Prof. Scheer.
Scheer, A.-W., Thomas, O., & Adam, O. (2005). Process Modeling Using Event-Driven Process Chains.
Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. [Abstrakcja skupia się na istotnych cechach jakiegoś obiektu w odniesieniu do perspektywy widza.]

Wymagania biznesowe – jak zbierać i dokumentować

Wprowadzenie

Ronald Ross, współ­au­tor stan­dar­du mode­lo­wa­nia reguł biz­ne­so­wych i biz­ne­so­we­go słow­ni­ka pojęć napi­sał nie­daw­no na swo­im pro­fi­lu LinkedIn:

People love sto­ries. Are user sto­ries help­ful in engi­ne­ering busi­ness solu­tions? Absolutely. Are you done with requ­ire­ments and solu­tion engi­ne­ering when you’ve wor­ked thro­ugh a set of user sto­ries? No. Not even clo­se!” [„Ludzie kocha­ją histo­rie. Czy histo­rie użyt­kow­ni­ków są pomoc­ne w two­rze­niu roz­wią­zań biz­ne­so­wych? Zdecydowanie tak. Czy skoń­czy­łeś z wyma­ga­nia­mi i inży­nie­rią roz­wią­za­nia, gdy już opra­co­wa­łeś zestaw histo­ry­jek użyt­kow­ni­ka? Nie. Nawet nie zbli­ży­łeś się do nich!”.]

(https://​www​.lin​ke​din​.com/​p​o​s​t​s​/​r​o​s​s​r​o​n​a​l​d​_​p​e​o​p​l​e​-​l​o​v​e​-​s​t​o​r​i​e​s​-​a​r​e​-​u​s​e​r​-​s​t​o​r​i​e​s​-​h​e​l​p​f​u​l​-​a​c​t​i​v​i​t​y​-​6​9​3​5​6​2​7​0​0​8​2​6​5​6​3​3​7​9​3​-​B​p​zb/)

Świat od dekad bory­ka się z jako­ścią i sku­tecz­no­ścią spe­cy­fi­ko­wa­nia wyma­gań na opro­gra­mo­wa­nie. OMG​.org opu­bli­ko­wa­ło stan­dard o nazwie MDA (ang. Model Driven Architecture ), któ­ry tak opi­su­je pro­ces two­rze­nia oprogramowania:

CIM -> PIM -> PSM

Są to odpo­wied­nio mode­le: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu dzia­ła­nia (PIM: Platform-Independent Model, jest to model dzie­dzi­ny sys­te­mu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego cza­su sze­rzej opi­sa­łem zależ­no­ści mię­dzy tymi mode­la­mi (czy­taj wię­cej o MDA).

CIM to model dzia­ła­nia orga­ni­za­cji: pro­ce­sy biz­ne­so­we i ich pro­duk­ty. Z uwa­gi na to, że obec­nie już nie rodzą się pro­jek­ty jed­no­ra­zo­wej infor­ma­ty­za­cji cało­ści orga­ni­za­cji, poja­wia się potrze­ba okre­śle­nia zakre­su pro­jek­tu, bo nie jest już nim cała orga­ni­za­cja. Model PIM to udo­ku­men­to­wa­ny mecha­nizm dzia­ła­nia sys­te­mu (opro­gra­mo­wa­nia), logi­ka jego dzia­ła­nia. Nie ma tu mowy o tym w jakiej tech­no­lo­gii powsta­nie, bo z zasa­dy mamy ich wie­le do wybo­ru, a wybór tech­no­lo­gii zale­ży od wie­lu poza-funk­cjo­nal­nych ogra­ni­czeń i wyma­gań. Technologia jest (powin­na być) kon­se­kwen­cją wybo­ru wyko­naw­cy i ten dopie­ro opra­cu­je model PSM, któ­ry w prak­ty­ce jest tak zwa­ną Koncepcją Wdrożenia, moż­na ją tak­że udo­ku­men­to­wać w nota­cji UML, ale na tym eta­pie powszech­na prak­ty­ką jest jedy­nie zapro­jek­to­wa­nie śro­do­wi­ska, zesta­wie­nie go i pra­ca od razu w kodzie.

Kluczowym pro­ble­mem jest przej­ście z CIM na PIM, czy­li jak udo­ku­men­to­wać zakres pro­jek­tu dostar­cze­nia opro­gra­mo­wa­nia i prze­kształ­cić go na wyma­ga­nia wobec tego oprogramowania?

CIM -> [zakres pro­jek­tu] -> PIM -> PSM

W meto­dach zwa­nych zwin­ny­mi, mode­le CIM i PIM są pomi­ja­ne. Typowym zaś narzę­dziem zbie­ra­nia wyma­gań” są tak zwa­ne histo­ryj­ki użyt­kow­ni­ka (user sto­ry). Problem w tym, że są one klu­czo­wym ryzy­kiem pro­jek­tów gdyż z regu­ły są nie­spój­ne i nie­kom­plet­ne jako wyma­ga­nia. Specyfikacja wyma­gań powin­na być: spój­na, kom­plet­na i nie­sprzecz­na. Opisanie zakre­su pro­jek­tu histo­ryj­ka­mi użyt­kow­ni­ka, nie mając mode­lu pro­ce­sów biz­ne­so­wych cało­ści (model CIM), jest pozba­wie­niem się narzę­dzia do wery­fi­ka­cji kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści takiej spe­cy­fi­ka­cji. Wszystkie wady (nie­kom­plet­ność, nie­spój­ność, sprzecz­no­ści) odkry­wa­ne są i usu­wa­ne (uzu­peł­nia­ne) dopie­ro na eta­pie wdra­ża­nia. Jest to pro­ces odkry­wa­nia wyma­gań w toku wdrożenia”. 

Historyjki użyt­kow­ni­ka jako lista potrzeb biz­ne­so­wych? Owszem! Historyjki użyt­kow­ni­ka jako wyma­ga­nia dla deve­lo­pe­ra? NIE! To tyl­ko mate­riał dla pro­jek­tan­ta, ponie­waż bar­dzo czę­sto jed­na i ta sama funk­cja sys­te­mu reali­zu­je wie­le róż­nych histo­rii użyt­kow­ni­ka. Implementacja per user sto­ry” pro­wa­dzi do bar­dzo kosz­tow­nych i nie­efek­tyw­nych roz­wią­zań (Opisywałem to na blo­gu: wpis pro­jekt Biblioteka, dwie histo­ryj­ki użyt­kow­ni­ka: chciał­bym wypo­ży­czyć książ­kę oraz chciał­bym zwró­cić książ­kę są reali­zo­wa­ne jed­ną usłu­gą apli­ka­cji: Karta Wypożyczenia, któ­ra zawie­ra rów­nież pole Data zwro­tu. Nadal spo­ty­kam pro­gra­mi­stów prze­ko­nu­ją­cych, że powin­ny to być dwa osob­ne ekra­ny – dwa przy­pad­ki uży­cia, czy­taj dwa razy wię­cej pra­cy kode­ra i dwa razy więk­szy koszt).

Czy można sformalizować proces zbierania historyjek użytkownika?

User Story to jed­no z naj­bar­dziej pro­ble­ma­tycz­nych narzę­dzi w meto­dach zwin­nych. Najczęściej zale­ca­na struk­tu­ra tych histo­ry­jek”, wraz z przykładami:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Na przy­kład:

Jako Administrator chcę otrzy­my­wać wia­do­mość e‑mail, gdy zosta­nie prze­sła­ny for­mu­larz kon­tak­to­wy, abym mógł na nie­go odpowiedzieć”

albo

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”;

Tak spi­sy­wa­ne wyma­ga­nia sta­no­wią ogrom­ny pro­blem z powo­du nie­rów­nej gra­da­cji, spro­wa­dza­nie ich do pozio­mu tak zwa­nych ato­mo­wych user sto­ry (dru­gi z powyż­szych przy­kła­dów) pro­wa­dzi do bar­dzo dużych liczb tych histo­ry­jek. Próba ich wery­fi­ka­cji (wali­da­cja user sto­ry) sta­je się co naj­mniej trud­nym zada­niem. Jakakolwiek wyce­na opro­gra­mo­wa­nia na bazie takich histo­ry­jek to wró­że­nie z fusów (więc deve­lo­pe­rzy moc­no zawy­ża­ją wyce­ny z uwa­gi na ryzy­ko utra­ty ren­tow­no­ści). Autorzy inne­go opra­co­wa­nia zauważają:

Rzeczywiście, przy oko­ło 800 US [User Story], hie­rar­chia była raczej trud­na do okre­śle­nia, a obraz sys­te­mu pod­czas pla­no­wa­nia był bar­dzo duży. Skalowalność jest więc zde­cy­do­wa­nie pro­ble­mem w pro­jek­tach zwin­nych, w któ­rych US są sła­by­mi arte­fak­ta­mi inży­nie­rii wyma­gań. Zdecydował się on [autor] na wpro­wa­dze­nie wzor­ca US: Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zde­fi­nio­wać hie­rar­chię w posta­ci Celu, Zadania i Użytkownika, ale bez powią­za­nia semantycznego.

Znam pro­jekt, w któ­rym licz­ba przy­pad­ków uży­cia, w pew­nym śred­niej tyl­ko wiel­ko­ści pro­jek­cie, szyb­ko się­gnę­ła czte­ry­stu. Wycena na ich pod­sta­wie poka­za­ła, że pla­no­wa­ny koszt wie­lo­krot­nie prze­kra­cza pla­no­wa­ny budżet. Ten pro­jekt zarzu­co­no, jed­nak wie­le tak wyce­nio­nych pro­jek­tów jest reali­zo­wa­nych, co daje obraz ska­li strat jakie przy­no­szą (zawy­żo­ny koszt to stra­ta). Powyżsi auto­rzy piszą na zakończenie:

Przyszłe pra­ce obej­mu­ją iden­ty­fi­ka­cję luk repre­zen­ta­cyj­nych, któ­re napo­ty­ka­ją prak­ty­cy w mode­lo­wa­niu US, oraz prze­gląd spo­so­bów, w jakie nasze ramy i [meto­da] GORE w ogó­le mogły­by roz­wią­zać te pro­ble­my. Równolegle oce­nia­na będzie rów­nież zdol­ność prak­ty­ków do sto­so­wa­nia pro­po­no­wa­nych ram zamiast zwy­kłych sza­blo­nów. Obecnie trwa­ją pra­ce nad narzę­dziem CASE (Computer Aided Software Engineering), któ­re zosta­nie wyko­rzy­sta­ne do wspar­cia eksperymentów.

Nie zna­la­złem wyni­ków dal­szych prac, więc podzie­lę się wyni­ka­mi swoich.

Gradacja User Story

Podstawowym pro­ble­mem z user sto­ry jest, moim zda­niem, brak stan­dar­du pozwa­la­ją­ce­go na zde­fi­nio­wa­nie ato­mo­wej histo­ryj­ki użyt­kow­ni­ka” czy­li pozio­mu, poni­żej któ­re­go nie dzie­li­my ich na mniej­sze. Jako audy­tor wie­lu doku­men­ta­cji (czę­sto w roli bie­głe­go) zauwa­ży­łem, że histo­ryj­ki użyt­kow­ni­ka są dopro­wa­dza­ne do pozio­mu poje­dyn­czych kro­ków sce­na­riu­szy przy­pad­ków uży­cia. Często też histo­ryj­ki użyt­kow­ni­ka utoż­sa­mia­ne są z przy­pad­ka­mi uży­cia (UML) i tak mode­lo­wa­ne, co jest poważ­nym błę­dem. Np. powyższe: 

Jako użyt­kow­nik mam moż­li­wość klik­nię­cia okre­ślo­nej loka­li­za­cji na mapie”

Mogło by to być czę­ścią sce­na­riu­sza usłu­gi (przy­pa­dek uży­cia UML), któ­rej celem jest Pokazanie Określonego Miejsca:

  1. AKTOR ini­cju­je usłu­gę Cel podróży
  2. SYSTEM wyświe­tla for­mu­larz Adres
  3. AKTOR wpro­wa­dza dane i naci­ska OK
  4. SYSTEM wyświe­tla mapę z nanie­sio­ną lokalizacją
  5. AKTOR kli­ka okre­ślo­ny punkt na mapie 
  6. SYSTEM powięk­sza obraz poka­zu­jąc deta­le lokalizacji

Powyższa histo­ryj­ka to jedy­nie punkt 5. tego sce­na­riu­sza. Nie trud­no dojść do wnio­sku, że samo klik­nię­cie na mapie to pozba­wio­na kon­tek­stu i celu, wyrwa­na pro­sta czyn­ność, i jej samo­dziel­ne ist­nie­nie w spe­cy­fi­ka­cji jako osob­ny byt, pozba­wio­ne jest sen­su. Z per­spek­ty­wy opro­gra­mo­wa­nia powsta­ją­ce­go w okre­ślo­nym celu, uzna­nie tej histo­ryj­ki za samo­dziel­ne wyma­ga­nie nie ma uza­sad­nie­nia. Uznanie jed­nak, że apli­ka­cja słu­ży mię­dzy inny­mi do zapo­zna­wa­nia się okre­ślo­ny­mi miej­sca­mi w prze­strze­ni, a usłu­gą tej apli­ka­cji jest Pokazanie Określonego Miejsca jak naj­bar­dziej ma sens. Idąc za suge­stią by histo­ryj­ka użyt­kow­ni­ka mia­ła strukturę: 

Jako [Użytkownik], chcę [Zadanie], aby [Cel]”

zmu­sza do zasta­no­wie­nia się czy kli­ka­nie na mapie jest celem, czy może jed­nak tym celem jest Pokazanie Określonego Miejsca, a kli­ka­nie jest ele­men­tem sce­na­riu­sza (pro­ce­du­ry) reali­za­cji tego celu (pamię­ta­my, że przy­pad­ki uży­cia mają sce­na­riu­sze, a te zło­żo­ne są z sekwen­cji kolej­nych kroków!).

Formalizacja User Story

Pojęcia Użytkownik, Zadanie, Cel, jako spój­ny zestaw pojęć odpo­wia­da­ją defi­ni­cji ato­mo­we­go (ele­men­tar­ne­go) pro­ce­su w nota­cji BPMN (doda­tek C, Słownik , ): Aktywność jest sko­ja­rzo­na z jej wyko­naw­cą (pula, tor), two­rzy pro­dukt (data object). Biorąc pod uwa­gę fakt, że pro­dukt ma tu okre­ślo­ne­go adre­sa­ta i musi on sta­no­wić sobą war­tość dla tego adre­sa­ta, mamy punkt wyzna­cza­ją­cy gra­ni­cę dzie­le­nia na czę­ści” tych histo­ry­jek. Nie będzie to moż­li­wość wsta­wie­nia z listy nume­ru NIP nabyw­cy” a utwo­rze­nie fak­tu­ry” (bo war­tość ma dopie­ro popraw­nie wysta­wio­na fak­tu­ra, a nie klik­nię­cie np. w pole NIP by wybrać kontrahenta). 

Jak sfor­ma­li­zo­wać histo­ryj­kę użyt­kow­ni­ka? Podstawą for­ma­li­za­cji (i celem) jest opra­co­wa­nie meto­dy kon­tro­li popraw­no­ści (wali­da­cja). Popatrzmy jesz­cze raz na szablon:

Jako 〈typ użyt­kow­ni­ka〉 chcę osią­gnąć 〈cel〉, aby 〈jakiś powód〉”. 

Typ użyt­kow­ni­ka to rola, celem jest pro­dukt pra­cy, a powo­dem? Powodem jest zawsze to, że okre­ślo­na oso­ba ocze­ku­je na efekt tej pra­cy (bez tego pra­ca ta była­by po pro­stu zbęd­na). Można więc wyobra­zić sobie taki zapis:

Jako sprze­daw­ca, chcę wysta­wić fak­tu­rę, klientowi. 

Mamy tu:

  1. rola: sprze­daw­ca
  2. cel: fak­tu­ra
  3. powód: ocze­ku­je tego klient. 

W tym miej­scu widać peł­ną zgod­ność tej defi­ni­cji z kon­struk­cją: aktyw­ność, jej pro­dukt, jego odbior­ca. Innymi sło­wy ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych wyko­na­ny w nota­cji BPMN, to nic inne­go jak połą­czo­ne w logicz­ne cią­gi histo­ryj­ki użytkownika. 

Wyobraźmy sobie taką listę histo­ry­jek użyt­kow­ni­ka, wyko­na­ną wg. powyż­sze­go opisu:

Specyfikacja histo­ry­jek użytkownika

Niektóre narzę­dzia CASE, pozwa­la­ją­ce na ich pro­fi­lo­wa­nie, pozwa­la­ją przed­sta­wić to tak­że na mode­lu wyma­gań (co póź­niej umoż­li­wia śla­do­wa­nie, czy­li kon­tro­lę kom­plet­no­ści, spój­no­ści i niesprzeczności):

Diagram wyma­gań (nota­cja SysML)

Powyższe mogło­by być kon­se­kwen­cją takie­go mode­lu procesów:

Diagram pro­ce­su reali­za­cji zamó­wie­nia (nota­cja BPMN).

Jak widać, model pro­ce­su daje peł­ny kon­tekst dla aktyw­no­ści. Fakt, że pro­ces to logicz­ny prze­pływ pra­cy, powo­du­je, że two­rze­nie mode­li BPMN gwa­ran­tu­je spój­ność, kom­plet­ność i nie­sprzecz­ność listy aktyw­no­ści, ich pro­duk­tów i ról. 

Podsumowanie

Stosowanie typo­wych histo­ry­jek użyt­kow­ni­ka ma dwie klu­czo­we wady: 1. nie ma jed­nej meto­dy zarzą­dza­nia ich gra­da­cją i struk­tu­rą, wie­lu auto­rów przy­wo­łu­je wła­sne, nie­co się róż­nią­ce meto­dy stan­da­ry­za­cji, 2. ich dro­bia­zgo­wość oraz brak meto­dy kon­tro­li spój­no­ści, pro­wa­dzą do szyb­ko rosną­cej ich licz­by, w kon­se­kwen­cji cha­osu, szcze­gól­nie w śred­nich i więk­szych projektach.

Powyżej widać, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie zebra­nych przy­kła­do­wych doku­men­tów (pro­duk­ty pra­cy ludzi: doku­men­ty) i opra­co­wa­nie na ich pod­sta­wie dia­gra­mu przy­pad­ków uży­cia, daje znacz­nie lep­sze wyni­ki niż zbie­ra­ne na warsz­ta­tach histo­ryj­ki użyt­kow­ni­ka. Same wyma­ga­nia wyra­żo­ne jako histo­ryj­ki użyt­kow­ni­ka, nie dają żad­nej szan­sy (brak meto­dy) na kon­tro­lę ich spój­no­ści, kom­plet­no­ści i nie­sprzecz­no­ści. Wymagania, jako kon­se­kwen­cja popraw­nie wyko­na­nych mode­li pro­ce­sów biz­ne­so­wych, z zasa­dy są spój­ne, kom­plet­ne i niesprzeczne.

W przy­to­czo­nym tu przy­kła­dzie widać, że dwie aktyw­no­ści (reje­stra­cja zamó­wie­nia i kon­tro­la jego sta­tu­su) reali­zo­wa­ne są jako dostęp do zapi­sa­ne­go w sys­te­mie Zamówienia. Daje to jasną prze­słan­kę do tego, że dwie histo­ryj­ki użyt­kow­ni­ka (dwie aktyw­no­ści na mode­lu pro­ce­sów) to dwa róż­ne kon­tek­sty uży­cia tej samej usłu­gi apli­ka­cji: Zamówienia (czy­li dostęp do ich two­rze­nia, aktu­ali­za­cji i pod­glą­du, to typo­wy przy­pa­dek uży­cia typu CRUD). Prawa dostę­pu do tego doku­men­tu mode­lu­je się zaś regu­ła­mi biz­ne­so­wy­mi (nie poka­za­no ich na dia­gra­mach), np. Klient ma wgląd tyl­ko w Zamówienia, któ­re sam złożył”. 

Można uznać, że małe pro­jek­ty, o małym ryzy­ku cha­osu wywo­ła­ne­go bra­kiem mode­li pro­ce­sów, moż­na reali­zo­wac na skró­ty” czy­li histo­ryj­ki użyt­kow­ni­ka i od razu model PSM (imple­men­ta­cja) z pomi­nię­ciem CIM i PIM, jed­nak jest to poważ­ne ryzy­ko już przy śred­nich pro­jek­tach. Dlatego pro­ces MDA:

{CIM -> [zakres pro­jek­tu] -> PIM} -> PSM

wyda­je się być znacz­nie efek­tyw­niej­szy co poka­zu­je prak­ty­ka (w nawia­sach klam­ro­wych {} zakres pra­cy analityka-projektanta).

Zakres pro­jek­tu to albo całe pro­ce­sy biz­ne­so­we albo świa­do­mie wybra­ne ich okre­ślo­ne aktyw­no­ści. Nie jest to tak­że żaden wodo­spad” (water­fall), bo ana­li­tycz­ny model pro­ce­sów biz­ne­so­wych powsta­nie szyb­ciej i taniej niż lista setek histo­ry­jek z pomo­cą wie­lo­dnio­wych warsz­ta­tów anga­żu­ją­cych całe zespo­ły ludzi. Wygenerowane z mode­lu pro­ce­sów biz­ne­so­wych przy­pad­ki uży­cia, są z zasa­dy spój­ne i kom­plet­ne, więc ich ite­ra­cyj­ne (kolej­ne) spe­cy­fi­ko­wa­nie (każ­dy pro­jek­tu­je­my jako samo­dziel­ny mikro­ser­wis) pozwa­la bez ryzy­ka odda­wać je kolej­no do imple­men­ta­cji, i jed­no­cze­śnie doku­men­to­wać (uszcze­gó­ła­wiać) kolejne. 

To spraw­dzo­na w prak­ty­ce meto­da wspie­ra­na przez wie­le narzę­dzi CASE (wszyst­kie dia­gra­my i ich prze­kształ­ce­nia poka­za­ne w tym arty­ku­le powsta­ły z uży­ciem Visual-Paradigm). Diagram przy­pad­ków uży­cia UML jest tu auto­ma­tycz­nie gene­ro­wa­ny z mode­li BPMN, wg poniż­szych zasad:

BPMNtoUseCase (źr. http://​www​.visu​al​-para​digm​.com/​t​u​t​o​r​i​a​l​s​/​f​r​o​m​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​t​o​-​u​s​e​-​c​a​s​e​s​.​jsp)

Po tej ope­ra­cji wystar­czy spraw­dzić kon­tek­sty doku­men­tow i skon­so­li­do­wać w jeden ewen­tu­al­ne nad­mia­ro­we przy­pad­ki uży­cia. I na koniec:

Jeśli nie masz mode­li poję­cio­wych, bra­ku­je Ci waż­ne­go ele­men­tu ukła­dan­ki w pro­jek­to­wa­niu roz­wią­zań, któ­ry jest nie­zwy­kle pomoc­ny w dostrze­ga­niu i prze­ka­zy­wa­niu ogól­ne­go obra­zu tych historyjek.”

Ronald Ross (Business Rules)

Źródła

Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agi­le requ­ire­ments: the Quality User Story fra­me­work and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
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.
Ross, R. G., & Fisher, L. (2020). Business Rules: Management and Execution.
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 07881-6_15
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699

Pełna Specyfikacja

Poniżej przy­kła­do­wy doku­ment wyge­ne­ro­wa­ny bez­po­śred­nio z Visual Paradigm, zawie­ra tak­że śladowanie. 

1. Procesy Business Process Diagram

Procesy Business Process Diagram

2. User Story

Historyjki użyt­kow­ni­ka jako wyma­ga­nia biznesowe.

ID

Nazwa

Rola

Produkt

Adresat

Opis

REQ001

Sprzedaż

Sprzedawca

Faktura

Klient

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

REQ002

Wydanie towa­ru

Magazynier

Dokument WZ

Klient

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

REQ003

Rejestracja Zamówień

Pracownik BOK

Zamówienie zaku­pu

Sprzedawca

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

REQ004

Śledzenie Zamówień

Klient

Zamówienie zaku­pu

Klient

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

3. Diagram Przypadków Użycia

Diagram Przypadków Użycia

4. Specyfikacja

 

Nazwa

ID

 

Główni akto­rzy 

Pula zadań

!!

Sprzedaż

UC02

Sprzedawca

Magazyny

UC03

Magazynier

Zamówienia

UC01

Klient, Pracownik BOK

4.1. Sprzedaż

ID: UC02

Usługa pozwa­la wysta­wiać faktury.

4.1.1. Główni aktorzy 

Sprzedawca

4.1.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Sprzedaż będzie doku­men­to­wa­na fak­tu­ra­mi w reje­strze sprzedaży

4.1.3. Wymagania 

4.1.3.1. Sprzedaż

ID: REQ001

jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi

4.1.4. Relacje

Relacja

Z

Do

unnamed

Sprzedawca

Sprzedaż

4.1.5. Diagramy Podległe 

4.1.5.1. Faktura

Faktura

4.1.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Sprzedaż

4.2. Magazyny

ID: UC03

Usługa doku­men­tu­je wyda­wa­nie towa­ru na pod­sta­wie opła­co­nych faktur.

4.2.1. Główni aktorzy 

Magazynier

4.2.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Operacje maga­zy­no­we doku­men­to­wa­ne są stan­dar­do­wy­mi doku­men­ta­mi księgowymi

4.2.3. Wymagania 

4.2.3.1. Wydanie towaru

ID: REQ002

jako maga­zy­nier chce wysta­wić Dokument WZ klientowi

4.2.4. Relacje

Relacja

Z

Do

unnamed

Magazynier

Magazyny

4.2.5. Diagramy Podległe 

4.2.5.1. Dokument WZ

Dokument WZ

4.2.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Wydanie z magazynu

4.3. Zamówienia

ID: UC01

Rejestr zamó­wień pozwa­la reje­stro­wać zamó­wie­nia, śle­dzić ich status.

4.3.1. Główni aktorzy 

Klient,  Pracownik BOK

4.3.2. Szczegóły

Complexity

śred­nia

Use Case Status

tyl­ko nazwa

Implementation Status

zapla­no­wa­na

Author

Jarosław Żeliński

Assumptions

Zamówienia od klien­tów są reje­stro­wa­ne jako Zamówienia zaku­pu w Rejestrze zamówień

4.3.3. Wymagania 

4.3.3.1. Rejestracja Zamówień

ID: REQ003

jako pra­cow­nik BOK chce zare­je­stro­wać zamó­wie­nie zaku­pu dla Sprzedawcy

4.3.3.2. Śledzenie Zamówień

ID: REQ004

Jako Klient chciał bym śle­dzić sta­tu­sy moich Zamówień zakupu

4.3.4. Relacje

Relacja

Z

Do

unnamed

Pracownik BOK

Zamówienia

unnamed

Klient

Zamówienia

4.3.5. Diagramy Podległe 

4.3.5.1. Zamówienia Zakupu

Zamówienia Zakupu

4.3.6. Śladowanie 

Typ

Wartość

Przekształcony z 

Procesy Business Process Diagram.Rejestracja zamó­wie­nia

Diagram Przypadków Użycia UML

Wstęp

Jest to dia­gram, któ­ry na rów­ni z Diagramem Klas, budzi bar­dzo czę­sto ogrom­ne pro­ble­my inter­pre­ta­cyj­ne (patrz: Diagram klas…). Bardzo wie­lu auto­rów przy­pi­su­je temu dia­gra­mo­wi role, któ­rych on nie peł­ni, a nie raz pre­zen­to­wa­ne w sie­ci i lite­ra­tu­rze przy­kła­dy są nie­po­praw­ne. Znakomita więk­szość auto­rów tych dia­gra­mów uży­wa ich jako zbio­ru moż­li­wych klik­nięć” co jest cał­ko­wi­tym nie­zro­zu­mie­niem celu uży­cia i idei tego dia­gra­mu. Nawet jeże­li ktoś potrze­bu­je takiej mapy kli­ka­nia, to są do tego lep­szych narzę­dzia i meto­dy (przy­kład: Mapa ekra­nów apli­ka­cji – pod­sta­wa dobre­go UX/UI design). Tworzenie nie­zgod­nych z nota­cją dia­gra­mów przy­pad­ków uży­cia po pro­stu psu­je struk­tu­rę pro­jek­tu w narzę­dziach CASE, czy­niąc ją prak­tycz­nie bez­u­ży­tecz­ną w pro­jek­to­wa­nia archi­tek­tu­ry systemu. 

Najpierw opi­szę krót­ko dia­gram przy­pad­ków uży­cia posłu­gu­jąc sie cyta­ta­mi z ory­gi­nal­nej spe­cy­fi­ka­cji. Później opi­szę typo­we błędy. 

Czym jest Diagram Przypadków Użycia

Kluczowe są tu wyja­śnie­nia wstę­pu do roz­dzia­łu UseCases Specyfikacji UML :

18 UseCases
18.1 Use Cases
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.
[…]
18.1.3 Semantics
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. A UseCase is a kind of BehavioredClassifier that repre­sents a dec­la­ra­tion of a set of offe­red Behaviors. Each UseCase spe­ci­fies some beha­vior that a sub­ject can per­form in col­la­bo­ra­tion with one or more Actors. UseCases defi­ne the offe­red Behaviors of the sub­ject witho­ut refe­ren­ce to its inter­nal structure.

Powyższe wytłusz­cze­nia zebra­łem poni­żej, uwa­gi ozna­czo­ne „[…]” są moje:

  1. Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły na rzecz i na żąda­nie Aktora].
  2. Każdy Przypadek Użycia repre­zen­tu­je okre­ślo­ny cel (powód), dla któ­re­go System jest projektowany. 
  3. Przypadek Użycia jest rodza­jem kla­sy­fi­ka­to­ra beha­wio­ral­ne­go, któ­ry repre­zen­tu­je dekla­ra­cję zbio­ru ofe­ro­wa­nych zacho­wań. [to zna­czy, że gru­pu­je okre­ślo­ny kon­tek­sto­wo powią­za­ny zbiór zacho­wań, są to alter­na­tyw­ne sce­na­riu­sze tego same­go przy­pad­ku użycia].
  4. Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] sys­te­mu bez odwo­ły­wa­nia się do jego wewnętrz­nej struktury. (!)

Są to pryn­cy­pia budo­wy tych diagramów.

Związki między Przypadkami Użycia

Extend

Specyfikacja UML:

An Extend is a rela­tion­ship from an exten­ding UseCase (the exten­sion) to an exten­ded UseCase (the extendedCase) that spe­ci­fies how and when the beha­vior defi­ned in the exten­ding UseCase can be inser­ted into the beha­vior defi­ned in the exten­ded UseCase. The exten­sion takes pla­ce at one or more spe­ci­fic exten­sion points defi­ned in the exten­ded UseCase. 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.

Związku «extend» moż­na użyć do poka­za­nia, że pew­ne ele­men­ty zacho­wa­nia Systemu reali­zo­wa­ne są warun­ko­wo. Te dodat­ko­we zacho­wa­nia są jed­nak z zasa­dy czę­ścią bazo­we­go Przypadku Użycia.

Autorzy spe­cy­fi­ka­cji UML jasno piszą, że: Szczegółowy spo­sób okre­śla­nia poło­że­nia punk­tu roz­sze­rzeń jest celo­wo nie­okre­ślo­ny. Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp. […] Zazwyczaj, przy­pa­dek uży­cia z ExtensionPoints skła­da się z zesta­wu drob­no­ziar­ni­stych opi­sów frag­men­tów zacho­wa­nia (sce­na­riu­sze), któ­re są naj­czę­ściej wyko­ny­wa­ne w pew­nej sekwen­cji. Taka seg­men­to­wa struk­tu­ra tek­stu opi­su dane­go przy­pad­ku uży­cia pozwa­la na roz­sze­rze­nie pier­wot­ne­go opi­su zacho­wa­nia przez dołą­cza­nie dodat­ko­wych opi­sów, frag­men­tów zacho­wa­nia, w odpo­wied­nich punk­tach wsta­wia­ne pomię­dzy pier­wot­ne frag­men­ty (punk­ty roz­sze­rzeń). Tak więc, roz­sze­rze­nie UseCase skła­da się zwy­kle z jed­ne­go lub wię­cej opi­sów frag­men­tów zacho­wa­nia, któ­re mają być wsta­wio­ne w odpo­wied­nie miej­sca roz­sze­rza­ne­go przy­pad­ku uży­cia. Rozszerzenia są więc spe­cy­fi­ka­cją wszyst­kich róż­nych punk­tów roz­sze­rzeń w danym przy­pad­ku uży­cia, w któ­rych moż­na umie­ścić dodat­ko­we zachowania.”

Innymi sło­wy, for­mal­nie moż­na na Diagramie Przypadków Użycia poka­zać, to że sce­na­riusz przy­pad­ku uży­cia jest podzie­lo­ny na frag­men­ty, któ­re są wyko­ny­wa­ne warun­ko­wo. Jest to jed­nak mode­lo­wa­nie sce­na­riu­sza zawie­ra­ją­ce­go instruk­cje if … then”. Tu przy­po­mnę więc klu­czo­wą zasa­dę, zapi­sa­ną w spe­cy­fi­ka­cji UML: Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia [mode­lo­wa­ne­go] przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Dlatego wie­lu auto­rów zwra­ca uwa­gę na pew­ne, takie jak ta, nie­kon­se­kwen­cje w specyfikacji. 

Include

Specyfikacja UML:

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. As the pri­ma­ry use of the Include rela­tion­ship is for reu­se of com­mon parts, what is left in a base UseCase is usu­al­ly not com­ple­te in itself but depen­dent on the inc­lu­ded parts to be meaning­ful. This is reflec­ted in the direc­tion of the rela­tion­ship, indi­ca­ting that the base UseCase depends on the addi­tion but not vice versa.

Innymi sło­wy: jeże­li dwa Przypadki Użycia mają pew­ne wspól­ne frag­men­ty zacho­wa­nia, moż­na taki frag­ment wyjąć przed nawias”, ten frag­ment jest na dia­gra­mie repre­zen­to­wa­ny tak­że jako Przypadek Użycia, jed­nak jest to nie­sa­mo­dziel­ny frag­ment, sta­no­wią­cy część wspól­ną co naj­mniej dwóch PU bazo­wych i on sam z sie­bie nie repre­zen­tu­je samo­dziel­ne­go zacho­wa­nia. Ten wspól­ny, wyłą­czo­ny frag­ment, łączy­my z PU bazo­wy­mi związ­kiem «inc­lu­de».

Tak więc związ­ki «inc­lu­de» i «extend» owszem nadal są w spe­cy­fi­ka­cji UML, jed­nak Wynika to z fak­tu, że Przypadki uży­cia mogą być spe­cy­fi­ko­wa­ne w róż­nych for­ma­tach, takich jak język natu­ral­ny, tabe­le, drze­wa itp.” i ktoś może chcieć taki tek­sto­wy for­mat zobra­zo­wać na Diagramie. 

Konsekwencje

Diagram Przypadków uży­cia ma rodo­wód w meto­dy­ce struk­tu­ral­nej (sto­so­wa­nie instruk­cji go to” i sub­ro­uti­ne” w pro­gra­mo­wa­niu struk­tu­ral­nym). Związki «extend» i «inc­lu­de» mają wła­śnie taki rodo­wód i nadal są w nota­cji UML, gdyż Diagram Przypadków Użycia jest nadal popu­lar­nym narzę­dziem w meto­dach struk­tu­ral­nych. Jest też nie­kon­se­kwen­cją spe­cy­fi­ka­cji UML, co widać w jej tre­ści, gdzie na począt­ku roz­dzia­łu auto­rzy spe­cy­fi­ka­cji UML zwra­ca­ją jed­nak uwa­gę, że Przypadki Użycia defi­niu­ją ofe­ro­wa­ne zacho­wa­nia przed­mio­tu bez odwo­ły­wa­nia się do jego wewnętrz­nej struk­tu­ry”. Więc sto­so­wa­nie powyż­szych związ­ków jest relik­tem metod struk­tu­ral­nych, i nie nale­ży ich sto­so­wać w pro­jek­tach zorien­to­wa­nych obiek­to­wo, tym bar­dziej, że jest to łama­nie pod­sta­wo­wej zasa­dy para­dyg­ma­tu obiek­to­we­go jaką jest hermetyzacja. 

Autorzy spe­cy­fi­ka­cji nota­cji UML, takim oto przy­kła­dem pod­su­mo­wu­ją roz­dział 18. Przypadki Użycia:

Jak widać celem pro­jek­to­wa­nia ban­ko­ma­tu są: Wypłata, Wpłata, Przelew, a tak­że: Rejestrowanie ban­ko­ma­tu (w sie­ci) i Udostępnianie listy trans­ak­cji. Detale tych dzia­łań i kolej­ność ich reali­za­cji nie są przed­mio­tem tego mode­lu, nie ma tu związ­ków «inc­lu­de» ani «extend», mimo, że np. trzy klu­czo­we ope­ra­cje wyma­ga­ją uży­cia kar­ty płat­ni­czej i kodu PIN (owszem, wspól­na część, ale są to jed­nak deta­le sce­na­riu­szy a nie osob­ne PU).

Traktując więc PU zgod­nie z jego pod­sta­wo­wą, przy­to­czo­ną powy­żej defi­ni­cją, jako: okre­ślo­ny cel (powód), dla któ­re­go System jest pro­jek­to­wa­ny”, uzna­je­my, że celem apli­ka­cji biz­ne­so­wej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że Drukujemy doku­ment”, szu­ka­my fak­tu­ry” czy wpro­wa­dza­my NIP kon­tra­hen­ta”. Pokazanie dru­ko­wa­nia jako wyłą­czo­nej czę­ści wspól­nej, lub roz­sze­rze­nia, PU Faktura i Zamówienie (sto­su­jąc zwią­zek «inc­lu­de» lub «extend»), czy też wydzie­la­nie na dia­gra­mie PU Wybór klien­ta z listy kon­tra­hen­tów”, to pro­jek­to­wa­nie archi­tek­tu­ry i dro­ga do klę­ski tego dia­gra­mu. To, że kom­po­nent reali­zu­ją­cy dru­ko­wa­nie będzie osob­nym ele­men­tem archi­tek­tu­ry tego sys­te­mu zapew­ne jest praw­dą, ale Diagram PU, jak już wie­my, to nie jest model archi­tek­tu­ry sys­te­mu. Nie jest to tak­że spe­cy­fi­ka­cja pro­ce­su biznesowego.

Obiektowo-zorientowane modelowanie systemu

W arty­ku­le Use Case 2.0 opi­sy­wa­łem kon­cep­cję obiek­to­we­go podej­ścia w pro­jek­to­wa­niu zorien­to­wa­nym na Przypadki Użycia, opra­co­wa­ną przez jed­ne­go z współ­twór­ców UML: Ivara Jacobsona . W arty­ku­le Aplikacje webo­we i mikro­ser­wi­sy czy­li archi­tek­tu­ra sys­te­mów webo­wych opi­sa­łem pro­jek­to­wa­nie opro­gra­mo­wa­nia opar­te na obiek­to­wym para­dyg­ma­cie i wzor­cach pro­jek­to­wych takich jak mikro­ser­wi­sy. Cytowałem mię­dzy inny­mi ten diagram:

Po pra­wej stro­nie powyż­sze­go widzi­my archi­tek­tu­rę zorien­to­wa­ną na mikro­ser­wi­sy. Jest to typo­we i zna­ne od lat kom­po­nen­to­we podej­ście z her­me­ty­za­cją kom­po­nen­tów, reali­zu­ją­cych usłu­gi apli­ka­cji . Bloki [MS] (micro­se­rvi­ces) to nic inne­go jak kom­po­nen­ty reali­zu­ją­ce Przypadki Użycia tego sys­te­mu. Każdy PU ma wła­sną imple­men­ta­cję (i bazę danych, dane [DB] tak­że nie są współ­dzie­lo­ne mię­dzy przy­pad­ka­mi uży­cia). Komponent [UI] to zagre­go­wa­ne na jed­nym ekra­nie wywo­ła­nia usług, czy­li głów­ne menu sys­te­mu. Tak więc Diagram Przypadków Użycia, to model tego głów­ne­go menu sys­te­mu, a nie model imple­men­ta­cji usług (nie archi­tek­tu­ra kodu i nie pro­ces biznesowy).

Podsumowanie

Na poniż­szym dia­gra­mie po lewej stro­nie, poka­za­no for­mal­nie popraw­ny dia­gram przy­pad­ków uży­cia. Z per­spek­ty­wy pro­jek­to­wa­nia zorien­to­wa­ne­go na kom­po­nen­ty, oraz zacho­wa­nia zasa­dy mówią­cej, że ten dia­gram nie słu­ży do mode­lo­wa­nia wewnętrz­nej archi­tek­tu­ry sys­te­mu, popraw­na pro­jek­to­wo jest wer­sja poka­za­na po pra­wej stronie:

Warto też wie­dzieć, że w kon­se­kwen­cji powyż­sze­go, łącze­nie Aktora z wydzie­lo­ny­mi, nie­sa­mo­dziel­ny­mi, opi­sa­mi zacho­wań repre­zen­to­wa­ny­mi przez przy­pad­ki uży­cia 4 i 5, jest pozba­wio­ne logi­ki (podob­nie jak tyl­ko jeden PU połą­czo­ny związ­kiem «inc­lu­de»).

Więc jak i gdzie poka­zać owe sce­na­riu­sze PU? Osobno na dia­gra­mach aktyw­no­ści (role kom­po­nen­tów) lub na dia­gra­mach sekwen­cji (wywo­ły­wa­ne ope­ra­cje inter­fej­sów). (Patrz arty­kuł: Diagram aktyw­no­ści – kie­dy).

Powyższa for­ma (dia­gram po pra­wej stro­nie) ma tak­że prak­tycz­ną zale­tę: Zamawiający zro­zu­mie ten dia­gram. Diagram o po lewej, jest już prak­tycz­ną utra­tą komu­ni­ka­cji z Zamawiającym, bo mało któ­ry z nich stu­diu­je spe­cy­fi­ka­cję UML. Specyfikacja po lewej pro­wa­dzi tak­że do ogrom­ne­go zawy­ża­nia osza­co­wa­nia wycen, gdyż mia­ry opar­te na tak zwa­nych punk­tach funk­cyj­nych, trak­tu­ją każ­dy PU jako samo­dziel­ną, kom­plet­ną jed­ną jed­nost­kę kosztową. 

A co może­my zna­leźć w sie­ci? Poniżej kil­ka przy­kła­dów wraz ze źró­dła­mi, ich oce­nę pozo­sta­wię czytelnikom. 

przykład 1

Major elements of business use case UML diagram.

(w nota­cji UML nie ma i nigdy nie było poję­cia biz­ne­so­wy przy­pa­dek uży­cia”, to poję­cie jest relik­tem meto­dy RUP, Rational Unified Process, z cza­sów gdy nie było nota­cji BPMN i BMM).

przykład 2

Major elements of UML use case diagram.

przykład 3

przykład 4

(źr.: Podstawy mode­lo­wa­nia w języ­ku UML, dr hab. Bożena Woźna-Szcześniak, prof. UJD, Uniwersytet Humanistyczno-Przyrodniczy im. Jana Długosza w Częstochowie, http://​www​.wozna​.org/​s​t​u​d​e​n​t​s​/​2​018 – 2019/uml/UML03.pdf)

Dla porów­na­nia do pobra­nia: Biblioteka

przykład 5

przykład 6

(źr.: Projektowanie Systemów Komputerowych, Laboratoria/Projekty, Krzysztof Regulski, AGH, WIMiIP, DIAGRAM PRZYPADKÓW UŻYCIA – USE CASE MODEL, https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf)

___

Na koniec pole­cam też arty­kuł: Ile przy­pad­ków uży­cia?

Źródła

D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/