Object-oriented Analysis & Design. Requirements Analysis



Podobné dokumenty
Analýza a Návrh. Analýza

7.2 Model použití (jednání) (Use Case)

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček

Unifikovaný modelovací jazyk UML

7.5 Diagram tříd pokročilé techniky

Systémová analýza a návrh. Zbyněk Ungermann, UNG května 2011

7.5 Diagram tříd pokročilé techniky

Modelování požadavků

Modelování webových služeb v UML

PŘÍLOHA C Požadavky na Dokumentaci

Požadavky pro výběrová řízení TerraBus ESB/G2x

Základy analýzy. autor. Jan Novotný února 2007

Specifikace požadavků, UC. Jaroslav Žáček

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

Semestrální práce ke kurzu 4IT421 Zlepšování procesů budování IS

Dodatek č. 5 ke Smlouvě o užití, implementaci a provozní podpoře informačního systému HELIOS FENIX č. F

7.2 Model použití (jednání) (Use Case)

Dodatek č. 3 ke Smlouvě o užití, implementaci a provozní podpoře informačního systému HELIOS FENIX č. F

7 Jazyk UML (Unified Modeling Language)

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ

Modelování řízené případy užití

7 Jazyk UML (Unified Modeling Language)

Unifikovaný proces vývoje

Nová funkcionalita Potvrzení o provedené transakci ve formátu PDF

Specifikace požadavků, UC. Jaroslav Žáček

TÉMATICKÝ OKRUH Softwarové inženýrství

Elektronická evidence tržeb. Produkční prostředí Přístupové a provozní informace

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53

ANALÝZA PROCESNÍHO ŘÍZENÍ NA MĚSTSKÉM ÚŘADU BŘECLAV

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Přednáška. Sběr požadavků na SW s použitím metody C.C a nástroje Craft.CASE. e-fractal, s.r.o.

Dodatek č. 2 ke Smlouvě o užití, implementaci a provozní podpoře informačního systému HELIOS FENIX č. F

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách

7.6 Další diagramy UML

Aplikační Dokumentace Standardy ICT MPSV

A7B36SI2 - Řízení SW projektů. Smart-Fine. Systém evidence parkovacích lístků pomocí chytrých telefonů. Analýza (v. 3)

7.6 Další diagramy UML

FiskalPRO Mobile. Aplikace pro Android

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech:

Nemocnice. Prvotní analýza a plán projektu

7 - Ustálený stav kmitavý a nekmitavý, sledování a zadržení poruchy

SW pokladna s intuitivním ovládáním, jednoduchým nastavením a rychlým zaškolením obsluhy

Přehledový manuál aplikace GABVAR (verze )

Ročníkový projekt. Jaroslav Žáček

UML: Unified Modeling Language

Elektronická evidence tržeb (EET) v programu HARMONIK

2. Modelovací jazyk UML 2.1 Struktura UML Diagram tříd Asociace OCL. 3. Smalltalk 3.1 Jazyk Pojmenování

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

Novinky v UML 2.5 a agilní modelování

KIV/ASWI 2007/2008 Pokročilé softwarové inženýrství. Cíle předmětu Organizační informace Opakování

CO JE VODAFONE EPOKLADNA?

Metodika analýzy. Příloha č. 1

SOFTWAROVÉ INŽENÝRSTVÍ 1

Diagram nebo text? Miroslav Benešovský, BenSoft s.r.o

Obsah. Zpracoval:

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

7.3 Diagramy tříd - základy

DODATEK Č. F KE SMLOUVĚ O UŽITÍ, IMPLEMENTACI A PROVOZNÍ PODPOŘE INFORMAČNÍHO SYSTÉMU HELIOS FENIX Č. F (1/IT/2012)

Sklady Zadávací dokumentace Verze 1.0

Testování softwaru. 10. dubna Bořek Zelinka

Analýza a modelování dat. Helena Palovská

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií)

Práce s velkými sestavami

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc.

MODUL EET. elektronická evidence tržeb

Smysl metodiky IS/IT. Koncentrovaná zkušenost Checklist na nic nezapomeneme

PRODEJ 2/1. Zvolte možnost Prodej.

Architektura softwarových systémů

Dříve než se začneme věnovat vlastnímu exportu poskytovaných podpůrných opatření, několik důležitých informací.

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová

Testování Java EE aplikací Petr Adámek

Elektronická evidence tržeb (EET) v programu HARMONIK stav k

Změna sazeb z 19% na 20%

