• Nebyly nalezeny žádné výsledky

Bakal´aˇrsk´a pr´ace GUI pro testov´an´ı komponentov´ych aplikac´ı

N/A
N/A
Protected

Academic year: 2022

Podíl "Bakal´aˇrsk´a pr´ace GUI pro testov´an´ı komponentov´ych aplikac´ı"

Copied!
46
0
0

Načítání.... (zobrazit plný text nyní)

Fulltext

(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´aˇrskou pr´aci vypracoval samostatnˇe a v´yhradnˇe s po- uˇzit´ım citovan´ych pramen˚u.

V Plzni dne 26. ˇcervna 2014

Luk´aˇs Rost´as

(3)

Podˇ ekov´ an´ı

R´ad bych podˇekoval Ing. Richardu Lipkovi, PhD. za vstˇr´ıcnost, ochotu a cenn´e rady pˇri veden´ı t´eto pr´ace.

(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´aln´e promˇenn´e . . . 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´eto pr´ace je implementovat knihovnu, kter´a vytvoˇr´ı grafick´e uˇzivatel- sk´e rozhran´ı usnadˇnuj´ıc´ı ovl´ad´an´ı testov´an´ı simulovan´ych komponent. Toto GUI bude generovan´e dynamicky a bude obsahovat prvky na z´akladˇe po- ˇ

zadavk˚u program´atora komponent. Knihovna umoˇzn´ı nastavovat parametry jednotliv´ych komponent v simulaci a z´aroveˇn sledovat promˇenn´e a parametry komponent jin´ych a zobrazovat je v grafick´e ˇci textov´e podobˇe.

V prvn´ı, teoretick´e, ˇc´asti pr´ace je text zamˇeˇren na vysvˇetlen´ı z´akladn´ıch pojm˚u komponentov´eho programov´an´ı a sezn´amen´ı se s frameworky OSGi a Spring. D´ale bude pˇredstaven simul´ator komponent Simco, kter´y je vyv´ıjen na Katedˇre informatiky a v´ypoˇcetn´ı techniky Fakulty aplikovan´ych vˇed Z´a- padoˇcesk´e univerzity v Plzni. Realizaˇcn´ı ˇc´ast bude zamˇeˇrena na samotnou aplikaci vytvoˇrenou v r´amci t´eto bakal´aˇrsk´e pr´ace.

(8)

2 Komponentov´ e programov´ an´ı

Komponenty, komponentov´e programov´an´ı a komponentov´y software v po- sledn´ıch letech nab´yvaj´ı na d˚uleˇzitosti. Z´akladn´ı myˇslenka komponentovˇe ori- entovan´eho softwarov´eho inˇzen´yrstv´ı (CBSE)1 je vytv´aˇren´ı aplikac´ı propojo- v´an´ım jednotliv´ych na sobˇe nez´avisl´ych ˇc´ast´ı, tzv. komponent. Tento pˇr´ıstup umoˇzˇnuje urychlit v´yvoj 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´e komponenty existuje mnoho, pro ´uˇcely t´eto pr´ace jsem vybral tyto dvˇe: Podle Clemense Szypersk´eho [1] je softwarov´a komponenta jednotka kompozice skl´adaj´ıc´ı se ze smluvnˇe specifikovan´ych rozhran´ı a expli- citn´ıch kontextov´ych z´avislost´ı. Softwarov´a komponenta m˚uˇze b´yt nasazena nez´avisle a je pˇredmˇetem kompozice tˇret´ıch stran. Jin´a definice [6] ˇr´ık´a, ˇze komponenta je nez´avisle dod´avan´a jednotka, kter´a zapouzdˇruje sluˇzby za ve- ˇrejn´e rozhran´ı a kter´a m˚uˇze b´yt skl´ad´ana 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 develop- ment.

(9)

Komponentov´e programov´an´ı Komponenty

Z´akladn´ı vlastnost komponent je skryt´a implementace pˇred okol´ım. Je- din´ym zp˚usobem, jak m˚uˇze tˇret´ı strana vyuˇz´ıt komponentu, je pˇres jej´ı roz- hran´ı. Tento princip je zn´am jako

”black-box“ model. Komponenta nem´a pˇr´ıstup k implementaci ostatn´ıch komponent, ale pouze k jejich veˇrejn´emu rozhran´ı. T´ım je odstranˇena z´avislost na konkr´etn´ı implementaci a kompo- nenta je snadno nahraditeln´a.

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

Na obr´azku 2.1 jsou zn´azornˇeny vztahy mezi komponentami, komponen- tov´ym modelem a komponentov´ym frameworkem. Tyto pojmy budou vysvˇet- leny d´ale.

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

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

(10)

Komponentov´e programov´an´ı Komponenty

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

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

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

• nez´avisl´y v´yvoj a nasazen´ı,

• nez´avisl´a rozˇs´ıˇren´ı a snadn´a 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´y moˇzn´y pˇr´ıstup ke sluˇzb´am komponenty je skrze jej´ı rozhran´ı. Je tedy d˚uleˇzit´e, aby toto rozhran´ı pro interakci s ostatn´ımi komponentami bylo jasnˇe definovan´e a zdokumentovan´e. Stabiln´ı rozhran´ı zajist´ı logick´e oddˇelen´ı jednotliv´ych komponent a zamez´ı neˇz´adouc´ım pˇr´ıstu- p˚um k vnitˇrn´ı implementaci. V ide´aln´ım pˇr´ıpadˇe by rozhran´ı mˇelo b´yt defi- nov´ano na z´akladˇe toho, co komponenta poskytuje a vyˇzaduje od ostatn´ıch

(11)

Komponentov´e programov´an´ı Komponenty

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

Na obr´azku 2.2 je zn´azornˇeno komponentov´e rozhran´ı mezi dvˇema kompo- nentami, kde komponenta A poskytuje poˇzadovan´e 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´y model je definice standard˚u pro implementaci komponenty, jej´ı dokumentaci a nasazen´ı. Komponentov´y model zajiˇst’uje, aby nez´avisle vyv´ıjen´e komponenty mohly b´yt bez probl´em˚u nasazeny ve spoleˇcn´em bˇeho- v´em prostˇred´ı. Model tak´e urˇcuje, jak by mˇela b´yt definov´ana rozhran´ı a jak´e prvky by tato definice mˇela obsahovat. Vˇsechny komponenty mus´ı splˇnovat poˇzadavky komponentov´eho modelu.

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

• Komponentov´e typy – komponentov´y typ lze definovat na z´akladˇe roz- hran´ı, kter´e komponenta implementuje. Pokud implementuje tˇri r˚uzn´a rozhran´ı X, Y a Z, tak komponenta je typu X, Y a Z a m˚uˇze libovolnˇe zast´avat roli X, Y nebo Z. Komponentov´y model vyˇzaduje, aby kom- ponenta implementovala jedno nebo v´ıce rozhran´ı. Pak m˚uˇze model definovat jeden nebo v´ıce komponentov´ych typ˚u. R˚uzn´e komponentov´e typy pak mohou v syst´emu zast´avat odliˇsn´e role a mohou b´yt zapojeny v r˚uzn´ych sch´ematech interakce.

(12)

Komponentov´e programov´an´ı Komponenty

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

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

Interakˇcn´ı sch´emata mohou b´yt spoleˇcn´a pro vˇsechny komponentov´e typy, nebo jedineˇcn´a pro jednotliv´e z nich.

• Nav´az´an´ı zdroj˚u – proces skl´ad´an´ı komponent je z´aleˇzitost navazov´an´ı komponent na jeden nebo v´ıce zdroj˚u. Zdrojem je myˇslena bud’ sluˇzba poskytovan´a komponentov´ym frameworkem nebo jin´a komponenta na- sazen´a v dan´em frameworku. Komponentov´y model popisuje zdroje dostupn´e komponent´am a tak´e to, jak a kdy jsou komponenty nava- zov´any na tyto zdroje. Naopak, framework povaˇzuje komponenty za zdroje, kter´e je tˇreba ˇr´ıdit.

Komponentov´ych model˚u existuje cel´a ˇrada, n´asleduje v´yˇcet nˇekolika z nich.

Kapitola 2.2 je pak cel´a vˇenov´ana komponentov´emu model OSGi pouˇzit´emu pˇri v´yvoji aplikace vytv´aˇren´e v r´amci t´eto pr´ace.

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

• Enterprise JavaBeans (EJB)– komponentov´a architektura, slouˇz´ıc´ı pro realizaci aplikaˇcn´ı vrstvy informaˇcn´ıho syst´emu. EJB komponenty jsou objekty implementovan´e v´yvoj´aˇrem, kter´e zajiˇst’uj´ı vlastn´ı aplikaˇcn´ı logiku syst´emu. Jedn´a se o souˇc´ast platformy Java EE2 [7].

• Component Object Model (COM) – platformˇe nez´avisl´y, distribuovan´y, objektovˇe orientovan´y syst´em pro vytv´aˇren´ı bin´arn´ıch softwarov´ych komponent, kter´e jsou schopny spolupracovat. Byl uveden spoleˇcnost´ı Microsoft v roce 1993.

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

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

(13)

Komponentov´e programov´an´ı Komponenty

nou architekturu pro podporu tvorby distribuovan´ych objektovˇe orien- tovan´ych aplikac´ı. Model je nez´avisl´y na operaˇcn´ım syst´emu, progra- mov´em vybaven´ı nebo programovac´ım jazyku.

• OSGi Service Platform – je specifikace dynamick´eho modul´arn´ıho sys- t´emu pro programovac´ı jazyk Java.

2.1.4 Komponentov´ y framework

Komponentov´y framework je implementac´ı komponentov´eho modelu, respek- tive sluˇzeb, kter´e dan´y komponentov´y model vynucuje [3]. Komponentov´y framework ˇr´ıd´ı ˇzivotn´ı cyklus komponent a zprostˇredkov´av´a jejich vz´ajemn´e interakce. Jeden komponentov´y framework m˚uˇze implementovat v´ıce kompo- nentov´ych model˚u.

Komponentov´y framework lze pˇrirovnat k mal´emu operaˇcn´ımu syst´emu.

V t´eto analogii jsou komponenty pro framework to sam´e, co jsou procesy pro operaˇcn´ı syst´em. Komponentov´y framework ˇr´ıd´ı zdroje sd´ılen´e komponen- tami, poskytuje z´akladn´ı mechanizmy umoˇzˇnuj´ıc´ı komunikaci mezi kompo- nentami a ˇr´ıd´ı ˇzivotn´ı cyklus komponent [3].

2.1.5 Kompozice

Kompozice je term´ın popisuj´ıc´ı, jak jsou skl´ad´any syst´emy pˇri komponentovˇe orientovan´em v´yvoji.

Z obr´azku 2.1, na kter´em je zn´azornˇen princip komponentovˇe orientova- n´eho syst´emu, lze identifikovat dva subjekty, kter´e jsou souˇc´ast´ı 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´a umoˇzˇnuje interakce mezi komponentov´ym frameworkem a jeho komponentami. Tyto interakce dovoluj´ı frameworku ˇr´ıdit komponentov´e zdroje. Kontrakty specifikuj´ıc´ı tyto interakce jsou klasifikov´any jako kontrakty syst´emov´e ´urovnˇe.

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

2.2 Platforma OSGi

V n´asleduj´ıc´ı ˇc´asti je pops´ana technologie OSGi. Vˇetˇsina textu vych´az´ı 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 apli- kac´ı. V programovac´ım jazyce Java jsou vˇsak tyto moˇznosti znaˇcnˇe omezen´e.

Aplikace vytvoˇren´e v Javˇe jsou typicky distribuov´any v JAR3 archivech, coˇz je souborov´y form´at zaloˇzen´y na ZIP kompresi, kter´y 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´e dalˇs´ı zdroje pro ´uˇcely aplikace jako obr´azky nebo tex- tov´e dokumenty.

JAR soubory obvykle poskytuj´ı jednu knihovnu nebo pouze ˇc´ast funkci- onality aplikace. Jen zˇr´ıdka aplikaci tvoˇr´ı pouze jeden JAR archiv, rozs´ahl´e

3Souborov´y form´at JAR – akronym vytvoˇren´y z

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

(15)

Komponentov´e programov´an´ı Platforma OSGi

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

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

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

• Nedostatky naˇc´ıt´an´ı zdroj˚u z classpath, moˇznosti konflikt˚u v pˇr´ıpadech, kdy se v aplikaci vyskytuje v´ıce tˇr´ıd se stejn´ym jm´enem. Classloader vˇzdy naˇcte prvn´ı verzi tˇr´ıdy dan´eho jm´ena, na kterou naraz´ı.

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

• Slab´a podpora verzov´an´ı, nˇekolik r˚uzn´ych verz´ı nem˚uˇze b´yt spuˇstˇeno souˇcasnˇe.

Z v´yˇse uveden´ych d˚uvodu vznikla pro platformu Java specifikace OSGi, kter´a tyto probl´emy odstraˇnuje.

2.2.2 Architektura OSGi

Technologie OSGi je specifikace dynamick´eho modul´arn´ıho syst´emu pro plat- formu Java, kter´a implementuje dynamick´y komponentov´y model. Standard je definov´an a udrˇzov´an mezin´arodn´ım konsorciem OSGi Alliance zaloˇzen´ym v roce 1999. P˚uvodnˇe zkratka OSGi znamenala Open Services Gateway ini- tiative, dnes se vˇsak jiˇz nepouˇz´ıv´a a

”OSGi“ se stalo ochrannou zn´amkou.

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

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

JAR hell“.

(16)

Komponentov´e programov´an´ı Platforma OSGi

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

Na obr´azku 2.3 je zn´azornˇena architektura OSGi a jej´ı jednotliv´e 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)

Komponentov´e programov´an´ı Platforma OSGi

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´an JAR souborem, kter´y mus´ı ob- sahovat manifest s informacemi o bundlu. V manifestu se nach´azej´ı speci-

´

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

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

• Bundle-SymbolicName: Jedineˇcn´y identifik´ator bundlu. Je to jedin´a po- vinn´a 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 dis- pozici 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´eho manifestu se nach´az´ı ve v´ypisu 2.1.

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

(18)

Komponentov´e programov´an´ı Platforma OSGi

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´a o ˇzivotn´ı cyklus bundlu, kter´y je zobrazen na obr´azku 2.4.

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

(19)

Komponentov´e programov´an´ı Platforma OSGi

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 ´uspˇeˇsnˇe aktivov´an a bˇeˇz´ı, metodastart()pro- bˇehla ´uspˇeˇsnˇe.

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

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

2.2.5 OSGi framework

V souˇcasn´e dobˇe existuje nˇekolik na sobˇe nez´avisl´ych open source implemen- tac´ı standardu OSGi [4].

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

• Knopflerfish – dalˇs´ı popul´arn´ı implementace OSGi, kter´a implementuje jak OSGi 3, tak OSGi 4. Framework je vyv´ıjen spoleˇcnost´ı Makewave a je licencov´an 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 licen- cov´an pod Apache License Version 2.0.

(20)

Komponentov´e programov´an´ı Spring

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

2.2.6 Sluˇ zby

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

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

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

2.3 Spring

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

´

uˇcelem je usnadnit v´yvoj v oblasti Java EE aplikac´ı. Spring je modul´arn´ı framework organizovan´y do dvaceti modul˚u a umoˇzˇnuje pouˇz´ıt jen ty ˇc´asti, kter´e program´ator skuteˇcnˇe pouˇzije [11].

J´adro Springu je tvoˇreno Spring kontejnerem. Objekty, se kter´ymi pracuje kontejner, se naz´yvaj´ı tzv.beany(anglicky beans). V terminologii komponen- tov´eho programov´an´ı beany lze nazvat komponentami. Framework vyuˇz´ıv´a konceptu Inversion of control, viz d´ale.

(21)

Komponentov´e programov´an´ı Spring

2.3.1 Dependency Injection

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

zeno jako vkl´ad´an´ı z´avislost´ı. V´ysledkem 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´an konstruktor s pa- rametrem, kter´y je v elementu constructor-arg. Atribut ref5 je re- ference na vkl´adan´y objekt.

2. Setterem – vloˇzen´ı se prov´ad´ı setterem. Parametr je definov´an v ele- mentuproperty, pˇriˇcemˇz setter mus´ı b´yt pojmenov´an ve tvarusetName, kde Name je hodnota atributu stejn´eho jm´ena. Reference na vkl´adan´y objekt se nach´az´ı opˇet v atributuref.

Oba zp˚usoby jsou uk´az´any ve v´ypisu 2.2, jenˇz zobrazuje ˇc´ast konfigu- raˇcn´ıho XML souboru. Tento soubor obsahuje definice bean˚u a je nezbytnou souˇc´ast´ı kaˇzd´e 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)

