dpu

Report
Karolina Muszyńska
Na podst.: http://www.csun.edu/~dn58412/IS431/IS431_SP13.html
G. Schneider , J.P. Winters „Stosowanie przypadków użycia”
S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu SI”


Modelowanie obiektowe jest techniką identyfikacji
obiektów w środowisku systemu oraz zależności
pomiędzy tymi obiektami.
Techniki analizy obiektowej wykorzystywane są do:
◦ analizy istniejących obiektów pod względem możliwości
ponownego ich wykorzystania lub dostosowania do
nowych zastosowań, oraz
◦ zdefiniowania nowych lub zmodyfikowanych obiektów,
które będą połączone z istniejącymi obiektami w
użyteczną aplikację biznesową.

Język UML (Unified Modeling Language) jest
zestawem notacji stosowanym do określania lub
opisu obiektów systemu informatycznego.
2

Korzyści - zalety:
◦ Podział skomplikowanych systemów na
łatwiejsze do opanowania i zrozumienia
komponenty
◦ Tworzenie komponentów, które mogą być
wielokrotnie wykorzystane w innych systemach
albo jako elementy wejściowe w innych
projektach
◦ Myślenie „obiektowe” jest bliższe
rzeczywistości
3
4


Diagramy struktury. Typ diagramów przedstawiających
elementy specyfikacji, które są niezależne od aspektu
czasu. Są to diagramy klas, obiektów, pakietów i
struktur połączonych oraz diagramy wdrożeniowe:
diagramy komponentów i rozlokowania.
Diagramy dynamiki. Typ diagramów przedstawiających
cechy zachowania się systemu lub procesy
biznesowe. Są to diagramy przypadków użycia,
czynności i maszyny stanowej, jak również cztery
diagramy interakcji, będące podzbiorem diagramów
dynamiki podkreślającymi interakcje pomiędzy
obiektami: diagramy sekwencji, komunikacji,
harmonogramowania i sterowania interakcją.
5
 Do modelowania funkcji systemu – diagramy
przypadków użycia
 Do modelowania obiektów, będących w zakresie
działania systemu oraz relacji między nimi –diagram
klas i diagram obiektów dla każdego przypadku
użycia, oraz dla całego systemu.
 Do modelowania interakcji pomiędzy obiektami w
celu realizacji funkcji/przypadku użycia – diagramy
sekwencji i czynności dla każdego przypadku użycia
 Do modelowania zachowania/logiki obiektów diagram maszyny stanowej dla każdej klasy
6
Diagramy UML - przykład
Diagram klas dla przypadku użycia
“Dodaj nowe zlecenie”
Diagram przypadków użycia
KLIENT
Dodaj nowego klienta
ZLECENIE
Utwórz nowe zlecenie
Pracownik
DOSTAWA
:klient
Pracownik
:zlecenie
Utwórz zlecenie
Utwórz zlecenie
:dostawa
Utwórz dostawę
Dostarcz zlecenie
Diagram sekwencji dla
przypadku użycia
“Dodaj nowe zlecenie”
Diagram maszyny
stanowej dla obiektu
“Zlecenie”
7
 Modelowanie przypadków użycia jest procesem
modelowania funkcji systemu, ukazującym zdarzenia
biznesowe, aktorów którzy te zdarzenia inicjują oraz to
w jaki sposób system reaguje na te zdarzenia.
 Przypadek użycia jest sekwencją powiązanych akcji,
zarówno zautomatyzowanych jak i ręcznych,
prowadzących do realizacji funkcji biznesowej. Nazywa
się go również scenariuszem realizacji funkcji.
 Aktor reprezentuje encję zewnętrzną, która wchodzi w
interakcję z systemem w celu wymiany informacji.
Aktorem jest użytkownik pełniący określoną rolę w
systemie i może to być zarówno osoba jak i zewnętrzny
system. W pewnego rodzaju zdarzeniach zwanych
zdarzeniami czasowymi, które inicjowane są w
określonym momencie czasu, aktorem jest czas.
8
 Diagram przypadków użycia jest opisem systemu
