Book Template Title. Author Last Name, Author First Name

Book Template Title Author Last Name, Author First Name

Book Template Title Author Last Name, Author First Name

I. rész - Szoftver technológia

1. fejezet - Esettanulmány Bevezetés Az alkalmazás fejlesztésére nincs tökéletes megoldás, csak javaslatok és ajánlások vannak. A fejlesztés valójában a programozói, rendszerfejlesztési tapasztalatunk használata a szükséges ismeretek birtokában. Ebben a fejezetben egy valós fejlesztés menté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 tényleges), 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 tartja 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 middlewaret 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, és mi rendszerünk használatakor kényelmetlen egy külső szerkesztőt használni (váltogatva az aktív alkalmazást). A fejelsztés a kalsszikus vízesés modell lépéseiből áll, a módszerek is azt javasolják, csak a legtöbb több lépést írnak elő, és így a rendszer finomodik. Érdemes már az elején definiálni egy szótárt, amit a felmerülő újabb és újabb fogalmakkal bővítünk. Általános elv minden fázisnál, hogy először egy durva megközelítés után egyre részletesebb leírást, modellt készítünk. Követelmények felderítése Minden projekt egy ötlettel / fő igénnyel kezdődik. Ebben az esetben ez a következő volt: Kellene egy olyan rendszer szerkesztő a VIRCA rendszerünkhöz, amely a rendszerünk OGRE 3D virtuális terében is használható, támogatja az Openrtm-aist rendszert (hiszen a mi rendszerünk azon alapszik), támogatja továbbá az általunk korábban elkészített kiterjesztést. Nevezzük ezeket fő követelményeknek. Ezt már most érezni lehet, hogy ezek vizsgálata újabb követelményeket fognak felvetni. Ezeket sorra megvizsgáltuk, majd pontosítottuk, részleteztük. Nézzük ezeket sorban! OGRE 3D virtuális terében használható. Az OGRE C++-ban implementált SDK, amit használhatunk 3 dimenziós modellek létrehozására mozgatására. Egyik lehetőség az volna, hogy mi felépítünk egy 3 dimenziós menüt, és szerkesztő felületet. Az openrtm-t Japánban fejlesztették ki és ott sok helyen használják. Ha OGRE alatt írjuk meg, akkor a menürendszer változása miatt folyamatosan újabb és újabb verziót kell fordítanunk és letölteni a felhasználóknak. Ez nagy függőséget jelentett volna. Fejlesztés során törekedni kell az általános megoldásokra, a könnyen frissen tartható rendszer komponensekre. Szerencsére akkoriban adták ki a Crome böngésző memóriába dolgozó verzióját, amit rögtön implementáltak OGRE alá Berkelium néven. A böngészőben működő szerkesztő lényegesen leegyszerűsíti a fejlesztés menetét és az előbb említett problémákra is megoldást kínál. (A felhasználó minden használatkor a legfrissebb verziót használja.). Első fontos döntésünk tehát, hogy egy webalkalmazást (vagy legalábbis böngészőben működő) készítünk, így a 2

