Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. komponent

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace Optimalizace a rozˇ s´ıˇ ren´ı porovn´ av´ an´ı OSGi komponent

Plzeˇ n 2012

Zuzana Bureˇsová

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracovala samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 16. kvˇetna 2012 Zuzana Bureˇsová

Abstract The comparator of Java types and OSGi components, which was developed on the Department of Computer Science and Engineering of the University of West Bohemia, can check compatibility of OSGi components and prevent errors from running incompatible components in a component framework. There are many application opportunities of this functionality, but currently only a few superstructural tools are ready for real usage. The goal of this diploma thesis is to spread possibility of real usage of the comparator by two means. The first targets improving comparator usability on performance-limited devices by optimizations of its memory consumption and computation time. Secondly, the work aims at enhancing functionality of the superstructural tools to provide more benefits for users. The implemented enhancement allows manual component difference analysis by providing graphical presentation of the differences.

Obsah ´ 1 Uvod 1.1 V´ ychoz´ı stav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 C´ıl projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Struˇcn´ y pˇrehled . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Komponenty 2.1 Koncept . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 2.1.1 Uvod . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Komponenta . . . . . . . . . . . . . . . . . . . 2.1.3 Komponentov´ y model . . . . . . . . . . . . . . 2.1.4 Komponentov´ y framework . . . . . . . . . . . . 2.1.5 Problémy . . . . . . . . . . . . . . . . . . . . . 2.2 Technologie OSGi . . . . . . . . . . . . . . . . . . . . . 2.2.1 OSGi specifikace . . . . . . . . . . . . . . . . . 2.2.2 OSGi komponenta . . . . . . . . . . . . . . . . 2.2.3 OSGi framework . . . . . . . . . . . . . . . . . ˇ 2.2.4 Zivotn´ ı cyklus OSGi komponenty . . . . . . . . 2.2.5 Aktiv´ ator OSGi komponenty . . . . . . . . . . 2.2.6 Interakce mezi OSGi komponentami . . . . . . 2.3 Sémantické verzov´ an´ı a resolving v OSGi . . . . . . . 2.3.1 Resolving . . . . . . . . . . . . . . . . . . . . . 2.3.2 Sémantické verzován´ı . . . . . . . . . . . . . . 2.3.3 Problémy resolvingu a sémantického verzován´ı 2.3.4 Dalˇs´ı problémy resolvingu . . . . . . . . . . . .

1 1 2 2

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

4 4 4 4 5 6 6 6 6 7 8 9 10 10 10 10 11 11 12

3 Nahraditelnost komponent 3.1 Pouˇzit´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 V´ ysledky a smˇer v´ yzkumu na katedˇre . . . . . . . . . . . 3.2.1 Pouˇzit´ı komparátoru pˇri resolvingu . . . . . . . . . 3.2.2 Podpora pro bezpeˇcnou nahraditelnost komponent 3.2.3 Podpora pro správné sémantické verzován´ı . . . . 3.2.4 Dalˇs´ı n´ amˇety pro pouˇzit´ı komparátoru . . . . . . . 3.3 Teorie nahraditelnosti komponent . . . . . . . . . . . . . . 3.3.1 Relace subtypu mezi komponentami . . . . . . . . 3.3.2 Jak lze relaci subtypu zjistit . . . . . . . . . . . . . 3.3.3 Metody ovˇeˇren´ı nahraditelnosti . . . . . . . . . . . 3.4 Kompar´ atory Java tˇr´ıd a OSGi komponent . . . . . . . . 3.4.1 Projekty pro z´ıskán´ı reprezentace . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

13 13 13 13 14 14 15 15 15 16 16 16 17

. . . . . . . . . . . . . . . . . .

OBSAH

3.5

3.6

3.7

3.8

3.9

OBSAH

3.4.2 Projekty komparátor˚ u z´ıskané reprezentace 3.4.3 Z´ avislosti mezi projekty . . . . . . . . . . . 3.4.4 Dalˇs´ı projekty . . . . . . . . . . . . . . . . Architektura kompar´ ator˚ u . . . . . . . . . . . . . . 3.5.1 Reprezentace Java typ˚ u . . . . . . . . . . . 3.5.2 Architektura naˇc´ıtán´ı reprezentace . . . . . 3.5.3 Architektura komparátor˚ u. . . . . . . . . . 3.5.4 Agregace v´ ysledku porovnán´ı . . . . . . . . Problémy a n´ amˇety pro dalˇs´ı práci . . . . . . . . . 3.6.1 Generické typy . . . . . . . . . . . . . . . . 3.6.2 Porovn´ av´ an´ı tˇr´ıd . . . . . . . . . . . . . . . 3.6.3 Ovˇeˇrov´ an´ı kompatibility dvou komponent . 3.6.4 Dalˇs´ı nedostatky . . . . . . . . . . . . . . . Implementované opravy a vylepˇsen´ı . . . . . . . . . ´ 3.7.1 Upravy hierarchie Java typ˚ u . . . . . . . . 3.7.2 Pomoc pˇri thread-safety anal´ yze . . . . . . ´ 3.7.3 Upravy struktury v´ ysledk˚ u porovnán´ı . . . 3.7.4 Vylepˇsen´ı algoritmu porovnán´ı tˇr´ıd . . . . . Technologie a v´ yvojové nástroje . . . . . . . . . . . 3.8.1 Java . . . . . . . . . . . . . . . . . . . . . . 3.8.2 OSGi . . . . . . . . . . . . . . . . . . . . . 3.8.3 Apache Maven . . . . . . . . . . . . . . . . 3.8.4 Assembla . . . . . . . . . . . . . . . . . . . 3.8.5 Hudson Continuous Integration . . . . . . . Zp˚ usob pr´ ace v t´ ymu . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

17 18 18 19 19 19 19 20 21 21 21 21 22 22 23 23 23 23 24 24 24 24 25 25 25

4 Vyuˇ zit´ı kompar´ ator˚ u na mal´ ych zaˇ r´ızen´ıch 27 4.1 Mal´ a zaˇr´ızen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2 Vyuˇzit´ı OSGi na platformˇe Android . . . . . . . . . . . . 27 4.1.3 Vyuˇzit´ı komparátor˚ u na platformˇe Android . . . . . . . . 28 4.2 Pˇredchoz´ı pr´ ace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 ´ 4.3 Ukol této pr´ ace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.1 Metodika . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4 V´ ykonnostn´ı testy . . . . . . . . . . . . . . . . . . . . . . . . . . 29 ´ cel v´ 4.4.1 Uˇ ykonnostn´ıch test˚ u . . . . . . . . . . . . . . . . . . 29 4.4.2 Vytv´ aˇren´ı v´ ykonnostn´ıch test˚ u . . . . . . . . . . . . . . . 30 4.5 Anal´ yza k´ odu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5.1 N´ astroje pouˇzité pro anal´ yzu komparátor˚ u . . . . . . . . 31 4.6 Optimalizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.6.1 Mˇeˇren´ı efektu optimalizac´ı . . . . . . . . . . . . . . . . . . 32 ´ 4.6.2 Uroveˇ n optimalizace . . . . . . . . . . . . . . . . . . . . . 33 4.7 V´ ykonnost Java aplikac´ı . . . . . . . . . . . . . . . . . . . . . . . 33 4.7.1 Doba v´ ypoˇctu . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.7.2 Spotˇreba pamˇeti . . . . . . . . . . . . . . . . . . . . . . . 34 4.7.3 Garbage kolektor . . . . . . . . . . . . . . . . . . . . . . . 35 4.8 Automatizované metody mˇeˇren´ı v´ ykonnostn´ıch parametr˚ u Java aplikac´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.8.1 Metody mˇeˇren´ı doby v´ ypoˇctu . . . . . . . . . . . . . . . . 37 4.8.2 Metody mˇeˇren´ı spotˇreby pamˇeti . . . . . . . . . . . . . . 38 4

OBSAH

OBSAH

4.8.3 Jak ovl´ adat garbage kolektor . . . . . . . . . . . . . . Implementace mˇeˇren´ı v´ ykonnostn´ıch parametr˚ u komparátoru ´ cel implementace . . . . . . . . . . . . . . . . . . . . 4.9.1 Uˇ 4.9.2 V´ ystup testovac´ı aplikace . . . . . . . . . . . . . . . . 4.9.3 Architektura . . . . . . . . . . . . . . . . . . . . . . . 4.9.4 Popis nˇekter´ ych metod d˚ uleˇzit´ ych rozhran´ı . . . . . . 4.9.5 Implementace objekt˚ u typu Tester . . . . . . . . . . . 4.9.6 Implementace objekt˚ u typu PerfTestCase . . . . . . . 4.9.7 Implementace objekt˚ u typu ResultsGatherer . . . . . 4.9.8 Implementace ˇr´ıd´ıc´ıch objekt˚ u . . . . . . . . . . . . . 4.9.9 Pomocné tˇr´ıdy a knihovny . . . . . . . . . . . . . . . . 4.9.10 Integrace do Hudsonu . . . . . . . . . . . . . . . . . . 4.9.11 Ovˇeˇren´ı pˇresnosti mˇeˇren´ı . . . . . . . . . . . . . . . . 4.10 Provedené optimalizace . . . . . . . . . . . . . . . . . . . . . 4.10.1 Oprava logov´ an´ı . . . . . . . . . . . . . . . . . . . . . 4.10.2 Optimalizace algoritmu porovnáván´ı tˇr´ıd . . . . . . . 4.10.3 Optimalizace algoritmu porovnán´ı seznamu metod . . 4.10.4 Celkov´ y efekt optimalizac´ı . . . . . . . . . . . . . . . . 4.11 Zhodnocen´ı v´ ysledk˚ u . . . . . . . . . . . . . . . . . . . . . . . 4.9

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

41 42 42 43 43 44 44 45 45 46 46 47 47 47 48 48 48 49 50

5 Vyuˇ zit´ı kompar´ ator˚ u pˇ ri anal´ yze rozd´ıl˚ u 5.1 C´ıle a pˇr´ınosy . . . . . . . . . . . . . . . . 5.1.1 Grafické zobrazen´ı rozd´ıl˚ u . . . . . 5.1.2 Dalˇs´ı moˇzné pouˇzit´ı v´ ystupu . . . 5.2 Projekt OBVS . . . . . . . . . . . . . . . 5.2.1 Architektura . . . . . . . . . . . . 5.2.2 Zp˚ usob integrace zobrazen´ı rozd´ıl˚ u 5.3 Technologie . . . . . . . . . . . . . . . . . 5.3.1 HTML . . . . . . . . . . . . . . . . 5.3.2 CSS . . . . . . . . . . . . . . . . . 5.3.3 Javascript . . . . . . . . . . . . . . 5.3.4 JQuery . . . . . . . . . . . . . . . 5.3.5 Treeview . . . . . . . . . . . . . . 5.4 Projekt prezentace rozd´ıl˚ u . . . . . . . . . 5.4.1 V´ ystupy . . . . . . . . . . . . . . . 5.4.2 Implementace . . . . . . . . . . . . 5.4.3 Moˇznosti rozˇs´ıˇren´ı . . . . . . . . . 5.5 Pˇr´ınosy a dalˇs´ı vyuˇzit´ı . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

51 51 51 51 52 52 53 54 54 54 54 55 56 56 56 58 59 61

6 Z´ avˇ er 6.1 Shrnut´ı pr´ ace . . . . . . . . . . . . . . . . 6.2 Pˇr´ınosy . . . . . . . . . . . . . . . . . . . 6.2.1 Pˇr´ınosy pro komparátor . . . . . . 6.2.2 Osobn´ı pˇr´ınosy . . . . . . . . . . . 6.3 N´ amˇety pro dalˇs´ı pr´ aci . . . . . . . . . . . 6.3.1 Optimalizace naˇc´ıtán´ı reprezentace 6.3.2 Nové n´ astroje . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

62 62 62 62 63 63 63 63

5

´ 1 Uvod 1.1

V´ ychoz´ı stav

Koncept rozdˇelen´ı aplikace na v´ıce komponent, které funguj´ı nezávisle a komunikuj´ı vz´ ajemnˇe podle dan´ ych pravidel, se v posledn´ıch desetilet´ıch velmi rozˇs´ıˇril. D˚ uvodem je pˇredevˇs´ım vyˇsˇs´ı rychlost v´ yvoje aplikace sloˇzené z komponent. Komponenty, podobnˇe jako objektovˇe orientovan´ y pˇr´ıstup, pˇrisp´ıvaj´ı k lepˇs´ı organizaci k´ odu a zapouzdˇren´ı jednotliv´ ych funkˇcnost´ı. Obzvláˇst’ pro velké aplikace je tato dalˇs´ı u ´roveˇ n ˇclenˇen´ı v´ yhodou, d´ıky které se kód stává ˇcitelnˇejˇs´ı a udrˇzovatelnˇejˇs´ı. Nejvˇetˇs´ıho urychlen´ı v´ yvoje aplikace lze dosáhnout pouˇzit´ım jiˇz hotov´ ych ˇc´ ast´ı k´ odu. Pˇri volbˇe komponentového pˇr´ıstupu lze vyuˇz´ıt hotov´ y komponentov´ y framework, kter´ y zajiˇst’uje komponentám bˇehové prostˇred´ı a poskytuje mnoho uˇziteˇcn´ ych sluˇzeb. K dispozici je také velké mnoˇzstv´ı hotov´ ych komponent, které je moˇzné do aplikace snadno zaˇclenit. Novˇe naprogramované komponenty bude moˇzné znovu pouˇz´ıt v budoucnu. V dneˇsn´ı dobˇe jsou n´ aroky na kvalitu aplikac´ı velmi vysoké, proto je ned´ılnou souˇc´ ast´ı v´ yvojového procesu testován´ı. D´ıky komponentovému pˇr´ıstupu lze testov´ an´ı v´ yraznˇe urychlit a zjednoduˇsit. Nen´ı nutné pˇri kaˇzdé zmˇenˇe testovat celou aplikaci, ale pouze upravenou komponentu. Po otestován´ı komponenty samotné je ale nutné ovˇeˇrit také jej´ı kompatibilitu s ostatn´ımi komponentami v systému. Pokud by do systému byla vloˇzena nekompatibiln´ı komponenta, hroz´ı p´ ad celé aplikace. Proto je riskantn´ı nahradit komponentu za bˇehu systému, aˇckoliv to nˇekteré komponentové frameworky umoˇzn ˇuj´ı. Na Katedˇre informatiky a v´ ypoˇcetn´ı techniky Fakulty aplikovan´ ych vˇed Západoˇceské univerzity v Plzni prob´ıhá v´ yvoj nástroj˚ u, které dokáˇzou kompatibilitu komponent automaticky ovˇeˇrit. V´ yzkum je zamˇeˇren pˇredevˇs´ım na platformu OSGi (Open Services Gateway initiative). Ovˇeˇren´ı prob´ıhá na základˇe porovn´ an´ı kompletn´ıho rozhran´ı komponenty oproti rozhran´ı vyˇzadovanému, nebo oproti rozhran´ı nahrazované komponenty. D´ıky tomu lze dosáhnout vyˇsˇs´ı spolehlivosti, neˇz jaké je dosaˇzeno testován´ım. Dalˇs´ı v´ yhodou je u ´spora ˇcasu na vytv´ aˇren´ı test˚ u. Tato metoda je také vhodná k zajiˇstˇen´ı bezpeˇcného nahrazen´ı komponenty za bˇehu systému. N´ astroje vyv´ıjené v r´ amci v´ yzkumu na katedˇre lze rozdˇelit na komparátor typ˚ u jazyka Java (JaCC - Java Class Compatibility checker) a komparátor OSGi komponent (OBCC - OSGi Bundle Compatibility Checking toolset), kter´ y je nadstavbou n´ astroje JaCC. Kromˇe v´ yvoje tˇechto dvou základn´ıch nástroj˚ u, které se pouˇz´ıvaj´ı ve formˇe knihoven, se dalˇs´ı v´ yzkumné projekty zamˇeˇruj´ı také na jejich re´ alné vyuˇzit´ı. Pˇr´ıkladem je nástroj pro automatické verzován´ı OSGi komponent nebo integrace kontroly kompatibility do frameworku Apache Felix.

1

´ Uvod

1.2

C´ıl projektu

C´ıl projektu

C´ılem projektu je rozˇs´ıˇrit moˇznosti reálného vyuˇzit´ı komparátor˚ u. K tomu byly zvoleny dva smˇery. Prvn´ım je vyuˇzit´ı komparátoru na v´ ykonovˇe omezen´ ych (napˇr. mobiln´ıch) zaˇr´ızen´ıch. Druh´ y smˇer se zamˇeˇruje na rozˇs´ıˇren´ı funkˇcnosti aplikaˇcn´ıch n´ astroj˚ u, d´ıky kterému se zv´ yˇs´ı pˇr´ınosy a rozsah moˇzného pouˇzit´ı n´ astroj˚ u pro uˇzivatele. Sloˇzitost aplikac´ı pro mal´ a (mobiln´ı) zaˇr´ızen´ı stále roste, proto se i zde dobˇre uplatˇ nuje komponentov´ y pˇr´ıstup. V´ ykonnost tˇechto zaˇr´ızen´ı je ale niˇzˇs´ı neˇz v´ ykonnost bˇeˇzn´ ych poˇc´ıtaˇc˚ u. Aplikace pro malá zaˇr´ızen´ı proto mus´ı hospodaˇrit u ´spornˇe s pamˇet´ı, které b´ yv´ a na takov´ ych zaˇr´ızen´ıch málo, a pro zajiˇstˇen´ı dostateˇcnˇe rychlé odezvy je potˇreba optimalizovat také ˇcas v´ ypoˇctu. Prvn´ım u ´kolem této pr´ ace je zmˇeˇrit v´ ykonnost komparátor˚ u, analyzovat moˇznosti optimalizac´ı a tyto optimalizace implementovat. Druh´ a ˇc´ ast pr´ ace se zab´ yvá rozˇs´ıˇren´ım nástroje pro automatické verzován´ı OSGi komponent o grafické zobrazen´ı rozd´ıl˚ u mezi p˚ uvodn´ı a novˇe verzovanou (upravenou) komponentou. V souˇcasné dobˇe nemus´ı b´ yt uˇzivateli jasné, z jakého d˚ uvodu je nutné konkrétn´ı ˇc´ ast verze zv´ yˇsit. Po implementaci rozˇs´ıˇren´ı budou d˚ uvody jasnˇe patrné a snadno dohledatelné. Uˇzivatel bude moci na prvn´ı pohled zhruba posoudit i kvantitu zmˇen. Zobrazen´ı rozd´ıl˚ u bude dále moˇzné vyuˇz´ıt i pro dalˇs´ı u ´ˇcely, napˇr´ıklad jako alternativa k nástroji SVN diff. Kromˇe grafického v´ ystupu uˇziteˇcného pro ˇclovˇeka bude rozˇs´ıˇren´ı obsahovat také strojovˇe ˇciteln´ y v´ ystup ve form´ atu XML.

1.3

Struˇ cn´ y pˇ rehled

V prvn´ı kapitole byly vysvˇetleny d˚ uvody a c´ıl práce. Druh´ a kapitola shrnuje principy komponentového pˇr´ıstupu v programován´ı a detailnˇeji se zamˇeˇruje na platformu OSGi. V závˇeru kapitoly jsou vysvˇetleny pˇr´ıˇciny nˇekter´ ych problém˚ u, které sniˇzuj´ı pˇr´ınosy komponentového pˇr´ıstupu. Tˇret´ı kapitola se zab´ yv´ a v´ yzkumem, kter´ y v´ yˇse popsané problémy ˇreˇs´ı. Konkrétnˇe jsou pops´ any projekty komparátor˚ u vyv´ıjené na Katedˇre informatiky a v´ ypoˇcetn´ı techniky Fakulty aplikovan´ ych vˇed Západoˇceské univerzity v Plzni. Struˇcnˇe pˇredstavena je také teorie nahraditelnosti komponent, ze které projekty vych´ az´ı. Ve ˇctvrté kapitole je pops´ ana metodika v´ ykonnostn´ı anal´ yzy a testován´ı Java aplikac´ı. Na z´ akladˇe této metodiky byla vytvoˇrena testovac´ı aplikace, která velmi pˇresnˇe mˇeˇr´ı d˚ uleˇzité v´ ykonnostn´ı charakteristiky Java aplikace. Metodika a testovac´ı aplikace byly vyuˇzity bˇehem optimalizac´ı komparátor˚ u, které jsou pops´ any v z´ avˇeru kapitoly. P´ at´ a kapitola popisuje rozˇs´ıˇren´ı nástroje pro automatické verzován´ı OSGi komponent o grafické zobrazen´ı rozd´ıl˚ u mezi komponentami. 2

´ Uvod

Struˇcný pˇrehled

V z´ avˇeru jsou shrnuty dosaˇzené v´ ysledky a pˇr´ınosy práce. Dále jsou uvedeny také n´ amˇety pro dalˇs´ı pr´ aci.

3

2 Komponenty 2.1 2.1.1

Koncept ´ Uvod

Jak jiˇz bylo ˇreˇceno v u ´vodu práce, pouˇzit´ı komponent pˇri v´ yvoji software pˇrin´ aˇs´ı mnoho v´ yhod. V této kapitole bude koncept komponent (Component-based software engineering, viz [11]) vysvˇetlen podrobnˇeji a budou rozebrány také jeho problémy. Komponentov´ y pˇr´ıstup je zaloˇzen na myˇslence, ˇze tvorba aplikace znamená skl´ ad´ an´ı aplikace z jednotliv´ ych nezávisl´ ych komponent, které jsou bud’ jiˇz hotové, nebo jejichˇz v´ yvoj m˚ uˇze prob´ıhat oddˇelenˇe. Ve skuteˇcnosti ale nen´ı moˇzné zajistit stoprocentn´ı nez´ avislost komponent. Komponenty mus´ı vzájemnˇe spolupracovat, ˇc´ asteˇcné nez´ avislosti se dociluje t´ım, ˇze jejich interakce jsou omezené. Komponenty mohou mezi sebou komunikovat pouze v rámci pravidel dan´ ych komponentov´ ym modelem a prostˇrednictv´ım svého rozhran´ı. Existuje mnoho komponentov´ ych model˚ u pro r˚ uzné programovac´ı jazyky. Komponentov´ y model standardizuje tvorbu komponent a d´ıky tomu je moˇzné pouˇz´ıvat komponenty r˚ uzn´ ych v´ yrobc˚ u. Pro v´ ybˇer konkrétn´ıho modelu je d˚ uleˇzité, aby byl model dostateˇcnˇe obl´ıben´ y a t´ım pádem bylo k dispozici velké mnoˇzstv´ı hotov´ ych komponent. Pouˇzit´ım hotov´ ych komponent se uspoˇr´ı velké mnoˇzstv´ı ˇcasu pˇri v´ yvoji a testován´ı software. S komponentov´ ym modelem z´ısk´ ame také kvalitn´ı z´ aklad architektury aplikace. Implementac´ı modelu je komponentov´ y framework. Pro nˇekteré modely je na v´ ybˇer i v´ıce framework˚ u (viz [20]). Program´ ator se tedy nemus´ı zab´ yvat bˇehov´ ym prostˇred´ım a ˇr´ızen´ım komponent, ale zamˇeˇr´ı se pouze na implementaci konkrétn´ı komponenty.

2.1.2

Komponenta

Kaˇzd´ a komponenta by mˇela implementovat urˇcitou ucelenou funkˇcnost. Podle konceptu potom zmˇena funkˇcnosti aplikace znamená pˇridán´ı nebo nahrazen´ı nˇekteré komponenty. Takto vytváˇrené komponenty lze také snadno nezávisle testovat, protoˇze d´ıky ucelené funkˇcnosti jsou interakce s okol´ım minimalizovány. Na obr´ azku 2.1 je zn´ azornˇen vztah komponenty, jej´ıho rozhran´ı, komponentového modelu a frameworku. Komponenta mus´ı splˇ novat poˇzadavky komponentového modelu. D´ıky tomu m˚ uˇze komponentov´ y framework komponenty ovl´ adat a zprostˇredkov´ avat jejich interakce. Tyto interakce se realizuj´ı pˇreváˇznˇe jako sluˇzby. Komponenta m˚ uˇze poskytovat sluˇzby ostatn´ım komponentám a m˚ uˇze také nˇejaké sluˇzby vyˇzadovat. Z pohledu frameworku a ostatn´ıch komponent je komponenta popsána sv´ ym

4

Komponenty

Koncept

Obr´ azek 2.1: Vztah komponenty, jej´ıho rozhran´ı, komponentového modelu a frameworku. Obr´ azek byl pˇrevzat z [11]

rozhran´ım a pˇr´ıpadnˇe mimofunkˇcn´ımi charakteristikami. Komponenty, které ji vyuˇz´ıvaj´ı, teoreticky neznaj´ı implementaˇcn´ı detaily a nesm´ı se na nˇe spoléhat. D´ıky tomu je komponenta nahraditelná. Ostatn´ı komponenty jsou závislé pouze na jej´ım rozhran´ı. Komponenta m˚ uˇze implementovat v´ıce r˚ uzn´ ych rozhran´ı. Pro svou funkˇcnost obvykle potˇrebuje sluˇzby jiné komponenty, která implementuje potˇrebné rozhran´ı. Propojen´ı komponent prob´ıhá pouze na základˇe poˇzadovaného rozhran´ı, klientsk´ a komponenta by nemˇela spoléhat na propojen´ı s nˇejakou konkrétn´ı komponentou. ˇ ım lépe jsou splnˇeny popsané principy komponentového pˇr´ıstupu, t´ım v´ıce C´ jsou vytvoˇrené komponenty znovupouˇzitelné.

2.1.3

Komponentov´ y model

Komponentov´ y model definuje typy komponent a moˇznosti jejich vzájemn´ ych interakc´ı a interakc´ı s frameworkem. Specifikace modelu obsahuje také zp˚ usob z´ apisu rozhran´ı. To m˚ uˇze b´ yt popsáno pomoc´ı programovac´ıho jazyka, speciáln´ıho jazyka pro definici rozhran´ı (IDL – Interface Definition Language) nebo v jiném form´ atu (napˇr. manifest v OSGi). Model urˇcuje, co je to komponenta a jak má b´ yt pˇripravena ke spuˇstˇen´ı ve frameworku. Komponentou m˚ uˇze b´ yt tˇr´ıda, objekt, bal´ık nebo jiná ˇcást kódu aplikace. Popis podoby komponenty mus´ı b´ yt dostateˇcnˇe pˇresn´ y, aby byl framework schopen komponentu spustit a dále s n´ı pracovat. Pro vz´ ajemnou interakci mezi komponentami definuje model zp˚ usob, jak komponenta m˚ uˇze nab´ıdnout sluˇzby ostatn´ım komponentám a naopak jak m˚ uˇze z´ıskat sluˇzby od ostatn´ıch komponent. Pro interakci komponenty s frameworkem model specifikuje zp˚ usob spuˇstˇen´ı a následného ˇr´ızen´ı komponenty frameworkem a zp˚ usob vol´ an´ı sluˇzeb frameworku komponentou. 5

Komponenty

2.1.4

Technologie OSGi

Komponentov´ y framework

Komponentov´ y framework je bˇehové prostˇred´ı pro komponenty. Obvykle pˇredstavuje kostru aplikace a iniciuje jejich spuˇstˇen´ı po svém startu. Framework implementuje konkrétn´ı komponentov´ y model a vyˇzaduje splnˇen´ı modelu jednotliv´ ymi komponentami. Pokud by komponenta nesplˇ novala model, framework by s n´ı neumˇel pracovat. Pro komponenty je framework nˇeco jako operaˇcn´ı systém pro aplikace. Podobnˇe jako operaˇcn´ı systém, framework spouˇst´ı nˇekteré komponenty hned po svém startu, jiné na pˇr´ıkaz uˇzivatele. Framework ˇr´ıd´ı ˇzivotn´ı cyklus komponent, poskytuje mechanismus pro jejich interakce a spravuje sd´ılené zdroje. Komponenty mohou volat sluˇzby frameworku, podobnˇe jako aplikace volaj´ı sluˇzby operaˇcn´ıho systému.