Komponentov´e programov´an´ı Spring

2.3.2 Spring DM (Blueprint)

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

V souˇcasn´e dobˇe je technologie Spring DM souˇc´ast´ı OSGi6 pod n´azvem Blueprint. Blueprint vych´az´ı z modelu Spring DM, rozd´ıly mezi nimi jsou ne- velk´eho v´yznamu. Zmˇeny, kter´e se t´ykaj´ı pˇredevˇs´ım konfiguraˇcn´ıho souboru, jsou pops´any v [12].

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

Aby bylo v aplikaci budovan´e s pouˇzit´ım OSGi moˇzn´e vyuˇz´ıvat Spring, je nutn´e, aby bundle obsahoval Spring konfiguraˇcn´ıXMLsoubor. Tento soubor je tˇreba um´ıstit do adres´aˇreMETA-INF/spring7. 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´yt um´ıstˇen´ı libovoln´e [5].

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

I kdyˇz aktu´alnˇeji se jev´ı pouˇzit´ı kontejneru Blueprint, v realizaˇcn´ı ˇc´asti t´eto pr´ace je pouˇzit Spring DM, a proto i uk´azka konfiguraˇcn´ıho souboru ve v´ypisu 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)

Komponentov´e programov´an´ı Spring

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´azce 2.3 je na ˇr´adc´ıch 10 a 11 pomoc´ı elementu osgi:servicezare- gistrov´ana 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´eto sluˇzby je pˇred´ana pomoc´ı mecha- nizmu Dependency Injection konstruktorem.

