- 1 -

Objektovo-orientovaný prístup a jeho vlastnosti

Objektovo orientovaný (OO) prístup sa začal presadzovať v osemdesiatych, ale najmä

deväťdesiatych rokoch. Medzi vlastnosťami a výhodami OO prístupu existuje určitá priama

súvislosť. Ak sa definuje objektová paradigma ako budovanie IS pomocou základných

stavebných prvkov - objektov, potom zapúzdrenosť alebo uzatvorenosť (encapsulation) je

jeho prvou vlastnosťou, využívanou z dvoch hľadísk:

1. Zapuzdrenie sémanticky a funkčne príbuzných dát (dátovej štruktúry, atribútov

objektu) a funkcií (modelujúcich správanie a služby objektu) do jedného celku

– objektu. Spojenie dát a funkcií zlepšuje čitateľnosť, stabilitu a prepojenia.

Pri zmene štruktúry dát existuje možnosť okamžite meniť aj príslušné

algoritmy, ktoré s nimi pracujú. Okolie má prístup k dátam najčastejšie len

sprostredkovane. Spojením dátovej a funkčnej špecifikácie, sledovaní

dynamickej komunikácie a vzťahov medzi objektmi a triedami sa vyraďuje

divergencia dátových a programových štruktúr so všetkými problémami a

nedostatkami, ktoré vznikali v štruktúrovanej analýze a návrhu.

2. Uzavretosť a zapuzdrenie štruktúry dát a funkcií v rámci objektu pomocou

definovania úrovne prístupu. Členské funkcie, ale aj dáta môžu byť prístupné

všetkým (public - verejné), prístupné len členským funkciám triedy (private -

súkromné) a prístupné členským funkciám triedy a tried od nej odvodených

(protected - chránené). Túto vlastnosť označujeme aj ako viditeľnosť

(visibility). Metódy sú najčastejšie typu public, aby k nim bolo možné

pristupovať nielen v členských funkciách triedy, ale aj kdekoľvek v programe.

Okrem riadiacich a výpočtových operácií pokrývajú metódy aj V/V operácie -

interface, ktorý chráni atribúty pred neautorizovanou zmenou, ktorá by mohla

narušit konzistenciu prostredia. Atribúty sú preto najčastejšie typu private, aby

ich nebolo možné priamo meniť, ale len prostredníctvom metód často

označovaných ako GetAt() a SetAt() (ktoré vracajú a nastavujú hodnotu atribútu

At). Môžu však byť aj typu protected, aby bol zabezpečený ich prenos dedením

do odvodených tried.

Objektovo-orientovaný prístup je založený na práci s objektom (object) ako základným

elementom, z ktorého sa skladá skúmaný systém a navrhovaný projekt.

- 2 -

Objekt môže byť akákoľvek entita, ktorú tak označíme a budeme ju skúmať: človek,

budova, formulár, účet, počítač, pokladňa.

Objektom môže byť aj abstraktná jednotka alebo štruktúra, ktorá nám napomôže

modelovať skúmanú časť univerza. Objekt je aj súčasťou programu alebo operačného

systému, čisto objektovo-orientované programy a OS sa skladajú len z objektov, čím je

zabezpečený unifikovaný prístup, správanie, možnosť dedenia, agregácie a podobne.

Objekt vlastní okrem svojej identifikácie (OID - Object ID), svojho mena aj svoje

atribúty (členské dáta, attributes) a metódy (členské funkcie, methods).

Vyznačuje sa istým správaním (behaviour) a službami (services) voči ostatným

objektom a okoliu.

Abstrakciou objektov s rovnakými vlastnosťami je trieda, ktorej grafický popis

a implementáciu popisuje príloha A.1. Štruktúru takejto triedy ukazuje obr. A.1.1 a A.1.2.

v prílohe A.1. Správanie a služby objektu zabezpečujú metódy, stav objektu zabezpečujú jeho

hodnoty uchovávané v členských dátach – atribútoch.

Komunikáciu s okolím, prístup k jeho atribútom a využitie vlastností objektu

zabezpečujú metódy, ktoré označujeme aj ako komunikačné rozhranie (interface).

V Component Object Modeling (COM) technológii objekty vlastnia aj niekoľko takýchto

rozhraní napríklad podľa verzie, prostredia, používateľa. COM protokol umožňuje využívať

jednotlivé COM objekty samostatne aj rôznym používateľom v distribuovanom prostredí

počítačovej siete paralelne bežiacich úloh (DCOM) a vymieňať konkrétne COM objekty

v binárnej podobe za nové a nie vymieňať celé aplikácie. COM+ ako nová verzia dopĺňa

ďalšie vlastnosti tejto rozširujúcej sa technológie. Táto metóda používa objektové vlastnosti

a implementačné vzory (container-iterator, smart pointers a podobne) a je základným

stavebným prvkom MS Windows aplikácií dnes a aj v .net technológii na začiatku nového

tisícročia má svoje pevné miesto v logickej vrstve vďaka svojim nepopierateľným kvalitám.

Z existencie objektov ako modulov vyplýva aj snaha o ich viacnásobné využitie, ktoré

v objektovom prístupe ide ďalej a vytvára možnosť pre dedenie vlastností objektov do iných

objektov a takto dokonalejšie napĺňa potrebu znovupoužiteľnosti už raz napísaného a

odladeného kódu. Dedenie však neslúži len na prenos atribútov a metód z nadtriedy do jej

podtried, ale vďaka dedeniu čisto virtuálnych metód abstraktných nadtried aj dodržiavaniu

vopred stanoveného rozhrania. V prílohe A.2. je popísané nielen jednoduché a násobné

- 3 -

dedenie, ale aj opakované a virtuálne dedenie, jeho zápis aj implementáciu na konkrétnych

príkladoch.

Znovupoužitie v rôznorodom prostredí (napríklad celé čísla, reálne čísla, vektory,

matice, text a podobne) pri odlišných požiadavkách vyvolalo potrebu využiť rovnaký vzor pre

objekt, funkciu, parameter, metódu alebo operátor v rôznych tvaroch s rôznym správaním.

Túto mnohotvarosť označujeme ako polymorfia, vďaka ktorej je vytvorený projekt oveľa

prehľadnejší a preto aj menej náchylný na chyby, je ľahšie udržiavateľný a využiteľný.

V prílohe A.6 a A.7 je popísaná polymorfia metód, funkcií a operátorov, inkluzívna

a parametrická polymorfia, ako aj využite polymorfie v zlomkovej algebre veľkých čísiel

(dynamické polia celých čísiel s vlastnou aritmetikou) podľa [Polášek 98c].

Ďalšou dôležitou vlastnosťou objektov je posielanie a prijímanie správ (messages) a

reakcia na udalosti (events), ktoré môžu nastať.

Udalosť býva často prezentovaná nastatím javu (napr. vyplnenie formulára, podanie

žiadosti a pod.), prípadne dosiahnutím určitej úrovne sledovanej veličiny (čas, dátum, teplota,

hodnota premennej). Správa často obsahuje dáta a žiadosť spustiť konkrétnu metódu (napr.

PrijmiZiadost()).

Princípy a vlastnosti OO prístupu boli zatiaľ analyzované len na diagrame objektov a

tried, ktorý používajú všetky metodológie. Okrem tohto statického pohľadu na štruktúru

existuje aj dynamický model a jeho diagramy, v ktorom sa sleduje najmä správanie objektov

v čase a ich interakcie medzi sebou. Okrem toho slúži aj na identifikáciu potrebných metód

objektov prijímajúcich správu a vykonávajúcich potrebnú operáciu.

Na účely zaznamenania a popisu interakcií objektov a posielania správ (najmä vyvolania

metódy prijímajúceho objektu) slúži sekvenčný diagram (príloha B.3) a komunikačný

diagram (príloha B.4).

K ďalším výhodám patria:

Lepšia čitateľnosť a zrozumiteľnosť analýzy a návrhu, ktorý môže čítať bez

problémov aj zainteresovaný klient-zadávateľ, nádejný používateľ a doménový

expert. Zrozumiteľnejšie termíny OO prístupu približujú vývoj softvéru

používateľovi. Štruktúrovaný prístup sa podriaďoval potrebám, slovníku a

vyjadrovaniu z oblasti výpočtovej techniky, OO prístup prichádza bližšie k

neodborníkovi v oblasti informatiky, k neprogramátorovi a nenúti ho učiť sa

podrobne diagramové notácie pre dátový alebo funkčný model. Nemusí všetko

- 4 -

vidieť v tabuľkách a algoritmoch. Môže čítať a opravovať bez dlhej prípravy

objektové diagramy, ktoré popisujú jeho pracovné okolie, ako aj systém, ktorý mu

má pomôcť a ktorý sa buduje. Spätná väzba je preto oveľa rýchlejšia a kvalitnejšia.

Predchádza sa tým mnohým chybám, ktoré vznikajú nedorozumením medzi

analytikom a doménovým expertom, ktorý poskytuje informácie.

Objektový prístup používa pri zobrazení skutočnosti a návrhu silnejšie prostriedky

schopné okrem prvkov skúmaného prostredia alebo informačného systému a ich

vzťahov (ako to je aj v štruktúrovanom prístupe) znázorniť aj:

- vzťahy nadriadenosti/podriadenosti alebo generalizácie/špecializácie a dedenia

vlastností prvkov,

- vzťahy agregácie a skladania častí do väčších celkov (príloha A.3), ako aj

štandardné vzťahy 1:1, 1:n, n:m a podobne (príloha A.4),

- tokov správ a udalostí,

- zapuzdrenia atribútov a metód zoskupených do jednoliatych objektov tvoriacich

nezávislé jadro, rozhranie alebo používateľské prvky.

Toto všetko možno zaznamenať v jednom diagrame, bez straty prehľadnosti. Okrem

tohto bohatého, ale statického modelu tried a objektov je možné zachytiť v

dynamických modeloch aj ich premenlivosť a správanie sa v čase.

Väčšia nezávislosť analýzy a návrhu od programovacích jazykov, databázového

prostredia a abstraktnosť bližšia ľudskému chápaniu.

Možnosť pridávať ďalšie prvky do systému v iteráciách.

Podpora najnovších technológií, akými sú predpripravené architektúry - skelety

(frameworks), vzory (patterns), komponenty (moduly), stereotypy (klasifikácia,

ktorá rozširuje a špecializuje prvok triedy alebo asociácie).

Nevýhodou OO prístupu je väčšia réžia, ktorá súvisí s vytváraním a správou objektov

ako stavebných prvkov obsahujúcich členské dáta a metódy. Prejaví sa to vyššími nárokmi na

výpočtový čas a pamäťový priestor, ktorý je však pri dnešných prostriedkoch zanedbateľný.

Štruktúrovaný prístup sa však používa aj naďalej z nasledujúcich dôvodov:

- existencia množstva výkonných relačných SRBD (Oracle, Informix, Sybase, MS

SQL Server a ďalšie), štruktúrovaných programovacích jazykov (Cobol, C,

- 5 -

Pascal) a neobjektových operačných systémov (UNIX/linux, VMS), vývojových

prostredí a podobne,

- existuje množstvo odborníkov a používateľov pracujúcich so štruktúrovanými

metodológiami a množstvo existujúcich projektov, ktoré je potrebné udržiavať a

vyvíjať,

- pre svoje výhody, akou je napríklad menšia pamäťová a výpočtová náročnosť

programovacích jazykov, databáz a implementovaných projektov a iné.

Ak sa máme rozhodnúť, či si vyberieme štruktúrovaný, alebo objektový prístup, je

nutné zvážiť výhody a nevýhody jednotlivých filozofií pre konkrétny projekt, dostupnosť

prostriedkov (OS, DB, prog. jazyk, CASE) a odborných zdrojov.

Možnosti využitia objektového prístupu pri tvorbe informačných systémov

Po zhrnutí vlastností objektového prístupu a najpoužívanejších objektových

metodológií, postupností, metód a diagramových techník je možné zhodnotiť aj čiastkové

nedostatky pre vývoj IS:

1. Najrozšírenejšie metodológie a metódy nevytvárajú dostatočné možnosti minimalizovať

tvorbu nadbytočných a nesprávných konštrukcií, štruktúr a tried, ich voľnosť predpokladá

vytváranie vlastných konkrétnych postupov pre jednotlivé oblasti, nie každý tím však

zvolí najvhodnejší konkrétny postup pre svoj projekt pre nedostatok skúseností a

poznatkov. Najďalej sú napríklad metodológia OMT2 a postupnosť RUP, ktoré obsahujú

okrem orientácie na prípady použitia aj rozdelenie tried do vrstiev, vytváraných v

jednotlivých iteráciách. Chýba silnejšia nadväznosť a kontinuita, presnejší návod pri

vytváraní jednotlivých vrstiev: prezentačnej (V/V obrazovky a formuláre aplikácie),

logickej a databázovej, ktorá by viedla k previazanému vývoju a rozširovaniu. Objektový,

dynamický a funkčný model sú nedostatočne prepojené aj metodologicky, aj v SAPP a nie

je tak dostatočne podporená konzistencia návrhu ako aj implementácia kompletnej

aplikácie.

2. Chýba predpis pre tvorbu optimálnej štruktúry objektov, najmä stálych – perzistentných,

ktoré tvoria databázovú vrstvu, tak, ako tomu je v štruktúrovanom prístupe. Jednou z mála

- 6 -

výnimiek je Coad-Yourdonova metodológia, ktorá popisuje normalizáciu a RUP, kde sa

aspoň spomína denormalizácia.

3. Diagram aktivít je pre zápis algoritmov metód objektov a služieb nevhodný, vychádza zo

stavového diagramu, ktorý používa koncepciu Petriho sietí. Hoci v UML nie je samotný

diagram aktivít najdôležitejší, je nepochopiteľné, prečo autori ponechali tak nevhodný

diagram, ktorý je v podstate obdobou vývojového diagramu. Nevhodnosť diagramu, v

ktorom sa ťažko odlišuje vetvenie od cyklu, iterácia a cykly s hornou a dolnou

podmienkou, nie je možné editovať štruktúru (vkladanie, presun a výber) a dovoľuje

vznik goto konštrukcií, bude vysvetlená a ilustrovaná v kapitole Riešenie prepojenia

modelov návrhom alternatívneho vývojového prostredia. Tejto problematike sa nevenuje

dostatočná pozornosť. Nemôžu ho nahradiť ani interaktívne diagramy. Objektové CASE

systémy nepodporujú dostatočne zaznamenanie vetvenia a cyklov ani v sekvenčnom a

komunikačnom diagrame. Z toho dôvodu je nevyhnutné hľadať lepší spôsob

zaznamenania operácií. Jednou alternatívou je prevziať vhodný diagram zo ŠP, pretože

telo metódy objektu podlieha pravidlám ŠP. Z tabuľky 1, kde sú porovnané jednotlivé

diagramové techniky štruktúrovaného a objektového prístupu, je zrejmé, že okrem

explicitnej normalizácie používa aj vhodnejšie zobrazenie algoritmov vo funkčnom

modeli ŠP. Tu je možné použiť JSP, YSD, NSD, alebo HIPO diagramy, v nich sa dá

nielen správne navrhnúť algoritmus základnými prvkami riadiacich štruktúr, ale je možná

aj ľahká zmena vkladaním, vyraďovaním a posunom celých podstromov, ako aj

generovanie metódy, druhou možnosťou je vychádzať z kódu a hľadať pre neho

odpovedajúce grafické vyjadrenie.

Štruktúrovaný prístup

(ŠP)

Objektový prístup

(OP)

výhody ŠP výhody OP

Entiry Relationship

Diagram (Dátový

model)

Diagram tried a

Objektový diagram

(Objektový model)

explicitná

normalizácia

silnejšie pros-

triedky (dedenie,

agregácia, …)

Data Flow Diagram

(súčasť Funkčného

modelu, ako aj

OO DFD sa zväčša

nepoužíva, používa sa

Collaboration

- 7 -

nasledujúce diagramy) Diagram (UML)

Entity Life History, State

Transition Diagram

State Diagram

Vývojový diagram Activity Diagram

JSD, YSD, NSD, HIPO nepoužíva sa, nahrá-

dza ho Activity

Diagram, Use Case

Diagram, interaktívne

diagramy

vhodné

zobrazenie algoritmu

Tab. 1 Tabuľka porovnania zastúpiteľných diagramových techník

(použité aj originálne názvy a skratky pre porovnanie)

Medzi nedostatky nie je zaradené zneprehľadnenie znázornenia kardinality značkou

‘*’ v objektovom diagrame UML, napríklad oproti plnému krúžku ako konektoru na spojnici

v OMT, ktorý bol organickou súčasťou väzby a ponechával voľný priestor na zaznamenanie

kvalifikátorov a rolí. Takto voľne plávajúca kardinalita v UML pri konektore často ani presne

neurčuje, ku ktorej väzbe je priradená. Na toto upozorňujem už od roku 1997 na svojich

prednáškach. Riešenie je jednoduché: autority a odborná verejnosť by sa museli dohodnúť na

prechode k OMT znázorneniu kardinality. Toto kritizujú aj v [Blaha 98], kde však používajú

len OMT a nie UML.

Po štúdiu a praktických skúsenostiach pri tvorbe softvérových produktov, poznaní

predchádzajúcich prístupov, metodológií a techník, snahe nájsť vhodné postupy odvodením

podľa konkrétnych požiadaviek analýzy, návrhu a implementácie je možné predostrieť

nasledovný cieľ a koncepciu riešenia:

1. Popísať metódu analýzy a návrhu IS, obsahujúcu štandardné diagramy a základné

princípy jazyka UML a postupnosti RUP, jej etapy je však vhodné doplniť tak, aby

postupovali od požadovaných výstupov po potrebné vstupy, pretože moduly vstupu

a výstupu sú v IS veľmi dôležité. Vychádzať z požiadaviek používateľa cez vytvorenie

konceptuálneho pohľadu na doménovú vrstvu v analýze po návrh fyzickej štruktúry

aplikačnej, logickej a dátovej vrstvy systému postupnou inkrementáciou v iteráciách od

požadovaného až po neznáme. Takýto návrh, popísaný v kapitole Návrh metódy analýzy a

návrhu pre vývoj IS, by mal minimalizovať chyby v návrhu a maximalizovať prínosy

analýzy.

- 8 -

2. Doplniť analýzu a návrh o myšlienky optimalizácie objektovej štruktúry, inšpirovanej

normalizáciou zo štrukturovaného prístupu budovania dátového modelu podľa [Codd

70], [Codd 71], [Scheber 88], [Russev MM] a z Coad-Yourdonovej metodológie [Coad

91]. Navrhnúť využitie konceptuálneho, logického a fyzického pohľadu na objektový, ale

aj na dynamický a funkčný model v kapitole Návrh metódy analýzy a návrhu pre vývoj IS.

3. Hľadať vhodnejšiu diagramovú techniku pre funkčný model a navrhnúť prepojenie

jednotlivých modelov v kapitole Riešenie prepojenia modelov návrhom alternatívneho

vývojového prostredia.

Návrh metódy analýzy a návrhu pre vývoj IS

Návrh alternatívnej postupnosti, radiacej sa svojimi vlastnosťami k následníkom konzervatívnych

metód, je obsahom tejto kapitoly. Základom bude všeobecne využívaná etapa konceptualizácie,

analýzy a návrhu, ako je tomu aj pri ostatných postupnostiach.

Postupnosť bude zachovávať

- orientáciu na používateľské požiadavky, z ktorých vychádza v konceptualizácii, rozvíja v

analýze a návrhu, vracia sa k nim a overuje s používateľom pri vytvorení modelu IS,

- postup od požadovaných výstupov IS k dátovej štruktúre, od dátovej štruktúry k potrebným

vstupom až po definovanie logickej vrstvy na transformáciu a spracovanie údajov,

- rekurzívnosť (rozvíjanie štruktúry objektov a metód z konceptuálneho do logického až po

fyzický návrh v dynamickom a objektovom modeli),

- iteratívnosť (neustále preverovanie modelov v jednotlivých krokoch z rôznych pohľadov) a

nie postupný, vodopádový proces analýzy, návrhu a implementácie, ale rýchly vývoj

aplikácie podľa koncepcie RAD (Rapid Application Development), kedy sa ponúka

používateľovi na schválenie hneď na začiatku vývoja prázdny prototyp IS so základnými

vstupmi a výstupmi, v ďalšom kole opravenými a doplnenými, v ďalšom funkčnými a

