{"id":745,"date":"2020-11-18T23:55:31","date_gmt":"2020-11-18T21:55:31","guid":{"rendered":"http:\/\/www.analizatozalezy.pl\/?p=745"},"modified":"2023-02-22T16:43:42","modified_gmt":"2023-02-22T14:43:42","slug":"7-zlych-praktyk-tworzenia-przypadkow-uzycia","status":"publish","type":"post","link":"https:\/\/www.analizatozalezy.pl\/index.php\/2020\/11\/18\/7-zlych-praktyk-tworzenia-przypadkow-uzycia\/","title":{"rendered":"7 z\u0142ych praktyk tworzenia przypadk\u00f3w u\u017cycia"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Cze\u015b\u0107!<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Tworzenie poprawnych i przydatnych przypadk\u00f3w u\u017cycia to niew\u0105tpliwie sztuka.\u00a0<\/span>Wiele os\u00f3b wykorzystuje przypadki u\u017cycia podczas analizy. Potrzeba jednak du\u017co do\u015bwiadczenia, wiedzy i cierpliwo\u015bci, aby stworzy\u0107 je poprawnie i zgodnie z najlepszymi praktykami.\u00a0<\/p>\n

Zanim przejdziemy dalej, ustalmy, czym s\u0105 przypadki u\u017cycia, o kt\u00f3rych jest artyku\u0142?<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t

\n\t\t\t\t\u201ePrzypadek u\u017cycia reprezentuje okre\u015blone, inicjowane przez aktora zachowanie lub zestaw zachowa\u0144 systemu, kt\u00f3rego celem jest z g\u00f3ry okre\u015blony i przydatny dla aktora rezultat, mo\u017ce zawiera\u0107 mo\u017cliwe warianty jego podstawowego zachowania, w tym wyj\u0105tkowe zachowanie takie jak obs\u0142uga b\u0142\u0119d\u00f3w, oznacza konkretne (w celu uzyskania konkretnego efektu) u\u017cycie Systemu; kluczowe poj\u0119cia skojarzone z Przypadkami U\u017cycia to Aktor i System (na podstawie UML v.2.5.1., www.omg.org).\u201d\t\t\t<\/p>\n\t\t\t\t\t\t\t

\n\t\t\t\t\t\t\t\t\t\t\thttps:\/\/it-consulting.pl\/autoinstalator\/wordpress\/glossary\/przypadek-uzycia\/#.X6p1X2hKhaQ<\/cite>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/blockquote>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Nieco upraszczaj\u0105c definicj\u0119, mo\u017cna powiedzie\u0107, \u017ce przypadek u\u017cycia przedstawia zachowanie lub zestaw zachowa\u0144 systemu na bod\u017ace podchodz\u0105ce z jego otoczenia (u\u017cytkownika lub inne systemy). Stosujemy go wi\u0119c 2 przypadkach:<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
    \n
  1. Aby zobrazowa\u0107 funkcjonalno\u015bci systemu od strony u\u017cytkownika<\/li>\n
  2. Aby zobrazowa\u0107 us\u0142ugi integracyjne, kt\u00f3re s\u0105 widoczne na zewn\u0105trz systemu<\/li>\n<\/ol>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Stworzone zosta\u0142o ju\u017c wiele tre\u015bci jak tworzy\u0107 przypadki u\u017cycia, w tym artykule wska\u017c\u0119 czego unika\u0107 podczas ich tworzenia. Artyku\u0142 powsta\u0142 na podstawie moich do\u015bwiadcze\u0144 oraz znajomych z bran\u017cy, poniewa\u017c zauwa\u017cyli\u015bmy pewne bardzo z\u0142e praktyki, kt\u00f3re wypaczaj\u0105 sens tworzenia przypadk\u00f3w u\u017cycia i utrudniaj\u0105 p\u00f3\u017aniejsze utrzymywanie dokumentacji.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

    \n\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"Przypadki\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Dlaczego?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    Zanim przejdziemy do z\u0142ych praktyk, zobaczmy, dlaczego takie praktyki powstaj\u0105. Wyobra\u017a sobie nast\u0119puj\u0105c\u0105 histori\u0119:<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    <\/p>\n

    <\/p>\n

    <\/p>\n

    \n

    „Pewnego dnia do firmy zosta\u0142 zatrudniony Stanis\u0142aw. Jest on analitykiem z niewielkim do\u015bwiadczeniem i wci\u0105\u017c z brakami wiedzy, w pewnych wa\u017cnych obszarach. W poprzedniej pracy niestety naby\u0142 praktyk\u0119 „Klient ma zawsze racj\u0119”.<\/p>\n

    Pewnego dnia podczas pracy z klientem dosta\u0142 zadanie identyfikacji oraz stworzenia przypadk\u00f3w u\u017cycia. Zrobi\u0142 to zgodnie ze znanymi zasadami i przes\u0142a\u0142 do klienta.<\/p>\n

    Klient odpowiedzia\u0142, \u017ce w ramach tych przypadk\u00f3w chcia\u0142bym mie\u0107 opisane, z kt\u00f3rego ekranu zaczyna si\u0119 scenariusz, oraz aby w opisie krok\u00f3w scenariusza by\u0142o opisane, na kt\u00f3rym ekranie jest aktualnie u\u017cytkownik i jakie pola ten ekran zawiera. Chcia\u0142bym r\u00f3wnie\u017c, aby w ramach tych opis\u00f3w zawiera\u0142y si\u0119 wszelkie regu\u0142y biznesowe, walidacje na polach i og\u00f3lnie, aby taki przypadek zawiera\u0142 wszystko.<\/p>\n

    Ku zasadzie „klient zawsze ma racj\u0119”, Stanis\u0142aw poprawi\u0142 przypadki. Efekt by\u0142 niesamowity, du\u017ce obszernie opisane przypadki u\u017cycia z nawet 20 krokami. Najwi\u0119kszy z przypadk\u00f3w ma ponad 6 stron A4. Pojawi\u0142y si\u0119 oczywi\u015bcie diagramy i nawet przypadki, kt\u00f3re nie posiadaj\u0105 scenariuszy, lecz s\u0105 „wa\u017cn\u0105” cz\u0119\u015bci\u0105 ca\u0142o\u015bci.<\/p>\n

    Stasiek przes\u0142a\u0142 wynik swoich prac do klienta, wi\u0119c klient ucieszony zaakceptowa\u0142 i rozpocz\u0119li realizacj\u0119. Od pocz\u0105tku zesp\u00f3\u0142 nie wiedzia\u0142 jak czyta\u0107 te przypadki i przeszukiwanie dokumentu zajmowa\u0142o ogromn\u0105 cz\u0119\u015b\u0107 czasu podczas pracy. Developerzy denerwowali si\u0119, poniewa\u017c te same rzeczy, wyst\u0119powa\u0142y w wielu miejscach dokumentu i ci\u0119\u017cko by\u0142o m\u00f3wi\u0107 o sp\u00f3jno\u015bci. Stanis\u0142aw stale musia\u0142 konsultowa\u0107 ze zesp\u00f3\u0142 i z klientem.<\/p>\n

    Klient z racji tego, \u017ce Stanis\u0142aw spe\u0142ni\u0142 jego \u017cyczenie, uzna\u0142 to za sw\u00f3j wk\u0142ad w \u015bwiat analizy i teraz wymaga tego we wszystkich kolejnych projektach…”<\/p>\n

    Historia Stanis\u0142awa<\/cite><\/p>\n<\/blockquote>\n

    <\/p>\n

    <\/p>\n

    Czy takie dokumentowanie jest dobre i czy ma sens, przy pe\u0142nym wachlarzu dost\u0119pnych technik i narz\u0119dzi analizy? Moim zdaniem nie.<\/p>\n

    <\/p>\n

    <\/p>\n

    Z\u0142e praktyki<\/h2>\n

    <\/p>\n

    <\/p>\n

    Czas na to, po co tu przyszed\u0142e\u015b. W rozdziale tym przedstawi\u0142em z\u0142e praktyki, kt\u00f3rych nale\u017cy unika\u0107 podczas tworzenia przypadk\u00f3w u\u017cycia.<\/p>\n

    <\/p>\n

    <\/p>\n

    Diagram przypadk\u00f3w bez opisu przypadk\u00f3w<\/h3>\n

    <\/p>\n

    <\/p>\n

    Pierwszy b\u0142\u0105d to diagram przypadk\u00f3w u\u017cycia, bez jakiegokolwiek opisu zaprezentowanych przypadk\u00f3w. Zesp\u00f3\u0142 nie maj\u0105c informacji o zawarto\u015bci „chmurek” musi sam opracowa\u0107 zasady dzia\u0142ania systemu (wi\u0119c nie wykona\u0142e\u015b swojej pracy, tworz\u0105c przypadek u\u017cycia!). Diagram sam w sobie niesie ma\u0142\u0105 warto\u015b\u0107, poniewa\u017c po jednym zdaniu w nazwie, nie dowiesz si\u0119, jak ma dok\u0142adnie dzia\u0142a\u0107 system, a tak\u0105 warto\u015b\u0107 musz\u0105 dawa\u0107 przypadki u\u017cycia.<\/p>\n

    <\/p>\n

    <\/p>\n

    B\u0142\u0119dne stosowanie relacji<\/h3>\n

    <\/p>\n

    <\/p>\n

    W wypadku b\u0142\u0119dnego stosowania relacji zauwa\u017cam dwa warianty.<\/p>\n

    <\/p>\n

    <\/p>\n

      \n
    1. Nie znajomo\u015b\u0107 zasad korzystania z relacji <\/li>\n
    2. Braki wynikaj\u0105ce z innych b\u0142\u0119d\u00f3w w tworzeniu (zawieranie interfejsu itd.)<\/li>\n<\/ol>\n

      <\/p>\n

      <\/p>\n

      Pierwszy do\u015b\u0107 szybko mo\u017cna wykry\u0107, je\u017celi znasz zasady tworzenia relacji, w drugim przypadku trzeba nieco do\u015bwiadczenia, aby go zauwa\u017cy\u0107 i odpowiednio poprawi\u0107. Kiedy\u015b spotka\u0142em si\u0119 z sytuacj\u0105, gdy kto\u015b stworzy\u0142 diagram, aby by\u0142 diagram, bo tego wymaga\u0142a umowa i nikt nie sprawdza\u0142 tej cz\u0119\u015bci dokumentacji. Szkoda, poniewa\u017c z dobrze stworzonego diagramu z poprawnymi relacjami, mo\u017cna szybko i efektywnie okre\u015bli\u0107 co jest do zrobienia i w jakiej kolejno\u015bci. Nawet je\u017celi chcemy tylko i wy\u0142\u0105cznie pozna\u0107 system jako nowa osoba w zespole.<\/p>\n

      <\/p>\n

      <\/p>\n

      \n
      \"\"<\/figure>\n<\/div>\n

      <\/p>\n

      <\/p>\n

      P<\/span>owy\u017cej, jest przyk\u0142ad \u017ale zrobionego diagramu i podzia\u0142u przypadk\u00f3w u\u017cycia. Unikaj takiego podej\u015bcia! Jest tu b\u0142\u0119dne zastosowanie relacji, z\u0142a identyfikacja i uwidacznia efekt opisu element\u00f3w interfejsu w ramach przypadku u\u017cycia. <\/p>\n

      Przejd\u017amy teraz do b\u0142\u0119d\u00f3w z powy\u017cszego diagramu. Pierwszy b\u0142\u0105d to identyfikacja przypadku u\u017cycia na podstawie interfejsu, czyli „Wy\u015bwietli\u0142em ekran g\u0142\u00f3wny”. Drugi b\u0142\u0105d, to „Zalogowa\u0142em si\u0119”, co nie mo\u017ce by\u0107 przypadkiem u\u017cycia. Trzeci b\u0142\u0105d jest powi\u0105zany z  „Use Case 3”, przypadkiem niemaj\u0105cy \u017cadnej relacji do aktora, ani innego przypadku u\u017cycia. Czwarty b\u0142\u0105d, kt\u00f3ry mo\u017cna podejrzewa\u0107 to relacje extend, przy czym tutaj trzeba wej\u015b\u0107 w opis samych przypadk\u00f3w i ich zale\u017cno\u015bci, poniewa\u017c czasami z tzw. Big Picture co\u015b wygl\u0105da b\u0142\u0119dnie, lecz jest bardzo dobrze zrobione.<\/p>\n

      Stosowanie relacje jest bardzo pomocne w zrozumieniu, dlatego wa\u017cne, aby zrobi\u0107 to poprawnie i z g\u0142ow\u0105.<\/p>\n

      <\/p>\n

      <\/p>\n

      Za du\u017ce lub za ma\u0142e<\/h3>\n

      <\/p>\n

      <\/p>\n

      Czasami spotykane przypadki u\u017cycia maj\u0105 15-30 krok\u00f3w w scenariuszu g\u0142\u00f3wnym i do tego scenariusz alternatywne. Bez wizualizacji w postaci diagramu aktywno\u015bci, odbiorca nie ma szans, zrozumie\u0107 jak co\u015b dzia\u0142a i czasami, taki przypadek opisuje zbyt du\u017cy obszar systemu, wi\u0119c powinien zosta\u0107 podzielony. Dobr\u0105 praktyk\u0105 jest zawieranie do 8-10 krok\u00f3w w scenariuszu, poniewa\u017c pozwala to na zrozumienie jego przebiegu i zale\u017cno\u015bci w przewa\u017cnie pierwszym czytaniu.
      Oczywi\u015bcie pojawia si\u0119 te\u017c sytuacja odwrotna, gdy pojawiaj\u0105 si\u0119 przypadki ze scenariuszami, posiadaj\u0105cymi 1-2 kroki. Tworzenie takich element\u00f3w r\u00f3wnie\u017c nie ma sensu, poniewa\u017c opisuje to przewa\u017cnie co\u015b, co powinno zosta\u0107 opisane poprzez np. wymaganie.<\/p>\n

      <\/p>\n

      <\/p>\n

      Przypadki u\u017cycia zawieraj\u0105 elementy intefejsu<\/h3>\n

      <\/p>\n

      <\/p>\n

      Miejscem do opisu interfejsu musi by\u0107 dedykowana cz\u0119\u015b\u0107 dokumentacji, gdzie opiszemy ekrany, list\u0119 p\u00f3l, logik\u0119 p\u00f3l i odwo\u0142ania do funkcjonalno\u015bci. Niestety, zbyt cz\u0119sto miejscem tym staj\u0105 si\u0119 przypadki u\u017cycia. Przez to pojawiaj\u0105 si\u0119 p\u00f3\u017aniejsze problemy z utrzymywaniem aktualno\u015bci przypadk\u00f3w u\u017cycia z nadmiarem w postaci opisu interfejsu (np. U\u017cytkownik musi klikn\u0105\u0107 przycisk „Kliknij tutaj”, zostanie wy\u015bwietlony ekran „klikacz tutejszy” … ). W moim odczuciu powodem, dlaczego tak przypadki s\u0105 tworzone, jest obrazowo\u015b\u0107 opisu, poniewa\u017c \u0142atwiej jest wyobrazi\u0107 sobie przycisk<\/strong> ni\u017c wyb\u00f3r opcji<\/strong>. Specyficzne s\u0142owa, kt\u00f3rych nale\u017cy unika\u0107 to nazwy element\u00f3w np. przycisk, lista rozwijana, checkbox itd.<\/span> Pope\u0142nienie tego b\u0142\u0119du, bardzo szybko prowadzi do niesp\u00f3jno\u015bci w dokumentacji i kosztownego utrzymywania aktualno\u015bci dokument\u00f3w.<\/p>\n

      <\/p>\n

      <\/p>\n

      \u0141\u0105czenie wszystkich przypadk\u00f3w z jednym<\/h3>\n

      <\/p>\n

      <\/p>\n

      „Czy wiesz o tym, \u017ce mo\u017cesz zrobi\u0107 to w alternatywnym scenariuszu i nie dodawa\u0107 kolejnego przypadku?” – mniej wi\u0119cej podobne s\u0142owa kiedy\u015b us\u0142ysza\u0142em. Nast\u0119pnie za namow\u0105 tej osoby powsta\u0142 wielki scenariusz z kilkoma scenariuszami alternatywnymi. Niestety to by\u0142 du\u017cy b\u0142\u0105d, poniewa\u017c jak potem okaza\u0142o si\u0119, by\u0142a to inna funkcjonalno\u015b\u0107. Jest to pu\u0142apka, w kt\u00f3r\u0105 mo\u017cna wpa\u015b\u0107. Je\u017celi pojawia si\u0119 wiele scenariuszy alternatywnych, nale\u017cy zrobi\u0107 krok wstecz i sprawdzi\u0107, czy przypadek u\u017cycia nie zawiera w sobie wielu funkcjonalno\u015bci i je\u017celi to si\u0119 potwierdzi, podzieli\u0107 go zgodnie z wynikaj\u0105cymi funkcjonalno\u015bci. Tworz\u0105c przypadek u\u017cycia ogranicz opis do tego co jest niezb\u0119dne, do przekazania. Nie trzeba opisa\u0107 ca\u0142ego \u015bwiata. Czasami wystarczy jedynie odno\u015bnik do „wa\u017cnego” elementu. Pami\u0119taj! Przypadek u\u017cycia to nie scenariusz filmu!<\/p>\n

      <\/p>\n

      <\/p>\n

      Przypadek u\u017cycia zast\u0119puj\u0119 ca\u0142\u0105 dokumentacj\u0119<\/h3>\n

      <\/p>\n

      <\/p>\n

      Przypadek u\u017cycia ma pewn\u0105 form\u0119, kt\u00f3ra \u015bwietnie odwzorowuje to co dzieje si\u0119 w systemie. Jednak czasami, w ramach opisu jest to nadu\u017cywane. Wynikiem tego jest zawieranie w scenariuszu wcze\u015bniej wspomnianych element\u00f3w, kt\u00f3re nie powinny si\u0119 tam znale\u017a\u0107 jak np. regu\u0142y biznesowe czy opis interfejsu. S\u0105 to zawsze rzeczy nadmiarowe, kt\u00f3re powinny mie\u0107 swoje oddzielne miejsce w dokumentacji i by\u0107 odpowiednio opisane. <\/p>\n

      <\/p>\n

      <\/p>\n

      Brak zastosowania struktury przypadku<\/h3>\n

      <\/p>\n

      <\/p>\n

      Ostatni b\u0142\u0105d, kt\u00f3ry cz\u0119sto jest przyczyn\u0105 wszystkich powy\u017cszych to BRAK ZASTOSOWANIA SZABLONU lub brak jego zrozumienia!<\/p>\n

      <\/p>\n

      <\/p>\n

      Je\u017celi zaczynasz tworzy\u0107 przypadek u\u017cycia, zastosuj szablon. Nast\u0119pnie przeczytaj instrukcj\u0119 oraz zobacz przyk\u0142ad, jak powinien zosta\u0107 prawid\u0142owo wype\u0142niony dokument. Wiele jest standard\u00f3w, \u015bwietnych artyku\u0142\u00f3w, szkole\u0144, a temat „jak tworzy\u0107 przypadki u\u017cycia” przewija si\u0119 co chwil\u0119 na blogach, wi\u0119c nie b\u0119dziesz mia\u0142 problemu w stworzeniu czego\u015b w\u0142asnego, je\u017celi nie masz firmowego szablonu.<\/p>\n

      <\/p>\n

      <\/p>\n

      Aby Ci\u0119 naprowadzi\u0107, okre\u015bl\u0119 w skr\u00f3cie, tylko \u017ce przypadek u\u017cycia, powinien by\u0107 opisany nast\u0119puj\u0105cymi cechami:<\/p>\n

      <\/p>\n

      <\/p>\n