Diagram przy­pad­ków uży­cia sta­le budzi wie­le kon­tro­wer­sji. Bywa, że nafa­sze­ro­wa­ny związ­ka­mi «inc­lu­de» i «exc­lu­de» wyglą­da jak talerz winogron.

Considering that the main ratio­na­le of use cases is to pro­vi­de a con­cep­tu­al brid­ge betwe­en busi­ness value and sys­tem capa­bi­li­ties, it’s not the role of busi­ness ana­ly­sts to weld the­ir con­cre­te, and spe­ci­fic requ­ire­ments into the con­si­stent and sta­ble func­tio­nal archi­tec­tu­re imple­men­ted by softwa­re clas­ses. (źr. Use Cases sho­uld know nothing abo­ut clas­ses | LinkedIn).

Powyższy cytat pocho­dzi z pew­nej dys­ku­sji. Świat się spie­ra” na temat tego do cze­go słu­ży dia­gram przy­pad­ków uży­cia. Dyskusja na LinkedIn poka­za­ła, że świat jest w tej kwe­stii podzie­lo­ny”. Skąd problem?

W 2011 roku napi­sa­łem, nie pierw­szy i pew­nie nie ostat­ni raz, że to ma być pro­sty dia­gram. Jego celem jest okre­śle­nie zakre­su pro­jek­tu w posta­ci, zro­zu­mia­łe­go dla zama­wia­ją­ce­go, dia­gra­mu poka­zu­ją­ce­go kto i do cze­go będzie uży­wał apli­ka­cji. I nic ponad to. NIe przy­pad­kiem jest czę­sto uzna­wa­ny za tak zwa­ny „[[model czar­nej skrzyn­ki]]”. Tak czę­sto spo­ty­ka­ne, mode­le nafa­sze­ro­wa­ne szcze­gó­ła­mi pro­jek­tu wywle­czo­ny­mi na wierzch z pomo­cą związ­ków «inc­lu­de» i «extend», sta­no­wią zbęd­ne (i przed­wcze­sne) ujaw­nia­nie archi­tek­tu­ry wewnętrz­nej, zaś dzie­dzi­cze­nie na tych dia­gra­mach to dla odmia­ny zbęd­ne wpla­ta­nie tu mode­li poję­cio­wych. Komplikowanie tego dia­gra­mu nisz­czy jego pod­sta­wo­wą rolę: kon­trakt zama­wia­ją­ce­go z dostaw­cą opro­gra­mo­wa­nia: zama­wia­ją­cy zawie­ra świa­do­mie ten kon­trakt gdy zro­zu­mie ten diagram.

…pro­ste jest pięk­ne: przy­pa­dek uży­cia to poje­dyn­cza, ele­men­tar­na kom­plet­na usłu­ga świad­czo­na przez System dla jego użyt­kow­ni­ka (czy­taj Przypadki uży­cia…).

Specyfikacja UML owszem zawie­ra opis, nie tyl­ko, związ­ków «inc­lu­de» i «extend» ale i dzie­dzi­cze­nia, nale­ży jed­nak pamię­tać, że spe­cy­fi­ka­cja zacho­wu­je kom­pa­ty­bil­ność wstecz (aż do lat 90-tych!) i to, że pomy­sło­daw­ca tego dia­gra­mu (obec­ny UML to zle­pek trzech nota­cji) nie znał dia­gra­mu klas, wiec musiał sobie jakość pora­dzić z poka­za­niem choć­by namiast­ki wewnętrz­nej struk­tu­ry apli­ka­cji. Dysponując jed­nak lep­szym do tego narzę­dziem, jakim jest dia­gram klas lub kom­po­nen­tów, kom­pli­ko­wa­nie dia­gra­mów przy­pad­ków uży­cia nie ma więk­sze­go sen­su. Polecam tu nie­daw­no napi­sa­ną recen­zje książ­ki UML for Java pro­gram­mers:

UMLforJavaProgrammersUseCases

Drugim powo­dem jest postę­pu­ją­ca stan­da­ry­za­cja mode­li poję­cio­wych róż­nych nota­cji rodem z OMG, mię­dzy inny­mi z powo­du rosną­ce­go zna­cze­nia (i korzy­ści z…) cało­ścio­we­go podej­ścia do mode­lo­wa­nia orga­ni­za­cji zwa­ne­go archi­tek­tu­rą kor­po­ra­cyj­na lub biz­ne­so­wą (lub po pro­tu [[podej­ściem sys­te­mo­wym do ana­li­zy orga­ni­za­cji]]). Ta stan­da­ry­za­cja to mię­dzy inny­mi zrów­na­nie” poję­cia aktyw­ność” w pro­ce­sie biz­ne­so­wym (BPMN) z poję­ciem Przypadek Użycia (UML), gdzie jest to ele­men­tar­na usłu­ga, wspie­ra­ją­ca aktyw­ność akto­ra, mają­ca stan począt­ko­wy i koń­co­wy (a pro­ces ma wej­ście i wyj­ście), stan koń­co­wy cechu­je okre­ślo­na war­tość dla akto­ra (UML) lub odbior­cy (BPMN), z poję­ciem usłu­ga apli­ka­cyj­na w archi­tek­tu­rze SOA (i w archi­tek­tu­rze korporacyjnej).

Obecnie przy­pad­ki uży­cia sta­no­wią pomost pomię­dzy per­spek­ty­wą biz­ne­so­wą widzą­ca przy­pad­ki uży­cia jako usłu­gi apli­ka­cji” a per­spek­ty­wą apli­ka­cji, któ­ra ofe­ru­je je (przy­pad­ki uży­cia) jako usłu­gi apli­ka­cyj­ne. Poniżej kla­sycz­ny”, od lat zna­ny, dia­gram obra­zu­ją­cy model SOA ([[Service Oriented Architecture]]):

SOA_OMG_model

Na tym dia­gra­mie widać (nie suge­ruj­my się kształ­tem ikon ;)) war­stwę Business Servces, któ­ra sta­no­wi ni mniej ni wię­cej tyl­ko wła­śnie przy­pad­ki uży­cia apli­ka­cji (Components) umiesz­czo­nych w war­stwie poni­żej. Na dzi­siaj pro­ce­sy biz­ne­so­we mode­lu­je­my nota­cją BPMN (twar­dzie­le nadal robią to dia­gra­mem aktyw­no­ści UML ;)), a resz­tę poni­żej nota­cją UML (mapu­jąc 1:1 ato­mo­we pro­ce­sy biz­ne­so­we na przy­pad­ki uży­cia, nie­któ­re pro­gra­my CASE robią to nawet automatycznie):

The most effec­ti­ve way to deve­lop a quali­ty softwa­re that can stre­am­li­ne and blend well with users» daily ope­ra­tions is to begin by ana­ly­zing users» daily work flows with care and pre­ci­sion and, to under­stand how par­ties work toge­ther to get jobs done. By doing so, you can find out the func­tions that the softwa­re sho­uld pro­vi­de in order to help the users. (From Business pro­cess to Use Case…)

Jeżeli nad pro­ce­sa­mi umie­ścić model moty­wa­cji biz­ne­so­wej (nota­cja BMM, nie ma tej war­stwy na powyż­szym dia­gra­mie) to otrzy­ma­my model archi­tek­tu­ry kor­po­ra­cyj­nej (po kil­ku pró­bach zasto­so­wa­nia nadal uwa­żam, że [[nota­cja ArchiMate]] nie wno­si żad­nej war­to­ści doda­nej, jest to – pomysł na nowa nota­cję – raczej zaprze­cze­niem zasa­dy nie mnóż bytów ponad potrze­bę” zna­nej jako [[brzy­twa Ockhama]]).

