u\u017cycia, a w\u0142a\u015bciwie z UML-owym diagramem przypadk\u00f3w u\u017cycia.<\/p>\n
Na pocz\u0105tek ma\u0142e zastrze\u017cenie: m\u00f3wi\u0119 o diagramach przypadk\u00f3w u\u017cycia<\/strong> a nie przypadkach u\u017cycia<\/strong>. Przypadki u\u017cycia to ca\u0142kiem niez\u0142e narz\u0119dzie, kt\u00f3remu po\u015bwi\u0119c\u0119 troch\u0119 uwagi dalej. Zwracam te\u017c uwag\u0119, \u017ce m\u00f3wi\u0119 tu o czystym UMLu, bez wchodzenia w tematyk\u0119 metodologii, framework\u00f3w modeli itp. Wracaj\u0105c do naszych dzisiejszych bohater\u00f3w – s\u0105dz\u0119, \u017ce diagramy przypadk\u00f3w to bardzo niebezpieczne narz\u0119dzie, kt\u00f3re mo\u017ce \u0142atwo wyrz\u0105dzi\u0107 wi\u0119cej szk\u00f3d ni\u017c przynie\u015b\u0107 po\u017cytk\u00f3w.<\/p>\n Przy pierwszym zetkni\u0119ciu si\u0119 z UMLem dostajemy informacj\u0119 „(model) diagram przypadk\u00f3w u\u017cycia s\u0142u\u017cy do opisu wymaga\u0144”<\/em>. Komunikat jest tym wyra\u017aniejszy im komunikuj\u0105cy ma wi\u0119kszy zwi\u0105zek ze standardem lub mniejsze do\u015bwiadczenia praktyczne. Co prawda coraz cz\u0119\u015bciej wspomina si\u0119 \u017ce „model wymaga\u0144” musi zosta\u0107 uzupe\u0142niony takimi rzeczami jak opis scenariuszy, warunk\u00f3w brzegowych, wsp\u00f3\u0142dzia\u0142ania ze sob\u0105 i dostarczanych warto\u015bci. Jednak informacja jak\u0105 si\u0119 otrzymuje prowadzi do wniosku, \u017ce\u00a0 diagram UC to g\u0142\u00f3wny spos\u00f3b analizy i zapisu wymaga\u0144, do kt\u00f3rego mo\u017cna ewentualnie, jak kto\u015b chce, doda\u0107 inne elementy jak kto\u015b chce. Oczywi\u015bcie na dodatki nigdy nie ma czasu ani zasob\u00f3w, a \u017ce sprawa jest za\u0142atwiona bo „mamy przecie\u017c ju\u017c diagram przypadk\u00f3w u\u017cycia”, to na nich si\u0119 poprzestaje.<\/p>\n W efekcie powstaj\u0105 „opisy” wymaga\u0144, sk\u0142adaj\u0105ce si\u0119 z rysunk\u00f3w pe\u0142nych jajeczek i ludzik\u00f3w z patyczk\u00f3w kt\u00f3re w zasadzie nie wnosz\u0105 \u017cadnej informacji a tylko zaciemniaj\u0105 obraz, bo<\/p>\n Typowy diagram UC wygl\u0105da tak – par\u0119 ludzik\u00f3w z patyk\u00f3w, czasem jeszcze powi\u0105zanych dziedziczeniem(!?), troch\u0119 elips powi\u0105zanych kreskami z ludzikami (czasem z dodatkowym efektem „spagetti”) i troch\u0119 tekstu. Tekst najcz\u0119\u015bciej ogranicza si\u0119 do nazw przypadk\u00f3w u\u017cycia. Czyli: mamy spory rysunek, kt\u00f3rego istotna tre\u015b\u0107 ogranicza si\u0119 do kilku, 3-4 wyrazowych opis\u00f3w. Opis\u00f3w, kt\u00f3re ka\u017cdy z czytaj\u0105cych rozumie inaczej. Bo co w\u0142a\u015bciwie znaczy „wprowadzenie zam\u00f3wienia” albo „weryfikacja poprawno\u015bci wniosku”? Nawet je\u017celi mamy okre\u015blone z czego si\u0119 sk\u0142ada takie zam\u00f3wienie czy wniosek, to ka\u017cdy wyobrazi sobie inaczej scenariusz wprowadzania,warunki brzegowe, ograniczenia, warunki pocz\u0105tkowe itd. W efekcie przedstawiaj\u0105c wymagania wy\u0142\u0105cznie jako diagram przypadk\u00f3w u\u017cycia, uzyskujemy taki rezultat – klient zamawia co\u015b, analityk opisuje co\u015b innego, a programista tworzy ca\u0142kiem co\u015b innego.<\/p>\n Do tego dochodzi jeszcze problem za\u015bmiecenia diagram\u00f3w przez zb\u0119dne lub ma\u0142o istotne elementy. Przyk\u0142ad – w zasadzie aktorzy, ich rodzaje, zale\u017cno\u015bci mi\u0119dzy nimi, s\u0105 ma\u0142o wa\u017cnymi elementami. Z punktu widzenia programisty czy u\u017cytkownika istotne jest CO system b\u0119dzie robi\u0142 (czyli jak UC dzia\u0142a) a nie kto b\u0119dzie z tego UC korzysta\u0142. Tego rodzaju informacja jest tak naprawd\u0119 istotna dla udzia\u0142owc\u00f3w lub w\u0142a\u015bcicieli biznesowych(podzia\u0142 zada\u0144), specjalist\u00f3w bezpiecze\u0144stwa i projektant\u00f3w GUI.<\/p>\n Podsumowuj\u0105c \u2013 mamy diagram na kt\u00f3rym zamieszczona jest w wi\u0119kszo\u015bci niepotrzebna lub nieistotna informacja, a istotne aspekty s\u0105 albo ukryte, albo nie s\u0105 w og\u00f3le opisane. W zasadzie sam pomys\u0142 diagramu przypadk\u00f3w u\u017cycia jako elementu UML jest kiepski. Taki troch\u0119<\/p>\n Po chwili zastanowienia si\u0119 wida\u0107, \u017ce ten rodzaj diagram\u00f3w nie spina si\u0119 z pozosta\u0142ymi, jest z troch\u0119 innej bajki. Pozosta\u0142e rodzaje diagram\u00f3w, w ten lub inny spos\u00f3b, s\u0105 ze sob\u0105 powi\u0105zane. W zasadzie dowolny element UMLa mo\u017cna powi\u0105za\u0107 z dowolnym klasyfikatorem(klasy maj\u0105 inne klasy, pakiety maj\u0105 klasy, klasy s\u0105 w komponentach, obiekty\/klasy maj\u0105 stany i przej\u015bcia mi\u0119dzy nimi, komponenty s\u0105 deployowane itd) i b\u0119dzie to mia\u0142o sens. Przypadki u\u017cycia w UML nie maj\u0105 prostego i \u015bcis\u0142ego powi\u0105zania z pozosta\u0142\u0105 cz\u0119\u015bci\u0105 modelu. Owszem mo\u017cna zdefiniowa\u0107 powi\u0105zanie UC z dowolnym klasyfikatorem, ale ju\u017c spos\u00f3b realizacji tego powi\u0105zania, jego znaczenie i sens jest s\u0142abo okre\u015blone (sformu\u0142owania typu „<\/em>can”, „may”, patrz: UML Superstructure str. 596). Do tego, ta definicja nie ma (przynajmniej w wi\u0119kszo\u015bci narz\u0119dzi) prostego sposobu prezentacji.<\/p>\n Przypadkom u\u017cycia brakuje konkretno\u015bci pozosta\u0142ych element\u00f3w UMLa, a raczej mo\u017cliwo\u015bci \u015bcis\u0142ego zdefiniowania. Tak w skr\u00f3cie – definicja UC nigdy nie mo\u017ce si\u0119 zbli\u017cy\u0107 szczeg\u00f3\u0142owo\u015bci\u0105 do np. definicji interfejsu. Pozosta\u0142e diagramy UMLowe mog\u0105 by\u0107 uzupe\u0142nione bardzo szczeg\u00f3\u0142owymi informacjami, ograniczeniami. W przypadku diagram\u00f3w UC nie da rady tego zrobi\u0107.<\/p>\n Z drugiej strony, w diagramach UC nie ma prostej, zdefiniowanej drogi pozwalaj\u0105cej odwzorowa\u0107 hierarchi\u0119 wymaga\u0144, r\u00f3\u017cne poziomy wymaga\u0144 (systemowy, biznesowy, funkcj\u0119). Diagram umo\u017cliwia powi\u0105zanie wzajemne UC ale raczej na jednym poziomie. W przypadku bardziej z\u0142o\u017conych system\u00f3w, wprowadza to spore ograniczenie lub wymusza kombinowanie, wprowadzanie w\u0142asnych rozszerze\u0144 lub interpretacji standardu UML.<\/p>\n Swoj\u0105 drog\u0105, z diagramami UC jest jestem powa\u017cny problem \u2013 UML nie wskazuje jak interpretowa\u0107 zapis, jak powi\u0105za\u0107 wymaganie z jego realizacj\u0105 (ale to jest problem ca\u0142ego UMLa – nie ma tak naprawd\u0119 semantyki i ma tak og\u00f3lny syntax \u017ce wszystko i nic mo\u017cna w nim napisa\u0107). 1<\/a><\/sup><\/p>\n Przede wszystkim \u2013 nale\u017cy wielkimi literami wypisa\u0107 sobie, \u017ce diagram UC nie s\u0142u\u017cy do zbierania wymaga\u0144. To jest tylko narz\u0119dzie (jedno z wielu) do wspierania tego\u017c zbierania. G\u0142\u00f3wna cz\u0119\u015b\u0107 zadania pt. \u201eanaliza wymaga\u0144\u201d odbywa si\u0119 ca\u0142kiem gdzie indziej, diagram UC mo\u017ce s\u0142u\u017cy\u0107 raczej do prezentacji, w skr\u00f3cony spos\u00f3b, informacji opisanych gdzie indziej. W wi\u0119kszo\u015bci przypadk\u00f3w nie jest jednak niezb\u0119dny lub mo\u017ce by\u0107 zast\u0105piony czym\u015b lepszym, bardziej dostosowanym do naszych potrzeb.<\/p>\n Kiedy ju\u017c sobie to u\u015bwiadomimy, mo\u017cna przej\u015b\u0107 dalej. Zapewne kto\u015b ju\u017c przed nami trafi\u0142 na taki problem, przemy\u015bla\u0142 go i co\u015b od siebie wyprodukowa\u0142 na ten temat. Warto sprawdzi\u0107 co s\u0105dz\u0105 inni, jak rozwi\u0105zali ten problem. Szcz\u0119\u015bliwi ci, kt\u00f3rzy wykorzystuj\u0105 gotow\u0105 metodologi\u0119 \u2013 tw\u00f3rcy wi\u0119kszo\u015bci z nich przemy\u015bleli problem zbierania wymaga\u0144 i w jaki\u015b spos\u00f3b odnie\u015bli si\u0119 do diagram\u00f3w UC, cho\u0107 nie zawsze uczynili to na wystarczaj\u0105cym poziomie szczeg\u00f3\u0142owo\u015bci. Niekt\u00f3rzy, jak tw\u00f3rcy i fanatycy metodyk \u201eagile\u201d, zignorowali to narz\u0119dzie, stwierdzaj\u0105c, \u017ce do niczego nie jest im potrzebne. <\/em>Inni, zw\u0142aszcza projektanci RUP, wr\u0119cz wprasowali diagramy UML na sta\u0142e w swoj\u0105 metodyk\u0119. Wi\u0119c w skr\u00f3cie \u2013 je\u017celi stosujesz ju\u017c jak\u0105\u015b gotow\u0105 metodyk\u0119, to prawie na pewno otrzyma\u0142e\u015b te\u017c sugestie dotycz\u0105ce sposob\u00f3w zastosowania diagram\u00f3w przypadk\u00f3w u\u017cycia.<\/p>\n Je\u017celi jednak, wskaz\u00f3wki czy sugestie zaproponowane przez metodyk\u0119 s\u0105 niewystarczaj\u0105ce, mo\u017cna przej\u015b\u0107 do czego\u015b bardziej konkretnego \u2013 framework\u00f3w modeli. Przyk\u0142adowy model matrycy Zachmana zawiera w sobie \u201e\u015bcie\u017ck\u0119\u201d wi\u0105\u017c\u0105c\u0105 wymagania biznesowe, cele, z wymaganiami systemowymi, ich realizacja i wdro\u017ceniem, wspieraj\u0105c si\u0119 (tu akurat zale\u017cy od implementacji) diagramami UML, w tym przypadk\u00f3w u\u017cycia. Podobnie inne standardy, szablony, frameworki takie jak np. TOGAF, wskazuj\u0105 i u\u0142atwiaj\u0105 zastosowanie diagram\u00f3w przypadk\u00f3w u\u017cycia w modelowaniu wymaga\u0144.<\/p>\n Id\u0105c krok dalej mo\u017cna jeszcze inaczej \u2013 opracowa\u0107 w\u0142asny spos\u00f3b zastosowania diagram\u00f3w przypadk\u00f3w u\u017cycia i trzyma\u0107 si\u0119 go. Tutaj drogi realizacji s\u0105 bardzo r\u00f3\u017cne \u2013 od ca\u0142kowitej rezygnacji z diagram\u00f3w UC do strategii szczeg\u00f3\u0142owego uzupe\u0142niania informacji przy u\u017cyciu innych element\u00f3w UMLa, jak np. diagramy stan\u00f3w, interakcji sekwencji itd. Mo\u017cna tak\u017ce wesprze\u0107 si\u0119 takimi koncepcjami jak schemat tekstowego opisu przypadk\u00f3w u\u017cycia zaproponowany przez Alistaira Cockburna, Xpowe scenariusze u\u017cytkownika.<\/p>\n Na koniec jeszcze troch\u0119 uwag o og\u00f3lnej sensowno\u015bci diagram\u00f3w przypadk\u00f3w u\u017cycia. Je\u017celi ju\u017c musimy ich u\u017cywa\u0107 to warto si\u0119 zastanowi\u0107 do czego. W mojej opinii to narz\u0119dzie dobrze nadaje si\u0119 do modelowania wymaga\u0144 systemowych, czyli ni\u017cszym ni\u017c faktycznie wymagania biznesowe. Na poziomie realizacji zaczynaj\u0105 nabiera\u0107 wi\u0119kszego sensu powi\u0105zania mi\u0119dzy przypadkami u\u017cycia, zale\u017cno\u015bci aktor\u00f3w od przypadk\u00f3w u\u017cycia. Do modelowania wymaga\u0144 biznesowych znacznie bardziej nadaje si\u0119 BPMN, opisy tekstowe, makiety(prototypy).<\/p>\n u\u017cycia, a w\u0142a\u015bciwie z UML-owym diagramem przypadk\u00f3w u\u017cycia. Na pocz\u0105tek ma\u0142e zastrze\u017cenie: m\u00f3wi\u0119 o diagramach przypadk\u00f3w u\u017cycia a nie przypadkach u\u017cycia. Przypadki u\u017cycia to ca\u0142kiem niez\u0142e narz\u0119dzie, kt\u00f3remu po\u015bwi\u0119c\u0119 troch\u0119 uwagi dalej. Zwracam te\u017c uwag\u0119, \u017ce m\u00f3wi\u0119 tu o czystym UMLu, bez wchodzenia w tematyk\u0119 metodologii, framework\u00f3w modeli itp. Wracaj\u0105c do naszych dzisiejszych bohater\u00f3w – … Czytaj dalej Mam problem z przypadkami<\/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,6],"tags":[9,8,17,16,7],"class_list":["post-82","post","type-post","status-publish","format-standard","hentry","category-analiza","category-uml","tag-diagram","tag-przypadki-uzycia","tag-uc","tag-use-case","tag-wymagania"],"_links":{"self":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/82","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=82"}],"version-history":[{"count":18,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/82\/revisions"}],"predecessor-version":[{"id":281,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/posts\/82\/revisions\/281"}],"wp:attachment":[{"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/media?parent=82"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/categories?post=82"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jaceksalacki.pl\/index.php\/wp-json\/wp\/v2\/tags?post=82"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Co to ja nie jestem<\/h2>\n
Juz kajs jaki jest ka\u017cdy widzi<\/h2>\n
Frak do kaloszy<\/h2>\n
Co robi\u0107? Co robi\u0107?<\/h2>\n
\n