Diagram przypadków użycia
Diagram przypadków użycia (Use Case
Diagram) ukazuje system z punktu widzenia
użytkownika.
Diagram przypadków użycia
• Diagram przypadków użycia (ang. Use Case Diagram) jest diagramem, który przedstawia
funkcjonalność systemu wraz z jego otoczeniem
• Diagramy przypadków użycia pozwalają na
graficzne zaprezentowanie własności systemu tak, jak są one widziane po stronie użytkownika
• Diagramy przypadków użycia służą do
zobrazowania usług, jakie są widoczne z zewnątrz
systemu
Diagram przypadków użycia
Diagramy przypadków użycia:
• specyfikują wymagania stawiane systemowi
• obrazują zachowanie systemu
• modelują otoczenie systemu
• nie definiują sposobu implementacji systemu
• opisują jedynie najważniejsze aspekty zachowania systemu
• nie są przesadnie szczegółowe
• są platformą do komunikacji analityka z klientem
Diagram przypadków użycia
Kluczowymi elementami są:
• aktorzy (actor)
• przypadki użycia (use case)
• związki (association)
Dodatkowo diagram może zwierać:
• notatki (note)
• ograniczenia (constraints)
Aktor
• Aktor (ang. Actor) jest funkcją, jaką pełni użytkownik w stosunku do systemu oraz przypadków użycia.
• Aktor reprezentuje spójny zbiór ról, które są
odgrywane przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem.
• Aktorem może być człowiek, urządzenie, inny system lub czas.
• Aktor nie musi być fizycznym obiektem. Istotne by pełnił określoną funkcję wobec systemu i
przypadku użycia, którego używa.
Aktor
Aktor to użytkownik lub inny system, który
wchodzi w interakcję z naszym systemem.
Aktor
• Aktorzy stanowią otoczenie systemu (nie są
częścią systemu)
• Aktor może aktywnie wymieniać informacje z systemem (dostarczać informacje i pobierać)
• Aktor może wywoływać akcje w systemie
• Aktorami mogą być:
człowiek
urządzenie
inny system
Aktor
Aktor reprezentuje rolę w jakiej człowiek,
inny system bądź urządzenie może się wcielić w interakcji z naszym systemem.
Jeden Kowalski
w wielu rolach
Aktor
Aktorzy mogą występować w zależności uogólnienie (generalization). Potomek dziedziczy całe zachowanie i znacznie po przodku.
Klient indywidualny i klient instytucjonalny są szczególnym
rodzajem
klienta.
Generalizacja
Student Użytkownik potomek przodek
Grot strzałki wskazuje na przodka (klasę ogólną)
Związek generalizacji to związek pomiędzy elementem ogólnym (nadklasa lub przodek) a specyficznym jego rodzajem zwanym podklasą lub potomkiem. Element specyficzny jest całkowicie zgodny z elementem ogólnym i zawiera dodatkową informację.
Egzemplarz elementu specyficznego może być użyty wszędzie tam,
Potomek zawsze może zastąpić przodka
Aktor
Pojazd Uogólnienie
Człowiek
ogólnie
Przypadek użycia
• Przypadek użycia (PU) jest graficzną reprezentacją wymagań funkcjonalnych
• Definiuje zachowanie systemu bez
informowania o wewnętrznej strukturze i narzucania sposobu implementacji
• Przypadek użycia pozwala na zdefiniowanie przyszłego, spodziewanego zachowania
systemu Dodaj słuchacza
Przypadek użycia
• Kwant funkcjonalności systemu
dostarczający aktorowi usług o mierzalnej wartości (I. Jacobson).
• Czynność, której wykonanie bezpośrednio świadczy o efektywności pracy
• Nazwana lub dobrze określona interakcja pomiędzy użytkownikiem a systemem
komputerowym
Przypadek użycia
• Przypadek użycia musi być w interakcji,
chociaż z jednym aktorem. Wyjątek stanowi sytuacja, gdy przypadek użycia jest
połączony z innym przypadkiem użycia związkiem rozszerzenie lub zawierania.
• Przypadek użycia to zbiór scenariuszy
powiązanych ze sobą wspólnym celem
użytkownika. Sprawdź ocenę
Przypadek użycia
Przypadek użycia opisuje, co system robi, lecz
nie określa, jak to robi.
Przypadek użycia
Przypadek użycia to opis zbioru akcji wykonywanych przez system w celu dostarczenia aktorowi wyniku.
W UML przypadek użycia jest przedstawiony
w postaci elipsy z nazwą po środku.
Przypadek użycia
Elementy żyjące wewnątrz systemu (przypadki użycia) są odpowiedzialne za wykonanie
działań, których elementy zewnętrzne (aktorzy) oczekują od systemu.
Nazwa przypadku użycia musi być czynnością.
Przypadek użycia
Budując model należy pamiętać o oddzieleniu
pojęć – tego, co dotyczy pracy systemu, od tego,
co dotyczy jego realizacji.
Związki
Związki w diagramach przypadków użycia:
• powiązania (tylko między aktorem a przypadkiem użycia)
• uogólnienia
• zawierania – include
• rozszerzenia - extend
Związki
Związek zawierania stosuje się w celu
uniknięcia wielokrotnego opisywania tego samego ciągu zdarzeń.
Przyjmij towar... zawsze zawiera Czytaj kod...
<< include >>
Związek zawierania
Bazowy PU include Zawierany PU
Zobacz prezentację
Wysłuchaj wykładu include
Związek zawierania (ang. Include) polega na tym, że bazowy przypadek użycia rozszerza swoją funkcjonalność o
zachowanie innego przypadku użycia. Zawierany przypadek
użycia nie jest autonomiczny.
Związki
Związek rozszerzenia służy do modelowania fragmentów przypadku użycia postrzeganych przez użytkownika jako opcjonalne zachowanie systemu.
Ekspresowa... opcjonalnie rozszerza Przesyłkę...
<< extend >>
Bazowy PU extend Rozszerzający PU
Wykonaj ćwiczenie
Wysłuchaj wykładu extend
Związek rozszerzania (ang. Extend) wskazuje, że dany przypadek użycia opcjonalnie rozszerza funkcjonalność bazowego przypadku użycia. Funkcjonalność bazowego
przypadku użycia jest rozszerzana o inny przypadek użycia po spełnieniu określonego warunku.
Związek rozszerzania
Student Użytkownik
Związek zawierania i rozszerzania
Sprawdź ocenę
Zobacz zaległości finansowe
Wyświetl
wszystkie oceny
extend include
Extension points
Extension Points pozwalają na dokładniejsze
określenie jakie rozszerzające przypadki użycia
mają być wywołane.
Punkt rozszerzania
Punkt rozszerzania (extension points)
wskazuje na to miejsce w zachowaniu (scenariuszu) przypadku użycia, które jest rozszerzone o inny przypadek użycia za pomocą związku
rozszerzenia.
Przelicz kwotę zamówienia
Złóż zamówienie
Extension points wymagana zmiana waluty
extend
Extension points
Rozszerzający przypadek użycia
Warunek rozszerzenia
Miejsce rozszerzenia
Pakiety
Pakiety pomagają dzielić usługi
(przypadki użycia)
logicznie w systemie.
Diagram przypadków użycia
Siec telefonii komorkowej
Zainicjuj polaczenie
Zaakceptuj polaczenie
Uzyj programu
Zainicjuj
telekonferencje
Zaakceptuj dodatkowe polaczenie
<< extend >>
<< extend >>
Granica systemu
Diagram przypadków użycia
Dobre rady przy budowaniu diagramu:
• nazwij diagram zgodnie z przeznaczeniem
• tak rozmieść przypadku użycia i aktorów żeby zminimalizować liczbę przecinających się
związków
• poukładaj przypadki użycia blisko siebie, które są podobne pojęciowo
• korzystaj z notatek
• nie musisz przedstawiać wszystkich
Diagram przypadków użycia
• Przypadki użycia służą do modelowania oczekiwanego zachowania systemu (bez zgłębiania sposobu implementacji systemu) .
• Dobrze zbudowane przypadki użycia
reprezentują jedynie najważniejsze aspekty
zachowania systemu (nie są przesadnie szczególne
ani zbyt ogólne) .
Diagram przypadków użycia
Diagram przypadków użycia
Siec telefonii komorkowej
Uzytkownik
Zainicjuj polaczenie
Zaakceptuj polaczenie
Uzyj programu wybierajacego
Zainicjuj
telekonferencje
Zaakceptuj dodatkowe polaczenie
<< extend >>
<< extend >>
Telefon komorkowy
uc Use Case View
Dziekan
Student
Wykładow ca
Zatw ierdź sylabus
Napisz sylabus
Zobacz prezentację
Wysłuchaj w ykładu
Wykonaj ćw iczenia Napisz plan
w ykładów
warunek:
{standard nauczania wymaga ćwiczeń}
«include»
«include»
«extend»
Zarządzanie uczelnią
Model przypadków użycia
Model przypadków użycia opisuje wymagania funkcjonalne względem
systemu z wykorzystaniem przypadków
użycia
Specyfikacja przypadku użycia
• Nazwa
• Opis
• Przebieg zdarzeń
• Diagram czynności
• Diagram przypadków użycia
• Wymagania specjalne
• Warunki początkowe
• Warunki końcowe
Student
Rejestracja na kurs
Katalog kursów
Use Case może mieć wiele instancji
Scenariusz opisuje instancje użycia Use Case: określa sekwencję akcji ilustrujących zachowanie systemu.
Scenariusze Use Case
Model przypadków użycia
• Definiowanie zakresu systemu
• Diagramy przypadków użycia
• Aktorzy i przypadki użycia
• Scenariusze – definiowanie przypadków użycia
• Diagramy czynności
System biznesowy i system informatyczny
• Budowany system informatyczny będzie działał w ramach określonej organizacji. Będzie zatem
fragmentem działalności (biznesu), jaki prowadzi ta organizacja.
• Zanim określimy sposób działania systemu
informatycznego należy dobrze poznać działanie biznesu go otaczającego. W tym celu można
stworzyć model całego systemu biznesowego.
• Istotnym ułatwieniem jest zachowanie spójności
między modelem systemu biznesowego i systemu
informatycznego.
System biznesowy i system informatyczny
• System biznesowy: zbiór procesów, czynności i ich wykonawców które stanowią spójną całość i udostępniają pewne usługi dla innych systemów biznesowych.
• System informatyczny: zbiór elementów (sprzętu komputerowego i oprogramowania) o
zdefiniowanym sposobie działania, które stanowią spójną całość i udostępniają pewne usługi dla
systemu biznesowego.
Opłacenie podatku od środków transportu
Zgłoszenie
sprzedaży pojazdu
Rejestracja pojazdu
System
Obsługi
Rejestracji
Granice systemu, granice firmy
• Modelując świat możemy określić dwie granice:
– Granicę między opisywanym fragmentem
rzeczywistości (systemem biznesowym) a jego zewnętrzem.
– Granice między budowanym systemem informatycznym a jego zewnętrzem.
• W modelu przypadków użycia, aktorzy znajdują
się na zewnątrz granicy. Sposób zachowania się
wnętrza systemu określają przypadki użycia.
Raport miesięczny
Zgłoszenie
sprzedaży pojazdu
Rejestracja pojazdu
Wydział
komunikacji
System Obsługi Rejestracji
Naczelnik
Właściciel
Rejestrator
Zakres systemu informatycznego
• Jednym z podstawowych celów modelowania jest określenie zakresu budowanego systemu.
• Zakres systemu stanowi odpowiedź na dwa pytania:
– Z kim system ma współpracować?
– Co system ma robić?
• Obiekty, z którymi współpracuje system to autorzy.
• Możliwe sposoby współpracy aktorów z systemem to przypadki użycia.
• Identyfikacja wszystkich aktorów i wszystkich
przypadków użycia określa zakres systemu.
Opłacenie podatku od środków transportu
Zgłoszenie
sprzedaży pojazdu
Rejestracja pojazdu
System Obsługi Rejestracji
Rejestrator
Modelowanie przypadków użycia - diagramy
• Na diagramach przypadku użycia:
– Grupujemy przypadki użycia
– Opisujemy zależności zachodzące pomiędzy aktorem a przypadkiem użycia oraz przypadkami użycia
• Celem diagramu jest:
– Pokazywanie ogólnej funkcjonalności systemu
– Uwidocznienie jaki aktor wykonuje jakie scenariusze – Pokazanie powiązań pomiędzy poszczególnymi
fragmentami funkcjonalności systemu
uc Use Case View
Zarządzaj ący zbiorami
Wypożyczający
System biblioteki głów nej wprow adź nowy
egzemplarz
dodaj istniejący egzemplarz
w yszukaj książkę rejestruj rezerw acj ę
rejestruj rezerw acj ę zdalnie
«extend»
«include»
«include»
Diagram przypadków użycia
Scenariusze (przebieg zdarzeń)
• Jeden i tylko jeden przebieg podstawowy
• Dowolna liczba przebiegów alternatywnych
– Nie standardowe zachowanie
– Obsługa sytuacji awaryjnych
– Obsługa błędów
Scenariusze (przebieg zdarzeń)
• Scenariusz jest instancją przypadku użycia
• Scenariusz może być przedstawiony za pomocą diagramów aktywności (lub
sekwencji)
Scenariusze przypadków użycia
• Specyfikując przypadek użycia (biznesowy czy
systemowy) musimy określić sekwencję czynności wykonywanych w ramach tego przypadku użycia.
• Sekwencja składa się z:
– Interakcji aktora z systemem (z wyróżnionym aktorem głównym)
– Akcje podejmowanych przez system w odpowiedzi na te interakcje
• Taką sekwencję nazywamy scenariuszem.
Rodzaje scenariuszy w PU
• Przypadek użycia może składać się z kilku scenariuszy
• Scenariusze w przypadku użycia możemy podzielić na:
• Scenariusz główny
• Scenariusze alternatywne
• Scenariusz główny – podstawowy przebieg przez przypadek użycia
• Scenariusze poboczne (alternatywne) – inne przebiegi przez przypadek użycia. Niektóre zdarzenia mogą
prowadzić w różnych kierunkach w zależności od decyzji
użytkownika lub stanu systemu.
Zasady pisania scenariuszy
• Gramatyka SVD(PI)
• Scenariusze w formie tekstowej powinny być pisane prostym i jednoznacznym językiem. Można np. zastosować gramatykę umożliwiającą budowanie zdań składających się jedynie z:
– Podmiotu (S) – nazwa aktora lub słowo „System”
– Orzeczenie (V) – nazwa czynności wykonywanej przez podmiot – Dopełnienie (D) – nazwa obiektu, który podlega czynności
– Przyimka (P) – „na”, „w”, itp.
– Dopełnienia dalszego (I) – opcjonalna nazwa innego obiektu
• System umieszcza dane klienta na liście klientów
• Sprzedawca wprowadza kod produktu
Scenariusz główny
Scenariusz główny określa przebieg przypadku użycia prowadzący do uzyskania oczekiwanego rezultatu.
Dokonanie rejestracji – operacja będąca elementem interfejsu użytkownika
1. Wypożyczający zgłasza chęć dokonania rejestracji 2. Wypożyczający wprowadza dane klienta
3. System stwierdza nie przekroczenie limitu wypożyczonych książek
4. System stwierdza nie zaleganie ze zwrotem książek
5. Wypożyczający wprowadza dane książki dla wypożyczenia 6. System stwierdza posiadanie książki przez bibliotekę
7. System stwierdza możliwość wypożyczenia egzemplarza książki
8. System podaje informację o wypożyczeniu
uc obsługa realizacj i szkoleń
System obsługi szkoleń
Koordynator szkoleń (from Aktorzy)
Trener (from Aktorzy) (from Obsługa realizacji szkoleń)
Rej estruj Trenera
(from Obsługa realizacji szkoleń) Przej rzyj moj e
szkolenia
(from Obsługa realizacji szkoleń) Przypisz zasoby
do szkolenia
Oceń zrealizow ane
(from Obsługa realizacji szkoleń) Przypisz Trenera
do szkolenia
Wprow adź dane uczestnika
(from Obsługa realizacji szkoleń) Przej rzyj listę
uczestników przypisanych do
szkolenia
Prezentuj informacj ę o
szkoleniu
Prezentuj informacj e o
Prezentuj informacj e o
szkoleniu otw artym Przypisz
uczestnika do szkolenia
Abstrakcyjny przypadek użycia. Nie jest implementowany w systemie niemniej jednak jego istnienie można zaznaczyć w
«include»
«extend»
«extend»
«include»
«include»
«include»
