Databázovéa informačnísystémy ŽIVOTNÍ CYKLUS INFORMAČNÍHO SYSTÉMU ZADÁNÍ

Databázovéa informačnísystémy ŽIVOTNÍ CYKLUS INFORMAČNÍHO SYSTÉMU ZADÁNÍ 1

Systémy 1 Obecný systém Slovo systém se používá v různých souvislostech. Původně znamenal jen seskupení, sjednocení, celek. Dnes chápeme systém jako seskupení prvků doplněné o vazby mezi nimi, o jejich uspořádanost, jejich strukturu a hierarchii. Je podobný pojmům organizace či struktura. Používá se téměř ve všech oborech lidské činnosti. Část reality, kterou chceme zkoumat, může být součástí většího systému a naopak zkoumaný objekt se může skládat z částí, které můžeme chápat opět jako systém. Jednou z důležitých věcí při definování systému jako objektu našeho zájmu je tedy určit hranice systému. Z hlediska existence systémů v závislosti na člověku můžeme rozdělit systémy na systémy přirozené (přírodní objekty) systémy umělé (vytvořené člověkem) 2

Systémy 2 Systémový přístup k řešení problémů Při práci nazveme systémem takový objekt našeho zájmu, který chceme poznat, popsat nebo vytvořit. Pro poznání a popis systému se postupně vyvinula řada metod a metodologií. Je známo, že způsoby zkoumání, popisu a návrhu systémů jsou ve svých základech stejné, ať jde o systémy z naprosto odlišných částí skutečného světa, systémy hmotné nebo nehmotné (informace). 3

Životní cyklus systému -harmonogram 1 Příklad: Úkolem je postavit dům. Aby byl výsledek úspěšný, opět nenímožné koupit cihly a začít stavět. Tisíciletími prověřené řešenírozděluje celý projekt do několika etap: 1. Rozmyslíme a zadáme, jaký dům se má postavit: obytný, rodinný dům, hotel,..., pro kolik lidí, kde bude stát, kolik máme na něj peněz, za jak dlouho atd. 2. Architekt vypracuje architektonický návrh: celkový vzhled domu, jeho zasazenído okolí, rozdělenídomu na patra, místnosti, jejich účel a vzhled atd. 3. Stavební inženýři různých profesí vypracují technický projekt: propočtou nosné části, navrhnou vhodnémateriály, vypracujídetaily řešení stavby, rozvodů vody, elektřiny apod., určí vazby domu na okolí -přívody energie, odvody odpadů atd. 4. Řemeslníci provedou dle technickédokumentace realizaci domu. V průběhu stavby provádí stavebnídozor kontrolu, kontroluje pořadía kvalitu provedení. 5. Provede se kolaudace, hledajíse nedostatky. Odstraní se nedostatky. 6. Do hotového domu se nastěhujílidé, provedou připojení vazeb na okolí (zjistí dopravní spojení, přihlásíadresu, elektřinu, plyn,...), naučí se zacházet s novým zařízením (topení, bezpečnostní zařízení,..) atd. 7. Dům se obývá, udržuje, v případě poruchy opravuje atd.. 4

Životní cyklus systému 2 Při řešení každého většího díla je vhodné dodržovat tyto etapy: 1. formulovat zadání, popsat požadavky na výsledné dílo, 2. analyzovat věcné požadavky detailně, vytvořit modely výsledku, 3. na základě vytvořených modelů popsat způsob technického provedení díla a jeho částí, 4. realizovat dílo podle technického popisu, 5. otestovat správné fungování všech požadovaných funkcí díla, 6. předat dílo zadavateli, 7. používat dílo, případně jej dále udržovat. 5

Životní cyklus vývoje systému 3 Závěr: informační systém je umělý systém, vytvářený člověkem, větší dílo, proto je nutné dodržovat systémový postup při jeho tvorbě. Existuje několik typů životního cyklu vývoje SW díla (tedy i IS): vodopádový spirálový 6

Životní cyklus informačního systému 1 Zadání vodopádový model Analýza Návrh implementace Implementace Testování Předání do provozu Provoz, údržba 7

Životní cyklus informačního systému 2 Zadání -SPECIFIKACE POŽADAVKŮ Nápad - využít pro řešení (evidenci) něčeho počítač. Písemnézadání, slovně (obvykle nejednoznačné, neúplné, nepřesné). Analýza - SPECIFIKACE PROBLÉMU Studium problému dříve, než se začne s řešením, model slouží jako podklad pro další řešení. Za řešení se považuje i odůvodněnénegativní stanovisko. Návrh ovládání programu a jeho vzhledu, prototyp. Návrh - NÁVRH IMPLEMENTACE, programování ve velkém Systémový návrh Optimalizace algoritmů, implementační podrobnosti, analýzy. Dekompozice řešení na moduly. Programování -IMPLEMENTACE A DOKUMENTACE Implementace dílčích částí, ladění modulů, syntéza modulů. Zpracování dokumentace programu. 8

Životní cyklus informačního systému 3 Testování -TESTOVÁNÍ SYSTÉMU Testování, zda se chování systému shoduje s představou uživatele, se specifikací a dokumentací, zda nemáchyby. Předání -ZAVEDENÍ SYSTÉMU DO PROVOZU Předáníuživateli, přechod na nový způsob práce, zaškolení. Napojenína okolísystému, na vstupy a výstupy Provoz - PROVOZ, ÚDRŽBA A ROZVOJ Sledováníprovozu, opravy chyb programu i dokumentace, údržba. Připomínky, návrhy na zlepšení, doplněníap. 9

Zadání, specifikace požadavků IS 1 Zadavatel přijde s návrhem zadání. Zadání je nutné vyžádat od zadavatele písemně. Mělo by obsahovat (nebo si řešitel vyžádá doplnění) tzv. funkční a nefunkční požadavky. Funkční požadavky PROČ nový systém. ČEMU má sloužit. KDO s ním pracuje -běžně, příležitostně, pravidelně zřídka. VSTUPY objekty, atributy VÝSTUPY výstupní sestavy, požadované informace FUNKCE jaké výpočty, odvozování, výběry, třídění,... Vazby na OKOLÍ systému odkud data a kam. Formalizace funkčních požadavků -modely vnějšího chování Je vhodné je vyžádat od zadavatele -uplatní se při analýze. 10