Esettanulmány felhasználók köre bővülhet, hiszen olyanok is használhatják, akik az alap openrtm rendszert használják. Mivel ez egy grafikus szerkesztő, ezért valamilyen kliens oldali technológiát kellett használnunk. Erre három lehetőség kínálkozik: Java FX Flash/Flex Silverlight A Microsoft által fejlesztett Silverligth technológiát azonnal elvetettük, mert nem létezik Linux és Mac OS rendszerek alá lejátszó plugin a böngészők alá. A Java FX és Flash támogatottság elég széleskörű, ezért azok teljesítményét, erőforrás igényét, programozhatóságát, használhatóságát vizsgáltuk meg. Sajnos a Berkelium alatt nem működött a Java FX lejátszó, így az akkori körülmények miatt maradt a flash. (Az összehasonlítás egyik fontos szempontja a minimális munka befektetése. Ezen okból a Java FX jobb lett volna, hiszen ha a szerver oldal jsp-ben íródik, akkor számos osztály közös lehetett volna.) Mivel a Flash rendszerben nem létezik CORBA és ICE könyvtár, így csak vékony kliensről beszélhetünk, azaz a kliens oldalon csak a komponensek és azok kapcsolata jelenik meg, a tényleges aktiválás összekötés a szerver oldali logika feladata. Támogatja az Openrtm-aist rendszert. Nyilván ha használni, csatlakozni, vezérelni szeretnénk egy rendszert, akkor ismernünk kell annak minden részletét. A rendszer felépítését és működését a Robot Technology Component (RTC) specifikáció rögzíti, amely letölthető az OMG weboldaláról. Tulajdonképpen minden olyan funkciót támogatnia kell, mint amit az alap rendszer szerkesztője támogat. Ezt viszonylag könnyű feltérképezni, hiszen a gyári szerkesztő letölthető és kiprobálható. Jellegében is hasonlítania kell az eredetihez, melyet a következő ábra mutat: 1.1. ábra - Az openrtm-aist rtcse rendszer szerkesztőjének képernyője Az ábra felső részén látható a fő ablak, amiben balra az elérhető komponensek, középen a szerksztő terület, balra pedig a tulajdonság ablak látható (tartalma a kiválasztott elem függvénye). Törekednünk kell arra, hogy a fontos funkciókat implementáljuk először (sőt ezen belül a meghatározókat és amelyik kevés ráfordítást igényel). A szerkesztő funkciói a következők: komponensek listázása (kapcsolódás a CORBA név szolgáltatóhoz), komponens adatainak a megjelenítése (portjainak elhelyezése a komponens körül), komponensek állapotának jelzése, komponensek vezérlése (aktivizálás, resetelés), portok összekötése (paraméterek megadása), Támogatja az általunk korábban elkészített kiterjesztést. Kifejlesztett kiterjesztésünknek egyik nagy momentuma az ICE technológia támogatása lett. Az alap rendszerben haasználható volt egy adatport (beépített típusok tuvábbítására és fogadására) szervízport CORBA alapú(funkcionalitás, metódus távoli hívására) A létező CORBA szervíz port használata (CORBA interfészek, osztályok készítése) nehézkes és nagy gyakorlatot igényel. Ezért fejlesztettük ki az ICE szervíz portot, amelyet sokkal egyszerűbb használni és megérteni. Másik nagy újdonság, hogy egy fogyasztó típusú szervíz porthoz (ICE) több szolgáltató port is kapcsolódhat, ami a VIRCA rendszerben szükséges is. Ezekket a kiterjesztésekket azonban a hivatalos szerkesztő nem érti, ezért kell beépíteni az új szerkesztőbe. 3

Esettanulmány Funkcionális követelmények felderítése Az fejelsztés következő lépése a funkciónális követelmények feltárása, erre remek módszer az UML használati eset diagramjának elkészítése. Az ábráról gyorsan és egyértelműen leolvashatóak a kapcsolatok, azonban szöveges leírás szükséges a modell elemek leírására. Egyes UML szerkesztők a diagrammok és a modell alapján képesek dokumentációt generálni, ami igen hasznos, sok munkát takarít meg. A következő ábárn láthatjuk a rendszer használati eseteit: 1.2. ábra - A szerkesztő használati esetei Ennek a létrehozása több lépésben szokott elkészülni, az nem baj, ha elsőre nem jut eszünkbe minden funkció ( a modszerek is csak ajánlások tesznek mikor legyen kész a teljes funkciólista bizonyos része). A diagram pont arra jó, hogy a megrendelő, vagy kollegánk a diagram alapján megérti elképzelésünket és ki tudja egészíteni a listánkat. A diagram egyszerűsége miatt amegrendelő is tudja használni azt. A dokumentációnak egységesnek kell lennie minden azonos típusú elemre. A használati esetekről tudnuk kell, hogy mennyire fontos, milyen előfeltételei, utóhatásai vannak. Érdemes a használati eseteket összefoglalni azaz definiálni a teljes listát, amit a következő ábra foglal össze: 1.1. táblázat - Használati eset diagram elemeinek összefoglaló táblázata Rövid név Megnevezés Dokumentáció A1 Kutató Személyek egy csoportja, akik grafikus felületen használják a rendszert. Nincs programozói ismeretük, azaz nem biztos, hogy ők fejlesztették ki a komponenst. HE1 Elérhető komponensek lekérdezése a CORBA nameservertől HE2 HE3 HE4 Komponens információk lekérdezése Komponens beillesztése a robot rendszerbe Port csatlakoztatása egy másik porthoz A szerkesztőnek fa struktúrában meg kell jelenítenie az elérhető komponenseket. Minden komponens regisztrálja magát egy corba name serveren. A frissítés autómatikus is és a felhasználó kérésére explicit is végre kell hajtani. A felhasználó lekérdezheti a komponensek különböző paramétereit: tulajdonságait (készítő, típus, implementációs nyelv) futási környezet paramétereit státuszát A felhasználó grafikus felületen keresztül beilleszt egy komponenst a szerkesztő területre. A beillesztett komponensek föbb paramétereinek már lent kell lennie, pl.: Név, készítő, portok nevei típusaj,... Komponensek közötti kapcsolatot a rendszerben azok portjaival lehet létrehozni. Az alap rendszer nem minden esetben teszi lehetővé a több-több kapcsolatot, sőt sok esetben a gyári szerkesztő grafikája is szétesik, de ez a szerkesztő támogatja azt. HE5 Komponens vezérlése Komponensek vezérlése a kliensből elengedhetetlen. Aktivizálás / deaktivizálás, vagy reszetelés. HE6 Adaport kapcsolat paramétereinek beállítása Adatportok esetén a kapcsoalt profil megadása döntően befolyásolja az adat mozgását, ezért elengedhetetlen ezen funkció implementálása. 4

