Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 1

Projektowanie systemów informacyjnych

Ewa Stemposz, Kazimierz Subieta

Instytut Podstaw Informatyki PAN,
Warszawa

Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa

Wykład 1

Pojęcia wstępne
Model przypadków użycia

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 2

Zalecana literatura

 E. Stemposz, K. SUBIETA: Slajdy do wykładu “Projektowanie
systemów informacyjnych”
 J. Płodzień, E. Stemposz: Analiza i projektowanie systemów
informatycznych, wydawnictwo PJWSTK, 2003 i wydanie II-gie
rozszerzone 2005
 M. Śmiałek: Zrozumieć UML 2.0 Metody modelowania
obiektowego, Helion, 2005
 S. Wrycza, B. Marcinkowski, K. Wyrzykowski: Język UML 2.0 w
modelowaniu systemów informatycznych, Helion 2005

 OMG Unified Modeling Language. Specification, Version 1.5,
Version

2.0,

The

Object

Management

Group,

2003,

http://www.omg.org

M. Fowler, K. Scott: UML Distilled, Addison-Wesley 1997
 J. Rumbaugh, I. Jacobson, G. Booch: The Unified Modeling
Language Reference Manual, Addison-Wesley, 1999

 T. Quatrani: Visual Modeling with Rational Rose 2000 and UML,
Addison-Wesley, 2000
 K. SUBIETA: Obiektowość w projektowaniu i bazach danych,
Akademicka Oficyna Wydawnicza PLJ, 1998

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 3

Zagadnienia

 Notacja

 Analiza aktorów

 Analiza przypadków użycia

 Relacje między przypadkami użycia

 Związek uogólnienia między aktorami

 Określanie aktorów

 Określanie przypadków użycia

 Dokumentowanie przypadków użycia

 Diagram interakcji dla przypadku użycia

 Podsumowanie

Model przypadków użycia:

Klasyfikatory; wystąpienia klasyfikatorów

Prezentowanie diagramów

Stereotypy; komentarze

Związki pomiędzy elementami modelowania

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 4

Prezentowanie diagramów

nagłówek

Diagramy mogą być prezentowane w formie:

- nieobramowanej

- obramowanej, gdzie diagram jest otoczony prostokątną ramą
zawierającą
nagłówek

nagłówek-diagramu=(rodzaj) nazwa-diagramu (parametry)

rodzaj – wyróżnik diagramu
nazwa – odzwierciedlająca merytoryczną zawartość
diagramu
parametry – parametry kluczowe dla danego
diagramu

Nazwa jest obligatoryjnym elementem składowym nagłówka;
rodzaj i parametry są elementami nieobligatoryjnymi.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 5

Stereotypy; komentarze

Stereotypy: mechanizm rozszerzalności UML. Stereotypy są
wykorzystywane do meta-klasyfikacji elementów modelu.

Notacja:

«

nazwa stereotypu

»

lub ikona

Przykłady stereotypów:

P1

P2

«include»

P3

P4

«extend»

Komentarze: mechanizm rozszerzalności UML. Komentarze są
wykorzystywane do wprowadzania do diagramu adnotacji przypisanych
do fragmentu modelu.

tekst adnotacji

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 6

Klasyfikatory; wystąpienia klasyfikatorów

Klasyfikator: kategoria modelowania UML, stanowiąca uogólnienie
grupy bytów o podobnych własnościach; pojęcie klasyfikatora odnosi
się do każdego rodzaju diagramów UML.

Notacja: zależna od rodzaju diagramów

Wystąpienie klasyfikatora (instacja klasyfikatora): odpowiada
konkretnemu bytowi z grupy bytów charakteryzowanych przez dany
klasyfikator

Notacja: zazwyczaj zgodna z notacją klasyfikatora; różnice występują głównie
w nazwach wystąpień: nazwa_własna_danego_bytu : nazwa_klasyfikatora

nazwisko : string
wiek : integer

Osoba

nazwisko = ” Nowak”
wiek = 35

O-Nowak : Osoba

klasyfikator

wystąpienie klasyfikatora

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 7

Związki pomiędzy elementami modelowania

(1)

Na diagramach UML występują cztery rodzaje związków pomiędzy
elementami modelowania: uogólnienie, asocjacja, zależność, realizacja.

Uogólnienie (generalizacja): występuje pomiędzy
klasyfikatorem ogólnym a klasyfikatorem specjalizowanym

Notacja:

Asocjacja: opisuje powiązania pomiędzy wystąpieniami
klasyfikatorów (również pomiędzy różnymi wystąpieniami tego
samego klasyfikatora)

Notacja:

klasyfikator
ogólny

klasyfikator
specjalizowany

klasyfikator

klasyfikator

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 8

Związki pomiędzy elementami modelowania

(2)

Zależność: jest związkiem pomiędzy takimi dwoma elementami
modelowania, dla których zmiana jednego elementu (u dostawcy
usług) może skutkować koniecznością wprowadzenia zmian do
elementu drugiego (u klienta usług)

Notacja:

Realizacja: to związek pomiędzy klasyfikatorami, gdzie jeden z
klasyfikatorów opisuje kontrakt, a drugi określa sposób realizacji
tego kontraktu

Notacja:

dostawca
usług

klient
usług

klasyfikator określający
sposób realizacji kontraktu

klasyfikator
opisujący kontrakt

Co?

Jak?

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 9

Modele wg Jacobsona

Model przypadków użycia: definiuje zarówno zewnętrze systemu
(aktorzy ≡ systemy zewnętrzne ≡ kontekst systemu), jak i jego wnętrze
(przypadki użycia); służy określeniu zachowań systemu w odpowiedzi
na akcje pochodzące z otoczenia systemu.

Obiektowy model dziedziny: odwzorowywuje byty świata
rzeczywistego (dziedziny problemowej ≡ dziedziny przedmiotowej) w
obiekty istniejące w systemie.

Obiektowy model analityczny: podzbiór modelu dziedziny (dotyczy
konkretnego zastosowania).

Model projektowy (logiczny): opisuje założenia przyszłej
implementacji.

Model implementacyjny (fizyczny): reprezentuje implementację
systemu.

Model testowania: określa plan testów, specyfikuje procedury, dane
testowe, raporty.

Modele wymagają odpowiednich procesów do ich tworzenia
 Proces analizy wymagań, składa się z dwóch podprocesów:

- proces modelowania przypadków użycia
- proces analizy związany z budową obiektowego modelu

analitycznego

 Proces projektowania

 Proces implementacji

 Proces testowania

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 10

Model analityczny

Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu.

Zakres

odpowiedzialności

systemu

Model analityczny

Celem budowy modelu analitycznego
może być wykrycie tych fragmentów
dziedziny problemu, których
wspomaganie za pomocą innego
oprogramowania będzie szczególnie
przydatne.

 Ujęcie w modelu pewnych elementów dziedziny problemu nie
będących częścią systemu czyni model bardziej zrozumiałym.
Przykładem jest ujęcie w modelu systemów zewnętrznych, z którymi
system ma współpracować.
 Na etapie modelowania może nie być jasne, które elementy
modelu będą realizowane przez oprogramowanie, a które w sposób
sprzętowy lub ręcznie.

Dziedzina problemu

Dostępne środki mogą nie
pozwolić na realizację systemu
w całości.

Przyczyny:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 11

Model wymagań

 Model przypadków użycia

 Obiektowy model analityczny

Składowe:

Model przypadków użycia został oparty o dwa podstawowe pojęcia:

Aktor

Przypadek użycia

Reprezentuje rolę, którą może grać w
systemie

jakiś

jego

użytkownik,

np.

kierownik, urzędnik, klient.
Reprezentuje sekwencję operacji
(realizowanych przez system), niezbędnych
do wykonania zadania zleconego przez
aktora, np. potwierdzenie pisma, złożenie
zamówienia, itp.

Aktorem jest dowolny byt z otoczenia systemu, który uczestniczy w
interakcji z systemem. Każdy potencjalny aktor może wchodzić w
interakcję z systemem na pewną liczbę jemu właściwych sposobów.
Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje
przepływ operacji w systemie związany z obsługą zadania zleconego
przez aktora w procesie interakcji.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 12

Notacja

Przypadek użycia: Powinien mieć unikatową
nazwę, opisującą przypadek użycia z punktu
widzenia jego zasadniczych celów. Czy lepiej jest
stosować nazwę opisującą czynność (“wypłata
pieniędzy”/„wypłacanie pieniędzy”) czy polecenie
(“wypłać pieniądze”) − zdania są podzielone.

Aktor: Powinien mieć unikatową nazwę.

Interakcja: Ilustruje związek asocjacji zachodzący
pomiędzy przypadkiem użycia (systemem) a
aktorem.

