Unified Modeling Language Wykład 4 Przypadki użycia

Slides:



Advertisements
Podobne prezentacje
Piotr Czekalski, ZMiTAC, Politechnika Śląska 2003
Advertisements

Związki w UML.
Modelowanie aktywności
Diagramy stanów i diagramy aktywności
Modelowanie przypadków użycia
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Maciej I Stanisław Jedlińscy
Język UML (Unified Modelling Language)
Projektowanie Aplikacji Komputerowych
Inżynieria Oprogramowania II
UML Unified Modeling Language
Co UML może zrobić dla Twojego projektu?
Modelowanie i język UML
UML – Unified Modeling Language (2)
UML Zunifikowany język modelowania
Unified Modeling Language Wykład 5 Diagram czynności
Unified Modeling Language Wykład 3 Diagram klas
Diagram czynności (Activity Diagrams)
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
BPMN Business Process Modeling Notation
Analiza i projektowanie Informacyjnych Systemów Zarządzania
Projektowanie - wprowadzenie
Diagramy czynności.
Projektowanie dynamiki - diagramy interakcji
Analiza, projekt i częściowa implementacja systemu obsługi kina
Wykład 4 Analiza i projektowanie obiektowe
Wykład 5 UML - Unified Modeling Language
IAI-Shop – Kompletna obsługa sprzedaży
C.d. wstępu do tematyki RUP
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
Inżynieria Oprogramowania
UML 2.x Robert Pająk.
Model przestrzenny Diagramu Obiegu Dokumentów
Obsługa Klienta – sprzedaż soczewek kontaktowych i artykułów z grupy – pozostałe. Czyli sprzedaż przypisana do Klienta i sprzedaż bezimienna (detaliczna).
Prezentacja i szkolenie
Wykład 6 Przypadki użycia a proces
DIAGRAMY UML.
MAKRA 1.
Modelowanie obiektowe Diagramy czynności
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Unified Modeling Language - Zunifikowany Język Modelowania
Wprowadzenie do UML dr hab. inż. Kazimierz Subieta profesor PJWSTK.
Modelowanie obiektowe Diagramy klas
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.
Moduł III Definiowanie i planowanie zadań typu P 1.
Diagram aktywności (czynności)
Diagram przypadków użycia
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
Przykłady analiza i projektowanie
Modelowanie obiektowe - system zarządzania projektami.
Diagram czynności Diagram czynności (activity diagram) służy do modelowania dynamicznych aspektów systemu. Diagram czynności przedstawia sekwencyjne lub.
Diagram przypadków użycia
Diagramy przepływu danych
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Część 1.  Pierwszym etapem metodyki strukturalnej jest analiza strukturalna której efektem jest model podstawowy systemu.
Unified Modeling Language
Inżynieria wymagań użytkownika - wprowadzenie
Wstęp do systemów informatycznych Model przypadków użycia.
E. Stemposz. Rational Unified Process, Wykład 10, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 10 Przepływ.
MAS Rafał Hryniów. Agenda  Zasady  Referaty  Projekt  Kolosy.
1. Promotor i skład zespołu menedżerskiego 2. Rozwiązywany problem 3. Wymagania 4. Wybór zespołu programistów 5. Narzędzia / Technologie 6. Przypadki.
Inżynieria systemów informacyjnych
Inżynieria Oprogramowania Laboratorium
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
Zapis prezentacji:

Unified Modeling Language Wykład 4 Przypadki użycia UML Unified Modeling Language Wykład 4 Przypadki użycia

Use Case Diagram Diagram przypadków użycia to przedstawienie użytkowników systemu (aktorów), funkcji wykonywanych przez system (przypadków użycia) i związków między nimi. Diagram PU ma ogromne znaczenie i jest początkiem modelowania. WSM dr Marek Szepski

Cocburn: Jak pisać efektywne przypadki użycia, WNT IO Schneider, Winters: Stosowanie przypadków użycia, WNT IO WSM dr Marek Szepski

Elementy diagramu PU System – to co mamy zrobić (granice) Aktor – spójny zbiór ról odgrywanych przez użytkowników PU w czasie interakcji z tym PU PU – to opisany ciąg akcji i ich wariantów, które system musi wykonać Związek Aktor - PU WSM dr Marek Szepski

Aktor To spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym systemem. Aktor ma zachowanie (czyli może wykonać instrukcję: jeżeli). Aktor osobowy – nieosobowy (inny system komp. urządzenie, czas) Jeden aktor – wiele osób. Jedna osoba – wiele ról. WSM dr Marek Szepski

Aktor GŁÓWNY: Uczestnik, który prosi system o realizację własnego celu. Zwykle rozpoczyna interakcję z systemem. Może działać przez pośrednika. Aktor POMOCNICZY (drugorzędny): Uczestnik, względem którego analizowany system ma cel. Sam nie inicjuje interakcji, ale wymienia komunikaty z systemem (np.. drukarka, istniejąca baza danych). UCZESTNIK poza systemem: ma interesy ochraniane przez system. WSM dr Marek Szepski

