Strukturovaná analýza informačních systémů

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Strukturovaná analýza informačních systémů BAKALÁŘSKÁ PRÁCE Martin Štíbal Brno, jaro 2008

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D. 11

3 Poděkování Chtěl bych poděkovat především vedoucímu mé bakalářské práce RNDr. Jaroslavu Rackovi, Ph.D. za vstřícný přístup, trpělivost, podklady, rady a v neposlední řadě také čas, který mi během jejího vypracovávání věnoval. m

4 Shrnutí Tato práce seznamuje s principy strukturované analýzy informačních systémů, se zaměřením na Yourdonovu moderní strukturovanou analýzu (YMSA). Cílem je provést analýzu knihovního informačního systému touto metodou a posoudit vhodnost použitého CASE nástroje. IV

5 Klíčová slova Yourdonova moderní strukturovaná analýza (YMSA), Informační systém (IS), Funkční (procesní) model systému, Diagram datových toků (DFD), Entitně relační diagram (ERD), Diagram datových toků s řízením (CDFD), Stavově přechodový diagram (STD), Datový model systému, Datový slovník (DD), Minispecifikace, Case Studio 2. v

6 , r» "Mte, Masarykova univerzita **., s»* / Fakulta informatiky ZADANÍ BAKALÁRSKE PRACE Student(ka): Program: Martin Štibai Fl B-AP Aplikovaná informatika, bakalářský studijní program Datum: Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D. Katedra (pracoviště): Katedra počítačových systémů a komunikací - Fakulta informatiky Název práce: Zadání: Strukturovaná analýza informačních systémů Seznámit se s principy strukturované analýzy informačních systémů, zaměřit se zejména na metodu YMSA. Provést analýzu vybraného informačního systému touto metodou. Následně diskutovat výhody a nevýhody použití YMSA pro daný systém, posoudit vhodnost použitého CASE nástroje. Postup analýzy zpracovat do podoby materiálů použitelných ve výuce. Základní literatura: Ráček, Jaroslav. Strukturovaná analýza systémů. Brno: Masarykova univerzita, s. FI. ISBN Souhlas se zadáním (podpis, datum) student(ka) -'vědoucí bakalářské práce vedoucíwdpovědného pracoviště

7 Obsah 1 Úvod 3 2 Modelovací nástroje strukturované analýzy Diagram datových toků (Data Flow Diagram - DFD) Kontextový diagram Seznam událostí Diagram datových toků s řízením (Control Data Flow Diagram - CDFD) Stavově přechodový diagram (State Transition Diagrams - STD) Minisp ecifikace Entitně relační diagram (Entity Relationship Diagram - ERD) Datový slovník (Data Dictionary - DD) 13 3 Yourdon Modern Structured Analysis (YMSA) Esenciální model Vytvoření modelu okolí systému Vytvoření prvotního modelu chování Dokončení esenciálního modelu Implementační model 18 4 Analýza informačního systému knihovny pomocí metody YMSA Model okolí systému Účel systému Kontextový diagram Seznam událostí Prvotní model chování Dokončení esenciálního modelu Implementační model 26 5 Závěr 27 A Seznam zkratek 30 B Struktura přiloženého CD 31 2

8 Kapitola 1 Úvod V dnešní době se informační technologie staly neoddělitelnou součástí našeho života. Protože se jejich obor uplatnění rok od roku zvětšuje, setkáváme se s nimi prakticky na každém kroku. Základním prvkem informačních technologií jsou softwarové produkty, které se dělí do dvou základních skupin podle toho, jaké cílové skupině je software určen. Do první skupiny patří software, který je určen pro širokou veřejnost a je k dostání v běžné obchodní síti. Druhou skupinu tvoří software vytvořený na míru zákazníka. Do této skupiny patří i informační systémy. Tvorba informačního systému se od tvorby běžného softwaru liší především vysokou komunikací mezi řešitelem a zákazníkem. Informační systém slouží především k uchování, zpracování a prezentaci dat. Návrh informačního systému je ale zdlouhavou a složitou záležitostí. Analýza patří mezi nejdůležitější části návrhu informačního systémů. Strukturovaná analýza je jedna z možností jak lze složitý návrh informačního systému zjednodušit a zpřehlednit. Především proto, že dělí analýzu na malé, dobře definované činnosti a určuje jejich posloupnost a vzájemné působení. Strukturovaná analýza používá pro návrh systému několik různých modelovacích nástrojů, které se vzájemně doplňují. Ty se podle pohledu na systém dělí na funkčně a datově orientované. Detailněji si je popíšeme v následující kapitole. Pro zjednodušení analytikovy činnosti existuje několik tzv. CASE (Computer Aided Software Engineering) nástrojů, které jsou velmi užitečné při návrhu informačního systému. Já jsem použil Case Studio 2 od české firmy Charonware. První část práce je zaměřena spíše teoreticky. V následující kapitole jsou popsány nejdůležitější modelovací nástroje strukturované analýzy. Ve třetí kapitole je podrobně popsána Yourdonova moderní strukturovaná analýza. Druhá část práce se věnuje vlastní analýze informačního systému knihovny pomocí metodiky YMSA. 3

9 Kapitola 2 Modelovací nástroje strukturované analýzy Při analýze systému je zapotřebí vytvořit několik modelů, které představují napodobeninu reálného systému. Tvorba modelů systému tvoří největší část práce systémového analytika. Tyto modely zachycují všechny důležité rysy a zakrývají nepodstatné rysy systému. Veliká výhoda modelů je, že analytikovi usnadňují komunikaci se zákazníkem. Pokud analytik navrhl modely dostatečně jednoduché a srozumitelné, aby je zákazník pochopil, může s ním diskutovat změny a opravy podle požadavků zákazníka s minimálními náklady a rizikem. Podle pohledu na systém se modely analýzy dělí na 2 základní skupiny [4]: 1. Funkčně orientované modely systému - Na systém se pohlíží jako na množinu funkcí transformujících data. Patří sem například DFD, CDFD a minispecifikace. 2. Datově orientované modely systému - Systém je chápán jako úložiště, ze kterého se zpětně získávají transformovaná data. Hlavními představiteli jsou ERD a datový slovník. Nejpoužívanější modelovací nástroje strukturované analýzy si popíšeme v následujících podkapitolách. 2.1 Diagram datových toků (Data Flow Diagram - DFD) Diagram datových toků (DFD) je jeden z nejpoužívanějších modelovacích nástrojů strukturované analýzy, který poskytuje funkčně orientovaný pohled na systém. Slouží tedy k modelování funkcionality systému. DFD zobrazuje systém jako síť procesů. Tyto procesy plní určité funkce a pomocí datových toků si mezi sebou předávají data [ ]. 4