Zadání, specifikace funkčních požadavků IS 1 Příklad: IS domácí videotéka (zestručněná verze) PROČ: potřebuji vést evidenci svých kazet a programů na nich nahraných. Zatím nemám žádnou evidenci, občas omylem koupím znovu tutéžkazetu, občas zapomenu, komu jsem něco půjčil. Při hledání vlastních nahrávek složitě vyhledávám program na několika kazetách, až najdu, co potřebuji. KDO: se systémem budu pracovat jen sám nebo rodinní příslušníci. VSTUPY: nutné informace o kazetách a programech, aby se mohly realizovat všechny funkce: název a autor programu, délka, VÝSTUPY: různé seznamy programů a na kterých kazetách jsou, co mi kdo dluží a kdo si jak často co půjčuje, jestli užněkterou kazetu mám. FUNKCE: systém má umět: Při objednánía nákupu nových kontrolovat, zda je užnemám. Při výpůjčkách přátelům vést záznam kdo a kdy si je půjčil a vrátil. Při výběru pro přehrávání vybírat podle žánrů, autorů, interpretů, délky. OKOLÍ: já, moji přátelé, autoři a prodejci kazet. 11

Zadání, specifikace funkčních požadavků IS 2 Formalizace zadání -modely vnějšího chováníis Cílem modelů vnějšího chování systému je popsat vytvářený systém jako černou skříňku, definovat její vnější chování a strukturalizovat okolí systému, které se systémem komunikuje. Modely jsou vhodné jako prostředek komunikace analytika se zadavatelem pro upřesňování a zpodrobňování zadání. 1. Proč, k čemu, kdo: Slovní popis současného stavu, proč nevyhovuje, jak se má lišit nový IS; jaká je hlavní priorita provozu IS; kdo s ním bude pracovat. 2. Vstupy: Seznam evidovaných objektů a jejich atributů. 3. Výstupy: Seznam výstupních sestav s jejich náčrtkem nebo seznamem atributů u jednotlivých sestav. 4. Funkce: seznam událostí a reakcí 5. Okolí: Kontextový diagram Model jednání (Use Case) 12

Zadání, specifikace funkčníchpožadavků IS 3 Zadání funkcí: seznam událostí a reakcí Model má za úkol získat od zadavatele seznam všech funkcí, které bude od IS požadovat. IS odráží realitu, i každá funkce IS je reakcí na nějakou událost. Sestaví se tabulka se sloupci událost a reakce, do ní se formou krátkých textů zapisují všechny možné vnější události, podněty působící na systém a jim odpovídající reakce systému. Události se někdy dále dělí na F -událost: vstup dat do systému (nová objednávka,...) T - událost: řízení vnitřními hodinami systému, nenese data (denně v 24.00, konec měsíce,...) C - událost: zvláštní případy, výjimečné události na pokyn zvenčí, událost nenese data ani čas (alarm, zablokuj dveře,...) 13

Zadání, specifikace funkčníchpožadavků IS 4 Seznam událostí a reakcí = požadované funkce systému Příklad: Události a reakce systému Knihovna událost nový čtenář výpůjčka knihy vrácení knihy novákniha ztracenákniha konec roku reakce zapiš do seznamu čtenářů zapiš výpůjčku zapiš vrácení...... výpočet účetní inventury aktér 14

Zadání, specifikace funkčníchpožadavků IS 5 Okolí: kontextový diagram = strukturování okolí systému, kdo a jak se systémem spolupracuje. Systém jako černá skřínka, neví se nic o jeho vnitřní struktuře. Nejvyšší DFD. Příklad: Kontextový diagram systému Knihovna 15

Zadání, specifikace funkčníchpožadavků IS 6 Okolí a funkce: model jednání = propojuje informace kontextového diagramu se seznamem událostí a reakcí, přiděluje události jednotlivým aktérům. Slouží k jemnější strukturalizaci okolí. Příklad: Část modelu jednání systému Knihovna 16

Zadání, specifikace funkčníchpožadavků IS 7 Aktér je část okolí systému, která komunikuje s vytvářeným systémem. Aktér je role uživatele, může to být člověk, či jiný systém, není to uživatel. Jeden člověk může působit jako několik aktérů. Aktéři se mohou například lišit právy (administrátor systému je jiná role než prostý uživatel), nebo způsobem zacházení s daty (uživatel vkládající data je jiný aktér, než uživatel, který si data jen prohlíží). Aktéra opět značíme obdélníkem. 17

Zadání, specifikace nefunkčníchpožadavků IS Nefunkční požadavky Požadavky na výsledný program: efektivita (požadovaná rychlost, výkon, paměťová náročnost), spolehlivost, přenositelnost a použitelnost. Požadavky na způsob řešení: často určují metodu, použití standardů z oblasti metodiky vývoje, dokumentace, programovací jazyk, prostředí (celkem podmínky dodání, implementační požadavky a použití standardů). Vnější požadavky: ostatní nefunkční implementační požadavky, použití standardů, cenová omezení, časové požadavky, požadavky na spolupráci nového systému s již existujícími systémy, daná organizační struktura, bezpečnost, omezení daná legislativou, platné zákony, vyhlášky, atesty apod. Příklad: Provozovánína PC pod operačním systémem Windows XP, bez nutnosti kupovat nový software, máme MS Office. Ty se uplatní až při návrhu implementace, ne při analýze. 18

Zadání, specifikace nefunkčníchpožadavků IS Příklad: Knihovní IS pro rozsáhlou veřejnou knihovnu s beletrií i odbornou literaturou požaduje: 1. Není nutné co nejrychlejší ukončeníis, nejdůležitější je rychlost odezvy systému při vyhledávání publikacípodle různých kritérií, export a import dat při spolupráci s jinými knihovními systémy, dále také bezpečnost evidovaných dat (zálohování). 2. Nejsou požadavky na metodiku řešení ani implementačníprostředí, pokud budou dodrženy standardní způsoby ovládání systému. 3. Cena max. xxx Kč. Harmonogram požadujeme nejprve realizovat a předat všechny vstupnífunkce (knihovníci mohou ukládat data již současně s dalším vývojem systému). Spolupráce IS s knihovními systémy ABC a XYZ. Dodržení knihovního zákona. 19

Databázovéa informačnísystémy ANALÝZA INFORMAČNÍHO SYSTÉMU 20