2.1.5

Probl´ emy

Existence mnoha komponentov´ ych model˚ u omezuje znovupouˇzitelnost hotov´ ych komponent. Komponentu lze pouˇz´ıt pouze v aplikaci zaloˇzené na stejném modelu, pro jak´ y byla vytvoˇrena. Rozdrobenost komponent mezi jednotlivé modely ztˇeˇzuje hled´ an´ı vhodné komponenty. Dalˇs´ım problémem je riziko nekompatibility po nahrazen´ı komponenty. Nekompatibilita m˚ uˇze vést k neoˇcekávané funkˇcnosti nebo aˇz k pádu aplikace. Aby se pˇredeˇslo problém˚ um, je nutné po nahrazen´ı komponenty celou aplikaci testovat pomoc´ı integraˇcn´ıch test˚ u. Pokud maj´ı b´ yt tyto testy spolehlivé, zabere jejich vytvoˇren´ı pˇr´ıliˇs mnoho ˇcasu a u ´spora ˇcasu d´ıky komponentovému pˇr´ıstupu se sniˇzuje. Nˇekteré modely se problém snaˇz´ı ˇreˇsit pomoc´ı systému verz´ı. Napˇr´ıklad v modelech DCE, CORBA a OSGi je pouˇzito sémantické verzován´ı ve formátu: major.minor.micro. Tento systém je ale nespolehliv´ y, protoˇze správné urˇcen´ı poskytované i vyˇzadované verze je ponecháno na programátorovi. Z tˇechto d˚ uvod˚ u je nahrazen´ı komponenty bez následn´ ych test˚ u nebo do konce za bˇehu systému riskantn´ı.

2.2 2.2.1

Technologie OSGi OSGi specifikace

Technologie OSGi (Open Service Gateway initiative) je komponentov´ y model pro jazyk Java. O jej´ı v´ yvoj a propagaci se stará skupina s názvem OSGi Alliance [9], kter´ a vznikla v roce 1999. Skupina poskytuje nejen specifikaci modelu, ale také referenˇcn´ı implementaci. J´ adrem OSGi specifikace je OSGi framework. Jeho ˇcásti jsou zobrazeny na 6

Komponenty

Technologie OSGi

obr´ azku 2.2.

Obr´ azek 2.2: Schéma OSGi frameworku. Obrázek byl pˇrevzat z [9]

• Execution environment: specifikace bˇehového prostˇred´ı. OSGi lze pouˇz´ıt na libovolné konfiguraci Java 2. • Modules: specifikace naˇc´ıtán´ı tˇr´ıd (class loading). Pˇri bˇeˇzném naˇc´ıt´ an´ı tˇr´ıd v Javˇe existuje pouze jedin´ y prostor tˇr´ıd (classpath). V OSGi m´ a kaˇzd´ a komponenta sv˚ uj vlastn´ı prostor tˇr´ıd. D´ıky tomu je napˇr´ıklad moˇzné spustit v jedné aplikaci najednou dvˇe tˇr´ıdy se shodn´ ym n´ azvem. Oddˇelen´ım prostor˚ u tˇr´ıd se zajiˇst’uje také izolovanost komponent a jejich bezpeˇcnost. • Life Cycle: specifikace ˇzivotn´ıho cyklu komponent. Komponenty v OSGi lze za bˇehu systému instalovat, spustit, zastavit, obnovit a odinstalovat. Pomoc´ı API frameworku m˚ uˇze tyto operace provádˇet nˇekter´ a z komponent. • Service Registry: specifikace interakc´ı komponent pomoc´ı sluˇzeb. Komponenty mohou do systému registrovat nab´ızené sluˇzby, po ˇcase je mohou opˇet odregistrovat. V registru sluˇzeb mohou také vyhledávat sluˇzby ostatn´ıch komponent. V OSGi je sluˇzba reprezentována Java tˇr´ıdou.

2.2.2

OSGi komponenta

Komponenta se v terminologii OSGi naz´ yvá bundle (viz [40]). Je to obyˇcejn´ y Java archiv (JAR), kter´ y mus´ı nav´ıc obsahovat manifest s popisem komponenty ve formˇe nˇekolika speci´ aln´ıch hlaviˇcek. Manifest komponenty je um´ıstˇen v JAR archivu na obvyklé cestˇe: META-INF/MANIFEST.MF. Obsah souboru se skl´ ad´ a z jednotliv´ ych ˇr´ adek ve formátu kl´ıˇc: hodnota“. V následuj´ıc´ım seznamu ” uv´ ad´ım nˇekteré typické hlaviˇcky OSGi manifestu: • Bundle-SymbolicName Tato hlaviˇcka je povinn´ a a udává název komponenty, kter´ y se pouˇz´ıvá jako identifik´ ator komponenty ve frameworku. Jako hodnota se obvykle pouˇz´ıv´ a reverzn´ı doménová notace, jako pro Java bal´ıky.

7

Komponenty

Technologie OSGi

• Bundle-Version Tato hlaviˇcka oznaˇcuje verzi komponenty. Pokud nen´ı specifikována, pouˇzije se defaultn´ı hodnota 0.0.0 . • Bundle-Activator Plnˇe kvalifikované jméno tˇr´ıdy, která implementuje rozhran´ı BundleActivator. Aktiv´ ator komponenty je volán frameworkem pˇri startu a zastaven´ı komponenty. Jeho implementace nen´ı povinná. • Export-Package Seznam exportovan´ ych bal´ık˚ u. Tyto bal´ıky jsou viditelné pro ostatn´ı komponenty, které si bal´ıky importuj´ı. Jména bal´ık˚ u se oddˇeluj´ı ˇcárkou a za jménem lze uvést i verzi bal´ıku. Ta se uvád´ı za stˇredn´ık ve formátu version=verze“. ” • Import-Package Seznam importovan´ ych bal´ık˚ u. Tyto bal´ıky komponenta potˇrebuje pro sv˚ uj bˇeh. Framework se pokus´ı bal´ıky importovat z jin´ ych komponent. Pokud se to nepovede, komponenta nem˚ uˇze b´ yt spuˇstˇena. Formát zápisu je stejn´ y jako pro hlaviˇcku Export-Package, ale kromˇe urˇcité verze bal´ıku lze uvést i pˇr´ıpustn´ y rozsah verz´ı (v´ıce v [40]). • Require-Bundle Tuto hlaviˇcku lze pouˇz´ıt k importu vˇsech exportovan´ ych bal´ık˚ u konkrétn´ı komponenty. Z´ aroveˇ n se vytváˇr´ı závislost na této konkrétn´ı komponentˇe (z´ avislost na implementaci). Jej´ı pouˇz´ıván´ı nen´ı doporuˇceno, protoˇze se t´ım poruˇsuj´ı z´ akladn´ı principy komponentového pˇr´ıstupu. Pˇr´ıklad jednoduchého manifestu: Bundle - Name : Example bundle Bundle - SymbolicName : cz . zcu . kiv . obcc . exampleBundle Bundle - Version : 1.0.0. R123 Bundle - Activator : cz . zcu . kiv . obcc . exampleBundle . Activator Export - Package : cz . zcu . kiv . obcc . exampleBundle Import - Package : cz . zcu . kiv . obcc , org . slf4j . impl ;\ version ="[1.3.1 , 1.4.0)" Bundle - R e q u ir e d Ex e c ut i o nE n v i ro n m en t : JavaSE -1.6

Z uvedeného manifestu lze vyˇc´ıst, ˇze název komponenty ˇciteln´ y pro ˇclovˇeka je Example bundle“, ve frameworku je bundle identifikován názvem ” cz.zcu.kiv.obcc.exampleBundle“ a verz´ı 1.0.0.R123“. Komponenta obsahuje ” ” aktiv´ ator a exportuje bal´ık cz.zcu.kiv.obcc.exampleBundle“. Ke svému fungo” v´ an´ı vyˇzaduje bal´ık cz.zcu.kiv.obcc“ v libovolné verzi a bal´ık org.slf4j.impl“ ” ” ve verzi vˇetˇs´ı nebo rovné 1.3.1 a menˇs´ı neˇz 1.4.0. Komponenta m˚ uˇze bˇeˇzet pouze v prostˇred´ı JavaSE-1.6.

2.2.3

OSGi framework

Pro technologii OSGi existuje mnoho r˚ uzn´ ych implementac´ı komponentového frameworku. Nˇekteré z nich splˇ nuj´ı OSGi specifikaci kompletnˇe, jiné pouze z 8

Komponenty

Technologie OSGi

ˇc´ asti. Pˇr´ıklady OSGi framework˚ u: • Apache Felix [10] Open Source projekt, kter´ y se snaˇz´ı implementovat OSGi specifikaci verze 4. Nˇekteré ˇc´ asti specifikace jeˇstˇe implementované nejsou. • Eclipse Equinox [22] Také Open Source projekt, kter´ y je integrovan´ y s v´ yvojov´ ym prostˇred´ım Eclipse. Splˇ nuje vˇsechny poˇzadavky OSGi specifikace verze 4 a vlastn´ı certifik´ at OSGi Alliance. Framework je typicky moˇzné ovládat pomoc´ı konzole (Felix, Equinox), nˇekteré frameworky poskytuj´ı i grafické rozhran´ı (Knopflerfish [41]).

2.2.4

ˇ Zivotn´ ı cyklus OSGi komponenty

Po startu aplikace se nejprve rozbˇehne framework, kter´ y následnˇe spust´ı jednotlivé komponenty. Proces spouˇstˇen´ı komponent nen´ı triviáln´ı, komponenta ˇ proch´ az´ı postupnˇe f´ azemi installed, resolved, starting a active. Zivotn´ ı cyklus OSGi komponenty zobrazuje obrázek 2.3.

ˇ Obr´ azek 2.3: Zivotn´ ı cyklus OSGi komponenty. Obrázek byl pˇrevzat z Wikipedie. Ve f´ azi installed je komponenta naˇctena ve frameworku z disku. Jeˇstˇe ale nem˚ uˇze pracovat, protoˇze nemá k dispozici poˇzadované zdroje, definované napˇr´ıklad pomoc´ı hlaviˇcky manifestu Require-Package. Framework mus´ı následnˇe provést resolving, coˇz je zjednoduˇsenˇe ˇreˇceno proces provázán´ı import˚ u a export˚ u. Pokud probˇehne resolving u ´spˇeˇsnˇe, dostane se komponenta do fáze resolved. Nyn´ı jiˇz m´ a k dispozici vˇse, co potˇrebuje pro svou ˇcinnost. Framework ji m˚ uˇze zaˇc´ıt spouˇstˇet. T´ım se komponenta dostává do fáze starting, ve které je

9

Komponenty

Sémantické verzov´ an´ı a resolving v OSGi

spuˇstˇena startovac´ı metoda jej´ıho aktivátoru (viz kapitola 2.2.5). Plnˇe spuˇstˇená komponenta se dostane do f´ aze active. Komponenta m˚ uˇze b´ yt také zastavena nebo dokonce odinstalována frameworkem nebo jinou komponentou. Bˇehem fáze stopping je zavolána ukonˇcovac´ı metoda aktiv´ atoru a komponenta pˇrejde zpˇet do fáze resolved. Odtud lze komponentu odinstalovat ze systému (uninstalled).

2.2.5

Aktiv´ ator OSGi komponenty

OSGi komponenta m˚ uˇze obsahovat aktivátor, coˇz je tˇr´ıda implementuj´ıc´ı rozhran´ı org.osgi.framework.BundleActivator. Toto rozhran´ı naˇrizuje implementaci metod start a stop, které jsou zavolány frameworkem pˇri startu a zastavován´ı komponenty. Parametrem metod je objekt tˇr´ıdy org.osgi.framework.BundleContext, kter´ y umoˇzn ˇuje interakci komponenty s frameworkem. Plnˇe kvalifikovan´ y n´ azev tˇr´ıdy aktivátoru mus´ı b´ yt zapsána v manifestu v hlaviˇcce Bundle-Activator.

2.2.6

Interakce mezi OSGi komponentami

Komponenty mohou spolupracovat pomoc´ı sd´ılen´ı Java bal´ık˚ u, které je realizov´ ano zejména pomoc´ı hlaviˇcek manifestu Import-Package a Export-Package. Tˇr´ıdy z importovan´ ych bal´ık˚ u m˚ uˇze komponenta libovolnˇe pouˇz´ıvat. Volnˇejˇs´ı zp˚ usob spolupr´ ace je realizován pomoc´ı sluˇzeb. Komponenta m˚ uˇze nab´ızet r˚ uzné sluˇzby ostatn´ım komponentám. Tyto sluˇzby jsou pˇredstavovány Java objektem a do frameworku jsou registrovány obvykle pod sv´ ym rozhran´ım, pˇr´ıpadnˇe i tˇr´ıdou. Ostatn´ı komponenty m˚ uˇzou sluˇzbu pomoc´ı tohoto rozhran´ı vyhledat. Registrace a z´ısk´ an´ı sluˇzeb m˚ uˇze prob´ıhat bud’ programovˇe, napˇr´ıklad v metodˇe start aktiv´ atoru komponenty, nebo pomoc´ı XML. Doporuˇcen´ ym zp˚ usobem je deklarace sluˇzeb v XML. Komponenta m˚ uˇze také reagovat na události registrace a deregistrace urˇcité sluˇzby. D´ıky tomu, ˇze je sluˇzba reprezentována objektem Java tˇr´ıdy, nezp˚ usobuje jej´ı vyuˇz´ıv´ an´ı témˇeˇr ˇz´ adné reˇzijn´ı náklady.

2.3 2.3.1

S´ emantick´ e verzov´ an´ı a resolving v OSGi Resolving

Resolving je proces p´ arov´ an´ı zdroj˚ u poˇzadovan´ ych a poskytovan´ ych jednotliv´ ymi komponentami v systému. Je potˇreba ho provést pˇred spuˇstˇen´ım komponent, aby komponenty mˇeli k dispozici veˇskeré zdroje, které potˇrebuj´ı pro svou

10

Komponenty


ˇcinnost. Resolving je u ´kolem frameworku, kter´ y vyhledává pro kaˇzd´ y poˇzadavek nˇejak´ y vyhovuj´ıc´ı zdroj podle dan´ ych pravidel. V OSGi se typicky prov´ ad´ı provázán´ı importovan´ ych a exportovan´ ych bal´ık˚ u. Poˇzadovan´ y bal´ık je vyhledáván podle názvu a verze, pokud je uvedena, pˇr´ıpadnˇe podle dalˇs´ıch atribut˚ u. Pˇri uveden´ı konkrétn´ıho ˇc´ısla verze vyhovuje bal´ık s touto verz´ı nebo vyˇsˇs´ı. Verzi lze omezit také na urˇcit´ y rozsah.

2.3.2

S´ emantick´ e verzov´ an´ı

Pravidla pro verzov´ an´ı OSGi komponent [8] jsou dána specifikac´ı. Verzován´ı se naz´ yv´ a sémantické, protoˇze verze obsahuje nˇekolik sloˇzek s dan´ ym v´ yznamem a d˚ uleˇzitost´ı. Jej´ı form´ at je: major.minor.micro.qualifier“. Prvn´ı tˇri sloˇzky jsou ” ˇc´ısla, posledn´ı sloˇzka m˚ uˇze obsahovat i p´ısmena. D˚ uleˇzitost sloˇzek klesá zleva doprava a libovoln´ y poˇcet sloˇzek zprava lze vynechat. V´ yznam jednotliv´ ych sloˇzek je n´ asleduj´ıc´ı: • major: sloˇzka s nejvyˇsˇs´ı d˚ uleˇzitost´ı. Jej´ı nav´ yˇsen´ı se provád´ı vˇzdy, kdyˇz dojde k poruˇsen´ı zpˇetné kompatibility (napˇr´ıklad smazán´ım nebo zmˇenou metody, kter´ a je souˇc´ ast´ı API). Bal´ıky s r˚ uznou verz´ı ve sloˇzce major jsou zcela nekompatibiln´ı. • minor: sloˇzka se stˇredn´ı d˚ uleˇzitost´ı. Navyˇsuje se pˇri zmˇenách API, které jsou zpˇetnˇe kompatibiln´ı (napˇr´ıklad pˇridán´ı nové metody do API). Vyˇzadovan´ y bal´ık je kompatibiln´ı s poskytovan´ ym bal´ıkem, pokud je major sloˇzka verze stejn´ a a minor sloˇzka poskytovaného bal´ıku vyˇsˇs´ı nebo rovna vyˇzadovanému. • micro: sloˇzka s nejniˇzˇs´ı d˚ uleˇzitost´ı. Jej´ı nav´ yˇsen´ı prob´ıhá pˇri kaˇzdém vyd´ an´ı komponenty, kdy nebylo zmˇenˇeno API, ale pouze vnitˇrn´ı implementace. Bal´ıky s verzemi liˇs´ıc´ımi se aˇz ve sloˇzce micro by mˇely b´ yt kompatibiln´ı. • qualifier: sloˇzka, kter´ a se nepouˇz´ıvá k porovnán´ı verz´ı, ale pouze k dalˇs´ımu upˇresnˇen´ı verze, napˇr´ıklad ˇc´ıslem SVN revize. Na kompatibilitu bal´ık˚ u by nemˇela m´ıt ˇz´ adn´ y vliv. Pokud dojde k nav´ yˇsen´ı nˇekteré sloˇzky, vˇsechny ménˇe d˚ uleˇzité sloˇzky kromˇe sloˇzky qualifier se vynuluj´ı.

2.3.3

Probl´ emy resolvingu a s´ emantick´ eho verzov´ an´ı

Framework vyb´ır´ a bal´ıky k provázán´ı zejména podle názvu a verze. Tyto informace uv´ ad´ı program´ ator v manifestu importuj´ıc´ı a exportuj´ıc´ı komponenty. Je tedy zodpovˇednost´ı programátora, aby urˇcil verze správnˇe. Problémem je, ˇze program´ ator obvykle mˇen´ı verze pouze na základˇe pocit˚ u a domnˇenek, nemus´ı si uvˇedomit dopad nˇekter´ ych zmˇen kódu na pˇr´ıpadnou zmˇenu v API. 11

Komponenty


D˚ usledkem jsou ˇcasté chyby sémantick´ ych verz´ı komponent a bal´ık˚ u. Tyto chyby mohou zp˚ usobit nekompatibilitu komponent, které byly propojeny pˇri resolvingu. To m˚ uˇze vést k neoˇcekávané funkˇcnosti nebo aˇz k pádu celé aplikace.

2.3.4

Dalˇ s´ı probl´ emy resolvingu

Framework mus´ı nˇekdy ˇreˇsit sloˇzité situace, které maj´ı v´ıce moˇzn´ ych ˇreˇsen´ı. Program´ ator si nemus´ı vˇzdy uvˇedomit, jaké problémy mohou tyto situace zp˚ usobit. Kaˇzd´ y framework m˚ uˇze nav´ıc tyto situace ˇreˇsit r˚ uznˇe. Jedná se napˇr´ıklad o pˇr´ıpad, kdy pro uspokojen´ı importu je k dispozici v´ıce komponent s odpov´ıdaj´ıc´ım exportem. Jiné problémy mohou nastat, pokud je implementace bal´ıku rozdˇelena mezi v´ıce komponent. Dalˇs´ı nepˇr´ıjemné efekty mohou vznikat po aktualizaci nebo odinstalován´ı komponenty v bˇeˇz´ıc´ım frameworku. Pokud byly ostatn´ı komponenty na aktualizovanou komponentu nav´ azány, tyto vazby se nepˇreruˇs´ı okamˇzitˇe. Ve frameworku m˚ uˇze proto nˇejakou dobu existovat stará i nová verze komponenty z´ aroveˇ n. Staré vazby budou vyuˇz´ıvat starou implementaci, novˇe vzniklé vazby budou pouˇz´ıvat novou implementaci. To m˚ uˇze zp˚ usobit problémy kompatibility. Dalˇs´ım d˚ usledkem je, ˇze aktualizace komponenty se neprojev´ı ihned zmˇenou funkˇcnosti. Aktualizace nebo rozpojen´ı star´ ych vazeb se provede aˇz po aktualizaci celého frameworku.

12

3 Nahraditelnost komponent 3.1

Pouˇ zit´ı

Nahrazovat komponentu v komponentové aplikaci je potˇreba z r˚ uzn´ ych d˚ uvod˚ u. ˇ Casto se napˇr´ıklad komponenta nahrazuje za u ´ˇcelem jej´ı aktualizace na novˇejˇs´ı verzi, nebo lze nahrazen´ım upravit funkˇcnost aplikace. V nˇekter´ ych pˇr´ıpadech m˚ uˇze b´ yt ˇzádouc´ı nahradit komponentu bez pˇreruˇsen´ı bˇehu aplikace. Takov´ y pˇr´ıpad je serverová aplikace, která mus´ı fungovat nepˇretrˇzitˇe. Aktualizace takové aplikace za bˇehu pˇrispˇeje k dodrˇzen´ı limit˚ u na odst´ avky. Je ovˇsem potˇreba, aby bylo nahrazen´ı bezpeˇcné, tj. aby v systému nevznikla nekompatibilita a nedoˇslo k pádu aplikace. Ovˇeˇren´ı, ˇze nahrazen´ı komponenty za jinou nezp˚ usob´ı problémy nebo dokonce p´ ad aplikace, se naz´ yv´ a nahraditelnost komponent. Komponenta je nahraditeln´ a za jinou komponentu, pokud je nová komponenta kompatibiln´ı s ostatn´ımi komponentami v systému.

3.2

V´ ysledky a smˇ er v´ yzkumu na katedˇ re

Nahraditelnost´ı komponent se na Katedˇre informatiky a v´ ypoˇcetn´ı techniky Fakulty aplikovan´ ych vˇed Z´ apadoˇceské univerzity v Plzni zab´ yvá t´ ym pod vedeˇ n´ım Ing. MSc. Pˇremysla Brady, Ph.D. Práce prob´ıhaj´ı v rámci projekt˚ u GACR (Methods and models for consistency verification of advanced component-based applications, Methods of development and verification of component-based applications using natural language specifications). V r´ amci v´ yzkumu byl vytvoˇren komparátor typ˚ u jazyka Java (JaCC - Java Class Compatibility checker) a komparátor OSGi komponent (OBCC - OSGi Bundle Compatibility Checking toolset), kter´ y je nadstavbou nástroje JaCC. Komponenty jsou porovn´ av´ any do hloubky aˇz na u ´roveˇ n metod a ˇclensk´ ych pol´ı Java tˇr´ıd.

3.2.1

Pouˇ zit´ı kompar´ atoru pˇ ri resolvingu

Kompar´ ator lze vyuˇz´ıt pˇri resolvingu v komponentovém frameworku. Komparátor ovˇeˇr´ı kompatibilitu komponent, mezi kter´ ymi se má vytvoˇrit vazba. Pokud jsou tyto komponenty nekompatibiln´ı, provázán´ı se v˚ ubec neprovede a aplikaci nebude moˇzné spustit. T´ım se chyba odhal´ı okamˇzitˇe a pˇredejde se neoˇcekávan´ ym problém˚ um za bˇehu aplikace. Dalˇs´ı v´ yhodou je moˇznost pouˇzit´ı komparátoru pˇri v´ ybˇeru vhodné exportuj´ıc´ı komponenty, pokud z´ akladn´ı poˇzadavky (jméno, verze, dalˇs´ı atributy) spl13

Nahraditelnost komponent

Výsledky a smˇer výzkumu na katedˇre

n ˇuje komponent v´ıce. V´ ybˇer je pomoc´ı komparátoru omezen pouze na kompatibiln´ı komponenty. Kompar´ ator byl jiˇz zkuˇsebnˇe integrován do frameworku Apache Felix v rámci projektu Felix resolver integration (viz [18]). Dalˇs´ım námˇetem je rozˇs´ıˇren´ı frameworku o zobrazen´ı d˚ uvod˚ u, proˇc nelze komponenty provázat a spustit. Pro tento u ´ˇcel bude moˇzné pouˇz´ıt grafické zobrazen´ı rozd´ıl˚ u mezi komponentami, které je souˇc´ ast´ı této pr´ ace (kapitola 5).

3.2.2

Podpora pro bezpeˇ cnou nahraditelnost komponent

Dalˇs´ı moˇznost´ı vyuˇzit´ı komparátoru je kontrola kompatibility komponent jeˇstˇe pˇred jejich zaveden´ım do frameworku. Souˇcást´ı komponentové aplikace m˚ uˇze b´ yt komponenta, kter´ a umoˇzn ˇuje rozˇsiˇrován´ı a aktualizaci aplikace za bˇehu. Tato komponenta m˚ uˇze fungovat bud’ automaticky, nebo m˚ uˇze b´ yt ovládána uˇzivatelem. Pˇred nasazen´ım vybrané komponenty do frameworku lze vyuˇz´ıt komparátor ke kontrole kompatibility s ostatn´ımi komponentami ve frameworku. Kompatibilitu je moˇzné kontrolovat dokonce jeˇstˇe pˇred staˇzen´ım vybrané komponenty z internetu. K tomuto u ´ˇcelu je pˇripravováno u ´loˇziˇstˇe komponent, které pomoc´ı kompar´ atoru vytváˇr´ı a ukládá informace o kompatibilitˇe jednotliv´ ych komponent (viz [32]).

3.2.3

Podpora pro spr´ avn´ e s´ emantick´ e verzov´ an´ı

Dalˇs´ım smˇerem pro pouˇzit´ı komparátoru je zajiˇstˇen´ı správného sémantického verzov´ an´ı jednotliv´ ych komponent pˇri jejich vydán´ı. Komponentov´ y framework n´ aslednˇe spoléh´ a standardnˇe jen na ˇc´ısla verz´ı. Pokud by byly správnˇe verzovány vˇsechny komponenty v systému, problémy s kompatibilitou by nemˇely nastat. Aby se pˇredeˇslo chyb´ am, lze ponechat urˇcen´ı verze nástroji pro automatické verzov´ an´ı. Webov´ y n´ astroj pro automatické verzován´ı je k dispozici na adrese http:// osgi.kiv.zcu.cz/ obvs/ index.html . Uˇzivatel do formuláˇre zadá dva soubory, komponentu v p˚ uvodn´ı verzi a upravenou komponentu k overzován´ı. N´ astroj pouˇzije kompar´ ator k porovnán´ı komponent a podle v´ ysledku urˇc´ı verzi podle sémantick´ ych pravidel pro novou komponentu. N´ astroj pro automatické verzován´ı lze pouˇz´ıvat také jako plugin do mavenu (viz [35]). Kromˇe automatického verzován´ı lze podpoˇrit volbu správné verze také pomoc´ı grafického zobrazen´ı rozd´ıl˚ u mezi p˚ uvodn´ı a upravenou komponentou, kter´ ym se zab´ yv´ a kapitola 5 této práce. Grafická podoba rozd´ıl˚ u pom˚ uˇze ˇclovˇeku ke spr´ avnému urˇcen´ı verze nové komponenty.

14


3.2.4

Teorie nahraditelnosti komponent

Dalˇ s´ı n´ amˇ ety pro pouˇ zit´ı kompar´ atoru

