Diagramy przypadków uŝycia. związków między nimi

Podobne dokumenty
Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie obiektowe - Ćw. 3.

Język UML w modelowaniu systemów informatycznych

Modelowanie Procesów Biznesowych Wykład 3 Notacja UML cz. 1

Diagram przypadków użycia

Język UML. dr inż. Piotr Szwed C3, pok

UML - zarys 2007/2008

Diagramy przypadków użycia

Podstawy programowania III WYKŁAD 4

Inżynierski Projekt Zespołowy

Projektowanie systemów informatycznych. Diagramy przypadków użycia

Diagramy czynności. sekwencyjnych i współbieŝnych. pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Michał Adamczyk. Język UML

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Diagramy przypadków użycia

Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela

Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Diagramy przypadków użycia - MS Visio

Paczki przelewów w ING BankOnLine

Diagramy sekwencji. wymienianych między nimi

Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

INTENSE PLATFORM Zmiany w wersji Wersja 7.2

Świat rzeczywisty i jego model

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

System rezerwacji online

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

UML. dr inż. Marcin Pietroo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Jerzy Skalski s9473, grupa WIs I.6-11c. System wspierający obsługę klienta dla firm sprzedających na Allegro

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta

Przypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady

Instalacja programu S4H

Określanie wymagań. Cele przedsięwzięcia. Kontekst przedsięwzięcia. Rodzaje wymagań. Diagramy przypadków użycia use case diagrams

Podstawy projektowania systemów komputerowych

Planowanie zajęć równoległych i mieszanych

Program Opakowania zwrotne dla InsERT GT.

Regulamin serwisu telefonicznego HaloŚląski. dla klientów korporacyjnych

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 9 Strukturyzacja modelu przypadków użycia

Inżynieria oprogramowania

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture

Diagramy klas. WYKŁAD Piotr Ciskowski

Specyfikowanie wymagań przypadki użycia

Import limitów urlopowych / nowy rok

Instrukcja pobierania informacji o Masowych Płatnościach Przychodzących w systemie BOŚBank24 iboss

Zad. 6: Sterowanie robotem mobilnym

Istotne zmiany w wersji 356 ToyDMS

Podstawy inżynierii oprogramowania

Przypadki użycia. Analiza. Model biznesowy. Specyfikacja wymagań. Model dziedziny problemu. Przypadki użycia

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Autor: Joanna Karwowska

Dokumentacja projektu Makao karciana gra sieciowa

Spis treści. Część I Diagramy języka UML Wstęp 7. Rozdział 1. Studia przypadków 13. Rozdział 2. Diagramy przypadków użycia 29

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

Moduł Handlowo-Magazynowy Przeprowadzanie inwentaryzacji z użyciem kolektorów danych

Diagramy czynności. Widok logiczny. Widok fizyczny

Tworzenie przypadków testowych

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla nauczyciela

INŻYNIERIA OPROGRAMOWANIA. laboratorium

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

ikasa instrukcja użytkownika dla Klientów nie posiadających zainstalowanej aplikacji

Agenda. Cele projektu Wizja projektu Modelowanie biznesowe Wymagania użytkownika Przypadki użycia

ikasa instrukcja użytkownika dla Klientów posiadających zainstalowaną aplikację

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Ustawianie lokalizacji dla indeksów Ustawianie lokalizacji dla indeksów spis kroków

SHOPER INTEGRATOR BY CTI INSTRUKCJA

IO - inżynieria oprogramowania. dr inż. M. Żabińska, zabinska@agh.edu.pl

12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:

TECHNOLOGIE OBIEKTOWE. Wykład 3

Zajęcia laboratoryjne z przedmiotu IOP

Zad. 5: Sterowanie robotem mobilnym

UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.

Rysunek 1: Przykłady graficznej prezentacji klas.

Kontrola i ewidencja numerów seryjnych z zastosowaniem czytnika kodów kreskowych w programie Symfonia Handel Premium

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela

ZAAWANSOWANA POLITYKA CENOWA v.0.47

SYSTEM LOJALNOŚCIOWY. Opis wersji PLUS programu

Konta uŝytkowników. Konta uŝytkowników dzielą się na trzy grupy: lokalne konta uŝytkowników, domenowe konta uŝytkowników, konta wbudowane

EXSO-CORE - specyfikacja

Modelowanie i analiza systemów informatycznych

Diagramy przepływu danych I

Bazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,

irap Raporty on-line

Opis zmian w wersji aplikacji Cyfrowe Repozytorium Dokumentów

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Technologia programowania

SHOPER INTEGRATOR XL BY CTI INSTRUKCJA

mpensjonat Oprogramowanie dla : hoteli pensjonatów domów wczasowych hosteli

Pomoc do programu KOFi

Narysować diagram sekwencji pokazujący rejestrację wypożyczenia przez Jana Kowalskiego książki Potop

slajd 1 Model przypadków użycia Anna Bobkowska

SKRÓCONA INSTRUKCJA OBSŁUGI SYSTEMU ZARZĄDZANIA OBIEGIEM INFORMACJI (SZOI)

Telewizja przemysłowa (CCTV) w RACS 5

Transkrypt:

Diagramy przypadków uŝycia Graficzne przedstawienie przypadków uŝycia, aktorów oraz związków między nimi

Zadania diagramów platforma komunikacji pomiędzy inwestorem a twórcą systemu identyfikacja i dokumentacja wymagań analiza obszaru dziedziny przedmiotowej opracowanie projektu przyszłego systemu podstawa do testowania funkcji systemu

Podstawowe kategorie pojęciowe Przypadek uŝycia specyfikacja ciągu akcji i ich wariantów które system moŝe wykonywać poprzez interakcje z aktorami Aktor spójny zbiór ról odgrywanych przez uŝytkowników przypadku uŝycia w czasie interakcji z tym przypadkiem uŝycia Związek powiązanie pomiędzy elementami modelu asocjacyjny zaleŝność zawierania zaleŝność rozszerzania uogólnienia

Przypadek uŝycia definiuje określoną funkcjonalność stanowiącą wartość dla aktora nazwę stanowi zwięzłe polecenie wykonania funkcji, sformułowane w trybie rozkazującym reprezentacja graficzna: Rezerwuj wycieczkę Sprzedaj towar

Aktorzy uŝytkownicy oraz klienci systemu mogą być osobowi bądź nieosobowi nazwę wyraŝa się rzeczownikiem lub określeniem rzeczownikowym w liczbie pojedynczej mogą uŝytkować jeden lub więcej przypadków uŝycia reprezentacja graficzna: Klient Konsultant Dział sprzedaŝy Nagrywarka Termin płatności

Związki: asocjacje związek pomiędzy dwoma lub więcej klasyfikatorami wskazuje na dwukierunkową komunikację pomiędzy aktorem a przypadkiem uŝycia nie posiada nazwy reprezentacja graficzna: Przyjmij dostawę Magazyn Wydaj towar

Związki: zaleŝność zawierania przedstawia powiązanie pomiędzy przypadkiem zawierającym a przypadkiem zawieranym jest to związek obligatoryjny zawierany przypadek nie jest wykonywany samodzielnie lecz wyłącznie przy odwołaniu się do przypadku zawierającego stereotyp <<include>> reprezentacja graficzna: Dokona j rezerwacji <<include>> Sprawdź listę dostępny ch pokoi

Związki: zaleŝność rozszerzania przedstawia powiązanie pomiędzy rozszerzanym przypadkiem uŝycia (bazowym), a przypadkiem rozszerzającym jest to związek opcjonalny przypadek rozszerzający zwiększa funkcjonalność przypadku rozszerzanego stereotyp <<extend>> reprezentacja graficzna: <<extend>> Sprawdź listę dostępnych pokoi Zmień kategorię pokoju

Związki: uogólnienia przedstazwia powiązanie pomiędzy przypadkiem ogólnym a szczegółowym dotyczy zarówno przypadków uŝycia jak i aktorów Sporządź raport sprzedaŝy Sporządź raport Recepcjonicta Sporządź raport o reklamacjach Pracownik hotelu Kierownik restauracji

Liczebność 1 Dokonaj transakcji 1 1 0..* Licytuj Uczestnik 1 0..* Wyszyukaj

Scenariusze przypadków uŝycia Nazwa Sprawdź poprawność zamodelowania przesuwników Numer 2.3. Twórca mgr inŝ. Krzysztof KsieŜyk Poziom waŝności Średni Typ Korekta modelu Aktorzy Operator, Skrypt Opis Procedura korekcyjna mająca na celu zweryfikowanie i ewentualną poprawę połączeń autotransformatorów Warunki wstępne Warunki końcowe Główny przepływ zdarzeń Alternatywne przepływy zdarzeń 1. Wczytany model EPC 2. Istnieje co najmniej jedna rozdzielnia z autotransformatorami pracującymi równolegle zadana w konfiguracji 1. Nie występują w modelu autotransformatory na których występuje zjawisko krąŝenia mocy 1. Operator wybiera na oknie przycisk Sprawdź poprawność zamodelowania autotransformatorów 2. Wczytywana jest z konfiguracji lista rozdzielni z autotransformatorami z zadaną kolejnością wezłów 3. Dla kaŝdej rozdzielni odszukiwane są transformatory z nią połączone 4. Sprawdzana jest ilość transformatorów połączonych z rozdzielnią 5. Sprawdzany jest warunek poprawnego zamodelowania transformatorów: porównywana jest kolejność węzłów z zadaną w konfiguracji 6. Dla transformatorów źle zamodelowanych zamieniany jest węzeł początkowy z końcowym 3.1. W konfiguracji nie są zdefiniowane Ŝadne rozdzielnie z autotransformatorami 3.3. Wpisanie do Log'a informacji o braku listy rozdzielni oraz analogiczny Komunikat 3.2. Następuje zakończenie procedury 4.1. W modelu dla wybranej rozdzielni istnieje tylko jeden transformator 4.2. Pobranie kolejnej rozdzielni z listy

Proces tworzenia diagramu przypadków uŝycia 1. Identyfikacja aktorów 2. Identyfikacja przypadków uŝycia 3. Określenie związków: asocjacji, zawierania, rozszerzania, uogólnienia 4. Określenie liczebności 5. Udokumentowanie przypadków uŝycia z wykorzystaniem scenariuszy