Analýza -Informační systém a jeho dimenze Zkoumání a modelování IS 3 základní dimenze: data, operace a čas, odtud 3 základní typy analýzy IS datová, funkční, časová Orientace modelů programových systémů Procesně orientovaný (funkční) přístup modeluje systém z hlediska akcí, pomocí procesů, které jsou propojeny datovými toky; procesy realizují transformace dat (systémy pro podporu technických výpočtů, expertních systémů ap.). Datově orientovaný přístup modeluje základní datové struktury, funkční stránka je druhá (pro IS), časová závěrečná. Dynamicky orientovaný (časový) přístup modeluje časové posloupnosti stavů systému (real-time systémy), pak fční, pak datová. Objektově orientovaný přístup modeluje systém jako množinu spolupracujících objektů, kde operace působící na objekty jsou zapouzdřeny v samotných objektech (jiná filozofie než u DB). 21

Analýza IS Analýza je studium problému (jeho poznání, popis, modelování) dříve, než se začne s řešením. Úkolem analýzy je zpracování několika typů modelů budoucího systému. Model slouží jako podklad pro další řešení, je to abstraktní obraz budoucí reality. Vytváří se pro správné pochopení struktury a funkcí systému a pro dorozumění mezi uživatelem, analytikem a realizátorem. Pro IS se vytváří 3 typy analýzy v tomto pořadí: 1. datováanalýza (konceptuální schéma, návrh struktury databáze 3NF) 2. funkční analýza (operace=funkce=algoritmy vykonávané nad databází) 3. dynamická analýza (časová následnost operací, stavy databáze a IS) 22

Analýza IS V analýze IS se obvykle vychází z Yordonovy strukturované analýzy = metodologie pro vývoj IS. Ta obsahuje pro datovou analýzu: ERD, konceptuální schéma pro funkční analýzu: DFD + minispecifikace pro časovou analýzu: STD, ELH 23

Datováanalýza a datový model IS Datová analýza zpracovává datový model na konceptuální úrovni. Ze zadání se vyberou potřebné evidence objektů a jejich atributů, určí se funkční závislosti mezi atributy, pomocí již známých metod se navrhne struktura databáze v alespoň 3NF (= vznikne seznam entit a jejich atributů, entity se pojmenují). Výsledný konceptuální model obsahuje lineární zápis seznamu typů entit a jejich atributů úplný grafický tvar ERD (2 úrovně) 1. konceptuální schéma modelující realitu 2. transformovaný ERD pro databázovéschéma úplné tabulky atributů datový slovník seznam dalších IO týkajících se entit a vztahů 24

Funkční analýza a funkční model IS Je-li hotov návrh struktury databáze, navrhují se funkce nad ní. Funkční analýza vychází opět ze zadání IS. Je výhodné, když se v zadání vyskytují následující prvky(viz zadání): 1. Seznam funkčních požadavků na vnitřní chování systému nebo seznam událostí a reakcí. 2. Požadované vstupy a výstupy. Z nich vytváří analytik funkční model: vnější pohled hrubý (graficky pomocí DFD), vztahy a hierarchie funkcí vnitřní pohled podrobně rozpracovává jednotlivé akce = algoritmy, minispecifikace. 25

Funkční analýza -diagram datových toků DFD Grafický nástroj pro modelování vztahů funkcí (algoritmů) popisuje algoritmy systému, transformace dat z jedné formy do druhé; modeluje funkce systému pomocí grafu a přitom používá následujících základních grafických prvků: procesy proces datové paměti datový tok aktéry datové toky aktér paměť 26

Diagram datových toků -DFD Proces (transformace, funkce) provádí transformaci dat vstupních na data výstupní, realizuje nějakou funkci nad daty. nové zboží Datové procesy vyjadřují fyzickou transformaci dat - změnu reprezentace dat nebo změnu stavu dat, modifikaci údajů, vznik nových údajů, zrušení údajů; úkolem datového procesu je zpracovávat data. Řídicí procesy provádějí řídicí akce, řídí vzájemné časové návaznosti procesů; používají se k popisu časových charakteristik aplikace; nezpracovávají data. Každý proces v DFD má svůj název a jednoznačné číslo (hierarchie) 27

Diagram datových toků -hierarchie DFD Pravidla týkající se funkcí Neexistuje proces generující výstupy bez vstupů (perpetum mobile). Neexistuje proces se vstupy bez žádných výstupů (černá díra). Neznázorňují se žádné inicializační ani závěrečné procedury. Neznázorňují se cykly mezi funkcemi. Datové procesy (neřídicí) nesmějí být propojeny řídicími toky. Žádné dvě funkce nesmí mít stejný název. Názvy procesů stručné, pojmenují věcně funkci procesu (Vystavení faktury, ne Zpracování dat). 28

Diagram datových toků -DFD Datový tok Datový tok vyjadřuje přesun dat nebo informací z jedné části systému do jiné, z okolí systému do systému nebo ze systému do jeho okolí. nový materiál Datový tok musí mít známý obsah, je pojmenovaný (explicitně nebo implicitně). Obsahuje data do systému vkládaná, systémem zpracovávaná nebo ze systému vypouštěná. 29

Diagram datových toků -hierarchie DFD Pravidla týkající se datových toků Datové paměti jsou propojeny jen prostřednictvím funkce, tedy datový tok do / z paměti musí vycházet z / do procesu. Datový tok z / do terminátoru musí procházet přes proces. Datové toky mezi funkcemi znázorňují pouze přenášená data, nevyjadřují volání jedné funkce druhou ani předávání řízení. Datový tok s týmž názvem může být v DFD použit na více místech, pokud název znamená skutečně tentýž obsah. Doporučuje se dodržovat označení datového toku z/do datové paměti: -bez označení = přenáší se jeden výskyt datové paměti -označen datovou pamětí = přenáší se jeden nebo více výskytů -označen jednoznačně jinak = přenáší se část výskytů. 30

Diagram datových toků -DFD Datová paměť (data store, zásobník) Paměť je místo (dočasného) uchování dat pro jejich pozdějšívyužití. Je to obecnější pojem než datový soubor (pole, soubor textový, soubor databázový, kniha, šanon apod.). Používá se tam, kde mezi procesy existuje časové zpoždění při předávání dat. materiál Pro každou paměť musí existovat alespoň jeden datový tok směřující do paměti a jeden směřující z paměti. Datový tok může vyjadřovat 1 výskyt dat, více výskytů dat, část jednoho výskytu či část z více výskytů. Paměť je pasivní prvek, data do paměti i z paměti musí vždy procházet přes proces. Paměť je další formou propojení procesů. 31

