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