(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)

• 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

Postřehy, nadsázky

• 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.

• 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)

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

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)

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

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

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.

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.

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

Vyvažování – vzájemná kontrola mezi modely a uvnitř hierarchie modelů

• 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

• 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

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

• 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

• 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.

• 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)

• 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

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í

• 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

• 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ů

• 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

• 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

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í

Přechod od výsledků analýzy k podkladům pro programování. Během návrhu jsou identifikovány moduly a jejich rozhraní.

• Graf komunikace objektů
• Graf použití modulů
• Jacksonovy strukturogramy
• Diagram struktury systému

• 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

• 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

• 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