Bakaláˇrská práce GUI pro testován´ı komponentových aplikac´ı

(1)

Z´ apadoˇcesk´ a univerzita v Plzni Fakulta aplikovan´ ych vˇed

Katedra informatiky a v´ ypoˇcetn´ı techniky

Bakal´ aˇ rsk´ a pr´ ace

GUI pro testov´ an´ı

komponentov´ ych aplikac´ı

(2)

Prohl´ aˇ sen´ı

Prohlaˇsuji, ˇze jsem bakaláˇrskou práci vypracoval samostatnˇe a výhradnˇe s po- uˇzit´ım citovaných pramen˚u.

V Plzni dne 26. ˇcervna 2014

Luk´aˇs Rost´as

(3)

Podˇ ekov´ an´ı

Rád bych podˇekoval Ing. Richardu Lipkovi, PhD. za vstˇr´ıcnost, ochotu a cenné rady pˇri veden´ı této práce.

(4)

Abstract

The goal of this bachelor’s thesis is to design and implement a library that creates a graphical user interface which makes it easier to control testing of simulated components. This GUI will be generated dynamically and will con- tain elements based on the programmer’s requierements. The theoretical part of this paper describes the OSGi, the Spring framework and the principles of component-based development. The second part aims to describe the design and implemenation of the library.

(5)

Obsah

1 Uvod´ 3

2 Komponentov´e programov´an´ı 4

2.1 Komponenty . . . 4

2.1.1 Definice a vlastnosti . . . 4

2.1.2 Komponentov´e rozhran´ı . . . 6

2.1.3 Komponentov´y model . . . 7

2.1.4 Komponentov´y framework . . . 9

2.1.5 Kompozice . . . 9

2.2 Platforma OSGi . . . 10

2.2.1 Modularita v Javˇe . . . 10

2.2.2 Architektura OSGi . . . 11

2.2.3 Komponenty v OSGi . . . 13

2.2.4 Zivotn´ı cyklus bundluˇ . . . 14

2.2.5 OSGi framework . . . 15

2.2.6 Sluˇzby . . . 16

2.3 Spring . . . 16

2.3.1 Dependency Injection . . . 17

2.3.2 Spring DM (Blueprint) . . . 18

3 Simul´ator Simco 20 3.1 Komponenty . . . 20

3.2 Ud´alosti . . . 21

3.3 Konfigurace . . . 22

(6)

OBSAH OBSAH

4 Anal´yza 24

4.1 Poˇzadavky na aplikaci . . . 24

4.2 Pouˇzit´e prostˇredky . . . 24

4.3 N´avrh prostˇred´ı . . . 25

4.4 Dynamick´e GUI . . . 25

5 Implementace 27 5.1 Poskytovan´e API . . . 27

5.1.1 Vytvoˇren´ı okna . . . 27

5.2 Nastavovac´ı prvky . . . 28

5.2.1 Nastaven´ı celoˇc´ıseln´e promˇenn´e . . . 28

5.2.2 Nastaven´ı reálné promˇenné . . . 28

5.2.3 Nastaven´ı textov´e promˇenn´e . . . 29

5.2.4 Nastaven´ı promˇenn´e typu pole . . . 29

5.3 Sledovac´ı prvky . . . 29

5.3.1 Sledov´an´ı promˇenn´e . . . 29

5.3.2 Logovac´ı komponenta . . . 30

5.4 Validace okna . . . 31

5.5 Komunikace . . . 31

5.5.1 Zas´ıl´an´ı zpr´av . . . 31

5.5.2 Konfiguraˇcn´ı soubor . . . 32

5.5.3 Spuˇstˇen´ı komponenty . . . 33

5.6 Uk´azka pouˇzit´ı . . . 34

6 Z´avˇer 36

Pˇrehled zkratek 37

Literatura 38

(7)

1 Uvod ^´

C´ılem této práce je implementovat knihovnu, která vytvoˇr´ı grafické uˇzivatel- ské rozhran´ı usnadˇnuj´ıc´ı ovládán´ı testován´ı simulovaných komponent. Toto GUI bude generované dynamicky a bude obsahovat prvky na základˇe po- ˇ

zadavk˚u programátora komponent. Knihovna umoˇzn´ı nastavovat parametry jednotlivých komponent v simulaci a zároveˇn sledovat promˇenné a parametry komponent jiných a zobrazovat je v grafické ˇci textové podobˇe.

V prvn´ı, teoretické, ˇcásti práce je text zamˇeˇren na vysvˇetlen´ı základn´ıch pojm˚u komponentového programován´ı a seznámen´ı se s frameworky OSGi a Spring. Dále bude pˇredstaven simulátor komponent Simco, který je vyv´ıjen na Katedˇre informatiky a výpoˇcetn´ı techniky Fakulty aplikovaných vˇed Zá- padoˇceské univerzity v Plzni. Realizaˇcn´ı ˇcást bude zamˇeˇrena na samotnou aplikaci vytvoˇrenou v rámci této bakaláˇrské práce.

(8)

2 Komponentov´ e programov´ an´ı

Komponenty, komponentové programován´ı a komponentový software v posledn´ıch letech nabývaj´ı na d˚uleˇzitosti. Základn´ı myˇslenka komponentovˇe ori- entovaného softwarového inˇzenýrstv´ı (CBSE)¹ je vytváˇren´ı aplikac´ı propojo- ván´ım jednotlivých na sobˇe nezávislých ˇcást´ı, tzv. komponent. Tento pˇr´ıstup umoˇzˇnuje urychlit vývoj aplikac´ı, jejich dlouhodobou udrˇzitelnost a v ne- posledn´ı ˇradˇe zlevnit ceny software d´ıky znovupouˇzitelnosti jiˇz existuj´ıc´ıch komponent.

2.1 Komponenty

2.1.1 Definice a vlastnosti

Definic softwarové komponenty existuje mnoho, pro úˇcely této práce jsem vybral tyto dvˇe: Podle Clemense Szyperského [1] je softwarová komponenta jednotka kompozice skládaj´ıc´ı se ze smluvnˇe specifikovaných rozhran´ı a expli- citn´ıch kontextových závislost´ı. Softwarová komponenta m˚uˇze být nasazena nezávisle a je pˇredmˇetem kompozice tˇret´ıch stran. Jiná definice [6] ˇr´ıká, ˇze komponenta je nezávisle dodávaná jednotka, která zapouzdˇruje sluˇzby za ve- ˇrejné rozhran´ı a která m˚uˇze být skládána s dalˇs´ımi komponentami.

Obecnˇe pro komponenty plat´ı [3]:

• neveˇrejn´a (skryt´a) implementace funkcionality,

• jsou pouˇz´ıv´any tˇret´ı stranou (third-party),

• odpov´ıdaj´ı komponentov´emu modelu.

1Component-based software engineering nebo tak´e CBD – component-based development.

(9)

Komponentov´e programov´an´ı Komponenty

Základn´ı vlastnost komponent je skrytá implementace pˇred okol´ım. Je- diným zp˚usobem, jak m˚uˇze tˇret´ı strana vyuˇz´ıt komponentu, je pˇres jej´ı rozhran´ı. Tento princip je znám jako

”black-box“ model. Komponenta nemá pˇr´ıstup k implementaci ostatn´ıch komponent, ale pouze k jejich veˇrejnému rozhran´ı. T´ım je odstranˇena závislost na konkrétn´ı implementaci a komponenta je snadno nahraditelná.

Z hlediska vývoje komponent a maximalizace moˇzné znovupouˇzitelnosti je d˚uleˇzité brát v potaz, jak velkou funkcionalitu by mˇely komponenty za- pouzdˇrovat. Lze ˇr´ıci, ˇze pˇr´ıliˇs jednoduché komponenty vlastnˇe nemaj´ı smysl a komponenty, které se snaˇz´ı zahrnout pˇr´ıliˇs komplexn´ı funkˇcnost, jsou zase málo flexibiln´ı.

Na obrázku 2.1 jsou znázornˇeny vztahy mezi komponentami, komponen- tovým modelem a komponentovým frameworkem. Tyto pojmy budou vysvˇet- leny dále.

Obr´azek 2.1: Komponenta, model, framework a jejich vztah [3]

Komponenta (1) je softwarová implementace, která m˚uˇze být spuˇstˇena na fyzickém nebo logickém zaˇr´ızen´ı. Komponenta m˚uˇze implementovat jedno

(10)

nebo v´ıce poˇzadovaných rozhran´ı (2). D´ıky rozhran´ı m˚uˇze být mezi dvˇema komponentami navázána komunikace. Povinnosti a závazky, které mus´ı komunikuj´ıc´ı komponenty plnit, specifikuj´ı tzv. kontrakty (3). Kontrakty zajiˇs- t’uj´ı, ˇze se nezávisle vyv´ıjené komponenty budou ˇr´ıdit urˇcitými pravidly tak, aby interakce komponent prob´ıhaly pˇredv´ıdatelným zp˚usobem a aby mohly být nasazeny do standardn´ıch bˇehových prostˇred´ı (4). Komponentovˇe ori- entované systémy jsou zaloˇzeny na malém poˇctu r˚uzných komponentových typ˚u, z nichˇz kaˇzdý z nich má jedineˇcnou roli (5) a je popsán rozhran´ım (2).

