Príloha A Základné prvky a vlastnosti objektového prístupu, ich notácia a implementácia

Transcription

1 Príloha A Základné prvky a vlastnosti objektového prístupu, ich notácia a implementácia A.1 Trieda ako typ Množinu objektov s rovnakými vlastnosťami (atribútmi a metódami), reprezentuje ich formalizovaná abstrakcia trieda (class). Skutočný výskyt objektu v reálnom svete alebo v behu programu sa nazýva aj inštancia (inštancia triedy). Trieda je z programátorského hľadiska používateľsky definovateľný typ. To znamená, že projektanti, ktorí používajú OO prístup, môžu zadefinovať triedu, chápať ju ako dátový typ obsahujúci atribúty a metódy a vytvárať premenné tohoto typu (tejto triedy), objekty danej triedy. Obr. A.1.1 Bežný grafický zápis triedy alebo objeku, blízky štandardným OO notáciám Vo všetkých známych OO metodológiách sa znázorňuje trieda ako obrazec, obsahujúci tri diely: 1. diel identifikácie, kde je uložený názov triedy alebo objektu, 2. diel atribútov, kde je uložený zoznam atribútov a pre každý je uvedené: a. prístupnosť (v UML: - ako private, # ako protected, + ako public) b. názov atribútu, c. typ atribútu (int, date, string, char[8], ale aj zložitejší typ, prípadne trieda, smerník, ), d. inicializačná hodnota (väčšinou konštanta celočíselná, reálna, reťazcová, prípadne smerník a podobne), 3. diel metód, kde je uložený zoznam metód. Metódy sú uvedené v riadkoch, ktoré obsahujú: a. prístupnosť metódy, b. názov metódy, c. zoznam parametrov v zátvorke, kde je uvedený i. názov parametra, ii. typ parametra (ako v predchádzajúcom), iii. inicializačná hodnota (ako v predchádzajúcom), d. typ návratovej hodnoty, dôležitý najmä pri funkciách. 1

2 Môžu sa vyskytovať objekty, ktoré neobsahujú atribúty a/alebo funkcie, prípadne nie sú uvedené pre väčšiu čitateľnosť. Aj na obr. A.1.1 bol vynechaný zoznam fiktívnych parametrov ostatných metód (okrem prvej) pre lepšiu prehľadnosť. Zoznam argumentov by sa tam opakoval. Konkrétny príklad na triedu a jej štruktúru je uvedený na obr. A.1.2 Dôležitým objektom v IS je doklad. Môže ním byť faktúra, objednávka, príjemka, výdajka, pracovná zmluva, zápis z porady, výpoveď pracovníkovi a podobne. Obr. A.1.2 Doklad ako trieda V príklade je uvedená trieda Doklad, ktorá obsahuje atribúty: 1. ID identifikačné číslo dokladu podľa predpisov organizácie, OID (Object ID), ktorý je automaticky priradený objektu, nie je využitý práve pre existenciu konkrétnych predpisov organizácie, ID môže byť tak štruktúrované (ISO 9001), že by bolo vhodnejšie vytvoriť samostatný typ, 2. Datum dátum vystavenia, je typu Date, môže to byť štruktúra, ale aj objekt so špecifickými metódami (odčítanie dátumov, zistenie dňa v týždni a podobne), 3. Vystavil obsahuje smerník na objekt Zamestnanec, ktorý vystavil daný dokument, 4. Adresat obsahuje smerník na organizáciu, ktorej je dokument vystavený a odposlaný. Doklad obsahuje metódy 1. Vypis( ) vypíše na obrazovku, prípadne vytlačí na tlačiarni doklad, s jeho atribútmi, uvedenými skôr a v predpísanom formáte a spôsobe, ktorý predpisuje algoritmus v metóde Vypis() (obsahuje parameter _date typu Date, ktorý ak nezadáme, bude tlačený okamžite, inak v čase, ktorý uvedieme ako parameter funkcie), 2. Uloz() uloží objekt Doklad do databázy, 3. Zrus() zruší objekt z databázy, 4. Zmen( ) zmení vybraté atribúty objektu (nemožno ich zmeniť priamo). Okrem týchto navrhnutých metód vznikajú aj metódy vyvolané pri vytvorení a zrušení objektu triedy a nazývajú sa konštruktor a deštruktor. Analytik o nich väčšinou neuvažuje a ponecháva to na implementáciu. Kompilátor jazyka C++ ich vytvára automaticky, ale je možné prekryť ich aj vlastnoručne napísanými, najmä ak chceme vykonať určité špeciálne funkcie a algoritmy pri vytvorení a zániku objektu (napr. nastavenie hodnôt inštančných premenných, alokácia a uvoľnenie pamäte, otvorenie a zatvorenie súboru). V C++ majú rovnaký názov ako trieda objektu, deštruktor má znak ~ pred menom na odlíšenie od 2

3 konštruktora. Konštruktorov môže byť aj viac, líšia sa zoznamom parametrov a samozrejme kódom. Implementácia triedy v C++ sa vykoná pomocou kľúčového slova class a jej atribúty a funkcie sa uzatvárajú ako štruktúra v zátvorkách { a }, ktoré ohraničujú začiatok a koniec definície triedy: class Doklad { protected: Long ID; Date Datum; Zamestnanec *Vystavil; Firma *Adresat; private: String *Obsah; public: Boolean Vypis(Date _date = SysDate) {... }; void Uloz() {... }; void Zrus() {... }; Boolean Zmen(Firma *_adresat, Date _datum, Zamestnanec *_vystavil, String *_obsah) { //... }; }; Často okrem metódy Zmen() (alebo Update()) môžeme vytvoriť aj metódy, ktoré vrátia (napr. VratAT() alebo GetAt()) alebo nastavia (napr. NastavAT( ) alebo SetAt( )) hodnoty atribútu At, keďže ten je najčastejšie neviditeľný, neprístupný (private alebo protected). Niektoré CASE systémy to robia automaticky. Vytvorenie objektu takejto triedy je potom identické definovaniu premennej typu tejto triedy: Doklad prac_zmluva, vypoved; Doklad Faktura[12]; Doklad *doklad; V príklade sú vytvorené objekty prac_zmluva, vypoved, pole 12 objektov s názvom Faktura, ku ktorým sa pristupuje ako k členom poľa Faktura[0] až Faktura[11]. V treťom riadku je vytvorený smerník doklad, ktorý môže uchovávať adresy na objekty tohto typu, prípadne jeho špecializované deriváty. Pri vytvorení týchto objektov bol zavolaný implicitný konštruktor, ktorý neobsahoval žiadne predpísané kroky (navrhnuté analytikom a implementované programátorom), neuvažovalo sa o vyvolaní špeciálneho konštruktora, ktorý by naplnil atribúty objektu, alokoval ďalšie miesto v pamäti, otvoril súbory, DB tabuľky, zaslal správu a podobne. Po vytvorení objektov možno napĺňať ich atribúty priamo, ak sú public, alebo nepriamo cez metódy, čo je považované za štandard. Metódy objektu sa vyvolajú ich uvedením za menom vytvoreného objektu, bodka slúži ako operátor prístupu, pri smerníku na objekt uvedieme ako operátor prístupu ->. 3

4 Formát volania: < objekt >. < atribút_objektu > < objekt >. < metóda_objektu > < smerník_na_objekt > -> < atribút_objektu > < smerník_na_objekt > -> < metóda_objektu > Príklad pre prácu s objektom a vyvolanie metód objektu: prac_zmluva.uloz(); cout << Faktura[6].Datum; // vyvolanie metody Uloz() // vykona ulozenie pracovnej zmluvy do db... // chyba: atribut Datum je protected, // nie je mozne k nemu volne pristupovat // a vypisat ho napr. pomocou cout << // len v metode triedy a jej podtriedy cout << Faktura[6].VratDatum(); // lepsie vytvorit public metodu VratDatum() pdoklad = &Faktura[i]; // ulozenie adresy objektu Faktura[i] do smernika pdoklad->vypis(); // vyvolanie metody, pri smerniku cez -> a nie. 4

5 A.2 Dedenie ako princíp znovupoužiteľnosti Generalizáciou množiny príbuzných tried sa vytvára zovšeobecnená, nadradená trieda, nadtrieda (topclass, superclass), ktorej sú odovzdané spoločné vlastnosti (atribúty a metódy). Špecializáciou sa naopak zo základnej triedy (base class) odvodia derivované triedy alebo podtriedy (derived classes, subclasses). Pri špecializácii vzniká prenos vlastností z nadtriedy na podtriedy nazývaný dedenie (inheritance). Dedenie funguje samozrejme aj pri postupe generalizácie. Atribúty a metódy nadtriedy získavajú jej podtriedy dedením a nemusia ich kopírovať. Ak je nutné niečo zmeniť v takto získaných prvkoch (rozšírenie, optimalizácia, oprava chyby a pod.), stačí to vykonať len na jednom mieste a prejaví sa to na všetkých podriadených úrovniach. To je výhoda oproti bežnej kópii kódu. Dedenie sa člení na: jednoduché dedenie, keď podtrieda dedí len od jednej nadtriedy, násobné dedenie, keď podtrieda dedí z viacero nadtried súčasne. Napríklad trieda Doklad môže slúžiť na uloženie údajov pre faktúry. Bolo by však vhodné niektoré informácie z obsahu štrukturalizovať a vytvoriť špecializáciou triedu, ktorá zdedí vlastnosti z Dokladu a pridá vlastné pre typ Faktura. class Faktura: public Doklad { }; protected: Date DatumSplatnosti; Obr. A.2.1a Príklad jednoduchého dedenia Obr. A.2.1b Implementácia jednoduchého dedenia Implementácia dedenia je jednoduchá. Tak napr. v jazyku C++ za kľúčové slovo class a meno novej triedy sa uvedie dvojbodka a zoznam všetkých nadtried: 5

6 Na obr. A.2.1 je konkrétny príklad jednoduchého dedenia. Trieda Faktura zdedila z Dokladu ID, DatumVystavenia, Vystavil, Adresat a Obsah. Datum sa zmenil na DatumVystavenia. Takto špecializácia pomohla aj na upresnenie názvu atribútu nadtriedy. Podtrieda zdedila okrem atribútov aj všetky metódy, ale Vypis() prekryla vlastnou metódou, pretože jej výpis Dokladu nevyhovuje, potrebuje vypísať aj svoje vlastné atribúty v určitom formáte. Okrem vlastných pridaných atribútov DatumSplatnosti, DatumZDPlnenia, FormaUhrady, SposobDopravy, StavFaktury (odoslaná, prijatá a pod.) pridáva aj vlastné špecifické metódy na výpočet ceny a DPH. Pozornosť si zaslúžia aj metódy NastavStav() a VratStav(). Takéto metódy by mohli byť vytvorené aj pre ostatné atribúty, ak je to potrebné. Dedenie tiež môže byť typu public (zdedené atribúty a metódy si ponechávajú svoj pôvodný typ prístupnosti protected a public), protected (zdedené členy sa zmenia na protected a pôvodné public prvky už nebudú použiteľné z iných tried a okolia) a private (zdedené členy sa zmenia na private a nebudú použiteľné mimo triedy, ani nebudú ďalej dedené). Používa sa väčšinou public dedenie, aby sa nestrácal pôvodný typ prístupuviditeľnosti dedených členov. Ak je potrebné ich ďalej chrániť, prípadne ďalej nedediť použije sa protected alebo private dedenie, ktoré je najužšou deriváciou. Podtrieda dedí tranzitívne aj nadtriedy svojich nadtried. Ak podtrieda zdedí cez svoje nadtriedy opakovane tú istú triedu, ktorá je ich nadtriedou, vzniká neželané opakované dedenie tej istej nadtriedy a jej členov. Odstraňuje sa zmenou dedenia na virtuálne. Specializacia podla povodu Spolocnost Nazov Adresa... Vypis( ) Specializacia podla typu ZahranicnaSpol Krajina... Vypis( ) GlobalnyVypis( ) DomacaSpol ICO /DIC BankoveSpojenie Telefon Fax KontOsoba... Vypis( ) GlobalnyVypis( ) S.R.O. A.S.... SpolSoZahUcastou... Vypis( ) GlobalnyVypis( ) Obr. A.2.2 Príklad násobného dedenia Na predošlom diagrame je opakované dedenie nadtriedy Spolocnost, ktorá obsahuje názov, adresu a ďašie dôležité atribúty. Špecializuje sa podľa pôvodu na domácu a zahraničnú 6

7 a podľa typu (akciová spoločnosť, spoločnosť s ručeným obmedzením a podobne). Spoločnosť so zahraničnou účasťou potom musí dediť násobne zo zahraničnej, domácej aj akciovej spoločnosti a tým získava opakovane ako toptriedu Spolocnost. Implementácia násobného dedenia aj s odstránením neželanej duplicity pomocou virtuálneho dedenia vyzerá v C++ nasledovne: //... class ZahranicnaSpolocnost: virtual public Spolocnost { // }; class DomacaSpolocnost: virtual public Spolocnost { // }; class SpolSoZahUcastou: public ZahranicnaSpolocnost, public DomacaSpolocnost, public AS { // }; // GlobVypis() a Vypis() si každá trieda vytvára znovu, pretože zdedené vypíšu len členy nadradenej triedy, prípadne globálne celej hierarchie nadradenej triedy smerom nahor. Je potrebné všimnúť si aj derivovaný alebo odvodený atribút DIC predznačený znakom /, ktorý možno získať výpočtom z atribútu ICO, ale väčšinou sa pre rýchlosť a zrozumiteľnosť ponecháva aj tento nadbytočný atribút. Fowler v [Fowler 12/97] spomína nielen derivované atribúty, ale aj derivované asociácie medzi objektmi, ktoré sprehľadňujú diagram, ale nie sú nutné, pretože sa dá tento vzťah odvodiť aj z ostatných dôležitejších vzťahov. Prípad Spolocnost ZahranicnaSpol DomacaSpol SpolSoZahUcastou sa nazýva aj kosoštvorcové dedenie, obsahujúce násobné dedenie dvoch nadtried podtriedou, ako aj opakované dedenie ich spoločnej nadtriedy vďaka tranzitívnemu dedeniu. V diagrame je špecializácia do podtried združená podľa pôvodu firmy a druhá podľa typu firmy. Kľúčové slovo virtual sa používa pri dedení aj na definovanie virtuálnej metódy. Ak vytvoríme smerník, ktorý ukazuje na rôzne objekty konkrétnej hierarchie, je vhodné, aby bol typu najvyššej nadtriedy (inkluzívny polymorfizmus, vysvetlený neskôr), prípadne žiadneho typu, teda typu void. Aby však kompilátor nemusel viazať staticky (static binding) už pri kompilácii konkrétnu metódu k smerníku, je potrebné definovať ju ako virtual. Potom ju bude viazať dynamicky (late alebo dynamic binding) až pri behu programu podľa objektu, na ktorý smerník ukazuje. Je to pomalšie, ale únosné a nevyhnutné riešenie. Štandardné metódy obsahujú rozhranie (typ návratovej hodnoty, názov metódy a zoznam parametrov), ako aj implementáciu (kód, telo metódy). Predpisujú teda rozhranie aj implementáciu. 7

8 Virtuálne metódy obsahujú rozhranie a môžu aj implementáciu. Predpisujú rozhranie a ponúkajú implementáciu. Čisto virtuálna metóda predpisuje len rozhranie. V C++ okrem kľúčového slova virtual je na konci deinície rozhrania symbolické priradenie = 0. Trieda, ktorá obsahuje aspoň jednu čisto virtuálnu metódu, sa označuje ako abstraktná trieda a nemožno vytvoriť objekt takejto triedy. Slúži len pri dedení ako nadtrieda, ako abstraktný vzor. Prekrývanie funkcií a metód Pri dedení môže objekt zdediť nielen želané, ale aj neželané vlastnosti nadtried. Ak ich nepotrebujeme, tak ich môžeme ignorovať a nepoužívať. Ak ich však potrebujeme v zmenenej podobe, musíme ich prekryť. V [Šešera 94] sa uvádzajú tri dôvody na prekrytie: 1. rozšírenie pôvodnej funkcie, jej doplnenie (napr. metóda Draw() triedy Window len vykreslí okno, metóda Draw() podtriedy LabeledWindow už vykresľuje okno orámované), 2. ohraničenie funkcie, (napríklad z pridávania ľubovoľného prvku metódou Add() v nadtriede na metódu, ktorá kontroluje pridávaný prvok, či sa nachádza v určenej celočíselnej množine pre metódu rovnakého mena Add() v podtriede), 3. optimalizácia funkcie (napr. náhrada pomalého, sekvenčného vyhľadávania netriedenej množiny prvkov nadtriedy za rýchle priame vyhľadávanie utriedeného poľa v podtriede). 8

9 A.3 Agregácia tried Dedenie bolo opisované ako vlastnosť, ale v skutočnosti je to aj vzťah klasifikácie a hierarchie medzi triedami, vzťah špecializácie tried smerom nadol a generalizácie smerom nahor. Pri vzťahu typu agregácia trieda C vlastní, obsahuje triedu CC. Trieda CC je teda súčasťou triedy C. Objekt sa teda môže skladať z viacerých podobjektov (napríklad doklad z hlavičky a obsahu, faktúra z položiek, systém z podsystémov, skupín úloh a úloh a podobne). class Polozka { protected: long ID; int poradie; // }; class Faktura { protected: Date DatumSplatnosti; Date DatumZdPlnenia; // stack<polozka *> _Polozka; public: void Vypis(); // }; Obr. A.3.1 Príklad agregácie (faktúra obsahuje položky) a jej implementácie Okrem agregácie je v UML možné požívať aj kompozíciu, ktorá je silnejšou verziou, znamená to, že trieda CC, ktorú trieda C obsahuje, zanikne spolu so zrušením triedy C. Druhou podmienkou je, že trieda CC patrí len triede C a neobsahuje ju žiadna iná trieda. Agregácia sa ľahko implementuje, ak sa chápe ako kompozícia: trieda C vlastní triedu CC ako svoj atribút, ak je potrebné vlastniť ich viac, vytvorí sa zoznam (napr. pole, smerník alebo zložitejšia štruktúra, obr. A.3.1). 9

10 Doklad ID : Long DatumVystavenia : Date = SysDate *Vystavil : Zamestnanec *Adresat : Firma *Obsah : String = Null Vypis( ) Uloz( ) Zrus( ) Zmen( ) Faktura DatumSplatnosti : Date DatumZdPlnenia : Date FormaUhrady SposobDopravy StavFaktury : Stav Vypis( ) CelkovaCena( ) CelkovaDPH( ) CelkCenaSDPH( ) NastavStav( ) VratStav( ) Faktura DatumSplatnosti : Date DatumZdPlnenia : Date FormaUhrady SposobDopravy StavFaktury : Stav Vypis( ) CelkovaCena( ) CelkovaDPH( ) CelkCenaSDPH( ) NastavStav( ) VratStav( ) Doklad ID : Long DatumVystavenia : Date = SysDate *Vystavil : Zamestnanec *Adresat : Firma *Obsah : String = Null Vypis( ) Uloz( ) Zrus( ) Zmen( ) Obr. A.3.2 Dedenia a agregácia Ak bolo potrebné nahradiť agregáciu vlastností do agregujúcej triedy, je to možné vykonať dedením, kedy agregované sú nadtriedy a agregujúca je podtriedou. Rovnako ak chceme nahradiť dedenie z nadtriedy do podtried, môžeme toto vykonať agregáciu, kedy podtrieda agreguje nadtriedu a tak získava jej vlastnosti. Z toho je zrejmé že agregácia je akoby inverzná k dedeniu a naopak vzhľadom na získavanie atribútov. Tento spôsob nahradzovania nie je teoreticky potrebný a obidve možnosti majú svoje unikátne vlastnosti, ilustruje to a dopĺňa možnosť pohľadu na tieto vzťahy. Napríklad pri dedení je využívaná vlastnosť viditeľnosti-prístupnosti (private/protected/public), kedy podtrieda dedí z nadtriedy len public a protected členy a nie private, čo pri agregácii nefunguje. Napriek tomu dopĺňanie týchto vzťahov využíva COM prístup a Visual Basic, kde dedenie pripúšťa len zdedenie rozhrania metódy, nie jej telo, preto sa používa na získanie plnej funkcionality agregácia. Graficky môžeme túto inverziu vlastností dedenia a agregácie vzhľadom na získanie atribútov vysvetliť na príklade z obrázku A.3.2 Trieda Doklad je nadtriedou triedy Faktura, ktorá dedí jej atribúty. Ak by náš jazyk neobsahoval dedenie, môžeme využiť agregáciu, kedy by trieda Faktura agregovala triedu Doklad a takýmto spôsobom získala atribúty. 10

11 A.4 Asociácia ako vzťah medzi triedami Triedy môžu vystupovať vo vzťahoch (asociáciách) 1:1, 1:n, n:m a podobne rovnako ako dátové entity v ER diagramoch. Vzťah možno ohodnotiť okrem kardinality aj kvalifikátorom, identifikovať ho jednoznačným názvom a priradiť roly objektom v tomto vzťahu. Na obr. A.4.1 je znázornený konkrétny príklad vzťahu Ucitel a Student. Keďže učiteľ učí viac žiakov a žiak má viac učiteľov, vzťah je n:n. Ucitel Katedra DatumNastupu : Date Prijem : Money... Vyucujuci uci > Ziak Student Specializacia DatumNastupu : Date Stipendium : Money... Vypis( ) GlobVypis( ) Prax( )...( ) 1..* Predmet IDPredmetu : long Nazov : String *Prednasajuci : Ucitel *Posluchac : Student * Vypis( ) GlobVypis( ) StudijnyRok( )...( ) Stav( ) Zapisat( ) Zrusit( )...( ) Obr. A.4.1 Príklad vzťahu učiteľ a študent Na diagrame je asociácia identifikovaná názvom uci >. Chápe sa (číta sa) zľava doprava, ale je obojsmerná, inak by bola šípka na spojnici, vtedy by bola jednosmerná. Obidva objekty vystupujú v tomto vzťahu v určitej úlohe, majú svoju rolu: Vyucujuci a Ziak. Často vzťahy 1:n a n:m dopĺňa asociačná trieda (tu Predmet) na doplnenie väzby. V [Rumbaugh 91] vidieť použitie kvalifikovanej asociácie v modeli využitia čipových kariet pri platbách pomocou ATM zariadení, kde v konkrétnom vzťahu je použitý kvalifikátor, slúžiaci ako kľúč alebo parameter, ktorý jednoznačne identifikuje 1:n vzťah k inému objektu. Napríklad kvalifikátor Kód Banky vo vzťahu Združenie bánk a Banka určuje konkrétnu banku. Kvalifikátor je neskôr implementovaný ako atribút a kľúč zúčastneného objektu vo vzťahu, alebo je súčasťou asociačnej triedy. Konkrétne použitie kvalifikátora IDIncidentu je vidieť v nasledujúcom diagrame pri triedach Klient a Zamestnanec (aj v roli riesitel aj v roli prijimatel), kde určuje konkrétny výskyt triedy Incident vo vzťahu k riešiteľovi incidentu, jeho prijímateľovi a zadávateľovi. Kvalifikátor IDProduktu určuje, ktorý Produkt je zasiahnutý. Výsledný návrh sa od tohto modelu odchýlil ako je vidieť v závere práce, ale IDIncidentu aj IDProduktu bolo v triedach Incident a Produkt potrebné zaviesť. 11

12 riesitel IDIncidentu Incident IDProduktu Produkt Zamestnanec * * IDIncidentu prijimatel IDIncidentu Klient Obr. A.4.2 Objektový diagram s ilustračným príkladom relácie n:m Ucitel a Ziak Asociácie 1:1 možno uchovať v triede smerníkom na asociovanú triedu. Agregáciu a asociáciu 1:n implementujeme smerníkom v n objektoch a poľom smerníkov na druhej strane. Asociácie n:n možno implementovať ako samostatnú väzobnú asociatívnu triedu, kde sú dvojice smerníkov na jednu a druhú triedu. K obojstrannej asociácii zjednodušene môže postačiť smerník alebo zoznam smerníkov na objekt(y) zúčastňujúce sa na vytvorenom vzťahu. Ako príklad na asociáciu 1:n alebo agregáciu, môže poslúžiť implementácia vzťahu z [Rumbaugh 91] spomínaná vyššie (vzťah alebo agregácia ZdruzenieBank a Banka): class Banka; class ZdruzenieBank { private: stack<banka *> banka; // }; class Banka { private: ZdruzenieBank *konzorcium; // }; Príklad, inšpirovaný z [Hellwig 98], je uvedený na strane 25. Hala môže obsahovať niekoľko prepraviek. Logicky je najprv potrebné vytvoriť objekt typu Hala až potom vytvoriť objekty typu Prepravka. Vtedy bude zaistené prepojenie medzi nimi metódou UlozDoHaly() v triede Prepravka (uchová sa smerník na halu v Prepravka) a metódou UmiestniPrepravku() v triede Hala (uchová sa smerník na prepravku do zoznamu všetkých smerníkov na prepravky v triede Hala). Pre čitateľnosť ignorujeme zrušenie prepojenia, čo nie je problém a zaoberáme sa len vytvorením spojenia, asociácie. Najprv bola preddefinovaná trieda Hala aby mohla byť použitá ako typ v triede Prepravka a bola vytvorená parametrická trieda stack ako všeobecný zásobník, ktorý je tu použitý ako množina smerníkov na prepravky. Pre čitateľnosť je vytvorený stack ako LIFO pole len s metódou pridaj(). Jednoduché je nahradiť to zložitejším typom zásobníka. 12

13 Implementácia triedy Prepravka a jej metódy UlozDoHaly(): class Hala; class Prepravka { private: Hala *hala; public: void UlozDoHaly(Hala *_hala) { hala = _hala; // hala->umiestniprepravku(this); } }; Pri agregácii vzniká problém pri zrušení objektu, ktorý vlastní objekty, z ktorých sa skladá. Agregácia je tranzitívny vzťah, preto treba v kaskáde zrušiť aj ostatné objekty zúčastňujúce sa na hierarchicky nižších agregáciách objektov, obyčajne sa to môže realizovať ako kompozícia, containment, cez dátové členy - atribúty, ktoré obsahujú podriadený objekt (inštanciu triedy). To je možné realizovať aj referenciou cez smerník, prípadne zoznamom smerníkov pri 1:n vzťahu. Druhou alternatívou je spätná referencia smerníkom z objektov na agregujúci objekt. Vytvorenie zásobníka stack ako par. triedy s metódou Pridaj(): template <class T> class stack { private: T pole[n]; int index; public: stack() { index=0; }; void pridaj(t objekt) { pole[index++]=objekt; } }; Vytvorenie triedy Hala a príklad vytvorenia haly A a prepravky P1 a vzťahu medzi nimi pomocou metód UlozDoHaly() a UmiestniPrepravku(): class Hala { private: stack<prepravka *> prepravky; public: 13

14 }; void UmiestniPrepravku(Prepravka *prepravka) { prepravky.pridaj(prepravka); } void main(int argc, char* argv[]) { Hala A; Prepravka P1; P1.UlozDoHaly(&A); // zapamätaj si halu A.UmiestniPrepravku(&P1); // prijmy prepravku // } Compuware Corporation, 2003, Using OptimalJ p. 120: 14

15 A.5 Perzistentné objekty a ich ukladanie do relačných databáz Pri vzniku objektového prístupu sa predpokladalo, že stále (persistent) objekty budú ukladané v objektovo-orientovanej databáze (OODB) a nestále (transient) vzniknú a zaniknú podľa potreby počas behu aplikácie. Hoci v [Šešera 94] predpokladajú rozšírenie OODB na úkor relačných, doteraz tento trend nie je žiaľ pozorovateľný. Nepresadil sa ani smer pridávania DB čŕt do OO programovacích jazykov (smalltalk: GemStone, C++: ObjectStore, Versant), ani smer rozšírenia databáz o OO črty, možno objektová nadstavba Oracle 8 prinesie efektívne a komerčne úspešné OODB prostredie. Dnes sa bežne pracuje v OO prostredí MS Windows, s OO jazykmi ako Java, VB alebo C++, ale v DB prostredí Oracle, MS SQL Server alebo iných relačných databáz. Preto sa diagram objektov používa aj na definovanie dátového modelu, keď sa zvyčajne v štrukturovanej analýze používaný entitno-relačný diagram ([Blaha 98], [Rumbau 91]). V prípade OOAaN sa ustanovila dohoda, že každý objekt reprezentuje jednu tabuľku a jeho dátové členy sú vlastne stĺpce tejto tabuľky. Metódy objektov reprezentujú potom jednotlivé procedúry na tabuľkách (Select, Insert, Update, Delete a podobne). Objektové diagramy okrem špecifikácie objektov a asociácií medzi nimi (1:1, 1:n, n:m a podobne) poskytujú viac: znázorňujú aj vzťahy nadriadenosti a podriadenosti, dedenia, agregácie a pod. Namapovanie asociácie n:m z diagramu na obr. A.4.1 a jej SQL interpretácia môže vyzerať napríklad takto: CREATE TABLE Ucitel ( ID_Ucitela ID not null, Meno_Ucitela char(50), Zaradenie integer, PRIMARY KEY (ID_Ucitela)); FOREIGN KEY (ID_Ziaka) REFERENCE Ziak); CREATE SECONDARY INDEX Ucitel_Index_Meno ON Ucitel (Meno_Ucitela); Tabuľka Ziak sa vytvorí podobne ako tabuľka Ucitel. CREATE TABLE Uci ( ID_Ucitela ID not null, ID_Ziaka ID not null, Pocet_Hodin integer, PRIMARY KEY (ID_Ucitela, ID_Ziaka), FOREIGN KEY (ID_Ucitela) REFERENCE Ucitel, FOREIGN KEY (ID_Ziaka) REFERENCE Ziak); CREATE SECONDARY INDEX Učí_Index_Ucitel ON Uci (ID_Ucitela) CREATE SECONDARY INDEX Učí_Index_Ziak ON Uci (ID_Ziaka) 15

16 Asociácia 1:1 sa môže riešiť referenciou na asociovanú tabuľku (obe tabuľky obsahujú ID svojho partnera), napríklad cez FOREIGN KEY. Vzťah 1:n sa rieši referenciu z tabuľky s viacnásobným výskytom (spätná referencia), prípadne asociačnou tabuľkou, v ktorej budú uložené referencie na obe tabuľky. Vzťah n:m sa implementuje pomocou umelej tabuľky väzieb (väzobná asociatívna tabuľka), ktorá obsahuje referenciu na obe tabuľky. Agregácia 1:1 sa môže riešiť ako skutočná kompozícia, keď agregujúci objekt - tabuľka obsahuje aj stĺpce agregovaného podobjektu tabuľky. Zriedkavejšie sa implementuje referenciou na agregovanú tabuľku, pretože navigácia cez dve tabuľky spomaľuje. Pri agregácii 1:n sa postupuje podobne ako pri vzťahu 1:n. Dedenie možno riešiť niekoľkými spôsobmi. Na obr. A.5.1 je schéma znázorňujúca nadriadenosť a podriadenosť s dedením vlastností nadtriedy - tabuľky Osoba podtriedami - tabuľkami Ucitel a Ziak. Osoba ID_Osoby : ID Meno : char(50) Adresa : char(50) Ucitel Zaradenie : integer Plat : money Ziak Studijny_smer : integer Rocnik : integer Obr. A.5.1 Príklad dedenia pri generalizácii špecializácii Tu existujú štyri prístupy: 1. V štandardnom prístupe ku každému objektu vytvoríme tabuľku a prepojíme ich cez ID supertriedy. Všetky podtriedy budú obsahovať tento identifikátor toptriedy aj ako stĺpec aj ako kľúč. Táto navigácia cez ID sa považuje za pomalú. CREATE TABLE Osoba ( ID_Osoby ID not null, Meno char(50), Adresa char(50), PRIMARY KEY (ID_Osoby) ); CREATE SECONDARY INDEX Osoba_Index_Meno ON Osoba (Meno) CREATE TABLE Ucitel ( ID_Osoby ID not null, Zaradenie integer, Plat money, 16

17 PRIMARY KEY FOREIGN KEY (ID_Osoby), (ID_Osoby) REFERENCE Osoba); Tabuľka Ziak sa vytvorí podobne ako tabuľka Ucitel. 2. Ak toptrieda obsahuje málo atribútov a je tu mnoho podtried s významnými atribútmi, vytvoríme len tabuľky subtried, ktoré budú obsahovať aj stĺpce s členskými dátami supertriedy. 3. Ak naopak existujú len 2-3 podtriedy s niekoľkými atribútmi a toptrieda je nositeľom veľkého množstva významných atribútov, je vhodné vytvoriť len jednu tabuľku pre toptriedu, ktorá obsahuje aj všetky atribúty podriadených subtried. Riadkov v tabuľke bude toľko, koľko je výskytov inštancií jednotlivých podtried, keď atribúty inej triedy budú prázdne, nevyužité. Tento prístup však spôsobuje neoptimálny výsledný návrh dátového modelu. Tento spôsob je však pre rýchlejšiu navigáciu využívaný, ako aj spôsob číslo 2, ktorý je najčastejší. 4. Vytvoriť tabuľky pre všetky triedy a podtriedy a tabuľku určenú na definovanie relácií medzi nimi. Štvrtý prístup môžeme prijať aj pre ostatné vzťahy medzi objektmi (tabuľkami): pre asociácie všetkých druhov a pre agregácie. Zaujímavé by bolo navrhnúť také štruktúry tabuliek, pri ktorých by bolo možné navrhnúť všeobecnú formu obsahujúcu metadáta o štruktúre celého diagramu, a nielen konkrétne väzby a aplikácie. Do tejto formy by sa dali ukladať údaje z diagramov na prenos do iných systémov a dal by sa z nich prípadne skonštruovať diagram odznova. Táto forma by obsahovala nasledujúce tabuľky, ktoré tu zovšeobecníme na objekty: 1. tabuľku o objektoch (ID objektu, meno objektu,... ) 2. tabuľku o atribútoch a metódach objektov (ID objektu člena, ID člena, meno, poradie, typ atribút alebo metóda,...) 3. tabuľku o väzbách, (ID väzby, meno, ID 1. objektu, ID 2. objektu, typ väzby medzi nimi,...) 4. tabuľku o atribútoch väzieb medzi tabuľkami (ID väzby, typ atribútu, špecifikácia atribútu). Ak sa bude väzba chápať ako objekt, potom tabuľka o atribútoch väzieb medzi tabuľkami zaniká a nahradí ju tabuľka o atribútoch a metódach objektov. 17

18 A.6 Mnohotvárnosť, polymorfia Niekedy je vhodné, aby objekty rozličných tried pre zrozumiteľnosť a ľahké použitie vlastnili metódy s rovnakými názvami (napr. Print(), Show()), hoci s viac či menej rozdielnou funkcionalitou podľa potreby údajov a implementácie. Podobná vlastnosť sa využíva často aj pri operátoroch + - * /, ale aj pri [] (), kedy sa operuje podľa potreby niekedy s celočíselnými a niekedy s reálnymi operátormi a operandmi, dokonca reťazcami znakov a podobne. Tento problém sa môže riešiť ďalšou charakteristickou vlastnosťou OO prístupu, ktorou je polymorfia (polymorphysm), ktorá zabezpečuje "viactvarosť" metódy podľa potreby, aby sa aj v prostredí, kde sa vyskytujú funkcie a metódy tried s rovnakým názvom, vybrala z kontextu tá najvhodnejšia podľa typu parametrov alebo príslušnosti k triede. Polymorfizmus je tu chápaný najmä ako mnohotvárnosť tried, všeobecných funkcií, metód a operátorov. Viacfunkčnosť metódy je zabezpečená funkciami s rovnakým menom, ktoré sa odlišujú svojimi parametrami a implementáciou (kódom - telom funkcie). Polymorfia môže tiež umožňovať viacznačnosť, "mnohotvárnosť" funkcie alebo operátora prekrytím. Zabezpečuje, že aj v hierarchii, kde sa vyskytujú rovnaké názvy metód, sa vyberie z kontextu práve tá, ktorá je vhodná. Získa sa tým rozšírenie, špecializácia kódu, implementácie predka u potomka. Optimalizácia a minimalizácia kódu využívaním implementácie členských funkcií predka u potomka pomocou polymorfie pri dedení je významnou vlastnosťou OOP. Najčastejšie sa výber orientuje podľa počtu a typu argumentov alebo úrovne hierarchie. Toto je vlastnosť, ktorá sa spája aj s pojmom prekrývania funkcií, pretože rovnakými menami prekrývame rôzne funkcie, ktoré sa musia však líšiť aspoň počtom a typom argumentov alebo umiestnením v rôznych triedach. V odbornej literatúre sa uvádzajú nasledujúce možnosti: Inkluzívny polymorfizmus umožňuje použiť namiesto objektu nadtriedy aj objekt ľubovoľnej podtriedy. Tým získavame možnosť využívať funkcie, ktoré prijímajú nadtriedy, aby pracovali aj s novými, rozširujúcimi podtriedami a nie je nutné prepisovať aj nemeniaci sa kód prijímajúcej funkcie, ktorá pracuje s pôvodnou štruktúrou základných aj odvodených tried. Takisto smerník, do ktorého treba uložiť adresy objektov rôznych druhov podtried, je vhodné vytvoriť ako smerník najvyššej triedy a potom nie je nutné vytvárať smerník pre každý objekt podtriedy samostatne a možno dynamicky v programe ukladať do neho adresy ľubovoľného objektu a vyvolávať práve metódu objektu uloženého tam v inej časti kódu. Parametrický polymorfizmus dovoľuje vytvárať šablóny tried a funkcií, kde je parametrom aj typ spracúvaných údajov. Konkrétny objekt a jeho trieda sa vytvoria špecifikovaním typu spracúvaných údajov a objektov. Prekrývanie funkcií a metód (overloading) znamená vytvoriť funkcie alebo metódy triedy s rovnakým názvom, aký už existuje, ale s inými parametrami a implementáciou. Prekrývanie operátorov znamená možnosť prekryť štandardné operátory ako sú + - * /, ale aj napríklad () []. Pokiaľ nemožno použiť prekrývanie, využíva sa pretypovanie - parametre sa premenia na typ vyhovujúci metóde alebo operátoru (reálne čísla na celočíselné, alebo naopak, a podobne). V [Šešera 94] upozorňujú na logické pravidlo, že predefinovaný operátor nesmie meniť počet operandov a asociatívnosť štandardného operátora

19 Zaujímavou možnosťou využitia polymorfie v jazyku C++ je práca so šablónou. Funkcia max() vráti väčšie z dvoch čísel, ktoré prijme ako paramatre. Napríklad v štruktúrovanom jazyku C bolo potrebné vyrobiť pre každý typ osobitnú funkciu, alebo aspoň funkcie pre väčšie typy (double, long) a menšie typy si funkcia pretypovala (float, int, char). Problém by nastal, ak by sme chceli touto funkciou poznať väčší z dvoch zlomkov, alebo väčší reťazec. V C++ tento problém odpadá vytvorením parametrickej funkcie. Je potrebné však vytvoriť aj operátor > pre Zlomok, reťazec a pod., ktorý prekryje pôvodný pri použití operandov zvoleného typu. Príklad šablóny vo funkcii max() a jej použitie: template <class T> T max(t a, T b) { return a>b? a : b; } main() { } int ai=1, bi=2; ai= max(ai, bi); float af=1.2, bf=2.1; cout << max(af, bf) <<'\n'; Príklad makra v jazyku C a jeho použitie:... #define MAX(A, B) //... (return((a)>(b))? (A) : (B)) main() { int a, b, c; //... a=max(0, b); c=max(++a, b); // } Šablóna template v C++ je oproti #define z C vhodnejšia v tom, že pomocou nej nedefinujeme text na ľavej strane, ktorý chceme nahradiť v zdrojovom kóde pravou stranou (vďaka čomu vznikajú problémy napr. pri inkrementácie a dekrementácie, ako je uvedené v druhom použití), ale funkciu, ktorá prijíma parametre cez rozhranie a sú prísne typové na rozdiel od textu. Nevýhodou šablóny je, že je pomalšia, pretože je volaná ako funkcia a nenahrádza konkrétny kód priamo v texte. Toto by sa dalo nahradiť pomocou techniky inline, ktorá vkladá priamo kód inline funkcie. Toto je vhodné napríklad pre funkcie v cykloch a pre krátke metódy v zriedka sa vyskytujúcich objektoch. Príklad inline funkcie a inline šablóny: inline inline max(int a, int b) {

20 return a>b? a : b; // ++a tu vstupuje cez parameter, // preto sa vykoná len raz } template <class T> inline T max(t a, T b) { return a>b? a : b; } Operátor > z predchádzajúceho príkladu, ako aj iné operátory sa dajú prekryť napr. v jazyku C++ pomerne ľahko: vytvorí sa metóda s menom, ktoré je zložené z kľúčového slova operator a samotného znaku/znakov pre operátor (+ - * / == = <= >= = a pod.). Konkrétny operátor sa vyberie podľa operandov vo výraze. Nasledujúci príklad rieši prekrytia operátora + pre reťazce znakov zakončených nulou. Vracia typ Retazec a patrí do triedy Retazec (Retazec Retazec::). Jej meno je síce operator+, ale na jej vyvolanie postačí samotné + vo výraze, kde vystupujú ako operandy reťazce. Metóda si najprv vytvorí objekt vysledok typu Retazec a alokuje pre neho pri vytvorení konštruktorom pamäť s veľkosťou súčtu dĺžky (strlen()) oboch reťazcov a miesto pre koncovú nulu. V druhom riadku vykoná skopírovanie (strcpy()) prvého operandu do objektu vysledok, v treťom riadku pripojí na koniec (strcat()) do vysledok druhý reťazec a takto vracia súčet - zreťazenie pomocou return. Príklad prekrytia operátora + v triede Retazec: Retazec Retazec::operator+(Retazec &retazec1, Retazec &retazec2) { Retazec vysledok(strlen(retazec1.pointer)+strlen(retazec2.pointer)+1); strcpy(vysledok.pointer, retazec1.pointer); strcat(vysledok.pointer, retazec2.pointer); return vysledok; }; Výber prekrývaného operátora alebo metódy vykonáva kompilátor, a vytvára tak statické spojenie (early binding alebo static binding). Projektant môže napomôcť operátorom rozsahu platnosti pre požadovanú triedu alebo výberom triedy. Aby vzniklo dynamické spojenie (late binding alebo dynamic binding), keď sa vyberá vhodná metóda až počas behu programu, musí sa použiť kľúčové slovo virtual pred názvom členskej funkcie. Takto sa dosiahne použitie aj takej metódy, ktorá pri kompilácii nebola prítomná. Vyskytuje sa to aj pri použití smerníku na triedu, keď kompilátor nevie, na akú triedu smerník bude ukazovať a ktorú metódu treba použiť. Vtedy je totiž najvhodnejšie definovať smerník na nadtriedu a počas behu programu ho presmerovávať na jednotlivé podtriedy (inkluzívna polymorfia). Vznikajú nasledujúce možnosti: 1. Členská funkcia nadtriedy je štandardná, nie je virtuálna. Vtedy predpisuje nielen rozhranie (meno a argumenty funkcie, počet a typ), ale aj implementáciu, čo znamená, že sa vždy vyvolá metóda nadtriedy, nie konkrétnej podtriedy, na ktorú ukazuje smerník. 2. Členská funkcia nadtriedy je virtuálna. Vtedy predpisuje rozhranie, ale implementáciu len ponúka, čo znamená, že sa vyvolá metóda konkrétnej podtriedy, na ktorú ukazuje smerník; len ak taká neexistuje, nahradí ju metóda nadtriedy. 3. Členská funkcia nadtriedy je čisto virtuálna (okrem kľúčového slova virtual pred menom funkcie je jej deklarácii priradená nula). Vtedy

21 predpisuje rozhranie, ale implementáciu neponúka, čo znamená, že sa vyvolá metóda konkrétnej podtriedy. Trieda, ktorá obsahuje aspoň jednu čisto virtuálnu metódu, sa označuje ako abstraktná trieda a nemôžeme vytvoriť objekt takejto triedy. Slúži len pri dedení ako nadtrieda, ako abstraktný vzor, zabezpečuje použitie rovnakého rozhrania a štruktúry pri dedení. Ak nemá metóda implementáciu, predpokladá sa, že slúži len ako virtuálna na dynamické viazanie, len ako vzor a implementácia kódu je len v potomkoch jej triedy. Ak obsahuje aj implementáciu, predpokladá sa, že sa použije pre vlastnú triedu. Parametrická polymorfia sa používa často aj v oblasti implementačných vzorov (patterns), kde napomáha všeobecnosti a otvorenosti: vzor container (zásobník) a iterator (prehliadač) neriešia, s akým typom hodnoty budú pracovať (čísla, reťazce, smerníky, polia a podobne), ale ako. Veľmi zaujímavou prácou v tomto obore bol príspevok na OOPSLA 97 [Duell 97], popisujúci nesoftverové príklady notoricky známych vzorov. Je to vhodná inšpirácia pre úvodnú prednášku do vzorov, nie však ako úvodný študijný materiál. Zaujímavý vzor z [Murray 93] používa tiež parametrickú polymorfiu. Dovoľuje naraz vrátiť nie jednu ale dve hodnoty (je možné pridať aj viac hodnôt). Vytvorí triedu Pair s dvomi parametrickými typmi class L a class R, atribútom left_d a right_d pre každý typ a get/set metódami pre manipuláciu s nimi (uloženie hodnoty do atribútu, výpis hodnoty z atribútu). Potom je možné uložiť do objektu (rch) takejto triedy naraz dve hodnoty z funkcie, ktorá vracia naraz aj najvyšší príjem aj s menom zamestnanca (find_highest_salary()). Potom sa už ľahko vytlačí pomocou rch.left() a rch.right() meno aj príjem pracovníka. Takúto možnosť nám štruktúrovaný jazyk C neponúka, tam je možné manipulovať len so smerníkom na štruktúru, ktorá obsahuje viac hodnôt. Pair template - parametrický vzor pre návrat viac hodnôt [Murray 93]: template <class L, class R> class Pair // vytvorime triedu Pair s dvomi typmi { private: L left_d; // a atributmi pre kazdy typ R right_d; public: // a get/set metodami... Pair(const L& l_arg, const R& r_arg):left_d(l_arg),right_d(r_arg) {} L left() const { return left_d; } void left(const L& l_arg) { left_d=l_arg; } R right() const { return right_d; } void right(const R& r_arg) { right_d=r_arg; } }; class Database; // implementacia Database aj find_highest_salary je na uzivatelovi Pair<char*, int> find_highest_salary(const Database&); // je typu Pair vrati meno aj zarobok z db void print_highest_salary(database& db) { Pair<char *, int> rch = find_highest_salary(db); cout << rch.left() << "earns" << rch.right() << endl; }

22 A.7 Aplikácia parametrického polymorfizmu v praxi () Technológia parametrického polymorfizmu bola úspešne vyskúšaná aj pri hľadaní čo najpresnejších výpočtov s veľkými číslami, ktoré sú potrebné aj pre veľké finančné inštitúcie, akými sú banky a poisťovne. Nejde len o priame výpočty, akými sú operácie s čiastkami prevyšujúcimi miliardy, ktoré vyžadujú neustále zachovávať presnosť aj na desatinných miestach, niekoľkonásobné prepočty úrokov, kde niektoré banky dokonca pripúšťajú určitú mieru nepresnosti, ale ide aj o zložité analytické a prognostické výpočty, kde sa bežne používajú výpočty s vysokým počtom iterácií, obsahujúcich napr. operáciu delenia, inverzie matíc a riešenie sústav rovníc o niekoľkých neznámych a podobne, kedy prichádza k nestabilite výpočtu pri určitých podmienkach. Keďže toto nie je ojedinelá situácia, bolo potrebné globálne riešenie, popísané v [Polášek 98c]. Nešlo o využitie špeciálnych algoritmov, ale o vytvorenie spoľahlivej a rýchlej aritmetiky, obsahujúcej také typy operandov a operátorov, ktorá by dovoľovala na jednej strane vypočítať ľubovoľne veľký faktoriál a vôbec počítať s veľkými číslami, obsahujúcimi bežne viac ako tisíc cifier, ako aj počítať bez obáv inverzie matíc a rovnice s podmienkami, blízkymi singulárnym maticiam. Využili sa na to skúsenosti s bežne používanou zlomkovou aritmetikou, kedy je vyradená operácia delenia, spôsobujúca vo výpočtovej technike ešte stále veľké nepresnosti. Každé číslo je najprv prevedené do zlomku (ak už sa v ňom nenachádza) a všetky operácie sú vykonané ako operácie so zlomkami, ak je to možné (sčítanie, odčítanie, násobenie a delenie cez násobenie obráteným zlomkom). Po každej operácii je zlomok upravený pomocou Eulerovho algoritmu najväčšieho spoločného deliteľa, aby nenarastala zbytočne veľkosť čitateľa a menovateľa, tým aj zložitosť jednotlivých výpočtov. Zlomky boli doplnené o typy, operujúce s veľkými číslami. Tak vznikla kombinácia zlomkovej aritmetiky a aritmetiky veľkých čísel. Najprv prekryl bežný súčet súčet zlomkov a v ňom prekryl bežný súčet a násobenie čitateľov a menovateľov sčítancov súčet a násobenie veľkých čísiel. Polymorfia napomohla pri: 1. nahradzovaní bežných typov operandov a operácií zlomkovou aritmetikou, namiesto bežných operátorov sa začali pomocou preťaženia používať zlomky a ich operátory, aplikačný programátor nevnímal, či používa bežné čísla, alebo už zlomky, jemu išlo o vyššiu presnosť pri zachovaní rýchlosti, 2. nahradzovaním typov čitateľa a menovateľa v zlomkoch od bežných celých a reálnych čísiel, cez nekonečne dlhé reťazce dekadických číslic až po polia celých čísiel, 32 a 64 bitových. Reťazce binárnych číslic sú teoreticky pre operácie vhodnejšie, ale prešlo sa priamo do binárnej prezentácie čísla, ukladanej do poľa celých čísel. Rozmer poľa sa dynamicky mení podľa veľkosti ukladaného čísla. Toto pole je menej náročné na priestor aj na čas ako čísla v reťazcoch. Využije sa tu lepšie pamäť, ako aj operácie cez celé registre procesora. K tomu bolo nutné použiť všetky možnosti polymorfie: prekrývanie operátorov a funkcií stále sa meniacich typov, inkluzívny polymorfizmus pre aplikačné metódy očakávajúce náš abstraktný aplikačný typ, derivovaný na stále efektívnejšie verzie, parametrický polymorfizmus najmä pri triede Zlomok: template <class T> class Zlomok { public:

23 //... }; T citatel; T menovatel; main() {... } Zlomok<int> zlint; Zlomok<double> zlfloat; zlint.citatel=1; zlfloat.citatel=1.2; Ďalším zrýchlením bolo vytvorenie inteligentných operácií, uložením automatického rozhodovania pre operáciu číslo-číslo (pre malé čísla), pole-číslo, pole-pole (pre veľké čísla) do ich tela. Aritmetika bola naprogramovaná v jazyku C/C++ s využitím preťaženia operátorov

24 Príloha B Obr Use Case bez vymedzenia hraníc systému, Hospital, Rational Rose

25 Obr Use Case s iným usporiadaním, v centre je užívateľ, ktorému služby sú ponúkané a slúžia mu, FIDS System, Rational Rose

26 Obr Use Case Diagram s dynamickými prvkami toku interakcií medzi službami a užívateľom, Building Management Sytem, Esprit Systems Consulting, 97, príklad z Rational Rose

27 From whitepapers, presentation and technical reports ( RUP): An include-relationship is a relationship from a base use case to an inclusion use case, specifying how the behavior defined for the inclusion use case is explicitly inserted into the behavior defined for the base use case. An extend-relationship is a relationship from an extension use case to a base use case, specifying how the behavior defined for the extension use case can be inserted into the behavior defined for the base use case. It is implicitly inserted in the sense that the extension is not shown in the base use case

28 A use-case-generalization is a relationship from a child use case to a parent use case, specifying how a child can specialize all behavior and characteristics described for the parent. Use Case Revisions - Replace «uses» relationship with Generalization and «include» dependency - Reclassified «extend» relationship as a Dependency - Defined format of «extend» relationship and extension points Include: vkladaná služba je bezpodmienečne vnorená do hlavnej (no/yes, yes) Extend: rozširujúca služba je rozširuje hlavnú len ak je splnená podmienka (no, yes) Generalization: špecializovaná služba dopĺňa hlavnú službu, od ktorej je odvodená (yes, no)

29 Question Extend Include Generalization What is the direction of the relationship? The addition use case references the base use case. The base use case references the addition use case. The addition use case (child) references the base use case (parent). Does the relationship have multiplicity? Yes, on the addition side. No. If you want to include the same segment of behavior more than once, that needs to be stated in the base use case. No. Does the relationship have a condition? Yes. No. If you want to express a condition on the inclusion you need to say it explicitly in the base use case. No. Is the addition use case abstract? Often yes, but not necessarily. Yes. Often no, but it can be. Is the base use case modified by the addition? The extension implicitly modifies the behavior of the base use case. The inclusion explicitly modifies the effect of the base use case. If the base use case (parent) is instantiated, it is unaffected by the child. To obtain the effects of the addition, the addition use case (child) must be instantiated. Does the base use case have to be complete and meaningful? Yes. Together with the additions, yes. If it is abstract, no. Does the addition use case have to be complete and meaningful? No. No. Together with the base use case (parent), yes. Can the addition use case access attributes of the base use Yes. No. The inclusion is encapsulated, and only "sees" itself. Yes, by the normal mechanisms of inheritance

30 case? Can the base use case access attributes of the addition use case? No. The base use case must be wellformed in the absence of the addition. No. The base use case only knows about the effect of the addition. The addition is encapsulated. No. The base use case (parent) must in this sense be well-formed in the absence of the addition (child)

31 class Firma { private: stack<osoba *> Zamestnanec; // }; a naopak v triede Osoba bude sprostredkovávať pole smerníkov na Firmu: class Osoba { private: stack<firma *> Zamestnavatel; // }; osoba meno : char adresa : char RodneCislo : char pracuje_pre > zamestnanec zamestnavatel * * firma meno : char adresa : char ICO Zamestnanie plat : int funkcia : char veduci pracovnik 1..* < riadi Obr. B.2.1 Príklad asociácie s asociačnou triedou podľa [Semantics 97] Obr Stavba štruktúrovaného programu podľa [Rumbaugh 91 Program Blok Zlozeny prikaz Jednoduchy prikaz

32 osoba Meno Adresa Rodne cislo zarobkovo cinny ostatni podnikatel Rocny prijem zamestnanec Dieta ziak Rocnik Skola Dochodca interny Dovolenka externy hodinovy Hodinova mzda Odpracovane hodiny mesacny student Specializacia Pracujuci student Obr. B.2.2 Príklad násobného delenia a delenia podľa kritéria

33 Obr Doménový model nemocnice (Hospital, Rational Rose 98)

34 Obr Class Diagram so zväzkami tried a bohatou sieťou väzieb medzi nimi, Building Management Sytem, Esprit Systems Consulting, 1997, Rational Rose 98 Obr Class diagram, kde prepojenie medzi zväzkami tried je nahradené prehľadným usporiadaním, ClassIQ, Rational Rose

35 Obr RMI, Rational Rose 98 Obr Class diagram s kombináciou väzieb a logickým usporiadaním zväzkov tried, RMI, Rational Rose

36 Prílohy

37 V UML je dôležité aj použitie stereotypov, ako špecializácie metamodelovacích prvkov a vzťahov (trieda, objekt, asociácie, dedenie, agregácia a podobne): 1. rozhranie (interface) je v UML chápané podľa [Semantics97] ako uzavretá množina vstupno-výstupných metód objektu, sú znázorňované samostatnou abstraktnou triedou, ktorú dedia ostatné reálne triedy, ktoré ponúkaju toto rozhranie svojim klientom ďalším triedam; častejšie je rozhranie znázorňované ako prázdny krúžok na spojnici, vychádzajúce z triedy; využitie rozhrania je znázornené šípkou, vychádzajúcou od klientskej triedy. Trieda môže ponúkať viac rozhraní podľa klienta, prostredia, OS a podobne. Zaujímavé príklady uvádza [Rational Rose] vo svojej knižnici projektov. Napríklad v Customer Services, Bank IDLInterfaces, Rational Rose 98, kde je vytvorené rozhranie pre Bank Account (bankový účet) a User (klient). 2. používateľ (Actor), je stereotypom triedy a je znázorňovaný schématizovanou postavou, sa používa najmä v konceptualizácii ako používateľ systému v konceptuálnom diagrame, ale vystupuje potom aj ďalej v poddiagrame služieb, v sekvenčnom, komunikačnom, ale aj objektovom diagrame. Okrem stereotypu rozhrania a používateľa sa dnes do popredia dostávajú aj prvky potrebné pri návrhu intranet/internet aplikácií. Nasledovné stereotypy zverejnil [Conallen 2001] na Stereotypy pre triedy: «server page» «server page» reprezentuje web stránku na strane servera, posielajúcu web stránku, jej atribútmi a metódami sú premenné a funkcie na stránke, spolupracujú s komponentami a databázou servera «client page» «client page» reprezentuje HTML stránku, jej atribútmi a metódami sú premenné a funkcie na stránke, «form» «form» reprezentuje (napr. HTML) formulár, ktorý je súčasťou client page, atribúty korešpondujú s prvkami na stránke. «JavaScript» objekt v Java kóde, podobný môže byť pre Visual Basic

38 Stereotypy pre asociácie: «builds» «link» server page vytvára (builds) client page jednosmerný vzťah od server page do client page hyperlinky z client page na iné stránky «submit» vyvolanie server page, ktorá spracuje zaslané údaje z formuláru «redirect» presmerovanie spracovania z jednej server page na druhú should be loaded. Obr. B.2.3 Schéma web aplikácie pomocou www stereotypov podľa [Conallen 01] [Conallen 01] uvádza použitie stereotypov pri konkrétnej aplikácii, sú tam časté frázy ako stránka na servri (server page) vytvorí (builds) stránku pre klienta (client page), client page obsahuje formulár (form), formulár posiela údaje a vyvolá spracovanie (submit), presmerovanie (redirect), hyperlinky (links) na server stránky a stránky pre klienta a podobne

39 Prílohy

40 Prílohy

41 Radovan Ďuga, 2001, Gratex International, a.s. OBR. 30: ČASŤ OBJEKTOVÉHO DIAGRAMU MCSC ZNÁZORŇUJÚCA OBJEKTY NA PREHLIADANIE INCIDENTOV

42 V rámci dynamického modelu sa v UML používajú nasledovné akcie, alebo správy: - zasielajúce udalosť, signál (send action) od vysielajúceho (zdrojového) k prijímajúcemu (cieľovému) objektu, - vyvolávajúce metódu (call action) prijímajúceho, - lokálne (local invocation), vyvolávajúce lokálne vykonanie metódy, operácie, - vytvárajúce (create action) nové inštancie, - ukončujúce (terminate action) prácu, prípadne rušiacu lokálnu inštanciu, - rušiace (destroy action) iné inštancie, - návratovú (return action), vracajúcu hodnotu vyvolávajúcemu, - neinterpretovateľnú (uninterpreted action) v UML. Udalosťou sa chápe nastatie určitého javu v systéme alebo okolí (dosiahnutie želaného stavu, hodnoty a pod.). Udalosť (informácia o nej ) sa šíri jednosmerne a môže mať aj svoje atribúty - parametre. Čas je implicitným parametrom udalosti, pretože vzniká v jednojednoznačnom časovom okamihu. Interakcie sú znázornené šípkami medzi ťažnicami objektov a sú usporiadané časovo zhora nadol. Znázorňujú odovzdanie informácie o udalosti z jedného objektu do druhého. Celý diagram je ilustráciou služby informačného systému, spracovania informácie, inicializačnej udalosti. Obr. B.3.3 Centralizované (fork-shaped) a decentralizované (stairway) riadenie systému podľa [RUP 98]

43 Temperature Controller : Environmental Controller 1: startup ( ) Air Conditioner : Cooler : SystemLog 2: RecordEvent ( ) 3: RecordEvent ( ) Obr. B.4.1 Diagram správ objektov, príklad z Rational Rose 4.0, Rational 1997 Debet [Ciastka > Stav] / Stav -= Ciastka [Vklad] [ else] / Stav += Ciastka - 1 [ Ciastka > -Stav] / Stav += Ciastka - 1 [Vyber] Kredit [Vklad] / Stav += Ciastka [else] / Stav -= Ciastka Obr. B.5.1 Príklad stavového diagramu v UML podľa [Semantics 97] (opravený) Implementácia triedy Ucet podľa [Semantics 97] (revidovaný): class Ucet {

44 private: money Stav; public: Ucet(money StavParam=0) : Stav(StavParam) {} void Vklad(money Ciastka) { Stav += Ciastka ( Stav <= 0 ); } }; void Vyber(money Ciastka) { if (Stav > 0) Stav -= Ciastka; }

45 :Pracovník kontroly IS/IT :Správca aplikácie (SW) :Správca HW a OS Monitoring IS/IT [problém v IS] Analýza stavu Konzultácie riešení Riešenie problému Obr. 1 Príklad rozdelenia diagramu podľa rolí objektov ([Kaj03]) citaj Y, E G = 1 H = Y/ G G = M M = ( G + H ) / 2 [ H - G > E] [ H - G <= E] vypis M Obr. 2 Zápis iteračného algoritmu pre druhú odmocninu podľa Newtnovho iteračného algoritmu v diagrame aktivít

46 const double e= ; double newton(double y) { double m, g = 1, h; start: h = y / g; m = (g + h) / 2; if(fabs(h - g) < e) goto end; else { g = m; goto start; } end: return m; } const double e= ; double newton2(double y) { double m = 1, g, h; do { g = m; h = y / g; m = (g + h) / 2; } while (fabs(h - g) > e); return m; } SQRT read Y, E M=1 do whille ( H-G >E) G=M H=Y/G M=(G+H)/2 write M Obr. 3 Schéma algoritmu funkcie

47 SQRT read Y, E M=1 do whille ( H-G >E) write M Obr. 4 Schéma algoritmu funkcie, druhá verzia G=M H=Y/G M=(G+H)/2 Otvor príslušné súbory Pre všetky vety Čítaj vetu Správna Kontrola správnosti vety Nesprávna Aktualizuj Správa o chybe Zatvor príslušné súbory Obr. 5 Príklad spracovania súboru záznamov v NSD

48 Vybraté objektovo-orientované metodológie C.1 Metodológia Coad-Yourdona Metodológia Coad-Yourdona patrí s metodológiou Boocha medzi najstaršie. Jej životný cyklus zahŕňa dve fázy: stratégiu analýzy a stratégiu návrhu. 1. Stratégia analýzy obsahuje päť etáp tvoriacich jednotlivé vrstvy (objekty, vzťahy, domény, atribúty, služby): 1.1. Identifikácia objektov, kde sú Objekt element problémovej domény, Trieda definícia množiny podobných objektov Identifikácia štruktúry (vzťahy, asociácie medzi objektami): vzťah generalizácie a špecializácie tried a objektov (Generalization-Specialization Hierarchy), vzťah agregácie tried a objektov (Whole-Part Structure) Identifikácia domén, zväzkov (Subjects) obsahujúcich triedy a objekty Definovanie atribútov Definovanie funkcií - služieb (Services); táto etapa zahŕňa kroky: Identifikácia stavov objektu a prechodov medzi stavmi Definovanie a deklarácia metód, rozdelených na riadiace a výpočtové Identifikácia správ a Message Connections medzi objektami. 2. Stratégia návrhu obsahuje nasledovné etapy: 2.1. Návrh prvkov problémovej domény (Designing the Problem Domain Component, PDC) obsahujúci kroky: Aplikácia výsledkov analýzy, ich vstup a testovanie v priebehu navrhovania Kvalitatívne a kvantitatívne rozširovanie objektov, vzťahov, domén, atribútov, služieb Návrh užívateľského rozhrania (Designing the Human Interaction Component) obsahujúci: Klasifikácia používateľov a skupín používateľov systému Klasifikácia používateľských scenárií Návrh organizačnej hierarchie spracovania požiadaviek Návrh detailnej interakcie Návrh grafického užívateľského rozhrania (Graphical User Interface - GUI) Návrh riadenia úloh (Designing the Task Management Component) obsahujúci: Identifikácia spracovania spôsobom multiuser, multisystem, single/multiprocessors a ich komunikácia

49 Identifikácia úloh, riadených udalosťami (event-driven tasks) Identifikácie úloh riadených časom (clock-driven tasks) Identifikácia prioritných a neprioritných úloh Identifikácia koordinátora úloh, dispečera Identifikácia všetkých úloh jednotlivo, definovanie koordinácie a komunikácie Návrh DB (Designing the Data Management Component) obsahujúci Budovanie štruktúry relačnej, OO, alebo inej DB. Normalizácia dátového modelu (pri relačnej DB) 1NF: atribúty musia byť jednoduché, nie zložené, 2NF: každý nekľúčový atribút opisuje len celým kľúčom, 3NF: každý nekľúčový atribút závisí len od kľúča, 4NF: hodnoty viacerých nekľúčových atribútov neodkazujú na ďalší nekľúčový atribút, 5NF: hodnoty viacerých nekľúčových atribútov neodkazujú na ďalší nekľúčový atribút vzhľadom na simultánnu (join) operáciu. Coad-Yourdonova metodológia využíva tri špecifikačné jazyky (notácie, diagramové tachniky): 1. objektový diagram obsahujúci 1.1. objekty (zaoblený rámček s troma oblasťami vnútri pre názov objektu, atribúty a služby) a triedy (ako objekty, ale v dvojitom rámčeku) 1.2. asociácie medzi nimi: generalizácia/špecializácia (gen-spec hierarchy), agregácia (whole-part structure), inštančné (instance connection), poslanie správy (message connection), 2. stavový diagram, ktorý obsahuje: 2.1. stavy objektu, 2.2. prechody medzi stavmi, 3. diagram funkcií objektov obsahujúci: 3.1. cyklus (ovál), 3.2. podmienku (šesťuholník), 3.3. textový blok, 3.4. konektory

50 C.2 Boochova metodológia Grady Booch sa považuje za autora prvej OO metodológie. Nazývala sa aj Object Oriented Design (OOD), zameriavala sa teda najmä na návrh, ale rozlišovala logický a fyzický návrh, preto ju bolo možné využiť aj na analýzu. Postupuje iteratívne a inkrementálne bez pevnej postupnosti krokov. Veľký dôraz kladie na služby, ktoré poskytuje systém, až potom na štruktúru a obsah, ktorá je na začiatku čiernou skrinkou. Vývoj podľa Boocha sa dá charakterizovať nasledovne: - identifikácia tried a objektov ako analýza - identifikácia sémantiky tried a objektov, relácií medzi nimi ako návrh - implementácia. Fázu analýzy zastupuje identifikácia tried a objektov, fázu návrhudnes už je považovaná za metódu, ktorá plne podporuje aj fázu analýzy a návrhu. V metodológii Grady Boocha sa používajú nasledovné diagramové techniky: 1. diagram tried (Class Diagram) znázorňujúci existujúce triedy a vzťahy medzi nimi v logickom návrhu, 2. diagram objektov (Object Diagram) znázorňujúci existujúce objekty a interakcie (posielanie správ: jednoduchých, synchrónnych asynchrónnych, časovaných a pod.) medzi nimi v logickom návrhu, 3. stavový diagram (State-transition Diagram) znázorňujúci stavový priestor triedy v danom kontexte, udalostí, ktoré vyvolávajú prechod z jedného stavu do druhého, akcií v jednotlivých stavoch, 4. interakčný diagram (Interaction Diagram) zobrazujúci scenár toku udalostí medzi objektami, 5. diagram modulov (Module Diagram), ktorý ukazuje alokáciu tried a objektov v moduloch vo fyzickom návrhu, 6. diagram procesov (Process Diagram), ktorý ukazuje alokáciu procesov v procesoroch a zariadeniach vo fyzickom návrhu. Triedy sa znázorňujú "obláčikom s prerušovanými čiarami, objekt s plnými, asociácia - je naznačená plnou čiarou, agregácia - plným krúžkom (na strane agregujúcej triedy), dedenie - šípkou (na strane nadtriedy). vzťah použitia (using) - prázdnym krúžkom (na strane používajúcej triedy). Silná agregácia hodnotou (by value) sa znázorňuje plným štvorčekom na strane agregovanej triedy a prázdnym pri slabej agregácii referenciou (by reference). Vlastnosť triedy sa zapisuje písmenkom v trojuholníku pri triede, kde A - je abstraktná trieda, F - spriatelená (Friend), S - statická, V- virtuálna

51 C.3 Metodológia OMT (Object Modeling Technique) Metodológia OMT bola vyvinutá v USA, vo firme General Electric. Patrila medzi najrozšírenejšie objektovo-orientované metodológie. Bola presadzovaná aj firmou Microsoft a podporoval ju produkt firmy Rational Software Corporation Rational Rose. Za svoj úspech vďačí bohatému grafickému formalizmu a postupnosti krokov podporujúcich všetky etapy životného cyklu vývoja softvérových produktov. Posledná verzia sa datuje k júnu Životný cyklus metodológie OMT je označovaný aj ako metódy vodopádu, keď sa postupne vykonávajú nasledujúce 4 fázy: 1. Analýza - štúdia problémovej domény. 2. Systémový návrh- rozhodnutie globálneho riešenia. 3. Objektovo orientovaný návrh - štúdia riešenia. 4. Implementácia - realizácia riešenia. Fáza analýzy v OMT obsahuje nasledujúce etapy a kroky: 1. zistenie stavu problému, špecifikácia požiadaviek používateľa, 2. vytvorenie objektového modelu (OM), kde je potrebné: 2.1. identifikovať objekty a triedy a vzdať sa redundantných (z dvoch podobných tried sa vyberie výstižnejšia), irelevantných (triedy nesúvisiace priamo s riešeným problémom vytvárajúcim okolie), vágnych (príliš všeobecné triedy s nejasnými hranicami), atribútnych (ďalej neštrukturalizovaných, ktoré sa dajú zapísať ako atribúty), relačných (trieda má byť prvkom, entitou a nie odrážať vzťah), 2.2. pripraviť dátový slovník (opis tried), 2.3. identifikovať asociácie (vzdať sa redundantných, irelevantných, vágnych, ternárnych a odvodených vzťahov), 2.4. identifikovať atribúty (vzdať sa kvalifikátorov, identifikátorov, interných hodnôt), 2.5. identifikovať dedenie, zjednodušiť a spresniť model, 2.6. testovať prístupy, verifikácia prístupových ciest (prepojení v diagrame) pre pravdepodobné úlohy pre systém, 2.7. iterácia a spresnenie modelu, 2.8. skupiny tried uzavrieť do modulov, 3. vytvorenie dynamického modelu (DM), čo znamená vytvoriť: 3.1. diagramy udalostí, 3.2. stavové diagramy, 4. vytvorenie funkčného modelu (FM), kde je potrebné: 4.1. špecifikovať V/V hodnoty, 4.2. vytvoriť diagramy toku dát (Data Flow Diagram - DFD), 4.3. popísať procesy, funkcie; metóda nepredpisuje formu, 4.4. identifikovať obmedzenia, závislosti, podmienky, 5. realizácia verifikácie v iterácii a spresňovanie modelov, vytvorených v predchádzajúcom procese. Systémový návrh Vo fáze vytvárania systémového dizajnu sa navrhne aplikácia na najvyššej úrovni a tvorí sa hrubý návrh celého systému

52 V rámci tejto fázy sa vykonávajú nasledujúce etapy: návrh organizácie systému do subsystémov, identifikácia paralelizmov a protirečení, návrh fyzickej alokácie subsystémov, návrh stratégie pre DB, návrh riadenia systému (procedurálne, riadené udalosťami, paralelné, iné), definovanie hraničných podmienok (spustenie a ukončenie práce systému, zastavenie práce pre chybu, prerušenie a pod.), zostavenie priorít systému (nekompatibility), návrh práce systému (dávkovo, v reálnom čase, kontinuálne, interaktívne, transakčne, paralelné spracovanie a pod.). Objektovo orientovaný návrh Vo fáze objektovo orientovaného návrhu sa projektant vracia k modelom, vytvoreným vo fáze analýzy a znovu ich optimalizuje. V tejto fáze sa vykonávajú nasledujúce etapy: kombinovanie troch modelov (nájsť operácie pre procesy FM a akcie DM, priradiť procesy objektov k prijímaným správam, priradit triedy z OM k objektom DM, operácie z DM zaradiť do tried OM), popis algoritmov operácií, vytvorenie modelu DB z perzistentných (stálych) objektov, optimalizácia prístupov k dátam, normalizácia DB modelu, zvýšenie úrovne dedenia, návrh implementácie atribútov asociácií, determinovanie reprezentácie atribútov, uzavretie triedy a asociácie do modulov, dokumentovanie (návrh) rozhodnutia

53 C.4 Metodológia OMT2 Koncepcia vodopádu v OMT sa v metodológií OMT2 nahrádza stratégiou iteratívneho, inkrementálneho a rekurzívneho vývoja. Iteratívnosť je zabezpečená opakovaným, cyklickým návratom k riešeniam z predchádzajúcich krokov. Inkrementálnosť sa prejavuje pridávaním nových prvkov a vlastností do pôvodných diagramov v ďalších krokoch a rekurzívnosť v rozvíjaní prvkov, v expandovaní jednoduchých, vysokoúrovňových štruktúr do zložitejších na nižších úrovniach. V OMT2 už nie je potrebné zamýšľať sa explicitne nad optimalizáciou modelov. Nie je potrebné vyraďovať nesprávne triedy a objekty, asociácie a atribúty, ako je tomu v OMT, pretože sa postupuje od najvyššej úrovne systému až po najmenšie detaily. V OMT2 sa rozširuje množina tried systému podľa vnútorných potrieb a návrhov používateľa v jednotlivých krokoch od najhrubšieho návrhu reálnych objektov (napr. klient, účet, pokladňa a pod.), neskôr vstupno-výstupných tried (V/V dialógy, výstupné zostavy, menu, formy, ) a až v posledných etapách sa vytvárajú nevyhnutné vnútorné objekty (výpočtové a pamäťové triedy) a detaily. Týmto spôsobom sa vyhneme chybám, ktoré vznikajú pri hromadnom vzniku všetkých objektov a vzťahov v OMT už na začiatku, ku ktorým sa v ďalších krokoch nevraciame. Toto je prvý rozdiel oproti OMT, kde sme optimalizovali v explicitných cykloch: v OMT2 existuje okrem vonkajších cyklov analýzy, návrhu a implementácie aj prirodzená vnútorná špirála návratov k pôvodnému riešeniu. Druhý rozdiel je v tom, že nezačíname analýzou a budovaním objektového modelu, ale celkovou konceptualizáciou, v ktorej je začiatkom zber používateľských požiadaviek a zoznam služieb systému, čo je prirodzenejšie a jednoduchšie. Životný cyklus metodológie OMT2 sa skladá z piatich nasledujúcich fáz: 1. Konceptualizácia. 2. Analýza. 3. Systémový návrh. 4. Objektovo orientovaný návrh. 5. Implementácia. Konceptualizácia V konceptualizácii sa snažíme spoznať výrobný proces alebo služby klienta, pre ktorého budeme navrhovať nový informačný systém. Konceptualizácia obsahuje spísanie služieb systému a zoznamu požiadaviek používateľa. V konceptualizácii sa identifikujú: 1. požiadavky používateľa a koncept riešenia, hodnotia sa používané technológie, situácia na trhu, finančné a časové zdroje, 2. služby systému, kde je potrebné determinovať: 2.1. systémové hranice, 2.2. používateľov, 2.3. použitie systému pre jednotlivých používateľov, 2.4. inicializačné udalosti, 2.5. ukončovacie podmienky, 2.6. zoznam typických a aditívnych scenárií, 2.7. výnimky

54 Analýza Analýza makroprocesov doménových objektov V tejto etape je použitý zaujímavý postup. Najprv je potrebné sa zamerať na doménové objekty, teda objekty reálneho sveta nami skúmanej domény. Vzniká tu preto málo chýb a omylov. Tieto objekty máme pred sebou a stačí ich len spoznať a správne zapísať do modelov. Pritom by sa malo postupovať nasledovne: 1. identifikovať triedy a operácie reálneho sveta, 2. vytvoriť stavové diagramy pre objekty. Analýza makroprocesov aplikačných objektov Za aplikačné objekty možno považovať jednotlivé programy a ich riadiace a vstupno-výstupné triedy, ako aj všetky objekty aplikácie, ktoré zabezpečujú vstup/výstup, rozhranie a riadenie aplikácie (V/V formuláre, dialógové okná a obrazovky, riadiace dialógy, menu a pod.). Tieto triedy objektov sú potrebné a projektant ich môže určiť v spolupráci s používateľom pomerne presne a ľahko. Tým obohatí naše modely z predchádzajúceho kroku. Odporúča sa, aby v rámci tejto etapy boli realizované nasledujúce kroky: 1. identifikácia systému a jeho hraníc, 2. identifikácia používateľov, 3. zhodnotenie služieb (Use Case) a zápis aplikačných tried do modelov, 4. určenie udalostí medzi používateľmi a systémom, zavedenie riadiacich a ďalších tried na spracovanie udalostí v sekvenčných diagramoch, 5. identifikácia operácií aplikácie, 6. vytvorenie zovšeobecného rozhrania. Analýza mikroprocesorov objektových modelov V tejto etape sa zjemňuje analýza doménových a aplikačných objektov a dopĺňa sa posledná kolekcia interných objektov alebo tried v prípade konkrétnych návrhov používateľa. Interné objekty zabezpečujú konkrétne riadiace, výpočtové a pamäťové služby. Keby sme ich popisovali hneď v prvej etape analýzy, mohli by vzniknúť redundancie a neoptimálne modely. Takto postupne popisom doménových, potom aplikačných a nakoniec interných objektov neprestajne rozširujeme modely a postupujeme od najočividnejšieho k najskrytejšiemu. Vytvorenie interných objektov sa dokončí až vo fáze návrhu (etapa objektového návrhu). V tejto etape sa vykonávajú nasledujúce kroky: 1. identifikácia tried z problémových domén a služieb, 2. vytvorenie modelového slovníka, v ktorom sa popisujú dvoma-tromi vetami triedy, atribúty, metódy, vzťahy, udalosti, stavy, 3. identifikácia asociácií a atribútov, 4. zvýšenie úrovne dedenia, 5. verifikovanie prístupových ciest, 6. zatriedenie skupín tried do subsystémov, 7. iterácia a zjemňovanie

55 Analýza mikroprocesorov dynamických modelov Po dokončení objektových modelov je potrebné podľa OMT2 pristúpiť k ich analýze v čase a k pozorovaniu dynamiky správania. Pritom sa vykonávajú nasledujúce etapy: 1. identifikácia externých udalostí, 2. definovanie stavov medzi udalosťami, 3. tvorba stavových diagramov, najmä pre riadiace triedy, 4. identifikácia operácií vyvolaných prechodmi, 5. validácia modelu vzhľadom na pôvodné služby a scenáre. Analýza mikroprocesorov funkčných modelov Po definovaní kto, alebo čo a kedy v predchádzajúcich etapách fázy analýzy je potrebné dať odpoveď aj na otázku ako. V tejto etape sa popisuje každá operácia systému a vytvárajú sa objektovo orientované Data Flow diagramy. Systémový návrh Tak ako v OMT aj v OMT2 v tejto fáze sa definuje na najvyššej úrovni celkový pohľad na nový informačný systém, na jeho návrh a implementáciu. Reprezentuje sytémovú architektúru a kolekcie tried, alokovaných v jednotlivých subsytémoch. Špecifikujú sa závislosti medzi subsystémami a redukujú sa nadbytočné a cirkulujúce závislosti. Vykonávajú sa nasledovné etapy: 1. odhad výkonu a adekvátnosti zdrojov, 2. dekompozícia systému do subsystémov, 3. tvorba plánu znovuvyužitia pôvodných subsystémov, ako aj novonavrhnutých v budúcnosti, 4. determinovanie stratégie distribúcie a konkurencie, 5. návrh riadenia globálnych zdrojov (spoločné zariadenia a prostriedky), 6. návrh riadenia DB, 7. inicializácia a ukončenie práce systému, chybové podmienky, 8. špecifikácia implementácie. Objektovo orientovaný návrh V objektovo orientovanom návrhu sa ukončuje práca návrhu IS na najnižšej úrovni. Ide o dokončenie tvorby interných objektov a ich vkladania do diagramov obsahujúcich doménové a aplikačné objekty. OO návrh obsahuje nasledovné etapy: 1. analýza modelov, ktoré boli vytvorené v analýze, 2. pridávanie nových elementov (triedy, asociácie, operácie) a príslušenstva (orientácia, viditeľnosť, kardinalita), návrh logickej aj fyzickej štruktúry dát, normalizácia, návrh číselníkov, 3. identifikácia interných systémových stavov, pamäťových objektov a redukovanie závislostí, 4. expandovanie operácií, tvorba algoritmov, diagramov algoritmov metód, funkcií v Jacksonovej notácii,

56 5. logická optimalizácia celého návrhu z hľadiska efektívnosti prístupov a operácií, 6. zapúzdrenie externých závislostí jadra systému pomocou interface objektov, oddelenie DB, jadra a rozhrania systému, 7. podrobný prepis štruktúr tried a asociácií do jazykových konštrukcií implementácie, 8. zvýšenie implementačného dedenia (niekedy stačí meniť názvy a poradie argumentov)

57 C.5 Rational Unified Process (RUP) Rational Unified Process bol vyvinutý a je udržiavaný spoločnosťou Rational Software Corporation, ktorá ho ponúka ako produkt v html formáte. RUP je charakterizovaný podľa [Villiers] ako model vývoja softvérových produktov (software development process model), ako skelet (framework) pre aplikovanie najlepších postupov v životnom cykle vývoja softvéru (6 best practices of modern software engineering): - iteratívny vývoj (Develop Iteratively) ako možnosť rozvíjať softvér zjemňovaním (refinement) a pridávaním ďalších vlastností (increments) v jednotlivých iteráciách, v ktorých sa zväčsuje pochopenie problému a získava demonštráciami výsledkov iterácie spätná väzba od používateľa, postupným približovaním sa predstave zadávateľa sa redukujú aj riziká projektu, - správa používateľských požiadaviek (Manage Requirements), neustále dopĺňanie, triedenie a hodnotenie požiadaviek, celý vývoj je podriadený použiadavkám zadávateľa a používateľa, - použitie komponentovej architektúry (Utilize Component Architectures), aplikácia vzorov, komonentov, nákup a využitie polotovarov a hotových modulov (je lacnejšie kúpiť produkt, ktorý spĺňa 75% požiadaviek, ako vyvíjať produkt, ktorý spĺňa nakoniec tiež 75%), - vizuálne modelovanie (Model Visually), vytváranie modelov reality na pochopenie problému, pre analýzu, návrh, implementáciu a ďalší rozvoj, - kontinuálne sledovanie a kontrolu kvality postupu vývoja aj výsledného produktu (Verify Quality), - riadenie a kontrola zmien (Control Changes). Obr. C.5.1 RUP model RUP je jednou z možností ako použiť jazyk UML pre vývoj softvéru, je charakteristický dvojrozmerným chápaním vývoja v čase a štruktúre (obr. C.5.1)

58 Dynamický rozmer procesu na horizontálnej osi obsahuje štyri fázy životného cyklu RUP: Inception (inicializácia, konceptualizácia) ako špecifikácia vízie koncového produktu [Kruchten 01], identifikácia projektu, jeho koncepcie, účelu, rozsahu, identifikácia používateľských požiadaviek, modelovanie firemných procesov Základné výstupy sú: - koncepčný dokument o projekte, základné požiadavky klienta a predpokla-dané vlastnosti produktu, - úvodný (základný) konceptuálny diagram (10% - 20% kompletnosť), - úvodný (základný) slovník projektu (aj ako doménový model), - úvodné (základné) firemné procesy, - plán projektu, - úvodná analýza predpokladaných rizík, - jeden alebo viac prototypov. Elaboration (rozpracovanie, analýza a návrh) ako definovanie vlastností a návrh kvalitnej architektúry systému, naplánovanie postupu a zdrojov, Základné výstupy sú: - konceptuálny diagram (min. 80% kompletnosť), identifikácia všetkých používateľov a služieb, ktoré sú aj spracované, - úplný zoznam požiadaviek, aj takých, ktoré nie sú priradené ku konkrétnej službe, - presná deklarácia architektúry projektu, - funkčný prototyp s konkrétnou architektúrou, - podrobný ďalší plán projektu, - revidovaná analýza predpokladaných rizík. Construction (konštrukcia) ako budovanie systému, inkrementálne pridávanie funkcionality do štruktúry systému, Základné výstupy sú: - softvérový produkt, integrovaný na požadovanej platforme - používateľský manuál, - charakterizácia aktuálnej verzie produktu - presná deklarácia architektúry projektu, - funkčný prototyp s konkrétnou architektúrou, - podrobný ďalší plán projektu, - revidovaná analýza predpokladaných rizík. Transition (zavedenie) ako dodanie produktu koncovému používateľovi, zaškolenie, podpora a údržba produktu. Tieto štyri fázy tvoria vždy jeden cyklus, prvý je označovaný ako inicializačný, ostatné ako evolučné cykly, počas ktorého vznikne prvá až n-tá generácia produktu. Každá fáza obsahuje iterácie, ktorých počet závisí od celkového poznania problému a od jeho zložitosti. Každá iterácia môže obsahovať nasledovné sekvencie aktivít - modelovanie firemných procesov (Business Modelling), - zber používateľských požiadaviek (Requirements), - analýzu a návrh (Analysis & Design),

59 - implementáciu (Implementation), - testovanie (Test), - ďalší rozvoj (Deployment), - konfigurácia a zmenové konanie (Configuration & Change Mgmt), - riadenie projektu (Project Management) - prostredie (Environment). Obsah jednotlivých aktivít je v každej fáze iný: implementácia v rozpracovaní a v konštrukcii bude rozdielna obsahom, formou, rozsahom aj významom. Napríklad v prvej fáze vzniká konceptuálny prototyp, v druhej štrukturálny, v ďalších vznikajú jednotlivé predbežné testovacie vydania (release) a ďalšie funkčné dodávky (delivery) RUP sleduje tvorbu a vývoj dokumentov, čo je potrebné a upriamuje pozornosť používateľov na výsledky, nie na formálny proces. RUP sa snaží zmierniť riziko sledovaním priorít jednotlivých požiadaviek a úloh, analýzou rizika (najmä používateľského, až potom technického) a jeho zohľadnením do každej iterácie. K zníženiu strát napomáha aj tvorba funkčného prototypu na konci každej iterácie a využite spätnej väzby od používateľa na ďalšie rozhodovanie a smerovanie práce na vývoji produktu. Obr. C.5.2 schéma pracovného postupu na spracovanie používateľských požiadaviek v [RUP 98] Pre porovnanie s inými metodológiami je potrebné sledovať najmä obsah toku aktivít v sekvencii zber používateľských požiadaviek (Requirements) na obr. C.5.2 a analýza a návrh (Analysis & Design) na obr. C.5.3. V prvej z nich ide o identifikáciu používateľov (Actors) ich požiadaviek (Needs) a presnú charakteristiku budúcich služieb systému (Use Cases). Aktivity Detail a Use Case, User-Interface Modeling a User-Interface Prototyping spresňujú

60 priebeh samotných služieb zachytených do tokov udalostí (flow of events) a rozhraní s hraničnými triedami (boundary classes), ktoré napomáhajú modelovaniu interakcií s okolím systému. V analýze a návrhu (Analysis & Design) je v aktivitách Analýza požiadaviek, Návrh subsystémov, Návrh tried, Návrh požiadaviek (Use-Case Analysis), najdôležitejšia identifikácia objektov podľa scenárov dynamického modelu správania sa služby a jej interakcií. Objekty a triedy sa delia na hraničné (boundary), ktoré komunikujú s používateľmi (User interface classes), iným systémom (System interface classes) alebo zariadeniami (Device interface classes), na dátove (entity) a riadiace (control). Zo scenárov v tvare komunikačných diagramov sa hľadajú aj potrebné metódy pre jednotlivé triedy podľa požiadaviek spolupracujúcich tried (správy, žiadajúce o vykonanie činnosti, vchádazajúce do triedy, umiestnené na hrane medzi triedami). Pridávajú sa aj atribúty pre potreby metód a uchovanie hodnôt. Vznikajú aj vzťahy asociácie a agregácie medzi komunikujúcimi triedami. Toto všetko (triedy, metódy, atribúty, vzťahy) je možné preniesť do diagramu tried. Pri optimalizácii dátového modelu perzistentných (stálych) tried sa spomína potreba denormalizácie kvôli častej operácii výberu zviazaných informácií z viacerých tried (join). Pri mapovaní do relačného modelu sa spomína 1. a 2. normálna forma, ale Obr. C.5.3 schéma pracovného postupu pre analýzu a anávrh v [RUP 98]

61 RUP exaktne popisuje - role (roles), úlohy a pozície (kto?) aktérov v procese (analytik, návrhár, implementátor, testér, manažer, recenzent, architekt, atď.), ktorí majú svoje povinnosti a schopnosti/možnosti plniť ich, - dokumenty (artifacts), informácie (čo?) vo forme dokladov, zoznamov, požiadaviek, katalógov, modelov, diagramov, ktoré sa dodávajú ako vstup alebo výstup aktivity, vznikajú a modifikujú sa v procese, - aktivity, atomárna časť práce (ako?) alebo úlohy v procese, vykonávaná jednou alebo viac osobami v konkrétnej role, výsledkom aktivity je vytvorenie alebo modifikácia dokumentu (príklad: zápis požiadaviek, identifikácia služieb, tried, atď.), - toky (workflow), sekvencia spriahnutých aktivít (kedy?), rolí a dokumentov s nimi spätých v časovej postupnosti

62 Prílohy

63 Prílohy

64 Prílohy

65 Prílohy

66 Prílohy

67 Prílohy

68 Prílohy

69 Prílohy

70 Prílohy

71 Prílohy

72 Prílohy

73 Prílohy

74 Prílohy

75 Prílohy

76 AGILE TECHNIQUES IN SOFTWARE PROJECT MANAGEMENT Polášek Ivan, Ing., Ph.D., Gratex International, a.s., Bratislava, Slovak Republic, Introduction Martin Fowler starts one paper about new software methodologies [Fow01a] with subtitle From Nothing, to Monumental, to Agile. It characterizes the evolution from the chaotic activity of coding and fixing the code to the conservative methodologies (SSADM, SDM, Coad-Yourdon, OMT, ) with strong structure of lifecycle or process, set of diagrams and methods to the Agile Modeling and the other new modern lightweight methodologies. Developers don t accept standard methodologies too much and they do not see them very successful. They call them monumental (Jim Highsmith), bureaucratic or heavy (Martin Fowler). Everybody (mainly methodologists and university lecturers) talks about them (to the big customers and poor students), almost nobody use them strictly in real projects. The new group of lightweight methodologies (SCRUM, FDD, DSDM, XP, AM, OS, Crystal Family, ) have appeared as a reaction to heavy methodologies nowadays. Many software-houses and IT customers ask to use them as a compromise between no process and process without slows down the development, as the compromise between chaos and unadaptive planning and development. But they are more than only simple compromise: they are adaptive and people oriented rather than predictive and process oriented. Agile processes welcome changes, they are derived from Rapid Application Development and their priority is to satisfy the customer through early and continuous delivery of valuable software (The Agile Alliance [AAM02]). We will analyse in our paper Agile Modeling and Extreme programming and their possible combination with the older object-oriented methodologies (Object Modeling Technique II, Rational Unified Process). 1 Agile Modeling We find the base rules for the agile methods and modeling in Agile Manifesto [AAM02]. It contains Principles behind the Agile Manifesto. They start with the subtitle We follow these principles. The first rule is as follows: Our highest priority is to satisfy the customer as a reaction to the reality and a lot of failures in software engineering area (Standish Group Report). We can accept it also with a further principle Working software is the primary measure of progress.. Agile techniques are rather code-oriented and less document-oriented, with smaller amount of documentation for a given task ( source code is the main part of the

77 documentation [AAM02]). User needs correct project (running code) and not only huge documentation. The next principle Welcome changing requirements, even late in development. is sometimes hard to implement in the standard lifecycle, because the client wants to know how long he has to wait, how much he has to pay and exactly what (in his new information system) he will receive (sometimes it is very simple: he wants everything and very fast and with the most modern technologies). Also his developer wants to know, what he has to do, and if it possible to do it in stipulated time The third principle Deliver working software frequently, is also hard to meet. Client is working with his old system and he need still the whole functionality. His business is running, he doesn t want to stay, do nothing and wait for the next/last version, it is impossible. Long parallel duty and services is infeasible and hard for management and employees. The next rules Business people and developers must work together daily throughout the project. and face-to-face conversation are well-known, very serious and necessary to implement. It is impossible to start with User requirements management & Analysis and then work on Design & Implementation phases alone in the softwarehouse out of the client office and then show the result to the user. It results big surprises on the both sides, disillusion and often failure of the whole project. Whole set of principles you can see in [AAM02]. Their authors say, that the best way is to implement them all (as the practices of Extreme Programming), sometimes it is hard to do it and easier way is to use some of them at least. 2 Extreme Programming XP is the most popular from the agile methodologies. Kent Beck and Ward Cunningham generalize their practices on projects during the 1990 s. It builds up to a twelve tried and tested practices [XP02], [XPC02], [Bec99], [Col01]. These 12 related practices increase productivity and quality and they work best for small team of 5 to 15 developers. XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development. We can analyse their applicability: 1. The Planning Game It is necessary to make quickly a rough plan and refine it as the things become more clear. We cannot know everything when we start: developers and customers will learn new things as the project will progresses. We have to

78 define use cases that briefly capture functional requirements, required features, scope and priority, the next release dates. 2. Testing This is the key principle of XP. Developers write the unit tests as they write code. They have to think about the problem before they program the system. The customer writes the acceptance (functional) tests for each activity, Use Case, Scenario or story. The test routines are the specification of the method s functionality and they will be used for testing after programming to show proper work of the system. If a bug occured, first we write a unit test that shows the problem, and then we fix it. Acceptance tests are automated to test every release with additional features. Developer can write acceptance test framework. 3. Pair Programming Pair programming means, that whole module code is written at one machine by two people. One person is writing, the other think about globally. They switch their roles throughout the day. It increases quality and does not double the programming costs, because the programmers are not only typing. Kent Beck writes in [Bec99]: - all design decisions involve at least two brains, - at least two people are familiar with every part of the system, - there is less chance of both people neglecting tests or other tasks, - changing pairs spreads knowledge throughout the team, - code is always being reviewed by at least one person. 4. Refactoring We should write the simplest code that could possibly work, but we ll learn along the way and we can improve code without changing functionality, without breaking the tests. 5. Simple Design Design of the system has to be as simple as possible and still work. Once more Kent Beck and his another list in [Bec99]: - all the tests run correctly, - it contains clear and no duplicate code, - the code consist of the fewest possible classes and methods, - it doesn t include extra features that will be not used. 6. Collective Code Ownership The team members collectively own the code to make changes to improve it. It negates the chaos from no code ownership and reduces bottleneck of the individual code owner. This requires extreme discipline: You break it, you fix it. - unit tests must run all the time. 7. Continuous Integration Developers should integrate the code several times (at least once) a day - as often as possible, after they get all the unit tests to run. This keeps the team moving at maximum speed, rather than in the typical yo-yo effect of

79 traditional approaches: write a lot, do a big-bang integration, than spend a lot of time fixing the problems. 8. On-site Customer It is very effective to have the customer available on-site to clarify stories and to make critical business decisions to eliminate bottlenecks waiting for this control messages. 9. Small Releases It hangs together with Continuous Integration - we will receive concrete feedback on what meets customer needs and what doesn t. Release the system as soon as it makes sense hour week 60-hour weeks affect product quality. The programmer has to be fresh in the morning and tired (but satisfied) every evening. Kent Beck writes: On Friday, I want to be tired and satisfied enough that I feel good about two days to think about something other than work. Then on Monday I want to come in full of fire and ideas. Very simple and important principle. 11. Coding Standards A coding standard makes the code easier to understand and improves consistency among team members. Without coding standards, it is harder to refactore the programming code. 12. Metaphor Metaphor contains a consistent picture how it will works together, describing the architecture. 3 Rational Unified Process Rational Unified Process is one of the leader of object-oriented software processes from the Rational Corporation (developed by Philippe Kruchten, Ivar Jacobson and others at Rational as the process complement to the UML [Rat98], [Kru01], but see also [Amb01], [Hen99], [Vil01]). RUP is possible to use as the conservative methodology (it can be used in a very traditional waterfall style) or as an agile method. It all depends on how you tailor it in your environment.: it is incremental development process with working prototypes at the end of the each iteration, user requirements-driven, and architecture-based approach to development. RUP is a configurable process framework, template and as such can accommodate a wide variety of processes. Therefore it is too open and vague and for many developers if it can be anything it ends up being nothing. The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language (UML). The UML is a industry-standard language that allows us to clearly communicate requirements, architectures and designs. The UML was

80 originally created by Rational Software, and is now maintained by the standards organization Object Management Group (OMG). [OMG03] Figure 1: The lifecycle of the Rational Unified Process (RUP). 4 Combination as a Compromise or The very first step We start to implement Agile modeling and Extreme programming in our project lifecycles in Gratex International, a.s. We use immediate these XP principles: 1. The Planning Game(1) and Metaphor (12), 2. Testing (2) (we insert it to the phases at the beginning of the lifecycle, into the documents and contracts, we have only problem with customer gestors and their busyness), Refactoring (4), Coding Standards (11), Simple Design (5) and partly Collective Code Ownership (6), 3. Continuous Integration (7) and Small Releases (9) (from 1 to 3 builds daily, managed and supported with our Gratex knowledge office tools - but not delivered to the customer). We expect and we have the problems with 1. Pair programming, 2. On-site Customer (we ask for it, but business gestors are busy and we have no other specialists there), hour week. Derived lifecycle, combining OMT2, RUP and XP could be as follows: repeat

81 { for all requirements create/update Use Cases & Test Cases for all Use Cases create/update interaction diagram create/update I/O model (forms, listings) create/update class diagram create/update state diagram for dynamic elements create/update function model diagrams for dynamic elements } repeat { for (every use cases or all system) { complete output services (output forms and listings) create/update data services according to outputs needs complete input/output services appropriate to DB structure } create/update user manual create/update test cases create/update system prototype } until the user is not satisfy with prototype and user manual create/update business services (output > DB flow) create/update test cases (DB > input flow) create/update multitier model optimize algorithms, DB, I/O design and cass structure complete DB for DWH and datamining implement information system } until IS is correct and complete Figure 2: Standard waterfall lifecycle in our projects (Gantt Diagram )

82 Figure 2: Lifecycle combined with XP principles with apparent acceleration Summary Agile modeling and Extreme programming are widely applicable, but we have to accept the following factors, suggesting these adaptive process: 1. Uncertain or volatile requirements from the user, 2. Small team of 5 to 15 responsible and motivated developers, 3. Customer who understands and will get involved, 4. Not fixed scope and price. The challenge for us now is to implement and test Pair programming and complete XP principles into the lifecycle and combine it with the whole lifecycle in real projects. Literature: [AAM02] Agile alliance manifesto: [AMH02] Agile modeling homepage: [Amb01] Ambler S.: Completing the Unified Process With Process Patterns, [Bec99] Beck K.: Extreme Programming Explained: Embrace Change. Addison- Wesley, 1999 [Col01] Collins C and Roy Miller R.:Extreme Programming Distilled, RoleModelSoftware, 2001, [Fow01a] Fowler M.: The New Methodology, Thought Works, 2001, [Fow01b] Fowler M.: Is Design Dead?, Thought Works, 2001, [Hen99] Henderson-Sellers B., Due R. and Graham I.: Existing OO Process- Focussed Methods: A Critique of RUP and OPEN from a PM perspective, TOOLS Workshop on Project Management of Object- Oriented Developed Systems, 1999 [IEE02] IEEE INTERNET COMPUTING: [Jac99] Jacobson, I, Booch G. and Rumbaugh J.: The Unified Software Development Process, Addison-Wesley,