Informačné systémy - skriptá - 8

NÁVRH A PROJEKTOVANIE IS

159

8. Návrh a projektovanie ISNávrh a projektovanie IS je veľmi dôležitou fázou pri zavádzaní ľubovolného informačného sys-

tému, pretože do značnej miery ovplyvní celkovú funkcionalitu systému a jeho životnosť. Projektompritom budeme považovať návrh organizačných, personálnych, technických, programových, staveb-ných, technologických a prevádzkových opatrení a činností, ktoré vytvárajú predpoklady pre automa-tizáciu určitých činností v rámci príslušného systému. Projekt je obvykle vyjadrený formou doku-mentácie. Vlastný návrh a projektovanie IS prešlo podobne ako samotné informačné systémy dlhodo-bým vývojom, počas ktorého boli aplikované rôznorodé princípy, metodiky a nástroje návrhu. Pred-metom obsahovej náplne predkladanej kapitoly je uviesť základné princípy tvorby projektov v oblastiIS, rozobrať najpoužívanejšie metodiky návrhu, ako aj príslušné nástroje používané pri vlastnom ná-vrhu IS.

8.1 Životný cyklus vývoja projektuKaždý projekt vývoja IS môžeme popísať prostredníctvom jeho životného cyklu v rámci ktorého

prechádza príslušnými fázami od úvodných analýz až po prevádzkovanie IS. Každá z jednotlivých fázprojektu je charakteristická svojimi vstupmi, výstupmi a postupom riešenia. Celkovo môžeme špecifi-kovať 5 základných fáz, ktoré sa vo všeobecnosti premietajú do životného cyklu každého projektu:

Špecifikácia požiadaviek a plánovanie IS je fáza, v rámci ktorej sa formulujú požiadavkykladené na plánovaný IS, analyzujú sa východiská a existujúci stav, pričom v neposlednomrade sa skúma, akým spôsobom vzájomne korešponduje organizačná, informačná a technolo-gická štruktúra v rámci daného subjektu.

Definičná štúdia – v rámci tejto fázy sa špecifikujú dielčie projekty, ktoré budú pokrývaťcelkový projekt. Špecifikuje sa logický model IS tzv. koncept systému a v neposlednom radesa určí celková realizovateľnosť výsledného projektu.

Návrh systému pokrýva vlastnú špecifikáciu štruktúry systému aj s prihliadnutím na konkrét-ny výber hardvérovej a softvérovej platformy. Definujú sa nielen jednotlivé funkcie systému,ale aj systémové dáta.

Implementácia a zavádzanie – ide sa o vlastnú realizáciu IS, v rámci ktorej prebieha imple-mentácia jednotlivých modulov IS, testovanie funkcionality systému na tzv. skúšobných dá-tach. Úlohou je inštalovať príslušný HW, SW a uviesť systém do prevádzkového stavu.

Prevádzka a údržba je finálna etapa, v rámci ktorej sa systém rutinne používa a udržuje vprevádzkovom stave.

Životný cyklus výstavby projektu môže koncepčne vychádzať z niekoľkých možných variant,medzi najpoužívanejšie patria :

• vodopádový typ – jedná sa o typ životného cyklu, kedy je každá z fáz ukončená schvaľovacímkonaním a po jeho ukončení nasleduje ďalšia fáza.

• fontánový typ – je v praxi používanejší typ nakoľko predpokladá, že po ukončení určitej etapyje možný návrat k predchádzajúcej etape aj s určitou modifikáciou jej výstupu.

• sieťový typ – je zdokonalením fontánového typu, nakoľko umožňuje paralelné spracovanieniekoľkých etáp súčasne.

• špirálový typ – je metóda aplikovaná práve pri návrhu softverových systémov, pričom využívaiteračný režim práce s postupným vylepšovaním výsledkov jednotlivých fáz.

• typ založený na metóde pokusov a omylov – kedy sa vlastné riešenie uberá metódou omylova pokusov s určitým experimentálnym a živelným charakterom riešenia. Tento model sa použí-val veľmi často pri riešení netypických systémov, s ktorých implementáciou neboli získané do-posiaľ žiadne skúsenosti.

INFORMAČNÉ SYSTÉMY 8. KAPITOLA

160

• typ založený na metóde prototypového modelu riešenia – vychádza z aplikovania už existu-júcich prototypov riešenia daného systému, ktorý má obdobné vlastnosti ako systém, pre ktorýuž existuje prototyp riešenia.

• typ založený na metóde tvorby modelu reality

Na obrázku (Obr. 8.1) je pre ilustráciu uvedený príklad životného cyklu fontánového typu, kedyjednotlivé fázy na seba sekvenčne naväzujú a po ukončení jednej fázy nasleduje bezprostredne nasle-dujúca fáza, ale principiálne je možný návrat k predchádzajúcim fázam. Na obrázku je tento princípdokumentovaný vo fáze prevádzky a údržby systému, kedy sa skúsenosti s prevádzkou IS priamopremietajú do fázy analýzy a budúcich zmien v systéme.

