Język UML w modelowaniu systemów informatycznych



Podobne dokumenty
Diagramy przypadków użycia

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

Modelowanie obiektowe - Ćw. 3.

Modelowanie i analiza systemów informatycznych Spis treści

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

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

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

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

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

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

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

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

Język UML w modelowaniu systemów informatycznych

UML w Visual Studio. Michał Ciećwierz

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

Podstawy języka UML UML

Język UML w modelowaniu systemów informatycznych

UML - zarys 2007/2008

Diagram przypadków użycia

Diagramy klas. WYKŁAD Piotr Ciskowski

TECHNOLOGIE OBIEKTOWE. Wykład 3

Podstawy projektowania systemów komputerowych

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Podstawy programowania III WYKŁAD 4

Język UML w modelowaniu systemów informatycznych

Podstawy modelowania w języku UML

IX Konferencja Informatyki Stosowanej

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

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

slajd 1 Model przypadków użycia Anna Bobkowska

Michał Adamczyk. Język UML

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

Tworzenie warstwy zasobów projektowanie metodą strukturalną

Świat rzeczywisty i jego model

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

Język UML w modelowaniu systemów informatycznych

Projektowanie systemów informatycznych

Tworzenie modelu konceptualnego systemu informatycznego część 1

Informatyzacja przedsiębiorstw WYKŁAD

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

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

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Podstawy inżynierii oprogramowania

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

Procesowa specyfikacja systemów IT

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

Podstawy języka UML UML

MODELOWANIE OBIEKTOWE

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

Tworzenie modelu przypadków użycia część 1 Diagramy przypadków użycia Wykład2

Modelowanie obiektowe

Inżynierski Projekt Zespołowy

Rysunek 1: Przykłady graficznej prezentacji klas.

Język UML w modelowaniu systemów informatycznych

Faza analizy (modelowania) Faza projektowania

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Analityk i współczesna analiza

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

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Inżynieria oprogramowania

Diagramy klas. dr Jarosław Skaruz

Inżynieria oprogramowania II

UML. zastosowanie i projektowanie w języku UML

Język UML w modelowaniu systemów informatycznych

UML cz. II. UML cz. II 1/38

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Modelowanie diagramów klas w języku UML. Łukasz Gorzel @stud.umk.pl 7 marca 2014

Modelowanie danych, projektowanie systemu informatycznego

Lista przykładowych pytań do egzaminu z przedmiotu Inżynieria Oprogramowania

Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Język UML w modelowaniu systemów informatycznych

Modelowanie i analiza systemów informatycznych

Diagramy przypadków użycia Wykład2

Specyfikowanie wymagań przypadki użycia

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

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

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

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL

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

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

Zalety projektowania obiektowego

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

1 Projektowanie systemu informatycznego

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

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

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

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

Diagramy zachowania. Diagramy struktury. Przypadków użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview)

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

Diagramy zachowania. Diagramy struktury. przypadki użycia. Stanów. Przeglądu interakcji widoku interakcji (ang. interaction overview)

Modelowanie obiektowe - Ćw. 1.

INSTRUKCJA LABORATORIUM Automatyzacja procesów przemysłowych.

Projektowanie bazy danych przykład

Technologia programowania

Laboratorium 8 Diagramy aktywności

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

Transkrypt:

Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3

Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case) reprezentują wymagania projektowanego (modelują funkcjonalność) systemu. Diagramy przypadków użycia ilustrują interakcję pomiędzy systemem i podmiotami zewnętrznymi do systemu. Te zewnętrzne jednostki nazywane są aktorami. Diagram przypadków użycia tworzony jest zazwyczaj w początkowych fazach modelowania. Cele stosowania diagramów przypadków użycia: definiuje granice modelowanego systemu, określa jego kontekst, definiuje użytkowników systemu i jednostki zewnętrzne, przedstawia funkcje dostępne dla użytkowników, określa powiązania i zależności pomiędzy nimi.

Diagramy przypadków użycia Elementy składowe diagramu Aktorzy Przypadki użycia Związki pomiędzy aktorami i przypadkami użycia

