Transcript PRI_W1_UML 2.0

Projektowanie systemów informacyjnych
Wykład 1
Pojęcia wstępne
Model przypadków użycia
Ewa Stemposz, Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 1
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 2
Zagadnienia
Prezentowanie diagramów
Stereotypy; komentarze
Klasyfikatory; wystąpienia klasyfikatorów
Związki pomiędzy elementami modelowania
Model przypadków użycia:










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
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 3
Prezentowanie diagramów
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)
nagłówek
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 4
Stereotypy; komentarze
Stereotypy: mechanizm rozszerzalności UML. Stereotypy są wykorzystywane do metaklasyfikacji elementów modelu.
Notacja: «nazwa stereotypu» lub ikona
Przykłady stereotypów:
P1
«include»
P2
P3
«extend»
P4
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 5
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
Osoba
O-Nowak : Osoba
nazwisko : string
wiek : integer
nazwisko = ” Nowak”
wiek = 35
klasyfikator
wystąpienie klasyfikatora
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 6
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:
klasyfikator
specjalizowany
klasyfikator
ogólny
Asocjacja: opisuje powiązania pomiędzy wystąpieniami klasyfikatorów (również
pomiędzy różnymi wystąpieniami tego samego klasyfikatora)
Notacja:
klasyfikator
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 7
klasyfikator
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:
klient
usług
dostawca
usług
Realizacja: to związek pomiędzy klasyfikatorami, gdzie jeden z klasyfikatorów
opisuje kontrakt, a drugi określa sposób realizacji tego kontraktu
Notacja:
klasyfikator określający
sposób realizacji kontraktu
klasyfikator
opisujący kontrakt
Jak?
Co?
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 8
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 9
Model analityczny
Model analityczny z reguły wykracza poza zakres odpowiedzialności systemu.
Przyczyny:
 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.
Dostępne środki mogą nie pozwolić na
realizację systemu w całości.
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 10
Dziedzina problemu
Model analityczny
Zakres
odpowiedzialności
systemu
Model wymagań
Składowe:  Model przypadków użycia
 Obiektowy model analityczny
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 11
Notacja
Wypłata
pieniędzy
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ę.
Klient
Weryfikacja
klienta
«include»
ud Obsługa klienta
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 12
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”.
(1) Czy system może być aktorem sam dla siebie? Aktor to przecież, zgodnie z
definicją, byt z otoczenia systemu.
(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?
(3) Aktor pasywny a interakcja z systemem ?
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 13
Analiza aktorów
Wyjaśnienie różnicy pomiędzy pojęciem „konkretny użytkownik” a
pojęciem „aktor”:
Konkretny
użytkownik
Przypadek użycia
Aktor
Może grać rolę
zleca
Jan Kowalski
Administrator systemu
Przeładowanie systemu
Adam Malina
Pracownik
Wejście z kartą i kodem
Konkretny gość
Osoba informowana
Konkretny klient
Klient
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 14
Uzyskanie
informacji ogólnych
Wypłata z konta
Wykorzystanie stereotypów dla aktorów
Aktor: człowiek,
grupa ludzi,
organizacja
«actor»
Klient
Aktor: system zewnętrzny
System
ubezpieczeń
Aktor: czas
1-szy dzień
roku
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 15
Klient
Klient
Przykład diagramu przypadków użycia (1)
?
Wpłata pieniędzy
Klient
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.
Wpłata pieniędzy
Klient
Kasjer
Wypłata pieniędzy
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 16
alternatywna notacja dla przypadków
użycia
Przykład diagramu przypadków użycia (2)
ud Automat do sprzedaży papierosów
Uzupełnienie
towaru
Zakup paczki
papierosów
Wykonanie operacji
pieniężnej
Operator
Klient
Sporządzenie
raportu
Kontroler
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 17
Liczność związków asocjacji
ud Automat do sprzedaży papierosów
Uzupełnienie
towaru
*
1
1
*
Zakup paczki
papierosów
*
Wykonanie operacji
pieniężnej
1
Operator
1
Klient
*
Sporządzenie
raportu
*
1
Kontroler
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 18
Oznaczanie kierunków interakcji
ud Automat do sprzedaży papierosów
Uzupełnienie
towaru
Zakup paczki
papierosów
Wykonanie operacji
pieniężnej
Operator
Klient
Sporządzenie
raportu
System
archiwizujący
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 19
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».
W obu poniższych diagramach P1, nazywane tu przypadkiem bazowym, zawsze
występuje jako pierwsze w kolejności działania.
Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa) P2, zwane tu
przypadkiem włączanym.
P1
«include»
P2
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.
P1
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 20
«extend»
P2
Relacje między przypadkami użycia (2)
Rejestracja
klienta
«include»
«include»
Przegląd
samochodu
Sprzedaż
samochodu
«include»
«extend»
Naprawa
samochodu
«extend»
«extend»
Umycie
samochodu
Przyholowanie
samochodu
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 21
«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
Relacje między przypadkami użycia (3)
Naprawa
samochodu
extension points:
Punkty rozszerzające
(extension points)
Umożliwiają podanie warunków
wymaganych do użycia przypadków
rozszerzających („opcjonalnych”).
Samochód poza warsztatem
Samochód wymaga przeglądu
«extend»
«extend»
extension point:
Samochód poza
warsztatem
extension point:
Samochód wymaga
przeglądu
Samochód jest brudny
Przyholowanie
samochodu
«extend»
extension point:
Samochód jest
brudny
Umycie
samochodu
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 22
Przegląd
samochodu
extension points:
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.
Złożenie zamówienia
Klient
«extend»
Dostawca
Realizacja zamówienia
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 23
Związek uogólnienia między aktorami (1)
Osoba
Pracownik
Księgowa
Gość
Pracownik
administracji
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 24
Związek uogólnienia między aktorami (2)
ud Automat do operacji bankowych
Podsystem
zarządzania bazą
danych banku
Obsługa
konta klienta
«include»
Informowanie o
stanie konta klienta
«include»
Klient
Inicjalizacja
karty klienta
Administrator
systemu
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 25
«include»
Weryfikacja karty
i kodu klienta
Związek uogólnienia między aktorami (3)
ud Automat do operacji bankowych
Podsystem
zarządzania bazą
danych banku
Obsługa
konta klienta
«include»
Informowanie o
stanie konta klienta
«include»
Klient
Inicjalizacja
karty klienta
Administrator
systemu
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 26
«include»
Weryfikacja karty
i kodu klienta
Rozbudowa modelu przypadków użycia
Wpłać
pieniądze
Wpłać
pieniądze
Kasjer
Kasjer
Wypłać
pieniądze
«include»
Wypłać
pieniądze
«extend»
«include»
Klient
banku
Klient
banku
Sprawdź
stan konta
Weź
pożyczkę
Zarząd
banku
Sprawdź
stan konta
Weź
pożyczkę
Uaktualnianie
stanu konta
Zarząd
banku
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 27
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.
Model zbyt szczegółowy − utrudnia analizę, zbyt ogólny − nie pozwala na wykrycie
bloków ponownego użycia.
Edycja
programu
«include»
Kompilacja
programu
Tworzenie przypadków użycia
jest niezdeterminowane i
subiektywne. Na ogół, różni
analitycy tworzą różne modele.
«include»
Wykonanie
programu
Programista
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 28
Drukowanie
pliku
Użytkownik
końcowy
Diagram kontekstowy
Podsystem
zarządzania bazą
danych banku
«system»
Automat do
operacji bankowych
Klient
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 29
Administrator
systemu
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.
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:
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 30
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 31
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 32
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:
1
Sporządzenie słownika pojęć
2
Określenie aktorów
3
Określenie przypadków użycia
4
Tworzenie opisu każdego przypadku
użycia plus:
 podział na nazwane części
 znalezienie wspólnych części w