Analýza

Návrh

Implementácia

Prevádzka/údržba

Obr. 8.1 Fontánový životný cyklus vývoja projektu

8.2 Metodológia návrhu a projektovania ISBudovanie informačných systémov a tvorba projektov v tejto oblasti prešla pomerne dlhým ob-

dobím vývoja, v rámci ktorého boli vypracované metodologické postupy, overené príslušné metódynávrhu a aplikované príslušné nástroje pri návrhu IS. Pre zjednotenie terminológie v ďalšom definu-jeme príslušné pojmy používané pri návrhu IS. Ich príklady sú uvedené v tabuľke (Tab. 8-1) a ichvzájomnú náväznosť zachytáva obrázok (Obr. 8.2).

• metodika návrhu predstavuje vlastne súhrn postupov a dielčích metód, ktoré definujú čo sarobí v procese tvorby IS. Určujú kedy a kým sa dané úkony vykonávajú, za použitia akých me-tód a nástrojov. Jedná sa vlastne o akúsi filozofiu tvorby a návrhu IS.

• metódy návrhu určujú čo je potrebné vykonať v rámci konkrétnej fázy návrhu a aké prístupy jepotrebné pritom dodržať.

• techniky určujú ako postupovať pri riešení daného návrhu.• nástroje sú prostriedky na vykonanie určitej činnosti

Tab. 8-1 Príklady používaných metodológií, metód a nástrojov pri návrhu IS

Metodika SSADM(Structured Systems Analysis and Design Method) fy LBMS (UK)Oracle CASE Method fy Oracle Corp. (USA)SDM (System Development Method) fy Gap Gemini Pandata (Holandsko)MDIS (Multidimensional Development of IS) VŠE (ČR)

Metóda Yourdon Structured Method (Yourdanova štruktúrovaná metóda návrhu IS )Jackson System Development (Vývoj systémov podľa Jacksona)Information Engineering (Informačný inžiniering)

Technika top-down princíp (návrh zhora - dolu)


161

Chenov model (Chenovoo modelovanie dát)Nástroj Data Flow Diagram (Diagramy dátových tokov)

Entity Relationship Diagram (Entitno–relačné diagramy)Structure Chart (Štruktúrne diagramy)CASE(Computer Aided System Engineering)-automatizované nástroje vý-voja

CASE Nástroje

Techniky Metódy

Metodika

Obr. 8.2 Vzájomná náväznosť jednotlivých prostriedkov návrhu IS

8.3 Nástroje používané pri návrhu ISV nasledujúcej kapitole si preberieme základné nástroje používané pri návrhu IS a metódach ná-

vrhu, ktoré sú využívané v rámci metód štrukturálnej analýzy. Ide sa o pomocné nástroje, ktoré slúžiana modelovanie procesov prebiehajúcich v informačných systémoch, stanovenie pohybu a spracova-nia informácií v rámci IS, ako aj k vlastnému modelovaniu bázy dát. V ďalšom sa zameriame na :

• Diagramy dátových tokov,

• Entitno-relačné diagramy.

8.3.1 Diagramy dátových tokov

Diagramy dátových tokov DFD (Data Flow Diagram) predstavujú grafický nástroj určený k opi-su systému z funkčného pohľadu, pretože vystihujú, čo má systém vykonávať, preferujú funkčné hľa-disko pred dátovým pohľadom a dávkové spracovanie pred interaktívnym. Pôvodne boli vyvinuté nazáklade inšpirácie diagramami toku práce (work flow diagrams) v rámci štruktúrovanej analýzy ateóriou grafov. Diagramy popisujú tok dát a ich transformáciu v rámci informačného systému. Nezao-berajú sa časovou následnosťou operácií a jednotlivých procesov, pretože vyjadrujú len to, že výstup-né dáta jedného procesu sú vstupnými dátami iného procesu, prípadne kde sú dáta prechodne uložené.Diagramy dátových tokov pozostávajú z nasledovných prvkov:

• 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é. Proces vyjadruje fyzickú transformáciu dát, alebozmenu stavu určitej časti dát.

• externá entita (terminátor) 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 nepo-zná jej obsah a správanie.

• 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 spotrebiču dát.

• dátová pamäť je miesto v systéme, kde sú dáta dočasne ukladané pre ďalšie spracovanie, takžemodeluje dáta v pokoji. Procesy s dátami v dátovej pamäti môžu vykonávať operácie typu číta-nie, zápis, aktualizácia, výmaz).


162

Dátový tok

Dátový tok

Proces

Externá entita Dátová pamäť

Dátová pamäťExterná entita

Proces

Yourdonova notácia

Gane-Sarsonova notácia

Obr. 8.3 Používané notácie na vyjadrenie prvkov DFD

