Podstawy Inżynierii Oprogramowania



Podobne dokumenty
Diagramy czynności. Widok logiczny. Widok fizyczny

Inżynieria oprogramowania

Podstawy programowania III WYKŁAD 4

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

Modelowanie obiektowe - Ćw. 6.

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

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

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

Inżynieria oprogramowania II

Diagramy czynności Na podstawie UML 2.0 Tutorial

NIFIED M L ODELLING ANGUAGE. Diagramy czynności

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

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

Język UML w modelowaniu systemów informatycznych

Modelowanie i analiza systemów informatycznych

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

Modelowanie obiektowe - Ćw. 3.

MODELOWANIE PRZEPŁYWU DANYCH

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

Diagramy przypadków użycia

Model przypadków użycia - rola diagramów aktywności Część 2 Wykładowca Dr inż. Zofia Kruczkiewicz

Projektowanie oprogramowania

Diagramy czynności tworzenie modelu przypadków użycia Wykład 2

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

Język UML w modelowaniu systemów informatycznych

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

TECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek

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

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

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

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

Michał Adamczyk. Język UML

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

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

INŻYNIERIA OPROGRAMOWANIA. laboratorium

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

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

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

Zasady organizacji projektów informatycznych

Informatyzacja przedsiębiorstw WYKŁAD

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

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

Techniki i rozwiązania IT w optymalizacji procesów

Projektowanie oprogramowania. Termin zajęć: poniedziałek, a podstawie materiału ze strony.

Tworzenie warstwy zasobów projektowanie metodą strukturalną

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania

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

Specyfikowanie wymagań przypadki użycia

UML cz. III. UML cz. III 1/36

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

Diagramy maszyn stanowych, wzorce projektowe Wykład 5 część 1

TECHNOLOGIE OBIEKTOWE. Wykład 3

SysML Tworzenie diagramu aktywności SysML005

Diagramy przepływu danych I

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

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

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

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

Diagram przypadków użycia

Modelowanie i analiza systemów informatycznych Spis treści

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

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

Świat rzeczywisty i jego model

Język UML w modelowaniu systemów informatycznych

POLITYKA JAKOŚCI. Polityka jakości to formalna i ogólna deklaracja firmy, jak zamierza traktować sprawy zarządzania jakością.

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

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Wykład 1 Inżynieria Oprogramowania

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig

Dobór systemów klasy ERP

Podstawy inżynierii oprogramowania

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

Modelowanie i analiza systemów informatycznych

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

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

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

PRZEWODNIK PO PRZEDMIOCIE

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

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

PRZEWODNIK PO PRZEDMIOCIE

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

Egzamin / zaliczenie na ocenę*

Cele przedsięwzięcia

APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.

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

MAS dr. Inż. Mariusz Trzaska. Diagramy aktywności

Opis Architektury Systemu Galileo

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

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

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

Projektowanie oprogramowania

PRZEWODNIK PO PRZEDMIOCIE

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

miejsca przejścia, łuki i żetony

WDROŻENIE MODELOWANIA PROCESÓW ORAZ WSPARCIE

Tom 6 Opis oprogramowania

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Transkrypt:

Wykład 3 Specyfikacja wymagań inaczej - historie użytkownika - diagramy aktywności User story (US)- opis wymagań projektowanej aplikacji. - krótko opisana pojedyncza funkcjonalność aplikacji lub - zestaw funkcjonalności, wzajemnie zależnych. 2012/2013 1

Historia użytkownika - rozmiar, struktura Wzorzec opisu historii: Jako <rola>, chcę <cel/pragnienie> aby <korzyść> równoważna - powszechnie stosowana - wersja krótsza: Jako <rola>, chcę <cel/pragnienie > 2012/2013 2

Historie użytkownika- przykłady 1. Jako kierownik chcę wyszukiwać klienta podając ich imię i nazwisko. 2. Jako użytkownik chcę modyfikować swój harmonogram lecz nie można nic modyfikować innym użytkownikom. 3. Kient sklepu internetowego może dodać do swojego koszyka produkt, którego szczegóły ogląda na stronie. 4. Pracownik BOK może zmienić na życzenie klienta zamówienie o podanym numerze. Wymaga to wcześniejszej autentykacji klienta sklepu 5. Użytkownik może wysłać powiadomienie email o nowo zdefiniowanym spotkaniu. 2012/2013 3

Historia użytkownika w MS TFS Zaleta User Stories 1. pokazują projektowaną aplikację z punktu widzenia przyszłego użytkownika. Co pozwoli na dostarczenie funkcjonalnego produktu. 2. zwięzła forma, dzięki której zebranie wymagań nie jest czasochłonne, ale pozwala na wyrobienie opinii co do wyglądu przyszłego systemu. 3. pozwalają na bezpośrednie wpisywanie ich do (Backlog- Scrum). 2012/2013 4