różnych przypadkach użycia
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 33
Udokumentowany w:
Słownik pojęć
Dokument opisu aktorów
Diagram przypadków użycia +
dokument z opisem przypadków
użycia
Krok 1: sporządzenie słownika pojęć
 Ważnym jest, by już na tym etapie rozpocząć organizowanie 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.
Przykład:
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.
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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 34
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).
Po wyszukaniu aktorów, należy ustalić:
 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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 35
Krok 3: określanie przypadków użycia (1)
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
 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.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 36
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 Create Read Update Delete.
 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 37
Krok 4: dokumentowanie przypadków użycia
Dokumentacja przypadków użycia powinna zawierać:
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:






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.
3. Opis szczegółowy każdego przypadku użycia:
 scenariusz(e)
 specyfikację uczestniczących obiektów,
 diagram(y) interakcji.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 38
Diagram interakcji dla przypadku użycia (1)
Przesyłanie komunikatów pomiędzy obiektami:
Obiekt 1
Aktor
Obiekt 2
Obiekt 3
Obiekt 4
k1
k2
k3
czas
k4
k5
ki − komunikat, czyli polecenie wykonania operacji na obiekcie, do którego komunikat
jest wysyłany; komunikat nosi nazwę tej operacji
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 39
Diagram interakcji dla przypadku użycia (2)
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
wpłata
pieniędzy
:Formularz
:Klient
:Kasa
:Konto
wypełnij
podaj formularz
aktualizuj stan
zwiększ
bilans
wydaj
pokwitowanie
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 40
zwiększ
bilans
:Bank
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 41
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 42
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 43
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 44
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.
Ponadto, model przypadków użycia pozwala na:
 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.
Przypadki użycia powinny odwzorowywać strukturę systemu tak, jak tę
strukturę widzą przyszli użytkownicy systemu.
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 45
Przypadki użycia w analizie
Eksperci
Doświadczenie
w dziedzinie
przedmiotowej
Model
dziedziny
Model
analityczny
Przypadki
użycia
Użytkownicy
Analiza i Projektowanie Systemów Informatycznych, Wykład 1, Slajd 46
Model
zastosowania
mocny wpływ
słaby wpływ