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

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

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

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

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

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

0

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

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)

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.

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

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.
  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
    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
  1. (...) 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ę.
  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.
  1. (...)
    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 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 ?
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
  1. 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?
    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...

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 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 ?
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 przede wszystkim 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. 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?
    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

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

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?

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

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.

0

tak, ten diagram co dales linka jest ok, ale czy mozna powiedziec ze zawsze jest jakis extend "I" include ? w tym przypadku akurat tak, ale nie zawsze - to ogolnie zalezy gdzie w scenariuszu bazowego przypadku wlaczysz scenariusz tego includea - nie majac specyfikacji z tego diagramu rownie dobrze mozesz odczytac

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

i w punkcie 2 wcale nie musi byc to zapisane w rejestrze - zgadzasz sie ?

tu faktycznie to POPRZEZ pasuje, ale nie powiedzialbym, ze mozna tak zawsze opisywac diagramy (i dobrym przykladem ze nie mozna jest to co napisales wczesniej interpretujac moj diagram) - ja predzej bym tak opisal ten diagram:
uzytkownik "tworzy sesje uzytkownika/zarzadza swoja sesja" za pomoca/poprzez opcje logowania i wylogowania. Informacje na temat sesji sa zapisywane w rejestrze (ale co jest zapisane i kiedy to juz ten diagram nie mowi i to w specyfikacji trzeba zawrzec)

co do ksiazki to tez ja mam, ale... ten nie bylem w stanie przeczytac-topornie napisana jakos i troche zametu tam wprowadza, poza tym nie opisuje UML 2.0 - mysle ze najlepsza ksiazka jest ksiazka pana Stanisława Wryczy (taka zolta okladka), a jak chcesz nie tylko opisowke UML 2.0 ale i zastosowanie w projekcie to calkiem niezla jest pozycja pana Michała Śmiałka, ale tam bardzo szczegolowego opisu UML nie ma

0

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?
Chyba się z Tobą zgodzę.

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 ?
Bo nigdy o takiej zasadzie nie słyszałem. Nie wiem, może to coś w stylu zasady, że po ok. 2,6s ładowania strony internetowej użytkownik zaczyna się irytować? Może to wynika z jakichś badań?

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.
Programu nie znam, a co do pytania to odpowiedź bankowo jest w specyfikacji UML i w dobrych książkach. Postaram się coś znaleźć.

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 ?
Wydaje mi się, że masz rację- jeśli to większy system- może lepiej stosować osobne UC nie zawracając sobie głowy, że można to w jednym zamknąć. Ale w którymś momencie przejścia powinno zostać to zauważone i wymodelowane. Tylko myślę sobie, że jeżeli dodanie komentarza do pliku i zdjęcia(de facto też pliku) nie różnią się niczym, to naturalne wydaje się intuicyjne traktowanie tego jako jeden UC. Ale może projekt jest tak ogromny, że może jednak nie... trudno mi powiedzieć.
I jeszcze: może UML pozwala na definiowanie UC w różnych przestrzeniach nazw, które odnoszą się do jendego UC (coś a'la referencja do UC ;)) - jak coś znajdę - dopiszę

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)
Ok. Mniej więcej wiem o co chodzi. Sęk w tym, że nie znam odpowiedzi :/ Podzielenie wielu UC na powiedzmy 10 el zbiory i przedstawienie każdego zbioru na osobnym diagramie jest poprawne, a jeżeli chodzi o wygodę kożystania... cóż mając 200 UC chyba nie ma sposobu przedstawić to w czytelny sposób (trzeba improwizować). Oczywiście dzielenie na logicznie spójne części pomoga, ale to raczej nie jest wymogiem. Nie wiem co odpowedzieć na pytanie o 'mieszanie' wymagań - myślę i nic ;)

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ę, że szkodliwa nie jest. Zastanawiam się tyklko czy to faktycznie jest miejsce na zaznaczanie takich informacji? Może wystarczyłoby w specyfikacji UC zawrzeć, że 'uruchomi' go tylko zalogowany użytkownik? I tak nie wszytko można zamieścić na diagramach ;)

  1. -- 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 ;)
    Aaa! Już wiem o co chodzi :D Chodzi o specyfikacje konkretnego UC, prawda? faktycznie UML nic na ten temat nie mówi. Przez to miałem dziwne historie z ćwiczeniowcem z inżynierii, bo chciał żeby mu specyfikacje przynieść i żadan forma go nie zadowalała. Mam wrażenie, że ile firm- tyle rodzajów na specyfikowanie UCaseów ;)
  1. 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 :/
    Zwyczajne problemy z komunikacją ;) A co do pt12. to myślę, że diagram jest pomocą w zrozumieniu specyfikacji. Przedstawiasz na nim UCase'y, rozbijasz na podprzypadki i ogólnie robisz wszystko co w diagramie UC da się zrobić (bez szeleństw). A wszystkie wątpliwości rozwiewasz przy pomocy specyfikacji konkretnych UC. Do której koncepcji to pasuje najbardziej?

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
Nie zgodzę się z tobą w 100%. Nie uważam, że co się przedstawi na diagramie można pominąć w specyfikacji. Specyfikacja, jak nazwa sugeruje, zawiera wszystkie informacje na temat danego UC. Diagram pomaga jedynie ogranąć całość.

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 ;)
Chyba mamy spore zakłócenia w tym miejscu na linii ;) Nie powiedziałem, ze taki diagram powinien być bez relacji między UC. dlatego zastanawiam się, o co dokładnie pytasz... bo chyba sie zgubiłem.

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 ?
Chyba ja tym razem coś pokręciłem. Faktycznie można myśleć o UC jak o funkcjach. Może pomyliłem pojęcie funkcji z interfejsem? teraz już nie pamiętam ;) A błędu nie widzę- jak najbadziej można pytać o takie osobiste(sic!) sprawy ;P

ps. Sorki, że tak długo to trwało. Ze wszystkich moich wymówek podam jedynie tą, że trudno jest zredagować odpowiedź na tak ogromnego posta i to neutralizowało, dośc skutecznie, moją motywację by to uczynić :D

@framer: mnie osobiście to nie przekonuje- wprawdzie w tym wytłumaczeniu diagram ma sens, ale raczej w innych przypadkach mogło by być mylące. Wydaje mi się, że lepiej określać te ograniczenia jako rozszerzanie i zawieranie. I po sprawie.

Pozdrawiam

//dopisane:
Jeśli chodzi o nazywanie UC, to można używac tzw. nazwy ścieżkowej:
Nazwa_pakietu::Nazwa_UC
Wracając do pnuktu 15. Okazuje się, że diagram z include jest niepoprawny (nie tylko logicznie), ale też jest wbrew zasadom. Jest tak dlatego, że includowany use case nie może występować jako samodzielny use case Myślę, że to rozwiązuje Twój spór z kolegą.
Róznica jest jeszcze taka, że przy zawieraniu(include) zawierany UC jest zawsze włączany do scenariusza danego UC. Przy rozszerzaniu(extend) podstawowy UC może występować samodzielnie i czasami może być rozszerzany.</b></b>

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