z cyklu: "USE CASE'owe historie" - za czy przeciw?

Odpowiedz Nowy wątek
2006-09-11 18:11

Rejestracja: 13 lat temu

Ostatnio: 13 lat temu

0

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

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

user image

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

  2. 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 ?

  3. 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 ?

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

  5. sprobuje wiec utworzyc diagram dla modulu galerii, JEGO WYBRANA CZĘŚĆ WYMAGAŃ po to by ukazac kolejny dylemat, oto 2 wersje:

user image

  1. 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 pozatym 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 ?

user image

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

  2. wersje a) i b) roznia sie przedewszystkim 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.

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

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

  5. Podsumowujac przedstawilem 3 metodologie ktore mozna wybrac:
    1) 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)
    2) 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
    3) relacje miedzy UC oraz podzial na funkcje glowne i podfunkcje robimy w spefyfikacji przypadkow uzycia - tylko sama tabelka textowa (A.Cockburn)

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

  7. pozatym dla kogo to ma byc przejrzyste? przedewszystkim 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

  8. na koniec jeszcze jedna zagadka - ktory rysunek przedstawiajacy fragment funkcjonalnosci galerii jest dobry/lepszy wedlug was ?

user image

to tyle, a teraz zapraszam do dyskusji ;) ciekawe jak bardzo mi sie oberwie :P

Pozostało 580 znaków

2006-09-13 20:54

Rejestracja: 15 lat temu

Ostatnio: 8 lat temu

0

Tak z ciekawości mam tylko jedno pytanie: co oznaczają strzałki ----|> pomiędzy aktorami?

Pozostało 580 znaków

2006-09-13 21:32

Rejestracja: 13 lat temu

Ostatnio: 13 lat temu

0

jest to relacja generalizacji miedzy aktorami, czyli inaczej uogolnienia badz mozna tez tu mowic o dziedziczeniu - w tym przypadku "uzytkownik" jest specjalizacja "goscia", a wiec uzytkownik dziedziczy wszystkie cechy elementu ogolnego, ktorym jest gosc.
Ja to rozumiem tak, ze sa dziedziczone wszystkie przypadki uzycia wykonywane przez goscia i oprocz tego ma swoje dodatkowe, ktore moze wykonywac tylko on (uzytkownik zalogowany)

Pozostało 580 znaków

2006-09-13 22:17

Rejestracja: 15 lat temu

Ostatnio: 4 dni temu

0
walec-51 napisał(a)

Tak z ciekawości mam tylko jedno pytanie: co oznaczają strzałki ----|> pomiędzy aktorami?

e-lucas napisał(a)

sa dziedziczone wszystkie przypadki uzycia wykonywane przez goscia i oprocz tego ma swoje dodatkowe

Aktor jest tak naprawdę klasą (ale wyszczególnioną) więc te strzałki to generalizacja-specjalizacja. Opróc use case'ów dziedziczy również atrybuty i metody (oczywiście, jeżeli nie są prywatne). W tej perspektywie to ma małe znaczenie, ale przy przechodzeniu do diagramu klas muszą one zostać.

A, jeszcze co do pt. 15
a) z tego diagramu wynika, że uzytkownik moze 'zainicjowac' ocenianie zdjecia, albo dodawanie komentarza. Ale nie moze zainicjować przypadku oglądania zdjęcia jako-tako.
c) tutaj użytkownik może zainicjować oglądanie zdjęcia, ale w szczególnych przypadkach będzie to połączone z oceną, lub komentowaniem.
Moim zdaniem 'lepszy' jest c), ale to zależy od definicji systemu.

Pozostało 580 znaków

2006-09-13 23:38

Rejestracja: 13 lat temu

Ostatnio: 13 lat temu

0

co do wypowiedzi id02009 i pkt 15 - widze ze podzielasz moje zdanie (tu chodzi o wyjasnienie w sumie juz nieistniejacego mojego sporu z kolega;), dodatkowo bym tu dodal ze ciezko mi sobie wyobrazic przeniesienie tego diagramu UC do projektu systemu gdzie zeby ocenic zdjecie najpierw gdzies sobie klikam "ocen zdjecie" a dopiero pozniej mi sie pokazuje fotka - troche to takie nieintuicyjne (inne pytanie czy tak moge te diagramy use case odbierac), aczkolwiek tez tak system mozna zrealizowac i jest tak jak mowisz ze to wlasnie zalezy od koncepcji realizacji systemu

