Projektowanie systemów informatycznych

Modelowanie obiektowe

funkcjonowania systemów w języku UML

Diagramy przypadków użycia

systemu

Dr hab. inż.. Edward Kołodziński prof. UWM

Katedra Informatyki Stosowanej

Wydziału Nauk Technicznych

MOFS - 3

ISZB - studia inżynierskie – I rok

Olsztyn 2009/2010

MODELOWANIE OBIEKTOWE FUNKCJONOWANIA SYSTEMÓW

Literatura:

1.

1.

Graessie P. i inni: UML 2.0 w akcji, Przewodnik

Graessie P. i inni: UML 2.0 w akcji, Przewodnik

oparty na projektach, Helion 2008

oparty na projektach, Helion 2008

2.

2.

Śmiałek M.: Zrozumieć UML 2.0 Metody

Śmiałek M.: Zrozumieć UML 2.0 Metody

modelowania obiektowego. Helion 2005 r.

modelowania obiektowego. Helion 2005 r.

3.

3.

Schmuller J.: UML dla każdego, Helion2001

Schmuller J.: UML dla każdego, Helion2001

4.

4.

Wrycza S.: Język UML 2.0 w modelowaniu

Wrycza S.: Język UML 2.0 w modelowaniu

obiektowym,

obiektowym,

Helion 2006

Helion 2006

MODELOWANIE OBIEKTOWE FUNKCJONOWANIA SYSTEMÓW

MODELOWANIE OBIEKTOWE FUNKCJONOWANIA SYSTEMÓW

Po co?

Czyli

Jaki jest cel opracowywania modelu?

Doskonalenie jakości funkcjonowania

systemu.

Poprawa

Skuteczności

Efektywności

Bezpieczeństwa

Itp.

Po co model?-

bo

„lepiej widać

rzeczywistość”

i problemy do rozwiązania.

MODELOWANIE OBIEKTOWE FUNKCJONOWANIA SYSTEMÓW

Motto:

„Skuteczność przedsięwzięcia inowacyjnego

zależy przede wszystkim od umiejętności

poprawnego sprecyzowania i jednoznacznego

zapisania

wymagań

na pożądany jego zakres.”

Np. na zakres

przedsięwzięcia

informatycznego

w organizacji

(w szczególności pożądane właściwości

projektowanego systemu informatycznego

(PSI))

patrzymy z perspektywy

ZAMAWIAJĄCEGO.

Podstawowe założenia obiektowego podejścia do

doskonalenia funkcjonowania organizacji (systemu)

Przy

ustalaniu wymagań

na zakres

przedsięwzięcia innowacyjnego ,

np. informatycznego, w organizacji

stosować będziemy

podejście

obiektowe.

Co to oznacza?

Podejście obiektowe do modelowania funkcjonowania organizacji w celu
określenia wymagań oznacza sposób identyfikacji jej :
- zadań,
- granic,
- struktury organizacyjnej,
- zadań wyróżnionych elementów składowych organizacji,
- technologii realizacji zadań przez te elementy,
- potrzeb danych tych elementów do realizacji przypisanych im

zadań,

- zewnętrznych i wewnętrznych przepływów danych niezbędnych do

realizacji zadań,

- zawartości i struktury bazy danych organizacji,
w celu ustalenia:
1.

wymagań na

przedsięwzięcie innowacyjne - np. informatyczne

;

2.

budżetu przedsięwzięcia innowacyjnego - np. informatycznego;

3.

harmonogramu realizacji przedsięwzięcia innowacyjnego - np.

informatycznego.

Podstawowe założenia obiektowego podejścia

do doskonalenia funkcjonowania organizacji

Ustalanie

wymagań na

przedsięwzięcie innowacyjne

(np.informatyczne)

będziemy realizować w dwóch

etapach:

1. opracowujemy model biznesowy organizacji

–środowiska funkcjonowania SI;

2. opracowujemy model systemowy SI,

na który składają się:

+ model struktury SI,

+ model dynamiki SI.

Wyznaczanie granic informatyzowanej organizacji

Granice

informatyzowanej

organizacji

identyfikuje się za

pomocą

przypadków

jej

użycia

przez

aktorów

.

Aktorzy-

role!

dowolnych bytów będących w interakcji z

rozpatrywaną organizacją, np. ludzie, urządzenia, inne

systemy, czas itp.

Aktor

-