z punktu widzenia jego funkcji – jakie funkcje
oferuje system
 Diagram przypadków użycia nie przedstawia
przepływów danych ani przepływów informacji w
systemie (przepływy te są przedstawiane na
diagramach interakcji)
9
 Rozszerzający przypadek użycia rozszerza
funkcjonalność bazowego przypadku użycia o nowe
zachowania lub akcje w stosunku do podstawowego
przebiegu zdarzeń. Rozszerzający przypadek użycia
może być wywołany jedynie przez przypadek użycia,
który rozszerza.
 Zawierany przypadek użycia zawiera typowe kroki
scenariusza, które są wspólne dla dwóch lub więcej
bazowych przypadków użycia. Zawierany przypadek
użycia redukuje redundancję i sprzyja ponownemu
wykorzystaniu wspólnych elementów.
10
Sprawdź listę
dostępnych pokoi
<<extend>>
Przekaż rezerwację
centrali
“Sprawdź listę dostępnych pokoi” jest przypadkiem bazowym.
W określonych sytuacjach (np. brak dostępnych pokoi do
wynajęcia w danym obiekcie) wywołany zostanie przypadek
“Przekaż rezerwację centrali”.
Przypadki rozszerzające nie są wykonywane automatycznie, a
zależność rozszerzania skierowana jest do przypadku
bazowego.
11
Dokonaj
rezerwacji
<<include>>
Sprawdź listę
dostępnych pokoi
Przypadek bazowy „Dokonaj rezerwacji” każdorazowo
wywołuje przypadek „Sprawdź listę dostępnych pokoi”.
Zależność zawierania skierowana jest do przypadku
zawieranego.
12
Złóż zamówienie
telefonicznie
Złóż
zamówienie
Klient
Przygotuj raport
Przedstawiciel
handlowy
Złóż zamówienie
przez stronę www
Przygotuj raport
sprzedaży
Przygotuj raport o
reklamacjach
Przypadki “Złóż zamówienie telefonicznie” i „Złóż zamówienie przez
stronę www” są możliwymi odmianami przypadku bazowego „Złóż
zamówienie”, natomiast „Przygotuj raport sprzedaży” i „Przygotuj raport
o reklamacjach” to odmiany przypadku bazowego „Przygotuj raport”.
Przedstawiciel handlowy może przyjmować rolę Klienta i inicjować te
same przypadki użycia co Klient.
13
Utwórz
zamówienie
Klient
Sprawdź stan
zamówienia
Sprzedawca
Anuluj
zamówienie
Zarządzaj stanem
magazynu
Administrator
bazy danych
Przypadki użycia typu CRUD (Create, Read, Update, Delete)
są wykorzystywane kiedy aplikacja służy do przechowywania
danych i tylko jeden aktor wchodzi z nią w interakcję (np.
zarządzanie bazą danych, zarządzanie zamówieniami, itp.).
14
 Każdy przypadek użycia powinien zawierać
dokumentację w formie scenariuszy.
 Scenariusz jest sekwencją akcji dokumentujących
zachowanie użytkownika i systemu.
 Każdy przypadek użycia powinien mieć przynajmniej
scenariusz główny ale wskazane jest, żeby wyróżnić
także scenariusze alternatywne.
 Zarówno scenariusz główny jak i alternatywny
szczegółowo opisują pełną funkcjonalność
reprezentowaną przez przypadek użycia.
 Dodatkowe ważne elementy dokumentacji
przypadków użycia to: warunki wstępne oraz
warunki końcowe.
15
 Identyfikacja aktorów (poszukiwanie źródeł i celów
głównych wejść i wyjść systemu).
 Identyfikacja przypadków użycia (główne funkcje
systemu).
 Identyfikacja związków pomiędzy aktorami i
przypadkami użycia (asocjacji)
 Identyfikacja dodatkowych relacji między
przypadkami użycia (“extend”, “include”)
 Identyfikacja relacji uogólnienia pomiędzy
przypadkami użycia i aktorami
 Udokumentowanie przypadków użycia
16

similar documents