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:
  1. Analýza stávajícího systému
  2. Specifikace požadavků
  3. Výběr technických možností
  4. Návrh logických dat
  5. Návrh logických procesů
  6. Fyzický návrh

Yourdonova metoda

Esenciální model = model okolí + model chování

  1. 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í
  2. 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
  3. 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
  4. 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 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
  • 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
You could leave a comment if you were logged in.
home/prog/ap13.txt · Poslední úprava: 2014/10/27 09:07 (upraveno mimo DokuWiki)
Nahoru
CC Attribution-Noncommercial-Share Alike 3.0 Unported
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0