Kompar´ ator by bylo moˇzné d´ ale vyuˇz´ıt k vyhledáván´ı vyhovuj´ıc´ı komponenty na internetu nebo v konkrétn´ım u ´loˇziˇsti. Podobné ˇreˇsen´ı je prezentováno v [42]. Pomoc´ı dotazovac´ı komponenty je vyhledávána jiná komponenta, která je s dotazovac´ı komponentou kompatibiln´ı (nebo témˇeˇr kompatibiln´ı). V souˇcasné dobˇe by bylo moˇzné komparátor vyuˇz´ıt pouze k vyhledán´ı zcela kompatibiln´ıch komponent. N´ amˇetem do budoucna je rozˇs´ıˇren´ı v´ ysledku porovn´ an´ı komponent o kvantifikaci rozd´ıl˚ u. D´ıky tomu by bylo moˇzné vyhledané komponenty ˇradit podle m´ıry nekompatibility.

3.3

Teorie nahraditelnosti komponent

Aby bylo moˇzné urˇcit, zda je komponenta nahraditelná za jinou komponentu, je potˇreba definovat poˇzadavky nahraditelnosti. Obecnˇe lze ˇr´ıci, ˇze komponenta je nahraditeln´ a za jinou, pokud toto nahrazen´ı nezp˚ usob´ı nekompatibilitu. Zp˚ usob˚ u, jak´ ymi to lze ovˇeˇrit, je v´ıce. Komparátory vyvinuté na katedˇre ovˇeˇruj´ı nahraditelnost bez nutnosti spuˇstˇen´ı a testován´ı komponent. Následuj´ıc´ı text popisuje postupy ovˇeˇrov´ an´ı nahraditelnosti implementované v komparátorech JaCC a OBCC.

3.3.1

Relace subtypu mezi komponentami

Komponentu lze reprezentovat pomoc´ı element˚ u jej´ıho rozhran´ı. Ty lze rozdˇelit na elementy importované a exportované. Rozhran´ı OSGi komponenty je tvoˇreno informacemi obsaˇzen´ ymi v manifestu, popisech sluˇzeb ve formátu XML a Java tˇr´ıdami, které jsou dosaˇzitelné pro ostatn´ı komponenty prostˇrednictv´ım exportovan´ ych bal´ık˚ u. Jednotlivé tˇr´ıdy je potˇreba reprezentovat aˇz na u ´roveˇ n signatur jejich pol´ı a metod. Kdyˇz m´ ame k dispozici reprezentace dvou komponent, m˚ uˇzeme tyto repre´ celem porovnán´ı je zjistit vzájemn´ zentace mezi sebou porovn´ avat. Uˇ y vztah komponent. Ty mohou b´ yt bud’ zcela nekompatibiln´ı, nebo m˚ uˇze b´ yt nˇekterá komponenta subtypem (viz [16]) druhé komponenty. Relaci subtypu si lze pˇredstavit jako relaci pˇredek – potomek v dˇediˇcnosti Java tˇr´ıd, kde potomek je subtypem (nebo specializac´ı) svého pˇredka. Podobnˇe jako princip polymorfismu, kde lze nahradit objekt typovan´ y na pˇredka libovoln´ ym potomkem, lze komponentu A nahradit komponentou B, pokud je komponenta B subtypem komponenty A.

15


3.3.2

Kompar´ atory Java tˇr´ıd a OSGi komponent

Jak lze relaci subtypu zjistit

Zjiˇstˇen´ı relace subtypu mezi komponentami je obt´ıˇzné, proto je nutné rozdˇelit komponentu na menˇs´ı ˇc´ asti, u kter´ ych se zjiˇstˇen´ı této relace zjednoduˇsuje. Komponenty m˚ uˇzeme rozloˇzit na dostateˇcnˇe jednoduché ˇcásti, aby bylo urˇcen´ı relace trivi´ aln´ı (primitivn´ı Java typy, metody. . . ). Relaci subtypu snadno urˇc´ıme u vˇsech tˇechto ˇc´ ast´ı. Celkov´ y v´ ysledek potom postupnˇe skládáme z v´ ysledk˚ u d´ılˇc´ıch.

3.3.3

Metody ovˇ eˇ ren´ı nahraditelnosti

Nahraditelnost komponenty A komponentou B lze ovˇeˇrit pomoc´ı zjiˇstˇen´ı relace subtypu mezi komponentami A a B. Pokud je komponenta B subtypem komponenty A, lze komponentu A komponentou B nahradit. Tato z´ akladn´ı metoda je pouˇzitelná bez znalosti dodateˇcn´ ych informac´ı o prostˇred´ı (kontextu) komponenty, ve kterém má b´ yt nasazena. Pokud tyto informace m´ ame k dispozici, lze je pouˇz´ıt k lepˇs´ımu rozhodnut´ı o nahraditelnosti komponenty za tˇechto konkrétn´ıch podm´ınek. Tato druh´ a metoda se naz´ yvá kontextová nahraditelnost [15]. M´ısto toho, aby se novˇe pˇrid´ avan´ a komponenta porovnávala s p˚ uvodn´ı komponentou, porovn´ av´ a se novˇe pˇrid´ avan´ a komponenta se sv´ ym komplementem z´ıskan´ ym z kontextu. Kontextem jsou myˇsleny ostatn´ı komponenty ve frameworku. Z pohledu nahraditelnosti jsou z kontextu zaj´ımavé pouze komponenty s nˇejakou vazbou na p˚ uvodn´ı komponentu, nebo s potenciáln´ı vazbou na novou komponentu. Komplement komponenty je ˇcást komponenty, která je skuteˇcnˇe vyuˇz´ıvána kontextem. Komplement je proto ne´ uplná reprezentace komponenty. Protoˇze se komplement z´ısk´ av´ a z kontextu, nen´ı nahraditelnost závislá na p˚ uvodn´ı nahrazované komponentˇe. Ta dokonce nemus´ı v˚ ubec existovat a kontextovou nahraditelnost lze vyuˇz´ıt ˇcistˇe pro u ´ˇcely zjiˇstˇen´ı kompatibility exportuj´ıc´ı a importuj´ıc´ı komponenty. Pokud je komponenta subtypem svého komplementu z´ıskaného z kontextu, je s kontextem kompatibiln´ı (p˚ uvodn´ı komponenta je nahraditelná touto komponentou v tomto konkrétn´ım kontextu).

3.4

Kompar´ atory Java tˇ r´ıd a OSGi komponent

V této kapitole budou podrobnˇeji popsány jednotlivé projekty komparátor˚ u i dalˇs´ıch n´ astroj˚ u, které je vyuˇz´ıvaj´ı. Projekty pˇredstavuj´ı v´ ychoz´ı stav pro tuto pr´ aci. Bˇehem pr´ ace jsem se ale také zapojila do v´ yvoje projekt˚ u. Implementovala jsem nˇekter´ a vylepˇsen´ı a opravy chyb.

16


3.4.1


Projekty pro z´ısk´ an´ı reprezentace

´ Ukolem n´ asleduj´ıc´ıch projekt˚ u je z´ıskán´ı reprezentace Java typ˚ u nebo OSGi komponent. Reprezentaci je moˇzné z´ıskávat r˚ uzn´ ymi zp˚ usoby. • javatypes [40] Projekt obsahuje zejména datové tˇr´ıdy pro uchován´ı naˇctené reprezentace Java typ˚ u. Kromˇe toho obsahuje také naˇc´ıtán´ı této reprezentace z bytek´ odu a reflexe, ale tato implementace je nyn´ı jiˇz zastaralá a novˇe se pouˇz´ıv´ a implementace v projektu javatypes-loader. • javatypes-loader Projekt implementuje v souˇcasné dobˇe naˇc´ıtán´ı reprezentace Java typ˚ uz bytek´ odu. V budoucnu by mˇel obsahovat také naˇc´ıtán´ı z reflexe. • bundle-types [40] Projekt obsahuje datové tˇr´ıdy pro uchován´ı reprezentace element˚ u OSGi komponent. • bundle-loader [40] V projektu je implementováno naˇc´ıtán´ı reprezentace element˚ u OSGi komponent. • bundle-parser Projekt naˇc´ıt´ a reprezentaci Java typ˚ u i element˚ u OSGi komponent z kontextu pouˇzit´ım naˇc´ıt´ an´ı z bytekódu. V budoucnu by mˇel b´ yt nahrazen novou implementac´ı naˇc´ıtán´ı reprezentace v projektech javatypes-loader a bundle-loader. • bundle-context-loader Projekt naˇc´ıt´ a reprezentaci Java typ˚ u a element˚ u OSGi komponent z kontextu pomoc´ı reflexe. • types-cmp Vˇsechny pˇredchoz´ı projekty závis´ı na projektu types-cmp, kter´ y obsahuje z´ akladn´ı rozhran´ı.

3.4.2

Projekty kompar´ ator˚ u z´ıskan´ e reprezentace

N´ asleduj´ıc´ı projekty porovn´ avaj´ı reprezentaci Java tˇr´ıd nebo element˚ u OSGi komponent a zjiˇst’uj´ı relaci subtypu mezi porovnávan´ ymi komponentami. • javatypes-cmp Kompar´ ator reprezentac´ı Java typ˚ u. • bundle-cmp Kompar´ ator reprezentac´ı element˚ u OSGi komponent.

17


3.4.3


Z´ avislosti mezi projekty

Projekty lze rozdˇelit na ˇc´ ast JaCC (types-cmp, javatypes, javatypes-loader, javatypes-cmp) a OBCC (bundle-types, bundle-loader, bundle-parser, bundlecontext-loader, bundle-cmp). Zjednoduˇsenˇe lze ˇr´ıci, ˇze projekty OBCC závis´ı na projektech JaCC a projekty komparátor˚ u závis´ı na projektech obsahuj´ıc´ıch reprezentaci komponent. Podrobnˇeji zobrazuje závislosti mezi projekty diagram 3.1.

Obr´ azek 3.1: Z´ avislosti mezi projekty. Obrázek z dokumentace projektu OBCC.

3.4.4

Dalˇ s´ı projekty

N´ asleduj´ıc´ı projekty vyuˇz´ıvaj´ı komparátory k vytvoˇren´ı reálnˇe pouˇzitelné funkcionality. • OBVS (OSGi Bundle Versioning Service) [14] Webové rozhran´ı pro automatické verzován´ı OSGi komponent. • maven-bundle-version-plugin Plugin do Mavenu pro automatické verzován´ı OSGi komponent.

18


3.5 3.5.1

Architektura kompar´ ator˚ u

Architektura kompar´ ator˚ u Reprezentace Java typ˚ u

Datov´ a struktura naˇctené reprezentace Java typ˚ u je inspirována rozhran´ım Java reflexe (bal´ık java.lang.reflection). Oproti rozhran´ı reflexe se struktura trochu liˇs´ı a je zjednoduˇsena. Diagram 3.2 zobrazuje hierarchii Java typ˚ u implementovanou v projektu JaCC.

Obr´ azek 3.2: Hierarchie Java typ˚ u. Obrázek z dokumentace projektu OBCC.

3.5.2

Architektura naˇ c´ıt´ an´ı reprezentace

Architektura naˇc´ıt´ an´ı reprezentace nen´ı jednotná. Je to zp˚ usobeno t´ım, ˇze na jednotliv´ ych projektech pracovalo velké mnoˇzstv´ı lid´ı a nebyla stanovena jednotn´ a pravidla. V souˇcasné dobˇe se pracuje na sjednocen´ı architektury vytvoˇren´ım nového projektu javatypes-loader, kter´ y v budoucnosti nahrad´ı (spolu s projektem bundle-loader) p˚ uvodn´ı implementace naˇc´ıtán´ı reprezentace, které jsou roztrouˇsené mezi r˚ uzn´ ymi projekty.

3.5.3


Projekty kompar´ ator˚ u lze rozdˇelit na tˇr´ıdy provádˇej´ıc´ı porovnán´ı a datové tˇr´ıdy pro uchov´ an´ı v´ ysledku porovn´ an´ı. Tˇr´ıdy prov´ adˇej´ıc´ı porovn´ an´ı ˇcásteˇcnˇe kop´ıruj´ı hierarchii reprezentace. Pro kaˇzd´ y reprezentovan´ y typ existuje tˇr´ıda, která dokáˇze objekty tohoto typu porovnat. Tˇr´ıdy typicky obsahuj´ı jedinou veˇrejnou metodu compare, jej´ıˇz parametry jsou porovn´ avané typy a stav porovnáván´ı. Metoda vrac´ı v´ ysledek porov19



n´ an´ı. Instance tˇechto tˇr´ıd nemaj´ı stav, a proto je lze pouˇz´ıvat opakovanˇe a ve v´ıce vl´ aknech. Instance se z´ıskávaj´ı pomoc´ı továrn´ı tˇr´ıdy (viz [25]). Stav porovn´ an´ı je pro vˇsechny tˇr´ıdy provádˇej´ıc´ı porovnán´ı spoleˇcn´ y a je uloˇzen v objektu typu ComparatorState, kter´ y je pˇredáván v metodách compare. Stav porovn´ an´ı obsahuje historii porovnan´ ych typ˚ u, r˚ uzné parametry porovnán´ı a tov´ arn´ı tˇr´ıdy pro z´ısk´ av´ an´ı komparátor˚ u jednotliv´ ych typ˚ u.

3.5.4

Agregace v´ ysledku porovn´ an´ı

Kaˇzd´ a tˇr´ıda prov´ adˇej´ıc´ı porovnán´ı má sv˚ uj specifick´ y algoritmus a k sestaven´ı v´ ysledku pouˇz´ıv´ a v´ ysledky z´ıskané od komparátor˚ u niˇzˇs´ıch u ´rovn´ı. V´ ysledek porovn´ an´ı se skl´ ad´ a z agregovaného rozd´ılu, kter´ y m˚ uˇze nab´ yvat pouze nˇekolika hodnot a vyjadˇruje relaci subtypu. Druhou ˇcást´ı je mnoˇzina stejnˇe strukturovan´ ych v´ ysledk˚ u z´ıskan´ ych od komparátor˚ u niˇzˇs´ıch u ´rovn´ı, ze kter´ ych je moˇzné dohledat d˚ uvody pro souhrnn´ y v´ ysledek. Agregovan´ y rozd´ıl m˚ uˇze nab´ yvat tˇechto hodnot: • UNK: nezn´ am´ y v´ ysledek • NON: shoda • INS: vloˇzen´ı (element je pˇr´ıtomn´ y pouze v nové komponentˇe) • DEL: smaz´ an´ı (element je pˇr´ıtomn´ y pouze v p˚ uvodn´ı komponentˇe) • SPE: specializace (element nové komponenty je subtypem odpov´ıdaj´ıc´ıho elementu v p˚ uvodn´ı komponentˇe) • GEN: generalizace (element p˚ uvodn´ı komponenty je subtypem odpov´ıdaj´ıc´ıho elementu v nové komponentˇe) • MUT: mutace (mezi elemnety neplat´ı relace subtypu v ˇzádném smˇeru) Bˇehem porovn´ an´ı nejdˇr´ıve vznikaj´ı pouze v´ ysledky NON, INS nebo DEL. Ostatn´ı v´ ysledky vznikaj´ı aˇz jejich agregac´ı. Agregace rozd´ıl˚ u se ˇr´ıd´ı podle priorit. Poˇrad´ı v´ ysledk˚ u podle priorit od nejd˚ uleˇzitˇejˇs´ıch po nejménˇe d˚ uleˇzité: UNK, MUT, INS, SPE, DEL, GEN, NON. Pokud je v agregovan´ ych v´ ysledc´ıch zastoupen rozd´ıl INS nebo SPE z´ aroveˇ n s rozd´ılem DEL nebo GEN, v´ ysledkem je vˇzdy MUT. Agregovat je obvykle potˇreba z´ıskaná mnoˇzina rozd´ıl˚ u z komparátor˚ u na niˇzˇs´ı u ´rovni. V nˇekter´ ych pˇr´ıpadech je ale nutné provést nejdˇr´ıve inverzi rozd´ılu, protoˇze pro z´ısk´ an´ı relace subtypu je potˇreba z´ıskat opaˇcnou relaci subtypu na niˇzˇs´ı u ´rovni. To se projevuje napˇr´ıklad u parametr˚ u metod. Pokud je klient zvykl´ y volat v p˚ uvodn´ı komponentˇe metodu s parametrem A, mus´ı komponenta, která je subtypem p˚ uvodn´ı komponenty, toto volán´ı také umoˇznit. Proto formáln´ı parametr volané metody v p˚ uvodn´ı komponentˇe mus´ı b´ yt subtypem parametru v nové komponentˇe (pˇr´ıpadnˇe m˚ uˇze b´ yt samozˇrejmˇe shodn´ y). 20


3.6 3.6.1

Problémy a n´ amˇety pro dalˇs´ı pr´ aci

Probl´ emy a n´ amˇ ety pro dalˇ s´ı pr´ aci Generick´ e typy

Bˇehem své pr´ ace na projektech jsem objevila nˇekolik nedostatk˚ u nebo chyb implementace. Prvn´ım a nejz´ asadnˇejˇs´ım je problém s generikami v komparátoru. Implementace porovn´ av´ an´ı generick´ ych typ˚ u nen´ı dotaˇzená a algoritmus ˇcasto konˇc´ı v nekoneˇcné smyˇcce. D˚ uvodem je, ˇze komparátor nepoˇc´ıtá s moˇznost´ı cyklick´ ych typ˚ u, jako napˇr´ıklad: class A <E extends List >

Kompar´ ator je pˇripraven pouze na cykly obyˇcejn´ ych tˇr´ıd, které ˇreˇs´ı zaveden´ım historie porovn´ avan´ ych tˇr´ıd. Pˇred samotn´ ym porovnán´ım tˇr´ıd je pomoc´ı historie ovˇeˇreno, ˇze porovn´ avaná dvojice jeˇstˇe nebyla porovnávána, nebo nen´ı porovn´ av´ ana pr´ avˇe ted’ d´ıky rekurzi. Dvojice je ihned vloˇzena do historie a poté se provede porovn´ an´ı. Stejné ˇreˇsen´ı je potˇreba zavést pro generické typy. Reprezentace generick´ ych typ˚ u je popsána v dokumentu [2].

3.6.2

Porovn´ av´ an´ı tˇ r´ıd

Druh´ ym nedostatkem, kter´ y zhorˇsuje funkcionalitu, je absence mechanismu, kterému v rozhran´ı Java reflexe odpov´ıdá metoda isAssignableFrom. Metoda zjiˇst’uje, zda je moˇzné objekt pˇretypovat na danou tˇr´ıdu nebo rozhran´ı. Implementace v kompar´ atorech by znamenala hlavnˇe nutnost naˇc´ıtat pˇredky a rozhran´ı tˇr´ıd. Poté by bylo moˇzné upravit algoritmus porovnáván´ı tˇr´ıd, aby se pˇri rozd´ılném n´ azvu nevygenerovala automaticky mutace. Pokud by se jedna z porovn´ avan´ ych tˇr´ıd shodovala s nˇekter´ ym pˇredkem tˇr´ıdy druhé, v´ ysledek porovn´ an´ı by se mohl zlepˇsit na generalizaci nebo specializaci.

3.6.3

Ovˇ eˇ rov´ an´ı kompatibility dvou komponent

Tˇret´ı problém je sp´ıˇse koncepˇcn´ıho typu. T´ yká se ovˇeˇrován´ı kompatibility exportuj´ıc´ı a importuj´ıc´ı komponenty. Uvedu nejdˇr´ıve problematick´ y pˇr´ıklad kódu v jednotliv´ ych komponent´ ach: Komponenta 1: interface MujInterface { void metoda ( Parametr p ); } Komponenta 2: class MojeImplementace implements MujInterface { void metoda ( Parametr p ) { p . toString (); }

21


Implementované opravy a vylepˇsen´ı

} Komponenta 3: class Parametr { String toString () { return " parametr " ; } }

Tˇr´ıdu Parametr z komponenty 3 importuj´ı obˇe zbylé komponenty. Komponenta 2 importuje rozhran´ı MujInterface z komponenty 1. Problém nastává pˇri ovˇeˇren´ı kompatibility komponent 1 a 2. Porovn´ an´ı bude prob´ıhat na základˇe naˇctené reprezentace komponenty 1 standardn´ım zp˚ usobem a naˇcteného komplementu komponenty 1 z kontextu, tj. z komponenty 2. Prvn´ı reprezentace bude obsahovat tˇr´ıdu Parametr, která je pr´ azdn´ a (nejsou dostupné zdroje pro naˇcten´ı jej´ı implementace). Druhá reprezentace bude obsahovat také tˇr´ıdu Parametr, ale nyn´ı vˇcetnˇe jej´ı metody toString(), protoˇze se jedn´ a o naˇc´ıtán´ı z kontextu (naˇctou se vˇsechny metody, které jsou pouˇzité). V´ ysledkem porovn´ an´ı bude, ˇze komponenta naˇctená z kontextu je subtypem komponenty naˇctené standardn´ım zp˚ usobem, protoˇze obsahuje nav´ıc metodu Parametr.toString(). To znamená, ˇze komponenty 1 a 2 budou vyhodnoceny jako nekompatibiln´ı. Komponenta 2 pouˇz´ıvá metodu, která v komponentˇe 1 chyb´ı. ˇ sen´ım je zaveden´ı ignorovan´ Reˇ ych bal´ık˚ u bˇehem porovnáván´ı. Pravdˇepodobnost, ˇze bude implementace bal´ıku rozprostˇrena do v´ıce komponent, je malá. Mezi ignorované bal´ıky lze proto zahrnout vˇsechny importované bal´ıky obou komponent, které z´ aroveˇ n nejsou exportované nˇekterou z nich. V´ ysledek porovn´ an´ı tˇr´ıd z tˇechto bal´ık˚ u by mˇel b´ yt vˇzdy NON, protoˇze pˇri importu stejné komponenty do obou komponent budou tyto tˇr´ıdy skuteˇcnˇe stejné. Porovnán´ı by se na této u ´rovni mˇelo zastavit, aby nebylo moˇzné se dostat na jiné bal´ıky importovan´ ych komponent.

3.6.4

Dalˇ s´ı nedostatky

D´ ale jsem zjistila, ˇze v komparátorech chyb´ı kompletnˇe implementace anotac´ı, implementace naˇc´ıt´ an´ı reprezentace pomoc´ı reflexe je ve velmi nedotaˇzeném stavu a chyb´ı implementace porovnáván´ı v´ yjimek.

3.7

Implementovan´ e opravy a vylepˇ sen´ı

N´ asleduj´ıc´ı opravy a vylepˇsen´ı komparátor˚ u jsem implementovala nad rámec prac´ı popsan´ ych v kapitol´ ach 4 a 5, které jsou jádrem této diplomové práce. U

22


Implementované opravy a vylepˇsen´ı

jednotliv´ ych u ´prav uv´ ad´ım také ˇc´ısla poˇzadavk˚ u v systému správy zmˇen (viz kapitola 3.8.4), kde lze dohledat jejich detailn´ı popis.

3.7.1

´ Upravy hierarchie Java typ˚ u

Bˇehem seznamov´ an´ı se s k´ odem komparátoru jsem objevila nˇekteré nelogiˇcnosti v hierarchii tˇr´ıd reprezentace Java typ˚ u. Dále jsem upravila implementaci metod toString, kter´ a p˚ uvodnˇe zp˚ usobovala v nˇekter´ ych pˇr´ıpadech nekoneˇcné cyklen´ı. Detailn´ı popis proveden´ ych zmˇen lze dohledat v nástroji pro správu poˇzadavk˚ u pod tˇemito ˇc´ısly poˇzadavk˚ u: JaCC - #105, #89, #122, #89, #123, #125

3.7.2

Pomoc pˇ ri thread-safety anal´ yze

ˇ ep´ Bc. Martin Stˇ anek prov´ adˇel v rámci oborového projektu thread-safety anal´ yzu, neboli anal´ yzu bezpeˇcnosti komparátor˚ u pˇri bˇehu ve v´ıce vláknech najednou. Tento u ´kol sv´ ym rozsahem pˇrekraˇcoval rozsah oborového projektu, proto jsem se na pr´ aci také pod´ılela. Prov´ adˇela jsem jak samotnou anal´ yzu ˇcásti projekt˚ u, tak implementaci nˇekter´ ych n´ asledn´ ych u ´prav. V´ ysledky anal´ yzy lze dohledat v dokumentu [4]. Popis mnou implementovan´ ych u ´prav je v nástroji pro správu poˇzadavk˚ u pod tˇemito ˇc´ısly poˇzadavk˚ u: JaCC - #114, #42, #119 OBCC - #291, #256, #319

3.7.3

´ Upravy struktury v´ ysledk˚ u porovn´ an´ı

Strukturu v´ ysledk˚ u porovn´ an´ı jsem vylepˇsila o referenci na agregovan´ y v´ ysledek a zaˇcala jsem pracovat také na zjednoduˇsen´ı struktury. Poˇzadavky lze dohledat pod tˇemito ˇc´ısly: JaCC - #120, #158

3.7.4

Vylepˇ sen´ı algoritmu porovn´ an´ı tˇ r´ıd

Vylepˇsila jsem algoritmus porovnán´ı tˇr´ıd t´ım, ˇze jsem sjednotila zp˚ usob detekce rekurze s ukl´ ad´ an´ım a pouˇz´ıv´ an´ım v´ ysledk˚ u jiˇz porovnan´ ych tˇr´ıd. Protoˇze mˇela tato u ´prava vliv na v´ ykonnost komparátoru, je tato zmˇena bl´ıˇze popsána v ˇcásti proveden´ ych optimalizac´ı v kapitole 4.10.2. Poˇzadavky jsou dohledatelné pod tˇemito ˇc´ısly:

23


Technologie a vývojové n´ astroje

JaCC - #113, #114

3.8 3.8.1

Technologie a v´ yvojov´ e n´ astroje Java

Vˇsechny projekty jsou psané v programovac´ım jazyce Java a pouˇz´ıvaj´ı standardn´ı JDK verze 1.6. Na projektech je potˇreba dodrˇzovat domluvené konvence. Kód i komentáˇre by se mˇely ps´ at anglicky a v kódován´ı UTF-8. Kaˇzdá tˇr´ıda a d˚ uleˇzité metody by mˇely b´ yt komentov´ any Javadoc komentáˇrem. K logován´ı by se mˇela vyuˇz´ıvat knihovna SLF4J. Kaˇzd´ y zdrojov´ y soubor by mˇel obsahovat hlaviˇcku s informacemi o licenci. Ve v´ yvojovém prostˇred´ı Eclipse lze nastavit automatické vkládán´ı této hlaviˇcky v nab´ıdce Window – Preferences – Java – Code Style – Code Templates – Comments – Files. Kromˇe nastaven´ı textu je potˇreba také zaˇskrtnout pod textem automatické vkl´ ad´ an´ı kommentáˇr˚ u. Dalˇs´ı konvence jsou d´ any pomoc´ı pravidel pro automatické formátován´ı, které lze v Eclipse nastavit v nab´ıdce Window – Preferences – Java – Code Style – Formatter. Pravidla lze stáhnout z [3]. V projektech by mˇela b´ yt dodrˇzována pravidla práce s v´ yjimkami popsaná v [1].

3.8.2

OSGi

Projekty kompar´ ator˚ u lze pouˇz´ıt bud’ jako knihovny, nebo také jako OSGi komponenty.

3.8.3

Apache Maven

Maven [21] je n´ astroj pro automatick´ y build. Je alternativou k nástroj˚ um Ant nebo Make. Na rozd´ıl od nich se nezamˇeˇruje na popis jak se co má udˇelat, ale pouze popis poˇzadovaného v´ ysledku. Konfigurace build procesu je um´ıstˇena v XML souboru pom.xml. Ten obsahuje typicky identifikaci projektu, závislosti a pˇr´ıpadnˇe seznam plugin˚ u, které pˇrid´ avaj´ı dalˇs´ı akce (napˇr´ıklad testován´ı). Identifikace projektu je rozdˇelena na ˇc´ ast groupId (identifikace skupiny projekt˚ u), artifactId (identifikace projektu) a version (verze). Projekty a knihovny, na kter´ ych projekt závisi (dependencies), se identifikuj´ı 24


