11. fejezet - Esettanulmány

11.1. Bevezetés

Egy kliens-szerver alakalmazás helyességét, hatékonyságát több helyen lehet és kell is ellenőrizni. Minnél hamarabb derülnek ki a hibák gyengeségek, annál hamarabb lehet azokat javítani, és ebben az esetben pontosan tudjuk a helyet és azonnal javíthatjuk (ha csak a végén vesszük észre a hibát, akkor meg kell keresni, hogy mibőól ered). Ebben a fejezetben egy valós fejlesztés tesztelését mutatjuk be.

Az MTA SZTAKI Kognitív informatika laborja tűzte ki magának a feladatot, hogy egy virtuális együttműködési rendszert hozzon létre, melynek neve VIRCA (VIRtual Collaboration Arena). Az alkalmazás egy 3 dimenziós térben valós és virtuális objektumokat jelenít meg, és kezel. A rendszerben tetszőleges számú és típusú komponenseket lehet elhelyezni (virtuális vagy valóságos), amelyek mindegyike egy önálló alkalmazás. Az első verzió után újabb igények merültek fel. Az elkészült rendszer egy osztott alkalmazás lett, ami CORBA és ICE technológiákat használ. A rendszer egy közös adatstruktúrát használ az elérhető komponensek nyilvántartására, a CORBA naming service-t (név szolgáltatást), ami fa struktúrában tárolja a komponenseket. A 3 dimenziós megjelenítő ablak OGRE (nyílt forráskódú grafikai motor) rendszer segítségével implementálták c++-ban. A mi rendszerünk a hálózati kommunikáció lebonyolítására egy Openrtm-aist robot middleware-t használ. Írtunk ehhez pár kiterjesztést (ICE port, 1 fogyasztó több szolgáltató lehetőség), és a projekt kezdetekor a gyári rendszer szerkesztőt használtuk. A gyári szerkesztő egy Eclipse plugin, amely használatához egy több 10 megabájtos alkalmazás szükséges (Eclipse), és mi rendszerünk használatakor kényelmetlen egy külső szerkesztőt használni (váltogatva az aktív alkalmazást). Másik probléma, hogy a mi általunk készített kiterjesztés a hivatalos szerkesztő nem ismeri és nem is tudja használni. Olyan szerkesztőre volt szükség, amely képes futni az OGRE virtuális terében. A Chrome egy módosított verziója képes memóriában létrehozni a böngésző képét, ami ezután ráfeszíthető egy síkra. A kliens tehát egy böngészőben futó vékony klienst is kell tartalmazzon. A kliens oldalon egy tipikus grafikus szerkesztőt kell implementálnunk, ezért a javascript - mint lehetséges megoldás kizárható. Három elternatíva közül válaszhattunk:

  • FLEX

  • JAVA FX

  • Silverligth

Szerettük voltna, ha az alkalmazás platform független, ezért a Silverlight-ot az első körben kizártuk. Előztetes vizsgálataink alapján ez a módosított böngésző nem képes Java FX technológia használatára Ezért nem volt választásunk a FLEX kliens oldali technológiát alkalmaztuk.

A szerver oldalon szintén valamilyen platform független megoldást szerettünk volna alkalmazni, ezért a JAVA alapú megoldást választottuk. Mivel a szerkesztőhöz kellett írnunk egy karakteres verziót is, ezért egy külön rétegben implementáltuk az üzleti logikát.

11.1. ábra - A SZTAKI Openrtm kiterjesztésének felépítése

A SZTAKI Openrtm kiterjesztésének felépítése


A rendszer 4 rétegből áll, melyek a következők:

  • megjelenítési, és vezérlési,

  • logika réteg,

  • alacsonyszintű réteg.

  • programozói middleware réteg

A megjelenítés és a vezérlés réteg (zöld színű). Feladatuk a rendszer interfészének biztosítása:

  1. paraméterek fogadása, ellenőrzése,

  2. esetleges eredmények megjelenítése,

  3. Szolgáltatásokat kér a vezérlő rétegtől

Az OpenrtmExt_Logic, logikai réteg (sárga színű) a logika réteg, amelynek feladata a megjelenítési réteg által kért funkciók kiszolgálása az OpenrtmExt_Iceport és az OpenRtm alrendszerek segítségével. Ez a réteg egy csomag (jar fájl), amely a web-, vagy konzol alkalmazás mellet kell legyen.

Alacsonyszintű réteg tartalmazza az Openrtm-aist implementációját, ez külső rész, és az OpenrtmExt_Iceport részt. Ezek végzik az alacsony szintű műveleteteket. Ezek minden esetben a futó komponensben vannak beágyazva.

Az alsó rétegeket csak alkalmazzuk azoknak a tesztelése más feladata, nekünk csak az OpenrtmExt_logic, OpenrtmExt_server és Openrtm_Tools részekkel kell foglalkoznunk. A fejlesztés a klasszikus vízesés modell lépéseiből áll, a módszerek is azt javasolják, csak a legtöbb több iterációt ír elő, és így a rendszer finomodik.

[Tipp]Tipp

A teszt eseteket már a specifikáció írásakor meg kell határozni és le kell írni a forgatókönyveket. Az egység teszteket érdemes már az első osztályok megírásánál lefuttatni, és minden módosításnál újból és újból lefuttatni. Erre a feladatra érdemes valamilyen autómatizált megoldást keresni, amely lefut lehetőleg minden "fontos" alkalomkor.

Az alkalmazásnak valójában ez a szerver oldala, azonban a kliensek egy böngészőn keresztül küldik kéréseiket a szervernek. A kliens nem a hagyományos értelemben vett vékony kliens, hiszen egy grafikus szerkesztő, amelyben az elemek elhelyezése, átrendezése, összekötése a fő tevékenység. Az elemek elhelyezése és a műveletek valóságos információkat igényelnek, amit a szerver oldali logika nyújt. Amikor a felhasználó elkészítette a rendszerét, akkor ténylegesen elindítja összeköti az elemeket, azaz a szerver oldali logika a kérései alapján utasítja az alacsony szintű réteget (vezérli a komponenseket). A teljes toplogiát a következő ábra mutatja:

11.2. ábra - Grafikus szerkesztő rendszerünk főbb komponensei és kommunikácós csatornái

Grafikus szerkesztő rendszerünk főbb komponensei és kommunikácós csatornái


Ha hibásan működik a rendszer az számos helyen levő hiba eredménye lehet. Ezért folyamatosan kell tesztelnünk a logikában, a szerver oldalon, a kliens oldali kódban is. Minden kis változás egy létező hiba kijavítása újabb hibákhoz vezethet, amit ha csak később veszünk észre, akkor nem tudjuk, hogy melyik változás okozta.

[Tipp]Tipp

Minnél hamarabb vezessünk be egy (lehetőleg a projekt indulásakor) folyamatos integráció rendszert (continous integration system), ami a kód legkisebb változása esetén lefuttatja az össze tesztet. Ezek a rendszerek levelet küldenek, ha beállítottuk. Alkalmazásával lehetőség nyílik arra, hogy midenki azonos verziót használ, és a javítások által keletkezett hibák azonnal kiderülnek.