a jak tam poprzedzajaca punkt 15 teoria ;) wiem ze duzo ale jesli byles wytrwaly i doczytales to powiedz mi czy sie z takim mysleniem zgadzasz czy raczej nie za bardzo

pozdrawiam

Pozostało 580 znaków

2006-09-14 01:12

Rejestracja: 15 lat temu

Ostatnio: 4 dni temu

0

Gdyby nie to, że mam dziś kłopoty z zaśnięciem, to chyba nigdy bym na tak długiego posta nie odpowiadał ;]

e-lucas napisał(a)
  1. 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
    Hmm, moim zdaniem przypadki użycia to inaczej są funkcjonalności całego systemu. Oczywiście możesz pogrupować sobie poszczególne przypadki (galeria etc.) i umieszcać na osobnych diagramach.

  2. 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
    UML jest językiem do opisu złożonych systemów z wielu perspektyw. Nie widzę przeszkód, żeby istniały diagramy ogólne z wszystkimi przypadkami dla całego systemu i jednocześnie szczegółowe- opisujące poszczególne moduły

  3. (...) 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 ?
    Wydaj mi się, że tutaj masz rację.

  4. 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 ?
    Moje rozumowanie jest takie: use case o danej nazwie w systemie jest jeden. Jeżeli występuje na dwóch diagramach, to oznacza tą samą funkcjonalność (wymagania użytkownika). Dlatego tak ważne jest zdefiniowanie nazw i trzymanie się ich.

  5. (...)
    Tego punktu nie rozumiem. Może na podstawie tego, co napisałem Ci na temat poprzedniego punktu spróbuj ponownie opisać ten problem.

    • nie ma pytania, więc nie ma odpowiedzi ;P
  1. 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 ?
    Nie wiem.

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 pozatym 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 ?
Właściwie odpowiedziałeś sobie na to pytanie- asocjacja jest dziedziczona, zatem ta jedna jest niepotrzebna. Możliwe, że jest inny sposób na przedstawienie tej sytuacji.

    • Myślę tak: dokumentacja w UML-u nie składa się jedynie z idealnych diagramów. Są też wcześniejsze wersje dokumentów, które też są brane pod uwagę. Dokumentują one między innymi ewolucję postrzegania systemu podczas projektowania. Zatem wersja b) byłaby pierwszym (spontanicznym, trywialnym) podejściem do problemu. Wersja a) byłaby kolejną wersją, bardziej zaawansowaną.

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.
Powinien. Ale dokumentacja jest też często dla ludzi, którzy dostali projekt do kontynuowania i chcą poznać ścieżkę (ewolucja powyżej), jaką przeszedł projekt, żeby go lepiej zrozumieć.

Mam wrażenie, że myślisz iż jeżeli projekt ma mieć diagram UC, to ma to być jeden-idealny diagram. Moim zdaniem można pozwolić sobie na rozrzutność i mieć kilka wersji tych samych nawet diagramów.

  1. -- tego znowu nie zrozumiałem. Może to wina godziny, ale może spróbuj napisać to jaśniej :)

  2. -- o tym w ogóle nie słyszałem, więc nie będę się wypowiadał. Zapytam za to: czy taka tabelka jest zgodna z językiem UML, czy to jakaś 'samowolka' ? ;)

  3. Jako, że znacznej części nie zrozumiałem, nie będę komentował.

  1. 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...
    "Obraz mówi więcej niż tysiąc słów", dlatego się z tobą zgodzę. Chociaż z drugiej strony, taka szczegółowa tabela byłaby świetnym uzupełnieniem diagramu i rozwiewała by wszelkie wątpliwości

  2. pozatym dla kogo to ma byc przejrzyste? przedewszystkim chyba dla architekta/projektanta do ktorego trafia ten diagram, a on ciemna masa przeciez chyba nie jest?
    Raczej nie jest. Ale dlaczego nie dać mu możliwości zapoznania się z ogólną wizją, zanim będzie musiał zagłębić się w szczegóły? To znacznie ułatwia pracę.

