MODEL USE CASE

10/7/2012

MODEL USE CASE

Bibliografia:

A. Cockburn -" Jak pisać efektywne
przypadki użycia", WNT 2004

http://www.usecases.org

Model Use Case

Przedstawia system z punktu widzenia u

ytkownika

(ró

nych klas u

ytkowników systemu).

Modeluje zachowanie systemu w odpowiedzi na
polecenia u

ytkownika.

Na tym etapie tworzone s

diagramy „Use Case”

Posłu

żą

one do nast

pnych etapów projektowania

oraz do ko

cowego testowania systemu pod k

tem

spełniania wymogów u

ytkowników.

Okre

system robi

Model logiczny

Przedstawia system w postaci klas, powi

interakcji mi

dzy nimi, zachowa

obiektów

nale

żą

cych do tych klas oraz sekwencji działa

systemu.

Na tym etapie tworzy si

nast

puj

ce diagramy:

klas, obiektów

sekwencji (interakcji)

współpracy

przej

ść

stanów

Okre

CO jest

w systemie,

JAK

system

działa

Model implementacyjny i
wdrożeniowy

Model implementacyjny

Przedstawia system jako moduły,
podsystemy, zadania. Na tym etapie powstaje
diagram komponentów.

Model wdro

eniowy

(Deployment )

Modeluje fizyczne rozmieszczenie modułów
systemu na komputerach. Uwzgl

dnia

wymagania sprz

towe, obszary krytyczne.

Na tym etapie tworzymy diagramy
rozmieszczenia (deployment).

Use Case – przykład użycia

Opisuje pewne zachowanie systemu, interakcje

systemu ze

rodowiskiem zewn

trznym

(człowiek, inny system – aktor)

g wykonywanych przez system akcji,

które na

żą

danie aktora realizuj

jego cele

i dostarczaj

mierzalne wyniki.

Reprezentuje wymagania funkcjonalne

use case –

CO system robi a NIE jak to robi

Elementy diagramów use case

aktor

przypadek u

ycia

relacje (asocjacje, zale

ci)

Aktor (osoba, system zewn

trzny):

korzysta z systemu

dostarcza/odbiera dane do/z systemu

administruje systemem

10/7/2012

Aktor

Aktor:

przyczyna

nap

dzaj

przypadki

ycia, sprawca zdarze

powoduj

cych

uruchomienie przypadku u

ycia, odbiorca

danych

wyprodukowanych

przez

przypadki u

ycia.

Aktor

–

osoba,

organizacja,

inny

system

komputerowy.

Grupa osób pełni

cych pewn

rol

, a nie

konkretna osoba

Przykład diagramu use case

bibliotekarz

Czytelnik

zamawia

wypożycza

zwraca

Działania wstępne

rozpoznanie dziedziny problemu

wywiady z udziałowcami

okre

lenie u

ytkowników i ich punktów

widzenia

modelowanie procesów biznesowych

ródła danych

wizja systemu

Strukturalizacja use case’ów

przykład u

ycia mo

e by

specjalizacj

innego (

generalizacja

)

przykład u

ycia mo

e by

wł

czany jako

cze

ść

innego (

<<include>>

)

przykład u

ycia mo

e rozszerza

zachowanie

innego (

<<extend>>

)

Relacje

Zale

ść

(dependency) mi

dzy

elementami, zmiana w jednym mo

e wpływa

na drugi, skierowanie pokazuje kierunek
zale

ci .

Generalizacja (dziedziczenie)

Asocjacja (association) powi

zanie.

Dwukierunkowa :

Jednokierunkowa:

Scenariusz przypadku użycia

Opisuje si

sekwencj

zdarze

jak si

rozpoczyna,

przepływ zdarze

jak si

czy,

jakie s

interakcje z aktorem.

Tekst nieformalny, tekst strukturalny (z

warunkami pocz

tkowymi i ko

cowymi),

pseudokod

10/7/2012

Format opisu przypadku użycia (1)

Nazwa: <W postaci wyra

enia czasownikowego>

Kontekst u

ycia: <Cel, normalne warunki wyst

pienia>

Zakres i poziom: <Czy przypadek u

ycia dotyczy całego

przedsi

biorstwa, wybranego systemu czy fragmentu

oprogramowania? Na jakim poziomie szczegółowo

jest opisany?>

Aktor główny: <Nazwa głównego aktora, opis jego roli>
Pozostali aktorzy i udziałowcy: <Nazwy aktorów, ich

interesy>

Wyzwalacze / Inicjacja: <Zdarzenie powoduj

rozpocz

cie przypadku u

ycia>

Warunki pocz

tkowe: <Co system zapewnia przed

zezwoleniem na rozpocz

cie przypadku u

ycia?>

Format opisu przypadku użycia (2)

Warunki ko

cowe:

- Gwarancje powodzenia: <Warunki spełnione po
pomy

lnym wykonaniu głównego scenariusza przypadku

ycia>

- Minimalne gwarancje: <Minimalne wymagania
prawdziwe na ko

cu ka

dego przebiegu przypadku u

ycia

(równie

niepoprawnego)>

Główny scenariusz powodzenia / Przepływ podstawowy:

Przepływy alternatywne:
<Numer zmienionego kroku> <Opis akcji>
Punkty rozszerzenia: <Miejsca i warunki rozszerze

Specjalne wymagania (np. niefunkcjonalne):

Scenariusz główny –przykład
zamawia książkę

System prezentuje ekran wyszukiwania.

Czytelnik

wprowadza dane bibliograficzne.

System przeszukuje katalog i wy

wietla list

tytułów.

Czytelnik

przegl

da list

i wybiera tytuł.

System wy

wietla list

ksi

ąż

ek.

Czytelnik

zamawia woln

ksi

ąż

System wy

wietla okno logowania.

Czytelnik

wprowadza nazw

i hasło.

System autoryzuje czytelnika.

10.

System potwierdza przyj

cie zamówienia.

Scenariusze alternatywne

Scenariusz

alternatywny 1 (odmowa autoryzacji)

1 – 8 Jak w scenariuszu głównym.

9 System odmawia autoryzacji: powrót do kroku 7.

Scenariusz

alternatywny 2 (brak wolnej ksi

ąż

ki)

1 – 5 Jak w scenariuszu głównym.

6. Brak wolnej ksi

ąż

ki: czytelnik zapisuje si

kolejki.

7. System wy

wietla okno logowania.

Czytelnik

wprowadza nazw

i hasło.

9. System autoryzuje czytelnika.

10. System potwierdza zapisanie do kolejki.

Generalizacja use case

Ogólny schemat i specyficzne realizacje

Ten sam cel

Mog

ró

ni aktorzy

przez telefon

przez
internet

osobiście

zamawia

Klient
telefoniczny

Klient
internetowy

Klient

10/7/2012

Rozszerzenie <<extend>>

Typowy schemat i dodatkowe czynno

Okre

lone punkty rozszerzenia

Brak odr

bnych aktorów

Przykład u

ycia podstawowy mo

e wyst

sam, ale w pewnych warunkach jego
zachowanie mo

e by

rozszerzone – w

pewnych punktach ( extension point), przez
inny przypadek), pokazane opcjonalne
zachowanie systemu

Wariant, opcja

Przykład <<extend>>

<<extend>>

Poł. Konferencyjne.

Połącz

Odbierz
dodatkowe

Odbierz

<<extend>>

sieć

klient

Zawieranie <<include>>

Przykład u

ycia wł

cza zachowanie innego,

przykład „included” nie mo

e by

samodzielny

Wyodr

bnienie fragmentu przypadku u

ycia

liwe fragmenty wspólne

Brak odr

bnych aktorów

10/7/2012

Przykład <<include>>

Czytelnik

zamawia

wypożycza

autoryzuje

<<include>>

Generalizacja aktorów

Czytelnik

wypożycza

zwraca

Wprowadza
czytelnika

bibliotekarz

Użycie generalizacji aktorów

obsługa

konta klienta

informowanie o

stanie konta klienta

inicjalizacja
karty klienta

include

podsystem

zarządzania bazą

danych banku

klient

administrator

systemu

weryfikacja

karty

i kodu klienta

Diagram przypadków użycia z
<<include>>

Rezerwuje

Wypożycza

Modyfikacja bazy

<<include>>

Zwraca

klient

include

<<include>>

Heurystyka tworzenia przypadków
użycia

4 kroki wg Cockburna

Zidentyfikuj aktorów i ich cele.

Napisz główny scenariusz powodzenia

Zidentyfikuj i wylistuj mo

liwe rozszerzenia

(zwłaszcza mo

liwe bł

dy)

4. Opisz jak system obsługuje ka

rozszerzenie (w tym ka

dy bł

10/7/2012

Zalety i wady przypadków użycia

przedstawiaj

wymagania funkcjonalne w

prostym do czytania formacie tekstowym

pokazuj

tylko wymagania funkcjonalne – bez

niefunkcjonalnych

projekt nie jest tylko tworzony w kategoriach
przypadków u

ycia

Diagram przypadków użycia –
podsumowanie

Przedstawia wymagane zachowanie systemu

Modeluje kontekst systemu

Czynno

ci:

Identyfikacja aktorów

Okre

lenie przypadków u

ycia

zadania aktora (np. wprowadzanie danych,

prezentacja danych, utrzymanie systemu)

Uporz

dkowanie modelu (generalizacja,

rozszerzenie, zawieranie

Dokumentacja modelu

Diagram przypadków użycia –
podsumowanie -2

Przypadki u

ycia nie dotykaj

problemów

projektowych:

struktury danych

współbie

ci operacji

struktury programu

Diagram przypadków u

ycia

nie pokazuje

kolejno

, w jakiej przypadki mog

wykonywane. Wła

ciw

kolejno

ść

okre

laj

diagramy realizowane w modelu logicznym.

Przykłady przypadków użycia

Order Food

Hire Employee

Reorder
supplies

Produce
mgt. reports

Track sales
and inv. data

<<include>>

Customer

Applicant

Supplier

Service Person

Manager

Przykłady

Use Case model – typowe błędy

Złe nazwy (rzeczowniki zamiast czasowników):

Niewła

ciwe u

ycie

relacji

Kierunki relacji

patient

add a patient

assign a visit

for a patient

"main

functionality"

something

included

"main

functionality"

something

extending

«include»

«extend»