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.

Przypadki użycia systemu czyli co?

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życia:

  1. nie­for­mal­ny opis ? kil­ka luź­nych zdań ogól­nie opi­su­ją­cych przypadek
  2. for­mal­ny opis ? kil­ka para­gra­fów, podsumowanie
  3. pełen opis ? for­mal­ny dokument

Przypadek uży­cia (źr. WIKI) powinien:

  1. opi­sy­wać w jaki spo­sób sys­tem powi­nien być uży­wa­ny przez akto­ra w celu osią­gnię­cia kon­kret­ne­go celu
  2. być pozba­wio­ny szcze­gó­łów doty­czą­cych imple­men­ta­cji oraz inter­fej­su użytkownika
  3. opi­sy­wać sys­tem na wła­ści­wym pozio­mie szczegółowości
Dalej mamy (Ian Sommerville) wymagania:
  1. Functional requ­ire­ments: Statements of servi­ces the sys­tem sho­uld pro­vi­de, how the sys­tem sho­uld react to par­ti­cu­lar inputs and how the sys­tem sho­uld beha­ve in par­ti­cu­lar situations.
  2. Non-func­tio­nal requ­ire­ments: Constraints on the servi­ces or func­tions offe­red by the sys­tem such as timing con­stra­ints, con­stra­ints on the deve­lop­ment pro­cess, stan­dards, etc.
  3. Domain requ­ire­ments: Requirements that come from the appli­ca­tion doma­in of the sys­tem and that reflect cha­rac­te­ri­stics of that domain.

Definicja Sommerville’a, wyma­gań funk­cjo­nal­nych: wyma­ga­nie funk­cjo­nal­ne to usłu­ga świad­czo­na przez sys­tem. Jest to prak­tycz­nie toż­sa­me z defi­ni­cją przy­pad­ku uży­cia sys­te­mu (parz zakoń­cze­nie arty­ku­łu) i taki jest wła­śnie ich sens. Idąc tym tropem…

W 1986 Ivar Jacobson, infor­ma­tyk zaan­ga­żo­wa­ny w two­rze­nie [[Unified Modeling Language]] (UML) oraz [[Rational Unified Process]] (RUP) opi­sał tech­ni­kę do spe­cy­fi­ko­wa­nia przy­pad­ków uży­cia. Z począt­ku uży­wał okre­śleń: sce­na­riusz użyt­ko­wa­nia (usa­ge sce­na­rios) i przy­pad­ki użyt­ko­wa­nia (usa­ge case). I tu widzę świa­teł­ko w tune­lu. Wymagania są dzie­lo­ne na nastę­pu­ją­ce kate­go­rie (źr. WIKI):

  1. Wymagania funk­cjo­nal­ne opi­su­ją funk­cjo­nal­ność, któ­rą sys­tem ma reali­zo­wać, na przy­kład for­ma­to­wa­nie tek­stu lub modu­lo­wa­nie sygna­łu. Czasami są zna­ne jako możliwości.
  2. Wymagania poza­funk­cjo­nal­ne spe­cy­fi­ku­ją kry­te­ria osą­dza­nia dzia­ła­nia sys­te­mu. Są one zna­ne jako wyma­ga­nia jakościowe.
  3. Wymagania ogra­ni­czeń okre­śla­ją gra­ni­ce roz­wią­za­nia. Niezależnie od tego jak pro­blem jest roz­wią­za­ny, ogra­ni­cze­nia muszą być respektowane.

W 2006 roku napisałem:

Po wie­lu podej­ściach do two­rze­nia przy­pad­ków uży­cia uzna­łem, że nale­ży naj­pierw opi­sać co jest w ogó­le celem two­rze­nia tego sys­te­mu, co on ma wspo­ma­gać lub auto­ma­ty­zo­wać. Jak? Należy naj­pierw zamo­de­lo­wać tę wspo­ma­ga­ną czyn­ność w zupeł­nym ode­rwa­niu od sys­te­mów. Jak już zde­fi­niu­je­my i zop­ty­ma­li­zu­je­my samą czyn­ność moż­na zabie­rać się do wyszcze­gól­nia­nia przy­pad­ków uży­cia czy­li tak na praw­dę zapro­jek­to­wać tę ?dru­ga stro­nę lustra?. (Przypadki uży­cia i UML | Analiza biz­ne­so­wa i pro­jek­to­wa­nie – Jarosław Żeliński – blog).

