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/

Paradygmat obiektowy i Przypadki Użycia

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

Obiektowy paradygmat i pojęcie systemu

Słownik j.polskiego mówi:

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

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

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

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

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

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

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

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

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

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

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

Co piszą w sieci i książkach

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

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

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

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

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

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

Inny przy­kład:

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

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

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

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

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

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

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

Przypadki użycia – czym są?

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

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

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

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

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

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

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

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

Rozszerzenie (18.1.3.2. Extend) 

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

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

Włączenie (18.1.3.3 Includes)

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

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

Dwa klu­czo­we wnioski:

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

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

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

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

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

Decomposing Use Cases Towards Logical Architecture Design6

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

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

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

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

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

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

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

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

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

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

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

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

Żródła

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

Use Case 2.0

Wprowadzenie

Właśnie zosta­łem zapytany:

Witam Pana, czy inte­re­so­wał się Pan Use Case 2.0 ?

Tak. Od cza­su do cza­su wpa­da­ją mi w ręce takie opi­sy. Ta idea jest cie­ka­wym i prag­ma­tycz­nym podej­ściem do eta­pu doku­men­to­wa­nia zakre­su pro­jek­tu. Warto jed­nak pamię­tać, że przy­pad­ki uży­cia mają swój kon­tekst (są osa­dzo­ne) w tym co robią użyt­kow­ni­cy, bez tego kon­tek­stu są nie­ste­ty ryzy­kow­nym narzę­dziem, bo dekla­ra­tyw­nym (skąd wie­my, że oso­ba A ma coś robić sko­ro nie wie­my jak wyglą­da cały pro­ces biz­ne­so­wy, czy mamy pole­gać tyl­ko na subiek­tyw­nej dekla­ra­cji tej osoby?).

Dość czę­sto spo­ty­kam się z teza­mi, że uży­cie przy­pad­ków uży­cia nie wyma­ga mode­lo­wa­nia pro­ce­sów i odwrot­nie, albo że są to ?narzę­dzia? ofe­ru­ją­ce podob­ne lub takie same korzy­ści (źr.: Przypadki uży­cia czy model pro­ce­su, cze­go uży­wać?)

Niestety nie… Standardem jest wypro­wa­dza­nie (trans­for­ma­cja) przy­pad­ków uży­cia z mode­li pro­ce­sów biznesowych:

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. (źr.: Transformacja mode­lu pro­ce­sów biz­ne­so­wych na model przy­pad­ków uży­cia)

o czym pisa­łem tak­że przy oka­zji MDA.

Autor pyta­nia przy­wo­łał tę prezentację:

Autor pre­zen­ta­cji pisze, że są to te przy­pad­ki uży­cia, któ­re zna­my z UML i tak będę je tu trak­to­wał: na tle spe­cy­fi­ka­cji UML. Dodam, że od 2015 roku mamy UML 2.51, dość istot­nie odbie­ga­ją­cy od UML z roku 2011, gdy powsta­ła ta pre­zen­ta­cja (powyż­szy PDF pocho­dzi z 2012 roku, ale nie ma tu istot­nych róż­nić). Poniżej kil­ka klu­czo­wych tez tej pre­zen­ta­cji i moje komen­ta­rze, gdyż wokół przy­pad­ków uży­cia naro­sło wie­le nie­po­ro­zu­mień wyni­ka­ją­cych z bar­dzo popu­lar­nej książ­ki zaty­tu­ło­wa­nej Stosowanie przy­pad­ków uży­cia (Alistair Cockburn), któ­rej autor sam dekla­ru­je, że nie uzna­je nota­cji UML a przy­pad­ki uży­cia rozu­mie ina­czej, o czym nie­ste­ty wie­lu zapo­mi­na lub nie wie, pisa­łem o tym już w 2011 roku:

Przypadki uży­cia to temat nie­koń­czą­cych się debat. Diagram przy­pad­ków uży­cia może mieć swój począ­tek bez przy­pad­ków uży­cia (Udziałowcy pro­jek­tu?). Ale czym one, przy­pad­ki uży­cia, są? Alistair Cockburn jest ?use case guru? dla wie­lu ana­li­ty­ków i pro­jek­tan­tów, pisze: Wyróżniamy 3 pozio­my szcze­gó­ło­wo­ści przy­pad­ków uży­cia: (1) nie­for­mal­ny opis ? kil­ka luź­nych zdań ogól­nie opi­su­ją­cych przy­pa­dek, (2) for­mal­ny opis ? kil­ka para­gra­fów, pod­su­mo­wa­nie, (3) pełen opis ? for­mal­ny doku­ment. (ŹR : Przypadki uży­cia sys­te­mu czy­li co?)

Ale po kolei…

Przypadki użycia

