Objektovo-orientovaný prístup a jeho vlastnosti

Transcript

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é - 2 -

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. PrijmyZiadost()). 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 - 3 -

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, - 4 -

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 - 5 -

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 Objektový prístup výhody ŠP výhody OP (ŠP) (OP) Entiry Relationship Diagram tried a explicitná silnejšie pros- Diagram (Dátový Objektový diagram normalizácia triedky (dedenie, model) (Objektový model) agregácia, ) Data Flow Diagram OO DFD sa zväčša (súčasť Funkčného nepoužíva, používa sa modelu, ako aj Collaboration - 6 -

7 nasledujúce diagramy) Entity Life History, State Transition Diagram Vývojový diagram JSD, YSD, NSD, HIPO Diagram (UML) State Diagram Activity Diagram 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 prezentač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 prezentač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ú, prezentač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, - 9 -

10 3. návrh výstupov služieb a systému, vytvorenie alebo doplnenie prezentačnej vrstvy, 4. návrh DB vrstvy podľa výstupov, 5. návrh vstupov, ktoré vyžaduje DB vrstva, doplnenie prezentačnej vrstvy, 6. vytvorenie prázdneho prototypu a používateľskej príručky, obsahujúcej celú prezentač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. 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. 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

12 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ý) Analýza Objektový Konceptuálny Dynamický Logický Funkčný (Fyzický) Návrh Objektový Logický Dynamický Fyzický Funkčný Doménová Doménová Prezentačná (Mikroprocesná) Doménová Prezentač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 prezentač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 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

13 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 číslované podľa poradia), prípadne explicitné vyjadrenie, že model nie je pre danú službu potrebný),

14 Príklad štruktúry a obsahu katalógu: ID požiadavky: POZ001 Názov: Zápis incidentu Dátum zadania: Priorita: A Stupeň zložitosti: - Charakteristika: zápis incidentu do MS SQL DB hneď pri jeho nahlásení Dátum spustenia: 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: Priorita: B Stupeň zložitosti: problém vytvorenia pravidlového systému a previazanie s dátovou vrstvou MS SQL a prezentačnou ASP Charakteristika: vyhľadanie experta podľa pravidiel Dátum spustenia: 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 Atribúty: ID, meno, telefón, ID: POU

15 Názov: Typ: Charakteristika: Atribúty: Klient Actor Klient obsahuje triedy Pracovisko a Kontaktna osoba ID, názov, adresa, telefón,fax, 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. 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í

16 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é podrobnejš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 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

17 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 prezentač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 prezentač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 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é

18 identifikovať a pomáhať si touto štruktúrou v ďalšom kroku, v ktorom používateľ definuje potrebné V/V triedy prezentač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. 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

19 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). 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

20 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ť prezentač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, 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,

21 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á->prezentač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, 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

22 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 prezentač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 prezentač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 prezentač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 prezentač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 prezentač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ť prezentačná vrstva bez vytvorenia nadbytočných vstupov. Vzniknú tak aj úplné vstupnový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 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é