Blok ponownego użycia: Wewnętrzny fragment
systemu, używany przez kilka przypadków użycia;
blok ponownego użycia nie jest elementem UML.

Relacja typu

«

include

»

lub

«

extend

»

: Pokazuje

związek zależności zachodzący pomiędzy dwoma
przypadkami użycia lub przypadkiem użycia a
blokiem ponownego użycia.

Nazwa diagramu wraz z nagłówkiem i ramą: ud
(ang. use case diagram) – wyróżnik diagramu.

Weryfikac

ja

klienta

Wypłata

pieniędzy

ud Obsługa
klienta

«include»

Klient

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 13

Aktor − kto (co) może wystąpić w roli

aktora?

Metoda przypadków użycia wymaga od analityka określenia
wszystkich

aktorów

związanych

z

planowanym

wykorzystywaniem projektowanego systemu, innymi słowy
wymaga ustalenia zbioru “przyszłych użytkowników systemu”.

Zazwyczaj aktorem jest osoba, ale może nim być także pewna
organizacja (np. biuro prawne), inny system komputerowy lub
urządzenie. Aktor modeluje grupę osób pełniących pewną rolę, a nie
konkretną osobę. 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, np.
aktor “strażnik budynku”.

(2) Aktor jest pierwotną przyczyną napędzającą przypadki użycia.
Jest sprawcą zdarzeń powodujących uruchomienie przypadku
użycia, jest też odbiorcą danych wyprodukowanych przez
przypadek użycia. Sprawca zdarzeń? Czy np. klient, nie
posiadający bezpośredniego dostępu do funkcji systemu jest
aktorem?

(1) Czy system może być aktorem sam dla siebie? Aktor to
przecież, zgodnie z definicją, byt z otoczenia systemu.

(3) Aktor pasywny a interakcja z systemem ?

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 14

Analiza aktorów

Wyjaśnienie

różnicy

pomiędzy

pojęciem

„konkretny użytkownik” a pojęciem „aktor”:

Konkretny
użytkownik

Aktor

Przypadek użycia

Może grać rolę

zleca

Jan Kowalski

Adam Malina

Konkretny

gość

Konkretny klient

Administrator systemu

Pracownik

Osoba

informowana

Klient

Przeładowanie systemu

Wejście z kartą i kodem

Uzyskanie

informacji ogólnych

Wypłata z konta

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 15

Wykorzystanie stereotypów dla aktorów

Aktor: system zewnętrzny

System

ubezpieczeń

Aktor: czas

1-szy dzień

roku

Klient

«actor»

Klient

Aktor: człowiek,
grupa ludzi,
organizacja

Klient

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 16

Przykład diagramu przypadków użycia (1)

Wpłata pieniędzy

Wypłata pieniędzy

Czy klient jest aktorem dla przypadku użycia: wpłata pieniędzy – to zależy
od konkretnego systemu. W operacjach wpłaty i wypłaty pieniędzy mogą
uczestniczyć także inni aktorzy, np. kasjer. Możemy go dołączyć jako
kolejny element rozbudowujący nasz model.

Klient

Klient

Kasjer

?

Wpłata pieniędzy

Wypłata pieniędzy

alternatywna notacja dla przypadków
użycia

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 17

Przykład diagramu przypadków użycia (2)

ud Automat do sprzedaży papierosów

Zakup paczki

papierosów

Uzupełnienie

towaru

Wykonanie operacji

pieniężnej

Sporządzenie

raportu

Klient

Operator

Kontroler

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 18

Liczność związków asocjacji

ud Automat do sprzedaży papierosów

Zakup paczki

papierosów

Uzupełnienie

towaru

Wykonanie operacji

pieniężnej

Sporządzenie

raportu

Klient

Operator

Kontroler

*

1

*

*

*

*

1

1

1

1

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 19

Oznaczanie kierunków interakcji

ud Automat do sprzedaży papierosów

Zakup paczki

papierosów

Uzupełnienie

towaru

Wykonanie operacji

pieniężnej

Sporządzenie

raportu

Klient

Operator

System

archiwizujący

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 20

Relacje między przypadkami użycia (1)

Przypadki użycia mogą być konstruowane w dowolnej
kolejności, chyba że występują między nimi związki zależności
typu

«

include

»

czy

«

extend

»

.

P1

P2

«

include

»

P1

P2

«

extend

