slajd 1 Model przypadków użycia Anna Bobkowska

Podobne dokumenty
Język UML w modelowaniu systemów informatycznych

Diagramy przypadków użycia

Diagram przypadków użycia

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

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

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

Modelowanie i analiza systemów informatycznych Spis treści

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

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Specyfikowanie wymagań przypadki użycia

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

Projekt aplikacji internetowej specyfikacja wymagań (cz.1)

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

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

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

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

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

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

Tworzenie warstwy zasobów projektowanie metodą strukturalną

Podstawy programowania III WYKŁAD 4

Podstawy języka UML UML

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

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Inżynieria oprogramowania

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

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

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

Analiza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia

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

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Cele przedsięwzięcia

TECHNOLOGIE OBIEKTOWE. Wykład 3

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

Tworzenie modelu konceptualnego systemu informatycznego część 1

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

SPECYFIKACJA WYMAGAŃ

APIO. W5 PRZYPADKI UŻYCIA. SCENARIUSZE PISANIE SCENARIUSZY RÓŻNE PODEJŚCIA RÓŻNE SZABLONY. dr inż. Grażyna Hołodnik-Janczura W8/K4

MODELOWANIE OBIEKTOWE

Diagramy czynności. Widok logiczny. Widok fizyczny

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

Spis treúci. 1. Wprowadzenie... 13

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

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

Język UML w modelowaniu systemów informatycznych

WZORCE LOGIKI APLIKACJI Reużywalne składniki wymagań

Projektowanie oprogramowania

Laboratorium z przedmiotu: Inżynieria Oprogramowania INEK Instrukcja 2

UML cz. I. UML cz. I 1/1

Modelowanie obiektowe - Ćw. 3.

Projektowanie systemów informatycznych

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

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

Inżynieria oprogramowania II

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

problem w określonym kontekście siły istotę jego rozwiązania

Podstawy języka UML UML

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

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

Życie w akademiku. Zakwaterowanie Opłaty za akademik Usterki w pokoju Pościel Goście... 4

UML 1 diagramy interakcji

Diagramy przypadków użycia - MS Visio

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

Informacje na temat budowy egzaminu zawodowego: Tytuł pracy egzaminacyjnej

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Inżyniera wymagań

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

Zalety projektowania obiektowego

REGULAMIN UDOSTĘPNIANIA ZBIORÓW I KORZYSTANIA Z INTERNETU W BIBLIOTECE PUBLICZNEJ MIASTA I GMINY W PIWNICZNEJ ZDROJU

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Inżynieria oprogramowania

Analityk i współczesna analiza

R E G U L A M I N Wypożyczalni Zbiorów Muzyczno-Fonograficznych Miejskiej Biblioteki Publicznej w Jastrzębiu Zdroju

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Modelowanie i analiza systemów informatycznych

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

Modelowanie obiektowe - Ćw. 5.

Dokument Detaliczny Projektu

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 Programowania Inżynieria wymagań

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

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

UCHWAŁA NR IX/75/2015 RADY MIEJSKIEJ W KLECZEWIE. z dnia 23 czerwca 2015 r.

Faza analizy (modelowania) Faza projektowania

IX Konferencja Informatyki Stosowanej

UML w Visual Studio. Michał Ciećwierz

Diagramy przypadków użycia Wykład2

Inżynieria wymagań. Proces inżynierii wymagań

MODELOWANIE PRZEPŁYWU DANYCH

Wykład 1 Inżynieria Oprogramowania

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

Diagramy czynności Na podstawie UML 2.0 Tutorial

Michał Adamczyk. Język UML

Inżynieria oprogramowania wykład IV Faza określenia wymagań

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

PROTEL SMART inteligentne oprogramowanie dla małych i średniej wielkości hoteli

Transkrypt:

slajd 1 Model przypadków użycia Anna Bobkowska Materia ły pomocnicze do wy kładu z Inżynierii Opr ogramowania na Wy dziale E TI PG. Ich lektura nie zastępuje obecności na wykładzie. Wykorzystanie materiałów w innym celu oraz ich rozpowszechnianie jest zabronione.

