UML

Diagramy przypadków

użycia

PLAN WYKŁADU



Cel stosowania przypadków użycia?



Co opisują przypadki użycia



Związki między przypadkami

użycia



Dokumentacja przypadków użycia



Przykłady poprawne



Przykłady błędów

Cel stosowania przypadków

użycia

Klasyfikacja diagramów UML 2.0

1. Diagramy struktury



Diagram klas (class diagram)



Diagram komponentów (component diagram)



Diagram struktur złożonych, diagram składowych, (composite

structure



diagram)



Diagram wdrożenia (deployment diagram)



Diagram obiektów (object diagram)



Diagram pakietów (package diagram)

2. Diagramy zachowania



Diagram czynności (activity diagram)



Diagram przypadków użycia (use case diagram)



Diagram maszyny stanów (state machine diagram)



Diagram interakcji

- Diagram sekwencji (sequence diagram

- Diagram komunikacji (communication diagram)

- Diagram przeglądu interakcji; diagram opisu interakcji

(interaction overview diagram)

- Diagram czasowy,diagram następstwa (timing diagram)

Przypadki użycia



Przypadki użycia tworzą

specyfikację wymagań



Przypadek użycia jest

metodą opartą na

scenariuszach

, służącą do określania wymagań.



Po raz pierwszy użyto jej w metodzie Objectory

(Jacobson i inni, 1993). Obecnie

stała się

podstawowym elementem notacji UML

opisywania obiektowych modeli systemu.



W najprostszej postaci w przypadku użycia

definiuje się aktorów

biorących udział w

interakcji



i wskazuje typ tej interakcji.

Cele diagramów przypadków

użycia

Dwa podstawowe cele:

modelowanie otoczenia systemu

(wyznaczenie granicy systemu i wskazanie

aktorów, którzy wchodzą w interakcję z

systemem)

modelowanie wymagań stawianych

systemowi

(określenie, z punktu widzenia

otoczenia, co system powinien robić,

niezależnie od tego jak ma to zrobić)

Pozostałe cele stosowania przypadków
użycia



Głębsze

zrozumienie użycia

systemu będącego

przedmiotem procesu projektowania.



Zwiększenie

stopnia świadomości analityków i

projektantów

co do celów tego systemu.



Umożliwienie

interakcji zespołu

projektowego z

przyszłymi użytkownikami systemu.



Weryfikacja

poprawności i kompletności

projektu.



Ustalenie wszystkich strukturalnych i funkcjonalnych

własności systemu.



Ustalenie

składowych systemu

i związanego z nimi

planu konstrukcji systemu.



Dostarczenie podstawy do sporządzenia planu

testów systemu

Co opisują przypadki

użycia?

Przypadek użycia



Przypadek użycia to

opis zbioru ciągów akcji

(i ich wariantów) wykonywanych przez system

w celu dostarczenia określonemu aktorowi

godnego uwagi wyniku



Przypadek użycia

opisuje oczekiwane

zachowanie

budowanego systemu

(podsystemu, klasy lub kooperacji), ale

nie

określa sposobu implementacji

tego

zachowania



Z punktu widzenia

aktora przypadek użycia

opisuje działanie mające dla niego jakąś

wartość

, na przykład:

obliczenie wyniku

utworzenie nowego obiektu lub zmianę stanu

obiektu

Związki między przypadkami

użycia

Diagram przypadków użycia

Przypadek użycia

–

– musi mieć nazwę unikalną,

wyróżniającą go spośród innych przypadków. Jeśli jest
tylko nazwa, wtedy mówimy o ‘nazwie prostej’, lub o
‘nazwie ścieżkowej’ (nazwa jest

poprzedzona

nazwą pakietu: Nazwa_pakietu::nazwa).

Aktor

–

– musi mieć unikalną nazwę. Można zdefiniować

zarówno ogólne rodzaje aktorów, jak i
uszczegółowienia. Aktorem może być osoba,
organizacja lub system komputerowy.

Związek

–

– pokazuje związek między przypadkiem użycia

a aktorem

dodaj odbiorce

Diagramy przypadków użycia zawierają

Aktor



Aktor reprezentuje

spójny zbiór ról

odgrywanych

przez użytkowników przypadków użycia w czasie

interakcji



Aktorami mogą być

ludzie, urządzenia i inne

systemy

informatyczne



Jedna osoba może wchodzić

w interakcję z

systemem z pozycji wielu aktorów

; np. być

zarówno sprzedawcą, jak i klientem. I odwrotnie,

jeden aktor może odpowiadać wielu konkretnym

osobom.



Aktor jest tu pierwotną przyczyną

napędzającą

przypadki użycia. Jest on sprawcą zdarzeń

powodujących uruchomienie przypadku użycia



Aktorzy mogą być:

aktywni

(inicjują przypadki

użycia) i

pasywni

Ilustracja różnicy między pojęciem

aktora a konkretnym użytkownikiem

systemu

Kolejne kroki w konstrukcji modelu przypadków użycia

Związki między przypadkami

użycia

Zasady



Semantyka

Diagram pokazuje

związki pomiędzy aktorami i

przypadkami użycia.

Notacja

graf

zawiera aktorów, przypadki użycia,

interfejsy i związki pomiędzy nimi,

generalizację pomiędzy aktorami,

oraz generalizację i rozszerzenia

wariantów.

Związki



Związki występują pomiędzy:

przypadkami użycia lub przypadkami

użycia i aktorami;



Rodzaje związków:

•

Asocjacja

(association);

•

Zależności

(dependencies)

Rozszerzenie

(extend);

Zawieranie

(include);

•

Generalizacja

(generalization)

Asocjacje

Złóż zamówienie

Sprzedawca

Związki asocjacji występują

wyłącznie pomiędzy

aktorami a

przypadkami użycia.

Zależności (dependencies)

Zależność

to taki związek pomiędzy

dwoma elementami modelowania, w

którym

zmiana jednego

z nich,

niezależnego,

wpływa na drugi

zależny

Związki pomiędzy przypadkami

Związki zależności

Zawieranie

- stereotyp <<

include

>>,

służy do uniknięcia wielokrotnego
opisywania tego samego ciągu zdarzeń
(wspólne zachowanie jest definiowane w
odrębnym przypadku użycia, który jest
następnie włączany przez bazowe
przypadki użycia.

Rozszerzanie

- stereotyp <<

extend

>>,

służy do modelowania fragmentów
przypadków użycia postrzeganych przez
użytkownika opcjonalnie (oddzielenie
działań opcjonalnych od wymaganych)

Przykłady relacji między przypadkami użycia

Związki pomiędzy przypadkami

Uogólnienie

- potomek dziedziczy całe

zachowanie po przodku i może dodać
nowe, lub zmienić zachowanie

Związki zależności

Złóż zamówienie

Data realizacji

Zamawianie

produktów

Planowanie

płatności

Zamawianie

katalogu

<<Include>>

<<Extend>>

Sprzedawca

Dokumentacja przypadków

użycia

Przypadki użycia - dokument

opisu



Dla każdego przypadku użycia

tworzymy dokument

opisujący przebieg zdarzeń opisany z punktu widzenia

aktora



Typowy opis

zawiera:

- Jak i kiedy przypadek użycia się rozpoczyna i

kończy?

- Kto uczestniczy?

- Kiedy dochodzi do interakcji z aktorami jakie obiekty

są przekazywane?

- Typowy przebieg zdarzeń

- Alternatywne ciągi zdarzeń

- Przebieg zdarzeń w sytuacjach szczególnych

(wyjątkowych)



Ciąg zdarzeń

można zapisać na wiele sposobów:

- tekst strukturalny (nieformalny lub formalny)

- pseudokod

Opis tekstowy przypadku użycia

„

Rejestracja

”

1. Aktorzy

* Użytkownik

* Baza użytkowników

2. Opis tekstowy ciągu zdarzeń

* System wyświetla stronę główną serwisu

* Użytkownik wybiera opcję „Rejestruj”

* System wyświetla formularz rejestracji nowego

użytkownika

*Użytkownik wprowadza unikalny login, hasło, adres email

oraz dane

adresowe

* System sprawdza unikalność loginu



już istnieje

w bazie – ponowne wyświetlenie

formularza rejestracji z informacją o tym, że login jest

już zarejestrowany.



nie istnieje

w bazie – następny krok

* System zapisuje login, hasło, email, dane adresowe

* System informuje użytkownika o zakończeniu procesu rejestracji

Przykłady

poprawne

Przypadek użycia

Wypożyczanie

Obsługa

wypożyczania

drukarnia

specjalistyczna

przekazanie manuskryptu

recenzent

wybór recenzenta

decyzja o losie publikacji

autor

ilustrator

wybór ilustratora

pracownik

kontraktowy

konsultacje

uzyskanie ISBN

centrala

kosztorysowanie

zlecenie druku

redaktor

kontrola stanu drukowania

drukarnia

Przypadki użycia- przykład

Przykład bankomatu



Diagram przypadków użycia pozwala na wizualizację

•

Relacji pomiędzy przypadkami użycia

•

Relacji pomiędzy przypadkami użycia a aktorami

•

Relacji pomiędzy aktorami

Diagram przypadków użycia w Posejdonie

Przykłady błędów

Diagram ilustrujący problemy z wyróżnianiem

aktorów systemu i tworzeniem struktur

generalizacji-specjalizacji dla aktorów

-błędna struktura

Nie jest prawdą, że każdy
pracownik „Wydziału
planowania remontów”
ma uprawnienia do
wywoływania przypadków
„Rejestrowanie usterek i
Organizowanie remontów
interwencyjnych” Takie
uprawnienia mają
wyłącznie pracownicy
„Zespołu d.s. remontów
interwencyjnych”