Jest tu jesz­cze jed­na cie­ka­wa rzecz: nie ma danych na tych mode­lach. Staromodne” podej­ście mówi, że opro­gra­mo­wa­nie to struk­tu­ry danych i funk­cje. I tak jest od stro­ny tech­nicz­nej ale to nie ma nic wspól­ne­go z biz­ne­sem. Biznes jest zain­te­re­so­wa­ny fak­tem sprze­da­ży, a to, że doku­men­tu­je­my do fak­tu­rą VAT to szcze­gó­ły”. Dlatego na tym pozio­mie abs­trak­cji (uogól­nie­nia) nie ma sen­su robie­nie mode­li danych, ma sens robie­nie spe­cy­fi­ka­cji obiek­tów biz­ne­so­wych, na pozio­mie ich nazw. Takie podej­ście nazy­wa się zarzą­dza­niem pozio­mem szcze­gó­ło­wo­ści pro­jek­tu (od ogó­łu do szcze­gó­łu), na pozio­mie mode­lo­wa­nia takiej archi­tek­tu­ry nie ma zna­cze­nia to, ile danych jest na fak­tu­rze, zna­cze­nie ma, to że zaist­niał fakt sprze­da­ży i na czymś (nośnik danych, obiekt bez­sen­so­wy z nazwą) go udokumentowano.

Tak więc na tytu­ło­we pyta­nie obec­nie nale­ża­ło by odpo­wie­dzieć: nie, przy­pad­ki uży­cia nie zna­ją swo­ich reali­za­cji… W doku­men­ta­cji na eta­pie mode­lo­wa­nia przy­pad­ków uży­cia, two­rzy­my pro­sty dia­gram zło­żo­ny z trzech typów ele­men­tów: aktor, przy­pa­dek i sys­tem. Bez pomi­ja­nia ele­men­tu sys­tem” (pro­sto­kąt będą­cy kon­te­ne­rem ma przy­pad­ki uży­cia), któ­ry sta­no­wi pod­sta­wę tego dia­gra­mu: wska­zu­je gra­ni­ce sys­te­mu. Jakiekolwiek szcze­gó­ły, w tym mode­le danych, to ostat­ni etap pra­cy jakim jest pro­jek­to­wa­nie i wyko­na­nie imple­men­ta­cji. Wszelkie bazy danych mode­lu­je­my na samym końcu.

Kolejny wnio­sek: przy­pad­ków uży­cia nie są set­ki a o rząd a nawet dwa rzę­dy mniej. Specyfikacje na set­ki przy­pad­ków uży­cia to jakieś total­ne nie­po­ro­zu­mie­nie (albo nie­zro­zu­mie­nie). Usługa apli­ka­cji świad­czo­na akto­ro­wi (kom­plet­na) to nie wsta­wie­nie adre­su na fak­tu­rze, a wysta­wie­nie (utwo­rze­nie) kom­plet­nej fak­tu­ry. Wstawianie adre­sów, pro­duk­tów itp. to ele­men­ty sce­na­riu­sza przy­pad­ku uży­cia (wywo­ła­nia na dia­gra­mie sekwen­cji albo opis współ­dzia­ła­nia akto­ra z ekra­nem aplikacji).