(24)

3 Simul´ ator Simco

Simco je framework, kter´y vznikl na Katedˇre informatiky a v´ypoˇcetn´ı tech- niky Fakulty aplikovan´ych vˇed Z´apadoˇcesk´e univerzity v Plzni v r´amci di- plomov´ych prac´ı Tom´aˇse Kab´ıˇcka [13] a Matˇeje Prokopa [14] v roce 2011, kdy prvn´ı jmenovan´y vytvoˇril j´adro frameworku a druh´y pak jeho grafick´e rozhran´ı. N´azev Simco je odvozen z anglick´eho Simulation of Component.

Cel´y simul´ator je vytvoˇren ze softwarov´ych komponent, coˇz vypov´ıd´a o jeho modul´arnosti.

Uˇ´celem simul´atoru je poskytnout n´astroj k testov´an´ı re´aln´ych softwaro- v´ych komponent v simulaˇcn´ım prostˇred´ı bez nutnosti vytv´aˇret jejich modely, kter´e by mohly b´yt potenci´alnˇe chybn´e. Testov´an´ı prob´ıh´a za pouˇzit´ı prin- cipu diskr´etn´ı ud´alostn´ı simulace s pˇredem dan´ym sc´en´aˇrem. Aplikace, kter´a je na tento framework napojena se naz´yv´a 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´aˇr – ukl´ad´a a spravuje ud´alosti, obsahuje jejich seznam, zajiˇst’uje kontrolu nad bˇehem cel´e Simco aplikace. Obsahuje simulaˇcn´ı ˇcas, kter´y se inkrementuje po kaˇzd´em kroku simulace a urˇcuje, kter´a ud´alost m´a b´yt vykon´ana.

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