24 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 prezentač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 prezentač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 {D i 1 i n} neprázdnych množín (domén). Potom podmnožinu karteziánskeho súčinu R D 1 x D 2 x x D n nazývame reláciou stupňa n (n-árnou reláciou) nad D 1, D 2,, D n. Prvky R sú usporiadané n-tice < d 1, d 2,, d n > také, že d i D i 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 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 specializacia > nadtrieda NenormalizovanaTrieda <<creates>> 2..n NormalizovanaTrieda * podtrieda * * Atribut casto nevyuzity, prechádza do podtriedy Atribut Klucovy Zavisly Nezavisly Klucovy Zavisly 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 Nazov DatumVydania Vydavatel ISBN Clanok Rocnik Cislo Nazov Zbornik NazovKoneferencie Datum MiestoKonania Kniha Ucebnica Skripta Ucet CisloUctu IDVlastnika UrocenieKreditu Stav Doklad ID datum vystavil adresat text termin Bezny VyskaPovDebetu UrocenieDebetu Terminovany Splatnost UcetPreUrok Vypoved dovod Prijatie funkcia nastupny 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 asociacia agregacia > OR NenormalizovanaTrieda <<creates>> * Agregujuca 2..n NormalizovanaTrieda * * Agregovana * casto sa opakuje hodnota, prechádza do agregujucej * Atribut Atribut Klucovy Zavisly Nezavisly Klucovy Zavisly 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 ID RC * * 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 Objednávka ID text datum adresat vystavil odosielatel Faktúra ID text datum adresat vystavil odosielatel Sklad * Hala MnozstvoUlozeneho mnozstvo * Polozka ID text mj mnozstvo cena * Polozka ID text mj mnozstvo cena * Tovar ID nazov mj Obr. 7a Optimalizácia štruktúry pre objednávku, faktúru, tovar na sklade Zamestnanec ID RC * * Dieta ID RC Zamestnanec ID RC pracuje na * * Projekt ID Nazov Veduci Prispevok poberaprispevok Odpracovane odpracovanehodiny Zamestnanec ID RC pracuje pre * * Firma ICO DICO Nazov Firma ICO DICO Nazov * * Tovar ID nazov mj Funkcia Funkcia Prijem MnozstvoDodavaneho mnozstvo 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 XAtribut1 XAtribut2... XAtributN SpolocnyAtribut1 SpolocnyAtribut2... SpolocnyAtributN Y YAtribut1 YAtribut2... YAtributN SpolocnyAtribut1 SpolocnyAtribut2... SpolocnyAtributN <<creates>> XY SpolocnyAtribut1 SpolocnyAtribut2... SpolocnyAtributN Xderiv XAtribut1 XAtribut2... XAtribut N Yderiv YAtribut1 YAtribut2... YAtribut N 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 XAtribut1 XAtribut2... XAtributN SpolocnyAtribut1 SpolocnyAtribut2... SpolocnyAtributN Y YAtribut1 YAtribut2... YAtributN SpolocnyAtribut1 SpolocnyAtribut2... SpolocnyAtributN <<creates>> Xderiv XAtribut1 XAtribut2... XAtributN Yderiv YAtribut1 YAtribut2... YAtributN * XY SpolocnyAtribut1 SpolocnyAtribut2... SpolocnyAtributN * 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 prezentač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á, prezentač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 prezentač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, prezentač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 prezentač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 Produkt : EditBox 1: PridajProdukt() 4: VyznacText() 2: VratProdukt() 3: ZaradProdukt() Pridaj : PushButton Zoznam : Listbox : Pouzivatel 5: [nepristupny] Uvolni() Vyrad : PushButton Pridaj::PridajProdukt() { Produkt.VratProdukt(); Zoznam.ZaradProdukt(); Produkt.VyznacText(); if (Vyrad.Nepristupny()) Vyrad.Uvolni(); } Obr. 11a Scenár metódy PridajProdukt() objektu Pridaj triedy PushButton (komunikačný diagram)

47 : Pouzivatel Pridaj : Push Button Produkt : Edit Box Zoznam : Listbox Vyrad : EditBox PridajProdukt VratProdukt ZaradProdukt VyselektujText [nepristupny] uvolni 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 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 prezentač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ň, prvok i ) { ZapíšDoKódu(úroveň, prvok i ) ak (existuje podriadený prvok ik ) ak (prvok i je funkcia alebo existuje viac ako jeden podriadený prvok ik ) { ZapíšDoKódu(úroveň, BEGIN) BEGIN je { alebo begin a pod. } pokiaľ (existuje nezapísaný podriadený prvok ik ) Zapíš(úroveň+1, prvok ik ) ZapíšDoKódu(úroveň, END) } inak Zapíš(úroveň+1, prvok ik ) END je } alebo end

