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życia:

  1. nie­for­mal­ny opis ? kil­ka luź­nych zdań ogól­nie opi­su­ją­cych przypadek
  2. for­mal­ny opis ? kil­ka para­gra­fów, podsumowanie
  3. pełen opis ? for­mal­ny dokument

Przypadek uży­cia (źr. WIKI) powinien:

  1. opi­sy­wać w jaki spo­sób sys­tem powi­nien być uży­wa­ny przez akto­ra w celu osią­gnię­cia kon­kret­ne­go celu
  2. być pozba­wio­ny szcze­gó­łów doty­czą­cych imple­men­ta­cji oraz inter­fej­su użytkownika
  3. opi­sy­wać sys­tem na wła­ści­wym pozio­mie szczegółowości
Dalej mamy (Ian Sommerville) wymagania:
  1. Functional requ­ire­ments: Statements of servi­ces the sys­tem sho­uld pro­vi­de, how the sys­tem sho­uld react to par­ti­cu­lar inputs and how the sys­tem sho­uld beha­ve in par­ti­cu­lar situations.
  2. Non-func­tio­nal requ­ire­ments: Constraints on the servi­ces or func­tions offe­red by the sys­tem such as timing con­stra­ints, con­stra­ints on the deve­lop­ment pro­cess, stan­dards, etc.
  3. Domain requ­ire­ments: Requirements that come from the appli­ca­tion doma­in of the sys­tem and that reflect cha­rac­te­ri­stics of that domain.

Definicja Sommerville’a, wyma­gań funk­cjo­nal­nych: wyma­ga­nie funk­cjo­nal­ne to usłu­ga świad­czo­na przez sys­tem. Jest to prak­tycz­nie toż­sa­me z defi­ni­cją przy­pad­ku uży­cia sys­te­mu (parz zakoń­cze­nie arty­ku­łu) i taki jest wła­śnie ich sens. Idąc tym tropem…

W 1986 Ivar Jacobson, infor­ma­tyk zaan­ga­żo­wa­ny w two­rze­nie [[Unified Modeling Language]] (UML) oraz [[Rational Unified Process]] (RUP) opi­sał tech­ni­kę do spe­cy­fi­ko­wa­nia przy­pad­ków uży­cia. Z począt­ku uży­wał okre­śleń: sce­na­riusz użyt­ko­wa­nia (usa­ge sce­na­rios) i przy­pad­ki użyt­ko­wa­nia (usa­ge case). I tu widzę świa­teł­ko w tune­lu. Wymagania są dzie­lo­ne na nastę­pu­ją­ce kate­go­rie (źr. WIKI):

  1. Wymagania funk­cjo­nal­ne opi­su­ją funk­cjo­nal­ność, któ­rą sys­tem ma reali­zo­wać, na przy­kład for­ma­to­wa­nie tek­stu lub modu­lo­wa­nie sygna­łu. Czasami są zna­ne jako możliwości.
  2. Wymagania poza­funk­cjo­nal­ne spe­cy­fi­ku­ją kry­te­ria osą­dza­nia dzia­ła­nia sys­te­mu. Są one zna­ne jako wyma­ga­nia jakościowe.
  3. Wymagania ogra­ni­czeń okre­śla­ją gra­ni­ce roz­wią­za­nia. Niezależnie od tego jak pro­blem jest roz­wią­za­ny, ogra­ni­cze­nia muszą być respektowane.

W 2006 roku napisałem:

Po wie­lu podej­ściach do two­rze­nia przy­pad­ków uży­cia uzna­łem, że nale­ży naj­pierw opi­sać co jest w ogó­le celem two­rze­nia tego sys­te­mu, co on ma wspo­ma­gać lub auto­ma­ty­zo­wać. Jak? Należy naj­pierw zamo­de­lo­wać tę wspo­ma­ga­ną czyn­ność w zupeł­nym ode­rwa­niu od sys­te­mów. Jak już zde­fi­niu­je­my i zop­ty­ma­li­zu­je­my samą czyn­ność moż­na zabie­rać się do wyszcze­gól­nia­nia przy­pad­ków uży­cia czy­li tak na praw­dę zapro­jek­to­wać tę ?dru­ga stro­nę lustra?. (Przypadki uży­cia i UML | Analiza biz­ne­so­wa i pro­jek­to­wa­nie – Jarosław Żeliński – blog).

