Wiktor Zychla pisze:
> rozpisanie scenariuszy/przypadków użycia nie zaprojektuje Ci samo
> architektury systemu, ani nie zbuduje modelu
> analitycznego/dziedzinowego, może tylko pomóc.
> spróbuj jakoś tak: scenariusz jaki rozpisujesz:
>
> 1. Zalogowanie sie do systemu,
> 2. Sprawdzenie dostepnych wolnych dni od pracy,
> 3. Wyslanie prosby o urlop do kierownika.
> 4. Otrzymanie akceptacji urlopu.
> 5. Zapisanie w bazie danych urlopu.

To co Megas podał (5 kroków przypadku użycia 'Wypisanie przez
pracownika urlopu') jest niczym innym jak osobnymi przypadkami użycia.

Aktorem będzie Użytkownik, który może wybrać następujące opcje w
systemie (przypadki użycia):

1. Zaloguj
2. Sprawdź wolne dni
3. Wypisz urlop
4. Wyświetl dni urlopu

Dla każdego z przypadków użycia powinno się napisać scenariusz użycia.
Podczas dalszej pracy w budowaniu całego modelu, wiemy jaką
funkcjonalność reprezentuje dany przypadek użycia i na tej podstawie
tworzymy dynamikę systemu.

Przykład:

Nazwa: Zaloguj (Nazwa przypadku użycia)

Twórca: Imię i Nazwisko

Aktorzy: Użytkownik (Aktorzy wchodzący w interakcję z danym przypadkiem
użycia)

Krótki opis: np. Logowanie użytkownika do systemu

Warunki wstępne:np. podanie identyfikatora użytkownika i hasło
(konieczne warunki inicjujące przypadek)

Warunki końcowe:np. identyfikator użytkownika i hasło zgodne z danymi w
bazie (stan systemu po realizacji przypadku użycia)

Główny przepływ:a) Użytkownik uruchamia aplikację
b) Wyświetla się okno logowania do systemu
c) Użytkownik wpisuje w pola swoje dane: identyfikator oraz hasło
d) Użytkownik naciska klawisz OK
e) Po poprawnym zalogowaniu uruchamia się główne okno aplikacji

Alternatywny przepływ:
b1) Po wyświetleniu formatki logowania użytkownik naciska klawisz ANULUJ
b2) Okno logowania wraz z aplikacją zostają zamknięte

e1) System wyświetla informację o błędnym identyfikatorze użytkownika
lub haśle
e2) Użytkownik wraca do punktu c) Głównego przepływu

.
.
.

w alternatywnym przepływie wypisujemy pełny scenariusz jaki może
spotkać użytkownik realizując dany przypadek użycia

Specjalne wymagania:Wypunktowana i scharakteryzowana lista dodatkowych
zidentyfikowanych wymagań niefunkcjonalnych, które mogą być istotne
przykładowo podczas projektowania czy kodowania

Notatki: Lista wszystkich komentarzy dotyczących przypadku użycia i
lista otwartych kwestii, które powinny zostać rozwiązane wraz z
propozycjami osób, które mogłyby je rozwiązać

Zapisanie w bazie danych urlopu nie jest przypadkiem użycia, tylko
funkcjonalnością, która powinna zostać uruchomiona automatycznie w
przypadku zatwierdzenia urlopu przez przełożonego (w przypadku
niezatwierdzeniu również powinna być taka możliwość). Natomiast
akceptacja urlopu powinna się pojawić podczas uruchomienia opcji
'Wyświetl dni urlopu' - jeszcze jedną funkcjonalnością przy
akceptacji/odrzuceniu urlopu przez przełożonego dodałbym powiadomienie
via mail.

>
> już widać, że model analityczny musi przewidywać jakichś użytkowników,
> jakiś rejestr dni wolnych, jakiś rejestr próść o urlop, coś
> przechowującego akceptacje / nieakceptacje.

To już logika systemu.


> dopiero z takiego przybliżenia analitycznego można bardzo uważnie
> zaprojektować ścisły model dziedzinowy (czyli diagram klas części
> biznesowej aplikacji).

:)

> podsystemów GUI/IO w ogóle bym nie modelował, bo one są zwykle pochodną
> technologii jakiej użyjesz i nie masz na nią zbyt dużego wpływu.

Jak najbardziej może zaprojektować wygląd formatek.

pozdrawiam
tsharny