Diagram datových toků -hierarchie DFD Pravidla týkající se datových pamětí Paměti se objeví až na té úrovni, kde jsou viditelné funkce do pamětí zapisující a z pamětí čtoucí. Vyhledání pro aktualizaci paměti se chápe jako součást zápisu do paměti, nevyznačují se zvláštní šipkou; šipka dovnitř znamená jakékoliv provádění změn (vkládání dat, aktualizaci, rušení). V paměti jsou uloženy výskyty dat se stejnou strukturou. Jestliže tok z / do paměti přenáší celý výskyt, nemusí se pojmenovávat, je určen obsahem a názvem paměti. 32

Diagram datových toků -DFD Aktér (terminátor) Aktér znázorňuje externí zdroj nebo cíl dat, objekt vně systému, s nímž systém komunikuje. Může to být člověk, skupina lidí (oddělení), jiný systém apod. Platí : > aktéři jsou vně IS, toky mezi nimi a systémem představují rozhraní mezi systémem a vnějším světem, > analytik nemá možnost měnit organizaci a chování entit vně systému ani změnit chování aktérů, > případné vztahy mezi aktéry se v DFD nezachycují, nesouvisí s IS zákazník IS Sklad 33

Diagram datových toků -hierarchie DFD Model systému pomocí DFD má hierarchickou strukturu. Na vrcholu hierarchie DFD zvaný kontextový. Obsahuje celý systém jako jednu funkci, definuje hranice systému a všechny aktéry - zdroje a cíle dat. Systém je zde černá skříňka s definovanými vstupy a výstupy. Příklad: Dodavatel IS Sklad Zákazník Výroba Skladník 34

Diagram datových toků -hierarchie DFD Bezprostředním rozkladem kontextového diagramu je DFD úrovně 0. Obsahuje základní funkce systému (rozklad na subsystémy) a jejich vztahy prostřednictvím datových toků a pamětí. Dodavatel Zákazník 1 2 příjem výdej sklad Výroba 3 4 Skladník objedn výpisy 35

Diagram datových toků -hierarchie DFD Další rozklad funkcí obdobně. Každá funkce, kterou je možno dále rozložit, se rozkresluje novým diagramem nižší úrovně až na elementární úroveň. Číslování procesů identifikuje úroveň rozkladu i proces v úrovni (např. 2.4.3) Výroba 3 Sklad Dodavatel 3.1. 3.2. nová objedn splnění obj Nejnižší úroveň obsahuje elementární = uživatelsky dále nedělitelné funkce. Platí: - činnosti se provádějíjako celek -jsou buď celé ruční nebo automatizované -jsou opakovatelné -jsou elementární, nemají další podrobnější DFD. 36

Diagram datových toků -hierarchie DFD Pravidla tvorby DFD Složitost jednoho DFD nepřesahuje velikost A4, neobsahuje velké množství uzlů (+- 6 uzlů, rozmezí 3-9), srozumitelný pro uživatele, analytika a návrháře Diagram technicky správný (konzistentní), srozumitelný, přehledný a esteticky uspořádaný (bubliny stejně velké, toky se nekříží ap., překreslovat až do grafické dokonalosti). Konzistence DFD, logická soudržnost diagramů, paměti, aktéři, datové toky v nižší úrovni odpovídají vyšší úrovni, jsou podrobnější uvnitř popisované funkce 37

Diagram datových toků -minispecifikace Minispecifikace = algoritmy elementárních funkcí pro nejnižší úroveň DFD (dále nedělitelné elementární funkce). Mnoho forem popisu - od přirozeného jazyka až po formální jazyky. Vždy je třeba dodržet následujícípravidla pro minispecifikace: Existuje jedna pro každou elementární funkci z množiny DFD, kontrolou je seznam požadovaných funkcí ze zadání. Popisuje algoritmus, jak jsou datové toky do funkce vstupující transformovány na výstupní datové toky. Vyjadřuje, co funkce znamená věcně, nemusí vyjadřovat způsob implementace funkce. Nezavádí redundandní popisy, nevyjadřuje znovu, co je popsáno v DFD nebo v datovém slovníku (domény atributů, klíče, ) Množina výrazů pro popis by měla být jednoduchá a nepříliš rozsáhlá, má používat standardní vyjadřování. Musí být srozumitelná uživateli, analytikovi i programátorovi. 38

Diagram datových toků -minispecifikace Jazyky pro popis minispecifikace Nepřílišvhodné programovací jazyk zatím přílišpodrobný, nerozumí zadavatel vývojový diagram neumožňuje popsat vše dostatečně... Budeme používat strukturovaný jazyk (návrh De Marco) Strukturovaný jazyk je přirozený jazyk doplněný o omezující pravidla tvorby vět (syntaxe), aby výsledný popis nepřipouštěl několik různých výkladů. V anglicky mluvících zemí je to ekvivalent jazyka Pascal, lze používat rozšířených funkcí, pro uživatele přirozené (strukturovaná angličtina). Pro komunikaci s českým uživatelem nevhodný, proto strukturovaná čeština -s dodržením přesných formulací v češtině se uživatel smíří. 39

Diagram datových toků -minispecifikace Slovník jazyka je složen z rozkazovacího způsobu sloves pro příkazy algoritmu pojmů (podstatných jmen) z datového slovníku níže uvedených rezervovaných slov pro formulaci logiky procesu Syntaxe jazyka obsahuje řídicí struktury pro definování procesu jednoduché rozkazovací věty ~ sekvence uzavřené rozhodovací formule ~ větvení (1) JE-LI podm PAK činnost1 JINAK činnost2 (2) VYBER ALTERNATIVU PŘÍPAD 1: podm1 činnost pro platnou podmínku 1 PŘÍPAD 2: podm2 činnost pro platnou podmínku 2... JINAK činnost pro ostatní případy 40

Diagram datových toků -minispecifikace Syntaxe jazyka obsahuje řídicí struktury pro definování procesu jednoduché rozkazovací věty ~ sekvence uzavřené rozhodovací formule ~ větvení uzavřené opakovací formule ~ cykly (1) DOKUD podm DĚLEJ opakovaná činnost (2) PRO KAŽDÝ paměť DĚLEJ opakovaná činnost (3) DĚLEJ opakovaná činnost DOKUD podm 41