Po kil­ku latach kolej­nych doświad­czeń upew­niam się, że pro­ste jest pięk­ne: przy­pa­dek uży­cia to poje­dyn­cza, ele­men­tar­na kom­plet­na usłu­ga świad­czo­na przez System dla jego użyt­kow­ni­ka. Usługa ta jed­nak może mieć warianty.

Przykład: jeże­li jakiś sys­tem, mie­dzy inny­mi, umoż­li­wia wpro­wa­dza­nie danych z for­mu­la­rza, wzo­rów for­mu­la­rza jest kil­ka­dzie­siąt to ile mamy przy­pad­ków uży­cia? Jeden, któ­ry pozwa­la na wpro­wa­dza­nie danych do jakie­goś” for­mu­la­rza, to jaki to jest for­mu­larz to para­metr. Scenariusz ma mię­dzy inny­mi krok: wyświetl for­mu­larz do wypeł­nie­nia. jaki for­mu­larz? Wynika to albo z kon­tek­stu, któ­ry może być efek­tem poprzed­nio wyko­na­nych ope­ra­cji albo z bez­po­śred­nie­go wybo­ru Aktora. Tak więc dobry pro­jekt raczej nie ma odręb­ne­go przy­pad­ku uży­cia dla każ­de­go wzo­ru for­mu­la­rza. Dobry pro­jekt ma jeden przy­pad­ku uży­cia, wzór for­mu­la­rza to efekt wybo­ru np. w poprzed­nim kro­ku. Jak taki przy­pa­dek uży­cia jest reali­zo­wa­ny? Opisze to kie­dyś 🙂 przy oka­zji wzor­ca Strategia i prak­tyk pro­jek­to­wa­nia DDD.

Jaki z tego ma poży­tek spon­sor pro­jek­tu? Koszt, pro­jekt ma kil­ka­na­ście lub kil­ka­dzie­siąt a nie set­ki przy­pad­ków uży­cia i jest łatwiej­szy w implementacji.