Komponentový model (6) je soubor komponentových typ˚u, jejich rozhran´ı a specifikac´ı pˇr´ıpustných interakc´ı mezi komponentovými typy. Komponentový framework pak poskytuje r˚uzné sluˇzby (8) podporuj´ıc´ı a vynucuj´ıc´ı kompo- nentový model. V mnoha ohledech lze komponentový framework pˇrirovnat ke speciáln´ımu operaˇcn´ımu systému [3].

V´yhody komponentov´eho pˇr´ıstupu:

• nezávislý vývoj a nasazen´ı,

• nezávislá rozˇs´ıˇren´ı a snadná nahraditelnost komponent,

• znovupouˇzitelnost,

• kratˇs´ı doba uveden´ı produktu na trh,

• uspora ˇ´ casu a prostˇredk˚u pˇri v´yvoji,

• dlouhodob´a udrˇzitelnost syst´emu.

2.1.2 Komponentov´ e rozhran´ı

Jak jiˇz bylo zm´ınˇeno, jediný moˇzný pˇr´ıstup ke sluˇzbám komponenty je skrze jej´ı rozhran´ı. Je tedy d˚uleˇzité, aby toto rozhran´ı pro interakci s ostatn´ımi komponentami bylo jasnˇe definované a zdokumentované. Stabiln´ı rozhran´ı zajist´ı logické oddˇelen´ı jednotlivých komponent a zamez´ı neˇzádouc´ım pˇr´ıstu- p˚um k vnitˇrn´ı implementaci. V ideáln´ım pˇr´ıpadˇe by rozhran´ı mˇelo být defi- nováno na základˇe toho, co komponenta poskytuje a vyˇzaduje od ostatn´ıch

(11)

komponent [4]. Komponenta obvykle ke své funkˇcnosti poˇzaduje rozhran´ı jiné komponenty, které znaˇc´ıme jako required. Rozhran´ı, která komponenta poskytuje, jsou oznaˇcována provided.

Na obrázku 2.2 je znázornˇeno komponentové rozhran´ı mezi dvˇema komponentami, kde komponenta A poskytuje poˇzadované vlastnosti komponentˇe B a komponenta B tyto vlastnosti vyˇzaduje.

Obr´azek 2.2: Rozhran´ı mezi komponentami

2.1.3 Komponentov´ y model

Komponentový model je definice standard˚u pro implementaci komponenty, jej´ı dokumentaci a nasazen´ı. Komponentový model zajiˇst’uje, aby nezávisle vyv´ıjené komponenty mohly být bez problém˚u nasazeny ve spoleˇcném bˇeho- vém prostˇred´ı. Model také urˇcuje, jak by mˇela být definována rozhran´ı a jaké prvky by tato definice mˇela obsahovat. Vˇsechny komponenty mus´ı splˇnovat poˇzadavky komponentového modelu.

Mezi tyto poˇzadavky patˇr´ı [3]:

• Komponentové typy – komponentový typ lze definovat na základˇe rozhran´ı, které komponenta implementuje. Pokud implementuje tˇri r˚uzná rozhran´ı X, Y a Z, tak komponenta je typu X, Y a Z a m˚uˇze libovolnˇe zastávat roli X, Y nebo Z. Komponentový model vyˇzaduje, aby komponenta implementovala jedno nebo v´ıce rozhran´ı. Pak m˚uˇze model definovat jeden nebo v´ıce komponentových typ˚u. R˚uzné komponentové typy pak mohou v systému zastávat odliˇsné role a mohou být zapojeny v r˚uzných schématech interakce.

(12)

• Schémata interakc´ı komponent – komponentový model specifikuje po- uˇzité komunikaˇcn´ı protokoly a zp˚usob dosaˇzen´ı poˇzadované kvality slu- ˇ

zeb, jako je zabezpeˇcen´ı nebo transakce. D´ale model popisuje, jak komponenty komunikuj´ı mezi sebou nebo s komponentov´ym frameworkem.

Interakˇcn´ı schémata mohou být spoleˇcná pro vˇsechny komponentové typy, nebo jedineˇcná pro jednotlivé z nich.

• Navázán´ı zdroj˚u – proces skládán´ı komponent je záleˇzitost navazován´ı komponent na jeden nebo v´ıce zdroj˚u. Zdrojem je myˇslena bud’ sluˇzba poskytovaná komponentovým frameworkem nebo jiná komponenta na- sazená v daném frameworku. Komponentový model popisuje zdroje dostupné komponentám a také to, jak a kdy jsou komponenty nava- zovány na tyto zdroje. Naopak, framework povaˇzuje komponenty za zdroje, které je tˇreba ˇr´ıdit.

Komponentových model˚u existuje celá ˇrada, následuje výˇcet nˇekolika z nich.

Kapitola 2.2 je pak celá vˇenována komponentovému model OSGi pouˇzitému pˇri vývoji aplikace vytváˇrené v rámci této práce.

Pˇr´ıklady komponentov´ych model˚u:

• Enterprise JavaBeans (EJB)– komponentová architektura, slouˇz´ıc´ı pro realizaci aplikaˇcn´ı vrstvy informaˇcn´ıho systému. EJB komponenty jsou objekty implementované vývojáˇrem, které zajiˇst’uj´ı vlastn´ı aplikaˇcn´ı logiku systému. Jedná se o souˇcást platformy Java EE² [7].

• Component Object Model (COM) – platformˇe nezávislý, distribuovaný, objektovˇe orientovaný systém pro vytváˇren´ı binárn´ıch softwarových komponent, které jsou schopny spolupracovat. Byl uveden spoleˇcnost´ı Microsoft v roce 1993.

• Common Object Request Broker Architecture (CORBA) – standard definovan´y konsorciem OMG (Object Management Group) tvoˇr´ıc´ı ucele-

2Java Platform, Enterprise Edition – standardizovaná platforma urˇcená pro vývoj pˇre- nositelných, robustn´ıch, ˇskálovatelných a bezpeˇcných serverových aplikac´ı v jazyce Java.

(13)

nou architekturu pro podporu tvorby distribuovaných objektovˇe orien- tovaných aplikac´ı. Model je nezávislý na operaˇcn´ım systému, progra- movém vybaven´ı nebo programovac´ım jazyku.

• OSGi Service Platform – je specifikace dynamického modulárn´ıho sys- tému pro programovac´ı jazyk Java.

2.1.4 Komponentov´ y framework

Komponentový framework je implementac´ı komponentového modelu, respektive sluˇzeb, které daný komponentový model vynucuje [3]. Komponentový framework ˇr´ıd´ı ˇzivotn´ı cyklus komponent a zprostˇredkovává jejich vzájemné interakce. Jeden komponentový framework m˚uˇze implementovat v´ıce kompo- nentových model˚u.

Komponentový framework lze pˇrirovnat k malému operaˇcn´ımu systému.

V této analogii jsou komponenty pro framework to samé, co jsou procesy pro operaˇcn´ı systém. Komponentový framework ˇr´ıd´ı zdroje sd´ılené komponentami, poskytuje základn´ı mechanizmy umoˇzˇnuj´ıc´ı komunikaci mezi komponentami a ˇr´ıd´ı ˇzivotn´ı cyklus komponent [3].

2.1.5 Kompozice

Kompozice je term´ın popisuj´ıc´ı, jak jsou skládány systémy pˇri komponentovˇe orientovaném vývoji.

Z obrázku 2.1, na kterém je znázornˇen princip komponentovˇe orientova- ného systému, lze identifikovat dva subjekty, které jsou souˇcást´ı kompozice:

komponenty a frameworky. D´ıky tomu existuj´ı tˇri hlavn´ı kategorie interakc´ı vznikaj´ıc´ıch v CBD [3]:

• Komponenta-komponenta – Kompozice, kter´a umoˇzˇnuje interakce mezi komponentami. Tyto interakce dod´avaj´ı aplikaˇcn´ı funkcionalitu. Kon-

(14)

Komponentov´e programov´an´ı Platforma OSGi

trakty specifikuj´ıc´ı tyto interakce jsou klasifikov´any jako kontrakty apli- kaˇcn´ı ´urovnˇe.

• Framework-komponenta – Kompozice, která umoˇzˇnuje interakce mezi komponentovým frameworkem a jeho komponentami. Tyto interakce dovoluj´ı frameworku ˇr´ıdit komponentové zdroje. Kontrakty specifikuj´ıc´ı tyto interakce jsou klasifikovány jako kontrakty systémové úrovnˇe.

• Framework-framework – Kompozice, která umoˇzˇnuje interakce mezi frameworky. Tyto interakce umoˇzˇnuj´ı kompozici komponent nasaze- ných v r˚uzných frameworc´ıch. Tyto kontrakty jsou klasifikovány jako kontrakty mezioperaˇcn´ı úrovnˇe.

