Zastanawiam sie ostatnio, podczas projektowania aplikacji, jak wykorzystywać diagramy use case. Głownym problemem jest to, jak szczegolowo mam wykorzystywac ten diagram

przykladowy diagram:



1) czy powinine okreslac tylko podstawowe zadania (szukaj w listach, dodaj nowa liste, usun liste, modyfikuj liste)
2) czy rozwijac go precyzyjniej (usun liste -> sprawdz czy istnieje zaplanowana wysylka -> wyslij komunikat do uzytkownika) - w takim przypadku przeciez pojawiaja sie inne problemy (np. sprawdz czy uzytkownik ma prawa do kasowania, sprawdz czy nie popelniono bledow przy wprowadzaniu danych itd)

uogolniajac - jakie macie doswiadczenia z tymi diagramami? jak precyzyjnie je projektujecie? czy zapisujecie kazdy use case do osobnego diagramu czy nanosicie wszystko na jednym?

zapraszam do dyskusji, zalaczajac moj przykladowy diagram do ktorego sie odnosilem

1. Kazdy use case to abstrakcja, im wyzszy poziom abstrakcji a jednoczesnie bardziej jednoznaczy tym lepiej
2. Wiele poziomow diagramow -> diagram nr 1 - package system x, diagram nr 2 - paczki skladajace sie na system, diagram nr 3 - use casy skladajace sie na paczke itd
3. Paczki, jeden diagram = jedna glowna opisywana paczka + paczki z ktorych korzysta/integruje sie z nimi itp
4. Jeden use case = jeden diagram

UPDATE:

Temat sie ma tak do PRO jak ....
Gdzie sa moderatorzy??

Co do pytania nr. 2 nie lepiej to przedstawić za pomocą diagramu czynności? W przypadku użycia tylko ogólny zapis i w notatce można by zapisać, że takie rzeczy są tam sprawdzane.

wlasnie tak jak napisales wydaje mi sie sensownie - use case zrobie bardzo ogolny, natomiast wszystkie dodatkowe skladowe czynnosci przedstawie za pomoca diagramu czynnosci


znam zasady panujace na php pro i miejsce dyskusji wydaje mi sie jak najbardziej poprawne - oczywiscie UML to abstrakcja nie dotyczaca zadnego jezyka ale analitycy/projektanci/programisci/ (czesto to ta sama osoba) piszacy w php czesto siegaja po narzedzia modelowania, chyba ze moderatorzy sa innego zdania (jak znasz - zaproponuj lepsze forum na taka dyskusje, chetnie je sprawdze)

UPDATE:
google znalo odpowiedz: Forum UML

@delta9, nie mówie o tresci pytania (udzielilem Ci odpowiedzi) a o jego poziomie merytorycznym.

Uzywalem UML przez wiele lat i wniosek
jset taki ze mozna sie za UML-owac ...
Wydaje mi sie z praktyki,ze najlepdzym podjesciem jes
Mix UML-concept ogoly i extremal programing czylo model
aplikacji iweryfikacja z uzytkownikiem.
Problem zUML jest taki, ze jest dluga droga do mapowania design od
implementacji czyli wczesci staje sie bezyteczny.

Nie polecam używania diagramów w sposób wiążący - z prostej przyczyny, że ich interpretacja może być bardzo subiektywna.
(Oddzielając Use Case od Use Case Diagram!)
Bo o ile te pierwsze opisują system dokładnie, to diagram jest taką prostą wizualizacją (w moim odczuciu), na której nie powinno być bałaganu, a przejrzystość (np. w celach przypomnienia).

Wcześniej padło już wiele dobrych rad, więc powiem, że pierwszą sprawą jest określenie modelu pracy, przedyskutowanie go z szefostwem i kolegami, a później konsekwencja.

Pozdrawiam
ww