Diagram przypadków użycia Pokazuje: funkcjonalność systemu widzianą od zewnątrz, zbiór usług Identyfikowani są: aktorzy, przypadki użycia oraz powiazania i związki między nimi Określa: granice systemu: użytkowników i inne systemy współpracujące z systemem - aktorzy funkcjonalność realizowana przez system: przypadki użycia Aktor 1 Przypadek użycia 1 Przypadek użycia 2 Przypadek użycia 3 Aktor 2 System Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia oraz nowych powiązań slajd 2

Definicje Model przypadków użycia - funkcjonalność z punktu widzenia użytkownika, system widziany jako czarna skrzynka. Przypadek użycia (ang. use case) - (spójna) jednostka funkcjonalności dostarczana przez system, która jest realizowana jako ciąg interakcji pomiędzy aktorem a systemem. Aktor (ang. actor) - abstrakcyjny użytkownik systemu, reprezentujący grupę rzeczywistych użytkowników o podobnych funkcjach i sposobie komunikacji z systemem; najczęściej aktor jest sprawcą zdarzenia powodującego uruchomienie przypadku użycia. Powiązanie Aktor - Przypadek użycia (ang. association) - usługa określona przez przypadek użycia jest dostępna dla aktora, aktor i system komunikują się podczas realizacji przypadku użycia. System lub obiekt (ang. Subject) posiada przypadki użycia slajd 3

Klasyfikacja aktorów Aktor główny - korzysta z podstawowych funkcji systemu Aktor drugorzędny - korzysta głównie z funkcji służących do realizacji zadań pomocniczych (np. administrowania i pielęgnacji systemu) Aktor aktywny - inicjuje przypadek użycia Aktor pasywny - nie inicjuje przypadku użycia, lecz tylko w nim uczestniczy Aktor ożywiony reprezentacja grupy ludzi Aktor nieożywiony system urządzenie Aktor zewnętrzny domyślnie Aktor wewnętrzny w modelowaniu biznesowym slajd 4

Identyfikacja aktorów Kto komunikuje się z systemem? Kto będzie korzystał z funkcji systemu? Kto będzie system pielęgnował? Jakie urządzenia system obsługuje? (aktorzy nieożywieni) Z jakimi innymi systemami system się komunikuje? (aktorzy będący innymi systemami) Kto lub co jest zainteresowane wynikami pracy systemu? slajd 5

Identyfikacja przypadków użycia Dla każdego aktora odpowiedz na pytania: jakiej funkcji aktor wymaga od systemu: czy aktor musi pamiętać, tworzyć, usuwać, modyfikować informacje w systemie czy aktor ma być powiadamiany o zdarzeniach w systemie, i na odwrót Rozważ, jakie są wejścia i wyjścia systemu Staraj się powiązać w jeden przypadek użycia zespół funkcji wspólnie realizujących ten sam cel Opisz przypadki użycia w języku naturalnym, według określonego szablonu Zobrazuj aktorów i przypadki użycia na diagramie przypadków użycia Przeanalizuj powiązania pomiędzy aktorami, pomiędzy przypadkami użyciaoraz pomiędzy aktorami i przypadkami użycia slajd 6

Przypadki użycia biznesowe i programowe BIZNESOWE Cel: pokazanie roli i usług dostarczanych przez organizację Granica: Usługi wykonywane przez ludzi mogą być wewnątrz systemu Aktorzy wewnętrzni użytkownicy systemu w danej organizacji PROGRAMOWE, funkcjonalne Cel: pokazanie wymagań względem systemu Granica: Wewnątrz systemu tylko funkcjonalność oprogramowania (ewent. obsługiwanych urządzeń) Zameldowanie Rezerwacj a Recepcjonistka Rejestracja zameldowania <<include>> Gość W ymeldowanie Recepcjonista Rejestracja wymeldowania <<include>> Płacenie Sprzątaczka Pobieranie nr pokoju do sprzątniecia Zaznaczenie do sprzątnięcia Sprzą tnię cie pokoju Rejestracja sprzątnięcia slajd 7 Pokojowa