2.2 Platforma OSGi

V následuj´ıc´ı ˇcásti je popsána technologie OSGi. Vˇetˇsina textu vycház´ı ze:

[4] a [10].

2.2.1 Modularita v Javˇ e

Jiˇz bylo ˇreˇceno, ˇze v dneˇsn´ı dobˇe je kladen velk´y d˚uraz na modularitu aplikac´ı. V programovac´ım jazyce Java jsou vˇsak tyto moˇznosti znaˇcnˇe omezen´e.

Aplikace vytvoˇrené v Javˇe jsou typicky distribuovány v JAR³ archivech, coˇz je souborový formát zaloˇzený na ZIP kompresi, který umoˇzˇnuje slouˇcit nˇeko- lik soubor˚u do jednoho. Jsou v nˇem obsaˇzeny pˇredevˇs´ım soubory typuclass, metadata a pˇr´ıpadné dalˇs´ı zdroje pro úˇcely aplikace jako obrázky nebo tex- tové dokumenty.

JAR soubory obvykle poskytuj´ı jednu knihovnu nebo pouze ˇcást funkcionality aplikace. Jen zˇr´ıdka aplikaci tvoˇr´ı pouze jeden JAR archiv, rozsáhlé

3Souborový formát JAR – akronym vytvoˇrený z

”Java archive“. Soubory maj´ı pˇr´ıponu .jar. V´ıce na [8].

(15)

aplikace se mohou skl´adat z des´ıtek aˇz stovek tˇechto soubor˚u [4]. Je zˇrejm´e, ˇ

ze kompozice tak velkého rozsahu je nároˇcná na správu a ˇr´ızen´ı, avˇsak Java sama o sobˇe nenab´ız´ı uspokojivé nástroje a technologie ke splnˇen´ı poˇzadavk˚u komponentovˇe orientovaného programován´ı tak, jak jsme je popsali v pˇred- choz´ıch kapitolách.

Zde je pˇrehled nejz´asadnˇejˇs´ıch nedostatk˚u⁴ spojen´ych s pouˇzit´ım JAR soubor˚u jako jednotek nasazen´ı [4]:

• Nedostatky naˇc´ıtán´ı zdroj˚u z classpath, moˇznosti konflikt˚u v pˇr´ıpadech, kdy se v aplikaci vyskytuje v´ıce tˇr´ıd se stejným jménem. Classloader vˇzdy naˇcte prvn´ı verzi tˇr´ıdy daného jména, na kterou naraz´ı.

• Neobsahuj´ı metadata ukazuj´ıc´ı jejich z´avislosti.

• Slabá podpora verzován´ı, nˇekolik r˚uzných verz´ı nem˚uˇze být spuˇstˇeno souˇcasnˇe.

Z výˇse uvedených d˚uvodu vznikla pro platformu Java specifikace OSGi, která tyto problémy odstraˇnuje.

2.2.2 Architektura OSGi

Technologie OSGi je specifikace dynamického modulárn´ıho systému pro platformu Java, která implementuje dynamický komponentový model. Standard je definován a udrˇzován mezinárodn´ım konsorciem OSGi Alliance zaloˇzeným v roce 1999. P˚uvodnˇe zkratka OSGi znamenala Open Services Gateway initiative, dnes se vˇsak jiˇz nepouˇz´ıvá a

”OSGi“ se stalo ochrannou zn´amkou.

OSGi umoˇzˇnuje instalaci, spouˇstˇen´ı, aktualizaci a odeb´ırán´ı modul˚u za bˇehu, tedy bez nutnosti zastaven´ı JVM (Java Virtual Machine). Dále pak definuje ˇzivotn´ı cyklus modulu a nab´ız´ı infrastrukturu pro spolupráci modul˚u

4Tyto nedostatky jsou tak znaˇcn´e, ˇze vzniklo pojmenov´an´ı

”JAR hell“.

(16)

skrze sluˇzby. Implementac´ı specifikace tohoto modul´arn´ıho syst´emu je OSGi framework, viz 2.2.5.

Na obrázku 2.3 je znázornˇena architektura OSGi a jej´ı jednotlivé vrstvy.

Obr´azek 2.3: Vrstvy v OSGi [9]

N´asleduje v´yˇcet vrstev s jejich popisem [10]:

• Bundles – bundly jsou OSGi komponenty vytvoˇren´e program´atory.

• Services – vrstva sluˇzeb dynamicky propojuje vytvoˇren´e bundly – za- jiˇst’uje komunikaci bundl˚u.

• Life Cycle – vrstva staraj´ıc´ı se o ˇzivotn´ı cyklus bundl˚u – instalaci, spuˇstˇen´ı, zastaven´ı, update a jejich odinstalov´an´ı.

• Modules– je vrstva staraj´ıc´ı se o zapouzdˇren´ı bundl˚u a definuj´ıc´ı, jak m˚uˇze bundle exportovat a importovat k´od.

• Execution Environment – definuje, jak´e metody a tˇr´ıdy konkr´etn´ı platforma nab´ız´ı.

• Security – vrstva zab´yvaj´ıc´ı se aspekty bezpeˇcnosti.

(17)

2.2.3 Komponenty v OSGi

V souvislosti se specifikac´ı OSGi nehovoˇr´ıme o komponentˇe nebo modulech, ale o tzv. bundle. Bundle je reprezentován JAR souborem, který mus´ı obsahovat manifest s informacemi o bundlu. V manifestu se nacházej´ı speci-

´

aln´ı hlaviˇcky obsahuj´ıc´ı informace, které framework potˇrebuje k úspˇeˇsné instalaci a spuˇstˇen´ı bundlu. Manifest se nacház´ı v JAR archivu na obvyklé cestˇe:META-INF/MANIFEST.MF. Prostˇrednictv´ım manifestu lze také nastavit, jaké sluˇzby budou dostupné ostatn´ım bundl˚um. Následuj´ıc´ı seznam obsahuje nˇekteré typické hlaviˇcky manifestu OSGi bundlu:

• Bundle-Name: Jm´eno bundlu (srozumiteln´e ˇclovˇeku).

• Bundle-SymbolicName: Jedineˇcný identifikátor bundlu. Je to jediná po- vinná hlaviˇcka manifestu.

• Bundle-Description: Kr´atk´y popis funkcionality bundlu.

• Bundle-ManifestVersion: Urˇcuje verzi OSGi, kter´a se m´a pouˇz´ıt.

• Bundle-Version: Verze bundlu.

• Export-Package: Seznam bal´ık˚u (packages), kter´e jsou viditeln´e a k dispozici ostatn´ım bundl˚um.

• Import-Package: Seznam bal´ık˚u, kter´e bundle vyuˇz´ıv´a a vyˇzaduje pro svoji funkˇcnost.

Pˇr´ıklad jednoduchého manifestu se nacház´ı ve výpisu 2.1.

D˚uleˇzitou vlastnost´ı bundl˚u je, ˇze kaˇzdý má sv˚uj vlastn´ı zavadˇeˇc tˇr´ıd (classloader), coˇz pˇrisp´ıvá k vzájemné izolaci bundl˚u a tedy modularitˇe celé aplikace.

(18)

Bundle−Name : H e l l o World

Bundle−SymbolicName : c z . zcu . k i v . h e l l o W o r l d Bundle−D e s c r i p t i o n : H e l l o World b u n d l e Bundle−M a n i f e s t V e r s i o n : 2

Bundle−V e r s i o n : 1 . 0 . 0

Export−Package : c z . zcu . k i v . h e l l o W o r l d ; v e r s i o n = ”1 . 0 . 0 ” Import−Package : o r g . o s g i . framework ; v e r s i o n = ”1 . 3 . 0 ”

V´ypis 2.1: Manifest OSGi bundlu

2.2.4 Zivotn´ı cyklus bundlu ˇ

Vrstva Life Cycle se stará o ˇzivotn´ı cyklus bundlu, který je zobrazen na obrázku 2.4.

Obr´azek 2.4: ˇZivotn´ı cyklus bundlu [4]

(19)

Stavy, ve kter´ych se m˚uˇze bundle nach´azet:

• INSTALLED – bundle byl ´uspˇeˇsnˇe nainstalov´an.

• RESOLVED – bundle je bud’ pˇripraven ke spuˇstˇen´ı (vˇsechny z´avislosti jsou splnˇeny a zdroje k dispozici), a nebo byl zastaven.

• STARTING – spouˇstˇen´ı bundlu, je zavol´ana metodastart()rozhran´ı BundleActivator.

• ACTIVE – bundle byl úspˇeˇsnˇe aktivován a bˇeˇz´ı, metodastart()pro- bˇehla úspˇeˇsnˇe.

• STOPPING – zastavov´an´ı bundlu. Je zavol´ana metoda stop() rozhran´ıBundleActivator.

• UNINSTALLED – bundle byl odinstalov´an, koneˇcn´y stav.

2.2.5 OSGi framework

