Analýza informačního systému jazykové školy

Save this PDF as:
 WORD  PNG  TXT  JPG

Rozměr: px
Začít zobrazení ze stránky:

Download "Analýza informačního systému jazykové školy"

Transkript

1 Masarykova univerzita v Brne Fakulta informatiky Analýza informačního systému jazykové školy Bakalárska práca Vypracovala: Zuzana Kasalová Vedúci práce: RNDr. Jaroslav Ráček, Ph.D. Brno, január 2006

2 Prehlásenie Prehlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracovala samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní práce použila riadne citujem s uvedením úplného odkazu na príslušný zdroj. Zuzana Kasalová 2

3 Zhrnutie Táto práca sa zaoberá predstavením niektorých metodík a nástrojov štruktúrovanej analýzy. Cieľom bolo previesť analýzu reálneho systému jazykovej školy pomocou jednej z metodík modernej štruktúrovanej analýzy a zdokumentovať ju. Konkrétne som si zvolila Yourdonovu modernú štruktúrovanú analýzu. Klúčové slová Yourodonova moderná štrukturovaná analýza, SASS, SSADM, CASE Studio 2, ERD, DFD, CDFD, STD, dátový slovník. 3

4 Obsah 1 Úvod Modelovacie nástroje analýzy Diagram dátových tokov ( Data Flow Diagram - DFD ) Entitno - relačný diagram ( Entity Relationship Diagram - ERD) Stavové diagramy (State Transition Diagrams - STD) Diagram dátových tokov s riadením (Control Data Flow Diagram - CDFD) Dátový slovník (Data Dictionary - DD) Procesné špecifikácie Metodiky štruktúrovanej analýzy Štruktúrovaná analýza a špecifikácia systému (SASS) Postup tvorby modelov podľa SSAS metodiky Použité nástroje pri tvorbe modelov Yourdonova moderná štruktúrovaná analýza (YMSA) Esenciálny model Vytvorenie modelu okolia Vytvorenie prvotného modelu chovania Dokončenie modelu chovania Vytvorenie implemetačného modelu Sturctured System Analysis and Design Methodology - SSADM Členenie procesu analýzy a návrhu v SSADM Základné modely systému Analýza informačného systému jazykovej školy Model okolia systému Účel systému Kontextový diagram Zoznam udalostí Model chovania systému Prvotný model chovania Dokončenie modelu chovania Záver...29 Literatúra...30 Elektronické zdroje...30 Obsah priloženého CD:

5 Zoznam obrázkov Obrázok č. 1: Vyjadrenie komponentov DFD v Yourdon/DeMarco notácii... 7 Obrázok č. 2: Identifikujúci vzťah medzi entitami... 9 Obrázok č. 3: Neidentifikujúci vzťah medzi entitami... 9 Obrázok č. 4: Informačný vzťah medzi entitami...10 Obrázok č. 5: Znázornenie kardinality vzťahu v notácii J. Martina (zdroj [1])...10 Obrázok č. 6: Príklad použitia asociovanej entity...10 Obrázok č. 7: STD s ohodnoteným prechodom. (zdroj [1]) Obrázok č. 8: Príklad rozhodovacej tabuľky...13 Obrázok č. 9: Analýza pomocou 4 modelov (zdroj[2])...15 Obrázok č. 10: Dokumenty štruktúrovanej špecifikácie (zdroj[2])...16 Obrázok č. 11: Analýza s esenciálnym modelom. (zdroj [1])...17 Obrázok č. 12: YMSA s vyvažovaním...20 Obrázok č. 13: SSADM notácia pre DFD...22 Obrázok č. 14: Časť kontextového diagramu...24 Obrázok č. 15: Výrez z prvotného DFD diagramu...26 Obrázok č. 16: Prvotný ERD model...27 Obrázok č. 17: Stavový diagram procesu riadenia výpožičky študenta

6 1 Úvod Prienik informačných technológií do našich životov spôsobil, že sa stali neoddeliteľnou súčasťou nášho života. Stretávame sa s nimi v domácnostiach, v školstve, verejnej správe, prakticky na každom kroku. Základným prvkom informačných technológií, sú softwarové produkty, medzi ktoré tiež patria informačné systémy (IS). Sú to systémy zberu, uchovávania, analýzy a prezentácie dát určených pre poskytovanie informácií širokému spektru užívateľov. Informačný systém je obvykle určený určitej skupine ľudí, ktorý s IS priamo pracujú. Je navrhnutý ako nástroj, ktorý podporuje určité činnosti. Tvorba IS sa od vývoja bežného softwaru odlišuje predovšetkým vysokou úrovňou spoluúčasti zákazníka na samotnom vývoji. Dôležitá je jeho účasť predovšetkým pri analýze a samotnom zavedení systému. Dôležitou úlohou analytika je zistiť, čo zákazník vyžaduje od systému a čo skutočne potrebuje. Pre samotný úspech projektu je podstatný kontakt s osobami, ktoré budú IS skutočne používať, pretože oni vedia najvhodnejšie špecifikovať požiadavky na systém. Akékoľvek zmeny v neskorších etapách vývoja IS sú veľmi časovo a finančne náročné. Predmetom analýzy IS je predovšetkým podrobné preskúmanie a špecifikácia jednotlivých činností a vzťahov v organizácii. Často krát sa tiež stáva, že zákazník nevie správne formulovať svoje požiadavky a nie je schopný popísať chovanie a štruktúru systému. Úlohou analýzy je tiež zoptimalizovať činnosti, ktoré v systéme prebiehajú a tým zvýšiť produktivitu práce zamestnancov. V súčasnosti existuje viacero metód pre prevedenie analýzy, o popis tých najznámejších som sa pokúsila vo svojej práci. Spoločným znakom všetkých uvádzaných metód je transformácia skutočného stavu do abstraktných modelov. Tento prístup umožňuje zapojiť do analýzy zákazníka, zistiť jeho názor na požiadavky a názorne mu ukázať jednotlivé štádia analýzy informačného systému. Uľahčuje tiež prácu vývojovému tímu, analytikom, manažérom a programátorom. Výsledkom prevedenia analýzy je špecifikácia systému, ktorá slúži ako základ k návrhu vyvíjaného systému. Analýzu IS jazykovej školy som vykonala v spolupráci s vedením jazykovej školy Pretorian. Na základe získaných informácií od pracovníkov študijného oddelenia a vedenia školy som sa snažila preniknúť do organizačnej štruktúry a logiky vnútorných vzťahov prostredia jazykovej školy. Požiadavky klientov jazykovej školy som získala formou dotazníkov, ktoré mi poskytli doplňujúce informácie. Teoretickú časť práce som rozdelila do piatich kapitol, kde prvá je úvodná a piata záverečná kapitola. Druhá kapitola sa zaoberá popisom nástrojov štruktúrovanej analýzy. Tretia kapitola je venovaná základným metodikám štruktúrovanej analýzy, pričom som sa podrobnejšie zamerala na Yourdonovu modernú štruktúrovanú analýzu. V štvrtej kapitole je uvedený detailný postup analýzy jazykovej školy pomocou Yourdonovej štruktúrovanej analýzy. 6