»

Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa)
P2, zwane tu przypadkiem włączanym.

Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o
P2, zwane tu przypadkiem rozszerzającym (inaczej: P2 czasami
rozszerza P1). Sformułowanie “czasami” oznacza, że warunek na
wywołanie P2 musi być spełniony, aby P2 zostało wywołane z P1. O ile
warunek nie został wyspecyfikowany − co jest dopuszczalne − P2
będzie wywołane zawsze.

W obu poniższych diagramach P1, nazywane tu przypadkiem
bazowym, zawsze występuje jako pierwsze w kolejności działania.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 21

Relacje między przypadkami użycia (2)

«include» wskazuje na
wspólny fragment wielu
przypadków użycia
(wyłączony “przed nawias”);
jest wykorzystywane w
przebiegach
podstawowych (przypadek
włączany jest zawsze
wykonywany) − strzałka jest
skierowana w stronę
przypadku włączanego

«extend» jest
wykorzystywane w
przebiegach opcjonalnych
(przypadek rozszerzający nie
zawsze będzie wykonywany)
− strzałka jest skierowana w
stronę przypadku bazowego

Naprawa

samochodu

Przegląd

samochodu

Sprzedaż

samochodu

Rejestracja

klienta

«

include

»

«

include

»

«

include

»

Umycie

samochodu

«

extend

»

Przyholowanie

samochodu

«

extend

»

«

extend

»

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 22

Relacje między przypadkami użycia (3)

Punkty rozszerzające

(extension points)

Umożliwiają podanie
warunków wymaganych do
użycia przypadków
rozszerzających
(„opcjonalnych”).

Umycie

samochodu

«

extend

»

Przyholowanie

samochodu

«

extend

»

«exten
d»

Naprawa

samochodu

extension points:

Samochód poza warsztatem
Samochód wymaga przeglądu

Przegląd

samochodu

extension points:

Samochód jest brudny

extension point:
Samochód poza
warsztatem

extension point:
Samochód wymaga
przeglądu

extension point:
Samochód jest
brudny

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 23

Relacje między przypadkami użycia (3)

Uwaga: Zabronione jest łączenie relacją «include» (czy «extend»)
przypadków użycia występujących w różnych przebiegach
systemu, jak np. na poniższym diagramie.

Klient

Dostawca

Złożenie zamówienia

Realizacja zamówienia

«

extend

»

Między złożeniem zamówienia a jego realizacją z reguły upływa trochę czasu.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 24

Związek uogólnienia między aktorami (1)

Np. Pracownik administracji dziedziczy dostęp do przypadków użycia
wyspecyfikowanych dla każdego pracownika, oraz ma dostęp do
przypadków związanych z jego własnym, specyficznym sposobem
wykorzystywania systemu.

Osoba

Gość

Pracownik

Księgowa

Pracownik

administracji

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 25

Związek uogólnienia między aktorami (2)

Obsługa

konta klienta

Informowanie o

stanie konta klienta

Inicjalizacja
karty klienta

Weryfikacja karty

i kodu klienta

ud Automat do operacji bankowych

«

include

»

«

include

»

«

include

»

Podsystem

zarządzania bazą

danych banku

Klient

Administrator

systemu

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 26

Związek uogólnienia między aktorami (3)

Obsługa

konta klienta

Informowanie o

stanie konta klienta

Inicjalizacja
karty klienta

Weryfikacja karty

i kodu klienta

ud Automat do operacji bankowych

«

include

»

«

include

»

«

include

»

Podsystem

zarządzania bazą

danych banku

Klient

Administrator

systemu

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 27

Rozbudowa modelu przypadków użycia

Model

przypadków

użycia

można

rozbudowywać

poprzez

dodawanie nowych aktorów, nowych przypadków użycia czy też
nowych relacji pomiędzy przypadkami.

Klient
banku

Wpłać

pieniądze

Wypłać

pieniądze

Kasjer

Sprawdź

stan konta

Weź

pożyczkę

Zarząd

banku

Klient
banku

Wpłać

pieniądze

Wypłać

pieniądze

Kasjer

Sprawdź

stan konta

Weź

pożyczkę

Zarząd

banku

«include»

Uaktualnianie

stanu konta

«include»

«extend»

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 28

Stopień szczegółowości diagramów

Model przypadków użycia dostarcza bardzo abstrakcyjnego spojrzenia na
system − spojrzenia z pozycji aktorów, którzy go używają. Z założenia nie
włącza zbyt wielu szczegółów, co pozwala wnioskować o funkcjonalności
systemu na odpowiednio wysokim poziomie abstrakcji. Podstawowym
(choć nie jedynym) zastosowaniem jest tu dialog z przyszłymi
użytkownikami zmierzający do sformułowania poprawnych wymagań na
system.