V souˇcasné dobˇe existuje nˇekolik na sobˇe nezávislých open source implementac´ı standardu OSGi [4].

• Equinox – je zˇrejmˇe nejrozˇs´ıˇrenˇejˇs´ı OSGi framework [4], je souˇcást´ı vývojové platformy Eclipse. Equinox implementuje specifikaci OSGi 4.1 a je licencován pod Eclipse Public License (EPL).

• Knopflerfish – dalˇs´ı populárn´ı implementace OSGi, která implementuje jak OSGi 3, tak OSGi 4. Framework je vyv´ıjen spoleˇcnost´ı Makewave a je licencován pod BSD licenc´ı. Existuje i komerˇcn´ı verze Knopflerfish Pro.

• Apache Felix – mal´a a velmi kompaktn´ı implementace OSGi 4.x. Felix je vyv´ıjen neziskovou spoleˇcnost´ı Apache Software Foundation a licencov´an pod Apache License Version 2.0.

(20)

Komponentov´e programov´an´ı Spring

• Concierge – je velmi kompaktn´ı a vysoce optimalizovaná implementace OSGi Release 3, která je urˇcena zejména pro platformy s omezenými zdroji, jako jsou mobiln´ı telefony nebo embedded zaˇr´ızen´ı. Concierge je licencován pod BSD licenc´ı.

2.2.6 Sluˇ zby

Moduly spolu mohou komunikovat kromˇe sd´ılen´ı Java bal´ık˚u, které je rea- lizováno nastavován´ım viditelnosti v manifestu (hlaviˇcky Export-Package a Import-Package), i pomoc´ı sluˇzeb. Pˇr´ıstup ke sluˇzbˇe je definován pomoc´ı Java rozhran´ı, které pˇredstavuje kontrakt mezi poskytovatelem a klientem.

Poskytovatel sluˇzby registruje sluˇzbu do registru sluˇzeb. Naopak klient vyu- ˇ

z´ıvá registr k vyhledán´ı poˇzadované sluˇzby a jej´ı následné vyuˇzit´ı. O zajiˇstˇen´ı tohoto mechanizmu se stará vrstva Service Layer.

2.3 Spring

Spring Framework je Java platforma, která poskytuje komplexn´ı infrastrukturu podporuj´ıc´ı vývoj Java aplikac´ı. Framework zajiˇst’uje infrastrukturu a programátor se tak m˚uˇze soustˇredit na samotnou implementaci. Hlavn´ım

´

uˇcelem je usnadnit vývoj v oblasti Java EE aplikac´ı. Spring je modulárn´ı framework organizovaný do dvaceti modul˚u a umoˇzˇnuje pouˇz´ıt jen ty ˇcásti, které programátor skuteˇcnˇe pouˇzije [11].

Jádro Springu je tvoˇreno Spring kontejnerem. Objekty, se kterými pracuje kontejner, se nazývaj´ı tzv.beany(anglicky beans). V terminologii komponen- tového programován´ı beany lze nazvat komponentami. Framework vyuˇz´ıvá konceptu Inversion of control, viz dále.

(21)

2.3.1 Dependency Injection

Návrhový vzor Inversion of Control usnadˇnuje správu objekt˚u a závislost´ı t´ım, ˇze pˇrenáˇs´ı odpovˇednost za vytváˇren´ı instanc´ı tˇr´ıd, inicializaci a prová- zán´ı objekt˚u z aplikace na framework [11]. Jednotlivé objekty tˇr´ıd si samy nevytváˇrej´ı ostatn´ı objekty, na kterých závis´ı, ale udˇelá to za nˇe Spring. Ve Springu je tento pˇr´ıstup znám jako Dependency Injection, tedy volnˇe pˇrelo- ˇ

zeno jako vkládán´ı závislost´ı. Výsledkem je vˇetˇs´ı vˇetˇs´ı kontrola nad objekty, vˇetˇs´ı znovupouˇzitelnost aplikace a jej´ı lepˇs´ı udrˇzitelnost. Existuj´ı dva hlavn´ı zp˚usoby Dependency Injection:

1. Konstruktorem – pˇri inicializaci je Springem zavolán konstruktor s pa- rametrem, který je v elementu constructor-arg. Atribut ref⁵ je reference na vkládaný objekt.

2. Setterem – vloˇzen´ı se provád´ı setterem. Parametr je definován v ele- mentuproperty, pˇriˇcemˇz setter mus´ı být pojmenován ve tvarusetName, kde Name je hodnota atributu stejného jména. Reference na vkládaný objekt se nacház´ı opˇet v atributuref.

Oba zp˚usoby jsou ukázány ve výpisu 2.2, jenˇz zobrazuje ˇcást konfigu- raˇcn´ıho XML souboru. Tento soubor obsahuje definice bean˚u a je nezbytnou souˇcást´ı kaˇzdé aplikace vyuˇz´ıvaj´ıc´ı Spring.

1 <beans>

2 <bean i d =”f o o ” c l a s s =”x . y . Foo”>

3 <c o n s t r u c t o r−a r g r e f =”ba r ”/>

4 <p r o p e r t y name=”baz ” r e f =”baz ”/>

5 </bean>

6

7 <bean i d =”ba r ” c l a s s =”x . y . Bar”/>

8 <bean i d =”baz ” c l a s s =”x . y . Baz”/>

9 </beans>

V´ypis 2.2: Dependency Injection ve Springu

5Lze tak´e vloˇzit parametr pˇr´ımo pomoc´ı atributuvalue.

(22)

2.3.2 Spring DM (Blueprint)

V pˇredchoz´ıch kapitolách byly popsány technologie OSGi a Spring. Spoje- n´ım tˇechto dvou technologi´ı vznikl komponentový model Spring DM, který dovoluje vyuˇz´ıvat výhod obou z nich.

V souˇcasné dobˇe je technologie Spring DM souˇcást´ı OSGi⁶ pod názvem Blueprint. Blueprint vycház´ı z modelu Spring DM, rozd´ıly mezi nimi jsou ne- velkého významu. Zmˇeny, které se týkaj´ı pˇredevˇs´ım konfiguraˇcn´ıho souboru, jsou popsány v [12].

Spring DM, respektive Blueprint je tvoˇren nˇekolika OSGi bundly. Tyto bundly jsou zodpovˇedné za vytváˇren´ı tzv. aplikaˇcn´ıho kontextu, který obsahuje a spravuje beany. Pˇri spojen´ı obou technologi´ı vnesena do aplikace nová modularita. V bˇeˇzné Spring aplikaci totiˇz existuje pouze jeden aplikaˇcn´ı kontext, který je sd´ılený pro celou aplikaci. Oproti tomu Spring DM vytváˇr´ı pro kaˇzdý OSGi bundle aplikaˇcn´ı kontext sv˚uj vlastn´ı. To znamená, ˇze beany v jednom bundlu nemohou pˇristupovat k bean˚um v ostatn´ıch bundlech [5].

Aby bylo v aplikaci budované s pouˇzit´ım OSGi moˇzné vyuˇz´ıvat Spring, je nutné, aby bundle obsahoval Spring konfiguraˇcn´ıXMLsoubor. Tento soubor je tˇreba um´ıstit do adresáˇreMETA-INF/spring⁷. Druhou variantu je specifikovat um´ıstˇen´ı konfiguraˇcn´ıho souboru pˇr´ımo v manifestu, a to hlaviˇckou Spring- context. V tomto pˇr´ıpadˇe m˚uˇze být um´ıstˇen´ı libovolné [5].

Významným pˇr´ınosem Spring DM je ulehˇcen´ı práce se sluˇzbami OSGi pouˇzit´ım jmenného prostoru (namespace)osgi. Prostˇrednictv´ım konfiguraˇc- n´ıho souboru lze nastavit, jaké sluˇzby bude bundle vyuˇz´ıvat a jaké poskyto- vat.

I kdyˇz aktuálnˇeji se jev´ı pouˇzit´ı kontejneru Blueprint, v realizaˇcn´ı ˇcásti této práce je pouˇzit Spring DM, a proto i ukázka konfiguraˇcn´ıho souboru ve výpisu 2.3 je uvedena dle konvenc´ı Spring DM.

6A to od specifikace OSGi 4.2.

7V pˇr´ıpadˇe Blueprintu se jedn´a o um´ıstˇen´ıOSGI-INF/blueprint.

(23)

1 <?xml v e r s i o n = ”1 . 0 ” e n c o d i n g =”UTF−8”?>

2 <b e a n s xmlns=”h t t p : / /www. s p r i n g f r a m e w o r k . o r g / schema / b e a n s ”

3 xmlns : x s i =”h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ” 4 xmlns : o s g i =”h t t p : / /www. s p r i n g f r a m e w o r k . o r g / schema / o s g i ”

5 x s i : s c h e m a L o c a t i o n =”h t t p : / /www. s p r i n g f r a m e w o r k . o r g / schema / b e a n s 6 h t t p : / /www. s p r i n g f r a m e w o r k . o r g / schema / b e a n s / s p r i n g−beans−2 . 0 . xsd 7 h t t p : / /www. s p r i n g f r a m e w o r k . o r g / schema / o s g i

