Modelowanie obiektoweDiagramy UML – diagram

przypadków użycia

Karolina Muszyńska

Na podst.: http://www.csun.edu/~dn58412/IS431/IS431_SP13.html G. Schneider , J.P. Winters „Stosowanie przypadków użycia” S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2.0 w modelowaniu

SI”

Modelowanie obiektowe jest techniką identyfikacji obiektów w środowisku systemu oraz zależności pomiędzy tymi obiektami.

Techniki analizy obiektowej wykorzystywane są do: ◦ analizy istniejących obiektów pod względem

możliwości ponownego ich wykorzystania lub dostosowania do nowych zastosowań, oraz

◦ zdefiniowania nowych lub zmodyfikowanych obiektów, które będą połączone z istniejącymi obiektami w użyteczną aplikację biznesową.

Język UML (Unified Modeling Language) jest zestawem notacji stosowanym do określania lub opisu obiektów systemu informatycznego.

2

Modelowanie obiektowe

Korzyści - zalety:◦ Podział skomplikowanych systemów na

łatwiejsze do opanowania i zrozumienia komponenty

◦ Tworzenie komponentów, które mogą być wielokrotnie wykorzystane w innych systemach albo jako elementy wejściowe w innych projektach

◦ Myślenie „obiektowe” jest bliższe rzeczywistości

3

Modelowanie obiektowe

4

Diagramy UML

Diagramy struktury.  Typ diagramów przedstawiających elementy specyfikacji, które są niezależne od aspektu czasu. Są to diagramy klas, obiektów, pakietów i struktur połączonych oraz diagramy wdrożeniowe: diagramy komponentów i rozlokowania.

Diagramy dynamiki.  Typ diagramów przedstawiających cechy zachowania się systemu lub procesy biznesowe. Są to diagramy przypadków użycia, czynności i maszyny stanowej, jak również cztery diagramy interakcji, będące podzbiorem diagramów dynamiki podkreślającymi interakcje pomiędzy obiektami: diagramy sekwencji, komunikacji, harmonogramowania i sterowania interakcją.

5

UML Diagrams

Do modelowania funkcji systemu – diagramy przypadków użycia

Do modelowania obiektów, będących w zakresie działania systemu oraz relacji między nimi –diagram klas i diagram obiektów dla każdego przypadku użycia, oraz dla całego systemu.

Do modelowania interakcji pomiędzy obiektami w celu realizacji funkcji/przypadku użycia – diagramy sekwencji i czynności dla każdego przypadku użycia

Do modelowania zachowania/logiki obiektów - diagram maszyny stanowej dla każdej klasy

6

Najpowszechniej stosowane diagramy UML

7

Diagramy UML - przykład

Diagram maszyny stanowej dla obiektu

“Zlecenie”

Dodaj nowego klienta

Utwórz nowe zlecenie

:klient :zlecenie

Utwórz zlecenie

Dostarcz zlecenieUtwórz zlecenie

ZLECENIE

KLIENT

DOSTAWA

Diagram przypadków użycia Diagram klas dla przypadku użycia“Dodaj nowe zlecenie”

Diagram sekwencji dla przypadku użycia

“Dodaj nowe zlecenie”

Pracownik

Pracownik

:dostawa

Utwórz dostawę

Modelowanie przypadków użycia jest procesem modelowania funkcji systemu, ukazującym zdarzenia biznesowe, aktorów którzy te zdarzenia inicjują oraz to w jaki sposób system reaguje na te zdarzenia.

Przypadek użycia jest sekwencją powiązanych akcji, zarówno zautomatyzowanych jak i ręcznych, prowadzących do realizacji funkcji biznesowej. Nazywa się go również scenariuszem realizacji funkcji.

Aktor reprezentuje encję zewnętrzną, która wchodzi w interakcję z systemem w celu wymiany informacji. Aktorem jest użytkownik pełniący określoną rolę w systemie i może to być zarówno osoba jak i zewnętrzny system. W pewnego rodzaju zdarzeniach zwanych zdarzeniami czasowymi, które inicjowane są w określonym momencie czasu, aktorem jest czas.

8

Modelowanie przypadków użycia

Diagram przypadków użycia jest opisem systemu z punktu widzenia jego funkcji – jakie funkcje oferuje system

