UML a modelowanie funckjonalności systemu
Megas
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. By system spełnił wymaganą
funkcjonalność określona w przypadkach uzcycia musi zawierać taką
funkcjonalność jak: Odbieranie/Wysyłanie danych z/do sieci, Identyfikacja
użytkownika, Komunikacja z baza danych itp... Jakich elementów UML i
diagramów powinienem użyć do tego.
Komponenty reprezentują fizyczną wymienną częścią systemu,
Klasy reprezentują klasy w języku obiektowym,
a jakie elementy reprezentują część funkcjonalności systemu.?
Bardzo prosze o wszelkie wskazówki bo jestem już załamany...
Pozdrawiam
Marcin
A.L.
>Witam,
>
>
>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.
Megas
>>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
>>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...
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,
b3) Zapamietywanie odczytanych juz e-mail,
b4) Sprawdzanie spam,
itp...
Przez to rozumiem czesci funckjonalnosci.
Jax
>>>
>>>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