Zp˚ usob pr´ ace v týmu

také pomoc´ı tag˚ u groupId, artifactId a version. Pomoc´ı tagu scope lze urˇcit, zda bude knihovna vloˇzena do v´ ysledného JAR souboru (compiled), nebo zda bude pouze pˇrid´ av´ ana na classpath pˇri spuˇstˇen´ı (provided). Projekt mus´ı m´ıt pˇredepsanou strukturu (pokud nen´ı pomoc´ı konfigurace zmˇenˇena). Zdrojové soubory jsou v adresáˇri src/main/java a ostatn´ı zdroje v src/main/resources. Pro testy jsou podobnˇe vymezeny adresáˇre src/test/java a src/test/resources. Build se spouˇst´ı bud’ z pˇr´ıkazové ˇrádky, nebo pomoc´ı grafického rozhran´ı Eclipse (plugin M2Eclipse). Obvykle se pouˇz´ıvá pˇr´ıkaz: mvn install

Tento pˇr´ıkaz zkompiluje zdrojové soubory, zabal´ı pˇreloˇzené tˇr´ıdy a zdroje do JAR archivu, spust´ı automatické testy a JAR archiv uloˇz´ı do lokáln´ıho u ´loˇziˇstˇe. Pˇr´ıpadné z´ avislosti se snaˇz´ı stahovat z veˇrejn´ ych u ´loˇziˇst’ na internetu. V projektech JaCC a OBCC se pouˇz´ıvá takzvan´ y rodiˇcovsk´ y POM (parent), kter´ y je um´ıstˇen´ y v trunk/pom. V jsou definované spoleˇcné ˇcásti jednotliv´ ych POM soubor˚ u. Pro build vˇsech projekt˚ u najednou lze pouˇz´ıt takzvan´ y reaktor POM, kter´ y je um´ıstˇen´ y pˇr´ımo v adres´ aˇri trunk. Nejdˇr´ıve je nutné spustit mvn install pro JaCC, n´ aslednˇe pro OBCC.

3.8.4

Assembla

Assembla [28] je n´ astroj, kter´ y integruje verzovac´ı systém SVN se správou poˇzadavk˚ u. Commit do SVN lze jednoduˇse provázat s pˇr´ısluˇsn´ ym poˇzadavkem pomoc´ı uveden´ı koment´ aˇre Re #123“ (pˇr´ıklad pro ˇc´ıslo poˇzadavku 123). SVN ” lze pouˇz´ıvat pomoc´ı libovolného klienta, napˇr´ıklad TortoiseSVN [43]. Projekt JaCC je na adrese http:// www.assembla.com/ spaces/ jacc, projekt OBCC na http:// www.assembla.com/ spaces/ obcc.

3.8.5

Hudson Continuous Integration

Hudson [37] je n´ astroj pro plynulou integraci. Pravidelnˇe zjiˇst’uje, zda v SVN nepˇribyla zmˇena, a pokud ano, spust´ı build projektu a testy. Hudson pro projekty JaCC a OBCC je k dispozici na adrese http:// students. kiv.zcu.cz:8080/ .

3.9

Zp˚ usob pr´ ace v t´ ymu

Na projektech JaCC a OBCC pracovalo v pr˚ ubˇehu této práce nˇekolik lid´ı souˇcasnˇe. Bylo nutné synchronizovat nˇekteré zmˇeny (refactoring) s optimalizacemi 25


Zp˚ usob pr´ ace v týmu

a rozˇs´ıˇren´ımi. Aby mohla spolupr´ ace v t´ ymu dobˇre fungovat, je nutné svou práci dostateˇcnˇe dokumentovat. To znamen´ a zejména vytváˇren´ı záznam˚ u v nástroji pro správu poˇzadavk˚ u a propojov´ an´ı kaˇzdého commitu do SVN s poˇzadavkem. Pˇred nahr´ an´ım proveden´ ych zmˇen do SVN je nutné ovˇeˇrit, ˇze jsou projekty kompilovatelné pomoc´ı Mavenu. Procházet by mˇely také automatické testy (v souˇcasné dobˇe proch´ az´ı jen nˇekteré). V pr˚ ubˇehu pr´ ace se cel´ y t´ ym pracuj´ıc´ı na projektech JaCC a OBCC pravidelnˇe sch´ azel kaˇzd´ ych ˇctrn´ act dn˚ u. Forma sch˚ uzek byla pˇrevzata z metodiky Scrum. V metodice Scrum se tato sch˚ uzka naz´ yvá daily standup a opakuje se kaˇzd´ y ˇ den. Clenov´ e t´ ymu by mˇeli celou dobu stát (aby se sch˚ uzka neprodluˇzovala) a kaˇzd´ y pod´ av´ a zpr´ avu o tˇrech bodech: • co jsem dˇelal(a) • co budu dˇelat • co mi br´ an´ı v pr´ aci Sch˚ uzku vede Scrum-master, kter´ y následnˇe ˇreˇs´ı pˇrekáˇzky ˇclen˚ u t´ ymu. Sch˚ uzka by mˇela b´ yt dlouh´ a zhruba patnáct minut a nemˇely by se na n´ı ˇreˇsit problémy. Mˇela by slouˇzit pouze ke vz´ ajemnému informován´ı o tom, kdo na ˇcem pracuje. Tyto sch˚ uzky ˇc´ asteˇcnˇe pˇredcház´ı provádˇen´ı zbyteˇcné nebo opakované práce v d˚ usledku nedostateˇcné komunikace mezi ˇcleny t´ ymu.

26

4 Vyuˇzit´ı komparátor˚ u na mal´ ych zaˇ r´ızen´ıch 4.1

Mal´ a zaˇ r´ızen´ı

Pouˇz´ıv´ an´ı mal´ ych (v´ ykonovˇe omezen´ ych) zaˇr´ızen´ı, jako jsou chytré telefony, PDA nebo tablety, je st´ ale v´ıce obl´ıbené. Do budoucna lze oˇcekávat podporu (témˇeˇr) standardn´ı Javy na vˇetˇsinˇe mobiln´ıch zaˇr´ızen´ıch. Jiˇz nyn´ı lze pouˇz´ıvat vˇetˇsinu aplikac´ı pro standardn´ı Javu na platformˇe Android.

4.1.1

Android

Android [26] je open-source platforma pro mobiln´ı zaˇr´ızen´ı (chytré telefony, navigace, tablety). Skl´ ad´ a se z operaˇcn´ıho systému, ovladaˇc˚ u pro konkrétn´ı zaˇr´ızen´ı, aplikaˇcn´ıho frameworku a bˇeˇzn´ ych uˇzivatelsk´ ych aplikac´ı. Operaˇcn´ı systém je zaloˇzen na j´ adru systému Linux. Aplikaˇcn´ı framework poskytuje rozhran´ı pro uˇzivatelské aplikace v Javˇe. Java na Androidu se m´ırnˇe liˇs´ı od standardn´ı Javy. Virtuáln´ım strojem je Dalvik virtual machine. Prvn´ı rozd´ıl oproti standardn´ı Javˇe je nutnost pˇrekladu class soubor˚ u do speci´ aln´ıho form´ atu (dex). Mezi dalˇs´ı rozd´ıly patˇr´ı, ˇze Dalvik nepodporuje nˇekteré speci´ aln´ı knihovny, napˇr´ıklad JAXB nebo DOM pro práci s XML. Program´ ator aplikac´ı m´ a k dispozici Android SDK – soubor knihoven a nástroj˚ u pro v´ yvoj aplikac´ı. Souˇc´ ast´ı SDK je také velmi dobˇre pouˇziteln´ y simulátor telefonu. Aplikace jsou psané jako komponenty aplikaˇcn´ıho frameworku a v názvoslov´ı Androidu se jim ˇr´ık´ a aktivity. Aktivity mezi sebou komunikuj´ı pomoc´ı zpr´ av s n´ azvem intent“. ” Android poskytuje vlastn´ı prostˇredky pro tvorbu uˇzivatelského rozhran´ı. Obvykle je grafické rozhran´ı konfigurováno pomoc´ı grafického editoru a je pˇridruˇzeno ke kaˇzdé aktivitˇe.

4.1.2

Vyuˇ zit´ı OSGi na platformˇ e Android

Aˇckoliv Android poskytuje sv˚ uj vlastn´ı komponentov´ y (aplikaˇcn´ı) framework, m˚ uˇze b´ yt OSGi framework na Androidu také uˇziteˇcn´ y. Existuje mnoho OSGi aplikac´ı, které by se mohly bez vˇetˇs´ıch u ´prav spustit na platformˇe Android. Pokusy pˇrenést OSGi framework na Android se jiˇz objevuj´ı, pˇr´ıkladem je projekt EZdroid [33], kter´ y se zamˇeˇruje na pouˇzit´ı frameworku Apache Felix na platformˇe Android.

27

Vyuˇzit´ı kompar´ ator˚ u na malých zaˇr´ızen´ıch

Pˇredchoz´ı pr´ ace

V´ yhodou OSGi komponent je niˇzˇs´ı reˇzie na komunikaci, neˇz jakou maj´ı komponenty Androidu. Komunikace v OSGi prob´ıhá pomoc´ı volán´ı metod. M˚ uˇze to b´ yt také jednoduˇsˇs´ı pro programátora neˇz pos´ılán´ı zpráv a vazba mezi komponentami je tˇesnˇejˇs´ı. Na druhou stranu, pouˇzit´ı OSGi na Androidu má i své nev´ yhody. Napˇr´ıklad nelze jednoduˇse vytv´ aˇret uˇzivatelské rozhran´ı v OSGi komponentách pomoc´ı grafického editoru. Komponenty mohou rozhran´ı vytváˇret jedinˇe programovˇe, nebo mus´ı b´ yt rozhran´ı souˇca´st´ı frameworku samotného (aktivity, ve které je framework spouˇstˇen).

4.1.3

Vyuˇ zit´ı kompar´ ator˚ u na platformˇ e Android

Pˇri pouˇz´ıv´ an´ı OSGi na Androidu nebo jin´ ych platformách pro malá zaˇr´ızen´ı vznik´ a také poˇzadavek na moˇznost bezpeˇcného nahrazen´ı nebo aktualizaci komponent. Ovˇeˇren´ı nahraditelnosti ale pˇrináˇs´ı nové reˇzijn´ı náklady na ˇcas bˇehu aplikace i spotˇrebu pamˇeti. Mal´ a zaˇr´ızen´ı jsou mnohem ménˇe v´ ykonná neˇz bˇeˇzné poˇc´ıtaˇce a maj´ı velmi omezené pamˇet’ové zdroje. Pˇr´ıliˇs velká reˇzie m˚ uˇze proto snadno zp˚ usobit nepouˇzitelnost takového systému. Aby bylo moˇzné na mal´ ych zaˇr´ızen´ıch komparátory pouˇz´ıvat, je potˇreba, aby jejich pamˇet’ové a ˇcasové nároky byly pˇrijatelnˇe n´ızké.

4.2

Pˇ redchoz´ı pr´ ace

V r´ amci oborového projektu (viz [17]) byl framework Apache Felix upraven pro bˇeh na platformˇe Android. Byla vyuˇzita také integrace komparátor˚ u do procesu resolvingu (typov´ a kontrola pˇri resolvingu). Práce mˇela za u ´kol udˇelat jednoduch´ y v´ ykonnostn´ı test komparátor˚ u na platformˇe Android. K vyhodnocen´ı v´ ysledk˚ u byly porovn´ av´ any ˇcasy a pamˇet’ spotˇrebovaná pˇri resolvingu bez typové kontroly a s typovou kontrolou. V´ ysledkem pr´ ace je moˇznost spuˇstˇen´ı komparátor˚ u na platformˇe Android a orientaˇcn´ı v´ ysledky v´ ykonnostn´ıch test˚ u. Ukázalo se, ˇze pamˇet’ové a ˇcasové nároky typové kontroly nejsou ideáln´ı. Pˇri testech reálné aplikace doˇslo nˇekolikrát k vyˇcerp´ an´ı pamˇeti. Relativn´ı nár˚ ust pamˇet’ov´ ych i ˇcasov´ ych nárok˚ u se liˇsil pro ˇ r˚ uzné velikosti komponent. Casov´ a nároˇcnost resolvingu se s pˇridán´ım typové kontroly zv´ yˇsila v rozmez´ı 9 aˇz 45 procent, pamˇet’ová nároˇcnost se zv´ yˇsila o 15 aˇz 64 procent. Pro uˇzivatele to znamená zv´ yˇsen´ı doby bˇehu v ˇrádu des´ıtek sekund.

28


4.3

´ Ukol této pr´ ace

´ Ukol t´ eto pr´ ace

´ Ukolem této pr´ ace je zv´ yˇsit pouˇzitelnost komparátor˚ u na mal´ ych zaˇr´ızen´ıch sn´ıˇzen´ım jejich n´ arok˚ u na systémové zdroje. Komparátory by mˇeli u ´spornˇe hospodaˇrit s pamˇet´ı a vytv´ aˇret malé datové struktury. Práce se zamˇeˇr´ı také na kontrolu a pˇr´ıpadnou optimalizaci algoritm˚ u pro sn´ıˇzen´ı ˇcasu provádˇen´ı typové kontroly.

4.3.1

Metodika

Pˇred samotnou optimalizac´ı je nutné vytvoˇrit mechanismus mˇeˇren´ı aktuáln´ı v´ ykonnosti (ˇcasové i pamˇet’ové). K tomuto u ´ˇcelu byla vytvoˇrena testovac´ı aplikace, kter´ a produkuje pˇrehledn´ y v´ ystup obsahuj´ıc´ı aktuáln´ı v´ ysledky i zlepˇsen´ı oproti v´ ysledk˚ um pˇredchoz´ım. N´ aslednˇe je moˇzné analyzovat kód aplikace za u ´ˇcelem nalezen´ı problematick´ ych ˇc´ ast´ı k´ odu a proveden´ı jejich optimalizace. Anal´ yza komparátor˚ u prob´ıhala manu´ alnˇe i za pouˇzit´ı programov´ ych nástroj˚ u (profiler, heap analyser). Efekt optimalizac´ı lze ovˇeˇrit a vyhodnotit pomoc´ı testovac´ı aplikace pro jednotlivé zmˇeny i pro vˇsechny provedené optimalizace. Testovac´ı aplikace byla nasazena do procesu plynulé integrace (continuous integration), aby mohla b´ yt v´ ykonnost sledov´ ana také pˇri budouc´ıch zmˇenách.

4.4

V´ ykonnostn´ı testy

Pomoc´ı v´ ykonnostn´ıch test˚ u [34] lze ovˇeˇrit, jak se testovaná aplikace chová pˇri urˇcité z´ atˇeˇzi. D˚ uleˇzit´ ymi hledisky k posouzen´ı v´ ykonnosti aplikace jsou obvykle konzumace pamˇeti, odezva nebo ˇcas v´ ypoˇctu. U serverov´ ych aplikac´ı se ˇcasto mˇeˇr´ı také pr˚ uchodnost – poˇcet zpracovan´ ych poˇzadavk˚ u za jednotku ˇcasu. V´ ykonnostn´ı testy lze vyuˇz´ıt také k mˇeˇren´ı ˇskálovatelnosti a spolehlivosti aplikace.

4.4.1

´ cel v´ Uˇ ykonnostn´ıch test˚ u

´ cel v´ Uˇ ykonnostn´ıch test˚ u m˚ uˇze b´ yt následuj´ıc´ı: • Ovˇeˇren´ı, ˇze systém splˇ nuje dan´ a výkonnostn´ı kritéria. Specifikace poˇzadavk˚ u na systém m˚ uˇze obsahovat kromˇe funkˇcn´ıch poˇzadavk˚ u také poˇzadavky na v´ ykonnost, napˇr´ıklad maximáln´ı dobu odezvy na konkrétn´ı akce uˇzivatele nebo pr˚ uchodnost urˇcitého typu poˇzadavk˚ u. V´ ykonnostn´ı poˇzadavky mohou b´ yt dané také konfigurac´ı c´ılového zaˇr´ızen´ı, napˇr´ıklad omezen´ım pamˇeti.

29


Výkonnostn´ı testy

• Ovˇeˇren´ı, ˇze systém zvl´ adne re´ alnou z´ atˇeˇz. Bˇeˇzné funkˇcn´ı testy testuj´ı aplikaci pˇri minimáln´ı zátˇeˇzi. Chován´ı aplikace pˇri velké z´ atˇeˇzi m˚ uˇze b´ yt jiné. Pokud zátˇeˇz vzroste nad urˇcitou mez, systém nemus´ı b´ yt schopen nˇekteré poˇzadavky plnit. Proto se pouˇz´ıvaj´ı testy, které simuluj´ı pˇredpokládanou reálnou zátˇeˇz. Sleduje se, zda systém i pˇri této z´ atˇeˇzi splˇ nuje poˇzadované nebo rozumné limity odezvy a je schopen poskytovat kompletn´ı funkcionalitu. Dále je moˇzné zátˇeˇz postupnˇe zvyˇsovat a hledat maximáln´ı zátˇeˇz, kterou je systém schopen zvládnout. • Porovn´ an´ı 2 systém˚ u a urˇcen´ı, který m´ a lepˇs´ı výkonnost. V nˇekter´ ych pˇr´ıpadech jsou komponenty systému nebo celé aplikace vyb´ır´ any podle v´ ykonnosti. Srovnán´ı v´ ykonnosti vlastn´ı aplikace s konkurenˇcn´ımi systémy lze vyuˇz´ıt k propagaci. • Mˇeˇren´ı aktu´ aln´ı výkonnosti a porovn´ an´ı s pˇredchoz´ımi verzemi. Mˇeˇren´ı a porovn´ an´ı r˚ uzn´ ych verz´ı jedné aplikace lze vyuˇz´ıt k vyhodnocen´ı efektu optimalizac´ı nebo sledován´ı efektu jednotliv´ ych zmˇen na v´ ykonnost. Tento u ´ˇcel vyˇzaduje pˇresnˇejˇs´ı metody mˇeˇren´ı, protoˇze zmˇeny v´ ykonnosti mohou b´ yt malé. • Vyhled´ an´ı kritických ˇc´ ast´ı systému (bottleneck). Tento typ test˚ u je zamˇeˇren na vyhledán´ı m´ıst v kódu, kde v´ ypoˇcet tráv´ı nejv´ıce ˇcasu. Tyto m´ısta je vhodné následnˇe optimalizovat. K vyhledán´ı kritick´ ych m´ıst se obvykle pouˇz´ıvaj´ı nástroje zvané profilery. • Monitorov´ an´ı systému. Monitorov´ an´ı se pouˇz´ıv´ a u jiˇz nasazen´ ych systém˚ u, proto je poˇzadována n´ızk´ a reˇzie prov´ adˇen´ ych mˇeˇren´ı. Monitorován´ım lze odhalit potenciáln´ı problémy vzniklé napˇr´ıklad zvˇetˇsen´ım dat nad u ńosnou mez nebo zv´ yˇsen´ım zat´ıˇzen´ı v d˚ usledku vyˇsˇs´ı obl´ıbenosti systému. Na tyto problémy lze vˇcas reagovat.

4.4.2

Vytv´ aˇ ren´ı v´ ykonnostn´ıch test˚ u

Implementaci v´ ykonnostn´ıch test˚ u nejv´ıce ovlivˇ nuje jejich u ´ˇcel. Ten rozhoduje o tom, jak velkou reˇzii mohou testy m´ıt, zda je lze opakovat na stejn´ ych datech a ´ cel ovlivˇ jaké technologie lze pˇri implementaci vyuˇz´ıt. Uˇ nuje také metriky, které je vhodné mˇeˇrit. Technologie mˇeˇren´ı, moˇznost opakovatelnosti test˚ u a pˇr´ıpustná reˇzie maj´ı z´ asadn´ı dopad na pˇresnost mˇeˇren´ı. Pro nˇekteré u ´ˇcely je vyˇzadována vysoká pˇresnost mˇeˇren´ı (porovn´ an´ı p˚ uvodn´ı a optimalizované verze systému), pro jiné plnˇe postaˇcuj´ı orientaˇcn´ı hodnoty (monitorován´ı systému, mˇeˇren´ı pˇri reálné zátˇeˇzi). Aby mˇely v´ ysledky test˚ u co nejvˇetˇs´ı hodnotu, mˇely by b´ yt testy provádˇeny v prostˇred´ı, které se co nejv´ıce bl´ıˇz´ı reálnému. Také testovac´ı data by mˇela odpov´ıdat realitˇe svou velikost´ı i r˚ uznorodost´ı.

30


4.5

Analýza k´ odu

Anal´ yza k´ odu

Pomoc´ı v´ ykonnostn´ıch test˚ u lze zjistit v´ ykonnostn´ı problémy aplikace. Následnˇe je nutné provést anal´ yzu k´ odu, která odhal´ı pˇr´ıˇciny problém˚ u a detekuje m´ısta v k´ odu, kter´ a jsou vhodn´ a k optimalizaci. Anal´ yzu lze prov´ adˇet bud’ manuálnˇe, nebo s pouˇzit´ım nˇejakého nástroje. Pomoc´ı manu´ aln´ı anal´ yzy lze odhalit zejména neefektivn´ı algoritmy nebo nevhodné datové struktury. Z´ akladn´ım n´ astrojem pro anal´ yzu je profiler. Funkˇcnost profiler˚ u obvykle zahrnuje mˇeˇren´ı ˇcasu v´ ypoˇctu v jednotliv´ ych metodách a poˇcet jejich zavolán´ı. ˇ str´ Cas aven´ y v metodˇe lze rozdˇelit na ˇcas vˇcetnˇe dalˇs´ıch zavolan´ ych metod a ˇ ˇcas bez nich. Casy jsou obvykle zkresleny kv˚ uli reˇzii jejich mˇeˇren´ı. Pro u ´ˇcely anal´ yzy ale toto zkreslen´ı nen´ı podstatné. Pomoc´ı profileru lze odhalit metody, které spotˇrebuj´ı nejv´ıce ˇcasu v´ ypoˇctu. Plat´ı zde Paretovo pravidlo, ˇze 80 procent ˇcasu je spotˇrebováno ve 20 procentech metod. Na tˇechto 20 procent nejnároˇcnˇejˇs´ıch metod má smysl se následnˇe zamˇeˇrit pˇri manu´ aln´ı anal´ yze. Dalˇs´ımi uˇziteˇcn´ ymi n´ astroji jsou analyzátory pamˇeti (heap analyser). S jejich pomoc´ı lze odhalit objekty, které zab´ıraj´ı nejv´ıce pamˇeti, nebo tˇr´ıdy s podezˇrele velk´ ym poˇctem instanc´ı. Na základˇe v´ ysledk˚ u se lze zamˇeˇrit na optimalizaci datov´ ych struktur a uvolˇ nov´ an´ı nepotˇrebn´ ych objekt˚ u. Analyz´ atory pamˇeti obvykle umoˇzn ˇuj´ı zachytit a dále analyzovat stav pamˇeti v jednom okamˇziku. Je proto d˚ uleˇzité tento okamˇzik vhodnˇe zvolit, aby z´ıskané v´ ysledky mˇely dobrou informaˇcn´ı hodnotu. D´ ale jsou k dispozici n´ astroje pro statickou anal´ yzu kódu. Ty dokáˇzou odhalit problémy zp˚ usobené ˇspatnou kvalitou kódu.

4.5.1

N´ astroje pouˇ zit´ e pro anal´ yzu kompar´ ator˚ u

• Eclipse TPTP Eclipse TPTP [24] je profiler zaloˇzen´ y na v´ yvojovém prostˇred´ı Eclipse. Jeho uˇzivatelské rozhran´ı je velmi pˇr´ıvˇetivé. Nástroj nab´ız´ı velké mnoˇzstv´ı pohled˚ u na namˇeˇrená data, ze kter´ ych jsem vyuˇzila hlavnˇe pˇrehled ˇcasovˇe nejn´ aroˇcnˇejˇs´ıch bal´ık˚ u, tˇr´ıd a metod. Po rozbalen´ı detailu metody se zobraz´ı vˇsechny volané metody opˇet seˇrazené podle spotˇreby ˇcasu. Nev´ yhodou n´ astroje je v´ yrazná reˇzie pˇri mˇeˇren´ı. V´ ypoˇcet, kter´ y bˇeˇznˇe trval nˇekolik stovek milisekund, trval s pouˇzit´ım tohoto nástroje 14 sekund. Delˇs´ı v´ ypoˇcty nebylo moˇzné v˚ ubec analyzovat, protoˇze nástroj v´ ypoˇcet nezvl´ adl a bylo nutné ho restartovat. Celkovˇe se n´ astroj uk´ azal b´ yt velmi uˇziteˇcn´ y a pomohl mi rychle detekovat problém vhodn´ y k optimalizaci (viz kapitola 4.10.1). • Eclipse MAT 31


Optimalizace

Eclipse MAT (Memory Analyzer) [23] je analyzátor pamˇeti, kter´ y je také postaven na v´ yvojovém nástroji Eclipse. Jeho uˇzivatelské rozhran´ı je pomˇernˇe nepˇrehledné. N´ astroj nab´ız´ı ˇsiroké spektrum pohled˚ u na data vˇcetnˇe moˇznosti vyhled´ av´ an´ı konkrétn´ıch objekt˚ u. Já jsem vyuˇzila zejména pˇrehled nejvˇetˇs´ıch konzument˚ u pamˇeti seskupen´ ych podle bal´ık˚ u. N´ astroj analyzuje soubor vygenerovan´ y virtuáln´ım strojem, kter´ y zachycuje stav pamˇeti v jednom okamˇziku v´ ypoˇctu. Soubor lze vygenerovat programovˇe pouˇzit´ım tohoto kódu: MBeanServer server = ManagementFactory . getPlatformMBeanServer (); HotSpotDiagnosticMXBean hotspotMBean = ManagementFactory . newPlatformMXBeanProxy ( server , " com . sun . management : type = HotSpotDiagnostic " , HotSpotDiagnosticMXBean . class ); hotspotMBean . dumpHeap ( " heapdump . hprof " , true );

K´ od je specifick´ y pro Oracle HotSpot VM [38] a neobsahuje oˇsetˇren´ı v´ yjimek. Stav pamˇeti je uloˇzen do souboru heapdump.hprof“. ” Také pomoc´ı tohoto n´ astroje se mi podaˇrilo detekovat v´ yznamn´ y problém v k´ odu, viz kapitola 4.10.3.

4.6

Optimalizace

Optimalizace jsou u ´pravy systému za u ´ˇcelem zlepˇsen´ı jeho v´ ykonu a sn´ıˇzen´ı nárok˚ u na systémové zdroje (pamˇet’, ˇcas). Provád´ı se na základˇe pˇredchoz´ı anal´ yzy k´ odu. Pro vyhodnocen´ı efektu optimalizac´ı je potˇreba m´ıt v´ ykonnostn´ı testy, které mˇeˇr´ı v´ ykonnost jednotliv´ ych verz´ı systému s dostateˇcnou pˇresnost´ı.

4.6.1

Mˇ eˇ ren´ı efektu optimalizac´ı