prepojenými na databázu atď., životný cyklus musí zabezpečovať vhodne zvolenou

postupnosťou krokov implicitnú, vnútornú iteratívnosť, ale dovoliť aj explicitný, vonkajší

cyklus opakovania pri ladení a pre zmenové konanie,

- inkrementálnosť (pridávanie aplikačnej, dátovej a logickej vrstvy k doménovej do

objektového modelu).

- 9 -

Orientáciu na používateľské požiadavky, zachovanie a skĺbenie vlastností iteratívnosti,

rekurzívnosti a inkrementálnosti je možné zapísať čo najjednoduchšie nasledovne:

pre (doménovú, aplikačnú, mikroprocesnú vrstvu)

pre (všetky služby)

vytvor alebo aktualizuj dynamický model

vytvor alebo aktualizuj objektový model

vytvor alebo aktualizuj funkčný model

Doplnením tejto základnej kostry bude

1. postup od definovania výstupov k vstupom, buduje sa tak systém od očakávaných výstupov

zo služby systému, ktoré požaduje používateľ,

2. vytvorenie logickej vrstvy podľa požiadaviek výstupov na dáta a požiadaviek dátovej vrstvy

na vstupy a doplnenie funkčného modelu o kvalitnejšiu diagramovú techniku, odvodenú od

riadiacich štruktúr,

3. využitie používateľskej dokumentácie ako virtuálneho prototypu ešte neexistujúceho

produktu v etape návrhu, vytvorenie príručky ešte pred programovaním, overia sa prvé

analytické kroky a návrhy, vyhne sa nedorozumeniam medzi zadávateľom, používateľom,

analytikom a návrhárom, používateľ môže získať presnejší obraz o budúcom IS a pripraviť

ľudské kapacity odborne aj kvantitatívne, ako aj celkové prostredie, zabezpečí vstupné

informácie,

4. prepojenie dynamického, objektového a funkčného modelu konkrétnymi pravidlami v

postupnosti a návrh fyzického prepojenia aj priamo v SAPP.

Týmto spôsobom je možné minimalizovať chyby a chybné konštrukcie, skrátiť potrebný čas a

náklady a zachovať kontinuitu vývoja pomocou požiadaviek používateľa, odpovedajúcich služieb a

neskôr komponentov projektu, ktoré sú základnými prvkami procesu.

Podrobnejší postup je možné zapísať nasledovne:

1. zber požiadaviek a ich transformovanie do služieb systému v konceptuálnom diagrame ako

konceptualizácia

2. vytvorenie vysvetľujúcich modelov služieb ako analýza,

- 10 -

3. návrh výstupov služieb a systému, vytvorenie alebo doplnenie aplikačnej vrstvy,

4. návrh DB vrstvy podľa výstupov,

5. návrh vstupov, ktoré vyžaduje DB vrstva, doplnenie aplikačnej vrstvy,

6. vytvorenie prázdneho prototypu a používateľskej príručky, obsahujúcej celú aplikačnú

vrstvu v podobe fiktívneho systému, všetky potrebné testy služieb aj s výsledkami, základnú

ale aj podrobnú koncepciu; ak užívateľ po jej prečítaní požaduje zmeny, je nutný návrat na 1.,

2. alebo 3.,

7. návrh logickej vrstvy objektov, ktoré zabezpečia výstupy z DB, zápis algoritmov metód

objektov,

8. doplnenie logickej vrstvy, ktorá zabezpečí naplnenie DB zo vstupov,

9. doplnenie návrhu DB a IS,

10. vytvorenie viacvrstvového objektového modelu ako revízia vrstiev,

11. vytvorenie modelu softvérových a hardverových komponentov, pilotná verzia,

12. implementácia, testovanie a zavádzanie do prevádzky.

Diagramy UML, ktoré vysvetľujú štruktúru služby (diagram tried a objektov), správanie sa

objektov pri plnení úlohy služby (sekvenčný a komunikačný diagram), popisujúce stavový priestor

služby (stavový diagram) alebo algoritmus plnenia úlohy služby (diagram služieb, interakcií

(sekvenčný a komunikačný) a procesný diagram) budeme označovať ako poddiagramy služby a budú

sa využívať v etape analýzy IS.

Vo všeobecnosti poddiagram (subdiagram) bude diagram, vysvetľujúci element diagramu v

ďalšom samostatnom diagrame napríklad komponent, zväzok tried, službu (Component, Package,

Use Case), operáciu a podobne.

Používateľ bude môcť pripomienkovať prázdny prototyp a fiktívny systém v kroku 6., schváliť

príručku ešte pred krokom 7., prvú pilotnú verziu v kroku 11. a prvú funkčnú verziu v kroku 12.,

ktorá bude podrobená všetkým testom, odladená, zavedená do prevádzky a považovaná za prvú

produkčnú nasadenú verziu, referenčnú pre ďalší vývoj a zmenové konania. Okrem návrhu tejto

postupnosti je v práci popísaná aj jedna z aplikácií, ktorá vznikla týmto spôsobom ako experiment a

slúžila na odskúšanie tejto postupnosti v celosti. Výhodou tohto projektu bola jeho potrebnosť pre

prax ako motivácia (zápis, evidencia, hľadanie riešenia a sledovanie eskalácie incidentov),

dostatočná náročnosť, univerzálnosť a komplexnosť. Vyriešiť tento projekt sa nepodarilo už dvom

- 11 -

tímom v minulosti z dôvodov nedostatočnej analýzy ale aj skúseností. Vybraté časti analýzy a návrhu

sú v kapitole Aplikácia postupnosti pre vývoj IS na konkrétnom projekte.

Okrem popisu vlastností postupnosti a jej jednotlivých etáp treba definovať aj používané modely,

pohľady a vrstvy, ktoré navrhovaná metóda používa.

Model budeme chápať ako zjednodušenú kópiu reality v jazyku UML. V etape konceptualizácie

a analýzy ide najmä o kópiu podstatných častí analyzovanej domény a pôvodného IS, v etape návrhu

ide o model (predlohu) navrhovaného systému.

Konceptuálny model popisuje služby systému a jej používateľov, je to počiatočný model

konceptualizácie, ktorý zachytáva najmä dynamickú stránku systému (interakcie medzi používateľmi

a službami, ako aj službami navzájom), ale aj jeho funkčné prvky a hraničné triedy v podobe

stereotypov Používateľ (Actor). Používa sa v etape konceptualizácie.

Objektový model popisuje statickú štruktúru systému (triedy, objekty a ich vzťahy) pomocou

diagramu tried a objektov. Používa sa v analýze a návrhu.

Dynamický model popisuje správanie sa systému: interakcie medzi objektami pomocou

sekvenčného a komunikačného diagramu, zmenu stavov pomocou stavového diagramu. Používa sa v

analýze a návrhu.

Funkčný model popisuje spôsob riešenia úloh a funkcií systému: algoritmus je možné zapísať

nielen procesným, ale aj sekvenčným a komunikačným diagramom, ako aj diagramom služieb.

Používa sa v analýze a návrhu.

Vrstva systému je súbor tried, príbuzných vzhľadom na štruktúru aplikácie.

Doménová vrstva obsahuje triedy reálneho sveta (real world classes), skutočne existujúce triedy

konkrétnej analyzovanej problémovej domény (oblasti), ktoré napomáhajú pri analýze pochopiť a

popísať jej štruktúru.

Aplikačná alebo prezentačná vrstva obsahuje vstupno-výstupné triedy systému, ako sú

formuláre, obrazovky, filtre, report, listingy a podobne. Postupnosť rozoznáva výstupnú vrstvu, ktorá

umožnuje zobraziť požadované výstupy z aplikácie a vstupnú, ktorá slúži na vstup potrebných

údajov.

Interná alebo mikroprocesná vrstva obsahuje triedy, ktoré zabezpečujú funkčnosť prezentačnej

vrstvy. Logická vrstva umožnuje najmä výpočty a spracovanie informácií, dátová vrtsva zabezpečuje

uchovanie údajov pomocou perzistentných tried a tried manipulujúcich s dostupnou bázou dát (aj v

relačnej podobe) a komunikujúcich s jej systémom riadenia.

- 12 -

Pohľad na systém budeme chápať v tejto metóde ako konkrétne zobrazenie modelu (forma),

alebo jeho diagramu v zodpovedajúcej minimálnej podrobnosti formy a popisu.

Konceptuálny pohľad je zobrazenie základných prvkov a ich vzťahov bez orientácie, prípadnej

kardinality a druhy vzťahu (asociácia, agregácia, šecializácia a podobne), bez atribútov a metód, rolí

a kvalifikátorov. Tento pohľad je vhodný pre analytika ako vstupná forma. Používa sa v etape

konceptualizácie a návrhu, prípadne pre komplexné alebo koncepčné zobrazenie modelu, kde nie je

možné zachytiť všetky vlastnosti.

Logický pohľad obsahuje okrem prvkov a vzťahov aj ich orientáciu a druh, atribúty a metódy.

Tento pohľad je vhodný pre používateľa na overenie analýzy a návrhára ako vstupná forma pre

návrh.

Fyzický pohľad obsahuje okrem prvkov a vzťahov, ich orientácie a druhu, atribútov a metód, aj

role, kvalifikátory, typy atribútov a ich inicializačné hodnoty, návratové typy metód, typy a

inicializačné hodnoty parametrov metód a všetky ostatné prvky, potrebné pre implementáciu. Preto

je tento pohľad vhodný ako výstupná forma návrhu pre implementátora ako najúplnejší pohľad.

Etapa postupnosti Využívaný model

Používaný pohľad Spracovávaná

vrstva

Konceptualizácia Konceptuálny Konceptuálny

(Logický)

Doménová

Analýza Objektový

Dynamický

Funkčný

Konceptuálny

Logický

(Fyzický)

Doménová

Aplikačná

(Mikroprocesná)

Návrh Objektový

Dynamický

Funkčný

Logický

Fyzický

Doménová

Aplikačná

Mikroprocesná

Tab. 2 Tabuľka využitia modelov, vrstiev a pohľadov

Predchádzajúca tabuľka 2 zachytáva použitie jednotlivých modelov, vrstiev a pohľadov v

etapách. Je z nej zrejmé previazanie modelov, pohľadov a vrstiev na jednotlivé etapy ako aj

najčastejšia forma (pohľad) zobrazenej vrstvy: pre doménovú je to konceptuálny a logický pohľad,

pre aplikačnú a mikroprocesnú najmä logický a fyzický. Alternatívy v zátvorkách je možné použiť v

konkrétnej etape. V ďalších explicitných iteráciách už slúži dosiahnutá forma (pohľad) modelu ako

- 13 -

základ, ktorý sa prehlbuje smerom k podrobnejšiemu, môže byť však pre konkrétny nový inkrement

alebo pre komplexné zobrazenie rozsiahleho modelu použitý aj jednoduchší pohľad.

Konceptualizácia

Zber požiadaviek, identifikácia používateľov a inicializačných udalostí, vytvorenie

katalógov

Začíname s identifikáciou používateľov, pretože musia byť známi, ako aj požiadavkami na

systém, jeho službami, ktoré používateľ očakáva, pretože ich vie identifikovať. Samozrejme, je ich

potrebné, v interakcii s ním, presne definovať a vyradiť redundantné, vágne a nadbytočné podľa

stanovenej priority. Je to vhodnejšie, ako začať s tvorbou tried v objektovom modeli.

V súvislosti so zberom požiadaviek (User Requirement Management) a s modelovaním

odpovedajúcich služieb systému (Use Case Modelling) sa používa aj pojem modelovania

ekonomických procesov a služieb (Business Proces Modelling alebo BPM). Cieľom podnikania je tu

poskytnúť službu zákazníkovi, kde aj vývoj, alebo výroba produktu je službou. V BPM sa stretávame

s dvoma metódami inžinierstva ekonomických procesov (Business engineering):

1. Spätné (Reverse engineering) - porozumenie existujúcemu podnikaniu, vytvorením

modelu, prípadne aj s potrebnou reštrukturalizáciu (potom reinžinierstvo).

2. Priame alebo dopredné (Forward engineering) - návrh nových procesov podnikania.

Zadávateľ alebo používateľ IS môže reštrukturalizovať BP, vzhľadom na informačné toky,

spracovanie a uchovanie údajov v očakávanom IS.

Ak sa model podnikania prekrýva s modelom IS, ktorý podporuje interné procesy, potom je

vhodné OO technológiou fixovať poznatky (know how) v zákazníckych triedach (business classes),

ktoré patria do logickej vrstvy. Na zaznamenanie informácií z konzultácií so zadávateľom projektu a

používateľom, zo štúdia ich dokumentov, smerníc a príručiek je možné sa inšpirovať metodológiou

SSADM, kde jedným z výstupov je súbor katalógov, vytvorených v etape analýzy:

Konkrétne výsledky tejto etapy sa vytvárajú v nasledovných krokoch:

1. vytvorenie zoznamu požiadaviek používateľa (ID, dátum zadania, priorita, zložitosť,

názov, charakteristika, dátum spustenia, odvolávky na komponenty a ostatné modely a

diagramy (modely číslované podľa služby/požiadavky, bez čísla pre celý systém, diagramy

- 14 -

číslované podľa poradia), prípadne explicitné vyjadrenie, že model nie je pre danú službu

potrebný),

Príklad štruktúry a obsahu katalógu:

ID požiadavky: POZ001

Názov: Zápis incidentu

Dátum zadania: 1.6.1999

Priorita: A

Stupeň zložitosti: -

Charakteristika: zápis incidentu do MS SQL DB hneď pri jeho nahlásení

Dátum spustenia: 1.2.2000

Objektový model: OM01.DT01 (objektový model 1. služby, diagram tried č.1)

Dynamický model: DM01.SD01, DM01.SD02, DM01.VD01

Funkčný model: -

...

ID: POZ012

Názov: Automatický výber experta

Dátum zadania: 21.6.1999

Priorita: B

Stupeň zložitosti: problém vytvorenia pravidlového systému a previazanie s dátovou

vrstvou MS SQL a aplikačnou ASP

Charakteristika: vyhľadanie experta podľa pravidiel

Dátum spustenia: 1.5.2000

...

2. vytvorenie zoznamu používateľov systému (ID, meno, trieda, atribúty, charakteristika),

Príklad štruktúry a obsahu katalógu:

ID používateľa: POU001

Názov: ASCSlužba

Typ: Actor

Charakteristika: Služba funguje 24 hodín denne, strieda sa po týždni

- 15 -

Atribúty: ID, meno, telefón, e-mail

ID: POU002

Názov: Klient

Typ: Actor

Charakteristika: Klient obsahuje triedy Pracovisko a Kontaktna osoba

Atribúty: ID, názov, adresa, telefón,fax, e-mail

…

3. vytvorenie zoznamu udalostí vstupujúcich do systému (ID, názov, typ (zasielajúca

udalosť, vyvolávajúca metódu, zmenu, lokálna akcia, vytvárajúca novú inštanciu, rušiaca

inštanciu, ukončujúca úlohu, návratová, signál, časová udalosť), parametre,

charakteristika, zdroj, cieľ), každú takúto udalosť by mala spracovávať konkrétna služba a

jej zdrojom by mal byť konkrétny používateľ alebo používatelia,

Príklad štruktúry a obsahu katalógu:

ID udalosti: UDA001

Názov: Nový incident

Typ: vyvoláva celú službu

Charakteristika: Klient oznamuje problém službe a tá ho zapíše ako incident

vyvolanie dialógu na zápis incidentu, kontrola vstupných údajov, zápis do DB

Parametre: ID kllienat, ID služby, OS, verzia, produkt, verzia, problém

Zdroj: POU001

Cieľ: POZ001

…

Vytvorenie konceptuálneho diagramu

V konceptuálnom diagrame sa prekryjú požiadavky z katalógu službami systému,

ktoré poskytuje svojim používateľom. Popri grafickom zápise, kde sa získa prehľad

o jednotlivých elementoch ale najmä o ich vzťahoch, treba dbať aj o dôslednú dokumentáciu.

- 16 -

Môže prísť k zlúčeniu jednoduchých, navzájom súvisiacich požiadaviek do spoločnej

služby, alebo rozdeleniu zložitej požiadavky do niekoľkých samostatných služieb a podobne,

diagram zobrazí aj vzťahy medzi používateľmi a službami podľa inicializačných udalostí.

Na záver je možné doplniť jednotlivé zoznamy a zosúladiť ich s konceptuálnym

diagramom. Pri zložitejšom systéme sa vytvárajú podskupiny katalógov a diagramov.

Vytvorenie modelov pre jednotlivé služby ako analýza

Pri každej službe (Use Case) je vhodné uvažovať o vytvorení diagramov, ktoré pod-

robnejšie vysvetľujú samotnú službu. V tejto etape sa zapíšu postupy, riešenia a návrhy

používateľa a/alebo zadávateľa systému, ktorý vychádza zo svojich predstáv a skúseností, ako

danú službu vykonávajú, alebo čím ju zabezpečujú. Pri zápise sa niektoré nezrovnalosti

okamžite konzultujú, zatiaľ to však nie je fáza návrhu, preto nie je potrebná optimalizácia, ale

získanie čo možno najviac poznatkov. Diagram sa stáva súčasťou modelu konkrétnej služby.

Konceptuálny diagram ako poddiagram zjemňuje a dovysvetlí službu, ktorá je príliš

globálna a všeobecná. Je možné, že v záujme prehľadnosti sú služby zastúpené až

diagramom nižšej úrovne. Príklad: konceptuálny diagram pre celý IS by obsahoval hlavné

podsystémy ako služby, tieto podsystémy by boli rozpracované do skupín úloh ako

služieb na ďalšej úrovni, na ďalšej úrovni by sa skupiny úloh rozvinuli do konceptuálnych

diagramov, kde by boli služby chápané ako úlohy. Na ďalšej úrovni by úlohy boli

dovysvetľované sekvenčnými a objektovými diagramami a podobne. Takýto

konceptuálny diagram patrí ešte do konceptuálneho modelu služby. Ak je v ňom

naznačený postup, ako budú jednotlivé služby spolupracovať a využívať ostatné, potom

patrí do funkčného modelu služby. V tomto prípade je vhodnejší aj doslovný preklad:

diagram prípadov použitia.

Sekvenčný diagram znázorňuje reakcie služby na všetky významné udalosti ako

poddiagram, vysvetľuje realizáciu služby pomocou dynamickej interakcie objektov; tu už

pravdepodobne nestačia triedy typu používateľ (Actor) z konceptuálneho diagramu, ale

objavujú sa aj nové objekty tried: to je aj cieľom vytvorenia dynamického typu diagramu

v tejto etape. Postup spracovania úlohy v službe je znázornený interakciami medzi

- 17 -

objektmi, označený najčastejšie udalosťami, ktoré vzniknú a ktoré si objekty posielajú, a

operáciami, ktoré prijímajúci objekt bude musieť vykonať. Sú to najčastejšie jeho budúce

metódy. Pri komplexnom postupe treba zvážiť všetky inicializačné udalosti z katalógu

a podľa nich vytvoriť jednotlivé scenáre (diagramy) správania sa služby. Mnohé udalosti

(aj keď od rôznych používateľov) vyvolávajú rovnaké interakcie v službe, preto nie je

potrebné pre každú udalosť vytvoriť jeden diagram. Často ani služba nie je natoľko bohatá

na objekty a ich interakcie, niekedy však potrebuje rozpísanie na podslužby

v konceptuálnom diagrame a následne vytvorenie sekvenčných diagramov. Sekvenčný

diagram spolu s komunikačným patria do dynamického modelu. Špeciálne prípady,

obsahujúce prvky vetvenia a cykly, popisujúce striktne určitý algoritmus, je vhodnejšie

zaradiť do funkčného modelu služby.

Tieto scenáre interakcií medzi objektami môže zaznamenať aj komunikačný diagram. Je

len iným vyjadrením sekvenčného diagramu. Stačí si zvoliť vhodnejšiu formu, nie je

nutné použiť obidva, iba v prípade, že prvý zaznamenáva udalosti a druhý vyvolané

správy s metódami objektov. Udalosťou je Poslanie objednávky. Správa, obsahujúca

žiadosť o vyvolanie metódy PrijmiObjednávku(), prekrýva a nahrádza udalosť. Pri oboch

interakčných diagramoch je potrebné rozlišovať optimistický scenár, kde sa zameriava len

na základ skúmanej služby a nie riešenia možných problémov, bežný scenár, ktorým je