Ja z kolei dodam, że nie jestem żadnym autorytetem jeśli chodzi o UML i moje odpowiedzi, to głównie to "jak ja to czuję". Nie jest to niczym poparte, oprócz mojej intuicji. Dlatego traktuj to z rozsądną dozą nieufności.

Pozdrawiam

ps do drugiego postu:

iezko mi sobie wyobrazic przeniesienie tego diagramu UC do projektu systemu gdzie zeby ocenic zdjecie najpierw gdzies sobie klikam "ocen zdjecie" a dopiero pozniej mi sie pokazuje fotka - troche to takie nieintuicyjne (inne pytanie czy tak moge te diagramy use case odbierac),
Przy UC trochę za wcześnie, żeby o interfejsie myśleć, ale w sumie do tego, w moim przypadku, musiało dojśc, żebym pojął różnicę w tych diagramach ;)
Ale idąc dalej w rozmyślaniach: gdyby przy[padek a) miał zaistnieć np. w takiej formie: klikam opcję 'oceń zdjęcia' i wyświetlają mi się zdjęcia i potem klikam jakąś ocenę, to de facto kliknięcie 'oceń zdjęcia' zaowocowało przeglądnięciem zdjęcia. Jak w ten sposób o tym myślę, to ta wersja zaczyna mieć dla mnie co raz mniej sensu...

Pozostało 580 znaków

2006-09-14 11:20

Rejestracja: 13 lat temu

Ostatnio: 13 lat temu

0
id02009 napisał(a)

Gdyby nie to, że mam dziś kłopoty z zaśnięciem, to chyba nigdy bym na tak długiego posta nie odpowiadał ;]

wiem, ze zadanie nie bylo proste wiec tymbardziej jestem wdzieczny za poswiecony czas ;) mysle, ze piwo za cierpliwosc przy czytaniu oraz odwage, ze w ogole podjales temat Ci sie nalezy ;)

dam Ci jeszcze szansy odp. odpisujac na Twoje ;) wiekszosc jest typu TAK/NIE wiec sprobuj i to wyzwanie podjac ;)

Hmm, moim zdaniem przypadki użycia to inaczej są funkcjonalności całego systemu. Oczywiście możesz pogrupować sobie poszczególne przypadki (galeria etc.) i umieszcać na osobnych diagramach.

no tak, calego systemu, ale tak jak mowisz pogrupowalem sobie te funkcjonalnosci na moduly, a ze tyle jest tych wymagan wobec calego systemu to zrobilem nieco wieksza hierarchie, ktora wyroznia przypadki uzycia na poziomie celu uzytkownika z perspektywy calej strony (przegladaj galerie,pliki itd) jak i z perspektywy poszczegolnych modulow (moglbym projektowac sama galerie no i wtedy mam UC na poziomie celu uzytkownika i szczegolowe, ale w tym wypadku galeria jest tylko jednym z wielu modulow wiec dochodzi jeszcze jeden poziom hierrchii-podobna analogie mozna by opisac na przykladzie projektowania samego "writera" z OpenOffice jak i projektowania calego OpenOfficea), wydaje mi sie ze jest to ok?

UML jest językiem do opisu złożonych systemów z wielu perspektyw. Nie widzę przeszkód, żeby istniały diagramy ogólne z wszystkimi przypadkami dla całego systemu i jednocześnie szczegółowe- opisujące poszczególne moduły

no ja tez tak uwazam, UML jest tu elastyczny, zreszta nie tylko tutaj i wszystko zalezy jak komu wygodnie. Nie odniosles sie bezposrednio do kwestii tych 9 UC na diagram, ale rozumiem przez to, ze rowniez dla Ciebie nie jest to glowna zasada, ktora powinienem sie kierowac przy tworzeniu diagramow ?

  1. 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 ?
    Moje rozumowanie jest takie: use case o danej nazwie w systemie jest jeden. Jeżeli występuje na dwóch diagramach, to oznacza tą samą funkcjonalność (wymagania użytkownika). Dlatego tak ważne jest zdefiniowanie nazw i trzymanie się ich.

