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

Podobne dokumenty
MAS dr. Inż. Mariusz Trzaska

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

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

Język UML w modelowaniu systemów informatycznych

Modelowanie obiektowe - Ćw. 3.

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

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

Diagramy przypadków użycia

Podstawy programowania III WYKŁAD 4

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

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

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

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

Diagram przypadków użycia

Analityk i współczesna analiza

Podstawy inżynierii oprogramowania

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

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

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

Modelowanie i analiza systemów informatycznych Spis treści

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

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

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

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

Narzędzia Informatyki w biznesie

Michał Adamczyk. Język UML

Język UML w modelowaniu 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)

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

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

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

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Diagram maszyny stanowej - POJĘCIA

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

Faza analizy (modelowania) Faza projektowania

Modelowanie obiektowe - Ćw. 6.

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

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

UML w Visual Studio. Michał Ciećwierz

UML. dr inż. Marcin Pietroo

Język UML w modelowaniu systemów informatycznych

ZARZĄDZANIU. Wykład VI. dr Jan Kazimirski

Język UML w modelowaniu systemów informatycznych

Tworzenie warstwy zasobów projektowanie metodą strukturalną

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

Świat rzeczywisty i jego model

Informatyzacja przedsiębiorstw WYKŁAD

Inżynieria oprogramowania

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

Wykład I. Wprowadzenie do baz danych

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp Podziękowania...

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

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

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

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

Informatyczne fundamenty

Specyfikowanie wymagań przypadki użycia

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

Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne

Identyfikacja i modelowanie struktur i procesów biologicznych

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

Unified Modeling Language

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Inżynieria oprogramowania II

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

TECHNOLOGIE OBIEKTOWE. Wykład 3

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

Narzędzia CASE dla.net. Łukasz Popiel

MODELOWANIE OBIEKTOWE

INŻYNIERIA OPROGRAMOWANIA. laboratorium

Modelowanie i analiza systemów informatycznych

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Programowanie I. O czym będziemy mówili. Plan wykładu nieco dokładniej. Plan wykładu z lotu ptaka. Podstawy programowania w językach. Uwaga!

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

Podstawy modelowania programów Kod przedmiotu

UML 1 diagramy interakcji

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

Diagramy czynności Na podstawie UML 2.0 Tutorial

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

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

Bazy danych 2. dr inż. Tadeusz Jeleniewski

Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)

WPROWADZENIE DO UML-a

WOJSKOWA AKADEMIA TECHNICZNA

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

Wprowadzenie do programowania aplikacji mobilnych

PROJEKT INŻYNIERIA OPROGRAMOWANIA. Temat: System obsługi kasy - projekt wzorcowy

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Identyfikacja i modelowanie struktur i procesów biologicznych

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Projektowanie interakcji

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

Projektowanie baz danych

RUP. Rational Unified Process

Inżynierski Projekt Zespołowy

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

PRZEWODNIK PO PRZEDMIOCIE

Projekt zespołowy Osoby wykonujące projekt:

Transkrypt:

45 min Ergonomia pracy umysłowej prof. dr hab. inż. Marcin Sikorski Analiza procesów: notacja UML, modele przypadków użycia, Rich Picture 7 Data wykładu:............. Razem slajdów: 23

Sytuacja problemowa kiosk interaktywny kolejki, reklamacje usprawnienie procesu? kiosk samoobsługowy? 2

Etapy obsługi kiosku aplikacja mobilna? 3

Zastosowania urz. mobilnych i usług on-line 1. Rozwiązywanie problemów bieżących zakupy, nawigacja, obliczenia, planowanie diety itp. 2. Dostęp do informacji w ruchu e-prasa, newsy, e-książki, lektura, galerie, 3. Pozostawanie w kontakcie e-maile, komunikatory, społeczności, 4. Rozrywka gry, układanki, sudoku, łamigłówki, 5. Edukacja i rozwój osobisty mobile learning, fractal learning, gry edukacyjne, video, 6. Sterowanie stylem życia e-zdrowie, ekologia, monitoring stylu życia, perswazja, 7. Praca zawodowa pracownicy mobilni 4