Diagram datových toků -minispecifikace Algoritmus musí být strukturovaný, používat standardní programové řídicí struktury sekvenci větvení cykly procedury Algoritmus musí rozlišovat jako samostatné body: příkazy, kteréprovádí program a činnosti, kteréprovádíuživatel příkazy manipulující s databází (čtení záznamů, ukládání, modifikace a rušení) a příkazy ostatní, prováděnév paměti počítače. Další zásady je vhodnérozlišovat identifikátory údajů v databázi a v paměti pracovně se zobrazují i obrazovky pro komunikaci s uživatelem a výstupní sestavy Minispecifikace jsou vstupem pro etapu návrhu implementace, tam jsou doplněny řadou implementačních podrobností. 42

Datováa funkční analýza -příklad IS Sklad Příklad: Zadání: Firma bere objednávky od zákazníků na daný počet a danou velikost oken. Vypočte spotřebu materiálu, objedná ho, uloží na sklad, odtud bere do výroby. Pro SKLAD je potřeba zajistit hevidenci materiálu, nakupovaného od různých výrobců, ceny nestálé, hje třeba evidovat příjmy a výdeje ze skladu, výdeje propojit se zakázkami hmusí být možnost návratu nespotřebovaného materiálu do skladu hje třeba evidovat vydaný materiál pro jednotlivé zakázky a vystavovat na ně faktury hměsíčně je třeba spočítat sumu příjmů a sumu výdejů a zaznamenat je do účetnictví hnutnost výpisu inventury zpětně ke dni 43

Datováa funkční analýza -příklad IS Sklad Příklad: Zadání: Firma bere objednávky od zákazníků na daný počet a danou velikost oken. Vypočte spotřebu materiálu, objedná ho, uloží na sklad, odtud bere do výroby. Pro SKLAD je potřeba zajistit hevidenci materiálu, nakupovaného od různých výrobců, ceny nestálé, někdy množstevní slevy, některý materiál balený velkoobchodně hve skladu je i spotřební materiál pro režii firmy papír,, potraviny do automatu, hje třeba evidovat příjmy a výdeje ze skladu, propojit je se zakázkami hmusí mít možnost návratu nespotřebovaného materiálu do skladu hměsíčně je třeba spočítat sumu příjmů a porovnat se sumou na fakturách, hměsíčně je třeba spočítat sumu výdejů a zaznamenat ji do účetnictví hnutnost výpisu inventury zpětně ke dni 44

Datováa funkční analýza -příklad IS Sklad Příklad: Analýza datová Struktura databáze (zde jen výsledek, ne postup při návrhu) Sklad (karta, nazev, cidod, cenj, mnoz, min, max) Pohyb (karta, datum, cizakaz, změna, cifak, mnoz, cenpri) Dodav (cidod, firma, ICO, ) Zakaznik(cizak, firma, ) Zakazka (cizakaz, cizak, ) Faktp (cifak, datum, tespl, dazap, suma, ) Faktp Dodavatel Sklad Pohyb Zakázka Zákazník 45

Datováa funkční analýza -příklad IS Sklad Příklad: Analýza funkční Požadovanéfunkce v zadání: záznam novékarty materiálu příjem materiálu nenípřijatáfaktura, jen dodací list (nejprve množství, potom ceny) výdej materiálu návrat materiálu žádanka - výdejka zrušení pohybu (příjmu, výdeje, návratu) libovolný výpis skladů, pohybů inventura materiálu měsíční příjmy, porovnáním s fakturami měsíční výdej návrat, rozpočítání nákladů režijního materiálu kontrola množství objednávky chybějícího materiálu ročníuzávěrka, počáteční stavy, archivace záznam, modifikace, rušení v číselnících 46

Datováa funkční analýza -příklad IS Sklad Příklad: Analýza funkční Kontextový diagram Dodavatel IS Sklad Zákazník Výroba Skladník Účtárna 47

Datováa funkční analýza -příklad IS Sklad Příklad: Analýza funkční Minispecifikace fce 1.1. příjem do skladu Pro všechen přijatý materiál na faktuře dodavatele připočtedo tabulky Sklad na příslušnouskladovou kartu nový materiál, příjem zapíše jako nový záznam do Pohyb. Pohyb Dodavatel 1.1. příjem do skladu Zakázka cizakaz sez_karet nove_mnoz cifak Sklad Faktp Doplnit do DD: sez_karet (karta,nazev,cidod,cenj,mnoz) nove_mnoz (mnoz, cenpri), cizakaz, cifak pokr. 48

Příklad: Minispecifikace fce 1.1. příjem do skladu - algoritmus 1. Suma=0 2. Pro všechen přijatý materiál na faktuře dodavatele proveď 3. zobraz seznam karet ze Sklad atributy karta nazev cidod cenj mnoz 4. uživatel vybere kartu 5. zapamatuj Sklad.karta, Sklad.nazev, Sklad.cenja Sklad.mnoz 6. zobraz formulář příjmu pro vybranou kartu karta : vybraná, opsáno ze Sklad, jen pro čtení název : opsáno ztabulky Sklad, jen pro čtení změna : =1 (příjem), bez editace datum : dnešní, možnost přepsat, kontrola na měsíc mnoz_prij : >0 cen_prij: >0 nebo NULL cizakaz : kontrola na existenci vzakázka nebo NULL cifak : kontrola na existenci ve Faktpnebo NULL 7. uživatel vyplníformulář pro přijímaný materiál 8. vypočti nové množství ve skladu: Sklad.mnoz = Sklad.mnoz+mnoz_prij, cenu jednotkovou zprůměrovanou Sklad.cenj průběžnou sumu cen: Suma=Suma+mnoz_prij*cen_prij 9. zapiš vyplněný formulář jako nový záznam do Pohyb 10. modifikuj v záznamu Sklad.karta hodnoty Sklad.mnoz a Sklad.cenj 11. Konec cyklu pro jeden materiál 12. Vypiš pro kontrolu seznammateriálus celkovou cenou faktury karta název množ-přijato cenj cena suma... 49

