Kilka post\u00f3w wcze\u015bniej wspomnia\u0142em o tym, \u017ce nie cierpi\u0119 diagram\u00f3w przypadk\u00f3w u\u017cycia. Skrytykowa\u0142em to narz\u0119dzie m.in. za, ukrywanie tego czym przypadki u\u017cycia naprawd\u0119 s\u0105. Nie wspomnia\u0142em jednak czym w\u0142a\u015bciwie s\u0105 te przypadki u\u017cycia. Poj\u0119cie jest znane od przynajmniej kilkunastu lat (1994?), czy jednak wszyscy u\u017cywaj\u0105cy tego pomys\u0142u wiedz\u0105 o co chodzi? Postaram si\u0119 w skr\u00f3cie opowiedzie\u0107 jak ja pos\u0142uguj\u0119 si\u0119 przypadkami u\u017cycia. Dzi\u015b skupi\u0119 si\u0119 raczej na tym jak zastosowa\u0107 przypadki u\u017cycia, jak je rozumie\u0107. Do tego jak je opisa\u0107 wr\u00f3c\u0119, mam nadziej\u0119, w kt\u00f3rym\u015b z kolejnych wpis\u00f3w.<\/p>\n
Zacznijmy od ustalenia podstawowej informacji \u2013 co to jest przypadek u\u017cycia. Sformu\u0142owanie niby proste, ale jednak na tyle p\u0142ynne \u017ce konieczne jest ustalenie sensownej definicji. Niestety obja\u015bnienia typu \u201eprzypadek u\u017cycia to opis wymagania\u201d, albo \u201eprzypadek u\u017cycia to przyk\u0142ad u\u017cycia systemu\u201d nie s\u0105 ani dobre ani wystarczaj\u0105ce. Moja, cho\u0107 oparta na \u201eWriting effective use cases\u201d, definicja UC brzmi tak:<\/p>\n
Przypadek u\u017cycia to plan zastosowania systemu do realizacji (osi\u0105gni\u0119cia) celu<\/p><\/blockquote>\n
lub, bardziej og\u00f3lnie<\/p>\n
Przypadek u\u017cycia to plan realizacji (osi\u0105gni\u0119cia) celu<\/p><\/blockquote>\n
Od razu zak\u0142adam, \u017ce nie jest to jedyna s\u0142uszna definicja, \u017ce nie istnieje inny spos\u00f3b interpretacji tego poj\u0119cia. R\u00f3wnie dobrze, mo\u017cna pracowa\u0107 wg innego sformu\u0142owania i uzyska\u0107 poprawne rezultaty. Jednak ustalenie co rozumiemy przez use case jest kluczowe do poprawnego zanalizowania problemu.<\/p>\n
Wracaj\u0105c do tematu \u2013 definicja definicj\u0105, ale co to znaczy? Ma\u0142a analiza powinna pom\u00f3c, ustalmy wi\u0119c jak nale\u017cy rozumie\u0107 u\u017cyte w definicji s\u0142owa. Zacznijmy od okre\u015blenia poj\u0119cia cel. Zwracam uwag\u0119, \u017ce w drugiej wersji definicji, nie pojawia si\u0119 s\u0142owo \u201esystem\u201d i to jest kluczowe do zrozumienia co znaczy cel. Cel to rezultat, efekt(a tak\u017ce cz\u0119\u015bciowy rezultat), kt\u00f3rego osi\u0105gni\u0119cie ma znaczenie dla uczestnik\u00f3w1<\/a><\/sup>, przynosi im jak\u0105\u015b korzy\u015b\u0107, ma znaczenie w kontek\u015bcie dziedziny\/biznesu. Cel \u201eznajduje si\u0119\u201d poza systemem \u2013 czyli osi\u0105gni\u0119cie go ma wp\u0142yw na otoczenie samego systemu, a nawet (teoretycznie) do osi\u0105gni\u0119cia celu nie jest konieczna aplikacja (ta konkretna i tak w og\u00f3le). Jak ju\u017c wspomnia\u0142em, cel ma znaczenie dla uczestnik\u00f3w w otoczeniu systemu, jednak niekt\u00f3rzy z nich s\u0105 bardziej zwi\u0105zani z nim, s\u0105 aktorami. Zwi\u0105zek mi\u0119dzy aktorem i przypadkiem u\u017cycia nie jest tak do ko\u0144ca oczywisty i prosty, mo\u017ce przyj\u0105\u0107 r\u00f3\u017cne poziomy. Jednak w moim opisie najwa\u017cniejsze s\u0105 dwa poziomy: pierwszy z nich, aktor g\u0142\u00f3wny, okre\u015bla aktora wykonuj\u0105cego wskazany przypadek u\u017cycia, czyli t\u0105 osob\u0119 kt\u00f3ra siedzi przed ekranem i doprowadza do zrealizowania celu. Drugi z poziom\u00f3w, interesariusz2<\/a><\/sup>, okre\u015bla dla kogo ma znaczenie osi\u0105gni\u0119cie, lub nie osi\u0105gni\u0119cie, celu. Chocia\u017c w mojej definicji przypadk\u00f3w u\u017cycia, aktorzy nie pojawiaj\u0105 si\u0119, s\u0105 jednak bardzo istotnym ich elementem, pozwalaj\u0105cym odkry\u0107 w\u0142a\u015bciwe przypadki u\u017cycia i ustali\u0107 czy we w\u0142a\u015bciwy spos\u00f3b zosta\u0142y opisane.<\/p>\n
Kolejny punkt definicji \u2013 plan. Zastanawia\u0142em si\u0119 d\u0142u\u017csz\u0105 chwil\u0119, jakiego s\u0142owa najlepiej tu u\u017cy\u0107. Scenariusz \u2013 typowe okre\u015blenie u\u017cywane w tym miejscu podczas opisywania idei przypadk\u00f3w u\u017cycia \u2013 nie do ko\u0144ca mi odpowiada, bo sugeruje \u017ce jest to liniowy opis \u201edialogu\u201d, jak w sformu\u0142owaniu \u201escenariusz filmowy\u201d. W potocznym rozumieniu, scenariusz <\/em>posiada tylko jedn\u0105 drog\u0119 od pocz\u0105tku do ko\u0144ca, nie ma alternatywnych \u015bcie\u017cek, r\u00f3\u017cnych zako\u0144cze\u0144, warunkowych zdarze\u0144, nietypowych sytuacji. Plan jest zdecydowanie lepszym okre\u015bleniem, bo sugeruje \u017ce mo\u017ce istnie\u0107 wiele \u015bcie\u017cek, dr\u00f3g, mo\u017cliwe s\u0105 r\u00f3\u017cne zako\u0144czenia (punkty docelowe) jak w planie dzia\u0142a\u0144 czy planie drogowym. I tak w\u0142a\u015bnie nale\u017cy rozumie\u0107 sformu\u0142owanie \u201eprzypadek u\u017cycia to plan\u201d – UC jest opisem \u015bcie\u017cek, dr\u00f3g, prowadz\u0105cych od rozpocz\u0119cia przypadku u\u017cycia (punkt startu) do osi\u0105gni\u0119cia celu, czyli zako\u0144czenia.<\/p>\n
Zako\u0144czenie, czyli osi\u0105gni\u0119cie celu. W ten oto spos\u00f3b dotarli\u015bmy do kolejnego elementu definicji \u2013 realizacja. Zako\u0144czenie przypadku mo\u017ce by\u0107 pozytywne, gdy cel zosta\u0142 osi\u0105gni\u0119ty, lub negatywne, gdy cel nie zosta\u0142 zrealizowany. Poniewa\u017c przypadki u\u017cycia znajduj\u0105 si\u0119 bardziej w obszarze dziedziny a nie systemu (patrz co oznacza cel), s\u0105 form\u0105 opisu interfejsu3<\/a><\/sup> mi\u0119dzy systemem a u\u017cytkownikiem, czy te\u017c otoczeniem, procesem biznesowym4<\/a><\/sup>, wi\u0119c realizacja musi by\u0107 opisywana z punktu widzenia aktora a nie systemu. Czyli opis jak aktor mo\u017ce wykorzysta\u0107 system do osi\u0105gni\u0119cia celu a nie jak system b\u0119dzie w tle przeprowadza\u0142 prace. W opisie przypadku u\u017cycia nie powinny pojawi\u0107 si\u0119 informacje o sposobie zrealizowania przypadku u\u017cycia przez system. M\u00f3wi\u0105c w skr\u00f3cie, gdy my\u015blimy o przypadkach u\u017cycia to system ma by\u0107 dla nas czarn\u0105 skrzynk\u0105, kt\u00f3rej zawarto\u015b\u0107 nas nie interesuje5<\/a><\/sup>.<\/p>\n
Kiedy ju\u017c wiemy co znaczy definicja to powiem, \u017ce nie nale\u017cy si\u0119 jej trzyma\u0107. \u015aci\u015ble. M\u00f3wi\u0105c o celu wspomnia\u0142em, \u017ce powinien by\u0107 poza systemem, jednak czasem warto poluzowa\u0107 regu\u0142y i dopu\u015bci\u0107 tak\u017ce wersj\u0119 celu systemowego, kt\u00f3rego osi\u0105gni\u0119cie daje efekt tylko w kontek\u015bcie systemu. Sztandarowym, u\u017cywanym w ka\u017cdej ksi\u0105\u017cce przyk\u0142adem, jest oczywi\u015bcie \u201eU\u017cytkownik loguje si\u0119\u201d. Ma sens tylko w systemie, tylko tu jego prawid\u0142owa realizacja da sensowny efekt. Nale\u017cy jednak pami\u0119ta\u0107 o dw\u00f3ch rzeczach \u2013 wyra\u017anym zaznaczeniu poziomu przypadku u\u017cycia i \u015bcis\u0142ym stosowaniu definicji celu przy pierwszym cyklu identyfikacji wymaga\u0144 do systemu \u2013 tu nale\u017cy my\u015ble\u0107 o celach tylko jako \u201edo czego mog\u0119 u\u017cy\u0107 systemu\u201d.<\/p>\n
Ca\u0142y powy\u017cszy wyw\u00f3d ma na celu ustalenie CO oznaczaj\u0105 przypadki u\u017cycia a nie JAK wygl\u0105daj\u0105. Ustalenie jednej, sp\u00f3jnej i sensownej definicji przypadk\u00f3w u\u017cycia umo\u017cliwia ich poprawne zidentyfikowanie. Oczywi\u015bcie, przypadki u\u017cycia stworzone na podstawie om\u00f3wionej definicji, b\u0119d\u0105 do\u015b\u0107 proste. Definicja pomija sporo wa\u017cnych element\u00f3w odr\u00f3\u017cniaj\u0105cych dobre przypadki u\u017cycia od z\u0142ych. W realnych zastosowaniach, opis przypadk\u00f3w mo\u017ce i powinien by\u0107 uzupe\u0142niony o niezb\u0119dne szczeg\u00f3\u0142y, jak np. warunki brzegowe (wej\u015bcia i wyj\u015bcia), wyzwalacze, sformalizowany opis planu dzia\u0142a\u0144. Chcia\u0142em jednak skupi\u0107 si\u0119 na tym czym s\u0105 przypadki u\u017cycia i opisa\u0107 to maksymalnie prosto. Dlatego te\u017c stara\u0142em si\u0119 nie porusza\u0107 tematu formy opisu przypadk\u00f3w. Rozpocz\u0119cie od ustalenia jak rozumiemy przypadki u\u017cycia, znaczenie u\u0142atwia ich identyfikacj\u0119, jest niezb\u0119dne do stworzenia listy zada\u0144 realizowanych przez projektowany system. W kolejnych wpisach chcia\u0142bym poruszy\u0107 temat formy opisu przypadk\u00f3w u\u017cycia a przede wszystkim przedstawi\u0107 kilka praktycznych przyk\u0142ad\u00f3w.<\/p>\n
\n<\/div>\n\n
- u\u017cytkownik\u00f3w, os\u00f3b dzia\u0142aj\u0105cych w otoczeniu systemu ↩<\/a><\/span><\/li>\n
- du\u017co bardziej podoba mi si\u0119 angielskie okre\u015blenie stakeholder \u2013<\/em> jest proste, \u0142atwo zrozumia\u0142e, du\u017co powszechniej u\u017cywane, zw\u0142aszcza w j\u0119zyku biznesowym; jednak nie ma w j. Polskim \u0142adnego odpowiednika, musimy wi\u0119c u\u017cywa\u0107 takiej nowomowy ↩<\/a><\/span><\/li>\n
- W znaczeniu – \u201epunkt styku\u201d a nie GUI ↩<\/a><\/span><\/li>\n
- Oczywi\u015bcie nie zawsze i nie wy\u0142\u0105cznie ↩<\/a><\/span><\/li>\n
- j.w. ↩<\/a><\/span><\/li>\n<\/ol>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Kilka post\u00f3w wcze\u015bniej wspomnia\u0142em o tym, \u017ce nie cierpi\u0119 diagram\u00f3w przypadk\u00f3w u\u017cycia. Skrytykowa\u0142em to narz\u0119dzie m.in. za, ukrywanie tego czym przypadki u\u017cycia naprawd\u0119 s\u0105. Nie wspomnia\u0142em jednak czym w\u0142a\u015bciwie s\u0105 te przypadki u\u017cycia. Poj\u0119cie jest znane od przynajmniej kilkunastu lat (1994?), czy jednak wszyscy u\u017cywaj\u0105cy tego pomys\u0142u wiedz\u0105 o co chodzi? Postaram si\u0119 w skr\u00f3cie … Czytaj dalej Przypadki u\u017cycia<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[8,17,16],"class_list":["post-132","post","type-post","status-publish","format-standard","hentry","category-analiza","tag-przypadki-uzycia","tag-uc","tag-use-case"],"_links":{"self":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/132","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/comments?post=132"}],"version-history":[{"count":20,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/132\/revisions"}],"predecessor-version":[{"id":397,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/132\/revisions\/397"}],"wp:attachment":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/media?parent=132"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/categories?post=132"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/tags?post=132"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}