7 2 Modelovacie nástroje analýzy Pri analýze nového systému je potrebné vytvoriť rôzne modely, ktoré nám zdôraznia dôležité a zakryjú nepodstatné rysy systému. Modely majú prispieť k správnemu pochopeniu rôznych vlastností systému a slúžia ako komunikačný prostriedok medzi užívateľmi systému a analytikmi, a taktiež medzi analytikmi a realizátormi systému. Ďalším dôvodom, prečo používame pri analýze systému modely je skutočnosť, že nám umožňujú prevádzať zmeny a opravy podľa požiadaviek užívateľa s minimálnymi nákladmi a rizikom. Modelovacie nástroje používané v štruktúrovanej analýze popisujem detailnejšie v nasledujúcich podkapitolách. Jedná sa o pomocné nástroje, ktoré slúžia na modelovanie procesov prebiehajúcich v informačných systémoch, stanovenie pohybu a spracovania informácií v rámci IS, ako aj k vlastnému modelovaniu bázy dát. 2.1 Diagram dátových tokov ( Data Flow Diagram - DFD ) Diagram dátových tokov, nazývaný tiež funkčný alebo procesný model systému patrí k najpoužívanejším modelovacím nástrojom štruktúrovanej analýzy. Predstavuje grafický nástroj určený k opisu systému z funkčného pohľadu. Umožňuje zobraziť systém ako sieť procesov, ktoré plnia dané funkcie a vymieňajú si medzi sebou dáta. Diagramy dátových tokov pozostávajú zo štyroch nasledovných komponentov: proces je miesto IS, v ktorom dochádza k transformácií dát. Jedná sa vlastne o funkciu ktorá transformuje vstupné dáta na dáta výstupné. Vyjadruje fyzickú transformáciu dát, alebo zmenu stavu určitej časti dát. terminátor (externá entita) je miesto v IS, v ktorom dáta vznikajú, alebo sú spotrebovávané. Jedná sa vždy o externú časť systému (človek, terminál, organizácia, ), pričom systém nepozná jej obsah a správanie. Vzťahy medzi terminátormi nevyjadrujeme na DFD. dátový tok vyjadruje pohyb dát v systéme a ich presun z jednej časti systému do druhej časti, alebo od zdroja dát do systému a zo systému k užívateľovi dát. Daný tok prenáša vždy iba jeden druh paketu a meno dátového toku predstavuje jeho význam. Obvykle býva znázorňovaný ako hrana ukončená šípkou, ktorá určuje smer toku dát. dátová pamäť je miesto v systéme, kde sú dáta dočasne ukladané pre ďalšie spracovanie, takže modeluje dáta v pokoji. Procesy s dátami v dátovej pamäti môžu vykonávať operácie typu čítanie, zápis, aktualizácia, mazanie. Vzhľadom k použitému CASE nástroju používam vo svojej práci notáciu Yourdon/DeMarco, ktorá je znázornená na nasledujúcej schéme. Obrázok č. 1: Vyjadrenie komponentov DFD v Yourdon/DeMarco notácii 7

8 Pri tvorbe DFD sa uplatňuje niekoľko zásad, vymenujem aspoň tie najdôležitejšie : dátové toky sú povolené len medzi procesmi (výstup jedného procesu je vstupom iného procesu), procesom a dátovou pamäťou (zápis, aktualizácia, mazanie dát), terminátorom a procesom (vstup dát do systému), procesom a terminátorom (výstup dát zo systému) dátové toky nie sú povolené medzi dvoma externými entitami (komunikácia je potom mimo IS) a medzi dátovými pamäťami (pamäte sú pasívne a na operácie s ich dátami sú potrebné procesy) nesmie existovať proces, ktorý sám o sebe generuje dáta (má výstupné toky a nemá žiadny vstupný tok) alebo iba sám spotrebováva dáta (má vstupné toky, pričom nemá žiadny výstupný tok) názvy procesov by mali byť stručné, pričom by mali výstižne charakterizovať daný proces a jeho funkcie nesmú existovať procesy s rovnakými názvami a funkciami nesmú existovať procesy a toky bez prideleného názvu. Reálny systém nemožno v skutočnosti popísať jediným DFD. Ak by DFD mal podrobne popisovať všetky transformácie tokov, stal by sa rýchlo neprehľadným a nedal by sa ani zobraziť v prijateľnej forme na bežný formát. Preto majú DFD väčšinou hierarchický charakter. Proces v diagrame na vyššej úrovni, môžeme podrobnejšie popísať diagramom nižšej úrovne. 1. Kontextový diagram 2. DFD 0.úrovne znázorňuje najviac 7±2 hlavných procesov 3. DFD 1.úrovne podrobnejšie vyjadrenie funkcií hlavných procesov z 0.úrovne 4. DFD 2.úrovne podrobnejšie popisuje zložitejšie procesy z 1.úrovne Postupnou dekompozíciou procesov nám vzniká stromovo usporiadaná množina diagramov. Procesy ktoré sa už nehierarchizujú nazývame primitívnymi procesmi. Diagram na najvyššej úrovni sa nazýva kontextovým diagramom, pričom je tvorený len jediným procesom, ktorý zastupuje funkciu navrhovaného IS a externými entitami. Kontextový diagram vymedzuje hranice systému a rozhrania, pomocou ktorých systém komunikuje s externými entitami. 2.2 Entitno - relačný diagram ( Entity Relationship Diagram - ERD) Entitno-relačné diagramy sú grafickým nástrojom, ktorý sa používa pri návrhu IS na vyjadrenie modelu dát, pričom je pohľadom na statickú časť systému. V rámci ERD sú definované jednotlivé dátové objekty entity a vzťahy medzi nimi. Používajú sa štandardne v metódach štruktúrovanej analýzy ako doplnok k DFD, ktorých nedostatkom je, že špecifikujú len funkcie a nie vlastný model dát. Entitno-relačné diagramy pozostávajú z nasledovných prvkov : Entita je akýkoľvek dátový objekt, ktorý je predmetom záujmu, o ktorom chceme uchovávať údaje. Entita je konkrétnou inštanciou entitnej množiny. 8

9 Entitná množina je množina entít rovnakého typu, druhu. V texte používam slovo entita vo význame entinej množiny. Atribút je elementárny prvok, ktorý vyjadruje bližšiu charakteristiku entity. Identifikátorom alebo kľúčovým atribútom budeme nazývať atribút alebo množinu atribútov, ktorých hodnoty umožňujú jednoznačne rozlíšiť jednotlivé entity navzájom. Doména atribútu je obor hodnôt, ktorý môže atribút nadobúdať. Vzťah je určitá forma spojenia medzi entitami, ktorú evidujeme. Medzi entitami môže existovať viac rôznych vzťahov. Vzťahová množina je množina vzťahov rovnakého typu, druhu. V texte budem používať slovo vzťah v zmysle označenia vzťahovej množiny. ERD sú grafickým nástrojom, preto sú definované pre ich jednotlivé prvky príslušné symboly. V literatúre ale aj v implementáciach CASE nástrojov sa stretávame s rôznymi notáciami pre tvorbu ERD, napr. Chenove diagrmany, notácia Jamesa Martina atd.. Vo svojich modeloch používam notáciu, ktorú podporuje CASE Studio 2. Entity sú označené ako obdĺžniky s názvom entity a atribútom vo vnútri. Vzťah znázorňujeme čiarou, ktorá spája dve entity. Podľa typu čiary rozlišujeme niekoľko druhov vzťahov. - plná čiara označuje identifikujúci vzťah, v ktorom tzv. závislá entita preberá primárny kľúč z nadradenej entity do svojho primárneho kľúča Obrázok č. 2: Identifikujúci vzťah medzi entitami - prerušovaná čiara označuje neidentifikujúci vzťah, v ktorom podradená entita preberá primárny kľúč z nadradenej entity ako cudzí kľúč. Cudzí kľúč sa nestáva súčasťou primárneho kľúča, ale predstavuje odkaz na nadradenú entitu. Obrázok č. 3: Neidentifikujúci vzťah medzi entitami - čiarko-čiarkovaná čiara označuje informačný vzťah, v ktorom sa nepreberajú žiadne kľúče, podáva len informáciu o existencii vzťahu medzi dvoma entitami 9