3.1 Komponenty

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

(25)

Simul´ator Simco Ud´alosti

• SIMULATION – simulaˇcn´ı komponenta. Neprov´ad´ı re´aln´y v´ypoˇcet, jej´ı bˇeh je pouze nasimulovan´y. Zastupuje re´aln´y syst´em a vrac´ı data, kter´a strukturou pˇripom´ınaj´ı data re´aln´a. Uˇzivatel m˚uˇze prostˇrednic- tv´ım konfiguraˇcn´ıch soubor˚u nastavit d´elku simulovan´eho v´ypoˇctu a hodnoty, kter´e komponenta vr´at´ı.

• REAL – re´aln´a komponenta, kter´a prov´ad´ı re´aln´y v´ypoˇcet a kter´a je testov´ana. Nemˇela by vˇedˇet o tom, ˇze je napojena na Simco framework, nedoch´az´ı tedy k ´uprav´am jej´ıho k´odu.

• INTERMEDIATE – komponenta typu prostˇredn´ık. Je potˇrebn´a k tomu, aby mohl framework sledovat komunikaci dvou re´aln´ych komponent.

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

3.2 Ud´ alosti

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

V simul´atoru mohou vzniknout n´asleduj´ıc´ı typy ud´alosti [13]:

• REAL_CALL – metoda re´aln´e komponenty komunikuje s nˇekterou z ji- n´ych komponent Simco aplikace.