Analiza problemu = analiza procesu W jaki sposób opisać : proponowany przebieg obsługi kiosku, aplikacji? typowe działania użytkownika? wymagane funkcje systemu? interakcje z elementami otoczenia? Cele analizy: 1. Pełne zrozumienie procesu i zakresu wspomagania IT 2. Określenie wymagań dla systemu IT oraz zakresu funkcji potrzebnych użytkownikowi końcowemu 3. Przygotowanie dokumentacji dla projektantów 5

Przydatne techniki analizy i modelowania: schemat blokowy (omówiony wcześniej) diagram czynności (omówiony wcześniej) model przypadków użycia - notacja UML technika Rich Picture diagramy interakcji ( diagram sekwencji) poza wykładem 6

Model wymagań na wspomaganie IT Składowe: 1. Model przypadków użycia 2. Obiektowy model analityczny Model przypadków użycia wykorzystuje dwa podstawowe pojęcia: Aktor Przypadek użycia Reprezentuje rolę, którą może grać w sytemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient) Reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp. Aktorem jest dowolny byt zewnętrzny, który uczestniczy w interakcji z systemem. Każdy potencjalny aktor może wchodzić w interakcję z systemem na pewną liczbę jemu właściwych sposobów. Każdy z tych sposobów nosi nazwę przypadku użycia i reprezentuje przepływ operacji w systemie związany z obsługą zadania zleconego przez aktora w procesie interakcji. 7

Przypadki użycia Notacja UML 8

UML Unified Modelling Language jest popularną notacją graficzną do celów analizy i projektowania systemów wspomagających procesy biznesowe (ale nie tylko) może służyć do specyfikowania, projektowania, wizualizacji i dokumentowania (zwykle interaktywnych) produktów, których istotnym składnikiem jest oprogramowanie zawiera wiele środków dla wyrażenia różnych perspektyw widzenia projektowanego systemu w jego docelowym otoczeniu ułatwia komunikację pomiędzy osobami planującymi proces obsługi ( biznes ) a informatykami 9

Główne elementy notacji UML wypłata pieniędzy Przypadek użycia: Powinien mieć unikalną nazwę, opisującą przypadek użycia z punktu widzenia jego zasadniczych celów. Czy lepiej jest stosować nazwę opisującą czynność ( wypłata pieniędzy ) czy polecenie ( wypłać pieniądze ) - zdania są podzielone. klient weryfikacja klienta «include» System obsługi klienta wnętrze systemu Aktor: Powinien mieć unikalną nazwę. Interakcja: Pokazuje interakcję pomiędzy przypadkiem użycia a aktorem. Blok ponownego użycia: Pokazuje fragment systemu, który jest używany przez kilka przypadków użycia; może być oznaczony jako samodzielny przypadek użycia. Relacja typu «include» lub «extend»: Pokazuje związek zachodzący między dwoma przypadkami użycia lub przypadkiem użycia a blokiem ponownego użycia. Nazwa systemu wraz z otoczeniem systemu: Pokazuje granicę pomiędzy systemem a jego otoczeniem. 10

Aktor Opracowanie przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych z wykorzystywaniem projektowanego systemu, czyli określenia przyszłych użytkowników systemu. Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Aktor modeluje grupę osób pełniących pewną rolę, a nie konkretną osobę. klient Jedna osoba może wchodzić w interakcję z systemem z pozycji wielu aktorów; np. być zarówno sprzedawcą, jak i klientem. Również jeden aktor może odpowiadać wielu konkretnym osobom, np. aktor strażnik budynku. 11

Analiza w odniesieniu do aktorów Różnice pomiędzy konkretnymi użytkownikami a aktorami Użytkownik Aktor Przypadek użycia Może grać rolę zleca Jan Kowalski Administrator systemu Przeładowanie systemu Adam Malina Konkretny gość Konkretny klient Pracownik Osoba informowana Klient Wejście z kartą i kodem Uzyskanie informacji ogólnych Wypłata z konta 12

Przykład diagramu przypadków użycia (1) wpłata pieniędzy klient wypłata pieniędzy W operacjach wpłaty i wypłaty pieniędzy mogą uczestniczyć także inni aktorzy, np. kasjer. Możemy go dołączyć jako kolejny element rozbudowujący nasz model. wpłata pieniędzy klient wypłata pieniędzy kasjer 13