Edycja

programu

Kompilacja

programu

Wykonanie

programu

Drukowanie

pliku

Programista

Użytkownik

końcowy

«

include

»

«

include

»

Tworzenie przypadków
użycia jest
niezdeterminowane i
subiektywne. Na ogół,
różni analitycy tworzą
różne modele.

Model zbyt szczegółowy − utrudnia analizę, zbyt ogólny − nie
pozwala na wykrycie bloków ponownego użycia.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 29

Diagram kontekstowy

Podsystem

zarządzania bazą

danych banku

Klient

Administrator

systemu

«system»

Automat do

operacji

bankowych

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 30

Przepływ zdarzeń (1)

 Jednym z najważniejszych elementów w opisie każdego
przypadku użycia – na etapie formułowania wymagań – jest
specyfikacja przepływu zdarzeń między aktorem a systemem.
Specyfikację przepływu zdarzeń należy formułować w języku
naturalnym: prostą, spójną prozą i w oparciu o terminy zawarte w
słowniku pojęć z dziedziny problemowej.

1. Przypadek użycia rozpoczyna się, gdy klient wkłada kartę do

bankomatu.

System czyta informacje na karcie i bada ich poprawność.
2. System pyta o PIN. Klient wprowadza PIN. System sprawdza

poprawność.

3. System pyta o rodzaj operacji do wykonania. Klient wybiera:

“Wypłać

pieniądze”.
4. System pyta o wielkość kwoty. Klient wprowadza kwotę.
5. System komunikuje się z bankiem, żeby sprawdzić

poprawność ID konta, PIN i dostępność kwoty.

Na przykład, przepływ zdarzeń między aktorem a systemem dla
bankomatu, dla przypadku użycia “Wypłać pieniądze”, mógłby
być opisany, jak poniżej:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 31

Przepływ zdarzeń (2)

6. System pyta klienta czy potrzebuje potwierdzenie.
7. System komunikuje klientowi prośbę o zabranie karty. Klient

zabiera kartę.

Komunikat stanowi tu pewien mechanizm bezpieczeństwa

chroniący klienta

przed nie zabraniem karty.
8. System wydaje pieniądze.
9. System drukuje potwierdzenie (o ile klient sobie życzył) i to

kończy

przypadek użycia.

 Możliwe są różne, alternatywne przepływy dla tego przypadku
użycia:

 Dane od aktora: np. aktor może unieważnić transakcję w
dowolnym momencie
lub może nie chcieć potwierdzenia.

 Stan systemu: np. bankomat może nie zawierać pieniędzy,
może brakować
papieru, może nastąpić blokada urządzenia wydającego
pieniądze czy też
blokada urządzenia drukującego potwierdzenie.

 Time-out lub błędy: np. jeśli klient nie odpowie w określonym
czasie, system
może unieważnić transakcję.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 32

Scenariusze

 Każdy alternatywny przepływ nie oznacza oddzielnego
przypadku użycia raczej grupujemy wszystkie powiązane przepływy
w jeden przypadek użycia.

 Taką grupę przepływów czasami nazywa się klasą przypadków
użycia.

 Wystąpieniem klasy przypadków użycia jest wtedy jeden z
pojedynczych, alternatywnych przepływów.

 Wystąpienie klasy przypadków użycia jest także nazywane
scenariuszem.

 Scenariusze są używane do “ekstrahowania” z przypadku użycia
unikatowej sekwencji akcji, inaczej: “wątków” w przypadku użycia.

 Na wczesnych etapach rozwoju systemu łatwiej jest rozpocząć
prace od pewnego konkretnego scenariusza, a następnie dokładać
przepływy alternatywne − w ten sposób tworzy się klasę
przypadków użycia.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 33

Kolejne kroki w konstrukcji modelu

Konstrukcja modelu przypadków użycia opiera się na kilku krokach i
wymaga ścisłej współpracy z przyszłym użytkownikiem, co implikuje
zasadę: “nie opisuj przypadków użycia w sposób, który nie jest łatwo
zrozumiały dla użytkownika”.

Jednocześnie powinien być budowany obiektowy model analityczny (schemat pojęciowy).

Krok:

Udokumentowany w:

Sporządzenie słownika

pojęć

Słownik pojęć

Określenie aktorów

Określenie przypadków

użycia

Tworzenie opisu każdego
przypadku
użycia plus:

 podział na nazwane części

 znalezienie wspólnych części
w różnych przypadkach użycia

Dokument opisu

aktorów

Diagram przypadków użycia +
dokument z opisem przypadków
użycia

1

2

3

4

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 34

Krok 1: sporządzenie słownika pojęć

 Słownik dotyczy dziedziny problemowej.
 Tworzenie go polega na wyłowieniu wszystkich pojęć z wymagań
użytkownika.
 Pojęcia mogą odnosić się do aktorów, przypadków użycia, obiektów,
operacji, zdarzeń, itp.
 Pojęcia w słowniku powinny być zdefiniowane w sposób precyzyjny
i jednoznaczny.
 Posługiwanie się pojęciami ze słownika powinno być regułą przy
opisie każdego kolejnego problemu, sytuacji czy modelu.

Na co należy zwracać uwagę przy kwalifikowaniu pojęć do
słownika:

 na rzeczowniki

−

mogą oznaczać aktorów lub byty z dziedziny

problemowej,
 na frazy opisujące funkcje, akcje, zachowanie się

−

mogą

stanowić podstawę do wyróżniania przypadków użycia.

 Ważnym jest, by już na tym etapie rozpocząć organizowanie słownika pojęć.

Konto – służy do rejestrowania zasobów i wyników transakcji
przeprowadzanych przez klienta, będącego właścicielem
konta. Konta mogą być różnych typów, a w szczególności:
konta indywidualne, małżeńskie, firmowe i inne. Każdy klient
może posiadać więcej niż jedno konto.

Przykład:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 35

Krok 2: określanie aktorów

Przy określaniu aktorów istotne są odpowiedzi na
następujące pytania:

 Jaka grupa użytkowników potrzebuje wspomagania ze strony
systemu (np. osoba
wysyłająca korespondencję)?

 Jacy użytkownicy są konieczni do tego, aby system działał i
wykonywał swoje
funkcje (np. administrator systemu)?

 Z jakich elementów zewnętrznych (innych systemów, urządzeń)
musi korzystać
system, aby realizować swoje funkcje.

Ustalanie potencjalnych aktorów musi być powiązane z ustalaniem
granic systemu, tj. odrzucaniem tych obszarów dziedziny
problemowej, którymi system nie będzie się zajmował (ustalenie
zakresu odpowiedzialności systemu).

 nazwę dla każdego aktora/roli,

 zakresy znaczeniowe dla poszczególnych nazw aktorów oraz relacje pomiędzy zakresami
(np. sekretarka  pracownik administracji  pracownik  dowolna osoba). Niekiedy

warto ustalić hierarchię dziedziczenia dostępu do funkcji systemu dla aktorów.

Po wyszukaniu aktorów, należy ustalić:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 36

Krok 3: określanie przypadków użycia (1)

 Dla każdego aktora, znajdź zadania: (1) w których system może go
wesprzeć w działalności związanej z dziedziną przedmiotową, (2)
niezbędne dla wspomagania działania systemu jako takiego (np.
zakładanie kont użytkowników).

 Staraj się powiązać w jeden przypadek użycia zespół zadań
realizujących podobne cele. Unikaj rozbicia jednego przypadku na zbyt
wiele pod-przypadków.

 Opisz przypadki użycia przy pomocy zdań w języku naturalnym,
używając terminów ze słownika.

 Uporządkuj aktorów i przypadki użycia w postaci diagramu.
 Przeanalizuj zarówno wyspecyfikowane przypadki użycia (niektóre z
nich mogą być „mutacjami” innych przypadków użycia), jak i powiązania
aktorów z przypadkami użycia. Ustal, co jest zbędne, a co może być
uogólnione.

Nazwy dla przypadków użycia powinny być krótkie, ale
jednoznacznie określające charakter zadania zlecanego
systemowi przez aktora. Ponadto, nazwy powinny odzwierciedlać
czynności z punktu widzenia aktorów, a nie systemu, czyli np.
“wpłacanie pieniędzy”, a nie “przyjęcie pieniędzy od klienta”.

funkcja systemu ≡ zachowanie systemu ≡ zadanie zlecane systemowi ≡ przypadek użycia

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 37

Określanie przypadków użycia (2)

 W pierwszym podejściu skup się na tzw. „przypadkach krytycznych”,
