Niedawno pisa­łem o UML v.2.51 i zasy­gna­li­zo­wa­łem, że

dia­gram aktyw­no­ści daje kon­tekst dla pojęć z gru­py ?acti­vi­ties? (aktyw­no­ści i czyn­no­ści oraz ich syn­tak­tycz­ne aso­cja­cje), dia­gram klas daje kon­tekst dla ?kla­sy­fi­ka­to­rów struk­tu­ral­nych?, itd. (Źródło: UML ver­sion 2.5 | | Jarosław Żeliński IT-Consulting)

Dzisiaj kil­ka słów na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych w UML.

Cztery lata temu poru­sza­łem temat uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych z uży­ciem mode­lu Eriksson-Penker’a:

Można się tak­że dość czę­sto spo­tkać z defi­ni­cją sze­ścio­ele­men­to­wą Erikssona-Penkera ([[Eriksson-Penker Business Modeling Profile]]). Tu mamy: Powyższy model bazu­je na uzna­niu, że pro­ces biz­ne­so­wy: ma cel, ma spe­cy­ficz­ne dane na wej­ściu, ma spe­cy­ficz­ne dane na wyj­ściu, wyma­ga zaso­bów, sta­no­wi ?wie­le czyn­no­ści do wyko­na­nia?, anga­żu­je róż­ne ?depar­ta­men­ty? w fir­mie (pozio­my prze­pływ), two­rzy jakąś war­tość dla klien­ta (wewnętrz­ne­go lub zewnętrz­ne­go). Problem jaki ja mam z tym wzor­cem to: wyma­ga nie­stan­dar­do­wych pojęć w UML. Profilowanie pole­ga na roz­bu­do­wie tak­so­no­mii zna­czeń (ste­reo­ty­py poka­zu­ją jakie pod­ty­py two­rzy­my dla dane­go typu), nie­ste­ty obiekt jako instan­cja kla­sy nie wytrzy­mu­je w moich oczach defi­ni­cji cze­goś tak abs­trak­cyj­ne­go jak cel biz­ne­so­wy(<>). Symbol pro­ce­su (tak zwa­ny pagon) tak­że nie jest poję­ciem z UML. Pojęcie Information jest tak pojem­ne, że w moich oczach jest wor­kiem, któ­ry pomie­ści wszyst­ko, a cechą dobrej nota­cji (for­mal­ne­go języ­ka, tak­że otwar­te­go) jest jed­nak wza­jem­ne wyklu­cza­nie się defi­ni­cji pojęć danej prze­strze­ni nazw (czy­li jeże­li coś jest np. Wejściem to już nie może być Informacją), na tej zasa­dzie nie rozu­miem też róż­ni­cy pomię­dzy celem pro­ce­su a jego wyj­ściem albo Aktorem z Zasobem (w koń­cu ludzie to zaso­by ludz­kie). (Źródło: Czym jest Piąty ele­ment ? Audyt orga­ni­za­cji czy­li ana­li­za biz­ne­so­wa | | Jarosław Żeliński IT-Consulting)

Generalnie więc jest to pomysł łamią­cy zasa­dy nota­cji… (pro­mo­wa­ny przez fir­mą SPARX, pro­du­cen­ta apli­ka­cji Enterprise Architect). Dość czę­sto spo­ty­kam się z tezą, że: UML posia­da bar­dzo istot­ną w kon­tek­ście prak­tycz­ne­go zasto­so­wa­nia cechę ? jest ela­stycz­ny. W zależ­no­ści od potrze­by, każ­de­mu jego ele­men­to­wi może zostać nada­ne nowe zna­cze­nie, two­rząc tym samym nowy ele­ment moż­li­wy do wyko­rzy­sta­nia pod­czas mode­lo­wa­nia.2 Niestety jest to bzdu­ra. UML ma bar­dzo ści­śle zde­fi­nio­wa­na seman­ty­kę. Owszem jest roz­sze­rzal­ny, ale roz­sze­rze­nie nota­cji to nie zmia­na zna­cze­nia sym­bo­li. Teza, że każ­de­mu jego ele­men­to­wi nota­cji UML może zostać nada­ne nowe zna­cze­nie” to cięż­ka here­zja (zresz­tą doty­czy to każ­dej notacji).