Pomoc´ı v´ ykonnostn´ıch test˚ u lze srovnávat jednotlivé verze systému a sledovat vliv kaˇzdé zmˇeny na v´ ykonnost. K vyhodnocen´ı jednotliv´ ych zmˇen lze srovnat v´ ykonnost aktu´ aln´ı verze s verz´ı pˇredchoz´ı. D´ıky testován´ı systému po kaˇzdé zmˇenˇe lze odhalit zmˇeny, které zp˚ usobily sn´ıˇzen´ı v´ ykonnosti systému a tyto zmˇeny odstranit. D´ılˇc´ı zmˇeny maj´ı obvykle mal´ y efekt na v´ ykonnost. Celkov´ y efekt optimalizac´ı se proto vyhodnocuje souhrnnˇe pro sérii zmˇen. K vyhodnocen´ı slouˇz´ı srovn´ an´ı v´ ykonnosti aktu´ aln´ı verze s v´ ykonnost´ı poˇcáteˇcn´ı (bázové) verze systému. Po dosaˇzen´ı potˇrebného zv´ yˇsen´ı v´ ykonnosti nebo po uzavˇren´ı optimalizaˇcn´ıho cyklu je obvykle poˇc´ ateˇcn´ı verze posunuta na verzi aktuáln´ı. Optimalizace potom mohou pokraˇcovat v dalˇs´ım cyklu. Bˇehem optimalizaˇcn´ıho cyklu je potˇreba eliminovat zmˇeny funkˇcnosti systému, protoˇze ty mohou m´ıt podstatn´ y

32


Výkonnost Java aplikac´ı

vliv na statistiky v´ ykonnosti. Efekt optimalizac´ı by potom nebylo moˇzné vyhodnotit. Poˇc´ ateˇcn´ı verze pro mˇeˇren´ı v´ ykonnosti mus´ı b´ yt vˇzdy posunuta za zmˇeny funkˇcnosti.

4.6.2

´ Uroveˇ n optimalizace

Optimalizace lze prov´ adˇet na r˚ uzné u ´rovni: • design Optimalizace na u ´rovni designu aplikace zahrnuj´ı volbu efektivn´ıch algoritm˚ u a vhodn´ ych datov´ ych struktur. Na této u ´rovni lze obvykle dosáhnout nejvˇetˇs´ıho zlepˇsen´ı v´ ykonnosti. • programový k´ od Kvalita programového kódu m˚ uˇze také ovlivnit v´ ykonnost. Lze ji ovlivˇ nit volbou vhodn´ ych konstrukc´ı programovac´ıho jazyka. Casto je ovˇsem potˇreba udˇelat kompromis mezi v´ ykonnost´ı a ˇcitelnost´ı kódu. Dneˇsn´ı pˇrekladaˇce nav´ıc pouˇz´ıvaj´ı velmi efektivn´ı metody optimalizace, proto optimalizace na této u ´rovni nen´ı pˇr´ıliˇs efektivn´ı. • kompilace Dneˇsn´ı pˇrekladaˇce dok´ aˇzou v´ ykonnost aplikace v´ yraznˇe zv´ yˇsit. Optimalizace na této u ´rovni m˚ uˇze znamenat zmˇenu pˇrekladaˇce nebo nastaven´ı jeho optimalizaˇcn´ıch parametr˚ u. V´ ysledn´ y rozd´ıl v´ ykonnosti m˚ uˇze b´ yt zásadn´ı. • bˇeh Interpretované jazyky, jako napˇr´ıklad Java, provádˇej´ı kompilaci za bˇehu pomoc´ı tzv. JIT (just-in-time) pˇrekladaˇce. V´ yhodou tˇechto pˇrekladaˇc˚ u je moˇznost vyuˇzit´ı aktu´ aln´ıho vstupu k volbˇe vhodn´ ych optimalizac´ı. Na druhou stranu nen´ı moˇzné dosáhnout v´ ykonnosti nativn´ıch aplikac´ı kv˚ uli reˇzii s poˇc´ ateˇcn´ı interpretac´ı a následn´ ym pˇrekladem. Na této u ´rovni lze optimalizovat aplikaci volbou lepˇs´ıho virtuáln´ıho stroje nebo nastaven´ım parametr˚ u JIT pˇrekladaˇce.

4.7

V´ ykonnost Java aplikac´ı

Hlavn´ımi v´ ykonnostn´ımi ukazateli jsou doba v´ ypoˇctu a spotˇreba pamˇeti. V této kapitole se zamˇeˇr´ım bl´ıˇze na jejich specifika v Java aplikac´ıch.

4.7.1

Doba v´ ypoˇ ctu

Doba v´ ypoˇctu je obecnˇe ovlivnˇena mnoha faktory, jako je napˇr´ıklad v´ ykonnost hardware, reˇzie operaˇcn´ıho systému nebo zat´ıˇzen´ı systému ostatn´ımi aplikacemi. Z tˇechto d˚ uvod˚ u je jej´ı pˇresné mˇeˇren´ı vˇzdy obt´ıˇzné. Operaˇcn´ı systémy proto

33



poskytuj´ı prostˇredky k mˇeˇren´ı procesorového ˇcasu spotˇrebovaného konkrétn´ım procesem, kter´ y nˇekteré tyto vlivy alespoˇ n ˇcásteˇcnˇe eliminuje. Pro aplikaci v Javˇe je ale z´ıskán´ı informace o spotˇrebovaném procesorovém ˇcase obt´ıˇznˇe dosaˇziteln´ a. Lze ji z´ıskat pomoc´ı propojen´ı s nativn´ı knihovnou, coˇz s sebou nese dalˇs´ı reˇzii. Oproti nativn´ım aplikac´ım je tento ˇcas zkreslen reˇzi´ı virtu´ aln´ıho stroje. K dalˇs´ımu zkreslen´ı doby bˇehu v Javˇe docház´ı kv˚ uli ˇcinnosti garbage kolektoru (viz kapitola 4.7.3). Ten se spouˇst´ı z pohledu aplikace nepˇredv´ıdatelnˇe a bˇehem jeho ˇcinnosti je ˇcinnost aplikace obvykle zastavena. Velk´ y vliv na dobu v´ ypoˇctu má také JIT kompilátor, kter´ y provád´ı kompilaci do strojového k´ odu bˇehem v´ ypoˇctu. Na poˇcátku v´ ypoˇctu shromaˇzd’uje kompil´ ator statistiky, na z´ akladˇe kter´ ych m˚ uˇze provést optimalizace kódu. Potom je postupnˇe prov´ adˇena kompilace, která se projevuje postupn´ ym zrychlován´ım opakovan´ ych ˇc´ ast´ı k´ odu. Po urˇcité dobˇe kompilátor pˇrestává pracovat a rychlost opakovan´ ych ˇc´ ast´ı v´ ypoˇctu se ustál´ı. Moˇznostm´ı mˇeˇren´ı doby v´ ypoˇctu v Javˇe se podrobnˇe zab´ yvá kapitola 4.8.1.

4.7.2

Spotˇ reba pamˇ eti

V programovac´ıch jazyc´ıch niˇzˇs´ıch u ´rovn´ı, jako je napˇr´ıklad C++, se o alokaci a uvolˇ nov´ an´ı pamˇeti star´ a programátor. Z pohledu aplikace je proto jej´ı spotˇreba deterministick´ a a opakovatelná. Naproti tomu v Javˇe se o uvolˇ nován´ı pamˇeti star´ a garbage kolektor (viz kapitola 4.7.3). Ten funguje podle sv´ ych algoritm˚ u a z pohledu aplikace zcela nedeterministicky. Opakované proveden´ı stejného algoritmu na stejn´ ych datech m˚ uˇze proto m´ıt r˚ uznou spotˇrebu pamˇeti. Chov´ an´ı garbage kolektoru je dokonce ovlivnˇeno i dostupnou pamˇet´ı. Pokud je pamˇeti m´ alo, bude se kolektor spouˇstˇet ˇcastˇeji a maximáln´ı obsazená pamˇet’ bude niˇzˇs´ı. Je proto potˇreba jeˇstˇe definovat, co je myˇsleno spotˇrebou pamˇeti“ ” v Javˇe. Kromˇe pamˇeti obsazené kv˚ uli ˇcinnosti samotné aplikace je dalˇs´ı pamˇet’ obsazena v d˚ usledku ˇcinnosti virtuáln´ıho stroje. Tento druh pamˇeti by bylo moˇzné mˇeˇrit z extern´ı aplikace pomoc´ı prostˇredk˚ u operaˇcn´ıho systému. Pokud se rozhodneme mˇeˇrit pamˇet’ spotˇrebovanou pouze ˇcinnost´ı samotné aplikace, máme k dispozici prostˇredky virtu´ aln´ıho stroje k mˇeˇren´ı pamˇeti alokované na haldˇe. Obt´ıˇznˇe mˇeˇriteln´ a je pamˇet’ na zásobn´ıku. Moˇznostmi mˇeˇren´ı spotˇreby pamˇeti v Java aplikaci se podrobnˇe zab´ yvá kapitola 4.8.2.

34


4.7.3


Garbage kolektor

ˇ Cinnost garbage kolektoru je jeden z hlavn´ıch faktor˚ u ovlivˇ nuj´ıc´ıch v´ ykonnost aplikac´ı v Javˇe a jej´ı mˇeˇren´ı. Jeho u ´kolem je uvolˇ novat objekty, které uˇz nejsou potˇreba. Z pohledu garbage kolektoru to jsou ty objekty, které jiˇz nejsou dosaˇzitelné pomoc´ı referenc´ı z bˇeˇz´ıc´ıho programu. Algoritm˚ u pro identifikaci nedosaˇziteln´ ych objekt˚ u je v´ıce a reálnˇe se pouˇz´ıvá nˇekolik druh˚ u garbage kolektor˚ u [30]. Nejv´ yraznˇeji lze algoritmy rozdˇelit na: • sériové Sériové algoritmy vyˇzaduj´ı pozastaven´ı aplikace bˇehem jejich provádˇen´ı. Jsou vhodné pro vˇetˇsinu aplikac´ı, proto se následuj´ıc´ı text bude zamˇeˇrovat pˇredevˇs´ım na nˇe. • paraleln´ı Paraleln´ı algoritmy funguj´ı paralelnˇe s bˇeˇz´ıc´ı aplikac´ı. Odstraˇ nuj´ı nedeterministick´ a zpomalen´ı aplikace, coˇz m˚ uˇze b´ yt uˇziteˇcné u aplikac´ı reálného ˇcasu nebo aplikac´ı citliv´ ych na zpoˇzdˇen´ı. Jejich pouˇzit´ı má ale i své nev´ yhody, jako je napˇr´ıklad niˇzˇs´ı efektivita. V nov´ ych verz´ıch Javy se virtuáln´ı stroj snaˇz´ı volit optimáln´ı garbage kolektor, velikost haldy, nastaven´ı JIT pˇrekladaˇc a dalˇs´ı parametry podle typu poˇc´ıtaˇce. Konfiguraci lze vynutit zadán´ım parametr˚ u virtuáln´ıho stroje.

Algoritmy garbage kolektoru Algoritmy garbage kolektoru ˇreˇs´ı pˇredevˇs´ım problém nalezen´ı nedosaˇziteln´ ych objekt˚ u. Primitivn´ı algoritmus je velmi jednoduch´ y. Kolektor nejprve vytvoˇr´ı seznam pˇr´ımo dosaˇziteln´ ych objekt˚ u (objekty odkazované ze zásobn´ıku). Potom pomoc´ı proch´ azen´ı grafu tvoˇreného referencemi mezi objekty oznaˇc´ı vˇsechny navˇst´ıvené objekty. Vˇsechny ostatn´ı objekty, které z˚ ustaly neoznaˇcené, jsou nedosaˇzitelné a kolektor je m˚ uˇze uvolnit. Problémem tohoto primitivn´ıho algoritmu je jeho ˇcasová nároˇcnost. Reálné algoritmy se snaˇz´ı pouˇz´ıvat r˚ uzné heuristické metody ke zv´ yˇsen´ı rychlosti vyhled´ av´ an´ı. D˚ usledkem heuristick´ ych metod je nalezen´ı pouze nˇekter´ ych nepotˇrebn´ ych objekt˚ u. Nepotˇrebné objekty mohou proto pˇreˇz´ıt i nˇekolik bˇeh˚ u kolektoru. Z´ akladn´ı heuristickou metodou je zaveden´ı generac´ı objekt˚ u. Tato metoda vych´ az´ı z pozorov´ an´ı, ˇze naprostá vˇetˇsina objekt˚ u pˇrestává b´ yt potˇrebná velmi kr´ atce po svém vzniku. Naopak objekty, které pˇreˇzij´ı pˇres urˇcitou ˇcasovou mez, z˚ ust´ avaj´ı obvykle potˇrebné jeˇstˇe velmi dlouho. Kolektor se proto zamˇeˇruje zejména na vyhled´ av´ an´ı mezi mlad´ ymi objekty. V praxi se pouˇz´ıvaj´ı tˇri generace objekt˚ u: mladá (young), starˇs´ı (tenured) a permanentn´ı (permanent) – obrázek 4.1 Kolektor vyhledává objekty po jednotliv´ ych generac´ıch, vˇzdy kdyˇz se daná generace napln´ı. 35



Novˇe alokované objekty pˇrib´ yvaj´ı do mladé generace. Po naplnˇen´ı mladé generace je spuˇstˇena minoritn´ı kolekce (minor collection), která se zamˇeˇruje pouze na mladou generaci. Obvykle je moˇzné vˇetˇsinu objekt˚ u uvolnit, ty zbylé se pˇresunou do prostoru pˇreˇzivˇs´ıch (souˇcást mladé generace). Prostory pˇreˇzivˇs´ıch jsou v mladé generaci dva, jeden je vˇzdy prázdn´ y. Bˇehem prov´ adˇen´ı minoritn´ı kolekce se pˇreˇzivˇs´ı objekty pˇresouvaj´ı do prázdného prostoru pˇreˇzivˇs´ıch a p˚ uvodn´ı obsazen´ y prostor pˇreˇzivˇs´ıch se vyprázdn´ı. Po urˇcitém mnoˇzstv´ı pˇresun˚ u objektu, nebo pokud je prostor pˇreˇzivˇs´ıch zaplnˇen, je objekt posl´ an do starˇs´ı generace. Po naplnˇen´ı starˇs´ı generace doje k plné kolekci (full/major collection). Ta trv´ a déle a zab´ yv´ a se objekty v mladé i starˇs´ı generaci. Konkrétn´ı algoritmus vyhled´ av´ an´ı objekt˚ u m˚ uˇze b´ yt pro kaˇzd´ y typ kolekce jin´ y.

Obr´ azek 4.1: Generace objekt˚ u. Obrázek byl pˇrevzat z [30].

Nastaven´ı garbage kolektoru V´ ykonnost garbage kolektoru je velmi závislá na velikosti jednotliv´ ych generac´ı. Proto se v r´ amci ˇcinnosti kolektoru tyto velikosti dodateˇcnˇe upravuj´ı, aby mohl ˇ ım je velikost mladé generace vyˇsˇs´ı, t´ım je vyˇsˇs´ı kolektor fungovat optim´ alnˇe. C´ také efektivita kolektoru. Na druhou stranu se zároveˇ n prodluˇzuj´ı pauzy aplikace pˇri spuˇstˇen´ı kolektoru. Velikost prostoru pˇreˇzivˇs´ıch má na v´ ykonnost kolektoru menˇs´ı vliv. Velikost generac´ı a dalˇs´ı konfiguraci chován´ı garbage kolektoru lze upravovat pomoc´ı parametr˚ u virtu´ aln´ıho stroje. Nˇekteré uˇziteˇcné parametry: • -verbose:gc Vypisuje informace o kaˇzdém spuˇstˇen´ı garbage kolektoru. • -XX:+PrintGCDetails, -XX:+PrintGCTimeStamps Rozˇsiˇruje informativn´ı v´ ypisy o ˇcinnosti kolektoru o dalˇs´ı informace.

36

Vyuˇzit´ı Automatizovan´ kompar´ ator˚ u na e metody malých mˇ zaˇ erˇr´ızen´ en´ııch výkonnostn´ıch parametr˚ u Java aplikac´ı

• -Xmx Nastavuje maxim´ aln´ı velikost haldy (reserved) a t´ım ovlivˇ nuje maximáln´ı velikost generac´ı. • -Xms Nastavuje prvotn´ı a z´ aroveˇ n minimáln´ı velikost haldy a t´ım ovlivˇ nuje minim´ aln´ı velikost generac´ı. • -XX:MinHeapFreeRation, -XX:MaxHeapFreeRatio Definuje optim´ aln´ı aktu´ aln´ı velikost haldy na základˇe pomˇeru volného a obsazeného prostoru. Pˇri kaˇzdém bˇehu kolektoru m˚ uˇze b´ yt aktuáln´ı velikost haldy pˇrizp˚ usobena v mez´ıch maximáln´ı a minimáln´ı velikosti. • -XX:NewRatio Pomˇer mladé a starˇs´ı generace. • -XX:NewSize, -XX:MaxNewSize Omezen´ı velikosti mladé generace zdola a shora. • -XX:SurvivorRatio Upravuje velikost prostoru pro pˇreˇzivˇs´ı. Pokud je pomoc´ı parametr˚ u -Xmx a -Xms nastavena velikost haldy na shodnou (nemˇennou) hodnotu, stane se chován´ı garbage kolektoru lépe pˇredv´ıdatelné, protoˇze se nebudou provádˇet zmˇeny aktuáln´ı velikosti haldy a generac´ı. Pokud je nastavena velikost mladé generace pomoc´ı -XX:NewSize na pˇr´ıliˇs vysokou hodnotu, bude znemoˇznˇeno provádˇen´ı minoritn´ı kolekce a kaˇzdá kolekce bude pln´ a. Vol´ an´ı metody System.gc() naplánuje vˇzdy plnou kolekci.

4.8

4.8.1

Automatizovan´ e metody mˇ eˇ ren´ı v´ ykonnostn´ıch parametr˚ u Java aplikac´ı Metody mˇ eˇ ren´ı doby v´ ypoˇ ctu

Z´ akladem mˇeˇren´ı doby v´ ypoˇctu je zjiˇstˇen´ı aktuáln´ıho ˇcasu pˇred v´ ypoˇctem, zjiˇstˇen´ı aktu´ aln´ıho ˇcasu po v´ ypoˇctu a jejich odeˇcten´ı. Jednotlivé metody se liˇs´ı pouze ve zp˚ usobu, jak´ ym je z´ıskán aktuáln´ı ˇcas.

Metody z´ısk´ an´ı aktu´ aln´ıho ˇ casu Nejvhodnˇejˇs´ı by bylo mˇeˇrit dobu v´ ypoˇctu pomoc´ı procesorového ˇcasu, tj. ˇcasu bˇehu procesu na procesoru. Tento ˇcas by mˇel dávat nejstálejˇs´ı v´ ysledky pˇri opakov´ an´ı testu, protoˇze nen´ı pˇr´ıliˇs ovlivnˇen ostatn´ımi procesy v systému. V Javˇe je ale problém tento ˇcas z´ıskat. Pouˇzit´ım management API dostupn´ ym 37


v Javˇe lze sice tento ˇcas z´ıskat, ale pouze s n´ızk´ ym rozliˇsen´ım. Mˇeˇren´ım bylo zjiˇstˇeno rozliˇsen´ı (nejmenˇs´ı interval) 15,6 milisekund. Kód z´ıskán´ı ˇcasu: long time = ManagementFactory . getThreadMXBean () . getCurrentThreadCpuTime ();

Druhou alternativou je mˇeˇrit reáln´ y ˇcas, kter´ y lze v Javˇe z´ıskat bud’ v milisekund´ ach, nebo v nanosekundách. Kód z´ıskán´ı ˇcasu v milisekundách: long time = System . currentTimeMillis ();

Rozliˇsen´ı tohoto ˇcasu je 1 milisekunda. Pˇresnost pro mˇeˇren´ı krátk´ ych u ´sek˚ u je ale omezena kv˚ uli obˇcasnému provádˇen´ı synchronizace. Nejpˇresnˇejˇs´ı je tˇret´ı zp˚ usob z´ıskáván´ı ˇcasu, v nanosekundách: long time = System . nanoTime ();

Rozliˇsen´ı tohoto ˇcasu je pouh´ ych 513 nanosekund. Tento zp˚ usob je pˇr´ımo urˇcen pro mˇeˇren´ı kr´ atk´ ych ˇcasov´ ych interval˚ u. Uv´ adˇen´ a rozliˇsen´ı jednotliv´ ych ˇcas˚ u se mohou na r˚ uzn´ ych poˇc´ıtaˇc´ıch liˇsit. Procesorov´ y ˇcas nemus´ı b´ yt podporovan´ y v˚ ubec.

Vybran´ a metoda z´ısk´ an´ı aktu´ aln´ıho ˇ casu Vybran´ a metoda kombinuje v´ yhody procesorového ˇcasu a reálného ˇcasu v nanosekund´ ach. Z´ akladem je mˇeˇren´ı ˇcasu v nanosekundách, které poskytuje v´ ysledky s vysok´ ym rozliˇsen´ım. V´ ysledek je vˇzdy porovnán s v´ ysledkem z´ıskan´ ym mˇeˇren´ım procesorového ˇcasu. Pokud se v´ ysledky pˇr´ıliˇs liˇs´ı (o nastavené procento), je v´ ysledek ignorov´ an a mˇeˇren´ı opakováno. T´ım je ˇcásteˇcnˇe eliminován vliv ostatn´ıch proces˚ u v systému.

Metodika mˇ eˇ ren´ı ˇ bude mˇeˇren na delˇs´ıch f´ Cas az´ıch v´ ypoˇctu, konkrétnˇe u komparátor˚ u se bude jednat o f´ azi naˇcten´ı reprezentac´ı a fázi porovnán´ı. Pˇresnost mˇeˇren´ı m˚ uˇze ovlivnit také spuˇstˇen´ı garbage kolektoru, proto je nutné jeho spuˇstˇen´ı bˇehem mˇeˇren´ı zabr´ anit (popis implementace bude popsán v kapitole 4.8.3). Pˇred samotn´ ym mˇeˇren´ım je nutné nˇekolikrát v´ ypoˇcet provést, aby se eliminoval vliv JIT kompil´ atoru. Druhou moˇznost´ı je JIT kompilaci vypnout pomoc´ı pˇrep´ınaˇce virtu´ aln´ıho stroje -Xint.

4.8.2

Metody mˇ eˇ ren´ı spotˇ reby pamˇ eti

Spotˇreba pamˇeti, podobnˇe jako doba v´ ypoˇctu, bude také mˇeˇrena pro jednotlivé f´ aze v´ ypoˇctu. Jej´ı mˇeˇren´ı je ale sloˇzitˇejˇs´ı, protoˇze se (obecnˇe) m˚ uˇze bˇehem mˇe38


ˇrené f´ aze nepˇredv´ıdatelnˇe mˇenit. Bude proto nutné bl´ıˇze specifikovat, co je pod pojmem spotˇreba pamˇeti“ myˇsleno. ” Aktu´ alnˇ e obsazen´ a pamˇ et’ O trochu jednoduˇsˇs´ım problémem je zjiˇstˇen´ı spotˇreby pamˇeti v jednom okamˇziku, neboli zjiˇstˇen´ı aktu´ alnˇe obsazené pamˇeti. Metod k jej´ımu z´ıskán´ı je nˇekolik. Prvn´ım zp˚ usobem je z´ısk´ an´ı obsazené pamˇeti prostˇrednictv´ım tˇr´ıdy Runtime: long memory = Runtime . getRuntime (). totalMemory () - Runtime . getRuntime (). freeMemory ();

Tento zp˚ usob nen´ı pˇr´ıliˇs pˇresn´ y (nemá dostateˇcné rozliˇsen´ı). Stejn´ ym problémem trp´ı i druh´ y zp˚ usob, kter´ ym je pouˇzit´ı management API Javy: long memory = ManagementFactory . getMemoryMXBean () . getHeapMemoryUsage (). getUsed ();

Uk´ azalo se, ˇze nejlepˇs´ı metodou je z´ıskán´ı obsazené pamˇeti z informac´ı garbage kolektoru dostupn´ ych pˇres management API: com . sun . management . GarbageCollectorMXBean sunBean1 = ( com . sun . management . GarbageCollectorMXBean ) ManagementFactory . g et Ga rb ag eC ol le ct or MX Be ans (). get (1); long memoryBeforeGC = 0; long memoryAfterGC = 0; GcInfo info = sunBean1 . getLastGcInfo (); for ( MemoryUsage e : info . getMemoryUsageBeforeGc (). values ()){ memoryBeforeGC += e . getUsed (); } for ( MemoryUsage e : info . getMemoryUsageAfterGc (). values ()){ memoryAfterGC += e . getUsed (); }

Tento k´ od funguje pouze pro virtuáln´ı stroj Oracle HotSpot VM [38]. Na zaˇc´ atku je z´ısk´ ana bean tˇr´ıda s informacemi o garbage kolektoru provádˇej´ıc´ıho plnou kolekci. (V systému jsou dva kolektory, kolektor na indexu 0 obstarává minoritn´ı kolekci.) Bean tˇr´ıda je pˇretypována na speciáln´ı rozhran´ı pro HotSpot VM kolektor. D´ıky tomu je moˇzné z´ıskat informace o posledn´ı kolekci (GcInfo). Informace obsahuj´ı obsazenou pamˇet’ pro jednotlivé generace a prostory pˇred a po proveden´ı kolekce. Pro spr´ avnou funkci k´ odu je potˇreba nastavit pouˇzit´ı sériového garbage kolektoru. K´ od z´ısk´ a hodnotu obsazené pamˇeti v dobˇe pˇred a po spuˇstˇen´ı garbage kolektoru. Pro z´ısk´ an´ı pamˇeti v libovolném okamˇziku v´ ypoˇctu staˇc´ı vynutit spuˇstˇen´ı kolektoru v tomto okamˇziku (implementace je popsána v kapitole 4.8.3). Dalˇs´ı metoda pouˇz´ıv´ au ´plnˇe jin´ y pˇr´ıstup, neˇz metody pˇredchoz´ı. Z popisovan´ ych metod je tato metoda nejpˇresnˇejˇs´ı, ale také nejnároˇcnˇejˇs´ı na implementaci, 39


proto nakonec nebyla v této práci pouˇzita. Základem je sledován´ı vzniku a zániku jednotliv´ ych objekt˚ u a udrˇzován´ı souˇctu jejich velikost´ı [39]. Velikost objektu lze napˇr´ıklad zjistit souˇctem velikost´ı vˇsech jeho pol´ı, které lze z´ıskat pouˇzit´ım reflexe. Pˇresnˇejˇs´ıho v´ ysledku lze doc´ılit pouˇzit´ım instrumentace [19]. Sledov´ an´ı vzniku objekt˚ u lze implementovat pomoc´ı aspekt˚ u, které mohou b´ yt nav´ az´ any na vol´ an´ı konstruktoru. Sledován´ı zániku objekt˚ u lze implementovat pomoc´ı tzv. phantom referenc´ı (popsáno v kapitole 4.8.3).