Przypadki użycia vs. historie użytkownika Historia użytkownika Przypadek użycia zapewnia niewielka rozmiarowo i łatwą w użyciu prezentacje informacji. zwykle formułowana w codziennym języku użytkownika ; obejmuje mało detali, co pozwala na ich doprecyzowanie, ale powinny pozwolić czytelnikowi na zrozumienie, co ma wykonywać oprogramowanie. skojarzona z testami akceptacyjnymi, które doprecyzowują rozumienie wymagania. Opisuje proces i jego kroki w szczegółach i może być opisana w postaci formalnego modelu PU w swoim zamierzeniu jest samowystarczający do pełnego zrozumienia wymagania. Uogólniony zbiór interakcji między aktorem i systemem. [1] Samodzielny dokument. 2012/2013 5

WIDOK STRUKTURALNY Podstawy Inżynierii Oprogramowania Specyfikacja zachowania diagramy aktywności diagramy maszyny stanów WIDOK FUNKCJONALNY Z CZYM! CO! JAK! WIDOK ZACHOWANIA 2012/2013 6

Aktywność Przeznaczenie modeluje (koordynuje) wykonanie zachowania, stosując modele: przepływu sterowania jak i przepływu danych może być wykorzystana do opisu procesu biznesowego, przypadku użycia lub operacji uszczegółowienie maszyny stanów Elementy (specyficzne) akcja : podstawowa jednostka zachowania; przekształca zbiór dane_wej w zbiór dane_wyj; czasami modyfikuje stan systemu, w którym akcja się wykonuje; akcja jest niepodzielna, jej trwanie nie podlega przerwaniu. przepływ sterowania przepływ obiektów; pin partycje (partition) 2012/2013 7

Diagram przypadków użycia vs. diagram aktywności Przypadki użycia pokazują, co powinien robić system Diagramy aktywności umożliwiają określenie tego, w jaki sposób system będzie osiągał swoje zamierzone cele Jakie akcje są wykonywane? Jak te akcje są połączone? Diagramy aktywności stosuje się w modelowaniu: procesów biznesowych scenariuszy przypadków użycia procesów systemowych charakteryzujących się dużą liczbą równoległych czynności i decyzji operacji algorytmów 2012/2013 8

Diagram Aktywności notacja podstawowa Aktywność jest opisywana diagramem aktywności reprezentowanym przez graf, którego wierzchołkami są węzły akcji, obiektu bądź węzły sterowania. Krawędzie reprezentują przepływ sterowania między węzłami. Decyzja/ scalenie Początek Rozwidlenie/ złączenie Koniec aktywności przepływu 2012/2013 9

Diagram Aktywności przykład Znajdź napój [brak kawy] [brak coli] [jest kawa] [jest cola] Daj kawę do filtru Wstaw filtr do ekspresu Dodaj wodę do zbiornika Daj filiżankę Daj puszki coli Włącz Ekspres Parz kawę Napełnij kawą Odbierz 2012/2013 12

Diagram Aktywności - sygnały Czynności uruchamiane jako reakcja na sygnał czasowy Rezerwacja biletu Nadanie sygnału Odebranie sygnału Akcept acja rezerw acji Potwierdzenie rezerwacji Kasowanie rezerwacji Upływ 48h 2012/2013 13

Diagram Aktywności przykład z przepływem danych i przepływem sterowania Recepcja Lekarz Laboratorium Rejestracja Karta informacyjn a Diagnoza Zewnętrzne Laboratorium Gromadze -nie danych Karta [Potrzeba analizy zewnętrznej?] informacyjn Formularz a Zapytanie [niewypełniony] [Potrzeba analizy laboratoryjnej?] Przygotowanie formularza Przekazanie formularza Zapytanie Analiza zapytania Wyniki analizy Analiza Odpowiedź Odpowiedź Formularz [wypełniony] 2012/2013 14

Diagram Aktywności - przykład (proces biznesowy) Węzeł początkowy [zamówienie - subskrypcja] Składanie zamówienia Decyzja (warunek) [zamówienie bezpośrednie] Czynność Przydzielanie miejsc Przydzielanie miejsc Obciążanie rachunku Udzielanie rabatu [stały klient?] Obciążanie karty kredytowej Wątek/krawędź Rozwidlenie/złączenie (równoległe) Przesłanie biletów Scalenie Węzeł końcowy 2012/2013 15

Dekompozycja aktywności na podaktywności DostawaProdukt [else] Zwykłe Zamówien Zamówien [pilne] 48h Wejściowy Parametr Wyjściowy Osiągnięcie precyzyjnego opisu - konieczna dekompozycja aktywności. Aktywności mogą dekomponowane na zhierarchizowane podaktywności 2012/2013 16

Modelowanie biznesowe* Motywacja: SKĄD WYMAGANIA Własności systemu powinny wynikać z potrzeb klientów i rozwiązywać ich rzeczywiste problemy Cele modelowania biznesowego: - zrozumienie struktury i dynamiki organizacji - zapewnienie jednolitego rozumienia organizacji przez wytwórców i uczestników procesu (opracowanie wspólnego słownika) - wyprowadzenie wymagań systemu niezbędnych do wsparcia organizacji Formy modelowania biznesowego (a) uproszczona, w której buduje się jedynie model domenowy, ilustrujący podstawowe byty i związki pomiędzy nimi, występujące w dziedzinie zastosowań, (b) pełna, w której buduje się model biznesowych przypadków użycia oraz model obiektów biznesowych. * materiał dodatkowy 2012/2013 19

