Transformacja modelu procesów biznesowych na model przypadków użycia

Ukazują się róż­ne opra­co­wa­nia na temat tytu­ło­wej trans­for­ma­cji. Jednym z takich opra­co­wań jest tekst Transformacja Modeli Pana Piotra Carewicza z fir­my 300 D&C, opu­bli­ko­wa­ny w perio­dy­ku Analiza Biznesowa Lato 2015 fir­mo­wa­nym przez Warszawski oddział IIBA. Pozwolę sobie na pew­ną pole­mi­kę z przed­sta­wio­nym tam pro­ce­sem trans­for­ma­cji mode­lu pro­ce­sów biz­ne­so­wych BPMN na Przypadki Użycia nota­cji UML. Autor powo­łu­je się na OMG​.org i spe­cy­fi­ka­cje BPMN i UML. Dlatego dla porząd­ku przy­to­czę klu­czo­we definicje.

10.3 Activities
An Activity is work that is per­for­med within a Business Process. An Activity can be ato­mic or non-ato­mic
(com­po­und). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which
allows the inc­lu­sion of re-usa­ble Tasks and Processes in the dia­gram. However, a Process is not a spe­ci­fic gra­phi­cal
object. Instead, it is a set of gra­phi­cal objects. The fol­lo­wing sub clau­ses will focus on the gra­phi­cal objects SubProcess
and Task. Activities repre­sent points in a Process flow whe­re work is per­for­med. They are the exe­cu­ta­ble ele­ments of a BPMN Process. (źr. BPMN for­mal 13 – 12-09)

Aktywność to ele­ment w pro­ce­sie repre­zen­tu­ją­cy wyko­na­ną okre­ślo­ną pra­cę. Atomowa (ele­men­tar­na) aktyw­ność to czyn­ność w pro­ce­sie, któ­rej nie dzie­li­my już na mniej­sze ele­men­ty składowe.

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 struc­tu­re. These Behaviors, invo­lving inte­rac­tions betwe­en the Actors and the sub­ject, may result in chan­ges to the sta­te of the sub­ject and com­mu­ni­ca­tions with its envi­ron­ment. A UseCase can inc­lu­de possi­ble varia­tions of its basic beha­vior, inc­lu­ding excep­tio­nal beha­vior and error han­dling. (źr. UML 2.5 for­mal 13 – 12-09)

Przypadek uży­cia jest więc kon­kret­nym zacho­wa­niem sys­te­mu (sub­ject) dają­cym jako efekt war­to­ścio­wy (ocze­ki­wa­ny) rezul­tat dla aktora.

Transformacja wg. OMG

Dla doko­na­nia jakiej­kol­wiek trans­for­ma­cji, nale­ży przy­jąć kon­kret­ną prag­ma­ty­kę (kon­tekst) gdyż obie nota­cje (UML i BPMN) dają pew­ną swo­bo­dę jej uży­cia (jak widać powyż­sze defi­ni­cje dają pewien mar­gi­nes swo­bo­dy uży­cia tych sym­bo­li). Z pomo­cą może przyjść nam biz­ne­so­wa defi­ni­cja pro­ce­su biz­ne­so­we­go: aktyw­ność prze­kształ­ca­ją­ca stan wej­ścia w stan wyj­ścia pro­ce­su, two­rzą­ca war­to­ścio­wy pro­dukt dla akto­ra (roli w pro­ce­sie). Taka aktyw­ność jest reali­zo­wa­na (może być) zgod­nie z jakąś pro­ce­du­rą. Przypadki uży­cia są ogra­ni­cza­ne ich sta­nem począt­ko­wym i koń­co­wym, mają akto­ra, mają jeden lub wię­cej alter­na­tyw­nych sce­na­riu­szy. Warto tu zwró­cić uwa­gę, że stan począt­ko­wy i koń­co­wy przy­pad­ku uży­cia oraz wej­ście i wyj­ście ele­men­tar­ne­go pro­ce­su biz­ne­so­we­go, to ana­lo­gicz­ne – odpo­wia­da­ją­ce sobie – poję­cia. Pojęcie ato­mo­wy” (w lite­ra­tu­rze spo­ty­ka­ne sło­wo to tak­że ele­men­tar­ny”) oznacza:

ele­men­tar­ny pro­ces biz­ne­so­wy: zada­nie wyko­ny­wa­ne przez jed­na oso­bę, w jed­nym miej­scu i okre­ślo­nym cza­sie, w odpo­wie­dzi na okre­ślo­ne zda­rze­nie biz­ne­so­we; zada­nie to pro­wa­dzi do uzy­ska­nia mie­rzal­nej war­to­ści biz­ne­so­wej; po jego wyko­na­niu dane są w spój­nym sta­nie; (przy­pad­ki uży­cia powin­ny reali­zo­wać ele­men­tar­ne pro­ce­sy biz­ne­so­we, cytat z: UML i wzor­ce pro­jek­to­we, Craig Larman)

Kluczowym wyma­ga­niem dla trans­for­ma­cji jest zde­fi­nio­wa­nie poję­cia, któ­re będzie łącz­ni­kiem (będzie trans­for­mo­wa­ne z cze­goś” na coś”, będzie wspól­nym ele­men­tem w obu mode­lach) pomię­dzy mode­lem pro­ce­sów biz­ne­so­wych a mode­lem przy­pad­ków uży­cia. Tu z pomo­cą przy­cho­dzi archi­tek­tu­ra SOA. SOA to wzo­rzec łączą­cy model pro­ce­sów biz­ne­so­wych z modem aplikacji:

SOA_OMG_model

Generalnie kon­cep­cja SOA bazu­je na uzna­niu, że ato­mo­we” pro­ce­sy biz­ne­so­we są wspo­ma­ga­ne (sup­port) poje­dyn­czy­mi usłu­ga­mi apli­ka­cyj­ny­mi. Tu zno­wu powo­ła­my się na OMG​.org i spe­cy­fi­ka­cję pro­fi­lu UML jakim jest SoaML:

6.1.5 Key Concepts of Basic Services
A key con­cept is, of cour­se, servi­ce. Service is defi­ned as the deli­ve­ry of value to ano­ther par­ty, ena­bled by one or more capa­bi­li­ties. Here, the access to the servi­ce is pro­vi­ded using a pre­scri­bed con­tract and is exer­ci­sed con­si­stent with con­stra­ints and poli­cies as spe­ci­fied by the servi­ce con­tract. A servi­ce is pro­vi­ded by a par­ti­ci­pant acting as the pro­vi­der of the servi­ce-for use by others.

6.2.6 Business Motivation […] There are other ways of cap­tu­ring requ­ire­ments inc­lu­ding use cases. A Service Contract, which is also a clas­si­fier, can reali­ze UseCases. In this case, the actors in the use case may also be used to type roles in the servi­ce con­tract, or the actors may reali­ze the same Interfaces used to type the roles. (źr. OMG SoaML, for­mal-12 – 05-10)

Tak wiec mamy prze­ło­że­nie: ato­mo­wy pro­ces w BPMN, aktyw­ność któ­ra wraz z jej wej­ściem i wyj­ściem, jest przy­po­rząd­ko­wy­wa­na do poje­dyn­czej usłu­gi apli­ka­cyj­nej repre­zen­to­wa­nej w UML jako przy­pa­dek uży­cia, któ­ry ma swój stan począt­ko­wy i koń­co­wy. Zarówno ato­mo­wy pro­ces jak i przy­pa­dek uży­cia nie są już dzie­lo­ne na mniej­sze ele­men­ty, bo gra­da­cję” podzia­łu w dół” ogra­ni­cza to, że w toku spój­nej pra­cy jed­ne­go czło­wie­ka (aktor) ma powstać war­to­ścio­wy dla akto­ra rezul­tat (pro­dukt). Innymi sło­wy ato­mo­wym pro­ce­sem i zara­zem przy­pad­kiem uży­cia, będzie np. utwo­rze­nie fak­tu­ry sprze­da­ży, gdyż nie­kom­plet­na fak­tu­ra nie sta­no­wi żad­nej war­to­ści biz­ne­so­wej. Wszelkie dzia­ła­nia w toku two­rze­nia fak­tu­ry są ele­men­ta­mi sce­na­riu­sza jed­ne­go przy­pad­ku uży­cia, a wcze­śniej pro­ce­du­ry reali­za­cji jed­nej aktyw­no­ści two­rzą­cej tę fakturę.