najčastejšia realizácia služby v praxi a pesimistický scenár, v ktorom sú zaznamenané

všetky možnosti a udalosti aj pri kritických a chybových stavoch. Je prirodzené začať

optimistickým, alebo bežným scenárom, ale je vhodné nakoniec vytvoriť a doplniť všetky

tri: prvé dva, jednoduchšie, pre porozumenie a zmeny v návrhu, posledný, najzložitejší,

pre neskoršie doplnenie v návrhu a implementáciu. Ďalšou možnosťou je vytvoriť najprv

scenár interakcií medzi objektami reálneho sveta, tak ako v skutočnosti v skúmanej

doméne prebieha. Potom ho doplniť o aplikačné (vstupo-výstupné) objekty IS a nakoniec

vytvoriť najpodrobnejší, v ktorom už budú vystupovať aj interné, skryté (mikroprocesné)

objekty aplikácie. Ak však zadávateľ projektu nemá podklady a predstavu o aplikačnej

a mikroprocesnej vrstve (vzhľad formulárov, presný postup riešenia), ponechávame túto

činnosť až na návrh, kde organicky patrí.

Diagram objektov a tried je vhodný najmä na exaktné definovanie tried a statických

vzťahov medzi nimi, znázornenie DB, na definovanie štruktúry služby, ktorá je potrebná

na zabezpečenie jej fungovania. Požívateľ tu oboznamuje analytika s používanými

- 18 -

formulármi a tabuľkami, s pôvodným systémom a podobne. Tu je možné viesť riadené

interview, v ktorom začíname od doménovej vrstvy s existujúcimi prvkami reálneho sveta

(klient, počítač, pokladňa, účet), ktoré sa týkajú samotnej služby a je ich ľahké

identifikovať a pomáhať si touto štruktúrou v ďalšom kroku, v ktorom používateľ definuje

potrebné V/V triedy aplikačnej vrstvy (formuláre, obrazovky, reporty, listingy a podobne),

a nakoniec kompletizuje doplnením mikroprocesnej vrstvy: riadiacich, výpočtových

(špeciálnych, ekonomických), dátových (stálych aj dočasných) prvkov (súbory, zoznamy,

tabuľky, denníky a knihy a podobne) ako interných objektov. Tieto informácie môžeme

doplniť existujúcimi prvkami pôvodného IS a prostredia, ktoré sa nenachádzajú

v požiadavkách. Tento postup bude ešte výraznejší vo fáze návrhu, kde sa už buduje

systém nezávisle a systematicky. Pri veľkej mohutnosti diagramov (napr. viac ako 10

prvkov - tried) je vhodné vytvoriť hierarchickú sieť poddiagramov, kde hlavný diagram

obsahuje len komponenty a tie sa v poddiagramoch rozvíjajú do ďalších komponentov

alebo tried na najnižšej úrovni. Takýmto spôsobom je možné vybudovať objektový model

služby.

Stavový diagram je vhodný na zápis množiny stavov, v ktorých sa môže služba, prípadne

významná dynamická trieda služby nachádzať. Slúži na znázornenie prechodu stavovým

priestorom v závislosti od udalostí. Dopĺňa dynamický model.

Procesný diagram znázorňuje ako je možné jednotlivé požiadavky na služby riešiť vo

forme algoritmu, predpísanej postupnosti operácií. Môžu sa vytvoriť aj pre špeciálne

algoritmy niektorých metód v triedach pre danú oblasť, ktoré používateľ pozná a požaduje

ich presné splnenie (generovanie ID, čísiel účtov a podobne). Niekedy je vhodnejšie

použiť na tento účel Jacksonov štruktúrovaný diagram, v ktorom v stromovej štruktúre

zapíšeme algoritmus metódy bežnými prostriedkami štruktúrovaného prístupu (sekvencia,

cyklus, vetvenie), prípadne použijeme zápis v programovacom jazyku ako skript alebo

návrh. Vhodný je napríklad Visual Basic pre ľahkú čitateľnosť, ak sa nepoužijú špeciálne

prvky, prípadne nie je nutné použiť už v tejto fáze špeciálne prvky konkrétneho jazyka

implementácie. Napríklad jazyk C/C++ nie je všetkým programátorom, pracujúcim

napríklad v Transact SQL / PL SQL, Visual Basic a podobne, pochopiteľný a nie je

vhodné ho použiť, ak nebol zvolený ako predpokladaný jazyk implementácie.

- 19 -

Pri tvorbe poddiagramov pre jednotlivé modely služby je najvhodnejšie postupovať

nasledovne:

1. Pe príliš komplexnú službu vytvoriť konceptuálny poddiagram s podslužbami a ich

vzťahmi.

2. Zaznamenať jednotlivé scenáre služby podľa inicializačných udalostí v interaktívnom

modeli, začať najpravdepodobnejším, bežným scenárom, prípadne optimistickým

a prejsť k pesimistickému, v ktorom už vystupujú aj všetky ošetrenia problémov.

Jednotlivé objekty v scenároch ponechávať v rovnakej pozícii, vytvárať tak vrstvy

rôznych scenárov nad identickou objektovou štruktúrou. Ak existuje diagram tried

a objektov, tak používať komunikačný diagram na zaznamenanie scenára služby nad

ním a nie sekvenčný diagram, pokiaľ je to možné (dovoľuje to používaný SAPP, napr.

MS VISIO) a prehľadné. Ak to nie je možné, alebo vhodné, potom sa dá

prekonvertovať na záver sekvenčný diagram na komunikačný, objekty umiestniť aj so

zreteľom na ich ďalšiu funkciu v objektovom diagrame, je vhodné vytvoriť jeden

scenár ako prenos udalostí medzi objektami a druhý ako správy, v ktorých sa

vyskytujú volania metód prijímajúceho objektu od vysielajuceho objektu.

3. Ak to klient vyžaduje, je možné vytvoriť aj diagramy vstupno-výstupných formulárov,

kde sa ujasnia jeho predstavy a z ktorých vyplynú aj potrebné prvky (objekty, metódy,

udalosti), informácie a zmeny do jednotlivých modelov, vstupno výstupné formuláre

už obsahujú mikroprocesné objekty, alebo aspoň vyžadujú ich existenciu

a komunikáciu s nimi (konverzné, výpočtové, vyhľadávacie a db služby).

4. Diagram tried vytvárame na základe objektovej štruktúry z interaktívnych diagramov

ako jeho ďalšiu vrstvu, kde si objekty zachovajú pôvodnú pozíciu, jednotlivé objekty

obohatiť o metódy z interakcií-správ a potrebných atribútov.

5. Preveriť, či nadobúda služba alebo trieda počas svojej existencie konkrétnu sériu

stavov a zaznamenať ich v dynamickom modeli: v stavovom diagrame.

6. Ak je potrebné pre službu zaznamenať riešenie požiadavky od používateľa ako

postupnosť krokov, potom zaznamenať tento algoritmus vo funkčnom modeli služby:

v procesnom diagrame, alebo v JSD, prípadne v skriptovacom jazyku (podľa dohody

väčšinou v tomto kroku postačuje Java alebo VB skript, zložitejší C/C++ jazyk,

bohatší o smerníkovu aritmetiku a škálu operátorov nie je potrebný), možné je použiť

aj interaktívne diagramy a diagram prípadov použitia (konceptuálny diagram).

- 20 -

7. Pre jednotlivé služby je potrebné vytvoriť scenáre testovania a sady vstupných údajov

s ich výstupnými ekvivalentami. Podľa pravidiel eXtreme Programming v [Collins

01], [Beck 99], [Fowler 01a] a podľa [Booch 96] ak sa to robí už v analýze, obe strany

si lepšie uvedomia obsah a zmysel (služby) a presnejšie stanovia jej štruktúru a

funkcie.

8. V analýze zapisujeme všetky informácie od zadávateľa projektu a vytvárame tak

doménovú a časť aplikačnej vrstvy modelov. Ak sú informácie príliš podrobné, je

možné vytvoriť čiastočne aj mikroprocesnú vrstvu. Predmetom návrhu bude korigovať

analýzu a vytvoriť alebo doplniť a aktualizovať jednotlivé vrstvy až po internú vrstvu

cielene a systematicky.

Pravidlá konzistencie modelov pre analýzu a návrh

Konzistenciu postupnosti a jej modelov budeme chápať ako prepojenosť jednotlivých

krokov a modelov v činnostiach, prvkoch a štruktúrach na zabezpečenie všetkých potrebných

zmien pri aktualizácii vo všetkých činnostiach a modeloch.

Optimálna objektová štruktúra IS bude taká štruktúra, ktorá pri minimálnom počte

prvkov a vzťahov (bližšie v kapitole Optimalizácia objektovej štruktúry) zabezpečí splnenie

požiadaviek používateľa a ďalšie štandardné vlastnosti softvéru (spoľahlivosť, integrita,

efektívnosť a podobne podľa [Russev MMb], [Bieliko MM]).

Optimálna postupnosť vývoja IS bude taká postupnosť, ktorá dosiahne optimálnu

objektovú štruktúru IS pri minimálnych časových, ľudských, finančných a ďalších nákladoch.

Teda taká, ktorá bude minimalizovať počet krokov a činností, stratu informácií,

minimalizovať nadbytočné, vágne a redundantné prvky a podobne.

Na dodržanie konzistencie modelov je vhodné dodržiavať nasledovné pravidlá:

1. pre každú službu vytvoriť jednotlivé modely, pokiaľ je to možné a vhodné,

2. vytvoriť modely aj pre celý systém, pokiaľ je to potrebné, v etape návrhu preveriť

a vyradiť prípadnú redundanciu rovnakých prvkov v rôznych službách,

3. všetky metódy, použité v interakciách medzi objektami, musí prijímajúca trieda

implementovať a vysielajúca umiestniť jej volanie do kódu svojich metód,

- 21 -

4. všetky objekty, vyskytujúce sa priamo, alebo sprostredkovane v konceptuálnom

(napríklad používatelia), stavovom, procesnom, alebo interaktívnom diagrame sa musia

vyskytovať aj v objektovom diagrame,

5. štruktúra systému, premietnutá do služieb bude mať svoj odraz aj v architektúre systému,

popísanom na záver v diagrame komponentov a rozmiestnenia,

6. každú operáciu zo stavového diagramu musí zastúpiť konkrétna metóda konkrétnej triedy

v objektovom modeli, ak diagram definuje stavový priestor jednej triedy a nie celej služby

s viacerými triedami, potom je naviazanie a konzistencia jednoduchšia, všetky akcie

a aktivity v stavoch pokrýva jedna trieda svojimi metódami, ak nebolo určené, že ju

vykonáva metóda inej triedy,

7. všetky neelementárne operácie z funkčného modelu musí vykonať konkrétna metóda

konkrétnej triedy v objektovom modeli,

8. triedy budú obsahovať všetky potrebné atribúty pre zabezpečenie vhodnej implementácie

metód a naopak,

9. zmeny v obsahu (pridanie, zmena, vyradenie prvku) sa musia premietnuť do všetkých

modelov, ako aj zmeny v zvýšení úrovne pohľadu (konceptuálny->logický->fyzický),

alebo doplnením vrstvy (doménová->aplikačná->mikroprocesná).

Podobné sady pravidiel obsahuje aj [Coad 91], [Rumbaugh 91], [Booch 94], [Booch 96],

[Šešera 94] a ďalší.

Všeobecné pravidlá pre analýzu a návrh

Na záver načrtnutého postupu analýzy je možné vyjadriť všeobecné pravidlá, ktoré sú

platné nielen pre analýzu, ale aj pre návrh:

1. vytváranie a dopĺňanie modelov ako aj sledovanie konzistencie je nutné vykonávať

neustále nielen v analýze ale aj v návrhu,

2. vytváranie modelov pre jednotlivé služby samostatne je možné vykonávať v paralelných

prúdoch aj v tímovej spolupráci, kedy si rozpracovanie služieb rozoberú jednotliví

kolegovia alebo skupiny, pri jemných a malých službách je možne vytvoriť komplexný

objektový model pre viacero služieb,

- 22 -

3. pri konceptualizácii a analýze asistuje zadávateľ projektu, budúci používateľ, doménový

expert a podobne, jednotlivé diagramy sú vynútené potrebou zaznamenať ich informácie

požiadavky a popis, v návrhu už jednotlivé diagramy slúžia na návrh optimálnej

objektovej štruktúry, preto obsah môže byť ponechaný, ale aj pozmenený,

4. v analýze aj v návrhu sa používajú podľa potreby prvotný, komplexný konceptuálny

pohľad (objekty, udalosti a vzťahy, bez presného popisu atribútov, metód, parametrov a

podobne), logický pohľad (udalosti nahradzujú správy a metódy, vzťahy sú spresňované

do asociácie, dedenia a agregácie, pridávajú sa atribúty a parametre) a nakoniec

najpodrobnejši fyzický pohľad (kardinalita vzťahov, role tried, kvalifikátory, typy

a rozmery atribútov, parametrov a návratových hodnôt).

Návrh výstupov IS, odvodenie aplikačnej vrstvy objektov

V etape návrhu sa začína od výsledkov služieb, ktoré klient očakáva a potrebuje, nie od

nejasnej predstavy o vnútornej štruktúre a jej správaní sa. Navrhované výstupy služieb sa tvoria na

základe požadovaných výsledkov akýmkoľvek editorom formulárov a následne sa prepisujú do

dynamického, objektového a funkčného modelu podľa pravidiel konzistencie.

Neskôr sa diagramy obohatia aj o interné triedy, ako je aj db tabuľka/y, z ktorej záznamy

vyberáme, čím sa zviditeľní jej štruktúra, jej atribúty - stĺpce a jej metódy.

Pri viacerých, jednoduchých výstupoch sa môže vytvoriť z každého výstupu objekt, kde

atribúty sú jednotlivé položky výstupu, prípadne viacero diagramov pre každý výstup samostatne

pri väčšej zložitosti.

Tieto diagramy aplikačných objektov je potrebné optimalizovať vzhľadom na poznanie

všetkých výstupov zadaných klientom, aby nevznikali redundancie a výstupy boli dostatočne

samostatné a použiteľné z viacerých služieb. Ak používateľ neidentifikoval výstupy, nie je

problém navrhnúť ich odvodením z charakteristiky služby a vytvoriť všetky potrebné obrazovky,

formuláre, reporty a listingy. Tu je vhodný logický pohľad (triedy, atribúty a operácie tried,

vzťahy špecifikovať ako agregáciu, dedenie a asociáciu, upresniť kardinalitu), konceptuálny (len

identifikácia tried so vzťahmi ešte presne nešpecifikovanými) je príliš jednoduchý a

nedostatočný, je vhodný pre viacvrstvový model a model aplikačných, softvérových a

hardvérových komponentov.

- 23 -

Návrh DB vrstvy podľa výstupov

Na zabezpečenie výstupov je potrebné mať k dispozícii dáta vo vhodnej štruktúre, preto v

tejto fáze je nutné prepojiť požiadavky výstupov s dátovou vrstvou tvorenou perzistentnými

triedami. Zjednodušene povedané, ide o transformáciu štruktúry V/V objektov aplikačnej vrstvy

aj do objektov dátovej vrstvy.

V tomto kroku je vhodné prejsť od logického k fyzickému pohľadu novopridaných, ako aj

existujúcich tried. Znamená to konkretizovať dátový typ atribútov (char, int, boolean, float/real,

double, string/varchar a podobne) a typ návratovej hodnoty metód. Dátovým typom je aj typ

triedy. Je nutné konkretizovať zoznam formálnych parametrov metód ako aj ich typ, prípadne

inicializačnú hodnotu. Tento krok však možno ponechať až na fázu návrhu, kde bude po revízii

diagramov jasné, či konkrétna trieda zostáva, prípadne zostáva v pôvodnom tvare.

Návrh vstupov, ktoré vyžaduje dátová vrstva, doplnenie aplikačnej vrstvy

V tomto kroku ide o vytvorenie odpovedajúcich vstupných formulárov, ktoré naplnia

konkrétnu DB. Transformovaním štruktúry (najmä atribútov) perzistentných objektov DB do

objektov vstupných formulárov s prihliadnutím k už definovaným výstupom sa dá vhodne

doplniť aplikačná vrstva bez vytvorenia nadbytočných vstupov. Vzniknú tak aj úplné vstupno-

výstupné fomruláre obrazoviek.

Vytvorenie prototypu IS a používateľskej príručky

V tomto kroku sa vytvorí prototyp IS a prvá verzia používateľskej príručky, v ktorej je

koncepcia celého IS, podrobná charakteristika, predpokladané technické, programové,

personálne a iné požiadavky, jeho ovládanie, varianty V/V formulárov, použité v simulácii práce

celého systému. Všetko sa píše v duchu ukončeného produktu a zadávateľ, doménoví experti aj

koncový používateľ ju tak čítajú. Klient tak môže oboznámiť svojich pracovníkov s novými

zmenami, vyškoliť ich na nové prostredie a vypočuť si ich námety a pripomienky. Môže

zamýšľané inovácie konzultovať a predostrieť aj partnerom, prezentovať pred konkurenciou a

- 24 -

všetky výhrady a doplnenia adresovať analytikom. Ak zadávateľ nie je spokojný, prípadne

požaduje zmenu, potom je nutný návrat na predošlé kroky, doplnenie a zmeny a opätovné

hodnotenie. Používateľ si zvyká a hodnotí nový produkt, hoci návrh logickej vrstvy a

implementácia ani nezačala a neboli investované zbytočné peniaze a čas. Často sa jeho bežná

averzia k novému produktu zmení pri jeho spoluúčasti na aktívnu spoluprácu a pozitívnejšie

prijatie.

Prototyp IS dopĺňajú presné scenáre testovania a sady vstupných údajov a ich výstupných

ekvivalentov. Okrem upresnenia funkcionality služby napomáhajú aj pri korekcii ďalších

návrhov. Tieto informácie budú veľmi cenné aj pre etapu testovania, ladenia a implementácie,

kedy preklenú bariéru medzi používateľmi a analytikmi, ktorí vytvorili tieto scenáre a testovacie

sady v analýze, medzi návrhármi, ktorí ich dopĺňali v návrhu, programátormi a pracovníkmi

testovacích oddelení, ktorí ich overovali v etape implementácie, testovania a ladenia. Pre

všetkých bývajú často aj tieto údaje veľmi dobrým základom na dorozumievanie sa a

porozumenie zamýšľanej funkcionalite.

Návrh logickej vrstvy objektov, ktoré zabezpečia výstupy z DB

V tejto fáze sa prechádza k systematickej identifikácii objektov logickej vrstvy. Sú to

rôzne výpočtové, riadiace a transformačné triedy, zaoberajúce sa spracovaním údajov,

numerickými metódami a podobne. Tieto triedy zabezpečujú požiadavky výstupov z aplikačnej

vrstvy na dáta. Tu je možné použiť aj implementačné vzory podľa [Meyers 96], [Meyers 98] a

[Murray 93]. Ako príklad môžu slúžiť vzory ako zásobníky, kontajnery, iterátory, inteligenté

smerníky, COM objekty a podobne. Dopĺňajú sa objektový, dynamický a funkčný model.

Doplnenie logickej vrstvy, ktorá zabezpečí naplnenie DB zo vstupov

Po vytvorení logickej vrstvy pre zabezpečenie naplnenia výstupov je možné navrhnúť

podobným spôsobom aj časť vrstvy pre smer od vstupov do dátovej vrstvy na transformáciu

vstupných údajov a uloženie do DB.

Doplnenie návrhu DB a IS o pôvodné prvky a jej optimalizácia

- 25 -

Nevyužité dáta a štruktúry sa ponechávajú pre prípad neskoršieho využitia a

prehľadávania (datamining a datawarehousing), je však vhodné udržiavať ich ako samostatné

moduly, v prípade nutného prepojenia a označiť ich dohodnutou formou. Podobne treba vytvoriť

zabezpečenie v logickej a aplikačnej vrstve. Tieto možnosti je vhodné ponechať skryté pred

bežným používateľom, ako voliteľné v nastavení a taktiež zabezpežiť aby nezasahovali do

spracovania a nespomaľovali ho a zaradiť ich do samostatných modulov, vyvolateľných na

požiadanie.

V ďalšom kroku môžeme uvažovať o vzťahu agregácie a dedenia, zjemňovať klasické

asociácie (upresňovať kardinalitu, roly tried, kvalifikátory, pomenovať vzťahy).