no tak, ale czy pakiety nie ograniczaja tutaj wlasnie przestrzeni nazw? stosuje StarUML i owszem - w jednym pakiecie nie dasz rady dodac drugiego UC o tej samej nazwie, ale w roznych juz tak. Zgadzam sie ze to ogolnie ta sama funkcjonalnosc no bo dla przykladu "Dodaj komentarz do zdjecia" oraz "Dodaj komentarz do pliku" reprezentuje w sumie funkcjonalnosc "Dodaj komentarz" - jesli nie mam pakietow i powiedzmy zbieram wymagania samej galerii gdzie moge komentowac i album, i zdjecie to oczywiscie stosuje ten sam UC "Dodaj komentarz", ale jesli juz mam kilka pakietow - np jeden do galerii i drugi do plikowni to wole sobie zrobic osobne UC by cala funkcjonalnosc danego modulu miec w jednym miejscu - nie wiem czy to do konca dobre podejscie bo tez skladanial bym sie ku temu by minimalnie sie rozniaca funkcjonalnosc zawrzec w jednym UC, ale z drugiej strony modelujac diagram jednego modulu skupiam sie tylko na okreslaniu jego funkcjonalnosci, zreszta UC niekoniecznie musza miec przelozenie od razu na kod (kazdy z osobna to ta sama funkcja) bo projektant powinien zauwazyc te podobne funkcjonalnosci i odpowiednio zareagowac,a na poziomie implementacji to juz na pewno powinna byc jedna funkcja do komentarzy tylko z roznymi atrybutami - mozna sie z tym zgodzic ?

  1. (...)
    Tego punktu nie rozumiem. Może na podstawie tego, co napisałem Ci na temat poprzedniego punktu spróbuj ponownie opisać ten problem.

tu chodzilo o te perspektywy wymagan calej strony i wybranego modulu - opisalem przyklad w 1b) z pakietem OpenOffice - ze przy tak zlozonych systemach ciezko wyroznic tylko 2 poziomy celow/wymagan uzytkownika- (glowny i szczegolowy), chcialem tez tam pokazac co powstanie jak sie nie pogrupuje wymagan - wyobraz sobie diagram na ktorym jest 1 aktor i od niego idzie 200 asocjacji do 200 UC - za ciekawie by to nie wygladalo, a podzial na 20 diagramow po 10 UC tez za specjalnie sprawy by nie zalatwial chyba ze logicznie sie podzieli te wymagania. Najwazniejsza kwestia jednak bylo to czy zagranie wprowadzajace cele uzytkownika z perspektywy calej strony i wybranego modulu jest OK i czy nie mieszanie zebranych tak wymagan glownych na 1 diagramie tez jest OK (PS. tyle tekstu pisze, a jednak dalej nie do konca udaje mi sie przekazac sens sprawy :/ cos chyba ze mna nie tak)

    • nie ma pytania, więc nie ma odpowiedzi ;P
      -nie kazdy punkt byl pytaniem ;) to byl przedstawiony taki tok myslowy, ktory chcialem zweryfikowac, no a punkt 6 w sumie odnosil sie do diagramu, ktorego bledy mozna bylo wytknac o ile takie sa, a pewnie sa ;)

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 pozatym 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 ?
Właściwie odpowiedziałeś sobie na to pytanie- asocjacja jest dziedziczona, zatem ta jedna jest niepotrzebna. Możliwe, że jest inny sposób na przedstawienie tej sytuacji.

czyli slusznie rozumuje :) dodalem ja tutaj by podkreslic na diagramie, ze akurat to robi uzytkownik zalogowany - niby wprowadzona specjalizacja mowi mi ze akurat ja moze wywolac tylko uzytkownik, w opisie UC tez moge to zrobic, ale na pierwszy rzut oka ogladajac digram nie kazdy to moze tak zinterpretowac (tu mam jeszcze jedna zagadke, ale to w innym temacie dam), pytanie czy taka nadmiarowosc jest szkodliwa? chyba nie. Nie jestem tu konsekwentny i nie daje asocjacji od aktora do kazdego przypadku ktory on uzywa, ale to chyba tez nie jest zle ?

    • Myślę tak: dokumentacja w UML-u nie składa się jedynie z idealnych diagramów. Są też wcześniejsze wersje dokumentów, które też są brane pod uwagę. Dokumentują one między innymi ewolucję postrzegania systemu podczas projektowania. Zatem wersja b) byłaby pierwszym (spontanicznym, trywialnym) podejściem do problemu. Wersja a) byłaby kolejną wersją, bardziej zaawansowaną.