zawsze istnieje poza organizacją (systemem),

nigdy nie jest jej częścią składową!!!.

Przykładowe pytania pozwalające zidentyfikować

aktora

:

• kto korzysta z systemu?

• kto uruchamia system?

• kto wyłącza system?

• kto zasila system ?

• kto korzysta z jego funkcjonowania?

• itd

Klien
t

Firma

Kurierska

Pracowni
k

Przedstawici

el Handlowy

Wyznaczanie granic systemu informatyzowanego cd.

Przykłady

aktorów

w systemie zamówień

Aktor

– to spójny zbiór ról odgrywanych przez użytkowników

systemu:

+

osobowych

– osoba, zespół, dział, instytucja itp. ;

+

nieosobowych

– urządzenia, czas, baza danych itp.

Odkrywanie

przypadków użycia

systemu

 Przypadek użycia systemu

inicjowany jest przez

aktora

.

 Przypadki użycia

określają czynności, które aktor chce aby

system wykonywał,

np. aktor klient – ma możliwość realizacji PU

„ Dostarcz towar”.

 Przypadki użycia-

określają

sposoby

(przedstawione za pomocą diagramów

np. czynności)

w jaki

aktorzy

korzystają z systemu.

 Przypadek użycia

powinien być całością wyodrębnionego zadania

(

widzianego z perspektywy aktora

) wykonywanego przez system na

rzecz aktora.

 Przypadki użycia

są środkami komunikacji.

Model przypadków użycia systemu jest użyteczny tylko wtedy, gdy

dostarcza adresatowi informacji do czego używany jest (jak działa)

system.

Odkrywanie

przypadków użycia

systemu



Przypadek użycia systemu

praktycznie jest inicjowany przez aktora.



Przypadki użycia

określają czynności, które aktor chce aby

system wykonywał, np.

aktor klient – możliwość „

Zamówienia towaru

”.



Przypadki użycia-

określają

sposoby (przedstawione za pomocą diagramów czynności) w jaki

aktorzy korzystają z systemu.



Przypadek użycia

powinien być całością wyodrębnionego zadania (widzianego z

perspektywy aktora) wykonywanego przez system na rzecz aktora.



Przypadki użycia

są środkami komunikacji. Model przypadków użycia systemu jest

użyteczny tylko wtedy, gdy dostarcza adresatowi informacji jak działa system.



Adresatami modelu

przypadków użycia

mogą być:

przyszli użytkownicy systemu,

specjaliści od marketingu, testerzy, projektanci,
autorzy dokumentacji itp.

 Opis

przypadków użycia

tworzony jest

iteracyjnie.

 Symbol graficzny

przypadku użycia

systemu

w UML.

Zadanie do

wykonania przez

system na rzecz aktora

Wyrażane w

trybie

rozkazującym

Odkrywanie

przypadków użycia

systemu

Symbol graficzny

przypadku użycia

systemu

w UML

Zadanie

wykonywane przez

system na rzecz aktora

wyrażone w trybie

rozkazującym

Wydaj resztę

Wydaj resztę

Wydaj resztę

Przykłady prezentacji:

Modelowanie w PSI

Na

obiektowy model funkcjonowania

organizacji

(systemu) składają się :

• model obiektowy struktury

fizycznej organizacji

;

• model obiektowy dynamiki

organizacji

–

procesów przez nią ( w niej )

realizowanych

.

Model obiektowy dynamiki organizacji

Elementy składowe

modelu obiektowego

dynamiki organizacji

:

 diagramy przypadków użycia;
 scenariusze PU;
 diagramy dynamiki: czynności,

sekwencji itp.

Diagramy przypadków użycia

Diagram przypadków użycia systemu

–

to graficzne przedstawienie użycia systemu przez

aktorów:



obramowane;



nieobramowane.

Symbol graficzny obramowanego diagramu przypadków

użycia systemu:

Ramka

Zawartość merytoryczna diagramu

Nagłówek

Otoczenie –

aktorzy

Diagramy przypadków użycia

Zawartość merytoryczna diagramu

Nagłówek

Każdy aktor na DPU

musi mieć powiązanie

co najmniej

z jednym PU

Rodzaje związków na diagramie:

• asocjacja,

• zależność,

•uogólnienie,

•realizacja.

Rodzaje związków na DPU

-

asocjacja

Asocjacja –

wskazuje na związek

