Strukturovaná analýza a návrh systému

Transkript

1 MASARYKOVA UNIVERZITA Fakulta informatiky Strukturovaná analýza a návrh systému Bakalářská práce Lenka Šístková Brno, 2010

2 Prohlášení: Prohlašuji, ţe tato práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování pouţívala nebo z nich čerpala, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. V Brně, Lenka Šístková ii

3 Poděkování: Především bych chtěla poděkovat vedoucímu mé bakalářské práce RNDr. Jaroslavu Ráčkovi, PhD. za velkou trpělivost, neocenitelné rady, obětavou pomoc a čas, který mi věnoval. Děkuji však i své rodině za podporu, kterou mi dala během celého studia. iii

4 Shrnutí: Práce popisuje strukturovanou analýzu a návrh. Na příkladu části informačního systému základní školy vysvětluje postup Yourdonovy moderní strukturované analýzy a strukturovaného návrhu. Výsledky práce jsou prezentovány i ve formě vyuţitelné při výuce. Klíčová slova: Yourdonova moderní strukturovaná analýza, YMSA, Strukturovaný návrh, ERD, DFD, SSD, Esenciální model, Implementační model, Informační systém, Ţivotní cyklus softwaru. iv

5 Obsah 1 Úvod Softwarové inţenýrství Systémy Informační systémy Ţivotní cyklus Vývoj software Modelovací nástroje Diagram datových toků Datový slovník Minispecifikace Entitně relační diagram Stavově přechodový diagram Vyvaţování modelů Diagram struktury návrhu Yourdonova strukturovaná analýza Esenciální model Model okolí Model chování Implementační model Vymezení hranic Vymezení uţivatelského rozhraní Manuální podpora Stanovení provozních omezení Strukturovaný návrh Transformační analýza Transakční analýza Návrhové heuristiky Závěr Informační zdroje Přílohy Příloha A: Model okolí Příloha B: Model chování Příloha C :Model struktury systému v

6 1. Úvod Dnes jiţ kaţdá firma pouţívá osobní počítače, které jsou připojeny k lokální nebo veřejné síti. Vedle operačních systémů pouţívá i software ke zkvalitnění sluţeb a zjednodušení vlastní práce. Software můţeme rozdělit podle způsobu vývoje na generický a smluvní. Generický software si můţe kaţdý uţivatel zakoupit ve specializovaném obchodě, v dnešní době některé druhy i v jakémkoli hypermarketu. Smluvní software si zákazník zpravidla objedná u specializované firmy, v níţ softwaroví inţenýři vytvoří systém dle poţadavků zákazníka. Softwarové inţenýrství je uznáváno jako samostatný obor od roku 1997, ale zatím nebyla vytvořena ucelená teorie způsobu vývoje softwaru. Existují však soustavy různých vývojových technik tvorby programového vybavení. Nejčastěji vytvářeným smluvním softwarem jsou databázové informační systémy. Tyto systémy procházejí pěti fázemi vývoje, jeţ jsou: analýza, návrh, implementace, validace a provoz. [1] Analýza je fáze, ve které se shromaţďují poţadavky zákazníka na informační systém a snaţí se porozumět prostředí, ve kterém bude pouţíván. Návrh se vytváří z výsledků analýzy a přesně definuje základní jednotky systému a jejich rozhraní. Implementací systému se rozumí spustitelný kód, který vytvoří programátoři, jenţ zpracují vytvořený návrh. Ve fázi validace se porovnává návrh a implementace systému tak, aby program splňoval vše, co bylo zahrnuto v návrhu systému. Poslední fází je zkušební provoz u zákazníka, při němţ se sleduje, jak programy pracují. Zákazník si vše můţe vyzkoušet a popřípadě poţadovat nějaké změny nebo vylepšení. Nutnou součástí vývoje softwaru je neustálá údrţba a vývoj dalších modifikací tak, aby celý systém drţel krok s dalším softwarem. Základem vývoje dobře fungujícího softwaru je analýza. Obecně je analýza vědecká metoda zaloţená na dekompozici celku na elementární části. Cílem analýzy je identifikovat podstatné a nutné vlastnosti elementárních částí celku, poznat jejich podstatu a zákonitosti. [9] Velmi záleţí na tom, aby si zákazník a analytik dobře porozuměli a nedošlo zde k nějakým nejasnostem. Spolu s návrhem systému je analýza fáze, kterou pochopí i naprostý laik, a tudíţ můţe zákazník zasahovat do průběhu vývoje. Další fáze jsou určeny odborníkům a nepředpokládá se, ţe by jim zákazník rozuměl. Analýza jakéhokoliv systému probíhá ve dvou fázích. První je vytvoření logického modelu, v němţ je popsáno vnější chování systému z pohledu potřeb uţivatele. Druhou fází je vytvoření fyzického modelu, tedy doplnění logického modelu o vlastnosti, jenţ jej přizpůsobují reálnému světu. [13] Teorie ke strukturované analýze se začaly objevovat koncem 60. let a dnes existuje několik postupů, jak strukturovanou analýzu vytvořit. Jednou z nich je Yourdonova moderní strukturovaná analýza (YMSA Yourdon Modern Structure Analysis), která byla představena roku 1989 Edwardem Yourdonem. Návrh je delším krokem vývoje softwaru. Podle výsledků analýzy se zvolí nejoptimálnější rozvrţení hardwaru, posloupnosti v práci systému nebo pravomoci uţivatele Práce představuje metodu YMSA na příkladu informačního systému základní školy. Systém má zjednodušit a zpřehlednit práci celému pedagogickému sboru a umoţnit rodičům, prostřednictvím internetového prohlíţeče, kdykoli zkontrolovat prospěch a docházku svých dětí. Systém obsahuje osobní údaje všech učitelů, ţáků a zákonných zástupců ţáků. Kaţdý jedinec má vytvořený osobní účet chráněný přihlašovacím jménem a heslem s právy a oprávněními tak, aby měl přístup ke všem pro něj důleţitým informacím. Je velmi důleţité, aby takto navrhnutý informační systém splňoval nároky zaměstnanců školy i zákonných zástupců ţáků

7 Práce se člení do pěti částí. První část seznamuje se softwarovým inţenýrstvím a etapami vývoje informačního systému. Druhá část popisuje modelovací nástroje, které jsou pouţívány při Yourdonově analýze a strukturovaném návrhu. Ve třetí části je popsána analýza metodikou YMSA na příkladu části informačního systému základní školy. Čtvrtá část seznamuje se strukturovaným návrhem a jeho postupy. Pátá část je závěrem celé práce, v níţ je shrnutí významu strukturovaného přístupu

8 2. Softwarové inţenýrství Softwarové inţenýrství je činnost zahrnující inţenýrství, informatiku a management, jehoţ cílem je návrh, tvorba a údrţba počítačových programů.[9] 2.1. Systémy Systém je souhrn souvisejících prvků, sdruţených do smysluplného celku. V latině a řečtině znamená termín systém kombinovat, uspořádat nebo sdruţovat.[9] Člověk je neustále obklopován systémy, ať těmi přirozenými nebo těmi, co sám vytvořil. V přírodě najdeme nepřeberné mnoţství skvěle fungujících systémů, z nichţ lidé čerpají inspirace pro tvorbu vlastních umělých systémů, které by jim měly usnadnit ţivot. Např. Sluneční soustava. Souvisejícími prvky jsou planety a jejich měsíce a kaţdý pohyb těchto těles je konán v nějakém smyslu. Kdyby neexistoval systém, vznikl by chaos a vzájemná zkáza těchto těles. Systém můţeme rozdělit na podsystémy nebo dále slučovat s jinými systémy do větších celků. Kaţdá planeta obíhá kolem Slunce a kolem většiny planet obíhají měsíce. Samo se tedy nabízí chápat planetu a její měsíce jako nějaký podsystém nebo naopak chápat Sluneční soustavu jako součást Galaxie Mléčná dráha. Se socializací člověka přicházela čím dál větší potřeba uměle vytvářet systémy v lidské společnosti, např. kmenové uspořádání v pravěku. Kaţdý systém ať uţ přírodní nebo umělý se mění a vyvíjí. Umělé systémy ovšem prodělávají tyto stavy častěji a masivněji, neţ je tomu přirozeně v přírodě. Dnešní technická doba, kde většinu práce udělají za člověka stroje, si vyţaduje systémy, které tyto stoje obsahují nebo se skládají pouze z nich Informační systémy(is) Informační systémy slouţí pro sběr, udrţování, zpracování a poskytování informací a dat. Systém nemusí být nutně automatizovaný pomocí počítačů, můţe být i v papírové podobě. Hierarchie uvnitř systému dává moţnost rozdělit systém na elementární části tak, aby kaţdá část mohla fungovat samostatně nebo nám umoţňuje spojit stávající systémy do většího celku. Např. mzdové účetnictví můţe být součástí personálního oddělení, jeţ patří do obchodního úseku velkého ekonomického systému jedné firmy, apod. Tvorba ISu je zdlouhavý proces, na kterém se podílí mnoho lidí. Ovšem je nutné si uvědomit, ţe vytvářet systém tzv. na zelené louce není obvyklé. Většina systémů je tvořena přebudováním jiţ stávajících systémů. Můţe se jednat o stávající počítačové systémy, které jsou zastaralé, a tudíţ potřebují obnovit, nebo o manuální systémy, které se převádějí na systémy počítačové. Mohou existovat i systémy, kde se kombinují obě varianty, jak manuální, tak počítačová. Pokud vytváříme systém uměle, je nezbytné vypracovat analýzu, jak by daný systém měl vypadat a co se od něj očekává. Lidé zabývající se touto problematikou jsou systémoví analytici. Analytik se při tvorbě systému setkává s mnoha lidmi, jichţ se vyvíjený systém nějak týká a probírá s nimi jejich představy a očekávané výstupy, které od systému mají. Proto je důleţité, aby byl analytik schopen s těmito lidmi vycházet a uměl jim vysvětlit vše, co je okolo systému zajímá nebo co jim není jasné