Aktorzy Aktorzy reprezentują spójny zbiór ról, jakie odgrywają użytkownicy przypadku użycia w czasie interakcji z danym przypadkiem użycia. Aktorzy mogą reprezentować stanowiska i funkcje w danej organizacji, mogą to być także systemy zewnętrzne aplikacji (podsystem, baza danych itd.) czy też urządzenia. Każdy z aktorów wymaga innej funkcjonalności systemu. Pewne funkcje (zadania, jakie system musi spełniać) mogą być potrzebne jednocześnie kilku aktorom.

Aktorzy Aktorzy są najczęściej prezentowani jako proste postacie lub, alternatywnie, jako klasa prostokąta wraz ze stereotypem «actor».

Aktorzy Aktorzy mogą uogólniać innych aktorów: Nazwa aktora jest rzeczownikiem (ewentualnie określeniem rzeczownikowym) w liczbie pojedynczej. Nazwa aktora powinna odzwierciedlać role jaką on pełni w systemie, a nie indywidualny obiekt ze świata rzeczywistego.

Aktorzy Aktor użytkuje jeden lub wiele przypadków użycia w projektowanym systemie, natomiast przypadek użycia jest użytkowany przez jednego lub więcej aktorów. Aktor inicjuje wykonanie funkcji systemu. Aktor wymaga dostępu do systemu. Aktor jest osobą fizyczną, rolą w systemie lub systemem zewnętrznym

Przypadki użycia Przypadek użycia jest specyfikacją akcji i ich wariantów, które poprzez interakcje z aktorami systemu, system może wykonać. Przypadek użycia jest działaniem, jakie realizuje system w odpowiedzi na aktywność aktora. Przypadki użycia na diagramach UML prezentuje się zazwyczaj w postaci elips z umieszczonymi w środku (lub pod elipsą) nazwami.

Przypadki użycia Przypadki użycia nie posiadają standardowych słów kluczowych lub stereotypów. Przypadek użycia może być pokazawany wraz z niestandardowym stereotypem umieszczonym bezpośrednio nad kego nazwą. Przypadek użycia może posiadać własności - operacje i atrybuty.

Diagramy przypadków użycia - związki Głównym związkiem jest asocjacja. Asocjacja mówi o wystąpieniu dwukierunkowej komunikacji pomiędzy przypadkiem użycia a aktorem. Związkom nie nadaje się nazw.

Diagramy przypadków użycia - związki Jeśli komunikacja pomiędzy przypadkiem użycia a aktorem przebiega tylko w jednym kierunku, można kierunek ten zaznaczyć strzałką.

Diagramy przypadków użycia - związki Związki pomiędzy przypadkiem użycia a aktorem mogą mieć ewentualnie wartości liczebności na każdym końcu. Poniższy rysunek ilustruje fakt, że klient może mieć tylko jedną sesję wypłaty na raz, ale bank może mieć dowolną liczbę klientów dokonujących wypłat jednocześnie.

Diagramy przypadków użycia - zawieranie Przypadek użycia może zawierać funkcjonalność innych przypadków użycia jako część ich normalnej obsłu. Zawierany przypadek użycia nie jest wykonywany samodzielnie; wykonywany jest zawsze, gdy stosowany jest przypadkek użycia "główny". Związku zawierania używa się wówczas, gdy z kilku innych przypadków użycia można wydzielić pewną część wspólną. Związek zawierania ma postać przerywanej strzałki ze stereotypem «include», biegnącej od przypadku użycia zawierającego do zawieranego.

Diagramy przypadków użycia - zawieranie

Diagramy przypadków użycia - zawieranie Przypadek użycia może być włączony przez jeden lub więcej przypadków użycia, przyczyniając się do zmniejszenia poziomu powielania funkcjonalności poprzez wydzielnie wspólnego zachowania, które wykorzystywane jest wiele razy.

Diagramy przypadków użycia - rozszerzanie Rozszerzenie pozwala na wydzielenie przypadku użycia, który w pewnych sytuacjach może zostać wzbogacony o dodatkowe opcje. Związek rozszerzenia ma postać przerywanej strzałki ze stereotypem «extend», biegnącej od przypadku użycia rozszerzającego do rozszerzanego.

Diagramy przypadków użycia - rozszerzanie Rozszerzany przypadek użycia może pokazywać jawne informacje o rozszerzeniu w części extension points.

Diagramy przypadków użycia - ograniczenia Zazwyczaj przypadki użycia wyświetla się jako część wewnątrzną pewnego systemu, a aktorów jako część poza systemem.