Nie ma też np. cze­goś takie­go jak „[[sys­te­mo­we przy­pad­ki uży­cia]]”, anie cze­go takie­go jak „[[biz­ne­so­we przy­pad­ki uży­cia]]” (to relikt z meto­dy­ki RUP z lat 90’tych przed poja­wie­niem się nota­cji BPMN). Wiem, wiem, że czę­sto się poja­wia­ją w lite­ra­tu­rze i na stro­nach zna­nych blo­gów, jed­nak nigdzie tam nie zna­la­złem defi­ni­cji tych pojęć odróż­nia­ją­cych te two­ry od nor­mal­nych” przy­pad­ków uży­cia, inter­fej­sów kom­po­nen­tów czy pro­ce­sów biz­ne­so­wych. Prowadzenie nowe­go poję­cia powin­no mieć jakieś pod­sta­wy i war­tość doda­ną bez tego są tyl­ko ury­wa­niem nie­zro­zu­mie­nia mode­lo­wa­nej isto­ty rze­czy i łama­niem zasa­dy eko­no­mii myśle­nia, tej pro­stej zasa­dy nie twórz bytów ponad mia­rę” (przy­po­mi­nam [[brzy­twa Ockhama]]) (nie­ste­ty fir­ma SPARX, pro­du­cent bar­dzo popu­lar­nej i taniej apli­ka­cji: Enterprise Architect, ma w zwy­cza­ju wymy­śla­nie róż­nych dziw­nych bytów tego typu, mię­dzy inny­mi czas jako aktor sys­te­mu” nada­jąc mu dedy­ko­wa­ny ste­reo­typ). Bo zasta­nów­cie się, gdzie na powyż­szym dia­gra­mie SOA wsta­wić owe sys­te­mo­we czy biz­ne­so­we przy­pad­ki użycia???