9 2.3. Ţivotní cyklus software Jakékoliv programové vybavení počítače se nazývá software. Tudíţ i informační systém, který je plně automatizován, je softwarem. V minulosti se vývojem softwaru zabýval pouze jediný člověk, programátor, který psal kód, jeţ slouţil k vyřešení určitého problému nebo vytvoření plně automatizovaného postupu jisté činnosti. V dnešní době se na tvoření sloţitých systémů, obsahujících miliony řádků kódu, podílí tým specialistů: analytici, designéři, programátoři, testeři a v neposlední řadě i budoucí uţivatelé. Kaţdý takto sloţitý software prochází při svém vzniku několika fázemi vývoje, které začínají prvotní představou vyvíjeného softwaru a končí v okamţiku, kdy se software přestane pouţívat. Tento vývoj se nazývá Ţivotní cyklus.[11] Existuje několik modelů pro znázornění ţivotního cyklu software, nejznámější jsou: vodopádový model model výzkumník prototypový model spirálový model Nejstarším modelem je model vodopádový (obr.1). Jde o řadu etap, kde výsledek kaţdé etapy se stane vstupem pro etapu následující. Celý proces v tomto modelu začíná analýzou, tedy definováním nároků, které jsou od vyvíjeného softwaru očekávány, čímţ se vytvoří celkový pohled na zamýšlený projekt a stanoví cíle. V další fázi se vytvoří podrobný návrh celého systému. Zde se do detailu popisují poţadované funkce a operace včetně uspořádání obrazovek, firemních pravidel, schémat procesů a další dokumentace. V následující fázi se napíše skutečný kód a testují se jednotlivé části systému, na coţ navazuje testování systému jako celku. Poslední fází projektu je samotný provoz a údrţba systému. V této části je software předán do provozu v reálných podmínkách firmy a neustále se sleduje jeho kompatibilita s vývojem dalšího softwaru i hardwaru.[11] Obr. 1: Vodopádový model Během vývoje systému se řešitelé při získávání poznatků často vracejí k předchozím etapám. Model výzkumník (obr.2) s tím přímo počítá jako se základní charakteristikou vývoje.[11] - 4 -

10 Vytvoř systém Implementuj systém Pouţívej systém NE Vyhovuje? ANO Předání hotového systému Obr. 2: Model výzkumník Prototypový model (obr.3) jiţ od začátku předpokládá změny v poţadavcích zákazníka. Prototyp můţeme chápat jako zjednodušenou implementaci celého systému nebo jako plnou implementaci části systému. Základním předpokladem je seznámit zákazníka s prvotní verzí systému v co nejkratší době. Tato verze musí obsahovat veškerá vnější rozhraní a umoţňovat zákazníkovi reagovat na předloţený prototyp systému. Podle připomínek zákazníka se upřesňuje a modifikuje prototyp systému do té doby, dokud není zákazník zcela spokojen. Poté následuje návrh a implementace systému.[11] Obr. 3: Prototypový model - 5 -

11 V modelu spirály (obr.4) se jednotlivé kroky ve spirále opakují, ale pokud moţno na vyšším stupni zvládnuté problematiky. Model spirála můţe být chápán jako série krátkých cyklů vodopádu, kdy výsledkem kaţdého cyklu je prototyp reprezentující určitou část z celého projektu. Metoda tvorby a úpravy je nejhrubější metodou. Napíše se kód a pak se upravuje aţ do momentu, kdy je zákazník spokojen. Bez dobrého plánování to můţe být nekonečný a riskantní postup. [11] Obr. 4: Model spirály 2.4. Vývoj software Kaţdý software prochází postupně pěti základními etapami vývoje, nehledě na to, kterého ţivotního cyklu je pro vývoj konkrétního softwaru pouţito. Těmito fázemi jsou: analýza, návrh, implementace, testování a provoz. Analýza Hlavní účel analýzy systému je skloubit poţadavky zákazníka s dostupnými technologiemi. K tomu nám slouţí datové modelování, popsané v dalších částech práce. Na konci fáze analýza má analytik detailní představu o vyvíjeném systému, tedy kdo bude s tímto systémem pracovat, s jakými daty a jakým způsobem. Ke konci analýzy se také musí spočítat veškeré náklady na tvorbu systému a stanovit rozpočet. Pokud se během analýzy zjistí nějaké nedostatky či bude-li chtít zákazník něco změnit, je to nejjednodušší právě v této fázi. Práce systémového analytika má velkou váhu, protoţe pokud podcení některou část systému, můţe to prodraţit celý systém, jak finančně, tak časově. Jestliţe problém nastane v některé z pozdějších fází, je nutné vracet se znovu na začátek celého procesu vývoje systému, coţ prodraţuje systém geometrickou řadou

12 Návrh Ve fázi návrhu je úkolem rozvrhnout fyzické zdroje. Hranice mezi analýzou a návrhem systému je minimální a kaţdý analytik by měl být schopen zvládnout i tvorbu návrhu. Aţ v této fázi se můţe analytik přesvědčit, ţe dobře porozuměl poţadavkům zákazníka a efektivně je skloubil s moţnostmi uţívané technologie. Prvním krokem návrháře je konfigurovat procesory podle modelů připravených analytikem. Poté se musí rozhodnout, jak budou rozděleny procesy a data do různých úkolů uvnitř kaţdého procesoru. A nakonec musí uspořádat procesy uvnitř kaţdého úkolu do posloupností, které byly naznačeny pomocí struktury diagramů ve fázi analýzy Implementace V této fázi se tvoří kód systému. Existuje nepřeberné mnoţství programovacích jazyků, které slouţí k vytváření spustitelného kódu různých systémů, jako například: Fortran, C, C++, Java, Virtual Basic, C# a další. Bez ohledu na to, v jakém programovacím jazyku je systém implementován, by nemělo být opomenuto několik věcí: produktivita (hodně kódu za málo času) efektivita (hospodárnost s pamětí a procesorem) správnost (ošetření kritických míst, aby nedocházelo ke kolizím systému nebo k vytvoření černých děr) přenositelnost (systém musí být schopen fungovat na různých typech počítačů) udrţovatelnost (systém se musí i nadále vyvíjet tak, aby byl schopný reagovat na vývoj hardwaru i softwaru) Testování Pravým a jediným cílem testování je "nalezení chyb v programu" tj. odhalit slabá místa programu tím, ţe se program přivede do nestabilního stavu, vyvolají se výjimky apod. Výsledkem dobrého testování je odhalení co největšího počtu chyb, které jsou pak následně opraveny. Prvním krokem se definuje testovací případ. Definice testovacího případu obsahuje následující poloţky: vstupní data: data zadávaná na vstup testovaného programu očekávaná výstupní data popis smyslu testu Zadáním vstupních dat do programu se získají výstupní data, která se porovnávají s očekávanými výstupními hodnotami. Pokud se vyskytla chyba, hovoří se o tom, ţe testovací případ byl úspěšný. Celý proces testování by měl být řádně zdokumentován. Základním dokumentem, sestavovaným před vlastním započetím testování, je tzv. plán testování. V tomto plánu by měly být vyjmenovány testovací případy, cíl jednotlivých testů, postup testování, podmínky, za jakých testování probíhalo, a harmonogram. Po skončení testů se tato zpráva doplní o konkrétní výsledky.[15] Provoz Provoz je konečná fáze vývoje systému, ve které se systém spouští v pracovním prostředí a zkoumá se jeho ţivotaschopnost. V reálném světě nevykonává všechnu práci automatický systém, ale stále ještě dochází k situacím, jeţ se řeší manuálně. Proto se vytváří formální - 7 -

13 popis částí systému, které se vykonávají právě manuálně. Stejně tak je důleţitý popis spolupráce uţivatelů s automatizovanou částí systému. Systémy pracují s daty, jeţ jsou uloţena v databázích, tudíţ dalším úkolem je zaručit přístup systému k příslušným databázím a zajistit, aby data, která jsou v databázích uloţena, byla v takovém tvaru, s nímţ je systém schopen pracovat. V případě, ţe taková databáze neexistuje, musí se vytvořit. Finálním krokem je samotná instalace systému do pracovního prostředí. Ale i kdyţ byl celý ţivotní cyklus vývoje systému prováděn pečlivě, stává se, ţe některé části nebudou pracovat přesně podle představ zákazníka, a proto se musí nevyhovující části opravovat. Dokud bude systém pouţíván, je nutné udrţovat jej v ţivotaschopném stavu, coţ znamená, neustálou inovaci podle vývoje informačních technologii. Tedy vývoj systému končí s jeho ţivotností - 8 -