10 Obrázok č. 4: Informačný vzťah medzi entitami Významnou charakteristikou vzťahu je jeho kardinalita (mohutnosť, arita). Kardinalita charakterizuje počet entít, ktoré vstupujú do daného vzťahu. Definujeme vždy maximálnu a minimálu kardinalitu. Minimálna kardinalita môže nadobúdať hodnoty 0 alebo 1 a maximálna kardinalita 1 nebo N. Obrázok č. 5: Znázornenie kardinality vzťahu v notácii J. Martina (zdroj [1]) Pri modelovaní vzťahov v dátových modelov sa môžeme stretnúť s asociatívnou (väzbovou) entitou. Je v podstate kombináciou entity a vzťahu. Vyskytuje sa vo vzťahoch typu M:N, ktoré nemožno v reálnom databázovom svete implementovať. Preto zavádzame asociatívnu entitu, ktorá obsahuje konkrétnu inštanciu väzby medzi entitami. Túto inštanciu je navyše možné doplniť o potrebné údaje pomocou atribútov v rámci entity. Pre lepšie pochopenie uvádzam príklad vzťahu medzi zákazníkom a výrobkom, ktorý je typu M:N. Zákazník si môže objednať viac výrobkov a výrobok môže byť objednaný viacerými zákazníkmi. Zavedieme asociatívnu entitu objednávka, ktorá obsahuje konkrétnu väzbu medzi zákazníkom a výrobkom. Asociatívna entita objednávka môže byť doplnená o atribúty dátum zadania, počet kusov atd. Obrázok č. 6: Príklad použitia asociovanej entity. Ďalším prípadom, s ktorým sa môžeme stretnúť je rekurzívny vzťah, kde je entita spojená sama so sebou. Pri modelovaní často tiež zistíme, že rôzne entity sú v skutočnosti len odlišnými formami základnej entity. Jedná sa o entity, ktoré majú rôzne atribúty, ale majú veľa spoločného, t.j. niektoré atribúty sú spoločné a v ostatných sa odlišujú (špecializujú). V ERD môžeme takéto entity vyjadriť hierarchickými vzťahmi medzi nadtypovými a podtypovými (špecializovanými) entitami. Napr. v evidencii lietadiel sú v zvláštnych skupinách evidované tryskové, vrtuľové, bezmotorové lietadlá. 10

11 2.3 Stavové diagramy (State Transition Diagrams - STD) Stavové diagramy modelujú časovo závislé chovanie systému. Vyjadruje tie aspekty chovania, ktoré sú ovplyvnené pôsobením vonkajších udalostí na systém. Na STD modelujeme tiež i vnútorné závislosti, t.j. keď systém zmení chovanie na základe nejakého výsledku transformácie dát. Komponenty modelu sú stavy a prechody medzi nimi. Stavy sú znázorňované ako pomenované uzly grafu (obdĺžnik s popisom vo vnútri), a prechody znázorňujeme orientovanými hranami, ktoré znázorňujú prípustné zmeny stavu. Každá hrana v STD je ohodnotená dvojicou popisov - podmienka prechodu zo stavu do stavu a akcia, ktorá sa má vykonať behom prechodu. Podmienka je vlastne odpoveď na udalosť z okolia (signál, prerušenie, príchod dátového paketu) a akcia je odozva na danú udalosť, ktorú systém identifikoval. Obrázok č. 7: STD s ohodnoteným prechodom. (zdroj [1]). Stavové diagramy vždy obsahujú jeden počiatočný stav a jeden alebo viacero koncových stavov. Počiatočný stav spoznáme tak, že nevychádza zo žiadneho stavu. Koncové stavy sú stavy, z ktorých nevedie žiadna výstupná hrana, t.j. nemajú žiadneho následníka. Je vhodné koncové stavy vždy preveriť, či sú naozaj koncovými, pretože často dochádza k vynechaniu niektorých podmienok, čo vedie k analytickým chybám. Pre lepšie pochopenie logiky zložitejších stavových diagramov, je vhodné ich hierarchicky dekomponovať na jednoduchšie a prehľadnejšie diagramy. Nesmieme pritom zabudnúť na spätnú kontrolu úplnosti a bezospornosti medzi jednotlivými úrovňami. Pri tvorbe STD môžeme použiť nasledujúce metódy: 1) Identifikujeme všetky možné stavy systému a každý zakreslíme do STD. Potom hľadáme všetky možné prechody medzi stavmi a zakresľujeme ich pomocou orientovaných hrán. 2) Vychádzame z počiatočného stavu a systematicky skúmame prípustné zmeny stavu a zakresľujeme orientované hrany a nové stavy. Potom pokračujeme pri hľadaní ďalších prechodov a stavov. Po dokončení predbežného STD je potrebné preveriť či boli všetky stavy definované, dosiahnuteľné, a či je možné všetky stavy opustiť. Takisto skontrolujeme či boli identifikované aj také podmienky zmien stavu, ktoré sa vymykajú štandardným situáciám pri prevádzke systému. 2.4 Diagram dátových tokov s riadením (Control Data Flow Diagram - CDFD) Diagram dátových tokov s riadením predstavuje DFD, ktorý je rozšírený o riadiace procesy, toky a pamäte. Každý riadiaci proces je možné popísať pomocou STD, je to 11

12 vlastne jeho procesná špecifikácia. Tiež platí, že ku každému STD musí existovať riadiaci proces na DFD. Graficky znázorňujeme riadiace procesy a toky pomocou prerušovaných čiar. Vstupné riadiace toky, ktoré vedú do riadiaceho procesu predstavujú podmienky prechodu v STD. Výstupné toky riadiaceho procesu odpovedajú akciám stavového diagramu. 2.5 Dátový slovník (Data Dictionary - DD) Dátový slovník predstavuje zoznam všetkých dátových prvkov a elementov, ktoré súvisia so systémom. Každý dátový element je popísaný podľa vopred definovaných pravidiel. Zameriavame sa predovšetkým na: - popis významu dátových tokov a pamätí, ktoré sme použili pri tvorbe DFD - zloženie a typ dát prúdiacich po tokoch alebo, ktoré sú uložené v pamäti - prípustné obory hodnôt a prípadne použité jednotky ktoré môžu dáta nadobúdať - popis zložených dát pomocou odkazov na jednotlivé zložky - vzťahy medzi entitami v ERD modeli Vo svojej práci som použila nasledujúcu notáciu, ktorá určuje pravidlá pre zápis dátových prvkov: Symbol Význam Príklad = skladá sa X = Y X sa skladá z Y + A Z = X + Y Z sa skladá z X a Y () voliteľná časť Z = X + (Y) Z sa skladá z X príp.z Y {} Iterácia použitých symbolov Z = {X} Z sa skladá z niekoľkých X [] výber jednej z možností Z = [X Y] Z sa skladá z X alebo z Y ** Komentár *toto je identifikátor, kľúčová položka Oddeľovač možností v [] Ako príklad uvádzam popis objektu Študent. ŠTUDENT = meno + priezvisko + status + adresa + telefón + ( ) ID_STUDENT = {číslo} číslo = [0-9] meno = {prípustný znak}30 prípustný znak = [A-Z a-z.,] priezvisko = {prípustný znak}30 status = [nový bývalý potencionálny] adresa = ulica + {číslo} + mesto + PSČ ulica = {prípustný znak}50 mesto = {prípustný znak}50 PSČ = {číslo}5 telefón = {číslo}20 = {prípustný znak} Procesné špecifikácie Špecifikácie procesov vytvárame pri funkčnom modelovaní systému po vytvorení rozkladu systému na množinu procesov, ktoré komunikujú pomocou dátových tokov s terminátormi, pamäťami a inými procesmi. Procesy na najnižšej úrovni DFD už ďalej 12

