Analýza požadavků a tvorba objektového návrhu – postup, použité modely a diagramy.
Wednesday, May 29, 2013
4:55 PM
Analýza požadavků a tvorba objektového návrhu – postup, použité modely a diagramy.
Typu požadavků:
Funkční
Mimofunkční
Může být externí nebo interní
Zainteresovaný hráč
Ředitel, investor, …
Má vliv na úspěch projektu 
Analytik
Jeho hlavní úlohou je zprostředkovávat kontakt mezi programátory a zákazníky
Musí mít dobré komunikační schopnosti, schopnost abstrakce, detailní znalost problémové oblasti, organizační dovednosti
Postup sběru požadavků
Elicit
Analyze, negotiate
Document
Review
Kategorie požadavků
Podle toho, jaké informace systém obsluhuje, udržuje
Jaké funkce poskytuje uživatelům
Kontextový model
Zobrazení vztahů s okolními entitami
Systém jako černá skříňka
Zobrazuje vztahy se stakeholders + ostatními systémy včetně rozhraní
Vize produktu
Co má výsledný produkt dělat
Kdo jsou stakeholders
Kdo jsou uživatelé
Časový rámec plánu projektu
Model užití
Model = aktéři + případy užití
Případ užití = sekvence akcí, které systém provede v důsledku nějakého podnětu zvenčí a jejichž výsledek je viditelný pro uživatele
Pro modelování datové části
Musíme od klienta zjistit, co tyto doménové třídy budou
S těmito třídami budeme najisto počítat
Datový model
Logický (konceptuální), fyzický – obvykle ERA, viz DB1
Hodnoty atributů datových entit se vyvíjí v čase
CRUDL matice – Create, Rename, Update, Delete List – cílem je vědět kdo a jak manipuluje s údaji
Modely základních struktur systému
Glosář
Pojmy a jejich vysvětlení, prevence nedorozumění
Model základních entit a jejich vztahů, doménové objekty – diagram tříd
Model nasazení
Vztah produktu k prostředí
Analýza požadavků obsahuje tři typy aktivit:
Sběr požadavků: komunikace se zákazníky a uživateli za účelem získání jejich požadavků na systém.
Analýza požadavků: identifikování nejasných požadavků, nekompletních, nejasných, nebo protichůdných a následně řešení těchto nesrovnalostí.
Zaznamenání požadavků: dokumentování požadavků v různých formách, jako běžný textový dokument, případy užití (use case), nebo specifikace procesů → dokument specifikace požadavků
Analýza a klasifikace požadavků
Identifikace zúčastněných stran ("Stakeholderů")
Případy užití (Use Case)
XP (Extrémní programování) – user stories
Funkční
Mimofunkční
Zainteresovaný hráč
Ředitel, investor, standardizační orgán, daňový poplatník…
Vliv na úspěch projektu
Analytik 
Zprostředkovatel mezi zákazníkem a programátory
Dovednosti a vlastnosti
Komunikační schopnosti, naslouchání a pozorování
Vedení schůzek, organizační
Schopnost abstrakce, nadhled, tvořivost
Detailní znalost problémové oblasti
Requirements development
Elicit
Analyze, negotiate
Potential -> stable requirements
Document
Review
Baselined requirements
Requirements management
Change management
Metoda FURPS – model klasifikace funkčních a mimofunkčních požadavků
F (functionality) – funkčnost
U (usability) – užitečnost
R (reliability) – spolehlivost
P (performace) – výkon
S (supportability) – rozšiřitelnost
Kontextový model
Zobrazení vztahů systému s okolními entitami
Systém jako černá skříňka
Aktéři, stakeholders
Rozsah systému
HCI, API, data
4(+1) kategorie požadavků
Klasifikace funkčnosti do 4 kategorií
Jaké informace systém obsluhuje, udržuje
Jaké funkce poskytuje uživatelům
Jaké jsou interakce s jinými systémy
Pro každý druh příslušné vlastnosti
Stačí jednoduché seznamy
+1 = mimo rozsah zadání, doplňková funkčnost
Vize produktu a rozsah projektu
Co má vzniknout
Esenciální, klíčové, vysokoúrovňové požadavky
Problem behind the problem
Business case (proč se to tak chce)
Zdůvodnění výhodnosti-návratnosti projektu
Požadavky: co to má dělat
Popis problému
Obchodní příležitost
Přehled stakeholders a uživatelů
Vize zahrnuje pohled všech zainteresovaných účastníků
Kdo jsou zájemci o systém, potenciální konkurence
Přehled očekávaných schopností a funkcí produktu
Popis, kvalitativní charakteristiky, priority
Omezení, standardy, závislosti vztahující se k projektu
Časový rozsah
Model užití
Popis požadavků na vnější funkčnost systému
Jací uživatelé k systému přistupují
Co to pro ně dělá
Jak systém zpracovává požadavky
Kde je hranice systému
Model = aktéři + případy užití
Kontext, primární funkčnosti
Další iterace, podružná funkčnost
Případy užití
Co to je případ užití
Sekvence akcí, které systém provádí v důsledku nějakého vnějšího podnětu a které vedou k výsledkům viditelným pro některého jeho uživatele
Aktéři …
Hledáme dialogy typu aktér-systém
Základní popis případu užití: název, stručný popis účelu, základní kroky postupu, odkazy na zdrojové informace
UML diagram případů užití
Tvorba objektového návrhu
Diagram aktivit
Diagram aktivit (UML)
akce – atomické dále nedělitelné kroky
vnořené aktivity – volání jiných procesů (aktivit), tyto aktivity mohou být reprezentovány dalším diagramem aktivit.
Sekvenci jednotlivých kroků v diagramu aktivit určuje řídicí tok.
Modelování datové části
Použití doménového modelu
Komunikace
Dorozumění s klientem
S těmito třídami můžeme najisto počítat
Analýza přidá zodpovědnosti, detaily vlastností a chování
Návrh je transformuje a přidá implementační třídy
Datový model
The three level of data modeling, conceptual data model, logical data model, and physical data model, were discussed in prior sections. Here we compare these three types of data models. The table below compares the different features: 
Feature
Conceptual
Logical
Physical
Entity Names
Entity Relationships
Attributes
Primary Keys
Foreign Keys
Table Names
Column Names
Column Data Types
Below we show the conceptual, logical, and physical versions of a single data model. 
Conceptual Model Design 
Logical Model Design 
Physical Model Design 
We can see that the complexity increases from conceptual to logical to physical. This is why we always first start with the conceptual data model (so we understand at high level what are the different entities in our data and how they relate to one another), then move on to the logical data model (so we understand the details of our data without worrying about how they will actually implemented), and finally the physical data model (so we know exactly how to implement our data model in the database of choice). In a data warehousing project, sometimes the conceptual data model and the logical data model are considered as a single deliverable. 
From <[link]> 
Obvykle jeden z prvních nezávisle na OO technikách (viz db1/db2/psds)
Datová entita typicky prochází vývojem (myšleno asi tak že hodnoty atributů entity se mění)
Životní cyklus
Model = stavový diagram
Vazba na doménový / datový model
CRUDL matice
Cíl: vědět, kdo manipuluje s jakými údaji
Create-Read-Update-DeleteList
Úroveň detailu
Analytická - uživatel, případ užití x informace
Návrhová - třída, funkce, proces x tabulka
Úplnost modelu požadavků
Přesně cíl/vize projektu
Seznam klíčových aktérů, jejich cíle
Seznam/diagram podstatných případů užití (dle cíle)
Stručný popis klíčových PU, znalost klíčových vlastností
Kompletní seznam aktérů, popis důležitých
Kompletní specifikace, 80-100% funkčnosti, stručné povědomí o všech
Přesný popis mimofunkčních vlastností
Kontext - vize, aktéři
Funkčnost - případy užití, user stories, procesní model…
Struktury - doménový model, stavový
Vlastnosti - u PU, funkcí, doménových tříd, samostatně
Product backlog
Obrysy požadavků agilně
Společné rysy agilních specifikací požadavků:
Cílem je říct, produkt by měl umět tohle
Forma
Epic, user story
Obsah
Název, stručný popis, odhad pracnosti, testy
Vize produktu -> Feature (více než 2 sprinty) -> Epic (větší funkcionalita, > 1 sprint) -> Skupina user stories
Modely základních struktur systému
Glosář
Seznam důležitých pojmů
Klíčové
Stručný, všemi odsouhlasený popis = společný slovník, prevence nedorozumění
Formát různý (word, excel, access…)
Popis struktury problémové oblasti
Jaké jsou základní abstrakce používané v oblasti aplikace?
Podle čeho si máme vymyslet stabilní třídy pro realizaci?
Východisko = glosář
Model = doménové objekty (diagram tříd)
Doménové objekty/třídy
Doménové objekty - > třídy
Věci vyskytující se v problémové doméně
Klíčové pro fungování systému
Systém udržuje informace
Podstatné aspekty
Terminologie uživatele, pojmy -> názvy tříd
Vztahy mezi třídami (asociace, kardinality)
Nezávislost na implementaci
Jak je najít? Doménovou analýzou (konzultace, doménový expert, části systému podstatné z jejich pohledu - pomůže obrázek, rozhovor s uživatelem, pozorování práce)
Model nasazení
Vztahy produktu k prostředí
Porozumění runtime a fyzickému prostředí
Charakteristiky, parametry
Odhad nákladů + podklad pro architekturu
Alternativy
Zelená louka - součást návrhu architektury
UML diagram nasazení
Postup se zaměřuje na data a jejich transformaci pomocí procesů systému,
hlavními nástroji jsou tedy DFD popisující procesy a toky dat a ERD (Entity Relationship Diagram) popisující data a vztahy mezi nimi
Zaměřuje se na vytvoření logického modelu nového navrhovaného systému (esenciální model) a následně přizpůsobení implementačním požadavkům (implementační model). 
Model prostředí 
Definuje hranice systému a okolí
Obsahuje kontextový diagram a seznam událostí (event list)
Definuje vnitřní chování systému, tak aby plnil požadavky okolí
Používané modely (diagramy) DFD, ERD, DD (datový slovník), SP (specifikace procesů), případně STD (stavový diagram)
Strukturovaná analýza. Klasický postup "shora dolů". Chápe systém jako celek a postupně ho dekomponuje na jednodušší části. Je metodicky velmi dobře zvládnut. Nevýhodou je absence možnosti ukončit předčasně analýzu a implementovat konkrétní část systému. Typickým příkladem je metoda SSADM (Structured Systems Analysis and Design Method).
Objektový model
Často se používá modelovací jazyk UML
Model případů užití
Diagram tříd
Stavové diagramy, sekvenční diagramy a další
CRC karty (Class-Responsibility-Collaboration cards)
Umožňuje zvládnout návrh i složitých a velkých systémů
Není na první pohled vidět kudy vedou vztahy, musí se vyčíst z karet (barevné rozlišení, čáry na nástěnce…)
Hierarchie objektů – sdružovány podle logických souvislostí do balíků a podbalíků
Přirozený přechod od analýzy k návrhu
Doménová analýza nepřihlíží podstatně k jednomu účelu a způsobu použití (kontextu použití), nýbrž shromažďuje pojmy a vazby pro doménu podstatné. 
Hledají se objekty, operace a vazby, které znalci z problémové oblasti pokládají za důležité (často používají jejich názvy apod.)
Objektově orientovaná analýza. Přístup "zdola nahoru", jehož základní myšlenkou je zobecňování. Začíná se z konkrétní části systému, která se analyzuje a popíše. V dalších částech se pak hledají společné rysy, z nichž se odvozují obecné zákonitosti. Výhodou je možnost rychlého paralelního vývoje prototypového software; nevýhodou je nedostatek ověřených metodických postupů a hlubší zkušenosti s rozsáhlejšími systémy.
From <[link]> 