14 3. Modelovací nástroje Hlavní náplní práce systémového analytika je vytvořit model systému podle poţadavků zákazníka tak, aby vyzdvihl důleţité rysy systému a potlačil nepodstatné detaily. Smyslem modelování je získat představu, jak bude vyvíjený systém fungovat a zároveň pomáhá zákazníkům při představě jeho konečné podoby. Proto je důleţité, aby byl model srozumitelný všem zúčastněným stranám a umoţňoval změny a opravy podle poţadavků zákazníka. Analytik si tak můţe ověřit, ţe rozumí všemu, co zákazník od systému očekává. Opravy a změny, jeţ jsou prováděny v pozdějších fázích vývoje systému, prodraţují systém geometrickou řadou s kaţdou další fází. Model slouţí jako dokument pro další uţivatele, systémové analytiky, vývojáře nebo budoucí zlepšovatele. Při tvoření modelu je důleţité zodpovědět si několik otázek: Co musí systém vykonávat? Jaké jsou vzájemné vztahy mezi funkcemi? Jaké změny musí systém vytvářet? Jaké vstupy se změní v jaké výstupy? Jaký druh práce systém vykonává? Kde získává informace ke své práci? Kam posílá výsledky své práce? Existují dva základní pohledy pro zkoumání systému: funkčně a datově orientovaný přístup. Základem funkčně orientovaného přístupu jsou procesy, které jsou propojeny funkčními a datovými toky. Veškerá data jsou uchovávána v pamětech. Model funkčního přístupu k systému se nazývá diagram datových toků (DFD data flow diagram). Datově orientovaný přístup se zaměřuje na elementární datové struktury, se kterými systém pracuje. Jakým způsobem se s daty zachází není v tomto přístupu podstatné. Pro zobrazení datově orientovaného přístupu se pouţívá entitně relační diagram (ERD entitně relační diagram).[2] Další fáze ve vývoji systému je návrh. Ve fázi návrhu se modelují diagramy, které popisují rozvrţení zdrojů a posloupnosti zpracování dat. Základním nástrojem pouţívaným k modelování struktury systému je Diagram struktury systému (SSD System Structure Diagram).[7] 3.1. Diagram datových toků (DFD Data Flow Diagram) DFD je modelovací nástroj, který se pouţívá k popisu přeměny vstupů ve výstupy a skládá se z procesů, datových skladů (pamětí), datových toků a terminátorů (obr.5). Procesy jsou zobrazovány v DFD jako bubliny. Reprezentují jednotlivé funkce systému, které přetváří vstupy ve výstupy. Kaţdý proces musí být jednoznačně pojmenován, aby bylo moţné jej jasně identifikovat. Název procesu je většinou jednoslovný, ale toleruje se i fráze nebo jednoduchá věta. DFD má stromovou strukturu, coţ znamená, ţe proces obsahuje další podprocesy a pokud ne, jedná o proces na nejniţší úrovni DFD a jeho funkce je popsána minispecifikací. Datové toky mohou být znázorněny jako rovné čáry nebo křivky. Spojují procesy a reprezentují informaci, která do procesu vstupuje nebo z něj vystupuje. Kaţdý tok je pojmenován podle významu, který mají data přenášena tímto tokem, coţ má za následek, ţe jedním tokem proudí pouze jeden typ dat. Názvy datových toku jsou podstatná jména a mají být co nejkratší, proto není moţné popsat datový tok jako jméno a příjmení a adresa a - 9 -

15 telefon, ale jen např. osobní údaje. Podrobnější vysvětlení obsahu toku je popsáno v datovém slovníku, který je zmiňován níţe. Směr, kterým data plynou, je znázorněn šipkou, která ukazuje směr toku dat. Datové sklady se modelují jako dvě vodorovné linky nebo elipsa. Slouţí k uchování dat pro pozdější zpracování, aniţ by docházelo ke změně jejich obsahu. Paměť je pouze pasivní prvek DFD, tudíţ pokud se do paměti zapisuje nebo se z ní čte, musí existovat proces, který bude transakci dat řídit. Čtení dat je nedestruktivní, proto se obsah paměti při čtení nemění. Ovšem tok vedoucí do paměti můţe mít význam změny, zápisu nebo zrušení obsahu části paměti. Paměť je implementována jako soubor nebo databáze a její název je odvozen od názvu uloţených dat jako mnoţné číslo. Terminátor reprezentuje externí entity, se kterými systém komunikuje. Veškeré informace, které systém od okolí čerpá, získává prostřednictvím terminálů a stejně tak, všechny výstupy, jeţ systém vyprodukuje, proudí do okolí přes terminátory. Terminátorem mohou být osoby, hardwarová zařízení nebo jiné softwarové systémy. Analytici ani návrháři nemají moţnost ovlivnit způsob práce ani obsah terminátorů. Graficky je znázorněn jako obdélník, v němţ je název reprezentující roli terminátoru. Při modelování DFD je dobré pamatovat na několik zásad: výběr smysluplných názvů (názvy by měly být vybírány tak, aby při pohledu na DFD bylo jasné, co daná komponenta dělá nebo představuje) optimální počet procesu ( pravidlo 7 ± 2 říká, ţe na jedné úrovni DFD by mělo být maximálně 9 a minimálně 5 procesů a pamětí. Je-li jich počet větší, stávají se diagramy nepřehlednými a je-li jich méně, je sada DFD příliš strukturovaná) překreslovat model, dokud není dokonalý vyhnout se příliš sloţitým modelům (snadné porozumění, okamţité pochopení a pěkné na pohled) ujistit se, ţe DFD je vnitřně jednotný a odpovídá ostatním komponentám analýzy systému (vyvaţování modelů) Obr. 5: Model datových toků

