Diagram przypadków użycia

Slides:



Advertisements
Podobne prezentacje
Związki w UML.
Advertisements

Unified Modeling Language Wykład 4 Przypadki użycia
Diagramy stanów i diagramy aktywności
Modelowanie przypadków użycia
Modelowanie klas i obiektów
Projektowanie w cyklu życia oprogramowania
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Projektowanie Aplikacji Komputerowych
Projekt modułu Gra strategiczna „Strusia jama” Wyrzutnie
UML Unified Modeling Language
Co UML może zrobić dla Twojego projektu?
Bartosz Walter Prowadzący: Bartosz Walter
Tomasz Jabłoński Michał Ziach
Diagramy interakcji Jacek Górski gr
Mapowanie procesów pracy i organizacja stanowisk
Diagramy klas w języku UML
Diagram czynności (Activity Diagrams)
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
Projektowanie - wprowadzenie
Analiza, projekt i częściowa implementacja systemu obsługi kina
Wykład 4 Analiza i projektowanie obiektowe
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
Infrastruktura języka UML w wersji 2.2
Inżynieria Oprogramowania
UML 2.x Robert Pająk.
Model przestrzenny Diagramu Obiegu Dokumentów
Związki w UML Do zrobienia jest: -Przerysować jak ktoś ma Visio te dwa diagramy tak żeby podmienić tylko nazwy a reszta Taka sama, -I dodać po jednym zdaniu.
Programowanie obiektowe – język C++
Model przypadków użycia
Programowanie obiektowe 2013/2014
Modelowanie obiektowe Diagramy czynności
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Modelowanie obiektowe Diagramy sekwencji
Unified Modeling Language - Zunifikowany Język Modelowania
Modelowanie obiektowe Diagramy klas
Programowanie w języku C++
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Diagramy przypadków użycia ALINA SUCHOMSKA. Przypadki użycia systemu  technika wyznaczania funkcjonalnych wymagań systemu  opisują typowe interakcje.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Programowanie strukturalne i obiektowe C++
Model obiektowy bazy danych
Diagram aktywności (czynności)
Diagram przypadków użycia
Diagram klas Kluczowymi elementami są: klasy (class)
Zarządzanie zagrożeniami
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Przykłady analiza i projektowanie
Diagram klas Diagramy klas służą do obrazowania statycznych aspektów projektowanych systemów jako: Projekt struktury logicznej baz danych Projekt składników.
Modelowanie obiektowe - system zarządzania projektami.
Projektowanie relacyjnych baz danych – diagramy związków encji
Diagram czynności Diagram czynności (activity diagram) służy do modelowania dynamicznych aspektów systemu. Diagram czynności przedstawia sekwencyjne lub.
Diagram obiektów Diagram obiektów ukazuje elementy i związki z diagramu klas w ustalonej chwili. Diagram obiektów jest grafem złożonym z wierzchołków i.
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Projekt modułu Nazwa całego projektu Nazwa modułu Imię i Nazwisko Inżynieria Oprogramowania II dzień, godzina rok akademicki W szablonie na niebiesko zamieszczone.
Diagramy przepływu danych
Część 1.  Pierwszym etapem metodyki strukturalnej jest analiza strukturalna której efektem jest model podstawowy systemu.
Unified Modeling Language
Wstęp do systemów informatycznych Model przypadków użycia.
E. Stemposz. UML i Analiza Obiektowa, Wykład 2, Slajd 1/42 Wykład 2 Model przypadków użycia dr inż. Ewa Stemposz
Studia Podyplomowe IT w Biznesie Analiza dynamiczna w UML
Architektura Rafał Hryniów. Architektura Wizja projektu systemu, którą dzielą twórcy Struktura komponentów systemu, ich powiązań oraz zasad i reguł określających.
Inżynieria systemów informacyjnych
T. 18. E Proces DGA - Działania (operatorka).
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
Modele wg Jacobsona Model przypadków użycia: definiuje zewnętrze (aktorów = systemy zewnętrzne = kontekst) oraz wnętrze (przypadki użycia), określające.
Zapis prezentacji:

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) pakiety (packages)

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.

Najczęściej używany symbol Aktor Aktor to użytkownik lub inny system, który wchodzi w interakcję z naszym systemem. Najczęściej używany symbol

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 Potomek zawsze może zastąpić przodka Student Użytkownik 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, gdzie dopuszcza się egzemplarz elementu ogólnego.

Aktor Uogólnienie ogólnie Człowiek Pojazd szczegó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 include Bazowy PU Zawierany PU 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. include Zobacz prezentację Wysłuchaj wykładu

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

Związek rozszerzania extend Bazowy PU Rozszerzający PU 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. extend Wykonaj ćwiczenie Wysłuchaj wykładu Warunek: {standard nauczania wymaga ćwiczeń}

Związek zawierania i rozszerzania Student Użytkownik include extend Sprawdź ocenę Zobacz zaległości finansowe Wyświetl wszystkie oceny

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 extend Złóż zamówienie Extension points wymagana zmiana waluty

Extension points Warunek rozszerzenia Miejsce rozszerzenia Rozszerzający przypadek użycia

Pakiety Pakiety pomagają dzielić usługi (przypadki użycia) logicznie w systemie.

Diagram przypadków użycia 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 przypadków użycia na jednym diagramie

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

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

Scenariusze Use Case Student Katalog kursów Rejestracja na kurs Student 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.

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.

System Obsługi Rejestracji Opłacenie podatku od środków transportu Rejestracja pojazdu System Obsługi Rejestracji Zgłoszenie sprzedaży pojazdu

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.

System Obsługi Rejestracji Właściciel Wydział komunikacji Rejestrator Naczelnik Rejestracja pojazdu Raport miesięczny System Obsługi Rejestracji Zgłoszenie sprzedaży pojazdu

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.

System Obsługi Rejestracji Opłacenie podatku od środków transportu Rejestrator Rejestracja pojazdu System Obsługi Rejestracji Zgłoszenie sprzedaży pojazdu

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

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 Wypożyczający zgłasza chęć dokonania rejestracji Wypożyczający wprowadza dane klienta System stwierdza nie przekroczenie limitu wypożyczonych książek System stwierdza nie zaleganie ze zwrotem książek Wypożyczający wprowadza dane książki dla wypożyczenia System stwierdza posiadanie książki przez bibliotekę System stwierdza możliwość wypożyczenia egzemplarza książki System podaje informację o wypożyczeniu

Ćwiczenie Automat do sprzedaży napojów Automat sprzedaje kawę, herbatę i czekoladę. Do kawy i herbaty można dodatkowo zażyczyć sobie cukier. Do herbaty opcjonalnie można zamówić cytrynę, a do kawy śmietankę. Spragniony klient wrzuca monety do automatu i wybiera napój z opcjonalnymi dodatkami. Kiedy zakończy komponowanie napoju naciska przycisk „Wydaj napój” i czeka na napój. Do momentu wciśnięcia przycisku wydającego napój klient może zrezygnować z zakupu wciskając przycisk „Zwrot monet”, pieniądze zostaną zwrócone.

Ćwiczenie