• REAL_RETURN – n´avrat z volan´e metody re´aln´e 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´alosti mezi jed- notliv´ymi bundly. Historie pr˚ubˇehu simulace se ukl´ad´a do souboru. Samotn´e j´adro frameworku se skl´ad´a z ˇsesti komponent, jejich podrobn´y popis lze nal´ezt 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´en´aˇr pr˚ubˇehu simulace. Ve sc´en´aˇri lze nadefinovat ud´alosti typu CASUAL, REGULAR, seznam komponent Simco aplikace s jejich vlastnostmi a nastaven´ı Simco aplikace. Ve v´ypisu 3.1 je uveden pˇr´ıklad jednoduch´eho sc´en´aˇre.

Koˇrenov´y element XML souboru m´a n´azev simCoScenario. Seznam kom- ponent se nach´az´ı v elementucomponents. Kaˇzd´a komponenta m´a definovan´y sv˚uj typ, jedineˇcn´e jm´eno8 a cestu ke sv´emu konfiguraˇcn´ımu souboru bundlu.

V elementu events jsou definov´any ud´alosti. U kaˇzd´e ud´alosti je uve- den jej´ı typ (REGULAR nebo CASUAL), zdroj ud´alosti, rozhran´ı, pˇres kter´e je volan´a sluˇzba registrov´ana, jm´eno volan´e metody a parametry t´eto metody.

V elementu eventDetails je nadefinov´ano, jak ˇcasto se m´a dan´a ud´alost opakovat. Podle typu ud´alosti je nastavena bud’ perioda, a nebo n´ahodn´a 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´ypis 3.1: Sc´en´aˇr simulace

(28)

4 Anal´ yza

4.1 Poˇ zadavky na aplikaci

C´ılem t´eto pr´ace je vytvoˇrit komponentu, pomoc´ı kter´e bude moˇzn´e vytvoˇrit dynamicky generovan´e grafick´e uˇzivatelsk´e rozhran´ı. Toto GUI bude slouˇzit k usnadnˇen´ı ovl´ad´an´ı testov´an´ı komponent. Vyvinut´a komponenta bude m´ıt dvˇe z´akladn´ı funkce:

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

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

4.2 Pouˇ zit´ e prostˇ redky

Vytv´aˇren´a komponenta bude nasazena jako samostatn´y modul do simul´atoru Simco (viz kapitola 3). Simul´ator je sloˇzen ze Spring DM bundl˚u. Z toho vy- pl´yv´a, ˇze vytv´aˇren´a komponenta bude implementov´ana v programovac´ım ja- zyce Java. D´ale bude vyuˇzit framework OSGi a Spring, respektive technologie vyuˇz´ıvaj´ıc´ı v´yhod obou z nich – Spring DM.

K implementaci bude pouˇzito v´yvojov´e prostˇred´ı Eclipse Java EE 4.2, framework Spring DM 3.1, programovac´ı jazyk Java 1.7 a operaˇcn´ı syst´em 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´asti. V lev´e ˇc´asti (1) se nach´az´ı panel urˇcen´y k odes´ıl´an´ı dat do simulace. V prav´e ˇc´asti (2) jsou pak um´ıstˇeny sle- dovac´ı prvky. Obˇe ˇc´asti 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´e nastavovac´ı nebo sledovac´ı elementy (3) jsou pak uvnitˇr panel˚u (1) a (2) rozmist’ov´any pod sebe pomoc´ı layoutuGridBagLayout. Rozvrˇzen´ı okna je zn´azornˇeno na obr´azku 4.1.