13 nerozkladáme, ale vhodným nástrojom popíšeme ich logiku, t.j. vytvoríme ich minišpecifikáciu. Každá minišpecifikácia obsahuje pravidlá a postupy pre transformáciu vstupných dátových tokov na výstupné dátové toky, nezaoberáme sa však implementáciou týchto pravidiel. V špecifikačnom dokumente sa nesmú vyskytovať reduntatné údaje, musíme ich eliminovať. Jednou z možných foriem vyjadrenia je použitie tzv. štruktúrovanej angličtiny. Jedná sa o jazyk, ktorý používa slovník angličtiny, pričom definuje určité obmedzenia, napr. nepoužíva zbytočné prídavné mená, príliš zložité vetné konštrukcie, interpunkčné znamienka, všetky módy okrem imperatívu atď. Slovník štruktúrovanej angličtiny sa skladá z imperatívnych anglických slovies, pojmov definovaných v DD, rezervovaných slov pre vyjadrenie logických výrazov. Syntax je obmedzená na jednoduché oznamovacie vety, uzavreté rozhodovacie a opakovacie konštrukcie. Napríklad uzavretá rozhodovacia konštrukcia má tvar. IF <podmienka>, THEN, <činnosť pre platnú podmienku>. OTHERWISE <činnosť pre neplatnú podmienku>. Ďalšou z možných alternatív pre vyjadrenie špecifikácie procesu sú rozhodovacie tabuľky. Používame ich hlavne v prípadoch, keď je potrebné popis transformácie procesu vyjadriť ako splnenie niekoľkých podmienok, ktoré môžu nadobúdať viacero hodnôt. Do tabuľky uvedieme všetky podmienky a akcie, ktoré sú na týchto podmienkach závislé. Výhodou rozhodovacích tabuliek je ich prehľadnosť. Zároveň je pomerne jednoduché overiť, či sú vnútorne konzistentné (t.j. či pre danú situáciu nie sú predpísané dve rôzne akcie) a úplné (či je v nich zachytená každá možná situácia). Rozhodovaciu tabuľku môžeme vyjadriť aj graficky, pomocou rozhodovacieho stromu. Pre ilustráciu rozhodovacej tabuľky uvádzam príklad o rozhodnutí o nákupe. Podmienka / Typ akcie Pravidlá Videla som niečo pekné v obchode A A A A A N Mám v banke peniaze - A A N N - Nevyhnutne to potrebujem A A N A N - Mám pri sebe dosť peňazí A N - N - - Prejdem okolo bez povšimnutia Pozriem si tú vec x x Opýtam sa a budem ju obdivovať x Kúpim ju na šek x Kúpim ju za hotové x x Obrázok č. 8: Príklad rozhodovacej tabuľky V ľavej hornej časti tabuľky sú podmienky, na základe ktorých sa treba rozhodnúť. V pravej hornej časti sú rozobrané možné situácie, dané sú ako kombinácie splnenia/nesplnenia týchto podmienok. V ľavej dolnej časti sú akcie, medzi ktorými sa treba rozhodnúť. Pravá dolná časť obsahuje priradenie akcií jednotlivým situáciám, ktorú akciu treba v danej situácii vykonať. 13

14 Úvodné a záverečné podmienky je vhodné použiť v prípadoch, ak je jasné, že určitá činnosť je podľa zákazníka vykonávaná pomocou špecifického algoritmu a analytik je toho názoru, že môže byť použitých viac druhov algoritmu. Stanovia sa podmienky, ktoré musia platiť pre vstupné a výstupné hodnoty. Príklad: Precondition 1: Študijné oddelenie žiada informácie o osobných údajoch a navštevovanom kurze študenta uložených v pamäti ŠTUDENT. Postcondition 1: Údaje meno, priezvisko, titul, adresa, telefón, , dátum narodenia, navštevovaný kurz. 14

15 3 Metodiky štruktúrovanej analýzy V predchádzajúcej kapitole som popísala nástroje potrebné pre štruktúrovanú analýzu, ale zatiaľ som neuviedla ako je tieto nástroje možné použiť. V ďalších kapitolách preto uvádzam najznámejšie metodiky, s ktorými som sa zoznámila, a to DeMarcova štruktúrovaná analýza a špecifikácia systému, Yourdonova moderná štruktúrovaná analýza a metodológiu SSADM. 3.1 Štruktúrovaná analýza a špecifikácia systému (SASS) Štruktúrovaná analýza a špecifikácia systému alebo bola jednou z prvých metód štruktúrovanej analýzy, ktorej autorom bol Tom DeMarco. Zameral sa na analýzu informačného systému s použitím metódy 4 modelov, preto sa táto metodika nazýva aj analýza pomocou 4 modelov. Tento postup je znázornený na nižšie uvedenom obrázku, a detailnejšie popísaný v nasledujúcej kapitole. Obrázok č. 9: Analýza pomocou 4 modelov (zdroj[2]) Postup tvorby modelov podľa SSAS metodiky 1. Vytvorenie fyzického modelu. Analytik najskôr zmapuje stávajúci systém, jeho funkčnú štruktúru a fyzické dáta. Fyzický model môže obsahovať spracovávanie a presun fyzických formulárov a pod. 15

16 2. Vytvorenie logického modelu. Fyzický model stávajúceho systému prevedieme na logický model stávajúceho systému, pričom sformulujeme podstatu transformácie dát a výstižne pomenujeme logické procesy. Zrušíme všetky implementačné detaily, ktoré by systém robil, keby sme mali ideálnu technológiu (nekonečné pamäte, nekonečnú rýchlosť atd.). 3. Vytvorenie logického modelu nového systému Väčšina systémov pravdepodobne zostane nezmenených, prípadne ich rozšírime o požiadavky na nové funkcie. Po úpravách a konzultácii s užívateľom sa zmeny zahrnú do nového logického modelu. 4. Vytvorenie fyzického modelu nového systému. K novému logickému modelu navrhneme vhodnú implementáciu a vznikne fyzický model nového systému. Ukázalo sa však, že vývoj systému pomocou uvedených modelov a vyššie uvedeného postupu je problematický. Jeho nevýhodou je relatívne dlhá doba potrebná na tvorbu fyzického a logického modelu, a skutočnosť že 75% fyzického modelu bude nepoužitých pri prevode na logický model. Analytik je silne ovplyvňovaný starým systémom, a v konečnom dôsledku logický model nového systému oproti starému obsahuje len minimálny počet zmien. Veľa užívateľov tiež spochybňovalo zmysel dôkladnej tvorby modelu systému, ktorý aj tak nebude použitý a bude nahradený novým systémom. O odstránenie týchto nedostatkov sa pričinil Edward Yourdon, ktorý sa pokúsil modelovať systém použitím esenciálneho modelu Použité nástroje pri tvorbe modelov Vstupom DeMarcovej štruktúrovanej analýzy sú užívateľské požiadavky a výstupom je tzv. štruktúrovaná špecifikácia. Samotný systém je špecifikovaný pomocou DFD, v ktorom sú uvedené podstatné procesy, pamäte a údaje. Zložitejšie procesy sú dekomponované na DFD nižšej úrovne. Elementárne procesy sú zapísané pomocou procesných špecifikácií, rozhodovacích tabuliek alebo stromov. Dátová časť systému je popísaná v Dátovom slovníku. Obrázok č. 10: Dokumenty štruktúrovanej špecifikácie (zdroj[2]) 16