Pretože DFD slúži na grafické vyjadrenie dátových tokov, musia byť jednotlivé prvky DFD gra-ficky odlíšené. Konkrétne vyjadrenie jednotlivých prvkov DFD je pritom závislé od konkrétnej školy[Gane 1978, Yourdon 1989]. Obidve vyjadrenia sú naznačené na predchádzajúcom obrázku (Obr.8.3). Pri tvorbe diagramov dátových tokov sa uplatňuje niekoľko zásad, vymenujeme preto aspoň tienajdô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, výmaz dát), externou entitou a procesom (vstupdát do systému), procesom a externou entitou (výstup dát zo systému);

• dátové toky nie sú povolené medzi dvoma externými entitami (komunikácia je potom mimo IS) amedzi 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);

• nesmie existovať proces, ktorý sám spotrebováva dáta (má vstupné toky, pričom nemá žiadny vý-stupný tok);

• diagramy dátových tokov majú hierarchický charakter, pretože proces v diagrame na vyššej úrovni,môžeme upresniť diagramom nižšej úrovne. Procesy ktoré sa už nehierarchizujú nazývame primi-tívnymi procesmi;

• jednotlivé procesy a ich hierarchické začlenenie vyjadrujeme priradeným číslovaním, ktoré začínačíslom “0”, a podľa hierarchického členenia nasledujú čísla vyššie (0 → 1, 2, 3; 1→ 1.1, 1.2; 1.1→ 1.1.1, 1.1.2 ,…);

• konkrétny diagram dátových tokov nesmie presiahnuť z prezentačných dôvodov rozmer A4 a ne-mal by mať z dôvodov prehľadnosti viac ako 9 procesov;

• diagram najvyššej úrovne sa nazýva kontextovým diagramom, pričom je tvorený len jediným pro-cesom, ktorý zastupuje funkciu navrhovaného IS a externými entitami. Kontextový diagram vyjad-ruje vzťah IS k jeho okoliu;

• názvy procesov by mali byť stručné, pričom by mali výstižne charakterizovať daný proces a jehofunkcie;

• nesmú existovať procesy s rovnakými názvami a funkciami;

• nesmú existovať procesy a toky bez prideleného názvu.

Pri aplikácií diagramov dátových tokov na konkrétny IS sa postupuje obvykle nasledovne:

spísanie požiadaviek na vlastnosti IS,


163

vytvorenie kontextového diagramu odpovedajúceho navrhovanému IS,

hierarchická dekompozícia kontextového diagramu na diagramy nižších úrovní,

špecifikácia primitívnych procesov.

Použitie diagramov dátových tokov si vysvetlíme na nasledovnom príklade.

Príklad:Aplikujte diagramy dátových tokov DFD pri návrhu zjednodušeného IS zameraného na

rezervačný systém železničnej dopravy.

1. Spísanie požiadaviek na vlastnosti IS• rezervačný systém musí umožniť príjem požiadaviek na miestenku kupé vlaku z terminálov od

jednotlivých operátorov : vlak: číslo vlaku, trasa: východzia, koncová stanica, deň;• rezervačný systém musí zabezpečiť overenie voľnosti kupé a podľa výsledku vytlačiť na tla-

čiarni terminálu miestenku a rezervovať v IS dané kupé, alebo zobraziť na jeho monitore za-mietnutie operácie;

• rezervačný systém musí umožniť aktualizáciu informácií od správcu systému.

2. Vytvorenie kontextového diagramuKontextový diagram vyjadruje vzťah navrhovaného informačného systému voči okoliu, preto ex-

ternými entitami v tomto prípade budú terminály operátorov jednotlivých železničných staníc a termi-nál správcu IS. V kontextovom diagrame vystupuje jediný proces, ktorý predstavuje cieľovú funkciuIS, čo je v tomto prípade príslušný rezervačný systém. Operátor ako externá entita systému prenáša naproces dátový tok „žiadosť na miestenku“, pričom proces smeruje na operátora tok, „vydanie miesten-ky“. Externá entita správca systému prenáša na proces dátový tok „žiadosť na aktualizáciu informáciío vlakoch“, naopak proces prenáša na externú entitu správcu informácie o vlakoch. Kontextový dia-gram dátových tokov je znázornený na nasledujúcom obrázku ()

Rezervačnýsystém

0.

Operátor 1 Operátor 2 Operátor n

Správa RS

Žiadosť namiestenku

Vydaniemiestenky

Žiadosť naaktualizáciu Výpis

informáciío vlakoch

Obr. 8.4 Kontextový diagram pre IS – Rezervačný systém

3. Vytvorenie systémového diagramu a dekompozícia diagramov dátových tokovSystémový diagram rozkladá primárny proces z kontextového diagramu na podprocesy, pričom