czyli takich, które stanowią istotę systemu (są normalnym,
standardowym użyciem) lub są ważne z powodu istniejących w projekcie
ryzyk (np. ryzyk technologicznych). Pomiń czynności wyjątkowe,
uzupełniające lub opcjonalne; pomiń przypadki użycia typu C

reate

R

ead

U

pdate

D

elete

.

 Określ wzajemne powiązania przypadków, wyspecyfikuj rodzaj
zależności: sekwencja («include») czy alternatywa («extend»).

 Dodaj zachowania wyjątkowe, uzupełniające, opcjonalne i CRUD. Ustal
związki “przypadków krytycznych” z tego rodzaju zachowaniami.

 Tworząc podział każdego przypadku użycia na nazwane części (bloki),
staraj się, aby nie były one ani zbyt ogólne ani zbyt szczegółowe. Zbyt
szczegółowe bloki utrudniają analizę, a zbyt ogólne zmniejszają
możliwość wykrycia fragmentów oprogramowania posiadających
potencjał ponownego użycia. Całość diagramu nie może być ani zbyt
duża ani zbyt złożona.

 Przeanalizuj przypadki użycia pod kątem wyizolowania bloków
ponownego użycia. Przeanalizuj podobieństwo nazw przypadków użycia,
podobieństwo nazw i zachowania bloków występujących w ich
specyfikacji. Wydzielenie bloku ponownego użycia może być powiązane z
określeniem bardziej ogólnych zadań lub dodaniu nowych elementów do
już istniejącego zadania.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 38

Krok 4: dokumentowanie przypadków użycia

1. Diagramy przypadków użycia: aktorzy, przypadki użycia i relacje
zachodzące między
przypadkami.
2. Krótki, ogólny opis każdego przypadku użycia:

Dokumentacja przypadków użycia powinna zawierać:

3. Opis szczegółowy każdego przypadku użycia:

 scenariusz(e)

 specyfikację uczestniczących obiektów,

 diagram(y) interakcji.

 jak i kiedy przypadek użycia zaczyna się i kończy,

 opis interakcji przypadku użycia z aktorami, włączając w to
kiedy interakcja ma
miejsce i co jest przesyłane,

 kiedy i do czego przypadek użycia potrzebuje danych
zapamiętanych w systemie
oraz jak i kiedy zapamiętuje dane w systemie,

 wyjątki występujące przy obsłudze przypadku,

 specjalne wymagania, np. czas odpowiedzi, wydajność,

 jak i kiedy używane są pojęcia dziedziny problemowej.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 39

Diagram interakcji dla przypadku użycia (1)

Przesyłanie komunikatów pomiędzy obiektami:

k1

k2

k3

k4

k5

Obiekt 1

Obiekt 2

Obiekt 3

Obiekt 4

ki

− komunikat, czyli polecenie wykonania operacji na obiekcie, do

którego komunikat jest wysyłany; komunikat nosi nazwę tej operacji

czas

Aktor

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 40

Diagram interakcji dla przypadku użycia (2)

wpłata

pieniędzy

:Formularz

:Kasa

:Konto

:Bank

wypełnij

podaj formularzaktualizuj stan

zwiększ
bilans

zwiększ
bilans

wydaj
pokwitowanie

:Klient

Uproszczony scenariusz

Wypełnij formularz wpłaty
Podaj formularz i gotówkę do
kasy
Aktualizuj stan konta klienta
Zwiększ bilans kasy
Zwiększ bilans banku
Wydaj pokwitowanie dla
klienta

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 41

Szablon dokumentacji przypadku użycia

Nazwa

Nazwa przypadku

Nr id

Numer identyfikacyjny przypadku

Autor

Informacje o autorze

Priorytet

Np. wysoki, średni, itd.

Typ

Np. ogólny, szczegółowy

Aktorzy

Lista aktorów związanych z przypadkiem

Opis

Krótka charakterystyka przypadku

Warunek początkowy

Świat „przed”, czyli informacja o tym, co

powinno być wykonane wcześniej, tak aby

system mógł zrealizować dany przypadek

Warunek końcowy

Świat „po”

Główny przepływ zdarzeń Scenariusz główny
Alternatywne przepływy
zdarzeń

Scenariusze alternatywne

Wymagania

niefunkcjonalne

Np. czas odpowiedzi, szybkość transakcji, itd.

Uwagi dodatkowe