Przykład: : Hotel - Opis problemu Hotel Hilton przyjmuje gości. Recepcjonista rejestruje i wymeldowuje gości oraz pobiera opłatę. W hotelu jest wiele pokoi; sprzątają je pokojowe. Pokój może być wynajęty bezpośrednio przy przyjeździe gościa, jeżeli istnieją wolne pokoje. Gość płaci recepcjoniście przed wymeldowaniem. Pokój może być posprzątany dopiero po zwolnieniu. Pokój musi być sprzątnięty przed wynajęciem kolejnemu gościowi. slajd 8

Diagram przypadków użycia (biznesowy) Zameldowanie Gość Wymeldowanie Recepcjonista Sprzątnięcie pokoju Pokojowa slajd 9

Opis tekstowy przypadków użycia Przypadek użycia: Zameldowanie OPIS TEKSTOWY Sposób postępowania podczas zameldowania gościa do pokoju PROCEDURA S1: Gość wchodzi do hotelu. S2: System sprawdza, czy Gość zarezerwował pokój. S3: Jeśli TAK, wtedy przejdź do S4. Jeśli NIE, system sprawdza, czy są wolne pokoje. Jeśli TAK, pokój jest rezerwowany dla Gościa; przejdź do S4. Jeśli NIE, przypadek jest kończony z komunikatem: BRAK MIEJSC. S4: Pokój jest przydzielony Gościowi. Do Recepcjonisty jest wysyłany komunikat PODAJ KLUCZ I KARTĘ. Gość otrzymuje klucz i kartę gościa. slajd 10

Opis tekstowy przypadków użycia Przypadek użycia: Wymeldowanie S1: Gość przybywa do recepcji z zamiarem opuszczenia hotelu. S2: System oblicza rachunek. Gość płaci. S3: Recepcjonista wysyła komunikat do Pokojowej, aby sprzątnęła zwalniany pokój. S4: Do Recepcjonisty system wysyła komunikat ODBIERZ KLUCZ. Gość zwraca klucz i kartę gościa. Przypadek użycia: Sprzątnięcie pokoju S1: Pokojowa otrzymuje komunikat od Recepcjonisty o konieczności sprzątnięcia podanego pokoju. S2: Pokojowa sprząta pokój. S3: Pokojowa wysyła komunikat do Recepcjonsty o sprzątnięciu pokoju. slajd 11

Związki między przypadkami użycia Zawiera (include) - w starszych wersjach używa (uses) związek A include B oznacza, że w czasie wykonywania przypadku użycia A jest wykonywana także funkcjonalność zdefiniowana przez B Rozszerza (extend) przypadek użycia C rozszerza przypadek użycia D, gdy opcjonalnie (w określonych warunkach) do D zostaje włączone wykoanie funkcjonalności C, np. C uzwględnia nową sytuację wyjątkową nie obsługiwaną przez D. Rejestracja samochodu «include» Przegląd samochodu «extend» Mycie samochodu slajd 12 Uogólnienie (Aktor-Aktor) (Przypadek użycia-przypadek użycia)

Opis warunków na związku ze stereotypem <<extend extend>> Punkt rozszerzeń (ang. extensionpoint) miejsce w którym może nastąpić Rozszerzenie wyspecyfikowane przez związek <<extend>> slajd 13

Możliwość specyfikacji krotności na powiązaniu aktora z przypadkiem użycia slajd 14 Krotności

Hotel model funkcjonalny Re zerwacj a Recepcjonistka Rejestracja zameldowania <<include>> Rejestracja wymeldowania Płacenie <<include>> Sprzątaczka Pobieranie nr pokoju do sprzątniecia Zaznaczenie do sprzątnięcia Rejestracja sprzątnięcia slajd 15

Opis nieformalny Opis ustrukturalizowany Opis przypadku użycia Interakcje pomiędzy aktorami a systemem lub pomiędzy obiektami w systemie na diagramach opisujących dynamikę systemu Cechy opisu: Powinien opisywać użyteczną funkcjonalność systemu. Powinien określać, jak i kiedy przypadek się zaczyna i kończy. Powinien zawierać opis interakcji przypadku użycia z aktorami (przepływ zdarzeń, uczestniczące obiekty). Powinien składać się z przebiegu podstawowego oraz przebiegów alternatywnych (wyjątkowych). Powinien uwzględniać związki pomiędzy przypadkami użycia. slajd 16