uvádza aj dátové toky k dátovým pamätiam. V rámci predkladaného príkladu by sa mohlo jednať opodproces „1. Rezervácia miestenky“ a o podproces „2. Aktualizácia informácií o vlakoch“, dátovoupamäťou by mohla byť v tomto prípade príslušná databáza vlakov. Ak sa budeme koncentrovať nadekompozíciu podprocesu „1.“, môžeme získať nasledovný diagram dátových tokov (Obr. 8.5).


164

Príjemobjednávky

1.1

Overenievoľnosti kupé

1.2

Operátor i

Žiadosť namiestenku

vlak,trasadeň

Dátabáza vlakov

Žiadosť nainformácie ovlaku,kupé

Vydaniemiestenky

1.3informácia o

voľnostikupé

Informácieo vlaku ,kupé

Rezerváciakupé

Vytlačenie výsledku(miestenka, zamietnutie)

Obr. 8.5 Diagram dátových tokov po dekompozícií procesu "1."

„1.1 Príjem objednávky“ – prijíma objednávku na miestenku od operátora, obsluhuje komuniká-ciu s operátorom, formátuje požiadavku na miestenku do tvaru „vlak–trasa–deň“, ktorý odosiela napodproces „1.2“.

„1.2 Overenie voľnosti kupé“ – na základe príjmu informácií z dátového toku „vlak–trasa–deň“od podprocesu 1.1, prehľadáva databázu vlakov, by získal informácie o voľnosti kupé podľa danýchpožiadaviek, viď dátové toky „Žiadosť na informácie o vlaku a kupé“ a „Informácie o vlaku a kupé“,medzi dátovou pamäťou „Databáza vlakov! a podprocesom „1.2“.

„1.3 Vydanie miestenky“ – prijíma prostredníctvom dátového toku „Informáciu o voľnosti kupé“,spĺňajúcich príslušné požiadavky na vlak, trasu a deň. Komunikuje s externou entitou „Operátor“prostredníctvom dátového toku „Vytlačenie miestenky“ a s dátovou pamäťou „Databáza vlakov“,prostredníctvom toku „Rezervácia miestenky“. Analogicky by v ďalšom nasledovala, ďalšia dekom-pozícia podprocesov „1.1“, „1.2“ a „ 1.3“, až po stanovenie primitívnych procesov, čím sa však z prie-storových dôvodov nebudeme venovať.

8.3.2 Entitno-relačné diagramy

Entitno-relačné diagramy ERD (Entity Relationship Diagram) sú grafickým nástrojom,ktorý sa používa pri návrhu IS na vyjadrenie modelu dát, pričom je vlastne pohľadom na sta-tickú časť systému. Zaviedol ich v roku 1976 Chen za účelom zjednotenia rôznorodých mo-delov databáz. V rámci ERD sú definované jednotlivé dátové objekty IS a vzťahy medzi nimi.Používajú sa štandardne v metódach štruktúrovanej analýzy ako doplnok ku diagramom dáto-vých tokov, ktorých nedostatkom je, že špecifikujú len funkcie a nie vlastný model dát. Entit-no-relačné diagramy pozostávajú z nasledovných prvkov :

• dátová entita je akýkoľvek dátový objekt, ktorý je predmetom záujmu o ktorom chceme ucho-vávať údaje. Entita ako taká vyjadruje typ objektu.

• relácia je vyjadrením vzťahu medzi entitami, pričom môže byť relácia orientovaná, alebo o-bojsmerná. Medzi entitami pritom môže existovať viac rôznych relácií.

• atribút je elementárny prvok, ktorý vyjadruje bližšiu charakteristiku entity.


165

Entitno-relačné diagramy sú grafickým nástrojom, preto sú definované pre ich jednotlivé prvkypríslušné symboly. Podobne ako u diagramov dátových tokov závisí ich vyjadrenie od konkrétnejškoly. Najpoužívanejšie sú notácie [Raumbaugh 1991, Chen 1976], ktoré sú naznačené na obrázku :

Entita1 Entita1

Entita1 Entita1

relácia

relácia

Raumbaugh

Chen

Obr. 8.6 Notácie na vyjadrenie entitno-relačných diagramov

Pri tvorbe entitno-relačných diagramov môžeme postupovať úplne nezávisle, alebo v priamej ná-väznosti na diagramy dátových tokov. V praxi býva dokonca zvykom, že projekčný tým je rozdelenýna dve nezávislé skupiny tvoriace DFD a ERD. Pri nezávislej tvorbe ERD sa obvykle vychádza z a-nalýzy modelovanej reality a požiadaviek užívateľov. Ak pred návrhom ERD boli vypracované dia-gramy dátových tokov, môže sa priamo využiť kontextový a systémový diagram a špecifikované dá-tové toky a dátové pamäte. Postup je potom nasledovný :

analýza a spísanie požiadaviek na IS,

vytvorenie kontextového diagramu,

vytvorenie systémového diagramu,

vytvorenie základného entitno-relačného diagramu,

