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

do góry

On Jan 14, 11:59 pm, "Megas" <k...@o...eu> wrote:
> Użytkownik "Megas" <k...@o...eu> napisał w
wiadomościnews:gklqnl$goj$1@news.onet.pl...
>
> >>>Od d?u?szego czasu mam k?opot z wymodelowaniem funkcjonalno??
> >>>projektowanego
> >>>systemu, czy kto? móg?by mi w tym pomóc?
> >>>Sytuacja jest taka, ?e mam ju? wymodelowany model przypadków u?ycia dla
> >>>mojego systemu, a teraz chcia?bym wymodelowac z jakich cz??ci
> >>>funkcjonalno?ci b?dzie si? sk?ada? system.
>
> >> Co to jest "czesci funkcjonalnosci" I dlaczego system ma sie z niuch
> >> skladac?
>
> >> A.L.
>
> Dla przykładu: Funkcjonalnosc programu 'Outlook Express' bedzie sie skladac
> z czesci:
> a) Wysyłanie i odbieranie poczty e-mail,

Diagram przepływu

> b) Prezentacja e-mail w GUI,

Diagram przepłwu, diagram stanu

> c) Tworzenie nowych e-mail (edytor tekstowy),

Diagram przepływu stanu, aktywności


Każdy z powyższych będzie rozwinięciem usecase, tak aby "przypadek
użycia" nie był samą nazwą.

--
ZZ@private

do góry

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

chodzi mi o [model] - [projekt] formatek to rzecz oczywiście pożądana.

Wiktor Zychla

do góry