17 3.2 Yourdonova moderná štruktúrovaná analýza (YMSA) Medzi najznámejšie a najpoužívanejšie metodológie patrí Yourdonova moderná štruktúrovaná analýza. Podstatou YMSA, tak ako aj u väčšiny metód, je modelovanie a vytváranie obrazu reality špecifickými prostriedkami. Hlavným cieľom je zachytiť všetky objektívne javy a skutočnosti tak, aby sme získali podstatné informácie toho kúsku reality, ktorý chceme modelovať. Touto metodológiou sa budem zaoberať podrobnejšie, pretože pri vypracovávaní praktickej časti mojej práce som postupovala podľa danej metodológie Esenciálny model Pán Yourdon používa analytický postup, ktorý vedie k nájdeniu tzv. esenciálneho modelu. Modeluje to čo má systém robiť, tak aby spĺňal všetky požiadavky a potreby užívateľov. Je časovo stabilný a nezávislý na použitej technológii. Vo väčšine systémov má dlhú životnosť a prípadné zmeny nie sú rozsiahle. Na základe esenciálneho modelu je možné previesť návrh pre konkrétnu implementáciu systému. Postup je znázornený na obrázku. Obrázok č. 11: Analýza s esenciálnym modelom. (zdroj [1]) Esenciálny model sa skladá z dvoch nasledujúcich častí: modelu okolia systému modelu chovania systému Model okolia systému predstavuje rozhranie medzi systémom a okolitým svetom a model chovania systému popisuje vnútorné časti systému. Tvorbu samotného modelu by sme mohli rozdeliť do nasledujúcich častí: 1. Vytvorenie modelu okolia 2. Vytvorenie prvotného modelu chovania 3. Dokončenie modelu chovania 4. Vytvorenie implementačného modelu 17

18 3.2.2 Vytvorenie modelu okolia Vytvorením modelu okolia definujeme hranice medzi systémom a okolím, stanovíme s kým bude systém komunikovať, aké požiadavky užívateľov bude spracovávať a ako bude systém na tieto požiadavky reagovať. Hranice medzi okolím a systémom môžu byť stanovené na základe rozhodnutia vrcholového manažmentu, alebo sú výsledkom politického obmedzenia. Môžu byť zvolené tiež náhodne alebo ich voľbu môže ovplyvňovať analytik. Podstatné je zvoliť si primerané hranice, príliš malé alebo veľké môžu zapríčiniť komplikácie, alebo dokonca až neúspech samotného projektu. Model chovania systému obsahuje tieto časti: účel systému kontextový diagram zoznam udalostí s odozvami Účel systému je stručný textový dokument, ktorý vystihuje k akému účelu bude slúžiť vytváraný systém. Je určený predovšetkým pre pracovníkov vrcholového manažmentu. Stanovuje ciele, ktoré by mali byť dosiahnuté po realizácii a po uvedení systému do prevádzky. Text má byť stručný a výstižný, v rozsahu jedného alebo niekoľkých odstavcov. Kontextový diagram je špeciálny prípad diagramu dátových tokov. Obsahuje jeden hlavný proces, ktorý je prepojený s okolitým svetom pomocou vstupných a výstupných dátových tokov. Terminátormi budeme nazývať entity, ktoré komunikujú so systémom. Zdôrazňujem niekoľko dôležitých znakov systému: osoby, organizácie a iné systémy z okolia, ktoré so systémom komunikujú prijímané dáta z okolitého sveta, ktoré má systém nejakým spôsobom spracovávať produkované dáta, ktoré systém produkuje a posiela do okolitého sveta dátové pamäte, ktoré sú zdieľané medzi systémom a terminátormi, boli vytvorené okolitým svetom a systém ich používa, alebo sú produktom systému a používa ich okolitý svet hranice medzi systémom a okolitým svetom Zoznam udalostí obsahuje všetky podnety, ktoré sa vyskytujú v okolitom svete, a na ktoré systém reaguje nejakou odozvou. Podľa toho aký má udalosť charakter rozlišujeme nasledujúce typy udalostí: F-udalosť (Flow-oriented) tokovo orientovaná udalosť, spojená so vstupom dát do systému, napr. žiadosť študenta o zápis do kurzu T-udalosť (Temporal) časová udalosť, napr. prevádzanie týždennej kontroly absencií v kurzoch C-udalosť (Control) riadiaca udalosť, je združená s vonkajším povelom, ktorá nenesie dáta Dôležité je poznamenať, že nie všetky vstupné dátové toky sú tokovo orientované, často krát sa jedná o dodatočné informácie vyžiadané systémom. Podľa zložitosti systému, môže byť model okolia systému môže byť doplnený ďalšími komponentmi, napr. počiatočný dátový slovník, ERD model externých dátových pamätí. Pre tvorbu modelu okolia môžeme použiť 2 varianty možných postupov: 1.variant: Na základe informácií od užívateľov zostavíme kontextový diagram. Skúmaním jeho komponentov odvodíme zoznam udalostí. 18

19 2.variant: Postup tvorby pomocou tohto variantu spočíva vo vytvorení prvotného ERD diagramu, a skúmaním kľúčových objektov a vzťahov medzi nimi. Pre každú entitu hľadáme, aké udalosti vedú k jej použitiu alebo zmene. Na základe týchto poznatkov odvodíme zoznam udalostí a pomocou neho vytvoríme kontextový diagram. Pred dokončením modelu okolia je nutné preveriť ešte niekoľko podmienok, ktoré zabezpečujú jeho úplnosť. Každý vstupný tok na kontextovom diagrame rozpoznáva nejakú udalosť, alebo vytvára odozvu na udalosť alebo oboje. Každý výstupný tok predstavuje odozvu na nejakú udalosť. Nečasové udalosti by mali mať vstup, pomocou ktorého je systém schopný identifikovať ich výskyt. Každá udalosť produkuje odozvu, alebo ukladá dáta pre neskorší výstup, alebo mení stav systému Vytvorenie prvotného modelu chovania Po vytvorení modelu okolia už vieme s kým bude systém komunikovať a ako bude systém reagovať na podnety. Účelom modelu chovania je popísať vnútorné chovanie systému v závislosti na udalostiach, ktoré nastávajú v jeho okolí. Základom modelu chovania sú DFD modely vnútorných dátových tokov, ktoré reprezentujú podstatné činnosti systému. Ukázalo sa, že použitie klasického dekompozičného postupu metódou zhora nadol od kontextového diagramu k jednotlivým DFD, nie je príliš vhodné. Komplikácie by mohli vznikať hlavne pri identifikácii jednotlivých subsystémov. Preto YMSA používa dekompozíciu na základe udalostí. Dekompozícia na základe udalostí vychádza z vopred pripraveného zoznamu udalostí. Cieľom je vytvoriť prvotný DFD model, ktorý predstavuje prvotný model chovania. Postup tvorby prvotného DFD je nasledujúci: 1. Pre každú udalosť v zozname udalostí hľadáme odozvu, pre ktorú zakreslíme po prvotného DFD jeden proces. 2. Proces pomenujeme podľa očakávanej odozvy na túto udalosť. 3. Doplníme odpovedajúce vstupné a výstupné dátové toky. 4. Zakreslíme dátové pamäte, ktoré modelujú dáta potrebné pre spracovávanie asynchrónne prebiehajúcich procesov. 5. Výsledný prvotný DFD porovnáme s kontextovým diagramom a so zoznamom udalostí. Súčasne s prvotným DFD vytvárame dátový slovník, ktorý obsahuje popisy jednotlivých pamätí. Prvotný DFD obsahuje značné množstvo procesov, pretože poskytuje celkový prehľad o všetkých možných udalostiach a odozvách, ktoré sa v systéme môžu nastať. Tento fakt má za následok to, že prvotný DFD model by mohol pôsobiť neprehľadne, preto nie je vhodný pre konzultáciu s užívateľom Dokončenie modelu chovania. Prvotný DFD je zložitý, preto ďalším krokom postupu je jeho vyvažovanie na rôznych úrovniach, tzv. level balancing. Vyvažovanie prebieha v dvoch smeroch. Vyvažovanie smerom nahor prebieha postupným zlučovaním príbuzných procesov na nižšej úrovni do nadradených procesov na vyššej úrovni, čím získame DFD nultej úrovne. Vo väčšine prípadov zlučujeme tie procesy, ktoré majú spolu súvisiace vstupné alebo výstupné dátové toky. V prípade, že procesy pristupujú k pamäti, ktorú iné procesy nepoužívajú, používame techniku zakrývania pamätí. Vo vyššej úrovni sa to prejaví tým spôsobom že pamäť nevidíme. Niekedy je naopak nutné vyvážiť DFD smerom dolu. Zložité procesy na danej úrovni dekomponujeme na jednoduchšie podprocesy, ktoré sa objavia na nižšej úrovni DFD. Ak funkčná dekompozícia nie je zrejmá, 19