Przykład diagramu przypadków użycia (2) otoczenie systemu wnętrze systemu Automat do sprzedaży papierosów uzupełnienie towaru klient zakup paczki papierosów wykonanie operacji pieniężnej operator sporządzenie raportu granica systemu kontroler 14

Relacje między przypadkami użycia Przypadki użycia mogą być konstruowane w dowolnej kolejności, chyba że występują między nimi relacje typu «include» czy «extend». W obu poniższych diagramach P1, nazywane przypadkiem bazowym, zawsze występuje jako pierwsze w kolejności działania. Przebieg podstawowy (sekwencyjny): P1 zawsze włącza (używa) P2, zwane tu przypadkiem włączanym. P1 «include» P2 Przebieg opcjonalny (alternatywny): P1 jest czasami rozszerzane o P2 zwane tu przypadkiem rozszerzającym (inaczej: P2 czasami rozszerza P1). Sformułowanie czasami oznacza, że warunek na wywołanie P2 musi być spełniony, aby P2 zostało wywołane z P1. O ile warunek nie został wyspecyfikowany, co jest dopuszczalne, P2 będzie wywołane zawsze (strzałka prowadzi od przypadku wyjątkowego do bazowego). P1 «extend» P2 15

Relacje między przypadkami użycia (2) Uwaga: Zabronione jest łączenie relacją «include» czy «extend» przypadków użycia występujących w różnych przebiegach systemu, jak np. na poniższym diagramie. Złożenie zamówienia klient «extend» dostawca Realizacja zamówienia 16

Relacje <<include>> i <<extend>> rejestracja klienta «include» sprzedaż samochodu «include»: wskazuje na wspólny fragment wielu przypadków użycia (wyłączony przed nawias ); wykorzystywane w przebiegach podstawowych (operacje zawsze wykonywane) «include» «include» przegląd samochodu «extend» «extend» naprawa samochodu «extend» «extend»: strzałka prowadzi od przypadku użycia, który czasem rozszerza inny przypadek użycia - wykorzystywane w przebiegach opcjonalnych (operacje nie zawsze wykonywane) umycie samochodu przyholowanie samochodu 17

Rozbudowa modelu przypadków użycia wpłać pieniadze wpłać pieniadze kasjer klient banku wypłać pieniadze sprawdź stan konta kasjer klient banku «include» wypłać pieniadze sprawdź stan konta «extend» «include» uaktualnianie stanu konta weź pożyczkę zarząd banku weź pożyczkę zarząd banku Model przypadków użycia można rozbudowywać poprzez dodawanie nowych aktorów, nowych przypadków użycia czy też nowych relacji pomiędzy nimi (np. relacji << uses>> - wspólny fragment wielu przypadków) 18

Technika Rich Picture (widok z lotu ptaka) 19

Opis sytuacji/kontekstu metodą Rich Picture graficzna reprezentacja sytuacji/problemu pochodzenie metody: podejscie Soft Systems Methodology (SSM) wydzielenie obszarów problemowych i relacji między nimi wydzielenie granic miedzy obszarami problemowymi elementy składowe problemu: system > podsystem > element - symbole dla oznaczenia ról - konflikty, emocje - ikony dla oznaczenia obiektów - metafory, abstrakcje - opisy tekstowe (objaśnienia, idee) - aktorzy, relacje - aspekty poznawcze - transakcje, przepływy dowolna technika rysowania, brak sztywnych reguł improwizacja, amatorska kreska, fantazyjne urozmaicenia Przydatne narzędzie komunikacji grupowej: pozwala na szersze spojrzenie na problem (różne punkty widzenia) uruchamia dyskusję zespołową, pozwala na wspólne rozumienie sytuacji pozwala na ujęcie sytuacji problemowej z kilku różnych perspektyw 20

Opis sytuacji/problemu metodą Rich Picture znaczne podobieństwo do techniki MindMapping oprócz skojarzeń oznacza się powiązania między obiektami oraz obszary problemowe symbole graficzne ilustrują pojęcia i zwiększają sugestywność opisu Opis Rich Picture środowiska, w jakim funkcjonuje lokalny klub sportowy 21

Opis sytuacji/problemu metodą Rich Picture 22

Opis sytuacji/problemu metodą Rich Picture