spresnenie entitno-relačného diagramu podľa nižších hierarchií DFD.

Na nasledujúcich obrázkoch (Obr. 8.7, Obr. 8.8) uvádzame pre ilustráciu príklad kontextovéhodiagramu obchodnej organizácie, ktorý modeluje informačný systém „Systém objednávok a evidencievýrobkov – SOE“, ktorému sme priradili odpovedajúci entitno-relačný diagram, modelujúci dátovýpohľad a statickú časť systému s príslušnými relačnými väzbami medzi jednotlivými dátovými ob-jektmi.

SOE

Distribútor

0.

Učtáreň Marketing

Sklad - výdaj Sklad - príjem

Predaj Nákup

Potvrdenkaobjednávky

Objednávka

Dodací list

Distribútor

Katalógvýrobkov

Dodací listŽiadanka na nákup

Výdajka Príjemka

Obr. 8.7 Príklad kontextového diagramu obchodnej organizácie


166

vystavuje

Objednávka

Výdajka

Dodací list

Žiadanka nanákup

Objednávka

Výrobok

Katalógvýrobkov

Sklad

Príjemka

Distribútor

obsahuje je vkatalógu

obsahuje

obsahuje

obsahuje

obsahuje

obsahuje

umiestnený v

má

mámôžemať

Obr. 8.8 Príklad odpovedajúceho entitno-relačného diagramu

8.4 Metódy používané pri návrhu ISPri návrhu informačných systémov sú aplikované prostriedky softvérového inžinierstva, ktoré sa

zaoberá problémami tvorby veľkých softverových systémov. Softvérové inžinierstvo kladie hlavnýdôraz na kvalitu softvérového systému. Kvalita sa pritom chápe ako komplexná charakteristika zahŕ-ňajúca atribúty ako funkčnosť, spoľahlivosť, robustnosť, modulárnosť, otvorenosť a znovu použiteľ-nosť. Metódy aplikované softvérovým inžinierstvom predstavujú riadený prechod od živelného návr-hu ku systematickej postupnosti krokov, ktoré vedú k štandardnému návrhu a implementácií systému.V súčasnosti sa stretávame s týmito hlavnými typmi metód:

• Objektovo–orientované metódy (Rumbaugh 1991, Coad 1991, Shlaer 1988),

• Metódy štruktúrovaného programovania (Yourdon 1989),

8.4.1 Objektovo orientované metódy

Tvoria metodickú nadstavbu nad objektovými programovacími jazykmi, akými sú napríklad C++,Delphi, SmallTalk a ďalšie. Preferujú dátový pohľad pred funkčným pohľadom, pričom vychádzajú zdefinície objektov, čo sú vlastne definované údajové štruktúry rozšírené o priradené funkcie. Založenésú na dekompozícii systému podľa dátového pohľadu, pričom hlavným nástrojom návrhu sú tzv. ob-jektové diagramy. Objektové diagramy sú vlastne rozšírením klasických entitno-relačných diagramovo objektový pohľad. V ďalšom sa im však už nebudeme kvôli obsahovému obmedzeniu publikáciepodrobnejšie venovať.

8.4.2 Štruktúrované metódy

Predstavujú vlastne metodickú nadstavbu nad štruktúrovanými programovacími jazykmi s proce-durálnou výstavbou, akými sú napríklad jazyky Cobol, Pascal a jazyk C. Je pre ne charakteristické, ževyužívajú funkčné hľadisko návrhu. Najskôr sa stanoví cieľová funkcia systému, ktorá sa následnedekomponuje na podfunkcie, ktoré sú realizovateľné priamo procedúrami príslušného programovacie-ho jazyka. Pri takomto spôsobe návrhu prevažujú funkcie nad dátami. Charakteristickým pre štruktú-


167

rované metódy je aplikovanie diagramov dátových tokov DFD doplnených o entitno-relačné diagramyERD. K najpoužívanejším štruktúrovaným metódam dnes patrí Yourdonova metóda, ktorá predsta-vuje klasickú školu štruktúrovanej analýzy a procedurálneho návrhu softverových systémov. Yourdo-nova metóda využíva pri konkrétnom návrhu softveru IS nasledujúce etapy:

• spísanie požiadaviek na funkcie IS,

• dekompozícia cieľovej funkcie systému FSD (diagramy štruktúry funkcií),

• vytvorenie diagramov DFD (kontextový diagram a jeho dekompozícia),

• určenie diagramov dátových štruktúr a entitno-relačných diagramov ERD,

• špecifikácia primitívnych funkcií,

• určenie diagramov prechodov (špecifikácia náväznosti a volania funkcií).

8.5 Metodika návrhu ISPre lepšiu ilustráciu podrobnejšie charakterizujeme jednu z menovaných metodík návrhu IS a síce

