🚀 go-pugleaf

Megas wrote:

>>>
>>>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"?...
>>
>> A.L.
> 
> Dla przykładu: Funkcjonalnosc programu 'Outlook Express' bedzie sie
> skladac z czesci:
> a) Wysyłanie i odbieranie poczty e-mail,
> b) Prezentacja e-mail w GUI,
> c) Tworzenie nowych e-mail (edytor tekstowy),
> d) Powiadamanie o poczcie dziwiekiem,
> itp...

Z tego co wiem, to są wymagania funkcjonalne i pisze się to w zwykłym pliku
tekstowym. Jego treść uzgadnia się z klientem. 

> Funckjonalnosc a) 'Wysyłanie i odbieranie poczty e-mail', bedzie sie
> skladac z czesci:
> a1) Odbior poczty za pomoca POP3,
> a2) Wysylanie poczty za pomoca SMTP,

Te dwa to są chyba wymagania systemowe narzucone przez klienta. Z tego co
wiem je też się spisuje w pliku tekstowym.

> b3) Zapamietywanie odczytanych juz e-mail,
> b4) Sprawdzanie spam,
> itp...

A sekwencja działań podczas odbioru poczty to idealny kandydat na diagram
czynności w UML.
 
> Przez to rozumiem czesci funckjonalnosci.
Jak widać trochę mieszasz różne sprawy. Rzucę ci przykładową sekwencję
działań z ćwiczebnego projektu:

Projekt "Baza danych wypożyczalni DVD z implementacja w Pythonie i SQL"
 1 Etapy wykonania
 1.1 zebranie wymagań
 1.1.1 opis tekstowy (na podstawie Professional Linux Programing)
 1.1.1.1 wymagania użytkownika (user requests) - plik: wymagania.odt
 1.1.1.2 wymagania systemowe (system requests) - plik: wymagania.odt
 1.1.1.3 pożądane, ale pominięte (ignored requests) - plik: wymagania.odt
 1.1.2 diagram przypadków użycia (UML) - plik: przypadki uzycia.dia
 1.1.3 diagram głównych czynności (UML) - plik: czynności - wypożyczenie.dia
 1.1.4 lista testów funkcjonalnych aplikacji - plik: testy.odt
 1.2 testowanie komponentów aplikacji
 1.2.1 PostgreSQL - zapytania wielokrotnie zagnieżdżone (katalog: ../testy
postresql/zapytania zagnieżdźone)
 1.2.2 PostgreSQL - generator identyfikatorów (ID) (katalog: ../testy
postresql/generowanie id)
 1.3 projekt klas logiki aplikacji (rdzenia programu) (UML) (plik:
klasy.dia)
 1.3.1 projekt wstępny na podstawie przypadków użycia
 1.3.2 weryfikacja z listą testów (funkcjonalnych i automatycznych)
 1.3.3 refaktoryzacja projektu (wyszukanie i zastosowanie wzorców
projektowych)
 1.4 projekt bazy danych (ERD) (plik: diagram erd.xmi)
 1.4.1 projekt na podstawie diagramu klas
 1.4.2 normalizacja projektu bazy danych
 1.5 przygotowanie bazy danych PostgreSQL
 1.6 projekt i napisanie testów automatycznych logiki aplikacji (rdzenia
programu)
 1.7 napisanie kodu logiki aplikacji (rdzenia programu) i kodu bazy danych
 1.8 testowanie logiki aplikacji (rdzenia programu) - po każdej grupie
poprawek kodu wszystkie testy od początku
 1.9 projekt interfejsu użytkownika
 1.10 napisanie kodu interfejsu użytkownika
 1.11 testowanie funkcji całej aplikacji (z punktu widzenia użytkownika
końcowego) - po każdej grupie poprawek kodu wszystkie testy od początku

Uwaga: punkty 1.6, 1.7 i 1.8 powtarzają się w miarę jak wykonywane są
kolejne fragmenciki projektu.


To przykładowy sposób wykonania projektu. Wszelkie uwagi merytoryczne mile
widziane.

Jax