Skalowanie

Czym tu jest ska­lo­wal­ność? Chyba tyl­ko tym, że doku­men­ta­cja UC rośnie linio­wo w mia­rę ich przy­ro­stu, jed­nak nie jest praw­dą, że zło­żo­ność sys­te­mu linio­wo opi­su­ją przy­pad­ki uży­cia (o czym pisa­łem tu: Przypadki uży­cia nie zna­ją swo­jej reali­za­cji) . Warto pamię­tać, że czym innym jest sys­tem pozwa­la na zarzą­dza­nie kar­to­te­ka­mi ksią­żek w biblio­te­ce” a sys­tem pozwa­na na zamia­nę obra­zu tek­stu na plik rtf (czy­li OCR)”.

Historia

Warto pamię­tać, że przy­pad­ki uży­cia, jako tech­ni­ka opi­su, mają swój rodo­wód w cza­sach ana­li­zy struk­tu­ral­nej (lata 80’te). Do UML zosta­ły włą­czo­ne, gdy ten powsta­wał w 1996 roku, jed­no­cze­śnie zosta­ły uży­te w meto­dy­ce Rational Unified Process prze­ję­tej (RUP) z jej auto­rem (Kruchten) w 1998 roku przez IBM. Tu też powsta­ły wyna­laz­ki” takie jak sys­te­mo­we czy biz­ne­so­we przy­pad­ki uży­cia, któ­rych nigdy nie było w for­mal­nym UML.

Obecnie mamy UML v.2.5.1. i przy­pad­ki uży­cia (UC) nadal i co do zasa­dy, to spe­cy­fi­ka­cja wyma­gań1 (spe­cy­fi­ka­cja sys­te­mu) pisa­na z per­spek­ty­wy sys­te­mu czy­li opi­su­je­my to co i jak sys­tem ma robić, a nie to do cze­go posłu­ży:

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.

Przypadki uży­cia jako dia­gram, to (powi­nien być) pro­sty sche­mat blo­ko­wy obra­zu­ją­cy abs­trak­cję mode­lo­wa­ne­go sys­te­mu (sub­ject) oraz usłu­gi jakie ofe­ru­je (Use Case) zewnętrz­nym bytom, jaki­mi są korzy­sta­ją­cy z jego (sys­te­mu) usług ludzie i inne sys­te­my (actor).

Na slaj­dzie 6, ude­rzy­ła mnie teza, że UC to tak­że mode­lo­wa­nie dzie­dzi­ny sys­te­mu, co jest nie­ste­ty nie­praw­dą, mając na uwa­dze spe­cy­fi­ka­cję UML, tym bar­dziej, że autor tej pre­zen­ta­cji tak­że ją przy­wo­łu­je. Dziedzina sys­te­mu to poję­cia i regu­ły (logi­ka), a gdzie w UC miej­sce na logi­kę (pamię­ta­my, że w UML mamy jesz­cze dia­gra­my klas i sekwencji)?

Use Case 2.0

Jeżeli autor uwa­ża, że UC moż­na przed­sta­wić na dia­gra­mie UML to zna­czy, że zna i akcep­tu­je regu­ły tej nota­cji. Czy UC to tyl­ko opi­so­wa wer­sja wyma­gań? W UML przy­pad­ki uży­cia są koja­rzo­ne w ich sce­na­riu­sza­mi (dia­gram sekwen­cji). Jest to opis ale for­mal­ny, nie mniej jed­nak więk­szość chy­ba narzę­dzi CASE (Computer Aided System Engineering) pozwa­la opi­sać UC pro­zą” na począ­tek. Niewątpliwie jest zale­tą to, że poziom i jakość opi­su moż­na dosto­so­wać do eta­pu pro­jek­tu oraz wie­dzy adre­sa­ta dokumentacji.

Niewątpliwą zale­tą sto­so­wa­nia tych dia­gra­mów, jest to że są zro­zu­mia­łe dla zama­wia­ją­ce­go (spon­so­ra pro­jek­tu), o ile oczy­wi­ście nie nad­uży­je­my sym­bo­li i wyobraź­ni np. trak­tu­jąc jako UC każ­de­go tknię­cia kla­wia­tu­ry, np. UC jako sys­tem po klik­nię­ciu pra­wym kla­wi­szem myszy wyświe­tla opa­da­ją­ca listę kon­tra­hen­tów”, co jest kom­plet­nym nie­po­ro­zu­mie­niem, to jest co naj­wy­żej ele­ment sce­na­riu­sza UC.