Příklad: Je dána databáze konkrétní NEMOCNICE Pokoj (cislo-pok, kapac-pok) Pacient (rodcis, jmeno, cislo-pok) Operace (rodcis, druh-oper, hodina, datum, jmeno-lek) Lekar(rodcis, jmeno-lek, obor) Jeden pacient může jít na operaci i vícekrát. Napište minispecifikaci pro funkci Záznam novéoperace Agoritmus (3 ukázky špatně formulovaných algoritmů) vyber pacient vyber lekar zadej druh operace, hodina, datum zjisti, zda lekar nemáv datum, hodina operaci pokud máoperaci, pak zadej hodina, datum zadej rodcis jestliže rodcis neexistuje, pak zadej znovu jinak zadej druh operace pak zadej datum, hodina jestliže datum, hodina je už v databázi vyber formulář operace zadej RČ,druh,hodina,datum,jm_lek pokud je stejne, jdi na konec jinak zkontroluj RČ mezi pacienty jestli druh operace v nabidce lékař má čas v daný datum zapamatuj údaje ve formuláři ulož změny operace aktualizuj formulář 50

Příklad: Pokoj (cislo-pok, kapac-pok) Pacient (rodcis, jmeno, cislo-pok) zřejmě jen aktuální Operace (rodcis, druh-oper, hodina, datum, jmeno-lek) Lekar(rodcis, jmeno-lek, obor) Agoritmus:Záznam novéoperace 1. zobraz formulář Nováoperace Rodné číslo pacienta: nabídka z Pacient (rodcis, jmeno) Jméno pacienta: doplň z Pacient po optickou kontrolu Druh operace: nabídka doplnit číselník Druh-oper Datum: Hodina: (datum sysdatum, hodina <0, 23>) Lékař: nabídka z Lekar (jmeno-lek) 2. uživatel lékař vybere pacient, druh-oper, jmeno-lek, doplní datum, hodina 3. zkontroluj jednoznačnost (datum, hodina, lekar) v Operace je-li chyba, zobraz chybovéhlášení a vrať se k bodu 1. 4. zapišnový záznam (rodcis, druh-oper, hodina, datum, jmeno-lek) do Operace Chyby: NE vyberu z Pacient vytvoří se novákarta Operace vybrání pacienta stiskne se tlačítko 51

Datováa funkční analýza -příklad IS Sklad Příklad: SKLAD Analýza funkční Minispecifikace fce 4.1. Inventura skladu zpětná Sklad naz_karty 4.1. Spohyb inventura Skladník Pohyb Spohyb datum Vypíše stav materiálu na kartách zpětně k zadanému dni Doplnit do DD: Spohyb (karta, změna, mnoz) naz_karty (nazev, cenj) datum pokr. 52

Datováa funkční analýza -příklad IS Sklad Příklad: SKLAD Analýza funkční Minispecifikace fce 4.1. Inventura skladu zpětná Obsah tabulky Pohyb (karta, datum, cizakaz, změna, cifak, mnoz, cenpri) změna: 0 = počáteční stav karta datum cizakaz změna cifak mnoz cenpri 1 = příjem 2 = výdej 6 1.1.05 0 20 3 = vrácení 6 4.1.05 345 2 10 6 6.1.05 1 123 50 3.00 6 6.1.05 456 2 20 6 10.1.05 456 3 5 53

Datováa funkční analýza -příklad IS Sklad Příklad: SKLAD Analýza funkční Minispecifikace fce 4.1. Inventura skladu zpětná Algoritmus 1. zobraz dotaz Datum požadovanéinventury: 2. uživatel zadá hodnotu do Pdatum kontrola na Pdatum<= Sysdatum 2. vyber zpohyb záznamy s datum <= Pdatum, uložjedo tabulky SPohyb 3. setřiď SPohybpodle karta,změna (= druh pohybu) 4. pro každou kartu z SPohyb sesumuj: mnpoc, mnpri, mnvyd, mnvra 5. vypočti mnoz= mnpoc+ Σmnpri -Σmnvyd + Σmnvra 6. vypiš seznam: Inventuraskladukedni. karta množ cenj cena ========================= 6 50 2.50 125.00... ========================= Celkem 2 765.90 54

Funkční analýza -Diagram funkční struktury DFS Diagram funkční struktury (DFS) zobrazuje hierarchickou strukturu funkcí. DFD dělázvětšeniny funkční struktury systému, DFS zobrazuje průřezy hierarchie funkční struktury. DFS zobrazuje, ze kterých podřízených funkcí se popisovanáfunkce skládá, nepopisuje jejich vzájemnou komunikaci. Sklad 1 Příjem 2 Výdej 3 Objedn 4 Výpisy 3.1 Nováobjed 3.2 Splnění objed 55

Funkční analýza -Diagram funkční struktury DFS Pro DFS lze formulovat následující integritní pravidla: pro každý DFD obsahuje DFS jeden prvek; pro každou elementární funkci obsahuje DFS jeden prvek nejnižší úrovně; rozklad jednoho prvku DFS (jedné funkce) musí počtem a identifikací podřízených prvků odpovídat DFD, popisujícímu strukturu této komunikace; DFS je jakýmsi obsahem všech DFD, je vhodné ho uvádět na začátku výsledného funkčního modelu (ale vytvořit po rozkladu DFD). 56

Dynamická analýza IS Analýza dynamická Diagram přechodu stavů STD Životní cyklus entity ELH 57

Dynamická analýza -stavový diagram STD Diagram přechodu stavů STD STD (State Transition Diagram) slouží k modelování chování systému v časových návaznostech, tj v závislosti na čase nebo na pořadí funkcí. Popisuje časové následnosti procesů, které DFD nezaznamenává, modeluje chování systému v závislosti na působení vnějších událostí nebo na základě vnitřních změn stavů. Definují se stavy, v nichž se systém nebo entity mohou během svého života nacházet nebo vnitřní stavy čekání na událost. Definují se přechody mezi stavy a události, které tyto přechody způsobují. Ukazuje, které události mohou být v daném stavu přijaty ajak na ně systém reaguje. Událost je impuls, kterým jeden objekt nebo aktér vyžaduje reakci jiného objektu nebo aktéra. Události buď přenášejí data (od aktéra do systému, mezi objekty systému ap.) nebo jde o externí událost, impuls z okolí systému, nebo o interní událost zevnitř systému (při jisté konfiguraci hodnot atributů objektů). 58

Dynamická analýza -stavový diagram STD Diagram přechodu stavů STD Stav je podmnožina hodnot atributů jednoho nebo více objektů (typů entit). Za určitého stavu má objekt jeden druh chování, při změně stavu se mění i jeho chování. Přechod mezi stavy je taková změna hodnot atributů, že objekt přejde z jednoho stavu do druhého. Je to buď modifikace hodnot atributů nebo změna časová nebo vnitřní impuls systému či impuls vnější. Změna stavu nastane při rozpoznání, že je splněna nějaká podmínka. Ze stavu do stavu přejde systém provedením určitých akcí. Akce je provedení (elementární) funkce, operace nad objektem. Aktivita je logicky konzistentní činnost, kterou realizuje objekt své chování. Je to posloupnost akcí. Celkové chování objektu se skládá z aktivit. 59

