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



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

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Diagram przypadków użycia

Diagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

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

Diagramy przypadków użycia

Język UML w modelowaniu systemów informatycznych

Podstawy programowania III WYKŁAD 4

Projektowanie interakcji. Jarosław Kuchta

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

Projektowanie logiki aplikacji

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

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

Modelowanie i analiza systemów informatycznych Spis treści

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

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

Cele przedsięwzięcia

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych

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

Modelowanie obiektowe - Ćw. 3.

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

SPECYFIKACJE WYMAGAŃ PRZYPADKI UŻYCIA (USE CASE)

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

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

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

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

Inżynieria oprogramowania II

Diagramy przypadków użycia - MS Visio

Projektowanie bazy danych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

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

FORMULARZ OCENY PARAMETRÓW TECHNICZNYCH

Projekt zespołowy Osoby wykonujące projekt:

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

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

System CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski

Modelowanie aktywności. Jarosław Kuchta Programowanie Współbieżne

Inżynierski Projekt Zespołowy

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

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

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

Świat rzeczywisty i jego model

Diagramy stanów i aktywności. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

System CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski

raporty-online podręcznik użytkownika

Projekt z przedmiotu Projektowanie systemów teleinformatycznych

DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL

Projektowanie interfejsu użytkownika (1) Jarosław Kuchta Projektowanie Aplikacji Internetowych

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

Projektowanie interakcji

Specyfikowanie wymagań przypadki użycia

Projektowanie systemów informatycznych

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

Ćwiczenia 3: Specyfikacja wymagań Pytania:

Technologia programowania

System zarządzania materiałami firmowymi

Modelowanie KONCEPCJA. przedstawiana przez INDYWIDUALNOŚĆ GHJ 6

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

PRZEWODNIK PO PRZEDMIOCIE

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

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

Projekt aplikacji internetowej specyfikacja wymagań (cz.1)

Wykład 1 Inżynieria Oprogramowania

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

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

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Instrukcja dla użytkowników serwisu internetowego

Analiza i projektowanie aplikacji Java

PRZEWODNIK PO PRZEDMIOCIE

WellCommerce Poradnik: Sprzedaż

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

Przewodnik dla użytkownika. Instrukcja korzystania z aplikacji mobilnej mtoken Asseco MAA

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

Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek

SKRÓCONY OPIS systemu lojalnościowego

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

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Projektowanie interfejsu użytkownika. Jarosław Kuchta Projektowanie Aplikacji Internetowych

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

Instrukcja korzystania z aplikacji mobilnej mtoken Asseco MAA klient korporacyjny

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Plan wykładu 2. Model Przypadków Użycia (PU) systemu Diagram PU Opisy PU Związki w modelu PU, strukturalizacja

Wymagania funkcjonalne systemu CRM

Diagramy czynności Na podstawie UML 2.0 Tutorial

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

WOJSKOWA AKADEMIA TECHNICZNA

APIO. W7 SPECYFIKACJA (UŻYCIA) DOSTĘPU DO DANYCH I SPOSOBU ICH PRZETWARZANIA 1. METODA CRUD 2. LOGIKA FUNKCJI

Inżynieria oprogramowania

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

Instrukcja. Zlecenia spedycyjne WWW

Inżynieria oprogramowania

Nowości w logistyce Elementy SCM w wersji 9.0

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

Referat pracy dyplomowej

Inżynieria Oprogramowania Jarosław Kuchta. Projektowanie interfejsu użytkownika (zasady ogólne)

System CRM dla banku. Analiza i projekt. Paulina Grabowska, Piotr Kalański, Marcin Kubacki, Adrian Wiśniewski

Projektowanie bazy danych przykład

Podstawy inżynierii oprogramowania

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

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

Transkrypt:

Modelowanie przypadków użycia Jarosław Kuchta

Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników. Przypadek użycia reprezentuje możliwość oferowaną użytkownikowi przez system Przypadek użycia jest realizowany przez interakcję pomiędzy systemem a jego użytkownikami. Ten sam użytkownik może występować w różnych rolach w różnych przypadkach użycia. Rolę użytkownika w interakcji z systemem reprezentuje aktor. Aktorem może być też system zewnętrzny, o ile korzysta z usług projektowanego systemu. Modelowanie przypadków użycia 2/23