Jak więc wyglą­da trans­for­ma­cja? Tu posłu­żę się frag­men­tem stro­ny pomo­cy pakie­tu Visual-Paradigm, jed­nej z nie­wie­lu apli­ka­cji CASE zacho­wu­ją­cej peł­ną zgod­ność ze spe­cy­fi­ka­cja­mi OMG:

BPMNtoUseCase (źr. http://www.visual-paradigm.com/tutorials/from-business-process-to-use-cases.jsp)
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)

(apli­ka­cja Visual-Paradigm two­rzy taką trans­for­ma­cje auto­ma­tycz­nie dla mode­lu pro­ce­su).

Kilka uwag do tekstu Pana Carewicza

Diagram przy­pad­ków uży­cia nie jest mode­lem sys­te­mo­wym”, jest kon­trak­tem pomię­dzy zama­wia­ją­cym opro­gra­mo­wa­nie a jego dostaw­cą, sta­no­wi spe­cy­fi­ka­cję wyma­gań, gdzie pod poję­ciem wyma­ga­nie” rozu­mie­my to, jakie usłu­gi ma to opro­gra­mo­wa­nie ofe­ro­wać (do cze­go będzie ono wyko­rzy­sty­wa­ne przez aktora):

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. (UML v.2.5)

W mode­lu MDA (Model Driven Architecture) dia­gram przy­pad­ków uży­cia sta­no­wi pomost” pomię­dzy mode­lem biz­ne­so­wym CIM (Computation Independet Model) a mode­lem logi­ki dzia­ła­nia i archi­tek­tu­ry PIM (Platform Independent Model). Model PIM to reali­za­cje przy­pad­ków uży­cia bazu­ją­ce na mode­lu dziedziny.

18.1.3 Semantics
18.1.3.1 Use Cases and Actors
[…] 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 struc­tu­re. (UML v.2.5)

Kluczem jest ostat­nie zda­nie: przy­pad­ki uży­cia defi­niu­ją zacho­wa­nie sys­te­mu bez odno­sze­nia się do jego wewnętrz­nej struk­tu­ry. Innymi sło­wy model przy­pad­ków uży­cia nie słu­ży do mode­lo­wa­nia archi­tek­tu­ry (wewnętrz­nej struk­tu­ry) opro­gra­mo­wa­nia. W UML 2.5 jaw­nie wydzie­lo­ny trzy obsza­ry seman­tycz­ne mode­lo­wa­nia, któ­re potwier­dza­ją powyższe:

UMLSemanticArea

Jednak dla zacho­wa­nia uni­wer­sal­no­ści i kom­pa­ty­bil­no­ści wstecz zacho­wa­no w UML 2.5 poję­cia – ste­reo­ty­py – «Extend» i «Include», któ­re wyja­wia­ją” wewnętrz­ną struk­tu­rę apli­ka­cji, jed­nak UML 2.5 zastrzega:

The spe­ci­fic man­ner in which the loca­tion of an ExtensionPoint is defi­ned is inten­tio­nal­ly unspe­ci­fied. 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. […] The inc­lu­ded UseCase must be ava­ila­ble for the beha­vior of the inc­lu­ding UseCase to be com­ple­te­ly descri­bed. (UM v.2.5. R.18.1.3.)