na DPU

„ aktor – przypadek użycia”

Rezerwuj

salę

Wykładowca

Asocjacja

Asocjacja wskazuje jedynie na interakcję „ aktor – przypadek użycia”,

a nie przepływ danych –

bez wskazania strony inicjującej

.

Jeśli chcemy określić stronę inicjującą PU, to

strzałką

wskazujemy

kierunek

nawigacji.

Rezerwuj

salę

Rodzaje związków na DPU

-

zależność

Zależność

– związek między

dwoma

elementami

( PU)

na DPU

,

w którym zmiana

działania

niezależnego

PU

wpływa na zmianę sposobu działania PU

zależnego

.

Rodzaje zależności:



zawieranie

– ang. include,



rozszerzenie

- ang. extend.

Zależność -

zawierania

Zawieranie –

obligatoryjny związek

pomiędzy

przypadkiem

zawierającym

a

zawieranym.

Przypadek zawierany

nie jest wykonywany

samodzielnie, lecz wyłącznie przy odwołaniu się

do niego przez

zawierającego

.

Dokonaj

rezerwacji

Sprawdź

listę wolnych

pokoi

Klient

<< include>>

Zastosowanie :

 istnieje możliwość wydzielenia pewnej wspólnej funkcjonalności dla wielu PU;

 realizacja wydzielonej części licznie powtarzających się PU w funkcjonowaniu
organizacji.

PU

Zawierając

y

PU

Zawierany

Zależność –

zawierania -

przykład

Związek zawieranie (ang. include) –powtarzający się ciąg czynności w przypadkach użycia systemu,

który można wyodrębnić w nich i ująć w postaci „autonomicznego” przypadku użycia o

określonej nazwie.

Przykład -przypadek użycia „

Znajdź zamówienie”

1. Przypadek użycia zaczyna się, gdy klient wprowadzi

numer zamówienia, numer klienta albo nazwisko klienta.

2. Klient wybiera Szukaj.
3. Jeżeli klient wprowadził numer zamówienia, to system

wyświetla zamówienie i przypadek użycia się kończy.

4. Jeżeli pracownik wprowadził nazwisko klienta albo

numer klienta, to

:

a) system zwraca listę wszystkich zamówień dla tego

klienta;
b) klient wybiera jedno z zamówień z listy;
c) system wyświetla to zamówienie i przypadek użycia

kończy się.

Zależność –

zawierania

-

przykład

Przykład - przypadek użycia

Anuluj zamówienie

ze związkiem

zawierania

przypadku użycia

Znajdź

zamówienie

1.

Przypadek użycia zaczyna się, gdy klient prosi o anulowanie
zamówienia.

2.

Include

Znajdź zamówienie

.

3.

Jeżeli stan zamówienia Potwierdzone, to:

a) system oznacza zamówienie jako anulowane,

b) system zawiadamia system księgowy o konieczności
zwrotu

pieniędzy na konto klienta i przypadek

użycia kończy się;

4.

Jeżeli stan zamówienia Wysłane, to system zawiadamia
klienta o warunkach zwrotu towaru i przypadek użycia
kończy się.

Anuluj

zamówieni

e

Klient

Znajdź

zamówieni

e

<<include>
>

Diagram dla przypadku użycia „

Anuluj zamówienie”

z zawieranym przypadkiem użycia

„

Znajdź zamówienie”

Odprawa

Wydanie karty

pokładowej

Biznesowy
przypadek użycia

Związek
zawierania

Podmiot

Asocjacja

Aktor

Przedstawiciel
pasażera

Include

Inc

lud

e

Inc

lud

e

Odprawa

automatyczna

Odprawa

ekspresowa

Pasażer

Obsługa
pasażerów

Elementy diagramu przypadku użycia

Celnik na

lotnisku

docelowy

m

Obsługa pasażerów

Odprawa

Odprawa

automatyczna

Odprawa

ekspresowa

Wsiadanie

na pokład

Żądanie listy

pasażerów

Wydanie karty

pokładowej

Transpor
t bagaży

Przedstawicie

l pasażera

Pasażer

In

clu

de

Incl

ude

Includ

e

Zależność

- rozszerzanie

Związek rozszerzania

( ang. extend)

Rozszerzanie

– opcjonalny związek

między dwoma elementami (PU) na
DPU, w którym funkcjonalność PU

rozszerzającego

może być włączona

