Modelowanie obiektowe Diagramy UML diagram przypadkw uycia dr

Modelowanie obiektowe Diagramy UML – diagram przypadków użycia dr Karolina Muszyńska Na podst. : https: //www. coursehero. com/file/20943013/Lec 431 -6/ G. Schneider , J. P. Winters „Stosowanie przypadków użycia” S. Wrycza, B. Marcinkowski, K. Wyrzykowski „Język UML 2. 0 w modelowaniu SI”

Agenda � Co to jest modelowanie obiektowe? � Zalety podejścia obiektowego � Geneza języka UML � Diagramy UML � Diagram przypadków użycia � Od zadań biznesowych do przypadków użycia 2

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. 3

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 4

Geneza języka UML � Burza metodologiczna w rozwiązaniach obiektowych w latach 1989 -94 ◦ ponad 50 różnych metod/rozwiązań obiektowych UML (Unified Modeling Language) – ujednolicony język modelowania systemów informatycznych � Język ◦ Udana próba połączenia zalet poprzednich metod - 1995 � Baza dla standardu UML ◦ Object Modeling Technique (James Rumbaugh) – notacja diagramów UML, analiza i projektowanie ◦ Object Oriented Analysis and Design (Grady Booch) – analiza i projektowanie ◦ Object Oriented Software Engineering (Ivar Jacobson) – modelowanie biznesowe, przypadki użycia 5

Diagramy UML 2. 0 6

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ą. � 7

Najpowszechniej stosowane diagramy UML �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 8

Diagramy UML - przykład Diagram klas dla przypadku użycia “Dodaj nowe zlecenie” Diagram przypadków użycia KLIENT Dodaj nowego klienta ZLECENIE Utwórz nowe zlecenie Pracownik DOSTAWA : klient Pracownik : zlecenie Utwórz zlecenie : dostawa Utwórz dostawę Dostarcz zlecenie Diagram sekwencji dla przypadku użycia “Dodaj nowe zlecenie” Diagram maszyny stanowej dla obiektu “Zlecenie” 9

Modelowanie przypadków użycia �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. 10

Diagram 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) 11

DIAGRAM PRZYPADKÓW UŻYCIA 12

Zależność zawierania <<include>> �Zależność zawierania przedstawia powiązanie pomiędzy przypadkiem zawierającym – bazowym, a przypadkiem zawieranym. Jest to związek obligatoryjny. �Zawierany przypadek użycia nie jest wykonywany samodzielnie lecz wyłącznie przy odwołaniu się do większego, zawierającego przypadku użycia. �Zawierany przypadek użycia zawiera typowe kroki scenariusza, które są wspólne dla dwóch lub więcej bazowych przypadków użycia. Takie podejście redukuje redundancję i sprzyja ponownemu wykorzystaniu wspólnych elementów. 13

Zależność zawierania <<include>> Dokonaj rezerwacji <<include>> Przypisz obsługę hotelową <<include>> Sprawdź listę dostępnych pokoi Przypadki bazowe „Dokonaj rezerwacji” oraz „Przypisz obsługę hotelową” każdorazowo wywołują przypadek „Sprawdź listę dostępnych pokoi”. Zależność zawierania skierowana jest do przypadku zawieranego. 14

Zależność rozszerzania <<extend>> �Zależność rozszerzania przedstawia powiązanie pomiędzy rozszerzanym przypadkiem użycia – bazowym, a przypadkiem rozszerzającym. Związek ten ma charakter opcjonalny. �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 i jego włączenie wymaga spełnienia określonego warunku. 15

Zależność rozszerzania <<extend>> Zaloguj <<extend>> Przypomnij hasło <<extend>> Dokonaj rejestracji “Zaloguj” jest przypadkiem bazowym. Jednak w określonych sytuacjach takich jak – niezarejestrowany użytkownik lub użytkownik, który zapomniał hasła do logowania wywołane zostaną przypadki rozszerzające “Dokonaj rejestracji” lub „Przypomnij hasło”. Przypadki rozszerzające nie są wykonywane automatycznie, a zależność rozszerzania skierowana jest do przypadku bazowego. 16

