====== AP13 Analýza a návrh systémů ====== ===== Zadání ===== (Problémy spojené s řešením rozsáhlých systémů. Empirické zákony softwarového inženýrství. Modelovací nástroje funkční a datové dekompozice. Konzistence modelu. Metody strukturované analýzy. Yourdonova metoda. Strukturovaný návrh, nástroje, metody, metriky a heuristiky návrhu) ====== Problémy spojené s řešením rozsáhlých systémů ====== * Složitost – lze ji charakterizovat nepřímo, některými viditelnými atributy programu (architektura, počet proměnných) * Velikost – programování v malém vs. programování ve velkém * Komunikace – jednotlivec, malý tým, velký tým * Čas * Plán prací * Neviditelnost SW ====== Empirické zákony softwarového inženýrství ====== Postřehy, nadsázky ===== Lehmanovy „zákony“ ===== * **Zákon trvalé proměny** – systém používaný v reálném prostředí se neustále mění, dokud není levnější systém restrukturalizovat, nebo nahradit zcela novou verzí. * **Zákon rostoucí složitosti** – při evolučních změnách je program stále méně strukturovaný a vzrůstá jeho vnitřní složitost. Odstranění narůstající složitosti vyžaduje dodatečné úsilí * **Zákon vývoje programu** – rychlost změn globálních atributů systému se může jevit v omezeném časovém intervalu jako náhodná. V dlouhodobém pohledu se však jedná o seberegulující proces, který lze statisticky sledovat a předvídat. * **Zákon invariantní (neproměnné) spotřeby práce** – celkový pokrok při vývoji programů je statisticky invariantní. Jinak řečeno, rychlost vývoje programu je přibližně konstantní a nekoreluje s vynaloženými prostředky. * **Zákon omezené velikosti přírůstku** – systém určuje přípustnou velikost přírůstku v nových verzích. Pokud je limita překročena, objeví se závažné problémy týkající se kvality a použitelnosti systému. ===== Brooksův zákon===== * Přidání řešitelské kapacity u opožděného projektu může zvětšit jeho zpoždění (náklady na začlenění nového pracovníka do týmu jsou zpravidla větší, než jeho přínos) ====== Modelovací nástroje funkční a datové dekompozice ====== ===== Funkční dekompozice ===== ==== Diagram datových toků DFD ==== je modelovací nástroj, který umožňuje zobrazit systém jako síť procesů, které plní určené funkce a předávají si mezi sebou data. Tímto způsobem jde modelovat nejen toky dat, ale i toky fyzických předmětů v systému. Diagram obsahuje čtyři základní typy komponent: * Terminátory – reprezentují externí entity, se kterými systém komunikuje * Procesy – transformují určité vstupy na výstupy * Datové toky – znázorňují cestu, po které se pohybují datové shluky z jedné části systému do druhé * Paměti – kolekce dat v klidu ==== Diagram datových toků s řízením CDFD==== je rozšířenou variantou DFD, na které jsou zakresleny i řídící procesy, jejichž účelem je řízení a synchronizace funkcí systému. Komunikují pomocí vstupních a výstupních signálů. Každý řídící proces je specifikován pomocí stavového diagramu (STD) ==== Seznam událostí ==== textový výčet stimulů, jež se objevují ve vnějším světě a na něž musí systém odpovědět. Tři typy událostí: * F (flow) – tokově orientovaná událost * T (temporal) – časová událost * C (control) – řídící událost ==== Minispecifikace ==== definuje logiku procesů DFD. Pro každý proces na nejnižší úrovni rozkladu DFD existuje právě jedna minispecifikace. Forma: * Strukturovaná angličtina * Rozhodovací tabulka * Rozhodovací strom * Vstupní a výstupní podmínky * Kopenogramy ==== Stavově přechodový diagram STD ==== slouží ke specifikaci řídících procesů zakreslených na CDFD. STD se skládá ze stavů a přechodů mezi stavy, které obsahují podmínku, při jejímž splnění nastává změna stavu, a názvu akce, kterou systém provede při změně stavu. ===== Datová dekompozice===== ==== Entitně relační diagram ERD ==== definuje neměnné atributy a strukturu dat. Datový model vyjadřuje vztahy, které nejsou zachyceny v procesních modelech. Komponentami datového modelu jsou: * Entitní množiny * Relace mezi entitami. ==== Datový slovník DD ==== je seznam definicí datových prvků systému. Opisuje obsah dat v datových tocích a pamětech na DFD, entity a atributy na ERD i další klíčová slova, která se vyskytují ve specifikaci systému ====== Konzistence modelu ====== Vyvažování – vzájemná kontrola mezi modely a uvnitř hierarchie modelů ===== Vyvažování DFD a DD ===== * každý datový tok a datová paměť na DFD musí být definovány v datovém slovníku. * Každý datový element nebo paměť definované v datovém slovníku se musí vyskytovat někde na DFD ===== Vyvažování DFD – minispecifikace ===== * Každý proces na DFD musí být asociován s DFD na nižší úrovni nebo se svojí minispecifikací * Každá minispecifikace procesu musí mít sdružený proces na nejnižší úrovni DFD * U minispecifikací a jím odpovídajících procesů musí souhlasit vstupy a výstupy ===== Vyvažování DD – minispecifikace ===== Pro každý odkaz v minispecifikaci procesu musí platit jedna z následujících možností: * Souhlasí se jménem datového toku nebo datové paměti připojené k procesu, který minispecifikace popisuje * Může to být lokální název explicitně definovaný ve specifikaci * Položka v datovém slovníku je komponentou datového toku nebo datové paměti připojené k procesu ===== Vyvažování ERD – DFD + minispecifikace ===== * Paměť na DFD musí odpovídat entitní množině na ERD a naopak. * Jména entitních množin na ERD a jména datových pamětí na DFD si musí odpovídat. * Položky v datovém slovníku musí být aplikovatelné současně na DFD i ERD. * Musí existovat procesy, které přiřadí hodnoty každému datovému elementu, který je atributem na ERD. Rovněž musí existovat procesy, které tyto hodnoty čtou ===== Vyvažování CDFD a STD ===== * Pro každý řídící proces existuje stavový diagram jako jeho specifikace. Ke každému stavovému diagramu musí existovat řídící proces na DFD. * Každá podmínka ve stavovém diagramu musí odpovídat nějakému vstupnímu řídícímu toku, který vede do řídícího procesu sdruženého s příslušným STD. * Každé akci stavového diagramu musí odpovídat nějaký výstupní řídící tok řídícího procesu sdruženého s tímto STD. ===== Matice CRUD ===== * Je nástrojem vyvažování funkčního a datového modelu systému * Ukazuje, jaké typy činností provádějí jednotlivé procesy s jednotlivými datovými typy. * Řádky reprezentují položky z datového slovníku, sloupce představují procesy * Čtyři typy operací – vytvoření (C), čtení (R), změna (U) a mazání (D) ===== Matice obrazovek ===== * Kontrola specifikace rozhraní, odstranění nadbytečností a rozporů * Operace s daty – vstup (Enter), zobrazení (Display) a změna (Modify) * Řádky matice tvoří položky datového slovníku * Sloupce odpovídají jednotlivým obrazovkám uživatelského rozhraní systému ====== Metody strukturované analýzy ====== ===== Strukturovaná analýza a specifikace (SASS) ===== Analýza pomocí 4 modelů * Studie stávajícího fyzického systému * Odvození logického ekvivalentu stávajícího systému * Odvození nového logického systému * Odvození nového fyzického systému ---- * Kvantifikace cen a termínů * Výběr jedné z možností * Začlenění nového fyzického modelu do specifikace Pro modelování systému používá metodika tyto nástroje: * Diagram datových toků -- popisy modelů * Datový slovník * Strukturovaná angličtina, rozhodovací tabulky, rozhodovací stromy -- pro popis minispecifikací ===== Logické modelování ===== * Vytvoření prvotního systémového DFD * Načrtnutí datového modelu * Analýza entit a jejich vztahů -- logický datový model * Relační datový model, normalizace * Překreslení DFD podle datového modelu * Dekompozice logického procesního modelu na procedurální jednotky * Specifikace detailů každé procedurální jednotky ===== Pohledová analýza ===== * Procesně zaměřená metodika * Analýza zdola-nahoru * Pohledy mají podobnou roli jako procesy * Pohledy se kombinují do akčních diagramů, které jsou podobné DFD Základní kroky pohledové analýzy: * Identifikace pozorovacích bodů * Sdružení pohledů do skupin podle obdobné problematiky * Určení struktury pohledů ===== DSSD ===== * Datově orientovaný přístup * Nejedná se o striktně stanovenou metodiku, spíše jde o souhrn zkušeností, které vedly ve většině případů k úspěchu * Při řešení systémů dosáhli autoři nejlepších výsledků v těch případech, kdy struktura programu odpovídala hierarchické struktuře datového modelu ===== SSADM ===== * Důraz kladen na detailní a strukturovaný přístup v každé etapě životního cyklu vývoje * Používá řadu nástrojů pro zachycení a vizualizaci detailů na každé úrovni * Přístup vede k vývoji kvalitnějších produktů * Metodika rozdělena do 6 etap: - Analýza stávajícího systému - Specifikace požadavků - Výběr technických možností - Návrh logických dat - Návrh logických procesů - Fyzický návrh ====== Yourdonova metoda ====== **Esenciální model** = model okolí + model chování - Vytvoření modelu okolí systému * Dokument o účelu systému – textový dokument, který vyjadřuje cíle systému * Kontextový diagram * Seznam událostí - Vytvoření prvotního modelu chování systému * Dekompozice systému na jednotlivé procesy, toky, paměti * Postup zdola nahoru * Pro každou odezvu na událost zakreslíme do prvotního DFD jeden proces * Proces pojmenujeme podle očekávané odezvy na tuto událost * Zakreslíme esenciální paměti * Doplníme odpovídající vstupní a výstupní toky * Vytvořený DFD ověříme proti kontextovému diagramu * Hledáme seskupení vzájemně souvisejících procesů do agregovaného procesu na diagramu vyšší úrovně * Seskupení procesů má zahrnout blízké, obdobné odpovědi * Paměti zakrýváme, pokud paměť používá pouze skupina procesů na nižší úrovni * Dokončení ERD a datového modelu jako celku * Dokončení stavového modelu * Minispecifikace * Definice datových komponent - Dokončení esenciálního modelu (1 + 2) * Zjednodušení složitého DFD -- vyvažování v obou směrech * Dokončení minispecifikací procesů * Dokončení datového modelu - Vytvoření implementačního modelu * Nutno stanovit, které procesy esenciálního modelu budou při implementaci automatizovány a které budou vykonávány manuálně * Manuální procesy jsou následně nahrazeny [[http://en.wikipedia.org/wiki/Terminator_%28character%29|terminátory]], které představují osoby, jež tyto procesy vykonávají ====== Strukturovaný návrh, nástroje, metody, metriky a heuristiky návrhu ====== Přechod od výsledků analýzy k podkladům pro programování. Během návrhu jsou identifikovány moduly a jejich rozhraní. ===== Nástroje strukturovaného návrhu ===== * Graf komunikace objektů * Graf použití modulů * Jacksonovy strukturogramy * Diagram struktury systému ===== Metody modulárního návrhu ===== * Návrh na základě funkční dekompozice * Návrh na základě datových struktur * Návrh na základě datových toků * Objektově orientovaný návrh ==== Transformační analýzy ==== * Pro vstupní toky postupuj dovnitř DFD, dokud data nejsou použita ke zpracování; první hranu před zpracováním označ značkou * Pro každý výstupní tok postupuj proti orientaci toku směrem dovnitř DFD, dokud jsou data pouze formátována. Narazíš-li na skutečný výsledek zpracování, první hranu po zpracování označ značkou * Spoj značky; ohraničený podgraf tvoří centrální transformaci DFD * Pokud centrální podgraf obsahuje více procesů, připoj k DFD nový proces, přesměruj přes něj všechny toky mezi procesy z ohraničeného podgrafu a prohlas jej za centrální transformaci * Do kořene diagramu struktury umísti centrální proces upraveného DFD. Uspořádej procesy: Nejvíce vlevo procesy výhradně generující data pro centrální proces, Nejvíce vpravo procesy výhradně přijímající data, Uprostřed procesy s oběma aktivitami * Podobně pokračuj pro procesy na nižší úrovni ==== Transakční analýzy ==== * Revize základního systémového modelu * Revize a úprava sady DFD pro software * Určení, zda u DFD převažují transformační nebo transakční toky * Vymezení transakčního centra * Promítnutí DFD na programovou strukturu zodpovědnou za transakční zpracování * Faktorizace a úprava transakční struktury a struktury každé akční cesty * Úprava prvotního návrhu programové struktury podle návrhových heuristik ===== Návrhové heuristiky ===== * Vyhodnocení prvotní programové struktury s cílem redukovat propojení a zvýšit kohezi * Minimalizace rozšiřujících se struktur; snaha o sbližování větví se vzrůstající hloubkou * Snaha udržet rozsah efektu modulu v rozsahu vymezeném řízením daného modulu * Vyhodnocení modulových rozhraní s cílem redukovat jejich složitost a nadbytečnost a zvýšit kohezi * Definovat moduly, jejichž funkce je zřejmá, ale vyhnout se těm, které jsou příliš restriktivní * hledání modulů -- „jeden vstup -- jeden výstup“, nepoužívat patologické vazby * software balit s ohledem na daná návrhová omezení a požadavky na přenositelnost ~~DISCUSSION~~