Czyli ste­reo­ty­py związ­ku uży­cia dla przy­pad­ków uży­cia, ozna­czo­ne związ­kiem «extend» lub «inc­lu­de», zosta­ły w UML 2.5 dla zacho­wa­nia moż­li­wo­ści uży­wa­nia dia­gra­mów przy­pad­ków uży­cia i kon­ty­nu­owa­nia ich opi­su w fir­mie opi­so­wej (tekst, tabe­le, inne­go for­my słow­ne a nie gra­ficz­ne). Są to relik­to­we kon­struk­cje z cza­sów gdy na począt­ku lat 90-tych powsta­wał UML (były to trzy odręb­ne nota­cje trzech twór­ców): autor dia­gra­mu przy­pad­ków uży­cia nie znał dia­gra­mów struk­tu­ral­nych (dia­gra­my klas, kom­po­nen­tów) i musiał jakoś poka­zać” ele­men­ty archi­tek­tu­ry kodu. Stosowanie tych kon­struk­cji w sytu­acji gdy mode­lem reali­za­cji przy­pad­ków uży­cia będą dia­gra­my sekwen­cji bazu­ją­ce na mode­lu dzie­dzi­ny (mode­le struk­tu­ry), nie ma żad­ne­go uza­sad­nie­nia i wpro­wa­dza zbęd­ny zamęt i nad­mier­ne, niczym nie uza­sad­nio­ne, roz­drob­nie­nie mode­lu (pomi­jam, że na tym eta­pie – umo­wa z zama­wia­ją­cym – przed­wcze­śnie narzu­ca decy­zje architektoniczne).

Autor tek­stu wpro­wa­dził tak­że kolej­ny podział przy­pad­ków uży­cia (ste­reo­ty­py) na cel użyt­kow­ni­ka”, przy­pad­ki wspie­ra­ją­ce”, pomoc­ni­cze”, pod­funk­cje”. Niestety nie zosta­ły one (te poję­cia) pre­cy­zyj­nie zde­fi­nio­wa­ne, wpro­wa­dza­ją do całej meto­dy” cha­os poję­cio­wy. Z kon­tek­stu moż­na wywo­dzić, że jest to jakaś for­ma wynie­sie­nia na poziom mode­lu przy­pad­ków uży­cia, poszcze­gól­nych kro­ków ich sce­na­riu­szy (wyszu­ka­nie zgło­sze­nia, zapi­sa­nie infor­ma­cji o zmia­nie zgło­sze­nia do dzien­ni­ka) czy wręcz (o zgro­zo!) linii kodu, jed­nak cel tego jest nie­ja­sny, poza znacz­ną kom­pli­ka­cją dia­gra­mu, któ­ry jako kon­trakt z kupu­ją­cym, powi­nien być pro­sty i czy­tel­ny dla biz­ne­su”. Wyciąganie na poziom usług sys­te­mu” nie­mal­że poje­dyn­czych linii przy­szłe­go pro­gra­mu nie znaj­du­je w moich oczach żad­ne­go uza­sad­nie­nia (po raz kolej­ny przy­po­mi­nam, że przy­pad­ki uży­cia to wyma­ga­nia a nie model kodu), poza tym, że przy­bli­ża taki model do pro­duk­tów ana­li­zy struk­tu­ral­nej z lat 80-tych (pyta­nie po co?).

Autor powo­łu­je się tak­że na nota­cję BPMN słusz­nie wska­zu­jąc, że do trans­for­ma­cji na przy­pad­ki uży­cia two­rzy­my pro­ces pry­wat­ny”, nie prze­zna­czo­ny do wyko­na­nia (non-exe­cu­ta­ble) w rozu­mie­niu nie two­rzo­ny w celu bez­po­śred­nie­go uru­cho­mie­nia” np. w jakimś sil­ni­ku pro­ce­so­wym”. I tu koń­czy się kon­se­kwen­cja, gdyż zale­ca sto­so­wa­nie deta­licz­nych czyn­no­ści i znacz­ni­ków spe­cy­ficz­nych dla mode­li wyko­ny­wal­nych (ozna­cze­nia w lewym gór­nym roku). Otóż do trans­for­ma­cji na przy­pad­ki uży­cia two­rzy­my model CIM (OMG MDA) a tu nie brnie­my” w deta­licz­ne szcze­gó­ły, gdyż te będą reali­zo­wa­ne w apli­ka­cji. Model CIM to pro­ce­sy biz­ne­so­we com­pu­ta­tion inde­pen­dent model” w nota­cji BPMN, poziom szcze­gó­ło­wo­ści mode­lu biz­ne­so­we­go CIM, do trans­for­ma­cji, koń­czy­my na wspo­mnia­nych na począt­ku ato­mo­wych pro­ce­sach biz­ne­so­wych”, to któ­ra z aktyw­no­ści tych pro­ce­sów sta­nie się wyma­ga­niem (przy­pad­kiem uży­cia apli­ka­cji) zale­ży od umo­wy na zakres pro­jek­tu i od nicze­go wię­cej. Wymóg jako­by czyn­no­ści wysła­nia i ode­bra­nia komu­ni­ka­tu musia­ły być obli­ga­to­ryj­nie wydzie­la­ne wyda­je się dziw­ny. Np. czytamy:

Send Task
A Send Task is a sim­ple Task that is desi­gned to send a Message to an exter­nal Participant (rela­ti­ve to the Process). Once the Message has been sent, the Task is completed.

sko­ro więc czyn­ność wysła­nia komu­ni­ka­tu jest dedy­ko­wa­na do jed­ne­go zda­rze­nia jakim jest wysła­nie komu­ni­ka­tu, zaś na mode­lu pro­ce­sów biz­ne­so­wych nie-wyko­ny­wal­nych” taki poziom szcze­gó­ło­wo­ści nie jest niczym uza­sad­nio­ny (wysła­nie potwier­dze­nia to z regu­ły ostat­ni krok pro­ce­du­ry a w sce­na­riu­szu przy­pad­ku uży­cia, ostat­ni krok tego sce­na­riu­sza) to pomysł ten wyda­je się nie mieć żad­ne­go uza­sad­nie­nia. Po dru­gie wysła­nie komu­ni­ka­tu” odwzo­ro­wa­ne jako przy­pa­dek uży­cia nie ma żad­ne­go sen­su w świe­tle tego czym jest przy­pa­dek uży­cia w UML.

Nie wiem też jak, z pomo­cą jakiej trans­for­ma­cji, Pan Carewicz uzy­skał na dia­gra­mie przy­pad­ków uży­cia dzie­dzi­czą­cych po sobie aktorów.

Na zakończenie

Z przy­kro­ścią muszę napi­sać, że arty­ku­ły takie jak tekst Pana Piotra Carewicza wpro­wa­dza­ją zamęt. Nie mają, jak poka­za­łem, pod­staw seman­tycz­nych, nie mają uza­sad­nie­nia w samych nota­cjach, nie raz wręcz koli­du­ją z nimi, pro­wa­dzą do powsta­wa­nia bar­dzo roz­bu­do­wa­nych i kosz­tow­nych w opra­co­wa­niu doku­men­tów, nie wno­szą­cych swo­ją szcze­gó­ło­wo­ścią żad­nej war­to­ści doda­nej, a uży­cie takiej doku­men­ta­cji jest prak­tycz­nie nie moż­li­we, gdyż jak widać jest ona nie­spój­na a nad­miar szcze­gó­łów poda­nych na tak wcze­snym eta­pie jak pla­no­wa­nie wyma­gań, pro­wa­dzi do bar­dzo dużej ilo­ści aktu­ali­za­cji w toku reali­za­cji pro­jek­tu. Zdaje sobie spra­wę, że Pan Carewicz pró­bu­je sobie jakoś pora­dzić z uży­ciem UML do meto­dy wymia­ro­wa­nia opro­gra­mo­wa­nia COSMIC, któ­rej jest orę­dow­ni­kiem, ale moim zda­niem to jed­nak śle­pa uliczka.

Powyższe, nie mają­ce uza­sad­nie­nia w UML, kon­struk­cje, moż­na spo­tkać tak­że w mate­ria­łach publi­ko­wa­nych przez fir­mę SPARX, pro­du­cen­ta opro­gra­mo­wa­nia Enterprise Architect. Osobiście, i nie tyl­ko ja (np. Czas nie jest akto­rem), odra­dzam te mate­ria­ły i suge­ru­ję jed­nak ory­gi­nal­ne spe­cy­fi­ka­cje. Samo narzę­dzie fir­my SPARX, mimo, że bar­dzo tanie i popu­lar­ne, nie­ste­ty jest bar­dzo pra­co­chłon­ne. Tyle w kwe­stii samej trans­for­ma­cji. Ocenę meto­dy opi­sa­nej przez Pana Carewicza z fir­my 300 D&C pozo­sta­wiam czytelnikom.

Polecam tak­że t dwa filmiki 🙂

Inne artykuły na podobny temat

image_print(wydruk PL)