i taka odpowiedz bardzo mi pasuje i sie z nia zgadzam :)

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.
Powinien. Ale dokumentacja jest też często dla ludzi, którzy dostali projekt do kontynuowania i chcą poznać ścieżkę (ewolucja powyżej), jaką przeszedł projekt, żeby go lepiej zrozumieć.
Mam wrażenie, że myślisz iż jeżeli projekt ma mieć diagram UC, to ma to być jeden-idealny diagram. Moim zdaniem można pozwolić sobie na rozrzutność i mieć kilka wersji tych samych nawet diagramów.

no przedewszystkim dla nich ona jest (a takze np moze byc uzywana na szkoleniach przyszlych uzytkowikow) - ok,czyli wyroznilbys podobnie jak pan S.Wrycza na kilku rodzajach diagramow (akurat w UseCase nie) poziom konceptualny i taki powiedzmy "implementacyjny", i ze oba z nich mozna zawrzec w projekcie ? OK, pasi mi to :] i masz racje ze chcialem jeden idealny zawrzec;)

  1. -- tego znowu nie zrozumiałem. Może to wina godziny, ale może spróbuj napisać to jaśniej :)
    no moze to nie byc proste jak nie czytales ksiazki A.Jaszkiewicza - niemniej zeby tego za bardzo nie rozwlekac to rozwine ten punkt w kolejnym poscie

  2. -- o tym w ogóle nie słyszałem, więc nie będę się wypowiadał. Zapytam za to: czy taka tabelka jest zgodna z językiem UML, czy to jakaś 'samowolka' ? ;)
    tabelka nie nalezy juz wlasciwie do uml chyba, wiem na pewno ze uml nie specyfikuje jak nalezy scenariusze UC pisac, ale czy sam opis przypadku uzycia, czyli inaczej specyfikacje danego wymagania tez jakos okresla jak pisac to nie wiem. UML zajmuje sie chyba glownie graficznym modelowaniem, natomiast w kwestii slownego upisu-dokladnej specyfikacji pozostawia chyba dosc duza swobode (np same scenariusze, ktore sa przeciez tylko czescia specyfikacji UC pozwala opisac tekstowo lub za pomoca diagramow czynnosci). Przegladajac rozne ksiazki - A.Jaszkiewicza, A.Cockburna, W.Wrycza czy M.Smiałka w ktorych kazdy autor INACZE (duzo elementow jest wspolnych oczywiscie) okresla tabelke (ew opis slowny) specyfikujaca UC to stwierdzam ze UML chyba jednak tego uzupelnienia diagramu graficznego nie precyzuje ;)

  3. Jako, że znacznej części nie zrozumiałem, nie będę komentował.
    -z poprzedniego punktu wnioskuje ze nie spotkales sie z tabelkami lub opisami slownymi precyzujacymi wymagania w postaci UC wiec ciezko i do tego punktu sie odniesc, albo ja tak pisze zle :/

  1. 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...
    "Obraz mówi więcej niż tysiąc słów", dlatego się z tobą zgodzę. Chociaż z drugiej strony, taka szczegółowa tabela byłaby świetnym uzupełnieniem diagramu i rozwiewała by wszelkie wątpliwości