Dynamická analýza -stavový diagram STD Diagram přechodu stavů STD podm akce stav1 stav2 podmínka: podm1; podm2; ; podmn přechod způsobí kterákoliv z nich akce: akce1;akce2; ; akcem akce se provedousekvenčně 60

Dynamická analýza -stavový diagram STD Diagram přechodu stavů STD Vnitřní přechody znamenají zpracování události s případnými připojenými akcemi beze změny stavu. Zapisují se do stavu a mají stejný tvar, jako událost zapsanéu přechodu. entry je událost, ke které dochází bezprostředně po každém vstupu do daného stavu. exit je událost, ke které dochází bezprostředně před každým opuštěním daného stavu. do je aktivita trvání stavu; stav může skončit sám od sebe, je-li jeho trvání spojeno s nějakou činností -pak je podmínka trvání formulována za do (není zaplacena celá částka faktury, systémový čas < 24:00 ); pakjejedinývýstup bez popisu. 61

Dynamická analýza -stavový diagram STD 62

Dynamická analýza -stavový diagram STD 63

Dynamická analýza -stavový diagram STD Hierarchie STD Reálný systém mívá obvykle desítky stavů, které se na jeden diagram nevejdou, nebo by byl nepřehledný. V tom případě se používá členění diagramů do hierarchické struktury, obdobně jako u DFD. Každý stav vyšší úrovně může být popsán samostatným STD nižší úrovně,vazbu mezi úrovněmi je vhodné zviditelnit číslováním stavů podle podobných pravidel, jako u DFD. 64

Dynamická analýza -stavový diagram STD 65

Dynamická analýza -stavový diagram STD Příklad 66

Dynamická analýza -stavový diagram STD 67

Dynamická analýza -stavový diagram STD Kontrola konzistence stavů Identifikujeme všechny stavy, zakreslíme je, hledáme přechody a zakreslíme. Vyjdeme z počátečního stavu, hledáme všechny možné změny, zakreslíme a pokračujeme pro nově vzniklé stavy. Kontroly: byly definovány všechny stavy? jsou všechny stavy dosažitelné? lze všechny stavy opustit? odpovídá chování systému v každém stavu všem možným podmínkám? Kontroly lze prověřit pomocí matice stavů. 68

Analýza IS -dynamická Stavový diagram entity Příklad: Faktura přijatá nová_nezapl nezapl_splat zapl_pozdě penalizovaná zapl_penale zapl_včas stor_nezapl stor_zapl refakturovaná výuč_refakt počáteční stav koncový stav (s možností změny) koncový stav vnitřní stav 69

Analýza IS -dynamická Kontrola konzistence stavů matice stavů Příklad: Faktura přijatá události stavy zapl čas>tespl penal zapl_pen storno refakt vyúčt_ref 1 nová_nez včas/ 2 pozdě/ 3 xxx xxx / 7 --- --- 2 zapl_včas --- --- --- --- / 8 --- --- 3 nezap_splat pozdě/4 --- xxx xxx / 7 --- --- 4 zapl_pozdě --- --- / 6 --- / 8 --- --- 5 penalizovaná 6 zapl_penal 7 stor_nezapl 8 stor_zapl 9 refakturovaná --- --- --- --- --- --- vyúčt / 10 10 vyúčt_refakt --- --- --- --- --- --- --- 70

Analýza IS -dynamická Životní cyklus entity (Entity Life History ELH) u DFD nelze ověřit, zda jsou popsány všechny podněty ke změnám dat nebo ověřit, jak se systém chová při neočekávaném pořadí výskytu dat. ELH je grafický model, znázorňuje život jedné entity - od jejího vzniku až po zrušení -pomocí stromového grafu. vkořeni stromu je entita, uzly na nižších úrovních znamenají jednotlivé podněty, které působí na entitu během jejího života v systému. zobrazuje, jak se mění stav a hodnoty této entity při uvedených událostech. o uzly obdélníkové, označeny entitou (první) nebo událostí (další); o posloupnost (sekvence) je vyjádřena seřazením událostí v každé úrovni stromu zleva doprava; o větvení (selekce) kolečkem v pravém horním rohu obdélníka; o opakování (iterace) operace se zaznamenáhvězdičkou. 71

Analýza IS -dynamická Životní cyklus entity Příklad: Faktura přijatá Faktura nová-nezapl změny archivovaná zapl-včas nezapl-splat zapl-pozdě penaliz zapl-penale 72

Analýza IS -závěr Vztahy mezi analytickými modely Každý model je zaměřen na jiný aspekt systému. Jednotlivé skutečnosti se zpravidla projevují ve více modelechsystému, proto je nutné prověřovat konzistenci každého modelu uvnitř i mezi modely navzájem. Ověření konzistence návrhu-jeho různých modelů je daní za použití strukturalizace popisu. Dobrý CASE systém by měl takovou konzistenci kontrolovat nebo ji pomáhat udržovat. 73

Komunikace s uživatelem Součástí analýzy by měl být i návrh komunikace s uživatelem. Zadáním je množina minispecifikací jejich komunikační okna (ovládací a řídicí prvky -menu, vstupní formuláře, výstupní sestavy, dotazovací okna, informační a chybová hlášení apod.) Komunikací rozumíme způsob a formu vedení dialogu počítače a uživatele, volbu akcí uživatelem (menu-systém a jeho formát), způsob a formát ukládání a modifikace dat (vstupní formuláře), možnosti výběrů informací, formulaci požadavků (QBE?), formát výstupů (standardní hlavičky a patičky, označení), formát dotazů programu uživateli, formát informačních a chybových hlášení, návrh jednotného uživatelského vzhledu programu 74

Komunikace s uživatelem Menu s lištou nahoře (+ ikony) a s roletovými menu více úrovní 75

Komunikace s uživatelem Menu s lištou nahoře (+ ikony) + výběrem funkcí vlevo + formulování dotazu 76

Komunikace s uživatelem Vstupní formulář - 77

Komunikace s uživatelem Report (výstupní sestava) s hlavičkou a formulovaným dotazem 78

Komunikace s uživatelem Report (výstupní sestava) s hlavičkou - pracovní 79

