MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨ AKULTA INFORMATIKY !"#$%&'()+,-./012345 Deklarat´ıvne-imperat´ıvny aplikaˇcny´ r´amec DIPLOMOVAPR´ ACA´ Martin Jurˇca Brno, jar 2012 Prehl´asenie Prehlasujem, zeˇ tato´ diplomova´ praca´ je moj´ım povodnˆ ym´ autorskym´ die- lom, ktore´ som vypracoval samostatne. Vsetkyˇ zdroje, pramene a literaturu,´ ktore´ som pri vypracovan´ı pouzˇ´ıval alebo z nich cerpal,ˇ v praci´ riadne citu- jem s uveden´ım upln´ eho´ odkazu na pr´ıslusnˇ y´ zdroj. Ved´ucipr´ace: RNDr. Vlastislav Dohnal, Ph.D. iii Pod’akovanie Rad´ by som tymto´ pod’akoval panovi´ Vlastislavovi Dohnalovi za jeho od- bornu´ pomoc a vedenie pri tvorbe tejto prace.´ Dalejˇ by som rad´ pod’akoval panovi´ Pavlovi Cenkovi za jeho odbornu´ asistenciu pri tvorbe navrhu´ tohto aplikacnˇ eho´ ramca.´ Tiezˇ by som rad´ pod’akoval panom´ Petrovi Kubovi, Alesoviˇ Pejchalovi a Milanovi Krˇapkovi´ za podporu a spatn¨ u´ odozvu pri zvazovanˇ ´ı roznychˆ architektonickych´ roz- hodnut´ı v navrhu.´ V neposlednej rade by som chcel pod’akovat’ Andreji Cechovejˇ a mojim rodicomˇ za ich podporu bez ktorej by tato´ praca´ nemohla vzniknut´ ’. v Zhrnutie Rozvoj v oblasti informacnˇ ych´ systemov´ a enterprise aplikaci´ ´ı viedol k na-´ vrhu corazˇ zlozitejˇ sˇ´ıch aplikaci´ ´ı tvorenych´ znacnˇ ym´ mnozstvomˇ progra- moveho´ kodu.´ Aplikacie´ tvorene´ vel’kym´ mnozstvomˇ programoveho´ kodu´ su´ obvykle naro´ cnejˇ sieˇ na udrzovanieˇ a potencialne´ sa v nich vyskytuje viac chyb.´ Tento stav bol adresovany´ roznymiˆ aplikacnˇ ymi´ ramcami,´ ktore´ riesiaˇ beznˇ e´ ukony´ vykonavan´ e´ aplikaciami.´ Tieto ramce´ tiezˇ obvykle zavadzaj´ u´ doporucenˇ e´ praktiky a konvencie pre tvorbu aplikaci´ ´ı. Niektore´ aplikacnˇ e´ ramce´ zaviedli deklarat´ıvne popisy aplikacie,´ ktore´ umozˇnujˇ u´ vyjadrit’ rozneˆ castiˇ aplikacie´ deklarat´ıvnym popisom, ciˇ uzˇ vyu- zitˇ ´ım struktˇ ur´ poskytovanych´ danou platformou, alebo pomocou konfi- guracie.´ Tato´ praca´ sa zaobera´ prepojen´ım deklarat´ıvneho a imperat´ıvneho pr´ıs- tupu ku tvorbe aplikaci´ ´ı s ciel’om vytvorenia noveho´ aplikacnˇ eho´ ramca.´ Ciel’om aplikacnˇ eho´ ramca´ vytvoreneho´ v tejto praci´ je rozsˇ´ırit’ moznostiˇ su´ casnˇ ych´ aplikacnˇ ych´ ramcov´ o nove´ deklarat´ıvne koncepty. vii Kl’´uˇcov´eslov´a aplikacnˇ y´ ramec,´ deklarat´ıvny ramec,´ modularny´ ramec,´ Java, ORM, JPA, validacia´ dat,´ Java Enterprise Edition ix Obsah 1 Poziadavkyˇ ...... 5 1.1 Ciele ...... 5 1.1.1 Vyuzitieˇ pre enterprise aplikacie´ ...... 5 1.1.2 Deklarat´ıvny navrh´ aplikaci´ ´ı...... 5 1.1.3 Opakovatel’na´ vyuzitelˇ ’nost’ kodu´ ...... 6 1.1.4 Abstrakcia datov´ eho´ ulo´ ziskaˇ ...... 6 1.2 Funkcnˇ e´ poziadavkyˇ ...... 7 1.2.1 Pouzˇ´ıvatel’ske´ u´ cty,ˇ skupiny, role a prava´ ...... 7 1.2.2 Multi-pouzˇ´ıvatel’ske´ aplikacie´ ...... 7 1.2.3 Podpora viac-nasobn´ eho´ behu aplikacie´ ...... 7 1.2.4 Centralna´ konfiguracia´ aplikacie´ ...... 8 1.2.5 Automaticka´ validacia´ konfiguracie´ ...... 8 1.2.6 Logovanie ...... 8 1.2.7 Alarmy ...... 9 1.2.8 Behove´ statistikyˇ ...... 9 1.3 Nefunkcnˇ e´ poziadavkyˇ ...... 9 2 Koncepty aplikaˇcnych´ r´amcov ...... 11 2.1 Model-View-Controller architektura´ ...... 11 2.2 Deklarat´ıvna tvorba aplikaci´ ´ı ...... 12 2.3 Agnosticky´ pr´ıstup k pouzˇ´ıvatel’skemu´ rozhraniu ...... 12 2.4 Databazov´ a´ abstrakcia ...... 13 2.5 Automaticka´ validacia´ dat´ ...... 13 2.6 Model udalost´ı ...... 14 2.7 Automaticke´ poskytovanie zavislost´ ´ı ...... 14 2.8 Autentizacia´ a autorizacia´ ...... 14 2.9 Logovanie ...... 15 3 N´avrharchitekt ´ury ...... 17 3.1 Struktˇ ura´ aplikacie´ ...... 17 3.2 Jadro ...... 18 3.2.1 Podporne´ nastroje´ ...... 19 3.3 Moduly ...... 19 3.3.1 Stav modulu, instalˇ acia´ a odinstalovanieˇ ...... 20 1 3.4 Sluzbyˇ ...... 20 3.5 Datov´ e´ sady ...... 23 3.6 Konfiguracia´ ...... 23 3.7 Lokalizacia´ ...... 24 3.8 Zivotnˇ y´ cyklus aplikacie´ ...... 25 3.8.1 Spustenie aplikacie´ ...... 25 3.8.2 Ukoncenieˇ aplikacie´ ...... 26 3.9 Module Manager ...... 26 3.9.1 Datov´ e´ sady ...... 27 3.10 Presenter ...... 27 3.11 File Logger ...... 27 3.11.1 Datov´ e´ sady ...... 27 3.12 Users ...... 28 3.12.1 Datov´ e´ sady ...... 28 3.13 Sessions ...... 28 3.13.1 Datov´ e´ sady ...... 28 3.14 Alarm Logger ...... 29 3.15 Statistics ...... 29 3.15.1 Datov´ e´ sady ...... 29 3.16 Billing ...... 29 3.16.1 Datov´ e´ sady ...... 29 3.17 Instalˇ ator´ ...... 29 4 Uk´azkov´aaplik´aciaˇ ...... 31 4.1 Modul Fridge ...... 32 4.2 Modul GUI ...... 33 4.3 Spustenie aplikacie´ ...... 33 4.4 Beh aplikacie´ ...... 34 4.5 Ukoncenieˇ aplikacie´ ...... 35 5 Z´aver ...... 37 2 Uvod´ Aplikacnˇ e´ ramce,´ ako napr´ıklad Tapestry [15], predstavuju´ rozsˇ´ırenia danej softwarovej platformy, napr´ıklad Java 6 Enterprise Edition [14]. Pridavaj´ u´ dodatocnˇ u´ funkcionalitu oproti funkcionalite poskytovanej danou softwa- rovou platformou, hoci tato´ funkcionalita je obvykle zaistena´ vyuzitˇ ´ım exis- tujucich´ konstruktovˇ danej platformy. Motivaciou´ pre vytvorenie noveho´ aplikacnˇ eho´ ramca´ je zvy´senieˇ pro- duktivity pri vyvoji´ aplikaci´ ´ı. Toho je dosiahnute´ definovan´ım a implemen- tovan´ım podpornych´ API, ktore´ riesiaˇ castoˇ sa vyskytujuce´ problemy´ alebo ulohy.´ Tieto podporne´ API su´ doplnene´ definovan´ım konvenci´ı danych´ pre navrhnuty´ aplikacnˇ y´ ramec.´ Tieto konvencie predstavuju´ doporucenˇ e´ po- stupy pouzitiaˇ implementovanych´ API pri tvorbe aplikaci´ ´ı. Praca´ je zamerana´ na tvorbu noveho´ aplikacnˇ eho´ ramca´ za u´ celomˇ spo- jenia najuzitoˇ cnejˇ sˇ´ıch postupov a funkcionality aplikacnˇ ych´ ramcov.´ Po- stupy a funkcionalita prevzata´ z inych´ aplikacnˇ ych´ ramcov´ je doplnena´ o dodatocnˇ u´ funkcionalitu. Ciel’om prace´ je navrh´ aplikacnˇ eho´ ramca´ pre prostredie takzvanych´ en- terprise aplikaci´ ´ı orientovanych´ na data.´ Ako enterprise aplikacie´ sa ob- vykle oznacujˇ u´ aplikacie´ vyuzˇ´ıvane´ v priemyselnom sektore, firmami alebo vladnymi´ organizaciami´ [1]. Aplikacie´ orientovane´ na data´ su´ zamerane´ na systematicke´ zbieranie a ukladanie dat,´ ktore´ su´ nasledne´ aplikaciou´ spra- covavan´ e´ za danym´ u´ celom.ˇ Pr´ıkladom aplikacie´ orientovanej na data´ je in- formacnˇ y´ system´ alebo administracnˇ e´ rozhranie webovej aplikacie.´ Pr´ıkla- dom aplikacie,´ ktora´ nie je orientovana´ na data,´ je napr´ıklad akcnˇ a´ pocˇ´ıta- covˇ a´ hra alebo jednoduchy´ hudobny´ prehrava´ cˇ bez funkci´ı ako hudobna´ kniznica.ˇ Navrhnuty´ aplikacnˇ y´ ramec´ bude podporovat’ webove´ pouzˇ´ıvatel’ske´ rozhranie a API pre vzdialenu´ komunikaciu´ s aplikaciou.´ Zabudovana´ pod- pora pre vzdialenu´ komunikaciu´ umozˇnujeˇ intergraciu´ so systemami´ tre- t´ıch stran´ alebo ich spajanie´ do supersystemu.´ Webove´ pouzˇ´ıvatel’ske´ roz- hranie bolo zvolene´ z dovoduˆ multi-platformnosti a pretozeˇ predstavuje technologicky´ trend pre enterprise aplikacie.´ Praca´ je clenenˇ a´ nasledovne: Kapitola Poziadavkyˇ obsahuje zhrnutie a 3 pop´ısanie poziadavkovˇ na navrhnuty´ aplikacnˇ y´ ramec.´ V kapitole Kon- cepty aplikacnˇ ych´ ramcov´ su´ preskuman´ e´ su´ casnˇ e´ aplikacnˇ e´ ramce´ pod- porujuce´ webove´ pouzˇ´ıvatel’ske´ rozhranie z hl’adiska ponukan´ ych´ funkci´ı. Vysledky´ prieskumu aplikacnˇ ych´ ramcov´ spolu s definovanymi´ poziadav-ˇ kami su´ v kapitole Navrh´ architektury´ rozpracovane´ do architektury´ navr- hnuteho´ aplikacnˇ eho´ ramca.´ Kapitola Uka´zkovˇ a´ aplikacia´ popisuje navrh´ a implementaciu´ jednoduchej aplikacie´ zalozenejˇ na navrhnutom aplikac-ˇ nom ramci.´ Praca´ je uzavreta´ kapitolou Zaver´ , ktora´ zhodnocuje navrhnuty´ aplikacnˇ y´ ramec´ a popisuje moznostiˇ jeho d’alsiehoˇ rozsirovaniaˇ a vyvoja.´ 4 Kapitola 1 Poziadavkyˇ Poziadavkyˇ je moznˇ e´ rozdelit’ do nasledujucich´ zakladn´ ych´ skup´ın: • ciele – popisuju´ cohoˇ by malo byt’ dosiahnute´ navrhom´ aplikacnˇ eho´ ramca´ alebo jeho pouzˇ´ıvan´ım. • funkcnˇ e´ poziadavkyˇ – popisuju´ spravanie´ (funkcie ciˇ sluzby)ˇ sys- temu´ a podporuju´ ciele, ulohy´ alebo cinnostiˇ pouzˇ´ıvatel’ov [4]. • nefunkcnˇ e´ poziadavkyˇ – obsahuju´ obmedzenie a kvality [4]. 1.1 Ciele 1.1.1 Vyuzitieˇ pre enterprise aplik´acie Aplikacnˇ y´ ramec´ bude urcenˇ y´ pre tvorbu enterprise aplikaci´ ´ı zameranych´ na data.´ Ked’zeˇ jednou z veducich´ technologi´ ´ı v tejto oblasti je Java Enter- prise Edition, aplikacnˇ y´ ramec´ bude urcenˇ y´ pre tuto´ platformu. 1.1.2 Deklarat´ıvnyn´avrhaplik´aci´ı Deklarat´ıvny navrh´ aplikacii´ spocˇ´ıva vo vytvoren´ı popisu struktˇ ury´ ap- likacie´ a aplikaciou´ spracovavan´ ych´ dat.´ Aplikacnˇ y´ ramec´ nasledne´ vyuzijeˇ tento popis na prisposobenieˆ aplikacnejˇ logiky. Vyuzitieˇ deklarativity zaist’uje [2]: • vysˇsiuˇ produktivity vyvoj´ arov´ • mensieˇ mnozstvoˇ programoveho´ kodu´ • l’ahsiuˇ udrzovatelˇ ’nost’ aplikacie´ – vyplyva´ z mensiehoˇ mnozstvaˇ ko-´ du • mensˇ´ı vyskyt´ chyb´ v aplikacii´ – vyplyva´ z mensiehoˇ mnozstvaˇ kodu´ 5 1. POZIADAVKYˇ Aplikacie´ budu´ navrhovane´ z vel’kej castiˇ definovan´ım datov´ ych´ sad.´ Datov´ a´ sada predstavuje usporiadanu´ mnozinuˇ dat´ zdiel’ajucich´ rovnaku´ struktˇ uru.´ Datov´ e´ sady su´ technicky reprezentovane´ ako POJO [5] triedy. Aplikacnˇ y´ ramec´ bude podporovat’ vykonavanie´ zakladn´ ych´ operaci´ ´ı nad vsetkˇ ymi´ datov´ ymi´ sadami: nacˇ´ıtanie zaznamov,´ vytvaranie´ zaznamov,´ u-´ prava zaznamov´ a mazanie zaznamov´ (tieto operacie´ su´ oznacovanˇ e´ ob- vykle skratkou CRUD – create, read, update, delete). Pre kazdˇ u´ definovanu´ datov´ u´ sadu bude moznˇ e´ definovat’ dodatocnˇ e´ operacie,´ ktore´ budu´ implementovane´ imperat´ıvne. Aplikacnˇ y´ ramec´ bude umozˇnovatˇ ’ vyuzˇ´ıvat’ vsetkyˇ operacie´ na datov´ ych´ sadach´ jednotnym´ API. Vstavana´ podpora pre zakladn´ e´ operacie´ znizujeˇ mnozstvoˇ imperat´ıv- neho kodu,´ ktory´ je nutne´ implementovat’. To umoznˇ ´ı urychlenie´ vyvojo-´ veho´ procesu. Urychlenie´ vyvojov´ eho´ procesu novych´ aplikaci´ ´ı zn´ıziˇ casovˇ e´ naklady´ potrebne´ pre vyvoj´ aplikaci´ ´ı. 1.1.3 Opakovatel’n´avyuzitelˇ ’nost’ k´odu Navrh´ aplikacnˇ eho´ ramca´ by mal podporovat’ DRY paradigma [6] (z ang- lickeho´ Don’t repeat yourself – Neopakuj sa) a s tym´ suvisiacu´ znovu- vyuzitelˇ ’nost’ kodu.´ Ciel’om je obmedzit’ nutnost’ tvorby opakujujuceho´ sa kodu´ vykonavajuceho´ tie iste´ operacie´ v roznychˆ castiachˇ aplikacie.´ DRY paradigma vynucuje va¨cˇsiuˇ univerzalnost´ ’ vytvaran´ eho´ programo- veho´ kodu,´ ktory´ je potom s minimalnymi´ azˇ ziadnymiˇ upravami´ vyuzitelˇ ’- ny´ v inych´ castiachˇ aplikacie´ alebo dokonca v inych´ aplikaci´ ach,´ coˇ v konec-ˇ nom dosledkuˆ prina´saˇ vysˇsiuˇ produktivitu. 1.1.4 Abstrakcia d´atov´eho´uloziskaˇ Va¨cˇsinaˇ aplikacnˇ ych´ ramcov´ sa zameriava na vyuzitieˇ relacnejˇ databazy´ ako perzistentneho´ ulo´ ziskaˇ dat´ aplikacie.´ Vynimku´ predstavuje napr´ıklad API Java Data Objects [7] (zname´ tiezˇ pod skratkou JDO). Java Data Objects sa obvykle daju´ vyuzˇ´ıvat’ na ukladanie dat´ nielen do relacnejˇ databazy,´ ale aj do objektovej databazy´ alebo do suborov.´ Ciel’om navrhovaneho´ aplikacnˇ eho´ ramca´ je poskytnut´ ’ jednotne´ API pre pr´ıstup k l’ubovol’nemu´ zdroju dat.´ Bude moznˇ e´ vyuzˇ´ıvat’ viacere´ zdroje dat´ su´ casneˇ a pracovat’ so vsetkˇ ymi´ datami´ akoby boli ulozenˇ e´ v jednom ulo´ zisku.ˇ To umoznˇ ´ı su´ casneˇ vyuzˇ´ıvat’ technologie´ Java Persistence API [8], Java Data Objects alebo ine´ technologie´ perzistencie. 6 1. POZIADAVKYˇ 1.2 Funkˇcn´epoziadavkyˇ 1.2.1 Pouz´ıvatelˇ ’sk´e´uˇcty, skupiny, role a pr´ava Aplikacnˇ y´ ramec´ mus´ı obsahovat’ podporu pre pouzˇ´ıvatel’ske´ u´ ctyˇ jedno- znacneˇ identifikujuce´ pouzˇ´ıvatel’ov systemu.´ Pouzˇ´ıvatel’ske´ u´ ctyˇ budu´ vyu- zˇ´ıvane´ na autentizaciu´ heslom a autorizaciu´ pre vykonanie operaci´ ´ı. Pouzˇ´ıvatelia su´ zoskupovan´ı do pouzˇ´ıvatel’skych´ skup´ın, pricomˇ jeden pouzˇ´ıvatel’ moˆzeˇ byt’ clenomˇ viacerych´ skup´ın su´ casne.ˇ Prava´ pouzˇ´ıvatel’a su´ urcenˇ e´ rolami pridelenymi´ danemu´ pouzˇ´ıvatel’ovi alebo jeho skupinam.´ Rola predstavuje mnozinuˇ jednotlivych´ prav.´ Ap- likacnˇ y´ ramec´ definuje pouzˇ´ıvatel’ske´ pravo´ pre kazdˇ u´ operaciu´ a kazdˇ u´ datov´ u´ sadu. Toto je moznˇ e´ vd’aka tomu, zeˇ existuje deklarat´ıvna defin´ıcia operaci´ ´ı nad datov´ ymi´ sadami. Kazdˇ e´ pouzˇ´ıvatel’ske´ pravo´ moˆzeˇ mat’ plat- nost’ vramci´ zaznamov´ daneho´ pouzˇ´ıvatel’a (napr´ıklad pravo´ zmazat’ vlast- ny´ pouzˇ´ıvatel’sky´ u´ cet),ˇ vramci´ skup´ın pouzˇ´ıvatel’a (napr´ıklad pravo´ zma- zat’ u´ cetˇ pouzˇ´ıvatel’ovi, ktory´ je clenomˇ l’ubovol’nej skupiny daneho´ pouzˇ´ı- vatel’a) alebo s plnym´ rozsahom (napr´ıklad pravo´ zmazat’ l’ubovol’ny´ pouzˇ´ı- vatel’sky´ u´ cet).ˇ Takto navrhnuty´ model prav´ by mal predstavovat’ dostatocneˇ flexibilny´ a robustny´ zaklad´ pre vyuzitieˇ v enterprise aplikaci´ ach,´ pri ktorych´ moˆzeˇ byt’ jedna instanciaˇ aplikacie´ vyuzˇ´ıvana´ su´ casneˇ roznymiˆ pouzˇ´ıvatel’mi. 1.2.2 Multi-pouz´ıvatelˇ ’sk´eaplik´acie Aplikacie´ postavene´ na navrhnutom aplikacnomˇ ramci´ by mali byt’ multi- pouzˇ´ıvatel’ske;´ to znamena,´ zeˇ moˆzuˇ byt’ vyuzˇ´ıvane´ viacerymi´ pouzˇ´ıvatel’- mi zarove´ n,ˇ pricomˇ aktivity pouzˇ´ıvatel’ov sa nesmu´ navzajom´ rusitˇ ’ do ma- ximalnej´ moznejˇ miery – s odhliadnut´ım od pr´ıpadov ako je editacia´ zaz-´ namu, ktory´ iny´ pouzˇ´ıvatel’ v priebehu editacie´ vymaze.ˇ Moznostˇ ’ vyuzˇ´ıvania zdiel’anej instancieˇ aplikacie´ viacerymi´ pouzˇ´ıva- tel’mi vedie k nizˇsˇ´ım narokom´ na systemov´ e´ prostriedky. Takyto´ centrali- zovany´ pr´ıstup tiezˇ umozˇnujeˇ uchovanie si globalneho´ prehl’adu o stave aplikacie´ a vsetkˇ ych´ pouzˇ´ıvatel’ov, ktor´ı s danou aplikaciou´ v danej dobe pracuju.´ 1.2.3 Podpora viac-n´asobn´ehobehu aplik´acie Aplikacnˇ y´ ramec´ nesmie zabranovatˇ ’ viac-nasobn´ emu´ spusteniu aplikacie,´ pricomˇ kazdˇ a´ vytvorena´ instanciaˇ moˆzeˇ vyuzˇ´ıvat’ inu´ konfiguraciu,´ ulo´ zis-ˇ ka´ dat,´ alebo dokonca funkcnˇ e´ celky (napr´ıklad pouzˇ´ıvatel’ske´ rozhranie 7 1. POZIADAVKYˇ cez vzdialeny´ terminal´ namiesto weboveho´ rozhrania). V pr´ıpade potreby bude moznˇ e´ obmedzit’ mnozstvoˇ spustenych´ instan-ˇ ci´ı aplikacie´ na jednu. 1.2.4 Centr´alnakonfigur´aciaaplik´acie Konfiguracia´ aplikacie´ bude nacˇ´ıtana´ z jednoho suboru.´ Tento subor´ moˆzeˇ vyzadovatˇ ’ nacˇ´ıtanie d’alsˇ´ıch konfiguracnˇ ych´ suborov´ pomocou speciˇ alnej´ direkt´ıvy. Centralizovana´ konfiguracia´ zabranujeˇ vyskytu´ vel’keho´ mnozstvaˇ kon- figuracnˇ ych´ suborov´ aplikacie.´ V pr´ıpade decentralizovanej konfiguracie´ sa navyseˇ moˆzeˇ vyskytnut´ ’ pouzˇ´ıvanie viacerych´ formatov´ konfiguracnˇ ych´ suborov´ su´ casne,ˇ coˇ zvysujeˇ naro´ cnostˇ ’ nastavenia aplikacie.´ Potreba po- znat’ len jeden format´ konfiguracnˇ ych´ suborov´ v kombinacii´ s centralizova- nou konfiguraciou´ ul’ahcujeˇ nastavenie aplikacie.´ 1.2.5 Automatick´avalid´aciakonfigur´acie Ked’zeˇ konfiguracia´ predstavuje pre aplikaciu´ formu vstupu, je nutne´ tento vstup validovat’ aby nebol beh aplikacie´ negat´ıvne narusenˇ y´ nevhodnymi´ hodnotami v konfiguracii.´ Validacia´ konfiguracnˇ ych´ poloziekˇ vyzadujeˇ nie- len overenie typu hodnoty poloziek,ˇ ale tiezˇ vhodny´ sposobˆ oznamenia´ pr´ıcinyˇ odmietnutia validovanej polozky.ˇ Validacia´ konfiguracie´ bude au- tomaticka´ a centralizovana.´ Je pravdepodobne,´ zeˇ pocetˇ konfiguracnˇ ych´ poloziekˇ aplikacie´ bude umern´ y´ mnozstvuˇ poskytovanych´ funkci´ı a sluzieb.ˇ V pr´ıpade lokalnej´ ale- bo decentralizovanej validacie´ konfiguracnˇ ych´ hodnotˆ by narast´ poctuˇ kon- figuracnˇ ych´ poloziekˇ mohol viest’ k narastu´ mnozstvaˇ aplikacnˇ eho´ kodu´ potrebneho´ pre ich validaciu,´ coˇ je v rozpore s ciel’ami prace.´ 1.2.6 Logovanie Aplikacnˇ y´ ramec´ mus´ı umozˇnovatˇ ’ zaznam´ sprav´ informujucich´ o behu ap- likacie´ (logovanie). Spravy´ zaznamenane´ logovac´ım procesom su´ nasledne´ vyuzitˇ e´ k spatn¨ emu´ skumaniu´ behu aplikacie,´ napr´ıklad za u´ celomˇ detek- cie chybneho´ spravania´ sa aplikacie.´ Logovanie mus´ı byt’ centralizovane,´ aby bolo moznˇ e´ z logov z´ıskat’ glo- balny´ pohl’ad na spravanie´ aplikacie.´ Lokalny´ pohl’ad na spravanie´ apli- kacie´ je moznˇ e´ z´ıskat’ filtrovan´ım logov. Globalny´ pohl’ad predstavuje cel- kovy´ prehl’ad o operaci´ ach´ vykonanych´ vsetkˇ ymi´ su´ castˇ ’ami aplikacie´ v da- 8 1. POZIADAVKYˇ ny´ casovˇ y´ interval, vratane´ interakci´ı medzi danymi´ su´ castˇ ’ami. Lokalny´ pohl’ad poskytuje len informacie´ o operaci´ ach´ vykonanych´ danou su´ castˇ ’ou. Aplikacnˇ y´ ramec´ definuje API pre zaznam´ logovac´ıch sprav.´ Toto API je vyuzˇ´ıvane´ aplikaciou´ aj su´ castˇ ’ami aplikacnˇ eho´ ramca.´ 1.2.7 Alarmy Su´ castˇ ’ou aplikacnˇ eho´ ramca´ bude moznostˇ ’ zasielat’ upozornenia (alarmy). Alarmy predstavuju´ upozornenia na rozneˆ situacie´ vyskytujuce´ sa za behu aplikacie,´ ktore´ nie su´ primarne´ urcenˇ e´ pouzˇ´ıvatel’ovi. Alarmy moˆzuˇ vyzadovatˇ ’ pozornost’ administratorov´ aplikacie.´ 1.2.8 Behov´eˇstatistiky Behove´ statistikyˇ umozˇnujˇ u´ zber udajov´ o spravan´ ´ı aplikacie´ a jej pouzˇ´ıvan´ı pouzˇ´ıvatel’mi. Tieto udaje´ sa daju´ nasledne´ vyuzitˇ ’ na sledovanie vyuzˇ´ıva- nosti jednotlivych´ castˇ ´ı aplikacie,´ alebo stanovenie limitov pre vyuzˇ´ıvanie aplikacie´ danymi´ pouzˇ´ıvatel’mi. Limity umozˇnujˇ u´ zabranit´ ’ nadmernemu´ pouzˇ´ıvaniu danych´ su´ castˇ ´ı ap- likacie´ pouzˇ´ıvatel’mi a pomahaj´ u´ tak ciastoˇ cneˇ zabranit´ ’ zlomysel’nemu´ ale- bo chybnemu´ pouzitiuˇ prostriedkov uzkou´ skupinou pouzˇ´ıvatel’ov na ukor´ va¨cˇsiny.ˇ 1.3 Nefunkˇcn´epoziadavkyˇ Nefunkcnˇ e´ poziadavkyˇ predstavuju´ poziadavkyˇ na urcitˇ e´ kvality aplikac-ˇ neho´ ramca,´ alebo obmedzenia jeho navrhu´ [3], [4]. Vramci´ tejto prace´ bol stanoveny´ len jeden poziadavokˇ na kvality ap- likacnˇ eho´ ramca:´ vykon´ aplikacie´ postavenej na aplikacnomˇ ramci´ by ne- mal byt’ vyrazne´ nizˇsˇ´ı nezˇ keby aplikacia´ tento ramec´ nepouzˇ´ıvala. Pre navrh´ aplikacnˇ eho´ ramca´ bolo stanovene´ nasledovne´ obmedzenie: funkcnˇ a´ specifikˇ acia´ a navrh´ architektury´ aplikacnˇ eho´ ramca´ bude vytvo- reny´ v anglickom jazyku z dovoduˆ pouzitelˇ ’nosti v globalnom´ mer´ıtku. 9 Kapitola 2 Koncepty aplikaˇcnych´ r´amcov Tato´ kapitola rozobera´ doleˆ zitˇ e´ ciˇ zauj´ımave´ koncepty najden´ e´ v preskuma-´ nych´ aplikacnˇ ych´ ramcoch´ alebo definovane´ v Poziadavkochˇ . Tento pries- kum je v plnom rozsahu dostupny´ v pr´ılohe Prieskum aplikacnˇ ych´ ramcov´ . Koncepty boli vybrane´ z nasledujucich´ aplikacnˇ ych´ ramcov,´ roztriede- nych´ podl’a platformy: • Java: Java Enterprise Edition, Tapestry, AppFuse, Aranea Framework, JBoss Seam, JVx, ManyDesigns Portofino, OpenXava, Play Framework • PHP: Agile Toolkit, AppFlower, CakePHP, Jelix, Lithium, Openbiz Cubi, PRADO Framework, Yii • Groovy: Grails • Perl: Catalyst • Python: Django, web2py • Ruby: Ruby on Rails 2.1 Model-View-Controller architekt ´ura Model-View-Controller (Model-Zobrazenie-Ovlada´ c)ˇ je oznacenieˇ navrho-´ veho´ paradigmatu, ktore´ oddel’uje od seba castiˇ aplikacie´ suvisiace´ s pre- pojen´ım s datami´ (model), zobrazovan´ım dat´ a pouzˇ´ıvatel’skeho´ rozhra- nia (view) a aplikacnouˇ logikou aplikacie´ (controller), ktora´ prepaja´ vsetkyˇ casti.ˇ Vazby¨ medzi castˇ ’ami tvoriacimi aplikaciu´ by mali byt’ coˇ najvol’nejsie,ˇ aby vymena´ jednej castiˇ mala coˇ najmensˇ´ı dopad na zvysnˇ e´ dve. Toto para- digma tym´ podporuje prenositel’nost’ kodu.´ Tento koncept je su´ castˇ ’ou 19 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Koncept bude zahrnuty´ do navrhu´ z dovoduˆ lepsejˇ prenositel’nosti vysled-´ neho´ kodu.´ 11 2. KONCEPTYAPLIKACNˇ YCHR´ AMCOV´ 2.2 Deklarat´ıvnatvorba aplik´aci´ı Deklarat´ıvna tvorba aplikaci´ ´ı spocˇ´ıva v popise struktˇ ury´ aplikacie´ a spra- covavan´ ych´ dat.´ Tento popis moˆzeˇ mat’ formu XML suborov,´ POJO tried, alebo konfiguracie,´ pr´ıpadne moˆzeˇ byt’ odvodeny´ zo struktˇ ury´ databazy,´ ktoru´ aplikacia´ pouzˇ´ıva na ukladanie dat.´ Zo spomenutych´ moznostˇ ´ı je preskuman´ ymi´ aplikacnˇ ymi´ ramcami´ naj- castejˇ sieˇ vyuzˇ´ıvana´ moznostˇ ’ XML suborov´ a POJO tried. Niektore´ aplikac-ˇ ne´ ramce´ su´ schopne´ vyuzitˇ ’ tento popis struktˇ ury´ dat´ na generovanie vhod- nych´ struktˇ ur´ v databazi´ aplikacie.´ Niektore´ aplikacnˇ e´ ramce´ su´ schopne´ vyuzitˇ ’ tieto popisy struktˇ ury´ dat´ na vytvorenie generickeho´ pouzˇ´ıvatel’skeho´ rozhrania. Kombinaciou´ vset-ˇ kych´ tychto´ vlastnost´ı je moznˇ e´ vytvorit’ vo vel’mi kratkom´ caseˇ funkcnˇ y´ prototyp aplikacie,´ v niektorych´ pr´ıpadoch moˆzuˇ moznostiˇ daneho´ aplikac-ˇ neho´ ramca´ postacovatˇ ’ aj na kompletnu´ realizaciu´ vyslednej´ aplikacie.´ Tento koncept je v roznomˆ rozsahu su´ castˇ ’ou 20 z 22 preskuman´ ych´ ap- likacnˇ ych´ ramcov.´ 2.3 Agnosticky´ pr´ıstupk pouz´ıvatelˇ ’sk´emurozhraniu Aplikacnˇ y´ ramec´ je agnosticky´ vociˇ pouzˇ´ıvatel’skemu´ rozhraniu, pokial’: • neobsahuje ziadnuˇ podporu pre pouzˇ´ıvatel’ske´ rozhranie; alebo • obsahuje API pre beznˇ e´ su´ castiˇ roznychˆ pouzˇ´ıvatel’skych´ rozhran´ı, pricomˇ tieto API nie su´ zviazane´ s konkretnou´ formou pouzˇ´ıvatel’s- keho´ rozhrania. Agnosticky´ pr´ıstup k pouzˇ´ıvatel’skemu´ rozhraniu pouzˇ´ıvaju´ len 2 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Tieto ramce´ tiezˇ poskytuju´ asponˇ jed- nu konkretnu´ formu pouzˇ´ıvatel’skeho´ rozhrania, ktora´ vyuzˇ´ıvala danu´ ab- straktnu´ podporu. Ostatne´ aplikacnˇ e´ ramce´ su´ pevne zviazane´ s nejakou konkretnou´ formou pouzˇ´ıvatel’skeho´ rozhrania. Tento koncept oslabuje vazby¨ medzi castˇ ’ami Controller a View z pohl’a- du paradigmatu Model-View-Controller a zarove´ nˇ ul’ahcujeˇ nahradenie po- uzˇ´ıvatel’skeho´ rozhrania za pouzˇ´ıvatel’ske´ rozhranie inej formy. S´ıce jednym´ z poziadavkovˇ na navrh´ aplikacnˇ eho´ rozhrania bolo we- bove´ rozhranie, vyuzitieˇ agnostickeho´ pr´ıstupu sa jav´ı ako vhodnejsieˇ rie- senie,ˇ ked’zeˇ zaist’uje l’ahku´ buducu´ rozsˇ´ıritel’nost’. API pre vzdialenu´ ko- munikaciu´ s aplikaciou´ sa navyseˇ da´ chapat´ ’ ako forma pouzˇ´ıvatel’skeho´ rozhrania, takzeˇ vyuzitieˇ tohto konceptu riesiˇ aj tento poziadavok.ˇ 12 2. KONCEPTYAPLIKACNˇ YCHR´ AMCOV´ 2.4 Datab´azov´aabstrakcia Databazov´ a´ abstrakcia zaist’uje prenositel’nost’ aplikacie,´ pr´ıpadne aj dat,´ medzi roznymiˆ poskytovatel’mi sluziebˇ datov´ ych´ ulo´ zˇ´ısk. Datov´ ym´ ulo´ zis-ˇ kom sa obvykle mysl´ı SQL relacnˇ a´ databaza.´ Preskuman´ e´ ramce´ azˇ na vy-´ nimky poskytuju´ takuto´ formu databazovej´ abstrakcie. U aplikacnˇ ych´ ram-´ cov pre platformu Java je moznˇ e´ vyuzitˇ ’ aj Java Data Objects, ktore´ umoz-ˇ nujˇ u´ abstrahovat’ aj od datov´ eho´ ulo´ ziska,ˇ ale su´ obmedzene´ len na pracu´ s jednym´ datov´ ym´ ulo´ ziskom.ˇ Databazov´ a´ abstrakcia je su´ castˇ ’ou 20 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Databazov´ a´ abstrakcia bude zahrnuta´ v navrhu´ za u´ celomˇ zaistenia ne- zavislosti´ na konkretnej´ technologii´ ukladania dat´ a podpory lepsejˇ preno- sitel’nosti aplikacie.´ Ako bolo stanovene´ v ciel’och, aplikacnˇ y´ ramec´ bude poskytovat’ databazov´ u´ abstrakciu, ktora´ bude abstrahovat’ od datov´ eho´ ulo´ ziskaˇ a bude umozˇnovatˇ ’ vyuzitieˇ viacerych´ datov´ ych´ zdrojov su´ casne.ˇ 2.5 Automatick´avalid´aciad´at Automaticka´ validacia´ dat´ je obvykle zamerana´ na validaciu´ dat´ vo for- mularoch´ alebo datov´ ych´ modeloch. Pre kazdˇ e´ pole je moznˇ e´ stanovit’ l’ubo- vol’ny´ pocetˇ validatorov,´ pricomˇ niektore´ aplikacnˇ e´ ramce´ umozˇnujˇ u´ defi- novat’ vlastne´ validatory.´ Aplikacnˇ e´ ramce´ pre silne typovane´ jazyky obvykle umozˇnujˇ u´ automa- ticky validovat’ typ poskytnutej hodnoty bez nutnosti validatoru´ daneho´ typu. Niektore´ aplikacnˇ e´ ramce´ pre slabo typovane´ jazyky toto kompen- zuju´ vyuzitˇ ´ım informaci´ ´ı zo struktˇ ury´ databazy´ pouzˇ´ıvanej aplikaciou.´ Validacnˇ y´ proces moˆzeˇ byt’ potom vykonany´ automaticky pri nastaven´ı hodnotˆ pol´ı formularu´ alebo datov´ eho´ modelu, alebo moˆzeˇ prebiehat’ uzˇ pri vyplnovanˇ ´ı hodnotˆ formularu´ v pouzˇ´ıvatel’skom rozhran´ı. Pokial’ su´ formulare´ alebo datov´ e´ modely definovane´ deklarat´ıvne, je obvykle moznˇ e´ do ich popisu zahrnut´ aj defin´ıciu validacnˇ ych´ obmedzen´ı. Aplikacnˇ e´ ramce´ popri samotnom validacnomˇ procese definuju´ aj spo-ˆ sob oznamenia´ zlyhanej validacie,´ pricomˇ zavadzaj´ u´ konvencie pre loka- lizaciu´ chybovych´ hla´sokˇ validacie.´ Tento koncept je su´ castˇ ’ou 14 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Ked’zeˇ navrhovany´ aplikacnˇ y´ ramec´ bude agnosticky´ vociˇ pouzˇ´ıvatel’s- kemu´ rozhraniu, jeho su´ castˇ ’ou bude len validacia´ datov´ ych´ modelov. 13 2. KONCEPTYAPLIKACNˇ YCHR´ AMCOV´ 2.6 Model udalost´ı Udalosti reprezentuju´ synchronne´ alebo asynchronne´ dorucovanˇ e´ spravy.´ Kazdˇ a´ takato´ sprava´ vznikne v jednej su´ castiˇ aplikacie´ a moˆzeˇ byt’ dorucenˇ a´ jednej, viacerym´ alebo vsetkˇ ym´ su´ castiamˇ aplikacie.´ Udalosti tak predstavuju´ sposobˆ ako upozornit’ rozneˆ su´ castiˇ aplikacie´ na dany´ (vonkajsˇ´ı) podnet alebo odvzdavat´ ’ informacie´ medzi su´ castˇ ’ami aplikacie´ jednym´ ciˇ viacerymi´ smermi. Vzhl’adom na povahu udalost´ı, su´ castiˇ aplikacie´ obvykle negeneruju´ navratov´ e´ hodnoty pre jednotlive´ udalosti, hoci niektore´ modely umozˇnujˇ u´ poskytnutie odpovedi su´ casti,ˇ ktora´ udalost’ vytvorila. Model udalost´ı je su´ castˇ ’ou 3 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Model udalost´ı bude zahrnuty´ do navrhu´ aplikacnˇ eho´ ramca,´ pretozeˇ sa jav´ı ako uzitoˇ cnˇ y´ nastroj´ pre komunikaciu´ medzi su´ castˇ ’ami aplikacie´ a je pouzitelˇ ’ny´ pre asynchronne´ pouzˇ´ıvatel’ske´ rozhrania. 2.7 Automatick´eposkytovanie z´avislost´ı V rozsiahlych aplikaci´ ach´ castoˇ mnohe´ su´ castiˇ zavisia´ na inych´ su´ castiach.ˇ Pokial’ si jednotlive´ su´ castiˇ z´ıskavaju´ zavislosti´ same,´ moˆzuˇ vznikat’ viac- nasobn´ e´ instancieˇ pozadovanˇ ych´ su´ castˇ ´ı, coˇ moˆzeˇ mat’ fatalne´ dopady na beh aplikacie.´ Centralizove´ automaticke´ poskytovanie zavislost´ ´ı predstavuje process, ktory´ vyhodnocuje zavislosti´ jednotlivych´ su´ castˇ ´ı aplikacie´ a tieto zavislosti´ poskytuje su´ castiamˇ aplikacie´ v spravnom´ porad´ı. Tento proces zarove´ nˇ vy- konava´ automaticku´ kontrolu dostupnosti vsetkˇ ych´ zavislost´ ´ı. Proces tiezˇ zaist’uje existenciu len jednej instancieˇ kazdejˇ su´ castiˇ aplikacie,´ u ktorej je to potrebne.´ Tento koncept je su´ castˇ ’ou 10 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Automaticke´ poskytovanie zavislost´ ´ı bude zahrnute´ v navrhu´ aplikac-ˇ neho´ ramca´ hlavne z dovoduˆ zjednoduseniaˇ prace´ so zavislost´ ’ami. 2.8 Autentiz´aciaa autoriz´acia Autentizacia´ je proces overenia identity pouzˇ´ıvatel’a aplikacie,´ napr´ıklad pomocou pouzˇ´ıvatel’skeho´ mena a hesla. Autorizacia´ je proces urceniaˇ prav´ daneho´ pouzˇ´ıvatel’a. Niektore´ preskuman´ e´ aplikacnˇ e´ ramce´ maju´ vstavane´ mechanizmy pre autorizaciu´ a autentizaciu.´ Tieto ramce´ obvykle vyuzˇ´ıvaju´ pouzˇ´ıvatel’ske´ u´ ctyˇ chranen´ e´ heslami, skupiny a prava.´ Ine´ aplikacnˇ e´ ramce´ definuju´ API 14 2. KONCEPTYAPLIKACNˇ YCHR´ AMCOV´ pre autorizaciu´ a autentizaciu,´ ktore´ je implementovane´ roznymiˆ dopln- kami a je tak moznˇ e´ vyuzˇ´ıvat’ rozneˆ sposobyˆ autentizacie´ a autorizacie.´ Tento koncept je su´ castˇ ’ou 10 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Poziadavkyˇ na aplikacnˇ y´ ramec´ s´ıce vyzadujˇ u´ istu´ formu pouzˇ´ıvatel’s- kych´ prav´ (pouzˇ´ıvatel’ske´ u´ cty,ˇ skupiny, role, prava),´ ale nebude obsaho- vat’ pevne danu´ implementaciu´ autentizacie´ a autorizacie.´ Aplikacnˇ y´ ramec´ bude definovat’ API pre autentizaciu´ a autorizaciu,´ ktore´ bude implemen- tovane´ jednym´ z modulov aplikacie.´ 2.9 Logovanie Logovanie slu´ ziˇ na zaznam´ sprav´ o behu aplikacie.´ Tieto spravy´ su´ nasled-´ ne vyuzitelˇ ’ne´ k spatn¨ emu´ skumaniu´ behu aplikacie.´ Preskuman´ e´ aplikacnˇ e´ ramce´ obvykle poskytuju´ moznostˇ ’ logovat’ do textovych´ suborov,´ pricomˇ niektore´ umozˇnujˇ u´ aj ine´ formy logovania, na- pr´ıklad protokolom Syslog [9]. Logovacie API poskytovane´ jednotlivymi´ ramcami´ ma´ rozneˆ podoby. Niektore´ ramce´ riesiaˇ zjednotenie zachytavania´ chyb´ a vynimiek´ (aplikacnˇ e´ ramce´ pre platformu PHP). Preskuman´ e´ aplikacnˇ e´ ramce´ pouzˇ´ıvaju´ rozneˆ struktˇ ury´ logovac´ıch sprav,´ niektore´ ramce´ napr´ıklad pouzˇ´ıvaju´ len zava´ z-ˇ nost’ spravy,´ textovu´ stravu´ a volitel’nu´ vynimku´ alebo chybu. Tento koncept je su´ castˇ ’ou 13 z 22 preskuman´ ych´ aplikacnˇ ych´ ramcov.´ Niektore´ aplikacnˇ e´ ramce´ vyuzˇ´ıvaju´ logovacie API poskytnute´ platformou, pre ktoru´ je dany´ ramec´ urcenˇ y.´ Centralne´ logovanie bude zahrnute´ v navrhu´ pretozeˇ sa jedna´ o jeden z funkcnˇ ych´ poziadavkov.ˇ 15 Kapitola 3 N´avrharchitekt ´ury Navrhnuty´ aplikacnˇ y´ ramec´ vyuzˇ´ıva modularnu´ architekturu´ postavenu´ na MVCP (Model-View-Controller-Presenter) paradigmatu. MVCP je kom- binaciou´ paradigmat´ MVC (Model-View-Controller) a MVP (Model-View- Presenter) [10]. Toto paradigma zachovava´ ulohu´ modelu a zobrazenia, pricomˇ uzˇsieˇ specializujeˇ ulohy´ prezentera´ a ovlada´ caˇ . Ovlada´ cˇ predstavuje imperat´ıvnu logiku, ktora´ je specifickˇ a´ pre danu´ aplikaciu.´ Ovlada´ cˇ je obvykle reprezentovany´ jednym´ alebo viacerymi´ mo- dulmi aplikacie.´ Niektore´ aplikacie´ nemusia mat’ ovlada´ c,ˇ pokial’ je pre- zenter´ schopny´ poskytnut´ ’ pozadovanˇ u´ funkcionalitu. Prezenter´ predstavuje medzivrstvu medzi modelom a zobrazen´ım. Pri- marnym´ u´ celomˇ prezenteru´ je poskytovanie dat´ a informaci´ ´ı o ich struktˇ ure´ zobrazeniu a prij´ımat’ vstup zo zobrazenia a vhodnym´ sposobomˆ ho pre- poslat’ modelu. Prezenter´ vyuzˇ´ıva ovlada´ cˇ na vykonanie operaci´ ´ı, ktore´ sam´ nepodporuje. Logicke´ usporiadanie tychto´ su´ castˇ ´ı znazor´ nujeˇ nasledovn´ y´ diagram: 3.1 Struktˇ ´uraaplik´acie Aplikacia´ postavena´ na navrhnutom aplikacnomˇ ramci´ bude pozostavat´ ’ z nasleduj´ ucich´ su´ castˇ ´ı: 17 3. NAVRHARCHITEKT´ URY´ • Jadro – Jadro aplikacnˇ eho´ ramca´ predstavuje vstupny´ bod aplikacie´ a poskytuje API pre spustenie aj ukoncenieˇ aplikacie.´ Jadro posky- tuje zakladn´ e´ sluzby,ˇ ako napr´ıklad nacˇ´ıtanie konfiguracie´ alebo vy- tvorenie spojenia s databazou.´ Su´ castˇ ’ou Jadra su´ podporne´ triedy a rozhrania vyuzˇ´ıvane´ aplikacnˇ ym´ ramcom´ alebo aplikaciou.´ • zakladn´ e´ moduly – moduly nutne´ pre zostavenie fungujucej´ aplika-´ cie. Tieto moduly zaist’uju´ zakladn´ e´ sluzby,ˇ napr´ıklad pr´ıstup k da-´ tam alebo komunikaciu´ medzi modulmi. • moduly sluziebˇ – moduly poskytnute´ aplikacnˇ ym´ ramcom,´ ktore´ poskytuju´ dane´ sluzbyˇ ostatnym´ modulom. Aplikacia´ nemus´ı ob- sahovat’ vsetky,ˇ pr´ıpadne ziadenˇ z tychto´ modulov. • aplikacnˇ e´ moduly – moduly, ktore´ su´ specifickˇ e´ pre danu´ aplikaciu,´ napr´ıklad moduly pre poskytnutie pouzˇ´ıvatel’skeho´ rozhrania. • zavadza´ cˇ aplikacie´ – kod,´ ktory´ je pouzitˇ y´ pre spustenie aplikacie´ a inicializaciu´ Jadra. Pozn.: Tato´ kapitola poskytuje len zakladn´ y´ prehl’ad architektury´ ap- likacnˇ eho´ ramca.´ Upln´ a´ dokumentacia´ architektury´ je dostupna´ v pr´ılohach´ Funkcnˇ a´ specifikˇ acia´ a Architektura´ aplikacnˇ eho´ ramca´ . 3.2 Jadro Pojem ”Jadro”je pouzitˇ y´ viac-zmyselne: moˆzeˇ znamenat’ triedu jazyka Java, ktora´ predstavuje Jadro, alebo jar bal´ıcekˇ obsahujuci´ triedu Jadra a pod- porne´ triedy a rozhrania. Bal´ıcekˇ Jadra obsahuje: • hlavnu´ triedu Jadra • triedy a anotacie´ pre podporu datov´ ych´ sad´ (viz 3.5) • triedy vynimiek´ pouzˇ´ıvanych´ aplikacnˇ ym´ ramcom´ • podporne´ nastroje´ (viz 3.2.1) • zakladn´ e´ nastroje´ pre logovanie • rozhrania objektov poskytovanych´ ramcom´ (viz 3.4) • spolocnˇ a´ trieda pre moduly a anotacie´ pre moduly (viz 3.3) 18 3. NAVRHARCHITEKT´ URY´ • rozhrania sluziebˇ ramca´ (viz 3.4) Bal´ıcekˇ jadra by mal poskytovat’ zaklad´ potrebny´ pre vyvoj´ modulu pre aplikacnˇ y´ ramec.´ 3.2.1 Podporn´en´astroje • Class Path Searcher – nastroj´ na skumanie´ Java bal´ıckovˇ tried za behu. Nastroj´ je schopny´ preskumat´ ’ vsetkyˇ adresare´ a jar/zip subo-´ ry specifikovanˇ e´ v aktualnej´ classpath. Nastroj´ je vyuzˇ´ıvany´ na z´ıskavanie informaci´ ´ı o dostupnych´ imple- mentaci´ ach´ rozhran´ı a definovanych´ datov´ ych´ sadach´ za behu. • Configuration Loader – nastroj´ na nacˇ´ıtanie konfiguracie´ aplikacie´ (viz 3.6). • Configuration Validator – nastroj´ na validaciu´ nacˇ´ıtanej konfiguracie´ (viz 3.6). • Named Parameter – pomocna´ trieda pre reprezentaciu´ pomenova- neho´ paru´ kl’u´ c-hodnotaˇ so sofistikovanym´ prevodom hodnoty na ret’azec v pr´ıpade potreby. • Persistence Configurator – nastroj´ na generovanie konfiguracnˇ eho´ suboru´ pre Java Persistence API. Nastroj´ je pouzˇ´ıvany´ na doplnenie zoznamu perzistentnych´ tried do konfiguracie´ JPA za behu. 3.3 Moduly Moduly je moznˇ e´ zjednoduseneˇ chapat´ ’ ako rozsˇ´ırenia Jadra. Moduly de- finuju´ dodatocnˇ e´ datov´ e´ sady a funkcionalitu, ktora´ moˆzeˇ byt’ dostupna´ inym´ modulom. Kazdˇ y´ modul je zabaleny´ ako jar bal´ıcekˇ umiestneny´ v ad- resari´ pre moduly aplikacie´ (viz pr´ılohy). Modul pozostava´ z: • hlavna´ trieda modulu – trieda pomenovana´ rovnako ako modul. • lokalizacnˇ e´ subory´ – viz 3.7. • l’ubovol’ny´ pocetˇ defin´ıci´ı datov´ ych´ sad´ – viz 3.5. • triedy a rozhrania specifickˇ e´ pre dany´ modul (volitel’ne)´ 19 3. NAVRHARCHITEKT´ URY´ • validacnˇ y´ subor´ konfiguracie´ modulu (volitel’ne)´ – viz 3.6. Jar bal´ıcekˇ modulu mus´ı niest’ rovnake´ meno ako modul. Triedy modulu by mali byt’ v bal´ıckuˇ pomenovanom ako modul, umiestnenom v bal´ıckuˇ cz.muni.fi.xjurca.runtime.modules, napr´ıklad cz.muni.fi.xjurca.runtime. modules.examplemodule. Vsetkyˇ hlavne´ triedy modulov dedia z triedy cz.muni.fi.xjurca.runtime. modules.Module, ktora´ poskytuje zakladn´ u´ funkcionalitu. Tato´ trieda defi- nuje API pre pracu´ s lokalizaciou´ modulu, komunikaciu´ s inymi´ modulmi a logovanie. 3.3.1 Stav modulu, inˇstal´aciaa odinˇstalovanie Aplikacnˇ y´ ramec´ si udrzujeˇ o kazdomˇ dostupnom module stavovu´ infor- maciu.´ Stavova´ informacia´ – skratene´ stav – urcujeˇ pouzitelˇ ’nost’ modulu v aplikacii.´ Stav moˆzeˇ byt’ jeden z nasledovnych:´ • UNINSTALLED – modul nie je nainstalovanˇ y´ a nie je moznˇ e´ ho pou- zˇ´ıvat’. • READY – modul je s´ıce nainstalovanˇ y,´ ale nema´ splnene´ zavislosti,´ takzeˇ ho nie je moznˇ e´ pouzˇ´ıvat’. • DISABLED – administrator´ aplikacie´ vypol dany´ modul. Modul nie je moznˇ e´ pouzˇ´ıvat’ aj ak su´ splnene´ jeho zavislosti.´ • ENABLED – modul je nainstalovanˇ y,´ ma´ splnene´ zavislosti´ a ne- bol vypnuty.´ Len taketo´ moduly je moznˇ e´ pouzˇ´ıvat’ pocasˇ behu ap- likacie.´ Modul moˆzeˇ volitel’ne definovat’ metodu´ install, ktora´ je vykonana´ In- stalˇ atorom´ pocasˇ instalˇ acie´ modulu v aplikacii.´ Tato´ metoda´ sa da´ pouzitˇ ’ na nastavenie modulu pred pouzitˇ ´ım v aplikacii.´ Obdobou pre odinstalovanieˇ modulu je metoda´ uninstall.Tato´ metoda´ je naopak pouzitelˇ ’na´ na odstranenie´ vedl’ajsˇ´ıch efektov pouzˇ´ıvania mo- dulu, napr´ıklad databazov´ ych´ struktˇ ur´ pre datov´ e´ sady modulu. Instalaˇ cnˇ y´ a odinstalaˇ cnˇ y´ proces je detailnejsieˇ pop´ısany´ v sekcii Instalˇ a-´ tor (viz 3.17). 3.4 Sluzbyˇ Sluzbyˇ predstavuju´ rozhrania implementovane´ a vyuzˇ´ıvane´ modulmi. Kaz-ˇ da´ sluzbaˇ zoskupuje metody´ aplikacnˇ eho´ ramca´ suvisiace´ s jednym´ danym´ 20 3. NAVRHARCHITEKT´ URY´ u´ celom,ˇ napr´ıklad lokalizaciou.´ Sluzbyˇ su´ pouzitˇ e´ na obmedzenie zavislost´ ´ı medzi modulmi, ktore´ tak moˆzuˇ vyuzˇ´ıvat’ API sluziebˇ namiesto API modu- lov. Sluzbyˇ su´ definovane´ ako rozhrania v bal´ıckuˇ cz.muni.fi.xjurca.runtime. services.Nazov´ sluzbyˇ by mal koncitˇ ’ slovom Service, napr´ıklad Logging- Service. Rozhranie sluzbyˇ by nemalo rozsirovatˇ ’ ine´ rozhranie. Moduly definuju´ zavislosti´ na sluzbˇ ach´ definovan´ım metody´ pre nasta- venie poskytovatel’a sluzby.ˇ Metoda´ mus´ı mat’ nazov´ setServiceProvider. Tato´ metoda´ ma´ jediny´ parameter, ktoreho´ typ je rozhranie pozadovanejˇ sluzby.ˇ Modul moˆzeˇ definovat’ viac tychto´ metod´ a vyjadrit’ tak vsetkyˇ svoje zavislosti´ na sluzbˇ ach.´ Vsetkyˇ moduly obdrziaˇ svoje pozadovanˇ e´ sluzbyˇ pri spusten´ı aplikacie.´ Tento proces zaist’uje modul Module Manager (viz 3.9). Aplikacnˇ y´ ramec´ zavadza´ nasledovnu´ konvenciu pre konfiguraciu´ slu- zieb:ˇ konfiguracnˇ e´ polozkyˇ sluziebˇ by mali mat’ ako prefix nazov´ sluzbyˇ bez ”Service”prevedny´ do malych´ p´ısmen zakoncenˇ y´ znakom bodky, napr´ı- klad sluzbaˇ LoggingService by mala vyuzˇ´ıvat’ prefix ”logging.”. Pre kazdˇ u´ sluzbuˇ je tiezˇ stanovana´ speciˇ alna´ konfiguracnˇ a´ polozkaˇ ”serviceProviders. • Service Management Service – sluzba,ˇ ktora´ umozˇnujeˇ za behu sku-´ mat’ dostupne´ sluzbyˇ a z´ıskavat’ ich implementacie.´ Umozˇnujeˇ vy- tvorenie takzvanych´ slabych´ zavislost´ ´ı – modul vyuzijeˇ alternat´ıvnu aplikacnˇ u´ logiku v pr´ıpade, zeˇ je dana´ sluzbaˇ nedostupna,´ ale nevy- zadujeˇ ju pre svoj beh. Sluzbaˇ je implementovana´ modulom Module Manager (viz 3.9). • Module Communication Service – umozˇnujeˇ posielanie udalost´ı me- dzi modulmi a volanie metod´ druhych´ modulov. Sluzbaˇ je imple- mentovana´ modulom Module Manager (viz 3.9). • Data Management Service – sluzbaˇ zaist’ujuca´ manipulaciu´ s datami´ v aplikacii.´ Tato´ sluzbaˇ poskytuje jednotne´ API pre pracu´ so vsetkˇ y-´ mi datov´ ymi´ sadami (viz 3.5) bez rozdielu. Sluzbaˇ umozˇnujeˇ vyu- zˇ´ıvat’ jazyk JPQL [11] na filtrovanie a triedenie zaznamov´ v l’ubovol’- nej datovej´ sade. Tato´ sluzbaˇ je implementovana´ modulom Presenter (viz 3.10). 21 3. NAVRHARCHITEKT´ URY´ • Data Set Inspector Service – poskytuje API pre skumanie´ dostup- nych´ datov´ ych´ sad´ a ich struktˇ ury.´ Sluzbaˇ umozˇnujeˇ za behu z´ıska- vat’ informacie´ o vlastnostiach datov´ ych´ sad´ a ich pol´ı, skumat´ ’ ope- racie´ definovane´ na jednotlivych´ datov´ ych´ sadach´ a ich dodatocnˇ e´ parametre. Tato´ sluzbaˇ je implementovana´ modulom Presenter (viz 3.10). • Localization Service – sluzbaˇ poskytuje pr´ıstup k lokalizacii´ jednot- livych´ modulov a globalnym´ lokalizacnˇ ym´ suborom.´ Aplikacnˇ y´ ra-´ mec definuje konvencie pre pomenovanie danych´ lokalizacnˇ ych´ fra-´ z´ı. Tieto konvencie su´ detailne pop´ısane´ v pr´ılohe Architektura´ ap- likacnˇ eho´ ramca´ .Tato´ sluzbaˇ je implementovana´ modulom Presen- ter (viz 3.10). • Logging Service – sluzbaˇ pre centralne´ logovanie v aplikacii.´ Ap- likacnˇ y´ ramec´ pouzijeˇ vstavany´ logger, pokial’nie je dostupny´ ziadenˇ modul implementujuci´ tuto´ sluzbuˇ (viz pr´ıloha Architektura´ apli- kacnˇ eho´ ramca´ ). Tato´ sluzbaˇ je implementovana´ modulom File Log- ger (viz 3.11). • User Rights Service – sluzba,ˇ ktora´ poskytuje podporu pre pouzˇ´ıva- tel’ske´ u´ cty,ˇ skupiny a prava.´ Tato´ sluzbaˇ poskytuje API pre kontrolu pouzˇ´ıvatel’skych´ prav´ a prihlasovanie pouzˇ´ıvatel’ov pomocou pouzˇ´ı- vatel’skeho´ mena a hesla. Tato´ sluzbaˇ je implementovana´ modulom Users (viz 3.12). • Sessions Service – sluzbaˇ poskytujuca´ podporu pre pouzˇ´ıvatel’ske´ se- denia. Sluzbaˇ definuje API pre vytvaranie´ novych´ pouzˇ´ıvatel’skych´ seden´ı a z´ıskavanie referenci´ı na existujuce´ pouzˇ´ıvatel’ske´ sedenia. Jednotlive´ sedenia predstavuju´ docasnˇ e´ ulo´ ziskˇ a´ dat´ suvisiacich´ s pouzˇ´ıvan´ım aplikacie´ danym´ pouzˇ´ıvatel’om v obdob´ı medzi prihla-´ sen´ım a odhlasen´ ´ım. Tato´ sluzbaˇ je implementovana´ modulom Ses- sions (viz 3.13). • Alarm Service – tato´ sluzbaˇ umozˇnujeˇ zasielanie alarmov, ktore´ je moznˇ e´ vyuzitˇ napr´ıklad na monitorovanie aplikacie.´ Tato´ sluzbaˇ je implementovana´ modulom Alarm Logger (viz 3.14). • Statistics Service – sluzbaˇ umozˇnujˇ uca´ zber a vyhodnocovanie statis-ˇ tickych´ udajov.´ Sluzbaˇ zarove´ nˇ umozˇnujeˇ urcovatˇ ’ limity pre statis-ˇ tiky pocˇ´ıtane´ aplikaciou,´ ktore´ je moznˇ e´ monitorovat’.Tato´ sluzbaˇ je implementovana´ modulom Statistics (viz 3.15). 22 3. NAVRHARCHITEKT´ URY´ • Billing Service – poskytuje API na u´ ctovanieˇ poplatkov za vykona-´ vanie operaci´ ´ı pouzˇ´ıvatel’mi alebo pouzˇ´ıvatel’skymi´ skupinami. Tato´ sluzbaˇ umozˇnujeˇ vyuzitˇ ’ model platby dopredu aj platby spatne.¨ Ta-´ to sluzbaˇ je implementovana´ modulom Billing (viz 3.16). 3.5 D´atov´esady Datov´ e´ sady predstavuju´ struktˇ urovan´ e´ ulo´ ziskˇ a´ dat.´ Datov´ e´ sady su´ de- finovane´ ako JPA entity v bal´ıckochˇ cz.muni.fi.xjurca.runtime. • beznˇ e´ datov´ e´ sady • virtualne´ datov´ e´ sady • agregacie´ datov´ ych´ sad´ Beznˇ e´ datov´ e´ sady su´ reprezentovane´ obycajnˇ ymi´ JPA entitami. Tieto datov´ e´ sady su´ ukladane´ do databazy,´ alebo ineho´ primarneho´ ulo´ ziskaˇ dat,´ ktore´ aplikacia´ pouzˇ´ıva. Virtualne´ datov´ e´ sady su´ definovane´ ako beznˇ e´ datov´ e´ sady, ale trieda datovej´ sady ma´ anotaciu´ @cz.muni.fi.xjurca.runtime.datasets.annotations. VirtualDataSet. Virtualne´ datov´ e´ sady nie su´ obvykle ukladane´ do databazy´ aplikacie.´ Pr´ıstup k zaznamom´ datovej´ sady je umoznenˇ y´ pomocou objektu poskytnuteho´ metodou´ modulu, ktory´ datov´ u´ sadu definuje. Virtualne´ da-´ tove´ sady je moznˇ e´ vyuzitˇ ’ na spr´ıstupnenie inych´ ulo´ zˇ´ısk dat,´ spr´ıstupnit’ data´ v pamati¨ aplikacii´ alebo poskytovat’ sluzby,ˇ ktore´ je moznˇ e´ reprezen- tovat’ datovou´ sadou – napr´ıklad tlacovˇ a´ fronta. Agregacie´ datov´ ych´ sad´ slu´ ziaˇ na spojenie zaznamov´ z viacerych´ da-´ tovych´ sad´ do jednej datovej´ sady, cˇ´ım vytvaraj´ u´ iste´ pohl’ady na data´ v ap- likacii.´ Agregacie´ datov´ ych´ sad´ su´ virtualne´ datov´ e´ sady implementovane´ aplikacnˇ ym´ ramcom.´ 3.6 Konfigur´acia Konfiguracia´ aplikacie´ je centralizovana´ a ulozenˇ a´ v textovych´ suboroch.´ Format´ konfiguracnˇ ych´ suborov´ vychadza´ z formatu´ .properties jazyka Ja- va [12]. Tento format´ je ramcom´ rozsˇ´ıreny´ o pr´ıkaz vlozeniaˇ ineho´ suboru.´ Pr´ıkaz vlozeniaˇ ma´ podobu @include cesta/k/suboru.cfg´ . Pr´ıkazy vlozeniaˇ 23 3. NAVRHARCHITEKT´ URY´ su´ vyhodnocovane´ pocasˇ nacˇ´ıtania suboru´ aplikacnˇ ym´ ramcom.´ Kazdˇ y´ na- cˇ´ıtany´ subor´ konfiguracie´ moˆzeˇ obsahovat’ l’ubovol’ne´ mnozstvoˇ tychto´ pr´ı- kazov. Konfiguracia´ je nacˇ´ıtana´ z adresara´ konfiguracie,´ pricomˇ ramec´ nacˇ´ıta len subor´ main.cfg a subory,´ na ktore´ sa tento subor´ odkazuje pr´ıkazmi vlozeniaˇ (rekurz´ıvne). Aplikacnˇ y´ ramec´ poskytuje prostriedky pre automaticku´ validaciu´ kon- figuracie.´ Aplikacnˇ y´ ramec´ umozˇnujeˇ deklarat´ıvne zap´ısat’ validacnˇ e´ ob- medzenia pre konfiguracnˇ e´ polozkyˇ do textovych´ suborov,´ ktorych´ format´ vychadza´ z formatu´ .properties jazyka Java. Tieto validacnˇ e´ obmedzenia umozˇnujˇ u´ obmedzit’ povolene´ hodnoty pre konfiguracnˇ e´ polozkyˇ a tiezˇ de- finovat’ predvolene´ hodnoty pre tieto polozky.ˇ Kazdˇ y´ modul moˆzeˇ obsahovat’ validacnˇ y´ subor´ pre svoje konfiguracnˇ e´ polozky.ˇ Aplikacnˇ y´ ramec´ automaticky pouzˇ´ıva vsetkyˇ validacnˇ e´ subory´ vsetkˇ ych´ akt´ıvnych modulov. Validacia´ konfiguracie´ je detailne pop´ısana´ v pr´ılohe Funkcnˇ a´ specifi-ˇ kacia´ . 3.7 Lokaliz´acia Lokalizacia´ aplikacie´ ju ulozenˇ a´ v textovych´ .properties suboroch.´ Aplikac-ˇ ny´ ramec´ poskytuje zakladn´ u´ globalnu´ lokalizaciu,´ kazdˇ y´ modul poskytuje lokalizaciu´ pre svoje vlastne´ datov´ e´ sady a operacie.´ Aplikacnˇ y´ ramec´ definuje konvencie pre pomenovanie lokalizacnˇ ych´ poloziek,ˇ ktore´ ich zoskupuju´ podl’a vyuzitiaˇ pomocou prefixov: • • operation. • field. • enum. • type. • constrain. 24 3. NAVRHARCHITEKT´ URY´ Konvencie pomenovania lokalizacnˇ ych´ poloziekˇ su´ detailne pop´ısane´ v pr´ılohe Architektura´ aplikacnˇ eho´ ramca´ . 3.8 Zivotnˇ y´ cyklus aplik´acie 3.8.1 Spustenie aplik´acie Aplikacia´ je spustena´ zo zavadza´ cuˇ aplikacie.´ Zavadza´ cˇ aplikacie´ vytvor´ı novu´ instanciuˇ Jadra (trieda cz.muni.fi.xjurca.runtime.Core). Jadro behom inicializacie´ vykona´ nasledovne´ kroky: • rozpoznanie a spracovanie parametrov odovzdanych´ z pr´ıkazoveho´ riadku • inicializacia´ vstaveneho´ loggeru • vyhl’adanie dostupnych´ modulov • nacˇ´ıtanie konfiguracie´ • validacia´ konfiguracie´ • vytvorenie konfiguracie´ pre Java Persistence API – vygenerovanie konfiguracnˇ eho´ suboru´ persistence.xml s vymenovanymi´ datov´ ymi´ sadami vsetkˇ ych´ dostupnych´ modulov. • vytvorenie spojenia do databazy´ pomocou JPA Jadro vyhod´ı vynimku´ pokial’ ktorykol´ ’vek z tychto´ krokov zlyha.´ Ap- likacia´ sa v takom pr´ıpade mus´ı ukoncitˇ ’. Po uspe´ snejˇ inicializacii´ Jadra vykona´ zavadza´ cˇ metodu´ Jadra startup(). Tato´ metoda´ dorucˇ´ı vsetkˇ ym´ modulom aplikacie´ nasledovne´ udalosti: • startup – moduly sa maju´ inicializovat’. • running – inicializacia´ prebehla uspe´ sne,ˇ aplikacia´ bezˇ´ı. Po vykonan´ı tychto´ krokov je aplikacia´ obvykle riadena´ vstupom z pou- zˇ´ıvatel’skeho´ rozhrania, ktory´ spracovav´ a´ jeden alebo viacere´ moduly. 25 3. NAVRHARCHITEKT´ URY´ 3.8.2 Ukonˇcenieaplik´acie Pre ukoncenieˇ aplikacie´ je nutne´ zavolat’ metodu´ Jadra shutdown().Tato´ metoda´ vykona´ nasledovne´ kroky: • poslanie udalosti shutdown – moduly maju´ ukoncitˇ ’ svoju cinnostˇ ’. • nasiln´ e´ ukoncenieˇ ostatnych´ vlakien´ – Jadro je schopne´ nasilne´ ukon- citˇ ’ vsetkyˇ prebiehajuce´ vlakna´ okrem aktualneho,´ v ktorom prebieha ukoncovaciaˇ procedura.´ Toto je uzitoˇ cnˇ e´ pre ladenie aplikacie,´ ale nemalo by sa pouzˇ´ıvat’ v produkcnomˇ prostred´ı. • uzavretie spojenia s databazou.´ • ukoncenieˇ vstavaneho´ loggeru. Po dokoncenˇ ´ı tejto metody´ moˆzeˇ kod,´ ktory´ metodu´ vyvolal, ukoncitˇ ’ aplikaciu´ volan´ım System.exit(0). 3.9 Module Manager Module Manager je jediny´ modul, ktory´ je priamo vyuzˇ´ıvany´ Jadrom. Tento modul zaist’uje inicializaciu´ ostatnych´ modulov v aplikacii,´ spravu´ a posky- tovanie sluziebˇ medzi modulmi a komunikaciu´ medzi modulmi. Pred dorucenˇ ´ım udalosti startup vykona´ Module Manager nasledovne´ kroky: • nacˇ´ıtanie zoznamu akt´ıvnych modulov z databazy´ • kontrola dostupnosti vsetkˇ ych´ akt´ıvnych modulov • vytvorenie instanciˇ ´ı hlavnych´ tried vsetkˇ ych´ modulov • vytvorenie zaznamov´ datovej´ sady ModuleManagerService obsahu- juce´ informacie´ o dostupnych´ sluzbˇ ach´ • vyhl’adanie vsetkˇ ych´ pozorovatel’ov udalost´ı • odovzdanie instanciˇ ´ı modulov modulu Presenter – modul Presenter ich pouzˇ´ıva pre efekt´ıvnejsiuˇ pracu´ s datov´ ymi´ sadami (viz 3.10). • poslanie udalosti startup s informaciami´ o vsetkˇ ych´ a akt´ıvnych mo- duloch 26 3. NAVRHARCHITEKT´ URY´ 3.9.1 D´atov´esady Modul definuje nasledovne´ datov´ e´ sady: • ModuleManagerService – obsahuje zaznamy´ o sluzbˇ ach´ dostupnych´ pre moduly. • ModuleManagerModuleStatus – obsahuje informacie´ o stave dos- tupnych´ modulov. • ModuleManagerModuleDetail – obsahuje lokalizovane´ informacie´ o akt´ıvnych moduloch. Tato´ datov´ a´ sada je virtualna,´ Module Ma- nager generuje zaznamy´ pri kazdomˇ pr´ıstupe. • ModuleManagerModule – predstavuje agregaciu´ datov´ ych´ sad´ Mo- duleManagerModuleStatus a ModuleManagerModuleDetail. 3.10 Presenter Modul Presenter poskytuje lokalizacnˇ e´ a datov´ e´ sluzbyˇ (Localization Ser- vice, Data Management Service, Data Inspector Service). Tento modul nedefinuje ziadneˇ datov´ e´ sady. 3.11 File Logger Modul File Logger je implementaciou´ logovacej sluzbyˇ (Logging Service). Modul loguje do l’udsky citatelˇ ’nych´ textovych´ suborov.´ Modul je schopny´ delit’ logovacie spravy´ do viacerych´ suborov´ pri dosiahnut´ı daneho´ poctuˇ sprav´ na subor,´ indexovat’ vytvaran´ e´ logovacie subory´ a komprimovat’ a mazat’ stare´ logovacie subory.´ 3.11.1 D´atov´esady Modul definuje nasledovne´ datov´ e´ sady: • FileLoggerFile – datov´ a´ sada reprezentujuca´ logovacie subory.´ • FileLoggerEntry – datov´ a´ sada reprezentujuca´ logovacie spravy.´ 27 3. NAVRHARCHITEKT´ URY´ 3.12 Users Modul Users implementuje sluzbuˇ User Rights Service. Modul udrziavaˇ in- formacie´ o pouzˇ´ıvatel’skych´ u´ ctoch,ˇ skupinach,´ rolach´ a pravach´ v datov´ ych´ sadach.´ Tento modul zarove´ nˇ udrziavaˇ zaznamy´ o historii´ prihlasovania sa pouzˇ´ıvatel’ov do aplikacie.´ 3.12.1 D´atov´esady Modul definuje nasledovne´ datov´ e´ sady: • UsersUser – obsahuje zaznamy´ o pouzˇ´ıvatel’skych´ u´ ctoch.ˇ Kazdˇ y´ u´ cetˇ ma´ priradenu´ mnozinuˇ pouzˇ´ıvatel’skych´ rol´ı a mnozinuˇ pouzˇ´ı- vatel’skych´ skup´ın. • UsersRole – pouzˇ´ıvatel’ske´ role. Kazdˇ a´ pouzˇ´ıvatel’ska´ rola predsta- vuje mnozinuˇ pouzˇ´ıvatel’skych´ prav.´ • UsersGroup – obsahuje pouzˇ´ıvatel’ske´ skupiny. Pouzˇ´ıvatel’ska´ sku- pina je mnozinouˇ pouzˇ´ıvatel’ov. Skupina obsahuje tiezˇ mnozinouˇ po- uzˇ´ıvatel’skych´ rol´ı pridelenych´ danym´ pouzˇ´ıvatel’om. • UsersRight – definovane´ pouzˇ´ıvatel’ske´ prava.´ Datov´ a´ sada je vyuzˇ´ı- vana´ primarne´ na zaistenie konzistencie dat´ na urovni´ datov´ ych´ sad.´ • UsersCache – vyrovnavacia´ pamat¨ ’ pre priame mapovanie pouzˇ´ıva- tel’skych´ u´ ctovˇ na pouzˇ´ıvatel’ske´ prava.´ Modul obsah tejto datovej´ sady transparentne aktualizuje. • UsersLoginLog – obsahuje zaznamy´ o prihlaseniach´ pouzˇ´ıvatel’ov do aplikacie.´ 3.13 Sessions Modul Sessions implementuje sluzbuˇ pre podporu pouzˇ´ıvatel’skych´ seden´ı (Sessions Service). 3.13.1 D´atov´esady Modul definuje datov´ u´ sady SessionsSession.Zaznamy´ tejto datovej´ sady predstavuju´ jednotlive´ pouzˇ´ıvatel’ske´ sedenia a k nim priradene´ data.´ 28 3. NAVRHARCHITEKT´ URY´ 3.14 Alarm Logger Modul Alarm Logger implementuje sluzbuˇ Alarm Service. Tento modul preposiela vsetkyˇ alarmy logovacej sluzbe.ˇ 3.15 Statistics Modul Statistics implementuje sluzbuˇ Statistics Service. Modul umozˇnujeˇ zber statistickˇ ych´ dat´ a ukladanie historie´ vypocˇ´ıtanych´ statistickˇ ych´ hod- notˆ v datovej´ sade. Modul je schopny´ vyvolat’ alarm pri prekrocenˇ ´ı nasta- venych´ limitov statistˇ ´ık. 3.15.1 D´atov´esady Modul definuje datov´ u´ sadu StatisticsHistory. Modul v pravidelnych´ inter- valoch pridava´ do tejto datovej´ sady zaznamy´ o vypocˇ´ıtanych´ statistickˇ ych´ hodnotach.´ 3.16 Billing Modul Billing je implementaciou´ sluzbyˇ Billing Service. 3.16.1 D´atov´esady Modul definuje nasledovne´ datov´ e´ sady: • BillingAccount – datov´ a´ sada uchovavaj´ uca´ zaznamy´ o existujucich´ u´ ctochˇ pre pouzˇ´ıvatel’ov a pouzˇ´ıvatel’ske´ skupiny. • BillingHistory – datov´ a´ sada obsahujuca´ zaznamy´ o cerpanˇ ´ı kreditu z u´ ctov.ˇ 3.17 Inˇstal´ator Instalˇ ator´ je samostatna´ konzolova´ aplikacia´ urcenˇ a´ pre instalˇ aciu´ aplikacie´ postavenej na aplikacnomˇ ramci.´ Instalˇ ator´ umozˇnujeˇ spravovanie modu- lov, kontrolu zavislost´ ´ı a instalovanie,ˇ odinstalovanie,ˇ zap´ınanie a vyp´ı- nanie jednotlivych´ modulov. Instalˇ ator´ uklada´ stav modulov do datovej´ sady ModuleManagerModu- leStatus. Pomocou tejto datovej´ sady je schopny´ rozpoznat’ prve´ spustenie, pri ktorom automaticky spust´ı instalˇ aciu´ vsetkˇ ych´ dostupnych´ modulov. 29 3. NAVRHARCHITEKT´ URY´ Pokial’ je instalˇ ator´ spusteny´ opakovane, zobraz´ı menu pre spravu´ modu- lov. Instalˇ ator´ je detailne pop´ısany´ v pr´ılohe Architektura´ aplikacnˇ eho´ ram-´ ca. 30 Kapitola 4 Uk´azkov´aaplik´aciaˇ Pre u´ celyˇ demonstrˇ acie´ pouzitelˇ ’nosti navrhnuteho´ aplikacnˇ eho´ ramca´ bola pripravena´ jednoducha´ aplikacia´ pre evidenciu potrav´ın v chladnicke.ˇ Ap- likacia´ umozˇnujeˇ evidovat’ zoznam potrav´ın oznacnˇ ych´ nazvami´ a popismi a uchovavat´ ’ informacie´ o cene potrav´ın, pocteˇ ostavaj´ ucich´ kusov, datumu´ kupy´ a datumu´ poslednej spotreby. Uka´zkovˇ a´ aplikacia´ pozostava´ z nasledovnych´ su´ castˇ ´ı: • zavadza´ cˇ – zaist’uje spustenie aplikacie.´ • Jadro – Jadro aplikacnˇ eho´ ramca,´ ktore´ je nevyhnutne´ pre spustenie a beh aplikacie.´ • modul Module Manager – zaist’uje spustenie vsetkˇ ych´ modulov ap- likacie´ a umozˇnujeˇ komunikaciu´ medzi modulmi. • modul Presenter – slu´ ziˇ pre pracu´ s datami´ aplikacie.´ • modul GUI – modul navrhnuty´ pre potreby uka´zkovejˇ aplikacie.´ Tento modul poskytuje graficke´ pouzˇ´ıvatel’ske´ rozhranie vytvorene´ pomocou knizniceˇ Swing. • modul Fridge – modul navrhnuty´ pre potreby uka´zkovejˇ aplikacie.´ Tento modul obsahuje defin´ıciu datovej´ sady FridgeItem, ktora´ je pouzitˇ a´ na ulozenieˇ zaznamov´ o potravinach´ v chladnicke.ˇ • instalˇ ator´ – nastroj´ na nainstalovanieˇ modulov uka´zkovejˇ aplikacie.´ • spu´ stˇ ’acie skripty instalˇ atoru´ – skripty pre Linuxovy´ shell a pr´ıkazovy´ riadok Windows, ktore´ zjednodusujˇ u´ spustenie instalˇ atoru.´ • spu´ stˇ ’acie skripty aplikacie´ – skripty pre Linuxovy´ shell a pr´ıkazovy´ riadok Windows, ktore´ zjednodusujˇ u´ spustenie aplikacie.´ 31 4. UKA´ ZKOVˇ AAPLIK´ ACIA´ Komunikaciu´ medzi hlavnymi´ su´ castˇ ’ami uka´zkovejˇ aplikacie´ znazor-´ nujeˇ nasledovny´ diagram: 4.1 Modul Fridge Modul Fridge obsahuje defin´ıciu datovej´ sady FridgeItem.Datov´ a´ sada ma´ nasledovnu´ struktˇ uru:´ • id – unikatny´ identifikator´ zaznamu´ o polozkeˇ v chladnicke.ˇ • name – nazov´ polozkyˇ v chladnicke.ˇ • description – nepovinny´ popis polozkyˇ v chladnicke.ˇ • price – cena, za ktoru´ bola polozkaˇ kupen´ a.´ • itemsLeft – pocetˇ kusov danej polozkyˇ v chladnicke.ˇ • buyed – datum´ a casˇ kupy´ danej polozky.ˇ • lastTaken – datum´ a casˇ poslednej konzumacie´ danej polozky.ˇ 32 4. UKA´ ZKOVˇ AAPLIK´ ACIA´ Nad touto datovou´ sadou je definovana´ jedna nestandardnˇ a´ operacia´ take.Tato´ operacia´ predstavuje vybranie jedneho´ kusu danej polozkyˇ z chladnicky.ˇ Operacia´ zmazeˇ zaznam´ pokial’ pocetˇ ostavaj´ ucich´ kusov kles- ne na nulu. Tato´ operacia´ je implementovana´ modulom Fridge. 4.2 Modul GUI Modul GUI poskytuje graficke´ rozhranie aplikacie.´ Graficke´ rozhranie ap- likacie´ pozostava´ z vypisu´ poloziekˇ v chladickeˇ a tlacidielˇ pre vykonavanie´ operaci´ ´ı nad datovou´ sadou FridgeItem. Modul vytvara´ modalne´ okna´ pre z´ıskanie vstupu operaci´ ´ı alebo zobra- zenie detailov polozky.ˇ 4.3 Spustenie aplik´acie Pri spusten´ı aplikacie´ zavadza´ cˇ vytvor´ı instanciuˇ Jadra. Jadro vytvor´ı in- stanciuˇ modulu Module Manager. Zavadza´ cˇ odovzda´ modulu GUI instan-ˇ ciu Jadra pomocou statickej metody´ setCore. Zavadza´ cˇ zavola´ metodu´ Jadra startup. Metoda´ startup cez modul Mo- dul Manager posleˇ udalost’ startup. Modul Modul Manager vytvor´ı instan-ˇ cie ostatnych´ modulov a udalost’ dorucˇ´ı. Metoda´ startup potom posleˇ uda- lost’ running. Modul GUI pri dorucenˇ ´ı udalosti running zobraz´ı graficke´ rozhranie. Tento proces znazor´ nujeˇ nasledovny´ diagram: 33 4. UKA´ ZKOVˇ AAPLIK´ ACIA´ 4.4 Beh aplik´acie Pri behu aplikacie´ sa v hlavnom okne zobrazuje vypis´ existujucich´ poloziek.ˇ Modul GUI spracovava´ akcie vykonane´ v grafickom rozhran´ı a podl’a typu akcie vytvor´ı, uprav´ı, zmazeˇ alebo nacˇ´ıta zaznamy´ datovej´ sady FridgeI- tem. Po vykonan´ı operacie´ modul GUI obnov´ı vypis´ poloziek.ˇ Nasledujuci´ diagram ukazuje komunikaciu´ medzi modulmi pri ulozenˇ ´ı noveho´ zaznamu´ a naslednom´ vykonan´ı nestandartnejˇ operacie´ take vram-´ ci jednej transakcie. 34 4. UKA´ ZKOVˇ AAPLIK´ ACIA´ 4.5 Ukonˇcenieaplik´acie Aplikacia´ je ukoncenˇ a´ pri zatvoren´ı hlavneho´ okna aplikacie.´ Pri zatvoren´ı hlavneho´ okna modul GUI zavola´ metodu´ Jadra shutdown. Metoda´ shut- down posleˇ udalost’ shutdown vsetkˇ ym´ modulom. V uka´zkovejˇ aplikacii´ na tuto´ udalost’ nereaguje ziadenˇ modul. Po dokoncenˇ ´ı metody´ shutdown modul GUI ukoncˇ´ı aplikaciu.´ 35 Kapitola 5 Z´aver V praci´ bol navrhnuty´ aplikacnˇ y´ ramec,´ ktory´ sp´lnaˇ stanovene´ ciele, pozia-ˇ davky a obmedzenia. Vyuzitelˇ ’nost’ navrhnuteho´ aplikacnˇ eho´ ramca´ bola nasledne´ preverena´ vytvoren´ım jednoduchej uka´zkovejˇ aplikacie.´ Navrhnuty´ ramec´ predsatvuje pouzitelˇ ’ny´ zaklad´ pre tvorbu enterprise aplikaci´ ´ı orientovanych´ na data.´ Dalˇ sˇ´ı vyvoj´ aplikacnˇ eho´ ramca´ by mohol riesitˇ ’ skˇ alovatel´ ’nost’ a beh v cloude, coˇ by nemalo byt’ t’azkˇ e´ dosiahnut’. Aplikacnˇ y´ ramec´ umozˇnujeˇ vyuzitieˇ viac-vlaknov´ eho´ modelu, ktory´ je predpokladom pre vertikalnu´ skˇ alovatel´ ’nost’. Horizontalnu´ skˇ alovatel´ ’nost’ je moznˇ e´ dosiahnut’ vyuzitˇ ´ım viacerych´ instanciˇ ´ı aplikacie´ beziacichˇ na samostatnych´ serveroch a data- bazov´ eho´ clusteru pre ukladanie dat.´ Dalˇ sˇ´ı rozvoj aplikacnˇ eho´ ramca´ by mohol zahr´natˇ ’ napr´ılad dynamicky pocˇ´ıtane´ atributy´ datov´ ych´ sad,´ ktore´ by boli odvodene´ z inych´ atributov´ deklarat´ıvne zadanymi´ vzorcami. Inym´ smerom vyvoja´ moˆzeˇ byt’ modul, ktory´ by obsahoval aplikacnˇ u´ logiku spolocnˇ u´ pre rozneˆ pouzˇ´ıvatel’ske´ roz- hrania a modul poskytujuci´ genericke´ pouzˇ´ıvatel’ske´ rozhranie. Aplikacnˇ y´ ramec´ s´ıce vyuzˇ´ıva deklarat´ıvne postupy pre navrh´ aplikaci´ ´ı, ale nevyuzˇ´ıva vsetkyˇ moznostiˇ deklarat´ıvneho pr´ıstupu. Dalˇ sˇ´ı vyzkum´ v tejto oblasti by mohol lepsieˇ vymedzit’ moznostiˇ deklarat´ıvneho pr´ıstupu, ktore´ by boli pr´ınosom pri navrhu,´ a rozpoznat’ moznosti,ˇ ktore´ by naopak viedli ku komplikovanejsiemuˇ navrhu´ aplikaci´ ´ı. 37 Literat ´ura [1] Kragen Sitaker, ” Enterprise software is a social, not technical, phenomenon,”http://lists.canonical.org/pipermail/kragen-tol/2005- April/000772.html, (2005) [2] J. W. Lloyd, ”Practical Advantages of Declarative Program- ming,”(University of Bristol, 1994) [3] Peter Eeles, Peter Cripps, ” Architektura softwaru,”(Computer Press, 2011) [4] Ruth Malan, Dana Bredemeyer, ”Defining Non-Functional Require- ments,”http://www.bredemeyer.com/pdf files/NonFunctReq.PDF, (2001) [5] Martin Fowler, ”POJO,”http://www.martinfowler.com/bliki/ POJO.html [6] Andrew Hunt, David Thomas, ”The Pragmatic Programmer: From Journeyman to Master,”(Addison Wesley Longman, 1999) [7] David Jordan, ”Java Data Objects,”(O’Reilly, 2003) [8] Mike Keith, Merrick Schincariol, ”Pro JPA 2: Mastering the Java(TM) Persistence API (Expert’s Voice in Java Technology),”(Apress, 2009) [9] C. Lonvick, ”The BSD syslog protocol,” http://www.ietf.org/rfc/rfc3164.txt, (IETF, 2001) [10] Mike Potel, ”MVP: Model-View-Presenter The Ta- ligent Programming Model for C++ and Java,” http://www.wildcrest.com/Potel/Portfolio/mvp.pdf, (Taligent, Inc, 1996) [11] ”JPQL Language Reference,” http://docs.oracle.com/cd/E16764 01/ apirefs.1111/e13946/ejb3 langref.html, (Oracle, 2009) 39 5. ZAVER´ [12] http://docs.oracle.com/javase/7/docs/api/java/util/ Properties.html#load(java.io.Reader) [13] Richard M. Reese, ” EJB 3.1 Cookbook,” (Packt Publishing, 2011) [14] David R. Heffelfinger, ”Java EE 6 Development with NetBeans 7,”(Pack Publishing, 2011) [15] Alexander Kolesnikov, ”Tapestry 5: Building Web Applications: A step-by-step guide to Java Web development with the developer- friendly Apache Tapestry framework,” (Packt Publishing, 2007) 40 Pr´ılohy Prieskum aplikaˇcnych´ r´amcov Funkˇcn´aˇspecifik´aciaaplikaˇcn´ehor´amca Architekt ´uraaplikaˇcn´ehor´amca Zdrojov´ek´odya zostaven´auk´azkov´aaplik´aciaˇ 41
Deklaratıvne-Imperatıvny Aplikaˇcn´Y R´Amec