50 a b c [while(not EndOfTasks())] [endwhile] Obr. 11c Príklad zápisu riadiacej štruktúry v sekvenčnom diagrame nasledovne: Program pre generovanie zdrojového kódu z interaktívneho diagramu by mohol vyzerať pre všetky objekty o v interakčnom diagrame { pokiaľ existuje volanie metódy m j () objektu o i volanej z objektu o a { ak neexistuje o i.m j () vytvor o i.m j () 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 o i ) (a teda nenastal explicitný koniec metódy a začiatok inej) pokiaľ (existuje volanie z o i metódy m jk () objektu o b } } zapíš o b.m jk () do o i.m j ()

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ä prezentač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 áno konceptuálny (z používateľa; komponenty zo služby) áno (z atribútov používateľa) áno (funkcie a možnosti používateľa) áno áno áno objektový áno áno interaktívny (potrebné pre komunikáciu) (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ň prezentač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ň prezentač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 : Zadavatel : Konceptualny model : Objektovy model : Interaktivne diagramy : Stavovy diagram : Funkcny model : V/V formulare Zaznamenaj pouzivatelov Vytvor katalog pouzivatelov Zaznamenaj poziadavky Vytvor katalog poziadaviek Zaznamenaj inicializacne udalosti Vytvor katalog in. udalosti Vytvor konceptualny diagram sluzby splnaju jednotlive poziadavky Zapis pouzivatelov ako triedy Zapis sluzby ako komponenty 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 : Konceptualny model : Objektovy model : Interaktivne diagramy : Stavovy diagram : Funkcny model : V/V formulare 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 dopĺňa prezentačnú a mikroprocesnú vrstvu v dynamickom, objektovom a funkčnom modeli

57 : Pouzivatel : Konceptualny model : Objektovy model : Interaktivne diagramy : Stavovy diagram : Funkcny model : V/V formulare Vytvor/aktualizuj vystupy pre sluzbu Vytvor/aktualizuj aplikacnu vrstvu Vytvor/aktualizuj datovu vrstvu podla vystupov Vytvor/aktualizuj vstupy podla datovej vrstvy Dopln aplikacnu vrstvu Dopln logicku vrstvu pre vystupy Dopln logicku vrstvu pre vstupy 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 Vytváranie/dopĺňanie katalógov a konc. diagramu ako KONCEPTUALIZÁCIA Katalóg požiadaviek Katalóg používateľov Katalóg inicializačných udalostí Konceptuálny diagram Vytváranie/dopĺňanie poddiagramov služieb ako ANALÝZA Diagram interakcií pre scenáre služby, stavový diagram pre dyn. službu a triedy Dynamický model Objektový model Funkčný model Pre metódy objektov [zmena, oprava alebo doplnenie] [Potrebná oprava zmena doplnenie] Výstupy IS Návrh DB Aplikačná vrstva modelov Podľa aplikačnej vrstvy NÁVRH Vstupy IS Prototyp IS v používateľskej príručke Podľa dátovej vrstvy a jej modelov použitá aplikačná vrstva [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 Implementácia, testovanie a ladenie [Funkčný IS] 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 nahlasenie: telefonom/mailom Klient Opakujúce sa cinnosti prezeranie zapis a update ASCsluzba nahlasenie PracovnikKlienta report pre klienta prezeranie a update 1.zapis a evidencia incidentov update a kontrola Expert 4. riesenie a mailing vedenie 2. evidencia klientov a pracovnikov podla obdobia podla klienta podla stavu podla typu 3. reporty 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,

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) nahlasenie: telefonom/mailom Klient Opakujúce sa cinnosti prezeranie zapis a update ASCsluzba 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... nahlasenie PracovnikKlienta report pre klienta prezeranie a update Expert 1.zapis a evidencia incidentov 4. riesenie a mailing update a kontrola vedenie 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 2. evidencia klientov a pracovnikov podla obdobia podla klienta podla stavu podla typu 3. reporty C. dalsie poziadavky: 1. blacklist neplaticov, 2. editovanie kontaktnych osob klientom 3. vyhladavanie rieseni (UI) 4. prijem strukturovanych mailov a aut. zaevidovanie incidentu, 5. hladanie riesenia podla vyriesenych klientom 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,

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 Záujemca klient ASC Ek. oddelenie GTI Back Up MS Back Up Otázka alebo ziadost o zmluvu Kontrola ciernej listiny Ak má otázku, ale nemá zmluvu, zapíšu sa všetky potrebné údaje (osoba a tel. cislo, prip. ICO a pod.) Ak je jednoduchá otázka, odpoved Údaje pre zmluvu Zmluva Podpísaná zmluva Potvrdenie Update ciernej listiny Ak klient vráti podpísanú zmluvu, prípadne po zaplatení, je vymazaný z ciernej listiny Zapis do DB klientov Obr. A.2b Sekvenčný diagram pre zápis a eskaláciu incidentu klienta (doménové objekty)

65 Klient ASC Ek. oddelenie GTI Back Up MS Back Up ID, ID zmluvy/série, otázka Overenie ID, ID zmluvy/série Telefonát, mail, fax Všetky odpovede pre rýchlost telefonicky, zároven faxom pre dokumentáciu Ak vyriešené, odpovedá Okamzite, v rámci telefonátu Koniec telefonátu Koniec telefonátu Ak vyriešené, Hladanie riešenia odpovedá, inak vysvetluje další postup Telefonát do 1, 2 hodín Eskalácia problému Riešenie, alebo rieši Ak neprišla uspokojivá odpoved a všetci neodpovedali Upozornenie po 12 hodinách Riešenie Pre neodpovedajúcich riešiacich Upozornenie po 18 hodinách Riešenie Odpoved alebo oznámenie eskalácie do MS Telefonát do 1, 2 dní Eskalácia problému Riešenie Odpoved z MS Upozornenie Pri predposlednej a poslednej odpovedi zo série, alebo Mesiac/týzden pred vypršaním rocnej/mesacnej zmluvy Obr. A.2a Sekvenčný diagram pre zápis incidentu nového záujemcu (doménová vrstva)

66 Novy incident Oznameny entry: OverIncident exit: UrciTypIncidentu [ ziadost o informacie ] [ omyl ] [ Incident OR Onsite ] [ Otazka ] Zapisany entry: Zapis entry: UrciExpertov Experti najdeni Informacie Eskalovany entry: PosliExpertom do: KontrolaEskalacie exit: OznamKlientovi incident odoslany Rieseny entry: Riesenie [ riesenie najdene ] [ riesenie nenajdene ] Vyrieseny entry: ZapisRiesenia riesenie zapisane a doplnene Archivovany entry: Oznam Obr. A.3 Stavový diagram pre triedu incident

67 zaujemca o support sa na nas obrati zistovanie udajov o incidente incident je riesitelny zistovanie udajov o zaujemcovi zaujemca je nas zakaznik alebo je VAP alebo ide o otazku, informaciu alebo vnutorny hotline zapis udajov o incidente udaje zapisane zaujemca nie je a ani nechce byt nasim klientom hladanie riesitela riesitel najdeny zapis incidentu incident uzatvoreny riesenie incidentu 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 prezentač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

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. : Klient : ASCsluzba FormIncident FormKlient DBKlient DBIncident : Expert PrijemIncidentu() ZapisIncident() ZapisKlienta OverKlienta klient OK Klient existuje klient NOK ZapisNovehoKlienta Novy klient ZapisNovehoKlienta ZapisIncidentu zaevidovanie incidentu ries(incident) overenie zaevidovanie experta riesenie odcitanie kreditov riesenie editovanie udajov Obr. A.5 Sekvenčný diagram pre zápis a riešenie incidentu (prezentačná vrstva)

69 Obr. A.6a. Diagram operácií a stavov pre zápis a V/V riesenie formular na incidentu login do systemu (návrh) * novy incident V/V form na zapis incidentu nema zaujem zapis incidentu zapis udajov o klientovi ak pojde o noveho klienta, V/V form na zapis jeho nazvu, adresy pracovisk a kontakty (mena a tel. cisla) nie je nas klient nas klient kredit<=0 VAP hotline otazka novy VAP kredit <= 0 zapis kredit (16) kredit>0 zapis kredit(5) kredit>0 niekto novy vyber z DB expertov podla produktu zapis kredit(1) vyber z DB expertov podla produktu a OS mailing vyber z DB expertov podla produktu a OS a kl.slov oznamenie klientovi, expertom, ocakavanie vyriesenia a zapisu paralelne otazka alebo VAP incident kredit-- kredit-=body(produkt) Obr. A.6a Diagram operácií a stavov pre zápis a riešenie incidentu (návrh), 1. verzia

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ž vstupnový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 prezentačných objektov je už možné pristúpiť k tvorbe objektového modelu. Prvý diagram popisuje doménové abstraktné, perzistentné aj prezentač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 prezentačné (<<Form>>). <<Persistent>> Incident ID Nazov Produkt Problem Nahlasil Prijal DatumPrijatia Vyriesil DatumVyriesenia Riesenie Stav Typ Jazyk * * * * <<Persistent> 1..* KlientASC Nazov ASC * riesitel * Expert (from Use Case View) * <<Actor>> PracovnikKlienta (from Use Case View) * ASCsluzba (from Use Case View) <<Form> Reporty <<Persistent>> Produkt IDProduktu NazovProduktu <<Abstract>> Osoba Meno Adresa telefon ID * <<Persistent>> <<Persistent> * KlucoveSlovo Pracovnik IDKlucovehoSlova pracovisko KlucoveSlovo PracTelefon mobil fax Obrazovkovy Riadkovy PodlaKlienta PodlaObdobia PodlaStavu PodlaTypu

73 Obr. A.8a Objektový diagram, obsahujúci doménové, prezentačné aj interné triedy <<Persistent>> Incident ID Nazov Produkt Problem Nahlasil Prijal DatumPrijatia Vyriesil DatumVyriesenia Riesenie Stav Typ Jazyk * * * * <<Persistent> 1..* KlientASC Nazov ASC 1..* riesitel 1..* Expert (from Use Case View) 1..* <<Actor>> PracovnikKlienta (from Use Case View) 1..* ASCsluzba (from Use Case View) <<Form> Reporty <<Persistent>> Produkt IDProduktu NazovProduktu <<Abstract>> Osoba Meno Adresa telefon ID 1..* <<Persistent>> <<Persistent> 1..* KlucoveSlovo Pracovnik IDKlucovehoSlova pracovisko KlucoveSlovo PracTelefon mobil fax Obrazovkovy Riadkovy PodlaKlienta PodlaObdobia PodlaStavu PodlaTypu <<Persistent>> IncidentKluc IDIncidentu IDKlucovehoSlova 6.1 Návrh vstupov IS podľa Obr. A.8b Revidovaný objektový diagram <<Persistent>> ExpertKluc IDExperta IDKlucovehoSlova 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é

74 prezentač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). <<Persistent>> Incident ID Nazov Produkt Problem Nahlasil Prijal DatumPrijatia Vyriesil DatumVyriesenia Riesenie Stav Typ Jazyk * * * * * <<Persistent>1..* KlientASC Nazov * <<Persistent>> Pracovisko nazov adresa telefon fax * ASC <<Actor>> KontakKlienta (from Use Case View) 1..* riesitel Expert 1..* (from Use Case View) 1..* ASCSluzba (from Use Case View) Obrazovkovy <<Form> Reporty Riadkovy <<Form>> ZaznamProdukt <<Persistent>> Produkt IDProduktu NazovProduktu <<Abstract>> Osoba Meno Adresa telefon ID <<Persistent> Pracovnik PodlaKlienta PodlaObdobia PodlaStavu PodlaTypu 1..* <<Persistent>> 1..* KlucoveSlovo IDKlucovehoSlova KlucoveSlovo <<Persistent>> ExpertKluc IDExperta IDKlucovehoSlova <<Form> Zaznam <<Persistent>> IncidentKluc IDIncidentu IDKlucovehoSlova <<Form>> ZaznamPracovisko <<Form>> NovyIncident <<Form>> EditIncident ID : EditBox Nazov : EditBox Produkt : ComboBox... Vyrad : Button Novy : Button... <<Form>> ZaznamExpert <<Abstract>> ZaznamPracovnik <<Form>> ZaznamASCSluzba <<Form>> ZaznamKlient <<Form>> ZaznamKontaktKlienta Vyrad () Novy () Dalsi () Predosly () Prvy () Posledny () Zmen () Najdi () Obr. A.9 Objektový diagram (ďalšie odvodené prezentačné a interné DB triedy)

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