Aktor: to informacja o jego profilu: typ, przeszłość, pozycja, umiejętności, doświadczenie, szkolenia itp... Aktorzy na diagramie PU to jedynie ich lista. Definicja aktora znajduje się w specyfikacji. Aktor jest zawsze poza systemem. WSM dr Marek Szepski

Gdzie szukać aktorów Aktor ma interes w stos. do systemu ! Kto korzysta z systemu? Kto instaluje system? Kto uruchamia system? Kto pielęgnuje system? Jakie inne systemy korzystają z tego s.? Kto pobiera informacje? Kto dostarcza informacje? Czy coś dzieje się automatycznie? Aktor ma interes w stos. do systemu ! Lista: AKTOR -> CEL WSM dr Marek Szepski

WSM dr Marek Szepski

Diagram kontekstowy Identyfikuje aktorów Definiuje aktorów Określa (częściowo) granice systemu WSM dr Marek Szepski

PU Def: Przypadek użycia to specyfikacja ciągu akcji ich wariantów, które system może wykonać poprzez interakcje z aktorami tego systemu WSM dr Marek Szepski

Przypadek użycia: To opis działania systemu To umowa na zachowanie systemu To czynności, które aktor chce by system wykonał Jest zawsze uruchamiany przez aktora To zakres funkcjonalny usług systemu WSM dr Marek Szepski

Opis PU WSM dr Marek Szepski

Opis nieformalny W małym dobrze współpracującym zespole Np..: Gdy przedstawiciel handlowy otrzymuje prośbę o anulowanie zamówienia, wyszukuje zamówienie w systemie i zaznacza je jako anulowane. Następnie do systemu księgowego wysyłane jest zlecenie zwrotu pieniędzy na konto klienta. WSM dr Marek Szepski

Opis formalny PU Numer i nazwa Opis – definicja Twórca opisu Aktorzy: główny, drugorzędny Warunki wstępne Główny scenariusz zdarzeń Alternatywne scenariusze Specjalne wymagania Warunki końcowe Uwagi WSM dr Marek Szepski

PU - CRUD C – create R – read U – update D – delete Można połączyć w jednym opisie WSM dr Marek Szepski

Obrazowanie PU Diagram czynności (koncentracja na czynnościach) Diagramy interakcji (koncentracja na komunikatach) - diagram sekwencji Diagram maszyny stanowej (koncentracja na zmianie stanu obiektów) WSM dr Marek Szepski

Jak pisać PU Forma czynna zdania Pisz z punktu widzenia wykonującego aktor robi, system robi, obiekt robi Właściwa szczegółowość opisu Z opisu coś wynika (błąd: system sprawdza – lepiej system potwierdza WSM dr Marek Szepski

Przykład Uczestnik aukcji wskazuje aukcję w której chce uczestniczyć System wyświetla formularz do wpisania oferty Uczestnik wpisuje ofertę a następnie wybiera licytuj System rejestruje ofertę i informuje o tym uczestnika Jeżeli aukcja w systemie holenderskim to następuje rozszerzenie: Finalizuj transakcje. 4a. Jeśli w kroku 3 uczestnik wpisał kwotę niezgodna z regulaminem, system informuje o tym i przechodzi do kroku 2 4b. Jeśli z powodu awarii technicznej lub zakończenia aukcji system nie może zarejestrować ofert, informuje o tym i następuje zakończenie PU WSM dr Marek Szepski

System Granice systemu: aktorzy i PU LISTA: W – POZA Podsystem, nadsystem: system informatyczny jest zwykle częścią systemu biznesowego i współpracuje z innymi lub nadrzędnymi systemami informatycznymi Problem: to może się nam przydać,czy musimy to mieć? – trudne decyzje WSM dr Marek Szepski

Związki Asocjacja (może mieć kierunek) Zawieranie <<include>> Rozszerzenie <<extend>> Uogólnienie (dziedziczenie) Realizacja <<realise>> WSM dr Marek Szepski

WSM dr Marek Szepski

WSM dr Marek Szepski

WSM dr Marek Szepski

WSM dr Marek Szepski

Testy: PU są gotowym planem testów systemu Intrfejs: z opisu PU wprost wynika specyfikacja interfejsów (nie twórz grafiki) Testy: PU są gotowym planem testów systemu DFD: aktor – terminator PU – proces związek – przepływ (różnice) ? – skład danych WSM dr Marek Szepski

WSM dr Marek Szepski

WSM dr Marek Szepski

WSM dr Marek Szepski

Diagram Przypadków Użycia WSM dr Marek Szepski

Perspektywa PU – zachowanie systemu Perspektywa projektowa – klasy, interfejsy, kooperacje Perspektywa procesowa – wątki, procesy, współbieżność, synchronizacja Perspektywa implementacyjna – komponenty i pliki Perspektywa wdrożeniowa - węzły WSM dr Marek Szepski