do

rozszerzanego.

Związek

rozszerzania

służy do warunkowego

rozszerzania zachowania przypadku użycia bez
zmiany jego pierwotnych zachowań.

Stosuje się

zazwyczaj

do dostosowania istniejącego

produktu

(projektu) do zmieniających

się potrzeb nowego klienta.

Rodzaje związków na DPU –

rozszerzanie

cd

.

Sprawdź listę

dostępnych pokoi

z uwzględnieniem ich

charakterystyk

Zarządzaj pokojami

<<extend>>

Stosowane

gdy funkcjonalność PU rozszerzanego, w określonych

sytuacjach, ma być uzupełniona (rozszerzona) o funkcjonalność
rozszerzającego, np.:

• zmiana kategorii pokoju,

• zmiana ceny wynajmu,

• czasowe wyłączenie pokoju z użytkowania.

PU

rozszerzający

PU

rozszerzany

Przykład

klient

Rozszerzenie

funkcjonalności

oprogramowania

stanowiska

recepcjonistki np. w

związku z

modernizacją hotelu

Rodzaje związków na DPU

–

rozszerzanie

cd

Sprawdź listę

dostępnych pokoi z

uwzględnieniem ich

charakterystyk

Miejsce rozszerzenia:

•modyfikacja danych o pokojach,

•brak pokoi spełniających kryteria.

Zarządzaj

pokojami

Przekaż informację

do recepcji

<<extend>>

<<extend>>

PU rozszerzające realizowane są w przypadku spełnienia warunków określonych
w miejscu (punktach) rozszerzenia (ang. extension points) PU rozszerzanego.

PU

rozszerzany

PU

rozszerzając

e

Dokumentowanie przypadku użycia

rozszerzenia

cd.

W dokumentacji modelu PU wskazujemy miejsca i warunki

rozszerzeń.

Każde miejsce rozszerzenia

składa się z :

•

nazwy,

•

opisu jego położenia po spełnieniu określonego warunku w PU
rozszerzanym,

•

warunki rozszerzenia.

„Przyjmij
zamówienie”

Extension Points:

przed krokiem

5.-

po wybraniu wszystkich

towarów.

Towar przeceniony:

•stały klient;

•wyprzedaż sezonowa;

•wyprzedaż nadmiernych zapasów.

Dokumentowanie przypadków użycia

cd.

Przykład związku

rozszerzenia

Opis czynności PU

„Przyjmij zamówienie” -

podstawowego

1.

realizacja PU zaczyna się, gdy klient wybierze

„Przyjmij

zamówienie”

;

2.

klient wprowadza swoje imię i nazwisko oraz adres;

3.

klient wprowadza kody towarów, które chce zamówić;

4.

dla każdego wpisanego kodu towaru:
a) system wyświetla opis i cenę towaru.
b) system dodaje cenę towaru do sumy,
koniec powtórzenia;

5. klient wprowadza informacje o karcie płatniczej;
6. klient wybiera Zatwierdź;
7. system sprawdza podane informacje, zapisuje zamówienie

jako oczekujące i przesyła informacje o płatności do systemu

księgowego;

8.

po potwierdzeniu płatności zamówienie jest oznaczone jako

potwierdzone.

System podaje klientowi numer zamówienia, a PU kończy się.

Koniec składania
zamówienia

Dokumentowanie przypadków użycia cd.

Diagram przypadku użycia

„Przyjmij zamówienie”

- z

rozszerzającymi przypadkami użycia

„Przyjmij

zamówienie”

Extension Points:

przed

krokiem 5.-

po wybraniu

wszystkich towarów.

Zniżka z powodu

wyprzedaży

sezonowej

Zniżka dla

stałych

klientów

<<extend>> (Stały
klient) [klient na liście
stałych klientów]

<<extend>>
(Towar przeceniony)
[towar na liście
towarów
przecenionych]

Zniżka z powodu

wyprzedaży

nadmiernych zapasów

<<extend>>
(Towar przeceniony) [towar na
liście nadmiernych zapasów i ilość
w magazynie > maksymalny
poziom w magazynie]

Dokumentowanie przypadków użycia cd.

Związek rozszerzenia

Przykład -przypadek użycia

„Dostarcz towar”

1.

przypadek użycia zaczyna się, gdy klient wybierze

„Dostarcz towar”

;

2.

