Inżynieria - bks.uniwersytetradom.pl przypadkow.pdf · Inżynieria oprogramowania ... systemów Elementy świata i modelu ... „analiza to studium problemu przed podjęciem działania

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

Menedżerowie, projekty

i zespoły

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

Geneza i ewolucja języka

Wkład dominujących podejść

w standard UML

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

Mechanizmy rozszerzalności

stereotyp

ograniczenie

metka

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.