Ponizej przedstawiam troche przydlugawy opis mojego punktu widzenia na przypadki uzycia - takie moje przemyslenia wraz pytaniami/watpliwosciami. Kazda z istotniejszych kwestii, ktora mozna skomentowac ponumerowalem by latwiej to mozna bylo zrobic. Zapraszam do lektury, a pozniej do dyskusji!.
- Mam zbudowac strone internetowa zawierajaca wiele dzialow (modulow) - np galerie, katalo firm, katalog linkow spis ogloszen i wiele wiele innych. Ponizej przedstawiam przypadki uzycia na poziomie celu uzytkownika CALEJ STRONY - czy to jest poprawne? dodam ze tych celow na poziomie uzytkownika (modulow strony) bedzie powiedzmy z 20-30
-
ktos mi powie ze jakbym umiescil wszystkie przypadki na poziomie celu i bylo by ich z 20-30 to by bylo za duzo no bo zasada 9 UC na diagram... no ale ja nie widze sensu tego rozbicjac na 2-3 diagramy nawet jesli by bylo 30 tych UC - czy ktos mi jest w stanie przedstawic jakies sensowne uzasadnienie? przejrzystosc..hmm, ale czy dobre pogrupowanie UC na cala kartke formatu A4 jest az tak zle? wiecej niby do ogladania ale przynajmniej jest obraz calosci
-
Teraz idziemy dalej - po okresleniu glownych wymagan funkcjonalnych i podzialu ich na moduly (mimo ze moglo by sie wydawac ze niby to czesc nalezaca do projektanta architektury no to przeciez na poziomie okreslania wymagan tez moge sobie je te wymagania pogrupowac - to ze pozniej przelozy sie to na komponenty nie ma chyba wiekszego znaczenia ?
-
rozpisuje sobie teraz na osobnym diagramie wymagania funkcjonalne samego np modulu galerii - pytanie czy teraz bedac na poziomie galerii tworza mi sie nowe wymagania uzytkowniaka na poziomie celu GALERII ? (nie na poziomie calej strony!) ktore dotycza tylko samej galerii i z jej punktu widzenia ?
-
przyjmuje ze wlasnie tak jest - gdyby tak nie bylo no to wtedy do wymagan na poziomie celu uzytkownika ktore wymienilem w pierwszym diagramie musialbym dolozyc wymagania na poziomie celu uzytkownika zwiazane z galeriia, potraktowac ja rownorzednie (choc widac chyba ze to sa inne poziomy wymagan - mniej i bardziej szczegolowe) co przyjmujac ze kazdy z powiedzmy 20 modulow ma 10 waznych wymagan na poziomie celu uzytkownika no to dalo by mi na diagramie glownym 200 przypadkow uzycia i 200 asocjacji prowadzacych do jednego aktora (czesc z nich by prowadzila oczywiscie do uzytkownika uprzywilejowanego ktory by mogl np oceniac zdjecia czy dodawac komentarze) czy potraktowanie wszystkich 200 wymagan na tym samym poziomie jest sensowne ? nie wydaje mi sie i nawet podzial na 20 diagramow by na kazdym bylo po 10 UC niczego tu nie zalatwia
-
sprobuje wiec utworzyc diagram dla modulu galerii, JEGO WYBRANA CZĘŚĆ WYMAGAŃ po to by ukazac kolejny dylemat, oto 2 wersje:
- Obie wersje porownam pozniej, a teraz chcialbym zapytac tylko czy taka generalizacja przy przegladaniu zdjecia wystarczy by pokazac ze przypadek "Dodaj Komentarz" moze wykonac tylko uzytkownik, a gosc nie ? moze jakos inaczej nalezy to zrobic ? dodalem tak testowo asocjacje miedzy uzytkownikiem i przypadkiem specjalizowanym "przeglada zdjecie", wedlug mnie ona tu jest niepotrzebna bo uzytkownik dziedziczac po gosciu i tak dostanie sie do tego przypadku uzycia, a poza tym rodzi sie inne pytanie - skoro jest ta asocjacja do przypadku uzycia uzytkownika to czemu nie ma do innych przypadkow uzycia jak dodanie komentarza czy ocena zdjecia ?
-
zanim zaczne porownanie a) i b) wspomne, ze wychodze z zalozenia ze diagramy te jako analityk wymagan rysuje wspolnie z klientem podczas spotkania na ktorym wlasnie okreslamy wymagania - takie podejscie przedstawia A.Jaszkiewicz w ksiazce "inzynieria oprogramowania" i ja sie z tym zgadzam bo na pewno to ulatwia rozmowe z klientem.
-
wersje a) i b) roznia sie przede wszystkim podejsciami - podejscie a) stara sie pokazac wszystkie relacje miedzy pokazanymi przypadkami uzycia, oprocz tego pokazuje w nie do konca moze oczywisty na pierwszy rzut oka sposob przyporzadkowanie UC do poszczegolnych klas uzytkownikow. Plusem jest pokazanie relacji, ktore jesli klient pobieznie przedstawia wymagania moga nie zostac okreslone, wszystkie wymagania mozna by tylko zebrac i oddach architektowi systemu i projektantom by sami zdecydowali co z tym zrobic, ale chyba czesciej bywa tak,ze klient mniej wiecej ma wyobrazenie co zamawia i czesto jest w stanie okreslic bardziej szczegolowo wymagania mowiac: "ja tu chcialbym robic to, a tu tamto", daje to pewne sugestie co do projektu systemu i zmniejsza szanse na to ze projektanci zaprojektuja zupelnie inaczej system niz chcial klient... i wiadomo ze nic dobrego z tego nie wyjdzie. Minusem jest dosc skomplikowany rysunek (w porownaniu do wersji b) ale jesli sie go buduje od zera razem z klientem to i on i analityk zapewne go rozumie, zwlaszcza jesli obie strony maja choc podstawowe pojecie na temat UML.
-
Wersja b kladzie glownie nacisk na podzial funkcjonalnosci wzgledem uprawnien/ról uzytkownika, rysunek duzo mniej skomplikowany, ale np nie pokazuje relacji miedzy poszczegolnymi przypadkami uzycia - np nie wiem kiedy moge ocenic zdjecie, dodac komentarz itd - wiem tylko ze takie cos moge w systemie zrobic. Jesli przyjmiemy ze wymagania sa okreslone na dosc wysokim poziomie abstrakcji to jest ok, ale... to chyba jednak troche za malo i tu przychodza z pomoca 2 podejscia: pierwsze z nich prezentuje A. Jaszkiewicz - mowa tutaj o hierarchii wymagan,ktora "opiera sie na obserwacji,ze pewne funkcje wykonywane przez system sa skladowymi (podfunkcjami) innych bardziej ogolnych funkcji".
No i fajnie, mam diagram ktorego przydatnosc A.Jaszkiewicz tlumaczy: "systemy komputerowe wykorzystywane sa przez roznych uzytkownikow korzystajacych z roznych funkcji systemu" - czyli majac diagram mam podzial wymagan wzgledem uprawnien, a majac hierarchie wymagan mam opisane relacje miedzy poszegolnymi wymaganiami, no spox. Ale zaraz - przeciez kosztem nieco bardziej skomplikowanego diagramu moge nie robic osobno tej hierarchi, a wykorzystac zaleznosci "extend", "include", generalizacje i za ich pomoca przedstawic te relacje miedzy UC - troszke sie wiecej pomecze przy diagramie ale nie bede musial robic tej hierarchi - czy to nie lepszy pomysl ? (zapewne zalezy od sytuacji choc ja uwazam ze ogolnie lepszy) -
mozna z tymi wymaganiami jesze inaczej zrobic - zebrac je w tabelce i dokladnie kazde z nich wyspecyfikowac wedlug przyjetych atrybutow, a diagramow w ogole nie robic - podejscie takie prezentuje A.Cockburn w ksiazce "jak pisac efektywne przypadki uzycia". Prezentowana w tej ksiazce tabelka dla poszczegolnych wymagan zawiera miedzyinnymi parametry do uzupelnienia jak: "Aktor glowny". "Uczestnicy i interesy" - parametry te powoduja ze nie musimy robic diagramu przypadkow uzycia, natomiast parametry: "Wyzwalacz"(okresla co uruchamia przypadek uzycia, a dla przykladu zacytuje opis tego punktu w tabelce dla przypadku uzycia "zarzadzaj raportami" gdzie we wspomnianej ksiazce pisze na str 182: "uzytkownik wybiera operacje bezposrednio poprzez interfejs exploratora" - czyli tu jest szczegolny przypadek opisany, ze nie wyzwala tego UC inny UC,a co wiecej - jest odniesienie nawet do interfejsu uzytkownika co podobno wedlug niektorych na tym etapie nie powinno miec w ogole miejsca, a wedlug mnie moze choc nie zawsze musi) oraz parametr "Poziom" (wykorzystuje sie go rowniez do okreslenia okresla nam zaleznosci miedzy przypadkami uzycia) - czyli reasumujac pierwsze 2 parametry po uzupelnieniu zastepuja nam diagramy UC, a kolejne 2 hierarchie wymagan, a sa przeciez jeszcze inne jak warunki itd. Stosujac takie podejscie rozumiem juz osoby, ktore twierdzily ze diagramy UC sa rzadko wykorzystywane w praktyce.
-
Podsumowujac przedstawilem 3 metodologie ktore mozna wybrac:
- robimy diagramy przypadkow uzycia na ktorych przedstawiamy wymagania oraz ich wzajemne relacjie - nie musimy robic hierarchii wymagan oraz w specyfikacji przypadkow, ktora uzupelnia diagram nie musimy okreslac relacji miedzy UC (Co jest na pewno trudniejsze niz w formie graficcznej)
- robimy diagramy pokazujace tylko funkcjonalnosc jaka udostepnia system dla poszczegolnych klas uzytkownikow, a relacje i podzial na podfunkcje robimy w specyfikacji przypadkow lub dodatkowo robimy tez hierarchie wymagan
- relacje miedzy UC oraz podzial na funkcje glowne i podfunkcje robimy w spefyfikacji przypadkow uzycia - tylko sama tabelka textowa (A.Cockburn)
-
moj wybor? wole zrobic sobie bardziej skomplikowany diagram niz meczys sie w poszczegolnych tabelkach z okreslaniem ktory use case jest wyzwalaczem, ktory wyzwalany i jaki jest jego poziom - szybciej mimo wszystko jako np architekt skapuje to z diagramow niz czytajac tony tekstu...
-
poza tym dla kogo to ma byc przejrzyste? przede wszystkim chyba dla architekta/projektanta do ktorego trafia ten diagram, a on ciemna masa przeciez chyba nie jest? i to ze nieco wiecej pracy przez to bedzie mial analityk wymagan (mowie o przypadku innim niz diagram b gdzie praca analityka sprowadzalaby sie tylko do spisania listy wymagan) - pamietajac o tym ze dobre zrozumienie klienta i jego wymagan jest kluczowe podczas kolejnych etapow realizowania systemu to wcale nie uwazam by ta przejrzystosc byla tu jakims problemem
-
na koniec jeszcze jedna zagadka - ktory rysunek przedstawiajacy fragment funkcjonalnosci galerii jest dobry/lepszy wedlug was ?
to tyle, a teraz zapraszam do dyskusji ;) ciekawe jak bardzo mi sie oberwie :P