Esettanulmány Rövid név Megnevezés HE7 Felhasználói rendszer mentése lokálisan HE8 Felhasználói rendszer betöltése lokális gépről HE9 Felhasználói rendszer mentése központi helyre HE10 Felhasználói rendszer betöltése központi helyről HE11 Adatport csatlakoztatása másikhoz HE12 Szervízport összekapcsolása HE13 Corba szervíz portok összekapcsolaása HE14 Ice szervíz portok összekapcsolása Dokumentáció A felhasználó munkáját lementheti lokálisan. Ilyenkor a homokzsákban futó flash alkalmazás kell, hogy hozzáférjen a mentett rendszerhez. Legyen lehetőség egy létező mentett rendszer felülírására. A felhasználó munkáját betöltheti lokálisan. Ilyenkor a homokzsákban futó flash alkalmazás kell, hogy hozzáférjen a mentett rendszerhez. Legyen lehetőség a betöltés után ellenőrizni a komponensek elérhetőségét. A felhasználó munkáját lementheti központi helyre. Ilyenkor a homokzsákban futó flash alkalmazás kell, hogy hozzáférjen a mentett rendszerhez. Legyen lehetőség egy létező mentett rendszer felülírására. A felhasználó munkáját betöltheti központi helyről. Ilyenkor a homokzsákban futó flash alkalmazás kell, hogy hozzáférjen a mentett rendszerhez. Legyen lehetőség a betöltés után ellenőrizni a komponensek elérhetőségét. Komponensek alapvető kommunikációjának eszköze az adatport. Itt előre definiált típusú információk mozognak. A kommunikáció egyirányú. Az openrtm-aist rendszerben a komponens egy fekete doboz. Ha valamely másik komponens szeretné használni szolgáltatásait, akkor azt csak előre definiált interfészeken keresztül teheti. Ennek egyetlen módja a szervíz portok definiálása. Ha egy komponens fogyasztani akarja másik komponens által nyújtott szolgáltatást, akkor össze kell kötni azok szervíz portjait. Az openrtm-aist rendszer tartalmaz CORBA szervíz portokat. Ennek támogatása elengedhetetlen. A SZTAKI által kifejlesztett új szervíz típus az ICE szervíz port. Ennek támogatása fontos feladat. Nézzünk meg példaként egy két használati eset részletes leírását: 1.2. táblázat - "Elérhető komponensek lekérdezése a CORBA nameservertől" használati eset részletei Megnevezés Szint Bonyolultság Prioritás Elofeltételek Utóhatások Érték Felhasználó Alacsony Magas Futó CORBA name server, futó alkalmazás szerver. Az elérhető komponensek eltárolódnak a modellben, a nézetben a felhasználó láthatja a komponenseket. 1.3. táblázat - "Port csatlakoztatása egy másik porthoz" használati eset részletei Megnevezés Szint Bonyolultság Érték Felhasználó Közepes 5

Esettanulmány Megnevezés Prioritás Elofeltételek Utóhatások Érték Magas 1. A komponens portjának már ismertnek kell lennie: tipus, név (azaz már előzőleg le kell kérdezni akomponenstől). 2. Azonos típusúak kell legyenek. A komponens adatokat fogadhat/küldhet vagy szolgáltatást használhat/ nyújthat. Ha több aktor van, akkor érdemes szerepeltetni azt is egy plusz oszlopban. Szerepelhet még az alternatív működés is. Nem funkcionális követelmények felderítése Ehhez a lépéshez az UML nem ad segítséget, a legtöbb módszer szöveges dokumentum létrehozását javasolja. A SysML azonban lehetőség ad követelmény diagram formájában. Ez a diagram tartalmazhatja a használati eseteket is, azonban vigyázzunk arra, hogy ha változtatjuk, akkor mind a két helyen változtassuk. Nagy előnye a diagramnak, hogy a követelmények közötti tartalmazás, pontosítás kapcsolatokat is ábrázolja, sőt a követelményeket ellenörző teszt eseteket! Itt is a fontos követelményekkel, követelemény kategóriákkal kezdünk, majd törekedünk a teljességre. A rendszer elemeinek, struktúrájának azonosítása Itt is a rendszer fő részeit határozzuk meg először, majd tovább bontjuk azokat. A létező rendszer kell először modellezni. Ezt a telepítés, üzemeltetés során figyelhetjük meg. Az együttműködő rendszerünket a következő ábra mutatja: 1.3. ábra - A szerkesztő használati esetei Először a világoskék részeket határozzuk meg, ezek az alap rendszer részei, aztán jön a kiterjesztés (türkiz kék), végül a zöld rész jön, ami mostani projektünk részleteit mutatja. A részek dokumentációja a következő: 1.4. táblázat - A rendszer strukturájának részletei Megnevezés Dokumentáció Grafikus szerkesztő Grafikus kliens Web alakalmazás Az új szerkesztő szoros együttműködésen alapszik. Az alapvető műveleteket a webalkalmazás végzi. A grafikus szerkesztő csak kéri azokat a webalkalmazástól. Egy webalkalmazáshoz általában több böngészőben futó flash alkalmazás fut. FLEX-ben írt grafikus kliens. Bíztosítja egy felhasználó barát használatát a rendszernek. Böngészőben fut (biztosítva a platform függetlenséget), csak egy flash lejátszó szükséges a használatához. JSP-ben implementált szerver logika. A flash klienstől (de akár más klienstől is, amely tud hhtp protokol felett kéréseket küldeni). Több szervleten keresztül érhetjük el a rendszer szolgáltatásait: menegzselhetjük a felhasználót, rendszert, komponensek információit lekérdezhetjük, vagy vezérelhetjük azokat, 6