Przykłady Aktorzy: Klient Sprzedawca Magazynier Przypadki użycia: Złożenie zamówienia Wystawienie faktury Sprawdzenie stanu towaru Modelowanie przypadków użycia 3/23

Dwustopniowy proces definiowania przypadków użycia 1. Zespół projektowy we współpracy z użytkownikami opracowuje tekstowy opis przypadków użycia 2. Zespół projektowy na podstawie opisu tekstowego opracowuje diagramy przypadków użycia. Modelowanie przypadków użycia 4/23

Rodzaje przypadków użycia ogólny(overview)/szczegółowy(detail) ogólny przypadek użycia prezentuje ogólnie wymagania użytkowników co do funkcjonalności systemu szczegółowy przypadek użycia pokazuje szczegóły interakcji podstawowy(essential)/rzeczywisty(real) podstawowy przypadek użycia pokazuje tylko podstawowe rozwiązania konieczne dla zrozumienia wymaganej funkcjonalności niezależnie od implementacji rzeczywisty przypadek użycia pokazuje konkretny ciąg kroków potrzebnych do realizacji tej funkcjonalności (implementację) Modelowanie przypadków użycia 5/23

Opis przypadku użycia Informacje ogólne Lista aktorów (opis aktorów, relacje między nimi) Relacje z aktorami i innymi przypadkami użycia (diagramy przypadków użycia) Scenariusz zdarzeń Charakterystyka opcjonalna Modelowanie przypadków użycia 6/23

Informacje ogólne Nazwa przypadku użycia czasownik rzeczownik (np. Złożenie zamówienia) Identyfikator identyfikator cyfrowy umożliwiający powiązanie funkcjonalności z przypadkiem użycia Referencja do wymagania funkcjonalnego ze specyfikacji wymagań umożliwia powiązanie przypadku użycia ze specyfikacją wymagań Poziom ważności umożliwia ustalenie kolejności implementacji przy podejściu ewolucyjno-iteracyjnym Rodzaj ogólny/szczegółowy podstawowy/rzeczywisty Modelowanie przypadków użycia 7/23

Lista aktorów Lista aktorów wyszczególnia wszystkich aktorów uczestniczących w przypadku użycia. Każdy aktor reprezentuje rolę użytkownika w interakcji z systemem. Aktor może też reprezentować zewnętrzny system współpracujący z danym systemem. Jeden z aktorów jest wyróżniany. Jest to tzw. aktor główny (primary actor), który inicjuje interakcję. Modelowanie przypadków użycia 8/23

Wielu aktorów w jednym przypadku użycia Złożenie zamówienia Klient Sprzedawca 2 Sesja gry Gracz Modelowanie przypadków użycia 9/23

Relacje między aktorami Użytkownik Użytkownik reprezentuje uogólnioną klasę użytkowników. Ma ogólne możliwości (np. logowanie) Klient reprezentuje klasę klientów. Ma możliwości biznesowe (np. złożenie zamówienia) Klient Administrator Administrator reprezentuje użytkownika pełniącego funkcję nadzorczą. Ma możliwości administracyjne (np. zarządzanie użytkownikami) Modelowanie przypadków użycia 10/23

Relacje między przypadkami użycia relacja zawierania (include) zachodzi wówczas, gdy jeden przypadek użycia jest obowiązkowo częścią innego przypadku użycia, tzn. scenariusz jednego przypadku użycia wchodzi w skład scenariusza innego przypadku użycia. relacja rozszerzenia (extend) zachodzi wówczas, gdy jeden przypadek użycia może być częścią innego przypadku użycia, tzn. scenariusz jednego przypadku użycia może zostać wykonany w scenariuszu innego przypadku użycia w pewnych warunkach. relacja generalizacji-specjalizacji zachodzi wówczas, gdy jeden przypadek stanowi stanowi szczególną (wyspecjalizowaną) wersję innego przypadku użycia, np. jeden z aktorów jest wyspecjalizowaną klasą aktora z drugiego przypadku użycia Modelowanie przypadków użycia 11/23