20 pokúsime sa odvodiť dekompozíciu na základe vstupných a výstupných tokov, z ktorých odvodíme možné rozdelenia. Súbežne s vyvažovaním DFD prebieha tvorba a úprava ERD modelu. Na základe DFD identifikujeme entity a priraďujeme k nim príslušné atribúty. Postupne doplňujeme aj dátový slovník a preverujeme ho voči všetkým úrovniam DFD a ERD. Po prevedení úplnej dekompozície a jej následnej kontroly vytvoríme pre procesy na najnižšej úrovni procesné špecifikácie. Ak používame v DFD aj riadiace procesy, je nevyhnutné popísať ich pomocou stavových modelov. Stavové modely plnia funkciu minišpecifikácie riadiacich procesov. Esenciálny model je v tejto fázy kompletný a obsahuje: účel systému kontextový diagram zoznam udalostí kompletná sada vyvážených DFD modelov kompletná sada ERD modelov kompletná sada stavových diagramov kompletný dátový slovník kompletná sada procesných špecifikácií Obrázok č. 12: YMSA s vyvažovaním Vytvorenie implemetačného modelu Finálnou fázou YMSA je vytvorenie implementačného modelu. Vychádza z esenciálneho modelu podľa ktorého je vytvorený návrh systému rešpektujúci všetky požiadavky užívateľa a používa vhodnú technológiu pre implementáciu navrhnutého systému. Výhodou je, že pri zmene technológie možno na základe esenciálneho možné implementáciu prispôsobiť aktuálnym potrebám. Dokončenie implementačného modelu spočíva: vo vymedzení rozsahu automatizovaných častí v určení užívateľského rozhrania a v doporučení pre jeho návrh návrh formulárov a obrazoviek špecifikácia operačných obmedzení opatrenia pre chybové technológie 20

21 3.3 Sturctured System Analysis and Design Methodology - SSADM Metodológia SSADM sa stala v priebehu 80. a 90. rokoch štandardom pre analýzu a návrh systémov. Jedná sa o metodológiu, ktorá kladie dôraz na detailný a štruktúrovaný prístup v každej etape vývoja projektu. Súčasťou metódy je systematické preverovanie dosiahnutých cieľov a ich následné korekcie. SSADM oddeľuje logický a fyzický návrh. Kladie dôraz na to, aby boli v priebehu analýzy zachytené neštandardné situácie a chybové stavy systému, ktoré by mohli nastať. Pre vytvorenie presnejšej definície aplikácie sa používajú rôzne modelovacie a diagramatické techniky Členenie procesu analýzy a návrhu v SSADM Formálne je SSADM rozdelená do 6 etáp, ktoré obsahujú jednotlivé kroky a majú striktne definované vstupy a výstupy. 1. etapa Analýza stávajúceho systému Stávajúci systém je študovaný za účelom porozumenia okolia a problémových oblastí nového systému. 2. etapa Špecifikácia požiadaviek Pohľad na stávajúci systém je použitý pre vytvorenie špecifikácie požadovaného systému. 3. etapa Výber technických možností Špecifikácia požiadaviek je podrobnejšie spracovaná, na základe ktorej je možné sformulovať technické riešenia. 4. a 5. etapa Návrh logických dát a procesov Podrobný návrh je dokončený na logickej úrovni ešte predtým ako sú riešené implementačné aspekty. 6. etapa Fyzický návrh Aplikáciou jednoduchých pravidiel je logický návrh prevedený na fyzický návrh Základné modely systému SSADM vytvára 3 základné modely systému: Logické dátové štruktúry (Logical Data Structures-LDS) tvorí dátový model, ktorý ukazuje informáciu uchovávanú v systéme a vzájomné vzťahy medzi jednotlivými informáciami Diagram dátových tokov (DFD) tvorí funkčný model, ukazujú akým spôsobom sa predávajú a transformujú informácie v systéme Životný cyklus entít (Entity Life History-ELH) ukazuje, ako entita vznikne, ako sa mení, a ako zaniká z pohľadu modelovaného systému 21

22 Logické dátové štruktúry LDS modeluje entity a ich vzťahy, od ERD modelov sa odlišuje predovšetkým grafickým znázornením vzťahov medzi entitami. Obsahuje komponenty trojakého druhu: datová entita predstavuje niečo čo je z hľadiska systému významné, a o čom sa má informácia uchovávať datová položka najmenšia diskrétna zložka informácie, ktorá má význam z hľadiska modelovaného systému vzťah asociácia medzi dvoma alebo viacerými entitami Okrem grafického znázornenia vzťahov medzi entitami, používa LDS model aj popisnú časť, ktorá uvádza z akých dátových položiek sa skladajú jednotlivé entity, aké sú ich vlastnosti a význam. Diagram dátových tokov Umožňuje zobraziť systém ako sieť procesov, ktoré plnia dané funkcie a vymieňajú si medzi sebou dáta. Ukazujú ako vstupujú informácie do systému a ako ho opúšťajú, ako sa informácie v systéme transformujú, a ako sa informácie uchovávajú. Skladá sa zo štyroch komponent externých entít, procesov, pamätí, dátových tokov. V metodológii SSADM sa používa odlišná notácia ako v YMSA. Životný cyklus entít Obrázok č. 13: SSADM notácia pre DFD Typický nástroj pre SSADM, pri ktorom vychádza z logiky spracovávania modelu entít. Skúmame udalosti a podnety, ktoré by nejakým spôsobom mohli ovplyvniť stav entity, na základe ktorých vytvoríme model životného cyklu entity. Jedná sa o model, ktorý znázorňuje život jednej entity od jej vzniku až po jej zrušenie. EHL model má stromovú štruktúru, v koreni je umiestnená samotná entita, jednotlivé uzly na nižších úrovniach predstavujú podnety, ktoré pôsobia na entitu behom jej života. Pre vyjadrenie časových udalostí sa používa pri tvorbe grafu používa nasledujúca konvencia. Sekvencia (postupnosť) udalosti sú zoradené v každej úrovni grafu zľava doprava. Selekcia (voľba) definuje alternatívy, z ktorých je vždy jedna zvolená, označujú sa kolieskom. Iterácia (opakovanie) definuje cyklus opakovania udalosti rovnakého typu, označujú sa hviezdičkou. Uvedené modely sú navzájom tesne zviazané. Každý model je tvorený nezávisle na ostatných, avšak po dokončení je jeho úplnosť preverená voči ostatným dvom modelom. 22