Esettanulmány Megnevezés Dokumentáció portokat köthetünk össze, vagy kacsolhatunk szét MATE Openrtm http port Felhasználó Robot Rendszere Komponens Vezérlő A Mate egy tag-alapú, eseményvezérelt Flex keretrendszer (framework). Arra szolgál, hogy megkönnyítse a Flex alkalmazások eseménykezelését. Biztosítja, hogy a esemény térképeket definiáljunk, és az alrendszerek telejsen függetlenek legyenek egymástól. Gyári openrtm rész, alapszolgáltatásokat implementálja. A sztenderd 80 tcp port, ami a kommunkicióhoz kell. A kiterjesztett (iceport) felhasználói rendszer, amely a szerkesztő beavatkozása segítségével jön létre, indul el, de önnálóan működik. Több komponens (fekete doboz) lehet részese, amelyek közti kapcsolatot a portok szolgáltatják. A felhasználó futtatja valamelyik támogatott operációs rendszeren. A rendszer egy komponense. Különböző nyelven implementált (c++, java). A kompoensek vezérlését teszi lehetővé CORBA távoli objektum. Openrtm JAR Gyári openrtm rész, alapszolgáltatásokat implementálja. Openrtm-aist keretrendszer java implementációja. Két jar file. Ez biztosítja az alap rendszer használatát. Dataport CORBA szervíz port openrtm kiterjesztés ICE port Típusos adatport, több alaptípusa van. a kapcsolat profil döntöen meghatározza működését. CORBA szervíz port, amely lehet szolgáltató vagy fogyasztó Támogatja az egy szolgáltató egy fogyasztó, egy szolgáltató több fogyasztó kapcsolatokat. SZTAKI által korábban kifejlesztett iceport kiterjsztés. Segítségével bármely komponensnek lehet ice szervíz portja. szervíz CORBA szervíz port, amely lehet szolgáltató vagy fogyasztó Támogatja az egy szolgáltató egy fogyasztó, egy szolgáltató több fogyasztó, több szolgáltató egy fogyasztó kapcsolatokat. 7

szójegyzék Common Object Request Broker Architecture General Inter-ORB Protocol CORBA name server Osztott alkalmazásához használható programozói middleware. Támogatja a C++, java, stb. nyelveket. Régi specifikáció, amihez több ingyenes és üzleti implementáció is készült. Absztrakt Corba kommunikációk protokolja. IIOP az implementációja a GIOP-nak TCP/IP felett. Corba egy kompoense. Egy primitív név szolgáltatást nyújt. Lehetőség van logikai mappákat (Naming Context) és egyedeket definiálni (object). Minden egyedre tárolja annak nevét (ezt lehet listázni) és ip, portot, amit a resolve parancs old fel. Az Openrtm az OmniORB-t használja (C+-ban írták) a java részek pedig a JacORB-t. Interoperable Reference Object Egyedi azonosítója a corba objektumnak. Binárisan mozog a TCP/ IP felett, de szövegesen látjuk általában "IOR:" előtag után, hexa karaktereket tartalmaz. 8

Irodalomjegyzék. http://www.virca.hu/.. http://www.omg.org/spec/rtc/.. http://www.openrtm.org/.. http://www.omg.org/spec/ CORBA/.. http://zeroc.com/.. http://www.sysml.org/. 9

Tárgymutató 10