Komentarze

  1. Hania Wesołowska 28 października 2015 at 22:39

    Zarówno ato­mo­wa aktyw­ność jak i przy­pa­dek uży­cia nie są już dzie­lo­ne na mniej­sze ele­men­ty bo ?gra­da­cję? podzia­łu ?w dół? ogra­ni­cza to, że ma powstać war­to­ścio­wy dla akto­ra rezul­tat (pro­dukt).”

    Można sobie wyobra­zić poziom szcze­gó­ło­wo­ści na jakim dal­sze scho­dze­nie w dół fak­tycz­nie spo­wo­du­je, że czyn­no­ści w przy­pad­ku uży­cia już nie będą dawa­ły war­to­ści i nie moż­na ich dzie­lić. Rozumiem, że to nie wyklu­cza jed­nak łącze­nia przy­pad­ków uży­cia w więk­sze gru­py dostar­cza­ją­ce okre­ślo­ną war­tość. Nie każ­dy przy­pa­dek uży­cia musi być atomowy?

    • Jaroslaw Zelinski 29 października 2015 at 08:06

      Przypadek uży­cia to twór czy­sto prak­tycz­ny, sta­no­wi narzę­dzie zawar­cia umo­wy pomię­dzy zama­wia­ją­cym opro­gra­mo­wa­nie a jego dostaw­cą. Wiele zamie­sza­nia robi tu poję­cie wyma­ga­nie funk­cjo­nal­ne”, któ­re jest bar­dzo nie­jed­no­znacz­ne, a w nie­któ­rych opra­co­wa­niach jest utoż­sa­mia­ne wła­śnie z przy­pad­kiem uży­cia. W efek­cie spo­ty­ka­my się np. z taki­mi przy­pad­ka­mi uży­cia jak wyświe­tle­nie listy kon­tra­hen­tów po klik­nię­ciu myszą”. Takie coś samo­dziel­nie nie ma racji bytu. Przypadki uży­cia to samo­dziel­ne (każ­dy ma w koń­cu wła­sny prio­ry­tet) usłu­gi, więc pro­sty test: czy wyświe­tle­nie listy kon­tra­hen­tów po klik­nię­ciu myszą” może być samo­dziel­nie zamó­wio­ną w opro­gra­mo­wa­niu usłu­gą, powie że nie. Druga rzecz: każ­dy przy­pa­dek uży­cia to z zasa­dy war­tość dla akto­ra, to zna­czy, że podzie­le­nie go – tego przy­pad­ku uży­cia – na mniej­sze ele­men­ty, nie mają­ce samo­dziel­nie tej cechy, nie ma żad­ne­go uza­sad­nie­nia. Tak więc przy­pa­dek uży­cia, jako poten­cjal­nie samo­dziel­nie ofe­ro­wa­na usłu­ga opro­gra­mo­wa­nia, jest na tym pozio­mie nie­po­dziel­ny na kawał­ki”.

      Łączenie przy­pad­ków uży­cia w gru­py ma sens, np. mogą to być dzie­dzi­no­we gru­po­wa­nia (podział na usłu­gi zwią­za­ne z pro­duk­ta­mi i usłu­gi zwią­za­ne kon­tra­hen­ta­mi), jed­nak nie powin­no to pro­wa­dzić do sytu­acji, w któ­rej wyję­ty z takiej gru­py przy­pa­dek uży­cia tra­ci moc”, czy­li prze­sta­je być samo­wy­star­czal­ny. Do gru­po­wa­nia w UML słu­żą pakiety. 

      Tu war­to wspo­mnieć o dzie­dzi­cze­niu na dia­gra­mach przy­pad­ków uży­cia. Często widu­ję np. dzie­dzi­cze­nie mię­dzy akto­ra­mi czy mię­dzy przy­pad­ka­mi uży­cia. Warto pamię­tać, że UML to zarów­no mode­le poję­cio­we jak i mode­le struk­tu­ry. Na mode­lach poję­cio­wych dzie­dzi­cze­nie ozna­cza uszcze­gó­ło­wie­nie pojęć i ich uogól­nia­nie, ale mamy tu na myśli słow­ni­ko­we defi­ni­cje pojęć a nie struk­tu­ry”. Tak więc sło­wo doku­ment jest uogól­nie­niem pojęć umo­wa, zamó­wie­nie itp. a fak­tu­ra będzie szcze­gól­nym przy­pad­kiem dowo­du księ­go­we­go. Struktura cze­goś” jest zaś z zasa­dy bytem mate­rial­nym, tak więc leżą­ce na sto­le doku­men­ty róż­nych rodza­jów, są nie­za­leż­ny­mi mate­rial­ny­mi byta­mi, nicze­go po niczym nie dzie­dzi­czą, żyją każ­dy wła­snym życiem. Na mode­lach struk­tu­ral­nych może być przy­dat­ne uogól­nie­nie ale wte­dy jest to z zasa­dy abs­trak­cja, coś co nie ma swo­je­go mate­rial­ne­go odpo­wied­ni­ka, celem jest tu wyłącz­nie wspól­ne nazew­nic­two (a nie gru­po­wa­nie!). Dotyczy to tak­że przy­pad­ków uży­cia i akto­rów: są to byty mate­rial­ne, sto­so­wa­nie tu związ­ku dzie­dzi­cze­nia ma sens wyłącz­nie poję­cio­wy. Związek dzie­dzi­cze­nia pomię­dzy akto­ra­mi na dia­gra­mie Pana Carewicza sta­no­wi wiec swe­go rodza­ju kurio­zum… aktor to real­ny czło­wiek (rola) a na mode­lach struk­tu­ry, tam gdzie poja­wia się dzie­dzi­cze­nie, mate­rial­ne wystą­pie­nia mają wyłącz­nie liście” struk­tu­ry, resz­ta (powy­żej) to abstrakcje…

  2. Jaroslaw Zelinski 30 października 2015 at 15:54

    Padło pyta­nie: więc jak mode­lo­wać i co ozna­cza dzie­dzi­cze­nie w języ­ku pro­gra­mo­wa­nia? Otóż na mode­lach PIM nie uży­wa­my dzie­dzi­cze­nia (model struk­tu­ry, logi­ka apli­ka­cji). Dziedziczenie w języ­ka opro­gra­mo­wa­nia to imple­men­ta­cja re-uży­cia kodu, dla struk­tu­ry ma sens jako ele­ment mode­lu PSM bo to dopie­ro model implementacji.

  3. Piotr Trętowski 9 listopada 2015 at 16:00

    Czyli przy­pad­ki uży­cia ozna­czo­ne <> i <> są w UML dla zacho­wa­nia moż­li­wo­ści uży­wa­nia dia­gra­mów przy­pad­ków uży­cia i kon­ty­nu­owa­nia ich opi­su w fir­mie opi­so­wej (tekst, tabe­le, inne­go for­my słow­ne a nie graficzne).”
    Panie Jarosławie, zgod­nie z moją skrom­ną wie­dzą poprzez <> i <> ozna­cza się zazwy­czaj związ­ki pomię­dzy przy­pad­ka­mi uży­cia, a nie przy­pad­ki użycia.

    Nie rozu­miem rów­nież powo­du wpro­wa­dza­nia w kon­tek­ście oma­wia­ne­go arty­ku­łu poję­cia atomowoego/elementarnego pro­ce­su biz­ne­so­we­go”, któ­ry wpro­wa­dza szum informacyjny.

    • Jaroslaw Zelinski 9 listopada 2015 at 23:15

      Stereotypy «extend» i «inc­lu­de» to typy związ­ków wska­zu­ją­ce, że dany przy­pa­dek uży­cia jest dodat­ko­wym sce­na­riu­szem roz­sze­rza­ją­cym lub wspól­nym dla dwóch lub wię­cej przy­pad­ków, w arty­ku­le cytu­je ory­gi­nał spe­cy­fi­ka­cji UML. Te związ­ki są inte­gral­ną czę­ścią przy­pad­ków uży­cia (co jest napi­sa­ne wprost w spe­cy­fi­ka­cji UML: zwią­zek kom­po­zy­cji” na dia­gra­mie pro­fi­lu dla dia­gra­mów przy­pad­ków uży­cia). Polecam gorą­co nie­po­mi­ja­nie dia­gra­mów pro­fi­li w doku­men­ta­cji, bo mają one wyż­szy prio­ry­tet niż pro­za” w tych dokumentach. 

      Pojęcie ato­mo­wa (ele­men­tar­na) aktyw­ność oraz pro­ces biz­ne­so­wy opar­ty na tej aktyw­no­ści (w kon­se­kwen­cji pro­ces biz­ne­so­wy ato­mo­wy) to poję­cia zde­fi­nio­wa­ne w spe­cy­fi­ka­cji BPMN Dodatek C. Pojęcia te zna­ne są w lite­ra­tu­rze przed­mio­tu od lat, ozna­cza­ją pro­ces, któ­re­go nie dzie­li­my już na pod-pro­ce­sy. Z naj­now­szej lite­ra­tu­ry pole­cam UML i wzor­ce pro­jek­to­we. Analiza i pro­jek­to­wa­nie obiek­to­we oraz ite­ra­cyj­ny model wytwa­rza­nia apli­ka­cji. Wydanie III” (autor Craig Larman). Praktycznie każ­da spe­cy­fi­ka­cja (w tym UML, BPMN, BMM) ze stron OMG ope­ru­je poję­ciem ato­mic ele­ment” w sto­sun­ku do ele­men­tów mode­li nie­pod­le­ga­ją­cych dal­szej dekom­po­zy­cji. Nie ma tu żad­ne­go chaosu. 

  4. Małgorzata 20 grudnia 2016 at 15:53

    Wprawdzie mate­ria­ły sta­re, ale mam pyta­nie, któ­re zawsze mi się nasu­wa, gdy prze­glą­dam jakie­kol­wiek mate­ria­ły szko­le­nio­we. Na fil­mi­ku (np. 02:25) widać roz­gra­ni­cze­nie na takie aktyw­no­ści jak Report item found” oraz Report item not found”. Czy to serio powin­no być roz­gra­ni­czo­ne? Rozumiem, że to tyl­ko przy­kła­do­wy mate­riał, ale widzę coś takie­go nagmin­nie (w zasa­dzie nie widzę innych przy­kła­dów szko­le­nio­wych) i zaczy­nam się po pro­stu zasta­na­wiać, czy sama dobrze robię i czy nad­mier­nie nie uprasz­czam… Osobiście zro­bi­ła­bym po pro­stu Report result”, zwłasz­cza, że dzię­ki temu pro­ces nie miał­by dwóch zakoń­czeń (też nie wiem po co). Czy dobrze myślę?

    • Jaroslaw Zelinski 21 grudnia 2016 at 10:19

      Generalnie tak. Trzeba brać popraw­kę na to, że tuto­ria­le pro­du­cen­tów takie­go opro­gra­mo­wa­nia nasta­wio­ne są na pre­zen­ta­cje moż­li­wo­ści narzę­dzia a nie na naukę bycia ana­li­ty­kiem ;). Oryginalne spe­cy­fi­ka­cje nota­cji zawie­ra­ją przy­kła­dy – oczy­wi­ście popraw­ne co do zasad – uży­cia ele­men­tów nota­cji, jed­nak czę­sto nie są to ani żad­ne dobre prak­ty­ki ani nawet god­ne naśla­do­wa­nia wzor­ce.… Przykłady takie speł­nia­ją raczej taką rolę w tych tuto­ria­lach jak Lorem Ipsum w bran­ży drukarsko/graficznej (Lorem Ipsum).

      Co do pyta­nia o Report item.… ja w życiu bym tego nie roz­gra­ni­czył ;), zro­bił bym tak samo jak Pani 😉

  5. Jaroslaw Zelinski 10 maja 2018 at 22:03

    od nie­daw­na mamy UML v.2.5 , i na szczę­ście w koń­cu wyru­go­wa­no poję­cie dzie­dzi­cze­nia z UML 🙂

  6. Jarosław Żeliński 29 września 2020 at 23:56

    Polecam nową pozycję:
    Ambra Molesini, Enrico Denti, & Andrea Omicini. (2021). MDE and MDA in a Multi- Paradigm Modeling Perspective (Y. Rhazali, Ed.). IGI Global. doi: 10.4018/978 – 1‑7998 – 3661‑2

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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