Obr´azek 4.1: Rozvrˇzen´ı grafick´eho uˇzivatelsk´eho rozhran´ı

4.4 Dynamick´ e GUI

Z v´yˇse uveden´eho vypl´yv´a, ˇze GUI nebude m´ıt pokaˇzd´e stejnou podobu, ale bude obsahovat prvky, o kter´e si program´ator komponent zaˇz´ad´a. Defino- v´an´ı toho, co m´a GUI obsahovat, se prov´ad´ı prostˇrednictv´ım API, kter´e tato komponenta poskytuje.

(30)

Anal´yza Dynamick´e GUI

Vytv´aˇren´a komponenta umoˇzn´ı sledovan´e komponentˇe zaregistrovat si promˇenn´e, kter´e budou sledov´any. Tato data bude moˇzn´e zobrazovat jak v textov´e podobˇe, tak v grafick´e ve formˇe grafu. D´ale bude umoˇznˇeno pˇri- j´ımat zpr´avy informuj´ıc´ı o pr˚ubˇehu simulace, tˇr´ıdit je podle druh˚u, ukl´adat je do soubor˚u. Oproti tomu nastavovac´ı ˇc´ast API poskytne sluˇzby, kter´ymi budou data odes´ıl´ana 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´atorovi simulovan´e komponenty sadu metod, po- moc´ı kter´ych se vytvoˇr´ı okno nastavovac´ıho modulu a jeho jednotliv´e ele- menty. Zajiˇst’uje z´akladn´ı komunikaci mezi uˇzivatelsk´ym rozhran´ım a kom- ponentami. Prostˇredk˚u API je potˇreba jednak k vytvoˇren´ı ovl´adac´ıho a sle- dovac´ıho GUI, a jednak k nastavov´an´ı dat uvnitˇr ˇr´ızen´e komponenty, tedy k z´ısk´an´ı uˇzivatelem zadan´e hodnoty.

5.1.1 Vytvoˇ ren´ı okna

public ControlGUI createWindow(String windowName);

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