Związki uogólnienia - dziedziczenia �Uogólnienie to związek o charakterze taksonomicznym pomiędzy klasyfikatorem ogólnym a specjalizowanym. �Element specjalizowany dziedziczy wszelkie cechy elementu ogólnego. �Związki dziedziczenia dotyczą zarówno przypadków użycia, jak i aktorów. 17

Dziedziczenie - uogólnienie w kontekście aktorów i przypadków użycia Złóż zamówienie telefonicznie Złóż zamówienie Klient Przygotuj raport Przedstawiciel handlowy Złóż zamówienie przez stronę www Przygotuj raport sprzedaży Przygotuj raport o reklamacjach 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. 18

Przypadki użycia typu CRUD i elementarne przypadki użycia Utwórz zamówienie Klient Sprawdź stan zamówienia Sprzedawca Anuluj zamówienie Zarządzaj stanem magazynu Administrator bazy danych 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. ). 19

DIAGRAM PRZYPADKÓW UŻYCIA 20

Dokumentacja przypadków użycia �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. 21

Proces tworzenia diagramu 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 22

Od zadań biznesowych do przypadków użycia

Opis zadania biznesowego Zadanie biznesowe Kroki zadania biznesowego Przyjęcie rezerwacji naprawy Identyfikacja typu naprawy Identyfikacja klienta Przyjęcie auta do naprawy Kroki zadania biznesowego Identyfikacja typu naprawy Identyfikacja klienta Przyjęcie auta do naprawy Elementy kroków zadania biznesowego Aktor zewn. Wyjaśnienie objawów usterki Klient Aktor wewn. Usługa systemu Oględziny auta Mechanik Określenie rodzaju koniecznej naprawy i podanie orientacyjnej ceny Mechanik Wyświetl listę napraw Wyszukanie klienta w bazie danych Mechanik Wyszukaj klienta Jeżeli nowy klient: wprowadzenie danych do bazy Mechanik Dodaj nowego klienta Wybór rodzaju naprawy Mechanik Wyświetl listę napraw Wybór planowanej daty realizacji naprawy Mechanik Wyświetl kalendarz Wydruk potwierdzenia rezerwacji Mechanik Drukuj potwierdzenie Zgoda na naprawę Klient Podanie danych identyfikacyjnych Klient 24

Diagram przypadków użycia 25

Scenariusz dla przypadku użycia „Zarezerwuj naprawę auta” 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Mechanik wybiera funkcję „Rezerwacja naprawy” System wyświetla formularz rezerwacji naprawy Mechanik wybiera przeszukiwanie bazy klientów System wyświetla listę klientów Mechanik wybiera klienta z listy System wprowadza dane klienta do formularza rezerwacji Mechanik wybiera przeszukiwanie bazy napraw Include: „Wyświetl listę napraw” Mechanik wybiera rodzaj naprawy z listy System wprowadza dane naprawy wraz z kosztem do formularza rezerwacji Mechanik wybiera wyświetlanie kalendarza i wybiera datę realizacji naprawy System wprowadza datę do formularza rezerwacji Mechanik zatwierdza dane rezerwacji naprawy System zapisuje rezerwację i drukuje potwierdzenie 26

Punkt rozszerzenia dla przypadku użycia „Zarezerwuj naprawę auta” przed punktem 5. extend: Dodaj nowego klienta Scenariusz przypadku użycia „Dodaj nowego klienta” 1. System wyświetla formularz dodawania nowego klienta 2. Mechanik wprowadza dane klienta (imię, nazwisko, adres, nr telefonu, email) 3. Mechanik zatwierdzane wpisane dane 4. System wyświetla potwierdzenie 27