Wprowadzenie

Przypadki uży­cia już opi­sy­wa­łem, mię­dzy inny­mi w arty­ku­le Paradygmat obiek­to­wy i przy­pad­ki uży­cia, jed­nak doty­czył on błę­dów popeł­nia­nych przy two­rze­niu tych dia­gra­mów. Tak więc teraz jak naj­bar­dziej sen­sow­ne jest odpo­wie­dzieć na kolej­ne pyta­nie: sko­ro nie na dia­gra­mie przy­pad­ków uży­cia, to gdzie mają być szcze­gó­ły? No i dosta­łem takie­go maila (z oczy­wi­stych powo­dów został zano­ni­mi­zo­wa­ny i uproszczony):

Witam, Będę wdzięcz­ny za pod­po­wiedź. Jeśli mode­lu­je­my dia­gram przy­pad­ków uży­cia sys­te­mu, gdzie akto­rem jest użyt­kow­nik back offi­ce i jed­nym z przy­pad­ków uży­cia jest mody­fi­ka­cja danych klien­ta. To w jaki spo­sób naj­le­piej wyra­zić, że w ramach tej mody­fi­ka­cji moż­na:
1. Zaktualizować imię i nazwi­sko.
2. Adres.
3. Zgodę na prze­twa­rza­nie danych.
Itd.
A) Czy naj­le­piej stwo­rzyć dedy­ko­wa­ny dia­gram uszcze­gó­ła­wia­ją­cy poszcze­gól­ne opcje mody­fi­ka­cji?
B) Czy na głów­nym dia­gra­mie przy­pa­dek uży­cia z mody­fi­ka­cja powi­nien zostać roz­sze­rzo­ny przez exten­d’y i kolej­ne przy­pad­ki uży­cia – będzie wte­dy dość gęsto bo są też inne przy­pad­ki uży­cia.
C) Możliwe opcje do mody­fi­ka­cji powin­ny zostać opi­sa­ne w for­mie tre­ści do przy­pad­ku uży­cia zwią­za­ne­go z modyfikacją?

Która opcja będzie naj­bar­dziej odpo­wied­nia? I zno­wu odpo­wiem przykładem. 

Biblioteka

W ww. poprzed­nim swo­im arty­ku­le przy­wo­ły­wa­łem już treść spe­cy­fi­ka­cji UML trak­tu­ją­cej o przy­pad­kach uży­cia. Tu więc od razu przy­kła­do­wy diagram.

Kontekst i wyma­ga­nia dla apli­ka­cji dla Biblioteki (opra­co­wa­nie własne) 

Na dia­gra­mie widać, że od apli­ka­cji ocze­ku­je­my: Kart wypo­ży­czeń, Kart czy­tel­ni­ków i Kart indek­so­wych książek. 

Nazwy przy­pad­ków uży­cia to kwe­stia przy­ję­tej kon­wen­cji. Dość czę­sto spo­ty­ka­na kon­wen­cja to cele akto­ra (np. zarzą­dza­nie wypo­ży­cze­nia­mi), jed­nak jak już swe­go cza­su pisa­łem, kon­tek­sty akto­ra (czę­sto user sto­ry) nie są dobre jako nazwa usłu­gi apli­ka­cji, bo bar­dzo czę­sto pro­wa­dzą do nie­uza­sad­nio­ne­go kom­pli­ko­wa­nia tego dia­gra­mu. Osobiście sto­su­ję kon­wen­cję opar­tą na nazwach zesta­wów infor­ma­cji (doku­ment, mock-up ekra­nu) jaki­mi apli­ka­cja zarzą­dza (pamię­taj­my, że sys­tem nie wie” w jakim celu jest uży­wa­ny, to wie jedy­nie aktor). Dlatego tu mamy Karty wypo­ży­czeń, a nie osob­ne: Wypożyczenia i Zwroty, bo zwrot książ­ki pole­ga na wpi­sa­niu daty zwro­tu na Karcie wypo­ży­cze­nia, nie jest to osob­ny przy­pa­dek uży­cia (!), a kolej­ny kon­tekst uży­cia usłu­gi Karty wypo­ży­czeń. Tak więc apli­ka­cja świad­czy usłu­gę (przy­pa­dek uży­cia) Karty wypo­ży­czeń a nie dwie: wypo­ży­cze­nia ksią­żek i zwro­ty ksią­żek, bo to są kon­tek­sty akto­ra (może ich być wię­cej o czym za chwi­lę). Pozostałe dwa przy­pad­ki uży­cia analogicznie. 

No i teraz pyta­nie: jak poka­zać, że moż­li­we jest zak­tu­ali­zo­wa­nie okre­ślo­nych danych? Np. wska­za­ne powy­żej doda­nie daty zwro­tu? Musimy mieć makie­tę Karty wypożyczenia:

Makieta Karty wypo­ży­cze­nia (tu dia­gram struk­tur połą­czo­nych UML)

Jak widać to tu wła­śnie jest miej­sce na zapis fak­tu, że czyn­ność (aktyw­ność w pro­ce­sie biz­ne­so­wym) zwrot książ­ki pole­ga na wpro­wa­dze­niu daty odda­nia książ­ki w pole data_zwrotu. Najgorszym pomy­słem było by doda­nie kolej­ne­go przy­pad­ku uży­cia na dia­gra­mie przy­pad­ków użycia.