klient wprowadza swoje imię i nazwisko oraz adres;

3.

klient wprowadza kody towarów, które chce zamówić;

4.

dla każdego wpisanego kodu towaru:
a) system wyświetla opis i cenę towaru.
b) system dodaje cenę towaru do sumy,
koniec powtórzenia;

5. klient wprowadza informacje o karcie płatniczej;
6. klient wybiera Zatwierdź;
7. system sprawdza podane informacje, zapisuje zamówienie jako oczekujące i przesyła

informacje o płatności do systemu księgowego;

8.

po potwierdzeniu płatności zmówienie jest oznaczone jako potwierdzone.

System podaje klientowi numer zamówienia, a przypadek użycia się kończy.

Rozszerzający PU „

Zniżka dla stałych klientów”

1. Przypadek użycia zaczyna się, gdy system otrzymuje wartość rabatu dla
stałego klienta.
2. System wyświetla rabat dla zamówienia.
3. System oblicza wartość rabatu, mnożąc wartość zamówienia przez procent
rabatu dla

klienta.

4. System odejmuje wartość rabatu od wartości zamówienia i przypadek
użycia się kończy.

Rodzaje związków na DPU –

zawieranie +

rozszerzanie

.

Dokonaj

rezerwacji

Zarządzaj

pokojami

Przekaż informację

do recepcji

Sprawdź listę

dostępnych pokoi

z uwzgl. ich charak.

<<include>>

<<extend>>

<<extend>>

PU

rozszerzany

PU

zawierając

y

PU

rozszerzając

e

PU

zawieran

y

Rodzaje związków na DPU-

uogólnienie

Związki uogólnienia w kontekście DPU dotyczą

zarówno PU jak i aktorów.

Sporządź

raport

Sporządź

raport o reklamacjach

Sporządź

raport sprzedaży

Pracownik

hotelu

Recepcjonista

Barman

Czy to są
aktorzy?

Rodzaje związków na DPU-

uogólnienie

Związek

uogólnienie

pozwala przedstawiać

strukturę hierarchiczną problemu (systemu).

Przykład [4]

System obsługi

kart kredytowych

System rejestracji

przelewów

System obsługi

płatności

gotówkowych

System obsługi

płatności

gotówkowych

System obsługi

płatności

Diagram kontekstowy

Diagram kontekstowy –

zestawienie

aktorów będących w interakcji z danym
systemem.

HURTOWNIA

Służby

Dostawca

Klient

Dostawca

mediów

Bank

Diagram kontekstowy –

zestawienie

aktorów będących w interakcji z danym
systemem.

Diagram kontekstowy –

zestawienie

aktorów będących w interakcji z danym
systemem.

?

Diagram kontekstowy

Diagram kontekstowy –

zestawienie

aktorów będących w interakcji z SI HURTOWNI.

SI

HURTOWNI

Magazynier

Operator

Księgowa

Dozorca

kierownik

Dostawca

Klient

?

Technologia tworzenia DPU

Opracowanie DPU systemu jest przedsięwzięciem

inicjującym informatyzację organizacji.

Tworzenie DPU jest procesem iteracyjnym.

Etapy tworzenia DPU :

1. identyfikacja i szczegółowa charakterystyka

aktorów,

2. opracowanie diagramu kontekstowego - opcjonalnie,

3. identyfikacja PU i ich charakterystyka- opis,

4. ustalenie związków i ich charakterystyka- opis,

5. sporządzenie dokumentacji.

Technologia tworzenia DPU

Tworzenie DPU jest procesem iteracyjnym.

Etapy tworzenia DPU :

1.

identyfikacja i szczegółowa charakterystyka aktorów,

2.

opracowanie diagramu kontekstowego - opcjonalnie,

3.

identyfikacja PU i ich charakterystyka- opis,

4.

ustalenie związków i ich charakterystyka- opis,

5.

sporządzenie dokumentacji.

Ad 1. charakterystyka każdego aktora powinna zawierać:

# specyfikację zadań współdziałania;

# częstość współdziałania;
# szczegółową specyfikację wymienianych danych;
# treść i forma wymiany;
# wszelkie uwarunkowania mające wpływ na sposób

„obsługi”

aktora przez system – realizację PU (

może

być więcej niż jeden).

Stopień szczegółowości opisu aktora- opis powinien zawierać informację

wystarczającą do opracowania modelu biznesowego organizacji i
analitycznego – opracowywanego systemu dla organizacji.

