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

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Strukturovaná analýza informačních systémů BAKALÁŘSKÁ PRÁCE

Martin Štíbal

Brno, jaro 2008

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

Poděkování Chtěl bych poděkovat především vedoucímu mé bakalářské práce RNDr. Jaro slavu 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

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

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

, r»™ "Mte,

Masarykova univerzita Fakulta informatiky

/

**., „„s»*

ZADANÍ BAKALÁRSKE

PRACE Datum: 15.4.2008

Student(ka):

Martin Štibai

Program:

Fl B-AP Aplikovaná informatika, bakalářský studijní program

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:

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

Zadání:

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, 2006. 104 s. FI. ISBN 80-210-4190-0.

Souhlas se zadáním (podpis, datum)

student(ka)

-'vědoucí bakalářské práce

vedoucíWdpovědného pracoviště

Obsah 1 Úvod 2 Modelovací nástroje strukturované analýzy 2.1 Diagram datových toků (Data Flow Diagram - DFD) 2.2 Kontextový diagram 2.3 Seznam událostí 2.4 Diagram datových toků s řízením (Control Data Flow Diagram - CDFD) 2.5 Stavově přechodový diagram (State Transition Diagrams - STD) 2.6 Minisp ecifikace 2.7 Entitně relační diagram (Entity Relationship Diagram - ERD) 2.8 Datový slovník (Data Dictionary - DD) 3 Yourdon Modern Structured Analysis (YMSA) 3.1 Esenciální model 3.1.1 Vytvoření modelu okolí systému 3.1.2 Vytvoření prvotního modelu chování 3.1.3 Dokončení esenciálního modelu 3.2 Implementační model 4 Analýza informačního systému knihovny pomocí metody YMSA . . . 4.1 Model okolí systému 4.1.1 Účel systému 4.1.2 Kontextový diagram 4.1.3 Seznam událostí 4.2 Prvotní model chování 4.3 Dokončení esenciálního modelu 4.4 Implementační model 5 Závěr A Seznam zkratek B Struktura přiloženého CD

3 4 4 6 7 7 8 9 11 13 14 14 15 16 17 18 19 19 19 20 21 22 23 26 27 30 31

2

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í sys témy. Tvorba informačního systému se od tvorby běžného softwaru liší především vy sokou komunikací mezi řešitelem a zákazníkem. Informační systém slouží pře devší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ásle dující kapitole. Pro zjednodušení analytikovy činnosti existuje několik tzv. CASE (Computer Ai ded Software Engineering) nástrojů, které jsou velmi užitečné při návrhu infor mač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 po drobně 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

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í na podobeninu 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í ko munikaci 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ásle dují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

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ěřu jí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ší zpra cování. Povolené operace jednoho datového toku nad pamětí jsou buď ne destruktivní čtení, zápis, modifikace nebo mazání. Terminátor: Yourdon:

Název externí entity

Datový tok:

Proces: (

/-—iNázev --\ ,i \^procesu^/

Paměť: Název

Název datového

/

>toku

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 pra cují 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 kompo nentami, musíme mezi ně umístit alespoň jeden proces. S výjimkou komu nikace terminátoru s paměti na rozhraní na kontextovém diagramu. 5


•

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 zpravi dla 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 nevznik nou 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 hra nici mezi systémem a okolním světem. Systém je zde zobrazen jako jeden proces 6


a je propojen s okolním světem pomocí vstupních a výstupních toků. Z kontex tové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 pro vá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


vznikne diagram datových toků s řízením (CDFD). Ří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 spl ně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 ča rou. Ří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 aktivuj proces 2

I J[ STAV 2

signál Y aktivuj proces 3

I 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 zobra zený 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


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ě je den 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 lo giku 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 fo rem 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é an glič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


1. FOR EVERY objednávka DO 1.1. IF dodáni přepravní firmou THEN 1.1.1.SELECT CASE 1 (Cena < 1000 Kč): 1.1.1.1.Přepravné = 100 Kč; CASE 2 (1000 Kč <= Cena < 5000 Kč): 1.1.1. 2 . Přepravné = 50 Kč; CASE 3 (Cena >= 5000 Kč): 1.1.1.3.Přepravné = 0 Kč; 1.2. IF dodáni osobně na prodejně THEN 1. 2 .1. 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 roz díl od minispecifikace strukturovanou angličtinou, minispecifikace rozhodovací tabulkou nebo rozhodovacím stromem neovlivňuje, jaký algoritmus má při imple mentaci programátor použít. Velkou výhodou těchto zápisů je i jejich přehlednost [3]. Pravidla: Podmínky: Cena< 1000 Kč 1000Kč <= Cena < 5000 Kč Cena >= 5000 Kč Dodání je přepravní firmou Dodání je osobně na prodejně Akce: Přepravné = 100 Kč Přepravné = 50 Kč Přepravné = 0 Kč

1

2

3

4

5

6

A N N A N

N A N A N

N N A A N

A N N N A

N A N N A

N N A N A

A N N N N N N A N N N N 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 postcon10


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. Po mocí 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 atri buty 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


•

Vztah, neboli relace, propojuje jednotlivé entity, které mají mezi sebou urči tou 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

Počet entit B, které mohou být ve vztahu s jednou entitou A

A

-

B

právě jedna

A

-o

B

žádná nebo jedna

H -°< B 0 -* B

žádná, jedna nebo více alespoň jedna

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 asoci ovaná 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 dodava telů, 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


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 opa kovat nebo nevyskytovat vůbec [ ]. Operátory, které se k tomuto zápisu používají shrnuje následující obrázek. Symbol ... = ...

... + ... (...)

[...I...1 {...} *

®-

*

Význam skládá se z a nepovinný prvek 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 = @UČO + 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

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é vy važ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ší meto diky strukturované analýzy. Ed Yourdon ji představil v roce 1989. 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

3. YOURDON MODERN STRUCTURED ANALYSIS (YMSA) poznatky o vnějším chovaní stávajícího systému (

1. Analyzuj stávající systém

D

Vytvoř

technická a uživatelská dokumentace

esenciální model 3. esenciální model systému

f-^ 1

Navrhni implementaci

<

O

«-^-

'

Obrázek 3.1: Analýza systému pomocí esenciálního modelu (Yourdon) [i ] 3.1.1 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 rozhod nutí 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 pra covní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 dia gramu 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

3. YOURDON MODERN STRUCTURED ANALYSIS (YMSA)

Existují dva různé způsoby tvorby modelu okolí [ ]: 1.

Kontextový diagram sestavíme na základě informací od uživatelů. Z kon textové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 na leznou 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 sys té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 roz pozná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.

3.1.2 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


Postup tvorby prvotního modelu chování [6]: •

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 ne zbytné 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. 3.1.3 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


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 obsa huje ří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ě techno logie 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

Kapitola 4

Analýza informačního systému knihovny pomocí me tody 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í mo delu okolí systému slouží nástroje: účel systému, kontextový diagram a seznam událostí. 4.1.1 Úč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 jed notlivých uživatelských rolí.

19

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 ka talogu 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, da tum 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é čte nář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ář informo vá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, na bídky knih, objednávky knih a edituje poptávané knihy. Spravuje také evi denci 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.

4.1.2 Kontextový diagram Kontextový diagram jsem vytvořil za pomoci účelu systému vytvořeného v před chozí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

4. ANALÝZA


YMSA

Case Studio 2 nemá přímou podporu kontextového diagramu, tak jsem zakres loval kontextový diagram do DFD nulté úrovně. Pro větší přehlednost jsem jed notlivé 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

, l\\ A I 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

AAA

doplněny čtenářsky dotaz odpoved na čtenářsky dotaz A A hrdaný vedouci knihovny knihovn 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

4.1.3 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 Stu dio 2 nepodporuje jeho tvorbu. Kompletní seznam událostí je v příloze.

21

4. ANALÝZA


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 identifiko vanou 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 pro ces 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 sou visejí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 vedou cí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 do tazu). 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 vy hledá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 esen ciá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

4. ANALÝZA


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í nalez nete 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 kon textové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ě souvi sejí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 vy váž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

4. ANALÝZA


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

čtenářsky dotaz odpoved na č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 zobra zeno 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í, ne identifikují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 na stavit 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

4.

A N A L Ý Z A I N F O R M A Č N Í H O SYSTÉMU K N I H O V N Y P O M O C Í METODY

Knihkupec ICO_knihkupce (PK) jméno telefon e-mail ulice cislo_domu mesto PSC

^

O b r á z e k 4.3: E R D i n f o r m a č n í h o s y s t é m u k n i h o v n y

YMSA

ISBN(PFK] ID_faktury(PFK] pocet_kusu cena za kus

4. ANALÝZA


YMSA

I když Case Studio 2 nepodporuje přímo datový slovník, je možné zapisovat da tový slovník do poznámek k jednotlivým prvkům DFD. Já jsem pro větší přehled nost 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

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 pro vá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áto vá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

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 objek tový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

Literatura [1] Webové stránky aplikace CASE Studia 2. [online], Naposledy navštíveno 18.5.2008. URL [2] DEMARCO, T.: Structured Analysis and Systems Specification. YOURDON Press, 1979, ISBN 0138543801. [3] Král, J.: Informační systémy. Science, 1998, ISBN 80-86083-00-4. [4] RYCHTA, K.; SOCHOR, J.: Softwarové inženýrství I. ČVUT, 1996, ISBN 80-0101428-2. [5] RÁČEK, J.: Strukturovaná analýza systémů. Masarykova univerzita, 2006, ISBN 80-210-4190-0. [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ů. 2007. [7] YOURDON, E.: Modern structured analysis, [online], Naposledy navštíveno 18.5.2008. URL [8] FROLÍK, V: CASE Studio 2 - user 's manual. Charonware, Ostrava, 2004 [9] BARKET, R.; LONGMAN, C : Case*Method. Addison-Wesley Professional, 1992

29

Dodatek A

Seznam zkratek CASE

Computer Aided Software Engineering

CDFD

Control Data Flow Diagram

DD

Data Dictionary

DFD

Data Flow Diagram

ERD

Entity Relationship Diagram

IS

Information System

STD

State Transition Diagram

YMSA

Yourdon Modern Structured Analysis

30

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 *

-

DFD - Knihovna - složka obsahující výsledný DFD *

-

ERD-Knihovna.dm2 - výsledný ERD vytvořený v CS2

Kontextový Diagram - složka obsahující kontextový diagram *

-

DFD-Knihovna.dm2 - výsledný DFD vytvořený v CS2

ERD - Knihovna - složka obsahující výsledný ERD *

-

DatovySlovnik.pdf - datový slovník ve formátu PDF

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

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í prvot ního modelu chování vytvořená v CS2 PrvotniModelChovani-VypujceniKnih.dm2 - jedna z částí prvot ní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

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

Recommend Documents