8 h t t p : / /www. s p r i n g f r a m e w o r k . o r g / schema / o s g i / s p r i n g−o s g i −1 . 0 . xsd ”>

9

10 <o s g i : s e r v i c e i d =”s e t t i n g s ”

11 r e f =”c o n t r o l ” i n t e r f a c e =”g u i . I S e t t i n g s ” />

12 <o s g i : r e f e r e n c e i d =”m e s s a n g e r ”

13 i n t e r f a c e =”o r g . o s g i . s e r v i c e . e v e n t . EventAdmin ” />

14

15 <bean i d =”c o n t r o l ” c l a s s =”g u i . C o n t r o l ”>

16 <c o n s t r u c t o r−a r g r e f =”m e s s a n g e r ”> </ c o n s t r u c t o r−arg>

17 </bean>

18

19 </beans>

V´ypis 2.3: Spring DM konfiguraˇcn´ı soubor

V ukázce 2.3 je na ˇrádc´ıch 10 a 11 pomoc´ı elementu osgi:servicezare- gistrována sluˇzba gui.ISettings. Tato sluˇzba je tedy poskytnuta ostatn´ım bundl˚um. Oproti tomu element osgi:reference zajiˇst’uje, ˇze bundle m˚uˇze vyuˇz´ıvat sluˇzbuEventAdmin. Instance této sluˇzby je pˇredána pomoc´ı mechanizmu Dependency Injection konstruktorem.

(24)

3 Simul´ ator Simco

Simco je framework, který vznikl na Katedˇre informatiky a výpoˇcetn´ı techniky Fakulty aplikovaných vˇed Západoˇceské univerzity v Plzni v rámci di- plomových prac´ı Tomáˇse Kab´ıˇcka [13] a Matˇeje Prokopa [14] v roce 2011, kdy prvn´ı jmenovaný vytvoˇril jádro frameworku a druhý pak jeho grafické rozhran´ı. Název Simco je odvozen z anglického Simulation of Component.

Celý simulátor je vytvoˇren ze softwarových komponent, coˇz vypov´ıdá o jeho modulárnosti.

Uˇćelem simulátoru je poskytnout nástroj k testován´ı reálných softwaro- vých komponent v simulaˇcn´ım prostˇred´ı bez nutnosti vytváˇret jejich modely, které by mohly být potenciálnˇe chybné. Testován´ı prob´ıhá za pouˇzit´ı principu diskrétn´ı událostn´ı simulace s pˇredem daným scénáˇrem. Aplikace, která je na tento framework napojena se nazývá Simco aplikace.

Framework je tvoˇren ˇctyˇrmi z´akladn´ımi stavebn´ımi prvky [13]:

• Komponenty – objekty reprezentuj´ıc´ı komponenty.

• Ud´alosti – objekty reprezentace ud´alost´ı simulace bˇehu Simco aplikace.

• Kalendáˇr – ukládá a spravuje události, obsahuje jejich seznam, zajiˇst’uje kontrolu nad bˇehem celé Simco aplikace. Obsahuje simulaˇcn´ı ˇcas, který se inkrementuje po kaˇzdém kroku simulace a urˇcuje, která událost má být vykonána.

• Simulace – objekt, kter´ym se manipuluje s celou simulac´ı.

3.1 Komponenty

Jak bylo ˇreˇceno, Simco aplikace se skládá z komponent, konkrétnˇe ze Spring DM modul˚u. Framework pracuje s nˇekolika druhy komponent, které je tˇreba rozliˇsit. Jednotlivé typy jsou uvedeny v následuj´ıc´ım výˇctu [13]:

(25)

Simul´ator Simco Ud´alosti

• SIMULATION – simulaˇcn´ı komponenta. Neprovád´ı reálný výpoˇcet, jej´ı bˇeh je pouze nasimulovaný. Zastupuje reálný systém a vrac´ı data, která strukturou pˇripom´ınaj´ı data reálná. Uˇzivatel m˚uˇze prostˇrednic- tv´ım konfiguraˇcn´ıch soubor˚u nastavit délku simulovaného výpoˇctu a hodnoty, které komponenta vrát´ı.

• REAL – reálná komponenta, která provád´ı reálný výpoˇcet a která je testována. Nemˇela by vˇedˇet o tom, ˇze je napojena na Simco framework, nedocház´ı tedy k úpravám jej´ıho kódu.

• INTERMEDIATE – komponenta typu prostˇredn´ık. Je potˇrebná k tomu, aby mohl framework sledovat komunikaci dvou reálných komponent.

• FRAMEWORK – komponenty, kter´e obsahuj´ı implementaci frameworku Simco.

3.2 Ud´ alosti

Hlavn´ı princip fungován´ı simulátoru spoˇc´ıvá v tom, ˇze kaˇzdý krok, který se v Simco aplikaci provede, je spojen s událost´ı ve frameworku. Pokud prob´ıhá komunikace mezi komponentami, Simco framework ji zachyt´ı, vytvoˇr´ı událost a vloˇz´ı ji do kalendáˇre. Vloˇzená událost m˚uˇze zp˚usobit vznik dalˇs´ıch událost´ı.

V simulátoru mohou vzniknout následuj´ıc´ı typy události [13]:

• REAL_CALL – metoda reálné komponenty komunikuje s nˇekterou z ji- ných komponent Simco aplikace.

• REAL_RETURN – návrat z volané metody reálné komponenty.

• SIMULATION_CALL – simulaˇcn´ı metoda komunikuje s nˇekterou z jin´ych komponent Simco aplikace.

• SIMULATION_RETURN – n´avrat z volan´e metody simulaˇcn´ı komponenty.

• REGULAR – periodicky vyskytuj´ıc´ı se ud´alost.

(26)

Simul´ator Simco Konfigurace

• CASUAL – ud´alost, u kter´e lze nadefinovat, s jakou pravdˇepodobnost´ı se bude vyskytovat.

Komponenty tˇret´ıch stran lze napojit na Simco framework prostˇrednic- tv´ım OSGi bundlu EventAdmin. Ten umoˇzˇnuje publikovat události mezi jed- notlivými bundly. Historie pr˚ubˇehu simulace se ukládá do souboru. Samotné jádro frameworku se skládá z ˇsesti komponent, jejich podrobný popis lze nalézt v [13].

3.3 Konfigurace

Simulaci lze nakonfigurovat pomoc´ı XML souboru. Prostˇrednictv´ım konfigu- raˇcn´ıho souboru je moˇzno nastavit tzv. scénáˇr pr˚ubˇehu simulace. Ve scénáˇri lze nadefinovat události typu CASUAL, REGULAR, seznam komponent Simco aplikace s jejich vlastnostmi a nastaven´ı Simco aplikace. Ve výpisu 3.1 je uveden pˇr´ıklad jednoduchého scénáˇre.

Koˇrenový element XML souboru má název simCoScenario. Seznam komponent se nacház´ı v elementucomponents. Kaˇzdá komponenta má definovaný sv˚uj typ, jedineˇcné jméno⁸ a cestu ke svému konfiguraˇcn´ımu souboru bundlu.

V elementu events jsou definovány události. U kaˇzdé události je uveden jej´ı typ (REGULAR nebo CASUAL), zdroj události, rozhran´ı, pˇres které je volaná sluˇzba registrována, jméno volané metody a parametry této metody.

V elementu eventDetails je nadefinováno, jak ˇcasto se má daná událost opakovat. Podle typu události je nastavena bud’ perioda, a nebo náhodná veliˇcina. V´ıce viz [13].

V elementuappSettings lze nastavit zpoˇzdˇen´ı kroku simulace, a to bud’

v milisekund´ach nebo v sekund´ach.

8Shodn´e s obsahem hlaviˇcky Bundle-SymbolicNamev manifestu komponenty.

(27)

Simul´ator Simco Konfigurace

1 <?xml v e r s i o n = ”1 . 0 ” e n c o d i n g =”UTF−8”?>

2 <s i m C o S c e n a r i o>

3 <components>

4 <component t y p e =”SIMULATION”>

5 <symbolicName>SimcoGPS</symbolicName>

6 <s e t t i n g s F i l e> C: / SimcoGPS/ g p s S e t t i n g s . xml </ s e t t i n g s F i l e>

7 </component>

8 </components>

9 <e v e n t s>

10 <e v e n t t y p e =”REGULAR”>

11 <s o u r c e>S i m c o A c c e l e r o m e t e r</s o u r c e>

12 <serviceN a me>s i m c o . a p p l i c a t i o n . I A c c e l e r o m e t e r</serviceN a me>

13 <methodName>s e t V e c t o r</methodName>

14 <methodParameters>

15 <p a r a m e t e r dataType=”j a v a . l a n g . I n t e g e r ” v a l u e =”10” />

16 </methodParameters>

17 <e v e n t D e t a i l s>

18 <d e t a i l key =”p e r i o d ” v a l =”10” />

19 </ e v e n t D e t a i l s>