A co np. z wyma­ga­niem: sys­tem powi­nien pozwa­lać na nali­cza­nie kar za prze­trzy­ma­nie książ­ki”. I zno­wu: naj­gor­szy pomysł to kolej­ny nowy przy­pa­dek uży­cia: nali­cza­nie kar. Naliczenie kary to wyko­na­nie ope­ra­cji na polach data wypo­ży­cze­nia i data zwro­tu, oraz zapi­sa­nie wyni­ku w polu kara za prze­trzy­ma­nie. Realizacja tego wyma­ga­nia to mody­fi­ka­cja (uzu­peł­nie­nie) makie­ty Karty wypo­ży­cze­nia, a nie powięk­sza­nie dia­gra­mu przy­pad­ków użycia.Makieta for­mu­la­rza słu­ży wła­śnie do zapi­sy­wa­nia takich szcze­gó­łów. Wzór na nali­cze­nie kary zapi­su­je­my osob­no jako regu­łę biz­ne­so­wą, np: Jeżeli książ­ka nie zosta­nie zwró­co­na w cza­sie okre­ślo­nym przez Regulamin biblio­te­ki, nale­ży nali­czyć karę w wyso­ko­ści okre­ślo­nej przez ten regu­la­min”. To zna­czy, że albo aktor sam nali­cza i wpi­su­je wyso­kość pobra­nej kary, albo potrzeb­ny będzie kolej­ny przy­pa­dek uży­cia (nie ma go na powyż­szym dia­gra­mie), np. Ustawienie para­me­trów sys­te­mu, udo­ku­men­to­wa­ny kolej­ną makie­tą, zawie­ra­ją­cą mię­dzy inny­mi mak­sy­mal­ną licz­bę dni wypo­ży­cze­nia i karę za każ­dy dzień prze­trzy­ma­nia. To pozwo­li­ło by nali­czać kary automatycznie. 

Na powyż­szym dia­gra­mie przy­pad­ków uży­cia poka­za­łem tak­że reali­za­cję wyma­ga­nia sys­tem powi­nien pod­po­wia­dać dane książ­ki po wpi­sa­niu nume­ru ISBN (deta­le tego jak sie to odby­wa doku­men­tu­je sie w sce­na­riu­szu – dia­gram sekwen­cji – Dodaj książ­kę, przy­pad­ku uży­cia Karty Indeksowe Książek, przy­po­mi­nam, że przy­pa­dek może mieć wię­cej niż jeden sce­na­riusz). Kolejne wyma­ga­nie: sys­tem powi­nien kon­tro­lo­wać to, czy czy­tel­nik nie został skre­ślo­ny z listy stu­den­tów” zosta­ło zre­ali­zo­wa­ne z pomo­cą inte­gra­cji z apli­ka­cją Dziekanat w spo­sób ana­lo­gicz­ny jak opis dla ISBN. 

A.Cocburn pisze w Hexagonal archi­tec­tu­re :

Przypadki uży­cia i gra­ni­ca apli­ka­cji
Przydatne jest uży­cie sze­ścio­kąt­ne­go wzor­ca archi­tek­tu­ry, aby wzmoc­nić pre­fe­ro­wa­ny spo­sób pisa­nia przy­pad­ków uży­cia. Częstym błę­dem jest pisa­nie przy­pad­ków uży­cia, któ­re zawie­ra­ją intym­ną wie­dzę na temat tech­no­lo­gii znaj­du­ją­cej się poza każ­dym por­tem. Te przy­pad­ki uży­cia zyska­ły słusz­nie złą sła­wę w bran­ży, ponie­waż są dłu­gie, trud­ne do odczy­ta­nia, nud­ne, kru­che i kosz­tow­ne w utrzymaniu.Rozumiejąc archi­tek­tu­rę por­tów i adap­te­rów, widzi­my, że przy­pad­ki uży­cia powin­ny być gene­ral­nie pisa­ne na gra­ni­cy apli­ka­cji (wewnętrz­ny sze­ścio­kąt), aby okre­ślić funk­cje i zda­rze­nia obsłu­gi­wa­ne przez apli­ka­cję, nie­za­leż­nie od tech­no­lo­gii zewnętrz­nej. Te przy­pad­ki uży­cia są krót­sze, łatwiej­sze do odczy­ta­nia, tań­sze w utrzy­ma­niu i bar­dziej sta­bil­ne w czasie.

https://​ali​sta​ir​.cock​burn​.us/​h​e​x​a​g​o​n​a​l​-​a​r​c​h​i​t​e​c​t​u​re/

Na zakończenie

Tworzenie dia­gra­mów np. jak ten:

(źr: Developing a Knowledge-Based Lean Six Sigma Model to Improve Leadership?s Performance in Healthcare Environment)

mija się z celem. Jest to dia­gram, któ­ry nie pomo­że deve­lo­pe­ro­wi, nie zawie­ra żad­nych istot­nych danych, a uży­cie go do doko­na­nia wyce­ny np. meto­dą punk­tów funk­cyj­nych czy COSMIC , da w efek­cie wyso­ce zawy­żo­ne, nie­ade­kwat­ne wyniki. 

Sposób doku­men­to­wa­nia reguł biz­ne­so­wych opi­sa­łem w arty­ku­le: SBVR czy­li regu­ły biz­ne­so­we i słow­nik. a two­rze­nie makiet for­mu­la­rzy w Wymagania na for­mu­la­rze czy­li dia­gram struk­tur złożonych.

Pełna doku­men­ta­cja sys­te­mu dla biblio­te­ki zosta­nie nie­ba­wem umiesz­czo­na na blo­gu. Zapoznaj się tak­że z Dokumentowanie przy­pad­ków uży­cia.

Źrodła

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).

Dodaj komentarz

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