Slajd 11 zwra­ca uwa­gę na waż­ną rzecz: odej­ście (lub wska­za­nie, że to zła prak­ty­ka) od dłu­gich warian­to­wych UC. UC jest defi­nio­wa­ny sta­nem począt­ko­wym i koń­co­wym, zaś sce­na­riu­szy – warian­to­wych – przej­ścia od począt­ku do koń­ca, może być wię­cej niż jeden, takie podej­ście po pierw­sze bar­dzo uprasz­cza doku­men­ta­cję, po dru­gie uła­twia zarzą­dza­nie imple­men­ta­cją (imple­men­to­wa­ne sce­na­riu­sze trak­to­wa­ne jako kolej­ne edy­cje two­rze­nia aplikacji) .

Praktyka

Ta pre­zen­ta­cja to kolej­ny przy­kład uzna­nia UC za tech­ni­kę zwin­ną, z czym tu się aku­rat zga­dzam: mało doku­men­ta­cji, zro­zu­mia­ła dla klien­ta, pozwa­la zarzą­dzać zakre­sem pro­jek­tu, da się mapo­wać na sprin­ty, backlog.

Ale był­bym bar­dzo ostroż­ny z uzna­niem, że UC to jed­nost­ki out­so­ur­cin­gu. Wzorzec pro­jek­to­wy mikro­ser­wi­sy sto­su­je­my tak, że każ­dy UC ma swo­ją imple­men­ta­cję (pamię­ta­my o her­me­ty­za­cji w meto­dach obiek­to­wych), jed­nak nie moż­na z góry uznać, że jakiś kom­po­nent nie będzie współużytkowany.

Podsumowanie

Prezentacja jest bar­dzo cie­ka­wa. Jest war­to­ścio­wa z dwóch głów­nych powo­dów: poka­zu­je, że UC to bar­dzo dobre narzę­dzie komu­ni­ka­cji oraz dobre narzę­dzie do zarzą­dza­nia zakre­sem i reali­za­cją pro­jek­tu. Pokazuje tak­że, że liczy się pro­sto­ta (jed­na z nie­licz­nych pre­zen­ta­cji, któ­ra cał­ko­wi­cie pomi­ja nie­po­trzeb­nie kom­pli­ku­ją­ce dia­gra­my, związ­ki extend i include).

Z dru­giej stro­ny był bym jed­nak bar­dzo ostroż­ny z utoż­sa­mia­niem use case z user sto­ry. Pierwsze mają ści­słą defi­ni­cję w UML, dru­gie to bar­dzo nie­for­mal­ne zapi­sy wizji użyt­kow­ni­ków. Tych dru­gich jest z regu­ły znacz­nie wię­cej, gdyż ope­ru­ją kon­tek­stem użytkownika:

  1. usłu­ga sys­te­mu kart biblio­tecz­nych (przy­pa­dek uży­cia): zarzą­dza­nie kar­ta­mi indek­so­wy­mi książek,
  2. kon­tekst użytkownika: 
    1. sprawdź auto­ra tytułu
    2. znajdź tytu­ły dla autora
    3. sprawdź datę wyda­nia tytułu
    4. sprawdź nazwę wydaw­cy tytułu

Jak widać, kon­tekst użyt­kow­ni­ka może istot­nie zafał­szo­wać zakres pro­jek­tu. Należy się wystrze­gać takich opi­sów, co do zasa­dy przy­pad­ki uży­cia opi­su­ją sys­tem z per­spek­ty­wy tego sys­te­mu a nie z per­spek­ty­wy akto­ra, co mam nadzie­ję tu poka­za­łem. Dlatego model przy­pad­ków uży­cia jest znacz­nie bez­piecz­niej­szy dla pro­jek­tu, jeże­li powsta­je jako trans­for­ma­cja mode­lu pro­ce­sów biz­ne­so­wych po usta­le­niu zakre­su projektu.

Generalnie idea uczy­nie­nia z przy­pad­ków uży­cia szkie­le­tu pro­jek­tu jest bar­dzo wygod­na, tym bar­dziej, że przy­sta­je do idei mikro­ser­wi­sów. Uznanie, że przy­pa­dek uży­cia, rozu­mia­ny jako usłu­ga apli­ka­cyj­na powią­za­na z okre­ślo­nym zesta­wem danych (dokument/formularz), jest jed­nost­ką wdro­że­nio­wą” z ewen­tu­al­ny­mi ite­ra­cja­mi (w pre­zen­ta­cji sli­ces), jest bar­dzo wygod­nym narzę­dziem zarzą­dza­nia zakre­sem pro­jek­tu. Załączam tak­że link do dokumentu: 

________________________________
1.
OMG? Unified Modeling Language? (OMG UML?) Version 2.5.1 OMG Document Number: formal/2017 – 12-05 Date: December 2017.

UML a modelowanie procesów biznesowych

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.

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 🙂

Przypadki użycia nie znają swoich realizacji…

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 …