20 </e v e n t>

21 </e v e n t s>

22 <a p p S e t t i n g s>

23 <s t e p L e n g h t u n i t =”msec”>500</ s t e p L e n g h t>

24 </ a p p S e t t i n g s>

25 </s i m C o S c e n a r i o>

Výpis 3.1: Scénáˇr simulace

(28)

4 Anal´ yza

4.1 Poˇ zadavky na aplikaci

C´ılem této práce je vytvoˇrit komponentu, pomoc´ı které bude moˇzné vytvoˇrit dynamicky generované grafické uˇzivatelské rozhran´ı. Toto GUI bude slouˇzit k usnadnˇen´ı ovládán´ı testován´ı komponent. Vyvinutá komponenta bude m´ıt dvˇe základn´ı funkce:

1. nastavov´an´ı komponent, 2. sledov´an´ı komponent.

Nastavovac´ı ˇcást umoˇzn´ı odeslat data do simulace, a t´ım nastavovat jejich parametry. Druhá ˇcást funkcionality spoˇc´ıvá v moˇznosti sledovat data komponent. Zde bude vytváˇrená komponenta data pˇrij´ımat, zobrazovat a ukládat.

4.2 Pouˇ zit´ e prostˇ redky

Vytváˇrená komponenta bude nasazena jako samostatný modul do simulátoru Simco (viz kapitola 3). Simulátor je sloˇzen ze Spring DM bundl˚u. Z toho vy- plývá, ˇze vytváˇrená komponenta bude implementována v programovac´ım jazyce Java. Dále bude vyuˇzit framework OSGi a Spring, respektive technologie vyuˇz´ıvaj´ıc´ı výhod obou z nich – Spring DM.

K implementaci bude pouˇzito vývojové prostˇred´ı Eclipse Java EE 4.2, framework Spring DM 3.1, programovac´ı jazyk Java 1.7 a operaˇcn´ı systém Windows 7 Professional.

(29)

Anal´yza N´avrh prostˇred´ı

4.3 N´ avrh prostˇ red´ı

Okno aplikace je rozdˇeleno na dvˇe ˇcásti. V levé ˇcásti (1) se nacház´ı panel urˇcený k odes´ılán´ı dat do simulace. V pravé ˇcásti (2) jsou pak um´ıstˇeny sledovac´ı prvky. Obˇe ˇcásti jsou um´ıstˇeny do okna za pouˇzit´ı layoutuBoxLayout.

Tento layout ˇrad´ı komponenty podle nastaven´ı vedle sebe do ˇr´adku, a nebo pod sebe do sloupce. V naˇsem pˇr´ıpadˇe je pouˇzita horizont´aln´ı konfigurace.

Jednotlivé nastavovac´ı nebo sledovac´ı elementy (3) jsou pak uvnitˇr panel˚u (1) a (2) rozmist’ovány pod sebe pomoc´ı layoutuGridBagLayout. Rozvrˇzen´ı okna je znázornˇeno na obrázku 4.1.

Obrázek 4.1: Rozvrˇzen´ı grafického uˇzivatelského rozhran´ı

4.4 Dynamick´ e GUI

Z výˇse uvedeného vyplývá, ˇze GUI nebude m´ıt pokaˇzdé stejnou podobu, ale bude obsahovat prvky, o které si programátor komponent zaˇzádá. Defino- ván´ı toho, co má GUI obsahovat, se provád´ı prostˇrednictv´ım API, které tato komponenta poskytuje.

(30)

Anal´yza Dynamick´e GUI

Vytváˇrená komponenta umoˇzn´ı sledované komponentˇe zaregistrovat si promˇenné, které budou sledovány. Tato data bude moˇzné zobrazovat jak v textové podobˇe, tak v grafické ve formˇe grafu. Dále bude umoˇznˇeno pˇri- j´ımat zprávy informuj´ıc´ı o pr˚ubˇehu simulace, tˇr´ıdit je podle druh˚u, ukládat je do soubor˚u. Oproti tomu nastavovac´ı ˇcást API poskytne sluˇzby, kterými budou data odes´ılána do simulace, a t´ım bude umoˇznˇeno komponentu ˇr´ıdit, respektive nastavovat jej´ı parametry.

(31)

5 Implementace

5.1 Poskytovan´ e API

Stˇredobodem komunikace s vnˇejˇs´ımi komponentami je rozhran´ıISettings.

Rozhran´ı poskytuje programátorovi simulované komponenty sadu metod, pomoc´ı kterých se vytvoˇr´ı okno nastavovac´ıho modulu a jeho jednotlivé elementy. Zajiˇst’uje základn´ı komunikaci mezi uˇzivatelským rozhran´ım a komponentami. Prostˇredk˚u API je potˇreba jednak k vytvoˇren´ı ovládac´ıho a sledovac´ıho GUI, a jednak k nastavován´ı dat uvnitˇr ˇr´ızené komponenty, tedy k z´ıskán´ı uˇzivatelem zadané hodnoty.

5.1.1 Vytvoˇ ren´ı okna

public ControlGUI createWindow(String windowName);

Prvn´ı metoda, kterou programátor komponenty pouˇzije. Touto metodou je spuˇstˇena inicializace prázdného okna. Oken je z principu moˇzné vytvoˇrit v´ıce (pro v´ıce komponent), je tedy d˚uleˇzité rozliˇsit, v jakém oknˇe se prvek má vytvoˇrit. K tomu slouˇz´ı návratová hodnota této metody, která je pouˇzita jako parametr v dalˇs´ıch metodách tohoto rozhran´ı. Jediný parametr metody je celoˇc´ıselné ID panelu, které si urˇc´ı programátor. To slouˇz´ı jednak k rozliˇsen´ı jednotlivých oken uˇzivateli – ID je vidˇet v záhlav´ı okna, a jednak pˇri pˇrij´ımán´ı dat z komponenty, která okno pouˇz´ıvá.

(32)

Implementace Nastavovac´ı prvky

5.2 Nastavovac´ı prvky

5.2.1 Nastaven´ı celoˇ c´ıseln´ e promˇ enn´ e

public void c r e a t e I n t S e t ( ControlGUI r e f G u i , S t r i n g l a b e l, i n t messageType , i n t min , i n t max , i n t s t e p ) ;

Metoda, která v oknˇe vyrob´ı blok, ve kterém je moˇzné nastavit celoˇc´ısel- nou promˇennou. Nejd˚uleˇzitˇejˇs´ım prvkem bloku je Swing komponentaJSpin- ner. Spinner slouˇz´ı k pˇrijet´ı celoˇc´ıselné od uˇzivatele, pˇriˇcemˇz parametrymin a maxje omezen rozsah spinneru. Parametr stepurˇcuje krok spinneru. Sou- ˇ

casnˇe je vytvoˇreno tlaˇc´ıtko, kterým se zadaná hodnota odeˇsle ˇr´ızené kom- ponentˇe. Hodnota parametru messageType je druh (kód) zprávy, která je odeslána do simulace po stisknut´ı tlaˇc´ıtka

”OK“. Parametr label obsahuje název promˇenné, která je zaregistrována, a koneˇcnˇe parametrrefGui, který zajist´ı vykreslen´ı jednotlivých prvk˚u do správného okna.

public void c r e a t e I n t S e t ( ControlGUI r e f G u i , S t r i n g l a b e l, i n t messageType ) ;

Metoda je pˇret´ıˇzen´a, je moˇzn´e ji zavolat bez parametr˚umin, maxastep.

5.2.2 Nastaven´ı re´ aln´ e promˇ enn´ e

public void c r e a t e D o u b l e S e t ( ControlGUI r e f G u i , S t r i n g l a b e l, i n t messageType , double min , double max , double s t e p ) ;

Metoda, která v oknˇe vyrob´ı blok, ve kterém je moˇzné nastavit reálnou promˇennou. Význam jednotlivých parametr˚u je totoˇzný s metodou crea- teIntSet, pouze se zde pracuje s datovým typem double.

public void c r e a t e D o u b l e S e t ( ControlGUI r e f G u i , S t r i n g l a b e l, i n t messageType ) ;

Opˇet je moˇzn´e vyuˇz´ıt pˇret´ıˇzen´ı metod a volat metodu bez nastaven´ı spinneru.

(33)

Implementace Sledovac´ı prvky

5.2.3 Nastaven´ı textov´ e promˇ enn´ e

public void c r e a t e T e x t S e t ( ControlGUI r e f G u i , S t r i n g l a b e l , i n t messageType ) ;

Metoda umoˇzˇnuje nastavit a odeslat promˇennou typuString. Parametry jsou reference na správné okno, popisek zobrazený v oknˇe a kód promˇenné.

5.2.4 Nastaven´ı promˇ enn´ e typu pole

public void c r e a t e F i e l d S e t ( ControlGUI r e f G u i , S t r i n g l a b e l, i n t messageType ) ;