Definice spotˇ reby pamˇ eti v´ ypoˇ ctu Nyn´ı je jiˇz vyjasnˇena metoda mˇeˇren´ı obsazené pamˇeti v jednom okamˇziku, stále je ale v´ıce moˇznost´ı definice spotˇreby pamˇeti celého v´ ypoˇctu nebo jeho fáze. Nelze bez u ´prav vyuˇz´ıt jednoduch´ y algoritmus mˇeˇren´ı doby v´ ypoˇctu a vypoˇc´ıtat spotˇrebu jen jako rozd´ıl obsazené pamˇeti na zaˇcátku a na konci v´ ypoˇctu. Zmˇeny obsazené pamˇeti jsou ovlivnˇeny ˇcinnost´ı garbage kolektoru. I kdyby se jednalo o jazyk bez garbage kolektoru, pro dokonal´ y popis spotˇreby pamˇeti v ˇcasovém u ´seku je potˇreba funkce, nikoliv jedna hodnota. Funkce je ale nepraktick´ a pro u ´ˇcely vyhodnocen´ı efektu optimalizac´ı. Proto je potˇreba tuto funkci pˇrevést na jednu nebo nˇekolik hodnot, které ponesou co nejd˚ uleˇzitˇejˇs´ı informace o spotˇrebˇe pamˇeti. Intuitivnˇe je spotˇreba pamˇeti obvykle vn´ımána jako minimáln´ı pamˇet’ potˇrebn´ a pro bˇeh v´ ypoˇctu. Pokud by se jednalo o program v jazyce bez garbage kolektoru, pak by bylo moˇzné tuto spotˇrebu definovat jako maximum aktuálnˇe alokované pamˇeti bˇehem doby v´ ypoˇctu. Správa pamˇeti pomoc´ı garbage kolektoru ale mˇeˇren´ı takové spotˇreby témˇeˇr znemoˇzn ˇuje a pro praktické u ´ˇcely hodnota této informace kles´ a. Pokud bychom se rozhodli ji pˇresto mˇeˇrit, bylo by to moˇzné jen s omezenou pˇresnost´ı. Pˇresnost je omezena hlavnˇe z d˚ uvodu velké reˇzie garbage kolektoru (nelze ho spouˇstˇet pˇr´ıliˇs ˇcasto) a jeho nepˇredv´ıdatelného chován´ı (nˇekteré nedosaˇzitelné objekty nemus´ı b´ yt pˇri kolekci uvolnˇeny). Pˇresnost by se teoreticky dala zv´ yˇsit nalezen´ım vlastn´ıho mechanismu zjiˇst’ován´ı nedosaˇziteln´ ych objekt˚ u. Princip spoˇc´ıv´ a v dostateˇcnˇe ˇcastém mˇeˇren´ı obsazené pamˇeti (napˇr´ıklad na zaˇc´ atku a na konci kaˇzdé metody) a zavolán´ı garbage kolektoru vˇzdy, kdyˇz se spotˇreba zv´ yˇs´ı nad urˇcit´ y práh. Po proveden´ı kolekce se pˇr´ıpadnˇe hodnota prahu zv´ yˇs´ı na spotˇrebu pamˇeti po kolekci plus nˇejak´ y krok, kter´ y urˇc´ıme podle poˇzadovaného rozliˇsen´ı. K ˇcastému mˇeˇren´ı pamˇeti nelze vyuˇz´ıt metodu spojenou s garbage kolektorem. Pokud by n´ am staˇcilo niˇzˇs´ı rozliˇsen´ı, m˚ uˇzeme pouˇz´ıt nˇekterou z prvn´ıch dvou popsan´ ych metod pro mˇeˇren´ı aktuálnˇe obsazené pamˇeti. Pro zlepˇsen´ı rozliˇsen´ı by byla nejvhodnˇejˇs´ı metoda posledn´ı, která vyuˇz´ıvá aspekty. Pomoc´ı aspekt˚ u by bylo také moˇzné zajistit spuˇstˇen´ı mˇeˇren´ı na zaˇcátku a na konci kaˇzdé

40


metody. Abychom mˇeˇren´ı co nejv´ıce urychlili, m˚ uˇzeme v´ ypoˇcet testovat nˇekolikr´ at a vˇzdy zpˇresnit krok a nastavit pˇresnˇejˇs´ı poˇcáteˇcn´ı práh. T´ım se sn´ıˇz´ı poˇcet spuˇstˇen´ı garbage kolektoru, coˇz je ˇcasovˇe nároˇcná operace. Metoda nebyla v této pr´ aci vyuˇzita, zejména kv˚ uli sloˇzitosti jej´ı implementace a d´ıky pouˇzitelnosti n´ asleduj´ıc´ıch popsan´ ych definic spotˇreby pamˇeti. Druhou moˇznost´ı je definovat spotˇrebu pamˇeti jako celkové mnoˇzstv´ı alokované pamˇeti v dané f´ azi v´ ypoˇctu. I takto definovaná spotˇreba má dobrou informaˇcn´ı hodnotu, protoˇze velikost alokované pamˇeti ovlivˇ nuje ˇcetnost spouˇstˇen´ı garbage kolektoru, a t´ım je ovlivnˇena také doba v´ ypoˇctu. Mˇeˇren´ı této spotˇreby je velmi jednoduché za pˇredpokladu, ˇze pˇred v´ ypoˇctem je uvolnˇena veˇskerá pamˇet’ z pˇredchoz´ıch v´ ypoˇct˚ u a bˇehem v´ ypoˇctu nedojde ke spuˇstˇen´ı garbage kolektoru. Jak toho doc´ılit je pops´ ano v kapitole 4.8.3. Potom staˇc´ı jen zmˇeˇrit aktuáln´ı obsazenou pamˇet’ na zaˇc´ atku a na konci v´ ypoˇctu a hodnoty odeˇc´ıst. Tˇret´ı definice bere spotˇrebu pamˇeti v´ ypoˇctu jako pamˇet’ obsazenou v´ ypoˇctem vytvoˇren´ ymi datov´ ymi strukturami. Jej´ı mˇeˇren´ı je velmi podobné jako v pˇredchoz´ı definici, pouze je po v´ ypoˇctu mˇeˇrena pamˇet’ aˇz po spuˇstˇen´ı garbage kolektoru. Hodnoty spotˇreby podle druhé a tˇret´ı definice jsou horn´ım a doln´ım odhadem pro spotˇrebu podle prvn´ı definice.

4.8.3

Jak ovl´ adat garbage kolektor

Detekce spuˇ stˇ en´ı garbage kolektoru Spuˇstˇen´ı garbage kolektoru lze sledovat d´ıky informativn´ım v´ ypis˚ um, které lze vynutit zad´ an´ım parametru virtuáln´ıho stroje (kapitola 4.7.3). Programovˇe lze spuˇstˇen´ı detekovat s vyuˇzit´ım management API: long count = 0; for ( GarbageCollectorMXBean bean : ManagementFactory . g et Ga rb ag eC ol le ct or MX Be an s ()) { count += bean . getCollectionCount (); }

Uveden´ y k´ od zjiˇst’uje celkov´ y poˇcet spuˇstˇen´ı garbage kolektoru od spuˇstˇen´ı aplikace. Pokud se poˇcet pˇred v´ ypoˇctem liˇs´ı od poˇctu po proveden´ı v´ ypoˇctu, doˇslo bˇehem v´ ypoˇctu ke spuˇstˇen´ı garbage kolektoru.

Jak vynutit spuˇ stˇ en´ı garbage kolektoru Zavol´ an´ı metody System.gc() naplánuje spuˇstˇen´ı garbage kolektoru. Ten je spuˇstˇen asynchronnˇe. Na jeho spuˇstˇen´ı je ale moˇzné poˇckat, napˇr´ıklad pomoc´ı phantom referenc´ı. Phantom reference [36] obsahuje referenci na libovoln´ y objekt, která je ignorov´ ana garbage kolektorem. Pokud je objekt dosaˇziteln´ y pouze pomoc´ı phantom 41

Vyuˇzit´ı kompar´ ator˚ Implementace u na malých zaˇ mˇ re´ızen´ ˇren´ııch výkonnostn´ıch parametr˚ u kompar´ atoru

referenc´ı, m˚ uˇze b´ yt uvolnˇen. Na událost uvolnˇen´ı objektu lze dokonce reagovat, proto lze tyto reference vyuˇz´ıt k proveden´ı u ´klidov´ ych operac´ı. Tato metoda je implementována v knihovnˇe jlibs [7], která poskytuje jednoduché rozhran´ı pro synchronn´ı zavolán´ı garbage kolektoru: jlibs . core . lang . RuntimeUtil . gc ();

Metodu je tˇreba pouˇz´ıvat opatrnˇe, protoˇze ˇcekán´ı na garbage kolektor v´ yraznˇe prodluˇzuje dobu v´ ypoˇctu (testu).

Jak zabr´ anit spuˇ stˇ en´ı garbage kolektoru Spolehlivˇe zabr´ anit spuˇstˇen´ı garbage kolektoru nelze, ale m˚ uˇzeme minimalizovat jeho pravdˇepodobnost a pˇr´ıpadné spuˇstˇen´ı detekovat. Základem je zajiˇstˇen´ı dostatku volné pamˇeti pro v´ ypoˇcet. Pomoc´ı parametr˚ u virtuáln´ıho stroje -Xms a -Xmx lze nastavit dostateˇcnˇe vysokou hodnotu minimáln´ı a maximáln´ı velikosti pamˇeti. Pomoc´ı parametr˚ u -XX:NewSize a -XX:MaxNewSize podobnˇe nastav´ıme dostateˇcnou velikost mladé generace. Pˇred v´ ypoˇctem uvoln´ıme pamˇet’ synchronn´ım zavolán´ım garbage kolektoru. Po proveden´ı v´ ypoˇctu zkontrolujeme, zda se bˇehem v´ ypoˇctu garbage kolektor nespustil. Pokud ano, ignorujeme v´ ysledek testu a test zopakujeme.

Jak donutit garbage kolektor uvolnit nepotˇ rebnou pamˇ et’ Spuˇstˇen´ı garbage kolektoru (vˇcetnˇe plné kolekce) negarantuje uvolnˇen´ı veˇskeré nedosaˇzitelné pamˇeti. Experimentálnˇe jsem nalezla zp˚ usob, jak uvolnit vˇetˇsinu pamˇeti z pˇredchoz´ıch v´ ypoˇct˚ u. Metoda spoˇc´ıv´ a v zaplnˇen´ı veˇskeré pamˇeti aˇz do vyhozen´ı chyby OutOfMemoryError a n´ asledném zavol´ an´ı garbage kolektoru. Pamˇet’ nejprve pln´ım bloky o velikosti 1 MB, poté i vˇetˇs´ımi bloky. Fungován´ı metody bylo ovˇeˇreno ziskem dostateˇcnˇe pˇresn´ ych v´ ysledk˚ u mˇeˇren´ı spotˇreby pamˇeti (kapitola 4.8.2).

4.9

4.9.1

Implementace mˇ eˇ ren´ı v´ ykonnostn´ıch parametr˚ u kompar´ atoru ´ cel implementace Uˇ

Pro vyhodnocen´ı efektu optimalizac´ı, které jsou u ´kolem této práce, jsem vytvoˇrila aplikaci pro v´ ykonnostn´ı testy komparátoru. Efekt provádˇen´ ych optimalizac´ı je moˇzné sledovat po kaˇzdé zmˇenˇe kódu a celkov´ y v´ ysledek je z´ıskán z porovn´ an´ı v´ ykonnosti koneˇcné a poˇcáteˇcn´ı verze kódu. Efekt optimalizac´ı lze vyˇc´ıst z pˇrehledného reportu generovaného aplikac´ı. 42


Testovac´ı aplikaci jsem integrovala také do procesu plynulé integrace zajiˇst’ované aplikac´ı Hudson. Spuˇstˇen´ım aplikace na zat´ıˇzeném serveru se sice zkresluj´ı v´ ysledky doby v´ ypoˇctu, ale pˇresnost mˇeˇren´ı spotˇreby pamˇeti z˚ ustává zachována. V´ ykonnost kompar´ ator˚ u bude moˇzné sledovat i v budoucnu po ukonˇcen´ı této pr´ ace.

4.9.2

V´ ystup testovac´ı aplikace

Aplikace generuje dvˇe pˇrehledné tabulky (viz kapitola 4.10.4) pro kaˇzdou mˇeˇrenou f´ azi v´ ypoˇctu. Pro u ´ˇcely komparátor˚ u byl v´ ypoˇcet rozdˇelen do dvou fáz´ı, na f´ azi naˇcten´ı reprezentace ( loader“) a fázi porovnán´ı ( cmp“). ” ” ˇ R´ adky tabulek obsahuj´ı namˇeˇrené v´ ysledky pro r˚ uzné metody mˇeˇren´ı. Aplikace mˇeˇr´ı dobu bˇehu v´ ypoˇctu, celkovou alokovanou pamˇet’ a pamˇet’ obsazenou v´ ysledn´ ymi datov´ ymi strukturami. Prvn´ı tabulka obsahuje absolutn´ı namˇeˇrené hodnoty v jednotliv´ ych verz´ıch k´ odu. Druh´ a tabulka obsahuje pouze dva sloupce s daty. V´ yznam prvn´ıho sloupce je zlepˇsen´ı aktu´ aln´ı verze oproti verzi pˇredchoz´ı. V´ yznam druhého sloupce je zlepˇsen´ı aktu´ aln´ı verze oproti verzi poˇcáteˇcn´ı. V´ ysledky v tabulk´ ach jsou vypoˇc´ıtány vˇzdy ze sady test˚ u pomoc´ı jednoduch´ ych statistick´ ych metod. V´ ysledky jednotliv´ ych test˚ u jsou dostupné ve form´ atu XML.

4.9.3

Architektura

Aplikace je spouˇstˇena formou JUnit [12] test˚ u. Tento zp˚ usob byl zvolen hlavnˇe z d˚ uvodu snadnˇejˇs´ı integrace do Hudsonu. Proces testován´ı nav´ıc m˚ uˇze selhat, kdyˇz nen´ı moˇzné doc´ılit dostateˇcné pˇresnosti mˇeˇren´ı (napˇr. kv˚ uli ˇspatné konfiguraci nebo zat´ıˇzen´ı poˇc´ıtaˇce). V takovém pˇr´ıpadˇe je vyhozen´ım v´ yjimky doc´ıleno selh´ an´ı unit testu. V procesu testov´ an´ı maj´ı hlavn´ı u ´lohu dva typy objekt˚ u: testovac´ı pˇr´ıpad (PerfTestCase) a tester (Tester). Testovac´ı pˇr´ıpad obsahuje implementaci testovaného v´ ypoˇctu. Tester implementuje metodu mˇeˇren´ı, tj. z´ıskán´ı hodnoty mˇeˇrené veliˇciny pˇred mˇeˇrenou f´ az´ı v´ ypoˇctu a po n´ı. Tester dále rozhoduje o potˇrebném poˇctu opakov´ an´ı v´ ypoˇctu kaˇzdého testovac´ıho pˇr´ıpadu a o u ´spˇechu nebo ne´ uspˇechu mˇeˇren´ı. Aplikace obsahuje nˇekolik metod mˇeˇren´ı, které jsou implementované jednotliv´ ymi testery. Pomoc´ı ˇr´ıd´ıc´ıho objektu jsou spuˇstˇeny testovac´ı pˇr´ıpady postupnˇe se vˇsemi testery. Testovac´ı pˇr´ıpad informuje testera o poˇcátku a konci jednotliv´ ych f´ az´ı v´ ypoˇctu. V´ ysledky test˚ u jsou od vˇsech tester˚ u hromadˇeny v objektu typu ResultsGatherer, kter´ y zajiˇst’uje jejich dalˇs´ı zpracován´ı a organizaci. Z namˇeˇren´ ych hodnot je napˇr´ıklad vypoˇc´ıt´ an pr˚ umˇer a dalˇs´ı statistické u ´daje. 43


4.9.4

Popis nˇ ekter´ ych metod d˚ uleˇ zit´ ych rozhran´ı

• void Tester.startPhase(String phaseName) Touto metodou oznamuje testovac´ı pˇr´ıpad testerovi, ˇze zaˇc´ıná fáze v´ ypoˇctu s n´ azvem dan´ ym parametrem phaseName. Tester provede u ´klidové operace a zah´ aj´ı mˇeˇren´ı. • void Tester.stopPhase(String message) Touto metodou oznamuje testovac´ı pˇr´ıpad testerovi, ˇze fáze v´ ypoˇctu konˇc´ı. Zpr´ ava pˇredan´ a parametrem upˇresˇ nuje okolnosti ukonˇcen´ı a je dohledateln´ a v XML v´ ystupu aplikace. Tester z´ıská v´ ysledky mˇeˇren´ı. • void Tester.initAccuracyChecking() Impuls od ˇr´ıd´ıc´ıho algoritmu, ˇze má tester zahájit kontrolu pˇresnosti mˇeˇren´ı. Pˇresnost je mˇeˇrena pro v´ıce jednotliv´ ych mˇeˇren´ı najednou, protoˇze jednotliv´ a mˇeˇren´ı d´ avaj´ı pˇr´ıliˇs malé vzorky pro kontrolu pˇresnosti. • boolean Tester.isAccuracyOk() ˇ ıd´ıc´ı algoritmus touto metodou zjiˇst’uje, zda mˇeˇren´ı probˇehlo u R´ ´spˇeˇsnˇe (s dostateˇcnou pˇresnost´ı). • int Tester.getRepeatCount() ˇ ıd´ıc´ı algoritmus touto metodou zjiˇst’uje, kolikrát je potˇreba kaˇzd´ R´ y testovac´ı pˇr´ıpad s pouˇzit´ım daného testera u ´spˇeˇsnˇe opakovat. R˚ uzné testovac´ı metody mohou vyˇzadovat r˚ uzné mnoˇzstv´ı poˇr´ızen´ ych dat pro dostateˇcnou pˇresnost mˇeˇren´ı. • void PerfTestCase.run(Tester tester) Testovac´ı pˇr´ıpad v této metodˇe implementuje testovan´ y v´ ypoˇcet. Testera z´ıskaného jako parametr metody informuje o jednotliv´ ych fáz´ıch v´ ypoˇctu. • void ResultsGatherer.addResult(String tester, String phaseName, double startVal, double endVal, String message) Metoda slouˇz´ı k pˇred´ an´ı v´ ysledku mˇeˇren´ı testera do objektu hromad´ıc´ıho v´ ysledky. Parametry metody jsou název testera (testovac´ı metody), název f´ aze v´ ypoˇctu, poˇc´ ateˇcn´ı namˇeˇrená hodnota, koneˇcná namˇeˇrená hodnota, zpr´ ava o zp˚ usobu ukonˇcen´ı v´ ypoˇctu. • void ResultsGatherer.acceptResultsAndReset() Metoda slouˇz´ı ke schv´ alen´ı vˇsech nov´ ych v´ ysledk˚ u mˇeˇren´ı. • void ResultsGatherer.reset() Metoda slouˇz´ı k odstranˇen´ı vˇsech neschválen´ ych v´ ysledk˚ u (z d˚ uvodu jejich nepˇresnosti). • void ResultsGatherer.computeStatistics() V´ ypoˇcet statistick´ ych u ´daj˚ u z namˇeˇren´ ych dat.

4.9.5

Implementace objekt˚ u typu Tester

• NanoTester NanoTester implementuje metodu pro mˇeˇren´ı doby v´ ypoˇctu popsanou v 44


kapitole 4.8.1. Maxim´ aln´ı moˇzná odchylka reálného a procesorového ˇcasu je parametrem konstruktoru. D´ıky tomu ji lze vhodnˇe zvolit podle pˇredpokládané doby v´ ypoˇctu. Dalˇs´ım parametrem konstruktoru je poˇcet opakován´ı test˚ u, kter´ y ovlivˇ nuje pˇresnost mˇeˇren´ı a dobu provádˇen´ı test˚ u. Konkrétn´ı nastaven´ı parametr˚ u pro r˚ uzné typy sad testovac´ıch pˇr´ıpad˚ u byly zvoleny na z´ akladˇe experiment˚ u s pˇresnost´ı mˇeˇren´ı. • MemoryTester MemoryTester implementuje dvˇe metody mˇeˇren´ı pamˇeti popsané v kapitole 4.8.2, mˇeˇren´ı celkové alokované pamˇeti a mˇeˇren´ı pamˇeti obsazené v´ ysledn´ ymi datov´ ymi strukturami. Metody jsou velmi pˇresné dokonce bez nutnosti mnoha opakov´ an´ı testu. Na základˇe experiment˚ u s pˇresnost´ı byl poˇcet opakov´ an´ı zvolen na 20. Odchylka celkového mˇeˇren´ı je niˇzˇs´ı neˇz 0,1 procenta. • NullTester NullTester je tester, kter´ y netestuje, ale slouˇz´ı pouze k opakovanému proveden´ı v´ ypoˇctu pˇred samotn´ ym mˇeˇren´ım. Bˇehem této doby se provede JIT kompilace a v´ ysledky n´ asledn´ ych mˇeˇren´ı budou ustálené.

4.9.6

Implementace objekt˚ u typu PerfTestCase

• BigTestCase Tento testovac´ı pˇr´ıpad je urˇcen pro z´ıskán´ı co nejpˇresnˇejˇs´ıch v´ ysledk˚ u za cenu dlouhé doby testov´ an´ı. V jednotliv´ ych fáz´ıch se provád´ı najednou naˇcten´ı a porovn´ an´ı nˇekolika komponent, které zajiˇst’uj´ı dostateˇcnou velikost testovac´ıch dat. • MicroTestCase Tento testovac´ı pˇr´ıpad provád´ı naˇcten´ı a porovnán´ı pouze jedné dvojice komponent. Je urˇcen zejména pro testován´ı bez JIT pˇrekladaˇce, které trvá mnohem delˇs´ı dobu.

4.9.7

Implementace objekt˚ u typu ResultsGatherer

• ConsoleResultsGatherer ConsoleResultsGatherer vypisuje v´ ysledky test˚ u do konzole. Je vytvoˇren pouze pro lad´ıc´ı u ´ˇcely. • BufferedResultsGatherer BufferedResultsGatherer je obalovac´ı objekt, kter´ y odstiˇ nuje vnitˇrn´ı ResultsGatherer od nutnosti schvalován´ı v´ ysledk˚ u. Neschválené v´ ysledky jsou uchov´ av´ any v bufferu a po jejich schválen´ı jsou pˇreposlány. BufferedResultsGatherer proto funguje jako dekorátor (návrhov´ y vzor Decorator nebo Wrapper [25]). • StructureResultsGatherer StructureResultsGatherer zajiˇst’uje strukturován´ı v´ ysledk˚ u. Vytvoˇrená struktura je vhodn´ a pro serializaci do XML. V listech stromové struktury jsou

45


mnoˇziny souvisej´ıc´ıch mˇeˇren´ı, ze kter´ ych se poˇc´ıtaj´ı statistické u ´daje (implementov´ ano tˇr´ıdou ResultSet). Hodnoty jsou nejdˇr´ıve filtrovány od neobvykl´ ych hodnot (posuzováno podle vzd´ alenost´ı od medi´ anu) a následnˇe je ze zbyl´ ych hodnot vypoˇc´ıtán pr˚ umˇer.

4.9.8

Implementace ˇ r´ıd´ıc´ıch objekt˚ u

• PerfTestsRunner ˇ ızen´ı prov´ R´ adˇen´ı test˚ u má na starosti tˇr´ıda PerfTestsRunner. Pˇred spuˇstˇen´ım test˚ u je tˇr´ıda nakonfigurována pomoc´ı sady tester˚ u, sady test˚ u a objektu pro shromaˇzd’ov´ an´ı v´ ysledk˚ u. Poté je spuˇstˇeno samotné testován´ı. Testov´ an´ı prob´ıh´ a postupnˇe se vˇsemi testery. Tester je spuˇstˇen pro sérii testovac´ıch pˇr´ıpad˚ u a nakonec je vyhodnocena pˇresnost mˇeˇren´ı této série. Pokud nebylo dosaˇzeno dostateˇcné pˇresnosti, mus´ı b´ yt mˇeˇren´ı opakováno. Maxim´ aln´ı poˇcet souvislého opakován´ı testu je nastaven na dostateˇcnˇe vysokou hodnotu, aby za bˇeˇzn´ ych podm´ınek nemohla b´ yt pˇrekroˇcena. Pokud je aplikace ˇspatnˇe nakonfigurována, m˚ uˇze doj´ıt k u ´plné nefunkˇcnosti nˇekterého testeru a d´ıky omezenému limitu nez˚ ustane aplikace v nekoneˇcné smyˇcce. Pro zv´ yˇsen´ı pravdˇepodobnosti, ˇze následná série bude u ´spˇeˇsná, zastav´ı se aplikace po chybˇe na urˇcitou dobu závislou na poˇctu pˇredchoz´ıch chyb. Pokud je série u ´spˇeˇsn´ a, jsou z´ıskané v´ ysledky akceptovány. V opaˇcném pˇr´ıpadˇe se provede jejich odstranˇen´ı. Kaˇzd´ y tester udává potˇrebn´ y poˇcet u ´spˇeˇsn´ ych opakov´ an´ı série. • Konkrétn´ı testovac´ı scén´ aˇre Konkrétn´ı testovac´ı scénáˇr (JUnit test) sestav´ı mnoˇzinu test˚ u a mnoˇzinu tester˚ u. Pˇred spuˇstˇen´ım test˚ u zajist´ı také popis a identifikaci testován´ı (SVN revizi, datum). Testovac´ıch scén´ aˇr˚ u m˚ uˇze prob´ıhat v´ıce za sebou v r˚ uzn´ ych procesech. V´ ysledky mezi scén´ aˇri se pˇredávaj´ı pomoc´ı serializace a deserializace objektu shromaˇzd’uj´ıc´ıho v´ ysledky. Pomoc´ı tˇr´ıdy PerfTestsRunner je provedeno samotné testován´ı. Následnˇe jsou aktualizované v´ ysledky serializovány a uloˇzeny. Kromˇe popsan´ ych testovac´ıch scénáˇr˚ u systém obsahuje také dva scénáˇre pomocné, které zajiˇst’uj´ı inicializaci pˇred testován´ım a zpracován´ı v´ ysledk˚ u po testov´ an´ı. Inicializace spoˇc´ıvá ve smazán´ı nebo pˇrejmenován´ı pˇredchoz´ıho souboru s v´ ysledky. Zpracován´ı v´ ysledk˚ u obsahuje v´ ypoˇcet statistick´ ych u ´daj˚ u a vygenerován´ı HTML reportu.

4.9.9

Pomocn´ e tˇ r´ıdy a knihovny

• SVNInfo Tˇr´ıda zjiˇst’uje aktu´ aln´ı revizi komparátoru v SVN. Ke svému fungován´ı potˇrebuje m´ıt moˇznost spustit pˇr´ıkaz svn na pˇr´ıkazové ˇrádce: svn info 46


Provedené optimalizace

http://svn.assembla.com/svn/jacc/trunk http://svn.assembla.com/svn/obcc/trunk -xml. V´ ystupem programu svn je XML s popisem aktuáln´ı verze projekt˚ u JaCC a OBCC. Toto XML je parsováno pomoc´ı knihovny SAX. • Knihovna Xstream Knihovna Xstream [5] slouˇz´ı pro jednoduchou serializaci (a deserializaci) libovoln´ ych objekt˚ u do XML. Jej´ı pouˇzit´ı je velmi jednoduché. Kód serializace: XStream xstream = new XStream ( new StaxDriver ()); xstream . toXML ( objectToSerialize , new FileOutputStream ( storeFile ));

K serializaci se vyuˇz´ıvaj´ı informace o objektu z´ıskané z reflexe, proto nemus´ı serializovateln´ y objekt implementovat ˇzádné rozhran´ı. Podobnˇe jednoduch´ y je k´ od deserializace: XStream xstream = new XStream ( new StaxDriver ()); MyObject myObject = ( MyObject ) xstream . fromXML ( storeFile );

Tˇr´ıda objektu mus´ı samozˇrejmˇe odpov´ıdat tˇr´ıdˇe serializovaného objektu.

4.9.10

Integrace do Hudsonu

D´ıky spouˇstˇen´ı aplikace jako JUnit testy lze testován´ı snadno spouˇstˇet pomoc´ı d´ avkov´ ych skript˚ u a stejn´ ym zp˚ usobem také nakonfigurovat v Hudsonu. Aplikace m´ a definované z´ avislosti na vˇsech testovan´ ych projektech, proto bude testov´ an´ı spuˇstˇeno vˇzdy pˇri zmˇenˇe testovaného kódu. V´ ysledky test˚ u lze prohl´ıˇzet pˇres webové rozhran´ı. Hudson umoˇzn ˇuje webové prohl´ıˇzen´ı soubor˚ u projektu. V koˇrenovém adresáˇri projektu je vygenerován soubor report.html s v´ ysledky, kter´ y lze z webového rozhran´ı Hudsonu otevˇr´ıt.

