{"id":9119,"date":"2022-02-28T09:15:19","date_gmt":"2022-02-28T09:15:19","guid":{"rendered":"https:\/\/www.cybermedian.com\/pl\/?p=9119"},"modified":"2025-02-07T10:47:12","modified_gmt":"2025-02-07T02:47:12","slug":"a-quick-guide-to-use-case-modeling","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pl\/a-quick-guide-to-use-case-modeling\/","title":{"rendered":"Szybki przewodnik po modelowaniu przypadk\u00f3w u\u017cycia"},"content":{"rendered":"

Modelowanie przypadk\u00f3w u\u017cycia<\/a>jest przydatnym narz\u0119dziem do uchwycenia wymaga\u0144. Zapewnia graficzn\u0105 reprezentacj\u0119 wymaga\u0144 systemu oprogramowania.<\/p>\n

Z publikacj\u0105 Ivara Jacobsona<\/a>ksi\u0105\u017cki z 1991 roku In\u017cynieria oprogramowania zorientowanego obiektowo, podej\u015bcie oparte na przypadkach u\u017cycia<\/a>, modelowanie przypadk\u00f3w u\u017cycia skutecznie sta\u0142o si\u0119 praktyczn\u0105 technik\u0105 analizy\u201d. Dzi\u015b Jacobson nadal promuje to podej\u015bcie do analizy system\u00f3w i zaktualizowa\u0142 je do Use Case 2.0, kt\u00f3re jest oficjalnie jednym z 14 typ\u00f3w diagram\u00f3w UML<\/a>.<\/p>\n

Poniewa\u017c model przypadku u\u017cycia jest prosty w koncepcji i wygl\u0105dzie, stosunkowo \u0142atwo jest om\u00f3wi\u0107 jego poprawno\u015b\u0107 z personelem nietechnicznym (takim jak klienci).<\/p>\n

Przypadek u\u017cycia nie jest procedur\u0105, procesem ani funkcj\u0105.<\/p>\n

Elementy diagramu przypadk\u00f3w u\u017cycia<\/h2>\n

Elementy diagramu przypadk\u00f3w u\u017cycia<\/a>to aktorzy (podmioty zewn\u0119trzne) oraz sam przypadek u\u017cycia. Og\u00f3lnie rzecz bior\u0105c, przypadek u\u017cycia to jednostka funkcjonalna (wymaganie) lub us\u0142uga w systemie.<\/p>\n

Aktor<\/h3>\n

Aktor aktor<\/a>jest ka\u017cd\u0105 jednostk\u0105 zewn\u0119trzn\u0105 w stosunku do systemu projektowego, niezale\u017cnie od tego, czy jest to osoba, czy inny podmiot nie-ludzki. U\u017cytkownik systemu jest typowym przyk\u0142adem aktora. Inne typy aktor\u00f3w obejmuj\u0105 systemy oprogramowania, kt\u00f3re s\u0105 integrowane z obecnym systemem (np. system baz danych), zewn\u0119trzny sprz\u0119t, taki jak czujnik itp.\"Types<\/p>\n

Istniej\u0105 dwa notacje w specyfikacji UML<\/a>:<\/p>\n

\"\"<\/p>\n

U\u017cywanie stickmana dla aktor\u00f3w jest bardziej ekspresyjne, ale mo\u017ce prowadzi\u0107 do zamieszania, je\u015bli aktor nie jest faktycznie osob\u0105, lecz maszyn\u0105 lub urz\u0105dzeniem zewn\u0119trznym. Symbol prostok\u0105ta jest standardowym notacj\u0105 UML<\/a>dla klasy<\/a>.<\/p>\n

Aktor to rola, a nie rzeczywista osoba <\/strong><\/p>\n

Aktor reprezentuje rol\u0119 podmiotu, kt\u00f3ry wchodzi w interakcj\u0119 z obecnym systemem, a nie instancj\u0119.<\/span>Notacja aktora wskazuje, \u017ce podmiot jest klas\u0105, a nie instancj\u0105 (tj. rzeczywistym u\u017cytkownikiem Johnem lub Mary). Pow\u00f3d, dla kt\u00f3rego aktor jest typem klasy, polega na tym, \u017ce nie jest to sam aktor, lecz rola, kt\u00f3r\u0105 odgrywa.<\/p>\n

Na przyk\u0142ad aktor mo\u017ce reprezentowa\u0107 klient\u00f3w banku, zamiast okre\u015bla\u0107 osobnego aktora dla ka\u017cdego klienta. Podobnie, mo\u017ce by\u0107 inny aktor reprezentuj\u0105cy mened\u017cera banku. Co ciekawe, w rzeczywistym \u015bwiecie mened\u017cer banku mo\u017ce by\u0107 r\u00f3wnie\u017c klientem tego samego banku. Innymi s\u0142owy, ta sama osoba odgrywa rol\u0119 zar\u00f3wno klienta, jak i mened\u017cera.<\/p>\n

Aktorzy g\u0142\u00f3wni vs aktorzy pomocniczy<\/strong><\/a><\/p>\n

Aktor g\u0142\u00f3wny<\/strong>przypadku u\u017cycia to interesariusz, kt\u00f3ry wymaga, aby system \u015bwiadczy\u0142 swoje us\u0142ugi. Ma cel zwi\u0105zany z systemem \u2013 cel, kt\u00f3ry mo\u017ce by\u0107 zaspokojony przez dzia\u0142anie systemu. Aktor g\u0142\u00f3wny jest zazwyczaj, ale nie zawsze, aktorem, kt\u00f3ry uruchamia przypadek u\u017cycia.<\/p>\n

Aktor pomocniczy <\/strong>jest u\u017cywany przez system, ale nie wchodzi w interakcj\u0119 z systemem samodzielnie. Innymi s\u0142owy, aktorzy pomocniczy nie inicjuj\u0105 \u017cadnych przypadk\u00f3w u\u017cycia.<\/p>\n

Przypadki u\u017cycia s\u0105 zazwyczaj inicjowane przez aktor\u00f3w g\u0142\u00f3wnych. System korzysta z aktora pomocniczego, takiego jak baza danych, poprzez zestaw przypadk\u00f3w u\u017cycia. Zwi\u0105zek mi\u0119dzy przypadkami u\u017cycia a uczestnikami reprezentuje komunikacj\u0119 dwukierunkow\u0105.<\/p>\n

Zatem dla ka\u017cdego przypadku u\u017cycia inicjowanego przez aktora g\u0142\u00f3wnego, po\u0142\u0105czony przypadek u\u017cycia musi by\u0107 odpowiedziany. Podobnie, dla ka\u017cdego zwi\u0105zku mi\u0119dzy aktorem pomocniczym a przypadkiem u\u017cycia, komunikacja zaczyna si\u0119 od przypadku u\u017cycia, a aktor pomocniczy powinien odpowiedzie\u0107 na inicjacj\u0119.<\/p>\n

Przypadek u\u017cycia<\/h3>\n

Przypadki u\u017cycia<\/strong>reprezentuj\u0105 funkcje (zwykle wymagania), kt\u00f3re maj\u0105 by\u0107 wdro\u017cone przez system. Szczeg\u00f3\u0142y przypadku u\u017cycia, z wyj\u0105tkiem jego unikalnej nazwy, nie s\u0105 intuicyjnie wyra\u017cone w diagramie; Szczeg\u00f3\u0142y te s\u0105 podane w opisie przypadku u\u017cycia.<\/p>\n

Przypadki u\u017cycia s\u0105 zazwyczaj inicjowane przez kluczowych aktor\u00f3w. System korzysta z bazy danych i innych uczestnik\u00f3w pomocniczych poprzez zestaw przypadk\u00f3w u\u017cycia.<\/p>\n

Zwi\u0105zek mi\u0119dzy przypadkami u\u017cycia a aktorami reprezentuje komunikacj\u0119 dwukierunkow\u0105. Dlatego dla ka\u017cdego przypadku u\u017cycia inicjowanego przez g\u0142\u00f3wnego aktora, na ten ostatni musi by\u0107 odpowiedziane. Podobnie, dla ka\u017cdego zwi\u0105zku mi\u0119dzy aktorem pomocniczym a przypadkiem u\u017cycia, komunikacja zaczyna si\u0119 od przypadku u\u017cycia, a aktor pomocniczy powinien odpowiedzie\u0107 na inicjacj\u0119.<\/p>\n

Granica systemu<\/h3>\n

Granica systemu definiuje system interesuj\u0105cy w odniesieniu do otaczaj\u0105cego go \u015bwiata.<\/p>\n

Przyk\u0142ad diagramu przypadk\u00f3w u\u017cycia: System rezerwacji lot\u00f3w<\/h3>\n

Przypadki u\u017cycia definiuj\u0105 interakcje mi\u0119dzy zewn\u0119trznymi aktorami a systemem w celu osi\u0105gni\u0119cia okre\u015blonych cel\u00f3w. Diagram przypadk\u00f3w u\u017cycia zawiera cztery g\u0142\u00f3wne komponenty<\/p>\n

W diagramie przypadk\u00f3w u\u017cycia systemu rezerwacji bilet\u00f3w system jest reprezentowany przez prostok\u0105ty zawieraj\u0105ce wiele r\u00f3\u017cnych przypadk\u00f3w u\u017cycia. Aktorem g\u0142\u00f3wnym jest klient, a aktorem pomocniczym jest administrator. Klient inicjuje przypadki u\u017cycia, takie jak rezerwacja, przegl\u0105danie i anulowanie lot\u00f3w, podczas gdy administrator inicjuje przypadki u\u017cycia, takie jak aktualizacja zapis\u00f3w lot\u00f3w, ale jest uwa\u017cany za aktora pomocniczego w przypadku anulowania lotu, poniewa\u017c tylko pomaga w realizacji przypadk\u00f3w u\u017cycia inicjowanych przez klienta.<\/p>\n

<\/p>\n

Edytuj ten przyk\u0142ad diagramu przypadk\u00f3w u\u017cycia UML<\/a><\/p>\n

Strukturyzacja przypadk\u00f3w u\u017cycia<\/h3>\n

Zgodnie z dziedzin\u0105 zastosowania i wyborem projektanta, przypadek u\u017cycia mo\u017ce by\u0107 podzielony na wiele przypadk\u00f3w u\u017cycia, kt\u00f3re s\u0105 po\u0142\u0105czone przez relacje < < include > > lub < < extend > >.<\/p>\n

Link asocjacyjny<\/strong>reprezentuje komunikacj\u0119 dwukierunkow\u0105 mi\u0119dzy aktorem a przypadkiem u\u017cycia, a zatem jest relacj\u0105 binarn\u0105. Poniewa\u017c jest to komunikacja dwukierunkowa, dla ka\u017cdego przypadku u\u017cycia inicjowanego przez aktora g\u0142\u00f3wnego, ten aktor musi otrzyma\u0107 odpowied\u017a z przypadku u\u017cycia.<\/p>\n

\"Customer<\/p>\n

Podobnie, dla ka\u017cdej komunikacji mi\u0119dzy przypadkiem u\u017cycia a aktorem pomocniczym (inicjowanej przez przypadek u\u017cycia), aktor pomocniczy musi wys\u0142a\u0107 odpowied\u017a z powrotem do przypadku u\u017cycia.<\/p>\n

Generalizacja<\/h4>\n

Generalizacja reprezentuje zwi\u0105zek mi\u0119dzy<\/p>\n