Diagram przypadków użycia nie przedstawia przepływów danych ani przepływów informacji w systemie (przepływy te są przedstawiane na diagramach interakcji)

9

Diagram przypadków użycia

Rozszerzający przypadek użycia rozszerza

funkcjonalność bazowego przypadku użycia o nowe

zachowania lub akcje w stosunku do podstawowego

przebiegu zdarzeń. Rozszerzający przypadek użycia

może być wywołany jedynie przez przypadek

użycia, który rozszerza.

Zawierany przypadek użycia zawiera typowe

kroki scenariusza, które są wspólne dla dwóch lub

więcej bazowych przypadków użycia. Zawierany

przypadek użycia redukuje redundancję i sprzyja

ponownemu wykorzystaniu wspólnych elementów.

10

Rozszerzające i zawierane przypadki użycia

“Sprawdź listę dostępnych pokoi” jest przypadkiem bazowym.W określonych sytuacjach (np. brak dostępnych pokoi do wynajęcia w danym obiekcie) wywołany zostanie przypadek “Przekaż rezerwację centrali”.Przypadki rozszerzające nie są wykonywane automatycznie, a zależność rozszerzania skierowana jest do przypadku bazowego.

11

Rozszerzający przypadek użycia(relacja “extend”)

<<extend>>

Sprawdź listę dostępnych pokoi

Przekaż rezerwację centrali

Przypadek bazowy „Dokonaj rezerwacji” każdorazowo wywołuje przypadek „Sprawdź listę dostępnych pokoi”.

Zależność zawierania skierowana jest do przypadku zawieranego.

12

Zawierane przypadki użycia (relacja “include”)

<<include>>

Dokonaj rezerwacji

Sprawdź listę dostępnych pokoi

Przypadki “Złóż zamówienie telefonicznie” i „Złóż zamówienie przez stronę www” są możliwymi odmianami przypadku bazowego „Złóż zamówienie”, natomiast „Przygotuj raport sprzedaży” i „Przygotuj raport o reklamacjach” to odmiany przypadku bazowego „Przygotuj raport”.

Przedstawiciel handlowy może przyjmować rolę Klienta i inicjować te same przypadki użycia co Klient. 13

Dziedziczenie - uogólnienia w kontekście aktorów i przypadków

użycia

Złóż zamówienie

Złóż zamówienie telefonicznie

Złóż zamówienie przez stronę www

Klient

Przygotuj raport

Przedstawiciel handlowy

Przygotuj raport sprzedaży

Przygotuj raport o reklamacjach

Przypadki użycia typu CRUD (Create, Read, Update, Delete) są wykorzystywane kiedy aplikacja służy do przechowywania danych i tylko jeden aktor wchodzi z nią w interakcję (np. zarządzanie bazą danych, zarządzanie zamówieniami, itp.).

14

Przypadki użycia typu CRUD i elementarne przypadki użycia

Utwórz zamówienie

Sprawdź stan zamówienia

Anuluj zamówienie

Klient

Zarządzaj stanem magazynu Administrator

bazy danych

Sprzedawca

Każdy przypadek użycia powinien zawierać dokumentację w formie scenariuszy.

Scenariusz jest sekwencją akcji dokumentujących zachowanie użytkownika i systemu.

Każdy przypadek użycia powinien mieć przynajmniej scenariusz główny ale wskazane jest, żeby wyróżnić także scenariusze alternatywne.

Zarówno scenariusz główny jak i alternatywny szczegółowo opisują pełną funkcjonalność reprezentowaną przez przypadek użycia.

Dodatkowe ważne elementy dokumentacji przypadków użycia to: warunki wstępne oraz warunki końcowe.

15

Dokumentacja przypadków użycia

Identyfikacja aktorów (poszukiwanie źródeł i celów głównych wejść i wyjść systemu).

Identyfikacja przypadków użycia (główne funkcje systemu).

Identyfikacja związków pomiędzy aktorami i przypadkami użycia (asocjacji)

Identyfikacja dodatkowych relacji między przypadkami użycia (“extend”, “include”)

Identyfikacja relacji uogólnienia pomiędzy przypadkami użycia i aktorami

Udokumentowanie przypadków użycia

16

Proces tworzenia diagramu przypadków użycia