Procesy biznesowe PB: naprawa zestawów komputerowych PB: zakup części komputerowych PB: sprzedaż zestawów komputerowych Firma komputerowa Sprzedaż Księgowość Magazyn Montownia Serwis Proces biznesowy Dział przed. Zadania działu służące wykonaniu procesu Sprzedaż urządzeń Sprzedaż Pozyskanie klienta, przyjęcie zamówienia, złożenie zamówienia montowni, sporządzenie dokumentów sprzedaży Księgowość Montownia Zbadanie zdolności kredytowej klienta Złożenie zamówienia zestawów Magazyn Dostarczenie elementów do montażu zestawów 2012/2013 20

Definicje podstawowych artefaktów modelu biznesowego Słownik pojęć dziedzinowych Model biznesowych przypadków użycia: Biznesowe przypadki użycia (procesy biznesowe) zbiór instancji (scenariuszy) akcji wykonywanych w przedsiębiorstwie dających mierzalną wartość aktorowi biznesowemu; wyróżnia się przypadki biznesowe jądra (tzw. core) składające się na podstawowy zbiór usług organizacji, postrzeganych przez aktorów biznesowych oraz przypadki biznesowe pomocnicze, wspierające podstawową działalność biznesową Aktorzy biznesowi reprezentuje rolę graną przez kogoś lub przez coś w otoczeniu przedsiębiorstwa Notacja: diagramy przypadków użycia; opisy tekstowe przypadków użycia 2012/2013 21

Definicje podstawowych artefaktów modelu biznesowego, c.d. Model obiektów biznesowych: Jednostki organizacyjne element grupujący inne elementy modelu (odpowiednik pakietu) Realizacje biznesowych przypadków użycia sposób wykonania danego procesu biznesowego: Pracownicy biznesowi klasa modelująca człowieka pracującego w organizacji Byty (encje) biznesowe pasywna klasa reprezentująca obiekty, które są wytwarzane/modyfikowane/przetwarzane przez pracowników biznesowych Notacja: diagramy klas (również zawierające pakiety) aspekt statyczny, diagramy aktywności, diagramy sekwencji lub współdziałania aspekt dynamiczny 2012/2013 22

Przykład dokumentacji procesu biznesowego Used by: Zamawiajacy usluge transportowa Description: Usługa transportowa polega na przetransportowaniu chorego, krwi lub organów z miejsca wskazanego przez Osobę zamawiającą usługę transportową do szpitala lub innego wskazanego miejsca. Kierowca realizujący kurs ma obowiązek wypełniania karty drogowej. Przepływ : 1. Osoba zamawiająca usługę transportową dzwoni do Dyspozytorni z poleceniem wykonania usługi transportowej. 2. Dyspozytor przyjmuje zlecenie, podejmuje decyzję o wysłaniu odpowiedniego pojazdu. 3. Dyspozytor wybiera jednego z dostępnych kierowców i zleca mu wykonanie kursu. 4. Kierowca realizuje zlecony kurs, po czym wypełnia Kartę drogową. Proponowane usprawnienia: ewidencja Kart drogowych Intent: Celem usługi jest przewiezienie chorego, krwi lub organów do przeszczepów z miejsca wskazanego przez Zamawiającego usługę do szpitala lub innego wskazanego miejsca Pre Conditions: Podpisana umowa ze Szpitalem Post Conditions: Zrealizowany kurs, wypełniona karta drogowa. 2012/2013 23

Realizacja procesu biznesowego -diagram aktywności 2012/2013 24

Przykład Model obiektów biznesowych diagram klas (jednostki organizacyjne) Władze Wydziały Domy studenckie Biuro prorektora Zespół domów studenckich Władze uczelni organ odpowiedzialny za działalność Politechniki Wrocławskiej Wydział - podstawowa jednostka organizacyjna uczelni. Jego zadaniem jest samodzielne prowadzenie działalności dydaktycznej i naukowej. W kontekście bieżącego opracowania wydział, którego pracami steruje dziekanat, zajmuje się głównie rozpatrywaniem podań studentów. W ramach Politechniki Wrocławskiej istnieje 12 wydziałów. Domy studenckie - mieszkalne budynki będące własnością Politechniki Wrocławskiej, w których zamieszkują studenci. Za każdy akademik odpowiada jego Kierownik. 2012/2013 25

Przykład (cd) opis procesu diagramem aktywności Dziekanat Student Pula miejsc wydzi ału Podanie Składanie podań Rozpatrywanie podań Byty biznesowe Promesa Lista rezerwowa Podanie Składanie podań - uzupełnienia Uzupełnienie i weryfikacja Lista rezerwowa Lista ostateczna 2012/2013 26

Modelowanie biznesowe - podsumowanie Kontekst systemu można opisać: - Pełnym modelem biznesowym - Modelem domenowym Zarówno model biznesowy, jak i wizja systemu służą do wyprowadzenia (identyfikacji i opracowania) specyfikacji wymagań 2012/2013 29