Inżynieria - bks.uniwersytetradom.pl przypadkow.pdf · Inżynieria oprogramowania ... systemów...
Transcript of Inżynieria - bks.uniwersytetradom.pl przypadkow.pdf · Inżynieria oprogramowania ... systemów...
Inżynieria
oprogramowania
Wprowadzenie do Unified Modeling Language.
Diagramy przypadków życia
dr Beata Kuźmińska-Sołśnia
Wprowadzenie
Czym jest model?
Model to „układ (...) możliwie mało skomplikowany,
działający analogicznie do oryginału”
- Słownik Języka Polskiego, PWN 1998
Model
Świat
rzeczywisty
System
komputerowy
Analiza i modelowanie
systemów
Elementy świata i modelu
użytkownicy, systemy zewnętrzne;
dane, ich struktura, sposób przetwarzania, zależności
statyczne i dynamiczne;
procesy, ich struktura i rozmieszczenie;
....
Metodyka modelowania
jest opisem czynności, sposobu i kolejności ich realizacji;
czynności te mają prowadzić ku MODELOWI, zapewniając
jednocześnie metody utrzymania wysokiej jakości
(spełnienia wymagań użytkownika)
Istota modelowania
Czym jest analiza? „analiza to studium problemu przed podjęciem działania”
Tom DeMarco, 1978
Sposoby zarządzania złożonością: abstrakcja: omijanie rzeczy nieistotnych
hermetyzacja: ukrywanie rzeczy złożonych
dziedziczenie: uogólnianie wspólnych cech
kojarzenie: porównywanie analogii
komunikacja: jak porozumiewają się elementy modelu
skalowanie: dopasowanie opisu do rozmiaru problemu
klasyfikacja: grupowanie zachowań elementów modelu.
Cele modelowania
1. divide et impera, czyli dekompozycja
2. łatwiejsze wyobrażenie systemu
3. specyfikacja struktury i zachowania
4. dokumentacja decyzji podjętych w trakcie
realizacji
Cztery zasady modelowania
1. Dobór modelu ma istotny wpływ na końcowy produkt -
Różne sposoby postrzegania rzeczywistości prowadzą do
różnych rozwiązań
2. Każdy model można przedstawić na różnych poziomach
szczegółowości. Wybór poziomu zależy od celu
3. Model powinien być dobrą abstrakcją rzeczywistości
4. System powinien być opisany przez kilka spójnych
i komplementarnych modeli. Do różnych celów potrzebne
są modele o różnym poziomie szczegółowości
W świecie obiektowym
Elementy świata
świat składa się z obiektów
procesy i dane są zintegrowane
Komunikacja między nimi
obiekty komunikują się za pomocą przekazywania
zdarzeń
Wzrost znaczenia obiektowości
wyzwania postępu technologicznego w informatyce, polegające na coraz bardziej powszechnym użytkowaniu systemów czasu rzeczywistego i systemów wbudowanych
różnorodność i powszechność aplikacji internetowych w gospodarce opartej na wiedzy, czyli w takich dziedzinach jak e-business, e-health, e-government, e-learning
multimedialny charakter aplikacji, wykorzystujących w coraz większym stopniu dźwięk, głos, grafikę, film
globalizacja gospodarki, a zatem integracja systemów informatycznych - w telekomunikacji, bankowości, edukacji, turystyce, transporcie
powszechność i dostępność aplikacji, zwłaszcza internetowych, dla potrzeb społeczeństwa informacyjnego
Podejście obiektowe
w zastosowaniach
metodykach tworzenia oprogramowania (przede
wszystkim Rational Unified Process)
graficznych językach ogólnego przeznaczenia (UML)
obiektowych językach programowania (JAVA,
platforma .NET)
bazach danych (np. ObjectStore)
Podstawowe pojęcia obiektowości
Obiekt (object) – reprezentacja konkretnego elementu świata, posiadająca pewne cechy i oferująca pewne usługi
Klasa (class) – Uogólnienie zbioru obiektów, które mają takie same atrybuty, operacje, związki i znaczenie (zbiór obiektów podobnych lub o wspólnych cechach)
Komunikat (message) – specyfikacja wymiany informacji między obiektami, zawierająca zlecenia wykonana określonej operacji
Podstawowe pojęcia obiektowości
Hermetyzacja (encapsulation) – różnicowanie dostępu do obiektu
poprzez ujawnienie otoczeniu tylko tych informacji o jego atrybutach
lub operacjach, które są niezbędne do efektywnego odwoływania się
do obiektu w systemie za pośrednictwem komunikatu
Polimorfizm (polymorphism) - możliwość nadawania tej samej nazwy
różnym atrybutom i operacjom oraz wykonywania różnych procedur
i akcji poprzez operacje o tych samych nazwach; pozwala na redukcję
liczby nazw atrybutów i operacji
Dziedziczenie (inheritance) - przyporządkowanie atrybutów
i operacji klasom obiektów na podstawie hierarchicznej zależności
między nimi. Możliwe jest wielokrotne dziedziczenie, co oznacza, że
dana klasa dziedziczy atrybuty i operacje z dowolnej liczby klas
nadrzędnych
Czym jest UML?
Metodyką
- UML nie określa metody
modelowania
- zaleca jedynie stosowanie
podejścia przyrostowego
Narzędziem
- UML to specyfikacja
dla narzędzi
Językiem programowania
- Generowanie kodu
z modelu stosowane
obecnie na niewielką skalę
Notacją graficzną
- UML określa sposób
zapisu modeli
UML nie jest UML jest
Czym jest UML?
UML oznacza Ujednolicony Język Modelowania
(Unified Modelling Language)
UML jest językiem wizualizacji, specyfikacji,
konstrukcji i dokumentacji artefaktów związanych
z tworzeniem oprogramowania
Model UML jest wypadkową wielu widoków
różnych aspektów systemu
UML abstrahuje od obiektu modelowania
i metodologii modelowania
UML ma być:
Gotowy do użytku
Ekspresywny
Prosty
Precyzyjny
Rozszerzalny
Niezależny od implementacji
Niezależny od procesu
UML - historia
niezależne notacje
modelowania:
Booch, Coad/Yourdon,
OMT, OOSE, Fusion
OOPSLA 1995:
wesja 0.8 Metody Zunifikowanej
(Booch & Rumbaugh, Rational
Software), dołącza Jacobson
Włącznie się do
prac OMG
UML 1.0 (Rational
Software) i UML 1.1
(OMG)
UML 1.3
UML 1.5
UML 2.0
UML 2.1
ok. 1990 1995 1996 1997 2000 2003 2004 2006/07
Język UML powinien
w sposób ścisły definiować podstawowe i zaawansowane kategorie oraz zasady modelowania obiektowego
umożliwiać dostosowywanie wykorzystywanej semantyki i notacji do rozwiązywania szerokiego spektrum problemów
wykazywać elastyczność wystarczającą do modelowania, obok systemów oprogramowania, także systemów biznesowych
wykazywać daleko posuniętą niezależność od konkretnych języków programowania oraz metodyk tworzenia systemów informatycznych
uwzględniać skalę realizowanych współcześnie projektów, związanych z bardzo rozbudowanymi systemami o kluczowym znaczeniu dla funkcjonowania przedsiębiorstw
Zakres UML
Skupiono się na standardzie języka do modelowania a nie na standardzie procesów tworzenia oprogramowania
Wysiłek autorów jest skoncentrowany na stworzeniu wspólnego metamodelu i wspólnej notacji
Promowany jest proces:
ukierunkowany na przypadki użycia systemu
skoncentrowany na architekturze
iteracyjny i przyrostowy
Zakres UML c.d.
Bloki konstrukcyjne – elementy
strukturalne (np. przypadki użycia, klasy, interfejsy, komponenty, węzły…)
czynnościowe (np., interakcja i maszyna stanowa)
grupujące (pakiety)
komentujące (notatki)
Związki (zależności, powiązania, uogólnienia, realizacje)
Diagramy
struktury
zachowania
UML – dwa podstawowe elementy
Notacja – istotna z punktu widzenia modelowania
elementy graficzne
składnia języka modelowania
istotna przy szkicowaniu modeli
Metamodel - istotny z punktu generacji kodu
definicje pojęć języka i powiązania pomiędzy nimi
istotny przy graficznym modelowaniu
Diagramy UML 2.0
Diagram struktury Diagram
zachowania (dynamiki)
Diagram klas
Diagram
pakietów
Diagram
obiektów
Diagram
struktur
połączonych
Diagram
wdrożeniowy
Diagram
komponentów
Diagram
rozlokowania
Diagram
przypadków
użycia
Diagram
czynności
Diagram maszyny
stanowej
Diagram
interakcji
Diagram sekwencji
Diagram
harmonogramowania
Diagram
komunikacji
Diagram
sterowania
interakcją
Charakterystyka diagramów
Diagram klas (Class Diagram)
kls / cld
Graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi
Diagram obiektów (Object Diagram)
obk / od
Wystąpienie diagramu klas, odwzorowujące strukturę systemu w wybranym momencie jego działania
Diagramy struktury
Charakterystyka diagramów
Diagram struktur połączonych
(Composite Structure Diagram)
spl / csd
Graficzne przedstawienie wzajemnie współdziałających części dla osiągnięcia pożądanej funkcjonalności współdziałania
Diagram pakietów (Packade Diagram)
pkt / pd
Graficzne przedstawienie logicznej struktury w postaci zestawu pakietów połączonych zależnościami i zagnieżdżeniem
Diagramy struktury
Charakterystyka diagramów
Diagram
rozlokowania
(Deploymet Diagram)
rzk / dd
Rodzaj diagramu wdrożeniowego, który
przedstawia sieć połączonych ścieżkami
komunikowania węzłów z ulokowanymi
na nich artefaktami
Diagram komponentów
(Component Diagram)
kmp / cod
Rodzaj diagramu wdrożeniowego, który wskazuje organizację i zależności między komponentami
Diagram wdrożeniowy
Charakterystyka diagramów
Diagram czynności
(Activity Diagram)
czn / ad
Graficzne przedstawienie sekwencyjnych
i (lub) współbieżnych przepływów sterowania
oraz danych pomiędzy uporządkowanymi
ciągami czynności, akcji i obiektów
Diagram przypadków użycia (Use Case Diagram)
uzc / ud
Graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej
Diagramy zachowania
Diagram maszyny stanowej
(Stare Machine Diagram)
stn / sm
Graficzne odzwierciedlenie dyskretnego, skokowego zachowania skończonych systemów stan-przejście
Charakterystyka diagramów
Diagramy interakcji
Diagram
komunikacji
(Communication
Diagram)
kmn / cd
Rodzaj diagramu interakcji, specyfikujący
strukturalne związki pomiędzy instancjami
klasyfikatorów biorącymi udział w interakcji
oraz wymianę komunikatów pomiędzy tymi
instancjami
Diagram sekwencji
(Sequence Diagram)
skw / sd
Rodzaj diagramu interakcji, opisujący interakcje pomiędzy instancjami klasyfikatorów systemu w postaci sekwencji komunikatów wymienianych między nimi
Charakterystyka diagramów
Diagramy interakcji
Diagram sterowania
interakcją
(Interaction Overview
Diagram)
sin / iod
Rodzaj diagramu interakcji, dokumentujący
przepływ sterowania pomiędzy logicznie
powiązanymi diagramami i fragmentami
interakcji z wykorzystaniem kategorii
modelowania diagramów czynności
Diagram harmonogramowania
(Timing Diagram)
hrm / td
Rodzaj diagramu interakcji, reprezentujący na osi czasu zmiany dopuszczalnych stanów, jakie może przyjmować instancja klasyfikatora uczestnicząca w interakcji
Język UML
Klasyfikator to abstrakcyjna kategoria modelowania systemu w języku UML, która uogólnia kolekcję instancji o tych samych cechach
Instancja jest wystąpieniem, egzemplarzem klasyfikatora
Klasyfikator ustrukturyzowany zawiera
specyfikację wewnętrznej struktury. Pojęcie to
odnosi się do diagramów struktur połączonych
Diagramy mogą być w postaci
Obramowanej - diagram w postaci
obramowanej otoczony jest
prostokątną ramą (ang.frame)
zawierającą nagłówek
nagłówek
Merytoryczna
zawartość diagramu
rama
<nagłówek-diagramu> ::= [<rodzaj>] <nazwa> [<parametry>]
rodzaj - pełny lub skrótowy wyróżnik diagramu zawartego w ramie; nazwa - syntetyczna nazwa odzwierciedlająca merytoryczną zawartość
diagramu; parametry - szczegółowe parametry kluczowe dla danego diagramu, np.
nazwy instancji klasyfikatorów, wartości zwrotne, operatory interakcji.
Nieobramowanej
Perspektywy w opisie
architektury systemu
perspektywa przypadków użycia - kluczowa i dominująca wobec pozostałych, definiuje zakres i oczekiwaną funkcjonalność tworzonego systemu;
perspektywa dynamiczna - wskazuje, w jaki sposób jest realizowane zachowanie instancji klasyfikatorów w systemie;
perspektywa logiczna - dokumentuje statykę systemu;
perspektywa komponentów - przeznaczona głównie dla programistów, specyfikuje oprogramowanie na poziomie komponentów;
perspektywa rozlokowania - specyfikuje sprzęt informatyczny niezbędny do funkcjonowania konkretnych komponentów systemu.
Modelowanie perspektyw architektury systemu
Perspektywa dynamiczna
(Dynamic View)
Perspektywa logiczna
(Logical View)
Perspektywa przypadków
użycia
(Use Case View)
Perspektywa komponentów
(Implementation View)
Perspektywa rozlokowania
(Deployment View)
Diagram klas Diagram obiektów Diagram struktur połączonych Diagram pakietów
Diagram interakcji Diagram czynności Diagram maszyny stanowej Diagram struktur połączonych Diagram pakietów
Diagram przypadków użycia Diagram pakietów
Diagram rozlokowania Diagram pakietów
Diagram komponentów Diagram pakietów
Stereotyp
Stereotyp to mechanizm rozszerzalności, który wzbogaca
zbiorowość standardowych kategorii modelowania języka UML
Stereotypy
Tekstowe
• pakietów jest «subsystem»,
• związku zależności - «include» czy też «extend»,
• komponentu - «file».
Graficzne
• mają domyślnie postać specyficznych symboli graficznych
umieszczanych na stereotypowanych elementach
Ograniczenie
Ograniczenie to wyrażenie semantyczne określające
warunek bądź zastrzeżenie związane z ograniczanym
elementem modelowania bądź grupą elementów
Ograniczenie jest w istocie tekstem wyrażonym w języku
naturalnym, formułą matematyczną, predykatem logiki
formalnej bądź instrukcją pseudokodu
Ograniczenia umieszczane są w nawiasach klamrowych
w bezpośrednim sąsiedztwie elementu lub elementów,
których znaczenie jest precyzowane;
np. {disjoint}
{czas < 15 min}.
Metka
Metka stanowi jawne zdefiniowanie właściwości w postaci przyporządkowania nazwawartość
Najpowszechniej metki stosuje się celem określenia właściwości istotnych w generowaniu kodu oraz zarządzaniu konfiguracjami;
np. {wersja = beta}
{model = HP LaserJet 1500L}
Diagramy przypadków
użycia
Diagram przypadków użycia to
graficzne przedstawienie
przypadków użycia, aktorów oraz
związków między nimi,
występujących
w danej dziedzinie przedmiotowej
Znaczenie diagramów
przypadków użycia
Celem podstawowym jest identyfikacja i dokumentacja wymagań
Zadania powiązane z celem głównym umożliwiają analizę obszaru zastosowań, dziedziny
przedmiotowej;
pozwalają na opracowanie projektu przyszłego systemu;
stanowią przystępną i zrozumiałą platformę komunikacji i współpracy udziałowców (ang. stakeholders) systemu - aktorów, twórców systemu, inwestorów i właścicieli
są rodzajem umowy, kontraktu pomiędzy udziałowcami co do zakresu i funkcjonalności przyszłego systemu
stanowią podstawę testowania funkcji i systemu na dalszych etapach jego cyklu życia.
Podstawowe kategorie pojęciowe
oraz notacja graficzna
Przypadki użycia
Aktorzy
Związki
Kategorie te w każdym diagramie są ze sobą
ściśle powiązane
Przypadek użycia
Przypadek użycia to specyfikacja ciągu akcji i ich wariantów, które system (lub inna jednostka) może wykonać poprzez interakcje z aktorami tego systemu
Przypadek użycia (ang. use case) jest więc kompleksowym działaniem realizowanym w systemie w konsekwencji określonej aktywności aktora (ang. actor)
Nazwę przypadku użycia stanowi zwięzłe polecenie wykonania funkcji w projektowanym systemie, sformułowane w trybie rozkazującym
Rezerwuj
wycieczkę Sprzedaj towar
Oznaczenia przypadków użycia
Przypadek użycia
Alternatywne notacje przypadków użycia
Rezerwuj wycieczkę Sprzedaj towar
Rezerwuj wycieczkę Sprzedaj towar
Aktor
Aktor jest to spójny zbiór ról odgrywanych przez
użytkowników przypadku użycia w czasie interakcji
z tym przypadkiem użycia
Podstawowe rodzaje aktorów
Konsultant System rezerwacji miejsc hotelowych
Dział sprzedaży
Bank hipoteczny Termin płatności Nagrywarka DVD-RAM
Związek
Związek stanowi semantyczne powiązanie
pomiędzy elementami modelu
W diagramach języka UML wyróżnić można
cztery rodzaje związków:
asocjację
uogólnienie
zależność
realizację
Asocjacja
Asocjacja jest związkiem pomiędzy dwoma lub więcej klasyfikatorami, opisującym powiązania pomiędzy ich instancjami
W diagramach przypadków użycia asocjacja wskazuje zatem domyślnie na dwukierunkową komunikację pomiędzy aktorem a przypadkiem użycia
Może ona dodatkowo występować w formie ze wskazaniem kierunku nawigacji
Klient
Rezerwuj
wycieczkę
Związki asocjacji w diagramie przypadków użycia
Zweryfikuj
wiarygodność
płatności System obsługi kart
kredytowych
Podstawowe elementy diagramów przypadku użycia
nazwa pojęcia notacja graficzna
Przypadek użycia
Aktor
Asocjacja
Diagram przypadków użycia
aukcji internetowej
Serwis transakcji
Dokonaj
rejestracji
Licytuj
Wyszukaj
artykuł
Dokonaj
transakcji
Uczestnik
Obserwator
DPU system obsługi hurtowni
Przyjmij dostawę
towarów
Wydaj towar
Generuj zestawienie
obrotów
Generuj zestawienie
sprzedaży miesięcznej Magazyn
Kierownik magazynu
Generuj zestawienie
zapasów Wystaw fakturę
Dział sprzedaży
System obsługi hurtowni
Zaawansowane składniki
diagramu
rozbudowa DPU poprzez zróżnicowanie związków
zależność zawierania
zależność rozszerzania
uogólnienie
rodzaje aktorów
liczebność
nawigacja
realizacja
przypadki użycia typu CRUD
diagram kontekstowy
dokumentacja przypadków użycia
Rozbudowa DPU poprzez
różnicowanie związków
Asocjacja to podstawowy rodzaj związku wykorzystywany w konstruowaniu diagramów przypadków użycia
Poza nią na diagramach przypadków użycia modelować można związki zależności, uogólnienia i realizacji
Porządkującą rolę mogą odegrać tu diagramy pakietów, przedstawione.
Szczególne możliwości rozbudowywania diagramów przypadków użycia stwarzają zależności (ang. dependencies)
Zależności zawierania, rozszerzania
Zależność to taki związek pomiędzy dwoma elementami modelowania,
w którym zmiana jednego z nich, niezależnego, wpływa na drugi, zależny
Zależności zawierania
Sens tworzenia zależności zawierani na diagramie przypadków użycia występuje w dwóch sytuacjach:
istnieje możliwość wydzielenia w formie zawieranego przypadku użycia pewnej spójnej, wspólnej dla kilku innych przypadków użycia funkcjonalności; jest to przykład praktycznego zastosowania zasady ponownego użycia - nie zachodzi konieczność powielania analogicznej treści w wielu przypadkach użycia; tym samym często występująca funkcjonalność jest reprezentowana jednokrotnie na diagramie i wykorzystywana przez inne przypadki użycia
interakcje aktor-system wyrażone w dokumentacji scenariusza tego przypadku są bardzo liczne
Dokonaj
rezerwacji
Sprawdź listę
dostępnych pokoi «include»
Zależności rozszerzania
Zależność rozszerzania «extend» przedstawia powiązanie pomiędzy rozszerzanym przypadkiem użycia, tj. przypadkiem bazowym, a przypadkiem rozszerzającym. Związek ten, w odróżnieniu od zależności zawierania, ma charakter opcjonalny
Tworzenie zależności rozszerzania znajduje uzasadnienie, o ile funkcjonalność reprezentowana przez rozszerzany przypadek użycia ma zostać uzupełniona o kilka dodatkowych kroków. Nie mają one być jednak automatycznie wykonywane przy każdym odwołaniu do tego
przypadku użycia, a jedynie w określonych sytuacjach.
Sprawdź listę
dostępnych pokoi Zarządzaj pokojami
«extend»
Różne rodzaje zależności
stereotypowanych
Dokonaj
rezerwacji
Sprawdź listę
dostępnych pokoi «include»
Zarządzaj pokojami
Przekaż rezerwację
centrali sieci
«extend»
«extend»
Miejsca rozszerzenia
w przypadku użycia
Sprawdź listę dostępnych pokoi
Miejsca rozszerzenia: Modyfikacja danych o pokojach Brak pokoi spełniających kryteria
Zarządzaj pokojami Przekaż rezerwację
centrali sieci
«extend» «extend»
Miejsca rozszerzenia
- notacja alternatywna
Sprawdź listę dostępnych pokoi
Miejsca rozszerzenia: Modyfikacja danych o pokojach Brak pokoi spełniających kryteria
Zarządzaj
pokojami
Przekaż rezerwację
centrali sieci «extend»
«extend»
Notatki w opisie miejsc
rozszerzeń
Miejsce rozszerzenia: modyfikacja danych o pokojach
Sprawdź listę
dostępnych pokoi
Zarządzaj
pokojami
Przekaż rezerwację
centrali sieci
Miejsce rozszerzenia: brak pokoi spełniających kryteria
«extend»
«extend»
Uogólnienia
Związki uogólnienia (ang. generalizations) dotyczą w kontekście charakteryzowanego diagramu zarówno przypadków użycia, jak i aktorów
Uogólnienie to związek o charakterze taksonomicznym pomiędzy klasyfikatorem ogólnym a specjalizowanym
Pracownik hotelu
Recepcjonista
Kierownik restauracji
hotelowej
Sporządź raport
Sporządź raport
sprzedaży
Sporządź raport
o reklamacjach
a b
Hierarchia dziedziczenia wyrażona
poprzez związki uogólnienia
System obsługi płatności
System obsługi płatności
gotówkowych
System obsługi płatności
bezgotówkowych
System obsługi
kart kredytowych
System rejestracji
przelewów
Rodzaje aktorów
Stereotypy graficzne aktorów
Klasyczna reprezentacja -
człowiek
System zewnętrzny
Urządzenie Czas
Zastosowanie stereotypów
graficznych aktorów
Recepcjonista
Kiosk multimedialny
Zarządzaj danymi
klientów
Ostatni dzień miesiąca
Utwórz kopię zapasową
Sporządź listę płac
Zamów bilet
Wnieś opłatę
Zarejestruj podatnika
Wylicz kapitał początkowy
System
ubezpieczeń
Stereotypy tekstowe aktorów
<<Actor>>
Recepcjonista
<<Actor>>
Kiosk
multimedialny
<<Actor>>
Ostatni dzień
miesiąca
<<Actor>>
System
ubezpieczeń
Liczebność
ud Aukcja internetowa
Uczestnik
Serwis transakcji
Obserwator
Dokonaj
rejestracji
Licytuj
Wyszukaj
artykuł
Dokonaj
transakcji
1
1
1
1
1
1
O..*
O..*
O..*
O..*
Nawigacja na diagramach przypadków użycia
ud Aukcja internetowa
Uczestnik
Obserwator
Dokonaj
rejestracji
Licytuj
Wyszukaj
artykuł
Dokonaj
transakcji
1
1
1
1
1
1
O..*
O..*
O..*
O..*
<<system>>
Serwis
transakcji
Realizacja
Realizacja to związek znaczeniowy między klasyfikatorami, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego
Dokonaj
transakcji
Przetwarzanie
transakcji
Zdjęcie artykułu
z aukcji
<<realize>>
<<refine>>
Przypadki użycia typu CRUD
CRUD
Create - tworzenie, wprowadzanie
Read - odczytywanie, wyszukiwanie
Update - aktualizacja, modyfikowanie
Delete - usuwanie, skreślanie
Możliwości
zaprojektować elementarne przypadki użycia Wprowadź
zamówienie, Wyszukaj zamówienie, Aktualizuj zamówienie,
Usuń zamówienie;
wyspecyfikować uogólniony przypadek użycia Zarządzaj
zamówieniami lub Utrzymuj dane zamówienia.
Stosowanie nazw ścieżkowych
Nazwa przypadku użycia może być prosta lub ścieżkowa. Nazwa prosta jest rutynowym sposobem określania przypadków użycia, natomiast w ramach stosowania nazwy ścieżkowej nazwę przypadku użycia poprzedza nazwa pakietu, w którym dany przypadek użycia się znajduje
Przyjmij
zamówienie
ObsługaZamówień::
Przyjmij zamówienie
Diagram kontekstowy Stanowi zestawienie aktorów będących w interakcji
z danym systemem traktowanym w kategorii pojedynczego procesu
Student
Dziekan
Pracownik Rektoratu
POS
Termin zakończenia sesji
System rezerwacji bibliotecznej
System e-learningu
Pracownik Dziekanatu
System obsługi stypendium
<<system>>
System administrowania
Uczelnią
Scen
ariusze
alternatyw
ne
Dokumentacja przypadków użycia
Każdy przypadek użycia powinien być uzupełniony o stosowną dokumentację, charakteryzującą scenariusze tego przypadku użycia (ang. use case scenarios).
Scenariusz stanowi określony ciąg akcji dokumentujący zachowanie. Dla danego przypadku użycia zawsze należy wyróżnić scenariusz główny.
Dokumentacja przypadku użycia może ponadto zawierać scenariusze alternatywne
W praktycznych zastosowaniach występują sytuacje zdeterminowane, charakteryzujące się niewystępowaniem alternatyw. Naturalnie w takich przypadkach opisuje się wyłącznie scenariusz główny
Scen
ariusze
alternatyw
ne
Scen
ariusze
alternatyw
ne
Scenariusz
główny
Dokumentacja przypadków użycia
Opisy mogą przybrać postać:
niesformalizowanego tekstu,
formalnego tekstu strukturalnego,
pseudokodu,
tabeli
Szablon dokumentacji przypadku użycia
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 typ 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łowy
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 zintegrowanych 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 przypadku użycia „Anuluj rezerwacje”
Nazwa Anuluj rezerwacje
Numer 5
Twórca Henryk Kowalski - Projektant
Poziom ważności Średni
Typ przypadku użycia Ogólny
Aktorzy Recepcjonista, 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
Nazwa Anuluj rezerwacje
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 może
przekroczyć 5 sekund
Notatki i kwestie Brak
Dokumentacja przypadku użycia „Anuluj rezerwacje” c.d.
Proces tworzenia diagramu
przypadków użycia – kolejne etapy
identyfikacja aktorów,
opcjonalne opracowanie diagramu kontekstowego
identyfikacja przypadków użycia
opracowanie związków - w szczególności asocjacji,
wykorzystanie wszystkich kategorii zaawansowanych
do opracowania diagramu przypadków użycia
udokumentowanie przypadków użycia
z wykorzystaniem szablonów
Bibliografia
Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych, Helion, Gliwice 2005.
Janusz Górski, Inżynieria oprogramowania w projekcie informatycznym, MIKOM, Warszawa 2000.
Andrzej Jaszkiewicz, Inżynieria oprogramowania, Helion, Gliwice 1997.