metodiku MDIS (Multidimensional Development of Information System), ktorá bola vyvinutá v Čes-kej republike na VŠE. Nakoľko je zameraná viac na filozofiu návrhu a celkovú koncepciu IS, pričomneobsahuje striktnú definíciu jednotlivých krokov realizácie oproti iným metódam, je jednoduchšia abude vhodnejšia pre celkovú predstavu. MDIS je tzv. multidimenzionálna metodika návrhu, pretožepreferuje návrh IS zo všetkých pohľadov, ktoré ovplyvňujú celkovú efektívnosť IS.

8.5.1 Fázy vývoja IS podľa MDIS

Celkovo je filozofia návrhu koncipovaná tak, aby bolo možné rozdeliť návrh do jednotli-vých projektov, ktoré sú riešiteľné a odovzdateľné samostatne. MDIS definuje úrovne :

• strategická úroveň – v rámci tejto úrovne sa definuje globálna a informačná stratégia, ktorépostihujú hlavné smery vývoja subjektu a požiadavky na IS.

• konceptuálna úroveň – pokrýva vlastne úvodnú analýzu prostredníctvom tzv. úvodnej štúdie(US), ktorá analyzuje realizovateľnosť IS a rozdelenie projektu na čiastkové projekty. Súčasťoutejto úrovne je aj tzv. globálna analýza a návrh (GAN), ktorá prebieha v každom čiastkovomprojekte a definuje aplikačné funkcie, logický návrh dátovej základne a varianty implementač-ného prostredia.

• technologická úroveň – zastrešuje detailnú analýzu a návrh (DAN), v ktorom sa transformujekonceptuálny návrh do konkrétneho implementačného prostredia. Konceptuálny model bázy dátje prevedený na model relačný, pre konkrétny SRBD. Navrhované funkcie sú prevedené nakonkrétne programové moduly budúcej aplikácie a je prevedený návrh užívateľského rozhrania.

• implementačná úroveň – pokrýva vlastnú implementáciu IS, jeho zavedenie, prevádzku a ú-držbu. Relačný model sa premietne do priameho návrhu relačných databáz konkrétneho SRBD.Programové moduly sú naprogramované v konkrétnom aplikačnom vývojovom prostredí.


168

Úvodná štúdiaGlobálna analýza a návrh (GAN)Detailná analýza a návrh (DAN)ImplementáciaZavedenie ISPrevádzka a údržba

Globálna/Informačná stratégia

Projekt 1 Projekt 2 Projekt n

Strategická úroveň

Konceptuálna úroveň

Technologická úroveňImplementačná úroveň

Obr. 8.9 Fázy životného cyklu vývoja IS podľa metodiky MDIS

8.5.2 Architektúra IS podľa metodiky MDIS

Metodika MDIS pre potreby návrhu IS využíva dve úrovne architektúr IS a to tzv. globálnu ar-chitektúru, ktorá je len hrubým modelom konkrétneho IS a dielčie architektúry, ktoré detailnejšie po-krývajú jednotlivé vlastnosti IS. Architektúry slúžia ako základné modely využívané v jednotlivýchprojektoch na konkrétnej úrovni. Najskôr sa špecifikuje globálna architektúra a z nej sú následne špe-cifikované dielčie architektúry a ich vzájomné vzťahy. MDIS definuje nasledovné dielčie architektú-ry:

• funkčná architektúra – vychádza z jednotlivých blokov globálnej architektúry, pričom ich po-stupne rozkladá na jednotlivé skupiny funkcií. Rozklad blokov na funkcie je realizovaný hierar-chickým spôsobom, až po primitívne funkcie.

• procesná architektúra – predstavuje návrh základných procesov subjektu, ktoré sú reakciou naurčité udalosti. Pri návrhu a modelovaní procesov sa používajú najmä diagramy dátových tokovDFD.

• dátová architektúra – predstavuje návrh dátovej základne IS, dátových objektov a ich väzieb,konkrétnych databáz a spôsobu ich uloženia. V tejto architektúre na konceptuálnej úrovni sapoužívajú často entitno-relačné diagramy ERD.

• technologická architektúra – pokrýva technologické riešenie IS, do jej pôsobnosti spadá vý-ber konkrétne architektúry IS (host–terminál, klient–server, NCC), výber štandardov pre komu-nikáciu s databázovým serverom (ODBC, SQL),rozhoduje o výbere užívateľského rozhraniaznakového, respektíve GUI.

• softvérová architektúra -určuje z akých softverových komponentov bude informačný systémpozostávať. Špecifikuje sa celková softvérová architektúra, druh, verzie a počty licencií softve-ru na strane serverov aj klientov IS.

• hardvérová architektúra -určuje počty, typy a vzájomné väzby jednotlivých hardvérovýchkomponentov IS (serverov, pracovných staníc, terminálov, periférií).


169

SAP

SQL

Hardverováarchitektúra

Softverováarchitektúra

Dátováarchitektúra

Technologickáarchitektúra

Funkčnáarchitektúra

Procesnáarchitektúra