Popatrzmy jed­nak na UML, wer­sja 2.5 po upo­rząd­ko­wa­niu (wcze­śniej też dostęp­ne były te moż­li­wo­ści). Mamy w w niej dwa rodza­je pojęć mode­lu­ją­cych zacho­wa­nia”: aktyw­no­ści i czyn­no­ści (zada­nia). Oba poję­cia uży­wa­ne na Diagramach Aktywności. Aktywność jest poję­ciem szer­szym, ogól­niej­szym, zada­nie to ele­men­tar­ny krok jakiejś pro­ce­du­ry” (podob­nie zresz­tą jak w BPMN). W UML poję­cie aktyw­no­ści jest prze­zna­czo­ne do mode­lo­wa­nia pro­ce­dur w opro­gra­mo­wa­niu. Może tak­że być wyko­rzy­sty­wa­ne do mode­lo­wa­nie pro­ce­sów biz­ne­so­wych w orga­ni­za­cjach (patrz wytłuszczenia):

15 Activities
15.1 Summary
An Activity is a kind of Behavior (see sub clau­se 13.2) that is spe­ci­fied as a graph of nodes inter­con­nec­ted by edges. […] Activities may descri­be pro­ce­du­ral com­pu­ta­tion, for­ming hie­rar­chies of Activities invo­king other Activities, or, in an object-orien­ted model, they may be invo­ked indi­rec­tly as methods bound to Operations that are direc­tly invo­ked. Activities may be applied to orga­ni­za­tio­nal mode­ling for busi­ness pro­cess engi­ne­ering and work­flow. In this con­text, events often ori­gi­na­te from insi­de the sys­tem, such as the fini­shing of a task, but also from out­si­de the sys­tem, such as a custo­mer call. Activities can also be used for infor­ma­tion sys­tem mode­ling to spe­ci­fy sys­tem level pro­ces­ses. […]
15.6.3.1 Activity Partitions
An ActivityPartition is a kind of ActivityGroup for iden­ti­fy­ing ActivityNodes that have some cha­rac­te­ri­stics in com­mon. ActivityPartitions can sha­re con­tents. They often cor­re­spond to orga­ni­za­tio­nal units in a busi­ness model. They may be used to allo­ca­te cha­rac­te­ri­stics or reso­ur­ces among the nodes of an Activity.

W UML 2.5 jaw­nie roz­dzie­lo­no poję­cia Activities i Actions. Aktywności nale­ży rozu­mieć jako pro­ce­du­ry (abs­trak­cje jakichś dzia­łań), czyn­no­ści zaś jako ato­mo­we ope­ra­cje (kolej­ne kro­ki pro­ce­dur). Dla porów­na­nia kolej­ny frag­ment spe­cy­fi­ka­cji UML:

16 Actions
16.1 Summary
An Action is the fun­da­men­tal unit of beha­vior spe­ci­fi­ca­tion in UML. An Action may take a set of inputs and pro­du­ce a set of out­puts, tho­ugh either or both of the­se sets may be emp­ty. Some Actions may modi­fy the sta­te of the sys­tem in which the Action exe­cu­tes. Actions are con­ta­ined in Behaviors, spe­ci­fi­cal­ly Activities (as ExecutableNodes, see Clause 15) and Interactions (see Clause 17). These Behaviors deter­mi­ne when Actions exe­cu­te and what inputs they have. However, the abs­tract syn­tax and seman­tics of Actions are very depen­dent on Activities, becau­se they spe­cia­li­ze ele­ments and seman­tics from Activities to accept inputs and pro­vi­de out­puts and to defi­ne Actions that coor­di­na­te other Actions (Structured Actions, see sub clau­se 16.11). In addi­tion, the con­cre­te syn­tax for Actions only appe­ars in Activity dia­grams (all the exam­ples in this Clause use Activity nota­tion), and some of the nota­tion for Actions is spe­ci­fied in Clause 15. This Clause focu­ses on the syn­tax and seman­tics of Actions spe­ci­fi­cal­ly, rather than the Behaviors that con­ta­in them, but must be read in con­junc­tion with Clause 15.