Diagramy przypadków użycia - uogólnienie Uogólnienie ma na celu uogólnienie aktorów bądź przypadków użycia, przy czym obiekt uogólniany posiada wszystkie cechy obiektu ogólnego. Uogólnienie ma postać strzałki z linią ciągłą i zamkniętym grotem.

Diagramy przypadków użycia - przykład I Źródło:http://wazniak.mimuw.edu.pl/images/7/76/Io-5-wyk.pdf

Diagramy przypadków użycia - przykład II System biblioteczny Występuje trzech aktorów: Czytelnik, Bibliotekarz i Zegar. Czytelnik i Bibliotekarz reprezentują role użytkowników systemu, natomiast Zegar służy do generowania cyklicznych Powiadomień. Czytelnik i Bibliotekarz korzystają z przypadków użycia. Niektóre z nich, np. Zwrot lub Wypożyczenie do czytelni, są przez nich współdzielone, natomiast Rejestracja czytelnika i Przedłużenie są dostępne tylko dla jednego albo drugiego aktora. Przypadek użycia Wyszukanie jest włączany do kilku innych przypadków użycia: Rezerwacja, Wypożyczenie i Wypożyczenie do czytelni. W ten sposób jest on wywoływany w sposób pośredni przez aktora, a bezpośrednio przez inny przypadek użycia.

Diagramy przypadków użycia - przykład III Przypadek użycia Rezerwacja jest rozszerzany przez Powiadomienie. Oznacza to, że Powiadomienie może uczestniczyć w realizacji funkcji Rezerwacji. Ponadto Rezerwacja posiada dwa szczegółowe przypadki: Rezerwację książki i Rezerwację czasopisma.

Diagramy przypadków użycia - przykład Źródło:http://www.uml-diagrams.org/use-case-diagrams.html

Diagramu przypadków dla Biznesu (ang. Business use case diagram) I Źródło:http://www.uml-diagrams.org/ airport-checkin-uml-use-case-diagram-example.html

Diagramu przypadków dla Biznesu (ang. Business use case 2015-10-28 Latex... Diagramu przypadków dla Biznesu (ang. Business use case diagram) diagram) I Źródło:http://www.uml-diagrams.org/ airport-checkin-uml-use-case-diagram-example.html Przykład wykorzystania diagramu przypadków dla Biznesu, który zwykle jest tworzony podczas modelowania biznesowego, zapisany przy użyciu notacji Rational Unified Process (RUP). Aktorzy biznesowi to: Passenger, Tour Guide, Minor Passenger, Passenger with Special Needs, czyli Pasażer, Przewodnik, Dziecko, Pasażer o specjalnych potrzebach (np niepełnosprawnych). Wszyscy aktorzy grają role zewnętrzne w stosunku do działalności lotniska.

Diagramu przypadków dla Biznesu (ang. Business use case 2015-10-28 Latex... Diagramu przypadków dla Biznesu (ang. Business use case diagram) diagram) I Źródło:http://www.uml-diagrams.org/ airport-checkin-uml-use-case-diagram-example.html Przypadki użycia dla biznesu to: Individual Check-In, Group Check-In, Security Screening, itd. (czyli odprawa indywidualna, odprawa grupowa, kontrola bezpieczeństwa). Przypadki użycia reprezentują funkcje biznesowe lub procesy zachodzące na lotnisku w celu zaspokojenia potrzeb pasażerów. Przypadki użycia Baggage Check-in (odprawa bagażu) i Baggage Handling (obsługa bagażu) rozszerzają przypadek użycia Check-In (odprawa), ponieważ pasażer może nie mieć żadnego bagażu.

Zalecane przykłady do samodzielnej analizy Przeanalizuj następujące Diagramy przypadków użycia znajdujące się na stronie: http://www.uml-diagrams.org/ use-case-diagrams-examples.html

Diagramy przypadków użycia W późniejszych fazach tworzenia oprogramowania diagramy przypadków użycia są przekształcane w bardziej szczegółowe opisy funkcjonowania systemu, takie jak np.: diagramy interakcji między obiektami systemu diagramy czynności realizowanych przez system diagramy stanów specyfikacje za pomocą warunków początkowych i końcowych mniej lub bardziej sformalizowane opisy w języku naturalnym pseudokod