10/7/2012

1

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

ś

la

CO

system robi

Model logiczny

Przedstawia system w postaci klas, powi

ą

za

ń

i

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

ś

la

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)

Ci

ą

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

ż

no

ś

ci)

Aktor (osoba, system zewn

ę

trzny):

korzysta z systemu

dostarcza/odbiera dane do/z systemu

administruje systemem

10/7/2012

2

7

Aktor

Aktor:

przyczyna

nap

ę

dzaj

ą

ca

przypadki

u

ż

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

ż

no

ść

(dependency) mi

ę

dzy

elementami, zmiana w jednym mo

ż

e wpływa

ć

na drugi, skierowanie pokazuje kierunek
zale

ż

no

ś

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

ę

ko

ń

czy,

jakie s

ą

interakcje z aktorem.

Tekst nieformalny, tekst strukturalny (z

warunkami pocz

ą

tkowymi i ko

ń

cowymi),

pseudokod

10/7/2012

3

13

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

ś

ci

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

ą

ce

rozpocz

ę

cie przypadku u

ż

ycia>

Warunki pocz

ą

tkowe: <Co system zapewnia przed

zezwoleniem na rozpocz

ę

cie przypadku u

ż

ycia?>

14

Format opisu przypadku użycia (2)

Warunki ko

ń

cowe:

- Gwarancje powodzenia: <Warunki spełnione po
pomy

ś

lnym wykonaniu głównego scenariusza przypadku

u

ż

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:

<Numer kroku> <Opis akcji>
<Numer kroku> <Opis akcji>

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ę

1.

System prezentuje ekran wyszukiwania.

2.

Czytelnik

wprowadza dane bibliograficzne.

3.

System przeszukuje katalog i wy

ś

wietla list

ę

tytułów.

4.

Czytelnik

przegl

ą

da list

ę

i wybiera tytuł.

5.

System wy

ś

wietla list

ę

ksi

ąż

ek.

6.

Czytelnik

zamawia woln

ą

ksi

ąż

k

ę

.

7.

System wy

ś

wietla okno logowania.

8.

Czytelnik

wprowadza nazw

ę

i hasło.

9.

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

ę

do

kolejki.

7. System wy

ś

wietla okno logowania.

8.

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

ą

by

ć

ró

ż

ni aktorzy

przez telefon

przez
internet

osobiście

zamawia

Klient
telefoniczny

Klient
internetowy

Klient

18

10/7/2012

4

19

Rozszerzenie <<extend>>

Typowy schemat i dodatkowe czynno

ś

ci

Okre

ś

lone punkty rozszerzenia

Brak odr

ę

bnych aktorów

Przykład u

ż

ycia podstawowy mo

ż

e wyst

ą

pi

ć

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

22

23

Zawieranie <<include>>

Przykład u

ż

ycia wł

ą

cza zachowanie innego,

przykład „included” nie mo

ż

e by

ć

samodzielny

Wyodr

ę

bnienie fragmentu przypadku u

ż

ycia

Mo

ż

liwe fragmenty wspólne

Brak odr

ę

bnych aktorów

10/7/2012

5

Przykład <<include>>

Czytelnik

zamawia

wypożycza

autoryzuje

<<include>>

<<include>>

26

Generalizacja aktorów

Czytelnik

wypożycza

zwraca

Wprowadza
czytelnika

bibliotekarz

28

Użycie generalizacji aktorów

obsługa

konta klienta

informowanie o

stanie konta klienta

inicjalizacja
karty klienta

«

include

»

«

include

»

«

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>>

>>

30

Heurystyka tworzenia przypadków
użycia

4 kroki wg Cockburna

1.

Zidentyfikuj aktorów i ich cele.

2.

Napisz główny scenariusz powodzenia

3.

Zidentyfikuj i wylistuj mo

ż

liwe rozszerzenia

(zwłaszcza mo

ż

liwe bł

ę

dy)

4. Opisz jak system obsługuje ka

ż

de

rozszerzenie (w tym ka

ż

dy bł

ą

d)

10/7/2012

6

31

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:

1.

Identyfikacja aktorów

2.

Okre

ś

lenie przypadków u

ż

ycia

zadania aktora (np. wprowadzanie danych,

prezentacja danych, utrzymanie systemu)

3.

Uporz

ą

dkowanie modelu (generalizacja,

rozszerzenie, zawieranie

4.

Dokumentacja modelu

Diagram przypadków użycia –
podsumowanie -2

Przypadki u

ż

ycia nie dotykaj

ą

problemów

projektowych:

struktury danych

współbie

ż

no

ś

ci operacji

struktury programu

Diagram przypadków u

ż

ycia

nie pokazuje

kolejno

ś

ci

, w jakiej przypadki mog

ą

by

ć

wykonywane. Wła

ś

ciw

ą

kolejno

ść

okre

ś

laj

ą

diagramy realizowane w modelu logicznym.

34

Przykłady przypadków użycia

Order Food

Hire Employee

Reorder
supplies

Produce
mgt. reports

Track sales
and inv. data

<<include>>

<<include>>

Customer

Applicant

Supplier

Service Person

Manager

35

Przykłady

36

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»

10/7/2012

7

37

Use cases vs. internal features

consider software to run a cell phone:

Use Cases

call someone

receive a call

send a message

memorize a number

Point of view: user

Internal Functions

• transmit / receive data

• energy (battery)

• user I/O (display, keys, ...)

• phone-book mgmt.

Point of view: developer /

designer