jak zabrać się za projektowanie/modelowanie aplikacji

Witam,

przebrnąłem przez jedną z książek dotyczących UMLa z zamiarem nauczenia się go. Przeczytalem opis 12 diagramów i mam mętlik w głowie. Przede wszystkim od ilości informacji, którą chciałem pochłonąć. Drugą sprawą jest to, że dalej jestem zielony (choć może już troszkę mniej) jak należy tego ustrojstwa używać, jak poprawnie podejść do projektowania. Nie mam pojęcia od czego zacząć. Czy jak ustalę listę aktorów to chwytać się za tworzenie diagramu przypadków użycia, czy może za scenariusze przypadków użycia. Czy wszystkie diagramy/większość czy raczej tylko ich część należy/można wykorzystać przy tworzeniu projektu... i dziesiątki innych wątpliwości.

Rozumiem, że wszystko tak naprawdę zależy od podejścia projektanta, wielkości/rodzaju projektu itp., ale chciałbym uzyskać od Was jakieś ogólne wskazówki, jaką drogą należy podążać, co należy zrobić w pierwszej kolejności, co w drugiej a co w trzeciej.

Będę wdzięczny za wszelkie zdroworozsądkowe porady czy wskazania na biblio(neto)grafię.

Naprawdę nic, zero null? Nikogo chętnego do podzielenia się wiedzą?? ;)

Ja się mogę podzielić, chociaż moja wiedza jest raczej teoretyczna.
Ostatnio pisałem pracę dyplomową i użyłem następujących diagramów:

• przypadków użycia - jako pierwszych, bo to one służą do tworzenia specyfikacji funkcjonalnej systemu, na ich podstawie dopiero opisywałem scenariusze;
• klas - na różne sposoby, jeden zmodyfikowany przedstawiał bazę danych, inne klasy w aplikacji;
• komponentów - przedstawiały podział systemy na moduły, bazę danych, biblioteki;
• sekwencji - komunikacja między obiektami, od warstwy najbliższej użytkownikowi aż po bazę danych, przepływ tego, co się dzieje w systemie dla takich czynności jak pobieranie czy zapis danych;
• czynności - algorytmy działania dla bardziej skomplikowanych funkcji/metod/procedur/wyzwalaczy.
  Innych nie użyłem, bo albo nie rozumiem albo nie widzę zastosowania na swoim poziomie.

Mam nadzieję, że coś się wreszcie w tym wątku ruszy i ktoś bardziej doświadczony się odezwie :)

P.S. Z jakiej książki się uczyłeś?

Nie ma sensu używać wszystkich diagramów UML tylko dla zasady. Przykładowo ja w pracy wykorzystuje (w kolejności od najczęściej używanego do nażadziej):

1. Diagramy przypadków użycia
2. Diagramy sekwencji
3. Diagramy komponentów
4. Diagramy klas

Reszty ani razu nie użyłem ani nie musialem czytać

Wielkie dzięki za odpowiedź Somekind i Rnd.
Mam oczywiście kolejne pytania: czy przypadek użycia z diagramu p.u. to taki, do którego tworzy się scenariusze? Czy jest to powiedzmy blok kilku takich przypadków? Żeby zobrazować to, co mam namyśli:
na diagramie mam p.u. zarządzanie materiałem video, rozumiem pod tym pojęciem takie rzeczy jak dodawanie, usuwanie, aktualizacja czy wyszukiwanie tych materiałów. Tworzenie scenariusza dla zarządzania raczej mija się z celem i należy je utworzyć dla poszczególnych operacji. Mam racje? Jeżeli tak, to czy na diagramie p.u. nie byłoby lepiej umieścić zamiast jednego zarządzania, czterech oddzielnych operacji? A może należy p.u. zarządzanie rozszerzyć za pomocą tych elementarnych operacji (jeżeli dobrze zrozumiałem idee extended i include)?

Jeszcze jedno moje pytanie właściwie wiąże się z ostatnim. Mianowicie, jak bardzo "rozdrabniać" wszystkie przypadki użycia? Do takich elementarnych operacji o jakich wyżej napisałem, czy raczej grupować je w moduły?

ps1. @somekind - pierwszą literaturą jaką przejrzałem nt. UMLa jest "UML dla każdego" z Helionu