Jak používat statistiky položkové v systému WinShop Std.

Plug-in pro správu požadavků a sledování postupu vývoje

Vlastní tisk dokladu je proveden prostřednictvím tisku z náhledu, nebo přímo přes tlačítko tisk.

Komponentový návrh SW

Úvodní studie (pokraov

ZMĚNY TÝKAJÍCÍ SE VŠECH KLIENTSKÝCH SEGMENTŮ:

Design systému. Komponentová versus procesní architektura

Národní architektonický plán a ostatní metody řízení veřejné správy ČR

Zadání příkazu k úhradě

BORM-II a BPMN v provozně ekonomických procesech BORM-II and BPMN in operation economic processes

Ad-on modul Microsoft Dynamics NAV. Pokladna. manuál

TÉMATICKÝ OKRUH Softwarové inženýrství

PŘEHLED FUNKCÍ PROGRAMU KROK ZA KROKEM

MOBILNÍ SKLADNÍK. Příručka k základnímu ovládání. Beta verze popisu produktu Aktualizace dokumentu: z 10

Použití zákaznických karet s čárovým kódem pro identifikaci zákazníků

Manažerská informatika - projektové řízení

6INF2. RNDr. Jaroslav Žáček, Ph.D.

VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ

ERP informační systém

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

1. Plné použití FMD kódů ve spojení s HUBem

TÉMATICKÝ OKRUH Softwarové inženýrství

Elektronická evidence tržeb. P r a h a 2. srpna 2016

Transkript:

Object-oriented Analyi & Deign Requirement Analyi

Waterfall Model Sytem Requirement Software Requirement Deign Verification Module Tet Validation Implementation Iteration

Agile Unified Proce Inception Elaboration Contruction Tranition Implementovány všechny feature Vyjaněna architektura, přijata hlavní deign deciion Vyjaněný záměr (přílib rozpočtu) Uvolnění do otrého provozu

Agile Unified Proce Inception Elaboration Contruction Tranition Inception: hrubá vize vyvíjeného ytému buine cae Věcný rozah (cope) hrubé základní požadavky hrubé odhady

Agile Unified Proce Inception Elaboration Contruction Tranition Elaboration: podrobná vize vyvíjeného ytému iterativní implementace základní (core) architektury iterativní implementace funkcionalit vyokou úrovní rizika identifikace většiny požadavků identifikace věcného rozahu (cope) realitičtější odhady

Agile Unified Proce Inception Elaboration Contruction Tranition Contruction: iterativní implementace zbývajících feature tety před naazením

Agile Unified Proce Inception Elaboration Contruction Tranition Tranition: deployment beta tet releae

OOA/D UML e používá na třech úrovních abtrakce: Konceptuální úroveň Diagramy reprezentují věci reálného věta (domain of interet) Úroveň pecifikace (oftwaru) Diagramy reprezentují SW-ovou abtrakci nebo SW komponenty ( jejich interface) ale ne jejich konkrétní implementaci Úroveň implementace (oftwaru) Diagramy reprezentují SW-ovou abtrakci nebo SW komponenty ( jejich interface) ale ne jejich konkrétní implementaci Konceptuální (analytická) třída Reprezentuje pojem (věc) reálného věta Návrhová (SW) třída Reprezentuje SW komponentu Implementační třída Třída ve mylu C++ nebo Java

OOA/D Define ue cae Define domain model Define interaction diagram Define deign cla diagram

Requirement (FURPS+) Functional (feature, zabezpečení,...) Ueability (GUI, ergonomie, lidký faktor, help, dokumentace,...) Reliability (příputná frekvence chyb, obnovení z chyb, předvídatelnot,...) Performance (rychlot odezvy, průchodnot, dotupnot, potř. paměti,...) Supportability (GUI, ergonomie, lidký faktor, help, internacionalizace, dokumentace,...) + Implementation (limity zdrojů, jazyky a nátroje, platforma) Interface (požadavky a omezení vyvolané externími ytémy) Operation (management ytému, konfigurovatelnot) Packaging Legal

Buine Modeling Domain model Ue-Cae Model Viion Requirement Ue-Cae Diagram Operation Contract Ue-Cae Text Sytem Sequence Diagram Gloary Suplementary Specification Buine (domain)rule Deign Deign model

Dicipline Artifact Incept I1 Elab E1..En Cont C1..Cn Tran T1..T2 Buine Modeling Domain Model Ue-Cae Model r Requirement Viion Supplementary Specification r r Gloary r Deign Model r Deign SW Architecture Document Data Model r

Příklady užití (ue-cae) jou textové dokumenty, nikoliv diagramy. Modelování příkladů užití (ue-cae modeling) je primárně paní textu, nikoliv krelení diagramů. Krelení ue-cae diagramů má pomoci identifikovat jednotlivé ue-cay a nalézt jejich trukturu

3 obvyklé tupně rozpracování ue-caů: Brief Zákazník přijde na pokladnu vybranými položkami ortimentu. Pokladní použije pokladní ytém k tomu, aby zaevidoval každou prodanou položku. Sytém průběžně zobrazuje průběžný oučet cen a detaily o jednotlivých položkách. Zákazník pokytne platební kartu, kterou ytém ověří a zaeviduje. Sytém upraví tav záob na kladě. Zákazník obdrží účtenku a odejde nákupem. Caual Podrobnější popi, více odtavců. Tak, jak potupně rote tupeň porozumění danému ue-cau. Fully dreed Podrobně popány všechny kroky a varianty. Podpůrné ekce jako pre-condition a pot-condition

Fully dreed ue cae Sekce Jméno ue-cau Rozah (Scope) Úroveň Primární aktér Stakeholder and interet Pre-condition Pot-condition Hlavní (úpěšný) cénář Extenze Speciální požadavky Změny technologie a dat Frekvance výkytu Různé Comentář Mělo by začinat loveem Název ytému, který je předmětem návrhu Uer-goal nebo ubfunction Ten, kdo vyvolává lužby ytému pro plnění vých cílů Kdo je zaintereován na ue-cau a co od něj očekává Co muí být plněno, aby e ue cae mohl vykonat Co je plněno po úpěšném plnění ue-cau Typický (nepodmíněný) úpěšný cénář (průběh). Alternativní cénáře (úpěšné nebo chybové) Souviející nefunkční požadavky Seznam změn technologie a formátu dat Může mít vliv na prioritu Typicky eznam nevyjaněných otázek

Fully dreed ue cae Hlavní cénář 1. Zákazník přijde na pokladnu e zbožím. 2. Pokladní zahájí nový prodej. 3. Pokladní zadá (čarový) kód zboží. 4. Sytém zaznamená položku prodeje a zobrazí popi zboží, cenu a průběžnou čátku. Pokladní opakuje kroky 3-4 pro všechny položky zboží. 5. Sytém zobrazí celkovou čátku včetně DPH. 6. Zákazník zaplatí a ytém zpracuje platbu. 7. Sytém předá informaci o ukutečněném prodeji a platbě externímu účetnímu ytému. 8. Sytém vydá účtenku 9. Zákazník odchází e zbožím.

Fully dreed ue cae Extenze (alternativní cénáře) *a. Kdykoliv. Manažer provádí opravnou operaci 1, Manažer zadá do ytému vůj autorizační kód. 2. Manažer nebo pokladní provede jednu operaci v manažerkém módu. 3. Sytém e vrátí do módu pokladní 2-4a. Zákazník oznámí pokladní, že má nárok na levu. 1. Pokladní nárok ověří a zadá kód levy. 2. Sytem vypočte výši uznané levy.

Jak identifikovat případy užití 1.Identifikace hranic ytému. 2.Nalezení primárních aktérů a jejich cílů. 3.Analýza ytémových událotí (vyžadujících obluhu). 4.Definice případů užití (za pomoci ue-cae diagramů)

Primární aktéři Hranice ytému Podpůrní aktéři

Alternativní notace aktéra Stereotype Služba autorizace platby <<ytem>> Služba autorizace platby <<actor>> Služba autorizace platby

Jeden ue-cae využívá jiný ue-cae

Buine Modeling Domain model Ue-Cae Model Viion Requirement Ue-Cae Diagram Operation Contract Ue-Cae Text Sytem Sequence Diagram Gloary Suplementary Specification Buine (domain)rule Deign Deign model

Domain model Deign model

Buine Modeling Domain model Ue-Cae Model Viion Requirement Ue-Cae Diagram Operation Contract Ue-Cae Text Sytem Sequence Diagram Gloary Suplementary Specification Buine (domain)rule Deign Deign model

Operation Contract Sytem Sequence Diagram Deign Model

Dicipline Artifact Incept I1 Elab E1..En Cont C1..Cn Tran T1..T2 Buine Modeling Domain Model Ue-Cae Model r Requirement Viion Supplementary Specification r r Gloary r Deign Model r Deign SW Architecture Document Data Model r