Doplnením atribútov a metód dokončíme prechod od konceptuálneho k logickému

návrhu.

V ďalšom kroku navrhneme typ atribútov (int, long, float, double, char, String a

podobne), parametre metód, typy parametrov, inicializačné hodnoty, návratové typy metód, ak

ich chápeme ako funkcie, a nie ako operácie. Návrh objektového modelu sa mohol začať už pri

zápise fyzického pohľadu na interné triedy v závere analýzy.

Návrh objektového modelu môže byť vedený revíziou a optimalizáciou (vyraďovanie

nevhodných tried a ich členov a zaraďovanie výkonnejších, vzhľadom na presnosť, nároky na

priestor a čas vykonávania) pôvodného modelu z analýzy alebo vytvorením úplne nového

modelu, v ktorom len vychádzame z poznatkov analýzy.

Pravidlá normalizácie relačnej BD

V nasledujúcej kapitole uvádzame základnu definíciu relácie, operácie s ňou a pravidlá

normalizácie (aj s príkladmi, použitými aj v iných kapitolách), pretože je možné aplikovať niektoré

uvedené vlastnosti a postup aj na objektový model.

Pri relačne orientovaných bázach dát, ktoré sú najrozšírenejšie a objektové systémy ich zatiaľ

najviac využívajú (na ukladanie perzistentných objektov) sa optimalizácia celkovej štruktúry

označuje ako normalizácia a prechádza jednotlivými normálnymi normami. Reláciou sa tu chápe

fyzicky databázová tabuľka (alebo matica) s n stĺpcami a m riadkami. Jednotlivé stĺpce zastupujú

atribúty, alebo entity v pôvodnej relácii a v riadkoch sú zaznamenané hodnoty konkrétnych výskytov

alebo objektov. Je zaujímavé, že tieto pomenovania sú vhodné aj pre objektové využitie. K presnejšej

matematickej formulácii relácie môže poslúžiť nasledovná definícia relácie, ktorú používa aj

[Scheber 88], odvolávajúci sa na [Codd 70]:

- 26 -

Nech je daný systém {Di | 1 ≤ i ≤ n} neprázdnych množín (domén). Potom podmnožinu

karteziánskeho súčinu R D1 x D2 x … x Dn nazývame reláciou stupňa n (n-árnou reláciou) nad D1,

D2, …, Dn. Prvky R sú usporiadané n-tice < d1, d2, …, dn > také, že di Di pre 1 ≤ i ≤ n.

Relácia je teda spojenie konkrétnych entít. Objektový prístup uznáva ako predchodcu

objektov entity, nie však relácie, hoci spolu súvisia a mnohé sa dá využiť. Na prácu s reláciami je

prepracovaný kalkul relačnej, ale aj množinovej algebry. Na prácu so štruktúrou relácie sa používa

kartézsky súčin (R x S = { rs | r R s S }), delenie (inverzná operácia ku kartézskemu súčinu),