Tato metoda umoˇzˇnuje nastavit a odeslat v´ıce hodnot najednou. Po jej´ım zavolán´ı je v oknˇe vytvoˇrena tabulka se dvˇema sloupci, do které lze vkládat jak ˇc´ıselné, tak ˇretˇezcové hodnoty. Zároveˇn je v tomto bloku vyrobeno tla- ˇ

c´ıtko, jehoˇz stiskem je pˇridán do tabulky ˇrádek. Odeslaná data reprezentuje objekt tˇr´ıdy DefaultTableModel. Parametry metody jsou: odkaz na okno, kde se má blok vykreslit, popisek bloku a kód generované zprávy pˇri odeslán´ı dat z okna.

5.3 Sledovac´ı prvky

5.3.1 Sledov´ an´ı promˇ enn´ e

public void o b s e r v e V a r i a b l e ( ControlGUI r e f G u i , S t r i n g name , i n t c o d e ) ;

Metoda vytvoˇr´ı v oknˇe blok pro pˇrij´ımán´ı hodnot registrované promˇenné z ˇr´ı- zené komponenty. Sledovac´ı blok obsahuje dvˇe needitovatelná textová pole, která jsou reprezentována Swing komponentou JTextArea. V prvn´ım poli je zobrazována aktuálnˇe pˇrijatá hodnota z ˇr´ızené komponenty, ve druhém pak celá jej´ı historie. Dále jsou zde um´ıstˇena dvˇe tlaˇc´ıtka. Prvn´ı tlaˇc´ıtko

”GET“

slouˇz´ı uˇzivateli k aktivn´ımu zaˇzádán´ı komponenty o aktuáln´ı hodnotu sledo- vané promˇenné. Stiskem tlaˇc´ıtka je vygenerována zpráva typuˇzádost o zaslán´ı

(34)

Implementace Sledovac´ı prvky

hodnoty. Je vˇsak na uˇzivateli, zda ve svém kódu tuto zprávu sleduje a jestli na ni reaguje. Druhé tlaˇc´ıtko

”GRAPH“ zobraz´ı graf z historie pˇrijat´ych hodnot.

Parametr refGui je odkaz na okno, ve kterém se má sledovac´ı blok vykreslit. Popisek sledovac´ıho bloku zobrazený v GUI, je nastavený paramet- rem name. Celoˇc´ıselná hodnota code, je jedineˇcný kód promˇenné, kterou si uˇzivatel zaregistruje. Podle hodnoty tohoto parametru je zjiˇstˇeno, kterému sledovac´ımu elementu je pˇrijatá hodnota z ˇr´ızené komponenty urˇcena. Me- chanizmus, kterým se pos´ılaj´ı data mezi komponentami a okny, je popsán v kapitole 5.4.

5.3.2 Logovac´ı komponenta

public void c r e a t e L o g ( ControlGUI r e f G u i , S t r i n g [ ] l e v e l s , i n t c o d e ) ;

Metoda vytvoˇr´ı textovou oblast, která funguje jako pˇrij´ımaˇc zpráv o bˇehu simulace z ˇr´ızené komponenty. Zobrazen´ı dat je realizováno Swing komponentou JTable. Pˇri vytváˇren´ı této komponenty uˇzivatel definuje moˇzné úrovnˇe zpráv, které chce rozliˇsovat. Zpráva odes´ılaná z ˇr´ızené komponenty by mˇela obsahovat ˇcas odeslán´ı, úroveˇn zprávy a samotný text zprávy.

Logovac´ı komponenta d´ale obsahuje tlaˇc´ıtko

”Save“, kterým lze jeho obsah uloˇzit do souboru. Souˇcást´ı je také panel, který obsahuje zaˇskrtávac´ı pole, tzv. checkboxy. Uˇzivatel m˚uˇze tˇemito pˇrep´ınaˇci filtrovat obsah tabulky podle

´

urovnˇe zprávy. ParametrrefGuije odkaz na okno, do kterého se logovac´ı blok vykresl´ı, pole ˇretˇezc˚u levels obsahuje moˇzné úrovnˇe zpráv. Parametr code je opˇet kód, pod kterým si ˇr´ızená komponenta zaregistrovala tento sledovac´ı prvek.

(35)

Implementace Validace okna

5.4 Validace okna

public void done ( ControlGUI r e f G u i ) ;

Poté, co si uˇzivatel volán´ım výˇse uvedených metod nakonfiguruje poˇza- dované GUI, je nutné jako posledn´ı zavolat metodudone(ControlGUI). Vo- lán´ım této metody je okno zvalidováno a správnˇe vykresleno. Parametr je reference okna, které má být zobrazeno.

5.5 Komunikace

V pˇredchoz´ı kapitole bylo popsáno, jakým zp˚usobem je generováno grafické rozhran´ı. Nyn´ı bude vysvˇetleno, jak prob´ıhá vlastn´ı komunikace mezi komponentou a vygenerovaným oknem, tedy zas´ılán´ı nastavených dat do ˇr´ızené komponenty a pˇrij´ımán´ı sledovaných dat z druhé strany.

Existuj´ı dva základn´ı zp˚usoby komunikace mezi komponentami – volán´ı metod rozhran´ı, které komponenta poskytuje, a vyuˇzit´ı správce událost´ı, který dokáˇze pˇredat zprávy registrovaným komponentám. Volán´ım metod rozhran´ı API je vytvoˇreno okno grafického rozhran´ı. Odes´ılán´ı nastavovac´ıch hodnot do simulace a pˇr´ıjem sledovaných parametr˚u vˇsak prob´ıhá druhým zp˚usobem.

5.5.1 Zas´ıl´ an´ı zpr´ av

K tomu, aby komponenta mohla vyuˇz´ıvat mechanizmus pˇredáván´ı zpráv pro- stˇrednictv´ım správce událost´ı, je nutné m´ıt k dispozici sluˇzbu EventAdmin, která je souˇcást´ı bundlu org.eclipse.equinox.event. Událost je objekt tˇr´ıdy

(36)

Implementace Komunikace

Event, který sestává ze dvou atribut˚u:

• topic – topic je pˇredmˇet zas´ılané zprávy. D´ıky tomuto atributu je moˇzné sledovat pouze ten druh událost´ı, které chceme.

• properties – prostˇrednictv´ım tohoto atributu jsou pˇren´aˇsen´a data.

Data jsou uloˇzena v asociativn´ım poliHashMap. Prvek tvoˇr´ı dvojice kl´ıˇc – hodnota. Právˇe kl´ıˇc obsahuje kód promˇenné nebo prvku uˇzivatelského rozhran´ı, kterému je zpráva urˇcena.

V pˇr´ıpadˇe naˇs´ı knihovny existuj´ı tˇri pˇredmˇety zpr´av:

1. Setting_topic– zprávy tohoto typu pˇrenáˇsej´ı z vygenerovaného okna uˇzivatelem odeslané hodnoty do sledované komponenty. Kód nastavo- vané promˇenné a jej´ı hodnotu obsahuje atribut properties.

2. Value_request_topic – z vygenerovaného okna je odeslána kompo- nentˇe ˇzádost o zaslán´ı hodnoty sledované promˇenné. Kód ˇzádané pro- mˇenné a panelu je pˇrenáˇsen atributem properties.

3. Value_send_topic – simulovaná komponenta odes´ılá hodnotu sledo- vané promˇenné k zobrazen´ı.

5.5.2 Konfiguraˇ cn´ı soubor

Aby bylo moˇzné vyuˇz´ıvat API, je tˇreba zajistit aby komponenty obdrˇzely reference na pˇr´ısluˇsné sluˇzby. Aby mohla simulovaná komponenta vzdálenˇe vygenerovat nastavovac´ı GUI, je tˇreba do jej´ıho konfiguraˇcn´ıho souboru uvést následuj´ıc´ı ˇrádek:

<osgi:reference id=”Interface”interface=”service.ISettings” />

Reference na rozhran´ı je startovac´ı metodˇe komponenty pˇred´ano pomoc´ı Springu a jeho dependency injection. Komponenta pot´e m˚uˇze vyuˇz´ıvat sluˇzeb rozhran´ıISetttings.

(37)

Implementace Komunikace

Následuj´ıc´ı ˇcást konfiguraˇcn´ıho souboru ˇr´ıká, ˇze komponenta bude na- slouchat událostem s topicem

”Setting topic“. Objekt EventHandler, kter´y to umoˇzˇnuje, je opˇet pˇred´an s vyuˇzit´ım DI.

<osgi:service id=”Listen1” ref=”InstanceSimul”

interface=”org.osgi.service.event.EventHandler”>

<osgi:service−properties>

</osgi:service−properties>

</osgi:service>

Pˇr´ıklad cel´eho konfiguraˇcn´ıho souboru je uveden v pˇr´ıloze A.1.

(38)

Implementace Uk´azka pouˇzit´ı

5.6 Uk´ azka pouˇ zit´ı

Na následuj´ıc´ım výpisu je pˇr´ıklad pouˇzit´ı vytváˇrené knihovny. Tento úsek kódu vygeneruje GUI, které je zobrazeno na obrázku 5.1.