16 Model systému obsahuje velké mnoţství různých procesů. Modelovat je na jedné úrovni by bylo velmi nepřehledné a obtíţné pro správnou orientaci. Pro zjednodušení sloţitých systémů se DFD modeluje jako hierarchie vzájemně si odpovídajících DFD. Na vrcholu pomyslné pyramidy stojí kontextový diagram, jenţ znázorňuje systém jako jediný proces. Podúroveň kontextového diagramu se nazývá systémový DFD nebo DFD nulté úrovně, ve kterém se systém dělí na hlavní procesy. Kaţdý proces je dále dekomponován na niţší úrovni DFD, coţ se opakuje tak dlouho, dokud na nejniţší úrovni DFD nevzniknou nejjednodušší procesy, jeţ lze popsat minispecifikací. Dekompozice systému lze vytvářet dvěma postupy: Shora-dolů a zdola-nahoru. Shora-dolů je postup popsaný výše, kde se od kontextového diagramu pokračuje systémovým DFD nalezením hlavních procesů, jeţ se dále postupně dekomponují na dílčí procesy. Ve sloţitějších systémech se ale stává, ţe hlavní procesy nejsou na první pohled zřejmé, proto se nabízí druhá moţnost, dekomponovat DFD zdola- na horu. Při dekompozici zdola na horu se v první fázi hledají elementární procesy, které se následně slučují do procesů na vyšší úrovni. Sada modelů DFD se po primárním vytvoření dále vyvaţuje, tedy dělí se nebo slučují další procesy, aby se vytvořila co nejoptimálnější struktura celého DFD.[2] 3.2. Datový slovník Samostatný diagram datových toků neobsahuje přesné definice dat a algoritmů, proto je nutné vytvořit přehled, který takové informace specifikuje. Datový slovník zahrnuje seznam všech datových objektů v databázi, jména a popis všech datových prvků a jejich vztahů, údaje o integritních omezeních, jména uţivatelů a evidenci udělených práv či oprávnění a kontrolní informace. Na základě informací z datového slovníku se vytváří entitně relační diagram. Datový slovník představuje spojení mezi projektem představovaným DFD a realizací IS. V DFD se data realizují pomocí zásobníků dat a datových toků. Proto datový slovník popisuje datové struktury a funkce těchto prvků. Jedním z nejdůleţitějších činností při návrhu informačního systému, je navrţení správné struktury dat. Pro jednotný a srozumitelný návrh se pouţívají struktury z vyšších programovacích jazyků. V následující tabulce jsou shrnuty symboly pouţívané při tvorbě datového slovníku. Symbol Popis = údaj se skládá + a opakující se { } obsah nepovinný ( ) prvek [ výčet moţností klíč Datové poloţky, jeţ se obtíţně popisují uvedenými operátory, se popisují komentářem

17 V tomto případě se popisuje význam datového toku v kontextu aplikace, někdy se uvádí komponenty prvku nebo rozsah hodnot. [2] 3.3. Minispecifikace Minispecifikace popisuje, co se děje v procesech na nejniţší úrovni v DFD. Tedy postupy a pravidla, kterým se řídí transformace dat při změně vstupu ve výstup. Při tvorbě minispecifikace se dohlíţí i na případné neţádoucí výskyty redundancí v celkovém modelu systému. Nejčastější forma psaní minispecifikace je strukturovaná angličtina. Občas lze pouţít rozhodovací tabulku nebo rozhodovací strom. Uţití konkrétního algoritmu nemusí být vţdy to nejlepší, proto se někdy volí podoba vstupních a výstupních podmínek. Vţdy je nutné dobře odhadnout, který typ vyjádření minispecifikace bude nejlépe srozumitelný zákazníkovi. [11] Slovník pro minispecifikaci je sloţen z imperativních sloves, pojmů definovaných v datovém slovníku a definovaných slov pro formulaci logiky. Syntaxe je omezena na jednoduché oznamovací věty, uzavřené rozhodovací konstrukce a uzavřené opakovací konstrukce. FOR EVERY <polozka v databazi> DO <provedeni cinnosti s polozkou v databazi>. WHILE DO, REPEAT UNTIL IF <podminka>, THEN <cinnost procesu pri platne podmince>. OTHERWISE <cinnost procesu pri neplatne podmince>. SELECT: CASE 1 (podmínka x): <cinnost procesu při platnosti podminky x>. CASE 2 (podmínka y): <cinnost procesu při platnosti podminky y>.... CASE n (podmínka z): <cinnost procesu při platnosti podminky z>. READ vstup FROM pamet. WRITE vystup TO pamet. GET vstup FROM terminator. PUT vystup TO terminator. Formy psaní minispecifikace jsou názorně popsány v literatuře [1][2][3]

18 3.4. Entitně relační diagram (ERD Entity Relationship Diagram) ERD znázorňuje statický datový model systému, jeţ popisuje datové sklady, které jsou modelovány v DFD. ERD se skládá s entitních a vztahových mnoţin. Většinou se tyto termíny zkracují na entity a vztahy mezi entitami nebo relace. Entitní mnoţinu reprezentuje obdélník obsahující její jméno, který představuje skupinu objektů z reálného světa. Kaţdá entita je specifikována svými atributy, datovými elementy, a platí, ţe kaţdý prvek v entitní mnoţině lze jednoznačně identifikovat. Uvnitř obdélníku, jenţ reprezentuje entitu, mohou být atributy uvedeny. Entitu lze jednoznačně identifikovat podle klíčových atributů, které bývají určitým způsobem vyznačeny. Vztahy mezi entitami, nebo-li relace, se znázorňují pojmenovanou čárou, která spojuje příslušné entitní mnoţiny. Relace mohou být dvou typů: identifikující a neidentifikující. Identifikující relace jsou zakresleny plnou čárou a znázorňují předávání klíčového atributu nadřazené entity závislé entitě, který se pak stává součástí primárního klíče závislé entity (obr.6a). Neidentifikující relace jsou znázorněny přerušovanou čárou a znamenají, ţe po předání primárního klíče nadřazené entity se nestává primárním klíčem závislé entity, ale pouze klíčem cizím (obr.6b). Obr.6a: Identifikující relace Obr. 6b: Neidentifikující relace Na koncích relace bývá vyjádřena arita, která reprezentuje počet objektů, jeţ se účastní vztahu mezi propojenými entitami. Arita se vyjadřuje číselnou hodnotou nebo zvolenými symboly. Nejčastější relace mají aritu typu 1:N nebo M:N. Písmena M a N jsou rovny alespoň jedné. Arita M:N znamená, ţe kaţdé nadřazené entitě je přiřazena přinejmenším jedna entita závislá. Ovšem tato arita nelze reálně realizovat, a proto se mezi tyto relace vkládá vazební entita. Vazební entita se naváţe mezi dvě původní entity pomocí vztahů 1:M a 1:N, coţ je rozklad původního vztahu M:N (obr.7). Existuje i vztah, který nemusí nastat a značí se 1:0..N (obr.8). Pokud relace spojuje dva a více výskytů jediného objektu, mluví se o rekurzivním vztahu.. Obr. 7: Vazební entita Obr. 8: Nepovinná vazba

19 Důleţitou činností při tvoření ERD je normalizace. Normalizace modelu je sada pravidel, jak postupovat při transformaci struktury entit a relací ERD na strukturu fyzického uspořádání tabulek a relací v databázi. Normalizací se odstraní opakující se data, zjednoduší se relace a zabrání se tzv. aktualizačním anomáliím, coţ jsou případy, kdy vymazáním jedné entity smaţeme atributy jiné entity. Normalizace by měla vést k vzniku tabulek, které lze snadno udrţovat a efektivně se na ně dotazovat. Normalizované schéma musí zachovat všechny závislosti původního schématu a relace musí zachovat původní data. To znamená, přirozeným spojením je moţné dostat se k původním datům.[12] Základní stupně normalizace: 1.NF První normální forma 2.NF Druhá normální forma 3.NF Třetí normální forma 1. normální forma (1.NF) Relace je v první normální formě, pokud kaţdý její atribut obsahuje jen atomické hodnoty. Tedy hodnoty z pohledu databáze jiţ dále nedělitelné.[12] Například v relaci obsahující data o nějaké osobě je více telefonních čísel: Jméno Příjmení Adresa Telefony Pavla Konečná Milonice ; Michal Pěnkava Palackého 9, Brno ; Petr Pavel Ve Dvoře 28, Zahrada ; V takovéto tabulce by se problematicky prováděly změny čísel, případně vyhledávání podle telefonního čísla. Aby tabulka byla v 1NF, musí se oddělit telefonní čísla do samostatné tabulky: Osoba ID Jméno Příjmení Adresa 1 Pavla Konečná Milonice Michal Pěnkava Palackého 9, Brno 3 Petr Pavel Ve Dvoře 28, Zahrada Telefon ID_osoby ČÍslo normální forma (2.NF) Relace se nachází v druhé normální formě, jestliţe je v první normální formě a kaţdý neklíčový atribut je plně závislý na primárním klíči, a to na celém klíči. To znamená, ţe 2. normální forma se řeší pouze v případě, ţe existuje vícehodnotový primární klíč.[12] Příklad: Učitelé učí předmět

20 Předmět Příjmení učitele Telefon Poč.hod Zeměpis Novák Fyzika Novák Přírodopis Ivová Chemie Ivová Klíčem této relace je kombinace atributů Příjmení učitele a Předmět. Telefon ovšem není závislý na celém klíči, ale pouze na atributu Příjmení učitele. Pokud by učitel změnil telefon, musel by se změnit v několika řádcích tabulky. Řešením je opět rozpad na dvě tabulky: Předmět Předmět ID učitele Poč.hod Zeměpis Fyzika Přírodopis Chemie 02 8 Učitel ID učitele Příjmení učitele Telefon 01 Novák Ivová normální forma (3.NF) Relace je v 3. NF, pokud je ve 2. NF a všechny neklíčové atributy jsou navzájem tranzitivně nezávislé. Tranzitivní závislost je taková závislost, mezi minimálně dvěma atributy a klíčem, kde jeden atribut je funkčně závislý na klíči a druhý atribut je funkčně závislý na prvním.[12] Příklad: Ţák ID ţáka Jméno Příjmení Datum narození Místo narození Bydliště PSČ 001 Milan Kuna Brno Tišnov Ivan Dyk Brno Kuřím Pepa Franta Olomouc Drásov Pavel Kuna Brno Tišnov V této tabulce závisí všechny atributy na klíči, ale také PSČ na bydlišti. Závislost ID ţáka ->Bydliště -> PSČ je tranzitivní závislost PSČ na klíči. A proto není pravda, ţe všechny neklíčové atributy jsou navzájem nezávislé. Řešením problému je opět rozpad na více relací. Ţák ID ţáka Jméno Příjmení Datum narození Město_ID 001 Milan Kuna Ivan Dyk Pepa Franta Pavel Kuna Město Město_ID Město PSČ 1 Tišnov Kuřím Drásov

21 Dále ještě existuje 4. normální forma, někdy také označovaná jako BCNF (Boyce Codd Normal Form), a 5. normální forma. Ty jsou ovšem při praktickém návrhu zvaţovány jen zřídka. Pokud nepřihlédneme k těmto pravidlům, můţe to vést k méně dokonalému návrhu, ale nemělo by to ovlivnit funkčnost celé databáze.[7] 3.5. Stavově přechodový diagram (STD State Transition Diagram) STD představuje část systému, jeţ vyčkává na nějakou událost. Hlavní částí diagramu jsou stavy, jeţ reprezentují změny stavu systému, jako například: čekání na zadání přístupového hesla, čekání pro další příkaz, smíchání surovin apod. STD slouţí ke specifikaci řídících procesů, které jsou zakresleny jiţ v DFD. Stavově přechodový diagram tvoří stavy a orientované přechody, které reprezentují změnu stavu. Stav se můţe modelovat ve tvaru elipsy, avšak takový model připomíná DFD, proto je častější modelovat stav v STD jako obdélník. Název stavu obvykle označuje nějakou formu čekání systému, tedy skutečnost, která má nastat. Ke kaţdému řídícímu procesu existuje právě jeden STD, který má právě jeden počáteční stav, v němţ se systém nachází při spuštění a minimálně jeden stav koncový. Popis přechodu se skládá z podmínky vyvolávající změnu stavu a názvu akce, jeţ provede systém při změně stavu (obr.9). Podmínka se shoduje s událostí, která se stala ve vnějším okolí systému. Akce mohou reprezentovat odpověď na událost vysílanou do vnějšího okolí nebo výpočty, jeţ si systém zapamatuje pro pozdější reakci.[1] Obr. 9: Stavový diagram 3.6. Vyvaţování modelů Kaţdý z nástrojů analýzy se zaměřuje na kritické aspekty modelování systému. Ovšem v praxi se modely analýzy pouţívají souběţně a vzájemně se kombinují. Je tedy nutné, aby si jednotlivé modely vzájemně odpovídaly. Jednoduše se můţe stát, ţe v různých částech modelů se jediná část reality vymodeluje různým způsobem. Větší nebezpečí je ve velkých projektech, kde se různí lidé věnují různým záleţitostem. I kdyţ se jedná o různé modely, jde neustále o jeden systém. Proto se v modelu nesmí vyskytovat ţádná sporná místa, nedostatky či redundance. Chyba, která se v části modelu jeví jako zanedbatelná, se v dokončeném modelu můţe objevit jako zásadní. Proto je neméně důleţitou částí vývoje systému vyvaţování modelů: 1. DFD x datový slovník 2. DFD x datový slovník x minispecifikace 3. ERD x DFD x datový slovník x minispecifikace 4. DFD x STD

22 Vyvaţování Diagramu datových toků a datového slovníku Datové toky na DFD představují proud dat v systému a paměti reprezentují sklady, kde se shromaţďují data. Struktura všech dat, jeţ projdou systémem, musí být popsána v datovém slovníku. Pokud definice nějakého proudu chybí, je povaţován za nedefinovaný, coţ je chyba. Stejně tak, kaţdý pohyb dat definovaný v datovým slovníku se musí objevit v DFD. V opačném případě se data povaţují za přebytečná, jelikoţ se nikdy v systému neobjeví. Problémy s nevyváţením DFD a datového slovníku nejčastěji nastávají při úpravách v DFD, kdy analytik nezkontroluje, jestli si DFD po úpravách odpovídá s datovým slovníkem. Vyvaţování Diagramu datových toků, Datového slovníku a Minispecifikace DFD má stromovou strukturu, tudíţ musí kaţdý proces obsahovat podprocesy, jeţ zpracovávají příchozí data. Jestliţe proces ţádné podprocesy neobsahuje, je listem pomyslného stromu a jeho práce je popsána minispecifikací. Pokud by se v systému objevil proces, který by obsahoval jak minispecifikaci, tak procesy niţší úrovně, je model systému zbytečně a hlavně nebezpečně nadbytečný. Ke kaţdé minispecifikaci musí existovat proces na nejniţší úrovni DFD. V případě, ţe existuje minispecifikace, ale nevyskytuje se k ní příslušný proces, je to většinou důsledek rušení procesů, kdy analytik nezrušil i příslušné minispecifikace. Vstupy a výstupy uvedené v minispecifikaci si musí odpovídat se vstupy a výstupy příslušného procesu. Toky v obou směrech, stejně jako paměti, s nimiţ proces pracuje, musí mít odpovídající operace v minispecifikaci. Např. Klíčové slovo READ odpovídá kaţdému vstupnímu toku nebo WRITE se shoduje s kaţdým výstupním tokem. Kaţdý odkaz v minispecifikaci procesu odpovídá názvu datového toku nebo je lokálním názvem explicitně určeným v minispecifikaci, eventuelně částí datového toku či paměti, s níţ pracuje proces a je definována v datovém slovníku. Vyvaţování Entitě relačního diagramu, Diagramu datových toků, Minispecifikací a Datového slovníku DFD reprezentuje jiný pohled na systém neţ ERD. Jelikoţ ale oba pohledy představují stejný systém, musí si v určitém smyslu odpovídat, neboť mezi oběma diagramy existují určité příbuznosti. Kaţdá paměť v DFD představuje úloţiště dat a její, struktura musí být určena v ERD. Samozřejmě i naopak musí platit, ţe kaţdý objekt v ERD musí být zpracován některým z procesů v DFD. Shodné části systému na různých typech grafů by měly mít stejný název. To znamená, ţe entitní mnoţiny na ERD by měly mít stejné pojmenování jako datová paměť v DFD. Konvence říká, ţe paměť v DFD má mnoţné číslo a entitní mnoţina v ERD jednotné. Pokud nedodrţíme shodné názvy, stává se model nečitelný, protoţe je obtíţné najít totoţný prvek v různých diagramech. DFD musí obsahovat procesy, které budou pracovat s daty uloţenými v pamětech, tedy vytvářet nebo rušit instance kaţdé entitní mnoţiny na ERD. Další důleţité procesy přiřazují hodnoty kaţdému datovému elementu, který je atributem v ERD, nebo hodnoty atributů z ERD čtou. Datový slovník obsahuje seznam všech datových objektů, které systémem projdou. Proto poloţky v datovém slovníku musí definovat entitní mnoţiny v ERD i obsah pamětí v DFD. Vyvaţování Stavově přechodového diagramu a Diagramu datových toků Kaţdý řídící proces v DFD musí mít odpovídající STD, který řídící proces specifikuje a naopak

23 Kaţdá podmínka v STD musí odpovídat některému vstupnímu řídícímu toku, jeţ vede do řídícího procesu v DFD, pro který existuje STD. Jednoduše, kaţdý vstupní řídící tok do řídícího procesu v DFD sdruţeného s STD musí odpovídat náleţité podmínce v STD. Kaţdá akce v STD musí odpovídat výstupnímu řídícímu toku v řídícím procesu DFD, který je popsán určitým STD. [1] 3.7. Diagram struktury návrhu Model struktury systému je znázorněn jako graf, jehoţ uzly jsou programové jednotky moduly a hrany mezi nimi jsou vzájemné vztahy mezi jednotlivými moduly. Modularita je jedním z obecných principů redukce sloţitosti a v případě softwarových systémů umoţňuje dosáhnout jejich přehlednosti, srozumitelnosti a udrţovatelnosti. Směr dat Směr řízení Transakční centrum Výběr Obr. 10: Notace SSD Opakování Lexikální vsuvka Moduly, které jsou na vyšší úrovni, řídí nebo volají moduly na úrovni niţší, jeţ jim poskytují dílčí funkcionalitu. Ověřený vstup Editace absence Čtení absence Ověřený vstup Zápis absence Vstup Ověřený vstup Vstup Čtení vstupu Ověření vstupu Obr.11 : Příklad SSD. Editace absencí

24 4. Yourdonova strukturovaná analýza Metodiku lze chápat jako teoreticko-praktické schéma, které určuje způsob, jak provádět různou odbornou činnost. Analytická metodika představuje souhrn doporučených praktik a postupů, pokrývajících celý ţivotní cyklus vytvářené aplikace. V oblasti strukturované analýzy existuje mnoţství metodik, které pouţívají různé typy modelů i postupů, jak je vytvořit.[9] Další část bakalářské práce obsahuje popis patrně nejznámější z analytických metodik Yourdonovu strukturovanou analýzu, jeţ vychází z kritiky DeMarca. Edward Yourdon, mezinárodní softwarový konzultant, představil svou metodiku v roce Metodika YMSA se dělí na esenciální a implementační model Esenciální model systému Esenciální model slouţí k tomu, aby uspokojil poţadavky uţivatelů. Odráţí podstatu systému, aniţ by závisel na implementačních a technických omezeních, coţ předpokládá dokonalou technologii a ţádné náklady. Jakmile začne analytik konzultovat své představy s představami zákazníka, měl by se vyvarovat přílišných detailů a zaměřit se na pohled zvenčí, tedy na to, jak bude systém vnímat uţivatel a nezacházet do vnitřních vrstev, jejichţ funkčnost je pro laika nesrozumitelná. Esenciální model by měl popisovat obsah datových toků a skladů, aniţ by se zmiňoval o technických záleţitostech nebo fyzické organizaci dat. Esenciální model se skládá ze dvou hlavních komponent: Model okolí Model chování Model okolí definuje hranice mezi okolím systému a prostředím, v němţ bude systém implementován. Skládá se z kontextového diagramu, seznamu událostí, a popisu účelu systému. Model chování popisuje, jak by se měl systém chovat uvnitř. Tento model se dělí na dvě dílčí fáze: Vytvoření prvotního modelu chování a dokončení esenciálního modelu, který obsahuje diagram datových toků, entitně relační diagram, stavový diagram, datový slovník a minispecifikaci transformačních procesů na nejniţší úrovni DFD.[1] [2] Model okolí systému Popis účelu Jedná se o stručný textový dokument, jenţ vyjadřuje hlavní cíle, kterých by mělo být dosaţeno po realizaci systému. Hlavním smyslem tohoto spisu je seznámit zákazníka, popř. vedení zákaznické firmy s vývojem systému a s veškerými cíli, jeţ by měly být dosaţeny vývojem zadaného systému. V příkladu vysvětluji, co očekávám od ISu základní školy a jaký je smysl systému. Účelem vývoje Informačního systému základní školy je vytvořit účinný nástroj pro vedení agendy jakékoli základní školy. Ředitelství školy se může dotazovat na veškeré informace obsažené v systému, vytváří rozvrhy, přiřazuje učitele k jednotlivým třídám a předmětům a registruje osoby, které mohou přistupovat do systému. Každý pátek ve stejnou dobu ředitelství obdrží přehled absencí všech žáků ve škole. Učitelé mohou vkládat známky a absence jednotlivých žáků a informovat o svých vyučovacích hodinách. Třídní učitel má přístup ke všem hodnocením a absencím, které se týkají žáků v jeho třídě. Zákonný zástupce žáka se může informovat o studiu svého dítěte

25 Kontextový diagram Kontextový diagram je speciální případ DFD, kde existuje pouze jeden proces a ten reprezentuje celý systém.(obr.16) Zdůrazňuje některé rysy systému. Lidé nebo systémy, s nimiţ systém komunikuje, se zobrazují jako terminátory. Terminátor komunikuje pouze se systémem. Není moţné zakreslit komunikaci mezi terminátory, jelikoţ taková komunikace se netyká systému(obr. 12). Obr. 12: Komunikace mezi terminátory Jestliţe nastane situace, kdy má terminál velké mnoţství vstupů a výstupů, je přehlednější takový terminátor zakreslit vícekrát (obr. 16). Analytik musí rozlišit mezi zdrojem dat a jejich nositelem. Nositelem dat je zařízení, mechanismus nebo přenosové medium pouţívané pro přenos dat z nebo do systému. Terminátor se váţe k uţivateli, jenţ má nějakou roli a je zdrojem dat. Podle této role se zvolí název terminátoru. Komunikace mezi terminátory a systémem je znázorněna orientovanou křivkou, tokem. Informace, které systém obdrţí, musí zpracovat a poté uloţit nebo poslat na výstup. Při znázorňování toků se vyhýbáme implementačně závislým prvkům dialogu (obr. 13). Obr. 13 Nesprávná komunikace terminátoru se systémem Pokud systém posílá data aţ po výzvě, přichází tato výzva z vnějšího prostředí, a tudíţ musí být zakreslena v kontextovém diagramu (obr.14). Data, která jsou určena pro jiný systém, nebo data, která zpracovává jiný systém a jsou určena pro vyvíjený systém, se znázorňují externí pamětí. Komunikace mezi externí pamětí a vyvíjeným systémem se znázorňuje podle typu komunikace. Obr. 14: Komunikace terminátoru se systémem Na obr. 15a vyvíjený systém ukládá data pro jiný systém, který si v případě potřeby uloţená data vyţádá. Na obr. 15b si systém odebírá zpracovaná data od jiného systému. Obr

26 ukazuje část kontextového diagramu s komunikaci mezi systémem a terminátorem učitel. Úplný kontextový diagram je znázorněn v příloze. Obr. 15a: Zápis do paměti Obr. 15b: Čtení z paměti Seznam událostí Obr. 16 Příklad kontextového diagramu Seznam událostí je výčet všech podnětů, které dostává systém od okolního světa a na něţ musí určitým způsobem reagovat. Kaţdá událost je označena písmeny F(flow-oriented), C(control) nebo T(temporal). F-tok značí událost, která je podmíněna dotazem od terminátoru. Tok obsahuje reálná data, s nimiţ systém pracuje. T-tok je závislý na čase, coţ znamená, ţe v určitém časovém bodě přijde příkaz k vykonání činnosti definované v systému, coţ je řízeno vnitřním časovým taktem systému. T-tokem se většinou poţaduje denní zpráva o

27 stavu společnosti či změnách ve společnosti nebo generování formulářů či faktur apod. Důleţitým faktorem je čas, ve kterém musí být daná činnost provedena. Takţe například zpráva o stavu konkrétní společnosti musí být generována ve 3 hodiny odpoledne, aby si ji mohl ředitel společnosti projít a zkontrolovat splnění denního plánu. C-tok muţe být chápán jako speciální případ T-toku, který je spouštěn externím podmětem v nepředvídatelném čase, tudíţ není řízena vnitřním časovým rytmem systému, ale událostí. Rozdíl mezi F-tokem a C- tokem je v obsahu datového toku. F-tok obsahuje data, zatímco C-tok pouze signál k provedení nějaké činnosti, např. k vyhodnocení stavu některého procesu nebo vytvoření poţadovaného formuláře apod. Zde je uváděn příklad seznamu událostí pro Informační systém základní školy. Tento příklad popisuje události, které dostává systém prostřednictvím terminátoru učitel, jehoţ komunikace je zakreslena částí modelu okolí na obr.16.[1] [2] Učitel 01. dotazuje se na hodnocení (F) 02. dotazuje se na absence (F) 03. dotazuje se na profil 04. dotazuje se na rozvrh (F) 05. dotazuje se na informace o vlastních vyučovacích hodinách (F) 06. dotazuje se na seznam žáků (F) 07. edituje svůj osobní profil (F) 08. vkládá hodnocení (F) 09. vkládá absence (F) 10. edituje informace o svých vyučovacích hodinách (F) Doplňující části modelu okolí Model okolí můţe obsahovat i počáteční fázi E-R diagramu a datový slovník definující vnější paměti a toky. Středně velké systémy mohou mít v modelu chování desítky aţ stovky toků, a proto začít s datovým slovníkem v této fázi vývoje později ušetří čas. Pokud model okolí obsahuje externí paměti, můţe se vytvořit E-R diagram z jejího obsahu.[2] Konstrukce modelu okolí Existují dvě počáteční situace při vzniku systému. Buď jiţ nějaký systém existuje, ať jiţ manuální nebo zastaralý počítačový systém, nebo firma či organizace teprve svůj provoz začíná a vychází se pouze z představy zadavatele. Druhá situace není zcela obvyklá, a tak i zde se často vychází z jiţ zaběhlých systémů v podobných organizacích. Prvním krokem analytika je projít si s budoucími uţivateli poţadované funkce systému. Kaţdý uţivatel má většinou představu jen o určité části systému, ve které pracuje. Z nashromáţděných informací se vytvoří model okolí a definují podněty v seznamu událostí, jeţ do systému plynou z okolí prostřednictvím terminátorů. Je moţné, ţe analytik opomene některého uţivatele nebo jejich důleţité interakce. V tom případě je to povaţováno za hrubou chybu analytika a promítne se to do dalších částí vývoje systému. Model okolí je určen laikům pro vytvoření představy vyvíjeného systému a je poměrně jednoduché provádět úpravy a změny, pokud se zákazník rozhodne něco měnit. V čím pokročilejší fázi vývoje se systém nachází, tím obtíţnější a finančně náročnější je poţadovaná úprava

28 Můţe nastat situace, kdy analytik nemá dostatečné informace k vytvoření modelu okolí, např. systém se vytváří na zelené louce, a není jasné, s čím bude systém muset komunikovat. V tomto případě je vhodné začít s E-R diagramem, jenţ ukáţe poţadované objekty a vztahy mezi nimi. Pro kaţdou entitu v E-R diagramu se hledají vnější události, které vedou k jejímu pouţití, změně apod. Podle toho se sestaví seznam událostí, z něhoţ se vytvoří kontextový diagram.[2] Pokud jsou všechny prvky modelu okolí vytvořeny, zbývá prověřit následující fakta: Kaţdý vstupní tok na kontextovém diagramu je nezbytný pro rozpoznání události, pro vytvoření odezvy na událost nebo obojí současně. Kaţdý výstupní tok je odezvou na událost Kaţdá nečasová událost ze seznamu událostí by měla mít vstup, podle něhoţ systém detekuje její výskyt. Kaţdá událost musí produkovat okamţitý výstup jako odezvu nebo by měla uloţit data pro pozdější výstup či změnit stav systému Celý model okolí ISu základní školy je znázorněn v příloze Model chování Prvotní model chování Prvotní model chování vychází z kontextového diagramu, který byl vytvořen jako součást modelu okolí. Hlavním úkolem je dekompozice systému na dílčí procesy a definovat datové sklady. Při dekomponování kontextového diagramu se postupuje metodikou zdola-nahoru, coţ znamená začít od nejniţší vrstvy DFD a postupovat směrem ke kontextovému diagramu. Pro kaţdou událost v seznamu událostí nakreslíme proces, jenţ bude zpracovávat data vyslaná terminátorem. Procesy jsou pojmenovány tak, aby jejich název vystihoval reakci na událost, která je s nimi spojená. Název procesu by měl být odpovědí na otázku: Jakou reakci systém předpokládá, aby byl schopen vytvořit poţadovanou událost? Kaţdý proces má zakresleny vstupní a výstupní toky a paměti tak, aby proces byl schopen vytvořit poţadovanou reakci. (obr.17) V případě, ţe bude existovat více procesů, které budou provádět totoţnou činnost, nebo-li v systému je více událostí, na něţ reaguje pouze jedna odezva, potom se sloučí pod jeden proces. Naopak je moţné, ţe systém vytváří více odezev pouze na základě jedné události, potom je nutné zakreslit pro kaţdou odezvu samostatný proces. Tady je důleţité správně pojmenovat procesy, aby nedošlo pouze k totoţnému pojmenování odlišných činností a následnému sloučení různých procesů. Souběţně s DFD se modeluje i ERD (Obr.18). Data, která proces zpracuje, jsou ukládána do datových skladů, kde se uchovávají pro další pouţití. V případě, ţe proces zpracuje data a vyšle je dalšímu procesu, který ovšem nemůţe data okamţitě zpracovat, je nutné mezi zúčastněné procesy vloţit esenciální paměť, jeţ data přechová do doby, neţ budou moci být pouţita. Názvy datových skladů reprezentují obsah v mnoţném čísle. Entity v ERD, které definují datové sklady v DFD, mají shodný název, pouze jsou prezentovány jednotným číslem. Pokud v DFD existují řídící toky a procesy, modelují se jejich funkce v STD. Poté, co se rozloţí celý systém, se vzniklý DFD porovná s kontextovým diagramem a seznamem událostí, jestli si všechny části odpovídají. Pro jednodušší orientaci by si měly odpovídat i čísla procesů s číslem události v datovém slovníku. Pro číslování procesů se pouţívá tečková notace, coţ znamená, ţe má-li proces číslo n, jsou jeho podprocesy o úroveň

29 níţe číslovány n.1, n.2 atd. Číslování procesů nemá ţádnou souvislost s pořadím, v jakém jsou procesy vykonávány.[2] Obr.17: Prvotní model chování Prvotní model chování se nekonzultuje se zákazníkem, neboť pro laika není dostatečně srozumitelný.[1] Celý prvotní model chování ISu základní školy je znázorněn v příloze. Datový slovník Dotaz na hodnoceni ID zaka predmetu Hodnoceni ID zaka predmetu + Hodnoceni + (Poznamka) Dotaz na absence zaka Absence zaka + (Do) + (Omluva) Dotaz na profil profilu ID profilu = [@ID Tridy] Profil = [Ucitel Zak Zastupce Predmet Ucebna Trida] Ucitel ucitele + (Titul) + Jmeno + Prijmeni + Telefon1 + (Telefon2) + + Ulice + Mesto Zak zaka ID zastupce + Jmeno + Prijmeni + Datom narozeni + Misto narozeni + Obcanstvi + Ulice + Mesto + Poznamka Zastupce = ID zastupce + (Titul) + Jmeno + Prijmeni + Telefon1 + (Telefon 2) + + Zamnestnavatel + Ulice + Mesto Predmet predmetu + Nazev + Studijni plan Ucebna ucebny + Specifikace + Cislo dveri Trida tridy SR ucitele + Nazev + Pocet zaku Dotaz na rozvrh predmet tridy ucitele +@ID ucebny Rozvrh predmetu tridy ucitele ucebny + Datum a cas + Obsah hodiny

30 Dotaz na hodinu predmetu tridy ucitele ucebny Hodina = Obsah hodiny Dotaz na seznam zaku tridy Seznam zaku ve tride = {@ID zaka + Jmeno + Prijmeni} Zmeneny profil ucitele + (Titul) + (Jmeno) + (Prijmeni) + (Telefon1) + (Telefon2) + ( ) + (Ulice) + (Mesto) Zmenene hodnoceni zaka predmetu + Hodnoceni + (Poznamka) Zmenena absence zaka + (Do) + (Omluva) Obr.18: ERD Dokončení modelu chování Dekompozice DFD Prvotní model chování je velice nepřehledný a je zapotřebí vytvořit jeho vyšší úrovně, ve kterých budou příbuzné procesy skryty pod jeden proces. Tím se nám celý model zjednoduší a zpřehlední. Kaţdá skupina procesů sjednocena pod jeden proces musí mít podobné odpovědi, tudíţ týkající se jedné záleţitosti. Paměť, jeţ je pouţívána pouze skupinou procesů, které jsou sjednoceny pod společný proces na vyšší úrovni, se skryje do společného procesu také. Pravidlo 7±2, které se pouţívá při tvoření procesů, naznačuje, ţe není vhodné, aby jediný proces obsahoval více neţ 9 a méně neţ 5 procesů a pamětí na niţší úrovni. Například pokud máme na jedné úrovni 14 procesů, je vhodné, abychom je rozdělily do dvou na vyšší úrovni. Pozor na bezhlavé dodrţování pravidla 7±2. Vţdy se snaţíme skrýt paměť s procesy, jeţ pracují přímo s konkrétní pamětí, do jednoho procesu na vyšší úrovni, coţ by měl být prvotní důvod pro vytvoření nadřazeného procesu, a ne jen bezduché dodrţování pravidla. [2]

31 Občas se některý z procesů ještě musí rozloţit na niţší úrovni. Při konzultaci s uţivatelem nebo v průběhu popisu minispecifikace se zjistí, ţe proces je příliš sloţitý a je moţné jej ještě dekomponovat. Jestliţe je funkční dekompozice nezřetelná, lze dekompozici odvodit podle vstupních a výstupních toků (obr.19) X Y X Proces Y Proces Zpracování vstupu Y Zpracování vstupu Y Obr. 19: Odvození dekompozice Při kaţdém kroku, ať se jedná o dekompozici nebo sdruţování, se musí neustále model vyvaţovat oproti datovému slovníku.[2] Dokončení datového slovníku a minispecifikace Je dobrým zvykem začínat vyvíjet datový slovník spolu s předběţným DFD. Kaţdá poloţka v datovém slovníku musí být interně konzistentní, coţ znamená, ţe různé poloţky si nesmí vzájemně odporovat, a zároveň se musí zkontrolovat se všemi úrovněmi DFD, ERD a minispecifikaci. Minispecifikace procesů na nejniţší úrovni se píše aţ po vytvoření předběţného modelu chování, protoţe procesy v předběţném DFD se neustále mění, ruší nebo přidávají.[2] Dokončení ERD ERD je vyvíjen v návaznosti na DFD. Po dokončení obou modelů je ERD dále zlepšován, coţ můţe být například doplnění entit o vhodné atributy. [2] Dokončení STD Pokud systém provádí nějakou činnost, jeţ je závislá na čase, vyvíjí se STD (obr.20) spolu s DFD a ERD. Aby mohl být STD dokončen, je důleţité znát chování systému jako celku. Existuje několik otázek, na něţ by měl být analytik schopen odpovědět: Uţ jsou definovány všechny stavy, ve kterých se systém můţe nacházet? Můţe systém dosáhnout všech definovaných stavů? Můţe systém změnit stav, ať se nachází v jakémkoli z definovaných stavů? Odpovídá systém v kaţdém stavu správně na všechny moţné podmínky? Po tom, co jsou všechny části esenciálního modelu vytvořeny, je důleţité je navzájem porovnat a ujistit se, ţe někde nedošlo k nekonzistenci dat. Další fáze vývoje systému není jen záleţitostí analytiků, ale podílí se na ní i návrháři a programátoři. [2] Pátek 14:00 Vyhledává ní absencí Signal od Reditelstvi Vyhledej absence Obr. 20: Stavový diagram

32 4.2. Implementační model Implementační model je poslední částí metodiky YMSA. Na vývoji posledního modelu se podílí spolu s analytiky i návrháři a programátoři. Uţivatele většinou nezajímá, jak systém funguje uvnitř, ale jak bude vypadat komunikace mezi systémem a uţivateli nebo jakou podobu budou mít výstupy ze systému. Implementační model vymezuje části systému, jeţ bude vykonávat systém automaticky nebo jeţ bude uţivatel vykonávat manuálně. Řeší detaily komunikace mezi uţivatelem a strojem. [2] Vymezení hranic Esenciální model vymezuje všechny funkce a všechna data, jeţ bude systém pouţívat. Otázkou je, která data bude vykonávat uţivatel manuálně a která systém automaticky. Hranice mezi systémem a okolním světem znázorněny v esenciálním modelu nejsou většinou striktní. Při tvorbě implementačního modelu se určuje, jakou část systému můţe uţivatel přímo ovlivňovat. Většinou se jedná o změny ve formátu výstupu a podobně. Občas se můţe stát, ţe uţivatel chce příliš systém ovlivňovat a je na řešitelském týmu, aby usměrnil poţadavky uţivatelů na únosnou míru, jinak můţe uţivatel zasahovat do systému natolik, ţe ovlivní jeho správný chod. Po určení manuální části systému má analytik za úkol popsat, jak bude uţivatel postupovat, aby docílil poţadovaných výsledků, pokud dosud uţivatel nemá zkušenosti s jinými informačními systémy. Jednou z částí implementačního modelu je rozdělit data a funkce znázorněné v DFD a v ERD do manuální a automatické části systému.(obr. 21)[2] Manuální část Automatická část Obr.21: Skrytí manuálních procesů do terminátoru

33 Vymezení uţivatelského rozhraní Vymezení uţivatelského rozhraní je část, která je obvykle časově náročná, ale uţivatele zajímá nejvíce. Zahrnuje výběr vstupních a výstupních zařízení, formáty všech vstupů proudících z terminátorů do systému, výstupů proudících ze systému zpět do terminátorů, posloupnost a načasování vstupů a výstupů v systému. Mezi vstupní zařízení patří: pracovní stanice, telefony, scannery, hlasová vstupní zřízení, čtečky, CD/DVD mechaniky apod. Jako výstupní zařízení se definují: Monitory, tiskárny, hlasová výstupní zařízení, optické disky apod. Poté, co je hardware vybrán, se uţivatel musí domluvit s analytikem na poţadovaném formátu vstupu, obzvláště pokud má systém přijímat data od jiných vnějších systémů. Stejně tak výstup musí splňovat určený standart především, je-li určený pro další zpracování jinými společnostmi nebo úřady. Jakou podobu mají data uvnitř systému není pro uţivatele důleţité. Datový slovník a minispecifikace řeší, s jakými daty a jak systém pracuje, ale jiţ neřeší posloupnost jednotlivých vstupů a výstupů. To můţe být vhodně modelováno v STD. Uţivatelské rozhraní, vhodné pro jakkoli zkušeného uţivatele, by mělo, např.: poţadovat vstupy a produkovat výstupy v určené, neměnné podobě při zjištění chybných dat na vstupu, poslat hlášení s přesným popisem chyby a výskytu umoţňovat zrušit část jakékoliv transakce nebo celou transakci průběhu zpracování poskytovat vhodné pomocné mechanismy, aby uţivatel nemusel listovat v mnohostránkových manuálech, ale pouze zadal popis problému a systém vyhledal informace, které uţivatel poţaduje poskytovat grafické rozhraní nebo příkazový řádek podle schopností a poţadavků uţivatele informovat uţivatele, ţe systém je zaměstnán, pokud vykonává časově náročnou operaci, např.: Systém pracuje, prosím čekejte. mít přijatelnou grafickou a zvukovou podobu Manuální podpora V esenciálním modelu analytik předpokládá, ţe technologie, které jsou implementovány, nebudou mít ţádné poruchy a nebudou vytvářet chyby. Občas se některý uţivatel rozhodne mít plnou kontrolu nad některou částí systému, například nad formátem výstupu apod. Ve většině případů se dodatečné manuální podpory systému zakreslují jako nové procesy v DFD v modelu chování. Existují čtyři kritické činnosti, při nichţ nejčastěji dochází k různým problémům: posílání vstupu do systému provedení výpočtu uchovávání dat v pamětech posílání dat ze systému Úkolem implementačního týmu je navrhnout řešení, jak minimalizovat ztráty nebo špatné zacházení s daty v systému

34 Stanovení provozních omezení Implementační tým musí rozhodnout, jakou kombinaci hardwaru, operačního systému, komunikačního zařízení, programovacího jazyka apod. bude nejlepší zvolit pro vyvíjený systém. To se ovšem nevyhne různým omezením, se kterými esenciální model nepočítal. Např.: Velikost paměti, rychlost přesunu a objem přenesených dat z paměti i do paměti. Časová odezva na vstup Zákazník trvá na uţití konkrétního hardwaru nebo programovacího jazyka apod. Speciální nároky prostředí, ve kterém bude systém provozován. (teplota, vlhkost, spotřeba energie, hluk, ) Spolehlivost a dostupnost Práva a oprávnění pro jednotlivé uţivatele

35 5. Strukturovaný návrh Návrh je další etapou ve vývoji systému. Není ovšem výjimkou, ţe i návrh vyvíjí stejný člověk jako analýzu. V předchozí kapitole je popsán uţivatelský implementační model, na kterém spolupracuje spolu s analytikem i návrhář a programátor. Právě při tvorbě implementačního modelu se musí analytik ujistit, zda dobře chápe poţadavky uţivatele, zatímco návrhář musí zajistit, aby poţadavky uţivatele mohli být realizovány v současné počítačové technologii. Proto musí návrhář dobře pochopit práci analytika, a tak je jednodušší, pokud obě fáze vykonávají ti samí lidé. Ve fázi návrhu systému se tvoří několik modelů. Pokud návrh vychází ze strukturované analýzy, čerpá z DFD, v němţ se hledají posloupnosti v práci procesů, které začínají příchodem vstupních dat od terminátorů a pokračují v poţadovaných intervalech. Procesy z DFD se rozdělují podle funkce, na transformační a transakční. Transformační procesy transformují vstupy na výstupy. Transakční procesy převádí data dalším procesům podle obsahu, čímţ vytváří pomyslná rozcestí, na kterých se větví datové toky. Návrh datových toků pouţívá dvě základní techniky: transformační a transakční analýzu. Pomocí nich se vytvoří výchozí kostra SSD (System Structure Diagram), která je rozpracována faktorizací struktur, za niţ následuje revize prvotního návrhu s pouţitím návrhové heuristiky Transformační analýza DFD, který byl vytvořen v první fázi vývoje systému, slouţí v transformační analýze k vyhledání transformačních center, jeţ se v podobě modulů přenesou do SSD (obr.22). V DFD se postupuje od terminátoru po vstupních tocích směrem do vnitřních částí modelu do té doby, neţ data, která po těchto tocích plynou, nejsou zpracována. Tok před samotným zpracováním se označí značkou. V případě výstupních toků je postup stejný, jen se postupuje od terminátoru v protisměru toku dat do středu diagramu. Ve chvíli kdy se narazí na procesy, která data zpracovávají a ne jen formátují pro výstup, se poslední tok před vstupem do procesu označí. Všechny označené toky se spojí křivkou a vzniklá podmnoţina grafu, tvoří centrální transformaci DFD. V případě, ţe podmnoţinu grafu tvoří více jak jeden proces, přidá se další proces, přes který jsou přesměrovány všechny toky mezi procesy v podmnoţině grafu a tento proces je prohlášen za centrální transformaci. Kořen SSD označuje centrální proces upraveného DFD, tedy ohraničenou podmnoţinu grafu. Nejvíce vlevo od kořene se přidávají pouze procesy generující data pro centrální proces a nejvíce vpravo jsou přidávány procesy přijímající data od centrálního procesu. Mezi centrálním procesem a procesy na okrajích stromu jsou procesy, jeţ přijímají i produkují data. Z těchto procesů se vytvoří bezprostřední následníci centrálního procesu. Vazby mezi procesy reprezentují přenášená data. Stejným způsobem pokračujeme i na niţších úrovních

36 Vstupní toky Transformační toky Výstupní toky 1. úroveň faktorizace: Hlavní řadič Řadič vstupů Řadič transformací Řadič výstupů 2. úroveň faktorizace: Hlavní řadič Řadič vstupů Řadič transformací Řadič výstupů C D E F G H I J L M A B N Obr. 22: Transformační analýza 5.2. Transakční analýza Transakční centrum se vymezuje v případě, ţe se v DFD vyskytují transakční toky. Najde se proces slouţící jako výchozí bod akčních cest a ve struktuře systému se určí jako transakční centrum. Podgrafy, jeţ vzniknou v DFD vymezením transakčních center, se zobrazí do SSD jako následníci transakčního centra. Struktura podgrafů je zakreslena do celkového SSD spolu s transformačními moduly, podle způsob zpracování dat, s pouţitím transakční nebo transformační analýzy(obr.23)

37 Část transformační Vstupní toky Transakční centru analýzy Transakční analýza: Hlavní řadič C D E A B Řadič H G I Obr. 23 Transakční analýza 5.3. Návrhové heuristiky Jakmile se dokončí transformační a transakční analýza je nutno vzniklý SSD optimalizovat podle návrhových heuristik. Nejvýznamnější heuristiky jsou: vyhodnotit primární programové struktury, jejímţ cílem je redukce propojení a zvýšení soudrţnosti minimalizovat rozšiřující se struktury a pokusit se přiblíţit větve se vzrůstající hloubkou udrţet obsah modulu v rozsahu, který je vymezen řízením datového modulu sniţovat sloţitost a nadbytečnost modulových rozhraní a zvýšit soudrţnost modulů definovat moduly s jasnou funkcí a vyhnout se příliš restriktivním modelům vyhledat moduly s jediným vstupem a výstupem a vyhnout se pochybným vazbám balit software s ohledem na návrhová omezení a poţadavky na přenositelnost Podrobnější popis a názorné příklady jsou uvedeny v literatuře [7]. Na závěr fáze návrhu se vytvoří textový popis funkce kaţdého modulu, který vychází z minispecifikace odpovídajících procesů na nejniţší úrovni DFD, a jeho rozhraní. Definují se lokální a globální datové struktury a uvedou se všechna omezení a meze návrhu. Poté je celý systém znovu přezkoumán a jsou zváţeny další moţnosti optimalizace

38 6. Závěr Vývoj v oblasti informačních technologií je velice rychlý a technologie se neustále mění. Jiţ teď je jasné, ţe strukturovanou analýzu nahradila objektová analýza, jejíţ ucelené metody se začaly objevovat aţ začátkem 90. let. Objekty tvořící modely objektové analýzy, jsou reprezentace předmětů reálného světa. Velmi často se objektová a strukturovaná analýza kombinují, tudíţ metody a přístupy, které strukturovaná analýza přinesla, se uplatňují dále i v analýze objektové. Tvorba sloţitých systémů se neobejde bez dobře propracované analýzy a následně i návrhu. Nároky, které jsou kladeny na informační systémy, neustále rostou a tím i náročnost práce analytických a návrhářských týmů. Existuje celá řada metodik, která mají pomoci řešitelským týmům zanalyzovat a navrhnout potřebný systém, jenţ by splnil očekávání zákazníka a efektivně slouţil uţivatelům. To, kterou z moţných metodik si tvůrci zvolí, většinou záleţí na jejich zkušenostech a praxi. YMSA je jednou z nejrozšířenějších metodik strukturované analýzy, která obsahuje kompletní sadu nástrojů k vytvoření analýzy systému tak, aby vypracované studie slouţily nejen samotným analytikům, ale i dalším členům vývojového týmu a budoucím uţivatelům, jenţ si podle vytvořených diagramů a textových materiálů dokáţí představit vzhled a funkčnost budoucího systému. DFD i ERD, jeţ jsou součástí této práce byly vytvořeny v modelovacím nástroji CASE STUDIO 2, který je určen pro vytváření modelů analýzy. Pro účely výuky je v CD přiloţen soubor slidů, které obsahují stručný přehled celé metodiky

39 7. Informační zdroje [1.] RÁČEK, JAROSLAV,. Strukturovaná analýza systému. Masarykova univerzita, Brno, ISBN [2.] YOURDON EDWARD, Modern Structured Analysis. Prentice-Hall, Englewood Cliffs, ISBN [3.] RÁČEK, JAROSLAV. SOCHOR JIŘÍ. OŠLEJŠEK RADEK, Studijní materiály předmětu FI:PB007. Výukové materiály předmětu Analýza a návrh systémů, Masarykova univerzita,fakulta informatiky. [online]. [4.] DEMARCO, TOME, Structured analysis and system specification, Yourdon Press,1978, ISBN: [5.] DRBAL, PAVEL, Základy softwarového inţenýrství: jak psát dobře strukturované programy, VŠE, Praha, 2003 [6.] KRÁL, JAROSLAV, Informační systémy,sience,veletiny, 1998, ISBN [7.] YOURDON, EDWARD, CONSTANTINE, LARRY, Structured Design, Prentice- Hall,Englewood Cliffs, 1987, ISBN [8.] Richta, KAREL, SOCHOR, JAROSLAV, Softwarové inţenýrství I.,VUT, Praha,1996 [9.] Wikipedie, otevřená encyklopedie. [online]. [10.] Databázový svět, Vyvíjíme databázový a informační systém. [online] [11.] Computerworld, Ţivotní cyklus vývoje systému. [online]. [12.] Manualy, Teorie relačních databází: Normalizace. [online]. [13.] Vladimír Šmíd, Ţivotní cyklus informačního sys mu.[online]. [14.] Rebood, Testování programů. [online]. [15.] Dubravcovi, Case nástroje. [online]

40 8. Přílohy Příloha A: Model okolí Obr. A. 1: Kontextový diagram Seznam událostí Ředitelství 11. dotazuje se na hodnoceni (F) 12. dotazuje se na profil předmětů, učitelů,ţáků a učeben (F) 13. dotazuje se na rozvrh učeben, tříd a učitelů (F) 14. dotazuje se na seznam tříd, odborných učeben, ţáků ve třídě, učitelů a předmětů (F) 15. dotazuje se na informace o jednotlivých vyučovacích hodinách (F) 16. edituje rozvrh (F) 17. edituje profily (F) 18. registruje osobu (ţáka nebo učitele) do systému(f) 19. přiřazuje učitele k předmětům(f) 20. přiřazuje třídního učitele ke třídě(f) 35

41 21. poţaduje přehled absencí kaţdý pátek (T) Učitel 22. dotazuje se na hodnocení (F) 23. dotazuje se na absence (F) 24. dotazuje se na profil 25. dotazuje se na rozvrh (F) 26. dotazuje se na informace o vyučovacích hodinách (F) 27. dotazuje se na seznam ţáků (F) 28. edituje svůj osobní profil (F) 29. vkládá hodnocení (F) 30. vkládá absence (F) 31. edituje informace o svých vyučovacích hodinách (F) Třídní učitel 32. dotazuje se na veskeré hodnocení(f) 33. dotazuje se na absence (F) 34. edituje absence studenta (F) 35. edituje informace o ţácích ve své třídě (F) Zákonný zástupce ţáka 36. dotazuje se na hodnocení svého dítěte (F) 37. dotazuje se na absence svého dítěte (F) 38. dotazuje se na vyuč. hodiny (F) 39. dotazuje se na profil (F) 40. edituje svůj osobní profil (F) 36

42 Příloha B: Model chování Obr. B. 2: Prvotní model chování

43 Obr. B. 3: Dekompozice Obr. B. 4: Systémový model