F1.1 F2.1

F1.1.2F1.2 F1.1.2

ENT1

ENT2

ENT3

|||||||||

WinWin

HP9000HPVectra

LAN:802.3RAID5

DFD

Obr. 8.10 Architektúra IS podľa návrhu metodikou MDIS

8.6 CASE – nástroje automatizovaného návrhu ISCASE (Computer Aided System Engineering) je oblasť zaoberajúca sa tvorbou nástrojov umož-

ňujúcich automatizovaný, respektíve poloautomatizovaný návrh softverových systémov. V súčasnostinástroje CASE používajú všetky významné softvérové domy zaoberajúce sa návrhom IS. Pri rozvojiCASE je obvykle snahou vytvoriť takú sadu automatizovaných nástrojov, ktorá by pokryla celý život-ný cyklus IS od strategického plánovania až po prevádzku systému a jeho údržbu. Automatizovanénástroje CASE pritom vychádzajú z osvedčených metód návrhu IS:

• metódy štruktúrovanej analýzy podľa Yourdona, DeMarca, Ward/Mellora,

• rozšírenia metód o analýzu systémov reálneho času,

• entitno-relačných metód modelovanie podľa Chena,

• štruktúrovaného návrhu,

• relačného dátového modelovania podľa Codda.

Jednotlivé komponenty, ktoré sú využívané pri aplikácií nástrojov CASE zhrnieme do nasledov-ných bodov:

• grafické nástroje systémovej analýzy a modelovania informačných tokov,• grafické nástroje na systémový návrh a implementáciu,• nástroje na tvorbu užívateľských rozhraní aplikácií,• nástroje dynamickej simulácie reakcií navrhovaných modulov z analýzy,• moduly poloautomatizovaného generovania údajových štruktúr a zdrojových sekvencií aplikácií

pre vybrané programovacie jazyky napr. 4GL (Progress 4GL), C, Cobol, ...• dokumentačné nástroje pre tvorbu pomoci a celkovej dokumentácie IS.

Dosah pôsobnosti nástrojov CASE závisí od ich konkrétnej implementácie pre príslušnú hardvé-rovú a softvérovú platformu. Výrobcovia týchto nástrojov sa však pokúšajú o univerzálnosť použitiana rôznorodých platformách. Napríklad programový balík Case /4/0 od firmy MicroTOOL pokrývanasledovnú skupinu produktov klient–server:

• Ada


170

• Informix SQL• Oracle PL/SQL• Progres 4GL• Watcom SQL• systémy Xbase (DBF formát)

Celkovo môžeme rozdeliť aplikáciu nástrojov CASE do troch základných fáz:

fáza analýzy a vytvorenie modelu IS

simulácia vytvorených modelov IS

návrh modulov, relačných databáz a programových modulov

1. Fáza analýzy a tvorby modelu – v tejto fáze sú nástroje CASE zamerané na vytváranie mo-delov dát, funkcií a ich vzájomného správania. Obvykle sa pritom aplikuje :

• diagram funkčných štruktúr slúžiaci na vytvorenie stromovej štruktúry funkcií systému, pri-čom uplatňuje prostriedky funkčnej dekompozície systému. Aplikuje pritom vertikálny po-hľad na funkčnú dekompozíciu.

• diagram informačných tokov podávajúci horizontálny pohľad na funkcie, informačné toky,externé rozhrania a samotné údajové objekty. Samotné funkcie sú pritom rozdelené do trochelementárnych skupín, na funkcie: riadiace, dialógové a spracúvajúce. Obdobne sú členenéaj samotné toky medzi funkciami na dátové, udalostné a materiálové.

• diagramy stavov a prechodov uplatňované na popis správania riadiacich funkcií, pričom ob-vykle aplikujú štandardné metódy z oblasti teórie konečných automatov.

• entitno-relačné diagramy, ktoré modelujú dáta z pohľadu ich typov, vzájomných väzieb atri-bútov podľa klasickej metódy vyvinutej pôvodne Chenom.

• diagramy dátových štruktúr vychádzajú z entitno-relačných diagramov, pričom slúžia na hie-rarchické rozčleňovanie dátových objektov a popis pohľadov na ne (views)

2. Fáza simulácie vytvorených modelov IS – slúži na odsimulovanie dynamického správaniavytvoreného modelu. Jej poslaním je odhaliť prípadné kritické miesta v dynamike systému, a-ko aj v samotnej špecifikácií jednotlivých modelov. Fáza prebieha obvykle tak, že sa zvoliadiagramy informačných tokov, nakonfigurujú sa scenáre udalostí generované externými enti-tami. Potom sa len nadefinujú akcie príslušných funkcií, ktoré ešte nie sú implementované.Výsledkom potom je vlastné overenie funkčnosti modelu, po ktorom už môže nastúpiť fázarealizácie.