Tak więc jeże­li chce­my legal­nie” mode­lo­wać pro­ce­sy biz­ne­so­we z uży­ciem UML, to był­by to dia­gram aktyw­no­ści z uży­ciem pojęć Activities i ActivityPartitions. Procedury (i algo­ryt­my) mode­lu­je­my z uży­ciem poję­cia Action. Porównując ten dia­gram i te poję­cia z BPMN widać wyż­szość tej dru­giej nota­cji. Po pierw­sze BPMN, ope­ru­jąc poję­cia­mi zda­rze­nie i bram­ka zda­rze­nio­wa, dosko­na­le daje sobie radę z mode­lo­wa­niem fak­tów w biz­ne­sie, po dru­gie – jak poka­zu­je prak­ty­ka – seman­ty­ka i gra­fi­ka BPMN jest łatwa do zro­zu­mie­nia dla odbior­cy biz­ne­so­we­go, cze­go dowo­dzi szyb­ki wzrost popu­lar­no­ści BPMN wśród ludzi biz­ne­su” i nadal zni­ko­my zakres sto­so­wa­nia UML w tej grupie.

Na koniec jesz­cze jed­na rzecz: kom­plet­nie nie rozu­miem uży­wa­nia poję­cia Przypadków Użycia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych. Nie znaj­du­je ono żad­ne­go uza­sad­nie­nia w seman­ty­ce UML. W spe­cy­fi­ka­cji UML czytamy:

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. A UseCase is a spe­ci­fi­ca­tion of beha­vior. An instan­ce of a UseCase refers to an occur­ren­ce of the emer­gent beha­vior that con­forms to the cor­re­spon­ding UseCase. Such instan­ces are often descri­bed by Interactions.

Tak więc Przypadek Użycia to WYŁĄCZNIE kon­kret­ne zacho­wa­nie (reak­cja na bodziec) sys­te­mu defi­nio­wa­ne­go (spe­cy­fi­ko­wa­ne­go). Specyfikacje tych zacho­wań to inte­rak­cje. Ciągnące się od lat w krę­gach wywo­dzą­cych się z metod RUP (Rational Unified Process3) poję­cie Biznesowych Przypadków Użycia jest w moich oczach, i nie tyl­ko, zaka­łą bran­ży. Od cza­su gdy powstał UML 0.9 jako jeden zestaw metod mode­lo­wa­nia, nigdy w spe­cy­fi­ka­cji UML OMG nie było mowy o Biznesowych Przypadkach Użycia. Pojęcia te są tak samo nie­zgod­ne z UML jak wcze­śniej wymie­nio­ne pomy­sły SPARX i pro­fil Eriksson-Penker’a. Jeżeli może­my coś ze sobą porów­nać to ele­men­tar­ny pro­ces biz­ne­so­wy i przy­pa­dek uży­cia, ale pod jed­nym warun­kiem: że odwzo­ro­wu­je­my (mapu­je­my) kon­kret­ny ele­men­tar­ny (ato­mo­wy) pro­ces biz­ne­so­wy w apli­ka­cji na kon­kret­ny przy­pa­dek uży­cia, o czym pisa­łem w arty­ku­le o trans­for­ma­cji pro­ce­sów biz­ne­so­wych na przy­pad­ki uży­cia.

Tak więc sto­so­wa­nie UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych jest moż­li­we z uży­ciem dia­gra­mu aktyw­no­ści i pojęć acti­vi­ties. Stosowanie przy­pad­ków uży­cia UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych nie ma żad­ne­go seman­tycz­ne­go uza­sad­nie­nia, co widać jak na dło­ni w spe­cy­fi­ka­cji UML. Tak więc zostaw­my UML do zorien­to­wa­ne­go obiek­to­wo mode­lo­wa­nia sys­te­mów i BPMN do pro­ce­so­wo zorien­to­wa­nych mode­li orga­ni­za­cji. Obiektowe mode­le orga­ni­za­cji jak naj­bar­dziej mają sens, są to mode­le dzie­dzi­ny mode­lo­wa­nej orga­ni­za­cji, wyko­rzy­sty­wa­ne jako model logi­ki biz­ne­so­wej w two­rze­niu oprogramowania.

Jarosław Żeliński

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

Dodaj komentarz

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