a owszem, taka tabela tak czy siak bedzie - np bedzie precyzowac ktory przypadek jacy aktorzy moga uzyc, krotki opis, scenariusze przypadku, waruki wstepne i koncowe, efekt wykonania i takie tam, ale np nie bede w tej tabelce musial tekstowo opisywac ktory przypadek moze uruchomic inny przypadek(czyli nie bede opisywal relacji miedzy UC) :/ bo to by bylo ciezkie.. wole to narysowac graficznie uzywajac extendy,includy i generalizacje kosztem wiekszej zlozonosci rysunku niz jakbym mial zrobic tylko aktorow i asocjacje od nich do UC - pomijam juz to ze taki diagram to mi za duzo by nie pomogl w odczycie wymagan, no chyba ze chociaz kilku roznych aktorow by bylo i wykonywaliby rozne UC co taki diagram by prezentowal - to by bylo juz cos, ale i tak nie za wiele bo rownie dobrze moglbym sobie napisac na kartce aktorow, podkreslic ich gruba kreska i pod nimi wypisac wymagania - gorzj by sie czytalo od diagramy az tak? nie sadze.. a zabawy troche mniej, dlatego uwazam ze diagramy bez relacji miedzy UC sie rzadko przydaja

  1. pozatym dla kogo to ma byc przejrzyste? przedewszystkim chyba dla architekta/projektanta do ktorego trafia ten diagram, a on ciemna masa przeciez chyba nie jest?
    Raczej nie jest. Ale dlaczego nie dać mu możliwości zapoznania się z ogólną wizją, zanim będzie musiał zagłębić się w szczegóły? To znacznie ułatwia pracę.

zapewne masz racje, tylko ze rozumiem, ze ta ogolna wizja to bylby diagram bez relacji miedzy UC a tylko strzalki od aktora do wszystkich UC jakie moze wykonac - oprocz przeczytania jakie wymagania musi spelniac system gosc sie nic nie dowiaduje, a te wymagania rownie dobrze moze wyczytac z "chmurek" UseCaseoych nie analizujac relacji, no ale faktem jest ze ogolnie moze to byc trudniejsze wiec zgadzam sie z Toba ;)

ps do drugiego postu:

iezko mi sobie wyobrazic przeniesienie tego diagramu UC do projektu systemu gdzie zeby ocenic zdjecie najpierw gdzies sobie klikam "ocen zdjecie" a dopiero pozniej mi sie pokazuje fotka - troche to takie nieintuicyjne (inne pytanie czy tak moge te diagramy use case odbierac),

Przy UC trochę za wcześnie, żeby o interfejsie myśleć, ale w sumie do tego, w moim przypadku, musiało dojśc, żebym pojął różnicę w tych diagramach ;)
---tak, prawda, ale jak juz robisz diagram nie na takim poziomie ogolnym (konceptualnym) a nieco bardziej szczegolowym no to ciezko extenda nie przyjac jako taka klikalna opcje danego przypadku, co wiecej - mysle ze to nie jest blad nawet bo juz specyfikowanie wymagan moze choc nie musi rodzic juz jakas wstepna wizje produktu. Powiem jeszcze wiecej - A.Cockubrn w ksiazce "Jak pisac efektowne przypdki uzycia" na str 255 w przypomnieniach zawiera punkt: "Trzymaj sie z dala od graficznego interfejsu uzytkownika" i podaje przyklad czego nie nalezy robic i moze wielu z was byc zaskoczonych ale przyklady dotycza wpisow w scenariuszu a nie diagramu UC - np przykladem uznanym jako zly jest: "uzytkownik wybiera funkcje i naciska ok", albo "system wyswietla ekran glowny z funkcjami do wyboru", ale to sa elementy scenariusza przypadku uzycia!
widome jest ze i na diagramie nie powinno sie odnosic bezposrednio do interfejsu, ale nigdzie w zadnej ksiazce nie wyczytalem by powiedzmy extend jakiejs funkcji/przypadku uzycia (czyli w sumie opcja jakiegos przypadku) rozumiana dla ulatwienia jako dodatkowy przycisk ekranu ktory jest wynikiem wywolania bazowego przypadku uzycia bylo zle, i nie widze sensownego uzasadnienia by w rozmowie z klientem np zapytac: "czyli jak pan juz oglada to zdjecie to chcialby pan rowniez je ocenic wtedy lub dodac komentarz?" i przedstawic to zdanie za pomoca 2 extendow "dodaj komentarz" i "ocen zdjecie" dla bazowego przypadku "przegladaj zdjecie" - czy jest tu gdzies blad myslowy ?

Ale idąc dalej w rozmyślaniach: gdyby przy[padek a) miał zaistnieć np. w takiej formie: klikam opcję 'oceń zdjęcia' i wyświetlają mi się zdjęcia i potem klikam jakąś ocenę, to de facto kliknięcie 'oceń zdjęcia' zaowocowało przeglądnięciem zdjęcia. Jak w ten sposób o tym myślę, to ta wersja zaczyna mieć dla mnie co raz mniej sensu...