3. Fáza návrhu IS – predstavuje implementačnú fázu návrhu v rámci ktorej sa generuje prísluš-né programové vybavenie a relačné databázové štruktúry. Obvykle sa vychádza najmä z dia-gramov informačných tokov, podľa ktorých sa generujú programové šablóny pre jednotlivéfunkčné moduly. Programové šablóny obsahujú vzory pre modulové prvky, akými sú naprí-klad prvky užívateľského rozhrania (formáty obrazoviek, pracovné meny, zostavy), funkciepracujúce priamo s databázami (SQL sekvencie) a spracúvajúce funkcie, ktoré v konečnomdôsledku realizujú spracovanie dát a aplikačnú logiku prostredníctvom transformácie dátovýchtokov.

8.6.1 Príklad konkrétne implementácie systému CASE

Nasledujúce obrázky znázorňujú príklad analýzy činnosti s využitím nástrojov programovéhoproduktu Case /4/0 od firmy MicroTOOL. Ide o ukážku základných činností firmy „Obchods nábytkom“. Prvý obrázok (Obr. 8.11) znázorňuje diagram štruktúry funkcií (FSD) informačnéhosystému firmy. Systém farebne rozlišuje funkcie, ktoré sú ďalej členené na dielčie funkcie, riadiace adialógové funkcie. Riadiace alebo dialógové funkcie už ďalej členiť nemožno. Možno ich považovaťza primitívne funkcie.


171

Obchod snábytkom

Vlastnýpredajnábytku

Sklad

Predajnábytku

Zásobovanienábytkom

Vytvorenieobjednávky

Zaradenieobjednávky

Vybavenieobjednávky

Zadováženienábytku

Vydávanienábytku

Riadeniezásobovanianábytkom

Obr. 8.11 Diagram štruktúry funkcií IS firmy "Obchod s nábytkom"

Jednotlivé funkcie zobrazené v diagrame možno ïalej dekomponovať na diečie funkcie.Informačné väzby medzi jednotlivými funkciami, externými entitami a dátovými pamäťami súzobrazené v ďalšom type diagramu – v diagrame dátových tokov (DFD). Obrázok (Obr. 8.12)znázoròuje príklad dekompozície funkcie „Vlastný predaj nábytku“ na dve čiastkové funkcie „Predajnábytku“ a „Zásobovanie nábytkom“. Na obrázku sú znázornené dátové toky medzi externou entitou„Zákazník“ a jednotlivými funkciami a tiež dátové toky medzi funkciami a dátovou pamäťoureprezentovanou „Centrálnou databázou“. Jednotlivé orientované hrany diagramu znázorňujú dátovétoky medzi entitami, funkciami a dátovými pamäťami.

Zákazník

Skladnábytku

Predaj nábytku

Predajnábytku

Zásobovanienábytkom

Centrálnadatabáza

Objednávka Zmeny v sklade

Nábytok

Zámer nakúpiť

Nábytok

Potvrdenka o predaji

Obr. 8.12 Diagram dátových tokov funkcie "Vlastný predaj nábytku"


172

S ohľadom na priestorové obmedzenia nebudeme uvádzať ďalšie DFD.

V informačnom systéme obchodu s nábytkom sa okrem iných uvažujú tieto entity :• kolekcia, ktorá je tvorená jednotlivými predmetmi,• predmet, ktorý je súčasťou kolekcie a súčasne môže byť predmetom objednávky,• objednávka, ktorá môže byť zaradená do určitej skupiny a• zaradenie objednávky.

Nasledujúci obrázok (Obr. 8.13) naznačuje vzájomné väzby medzi týmito entitami, pričomsúčasne vyznačuje aj kardinalitu ich vzťahu. V zásade ide o vzťahy typu N : 1, v obrázku označenéCN : 1. (Vzťah C znamená podmienku, pri ktorej platí daný vzťah)

Kolekcia PredmetCNzahŕňa

1patrí do

ZaradenieobjednávkyObjednávka

CNobsahuje

CNvyskytuje sa v

Obr. 8.13 Entitno-relačný diagram vzťahov medzi entitami IS

Posledná schéma (Obr. 8.14) znázorňuje relácie medzi jednotlivými dátovými pamäťamipoužitými v IS „Obchod s nábytkom“. V príklade sa predpokladá použitie relačného dátovéhomodelu. Ako dátové tabuľky sú navrhnuté tieto:

• kolekcia,• tovar,• objednávka,• zaradenie objednávky.

TovarKolekcia

Objednávka Zaradenieobjednávky

obsahuje

patrí do

zahŕňa

Obr. 8.14 Relačný diagram - vzťahy medzi dátovými tabuľkami

Programový produkt CASE poskytuje podstatne viac služieb, ale s ohľadom na obmedzený roz-sah tejto publikácie sa ním podrobnejšie zaoberať nebudeme.

Informačné systémy - skriptá - 8

Documents

Transcript of Informačné systémy - skriptá - 8