spojenie (takzvaný join podľa spoločných reštrikčných atribútov A a B relácií R a S do relácie T

A x B = R[ATB]S = { rs | r R s S (r.A, s.B) T) a projekcie. Na prácu s hodnotami-obsahom

entít sa využíva reštrikcia (podľa hodnôt k v reštrikčnom atribúte A pomocou binárneho

porovnávacieho atribútu kde R[A k] = { r | r R (r.A k) }) ako aj množinové operácie

zjednotenia, prieniku a relatívneho komplementu (rozdielu). Dôležitá pre normalizáciu je projekcia –

definícia projekcie je nasledovná:

Nech R je relácia a A jej atribút, potom projekciou R do A (označovaná ako R[A]) sa nazýva:

R[A] = { r.A | r R }

Pre samotnú normalizáciu sú dôležité najmä jej prvé tri kroky, v ktorých sa literatúra príliš

neodlišuje. Štvrtá, prípadne piata normálna forma nie je uspokojivo popísaná [Yourdon 91] [Scheber

88] a rozchádzajú sa jej definície, prípadne nie je zabezpečená reverzibilnosť a hrozí strata

informácií.

Prvá normálna forma predpokladá, že relácia obsahuje len jednoduché atribúty, nie zložené, ktoré sú

reláciami.

Ak napríklad relácia Zamestnanec obsahuje atribút MenoZamestnanca a v ňom je uložené priezvisko,

meno, prípadne aj titul, tak môžu vznikať nasledovné problémy:

- používateľ môže zadať len priezvisko a ignoruje krstné meno,

- používatelia ukladajú priezvisko a meno, prípadne aj titul v rôznom poradí a dochádza k

nejednoznačnosti a problémom pri vyhľadávaní (nie je známe, či je prvé meno alebo

- 27 -

priezvisko),

- okrem problémov pri vyhľadávaní sa často uloží to isté meno v rôznych podobách a podobne.

Druhá normálna forma je definovaná nasledovne:

Relácia R je v druhej normálnej forme ak je v prvej normálnej forme a ak každý atribút, ktorý nepatrí

k žiadnemu kľúču relácie R, silne funkčne závisí od každého kľúča relácie R.

Atribút B funkčne závisí od A (A -> B), ak platí:

s, r R : s.A = r.A => s.B = r.B

Atribút B silne funkčne závisí od A, ak neexistuje žiadna vlastná podmnožina A’ zloženého atribútu

A taká, že platí A’ -> B .

Kľúč relácie jednoznačne identifikuje každý výskyt, populáciu alebo n-ticu relácie. Je to vybraný

atribút, alebo podmnožina atribútov relácie, kedy žiaden atribút z kľúča nemôže byť vynechaný,

pretože by vznikla redundancia.

Ako príklad môže poslúžiť relácia Hala s informáciami o obsahu jednotlivých hál skladu.

Relácia sklad môže obsahovať nasledovné atribúty: IDHaly, Kapacita, Pobočka, IDTovaru,

NázovTovaru, Množstvo, MernáJednotka, DátumObstarania, Cena, TypTovaru.

Pri napĺňaní odpovedajúcej fyzickej tabuľky jednotlivými výskytmi relácie sa však zistí, že

- atribúty NázovTovaru, MernáJednotka, Cena, TypTovaru sú závislé na atribúte IDTovaru

- atribúty Kapacita, Pobočka sú závislé na IDHaly

- atribúty Množstvo, DátumObstarania, Cena sú závislé na IDHaly a IDTovaru.

Vznikajú tak nasledovné problémy:

- informácie o hale sú k dispozícii až po uložení prvého tovaru do nej, po vybratí tovaru z nej,

ak je teda hala prázdna, dáta znovu neexistujú,

- rovnaké atribúty o hale sa opakujú n x m, atribúty o tovare m krát, kde n je počet výskytov

druhu tovaru a m počet dovezeného množstva v konkrétnom čase a cene; tu vzniká problém

redundancie a spotreby pamäti, ošetrovania chýb, násobných zmien a podobne.

Preto je vhodné rozdeliť reláciu projekciou na tri relácie:

Hala(IDHaly, Kapacita, Pobočka, Mesto, Kraj),

Tovar(IDTovaru, NázovTovaru, MernáJednotka, TypTovaru),

- 28 -

a TovarVHale(IDHaly, IDTovaru, Množstvo, DátumObstarania, Cena).

Podčiarknuté atribúty sú kľúčmi v reláciách a ostatné atribúty sú od nich silne funkčne závislé.

Teraz už je možné uchovať informácie o hale samostatne, nepopulovať ich výskyt podľa počtu

druhov tovaru v hale a ich výskyte v hale a podobne.

Opakujú sa však atribúty Mesto, Kraj, alebo Krajina, Štát a podobne. Tieto atribúty sú tranzitívne

závislé a bolo by vhodné ich oddeliť ďalšou projekciou a udržiavať v samostatnej relácii.

Relácia je v tretej normálnej forme, ak je v druhej normálnej forme a žiaden atribút, ktorý nie je

zložkou niektorého kľúča relácie R, nie je tranzitívne závislý od žiadneho kľúča relácie.

Na odstránenie tranzitívnej závislosti sa môže rozdeliť relácia Hala nasledovne:

Hala(IDHaly, Kapacita),

Pobocka(Pobočka, Mesto, Kraj),

Možno aj MernaJednotka je tranzitívne závislá na TypTovaru, tieto príklady sú ilustratívne a nie

verná kópia existujúceho projektu. V praxi niekedy rozdiel medzi silnou funkčnou závislosťou a

tranzitívnou závislosťou je skrytý v úlohe a zložení kľúča. Normalizácia sa väčšinou vykonáva

intuitívne a často zostáva štruktúra v nenormalizovanej podobe, pre väčšiu rýchlosť výberu dát z

jednej nenormalizovanej tabuľky s opakujúcimi sa hodnotami ako z viacerých normalizovaných.

Pravidlá eliminácie nevhodných tried

Pri perzistentných triedach, ktoré vytvárajú stále inštancie, uchovávané v databáze aj mimo času

vykonávania aplikácie, ale aj pri tranzientných, ktoré sa vytvárajú počas behu programu, možno

vykonať podobnú optimalizáciu štruktúry ako pri normalizácii relačnej bázy dát. V [Blaha 98]

odmietajú koncepciu normalizácie, pretože objektový prístup používa entity a má teda bližšie k

entitnému prístupu ako k relačnému Na druhej strane radia elimináciu nevhodných tried, najmä

redundantných (z podobných (napríklad investície, portfólio, investičné portfólio, mix) vybrať

najvýstižnejšiu), irelevantných (nesúvisiacich priamo s riešením problému a vytvárajúcich len

okolie), vágnych (príliš všeobecných tried s nejasnými hranicami, napríklad softvér, program, modul,

druh, schopnosť a podobne), atribútnych (ďalej neštrukturalizovateľných, ktoré sa dajú zapísať ako

atribúty, alebo operácie), relačných (trieda má byť entitou a nie odrážať vzťah). Toto je popísané už

v [Rumbau 91], ktorá sa považuje za jednu z prvých a najlepších kníh o OMT (Object Modeling

Technique). V [Blaha 98] pokračujú v koncepcii metodológie OMT, hoci jazyk UML sa stal

- 29 -

štandardom a RUP ho dopĺňa ako postupnosť. Aj James Rumbaugh, spoluautor UML, RUP aj OMT,

dokonca napísal predhovor k tejto knihe a hoci predná strana upozorňuje na použite UML v nej,

okrem kritiky popisu multiplicity (“*”) tu nie je nikde významne použitá.

Popisujú aj obojsmerné transformácie objektových štruktúr objektov (napríklad zmeny vzťahov,

ich kardinalít, prenášanie atribútov z podtried do nadtried a podobne).

Z týchto dvadsiatich transformácií sú zaujímavé transformácie T18 až T20, popisujúce vzťah

kvalifikátora a asociačného atribútu, jeho prenos do triedy a použitie asociačnej triedy. Nevedú

však k optimalizácii, dajú sa len použiť ako prostriedok.

Pravidlá revidovanej normalizácie štruktúry tried

Ak sa pri tvorbe objektov použije entitný prístup, na záver je možné považovať ich v jednom

kroku za relácie vlastností (object properties) a aplikovať revidovanú normalizáciu objektov,

najmä ak aj literatúra pripúšťa neoptimálnosť štruktúry a navrhuje dosť intuitívny postup

eliminácie prípadných nevhodných tried. Nasledovné pravidlá síce vychádzajú z princípov

normalizácie štruktúrovaného prístupu, manipulujú však s objektmi, ich atribútmi a metódami.

1. Preverenie dostatočnej a adekvátnej atomárnosti nielen atribútov ale aj metód objektov: ak sa

metóda skladá z častí, ktoré by mohli byť vyvolané samostatne, je prirodzené vykonať

rozdelenie metódy na viac samostatných členských funkcií objektu. Pri atribútoch je proces

tiež jednoznačný: príkladom je MenoZamestnanca ako atribút, ktoré sa rozdeľuje na atribúty

Priezvisko, Meno a Titul, aby nevznikali problémy pri vstupoch, triedení a vyhľadávaní.

Možno však považovať za vhodný aj taký atribút, ktorého typom je štruktúra alebo trieda,

pokiaľ vyhovujú rekurzívne ich jednotlivé položky hľadisku atomárnosti a ostatným

podmienkam na rozdiel od štruktúrovaného prístupu, kde relácia ako atribút nie je vhodná.

2. Vytvorenie explixitného identifikátora - určenie primárneho kľúča z atribútu/atribútov,

jednoznačne určujúceho každú inštanciu triedy, ak nepostačuje systémový identifikátor objektu

(OID).

3. Vyradenie atribútov, ktoré nie sú závislé od primárneho atribútu, alebo sú tranzitívne závislé

cez nekľúčový atribút (2NF a 3NF pri štruktúrovanom prístupe). Metódy sa neviažu na

primárny kľúč, len Get()/Set() metódy na atribút, ktorého hodnotu nastavujú a vypisujú, ostatné

na množinu atribútov, ktoré pri svojom výpočte potrebujú. Ponechanie modelu v

neoptimalizovanom (nenormalizovanom) tvare je možné, je však vhodné túto modifikovanú

- 30 -

objektovú normalizáciu previesť explicitne a nie intuitívne a definovať konkrétne zámery

prípadnej denormalizácie, napríklad vzhľadom na rýchlosť spracovania a podobne, kedy je

vyhľadávanie nad nenormalizovanou triedou inštancií rýchlejšie ako nad niekoľkými

normalizovanými triedami objektov, ktoré vznikli rozdelením pôvodnej triedy, jej projekciou

do nových tried. Metódy prechádzajú do nových tried podľa atribútov s ktorými pracujú,

niekedy je potrebné vytvoriť aj rozdelenie metód (napríklad editácia alebo kontrola množiny

atribútov).

4. Preverenie štruktúry a normalizácie podľa nasledujúcich vzorov 1 - 4.

5. Pridanie chýbajúcich asociačných tried pre vzťahy m:n, ale aj 1:n ak je to potrebné a ak to

nevyplynulo z bodu 3. Tieto triedy obsahujú referencie na obe triedy vo vzťahu, prípadne aj

ostatné atribúty vzťahu, vzťah n:m sa takto doplní, rozdelí a vznikajú dva nové vzťahy n:1 a

1:m.

Pravidlá rozdelenia tried

Zaujímavou možnosťou je sledovať odstránenie redundantných atribútov (a tým aj metód),

alebo redundantných hodnôt atribútov pomocou rozdelenia do tried s konkrétnym typom vzťahov.

Atribúty objektov s opakujúcimi sa hodnotami môžeme rozdeliť podľa využitia na prázdne (Null)

a neprázdne. Pri rozdelení prechádzajú do nových tried aj príslušné metódy. Zapísať jednotlivé

prípady je možné aj v jazyku OCL (Object Constraint Language), ktorý upresňuje a formalizuje

určité podmienky pre objektový model. Je popísaný v [OCL97] a v [UML 99] a využitý v

[Semantics 97] a v [UML 99]. Tento jazyk je vo vývoji a na jeho nevýhody upozorňujú v [Cook

99a] aj v spoločnej práci [Cook 99b], najmä na formálne nepresnosti typov a výrazov.

Zavedenie kľúča key pre triedu withKey a jej všetky inštancie v OCL vyzerá nasledovne:

withKey : class

withKey.allInstances->forAll(p1, p2 | p1 <> p2 implies p1.key <> p2.key

and

withKey.allInstances->forAll(p | p.key <> Empty)

Potom definícia závislého atribútu att v triede Normalized je nasledovná:

- 31 -

Normalized : class

Normalized.allInstances->forAll(p1, p2 | p1.key = p2.key implies p1.att = p2.att)

Existencia atribútu at bez hodnoty v triede notNormalizedWithEmpty sa dá popísať nasledovne:

notNormalizedWithEmpty : class

notNormalized.allInstances->exist(p1, p2 | p1.key <> p2.key and p1.att = p2.att

and p1.att = Empty)

To však nie je negácia závislosti atribútu podľa predošlej definície, tá by vyzerala nasledovne:

notNormalized : class

notNormalized.allInstances->forAll(p1, p2 | p1.key = p2.key and p1.att <> p2.att)

a nemá preto svoj obraz v normalizácii bázy dát, preto je potrebné posúdiť či ide o

abnormalitu a je nutné ju vyradiť podľa vzoru 1. popísaného nižšie. Takýto pohľad na

optimalizáciu databázového modelu sa dá priblížiť spôsobom popisu vzorov podľa [Gamma

95].

Pravidlo č.1 Rozdelenie triedy špecializáciou

Slúži na odstránenie atribútov s redundantnými nulovými hodnotami rozdelením tried na

nadtriedu a podtriedy, do ktorých prechádzajú tieto neefektívne využité atribúty. Vždy treba

rozhodnúť, či použitie tohto vzoru napomôže optimalizácii. Z pôvodnej triedy sa presunú často

nevyužité atribúty do derivovaných podtried, v ktorých už obsahujú hodnoty.

- 32 -

Klucov y Zav isly Nezav isly Zav islyKlucov y

Nenormalizov anaTrieda

*

Atribut

* *

Atribut

nadtrieda

Normalizov anaTrieda<<creates>>

2..n

*

*

specializacia >

podtrieda

*

casto nev y uzity ,prechádza do podtriedy

Obr. 4a Možnosti optimalizácie pre obsahovo opakujúce sa atribúty, prázdne

Doplňujúci popis a príklady:

Vzor je ilustrovaný na príklade publikácie, účtu a dokladu. Ak by boli všetky inštancie

objektami jednej triedy, tak by pri objekte typu kniha triedy publikácia ostávali prázdne

atribúty časopisu (názov, číslo, ročník, ...) a príspevku pre zborník konferencie, pri bežnom

účte atribúty výpovednej lehoty termínovaného a revolvingu a naopak pri termínovanom účte

atribúty povoleného debetu a pokuty, alebo poplatku prípadne úročenia debetu pre

kontokorentný účet. Pri doklade PAM by sa striedali prázdne hodnoty v atribútoch dôvod

výpovede a nástupný plat a funkcia. Podmnožina atribútov by bola prázdna podľa

konkrétneho reštrikčného atribútu, upresňujúceho typ alebo stav objektu - existujú prípady,

kedy sa aj pre stav objektu vytvárajú samostatné triedy v [Gamma 95] je popísaný dokonca

vzor State.

- 33 -

Publikacia

NazovDatumVy daniaVy dav atelISBN

Clanok

RocnikCisloNazov

Zbornik

Nazov Konef erencieDatumMiestoKonania

Kniha Ucebnica Skripta

Ucet

CisloUctuIDVlastnikaUrocenieKredituStav

Bezny

Vy skaPov DebetuUrocenieDebetu

Terminov any

SplatnostUcetPreUrok

Doklad

IDdatumv y stav iladresattexttermin

Vy pov ed

dov od

Prijatie

f unkcianastupny

Obr. 4b Vhodné rozdelenie pre triedy Publikacia, Ucet, Doklad.

Okrem týchto príkladov je takáto špecializácia potrebná aj pri rôznych typoch cenných

papierov, klientov (fyzická, právnická osoba), firiem (a.s., s.r.o., domáca alebo zahraničná

spoločnosť), poistiek (životná, neživotná), tovaru, výrobkov a podobne. Zvolené príklady sú na

prvý pohľad zrejmé, ale pri konkrétnom projekte je vhodné sledovať opakujúci sa výskyt

prázdnych atribútov podľa určitého javu a aplikovať rozdelenie.

Klasický prípad nezávislých atribútov v triede, ktorých hodnoty sa opakujú a ktorý je negáciou

definície závislých atribútov, uvedenou vyššie je nasledovný zápis:

- 34 -

notNormalized2 : class

notNormalized.allInstances->exist(p1, p2 | p1.key = p2.key and p1.att <> p2.att)

Pre tranzitívne závislý atribút s nenulovou hodnotou:

notNormalized3 : class

notNormalized.allInstances->exist(p1, p2 | ( p1.key <> p2.key and p1.att1 = p2.att1 )

implies ( p1.att2 = p2.att2 ) )

kde att1<>key, ale môže byť súčasťou kľúča key: att key.

Odstránenie obsahovo opakujúcich sa neprázdnych atribútov popisuje vzor 2.

Pravidlo č.2 Rozdelenie triedy asociáciou/agregáciou

Slúži na odstránenie atribútov s redundantnými nenulovými hodnotami,

spôsobujúcimi neefektívne spracovanie a anomálie. V takomto prípade treba rozhodnúť, či

použitie tohto vzoru napomôže optimalizácii. Odstránenie sa vykoná rozdelením na triedu

(atribúty s opakujúcou sa hodnotou ostávajú v triede) a jej časť, ako agregovanú, prípadne

asociovanú triedu, obsahujúcu ostatné atribúty, ktorých viacnásobný výskyt donútil k

spomínanému opakovaniu.Kardinalita agregácie/asociácie je 1:n.

- 35 -

Klucov y Zav isly Nezav isly Zav islyKlucov y

Nenormalizov anaTrieda

*

Atribut

* *

Atribut

Agregov ana*

Agregujuca*

*Normalizov anaTrieda<<creates>>

2..n

*

*

*

agregacia >

*

asociacia

OR

casto sa opakuje hodnota,prechádza do agregujucej

Obr. 5 Možnosti optimalizácie pre obsahovo opakujúce sa atribúty, neprázdne

Pôvodnú triedu nahradia agregované triedy s neopakujúcimi sa atribútmi a agregujúca

trieda, ktorá obsahovala opakujúce sa atribúty. Namiesto agregácie sa môže podľa potreby

použiť aj asociácia, najmä ak agregované triedy komunikujú a majú vzťahy aj s inými

triedami alebo ich životný cyklus (vznik a zánik, ako aj jednotlivé stavy) neovplyvňuje

výlučne agregujúca trieda.

Doplňujúci popis a príklady:

Ako príklad môže poslúžiť faktúra alebo objednávka so svojimi položkami na obr. 7a,

kde sa okrem atribútov faktúry (ID, názov, dátum vystavenia, odosielateľ, príjemca) popisujú

aj atribúty jednotlivých položiek (tovar, cena, množstvo, merná jednotka) a preto sa opakujú

pre každú inštanciu číslo faktúry, dátum vystavenia, odosielateľ, príjemca a podobne. Toto je

v relačnom chápaní slabá závislosť od kľúča – čísla faktúry, ak aj je atribút súčasťou kľúča

inštancie. Ak číslo položky obsahuje číslo faktúry, potom ide o tranzitívnu závislosť.

Podobným príkladom na tranzitívnu závislosť je v triede zamestnanec štát zamestnanca

pobočky nadnárodnej spoločnosti na obr. 6, ktorý závisí od mesta a tým až tranzitívne od

adresy (ulice) a ID zamestnanca.

- 36 -

Stat

Mesto

Zamestnanec

IDRC

Ulica

**

*

**

*

Obr. 6 Optimalizácia adresy zamestnanca:

Podobne aj atribúty haly s tovarom na obr.7a sa opakujú vďaka viacerým druhom tovaru

v nej. Ide o tranzitívnu závislosť atribútov merná jednotka, názov tovaru a typ tovaru od ID

tovaru, ak je kľúčom ID haly, alebo tranzitívnu závislosť skladu alebo pobočky od haly, ak je

kľúčom ID tovaru. Keďže by mal byť kľúč zložený z oboch pre atribút množstva tovaru

v hale, potom nevzniká ani silne funkčná závislosť atribútov na kľúči. Tranzitívna závislosť

skladu sa vyrieši jeho oddelením agregáciou a tranzitívna závislosť tovarových atribútov

oddelením tovaru od haly a množstvo v hale ako aj čas uskladnenia vyrieši asociatívna trieda.

V triedach, kde okrem zamestnanca sa evidujú deti, alebo projekty, alebo firmy, pre ktoré

pracuje, vzniká tiež tranzitívna závislosť napríklad dátumu narodenia na ID dieťaťa, vedúceho

na ID projektu a adresy na ID firmy. V prípade, že vznikne zložený kľúč z ID zamestnanca a

ID dieťaťa, ID projektu alebo ID firmy, nebudú niektoré atribúty silne funkčne závislé, preto

je vhodné rozdeliť triedu na n:m asociáciou. Nie je možné použiť agregáciu, pretože ide

o kardinalitu n:m (obaja rodičia pracujú v jednej firme, viac zamestnancov vo viacerých

firmách a projektoch, n firiem dodáva, alebo objednáva m produktov).

- 37 -

Polozka

IDtextmjmnozstv ocena

Faktúra

IDtextdatumadresatv y stav ilodosielatel

**

Sklad

Tov ar

IDnazovmj

Hala

*

*

*

*Polozka

IDtextmjmnozstv ocena

Objednáv ka

IDtextdatumadresatv y stav ilodosielatel

**

Mnozstv oUlozeneho

mnozstv o

Obr. 7a Optimalizácia štruktúry pre objednávku, faktúru, tovar na sklade

Zamestnanec

IDRC

Dieta

IDRC

**

Prispev ok

poberaPrispev ok

* *

Zamestnanec

IDRC

Projekt

IDNazovVeduci** **

Odpracov ane

odpracov aneHodiny

Zamestnanec

IDRC

Firma

ICODICONazov*** *

Funkcia

FunkciaPrijem

**

pracuje pre

pracuje na

Firma

ICODICONazov

Tov ar

IDnazovmj**

Mnozstv oDodav aneho

mnozstv o

Obr. 7b Optimalizácia štruktúry pre pracovníka s deťmi a zamestnanca

Silne funkčná závislosť množstva dodávaného tovaru, odpracovaných hodín na

projekte, funkcií, príspevkov na dieťati a podobne sa vyrieši asociatívnou triedou, ktorá bude

obsahovať zložený kľúč z oboch ID objektov, zúčastňujúcich sa na väzbe a na ktorom budú

atribúty väzby silne funkčne závislé.

- 38 -

Pravidlo č.3 Rozdelenie generalizáciou

Slúži na odstránenie viacnásobného výskytu atribútov/metód v triedach presunom do

vytvorenej nadtriedy, pre sémanticky blízke atribúty a triedy. Takéto vytváranie hierarchických

štruktúr zjemňovaním dedenia je môžné vykonať opakovane až do odstránenia všetkých

opakujúcich sa atribútov/metód triedy.

Vo pravidle č. 1 sme z príliš všeobecnej triedy vytvárali špecializáciou odvodené

podtriedy s dovtedy často sa opakujúcimi, nulovými hodnotami niektorých atribútov, ktoré

takto získali v derivovaných triedach na význame. Tu vytvárame z viacerých tried nadtriedu,

ktorej delegujeme spoločné, opakujúce sa prvky. Tento vzor teda popisuje generalizáciu

a tvorbu tried opačným merom, zdola nahor. Spolu so vzorom č. 1 popisuje postup vytvárania

tried, ktorý je intuitívne jasný, ale mnoho doménových expertov má problémy s rozhodnutím

sa pre generalizáciu, špecializáciu, kompozíciu alebo asociáciu a potrebujú poznať pravidlá

postupu.

Štruktúra

Ak niektoré triedy obsahujú redundantné atribúty, ktoré sú sémanticky podobné, je

vhodné vytvoriť pre nich nadtriedu a presunúť tam tieto atribúty. Triedy ich budú môcť vďaka

dedeniu ako podtriedy využívať aj naďalej, ale sprehľadní sa celková štruktúra. Pri pridaní

novej triedy, ktorá obsahuje takéto atribúty, je možné ich v novej triede vyradiť a triedu

zaradiť do príslušnej úrovne takéhoto hierarchického stromu.

- 39 -

X

XAtribut1XAtribut2...XAtributNSpolocny Atribut1Spolocny Atribut2...Spolocny AtributN

Y

YAtribut1YAtribut2...YAtributNSpolocny Atribut1Spolocny Atribut2...Spolocny AtributN

Yderiv

YAtribut1YAtribut2...YAtributN

Xderiv

XAtribut1XAtribut2...XAtributN

XY

Spolocny Atribut1Spolocny Atribut2...Spolocny AtributN

<<creates>>

Obr. 8 Možnosti optimalizácie pre atribúty a triedy sémanticky blízke s opakujúcimi sa atribútmi

Triedy ich budú môcť vďaka dedeniu ako podtriedy využívať aj naďalej, ale

sprehľadní sa celková štruktúra. Pri pridaní novej triedy, ktorá obsahuje takéto opakujúce sa

prvky, je možné ich v novej triede vyradiť a triedu zaradiť do príslušnej úrovne takéhoto

hierarchického stromu.

Doplňujúci popis a príklady:

- 40 -

Vzor môžeme ilustrovať na príklade personálu v nemocniciach, kde evidujeme rôzne

druhy zdravotných sestier a rôzne profesie lekárov. Je vhodné identifikovať tieto triedy

a vytvoriť pre ne spoločnú nadtriedu lekár, zdravotná sestra a podobne. Takisto aj pre faktúru,

dodací list a podobne, môžeme vytvoriť spoločnú nadtriedu doklad. Podobne aj pre triedy

popisujúce potrebné typy účtov (spoločnú triedu účet).

Pravidlo č.4 Rozdelenie tried agregáciou/asociáciou

Slúži na odstránenie viacnásobného výskytu atribútov/metód v triedach presunom

(projekciou) do novovytvorenej triedy ako ich časti – agregovanej, alebo asociovanej triedy, pre

sémanticky odlišné triedy.

- 41 -

X

XAtribut1XAtribut2...XAtributNSpolocny Atribut1Spolocny Atribut2...Spolocny AtributN

Y

YAtribut1YAtribut2...YAtributNSpolocny Atribut1Spolocny Atribut2...Spolocny AtributN

<<creates>>

Xderiv

XAtribut1XAtribut2...XAtributN

XY

Spolocny Atribut1Spolocny Atribut2...Spolocny AtributN

*

Yderiv

YAtribut1YAtribut2...YAtributN

***

Obr. 9 Možnosti optimalizácie pre atribúty a triedy sémanticky rozdielne s opakujúcimi sa atribútmi

Ak niektoré triedy obsahujú spoločné atribúty, ktoré sú sémanticky rozdielne od

ostatných, je vhodné vytvoriť pre ne samostatnú triedu mimo hierarchie a presunúť tam tieto

atribúty. Takáto trieda bude potom vo vzťahu asociácie, alebo agregácie, ak boli dovtedy tieto

prvky súčasťou celku a budú vznikať a zanikať spolu s ostatnými.

Doplňujúci popis a príklady:

Vzor môžeme ilustrovať na príklade tovaru alebo výrobného produktu a jeho súčastiek

(napríklad auto a jeho vybavenie: motor, kolesá, karoséria a podobne).

- 42 -

Viacvrstvový model

Po dokončení všetkých modelov a vrstiev je vhodné vytvoriť aj viacvrstové diagramy zložené

z niekoľkých častí alebo vrstiev. Väčšinou sa používa trojvrstvový diagram (Three - Tiered Class

Diagram) kde sa nachádzajú:

Prezentačná, alebo používateľská vrstva (User Services) - triedy, ktoré zabezpečujú služby

navonok, pre konkrétneho používateľa; sú to aplikačné V/V triedy,

vrstva logiky (Business Services) - ktorá zabezpečuje výpočty, spracovanie, úlohy a logiku

systému,

dátová vrstva (Data Services) obsahujúca (perzistentné) triedy a služby komunikácie so

SRBD.

Ide tu o rozdelenie a zoskupenie tried podľa príslušnosti do jednotlivých vrstiev, ktoré

navzájom spolupracujú v aplikácii. Tak možno oddeliť DB služby od výpočtových, ľahšie ich

udržiavať, optimalizovať, opravovať, vymieňať a využívať na podobné zameranie. Identifikuje sa tak

a analyzuje komunikácia medzi vrstvami a zjednodušuje sa, prípadne posudzuje adaptácia vrstvy pre

iné podmienky (prezentačná vrstva pre iné odvetvie, alebo krajinu, dátová vrstva pre nový typ

databázy, logická pre výmenu za efektívnejšie algoritmy), alebo jej výmenu.

V konceptualizácii a analýze sa začína často s doménovými, reálnymi triedami, ktoré sa

neskôr transformujú do dátovej entity, budú potrebovať formulár na editovanie obsahu, prípadne

výpočtovú triedu a triedu pre rozhranie. Vznikne tak viac tried s rovnakým názvom: doménová,

aplikačná pre V/V formulár, interná-dátová, interná-výpočtová, rozhranie a podobne. Tento problém

sa dá riešiť dvomi spôsobmi:

1. pre jednotlivé triedy sa vytvoria rôzne stereotypy, napríklad Form (ako Formular pre aplikačnú),

DB (pre dátovú), Internal alebo C (ako Class pre výpočtovú), I alebo Interface pre rozhranie,

2. ak konkrétne prostredie nedovoľuje rovnaké mená, hoci pre rôzne stereotypy, potom budú slúžiť

predchádzajúce akronymy ako predpony mena pre jednotlivé druhy tried: Faktura (reálna trieda),

FormFaktura (V/V formulár, aplikačná trieda, v prezentačnej vrstve), CFaktura (pre výpočtovú

triedu, v logickej vrstve), DBFaktura (pre internú triedu v dátovej vrstve), IFaktura pre všeobecné

rozhranie rôznych typov faktúr, tento príklad je len ilustratívny pre návrh menných konvencií

a nie je dokonalý svojím obsahom.

- 43 -

Väčšinou doménová reálna trieda tvorí na začiatku predobraz pre následné dvojnícke triedy

a v závere návrhu už zaniká a ostávajú už len jej implementační následníci v aplikačnej

(používateľskej) a internej vrstve (logickej a dátovej).

Na obr. 10. je znázornená dvojvrstvová architektúra klient-server podľa [RUP 98], kedy prvá

pracovná stanica (Client A) obsahuje aplikáciu a všetky potrebné služby a komunikuje priamo s

databázou. Trojvrstvovú architektúru využíva až druhá alternatíva, kedy pracovná stanica (Client B)

využíva server, na ktorom je sústredená časť všeobecnej logiky systému a služieb a až ten komunikuje

s databázou. Dnes ide najmä o spoločné COM objekty a db služby. Tretia alternatíva, typická pre

intranet/internet riešenia, používa tzv. tenkého klienta (Client C), ktorý obsahuje len prehliadač. Web

server, s ktorým komunikuje, obsahuje aj prezentačnú aj logickú vrstvu.

Obr. 10 Dvojvrstvová, trojvrstvová a web aplikácia, RUP, Rational Software, 1998

Ďalším prvkom objektovej analýzy je vyčlenenie tried, ktoré slúžia len ako rozhranie

(interface), nielen k používateľovi, ale aj k ostatným triedam. Sú to triedy, ktoré obsahujú len metódy

na sprístupnenie ostatných členov, dát a funkcíi, vlastností, atribútov, zabezpečenie V/V rozhrania.

Tieto metódy sú prázdne, slúžia len ako abstraktné vzory prístupu a komunikácie, ktoré skutočné

triedy dedia a dopĺňajú ich funkčný kód, implementáciu. Význam tejto technológie je v tom, že

používateľ dopredu pozná rozhranie a nezaujíma ho, ako bude zabezpečené. Ak napríklad dodávateľ

vyvinie novú verziu, musí ponechať pôvodné rozhranie a pridať aj nové, vylepšené, ako ďalšiu

verziu, aby pôvodné programy a komponenty pristupovali k pôvodnému rozhraniu a nové k novému.

Vo všetkých krokoch analýzy a návrhu boli uplatnené pravidlá konzistencie o vytváraní

dynamického a následne objektového modelu. Pre triedy, ktoré menia stavy počas behu programu, sa

- 44 -

vytvára aj stavový diagram. To sa vytvára už pre doménové triedy. V nich sa definujú stavy skúmanej

triedy a udalosti, ktoré vedú k prechodu do jednotlivých stavov. V stavoch sa zaznamenávajú operácie

- metódy triedy, ktoré je nutné pri vstupe do stavu alebo na výstupe - zániku pri ukončení vykonať.

Operácie sú chápané ako aktivity (vykonávajú sa počas celého trvania stavu (do)) a ako akcie

(vykonávajú sa pri vstupe (on entry), výstupe (on exit), alebo pri nejakej udalosti (on event)).

Stavový diagram použijeme pre každú triedu, ktorá vykazuje možnosť nachádzať sa vo viac

stavoch, do ktorých prechádza po nastatí udalostí, príchodu očakávanej správy alebo splnení určitých

podmienok.

Algoritmy metód tried, ktoré je nutné pre svoju dôležitosť navrhnúť a zapísať, tvoríme

podobným postupom ako v analýze.

V analýze sa algoritmy väčšinou získali od používateľa; išlo o algoritmy aplikačnej oblasti

týkajúce sa všeobecných alebo interných predpisov a smerníc.

Vo fáze návrhu môže ísť síce aj o doplnenie potrebných algoritmov od používateľa alebo

zadávateľa, ale ide aj o získavanie algoritmov pre triedy mikroprocesov, ktoré sú viac systémovo a

programátorsky orientované a nie aplikačne. Ich riešenia sa vyhľadávajú väčšinou v odbornej

literatúre a článkoch, na konferenciách a pri konzultáciách so špecialistami. Ide napríklad o špeciálne

numerické a dátové algoritmy, kde sa prihliada na stupeň presnosti, spotrebu primárnej a sekundárnej

pamäte, časové nároky a pod. Aj táto práca je dôležitou súčasťou návrhu.

Model softvérových a hardvérových komponentov IS

Na záver možno zrevidovať hlavný diagram komponentov a vytvoriť pohľad na softvérové

komponenty navrhovaného systému, kde vystupujú už mená konkrétnych knižníc tried a funkcií, či už

dodávaných, alebo vytvorených. Môžeme uvádzať aj ich prípony ako .lib, .dll, .ocx., .bin, aj .exe a

podobne. Možno navrhnúť aj komponenty zdrojových textov programu (.hpp, .cpp a pod.) a ich

závislosť, prípadne aj usporiadanie výkonných modulov podľa prevádzok, oddelení, pracovných

staníc a podobne.

V tejto etape je nutné navrhnúť aj spôsob ochrany a zabezpečenia systému, režim práce, typ

programovacieho jazyka, DB a podobne. Toto však nie je integrálnou súčastou UML.

- 45 -

Implementácia

Implementáciu bežnej aplikácie je možné rozdeliť na implementáciu dátovej, logickej a

prezentačnej vrstvy (pri technologických procesoch, systémových programoch alebo napríklad

aplikáciách čipových kariet sa môžu použiť iné architektúry). Väčšinou programátor potrebuje pre

implementáciu dátový model, základné scenáre služby (use case) a návrhy obrazoviek. Dnešné

vývojové prostredia dovoľujú návrh obrazoviek a okamžité generovanie celkovej aplikácie. Takýmito

rozšírenými prostrediami pre jazyk C++ je napríklad C++ Builder alebo Microsoft Visual C/C++,

popísané množstvom publikácií podobných [Kruglin 98] prípadne celé MS Visual Studio, kde sú aj

ďalšie jazyky (Visual Basic, Visual FoxPro), ktoré tiež používajú spoločné prostredie návrhu

prezentačnej vrstvy a generovanie prázdnej aplikácie. Je dokonca možné navrhnúť aj prepojenie na

databázu pomocou sady premenných a nakoniec doplniť preddefinované metódy kódom. K

jednotlivým objektom obrazoviek je možné priradiť metódy podľa udalosti na objekte. Pri vstupnom

poli je dôležitou udalosťou zapisovanie znakov z klávesnice, prípadne potvrdenie na konci zápisu

pomocou klávesy Enter. Pri tlačidle je to jeho voľba poklepom na ňom pomocou počítačovej myši,

kedy sa v metóde spustí žiadaná operácia, ktorú samotné tlačidlo zastupuje. Keďže používateľ okrem

menu práve tieto objekty žiada o spustenie operácií, ich metódy v dialógu sú najdôležitejšie a kryjú sa

často s dôležitými scenármi služby. Preto je vhodné zaznamenať interakciu objektov v dialógu po

stlačení tlačidla (Obr. 11a. a 1.11b.).

- 46 -

: Pouziv atel

Pridaj : PushButton

Vy rad : PushButton

Produkt : EditBox

Zoznam : Listbox

Pridaj::PridajProdukt(){

Produkt.VratProdukt();Zoznam.ZaradProdukt();Produkt.Vy znacText();if (Vy rad.Nepristupny ())

Vy rad.Uv olni();}

1: PridajProdukt()2: VratProdukt()

4: Vy znacText()

3: ZaradProdukt()

5: [nepristupny ] Uv olni()

Obr. 11a Scenár metódy PridajProdukt() objektu Pridaj triedy PushButton (komunikačný diagram)

- 47 -

: Pouziv atel

Pridaj : PushButton

Produkt : EditBox

Zoznam : Listbox

Vy rad : EditBox

PridajProdukt

VratProdukt

ZaradProdukt

[nepristupny ] uv olni

Vy selektujText

Obr. 11b Scenár metódy PridajProdukt() objektu Pridaj triedy PushButton (sekvenčný diagram)

Keďže ide často o veľmi jemné operácie, analytik ich nezaznamenáva v takomto tvare často,

ale len v skripte v dokumentácii dialógu, ako to je pri obrázku 2.11a. Na tomto obrázku je celý scenár

zaznamenaný v komunikačnom diagrame, ktorý môže v doplňujúcej vrstve prekrývať objektový

diagram dialógu podľa kapitoly 2.1.3.

Previazaním jednotlivých objektov obrazovky sa zaoberá aj vzor Mediator z [Gamma 95].

Vzor Command opisuje štruktúru a fungovanie celej aplikácie, obsahujúcej dokumenty a menu s

príkazmi na spracovanie. Dnes sú skôr vynikajúcim príkladom používanej architektúry a nie je

potrebné už tieto vzory implementovať, pretože ich štandardné prostredie už obsahuje. Vo

vygenerovanej aplikácii už je väčšinou prítomná aj podpora pre Dispečer (Mediator), ktorý spúšťa

metódy objektov podľa zaregistrovanej udalosti, podpora pre menu systém, spracovanie dokumentov

(SDI - Single Document Interface, MDI - Multiple Document Interface), podobné prostrediu

dokumentov Wordu, Excelu, PowerPointu v Microsoft Office a iných systémov a nie je problém

vytvoriť pre spracovanie faktúr, klientov, alebo objednávok podobné aplikácie. Aj CASE systém

D4W:Doors For Windows, ktorý vznikol pred dnešnými vývojovými nástrojmi, popísaný v [Polášek

- 48 -

94] a v Prílohe D., sa zaoberá tvorbou dialógov a zdrojového kódu celej aplikácie, ich vnútornou

riadiacou logikou a naviazaním na databázu.

Ak však ide o rozsiahlu profesionálnu aplikáciu, kde nestačia len návrhy obrazoviek a

predstava spracovania údajov, je potrebné použiť jazyk UML a jeho jednotlivé diagramy na

vytvorenie modelu budúceho systému. Ak sú v elektronickej podobe, vytvorené pomocou CASE

systému, je možné priamo z nich generovať skelet, alebo fragmenty aplikácie. Čo všetko by bolo

potrebné pre vygenerovanie celej aplikácie bez ďalšieho zásahu v ideálnom prípade?

Na zabezpečenie previazania celej aplikácie je potrebný konceptuálny diagram, podľa

jednotlivých služieb sa vytvárajú moduly a knižnice aplikácie v komponentovom diagrame a ich

fyzické umiestnenie v diagrame rozmiestnenia. Jednotlivé služby – moduly sú naplnené konkrétnou

objektovou štruktúrou a to je potrebné zaznamenať v objektovom diagrame a aj vygenerovať do

zdrojového kódu. Transformáciu jednotlivých prvkov (trieda s jej atribútmi a metódami, špecializácia

tried, agregácia a asociácia) do kódu je uvedená v kapitole 1.2. Na vygenerovanie fyzickej štruktúry

dátovej a logickej vrstvy je teda potrebné použiť objektový model, najlepšie plnohodnotný

viacvrstvový diagram. Pre prezentačnú vrstvu je najvhodnejšie použiť aj verné návrhy skutočných

obrazoviek a doplniť ich metódami podľa odpovedajúcich aplikačných tried. K tejto stále ešte

statickej štruktúre je vhodné pripojiť aj dynamický a funkčný model, ktorý dokáže vyplniť aj telá

metód objektov. Doplnenie triedy o potrebné atribúty ale najmä metódy, dokonca aj o ich

implementáciu je možné aj pomocou stavového diagramu, kde často stav triedy môže zabezpečiť

jedna metóda a jej telo bude pozostávať postupne z operácií popísaných pre vstup do stavu (entry

operácie), samotný stav (do aktivity) a výstup zo stavu (exit operácie). Aj pri prechodoch zo stavu do

stavu sa okrem udalosti zapisuje aj vykonávaná operácia, ktorej telo môže obsahovať operácie z

nasledujúceho vetvenia, stavov, prechodov a podobne. Naplnenie metód objektov pomocou stavového

diagramu je priblížené v Príloha B.5 Stavový diagram na príklade zo [Semantics 97].

V dynamickom modeli sa sleduje interakcia konkrétnych objektov a a b, kde ju v závere môže

zastupovať volanie metódy b.m() objektu b z objektu a. Všetky ďalšie metódy objektov, ktoré vyvolá

následne objekt b, môžu byť súčasťou metódy b.m(). Interaktívne diagramy sú popísané v prílohe B.3

a B.4. Pri zložitejších, napríklad numerických metódach logickej vrstvy je vhodné využiť

zaznamenaný algoritmus z funkčného modelu priamo do konkrétnej metódy. Použitie funkčného

modelu pre konkretizáciu algoritmu metódy, jej presnejší popis je v prílohe B.6 a v kapitole Riešenie

prepojenia modelov návrhom alternatívneho vývojového prostredia, aj s konkrétnymi problémami.

- 49 -

Takto vznikne funkčná aplikácia, ktorú môžeme dopĺňať priamo v prostredí SAPP, prípadne ju

aktualizovať pomocou reverzného inžinierstva.

K vytvoreniu aplikácie bez ďalšieho zásahu je potrebné využiť nasledovné diagramy

jednotlivých modelov:

1. Konceptuálny diagram na previazanie celého vývoja tvorbou služieb systému, a

vybudovanie architektúry pomocou komponentov.

2. Pokrytie rozhraní jednotlivých služieb smerom na používateľa pomocou návrhov V/V

obrazoviek.

3. Interaktívne diagramy na popis scenárov fungovania služieb systému, ktoré previažu

jednotlivé V/V obrazovky a formuláre a ich vyvolávanie.

4. Objektový diagram na generovanie zdrojového kódu štruktúry aplikácie (tzv. skelet alebo

shell), všetkých jeho vrstiev.

5. Diagramy funkčného modelu na presný popis algoritmu metód. Ak bude procesný diagram

realizovaný ako podstrom metódy objektu v navigátore SAPP, alebo ako JSD, prípadne

YSD, potom je možné použiť pre generovanie zdrojového kódu bežný algoritmus, použitý

aj v [Polášek 96c]. Program prechádza stromom rekurzívne po jeho vrcholoch, generuje

kód a pokiaľ je viac podriadených prvkov (najmä pre riadiace štruktúry while, for, if-else a

podobne) zapisuje aj začiatok a koniec bloku podľa zvoleného jazyka.

Základný algoritmus pre generovanie kódu z revidovaného JSD ako syntaktického

stromu, popísanom v kapitole Riešenie prepojenia modelov návrhom alternatívneho

vývojového prostredia, použitý v [Polášek 96c] a v [Polášek 98], môže vyzerať nasledovne

(prvok znamená vrchol stromu, úroveň znamená úroveň vrcholu stromu, podriadený prvok

znamená následník):

Zapíš(úroveň, prvoki)

{

ZapíšDoKódu(úroveň, prvoki)

ak (existuje podriadený prvokik)

ak (prvoki je funkcia alebo existuje viac ako jeden podriadený prvokik)

{

ZapíšDoKódu(úroveň, BEGIN) BEGIN je { alebo begin a pod.

pokiaľ (existuje nezapísaný podriadený prvokik)

Zapíš(úroveň+1, prvokik)

ZapíšDoKódu(úroveň, END) END je } alebo end

}

inak Zapíš(úroveň+1, prvokik)

}

- 50 -

a b c

[while(not EndOfTasks())]

[endwhi le]

Obr. 11c Príklad zápisu riadiacej štruktúry v sekvenčnom diagrame

Program pre generovanie zdrojového kódu z interaktívneho diagramu by mohol vyzerať

nasledovne:

pre všetky objekty o v interakčnom diagrame

{

pokiaľ existuje volanie metódy mj() objektu oi volanej z objektu oa

{

ak neexistuje oi.mj()

vytvor oi.mj()

inak

vytvor samostatnú sekciu metódy, volanú dispečerom

(napríklad pomocou prepínača switch-case podľa this

volajúceho objektu alebo iného parametra,

ako je tomu vo vzore Mediator podľa [Gamma 95])

pokiaľ (neprišlo zavolanie inej metódy oi)

(a teda nenastal explicitný koniec metódy a začiatok inej)

pokiaľ (existuje volanie z oi metódy mjk() objektu ob

zapíš ob.mjk() do oi.mj()

}

}

- 51 -

Ak je potrebné zaznamenať aj riadiacu štruktúru (if – else, while a podobne), je

možné toto zapísať pomocou rekurzívnej interakcie (local invocation) v objekte a štruktúru

a/alebo začiatok a koniec bloku uložiť ako podmienku interakcie a samotnú správu nevyplniť.

Takto je možné aj vnárať štruktúry, nemusí to však zvýšiť prehľadnosť.

Navigácia a prepojenie jednotlivých diagramových techník

Použitie jednotlivých diagramových techník a uloženie vizualizovaných informácií a návrhov

je veľmi dôležité.

V konceptuálnom diagrame ukladáme informácie o používateľoch systému. Títo používatelia

vystupujú neskôr v analýze a návrhu chápaní ako triedy. Prideľujeme im názvy v tvare podstatného

alebo zpodstatnelého mena ako klient, pracovník, vedenie, dodávateľ, odberateľ a podobne.

Používatelia sú triedami v podstate od začiatku, len sú špecifikovaní stereotypom Actor.

V Use Case diagramoch ďalej zaznamenávame aj služby, ktoré systém ponúka. Tieto služby

sa neskôr môžu stať komponentami alebo zväzkami tried. Môžeme ich tiež zaznamenávať v tvare

podstatného alebo spodstatneného mena, prípadne slovného spojenia: evidencia pracovníkov, mzdy,

nábor nových pracovníkov, evidencia hostí, kontrola, audit, evidencia dodávateľov, fakturácia a pod..

Sekvenčné diagramy rozvíjajú služby do podoby scenárov. Identifikujeme v nich tok

externých udalostí, ktoré vyvolávajú odozvu systému (služby) a interných udalostí, ktoré modelujú a

zabezpečujú správanie služby. Udalosti opisujeme ako javy, ktoré práve nastali, najčastejšie slovnými

spojeniami: príchod hosťa, podanie žiadosti, dodanie tovaru, splatná faktúra a podobne. Udalosti

môžu spoluidentifikovať aj prídavné mená: dodané, utriedené a pod. Okrem udalostí spoznávame v

tomto diagrame aj nové objekty, ktoré zabezpečujú príjem, spracovanie a odosielanie udalostí.

Objekty označujeme aj podstatnými menami ako fakturačné oddelenie, sklad, personálne oddelenie a

podobne. V diagrame sa pracuje nie s triedami, ale s ich inštanciami - objektmi. Možno však označiť

objekt podobným menom, ako má trieda (sklad:Sklad), prípadne ho vynechať (:Sklad). Výhoda

objektov je v tom, že možno vytvoriť aj viac inštancií tej istej triedy a modelovať interakcie aj medzi

nimi.

Komunikačné diagramy sa sústreďujú na dátové a riadiace správy medzi objektmi.

Najčastejšie ich zastupujú už metódy objektu, ktorý správu prijíma. Preto sa už nezapisuje udalosť

napr. poslanie ziadosti medzi objektom ziadatel a oddelenie ale PrijmiZiadost(), ktorá je členskou

- 52 -

funkciou - operáciou objektu oddelenie. Metódy môžu byť v tvare podstatného mena: Triedenie(),

VyhladanieOdberatela(), TlacFaktur() a pod., ale aj v tvare slovesa v 2. os. j. č. v rozkazovacom

spôsobe: Vyhladaj(), Utried(), Vytlac() a podobne. Aj v tomto diagrame sa zapisujú nové objekty.

Stavové diagramy zaznamenávajú prechod vybratých tried stavovým priestorom, a to

vybratých tried, ktoré menia stavy dynamicky v čase podľa vzniknutých udalostí. Identifikujú sa tu

udalosti, ktoré spôsobujú prechod z jedného stavu do druhého, ale aj metódy objektov, ktoré sa musia

v danom stave vykonať. Niektorí autori pripúšťajú aj možnosť zapisovať do stavu aj potrebné atribúty

pre vykonanie operácií a aktivít v danom stave. Potom stav so svojou rozšírenou štruktúrou: názov

stavu, potrebné atribúty, operácie a aktivity, pripomína definíciu triedy. Je možné to chápať ako

definíciu triedy v danom momente, ide o časový rez triedou a poskladanie všetkých rezov nám vlastne

vytvorí úplný obraz o triede. Samotné stavy si vyžiadajú najčastejšie vytvorenie samostatného

atribútu. Stavy dobre opisujú prídavné mená v slovných spojeniach. Takýmto príkladom je aj diagram

A.3 v kapitole Aplikácia postupnosti..., kde Incident nadobúda stavy Zapisany, Eskalovany, Rieseny

a podobne, po udalostiach napríklad Experti najdeni, Incident odoslany. Operáciami v stavoch sú

napríklad OverIncident, PosliExpertom, ZapisRiesenia, ktoré budú neskôr metódami objektu Incident

v objektovom diagrame.

Procesný diagram je podobný stavovému diagramu ale namiesto stavov sú tu operácie, ktoré

sú súčasťou algoritmu vybratej metódy triedy, ktorej algoritmus je potrebné analyzovať alebo

navrhnúť. Operáciami môžu byť nielen jednoduché príkazy, ale aj vyvolania metód iných objektov.

Nemodeluje sa tu správanie vybratej triedy, ale vybratá členská funkcia triedy. Diagram nahrádza

Jacksonov, Yourdonov alebo vývojový diagram.

Objektový model slúži na zápis a doplnenie o ďalšie nové triedy, najmä aplikačné a interné,

dopĺňajú sa aj o atribúty a metódy. Pri názvoch atribútov používame podstatné mená, prídavné mená

môžu byť hodnotami.

Ak by sme to mali zhrnúť, tak triedy a ich objekty ako základné stavebné prvky vznikajú z

používateľov a služieb, navrhnutých v konceptualizácii a zapísaných v konceptuálnych diagramoch.

Dopĺňajú sa o ďalšie objekty v sekvenčných a komunikačných diagramoch, ako aj v objektových

diagramoch. Nové metódy do tried sa pridávajú počas tvorby sekvenčného, komunikačného,

stavového, objektového a procesného diagramu.

- 53 -

Diagram možnosť identifikovať objekt možnosť identifikovať atribút objektu možnosť identifikovať metódu objektu

konceptuálny áno

(z používateľa; komponenty zo služby) áno

(z atribútov používateľa) áno

(funkcie a možnosti používateľa)

objektový áno

áno

áno

interaktívny áno

(potrebné pre komunikáciu) áno

(z obsahu interakcií a správ)

stavový áno

(z potrebných atribútov stavu) áno

(z operácií v stave)

procesný áno

(podľa volania metódy objektu) áno

(pre potrebu metódy) áno

(z volania inej metódy)

Tab. 3 Možnosť identifikácie objektov, atribútov a metód z jednotlivých diagramov

Navrhovanú postupnosť ako algoritmus možno zapísať nasledovne:

opakuj

{

pre všetky (požiadavky, používateľov, vstupujúce inicializačné udalosti)

vytvor, alebo aktualizuj katalóg

vytvor, alebo aktualizuj konceptuálny diagram,

kde služby spĺňajú jednotlivé požiadavky

pre (každú službu)

{

pre (každú inicializačnú udalosť s odlišnou reakciou služby)

pre (pesimistický, bežný, optimistický scenár)

ak (existuje a je to potrebné)

vytvor alebo aktualizuj interaktívny diagram

ak (zadávateľ disponuje konkrétnou V/V predstavou)

zapíš potrebné V/V formuláre služby podľa zadávateľa

ak (je potrebný objektový model služby)

vytvor alebo aktualizuj diagram tried a objektov

ak (je potrebný stavový diagram služby)

vytvor alebo aktualizuj ako poddiagram služby

ak (je potrebný funkčný model služby)

vytvor alebo aktualizuj vhodné diagramy funkčného modelu

}

opakuj {

pre (každú službu, alebo celý systém)

{

navrhni výstupné formuláre podľa potrieb používateľa

- 54 -

a doplň aplikačnú vrstvu modelov

vytvor alebo doplň dátovú vrstvu (DB) podľa potrieb výstupov,

navrhni vstupné formuláre podľa potrieb DB

a doplň aplikačnú vrstvu týmito objektmi

vytvor alebo aktualizuj prototyp IS v používateľskej príručke

}

}

pokiaľ nie je používateľ spokojný s prototypom IS v príručke

vytvor alebo aktualizuj vrstvu logiky, zabezpečujúcu výstupy z DB,

vytvor alebo aktualizuj vrstvu logiky, zabezpečujúcu DB zo vstupov,

vytvor alebo aktualizuj viacvrstvové diagramy

dokonči prechod z logického do fyzického pohľadu a optimalizuj

doplň návrh DB a IS pre DWH a DM

implementuj IS, testuj a zaveď do prevádzky,

}

pokiaľ nie je IS úplne funkčný

- 55 -

: Interaktivne diagramy

: Zadavatel : Stavovy diagram

: Funkcny model

: V/V formulare

: Konceptualny model

: Objektovy model

Zaznamenaj pouzivatelov

Zaznamenaj poziadavky

Zaznamenaj inicializacne

udalosti

Zapis pouzivatelov ako triedy

Zapis sluzby ako komponenty

Vytvor konceptualny diagramsluzby splnaju jednotlive poziadavky

Vytvor katalog pouzivatelov

Vytvor katalog poziadaviek

Vytvor katalog in. udalosti

Obr. 12a Toky informácií v etape konceptualizácie medzi modelmi a diagramami

Na obr. 12a je zaznamenaná postupnosť etapy konceptualizácie formou sekvenčného

diagramu. Objektami sú tu modely (konceptuálny, funkčný a objektový), diagramy dynamického

modelu (interaktívne diagramy a stavový diagram) a vstupno/výstupné formuláre systému. Jednotlivé

správy (zazanamenaj, zapíš, vytvor) však neposiela zdrojový prvok a prijímajúci ho nevykonáva, je to

skôr predpis pre analytika. Je to algoritmus, zapísaný pomocou sekvenčného diagramu, nevyužíva sa

však cyklus a podmienky. Napriek tomu je zo zápisu zrejmé, odkiaľ kam sú prenášané jednotlivé

prvky a informácie, kto je ich zdrojom (Zadávateľ) a kam sa zaznamenávajú a zobrazujú

(Konceptuálny model a Objektový model). Prvá správa prikazuje analytikovi získať od zadávateľa

- 56 -

všetky typy používateľov budúceho IS, ich úlohy zodpovednosť a práva a uložiť ich do

konceptuálneho modelu, ktorý obsahuje katalógy a konceptuálny diagram.

Na obr.12b je zaznamenaná postupnosť etapy analýzy. Správy sú opäť jednotlivými krokmi

analytika, ktorý sa opiera o dostupné informácie v zdrojovom prvku, dopĺňa ich údajmi od

zadávateľa, doménových expertov a vytvára nové elementy a štruktúry v cieľovom objekte.

: Pouzivatel : Interaktivne

diagramy : Stavovy diagram

: Funkcny model

: V/V formulare

: Konceptualny model

: Objektovy model

Vytvor scenare pre sluzby

Zapis nove triedy a metody

Vytvor diagram pre dynamicke sluzby

Vytvor diagram pre dynamicke triedy

Zapis nove metody triedy podla operacii v stavoch

Zapis algoritmy pre sluzby

Zapis algoritmy pre metody

Obr. 12b Toky informácií v etape analýzy medzi modelmi a diagramami

Na obr.12c je zaznamenaná postupnosť etapy návrhu, kde pracuje návrhár samostatne, vytvára

a dpĺňa aplikačnú a mikroprocesnú vrstvu v dynamickom, objektovom a funkčnom modeli.

- 57 -

: Pouzivatel

: Interaktivne diagramy

: Stavovy diagram

: Funkcny model

: V/V formulare

: Konceptualny model

: Objektovy model

Vytvor/aktualizuj vystupy pre sluzbu

Vytvor/aktualizuj datovu vrstvu podla vystupov

Vytvor/aktualizuj vstupy podla datovej vrstvy

Vytvor/aktualizuj aplikacnu vrstvu

Dopln logicku vrstvu pre vystupy

Dopln logicku vrstvu pre vstupy

Dopln aplikacnu vrstvu

Obr. 12c Toky informácií v etape návrhu medzi modelmi a diagramami

Prehľadne sa dá postupnosť zapísať v procesnom diagrame, ktorý sa nachádza na obr.13.

Využíva synchronizáciu na paralelné procesy, ktoré môžu vzniknúť pri vytváraní jednotlivých

diagramov súčasne, hoci vykonanie aktivít zľava doprava môže byť niekedy vhodnejšie.

- 58 -

Konceptuálny diagramKatalóg inicializačných udalostíKatalóg požiadaviek Katalóg používateľov

Dynamický model Funkčný modelObjektový model

Výstupy IS

Návrh DB

Vstupy IS

Prototyp IS v používateľskej príručke

[požiadavky splnené]

Logická vrstva pre zabezpečenie Výstupy <- DB

Logická vrstva pre zabezpečenie Vstupy -> DB

Viacvrstvové diagramy a optimalizácia

Doplnenie objektového, dynamického a funkčného modelu

[Funkčný IS]

Implementácia, testovanie a ladenie

[Potrebná oprava

zmena

doplnenie]

[zmena, oprava

alebo doplnenie]

Vytv

ára

nie

/dopĺň

anie

kata

lógov a

konc.

dia

gra

mu

ako K

ON

CE

PT

UA

LIZ

ÁC

IA

Vytv

ára

nie

/dopĺň

anie

poddia

gra

mo

v s

lužie

b

ako A

NA

LÝ

ZA

NÁ

VR

H

Pre metódy objektov

Aplikačná vrstva modelov

Podľa aplikačnej vrstvy

Podľa dátovej vrstvy a jej modelov

použitá aplikačná vrstva

Diagram interakcií pre scenáre služby,

stavový diagram pre dyn. službu a triedy

Obr. 13 Schéma postupnosti návrhu IS v procesnom diagrame

- 59 -

Vytvorme štvordimenzionálnu tabuľku použitia vrstiev a pohľadov v modeloch počas

jednotlivých etapách postupnosti a zaznamenajme ich povinné použitie znakom “!”. Znakom “?”

zaznamenajme možnosť práce alebo doplnenia vrstvy v modeli pre konkrétny pohľad a pomocou

znaku “-“ nevhodnosť pre danú etapu. Vyznačme prienik povinného použitia rovnakých vrstiev v

modeloch tmavšou farbou v tabuľke a zistíme že ide o prezentačnú vrstvu vo forme logického

pohľadu v etape analýzy a návrhu v objektovom dynamickom a funkčnom modeli.

Koncept. model Objektový model Dynamický model Fun. model

KP LP FP KP LP FP KP LP FP KP LP FP

doménová ! ? - - - - - - - - - -

konceptualizácia prezentačná ? ? - - - - - - - - - -

logická ? ? - - - - - - - - - -

dátová vrstva - - - - - - - - - - - -

doménová ? ? ? ! ! ? ! ! ? ! ! ?

Analýza prezentačná ? ? ? ! ! ? ! ! ? ! ! ?

logická ? ? ? ? ? ? ? ? ? ? ? ?

dátová vrstva ? ? ? ? ? ? ? ? ? ? ? ?

doménová ? ? ? ? ? ? ? ? ? ? ? ?

Návrh prezentačná ? ? ? ? ! ! ? ! ! ? ! !

logická ? ? ? ? ! ! ? ! ! ? ! !

dátová vrstva ? ? ? ? ! ! ? ! ! ? ! !

Tab. 4 Použitie jednotlivých modelov, vrstiev a pohľadov pre navrhovanú postupnosť: nutnosť (!), možnosť (?)

a nevhodnosť (-), použité dimenzie: 1. etapy postupnosti, 2. modely (konceptuálny, objektový, dynamický,

funkčný), 3. vrstvy (doménová, prezentačná, logická, dátová), 4. pohľady (konceptuálny – KP, logický – LP,

fyzický - FP)

Vyplýva z toho dôležitosť popisu vstupno-výstupných formulárov a objektov prezentačnej

vrstvy od používateľa v analýze ako jej výstupu a ich dôkladné spracovanie v etape návrhu a

odvodenie potrebnej štruktúry dátovej a logickej vrstvy.

- 60 -

Aplikácia postupnosti pre vývoj IS na konkrétnom projekte

(Vybraté časti dokumentácie analýzy a návrhu systému Support Server )

Nasledujúce fragmenty diagramov ukazujú skutočné použitie postupnosti návrhu IS,

ktorá nebola použitá do všetkých detailov pre nedostatok času a tlak používateľa, ale sú cenné

vyňatím zo skutočného, reálneho riešenia, ktoré bolo zavŕšené fungujúcou aplikáciou, hoci už

dnes sú zrejmé možnosti doplnenia a zmien. Táto aplikácia je už treťou a jedinou funkčnou

verziou, kedy prvá klient/server verzia v jazyku C/C++/SQL nebola dobre navrhnutá a

implementovaná, druhá verzia skončila vo fáze analýzy pre neschopnosť analytikov vytvoriť

korektný návrh vďaka nasledovným chybám:

- neboli hneď na začiatku ujasnené požiadavky v konceptualizácii a tým aj funkcionalita

systému,

- začalo sa hneď návrhom dátového modelu, ktorý sa neustále prepracovával a nikdy

nedokončil, vládla snaha o jeho dokonalosť namiesto iteratívnej konvergencie k

vyhovujúcemu modelu.

Konceptualizácia

Nasledujúci konceptuálny diagram bol vytvorený na prvom stretnutí a ďalej dopĺňaný. Stal sa

východiskom a autoritou počas celého vývoja implementácie a testovania. Obsahuje základné

požiadavky na Support Server:

- zápis a evidencia incidentu (incidentom sa rozumie hardverový alebo

softvérový problém klienta, ktorý je potrebné vyriešiť),

- riešenia a mailing (sleduje sa eskalácia incidentu: priradenie riešenia

incidentu množine vhodných voľných expertov, ich odpovede, zaslanie

riešenia klientovi),

- evidencia klientov a pracovníkov,

- reporty (reporty sú potrebné pre pracovníkov a vedenie support centra, pre

jeho zriaďovateľa (spoločnosť Microsoft))

- 61 -

Obr. A.1a Globálny konceptuálny diagram pre systém Support Server

Na ďalšom stretnutí sa stanovili prioritné požiadavky, odvodili sa dôležité požiadavky

pre riešenie v druhom slede (iterácii) a ďalšie perspektívne požiadavky pre budúce iterácie.

Nepostupovalo sa rozširovaním služieb na špecializované služby, prepojené vzťahom extend a

podslužby napojené cez include alebo uses. Diagram sa nerozširoval, len sa spísal katalóg

požiadaviek, ktorý sa stal aj súčasťou diagramu ako jeho upresňujúca dokumentácia.

Katalóg požiadaviek obsahoval nasledovné informácie:

A. Prioritné požiadavky na systém:

1. zápis a evidencia incidentov:

vytvorenie editora formuláru na zápis incidentu a uloženie do DB, čítanie incidentov,

editovanie riešenia,

Opakujúce sa cinnosti

vedenie

3. reporty

podla obdobiapodla klientapodla stavupodla typu

Klient

2. evidencia klientov a pracovnikov

PracovnikKlienta

report pre klienta

Expert

1.zapis a evidencia incidentov

prezeranie a update

nahlasenie

4. riesenie a mailing

ASCsluzba

update a kontrola

zapis a update

prezeranie

nahlasenie: telefonom/mailom

- 62 -

2. editovanie ostatných entít - tabuliek:

2.1. produktov (automaticky odvodený formulár)

2.2. klientov, pracovísk a kontaktných pracovníkov (prepojené)

2.3. expertov a pracovníkov ASC, ktorí prijímajú a riešia incidenty (odv. formulár)

Obr. A.1b Doplnený konceptuálny diagram

3. reporty incidentov podľa rôznych kritérií pre rôznych užívateľov:

3.1. podľa experta pre experta,

3.2. podľa stavu riešenia, priority,

Opakujúce sa cinnosti

vedenie

3. reporty

podla obdobiapodla klientapodla stavupodla typu

Klient

A. Prioritne poziadavky na system su nasledovne:1. zapis a evidencia incidentov:vytvorenie editora formularu na zapis incidentu a ulozenie do DB, citanie incidentov, editovanie rieseni 2. editovanie ostatnych entit - tabuliek:2.1. produktov (aut. formular)2.2. klientov, pracovisk a kontaktnych pracovnikov (prepojene)2.3. expertov a pracovnikov ASC, ktori prijimaju a riesia incidenty (aut. formular)3. reporty incidentov podla roznych kriterii pre roznych uzivatelov:3.1. podla experta pre experta,3.2. podla stavu riesenia, priority,3.3. podla obdobia, produktu, OS, prijimatela,...je nutne ponuknut moznost triedenia priamo vo formulari...

B. Dolezite poziadavky, riesene v druhom slede:1. vyber experta na riešenie incidentu,2. mailing strukturovanych mailov,3. zadavanie incidentov cez web, reporty incidentov podla klienta pre klienta,4. editovanie zoznamu pracovnikov (expertov), klientov, produktov, OS, kl. slov,5. kontrola klienta na povolene osoby a zaplatenu podporu (body),6. export do cvc, backup,7. restaurovanie a editovanie DB

C. dalsie poziadavky:1. blacklist neplaticov,2. editovanie kontaktnych osob klientom3. vyhladavanie rieseni (UI)4. prijem strukturovanych mailov a aut. zaevidovanie incidentu,5. hladanie riesenia podla vyriesenych klientom

2. evidencia klientov a pracovnikov

PracovnikKlienta

report pre klienta

Expert

1.zapis a evidencia incidentov

prezeranie a update

nahlasenie

4. riesenie a mailing

ASCsluzba

update a kontrola

zapis a update

prezeranie

nahlasenie: telefonom/mailom

- 63 -

3.3. podľa obdobia, produktu, OS, prijímateľa,...

je nutné ponúknuť možnosť triedenia priamo vo formulári...

B. Dôležité požiadavky, riešené až v druhom slede:

1. automatický výber experta na riešenie incidentu,

2. mailing štruktúrovaných mailov,

3. zadávanie incidentov cez web,

reporty incidentov podľa klienta pre klienta,

4. editovanie zoznamu pracovníkov (expertov), klientov, produktov, OS a kľúčových slov,

5. kontrola klienta na povolené osoby a zaplatenú podporu (body),

6. export do celkového výkazu činnosti, záloha DB,

7. reštaurovanie a editovanie DB

C. ďalšie požiadavky:

1. čierna listina neplatičov,

2. editovanie kontaktných osôb klientom

3. vyhľadávanie riešení (vytvoriť ES)

4. príjem štruktúrovaných mailov a automatické zaevidovanie incidentu,

5. hľadanie riešenia samotným klientom podľa už vyriešených incidentov

Analýza

Analýze boli podrobené služby pre Zápis a evidenciu incidentu a Riešenie a mailing a

vytvorené poddiagramy týchto dvoch služieb spoločne pre ich prepojenosť a analytickú

zložitosť pre programátora. Služba Evidencia klientov a pracovníkov a služba Reporty bola

pre svoju jednoznačnosť ignorovaná v tejto etape.

Dynamický model bol vytvorený zo sekvenčných diagramov pre zápis a riešenie

incidentu nového záujemcu a klienta, ako aj stavový diagram pre triedu incident a jeden pre

obidve analyzované služby.

- 64 -

Obr. A.2b Sekvenčný diagram pre zápis a eskaláciu incidentu klienta (doménové objekty)

klient ASC GTI Back Up MS Back UpZáujemca Ek. oddelenie

Kontrola ciernej listiny

Otázka alebo ziadost o zmluv u

Ak je jednoduchá otázka, odpov ed

Údaje pre zmluv u

Zmluv a

Podpísaná zmluv a

Potv rdenie

Ak má otázku, ale nemá zmluv u, zapíšu sa v šetky potrebné údaje (osoba a tel. cislo, prip. ICO a pod.)

Update ciernej listiny Ak klient v ráti podpísanú zmluv u, prípadne po zaplatení,je v y mazaný z ciernej listiny

Zapis do DB klientov

- 65 -

Obr. A.2a Sekvenčný diagram pre zápis incidentu nového záujemcu (doménová vrstva)

ASCKlient GTI Back Up MS Back UpEk. oddelenie

ID, ID zmluv y /série, otázka

Ov erenie ID, ID zmluv y /série

Ak v y riešené, odpov edá

Hladanie riešeniaAk v y riešené, odpov edá,

inak v y sv etluje

další postup

Eskalácia problému

Riešenie, alebo rieši

Eskalácia problému

Odpov ed alebo oznámenie

eskalácie do MS

Riešenie

Odpov ed z MS

Okamzite, v rámci telef onátu

Telef onát do 1, 2 hodín

Telef onát do 1, 2 dní

UpozorneniePri predposlednej a poslednej odpov edi zo série, aleboMesiac/týzden pred v y pršaním rocnej/mesacnej zmluv y

Upozornenie po 12 hodináchAk neprišla uspokojiv á odpov ed a v šetci neodpov edali

Upozornenie po 18 hodinách

Pre neodpov edajúcich riešiacich

Riešenie

Riešenie

Koniec telef onátu

Koniec telef onátu

Telef onát, mail, f ax

Všetky odpov ede pre rýchlost telef onicky , zárov en f axom pre dokumentáciu

- 66 -

Obr. A.3 Stavový diagram pre triedu incident

Oznameny

entry: OverIncidentexit: UrciTypIncidentu

Zapisany

entry: Zapisentry: UrciExpertov

Eskalovany

entry: PosliExpertomdo: KontrolaEskalacie exit: OznamKlientovi

Rieseny

entry: Riesenie

Vyrieseny

entry: ZapisRiesenia

Informacie

Novy incident

Archivovany

entry: Oznam

Experti najdeni

[ Incident OR Onsite ] [ Otazka ]

[ omyl ]

[ ziadost o informacie ]

riesenie zapisane a doplnene

[ riesenie najdene ][ riesenie nenajdene ]

incident odoslany

- 67 -

Obr. A.4 Stavový diagram pre zápis a eskaláciu incidentu (analýza)

Objektový model nebol vytvorený vzhľadom na skúsenosti z predošlého projektu a

prešlo sa na návrh výstupov, kde sa počítalo s tým, že vznikne aj prvý prázdny prototyp,

obsahujúci množinu prepojených obrazoviek.

Návrh výstupov IS

V tejto etape sa najprv vytvoril interaktívny diagram, ktorý popísal znovu

komunikáciu objektov pri zápise a riešení incidentu. Tentoraz to však neboli doménové, ale

aplikačné objekty. Týmto spôsobom sa identifikovali potrebné formuláre. Pri analýze

participoval vzhľadom na RAD koncepciu aj programátor, ktorý nerozumel na prvý pohľad

zistov anie udajov o incidente

zistov anie udajov o zaujemcov i

riesenie incidentu

zapis udajov o incidente

hladanie riesitela

zapis incidentu

incident uzatv oreny

riesitel najdeny

udaje zapisane

zaujemca nie je a ani nechce by t nasim klientom

zaujemca je nas zakaznik alebo je VAP

alebo ide o otazku, inf ormaciu alebo v nutorny hotline

incident je riesitelny

zaujemca o support sa na nas obrati

- 68 -

zložitému účtovaniu za vyriešné incidenty a výberu vhodných expertov pre incident. Bol teda

už teraz vytvorený aj procesný diagram (dve verzie), ktoré napomohli nielen lepšiemu

pochopeniu, ale aj pri tvorbe obrazoviek.

Obr. A.5 Sekvenčný diagram pre zápis a riešenie incidentu (aplikačná vrstva)

ries(incident)

: Klient : ASCsluzbaFormIncident FormKlient DBKlient DBIncident

: Expert

PrijemIncidentu()

ZapisIncident()

ZapisKlienta

ZapisNovehoKlienta

OverKlienta

ZapisNovehoKlienta

klient OK

klient NOK

ZapisIncidentu

Klient existuje

Novy klient

zaevidovanie incidentu

overenie

riesenie

riesenie

editovanie udajov

odcitanie kreditov

zaevidovanie experta

- 69 -

Obr. A.6a. Diagram operácií a stavov pre zápis a riesenie incidentu (návrh)

Obr. A.6a Diagram operácií a stavov pre zápis a riešenie incidentu (návrh), 1. verzia

zapis incidentu

zapis udajov o klientovi

nas klientnie je nas klient

vyber z DB expertov podla produktu

vyber z DB expertov podla produktu a OS

vyber z DB expertov podla produktu a OS a kl.slov

mailing

oznamenie klientovi, expertom, ocakavanie vyriesenia a zapisu

V/V formular na login do systemu V/V form na zapis incidentu

ak pojde o noveho klienta,V/V form na zapis jeho nazvu, adresy pracoviska kontakty (mena a tel. cisla)

VAP hotline

zapis kredit(5)zapis kredit (16)

otazka

novy VAP

kredit>0

kredit<=0

zapis kredit(1)

kredit-=body(produkt)

paralelne

kredit--

otazka alebo VAP incident

* novy incident

nema zaujem

niekto novy

kredit <= 0

kredit>0

- 70 -

Nakoniec sa pristúpilo k návrhu obrazoviek pre reporty, riadkový a obrazovkový

prehliadač incidentov. Dopĺňali sa aj o typický príklad v obsahu, pretože vypovedacia

hodnota obrazoviek s prázdnymi výstupmi bola nižšia. V dokumentácii sa popísali množiny

typických a akceptovateľných hodnôt pre jednotlivé prvky, ich formáty a podobne.

Obr. A.7a Obrazovkový report incidentov (je vidieť len jeden incident a všetky jeho atribúty)

Obr. A.7b Riadkový prehliadač incidentov (je vidieť viac incidentov ale nie všetky ich atribúty)

- 71 -

Obr. A.7c Obrazovkový prehliadač incidentov (je vidieť len jeden incident a všetky jeho atribúty)

Obrazovka pre reporty je typický výstupný formulár zo systému, ktorý dostatočne

presne naznačí, ktoré údaje je potrebné uchovávať v databáze. Prehliadače sú už vstupno-

výstupné formuláre, v ktorých je možné incidenty nielen prehliadať ale aj editovať prípadne

zadávať nové.

Podobné návrhy boli vytvorené aj pre prehliadače klienta a expertov.

Návrh DB vrstvy podľa výstupov systému

- 72 -

Po identifikovaní takéhoto dostatočného množstva doménových a aplikačných

objektov je už možné pristúpiť k tvorbe objektového modelu. Prvý diagram popisuje

doménové abstraktné, perzistentné aj aplikačné triedy: Incident, Report a jeho druhy,

Pracovnik a jeho špecializácie (Expert, ASCsluzba, PracovnikKlienta). Novou triedou je tu

Produkt a Klucove slovo, ktoré dopĺňajú incident a podľa ktorých bude vyberaný expert na

riešenie.

Na ďalšom diagrame je vťah n:m medzi expertom, incidentom a kľúčovým slovom

doplnený asociatívnou triedou.

V oboch diagramoch chýba viacero atribútov tried, napríklad ID klienta, Operačný

Systém v incidente a podobne. Tie však nezmenia štruktúru modelu. Už teraz je zrejmé čo je

potrebné ukladať do databázy, objekty sú odlíšené stereotypom <<Persistent>>. Pre

konzistenciu a čitateľnosť modelu sú použité aj doménové triedy (bez stereotypu), abstraktné

triedy (<<Abstract>>) a aplikačné (<<Form>>).

Osoba

MenoAdresatelefonID

<<Abstract>>

PodlaKlienta PodlaObdobia PodlaStavu PodlaTypuRiadkovyObrazovkovy

1..*

*

*

*

ASC

*

KlientASC

Nazov

<<Persistent>1..*

*

Pracovnik

pracoviskoPracTelefonmobile-mailfax

<<Persistent> * KlucoveSlovo

IDKlucovehoSlovaKlucoveSlovo

<<Persistent>>

*

ASCsluzba

(from Use Case View)

*

*

riesitel

Expert

(from Use Case View)

*

*

*

*

Produkt

IDProduktuNazovProduktu

<<Persistent>>

PracovnikKlienta

(from Use Case View)

<<Actor>>

**

*

Incident

IDNazovProduktProblemNahlasilPrijalDatumPrijatiaVyriesilDatumVyrieseniaRiesenieStavTypJazyk

<<Persistent>>

*

**

*

*

Reporty

<<Form>

*

- 73 -

Obr. A.8a Objektový diagram, obsahujúci doménové, aplikačné aj interné triedy

6.1 Návrh vstupov IS podľa … Obr. A.8b Revidovaný objektový diagram

Návrh potrebných vstupov

Keďže si reporty incidentov a prehliadače vyžadujú aj údaje o klientovi, jeho

pracoviskách a kontaktných pracovníkoch, expertoch, produktoch a podobne, je potrebné v

etape návrhu vstupov upresniť formuláre pre vstup údajov o klientovi, expertovi, produkte a

ostatných. Okrem toho bolo potrebné vytvoriť aj vstupné filtre pre reporty (hodnoty atribútov,

štruktúra reportu, utriedenie), ktoré sa tiež ľahko odvodili od výstupného formuláru reportu.

Dôležitým formulárom je vstup údajov o incidente, kde sa nepridalo veľa nových informácií,

len sa rozhodlo, ktoré vstupné polia budú kombinované s ponukou preddefinovaných hodnôt

(označované ako ComboBox – spojenie zoznamu – ListBox so vstupným poľom – EditBox,

alebo TextBox). Po návrhu tohto formuláru sa doplnil objektový model o ďalšie potrebné

Osoba

MenoAdresatelef onID

<<Abstract>>

PodlaKlienta PodlaObdobia PodlaStav u PodlaTy pu

ExpertKluc

IDExpertaIDKlucov ehoSlov a

<<Persistent>>

IncidentKluc

IDIncidentuIDKlucov ehoSlov a

<<Persistent>>

Riadkov yObrazov kov y

1..*

1..*

1..*

1..*

ASC

1..*

KlientASC

Nazov

<<Persistent>1..*

1..*

Pracov nik

pracov iskoPracTelef onmobile-mailf ax

<<Persistent> 1..* Klucov eSlov o

IDKlucov ehoSlov aKlucov eSlov o

<<Persistent>>

*

ASCsluzba

(f rom Use Case View)

1..*

*

riesitel

Expert

(f rom Use Case View)

1..*

1..*

1..*

*

Produkt

IDProduktuNazov Produktu

<<Persistent>>

Pracov nikKlienta

(f rom Use Case View)

<<Actor>>

1..**

*

Incident

IDNazovProduktProblemNahlasilPrijalDatumPrijatiaVy riesilDatumVy rieseniaRiesenieStavTy pJazy k

<<Persistent>>

1..*

**

*

*

Reporty

<<Form>

*

- 74 -

aplikačné triedy pre produkt, pracovníka, experta, klienta, pracovisko klienta, pracovníka

klienta a podobne. Keďže CASE systém (Rational Rose a MS Visio 2000) nedovolil používať

rovnaké názvy tried, hoci mali rôzne stereotypy, bolo nutné ich odlíšiť predponou Zaznam

(Produkt – ZaznamProdukt).

Obr. A.9 Objektový diagram (ďalšie odvodené aplikačné a interné DB triedy)

Osoba

MenoAdresatelefonIDemail

<<Abstract>>

PodlaKlienta PodlaObdobia PodlaStavu PodlaTypu

ExpertKluc

IDExpertaIDKlucovehoSlova

<<Persistent>>

IncidentKluc

IDIncidentuIDKlucovehoSlova

<<Persistent>>

Riadkovy

NovyIncident<<Form>>

EditIncident

ID : EditBoxNazov : EditBoxProdukt : ComboBox...Vyrad : ButtonNovy : Button...

Vyrad ()Novy ()Dalsi ()Predosly ()Prvy ()Posledny ()Zmen ()Najdi ()

<<Form>>

ZaznamExpert<<Form>>

ZaznamASCSluzba<<Form>>

1..*

1..*

1..*

1..*

ASC

1..*

*

Pracovnik<<Persistent>

ZaznamPracovnik<<Abstract>>

1..* KlucoveSlovo

IDKlucovehoSlovaKlucoveSlovo

<<Persistent>>

*

ASCSluzba

(from Use Case View)

1..*

*

riesitel

Expert

(from Use Case View)

1..*

1..*

1..*

*

*

*

Reporty<<Form>

Obrazovkovy

Zaznam<<Form>

Produkt

IDProduktuNazovProduktu

<<Persistent>>

ZaznamProdukt<<Form>>

KontakKl ienta

(from Use Case View)

<<Actor>>

Pracovisko

nazovadresatelefonfax

<<Persistent>>

ZaznamKlient<<Form>>

Incident

IDNazovProduktProblemNahlasi lPrijalDatumPrijatiaVyriesilDatumVyrieseniaRiesenieStavTypJazyk

<<Persistent>>

1..*

**

*

*

*

Kl ientASC

Nazov

<<Persistent>1..*

**

**

*

ZaznamPracovisko<<Form>>

ZaznamKontaktKl ienta<<Form>>

- 75 -

Obr. A.10 Obrazovka pre zápis nového incidentu a jeho editovanie

Obr. A.11 Obrazovka pre vstup údajov o klientovi

- 76 -

Obr. A.12a Obrazovka pre zápis hľadaných hodnôt a obmedzení do filtra pre report incidentu

(Filter hodnôt)

Obr. A.12b Obrazovka pre definovanie štruktúry reportu a triedených atribútov

(Filter štruktúry)

Vytvorenie používateľskej príručky

Používateľská príručka (jej časť je uvedená nepozmenená v prílohe B.) bola

prezentovaná pracovníkom support centra a bol vytvorený aj prvý prototyp aplikácie.

- 77 -

Návrh logickej vrstvy

Logická vrstva by mala zabezpečiť vyselektovanie správnych údajov na výstupy a uloženie

vstupov do tabuliek. Tieto procesy sa dajú odvodiť podľa dátovej a prezentačnej vrstvy.

Okrem toho však vznikla aj potreba upresniť niektoré interné procesy ako vyhľadávanie

expertov podľa produktu a kľúčových slov incidentu a apôsob ovládania.

Obr. A.13 Obrazovka pre naviazanie produktov (alebo kľúčových slov) na experta

Obr. A.14 Obrazovka zabezpečujúca tvorbu a rozosielanie mailu s incidentom správnym expertom

- 78 -

Obr. A.15 Objektový diagram (interné a V/V triedy)

Pracovnik

MenoAdresatelefonIDemail

<<Abstract

PodlaKlienta PodlaObdobia PodlaStavu PodlaTypu

ExpertKluc

IDExpertaIDKlucovehoSlova

<<Persistent>>

IncidentKluc

IDIncidentuIDKlucovehoSlova

<<Persistent>>

RiadkovyObrazovkovy

NovyIncident

<<Form>>

EditIncident

ID : EditBoxNazov : EditBoxProdukt : ComboBox...Vyrad : ButtonNovy : Button...

Vyrad ()Novy ()Dalsi ()Predosly ()Prvy ()Posledny ()Zmen ()Najdi ()

<<Form>>

ZaznamExpert

<<Form>>

ZaznamSluzba

<<Form>>

1..*

1..*

1..*

1..*

ASC

1..*

1..*

ZaznamPracovnik

<<Abstract>>

1..* KlucoveSlovo

IDKlucovehoSlovaKlucoveSlovo

<<Persistent>>

*

ASCsluzba

(from Use Case View)

1..*

*

riesitel

Expert

(from Use Case View)

1..*

1..*

1..*

*

Produkt

IDProduktuNazovProduktu

<<Persistent>>

*

*

MailingForm

PonuknutiExperti : ListboxVybraniExperti : ListboxVyrad : ButtonZarad : ButtonPosli : Button

Posli ()Zarad ()Vyrad ()

<<Form>>

Reporty

<<Form>

Filter

NastavFilter ()SpustiFilter ()ZrusFilter ()

<<Internal>>

FilterForm

<<Form>>

*Pracovisko

NazovAdresaTelefonFax

PracovnikKlienta

(from Use Case View)

<<Actor>>

ZaznamKontaktKlienta

<<Form>>

Import/Export

SQLImport ()SQLExport ()ExcelExport

<<Internal>>

Incident

IDNazovProduktProblemNahlasilPrijalDatumPrijatiaVyriesilDatumVyrieseniaRiesenieStavTypJazyk

<<Persistent>>

1..*

**

*

*

*

KlientASC

Nazov

<<Persisten1..*

1..*

*

Zaznam

<<Form>Mailing

VyberExpertov (ID : Incident)ZasliMail (ID : Incident)

<<Internal>>

ZaznamKlient

<<Form>>

ZaznamPracovisko

<<Form>>

- 79 -

Obr. A.16 Procesný diagram pre zápis a riesenie incidentu (návrh), 2.verzia

* ZapisNovyIncident()

ZapisUdajovKlienta

V/V formulár na zápis incidentu

V/V formular na zápis nového klienta

alebo editovanie názvu,

pracoviska a kontaktu (mená a tel. čísla)

[otázka][hotline][VAP][klient][~klient]

ZapiKredit(20) ZapisKredit(5) ZapisKredit(1)

[nový] [nový][nový] [kredit>0]

[kredit>0]

[kredit<=0][kredit<=0]

[kredit<=0]

vyber expertov z DB podla produktu

vyber expertov z DB podla produktu a OS

vyber expertov z DB podla produktu a OS a kl.slov

poslanie incidentu vybranym expertom

[expertov > k]

[expertov > k]

oznamenie expertom o zaslani incidentu oznamenie klientovi o prijati incidentu ocakavanie riesenia

Zapis riesenia

--kredit kredit -= body(produkt)

[otazka alebo VAP] klient

- 80 -

Viacvrstvový model

Zavŕšením návrhu bolo vytvorenie viacvrstvového diagramu, ktorý nezískal

štandardnú podobu troch sekcií vedľa seba, ale podobu organicky začlenených oblastí: dátová

vrstva je na spodnej časti diagramu a logická je umiestnená v centre prezentačnej vrstvy. Na

ne v treťom rozmere nadväzujú rezy, v ktorých sú znázornené jednotlivé scenáre využitia

modelu: zápis nového incidentu, prezeranie incidentov, reporty a podobne. V týchto rezoch je

vidieť využitie tried a indikuje, ktoré triedy treba pozmeniť, ktoré (nevyužité) vyradiť a ktoré

vytvoriť.

Obr. A.17 Viacvrstvový objektový diagram intranet/internet aplikácie Support Server

Schématicky v zmenšenom merítku približne 1:5 je uvedený viacvrstvový objektový diagram,

scenár zápisu nového klienta a scenár nastavenia a generovania reportov na obr. A.17-A.19.

- 81 -

Je z nich zrejmá ohraničená DB vrstva v spodnej časti a veľká mikroprocesná ASP trieda v

centre diagramu, zabezpečujúca väčšinu interných operácií.

Obr. A.18 Komunikačný diagram - scenár

Zápis nového klienta

Obr. A.19 Komunikačný diagram - scenár

Nastavenie a generovanie reportov

- 82 -

Z predchádzajúcich obrázkov je zrejmé, že nie každý scenár používa všetky triedy. Pre

skúmanie scenára samostatne je v prípade potreby vhodné konvertovať ho do sekvenčného

diagramu.

Nedostatky a možnosti zlepšenia

Pri tvorbe viacvrstvového diagramu boli zistené nasledovné poznatky a nedostatky

tohto postupu:

1. Číslovanie správ v jednotlivých scenároch je zložité, hoci zachytáva aj

paralelizmus a vetvenie, a jednoznačne určuje postupnosť a môže slúžiť aj pre

prípadné generovanie metód. Jednotlivé rezy boli vytvorené v CASE systéme MS

Visio 2000, bola by však vhodná aj animácia interakcií, ako tomu je napríklad v

CASE/4/0 od spoločnosti Microtool.

2. Je potrebné odlišovať paralelizmus a vetvenie, pre paralelné interakcie budú

priraďované veľké písmená A..X, pre vetvenie male písmená a..x, pri

premenlivom počte a cykle je možné použiť podmienku *(i=1..n) podľa [Fowler

MM] a [Semantics 97].

3. Pri takejto zložitosti nie je možné používať obojsmerné prepojenie a správy s navi-

gáciou (šípkou) pre naznačenie smeru správy, každá správa má vlastné prepojenie

od triedy k triede s navigáciou smeru pri konektore.

4. Na označenie stereotypov bolo použité značenie <…> namiesto << … >> , čo je

nedorozumenie a chyba, spôsobená aj možnosťami ešte príliš nového CASE

systému MS Visio 2000.

5. Udalosť a operácia na hrane sú oddeľované lomítkom, ak udalosť chýba, operácii

nepredchádza lomítko v snahe o zjednodušenie, čo je tiež nesprávne.

6. V diagramoch boli použité nasledovné stereotypy interakcie: <<user

interaction>> - aktivita používateľa (vyplňovanie formulára, zadávanie údajov),

<<return>> - návrat hodnoty alebo referencie, <<redirect>> - presmerovanie

riadenia na inú adresu alebo dialóg, <<call>> - vyvolanie metódy iného objektu –

inej stránky, <<create>> - vytvorenie ďalšej inštancie, napríklad aktívnej stránky

servera.

- 83 -

7. Scenáre takto zapísané nad nemennou objektovou štruktúrou, kde sa mení v reze

len postupnosť interakcií, nie je vždy prehľadná pre zložitosť a veľkosť modelu.

Ak by sa nezotrvávalo na nemennej štruktúre objektového podkladu

komunikačného diagramu, potom by scenár pokrýval priemerne 50% pôvodnej

plochy, avšak pri strate pevných pozícií jednotlivý tried a tým možnosti

komparácie scenárov dynamického modelu a objektového modelu v trojrozmernej

schéme. Na obrazovke počítača pri 13xA4 je to nemožné. Vhodnejšie a

opodstatnené je toto trojrozmerné vrstvenie pri jednoduchších diagramoch na

jeden list najmä v analýze. Zo skúseností však vyplýva, že na záver je nutné

vytvoriť aj takéto komplexné a veľkorozmerné modely. Ďalšou možnosťou je

požiadať CASE systém nielen o zhodnotenie jednotlivých scenárov (využitie tried,

hľadanie vágnych a redundantných štruktúr a podobne), ktoré nie je možné

interaktívne na obrazovke vykonať, ale aj o vygenerovanie tela metód podľa

volania ďalších metód v správach, ako aj vytvorenie sekvenčných diagramov ako

iného pohľadu na ten istý obsah a štruktúru pre lepšiu čitateľnosť v niektorých

prípadoch. Ďalšou možnosťou je vytvoriť katalóg dôležitých rozdelení toku

interakcií pri vetvení a paralelizme. Incidenčné matice a rozhodovacie tabuľky sa

pre tento prípad nezdajú ako najvhodnejší doplnok.

3D Diagram

Najprv teda vytvoríme jednotlivé scenáre, v ktorých vytvárame len také triedy, ktoré

potrebujeme a nakoniec samotný objektový model len z využívaných tried. Takáto je

zjednodušená filozofická koncepcia prístup. V skutočnosti sme na tvorbu použili MS Visio

2000, v ktorom je možné vytvárať takéto rezy nad objektovým diagramom. Každú potrebnú

triedu sme najprv zapísali do bázickej vrstvy a až potom sme ju využívali v ďalších rezoch, v

ktorých sme určovali, ktoré triedy z bázickej vrstvy sa môžu zobraziť.

- 84 -

Obr. 4 Schéma 3D modelu z ilustračného príkladu reálneho projektu

- 85 -

Optimalizácia návrhu

Optimalizácia bola vykonaná v návrhu DB vrstvy, v návrhu logickej vrstvy a pri

tvorbe viacvrstvového modelu, počas všetkých troch iterácií podľa pravidiel konzistencie,

eliminácie nevhodných tried a revidovanej normalizácie štruktúry tried.

Poznámka

V tejto dokumentácii boli použité skutočné vybraté diagramy z analýzy a návrhu. Prvotné V/V obrazovky sa

však nedochovali pre neustálu aktualizáciu originálneho dokumentu v jednotlivých iteráciách vývoja systému

(dokonca aj v tejto kapitole boli použité dialógy z dvoch rôznych iterácií). Návrh bol implementovaný v

intra/internet prostredí technológiou ASP (Active Server Pages) v jazykoch Java a Visual Basic Script nad

SRBD MS SQL Server.

Dobrá postupnosť by mala odstrániť komunikačnú priepasť medzi používateľom a

analytikom, návrhárom a implementátorom ako aj medzi analýzou, návrhom a

implementáciou. Mala by byť natoľko konzistentná a stmeľujúca, aby nedochádzalo k

zbytočnej strate informácií a ich neželanej zmene. Mala by ponúknuť analytikovi, návrhárovi

aj implementátorovi možnosť využiť ju a zachovať tok informácií v priestore medzi nimi aj v

čase pri vývoji produktu.

Predkladaná alternatívna postupnosť pre UML bola navrhnutá práve tak, aby vytvárala

predpoklady pre konzistentný vývoj, kde každý nasledujúci krok obsahuje všetky prvky IS z

predošlého kroku a aby sa výsledný produkt neodklonil od vyjadrených požiadaviek

používateľa.

Zachovanie prvkov IS je podporované vo všetkých krokoch a prechodoch medzi nimi:

1. Konceptualizácia –> analýza: v konceptualizácii vytvárame konceptuálny diagram na

základe zozbieraných zoznamov požiadaviek, inicializačných udalostí a používateľov

systému. V analýze vytvárame jednotlivé scenáre podľa inicializačných udalostí. Udalosti

vstupujú do jednotlivých služieb, ktoré prekrývajú požiadavky používateľa a keďže

služby obsahujú najmenej jednu inicializačnú udalosť, nie je možné aby službu ďalej

nezastupoval spoň jeden poddiagram. Tu sú teda informácie zachované a rozvíjané ďalej.

2. Analýza –> návrh výstupov, db vrstvy a vstupov. Každá požiadavka, zastúpená službou a

rozpísaná poddiagramom, komunikuje a preto potrebuje určité vstupno-výstupné

- 86 -

rozhranie. Vo výstupnom rozhraní sa objavia všetky potrebné prvky, tak ako aj v

navrhovanej db vrstve, kde je nevyhnutné všetky perzistentné informácie uchovať.

Vstupné rozhranie zabezpečuje možnosť naplniť všetky potrebné prvky a vyhovieť tak

fungovaniu služby. Tento postup preto nevedie ku strate prvkov, ale k jeho zachovaniu.

3. Návrh V/V a DB –> návrh logickej vrstvy, doplnenie DB. Tu je model IS dopĺňaný o

ďalšie triedy a vzťahy, ktoré zabezpečujú prepojenie výstupného rozhrania, db vrstvy a

vstupného rozhrania a preto nemôžu tieto kroky viesť k divergencii, ani k úbytku prvkov,

ale práve naopak, k ich doplneniu.

4. Viacvrstvový model, model komponentov a rozmiestnenia: tento krok sa taktiež vracia k

modelu z predošlých krokov a zobrazuje inak jeho štruktúru, prípadne ju optimalizuje. Tu

zanikajú doménové objekty, čo ale nespôsobuje stratu prvkov IS, pretože štruktúra

doménových objektov sa odzrkadlila v aplikačných a mikroprocesných, ktoré si ju

pamätajú, zachovávajú a rozširujú.

5. Implementácia, testovanie a ladenie už len zachovávajú navrhnutú štruktúru, aj vďaka

overovaniu funkčnosti priamo používateľom a testom, popísaným pri tvorbe prototypu IS

v používateľskej príručke.

Zachovanie vyjadrených požiadaviek používateľa je podporené v štyroch krokoch:

1. prvý raz sú vyjadrené a zapísané v konceptualizácií,

2. overené a dopĺňané v analýze pri tvorbe všetkých modelov služieb (najmä scenárov v

dynamickom modeli) v spolupráci s používateľom,

3. v kroku Vytvorenie používateľskej príručky sú konfrontované výsledky z etapy návrhu

aplikačnej vrstvy a správania sa systému, tu je prípadná divergencia výsledkov od

očakávania špecifikovaná a návrh sa opakuje pokiaľ nie je predstava používateľ splnená,

4. nakoniec sú výsledky návrhu mikroprocesnej vrstvy (dátová a logická vrstva) testované a

ladené po implementácii.

99