Komunikace s uživatelem Report: Klasická sestava tabulková Příklad: hlavička sestavy Výplatní listina za 2.2003 ==================================== sloupcové nadpisy Jméno hrubá mzda daň čistá mzda ==================================== zákl.řádky Adam Karel 12000.- 1000.- 11000.- Beran Alois 32000.- 3500.- 28500.-... ==================================== pata sestavy CELKEM 559000.- 59000.- 500000.- ==================================== 80

Komunikace s uživatelem Report: VŠB-TUO strana 1 hlavička sestavy Výplatní listina za 2.2003 ==================================== sloupcovénadpisy Jméno hrubámzda daň čistámzda ==================================== zákl.řádky Adam Karel 12000.- 1000.- 11000.- Beran Alois 32000.- 3500.- 28500.-... pata stránky konec stránky -------------------------------------------------------------------------- hlavička stránky... strana 2... -------------------------------------------------------------------------- ==================================== pata sestavy CELKEM 559000.- 59000.- 500000.- ==================================== 81

Komunikace s uživatelem Report: VŠB-TUO strana 1 hlavička sestavy Výplatní listina za 2.2003 ==================================== sloupcovénadpisy Jméno hrubámzda daň čistámzda ==================================== hlava grupy Katedra 400 zákl.řádky Adam Karel 12000.- 1000.- 11000.- Beran Alois 32000.- 3500.- 28500.-... pata grupy ------------------------------------------------------------ 456 celkem -------------------------------------------------------------- hlava grupy Katedra 456... ==================================== pata sestavy CELKEM 559000.- 59000.- 500000.- ==================================== 82

Komunikace s uživatelem Chybovéhlášení 83

Komunikace s uživatelem Nástroje pro komunikaci s uživatelem h základní ovládací prostředky (prostředí, klávesy, myš, tlačítka,...) h h h ovládání programu, struktura menu, uživatelské rozložení do submenuaž po elementární funkce (ovládání, styl, barvy,...) forma základní komunikace (okna, barvy, styl komunikace, styl dotazů,...) forma nápověd, helpů h chybová hlášení (umístění, okno, styl, barva,...) h informační hlášení (umístění, okno, styl, barva,...) h h formát vstupních formulářů, podformulářů různých typů (typ oken, styl, hlavičky, barvy,...) formát výstupních sestav (volby typů výstupů, styl sestav, hlavičky, patičky,...) 84

Komunikace s uživatelem Pravidla pro návrh komunikace člověk - počítač princip prvořadosti uživatele (true image formulářů a sestav) princip jednotnosti (jednotný styl, obdobné situace obdobně,...) návrh jednotného, jednoznačného a jednoduchého komunikačního jazyka pro I/O zprávy, jednotné užití kláves, ikon ap. vlastní jednotný styl komunikace => jednotný styl programování návrh jednotného vzhledu systému menu a podmenu návrh základních dialogů s uživatelem (umístění, tvar a barvy oken, styl dotazů, nápověd ap.) návrh chybových hlášení (není připojena síť, to nesmíš,...) návrh informačních hlášení formátů formulářů, uspořádání, barvy, podformuláře ap. návrh formátů sestav, jednotný způsob jak vyvolat a kam zobrazovat výstup a jak, hlavičky a patičky sestav 85

Komunikace s uživatelem princip vlídnosti (helpy, nápovědy, přesně formulované otázky, jemná upozornění na chyby,...); zprávy pozitivní, ne negativní, žádný druh humoru (opakovaný vtip není vtip, může být i nepříjemný, odporovat principu vlídnosti) zprávy produkované systémem musí respektovat kontext, ve kterém se uživatel nachází, zprávy dost podrobné a informující, co dál respektovat úroveň zkušeností a zaměření uživatele uživatele, jinak dávat zprávy písařce, úředníkovi, vedoucímu, jinak programátorovi minimalizovat čas pro vstupní zprávy uživatele optimalizovat počet kroků (kliků, voleb), pomocí nichž se uživatel dostane k akci, kterou chce realizovat minimalizovat počet úderů na klávesnici, kliků myši,... zprávy vkládané uživatelem majíbýt co nejstručnější, aby se omezilo množství překlepů, nepřesnosti, urychlila komunikace 86

Komunikace s uživatelem vhodnými dotazy zajistit úplnost a správnost vstupního požadavku podrobit každý vstup všem v úvahu přicházejícím kontrolám umožnit v odůvodněných případech zdůvodnění odpovědi, i zde opětovné potvrzení příkazu maximalizovat spolehlivost komunikace odlišit zprávy a data uživatele od zpráv systému, běžné, chybové, dotazy ap. např. barvou, umístěním na obrazovce, písmem, sytostí dát signál o přijetí každého požadavku, aby uživatel věděl, co se děje, když se dlouho nic neděje opakovat na obrazovce standardní funkce (HELP, READ,...) nepředpokládat, že si uživatel něco pamatuje z předcházejícího kroku 87

Komunikace s uživatelem poskytnout nápovědu v každé situaci, když uživatel neví, jak dál, co má odpovědět, jak dál pokračovat; zabudování uživatelské příručky do programu umožnit kdykoliv návrat v komunikaci; kromě chyby by systém měl vždy umožnit změnu názoru nebo vycouvání při chybné volbě optimalizovat množství výstupních informací, před výstupem spočítat množství výstupních zpráv řešit případy zjevného i skrytého nedostatku informací minimalizovat čas pro zácvik uživatelů připravit ilustrativní komunikaci uživatelskou příručku napsat tak, aby uživatel, který potřebuje jen něco nemusel číst vše zkrácenou uživatelskou příručku zabudovat do programu před zavedením systému provést vhodnou osvětu 88

Komunikace s uživatelem Analýza příčin chyb a principy správné reakce na chyby jako příkazy či odpovědi uživatele musí být systém schopen přijímat jakákoliv data (nehavarovat, dát zprávu o chybách) hlášení chybových stavů -ve formě srozumitelné uživateli a konkrétní, v kontextu chyby automaticky neopravovat nechat si opakovaně potvrdit závažná a nebezpečná rozhodnutí neumožnit nevhodnou kumulaci příkazů, kde by mohlo dojít k nedorozumění umožnit nevyplnění některých odpovědí a předem definovat, co to znamená zařadit záznam o chybách do souboru chyb; uživateli možnost zapsání zprávy do tohoto souboru chyb 89

Vztah analýza -návrh implementace 90