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.
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>
V´ypis 2.2: Dependency Injection ve Springu
5Lze tak´e vloˇzit parametr pˇr´ımo pomoc´ı atributuvalue.
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.
Komponentov´e programov´an´ı Spring
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:service zare-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.
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]:
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.