Owszem, moż­na przy­jąć dowol­na kon­wen­cję two­rze­nia mode­li ale wte­dy nale­ży ją opi­sać od stro­ny poję­cio­wej. Bez tego model sta­je się zwy­kłym obraz­kiem, nie jest mode­lem. Ale pyta­nie po co, sko­ro w BPMN/UML to wszyst­ko jest, wraz z opi­sem jak gład­ko” przejść z mode­lu biz­ne­so­we­go, przez model przy­pad­ków uży­cia do mode­lu archi­tek­tu­ry sys­te­mu… Owszem nota­cja UML zawie­ra wszyst­kie opi­sa­ne tu poję­cia i sym­bo­le, ale nie wol­no zapo­mi­nać, że nota­cja to wyłącz­nie język czy­li same sło­wa i gra­ma­ty­ka, sens maja dopie­ro zda­nia. Tak wiec pisząc Krowa z sil­ni­kiem odrzu­to­wym, jeli­ta na czer­wo­no, jądro­wy­mi kopy­ta­mi, wypra­wio­na na buty skó­ra, znisz­czy­ła metro, wypa­dek samo­cho­do­wy, prze­la­tu­jąc nad Warszawą, licz­ba płyt chod­ni­ko­wych to 1347, a następ­nie wylą­do­wa­ła w Elektrociepłowni Żerań, zała­du­nek węgla w połu­dnie wyko­na­ny przez Kowalskiego, i poży­wi­ła się węglem popi­ja­jąc wodę z Wisły” to popraw­ne gra­ma­tycz­nie, bez­błęd­nie napi­sa­ne zda­nie w języ­ku pol­skim, ale nikt nie ma chy­ba wąt­pli­wo­ści, że kom­plet­nie pozba­wio­ne sen­su. Tak samo moż­na popraw­nie, zgod­nie z zasa­da­mi nota­cji, nary­so­wać dia­gram UML …

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 6 komentarzy

  1. Piotr

    «sko­ro w BPMN/UML to wszyst­ko jest, wraz z opi­sem jak ?gład­ko? przejść z mode­lu biz­ne­so­we­go, przez model przy­pad­ków uży­cia do mode­lu archi­tek­tu­ry systemu?»

    A gdzie to jest opi­sa­ne moż­na wiedzieć?

    1. Jaroslaw Zelinski

      Gładkość przej­ścia to nie to samo co algo­rytm na napi­sa­nie”… ana­li­za i pro­jek­to­wa­nie to sztu­ka. Jednak zasa­dy” są:
      – ato­mo­we pro­ce­sy to jeden to jed­ne­go przy­pad­ki użycia
      – nośni­ki danych do encje/agregaty w mode­lu dziedziny
      – regu­ły biz­ne­so­we to mecha­ni­zmy w mode­lu dziedziny

      A teraz pozo­sta­je tyl­ko sztu­ka zapro­jek­to­wa­nia” mode­lu dzie­dzi­ny speł­nia­ją­ce­go zasa­dy SOLID, szcze­gól­nie open clo­se prin­ci­pia”… (tu pole­cam wzor­ce projektowe)

  2. Piotr

    Nie koja­rzę takie­go poję­cia w BPMN jak ? «ato­mo­we pro­ce­sy». Są albo pro­ce­sy albo aktyw­no­ści (task, acti­vi­ti). To co to jest ów ato­mo­wy proces?

    1. Jaroslaw Zelinski

      Pojęcie Atomic Activity” jest zde­fi­nio­wa­ne w dodat­ku C w Specyfikacji BPMN (Business Process Model and Notation, v2.0.2, p. 499). Atomowy pro­ces to aktyw­ność ato­mo­wa” i jej pro­dukt (patrz doda­tek C i defi­ni­cja poję­cia Business Process).

      To poję­cie z dzie­dzi­ny zarzą­dza­nia: ato­mic busi­ness pro­cess” to nie­po­dziel­ny pro­ces biz­ne­so­wy, aktyw­ność z jej wej­ściem i wyj­ściem. Innymi sło­wy, jeże­li robi­my na kil­ku pozio­mach abs­trak­cji (szcze­gó­ło­wo­ści) mode­le pro­ce­sów to naj­niż­szy poziom to ato­mo­we pro­ce­sy biz­ne­so­we”. Tu zresz­tą jest masa nieporozumień. 

      Proces biz­ne­so­wy ma swo­ja uzna­ną w nor­mach ISO defi­ni­cje (aktyw­ność prze­kształ­ca­ją­ca stan wej­ścia w stan wyj­ścia będą­cy uży­tecz­nym dla klien­ta pro­duk­tem). W BPMN każ­da kon­struk­cja wej­scie-aktyw­ność-wyj­ście (gdzie wej­ście i wyj­ście to dane) jest taki ato­mo­wym pro­ce­sem. Zwracam uwa­gę, w BPMN pro­ce­sem biz­ne­so­wym jest każ­dy dia­gram a nie to co powyżej. 

      Studiując lite­ra­tu­rę z OMG dowie się Pan, że poję­cia przy­pa­dek uży­cia to wła­śnie taki ato­mo­wy pro­ces z per­spek­ty­wy użyt­kow­ni­ka (np. nowa fak­tu­ra. Nie jest taki pro­ce­sem np. wsta­wie­nie pro­duk­tu do fak­tu­ry” bo jest to albo krok pro­ce­du­ry fak­tu­ro­wa­nia (np. w sys­te­mie zarzą­dza­nia jako­ścią ISO) albo krok sce­na­riu­sza tego przy­pad­ku użycia. 

      Nie ma sen­su model, w któ­rym wysta­wie­nie fak­tu­ry jest mode­lo­wa­ne wie­lo­ma przy­pad­ka­mi uży­cia (mimo, że przy­kła­dów takich są set­ki w sie­ci i w książ­kach a nawet na wie­lu szko­le­niach). Jest to kom­plet­ne nie­zro­zu­mie­nie tego czym jest model biz­ne­so­wy czy model opro­gra­mo­wa­nia. Żadna nota­cja nie narzu­ca tu gra­da­cji, ani BPMN ani UML, gra­da­cję narzu­ca sens biz­ne­so­wy i architektoniczny.

    2. Jaroslaw Zelinski

      ato­mo­wy pro­ces biz­ne­so­wy” spo­tkać moż­na w lite­ra­tu­rze tak­że pod nazwą ele­men­tar­ny pro­ces biz­ne­so­wy” skr. EBP, (Craig Larman, UML i wzor­ce pro­jek­to­we”, któ­ry doda­je w swo­jej książ­ce tak­że, że EBP jest reali­zo­wa­ny przez jeden przy­pa­dek użycia).

Dodaj komentarz

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