23 4 Analýza informačného systému jazykovej školy Pri analýze informačného systému jazykovej školy som sa rozhodla postupovať podľa Yourdonovej modernej štruktúrovanej analýzy, ktorej postup som dôkladne popísala v kapitole 3.2. Pre realizáciu analýzy som použila modelovací nástroj CASE studio 2. Prvým krokom bolo vytvorenie modelu okolia, ktorý predstavuje jednu z dvoch častí esenciálneho modelu. 4.1 Model okolia systému Model okolia predstavuje rozhranie medzi systémom jazykovej školy a jej okolím. Stanovuje s kým systém komunikuje, spracováva požiadavky užívateľov a odozvy na ne. Skladá z nasledujúcich troch častí: účel systému, kontextový diagram a zoznam udalostí Účel systému Hlavným účelom informačného systému je predovšetkým skvalitniť prevádzku a služby jazykovej školy. Jeho úlohou je podporiť a zefektívniť patričným spôsobom prácu zamestnancov a umožniť študentom získavať čo najaktuálnejšie informácie o poskytovaných službách jazykovej školy. Systém umožňuje: - evidovať základné informácie o študentoch a zamestnancoch školy - evidovať výpožičky lektorov a študentov, platby za kurzy a výpožičky - sprostredkovanie informácií o ponúkaných kurzoch, rozvrhoch kurzov a o ostatných službách - objednávať nové študijné materiály Užívatelia systému: Študent si zvolí jazyk, ktorý by chcel študovať. Po absolvovaní vstupného testu a určenia vstupnej pokročilosti si vyberie vhodný kurz z ponuky kurzov. Vyplní prihlášku, do ktorej uvedie svoje osobné údaje. V prípade nespokojnosti môže prestúpiť do iného kurzu alebo zrušiť zápis kurzu. Po zrušení zápisu je povinný uhradiť pomernú čiastku z ceny kurzu podľa aktuálneho cenníka a zaplatiť storno poplatok. Za príslušný poplatok si môže vypožičať študijné materiály. Môže si prezerať aktuálny stav výpožičiek a rozvrh kurzov. Lektor je zamestnanec jazykovej školy, ktorý vyučuje jazykové kurzy. Má možnosť vypožičiavať si študijné materiály potrebné k výučbe, pristupovať k údajom o študentoch a prezerať si údaje o kurzoch a rozvrhoch. Je povinný evidovať dochádzku v kurzoch a hlásiť absencie. Po skončení kurzov odovzdáva hodnotenie kurzu. Ekonomické oddelenie prijíma a kontroluje realizáciu platieb za kurzy a výpožičky. Posiela upomienky študentom, ktorí nezaplatili. Platí faktúry za objednávky nových študijných materiálov. 23

24 Vedenie školy prevádza administratívu zamestnancov školy. Určuje a aktualizuje ceny kurzov. Má možnosť prezerať si informácie o kurzoch, informovať sa o návštevnosti kurzov a vedie štatistiky k jednotlivým kurzom. Študijné oddelenie vedie evidenciu osobných údajov o študentoch a vyučovaných kurzoch. Vypisuje nové kurzy, ruší neobsadené kurzy, zostavuje a mení rozvrhy kurzov. Požičiava študentom a lektorom študijné materiály. V prípade potreby objednáva nové študijné materiály. Kontroluje stav vrátených študijných materiálov, odovzdávanie dochádzok a hodnotení kurzov. Dodávateľ študijných materiálov prijíma a potvrdzuje objednávky, posiela faktúry a dodáva študijné materiály Kontextový diagram Na základe účelu systému a následnej analýzy procesov v jazykovej škole som v CS2 vytvorila kontextový diagram. Pozostáva z jedného procesu Jazyková škola a z terminátorov: Študent, Lektor, Študijné oddelenie, Ekonomické oddelenie, Vedenie a Dodávateľ. Kontextový diagram zachytáva komunikáciu týchto vymenovaných objektov so systémom. Dátové toky vedúce do procesu Jazyková škola predstavujú dotazy a požiadavky užívateľov systému. Dátové toky vedúce z procesu Jazyková škola prestavujú odozvy a reakcie. Pre prehľadnosť som jednotlivé toky vystupujúce z procesu Jazyková škola a toky vstupujúce do terminátorov odlíšila farebne. Ako ukážku uvádzam časť kontextového diagramu, kompletný diagram uvádzam v prílohe. Obrázok č. 14: Časť kontextového diagramu 24

25 4.1.3 Zoznam udalostí Zoznam udalostí je úzko spojený s kontextovým diagramom. Obsahuje kompletný zoznam udalostí a ich odoziev, ktoré sa vyskytujú v systéme. Každá položka zoznamu obsahuje číslo udalosti, názov udalosti, typ udalosti a odozvy na danú udalosť. Typ udalosti môže byť tokovo, časovo alebo riadene orientovaný. Vzhľadom k veľkému rozsahu zoznamu udalostí uvádzam len príklad niektorých udalostí, ktoré sa v systéme objavujú. Celý dokument obsahuje 48 udalostí a je uvedený v priloženom CD. U1 Študent žiada o zápis do kurzu. (F) Odozvy: Voľba jazyka, Vyplnenie vstupného testu, Vyhodnotenie testu, Určenie pokročilosti, Vyplnenie prihlášky, Zápis do kurzu, Pridelenie statusu U7 Študent sa dotazuje na svoje výpožičky. (F) Odozvy: Zaslanie zoznamu výpožičiek študenta U14 Lektor žiada o požičanie študijných materiálov. (F) Odozvy: Zápis výpožičky, Zmena statusu výpožičky, Vydanie výpožičky U21 Ekonomické oddelenie sa dotazuje na pohľadávky študentov. (F) Odozvy: Zaslanie pohľadávok študentov, Zaslanie upomienok študentom U28 Vedenie upravuje cenník služieb a kurzov. (F) Odozvy: Uloženie upraveného cenníku, Zaslanie potvrdenia U45 Študijné oddelenie žiada informácie o dochádzkach kurzov. (F) Odozvy: Zobrazenie dochádzok kurzov U48 Systém prevádza týždennú kontrolu absencií v kurzoch. (T) Odozvy: Zobrazenie stavu absencií v kurzoch 4.2 Model chovania systému Ďalšou časťou esenciálneho modelu je model chovania systému, ktorý definuje jeho vnútorné časti. Tvorbu modelu chovania systému som rozdelila na vytvorenie prvotného modelu chovania a dokončenie modelu chovania Prvotný model chovania Princípom tvorby tohto modelu je grafické zakreslenie všetkých odoziev na udalosti. Ako nástroj pre grafickú reprezentáciu prvotného modelu chovania mi poslúžil diagram dátových tokov, nazývaný prvotný DFD. Jednou zo silných stránok DFD diagramov, ktoré CS2 podporuje je možnosť ich top-down dekompozície, teda proces na vyššej úrovni je možné popísať pomocou procesov na nižšej úrovni. Prvotný DFD by teda bolo možné vytvoriť dekompozíciou kontextového diagramu. Nevýhodou je však fakt, že kontextový diagram neobsahuje všetky odozvy na udalosti, ale len odozvy, ktoré prekračujú hranicu systému. Preto prvotný DFD som konštruovala podľa zoznamu udalostí a odoziev. Každá odozva zo zoznamu udalostí by mala obsahovať samostatný proces na prvotnom DFD.To znamená, že z každého procesu by mal viesť jeden výstupný tok (odozva). Pre prehľadnosť modelu som však podobné procesy zlúčila už pri tvorbe prvotného DFD. Niektoré procesy teda reprezentujú viac odoziev a obsahujú 25