1 ControlGUI c o n t r o l 1 = r e f I n t e r f a c e . createWindow ( 1 ) ; 2

3 r e f I n t e r f a c e . c r e a t e T e x t S e t ( c o n t r o l 1 , ”Nazev ” , 1 ) ; 4 r e f I n t e r f a c e . c r e a t e D o u b l e S e t ( c o n t r o l 1 ,

5 ” D e s e t i n n e c i s l o ” , 2 , −5.00 , + 5 . 0 0 , 0 . 0 5 ) ; 6 r e f I n t e r f a c e . c r e a t e D o u b l e S e t ( c o n t r o l 1 , ”Vykon ” , 3 ) ; 7

8 r e f I n t e r f a c e . c r e a t e F i e l d S e t ( c o n t r o l 1 , ”Prevody ” , 4 ) ; 9 r e f I n t e r f a c e . c r e a t e I n t S e t ( c o n t r o l 1 , ”Otacky ” , 5 ) ; 10 r e f I n t e r f a c e . c r e a t e D o u b l e S e t ( c o n t r o l 1 , ” S p o t r e b a ” , 5 ) ; 11 r e f I n t e r f a c e . c r e a t e F i e l d S e t ( c o n t r o l 1 , ”P o l e hodnot ” , 6 ) ; 12

13 r e f I n t e r f a c e . c r e a t e L o g ( c o n t r o l 1 , urovneZprav , 7 ) ; 14

15 r e f I n t e r f a c e . o b s e r v e V a r i a b l e ( c o n t r o l 1 , ” V z d a l e n o s t ” , 8 ) ; 16 r e f I n t e r f a c e . o b s e r v e V a r i a b l e ( c o n t r o l 1 , ” R y c h l o s t ” , 9 ) ; 17

18 r e f I n t e r f a c e . done ( c o n t r o l 1 ) ;

V´ypis 5.1: Pˇr´ıklad vytv´aˇren´ı GUI

V rámci zpˇrehlednˇen´ı kódu je vhodné nadefinovat sadu konstant, které budou reprezentovat jednotlivé signály.

(39)

Implementace Uk´azka pouˇzit´ı

Obr´azek 5.1: Pˇr´ıklad vygenerovan´eho okna

(40)

6 Z´ avˇ er

V rámci této práce byla implementována knihovna, která na základˇe poˇza- davk˚u programátora vytvoˇr´ı grafické uˇzivatelské rozhran´ı, jehoˇz prostˇrednic- tv´ım je umoˇznˇeno nastavovat parametry jednotlivých komponent v simulaci a zároveˇn sledovat promˇenné a parametry jiných komponent a s tˇemito daty dále manipulovat.

V´ıtaným vylepˇsen´ım funkˇcnosti by byla moˇznost zobrazovat sledovaná data ”online“ pomoc´ı dynamického grafu.

(41)

Pˇ rehled zkratek

GUI – Graphical user interface

OSGi – Open Service Gateway initiative

CBSE – Component-based software engineering EJB – Enterprise JavaBeans

Java EE – Java Platform, Enterprise Edition COM – Component Object Model

CORBA – Common Object Request Broker Architecture OMG – Object Management Group

CBD – Component-based development JAR – Java archive

JVM – Java Virtual Machine

BSD – Berkeley Software Distribution XML – Extensible Markup Language Spring DM – Spring Dynamic Modules API – Application Programming Interface

(42)

Literatura

[1] SZYPERSKI, Clemens.Component software: beyond object-oriented programming. 1st ed. repr. Harlow, England: Addison-Wesley, 1998. ISBN 0-201-17888-5.

[2] KIV Wiki. Uvod do komponent´ [online]. Západoˇceská univerzita v Plzni, Fakulta aplikovaných vˇed, Katedra informatiky a výpoˇcetn´ı techniky.

2011 [cit. 3/2014]. Dostupn´e z WWW:

http://wiki.kiv.zcu.cz/UvodDoKomponent/HomePage

[3] BACHMANN, Felix et al. Volume II: Technical concepts of component- based software engineering [online]. Carnegie Mellon University, Software Engineering Institute. 2000 [cit. 3/2014]. Dostupn´e z WWW:

http://resources.sei.cmu.edu/asset_files/TechnicalReport/

2000_005_001_13715.pdf

[4] BARTLETT, Neil. OSGi In Practice [online]. Amazon.com, 2009. Do- stupn´e z WWW:

http://freecomputerbooks.com/OSGi-In-Practice.html

[5] WALLS, Craig. Modular Java: creating Flexible Applications with OSGi and Spring. 1st edition. USA: The Pragmatic Bookshelf, 2009. ISBN 1- 934356-40-9.

[6] D’SOUZA, Desmond. Objects, Components, and Frameworks with UML:

The Catalysis^TMApproach [online]. Addison-Wesley Professional. 1998 [cit. 3/2014]. Dostupn´e z WWW:

http://www.catalysis.org/publications/Benelux-new.pdf

(43)

LITERATURA LITERATURA

[7] FI WIKI. Enterprise JavaBeans [online]. Fakulta informatiky Masary- kovy univerzity. 2013 [cit. 4/2014]. Dostupn´e z WWW:

http://kore.fi.muni.cz/wiki/index.php/Enterprise_JavaBeans

[8] ORACLE. JAR File Specification [online]. Dostupn´e z WWW:

http://docs.oracle.com/javase/7/docs/technotes/guides/jar/

jar.html

[9] The OSGi Alliance. The OSGi Architecture [online]. Dostupn´e z WWW:

http://www.osgi.org/Technology/WhatIsOSGi

[10] The OSGi Alliance. OSGi Core Release 5 [online]. 2012 [cit. 4/2014].

Dostupn´e z WWW:

http://www.osgi.org/download/r5/osgi.core-5.0.0.pdf

[11] JOHNSON, Rod et al. Spring Framework Reference Documentation [online]. 2013 [cit. 5/2014]. Dostupn´e z WWW:

http://docs.spring.io/spring/docs/3.2.x/

spring-framework-reference/

[12] SpringSource. OSGi 4.2 Blueprint Container [online], [cit. 6/2014].

Dostupn´e z WWW:

http://docs.spring.io/osgi/docs/2.0.0.M1/reference/html/

blueprint.html

[13] KABÍˇCEK, Tomáˇs.Simulaˇcn´ı systém softwarových komponent zaloˇzený na komponentách. Diplomová práce. Západoˇceská univerzita v Plzni, Fa- kulta aplikovaných vˇed, Katedra informatiky a výpoˇcetn´ı techniky. Plzeˇn, 2011.

[14] PROKOP, Matˇej. Vizualizace simulace komponent. Diplomov´a pr´ace.

Západoˇceská univerzita v Plzni, Fakulta aplikovaných vˇed, Katedra informatiky a výpoˇcetn´ı techniky. Plzeˇn, 2011.

(44)

(45)

A Pˇ r´ılohy

A.1 Konfiguraˇ cn´ı soubory

<?xml version=”1.0” encoding=”UTF−8”?>

<beans xmlns=”http://www.springframework.org/schema/beans”

xmlns:xsi=”http://www.w3.org/2001/XMLSchema−instance”

xmlns:osgi=”http://www.springframework.org/schema/osgi”

xsi:schemaLocation=”http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring−beans−2.0.xsd http://www.springframework.org/schema/osgi

http://www.springframework.org/schema/osgi/spring−osgi−1.0.xsd”>

<osgi:service id=”Interface” ref=”Control”interface=”service.ISettings” />

<osgi:reference id=”Messanger”interface=”org.osgi.service.event.EventAdmin”/>

<constructor−arg ref=”Messanger”> </constructor−arg>

</bean>

<osgi:service id=”Listening to value” ref=”Control”

</osgi:service>

</beans>

V´ypis 1: Konfiguraˇcn´ı soubor ovl´adac´ı komponenty

(46)

<?xml version=”1.0” encoding=”UTF−8”?>

<beans xmlns=”http://www.springframework.org/schema/beans”

xmlns:xsi=”http://www.w3.org/2001/XMLSchema−instance”

xmlns:osgi=”http://www.springframework.org/schema/osgi”

xsi:schemaLocation=”http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring−beans−2.0.xsd http://www.springframework.org/schema/osgi

http://www.springframework.org/schema/osgi/spring−osgi−1.0.xsd”>

<osgi:reference id=”Interface”interface=”service.ISettings” />

<osgi:reference id=”Messanger”interface=”org.osgi.service.event.EventAdmin”/>

<bean id=”InstanceSimul” name=”SimulKomponenta”

class=”simulKomponenta.Sim” init−method=”start”>

</bean>

</osgi:service>

</osgi:service>

</beans>

V´ypis 2: Pˇr´ıklad konfiguraˇcn´ıho souboru sledovan´e komponenty

Bakaláˇrská práce GUI pro testován´ı komponentových aplikac´ı

Z´ apadoˇcesk´ a univerzita v Plzni Fakulta aplikovan´ ych vˇed

Katedra informatiky a v´ ypoˇcetn´ı techniky