10 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY Diagram datových toků obsahuje následující čtyři komponenty [5]: Terminátory reprezentují externí entity, které patří do okolí systému a se kterými systém komunikuje. Všechny informace, které systém přijímá nebo vysílá jsou vysílány, respektive přijímány terminátory. Terminátory jsou nejčastěji osoby nebo skupiny osob, ale mohou to být i jiné systémy, se kterými náš systém komunikuje. Analytik ani systém nemůže změnit obsah terminátorů nebo způsob jakým pracují. Procesy jsou jediné části systému, které převádějí vstupy na výstupy. Každý proces by měl být jednoznačně identifikován a vhodně pojmenován, buďto jedním slovem, jednoduchou větou nebo frází. Jméno vyjadřuje, co daný proces dělá. Ke každému procesu na DFD existuje buď minispecifikace viz 2.6, nebo je dekomponován na nižší úrovni DFD, kde jsou znázorněny jeho subprocesy Datové toky popisují pohyb informačních paketů nebo fyzických materiálů mezi jednotlivými částmi systému. Datové toky jsou pojmenovány podle toho jaká data přenášejí. Některé datové toky nemusí být pojmenovány, pokud je zřejmé jaká data přenášejí. Typicky to jsou datové toky směřující z nebo do paměti. Šipka znázorňuje směr toku dat. Řídící toky, které neobsahují žádná data se zakreslují přerušovanou čarou. Paměti jsou pasivní prvky systému, kde se data ukládají pro pozdější zpracování. Povolené operace jednoho datového toku nad pamětí jsou buď nedestruktivní čtení, zápis, modifikace nebo mazání. Yourdon: Terminátor: Název externí entity Proces: /- i --\ Datový tok:, ( Název i Název datového / >- \^procesu^/ toku Paměť: Název paměti Obrázek 2.1: Prvky DFD v notaci Yourdon [7] Pravidla a doporučení tvorby DFD [6]: Protože analytik nemůže měnit obsah terminátorů nebo způsob jakým pracují a paměti jsou pasivní prvky systému, tak se na DFD nemůže objevit přímý datový tok mezi dvěma terminátory, dvěma paměťmi nebo pamětí a terminátorem. Pokud chceme znázornit komunikaci mezi těmito komponentami, musíme mezi ně umístit alespoň jeden proces. S výjimkou komunikace terminátoru s paměti na rozhraní na kontextovém diagramu. 5

11 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY Každý proces na DFD by měl být očíslován z důvodu snazší identifikace, toto číslování se přenáší pomocí tečkové notace na nižší úrovně DFD. Stejné datové toky, terminátory, procesy a paměti se na všech úrovních DFD musí jmenovat stejně. Na jednom DFD by se z důvodu lepší čitelnosti mělo dodržovat pravidlo 7 ± 2. To znamená, že součet procesů a pamětí by měl být přibližně 7 na každé úrovní DFD. Na DFD by se neměl vyskytovat proces, který přijímá data od jednoho procesu a nezměněná je přeposílá dalšímu procesu. Nesmí existovat proces, který pouze přijímá data (datové toky do tohoto procesu pouze vstupují) a také nesmí existovat proces, který pouze odesílá svá generovaná data (datové toky z tohoto procesu pouze vystupují). V obou případech se většinou jedná o nerozpoznanou externí entitu. Datové toky mezi terminátory a procesy, stejně tak j ako mezi dvěma procesy, musí být pojmenované. Nesmí existovat terminátory, procesy a paměti bez přiděleného názvu. Na DFD nesmí nastat situace, kdy se z jedné části systému dostaneme do druhé pouze přes terminátor. Pokud tento případ nastane, tak se systém rozpadá na dva systémy. Na jednotlivých úrovních DFD musí souhlasit vstupní a výstupní datové toky u procesů a jim odpovídajících DFD na nižších úrovních. Paměť se opakovaně uvádí na všech DFD nižší úrovně, které dekomponují procesy spolupracující s pamětí. Pokud chceme dodržovat pravidlo 7 ± 2 tak na popsání jednoho systému zpravidla nestačí pouze jeden DFD. Proto mají DFD hierarchický charakter, kde diagram nižší úrovně popisuje složitější proces vyšší úrovně. Dekompozice procesů z vyšší úrovně na nižší úroveň se opakuje tak dlouho, dokud na nejnižší úrovni nevzniknou dostatečně jednoduché procesy, které lze popsat minispecifikací (viz 2.6). 2.2 Kontextový diagram Zvláštním případem diagramu datových toků je kontextový diagram. Určuje hranici mezi systémem a okolním světem. Systém je zde zobrazen jako jeden proces 6

12 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY a je propojen s okolním světem pomocí vstupních a výstupních toků. Z kontextového diagramu je tvořen seznam událostí, který je popsán v následující kapitole 2.3 [5]. Kontextový diagram také znázorňuje a zdůrazňuje tyto rysy systému [6]: osoby a jiné systémy, s nimiž systém komunikuje (terminátory), data přijímaná z okolního světa, které bude systém zpracovávat, data vysílaná do okolního světa, která systém produkuje, sdílené datové paměti, hranice mezi systémem a okolním světem. 2.3 Seznam událostí Seznam událostí je textový seznam všech akcí, které okolní svět může provádět nad systémem a na něž musí systém reagovat. Jednotlivé události se nejčastěji získávají tak, že se postupně procházejí všechny terminátory na kontextovém diagramu a pro každý terminátor se hledají akce, které může nad systémem provádět. Druhou možností, jak získat seznam událostí, je hledání událostí na ERD, které způsobí vznik, změnu a zánik instancí entit a relací. Každá nalezená událost je dále označena, podle toho, jak ji systém rozpozná [5]. Typy událostí [7]: F (Flow): tokově orientovaná událost, která je spjata s příjmem datových paketů, T (Temporal): časově orientovaná událost, která nastává v nějakém časovém bodě, C (Control): řídící událost, která je sdružena s řídícím tokem. 2.4 Diagram datových toků s řízením (Control Data Flow Diagram - CDFD) Pokud je v diagramu datových toků (DFD) potřeba vyjádřit časovou posloupnost procesů, tak rozšiřujeme DFD o řídící procesy a řídící toky. Po tomto rozšíření 7

13 vznikne diagram datových toků s řízením (CDFD). 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY Řídící proces zajišťuje pouze správnou časovou posloupnost ostatních procesů. Řídící procesy komunikují s ostatními procesy pomocí speciálních řídících toků tzv. vstupních a výstupních signálů. Vstupní signály informují řídící proces o splnění sledované události během transformace. Výstupními signály naopak dává řídící proces pokyny transformačním procesům [5]. Řídící procesy jsou na CDFD znázorněny elipsou zakreslenou přerušovanou čarou. Řídící toky jsou také zakresleny přerušovanou čarou. Každý řídící proces znázorněný na CDFD musí být specifikován pomocí stavově přechodového diagramu (STD) viz 2.5 STAVÍ signál X I aktivuj proces 2 J [ STAV 2 signál Y I aktivuj proces 3 y STAV 3 Obrázek 2.2: Notace CDFD a vztah s STD [< ] 2.5 Stavově přechodový diagram (State Transition Diagrams - STD) Stavově přechodový diagram (STD) musí existovat pro každý řídící proces zobrazený na CDFD. STD slouží jako specifikace řídících procesů a skládá se ze stavů a přechodů mezi nimi. Stav je zobrazen jako obdélník s názvem a přechod je znázorněn šipkou s popisem. Popis přechodu je rozdělen čarou na podmínku a akci. Podmínkou se rozumí událost ve vnějším okolí, kterou systém detekuje. Akce je reakce na splněnou podmínku. Pokud dojde ke splnění podmínky, tak nastává změna stavu, po které se provede akce [5]. 8

14 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY podmínka akce STAVÍ STAV 2 Obrázek 2.3: Notace STD [7] Každý stavově přechodový diagram má jen jeden počáteční stav a minimálně jeden koncový stav. Počáteční stav poznáme tak, že na něj ukazuje šipka. Koncové stavy jsou ty, ze kterých nevedou žádné přechody. Složité stavově přechodové diagramy je vhodné dekomponovat pro lepší přehlednost a srozumitelnost [5]. Pravidla pro tvorbu stavově přechodových diagramů [6]: identifikovat všechny možné stavy systému a zakreslit je na STD najít všechny přechody mezi stavy a začít je zakreslovat systematicky od počátečního do koncového stavu prověřit konzistenci a hierarchii STD prověřit konzistenci STD oproti jiným modelům systému 2.6 Minispecifíkace Každý proces na diagramu datových toků (DFD), který není triviální, je dekomponován na nižší úrovní. Pro všechny procesy, které jsou na nejnižší úrovni, existuje právě jedna minispecifikace. Minispecifíkace má za úkol srozumitelně popsat logiku procesů. Popisuje pravidla převodu vstupních datových toků na výstupní datové toky. Minispecifikace nikdy nesmí popisovat vlastní implementaci těchto pravidel, a také nesmí do modelu systému vnášet redundanci žádného druhu [7]. Existuje několik způsobů zápisu minispecifikace. Jednou z nejpoužívanějších forem je zápis pomocí strukturované angličtiny. Jedná se o běžný jazyk používající slovník. Z tohoto jazyka jsou vynechány zbytečné přívlastky, přídavná jména, složité větné konstrukce, interpunkční znaménka atd. Slovník strukturované angličtiny je složen z imperativních sloves, pojmů uvedených v Datovém slovníku (DD) viz 2.8 a slov použitých pro formulaci logických výrazů. Syntaxe je omezena na jednoduché oznamovací věty a uzavřené rozhodovací a opakovací konstrukce [5]. 9

15 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY 1. FOR EVERY objednávka DO 1.1. IF dodáni přepravní firmou THEN SELECT CASE 1 (Cena < 1000 Kč): Přepravné = 100 Kč; CASE 2 (1000 Kč <= Cena < 5000 Kč): Přepravné = 50 Kč; CASE 3 (Cena >= 5000 Kč): Přepravné = 0 Kč; 1.2. IF dodáni osobně na prodejně THEN Přepravné = 0 Kč; Obrázek 2.4: Příklad strukturované angličtiny Další velmi používanou formou zápisu jsou rozhodovací tabulky a rozhodovací stromy. Znázorňují různé kombinace podmínek a k nim příslušné akce. Na rozdíl od minispecifikace strukturovanou angličtinou, minispecifikace rozhodovací tabulkou nebo rozhodovacím stromem neovlivňuje, jaký algoritmus má při implementaci programátor použít. Velkou výhodou těchto zápisů je i jejich přehlednost [3]. Pravidla: Podmínky: Cena< 1000 Kč A N N A N N 1000Kč <= Cena < 5000 Kč N A N N A N Cena >= 5000 Kč N N A N N A Dodání je přepravní firmou A A A N N N Dodání je osobně na prodejně N N N A A A Akce: Přepravné = 100 Kč A N N N N N Přepravné = 50 Kč N A N N N N Přepravné = 0 Kč N N A A A A Obrázek 2.5: Příklad rozhodovací tabulky Třetí nejpoužívanější formou je zápis pomocí vstupních a výstupních podmínek tzv. preconditions a postconditions. Preconditions platí pro vstupní hodnoty a postcon- 10

16 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY ditions platí pro výstupní hodnoty [ ]. Následuje příklad. Precondition 1: Zákazník objednává zboží o celkové ceně menší jak 1000 Kč a nechává si ho doručit přepravní firmou. Postcondition 1: Účtuje se přepravné ve výši 100 Kč. Precondition 2: Zákazník objednává zboží o celkové ceně větší nebo rovno 1000 Kč a menší jak 5000 Kč a nechává si ho doručit přepravní firmou. Postcondition 2: Účtuje se přepravné ve výši 50 Kč. Precondition 3: Zákazník objednává zboží o celkové ceně větší nebo rovno 5000 Kč a nechává si ho doručit přepravní firmou. Postcondition 3: Účtuje se přepravné ve výši 0 Kč. Precondition 4: Zákazník si objednané zboží vyzvedne osobně na prodejně. Postcondition 4: Účtuje se přepravné ve výši 0 Kč. 2.7 Entitně relační diagram (Entity Relationship Diagram - ERD) Entitné relační diagram (ERD) je grafický nástroj reprezentující datový model. Pomocí ERD se popisují neměnné atributy struktura a vzájemné vztahy mezi entitnímy množinami, které není možné zachytit na funkčních modelech. Komponenty entitně relačních diagramů [5]: Entita je jednoznačně identifikovatelný datový objekt, o němž uchováváme informace. Obsahuje několik atributů (alespoň jeden), které ji popisují, a které si chceme v systému pamatovat. Entitní množina je množina entit stejného typu. Na ERD je reprezentována obdélníkem se jménem. Atribut představuje typ hodnot uchovávaných pro jednotlivé entity. Pomocí některých atributů lze jednotlivé entity jednoznačně identifikovat. Tyto atributy se označují jako klíčové. Každý atribut má svoji doménu. Doména atributu je množina přípustných hodnot atributu. 11

17 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY Vztah, neboli relace, propojuje jednotlivé entity, které mají mezi sebou určitou vazbu. Je znázorněn jako čára se jménem vztahu. Druh čáry určuje typ vztahu. Plná čára reprezentuje identifikující vztah (do primárního klíče podrazené entity se zkopíruje primární klíč nadřazené entity), čárkovaná čára reprezentuje neidentifikující vztah (primární klíč nadřazené entity se zkopíruje jako cizí klíč do podrazené entity) a čerchovaná čára znázorňuje informativní vztah (nic se nekopíruje, vyjadřuje pouze vztah mezi entitami). Na obou koncích čáry je znázorněna arita vztahu, která pro každou entitu v entitní množině udává, s kolika entitami z jiné entitní množiny může být ve vztahu. Značení v ERD A - B právě jedna Počet entit B, které mohou být ve vztahu s jednou entitou A A -o B žádná nebo jedna H - < B 0 -* B alespoň jedna žádná, jedna nebo více Obrázek 2.6: Možné arity relací [5] V některých případech se můžeme setkat s aritou relace M:N, která se často převádí na dva jednodušší vztahy 1:N. Po tomto převodu vznikne asociovaná entita. Například, pokud dodavatel vystavuje několik faktur více zákazníkům a zákazníkovi je vystaveno několik faktur od různých dodavatelů, můžeme zavést asociovanou entitu faktura. Vztahová množina reprezentuje množinu vztahů stejného typu. Tvorba ERD se nejčastěji řídí následujícím postupem [ ]: Po pochopení zákazníkovy aplikace se vytvoří iniciální ERD. Poté se začnou přidávat entitní množiny a vztahy mezi nimi s příslušnou aritou. Následuje přidání atributů a označení některých atributů primárními klíči. Dalším krokem je prověrka entit na základě seznamu datových elementů. Předposledním krokem je odstranění entitních množin, které mají pouze jedinou entitu, jsou tvořené jenom identifikátorem nebo mají odvozené vztahy. Na závěr se ověří správnost a úplnost vzniklého ERD. 12

18 2. MODELOVACÍ NÁSTROJE STRUKTUROVANÉ ANALÝZY Pokud se v textu objevuje slovo entita nebo vztah považujte ho ve smyslu entitní množina respektive vztahová množina. 2.8 Datový slovník (Data Dictionary - DD) Datový slovník je organizovaný a centralizovaný seznam všech datových prvků systému. Skládá se z popisu dat v datových tocích a pamětech použitých na DFD a také z entit a atributů, které jsou zobrazeny na ERD. Pokud je při analýze použit i jiný modelovací nástroj, např. STD, tak i jeho objekty jsou popsány v datovém slovníku. Datový slovník může být vytvářen ručně, např. ve formě tabulky, nebo automaticky na základě popisů složek grafických modelů v CASE nástroji [5]. Datové prvky mohou být v datovém slovníku popsány buď elementárně nebo složené. Elementární popis představuje přípustný obor hodnot. Složený popis představuje odkaz na jiné elementární nebo složené složky, které se mohou opakovat nebo nevyskytovat vůbec [ ]. Operátory, které se k tomuto zápisu používají shrnuje následující obrázek. Symbol Význam... =... skládá se z a (...) nepovinný prvek [...I...1 výběr jedné z možností {...} iterace * * komentář - identifikátor, klíč Obrázek 2.7: Operátory datového slovníku [2] Příklad datového slovníku: student + titul + křestní_jméno + + ( prostřední_jméno ) + příjmení UČO = {0 až 9} titul = [ null Bc. Mgr. Ing. Dr. Prof. ] křestní_jméno = { povolený_znak } prostřední_jméno = { povolený_znak } příjmení = { povolený_znak } povolený_znak = [ a až ž A až Ž ] 13

19 Kapitola 3 Yourdon Modern Structured Analysis (YMSA) Metodiky strukturované analýzy popisují jednotlivé kroky analýzy. Jedná se zejména o jejich pořadí, pravidla tvorby modelů systému a jejich vzájemné vyvažování. V této kapitole si popíšeme Yourdonovu moderní strukturovanou analýzu (YMSA). Yourdonova moderní strukturovaná analýza patří mezi nejpoužívanější metodiky strukturované analýzy. Ed Yourdon ji představil v roce Vychází z jeho dvacetiletých zkušeností vývoje systémů. Hlavním cílem této analýzy je nalézt esenciální model, ze kterého se následně odvodí implementační model [7]. 3.1 Esenciální model Esenciální model má za úkol zachytit všechny potřeby a požadavky uživatelů na systém. Nemají na něj vliv implementační ani technická omezení. Každý proces pracuje nekonečně rychle a každý datový tok má nulové zpoždění [7]. Esenciální model se skládá z následujících částí [5]: model okolí systému - vytvoření modulu okolí model chování systému - vytvoření prvotního modelu chování - dokončení esenciálního modelu 14

20 3. YOURDON MODERN STRUCTURED ANALYSIS (YMSA) ( 1. Analyzuj stávající systém poznatky o vnějším chovaní stávajícího systému D Vytvoř esenciální model esenciální model systému f-^ 1 3. Navrhni implementaci technická a uživatelská dokumentace < ' O «-^- Obrázek 3.1: Analýza systému pomocí esenciálního modelu (Yourdon) [i ] Vytvoření modelu okolí systému Model okolí systému definuje hranice mezi okolním světem a systémem. Znázorňuje, s kým bude systém komunikovat a na jaké události z vnějšího světa bude reagovat. Rozhraní může být stanoveno na základě manažerského rozhodnutí nebo zcela náhodně [5, 7]. Nástroje používané k definování okolí [7]: účel systému, kontextový diagram, seznam událostí. Účel systému je krátký, stručný a výstižný textový dokument, určený pro pracovníky na řídících funkcích. Popisuje hlavní strategické cíle, které by měly být dosaženy po realizaci a nasazení systému [5]. Kontextový diagram, jak již bylo popsáno v kapitole 2.2, je zvláštní případ diagramu datových toků (DFD), který slouží k grafickému znázornění hranice mezi systémem a okolním světem. Seznam událostí jsem již také popsal v kapitole 2.3. Slouží k zachycení událostí, které se objevují v okolním světe a na něž musí systém reagovat. 15

21 Existují dva různé způsoby tvorby modelu okolí [ ]: 3. YOURDON MODERN STRUCTURED ANALYSIS (YMSA) 1. Kontextový diagram sestavíme na základě informací od uživatelů. Z kontextového diagramu odvodíme seznam událostí. Tento způsob se používá častěji. 2. Nejprve se vytvoří entitně relační diagram (ERD). Zkoumáním ERD se naleznou esenciální entity a vztahy mezi nimi. Pro každou entitu hledáme, jaké události zapříčiní její použití. Z těchto nalezených událostí sestavíme seznam událostí a z něho následně vytvoříme kontextový diagram. Souběžně s již zmíněnými třemi částmi modelu okolí vznikají i další modely systému. Jedná se zejména o datový slovník viz 2.8 a o prvotní ERD viz 2.7. Po dokončení modelu okolí je nutné ověřit, zda splňuje následující podmínky [6]: Všechny vstupní toky na kontextovém diagramu jsou potřebné pro rozpoznání události nebo pro vytvoření odezvy na událost nebo pro obojí současně. Všechny výstupní toky představují odezvu na událost. Všechny nečasové události ze seznamu událostí, tedy ty, které nejsou označeny písmenem T, musí mít vstup, aby byl systém schopen rozpoznat jejich výskyt. Všechny události ze seznamu událostí musí produkovat okamžitý výstup nebo ukládat data pro pozdější výstup nebo změnit stav systému Vytvoření prvotního modelu chování Model chování se na rozdíl od modelu okolí soustředí na vnitřní chování systému. Jako hlavní modelovací nástroj se používá diagram datových toků (DFD) viz 2.1. Většina jiných metodik po vytvoření kontextového diagramu postupuje tak, že tento diagram okamžitě dekomponuje postupem shora-dolů na jednotlivé hlavní procesy. Veliká nevýhoda tohoto postupu spočívá v tom, že je značně obtížné nalézt tyto hlavní procesy. Proto YMSA, narozdíl od jiných metodik, používá po vytvoření kontextového diagramu dekompozici postupem zdola-nahoru. Vychází se ze seznamu událostí, pomocí něhož se vytvoří prvotní DFD [5, 7]. 16

22 Postup tvorby prvotního modelu chování [6]: 3. YOURDON MODERN STRUCTURED ANALYSIS (YMSA) Pro každou odezvu na událost ze seznamu událostí se na DFD zakreslí jeden proces a pojmenuje se podle očekávané odezvy na tuto událost. Pokud jedna událost produkuje více odezev, je pro každou odezvu zakreslen samostatný proces. Pokud je odezva shodná pro více událostí, zakreslí se pro tyto odezvy pouze jediný proces. Pro asynchronně probíhající události se zakreslí esenciální paměti a nezbytné toky. Prvotní model chování se doplní o potřebné terminátory a vstupní a výstupní toky. Takto vytvořené DFD se porovná s kontextovým diagramem a seznamem událostí. Souběžně s tvorbou prvotního DFD se vytváří i ERD a datový slovník. Takto vzniklý model obsahuje velké množství procesů a je tedy velice nepřehledný. Proto se nedoporučuje prvotní model chování konzultovat se zákazníkem Dokončení esenciálního modelu V této etapě analýzy se dokončuje prvotní model chování. Dochází k zjednodušování složitého DFD pomocí vyvažování. Vyvažování probíhá v obou směrech, tedy zdola-nahoru i shora-dolů. Při vyvažování zdola-nahoru dochází ke slučování podobných procesů na stejné úrovni do jednoho procesu na vyšší úrovni. Je pouze na úsudku analytika, které procesy sloučí. Většinou se jedná o procesy které operují nad společnými daty. Pokud je paměť používána pouze procesy na nižší úrovní, které budou sloučeny do procesu na vyšší úrovni, tak je pro větší přehlednost modelu paměť na vyšší úrovni zakryta [5]. Vyvažování shora-dolů se provádí, pokud jsou procesy na nejnižší úrovni ještě příliš složité. Takovéto procesy se zjemní a tedy i zpřehlední pomocí jednodušších procesů na nižší úrovni [5]. 17

23 3. YOURDON MODERN STRUCTURED ANALYSIS (YMSA) Souběžně s vyvažováním DFD modelu se upravuje i ERD model. Dokončují se všechny minispecifikace k procesům na nejnižších úrovních a dokončuje se také datový slovník, který se prověřuje oproti všem úrovním DFD. Pokud DFD obsahuje řídící procesy, tak se pro každý řídící proces vytvoří místo minispecifikace stavově přechodový diagram [7]. Dokončený esenciální model obsahuje [6]: účel systému, kontextový diagram a seznam událostí, kompletní sadu vyvážených DFD modelů, kompletní ERD, kompletní sadu STD, kompletní datový slovník, kompletní sadu minispecifikací. 3.2 Implementační model Implementační model je posledním fází YMSA. Slouží k přizpůsobení vzniklého esenciálního modelu konkrétnímu způsobu nasazení. Stanovuje, které procesy budou při implementaci esenciálního modelu manuální, tzn. ukryty do terminátorů. Také stanovuje podobu vstupních a výstupních zařízení, formátů obrazovek a formátů výstupů. Určuje uživatelské rozhraní, opatření pro chybové technologie a specifikaci operačních omezení. Velikou výhodou YMSA je, že při změně technologie se implementační model pouze přizpůsobí těmto požadavkům a esenciální model zůstane nezměněný [5, 7]. 18

24 Kapitola 4 Analýza informačního systému knihovny pomocí metody YMSA Tato kapitola se zabývá analýzou informačního systému knihovny. Pro analýzu jsem použil Your dono vu moderní strukturovanou analýzu (YMSA), kterou jsem podrobně popsal v předcházející kapitole 3. Jako modelovací nástroj jsem použil CASE studio 2 od české firmy Charonware. Jak již bylo zmíněno v předchozí kapitole 3, je vytvoření esenciálního modelu nejdůležitějším prvkem této analýzy. Esenciální model se skládá z modelu okolí systému a modelu chování systému, kterým se budu věnovat v následujících podkapitolách. 4.1 Model okolí systému V modelu okolí jsem popsal hranice knihovního informačního systému, tzn. s kým bude systém komunikovat a na jaké události bude reagovat. K definování modelu okolí systému slouží nástroje: účel systému, kontextový diagram a seznam událostí Účel systému Protože Case Studio 2 nepodporuje tvorbu tohoto modelu, a protože účel systému je stručný textový dokument, rozhodl jsem se tento model znázornit v následujícím textu. K popisu účelu systému jsem použil popis charakteristiky systému a popis jednotlivých uživatelských rolí. 19

25 4. ANALÝZA INFORMAČNÍHO SYSTÉMU KNIHOVNY POMOCÍ METODY YMSA Charakteristika systému: Informační systém knihovny má za úkol efektivní přechod z papírové formy na elektronickou. Co nejvíce zautomatizovat chod knihovny a především zjednodušit a zefektivnit práci všech, kteří používají stávající systém. Uživatelské role: Neregistrovaný čtenář může pouze procházet a vyhledávat knihy z katalogu. Registrovaný čtenář má v systému vlastní účet. Může vyhledávat knihy z katalogu a následně si je rezervovat, pokud již není kniha v tomto období rezervována jiným čtenářem. O připravenosti knihy je čtenář informován stejně tak jako o konci výpůjční doby. Dále má registrovaný čtenář přístup k informacím o svému účtu, kde také zjistí, jaké knihy má vypůjčeny, datum vrácení knih, případně si může výpůjčku prodloužit, pokud jiný čtenář již nemá knihu rezervovanou na daný termín. Registrovaný čtenář musí platit kredit, ze kterého se automaticky strhávají služby požadované čtenářem a pokuty. Výši svého kreditu zjistí registrovaný čtenář z informací o svému účtu. Pokud je stav kreditu nízký, je registrovaný čtenář informován o nutnosti navýšení kreditu. Čtenář také může zasílat dotazy vedoucímu knihovny. Knihovník má přístup ke katalogu knih, může knihy vyhledávat a upravovat jejich informace. Může vyhledávat a editovat informace o čtenáři. Zadává také vypůjčení a navrácení knihy. Vedoucí knihovny má stejné role jako knihovník. Navíc vyřizuje faktury, nabídky knih, objednávky knih a edituje poptávané knihy. Spravuje také evidenci všech, kteří jsou v systému registrováni a odpovídá na čtenářské dotazy. Knihkupec zasílá nabídky knih a faktury, přijímá a potvrzuje objednávky od vedoucího knihovny a nechává si zasílat poptávané knihy Kontextový diagram Kontextový diagram jsem vytvořil za pomoci účelu systému vytvořeného v předchozím kroku. Na kontextový diagram jsem znázornil všechny toky mezi okolním světem a systémem kromě implementačních toků. 20

26 4. ANALÝZA INFORMAČNÍHO SYSTÉMU KNIHOVNY POMOCÍ METODY YMSA Case Studio 2 nemá přímou podporu kontextového diagramu, tak jsem zakresloval kontextový diagram do DFD nulté úrovně. Pro větší přehlednost jsem jednotlivé toky obarvil. Kompletní kontextový diagram je zobrazen na následujícím obrázku a je také uveden v příloze. hledaná kniha vyhledané knihy rezervovaná kniha odpoved na rezervaci knihy zrušena rezervace knihy zadost o prodlouženi výpůjčky odpoved na prodlouženi výpůjčky upozorněni na konec vypujcni doby upozorněni na nizky kredit ohlášeni dostupnosti knihy zašli informace o učtu informace o učtu potvrzeni platby kreditu čtenářsky dotaz doplněna odpoved na čtenářsky dotaz upomínka Registrovaný ctěn er A l\l\h hledaná kniha vyhledané knihy editovane informace o knize hledaný ctenar vyhledáni čtenáři editovane informace o čtenáři informace o novem ctenari vypůjčena kniha navracena kniha -nezaplacena faktura nabidka knih doplněna objednávka knih potvrzeni objednávky knih poptávané knihy zašli poptávané knihy knihkupci Knihkupec doplněna nabidka knih objednávka knih doplnene potvrzeni objednávky knih pridávaná poptávaná kniha odebíraná poptávaná kniha zašli poptávané knihy vedoucímu knihovny zašli nezaplacené faktury nezaplacené faktury zaplacena faktura hledaná objednávka vyhledané objednávky doplněny čtenářsky dotaz, odpoved na čtenářsky dotaz l\\ A AAA A A hrdaný vedouci knihovny I vyhledáni vedouci knihovny editovane informace o vedoucím knihovny informace o novem vedoucím knihovny hledaný knihovník vyhledaní knihovnici editovane informace o knihovníkovi informace o novem knihovníkovi hledaný knihkupec vyhledaní knihkupci editovane informace o knihkupci informace o novem knihkupci zašli nabídky knih nabídky knih Obrázek 4.1: Kontextový diagram informačního systému knihovny Seznam událostí Procházením všech terminátorů na kontextovém diagramu a zkoumáním akcí, které mohou provádět nad systémem, jsem vytvořil seznam událostí. Za každou událost jsem do závorky uvedl typ události (popsáno v kapitole 2.3). Za typ události jsem pro větší přehlednost ještě doplnil název toku, který s danou událostí souvisí. K znázornění seznamu událostí jsem použil textový editor, protože Case Studio 2 nepodporuje jeho tvorbu. Kompletní seznam událostí je v příloze. 21

27 4. ANALÝZA INFORMAČNÍHO SYSTÉMU KNIHOVNY POMOCÍ METODY YMSA Souběžně s tvorbou účelu systému, kontextového diagramu a seznamu událostí jsem vytvářel i ERD a datový slovník. 4.2 Prvotní model chování Vytvořený model okolí systému mi nyní sloužil jako základ pro tvorbu prvotního modelu chování. Nejdůležitější z něj je seznam událostí. Pro každou identifikovanou odezvu na událost ze seznamu událostí jsem na prvotní model chování zakreslil jeden proces a pojmenoval jsem ho podle očekávané odezvy. Tento proces vytváří odezvu na danou událost. V tomto momentu je velice nepříjemná absence nástroje pro vytvoření seznamu událostí v Case Studiu 2. Analytik je totiž nucen spravovat dva seznamy se souvisejícím obsahem. Jedná se o již externě vytvořený seznam událostí a o prvotní DFD. Pokud existuje událost, jako je např. Registrovaný čtenář zasílá dotaz vedoucímu knihovny (F - čtenářský dotaz), na jejímž základě systém produkuje více odezev (uloží čtenářský dotaz a zašle vedoucímu knihovny doplněný čtenářský dotaz), tak jsem zakreslil na prvotní DFD samostatný proces pro každou odezvu na takovouto událost (Uložení čtenářského dotazu a Doplnění čtenářského dotazu). Naopak, pokud existuje odezva jako je např. zaslání vyhledaných knih, která je shodná pro více událostí (Neregistrovaný čtenář vyhledává knihu (F - hledaná kniha), Registrovaný čtenář vyhledává knihu (F - hledaná kniha), Knihovník vyhledává knihu (F - hledaná kniha) a Vedoucí knihovny vyhledává knihu (F - hledaná kniha)), tak jsem pro všechny tyto události zakreslil na prvotní DFD pouze jeden proces (Vyhledání knihy). Pro všechny asynchronně probíhající události jsem na prvotní DFD zakreslil esenciální paměti, jako jsou např. Registrovaní čtenáři, Knihy, Rezervace atd. Následně jsem zakreslil všechny potřebné toky. Case Studio 2 nepodporuje přímo prvotní model chování, tak jsem prvotní model chování zakresloval do DFD nulté úrovně. Bohužel Case Studio 2 nepodporuje ani žádné přehlednější zakreslování, tak se model po zakreslení 33 procesů stal velice nepřehledný, a to ještě zbývalo zakreslit 15 procesů. Takto rozpracovaný 22

28 4. ANALÝZA INFORMAČNÍHO SYSTÉMU KNIHOVNY POMOCÍ METODY YMSA prvotní model chování naleznete v příloze. Proto jsem se pro větší přehlednost prvotního modelu chování rozhodl vzájemně související události ze seznamu událostí rozdělit do skupin. Celý seznam událostí se mně podařilo rozdělit na tři hlavní skupiny. Rozdělený seznam událostí jsem připojil za již vytvořený celistvý seznam událostí, který je v příloze. Následně jsem pro každou skupinu vytvořil samostatný prvotní DFD. Na tyto tři prvotní DFD lze nahlížet jako na jediný, protože jsem všechny opakující se terminátory a paměti označil hvězdičkou nad jménem, která značí kopii. Všechny tři vytvořené prvotní modely chování naleznete v příloze. Souběžně s tvorbou prvotního modelu chování jsem doplňoval i ERD a datový slovník. Na závěr jsem zkontroloval takto vytvořené prvotní modely chování oproti kontextovému diagramu a seznamu událostí. 4.3 Dokončení esenciálního modelu V tomto kroku jsem se zabýval zjednodušováním složitého prvotního modelu chování na sadu vyvážených DFD modelů. Nejprve jsem použil vyvažování směrem nahoru, abych seskupil vzájemně související procesy na nižší úrovni do procesu na vyšší úrovni. Poté jsem nově získanou vrstvu vyvážil směrem dolů, abych sloučil do jednoho procesu procesy, které byly na prvotním DFD zakresleny jako různé odezvy na stejnou událost. Tomuto vyvážení nahoru a dolů se říká setřepání. Takto vytvořený DFD model naleznete v příloze. Tento získaný model byl ale stále moc nepřehledný (především pravidlo 7 ± 2 viz Pravidla a doporučení tvorby DFD v kapitole 2.1), tak jsem se rozhodl ho ještě jednou vyvážit směrem nahoru. Výsledek tohoto vyvážení už splňoval i další pravidla tvorby DFD. Na závěr jsem pro větší přehlednost doplnil o úroveň výše kontextový diagram. Kompletní sada DFD je v příloze. Největší vadou Case Studia 2 je že nepodporuje vyvažování směrem nahoru, tj. neumožňuje slučovat procesy do procesu na vyšší úrovni. Pokud chcete vyvažovat směrem nahoru, musíte vytvořit nový projekt, ve kterém zakreslíte novou vrstvu do DFD nulté úrovně a následně musíte již získané nižší vrstvy ručně překreslit do nižších úrovní, protože Case Studio 2 nepodporuje kopírování. 23

29 4. ANALÝZA INFORMAČNÍHO SYSTÉMU KNIHOVNY POMOCÍ METODY YMSA Naopak vyvažování směrem dolů je v Case Studiu 2 dostatečně propracované. Stačí v nastavení procesu povolit rozkreslení do nižší úrovně a Case Studio 2 do této úrovně zobrazí všechny potřebné objekty. Přidání nových objektů do nižší úrovně jinak neovlivní vyšší úroveň, ale je nutné si dávat pozor, pokud mažete nějaký objekt. Pokud smažete jakýkoliv objekt na nižší úrovni, tak se tento objekt smaže i na všech vyšších úrovních. Registrovaný ctener odpoved na čtenářsky dotaz čtenářsky dotaz Vedoucí knihovny Obrázek 4.2: Ukázka DFD třetí úrovně - Čtenářský dotaz a odpověď na něj Souběžně s dokončením esenciálního modelu jsem dokončil i ERD, které je zobrazeno na následující straně, datový slovník a pro každý proces na nejnižší úrovni jsem vytvořil minispecifikaci. Kompletní ERD, datový slovník i minispecifikaci naleznete v příloze. Case Studio 2 má tvorbu ERD na vysoké úrovni. Podporuje identifikující, neidentifikující a informativní vztahy a automaticky s druhem vztahu přenáší i kandidátní a cizí klíče. Ve vlastnostech každého vztahu lze také jednoduše nastavit arita vztahu. V nastavení každé entity lze jednoduše přidávat atributy, specifikovat jejich typ a označovat je primárním klíčem. 24

30 4. ANALÝZA INFORMAČNÍHO SYSTÉMU KNIHOVNY POMOCÍ METODY YMSA Knihkupec ICO_knihkupce (PK) jméno telefon ulice cislo_domu mesto PSC ^ ISBN(PFK] ID_faktury(PFK] pocet_kusu cena za kus Obrázek 4.3: ERD informačního systému knihovny

31 4. ANALÝZA INFORMAČNÍHO SYSTÉMU KNIHOVNY POMOCÍ METODY YMSA I když Case Studio 2 nepodporuje přímo datový slovník, je možné zapisovat datový slovník do poznámek k jednotlivým prvkům DFD. Já jsem pro větší přehlednost zvolil zápis datového slovníku do zvláštního textového dokumentu. Case Studio 2 dovoluje zapisovat minispecifikaci v textová formě do kolonky specifikace pro každý proces na DFD. Protože takto zapsaný text nelze nijak formátovat, a je tedy nepřehledný, rozhodl jsem se i minispecifikaci zapsat do zvláštního textového dokumentu. Výsledný esenciální model obsahuje: účel systému, kontextový diagram, seznam událostí, množinu vyvážených DFD modelů, ERD model, datový slovník, minispecifikaci. 4.4 Implementační model Už během dokončování esenciálního modelu jsem podvědomě postupoval tak, že všechny manuální prvky byly zahrnuty do terminátorů, kteří dělají všechnu manuální činnost. Proto je model systému knihovny podle metodiky YMSA hotov. Veškerá příloha je uložena na přiloženém CD. 26

32 Kapitola 5 Zaver Při tvorbě této bakalářské práce jsem si ověřil, že analytik musí být při analýze systému velice pečlivý. Jakékoliv opomenutí, aťuž z nedbalosti nebo z neznalosti, může velice zkomplikovat vznik kvalitního informačního systému. Jakékoliv zásahy do modelů systému v pozdějších fázích analýzy, byť jsou nepatrné, jsou velice náročné a nákladné, protože všechny modely jsou mezi sebou úzce provázány, a proto změna v jednom modelu zapříčiní změnu ve většině ostatních modelů. Protože poslední dobou velice rychle rostou i nároky na nové informační systémy, roste i zodpovědnost analytika a obtížnost samotné analýzy. Podle mého názoru je Yourdonova moderní strukturovaná analýza (YMSA) stále nejpoužívanější, i díky své propracovanosti a konzistenci jednotlivých modelů. Jsou v ní shrnuty všechny výhody strukturované analýzy. Především postup zdola-nahoru usnadňuje analytikovi vyhledávání podobných procesů a jejich následné vyvažování. Po zkušenostech s návrhem informačního systému knihovny bych Case Studio 2 jako CASE nástroj pro Yourdonovu moderní strukturovanou analýzu s velkou pravděpodobností nedoporučil. Největší nevýhodou tohoto nástroje je nemožnost automatického vyvažování zdola-nahoru, na kterém je YMSA postavena. I absence jiných modelovacích nástrojů je značně nepříjemná. Jedná se zejména o seznam událostí. I propracovanější minispecifikace (hlavně z pohledu formátování) by byla přínosem. Také mě překvapilo chování Case Studia 2 při odpojení toku nebo při povolení vyvažování shora-dolů. V obou případech se všechny nepřipojené konce toků přesunou do levého horního rohu, což je v některých případech velmi nepřehledné a zdržující. Jinak je vyvažování shora-dolů dobře propracované. Největší výhodou Case Studia 2 je jeho dokonalost při tvorbě ERD. Podle mého názoru nemá Case Studio 2 při tvorbě ERD konkurenci. I z nástupce Case Studia 2, kterým je Data Modeler 3, je vidět, že se již specifikuje výhradně na tvorbu datových modelů, protože diagramy datových toků z něho zcela zmizely 27

33 5. ZÁVĚR [1]. Celkově lze tedy konstatovat, že Case Studio 2 je vhodný nástroj především pro metodiky, které postupují shora-dolů. I přesto, že je strukturovaná analýza systémů čím dál více vytlačována objektovými metodami analýzy, si myslím, že se Yourdonova moderní strukturovaná analýza bude používat i v budoucnosti především u analýz menších systémů. 28

34 Literatura [1] Webové stránky aplikace CASE Studia 2. [online], Naposledy navštíveno URL < [2] DEMARCO, T.: Structured Analysis and Systems Specification. YOURDON Press, 1979, ISBN [3] Král, J.: Informační systémy. Science, 1998, ISBN [4] RYCHTA, K.; SOCHOR, J.: Softwarové inženýrství I. ČVUT, 1996, ISBN [5] RÁČEK, J.: Strukturovaná analýza systémů. Masarykova univerzita, 2006, ISBN [6] SOCHOR, J.; RÁČEK, J.; OŠLEJŠEK, R.: Výukové materiály k předmětu PB007 - Analýza a návrh systémů [7] YOURDON, E.: Modern structured analysis, [online], Naposledy navštíveno URL < [8] FROLÍK, V: CASE Studio 2 - user 's manual. Charonware, Ostrava, 2004 [9] BARKET, R.; LONGMAN, C: Case*Method. Addison-Wesley Professional,

35 Dodatek A Seznam zkratek CASE CDFD DD DFD ERD IS STD YMSA Computer Aided Software Engineering Control Data Flow Diagram Data Dictionary Data Flow Diagram Entity Relationship Diagram Information System State Transition Diagram Yourdon Modern Structured Analysis 30

36 Dodatek B Struktura přiloženého CD bc.pdf - text bakalářské práce ve formátu PDF bc.tex - zdrojový text bakalářské práce ve formátu KTpX bc.bib - bibliografická databáze k bakalářské práci ve formátu BibTgX obr - složka obrázků vložených do textu bakalářské práce YMSA - Knihovna - složka obsahující modely knihovny podle YMSA - Datový slovník - složka obsahující datový slovník * DatovySlovnik.pdf - datový slovník ve formátu PDF - DFD - Knihovna - složka obsahující výsledný DFD * DFD-Knihovna.dm2 - výsledný DFD vytvořený v CS2 - ERD - Knihovna - složka obsahující výsledný ERD * ERD-Knihovna.dm2 - výsledný ERD vytvořený v CS2 - Kontextový Diagram - složka obsahující kontextový diagram * KontextovyDiagram.dm2 - kontextový diagram vytvořený v CS2 - Minispecifikace - složka obsahující minispecifikace * Minispecifikace.pdf - minispecifikace ve formátu PDF - obrmodelů - složka obsahující obrázky všech ERD i DFD modelů ve formátu PNG - Prezentace - složka obsahující postup analýzy v podobě prezentace - První Vyvážení - složka obsahující DFD vzniklé po prvním vyvážení nahoru a dolů * PrvniVyváženi.dm2 - první vyvážení vytvořené v CS2 31

37 B. STRUKTURA PŘILOŽENÉHO CD Prvotní Model Chování - složka obsahující prvotní modely chování * PrvotniModelChovani-Neprehlednydm2 - prvotní model chování, který jsem nedokončil kvůli jeho nepřehlednosti vytvořený v CS2 * PrvotniModelChovani-SpravaKnih.dm2 - jedna z částí prvotního modelu chování vytvořená v CS2 * PrvotniModelChovani-SpravaUzivatelu.dm2 - jedna z částí prvotního modelu chování vytvořená v CS2 * PrvotniModelChovani-VypujceniKnih.dm2 - jedna z částí prvotního modelu chování vytvořená v CS2 Seznam udalosti - složka obsahující seznam událostí * SeznamUdalosti.pdf - seznam událostí ve formátu PDF 32