Technologia tworzenia DPU

Tworzenie DPU jest procesem iteracyjnym.

Etapy tworzenia DPU :

1.

identyfikacja i szczegółowa charakterystyka aktorów,

2.

opracowanie diagramu kontekstowego - opcjonalnie,

3.

identyfikacja PU i ich charakterystyka- opis,

4.

ustalenie związków i ich charakterystyka- opis,

5.

sporządzenie dokumentacji.

Ad 1. charakterystyka każdego aktora powinna zawierać:
# specyfikację zadań współdziałania;
# częstość współdziałania;
# szczegółową specyfikację wymienianych danych;
# treść i forma wymiany;
# wszelkie uwarunkowania mające wpływ na sposób „obsługi” aktora przez

system – realizację PU (może być więcej niż jeden).

Ad 2.

zaleca się sporządzanie

diagramów

kontekstowych

– poprawiają komunikatywność

dokumentacji.

Technologia tworzenia DPU

Tworzenie DPU jest procesem iteracyjnym.

Etapy tworzenia DPU :

1.

identyfikacja i szczegółowa charakterystyka aktorów,

2.

opracowanie diagramu kontekstowego - opcjonalnie,

3.

identyfikacja PU i ich charakterystyka- opis,

4.

ustalenie związków i ich charakterystyka- opis,

5.

sporządzenie dokumentacji.

Ad 1. charakterystyka każdego aktora powinna zawierać:
# specyfikację zadań współdziałania;
# częstość współdziałania;
# szczegółową specyfikację wymienianych danych;
# treść i forma wymiany;
# wszelkie uwarunkowania mające wpływ na sposób „obsługi” aktora przez

system – realizację PU (może być więcej niż jeden).

Ad 2. zaleca się sporządzanie

diagramów kontekstowych

– poprawiają

komunikatywność dokumentacji.

Ad 3.

opis powinien zawierać treści niezbędne do

opracowania diagramów dynamiki organizacji i
opracowywanego dla niej systemu.

Technologia tworzenia DPU

Tworzenie DPU jest procesem iteracyjnym.

Etapy tworzenia DPU :

1.

identyfikacja i szczegółowa charakterystyka aktorów,

2.

opracowanie diagramu kontekstowego - opcjonalnie,

3.

identyfikacja PU i ich charakterystyka- opis,

4.

ustalenie związków i ich charakterystyka- opis,

5.

sporządzenie dokumentacji.

Ad 1. charakterystyka każdego aktora powinna zawierać:
# specyfikację zadań współdziałania;
# częstość współdziałania;
# szczegółową specyfikację wymienianych danych;
# treść i forma wymiany;
# wszelkie uwarunkowania mające wpływ na sposób „obsługi” aktora przez

system – realizację PU (może być więcej niż jeden).

Ad 2. zaleca się sporządzanie

diagramów kontekstowych

– poprawiają

komunikatywność dokumentacji.

Ad 3.

opis powinien zawierać treści niezbędne do opracowania diagramów dynamiki

organizacji i opracowywanego dla niej systemu.

Ad 4. chodzi o związki zawierania się i

rozszerzenia.

Dokumentacja PU

Każdy PU powinien posiadać dokumentację w postaci

scenariusza –

ang.use case scenarios.

Scenariusz-

ciąg akcji

charakteryzujący sposób

realizacji (zachowanie) PU.

Scenariusze:

•

główne,

•

alternatywne.

Postacie scenariuszy:

•

niesformalizowany tekst,

•

tabele.

Nazwa:

Pełna nazwa przypadku użycia

Numer:

Numer identyfikacyjny przypadku użycia

Twórca:

Dane twórcy przypadku użycia,
np. imię, nazwisko, stanowisko

Poziom ważności:

Określenie poziomu ważności przypadku z perspektywy użytkownika, np. niski,
średni, wysoki

Typ przypadku
użycia:

Określenie typu przypadku użycia z punktu widzenia jego złożoności oraz
ważności dla zaspokojenia potrzeb użytkownika,
np. ogólny/szczegółowy;
niezbędny/istotny/przeciętnie istotny/mało istotny

Aktorzy:

Lista aktorów będących w związku z przypadkiem użycia

Krótki opis:

Krótka, ogólna charakterystyka przypadku użycia

Warunki wstępne:

Charakterystyka koniecznych warunków inicjujących przypadek

Warunki końcowe:

Charakterystyka stanu systemu po realizacji przypadku użycia

Główny przepływ
zdarzeń:

Wypunktowana i scharakteryzowana lista przepływów zdarzeń zachodzących
podczas realizacji przypadku użycia; scenariusz główny

Alternatywne
przepływy zdarzeń:

Wypunktowana i scharakteryzowana lista możliwych, alternatywnych
przepływów zdarzeń przypadku użycia

Specjalne
wymagania:

Wypunktowana i scharakteryzowana lista dodatkowych zidentyfikowanych
wymagań niefunkcjonalnych, które mogą być istotne przykładowo podczas
projektowania czy kodowania

Notatki i kwestie:

Lista wszelkich komentarzy dotyczących przypadku użycia i lista pozostałych
otwartych kwestii, które powinny zostać rozwiązane wraz z propozycjami osób,
które mogłyby je rozwiązać

Dokumentacja PU –

szablon

scenariusza[4]

Nazwa:

Anuluj rezerwacje

Numer:

5

Twórca:

Jan Kowalski – Projektant

Poziom ważności:

Średni

Typ przypadku użycia:

Ogólny

Aktorzy:

Recepcjonistka, Kierownik recepcji

Krótki opis:

Anulowanie istniejącej rezerwacji pokoju lub apartamentu

Warunki wstępne:

Co najmniej jeden pokój lub apartament hotelowy musi być zarezerwowany

Warunki końcowe:

System odnotowuje pokój lub (i) apartament jako dostępny

Główny przepływ zdarzeń:

1.

Recepcjonista weryfikuje rezerwacje, uruchamiając funkcję
„Rezerwacje”

2.

System wyświetla okno z informacjami o rezerwacjach (pokoje i
apartamenty hotelowe)

3.

Pracownik recepcji zaznacza rezerwacje do anulowania i uruchamia
funkcję „Anuluj rezerwacje”

4.

System wyświetla komunikat „Czy anulować zaznaczone
rezerwacje?”

5.

Pracownik recepcji potwierdza operację anulowania zaznaczonych
rezerwacji

6.

System potwierdza wykonanie operacji komunikatem „Anulowano
wybrane rezerwacje” i odświeża ekran monitora

Alternatywne przepływy
zdarzeń:

2a. System wyświetla komunikat „Brak rezerwacji”
3a. Pracownik recepcji rezygnuje z anulowania rezerwacji
3b. Jeśli podczas rezerwacji podany został adres e-mail, pracownik

może wysłać do klienta pocztą elektroniczną informację o
anulowaniu rezerwacji

Specjalne wymagania:

1.

Wysoka niezawodność systemu

2.

Czas przetwarzania operacji anulowania rezerwacji nie może
przekroczyć 5 sekund

Notatki i kwestie:

Brak

Dokumentacja PU – przykładowy scenariusz[4]

Technologia tworzenia DPU

Skąd uzyskać informację do opracowania DPU

organizacji ?

Technologia tworzenia DPU

Skąd uzyskać informację do opracowania DPU

organizacji ?

Z doświadczenia wynika, że szczególnie dobre

wyniki można uzyskać ze współpracy z grupami

osób takich, jak:

•

klienci, którzy często bywają krytycznymi, lecz

również kreatywnymi dostawcami wiedzy;

•

partnerzy biznesowi;

•

eksperci w analizowanej dziedzinie;

•

uczestnicy i kontrolerzy procesów biznesowych;

•

zarząd firmy;

•

pracownicy;

•

niezależni obserwatorzy.

Technologia tworzenia DPU

Metody poznawania procesów biznesowych

W procesie analizy i poznawania procesów biznesowych

pomocne bywają następujące techniki:

•

obserwacja pracowników przy pracy;

•

branie udziału w analizowanych procesach

biznesowych;

•

przyjęcie roli uczestnika zewnętrznego (na przykładzie

klienta);

•

ankiety;

•

przeprowadzanie wywiadów;

•

organizowanie burz mózgów z udziałem wszystkich

zaangażowanych grup;

•

prowadzenie dyskusji z ekspertami;

•

analiza istniejących formularzy, dokumentacji,

specyfikacji i narzędzi pracy;

•

opisywanie struktury organizacyjnej i zasad przepływu

informacji (diagramy organizacyjne itp.).