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.5¹, 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ń¹ (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
   5. …

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: