Vypisky

na DFD nijak znázorněna.

Systém by neměl být rozdělen na dvě části spojené pouze
terminály -- pak by to mohly být zcela rozdílné systémy.

Pokud má terminál hodně vstupů/výstupů, může se zakreslit
vícekrát, přidá se hvězdička, aby bylo vidět, že jich
je víc.

**** Minispecifikace
Pravidla transformace vstupních toků na výstupní toky.

Strukturovaná angličtina, rozhodovací tabulky, rozhodovací
stromy, preconditions, postconditions, kopenogramy.

*** Kontrola chyb
* Černé díry
* Bílí trpaslíci
* Paměti do kterých se jen zapisuje nebo jen čte. Mají smysl jen
na rozhraní mezi systémem a terminátorem (a ne vždy je to
tolerováno).
* Komunikace je povolena jedině přes procesy

*** Control DFD
Rozšířen o řídící toky, paměti a procesy. Každý řídící proces
je popsán pomocí stavového diagramu. Na řídícím toku je
v podstatě jen binární signál -- aktivuje cílový proces.

*** Vyvažování
* Každý datový tok a každá paměť musí být v datovém slovníku
a naopak vše z datového slovníku musí být někde použito.
* Každý proces má buď DFD nižší úrovně, nebo minispecifikaci.
* Musí souhlasit vstupy a výstupy jak na nižší úrovni DFD,
tak v minispecifikaci.
* V minispecifikaci musí každé podstatné jméno označovat
něco jasně definovaného (lokální pojem, datový tok do/z
procesu, paměť připojená k procesu).
* Každá paměť na DFD musí odpovídat něčemu na ERD.
* Pro každou entitu v ERD musí někde v DFD existovat procesy,
který přiřadí nějakou hodnotu každému atributu entity.
* Pro každý řídící proces existuje stavový diagram
a naopak.
* Každá podmínka stavového diagramu musí odpovídat nějakému
vstupnímu řídícímu toku.
* Každé akci na stavovém diagramu musí odpovídat nějaký
výstup na řídícím toku.

Matice ''CRUD'' -- __C__reate, __R__ead, __U__pdate, __D__elete
-- pro každou paměť a pro každý proces máme v tabulce co
proces s danou pamětí dělá. Podobně matice ''EDM'', která
popisuje kde v GUI se dají záznamy editovat, vkládat a
kde se vypisují.


** Esenciální model
Abstrahuje od implementačních detailů (jako třeba "pošli data,
posílám data, přijal jsem data, končím komunikaci").

*** Model okolí
#modelOkoli
Popisuje rozhraní mezi systémem a okolním světem. Používá
* Účel systému -- hlavně pro vrcholový management,
popisuje hlavní cíle.
* Kontextový diagram
* [[#seznamUdalosti][Seznam událostí]]

Model by měl splňovat následující podmínky:
* Každý vstup je buď od události nebo je nutný pro odezvu
na nějakou událost.
* Každý výstup je odezvou na událost.
* Každá nečasová událost má nějaký vstup (kterým se
aktivuje její zpracování)
* Každá událost musí mít odezvu - buď nějaký výstup
nebo zápis do paměti nebo změna stavu.

*** Model chování
#modelChovani
Model chování je v podstatě zbytek DFD -- nižší úrovně, minispecifikace,
datový slovník. Současně s DFD tvoříme i ERD.

Tvorba prvotního modelu:
* Pro každou odezvu na událost udělat jeden proces, který
pojmenujeme podle odezvy.
* Zakreslíme paměti, které jsou nezbytné pro zpracování
asynchronních událostí.
* Doplníme odpovídající vstupní a výstupní toky.
* Ověříme proti kontextovému diagramu.

Tvorba hiearchie
* Dáváme dohromady podobné procesy, reagující na
podobné události.
* Na vyšší úrovni nekreslíme paměť, pokud s ní
nikdo na té vyšší úrovni nepracuje.

** Seznam událostí
#seznamUdalosti
Druhy událostí:
F (Flow) :: Sdružena s datovým tokem (příjem datových paketů)
T (Temporal) :: Vyvolána v nějakém konkrétním čase
C (Control) :: Povel, signál. Nemá přidružená data.

Příklad:
#Verbatim