(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´a v oknˇe vyrob´ı blok, ve kter´em je moˇzn´e 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´e 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´ym se zadan´a hodnota odeˇsle ˇr´ızen´e kom- ponentˇe. Hodnota parametru messageType je druh (k´od) zpr´avy, kter´a je odesl´ana do simulace po stisknut´ı tlaˇc´ıtka

”OK“. Parametr label obsahuje n´azev promˇenn´e, kter´a je zaregistrov´ana, a koneˇcnˇe parametrrefGui, kter´y zajist´ı vykreslen´ı jednotliv´ych prvk˚u do spr´avn´eho 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´a v oknˇe vyrob´ı blok, ve kter´em je moˇzn´e nastavit re´alnou promˇennou. V´yznam jednotliv´ych parametr˚u je totoˇzn´y s metodou crea- teIntSet, pouze se zde pracuje s datov´ym 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´avn´e okno, popisek zobrazen´y v oknˇe a k´od promˇenn´e.

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´an´ı je v oknˇe vytvoˇrena tabulka se dvˇema sloupci, do kter´e lze vkl´adat jak ˇc´ıseln´e, tak ˇretˇezcov´e hodnoty. Z´aroveˇn je v tomto bloku vyrobeno tla- ˇ

c´ıtko, jehoˇz stiskem je pˇrid´an do tabulky ˇr´adek. Odeslan´a data reprezentuje objekt tˇr´ıdy DefaultTableModel. Parametry metody jsou: odkaz na okno, kde se m´a blok vykreslit, popisek bloku a k´od generovan´e zpr´avy pˇri odesl´an´ı 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´an´ı hodnot registrovan´e promˇenn´e z ˇr´ı- zen´e komponenty. Sledovac´ı blok obsahuje dvˇe needitovateln´a textov´a pole, kter´a jsou reprezentov´ana Swing komponentou JTextArea. V prvn´ım poli je zobrazov´ana aktu´alnˇe pˇrijat´a hodnota z ˇr´ızen´e komponenty, ve druh´em pak cel´a jej´ı historie. D´ale jsou zde um´ıstˇena dvˇe tlaˇc´ıtka. Prvn´ı tlaˇc´ıtko

”GET“

slouˇz´ı uˇzivateli k aktivn´ımu zaˇz´ad´an´ı komponenty o aktu´aln´ı hodnotu sledo- van´e promˇenn´e. Stiskem tlaˇc´ıtka je vygenerov´ana zpr´ava typuˇz´adost o zasl´an´ı

(34)

Implementace Sledovac´ı prvky

hodnoty. Je vˇsak na uˇzivateli, zda ve sv´em k´odu tuto zpr´avu sleduje a jestli na ni reaguje. Druh´e tlaˇc´ıtko

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

Parametr refGui je odkaz na okno, ve kter´em se m´a sledovac´ı blok vy- kreslit. Popisek sledovac´ıho bloku zobrazen´y v GUI, je nastaven´y paramet- rem name. Celoˇc´ıseln´a hodnota code, je jedineˇcn´y k´od promˇenn´e, kterou si uˇzivatel zaregistruje. Podle hodnoty tohoto parametru je zjiˇstˇeno, kter´emu sledovac´ımu elementu je pˇrijat´a hodnota z ˇr´ızen´e komponenty urˇcena. Me- chanizmus, kter´ym se pos´ılaj´ı data mezi komponentami a okny, je pops´an 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´a funguje jako pˇrij´ımaˇc zpr´av o bˇehu si- mulace z ˇr´ızen´e komponenty. Zobrazen´ı dat je realizov´ano Swing komponen- tou JTable. Pˇri vytv´aˇren´ı t´eto komponenty uˇzivatel definuje moˇzn´e ´urovnˇe zpr´av, kter´e chce rozliˇsovat. Zpr´ava odes´ılan´a z ˇr´ızen´e komponenty by mˇela obsahovat ˇcas odesl´an´ı, ´uroveˇn zpr´avy a samotn´y text zpr´avy.

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

”Save“, kter´ym lze jeho ob- sah uloˇzit do souboru. Souˇc´ast´ı je tak´e panel, kter´y obsahuje zaˇskrt´avac´ı pole, tzv. checkboxy. Uˇzivatel m˚uˇze tˇemito pˇrep´ınaˇci filtrovat obsah tabulky podle

´

urovnˇe zpr´avy. ParametrrefGuije odkaz na okno, do kter´eho se logovac´ı blok vykresl´ı, pole ˇretˇezc˚u levels obsahuje moˇzn´e ´urovnˇe zpr´av. Parametr code je opˇet k´od, pod kter´ym si ˇr´ızen´a komponenta zaregistrovala tento sledovac´ı prvek.

(35)

Implementace Validace okna

5.4 Validace okna

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

Pot´e, co si uˇzivatel vol´an´ım v´yˇse uveden´ych metod nakonfiguruje poˇza- dovan´e GUI, je nutn´e jako posledn´ı zavolat metodudone(ControlGUI). Vo- l´an´ım t´eto metody je okno zvalidov´ano a spr´avnˇe vykresleno. Parametr je reference okna, kter´e m´a b´yt zobrazeno.

5.5 Komunikace

V pˇredchoz´ı kapitole bylo pops´ano, jak´ym zp˚usobem je generov´ano grafick´e rozhran´ı. Nyn´ı bude vysvˇetleno, jak prob´ıh´a vlastn´ı komunikace mezi kom- ponentou a vygenerovan´ym oknem, tedy zas´ıl´an´ı nastaven´ych dat do ˇr´ızen´e komponenty a pˇrij´ım´an´ı sledovan´ych dat z druh´e strany.

Existuj´ı dva z´akladn´ı zp˚usoby komunikace mezi komponentami – vol´an´ı metod rozhran´ı, kter´e komponenta poskytuje, a vyuˇzit´ı spr´avce ud´alost´ı, kter´y dok´aˇze pˇredat zpr´avy registrovan´ym komponent´am. Vol´an´ım metod rozhran´ı API je vytvoˇreno okno grafick´eho rozhran´ı. Odes´ıl´an´ı nastavovac´ıch hodnot do simulace a pˇr´ıjem sledovan´ych parametr˚u vˇsak prob´ıh´a druh´ym zp˚usobem.

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

K tomu, aby komponenta mohla vyuˇz´ıvat mechanizmus pˇred´av´an´ı zpr´av pro- stˇrednictv´ım spr´avce ud´alost´ı, je nutn´e m´ıt k dispozici sluˇzbu EventAdmin, kter´a je souˇc´ast´ı bundlu org.eclipse.equinox.event. Ud´alost je objekt tˇr´ıdy

(36)

Implementace Komunikace

Event, kter´y sest´av´a ze dvou atribut˚u:

• topic – topic je pˇredmˇet zas´ılan´e zpr´avy. D´ıky tomuto atributu je moˇzn´e sledovat pouze ten druh ud´alost´ı, kter´e 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´avˇe kl´ıˇc obsahuje k´od promˇenn´e nebo prvku uˇzivatelsk´eho rozhran´ı, kter´emu je zpr´ava urˇcena.

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

1. Setting_topic– zpr´avy tohoto typu pˇren´aˇsej´ı z vygenerovan´eho okna uˇzivatelem odeslan´e hodnoty do sledovan´e komponenty. K´od nastavo- van´e promˇenn´e a jej´ı hodnotu obsahuje atribut properties.

2. Value_request_topic – z vygenerovan´eho okna je odesl´ana kompo- nentˇe ˇz´adost o zasl´an´ı hodnoty sledovan´e promˇenn´e. K´od ˇz´adan´e pro- mˇenn´e a panelu je pˇren´aˇsen atributem properties.

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

5.5.2 Konfiguraˇ cn´ı soubor

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

<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´asleduj´ıc´ı ˇc´ast konfiguraˇcn´ıho souboru ˇr´ık´a, ˇze komponenta bude na- slouchat ud´alostem 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>

<entry key=”event.topics” value=”Setting topic” />

</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´asleduj´ıc´ım v´ypisu je pˇr´ıklad pouˇzit´ı vytv´aˇren´e knihovny. Tento ´usek k´odu vygeneruje GUI, kter´e je zobrazeno na obr´azku 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´amci zpˇrehlednˇen´ı k´odu je vhodn´e nadefinovat sadu konstant, kter´e budou reprezentovat jednotliv´e sign´aly.

(39)

Implementace Uk´azka pouˇzit´ı

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

(40)

6 Z´ avˇ er

V r´amci t´eto pr´ace byla implementov´ana knihovna, kter´a na z´akladˇe poˇza- davk˚u program´atora vytvoˇr´ı grafick´e uˇzivatelsk´e rozhran´ı, jehoˇz prostˇrednic- tv´ım je umoˇznˇeno nastavovat parametry jednotliv´ych komponent v simulaci a z´aroveˇn sledovat promˇenn´e a parametry jin´ych komponent a s tˇemito daty d´ale manipulovat.

V´ıtan´ym vylepˇsen´ım funkˇcnosti by byla moˇznost zobrazovat sledovan´a data ”online“ pomoc´ı dynamick´eho 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 pro- gramming. 1st ed. repr. Harlow, England: Addison-Wesley, 1998. ISBN 0-201-17888-5.

[2] KIV Wiki. Uvod do komponent´ [online]. Z´apadoˇcesk´a univerzita v Plzni, Fakulta aplikovan´ych vˇed, Katedra informatiky a v´ypoˇ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 CatalysisTMApproach [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´IˇCEK, Tom´aˇs.Simulaˇcn´ı syst´em softwarov´ych komponent zaloˇzen´y na komponent´ach. Diplomov´a pr´ace. Z´apadoˇcesk´a univerzita v Plzni, Fa- kulta aplikovan´ych vˇed, Katedra informatiky a v´ypoˇcetn´ı techniky. Plzeˇn, 2011.

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

Z´apadoˇcesk´a univerzita v Plzni, Fakulta aplikovan´ych vˇed, Katedra in- formatiky a v´ypoˇ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”/>

<bean id=”Control” name=”ControlWindow”class=”tvorbaGUI.Control”>

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

</bean>

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

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

<osgi:service−properties>

<entry key=”event.topics” value=”Value send topic” />

</osgi:service−properties>

</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”>

<property name=”refInterface” ref=”Interface” />

<property name=”messanger” ref=”Messanger” />

</bean>

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

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

<osgi:service−properties>

<entry key=”event.topics” value=”Setting topic” />

</osgi:service−properties>

</osgi:service>

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

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

<osgi:service−properties>

<entry key=”event.topics” value=”Value request topic” />

</osgi:service−properties>

</osgi:service>

</beans>

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

Odkazy

Související dokumenty

Jednou z moˇ znost´ı zpracov´ an´ı ultrazvukov´ ych sn´ımk˚ u, nikoliv vˇ sak nejlepˇ s´ı, je pouˇ zit´ı prostˇ red´ı MATLAB, kter´ y je v akademick´ e sf´ eˇ re

C´ılem bakal´aˇrsk´e pr´ace je n´avrh elektroniky rozhran´ı modulu iNemo M1, kter´e umoˇzn´ı pˇrenos zmˇeˇren´ ych dat do poˇc´ıtaˇce pomoc´ı vhodn´e

Pro z´ aklad aplikace jsem pouˇ zil n´ astroj JHipster, kter´ y umoˇ zˇ nuje vyuˇ zit´ı mnou vybran´ ych technologi´ı.. JHipster je n´ astroj pro vygenerov´ an´ı

Jako hlavn´ı n´ aplˇ n pr´ ace byly vytvoˇ reny knihovn´ı funkce a testy v jazyce TCL, kter´ e slouˇ z´ı pro automatick´ e testov´ an´ı grafick´ eho rozhran´ı

Na z´akladˇe anal´yzy implementuje v druh´e ˇc´asti pr´ace ˇreˇsen´ı detekce a sledov´an´ı vozidel pomoc´ı modelu DETR, kter´y je absolutn´ı novinka mezi modely pro

Teˇ ziˇstˇ em bakal´ aˇrsk´ e pr´ ace je implementace origin´ aln´ı aplikace pro tvorbu animac´ı, jej´ıˇ z hlavn´ı konkurenˇ cn´ı v´ yhodou je podpora pro automatick´

Pˇredloˇ zen´ a bakal´ aˇrsk´ a pr´ ace se zab´ yv´ a odhadov´ an´ım geometrie dvou kamer z korespondenc´ı, za situac´ı kdy se vyskytuje v´ yznamn´ e mnoˇ zstv´ı

modelem ˇ s´ıˇ ren´ı z´ aˇ ren´ı v plazmatu zaloˇ zen´ em na principu raytracingu, kter´ y je v pr´ aci vyuˇ zit jednak pro modelov´ an´ı absorpce laserov´ eho svazku