4.9.11

Ovˇ eˇ ren´ı pˇ resnosti mˇ eˇ ren´ı

Pˇresnost mˇeˇren´ı byla ovˇeˇrov´ ana nˇekolikanásobn´ ym spuˇstˇen´ım test˚ u na stejné verzi k´ odu. Z´ıskané v´ ysledky pˇresnosti jsou zobrazeny v tabulce 4.2 s v´ ysledky mˇeˇren´ı. Test optimalizovan´ a verze kódu (t2) byl spuˇstˇen tˇrikrát po sobˇe. V´ ysledky mˇeˇren´ı pamˇeti se liˇs´ı maxim´ alnˇe o 0,08 procenta, v´ ysledky mˇeˇren´ı doby v´ ypoˇctu maxim´ alnˇe o 0,7 procenta (bez JIT kompilace maximálnˇe o 1,6 procenta).

4.10

Proveden´ e optimalizace

Optimalizace provedené v r´ amci této práce byly zamˇeˇreny pouze na ˇcást porovˇ ast naˇc´ıtán´ı reprezentace nebylo moˇzné n´ an´ı reprezentac´ı OSGi komponent. C´ 47



optimalizovat, protoˇze soubˇeˇznˇe prob´ıhal v´ yvoj jej´ı nové verze.

4.10.1

Oprava logov´ an´ı

Anal´ yzou v´ ykonnosti pomoc´ı profileru byly odhaleny nápadnˇe velké ˇcasové ztráty zp˚ usobené vol´ an´ım metody toString() bˇehem porovnán´ı metod. Zamˇeˇrila jsem se proto na zp˚ usob logov´ an´ı v komparátoru metod a odhalila jsem v´ yrazné nedostatky. Logovac´ı knihovnˇe byl pˇredáván vˇzdy kompletnˇe sestaven´ y ˇretˇezec, kter´ y se t´ım p´ adem musel tvoˇrit i pˇri vypnutém logován´ı. Chybu jsem opravila vyuˇzit´ım prostˇredk˚ u logovac´ı knihovny pro formátován´ı ˇretˇezce. Knihovnˇe je pˇred´ an formátovac´ı ˇretˇezec a pole argument˚ u, nad kter´ ymi knihovna v pˇr´ıpadˇe potˇreby (pouze pˇri zapnutém logován´ı) zavolá sama metodu toString(). Touto jednoduchou opravou se v´ ysledky test˚ u zlepˇsily na dobˇe v´ ypoˇctu zhruba o 70% a na celkové alokované pamˇet’ témˇeˇr o 90%.

4.10.2

Optimalizace algoritmu porovn´ av´ an´ı tˇ r´ıd

Manu´ aln´ı anal´ yzou k´ odu jsem zjistila neefektivitu algoritmu porovnán´ı tˇr´ıd. Pro ukonˇcen´ı rekurze porovn´ an´ı cyklické struktury tˇr´ıd se pouˇz´ıvá historie tˇr´ıd. V p˚ uvodn´ı verzi algoritmus pouˇz´ıval zásobn´ık právˇe porovnávan´ ych tˇr´ıd pro detekci a ukonˇcen´ı rekurze a kromˇe toho jeˇstˇe samostatnou historii tˇr´ıd pro ukl´ ad´ an´ı v´ ysledk˚ u porovn´ an´ı tˇr´ıd. Jeˇstˇe pˇred zah´ ajen´ım mˇeˇren´ı efektu optimalizac´ı (v rámci sv´ ych poˇcáteˇcn´ıch prac´ı na projektech komparátor˚ u) jsem tento algoritmus upravila, aby byla pro oba u ´ˇcely pouˇzita pouze jedna struktura – historie porovnan´ ych tˇr´ıd. Tato optimalizace nen´ı obsaˇzena v namˇeˇren´ ych v´ ysledc´ıch. N´ aslednˇe jsem se pokusila optimalizaci jeˇstˇe vylepˇsit zmˇenou datové struktury, ale efekt byl z´ aporn´ y, proto jsem ponechala p˚ uvodn´ı strukturu. Podaˇrilo se mi ale sn´ıˇzit poˇcet vyhled´ aván´ı tˇr´ıdy v historii, coˇz pˇrineslo efekt na sn´ıˇzen´ı testované doby v´ ypoˇctu pˇribliˇznˇe o 2%.

4.10.3

Optimalizace algoritmu porovn´ an´ı seznamu metod

Bˇehem anal´ yzy objekt˚ u v pamˇeti jsem si vˇsimla nesmyslnˇe vysokého poˇctu v´ ysledk˚ u porovn´ an´ı metod. To mˇe dovedlo k závˇeru, ˇze je potˇreba optimalizovat algoritmus porovn´ an´ı seznamu metod, ze kterého jsou v´ ysledky porovnán´ı metod vyˇzadov´ any. P˚ uvodn´ı implementace algoritmu byla velmi nepˇrehledná a pravdˇepodobnˇe i chybn´ a. Do v´ ysledné struktury relevantn´ıch v´ ysledk˚ u porovnán´ı ukládala nˇe-

48



které zbyteˇcné v´ ysledky. Algoritmus jsem proto kompletnˇe pˇredˇelala. Optimalizace se projevila v testech sn´ıˇzen´ım doby v´ ypoˇctu zhruba o 20% a poklesem velikosti vytvoˇren´ ych datov´ ych struktur o 75%.

Struˇ cn´ y popis nov´ eho algoritmu V pˇr´ıpadˇe metod se nejprve vytvoˇr´ı skupiny metod se stejn´ ym názvem a poˇctem parametr˚ u. Kaˇzd´ a skupina je rozdˇelena na dvˇe ˇcásti reprezentuj´ıc´ı metody jednotliv´ ych porovn´ avan´ ych komponent. V rámci skupiny je potˇreba porovnat kaˇzdou metodu prvn´ı komponenty s kaˇzdou metodou druhé komponenty a sestavit celkov´ y v´ ysledek z v´ ysledk˚ u d´ılˇc´ıch. D´ılˇc´ı v´ ysledek je z´ıskán pro kaˇzdou metodu skupiny tak, ˇze je nalezen nejv´ yhodnˇejˇs´ı rozd´ıl od nˇekteré metody z opaˇcné komponenty (v nejhorˇs´ım pˇr´ıpadˇe se za rozd´ıl zvol´ı odstranˇen´ı, protoˇze metoda v opaˇcné komponentˇe chyb´ı). D´ılˇc´ı v´ ysledky pro metody druhé komponenty je potˇreba obr´ atit. Zjiˇst’ov´ an´ı, zda maj´ı metody stejn´ y název a poˇcet parametr˚ u, jsem upravila na pouˇzit´ı kompar´ atoru (ve smyslu rozhran´ı java.utils.Comparator) m´ısto p˚ uvodn´ı metody ovˇeˇruj´ıc´ı shodu. Algoritmus je spoleˇcn´ y pro metody i konstruktory, u kter´ ych se nesm´ı porovnávat název, a je implementován v abstraktn´ı tˇr´ıdˇe JMemberListComparator. Potomci této tˇr´ıdy inicializuj´ı komparátor podle sv´ ych potˇreb. D´ıky nové moˇznosti ˇrazen´ı metod bylo moˇzné zjednoduˇsit a optimalizovat algoritmus vytv´ aˇren´ı skupin metod se stejn´ ym názvem a poˇctem parametr˚ u.

4.10.4

Celkov´ y efekt optimalizac´ı

Celkov´ y efekt optimalizac´ı zachycuj´ı tabulky 4.2, 4.3 a 4.4. Na pouˇzit´ ych testovac´ıch datech byla doba v´ ypoˇctu sn´ıˇzena pˇribliˇznˇe o 86% (bez JIT kompilace o 82%), celkov´ a alokovan´ a pamˇet’ klesla o 94% a velikost v´ ysledn´ ych datov´ ych struktur se sn´ıˇzila o 75%. Namˇeˇrené hodnoty ˇcasu jsou uvedeny v nanosekundách (mˇeˇreno na procesoru Core i7 2,8 GHZ) a hodnoty pamˇeti v bytech. Prvn´ı sloupec hodnot pˇredstavuje stav pˇred optimalizac´ı, dalˇs´ı tˇri sloupce obsahuj´ı mˇeˇren´ı po optimalizaci.

Obr´ azek 4.2: Mˇeˇren´ı efektu optimalizac´ı.

49


Zhodnocen´ı výsledk˚ u

Obr´ azek 4.3: Mˇeˇren´ı efektu optimalizac´ı bez JIT kompilace.

Obr´ azek 4.4: Mˇeˇren´ı efektu optimalizac´ı - tabulka zlepˇsen´ı posledn´ıho mˇeˇren´ı oproti mˇeˇren´ı prvn´ımu a pˇredchoz´ımu.

4.11

Zhodnocen´ı v´ ysledk˚ u

Proveden´ım optimalizac´ı se podaˇrilo dosáhnout v´ yrazného sn´ıˇzen´ı doby bˇehu a spotˇreby pamˇeti porovn´ an´ı reprezentac´ı komponent. Pouˇzité nástroje pro anal´ yzu k´ odu se uk´ azaly jako velmi pˇr´ınosné, protoˇze s jejich pomoc´ı byly velmi rychle odhaleny problémy v k´ odu vhodné k optimalizaci. D´ıky velmi pˇresnému mˇeˇren´ı efektu optimalizac´ı pomoc´ı vytvoˇrené aplikace bylo moˇzné posuzovat kaˇzdou zmˇenu kódu samostatnˇe. Zmˇeny, které nevedly ke zv´ yˇsen´ı v´ ykonnosti, byly na z´ akladˇe ˇspatn´ ych namˇeˇren´ ych v´ ysledk˚ u zam´ıtnuty. Testovac´ı aplikaci bude moˇzné dále vyuˇz´ıt pro optimalizaci naˇc´ıtán´ı reprezentace komponent.

50

5 Vyuˇzit´ı komparátor˚ u pˇ ri anal´ yze rozd´ıl˚ u 5.1 5.1.1

C´ıle a pˇ r´ınosy Grafick´ e zobrazen´ı rozd´ıl˚ u

Druh´ ym c´ılem pr´ ace bylo rozˇs´ıˇren´ı moˇznost´ı vyuˇzit´ı komparátoru. Komparátor je moˇzné vyuˇz´ıt pro manu´ aln´ı anal´ yzu rozd´ılu mezi komponentami. Za t´ımto u ´ˇcelem byl vytvoˇren grafick´ y v´ ystup, kter´ y pˇrehlednˇe zobrazuje jednotlivé rozd´ıly. Grafick´ y v´ ystup byl integrován do nástroje pro automatické verzován´ı (OBVS [14]). Uˇzivatel verzovac´ıho n´ astroje z´ıská vysvˇetlen´ı, z jak´ ych d˚ uvod˚ u nástroj urˇcil konkrétn´ı sémantickou verzi.

5.1.2

Dalˇ s´ı moˇ zn´ e pouˇ zit´ı v´ ystupu

Grafick´ y v´ ystup je moˇzné d´ ale vyuˇz´ıt k zobrazen´ı rozd´ıl˚ u v kódu jako alternativa k SVN n´ astroji diff, kter´ y zobrazuje rozd´ıly dvou verz´ı souboru. Pˇr´ıklad v´ ystupu SVN diff (TortoiseSVN) je na obrázku 5.1.

Obr´ azek 5.1: N´ ahled v´ ystupu nástroje TortoiseSVN diff Rozd´ıl mezi SVN diff a v´ ystupem pˇripraven´ ym v této práci spoˇc´ıvá v principu porovn´ an´ı k´ odu. SVN diff porovnává kód jako prost´ y text, bez jakékoliv znalosti jeho struktury. V textu se snaˇz´ı vyhledávat podobné sekvence. V´ ystup zaloˇzen´ y na komparátorech zobrazuje rozd´ıly z´ıskané porovnán´ım k´ odu se znalost´ı jeho struktury. Takové porovnán´ı se naz´ yvá porovnán´ı zaloˇzené

51

Vyuˇzit´ı kompar´ ator˚ u pˇri analýze rozd´ıl˚ u

Projekt OBVS

na modelu (model based). Komparátory vytvoˇr´ı model obou komponent a tyto modely mezi sebou porovnaj´ı. Z´ıskan´ y v´ ystup odpov´ıd´ a hloubce modelu. Informace, které nejsou souˇcást´ı modelu (napˇr´ıklad k´ od uvnitˇr metod), nejsou porovnány. V´ yhodou je prezentace pouze podstatn´ ych informac´ı, nev´ yhodou absence detailn´ıch informac´ı. Dalˇs´ı v´ yhodou porovn´ an´ı zaloˇzené na modelu je, ˇze se dokáˇze vypoˇrádat se zd´ anliv´ ymi zmˇenami typu zmˇena poˇrad´ı metod. Porovnán´ı zaloˇzené na textu tyto zd´ anlivé zmˇeny oznaˇcuje jako zmˇeny. Naopak nev´ yhodou tohoto typu porovn´ an´ı je moˇznost jeho pouˇzit´ı pouze pro konkrétn´ı programovac´ı jazyk. Porovn´ an´ı zaloˇzené na textu je univerzáln´ı.

5.2

Projekt OBVS

Projekt OBVS (OSGi Bundle Versioning Service [14]) je nástroj pro automatické verzov´ an´ı OSGi komponent. Pouˇz´ıvá se prostˇrednictv´ım webového rozhran´ı. Uˇzivatel prostˇrednictv´ım webového formuláˇre nahraje dvˇe OSGi komponenty, jednu v p˚ uvodn´ı verzi, druhou upravenou a urˇcenou k overzován´ı. Nástroj pomoc´ı kompar´ ator˚ u urˇc´ı sémanticky správnou verzi pro upravenou komponentu. Overzovan´ a komponenta je uˇzivateli nab´ıdnuta ke staˇzen´ı. Náhled formuláˇre pro zad´ an´ı komponent je na obr´ azku 5.2. N´ astroj je nasazen na adrese http:// osgi.kiv.zcu.cz/ obvs/ index.html .

Obr´ azek 5.2: N´ ahled rozhran´ı nástroje OBVS - formuláˇr pro zadán´ı komponent.

5.2.1

Architektura

Webové rozhran´ı je vytvoˇreno jako standardn´ı J2EE aplikace, která pouˇz´ıvá servlety a JSP str´ anky. V souˇcasné dobˇe prob´ıhá v´ yvoj nového webového rozhran´ı, které bude zaloˇzeno na technologii Spring. Pro své fungován´ı vyuˇz´ıvá nástroj kompar´ atory ve formˇe knihoven.

52


5.2.2

Projekt OBVS

Zp˚ usob integrace zobrazen´ı rozd´ıl˚ u

Pro technologie integrace je d˚ uleˇzité, ˇze souˇcasná i budouc´ı verze nástroje je ps´ ana v Javˇe a k zobrazov´ an´ı pouˇz´ıvá HTML, CSS a Javascript. Tyto technologie proto byly pouˇzity také k implementaci zobrazen´ı rozd´ıl˚ u. Rozd´ıly se zobrazuj´ı na str´ ance zobrazené po overzován´ı komponenty, odkud je moˇzné overzovanou komponentu st´ ahnout.

Rozhran´ı Grafické zobrazen´ı rozd´ıl˚ u bylo implementováno jako samostatn´ y projekt (kapitola 5.4) se z´ avislostmi na komparátorech. Pro klientsk´ y program poskytuje velmi jednoduché rozhran´ı. V´ ystup je generován zavolán´ım jediné metody, které je pˇred´ an parametr obsahuj´ıc´ı strukturu v´ ysledku porovnán´ı. Návratová hodnota je typu String a obsahuje HTML kód bez HTML hlaviˇcek, aby ho bylo moˇzné vloˇzit bez u ´prav do webové stránky. Tagy do HTML hlaviˇcky je moˇzné z´ıskat samostatnˇe, opˇet jako String. Tyto tagy obsahuj´ı CSS styly a Javascript potˇrebn´ y pro správné zobrazen´ı v´ ystupu. Tagy obsahuj´ı také odkazy na soubory styl˚ u a skript˚ u. Do webov´ ych zdroj˚ u proto byly vloˇzeny potˇrebné obrázky a soubory s nemˇenn´ ymi CSS styly a Javascriptem.

Rizika nekompatibility Vytvoˇren´ y v´ ystup by mˇel b´ yt integrován také do nové verze nástroje OBVS, proto byly k omezen´ı rizika nekompatibility na u ´rovni technologi´ı HTML, CSS a Javascriptu pouˇzity preventivn´ı metody. Na u ´rovni HTML vzniká riziko konfliktu v hodnot´ ach atribut˚ u id a name a v názvech tˇr´ıd pro stylován´ı. Riziko bylo omezeno volbou dostateˇcnˇe specifick´ ych jmen a názv˚ u tˇr´ıd. Atributy id nejsou pouˇz´ıv´ any v˚ ubec. Na u ´rovni CSS hroz´ı zakryt´ı styl˚ u. Bud’ mohou styly stránky ovlivnit styly zobrazen´ı rozd´ıl˚ u, nebo naopak. Proto jsou pouˇzity dostateˇcnˇe konkrétn´ı selektory na obou stran´ ach. Na u ´rovni Javascriptu m˚ uˇze doj´ıt k pˇrepsán´ı globáln´ıch promˇenn´ ych. V pˇr´ıpadˇe pouˇzit´ı knihovny JQuery je obvykle jedinou globáln´ı promˇennou instance knihovny. Pokud by knihovna byla do stránky vloˇzena dvakrát, je p˚ uvodn´ı inˇ sen´ım je uloˇzen´ı instance knihovny stance vˇcetnˇe nahran´ ych plugin˚ u ztracena. Reˇ do jiné promˇenné s dostateˇcnˇe sloˇzit´ ym názvem pomoc´ı skriptu vloˇzeného tˇesnˇe za skript knihovny a plugin˚ u. Vˇzdy pˇred pouˇzit´ım knihovny je instance zkop´ırov´ ana zpˇet do standardn´ı promˇenné.

53


5.3 5.3.1

Technologie

Technologie HTML

HTML (HyperText Markup Language) je znaˇckovac´ı jazyk pro text propojen´ y odkazy. Je standardn´ım jazykem pro vytváˇren´ı webov´ ych stránek. V souˇcasné dobˇe je nejv´ıce rozˇs´ıˇrena jeho verze 4, nejnovˇejˇs´ı verze 5 nemá zat´ım dostateˇcnou podporu mezi prohl´ıˇzeˇci. HTML m´ a podobnou syntaxi jako XML, ale syntaktická pravidla jsou volnˇejˇs´ı (napˇr´ıklad nen´ı nutné psát ukonˇcovac´ı tagy). Pouˇz´ıt lze omezenou sadu tag˚ u se sémantick´ ym (napˇr´ıklad <em>) nebo prezentaˇcn´ım (napˇr´ıklad nebo ) v´ yznamem. V´ yborn´ y tutorial technologie HTML je na [45]. N´ astupcem HTML je XHTML (Extensible HyperText Markup Language), které vyˇzaduje dodrˇzen´ı syntaxe XML a odbourává pouˇzit´ı prezentaˇcn´ıch tag˚ u. Stylov´ an´ı a zp˚ usob prezentace má b´ yt kompletnˇe pˇresunuta na technologie CSS (kask´ adové styly) a Javascript.

5.3.2

CSS

CSS (Cascading Style Sheets - kaskádové styly) je technologie pro stylován´ı obsahu zapsaného ve form´ atu HTML, XHTML nebo XML. Hlavn´ım u ´kolem je oddˇelen´ı vzhledu dokumentu od jeho struktury a obsahu. V prohl´ıˇzeˇc´ıch je bˇeˇznˇe podporov´ ana jejich verze 2. Styly se skl´ adaj´ı z jednotliv´ ych pravidel. Pravidlo obsahuje selektor a blok deklarac´ı. Pomoc´ı selektoru se urˇcuje mnoˇzina element˚ u, na které se pravidlo vztahuje. Blok deklarac´ı popisuje formátován´ı element˚ u. Selektory mohou b´ yt velmi obecné (napˇr. pro vˇsechny odstavce) i naprosto ˇ ım je selektor v´ıce konkrétn´ı, t´ım má vyˇsˇs´ı konkrétn´ı (napˇr. podle id elementu). C´ prioritu. Dalˇs´ı pravidla pro prioritu selektor˚ u vycház´ı z m´ısta jejich deklarace nebo poˇrad´ı. V´ıce se lze o CSS dozvˇedˇet na [44].

5.3.3

Javascript

Javascript je skriptovac´ı jazyk, kter´ y má podobnou syntaxi jako C++ nebo Java. Poskytuje prostˇredky pro objektovˇe orientované programován´ı. Pouˇz´ıvá se zejména na webu, ale st´ ale ˇcastˇeji také pro klasické aplikace. Pˇr´ıkladem je projekt Node.js [29], kter´ y pouˇz´ıvá Javascript na stranˇe klienta i serveru. V´ yznam Javascriptu na webu spoˇc´ıvá v jeho interpretaci prohl´ıˇzeˇcem na stranˇe klienta. To pˇrin´ aˇs´ı r˚ uzné v´ yhody. Javascript umoˇzn ˇuje rychlou odezvu na akce uˇzivatele, napˇr´ıklad kontrolu vyplnˇen´ ych hodnot nebo interaktivn´ı nápovˇedu. D´ıky interpretaci u klienta nedocház´ı tak ˇcasto k poˇzadavk˚ um na server.

54


Technologie

T´ım se sniˇzuje zat´ıˇzen´ı serveru i s´ıtˇe. Z pohledu program´ atora pˇrináˇs´ı Javascript zaj´ımavé moˇznosti. Jedná se o slabˇe typovan´ y jazyk (weakly-typed), promˇenné nemaj´ı pevnˇe urˇcen´ y datov´ y typ. Ke kaˇzdému objektu lze pˇristupovat jako k asociativn´ımu poli. Objekty lze mimo jiné vytv´ aˇret pomoc´ı zápisu v JSON (JavaScript Object Notation) form´ atu, kter´ y je velmi jednoduch´ y a dobˇre ˇciteln´ y. V kombinaci s funkc´ı eval lze takto vytvoˇrit objekt i z ˇretˇezce v JSON formátu, coˇz se ˇcasto pouˇz´ıvá pro komunikaci Javascriptu u klienta se serverem. K´ od v Javascriptu je organizován do funkc´ı. Globáln´ı kontext je brán jako funkce, kter´ a se zavol´ a bˇehem naˇc´ıtán´ı stránky. Uvnitˇr je moˇzné definovat dalˇs´ı funkce, se kter´ ymi lze pracovat také jako s objekty. Zásadn´ım rozd´ılem oproti jazyk˚ um, jako je napˇr´ıklad Java, je viditelnost promˇenn´ ych. Java pouˇz´ıvá rozsah na u ´rovni blok˚ u (block-level scoping), zat´ımco Javascript pouˇz´ıvá rozsah na u ´rovni funkc´ı (function-level scoping). To znamená, ˇze promˇenná je viditelná ze vˇsech vnoˇren´ ych funkc´ı. Podpora Javascriptu v prohl´ıˇzeˇc´ıch je ˇsiroká, ale v jednotliv´ ych prohl´ıˇzeˇc´ıch se m˚ uˇze liˇsit rozhran´ı pro pˇr´ıstup k element˚ um stránky (DOM objekt˚ um). Proto je vhodné vˇzdy pouˇz´ıvat knihovnu, která programátora od tˇechto rozd´ıl˚ u odstin ˇuje. Knihovna vˇetˇsinou nav´ıc poskytuje mnoho uˇziteˇcn´ ych funkc´ı. Pˇr´ıkladem takové knihovny je JQuery.

5.3.4

JQuery

JQuery [31] je lehk´ a (lightweight) Javascriptová knihovna, která je podporována v naprosté vˇetˇsinˇe prohl´ıˇzeˇc˚ u. Jej´ı v´ yvoj zaˇcal v roce 2006, proto je podporov´ ana i starˇs´ımi prohl´ıˇzeˇci, jako je napˇr´ıklad Internet Explorer verze 6. Knihovna se stala velmi obl´ıbenou a ˇsiroce vyuˇz´ıvanou, proto lze oˇcekávat jej´ı v´ yvoj a podporu v nov´ ych verz´ıch prohl´ıˇzeˇc˚ u i do budoucna. Knihovna je vyd´ av´ ana pod licenc´ı GPL (GNU General Public License) nebo MIT (Massachusetts Institute of Technology). Lze ji proto svobodnˇe pouˇz´ıvat v libovolném projektu. Knihovna poskytuje podporu pro procházen´ı a u ´pravy DOM (Document Object Model) objekt˚ u, reakce na události (akce uˇzivatele), Ajax (technologie asynchronn´ı komunikace se serverem), animace a mnoho dalˇs´ıho. Dalˇs´ı funkcionalitu lze pˇridat pomoc´ı plugin˚ u, kter´ ych existuje velké mnoˇzstv´ı. V´ yhodou knihovny JQuery oproti jin´ ym Javascriptov´ ym knihovnám a framework˚ um je mal´ a velikost k´ odu, jednoduchost a snadné (intuitivn´ı) pouˇzit´ı, svobodn´ a licence, velké mnoˇzstv´ı funkcionality (ˇcásteˇcnˇe poskytované pluginy) a rozˇs´ıˇrenost pouˇzit´ı. Srovn´ an´ı knihoven lze nalézt na Wikipedii [6].

55


5.3.5

Projekt prezentace rozd´ıl˚ u

Treeview

Treeview je plugin do knihovny JQuery pro zobrazován´ı stromové struktury. Hlavn´ı funkcionalitou je moˇznost rozbalován´ı a zabalován´ı (skr´ yván´ı) jednotliv´ ych vˇetv´ı struktury. Plugin dále zjednoduˇsuje um´ıstˇen´ı ikonek k jednotliv´ ym poloˇzk´ am struktury. ˇ adné Struktura mus´ı b´ yt tvoˇrena vnoˇren´ ymi seznamy (tagy
,
). Z´ dalˇs´ı poˇzadavky plugin nevyˇzaduje. Plugin zajiˇst’uje základn´ı stylován´ı stromu, které lze jednoduˇse vylepˇsit pomoc´ı vlastn´ıch styl˚ u. Treeview nen´ı jedin´ y plugin pro vytvoˇren´ı stromové struktury, ale jeho v´ yhodou oproti ostatn´ım je jeho velmi snadné pouˇzit´ı, absence zbyteˇcn´ ych funkc´ı a velmi jednoduch´ y k´ od.

5.4 5.4.1

Projekt prezentace rozd´ıl˚ u V´ ystupy

Pro vytvoˇren´ı grafického zobrazen´ı rozd´ıl˚ u byl zaloˇzen nov´ y projekt s názvem obcc-presentation. V´ ystupy generované projektem budou m´ıt ˇsirˇs´ı uplatnˇen´ı, neˇz jen v r´ amci n´ astroje OBVS. Projekt generuje nˇekolik typ˚ u v´ ystupu ve formátech HTML a XML. Pro integraci do n´ astroje OBVS byl zvolen v´ ystup s názvem htmlLimitedDepth (limitovan´ a hloubka). Alternativn´ım HTML v´ ystupem je v´ ystup s názvem htmlFlat (ploch´ y nebo lineárn´ı). Oba v´ ystupy se snaˇz´ı pˇrevést p˚ uvodn´ı rekurzivn´ı strukturu v´ ysledk˚ u porovnán´ı do lépe ˇcitelné podoby.