26 viac výstupov. Po zakreslení všetkých odoziev vzniklo zhruba 95 procesov. Prvotný DFD som doplnila o riadiace procesy, ktoré koordinujú prácu zložitejších udalostí. Riadiace procesy sú v samotnom diagrame označené žltou farbou a riadiace toky fialovou farbou. Tvorba modelu pokračovala doplnením potrebných pamätí a tokov pre správnu prácu procesov. Pre zvýšenie prehľadnosti modelu som zakreslila do modelu kópie terminátorov a pamätí, ktoré sú označené hviezdičkou za názvom objektu. Pre lepšiu predstavu uvádzam príklad udalosti a odoziev na ňu: U14 Lektor žiada o požičanie študijných materiálov (F) Odozvy: Zápis výpožičky Zmena statusu výpožičky Vydanie výpožičky Obrázok č. 15: Výrez z prvotného DFD diagramu Súbežne s vytváraním DFD modelu som navrhovala prvotný ERD model. Každá entita z ERD modelu reprezentuje pamäť z DFD modelu. Modelovanie ERD diagramov je v CS2 dobre prepracované, poskytlo mi ľahké priraďovanie identifikujúcich a neidentifikujúcich vzťahov medzi entitami. Pomocou menu entita som definovala atribúty entít, ich kľúče a typy. Pre určovanie kardinality a typu vzťahov som využila menu relácie, čo mi značne uľahčilo prácu. Jednou zo silných stránok CS2 je, že automaticky rozpoznáva asociovanú entitu pri použití M:N relácie. Entity Zamestnanec, Študent, Dodávateľ by mohli mať nadentitu Osoba, kde by som mohla využiť dedičnosť spoločných atribútov. Tento typ väzby ale CS2 nepozná, preto som ho nepoužila. 26

27 Obrázok č. 16: Prvotný ERD model Dokončenie modelu chovania Ďalším krokom k vytvoreniu esenciálneho modelu je dokončenie modelu chovania. Konečný model chovania vznikne postupným vyvažovaním procesov prvotného DFD smerom nahor do DFD 0. úrovne, a následnou dekompozíciou procesov tohto modelu, na jednotlivé podprocesy. Keďže CS2 nepodporuje vyvažovanie smerom nahor ani kopírovanie a spájanie jednotlivých procesov, vytvorila som ďalší DFD model, ktorý obsahuje agregované procesy. Po zvážení som zlúčila také procesy, ktoré mali podobné alebo spolu súvisiace odozvy. Pri výskyte redundatných tokov pri jednotlivých procesoch a pamätiach som pristúpila k ich odstráneniu. Pre sprehľadnenie modelu som zakrývala pamäte, ak ju používali iba spolu súvisiace zlučované procesy. Ďalším vyvažovaním smerom nahor som získala DFD 0.úrovne. Po dosiahnutí nultej úrovne som pristúpila k vyvažovaniu modelu smerom nadol. Tento proces vyvažovania bol už znateľne príjemnejší, pretože CS2 vyvažovanie týmto smerom podporuje. Nastavením atribútov v menu procesu, je možné povoliť posun do nižšej úrovne. Pri presune sú tiež skopírované potrebné objekty a toky procesu. Pri manipulácii s objektmi je potrebné byť opatrný, pretože odstránenie objektu na nižšej úrovni sa prejaví aj na vyšších 27

28 úrovniach. Pridávanie nových objektov a tokov na nižších úrovniach sa vo vyšších vrstvách nezobrazuje. Priebežne s vyvažovaním DFD prebieha tiež úprava ERD modelu. ERD je potrebné doplniť o nové entity, previesť normalizáciu entít, doplniť potrebné atribúty entít. Po prevedení dekompozície a jej spätnej kontroly, je čas na popísanie elementárnych procesov na najnižšej úrovni pomocou minišpecifikácií. Pre napísanie minišpecifikácií som zvolila textovú formu s použitím štruktúrovanej angličtiny. CS2 umožňuje v atribútoch procesu popis minišpecifikácií procesu, ktorý som aj využila. Ako príklad uvádzam minišpecifikácie procesu Úpravy údajov v cenníku. 1. IF Vedenie SEND požiadavka úpravy cenníku THEN 1.1 SELECT: CASE 1 (požiadavka na zápis) WRITE zmenené údaje TO CENNÍK CASE 2 (požiadavka na zrušenie) DELETE zmenené údaje TO CENNÍK CASE 3 (požiadavka na pridanie) UPDATE zmenené údaje TO CENNÍK 1.2 SEND potvrdenie TO Vedenie Ďalším komponentom esenciálneho modelu je dátový slovník. S tvorbou dátového slovníka začíname už pri tvorbe prvotného DFD diagramu a postupne ho dopĺňame. Obsahuje popis všetkých tokov a pamätí, ktoré sa v modeloch vyskytujú. Preveríme ho voči všetkým úrovniam DFD a EDR modelu. K tomu, aby bol esenciálny model kompletný chýbajú ešte stavové diagramy riadiacich procesov, ktoré nahradzujú ich minišpecifikáciu. Na ukážku uvádzam stavový diagram: Obrázok č. 17: Stavový diagram procesu riadenia výpožičky študenta 28

29 5 Záver Pri vypracovávaní tejto práce som sa zoznámila s metodikami štruktúrovanej analýzy a v praxi som si vyskúšala čo všetko obnáša prevedenie analýzy informačného systému. Z uvedených metodík som si zvolila Yourdonovu štruktúrovanú analýzu, pomocou ktorej som previedla analýzu informačného systému jazykovej školy. Presvedčila som sa, že jednou z vlastností analytika musí byť dôkladnosť a precíznosť pri vypracovávaní jednotlivých modelov. Pri analýze systému vznikajú modely a dokumenty, ktoré musia byť vzájomne konzistentné. Každú zmenu v modeloch a dokumentoch je potrebné zvážiť, pretože sú časovo náročné a môžu viesť k vzájomnej nekonzistencii modelov. Ďalšou fázou Yourdonovej štruktúrovanej analýzy, ktorou sa vo svojej práci nezaoberám by bolo vytvorenie implemenačného modelu, ktorý definuje a špecifikuje vlastnú komunikáciu medzi užívateľom a systémom. Zoznámila som sa tiež s aplikáciou Case Studio 2, ktorá mi poslúžila predovšetkým pre tvorbu DFD a ERD diagramov. Výhodou tejto aplikácie je vzájomná prepojenosť týchto diagramov a predovšetkým možnosť dekompozície DFD diagramu. Nedostatkom tohto nástroja je však vyvažovanie DFD smerom nahor, ktoré prakticky vôbec nepodporuje, a analytik je nútený pre každú úroveň vytvárať nový model, čo nie je moc pohodlné. Vzhľadom k rozsiahlosti a značnej komplikovanosti analyzovaného systému jazykovej školy som sa pokúsila špecifikovať všetky požiadavky kladené na systém a zdokumentovať ich, pretože by mali poslúžiť pre návrh vyvíjaného systému. 29