Wszystko, co warte jest uwagi, a nie zostało

omówione powyżej

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 42

Dokumentacja przypadku Wypożycz kasetę

(1)

Nazwa

Wypożycz kasetę

Nr id

7

Autor

Jan Kowalski - analityk

Priorytet

Wysoki

Typ

Ogólny

Aktorzy

Pracownik wypożyczalni

Opis

Przypadek dotyczy rejestracji wypożyczenia kaset;

kasety przeznaczone dla dorosłych można

wypożyczać od 18-tego roku życia; jednocześnie

można mieć wypożyczonych co najwyżej 5 kaset;

nie wolno wypożyczać osobie, która aktualnie

znajduje się w okresie karencji

Warunek początkowy

Osoba wypożyczająca powinna być zarejestrowana

jako klient wypożyczalni

Warunek końcowy

O ile warunki wypożyczenia zostały zrealizowane,

to powinny zostać zarejestrowane następujące

informacje o wypożyczeniu kasety : kto

wypożyczył, co wypożyczył i kiedy wypożyczył

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 43

Dokumentacja przypadku Wypożycz kasetę

(2)

Główny przepływ

zdarzeń

1. Pracownik wypożyczalni uruchamia przypadek

Wypożycz kasetę.

2. System odpytuje o nazwisko i imię osoby

wypożycząjącej. Pracownik wprowadza

odpowiednie informacje.

3. System odpytuje o tytuł filmu. Pracownik

wprowadza tytuł.

4. System rejestruje wypożyczenie kasety z filmem

(kto, co, data wypożyczenia).

Alternatywne

przepływy

zdarzeń

2a O ile osoba wypożyczająca nie jest

zarejestrowana w

systemie, system informuje o tym aktora i

kończy

przypadek użycia

2b. O ile jest zarejestrowana więcej niż jedna

osoba o tym

samym nazwisku i imieniu, system wyświetla

okno z

listą osób. Pracownik wybiera odpowiednią

osobę z listy.

3a O ile aktualnie nie ma filmu o tym tytule w

zasobach

wypożyczalni, lub wszystkie kasety z filmem są

wypożyczone, system informuje o tym aktora i

kończy

przypadek.

3b O ile film jest przeznaczony dla osób dorosłych

a osoba

wypożyczająca nie ukończyła 18-tu lat, system

informuje o

tym aktora i kończy przypadek.

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 44

Dokumentacja przypadku Wypożycz kasetę

(3)

Alternatywne przepływy

zdarzeń, cd.

3c Jeśli osoba wypożyczająca ma już aktualnie

co najmniej pięć wypożyczonych kaset na

koncie, system informuje o tym aktora i

kończy przypadek.

3d Jeśli osoba wypożyczająca znajduje się

aktualnie w okresie karencyjnym, system

informuje o tym aktora i kończy przypadek.

Wymagania

niefunkcjonalne

Brak

Uwagi dodatkowe

Brak

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 45

Podsumowanie

Główne zadanie modelu przypadków użycia to określenie
poprawnych wymagań

funkcjonalnych

na projektowany system,

co jest uznawane za jeden z podstawowych problemów w procesie
budowy systemu.

Przypadki użycia powinny odwzorowywać strukturę
systemu tak, jak tę strukturę widzą przyszli
użytkownicy systemu.

 lepsze zrozumienie możliwych sposobów wykorzystania

projektowanego systemu (przypadków użycia), lepsze zrozumienie
jego funkcjonalności − co w efekcie oznacza zwiększenie stopnia
świadomości uczestników projektu co do celów systemu,

 umożliwienie interakcji zespołu projektowego z przyszłymi

użytkownikami systemu,

 ustalenie praw dostępu do zasobów,

 zrozumienie strukturalnych własności systemu, a przez to ustalenie

składowych systemu i związanego z nimi planu budowy systemu,

 dostarczenie podstawy do sporządzenia harmonogramu prac,

 dostarczenie bazy do budowy planu testów systemu,

 dostarczenie środków umożliwiających weryfikację poprawności i

kompletności projektu.

Ponadto, model przypadków użycia pozwala na:

Analiza i Projektowanie Systemów Informatycznych, Wykład 1,
Slajd 46

Przypadki użycia w analizie

Eksperci

Użytkownicy

Doświadczenie

w dziedzinie

przedmiotowej

Przypadki

użycia

Model

dziedziny

Model

zastosowania

Model

analityczny

mocny wpływ
słaby wpływ