Przykłady relacji między przypadkami użycia Złożenie zamówienia «include» Określenie terminu dostawy Logowanie użytkownika «extend» Rejestracja nowego użytkownika Zarządzanie użytkownikami Dodawanie użytkownika Edycja danych użytkownika Usuwanie użytkownika Modelowanie przypadków użycia 12/23

Relacje między aktorami i przypadkami użycia (1) Logowanie Logowanie User User Logowanie Admin Admin Modelowanie przypadków użycia 13/23

Relacje między aktorami i przypadkami użycia (2) Administrator Zarządzanie użytkownikami Dodawanie użytkownika Edycja danych użytkownika Usuwanie użytkownika Administrator Dodawanie użytkownika Edycja danych użytkownika Usuwanie użytkownika Modelowanie przypadków użycia 14/23

Diagram przypadków użycia Złożenie zamówienia Sprawdzenie zamówienia Sprawdzenie stanu w magazynie Klient Zmiana zamówienia Sprzedawca Anulowanie zamówienia Realizacja zamówienia Spedytor Magazynier Modelowanie przypadków użycia 15/23

Scenariusz zdarzeń Podstawowy ciąg zdarzeń Aktywności zagłębione Sytuacje wyjątkowe Modelowanie przypadków użycia 16/23

Złożenie zamówienia: Scenariusz zdarzeń opis tekstowy (1) 1. Akceptacja klienta 2. Negocjacje pozycji 3. Akceptacja zamówienia Modelowanie przypadków użycia 17/23

Akceptacja klienta: Scenariusz zdarzeń - opis tekstowy (2) 1. Po zgłoszeniu się klienta sprzedawca wyszukuje jego dane na liście klientów. 2. Jeśli brak klienta na liście klientów, to sprzedawca wprowadza nowego klienta. 3. Sprzedawca potwierdza aktualne dane klienta. 4. Jeśli dane klienta nie są aktualne, to sprzedawca uaktualnia dane. Modelowanie przypadków użycia 18/23

Scenariusz zdarzeń opis tekstowy (3) Wprowadzenie nowego klienta: 1. Sprzedawca prosi klienta o podanie danych osobowych. 2. Klient podaje swoje dane osobowe. 3. Sprzedawca wprowadza dane osobowe klienta do tabeli klientów. Sytuacja wyjątkowa: 1. Klient odmawia podania danych osobowych. 2. Sprzedawca ponownie prosi klienta o podanie danych osobowych. 3. Jeśli klient ponownie odmawia podania danych osobowych, to transakcja się kończy. Modelowanie przypadków użycia 19/23

Negocjacje pozycji: Scenariusz zdarzeń opis tekstowy (4) Dla każdej pozycji zamówienia: 1. Sprzedawca informuje klienta o oferowanym towarze. 2. Klient wybiera towar. 3. Sprzedawca informuje klienta o cenie i terminie realizacji. 4. Klient akceptuje lub odrzuca ofertę Modelowanie przypadków użycia 20/23

Oferowanie towaru: Scenariusz zdarzeń opis tekstowy (5) 1. Sprzedawca dostosowuje listę oferowanych towarów do potrzeb klienta. 2. Sprzedawca prezentuje listę oferowanych towarów dla klienta. Modelowanie przypadków użycia 21/23

Scenariusz zdarzeń - diagram sekwencji klient : Klient Zgłoszenie klienta : Sprzedawca Wyszukanie klienta Lista klientów : Lista klientów Cennik towarów : Cennik Stan aktualny : Stan magazynu Potwierdzenie zgłoszenia Dane klienta Pozycje zamówienia Zapytanie o cenę Cena towaru Cena i termin realizacji Zapytanie o stan Stan towaru Modelowanie przypadków użycia 22/23

Literatura A.Dennis, B.H.Wixom, D.Tegarden: Systems Analysis & Design. An Object-Oriented Approach with UML, John Wiley & Sons, 2002 Modelowanie przypadków użycia 23/23