A gdzie przy­pad­ki sys­te­mo­we? Nie ma takich. Pojęcie Aktora ma jasną defi­ni­cję (oso­ba lub inny sys­tem mają­cy inte­rak­cję z Systemem), poję­cie przy­pad­ku uży­cia tak­że (spe­cy­fi­ka­cja dzia­łań Systemu w odpo­wie­dzi na dzia­ła­nia akto­ra lub inne­go pod­mio­tu zain­te­re­so­wa­ne­go” Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych defi­ni­cji nie tyl­ko psu­je stan­dard bo nie pasu­je do spój­nej prze­strze­ni nazw. Wymyślanie swo­ich zna­czeń po pro­tu psu­je zro­zu­mia­łość, nisz­czy role komu­ni­ka­cyj­ną mode­li (języ­ka ich two­rze­nia). Niestety Pan Cockbourn jest w moich oczach takim dora­bia­czem” i psu­ją­cym sens pro­ste­go i jak widać trud­ne­go zara­zem, narzę­dzia jakim jest model przy­pad­ków uży­cia systemu.

O tym jak moż­na psuć i kom­pli­ko­wać pro­ste rze­czy (Pan Cockbourn) napi­sa­łem w Po brzy­twie… (dia­gram poni­żej to wręcz antyw­zo­rzec… 😉 a widu­je takie nie­ste­ty w pro­jek­tach). Zaryzykuję nawet tezę, że ktoś kto popra­wia wypra­co­wa­ny sys­tem poję­cio­wy jakim jest np. UML po pro­stu nie rozu­mie ani tego sys­te­mu ani tego czym jest sys­tem poję­cio­wy i język mode­lo­wa­nia. UML, owszem, moż­na roz­sze­rzać (ste­reo­ty­py), ale to wyma­ga zro­zu­mie­nia go, bo samo mno­że­nie ste­reo­ty­pów bez zacho­wa­nia pew­nych zasad rzą­dzą­cych prze­strze­nią nazw jaką się UML, pro­wa­dzi to bełkotu.

Mnożenie bytów na dia­gra­mach to poniż­sza „[[pusz­ka pan­do­ry]]”. Za coś podob­ne­go jak poni­żej nie płacimy!

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 16 komentarzy

  1. Michał Wolski

    Jarku zga­dzam się z Tobą w 100%. Nie mniej jed­nak jest trud­no cza­sem wytłu­ma­czyć czy­tel­ni­kom takie­go gigan­ta jak Alistair Cockburn, że guru” od przy­pad­ków uży­cia jest w błę­dzie i olał” spe­cy­fi­ka­cję UML, któ­ra powin­na być i jest wyznacz­ni­kiem zna­cze­nia poszcze­gól­nych ele­men­tów nota­cji UML.

    1. Jarek Żeliński

      Ja im, jego czy­tel­ni­kom, nicze­go nie tłu­ma­czę, on nie jest w błę­dzie, on nie uży­wa UML 🙂 , uży­wa poję­cia przy­pa­dek uży­cia” w innym zna­cze­niu niż zde­fi­nio­wa­ne w UML. To po pro­stu przy­pad­ko­wa zbież­ność nazw” ale nie­ste­ty wpro­wa­dza w błąd… 😉

  2. Michał Wolski

    Dokładnie tak. Cockburn dopie­ro oko­ło 180 stro­ny swo­jej książ­ki pt.: Jak pisać efek­tyw­ne przy­pad­ki uży­cia” pisze, że kon­cep­cja przy­pad­ków uży­cia, któ­rą on pre­zen­tu­je sta­ła się podstawą/inspiracją do przy­pad­ków uży­cia zna­nych z UML. Pisząc wcze­śniej olał” mia­łem na myśli iż jego kon­cep­cja przy­pad­ków uży­cia nie jest toż­sa­ma z przy­pad­ka­mi uży­cia zna­ny­mi ze spe­cy­fi­ka­cji języ­ka UML.

    1. Jarek Żeliński

      No nie­ste­ty, ale wie­lu ludzi utoż­sa­mia przy­pad­ki uży­cia Cockbourn’a i UML… co jest jed­nak błędem…

  3. Tomasz Styp-Rekowski

    Witam,
    Od nie­daw­na zaczą­łem się inte­re­so­wać ana­li­zą biz­ne­so­wą, więc moż­li­we, że moję myśle­nie jest błęd­ne, ale zasta­na­wia mnie co tak dokład­nie jest złe­go w zapre­zen­to­wa­nym powy­żej antyw­zo­rze”? Nie znam co praw­dą języ­ka w któ­rym napi­sa­ny jest ten dia­gram, ale wyda­je mi się, że jeśli każ­da wymie­nio­na funk­cjo­nal­ność jest uni­kal­na to nie mamy do czy­nie­nia ze zbyt­nim mno­że­niem bytów, tyl­ko po pro­stu sys­tem jest bar­dzo duży. Może cho­dzi Panu o przej­rzy­stość dia­gra­mu i moż­li­wość podzie­le­nia go na kil­ka z podzia­łem na dzie­dzi­nę, ale nie jest to wyja­śnio­ne. Mógłby Pan to mi nie­co doprecyzować?
    Pozdrawiam

    1. Jaroslaw Zelinski

      Na począ­tek nie myl­my funk­cjo­nal­no­ści” z przy­pad­kiem uży­cia”, ten dru­gi tu usłu­ga systemu.

      Diagram przy­pad­ków uży­cia ma sens (jest czy­tel­ny i jest mode­lem) pod warun­kiem, że posłu­ży­my się okre­ślo­ną defi­ni­cją” przy­pad­ku uży­cia. Definicja UML to (w uprosz­cze­niu) usłu­ga sys­te­mu mają­ca okre­ślo­ny wyma­ga­ny stan począt­ko­wy i two­rzą­ca okre­ślo­ny, przy­dat­ny dla akto­ra, stan koń­co­wy czy­li pro­dukt. Jest ona nie­mal­że toż­sa­ma z defi­ni­cją pro­ce­su biz­ne­so­we­go: prze­kształ­ca stan wej­ścio­wy w stan koń­co­wy”. Stany pośred­nie nie są więc przy­pad­ka­mi uży­cia (nie ist­nie­je ich hie­rar­chicz­na gra­da­cja) a jedy­nie kro­ka­mi sce­na­riu­sza. Innymi sło­wy, przy­pad­ki uży­cia to w zasa­dzie ele­men­ty menu, któ­re aktor może wywo­łać (usłu­gi sys­te­mu) by coś uzy­skać. Tak więc np. wysta­wie­nie fak­tu­ry to jeden przy­pa­dek uży­cia (stan począt­ko­wy wyma­ga wie­dzy komu i za co tę fak­tu­rę wysta­wić, stan koń­co­wy to popraw­na fak­tu­ra, kom­ple­to­wa­nie tych danych to kro­ki sce­na­riu­sza a nie osob­ne przy­pad­ki uży­cia), nie są nimi wsta­wie­nie pro­duk­tu” czy wybór kontrahenta”. 

      Przypadków uży­cia raczej nie dzie­li­my dzie­dzi­no­wo, a raczej gru­pu­je­my na modu­ły sys­te­mu (lub odręb­ne pod­sys­te­my). jeże­li na jed­nym dia­gra­mie jest ich wie­le to sygnał, że tego podzia­łu nie doko­na­no (a pamie­taj­my, że dobra prak­ty­ka jest podział dużych sys­te­mów na pod­sys­te­my). Dalej: nie bar­dzo ma sens two­rze­nie dia­gra­mów pozba­wio­nych ramy System, gdyż wyzna­cza ona zakres pro­jek­tu (gra­ni­ce sys­te­mu), naj­sil­niej­szy ele­ment zarzą­dza­nia zakre­sem pro­jek­tu. Bez tego nie­moż­li­we jest mode­lo­wa­nie integracji. 

      W książ­kach moż­na spo­tkać inne niż w UML (nie­zgod­ne z nim), defi­ni­cje przy­pad­kow uzy­cia (np. popu­lar­ny A.Cocborn) jed­nak uży­wa­nie ich wpro­wa­dza zamęt w doku­men­ta­cji i utrud­nia korzy­sta­nie z popu­lar­nych sys­tem­wów CASE. jeże­li jed­nak już sto­su­je­my dia­gra­my UML, to dla uni­ka­nia nie­po­ro­zu­mień, nale­ży na nich zacho­wac defic­ni­ję z UML. Jest to o tyle korzyst­ne, ze OMG har­mo­ni­zu­je nota­cje (np. BMN, BMM) dzię­ki cze­mu moż­li­we jest wza­jem­ne mapo­wa­nie np. ele­men­tar­ne pro­ce­sy w BPMN na przy­pad­ki uży­cia, jest to zresz­tą zale­ca­na meto­da ich – przy­pad­ków uży­cia – iden­ty­fi­ka­cji. Diagram zbyt duży” z zasa­dy jest zły, bo poka­zu­je, że autor nie panu­je nad złożónościąprojektu.

  4. Tomasz Styp-Rekowski

    Dziękuję za szyb­ką odpowiedź.
    Mam tyl­ko jed­ną wąt­pli­wość. Użyłem sło­wa funk­cjo­nal­ność”, ponie­waż na wcze­śniej­szym dia­gra­mie (któ­ry raczej nie jest antyw­zor­cem) jest napi­sa­ne w notat­ce, że Przypadki uży­cia to funk­cjo­nal­no­ści mają­ce­go powstać Systemu.[…]. Więc jak to jest? Usługa systemu/Przypadek uży­cia to nie funk­cjo­nal­ność systemu?

    1. Jaroslaw Zelinski

      Używam poję­cia funk­cjo­nal­ność” w rozu­mie­niu funk­cja sys­te­mu” jako poję­cia toż­sa­me­go z jego przy­pad­kiem uży­cia”. Ta zbież­ność to tak­że kon­se­kwen­cja har­mo­ni­za­cji nota­cji jaką robi OMG (orga­ni­za­cja zarzą­dza­ją­ca spe­cy­fi­ka­cja­mi tych nota­cji). Dzieje się do nie­daw­na i w moich star­szych arty­ku­łach poję­cia te nie były tak rygo­ry­stycz­nie utoż­sa­mia­ne. Potoczne (słow­ni­ko­we w sen­sie j.polskiego) zna­cze­nie sło­wa to ?funk­cjo­no­wa­nie lub funk­cja cze­goś w jakimś sys­te­mie?. Jeżeli uzna­my, że funk­cja sys­te­mu (tu apli­ka­cji) to usłu­ga jakiej od nie­go ocze­ku­je­my, to są to zgod­ne poję­cia. Jednak w potocz­nym rozu­mie­niu funk­cjo­nal­ność” jest fak­tycz­nie szer­szym poję­ciem i war­to te poję­cia upo­rząd­ko­wać w doku­men­ta­cji projektowej. 

      Tożsamość pojęć funk­cja sys­te­mu”, usłu­ga sys­te­mu” i przy­pa­dek uży­cia (sys­te­mu)” (w kate­go­rii ana­li­zy i pro­jek­to­wa­nia obiek­to­we­go) wyni­ka tak­że ze spe­cy­fi­ka­cji SOA i Architektury Korporacyjnej, gdzie wła­śnie usłu­ga sys­te­mu z per­spek­ty­wy akto­ra jest jego przy­pad­kiem uży­cia, zaś ele­men­tar­ny (zwa­ny cza­sem ato­mo­wym) pro­ces biz­ne­so­wy jest wspie­ra­ny kon­kret­ną usłu­gą sys­te­mu (jest to jego przy­pa­dek użycia).

      Dlatego napi­sa­łem, że wysta­wia­nie fak­tur” to funk­cjo­nal­ność sys­te­mu, ale moż­li­wość wsta­wie­nia wie­lu pro­duk­tów na fak­tu­rze” to już nie odręb­na funk­cjo­nal­ność a cecha for­mat­ki faktury. 

  5. Wojtek

    Witam,

    Z tego co zro­zu­mia­łem warian­ty przy­pad­ku uży­cia powin­ny znaj­do­wać się w tym samym przypadku.

    Czy w przy­pad­ku gdy mamy trzy warian­ty doda­nia cze­goś do systemu(tworzenie od pod­staw, ze wzor­ca i sko­pio­wa­nie już ist­nie­ją­ce­go ele­men­tu) przed­sta­wia­my jeden z warian­tów jako sce­na­riusz głów­ny, a resz­ta warian­tów w sce­na­riu­szach alternatywnych?

    Czy tak samo będzie w przy­pad­ku gdy daną rzecz może­my pro­ce­so­wać na dwa róż­ne sposoby?

    Nie za bar­dzo czu­ję przy­pad­ki uży­cia, któ­ra mają kil­ka warian­tów procesowania.

    Pozdrawiam

    1. Jaroslaw Zelinski

      Bardzo waż­ne jest to co rozu­mie­my pod poję­ciem pro­ce­so­wa­nia”, jeże­li to sekwen­cja róż­nych czyn­no­ści to nie jest to przy­pa­dek uży­cia a pro­ces (być może biz­ne­so­wy). Przypadek uży­cia to z zasa­dy jed­na usłu­ga apli­ka­cji dają­ca jako efekt jeden kon­kret­ny rezul­tat (pro­dukt). Przypadkiem uży­cia będzie np. two­rze­nie doku­men­tu fak­tu­ry. Jeżeli fak­tu­ra ma kil­ka eta­pów zatwier­dza­nia to jest to jeden pro­ces biz­ne­so­wy mają­cy kil­ka róż­nych aktyw­no­ści: two­rze­nie nowej fak­tu­ry, kon­tro­la mery­to­rycz­na, zatwier­dze­nie. Przypadek uży­cia jest jeden: zarzą­dza­nie fak­tu­rą (przy­pa­dek typu CRUD).

      Warto też pamię­tać, że jeden przy­pa­dek uży­cia może mieć alter­na­tyw­ne sce­na­riusz i alter­na­tyw­ne ich przebiegi.…

    2. Wojtek

      Dziękuje za odpowiedź.

      Czy moż­na zasto­so­wać takie podej­ście, że pro­ces biz­ne­so­wy roz­pi­su­je­my w BPMN, nato­miast czyn­no­ści tego pro­ce­su za pomo­cą Przypadków Użycia? Przyjmijmy, że mam pro­ces two­rze­nia fak­tu­ry z kon­tro­lą mery­to­rycz­na i zatwier­dza­niem na róż­nych szcze­blach orga­ni­za­cji. Proces BPMN opi­su­je mi ogól­ny sche­mat tego pro­ce­su (utwórz->sprawdź>akceptuj->akceptuj->koniec). Natomiast przy­pad­ki uży­cia wcho­dzą w szcze­gó­ły tych czyn­no­ści, np PU wyja­śnia jak czyn­ność utwo­rze­nia fak­tu­ry się odbywa?

    3. Jaroslaw Zelinski

      Jako pod­sta­wę war­to przy­jąć ści­słą sepa­ra­cję mode­lu CIM (Computing Independent Model, źr. http://​www​.omg​.org/​mda) od mode­lu PIM apli­ka­cji (opro­gra­mo­wa­nie) będą­cej narzę­dziem w pro­ce­sie biz­ne­so­wym. Jeżeli więc model pro­ce­su w nota­cji BPMN to model CIM, a pod poję­ciem przy­pa­dek uży­cia” rozu­mie­my tu jego sce­na­riusz opi­su­ją­cy inte­rak­cję z narzę­dziem (szcze­gó­ły pra­cy z GUI), to jest to sku­tecz­na dro­ga. Warto upo­rząd­ko­wać sto­so­wa­nie pojęć pro­ces (biz­ne­so­wy), sce­na­riusz UC, inte­rak­cje itp. bez cze­go nawet zro­zu­mie­nie Pana pyta­nia sta­je się wyzwa­niem :). Jeżeli pod poję­ciem czyn­ność utwo­rze­nia fak­tu­ry” rozu­mie­my szcze­gó­ły pra­cy aktor-sys­tem to tak.

  6. Tomasz Styp-Rekowski

    Mam pyta­nie odno­śnie tego czy gdy mamy 1 przy­pa­dek uży­cia i mamy do nie­go kil­ka ście­żek alter­na­tyw­nych to czy może­my potem two­rzyć następ­ne ścież­ki alter­na­tyw­ne dla powsta­łych już ście­żek alter­na­tyw­nych głów­ne­go sce­na­riu­sza. Czy nie będzie to wte­dy zbyt roz­bu­do­wa­ny przy­pa­dek uży­cia? Jest spo­sób na uprasz­cza­nie takich sytu­acji czy po pro­stu roz­bu­do­wu­je­my go tak dłu­go aż wyczer­pie­my temat?

    1. Jaroslaw Zelinski

      Przede wszyst­kim nale­ży sobie zde­fi­nio­wać poję­cie Przypadek uży­cia”: inną defi­ni­cję przy­jął A.Cockburn, inną swe­go cza­su przy­ję­to w RUP (to są lata 90-te) i inna jest w obec­nym UML (pole­cam jed­nak ory­gi­nal­ną spe­cy­fi­ka­cję a nie książ­ki!). Jeżeli pro­jekt ma być cały w UML i ma być spój­ny, nie pozo­sta­je nic inne­go jak uzna­nie defi­ni­cji UML. Tu zaś spra­wa się uprasz­cza, bo sko­ro przy­pa­dek uży­cia to uży­cie apli­ka­cji w celu osią­gnię­cia okre­ślo­ne­go rezul­ta­tu” (tu zwra­cam uwa­gę, że cel ma czło­wiek, opro­gra­mo­wa­nie daje jakiś rezul­tat) to sce­na­riusz będzie raczej” jeden, z ewen­tu­al­ny­mi warian­ta­mi wyni­ka­ją­cy­mi z tego, że narzę­dzie jakim jest apli­ka­cja, może zare­ago­wać warian­to­wo. Tu czę­sto ludzie wpa­da­ją w pułap­kę mie­sza­nia kon­tek­stu biz­ne­so­we­go z kon­tek­stem apli­ka­cji, typo­wy przy­kład to przy­pad­ki uży­cia nazy­wa­ne CRUD, czy­li jeden przy­pa­dek uży­cia i czte­ry kon­tek­sty jego wyko­rzy­sta­nia. (tu wię­cej o przy­pad­kach uży­cia CRUD)

      Kolejna waż­na rzecz: z zasa­dy dia­log aktor-sys­tem posłu­gu­je się jed­nym bytem” jakim jest for­mat­ka ekra­no­wa a nie poje­dyn­cze jej pole, więc stan­dar­do­wy” sce­na­riusz ma trzy kro­ki: ini­cja­cja przy­pad­ku uży­cia, wypeł­nie­nie for­mat­ki ekra­no­wej wyświe­tlo­nej przez sys­tem i potwier­dze­nie, sys­tem potwier­dza, że przy­jął lub wyświe­tla listę błę­dów do popra­wy. Jeżeli z jakie­goś powo­du zbie­ra­nie danych” na jed­nej for­mat­ce nie satys­fak­cjo­nu­je nas, tyl­ko ten jeden krok (cała for­mat­ka na raz) dzie­li­my na mniej­sze (wpro­wa­dza­ny dane par­tia­mi). tu mogą się poja­wić alter­na­tyw­ne ścież­ki, ale nadal jest to jeden przy­pa­dek uży­cia mają­cy jeden począ­tek i jeden rezultat. 

      Tu zno­wu zwra­cam uwa­gę, że rezul­ta­tem jest postać danych a nie kon­kret­ne dane (rezul­ta­tem wpro­wa­dza­nia danych o klien­cie jest zawsze kolej­na nowa kar­to­te­ka klien­ta a nie kon­kret­na fir­ma) czy­li ten przy­pa­dek uży­cia ZAWSZE daje taki sam rezultat.

  7. Tomasz Styp-Rekowski

    Dziękuję za odpowiedź.
    Zastanawiałem się po pro­stu w jaki spo­sób opi­sać przy­pa­dek Logowanie do sys­te­mu”, w któ­rym w zależ­no­ści od róż­nych usta­wień użyt­kow­ni­ka sys­tem odpo­wia­da w bar­dzo róż­no­ra­ki spo­sób. I jeśli nie roz­bi­je się tego na kil­ka uszcze­gó­ło­wio­nych przy­pad­ków (np. logo­wa­nie do sys­te­mu użyt­kow­ni­ka z danym upraw­nie­niem lub posia­da­ją­cym dane urzą­dze­nie uwie­rzy­tel­nia­ją­ce) to powsta­nie jeden bar­dzo roz­bu­do­wa­ny z wie­lo­ma ścież­ka­mi alter­na­tyw­ny­mi (oprócz usta­wień róż­nych usta­wień użyt­kow­ni­ka docho­dzi prze­cież jesz­cze walidacja).

    1. Jaroslaw Zelinski

      Logowanie jako takie nie jest usłu­gą dla akto­ra a imple­men­ta­cją wyma­ga­nia dopusz­cza­my do pra­cy wyłącz­nie auto­ry­zo­wa­nych użyt­kow­ni­ków”. To zaś a jaki spo­sób sys­tem zare­agu­je na zacho­wa­nia użyt­kow­ni­ka zale­ży od reguł biz­ne­so­wych czy­li sta­nów okre­ślo­nych obiek­tów w sys­te­mie. Gdyby nawet logo­wa­nie było UC, to koń­czy się on w momen­cie poda­nia hasła bez błę­du. Kolejne akcje (odpo­wiedź sys­te­mu) mogą zale­żeć od tego kto jest zalo­go­wa­ny czy­li kto żąda obsłu­gi i efek­ty mogą być zależ­ne od iluś tam reguł. Co do zasa­dy regu­ły biz­ne­so­we nie sa pro­ce­sa­mi (ani sce­na­riu­sza­mi), pole­cam stro­nę: BRGroup.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.