no ja tak wlasnie tak to postrzegam rowniez i tez nie ma to dla mnie sensu, pytanie czy tak wlasnie nalezy interpretowac diagram? czy tok myslowy jest dobry?

pozdrawiam i raz jeszcze dziekuje za odp - ja rozumiem ze temat jest bardzo dlugi, ale wydaje mi sie ze tyle tu ciekawych kwestii jest poruszanych ze warto sie nim zainteresowac - kazdy sie cos przy okazji moze nauczy

Pozostało 580 znaków

framer
2006-09-20 23:25
framer
0

Dotyczy pt.15
Własnie przegłądałem książke i spodobało mi się skojażenie <incude> i <extend>. Include można skojażyć jako ?I? czyli w twoim przypadku a) ?Dodaj komentaż I przegłądaj zdjęcie? oraz ?Oceń zdjęcie I przegłądaj zdjęcie? co nie za bardzo pasuje . A Extend skojażone jako ?Po przez? czyli w przypadku b) ?Przegłądaj zdjęcie po przez dodanie komentarza? też nie za bardzo. Natomiast mi sie wydaje że najliepiej było by zrobić tak:
Aktor -----|> UC przegłądaj zdjęcie - - -(include)- - -> UC Dodaj komentarz. Wedłóg takiego skojażenia wychodzi: ?Przglądaj zdjęcie I Dodaj komentarz?.

Pozostało 580 znaków

2006-09-22 20:22

Rejestracja: 15 lat temu

Ostatnio: 4 dni temu

0

Aktor -----|> UC przegłądaj zdjęcie - - -(include)- - -> UC Dodaj komentarz. Wedłóg takiego skojażenia wychodzi: ?Przglądaj zdjęcie I Dodaj komentarz?.

Moim zdaniem to trochę niefortunne wytłumacznie. Dlatego, że "I" się kojarzy z logicznym "I". Czyli w tym przypadku sugeruje to, że zawsze jak przeglądasz zdjęcie dodajesz komentarz.
A tak naprawdę oznacza, że przypadek Przglądaj zdjęcie czasami jest rozszerzany przez przypadek 'dodaj komentarz' albo 'oceń zdjęcie'.
ps. Jaka to książka?

Pozostało 580 znaków

2006-09-22 21:36

Rejestracja: 13 lat temu

Ostatnio: 13 lat temu

0

include wlacza scenariusz wlaczanego przypadku uzycia do przypadku bazowego - ciezko tu jakos odniesc sie do "I", ktory bardziej pasuje do jakiegos wyrazenia logicznego - mozna tu jakby powiedziec, ze jest wywolywany bazowy I wlaczany przypadek uzycia - stanowia wtedy jakby jeden wiekszy przypadek uzycia-takie tlumaczenie tego "I" jestem w stanie pojac, natomiast to "poprzez" to juz ciezko

przychylam sie do zdania id2009 i takze zapytam co to za ksiazka ;)

Pozostało 580 znaków

framer
2006-09-23 09:27
framer
0
e-lucas napisał(a)

mozna tu jakby powiedziec, ze jest wywolywany bazowy I wlaczany przypadek uzycia - stanowia wtedy jakby jeden wiekszy przypadek uzycia-takie tlumaczenie tego "I" jestem w stanie pojac,

Dokładnie o to mi chodziło. Na przykłądzie logowania/wylogowania użytkownika do systemu.

http://www.vado.pl/images/uc1.png

1.Zarządzaj własną sesją POPRZEZ logowanie I zapisz do rejestru .
2.Zarządzaj własną sesją POPRZEZ wylogowanie I zapisz do rejestru .

e-lucas napisał(a)

przychylam sie do zdania id2009 i takze zapytam co to za ksiazka

http://www.lideria.pl/sklep/opis?nr=36448&id=1200CjrvmAmNY

Ksiązka jest taka sobie. Generalne tam nie było tego skojarzenia przedstawiono bezpośrednio tylko wychodziło to z przykładów.

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 0, botów: 1

Robot: CCBot