V´ ystup htmlLimitedDepth Struktura v´ ysledk˚ u porovn´ an´ı má charakter stromu z´ıskaného algoritmem DFS (Depth-first search). Takov´ a struktura je pro ˇclovˇeka málo ˇcitelná, protoˇze zanoˇren´ı vˇetv´ı stromu nerespektuje intuitivn´ı zásady zanoˇren´ı element˚ u OSGi komponent a Java typ˚ u. Pˇr´ıstup zvolen´ y pro generován´ı v´ ystupu htmlLimitedDepth je snaha o transformaci struktury do stromu s u ´rovnˇemi Java bal´ık – tˇr´ıda – metoda, na kter´ y je uˇzivatel zvykl´ y napˇr´ıklad z v´ yvojového prostˇred´ı. V´ ystup je rozdˇelen na dva samostatné stromy. Prvn´ı zobrazuje rozd´ıly na u ´rovni OSGi element˚ u, druh´ y na u ´rovni Java typ˚ u. Nˇekteré u ´rovnˇe p˚ uvodn´ı struktury jsou vypuˇstˇeny. Strom element˚ u OSGi komponenty obsahuje u ´rovnˇe: komponenta, OSGi bal´ık nebo sluˇzba, Java bal´ık, Java tˇr´ıda (s odkazem do pˇr´ısluˇsné vˇetve ve stromu Java typ˚ u). Strom Java typ˚ u obsahuje u ´rovnˇe: Java bal´ık, tˇr´ıda, metody a ˇclensk´ a pole, odkaz na typy parametr˚ u a návratové hodnoty metod nebo typ pole. Aby byla orientace ve stromech uˇzivateli maximálnˇe

56



usnadnˇena, jsou pouˇzity pro jednotlivé vˇetve ikony z v´ yvojového prostˇred´ı Eclipse. Rozd´ıly jsou zobrazeny na spoleˇcném stromˇe pro obˇe komponenty pomoc´ı rohov´ ych ikon. Tento systém je inspirován zobrazen´ım rozd´ıl˚ u v aplikaci TortoiseSVN, konkrétnˇe v n´ astroji diff v kombinaci se zp˚ usobem zobrazován´ı zmˇen v souborovém systému. Strom obsahuje vˇsechny elementy, které jsou obsaˇzeny alespoˇ n v jedné z porovn´ avan´ ych komponent. Pokud je element pˇr´ıtomn´ y pouze v prvn´ı komponentˇe, je ve stromu oznaˇcen ˇcervenou ikonou ve tvaru kˇr´ıˇzku (element byl odebr´ an). Pokud je element pˇr´ıtomn´ y pouze ve druhé komponentˇe, je oznaˇcen modrou ikonou ve tvaru znaménka plus (element byl pˇridán). Pokud je v´ ysledkem porovn´ an´ı na nˇekteré u ´rovni mutace (MUT), je element oznaˇcen ˇcerven´ ym vykˇriˇcn´ıkem. Ikony pro oznaˇcován´ı element˚ u byly pˇrevzaty z programu TortoiseSVN, ve kterém jsou pouˇzity pro oznaˇcen´ı zmˇen v souborovém systému. Vˇetve stromu je moˇzné zabalovat (skr´ yvat) a rozbalovat. Uˇzivatel má d´ıky tomu jak souhrnn´ y pˇrehled o stavu jednotliv´ ych bal´ık˚ u, tak si m˚ uˇze rozbalit i detailn´ı d˚ uvody rozd´ıl˚ u.

V´ ystup htmlFlat V´ ystup htmlFlat pˇrev´ ad´ı rekurzivn´ı strukturu v´ ysledk˚ u do struktury lineárn´ı (ploché). Jednotlivé v´ ysledky jsou provázány se sv´ ym rodiˇcem a potomky pomoc´ı odkaz˚ u. V´ ystup byl inspirován profilovac´ım nástrojem pro Android Traceview [27]. Uˇzivatel se pohybuje po jednotliv´ ych uzlech stromu a má moˇznost se pomoc´ı odkazu dostat na rodiˇce uzlu nebo jeho potomky. Zobrazeny jsou vˇzdy jen detaily aktu´ aln´ıho uzlu. U ostatn´ıch uzl˚ u je vidˇet typ elementu (pomoc´ı Eclipse ikony), v´ ysledek porovn´ an´ı (pomoc´ı TortoiseSVN ikony) a název. Vˇsechny uzly jsou zobrazeny pod sebou bez definovaného poˇrad´ı a uˇzivatel se m˚ uˇze pˇrepnout do libovolného uzlu. Tento typ v´ ystupu je urˇcen sp´ıˇse pro ladic´ı u ´ˇcely a k pochopen´ı algoritmu porovn´ av´ an´ı. Z tˇechto d˚ uvod˚ u je struktura zachována v p˚ uvodn´ı podobˇe.

XML v´ ystupy Pro oba popsané HTML v´ ystupy existuj´ı také jejich alternativy ve formátu XML. Tyto v´ ystupy jsou urˇceny pro dalˇs´ı strojové zpracován´ı, ale jsou také dobˇre ˇcitelné pro ˇclovˇeka d´ıky peˇclivému odsazován´ı a odˇrádkován´ı.

57


5.4.2


Implementace

Architektura Projekt je pouˇz´ıv´ an jako Java knihovna. Rozhran´ı pro pouˇzit´ı knihovny bylo pops´ ano v kapitole 5.2.2. Popsané API obsahuje metody pro generován´ı vˇsech typ˚ u v´ ystupu. V´ ystupy jsou z´ısk´ av´ any ve formˇe ˇretˇezc˚ u, aby je bylo moˇzné vloˇzit do sestavovaného HTML nebo XML dokumentu jako jedna z jeho ˇcást´ı. HTML v´ ystup se m˚ uˇze odkazovat na dalˇs´ı zdroje (obrázky, styly, skripty), jejichˇz správné um´ıstˇen´ı mus´ı zajistit uˇzivatel nebo klientská aplikace.

Univerz´ aln´ı vizitor V´ ysledek porovn´ an´ı je proch´ azen pomoc´ı jednotného mechanismu, kter´ y je zaloˇzen na n´ avrhovém vzoru vizitor (visitor pattern) [25]. Návrhov´ y vzor vizitor je urˇcen k pr˚ uchodu strukturou a k proveden´ı nˇejaké akce v kaˇzdém uzlu. Objekty struktury mus´ı obvykle implementovat rozhran´ı obsahuj´ıc´ı metodu visit (Visitor visitor), aby je vizitor mohl navˇst´ıvit. Konkrétn´ı implementace objekt˚ u mus´ı tuto metodu implementovat a zavolat v n´ı správnou metodu vizitora pro své navˇst´ıven´ı. Vizitor mus´ı obsahovat metody pro navˇst´ıven´ı kaˇzdého typu objektu ve struktuˇre. Vizitor implementovan´ y v tomto projektu nevyˇzaduje po objektech struktury implementaci ˇz´ adného speci´ aln´ıho rozhran´ı. Ke svému fungován´ı vyuˇz´ıvá reflexi. Podle typu objektu je schopen nalézt pˇr´ısluˇsnou metodu pro navˇst´ıven´ı objektu s´ am. D´ıky tomu nen´ı ani vyˇzadována implementace metod pro vˇsechny typy struktury konkrétn´ım vizitorem. Konkrétn´ı vizitor dˇed´ı od tˇr´ıdy UniversalVisitor (implementace inspirována v [13]) a implementuje metody pro navˇst´ıven´ı objekt˚ u potˇrebn´ ych typ˚ u. Metody mus´ı splˇ novat jednotn´ a pravidla pro pojmenován´ı, aby byly nalezeny algoritmem vyhled´ av´ an´ı metod, kter´ y je implementován ve tˇr´ıdˇe UniversalVisitor. Klient zavol´ a proch´ azen´ı struktury pomoc´ı metody visit (Object object) implementované tˇr´ıdou UniversalVisitor. Tato metoda zavolá metodu pro tˇr´ıdu objektu, tˇr´ıdu jeho nejbliˇzˇs´ıho pˇredka nebo nejbliˇzˇs´ı rozhran´ı. V´ yhodou této implementace vizitora je moˇznost procházen´ı libovolné struktury objekt˚ u. V tomoto projektu je toho vyuˇzito k pr˚ uchodu strukturou naˇctené reprezentace i strukturou v´ ysledk˚ u porovnán´ı. Konkrétn´ı vizitor vytváˇr´ı konkrétn´ı v´ ystup. D´ıky tomu jsou pohromadˇe ˇcásti v´ ystupu pro vˇsechny typy objekt˚ u struktury.

58



Algoritmus tvorby v´ ystupu htmlLimitedDepth V´ ystup htmlLimitedDepth je tvoˇren pomoc´ı nˇekolika instanc´ı rekurzivn´ıch vizitor˚ u (RecursiveResult2HTMLVisitor). Prvn´ı vizitor je spuˇstˇen pro koˇrenov´ y v´ ysledek porovn´ an´ı. Vizitor si sám urˇcuje, zda se maj´ı navˇst´ıvit také potomci v´ ysledku. Kdyˇz je navˇst´ıven v´ ysledek porovnán´ı tˇr´ıd, je vytvoˇren nov´ y vizitor zaˇc´ınaj´ıc´ı na tomto v´ ysledku. P˚ uvodn´ı vizitor uˇz dále do hloubky nepokraˇcuje. Instance vizitor˚ u jsou organizovány ˇr´ıd´ıc´ı tˇr´ıdou (ResultHTMLController). ˇ ıdic´ı V té se postupnˇe nahromad´ı vizitory pro kaˇzdou porovnávanou tˇr´ıdu. R´ tˇr´ıda zorganizuje vizitory do jednotliv´ ych bal´ık˚ u a spoj´ı vygenerovan´ y v´ ystup.

Klientsk´ aˇ c´ ast Z pohledu serveru je v´ ystup obyˇcejn´ y ˇretˇezec, kter´ y má b´ yt vloˇzen do HTML str´ anky. Na klientské stranˇe pˇri interpretaci v prohl´ıˇzeˇci je v´ ystup formátován pomoc´ı HTML, CSS a Javascriptu. Vygenerované HTML obsahuje vnoˇrené netˇr´ıdˇené seznamy. Pomoc´ı Javascriptu, konkrétnˇe pluginu Treeview knihovny JQuery, jsou seznamy transformovány do stromu s rozbalovateln´ ymi vˇetvemi. Javascript je také pouˇzit k fináln´ım u ´prav´ am struktury, které by bylo obt´ıˇzné implementovat na u ´rovni Javy (vizitor˚ u). Pomoc´ı kask´ adov´ ych styl˚ u jsou uzl˚ um struktury pˇriˇrazeny ikony.

V´ ysledn´ a grafick´ a podoba Obr´ azek 5.3 zobrazuje n´ ahled v´ ysledné podoby grafického v´ ystupu htmlLimitedDepth. Z obr´ azku je patrné, ˇze v nové verzi porovnávané komponenty byla smaz´ ana metoda methodPublicReturnNumberParamIntNumber tˇr´ıdy NormalClass z bal´ıku cz.zcu.kiv.obcc.testbundle.normal.

5.4.3

Moˇ znosti rozˇ s´ıˇ ren´ı

HTML v´ ystup by bylo moˇzné rozˇs´ıˇrit o dalˇs´ı informace o jednotliv´ ych uzlech. Napˇr´ıklad by mohl b´ yt pˇrid´ an odkaz na javadoc dokumentaci, pokud bude k dispozici. M´ısto webového rozhran´ı nástroje OBVS by bylo moˇzné vytvoˇrit rozhran´ı ve formˇe klientské aplikace, která by pos´ılala komponenty k overzován´ı formou webov´ ych sluˇzeb. T´ım by se usnadnilo pouˇzit´ı nástroje pro uˇzivatele. Grafick´ y v´ ystup by bylo moˇzné zaslat do klientské aplikace spolu s overzovanou komponentou.

59



Obr´ azek 5.3: N´ ahled grafického v´ ystupu htmlLimitedDepth.

60


5.5

Pˇr´ınosy a dalˇs´ı vyuˇzit´ı

Pˇ r´ınosy a dalˇ s´ı vyuˇ zit´ı

N´ astroj pro automatické verzován´ı (OBVS) byl rozˇs´ıˇren o grafické zobrazen´ı rozd´ıl˚ u mezi komponentami. Uˇzivatel nyn´ı kromˇe overzované komponenty z´ıská také vysvˇetlen´ı, proˇc byla urˇcena konkrétn´ı sémantická verze. D˚ uvody pro nutnost zmˇeny verze lze v grafickém zobrazen´ı velmi snadno vyhledat. Grafick´ y v´ ystup by bylo moˇzné dále vyuˇz´ıt i v jin´ ych aplikac´ıch, kde se vyuˇz´ıvaj´ı kompar´ atory. Napˇr´ıklad by bylo moˇzné zobrazovat d˚ uvody nekompatibility komponent pˇri resolvingu nebo pokusu o nahrazen´ı komponenty v komponentovém frameworku. Dalˇs´ım n´ amˇetem je vyuˇzit´ı grafického v´ ystupu pˇri vyhledáván´ı komponenty. Grafick´ y v´ ystup poskytuje uˇzivateli orientaˇcn´ı informaci o kvantitˇe rozd´ıl˚ u. Uˇzivatel by se proto mohl lépe rozhodnout, kterou komponentu vybrat, aby byly u ´pravy nutné k obnoven´ı kompatibility co nejmenˇs´ı. Grafick´ y v´ ystup by mohl b´ yt dále vyuˇz´ıván jako alternativa k SVN nástroj˚ um. Uˇzivatel by pomoc´ı nˇeho dokázal snadno vyhledat vˇsechny zmˇeny v rozhran´ı komponenty. V´ ystup by bylo moˇzné také pˇripojovat k informac´ım o vydané komponentˇe (release notes).

61

6 Závˇer 6.1

Shrnut´ı pr´ ace

Sezn´ amila jsem se s konceptem komponent obecnˇe a s komponentov´ ym modelem OSGi. Z´ıskané poznatky jsem shrnula v kapitole 2. Prostudovala jsem projekty t´ ykaj´ıc´ı se nahraditelnosti komponent vyv´ıjené na Katedˇre informatiky a v´ ypoˇcetn´ı techniky Fakulty aplikovan´ ych vˇed Západoˇceské univerzity v Plzni. V kapitole 3 jsem zpracovala pˇrehled projekt˚ u, v´ yvojov´ ych n´ astroj˚ u a zp˚ usobu pr´ ace na projektech. Popsala jsem také nedostatky a chybˇej´ıc´ı funkce kompar´ atoru. Do práce na projektech jsem se sama zapojila. Kapitolu 3 lze vyuˇz´ıt také jako pˇr´ıruˇcku pro dalˇs´ı studenty, kteˇr´ı na projektech zaˇc´ınaj´ı pracovat. Na z´ akladˇe ruˇcn´ı anal´ yzy k´ odu i mˇeˇren´ı v´ ykonnosti pomoc´ı nˇekolika nástroj˚ u jsem analyzovala ˇcasovou a pamˇet’ovou nároˇcnost implementace komparátoru a nalezla kritick´ a m´ısta v k´ odu. Tato m´ısta jsem pomoc´ı vhodn´ ych vylepˇsen´ı optimalizovala. Pro zjiˇstˇen´ı efektu optimalizac´ı jsem vytvoˇrila aplikaci, která mˇeˇr´ı rozd´ıl v´ ykonnosti aktu´ aln´ı verze oproti pˇredchoz´ım verz´ım. Pro pouˇzit´ a testovac´ı data klesla doba bˇehu optimalizovaného v´ ypoˇctu porovn´ an´ı zhruba o 88%, velikost vytvoˇren´ ych datov´ ych struktur o 75% a velikost celkové alokované pamˇeti bˇehem v´ ypoˇctu o 94%. Mˇeˇren´ı v´ ykonnosti komparátor˚ u jsem zapojila do procesu continuous integration, aby bylo moˇzné sledovat v´ yvoj v´ ykonnosti i do budoucna. Optimalizovanou implementaci komparátoru jsem vyuˇzila k rozˇs´ıˇren´ı nástroje pro automatické verzov´ an´ı OSGi komponent (OBVS). Po overzován´ı komponenty jsou graficky zobrazeny rozd´ıly mezi p˚ uvodn´ı a verzovanou komponentou. D´ıky tomu jsou na prvn´ı pohled patrné d˚ uvody pro zv´ yˇsen´ı sémantické verze komponenty.

6.2 6.2.1

Pˇ r´ınosy Pˇ r´ınosy pro kompar´ ator

D´ıky sn´ıˇzen´ı pamˇet’ov´ ych a ˇcasov´ ych nárok˚ u komparátoru se zv´ yˇsila pouˇzitelnost kompar´ atoru na v´ ykonovˇe omezen´ ych zaˇr´ızen´ıch. V´ ykonnost m˚ uˇze b´ yt dále zlepˇsov´ ana a sledov´ ana d´ıky jej´ımu automatickému mˇeˇren´ı. S pouˇzit´ım aplikace pro mˇeˇren´ı v´ ykonnosti lze provést dalˇs´ı optimalizace a snadno vyhodnotit jejich pˇr´ınosy. Vytvoˇren´ y grafick´ y v´ ystup zobrazuj´ıc´ı rozd´ıly mezi komponentami má ˇsiroké moˇznosti uplatnˇen´ı. Lze ho napˇr´ıklad vyuˇz´ıt v komponentovém frameworku pro 62

Z´ avˇer

N´ amˇety pro dalˇs´ı pr´ aci

vysvˇetlen´ı d˚ uvodu nekompatibility. Jiná uplatnˇen´ı dávaj´ı prostor pro dalˇs´ı námˇety na vyuˇzit´ı kompar´ ator˚ u.

6.2.2

Osobn´ı pˇ r´ınosy

D´ıky této pr´ aci jsem se bl´ıˇze seznámila s v´ yhodami a moˇznostmi komponentového pˇr´ıstupu pˇri v´ yvoji aplikac´ı a s technologi´ı OSGi. Pˇri práci na projektech kompar´ ator˚ u jsem poznala r˚ uzná u ´skal´ı práce v t´ ymu a nutnost dostateˇcné komunikace mezi ˇcleny t´ ymu. V ˇc´ asti pr´ ace zab´ yvaj´ıc´ı se optimalizac´ı komparátoru jsem se detailnˇeji seznámila s fungov´ an´ım garbage kolektoru a dalˇs´ıch faktor˚ u ovlivˇ nuj´ıc´ıch v´ ykonnost Java aplikace. Tyto znalosti mi mohou pomoci pˇri ˇreˇsen´ı problém˚ u v budoucnu. Vytvoˇrenou aplikaci pro mˇeˇren´ı v´ ykonnosti m˚ uˇzu vyuˇz´ıt také pro dalˇs´ı projekty.

6.3 6.3.1

N´ amˇ ety pro dalˇ s´ı pr´ aci Optimalizace naˇ c´ıt´ an´ı reprezentace

Bˇehem této pr´ ace nebylo moˇzné optimalizovat ˇcást komparátor˚ u naˇc´ıtaj´ıc´ı reprezentaci OSGi komponent, protoˇze soubˇeˇznˇe prob´ıhal v´ yvoj jej´ı nové verze. Podle v´ ysledk˚ u mˇeˇren´ı je nyn´ı doba bˇehu i spotˇreba pamˇeti pˇri naˇc´ıtán´ı reprezentace v´ yraznˇe vyˇsˇs´ı, neˇz pˇri následném porovnán´ı. V budoucnu je proto vhodné provést optimalizace také této ˇcásti.

6.3.2

Nov´ e n´ astroje

N´ amˇetem do budoucna je vytvoˇren´ı aplikace pro vyhledáván´ı komponenty na z´ akladˇe dotazovac´ı komponenty. Systém by mohl porovnat potenciálnˇe vhodné komponenty s dotazovac´ı komponentou a seˇradit je podle m´ıry kompatibility. S t´ım souvis´ı nutnost rozˇs´ıˇren´ı v´ ysledku porovnán´ı komponent o kvantifikaci rozd´ıl˚ u. Uˇzivateli by mohly b´ yt také zobrazeny rozd´ıly rozhran´ı formou implementovaného grafického v´ ystupu. Dalˇs´ım n´ amˇetem je vytvoˇren´ı aplikace, která by nahrazovala nebo doplˇ no´ celem aplikace by bylo vala n´ astroj SVN diff pˇri verzován´ı OSGi komponent. Uˇ zobrazen´ı pouze takov´ ych rozd´ıl˚ u mezi verzemi OSGi komponenty, které maj´ı vliv na jej´ı rozhran´ı. Uˇzivatel by tak mohl lépe kontrolovat provedené zmˇeny a rozhodovat o vyd´ an´ı komponenty.

63

Seznam zkratek API DOM GPL HTML IDL JaCC JAR JDK JIT JSON MIT OBCC OSGi SDK XHTML XML

Application programming interface Document Object Model GNU General Public License HyperText Markup Language Interface Definition Language Java Class Compatibility checker Java archive Java Development Kit Just-in-time JavaScript Object Notation Massachusetts Institute of Technology OSGi Bundle Compatibility Checking toolset Open Services Gateway initiative Software Development Kit Extensible HyperText Markup Language Extensible Markup Language

64

Literatura [1] Exception Handling Rules. Dokumentace projektu OBCC. http:// www.assembla.com/ spaces/ obcc/ wiki/ ExceptionHandlingRules. [2] JaCC representation tests. Dokumentace projektu JaCC. http:// www.assembla.com/ spaces/ jacc/ documents/ bvV0jCtv4r4kq0eJe5cbLr/ download/ bvV0jCtv4r4kq0eJe5cbLr . [3] OBCC Eclipse code formatter. Dokumentace projektu OBCC. http:// svn.assembla.com/ svn/ obcc/ trunk/ extras/ src/ main/ resources/ obcc/ OBCC-eclipse-src-formatter.xml . [4] Thread-safety analysis results. Dokumentace projektu JaCC. http:// subversion.assembla.com/ svn/ obcc/ documentation/ trunk/ thread-safety-analysis-results.ods. [5] Xstream project, 2011. http:// xstream.codehaus.org/ . [6] Comparison of JavaScript frameworks, 2012. Wikipedia http:// en.wikipedia.org/ wiki/ Comparison of JavaScript frameworks. [7] JLibs project, 2012. http:// code.google.com/ p/ jlibs. [8] OSGi Alliance. Semantic Versioning, Technical Whitepaper, 2010. http:// www.osgi.org/ wiki/ uploads/ Links/ SemanticVersioning.pdf . [9] OSGi Alliance. OSGi Alliance, 2012. http:// www.osgi.org. [10] Apache. Apache Felix, 2011. http:// felix.apache.org. [11] Felix Bachmann et al. Volume II: Technical concepts of component-based software engineering. Technical Report CMU/SEI-2000-TR-008, Software Engineering Institute, Carnegie Mellon University, 2000. [12] Kent Beck, Erich Gamma, and David Saff. JUnit, 2012. http:// www.junit.org/ .

65

LITERATURA

LITERATURA

[13] Jeremy Blosser. Reflect on the Visitor design pattern, 2007. Java World, Infoworld, Inc. http:// www.javaworld.com/ javaworld/ javatips/ jw-javatip98.html . [14] Pˇremysl Brada. Automated Semantic Versioning for OSGi Bundles. OSGi Community Event 29th September 2010. [15] Premysl Brada. Enhanced type-based component compatibility using deployment context information. Electronic Notes on Theoretical Computer Science, 279(2):17–31, December 2011. Proceedings of Formal Approaches to Software Component Applications (FESCA), satellite event of European Conference on Theory and Practice of Software (ETAPS). [16] Premysl Brada and Lukas Valenta. Practical verification of component substitutability using subtype relation. In Proceedings of the 32nd Euromicro Conference on Software Engineering and Advanced Applications, pages 38– 45. IEEE Computer Society Press, 2006. [17] Zuzana Bureˇsov´ a. OBCC performance tests on Android, 2011. Dokumentace projektu OBCC. http:// www.assembla.com/ spaces/ obcc/ wiki/ Performance tests on Android . [18] Zuzana Bureˇsov´ a, Veronika Dudová, and Karel Hovorka. Felix resolver integration, 2011. http:// www.assembla.com/ spaces/ obcc/ wiki/ Felix resolver integration. [19] Neil Coffey. Instrumentation: querying the memory usage of a Java object, 2011. http:// www.javamex.com/ tutorials/ memory/ instrumentation.shtml . [20] Ivica Crnković, Séverine Sentilles, Aneta Vulgarakis, and Michel R.V. Chaudron. A classification framework for software component models. IEEE Transactions on Software Engineering, 37(5):593–615, September/October 2011. [21] The Apache Software Foundation. Apache Maven, 2012. http:// maven.apache.org. [22] The Eclipse Foundation. Eclipse Equinox, 2012. http:// www.eclipse.org/ equinox/ . [23] The Eclipse Foundation. Eclipse Memory Analyzer, 2012. http:// www.eclipse.org/ mat/ . [24] The Eclipse Foundation. Eclipse Test and Performance Tools Platform Project, 2012. http:// www.eclipse.org/ tptp/ . [25] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. [26] Google. Android, 2012. https:// developers.google.com/ android . 66

LITERATURA

LITERATURA

[27] Google. Profiling with Traceview and dmtracedump, 2012. http:// developer.android.com/ guide/ developing/ debugging/ debugging-tracing.html . [28] Assembla Inc. Assembla, 2012. http:// www.assembla.com. [29] Joyent Inc. Node.js, 2012. http:// nodejs.org/ . [30] Sun Microsystems Inc. Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine, 2003. http:// www.oracle.com/ technetwork/ java/ gc-tuning-5-138395.html . [31] The jQuery Foundation. JQuery, 2012. http:// jquery.com/ . ´ ziˇstˇe komponent podporuj´ıc´ı kontroly kompatibility. Diplo[32] Jiˇr´ı Kuˇcera. Uloˇ mov´ a pr´ ace, Z´ apadoˇcesk´ a univerzita, 2011. [33] Luminis. EZdroid, 2012. http:// www.ezdroid.com. [34] J.D. Meier, Carlos Farre, Prashant Bansode, Scott Barber, and Dennis Rea. Performance Testing Guidance for Web Applications. Microsoft, 2007. [35] Bohdan Mix´ anek. Rozˇs´ıren´ı n´ astroje pro verzov´ an´ı OSGi komponent. Diplomov´ a pr´ ace, Z´ apadoˇceská univerzita, 2011. [36] Oracle. Java SE 6 API Specification: Class PhantomReference, 2011. http:// docs.oracle.com/ javase/ 6/ docs/ api/ java/ lang/ ref/ PhantomReference.html . [37] Oracle. Hudson, 2012. http:// hudson-ci.org/ . [38] Oracle. Java SE HotSpot at a Glance, 2012. http:// www.oracle.com/ technetwork/ java/ javase/ tech/ index-jsp-136373.html . [39] David J. Pearce, Matthew Webster, Robert Berry, and Paul H.J. Kelly. Profiling with AspectJ. Software Practise and Experience, 1(1), 2005. http:// homepages.ecs.vuw.ac.nz/ ˜djp/ files/ SPE05.pdf . [40] Jaroslav Plz´ ak. Z´ısk´ an´ı reprezentace OSGi komponent. Diplomová práce, Z´ apadoˇcesk´ a univerzita, 2009. [41] The Knopflerfish Project. Knopflerfish, 2012. http:// www.knopflerfish.org. [42] Naiyana Tansalarak and Kajal Claypool. Finding a needle in the haystack: A technique for ranking matches between components. In Proceedings of 8th International Symposium on Component-Based Software Engineering (CBSE 2005), volume 3489 of Lecture Notes in Computer Science. Springer Verlag, 2005. 67

LITERATURA

LITERATURA

[43] The TortoiseSVN Team. TortoiseSVN, 2012. http:// tortoisesvn.net/ . [44] W3schools. CSS Tutorial, 2012. http:// www.w3schools.com/ html/ . [45] W3schools. HTML Tutorial, 2012. http:// www.w3schools.com/ html/ .

68

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. komponent

Recommend Documents