Po kil­ku latach kolej­nych doświad­czeń upew­niam się, że 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. Usługa ta jed­nak może mieć warianty.

Przykład: jeże­li jakiś sys­tem, mie­dzy inny­mi, umoż­li­wia wpro­wa­dza­nie danych z for­mu­la­rza, wzo­rów for­mu­la­rza jest kil­ka­dzie­siąt to ile mamy przy­pad­ków uży­cia? Jeden, któ­ry pozwa­la na wpro­wa­dza­nie danych do jakie­goś” for­mu­la­rza, to jaki to jest for­mu­larz to para­metr. Scenariusz ma mię­dzy inny­mi krok: wyświetl for­mu­larz do wypeł­nie­nia. jaki for­mu­larz? Wynika to albo z kon­tek­stu, któ­ry może być efek­tem poprzed­nio wyko­na­nych ope­ra­cji albo z bez­po­śred­nie­go wybo­ru Aktora. Tak więc dobry pro­jekt raczej nie ma odręb­ne­go przy­pad­ku uży­cia dla każ­de­go wzo­ru for­mu­la­rza. Dobry pro­jekt ma jeden przy­pad­ku uży­cia, wzór for­mu­la­rza to efekt wybo­ru np. w poprzed­nim kro­ku. Jak taki przy­pa­dek uży­cia jest reali­zo­wa­ny? Opisze to kie­dyś 🙂 przy oka­zji wzor­ca Strategia i prak­tyk pro­jek­to­wa­nia DDD.

Jaki z tego ma poży­tek spon­sor pro­jek­tu? Koszt, pro­jekt ma kil­ka­na­ście lub kil­ka­dzie­siąt a nie set­ki przy­pad­ków uży­cia i jest łatwiej­szy w implementacji.

A gdzie przy­pad­ki sys­te­mo­we? Nie ma takich. Pojęcie Aktora ma jasną defi­ni­cję (oso­ba lub inny sys­tem mają­cy inte­rak­cję z Systemem), poję­cie przy­pad­ku uży­cia tak­że (spe­cy­fi­ka­cja dzia­łań Systemu w odpo­wie­dzi na dzia­ła­nia akto­ra lub inne­go pod­mio­tu zain­te­re­so­wa­ne­go” Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych defi­ni­cji nie tyl­ko psu­je stan­dard bo nie pasu­je do spój­nej prze­strze­ni nazw. Wymyślanie swo­ich zna­czeń po pro­tu psu­je zro­zu­mia­łość, nisz­czy role komu­ni­ka­cyj­ną mode­li (języ­ka ich two­rze­nia). Niestety Pan Cockbourn jest w moich oczach takim dora­bia­czem” i psu­ją­cym sens pro­ste­go i jak widać trud­ne­go zara­zem, narzę­dzia jakim jest model przy­pad­ków uży­cia systemu.

O tym jak moż­na psuć i kom­pli­ko­wać pro­ste rze­czy (Pan Cockbourn) napi­sa­łem w Po brzy­twie… (dia­gram poni­żej to wręcz antyw­zo­rzec… 😉 a widu­je takie nie­ste­ty w pro­jek­tach). Zaryzykuję nawet tezę, że ktoś kto popra­wia wypra­co­wa­ny sys­tem poję­cio­wy jakim jest np. UML po pro­stu nie rozu­mie ani tego sys­te­mu ani tego czym jest sys­tem poję­cio­wy i język mode­lo­wa­nia. UML, owszem, moż­na roz­sze­rzać (ste­reo­ty­py), ale to wyma­ga zro­zu­mie­nia go, bo samo mno­że­nie ste­reo­ty­pów bez zacho­wa­nia pew­nych zasad rzą­dzą­cych prze­strze­nią nazw jaką się UML, pro­wa­dzi to bełkotu.

Mnożenie bytów na dia­gra­mach to poniż­sza „[[pusz­ka pan­do­ry]]”. Za coś podob­ne­go jak poni­żej nie płacimy!