Ustrukturalizowany opis przypadku użycia Wzorzec opisu Nazwa przypadku Nazwa przypadku użycia Nazwy obiektów Nazwy obiektów, których dotyczy przypadek użycia Aktorzy Obiekty inicjujące/biorące udział w przypadku Streszczenie Skrótowy opis najważniejszych zachowań modelowanych przez przypadek użycia Zdarzenie inicjujące Zdarzenie rozpoczynające sekwencję interakcji Struktura Opis struktury przypadku użycia Warunki początkowe Warunki umożliwiające wystąpienie danego przypadku użycia Pełny opis Opis interakcji pomiędzy obiektami, z wyszczególnieniem miejsc, w których mogą wystąpić sytuacje wyjątkowe Sytuacje wyjątkowe Opis nietypowych sytuacji (przebiegów) mogących wystąpić w ramach przypadku użycia Warunki końcowe Stan, w jakim przypadek użycia pozostawia uczestniczące w nim obiekty Komentarz Dodatkowe informacje nie związane z funkcjonalnością danego przypadku użycia, przydatne w dalszych etapach modelowania slajd 17

Ustrukturalizowany opis przypadku użycia Przykład opisu Nazwa przypadku Nazwa obiektu Aktorzy Streszczenie Wymeldowanie System hotelowy Gość, Recepcjonista Procedura realizowana przy opuszczaniu hotelu przez gościa Zdarzenie inicjujące Zgłoszenie wyjazdu przez Gościa Struktura Brak Warunki początkowe Brak Pełny opis Sytuacje wyjątkowe Warunki końcowe Komentarz Gość zgłasza wyjazd, płaci i zwraca klucze od pokoju (wyjątek: zgubione klucze). Recepcjonista sprawdza zapłacenie rachunku (wyjątek: nie zapłacono) i wydaje Pokojowej polecenie sprzątnięcia pokoju. Zgubiono klucze: żądanie zapłacenia przez Gościa kosztu kluczy. Nie zapłacono: żądanie zapłacenia rachunku przez Gościa. Pobyt opłacony, klucz zwrócony, zainicjowane sprzątanie pokoju. Sprzątanie pokoju jest osobnym przypadkiem użycia. Obsługa sytuacji Zgubiono klucze oraz obsługa płacenia mogą być modelowane osobnymi przypadkami użycia. slajd 18

Use Case Model in Context Functional requirements specification User interface design Use case model System design Configuration of the system Test design slajd 19

Przypadki użycia w cyklu wytwarzania oprogramowania Specyfikacja wymagań funkcjonalnych na system Weryfikacja poprawności i kompletności specyfikacji wymagań Wspomaganie walidacji wymagań Punkt wyjścia do opracowania testów (w tym akceptacyjnych) systemu Identyfikacja składowych (obiektów) systemu Podstawa do opracowania diagramów interakcji (scenariuszy) Możliwość śledzenia, jak wymagania przeradzają się w klasy obiektów i operacje systemu Podstawa do oceny rezultatów testów slajd 20

Zalety modelowania przypadkami użycia Określenie granic systemu i aktorów zewnętrznych Funkcjonalność systemu wyrażona w terminach istotnych dla aktorów zewnętrznych Określenie logiki realizacji funkcjonalności w systemie Zrozumiałość i komunikatywność Przydatność w różnych fazach cyklu wytwarzania oprogramowania Przydatność dla celów prezentacji i dokumentacji slajd 21

Biblioteka model biznesowy Wypożyczenie książki Czytelnik Zwrot książki Bibliotekarz Korzystanie z książki w czytelni slajd 22

Biblioteka poglądowy model programowy Przeglądanie katalogu Zamawianie książki W ydawanie książek Czytelnik Zwrot książek Sprawdzanie konta <<extend>> odnotownie opłaty za przetrzymywanie Bibliotekarz Wysyłanie upomnień Dodawanie/usuwanie książek Zarządzanie kontami czytelników slajd 23