MIDP alkalmazás fejlesztése

Szabadon választott hálózati J2ME/MIDP alkalmazás fejlesztése Készítette: Novák György Témavezető: Bátfai Norbert

Debreceni Egyetem Informatikai Intézet

Debrecen 2004.

Tartalomjegyzék 1. Bevezető..............................................................................................................................................3 2. A használt technológiák.......................................................................................................................4 2.1. Vezeték nélküli hálózatok............................................................................................................4 2.2. J2ME...........................................................................................................................................5 2.3. Webszolgáltatások.......................................................................................................................9 2.4. Szervletek..................................................................................................................................10 2.5. Castor.........................................................................................................................................11 3. A rendszerrel szemben támasztott követelmények............................................................................14 3.1. Funkcionális követelmények.....................................................................................................14 3.2. Nem funkcionális követelmények.............................................................................................17 4. A rendszer implementációja..............................................................................................................19 4.1. Kliens oldal................................................................................................................................19 4.2. Szerver oldal..............................................................................................................................37 4.3. Mindkét oldalon használt objektumok.......................................................................................38 4.4. Kommunikáció..........................................................................................................................39 5. Tesztelés............................................................................................................................................45 6. Összefoglalás.....................................................................................................................................47 7. Mellékletek: A Conference rendszer leírása......................................................................................48 7.1. A rendszer rövid leírása.............................................................................................................48 7.2. A rendszerben előforduló személyek és használati esetek........................................................48 7.3. A rendszerben szereplő objektumok..........................................................................................51 Ábrajegyzék..........................................................................................................................................54 Irodalomjegyzék....................................................................................................................................55

1. Bevezető Aki járt már valamilyen konferencián, az tudja, hogy szokás különböző tájékoztató füzetekkel ellátni a vendégeket, melyekben benne van a konferencia előadásainak időpontja, valamint rövid leírása. Ezen füzetecske mérete a konferencia méretével arányosan nő, így egy komolyabb konferencián már kényelmetlen egy vaskos kis könyvecskéből keresgetni, hogy milyen előadás is lesz a kávészünet után (a helyzet még rosszabb, ha több szekcióban, párhuzamosan zajlanak az előadások). Gondoljuk el, hogy mennyivel egyszerűbb lenne, ha csak elővennénk a mobilunkat, vagy a PDA-nkat, és azon egy kis Java programot elindítva, az rögtön megmutatná, hogy milyen előadások zajlanak éppen, mik lesznek a következők, és minden olyan információt egykét gombnyomással elérnénk, amelyre az adott pillanatban szükségünk lehet! Mivel napjainkban már szinte minden embernek van mobil telefonja (van akinek több is), sőt esetenként PDA-ja is, és az újabb (1-2 éves) készülékek nagy része képes Java nyelven írt programok futtatására, ezért az előbb felvázolt lehetőség sok ember számára megkönnyítheti a konferenciák programjának káoszában való eligazodást. Miután már létezik egy web-es felületű rendszer (Conference, lásd 7. fejezet), mely konferenciák szervezését segíti, így most a célom egy mobil környezetben (mobil telefonokon, PDA-kon) futó alkalmazás elkészítése, mely képes a már meglévő rendszerhez kapcsolódni. Ha elkészül ez az alkalmazás, akkor a felhasználónak nem lesz más dolga, mint a web-es felületen regisztrálnia magát, letölteni a mobil készülékére a programot, és máris használhatja a rendszert, azaz áttekinthető formában mindig rendelkezésére áll az általa kiválasztott konferenciák programja.

3

2. A használt technológiák Ebben a fejezetben a fejlesztés során felhasználásra kerülő technológiákról adok egyegy rövid ismertetőt. Ezek a leírások semmiképpen nem tekinthetők a technológiákat minden részletre kiterjedően bemutató írásoknak, mindössze egy általános áttekintést próbálok nyújtani, kiemelve azokat a jellemzőket, melyek a készülő alkalmazás szempontjából fontosak. A tárgyalt technológiákhoz bőséges irodalom áll rendelkezésre (mind könyv, mind az Interneten fellelhető ismertetők

formájában),

amiből

az

általam

is

használt

írások

megtalálhatók

az

irodalomjegyzékben (lásd: 55. oldal).

2.1. Vezeték nélküli hálózatok Azt hiszem nyugodtan mondhatjuk, hogy napjaink informatikai világa szinte elképzelhetetlen hálózatok nélkül. A hálózatok előnye többek között az erőforrások megosztása, a megbízhatóság növelése, vagy például az egymással való kommunikáció lehetősége. Ha az asztali számítógépek világát nézzük, akkor a legelterjedtebb hálózat az Internet, mely mára szinte minden számítógépet használó emberhez eljutott. Mikor megjelentek a kézi számítógépek, PDA-k, valamint később a (Java) programokat is futtatni képes mobil telefonok, akkor arra is igény mutatkozott, hogy ezekről a felhasználó elérhessen más gépeket, például kezelni tudja az asztali gépén tárolt dokumentumait. A korábban már jól bevált vezetékes hálózat azonban ebben a környezetben nem alkalmazható, hiszen ezen készülékek legnagyobb erőssége a hordozhatóságuk, amit egy „falba dugott” kábel rögtön semmissé tesz. Így tehát nem maradt más, mint hogy vezeték nélküli hálózatokat készítsenek a mérnökök. A vezeték nélküli (más néven „WiFi”, vagy 802.11b) hálózatok kialakításához először is szükség van valamilyen adathordozó közegre, mely esetünkben vagy infravörös fény, vagy 2,4-2,4835 GHz-es tartományba eső rádióhullám. Mint tudjuk az infravörös megoldásnak a hátránya az, hogy a kommunikáló feleknek „látniuk” kell egymást, azaz az infravörös fénynek el kell jutnia (természetesen egyenes úton, akadályok nélkül) az egyik számítógépből a másikba. A rádióhullámoknál ilyen probléma nincs, mivel azok minden irányban terjednek. Másrészt szükségünk van valamilyen protokollra, mely szabályozza, hogy a hálózat mely tagja mikor küldhet adatot a hálózaton. Ez a protokoll az IEEE 802.11-es szabvány szerint a CSMA/CA, melynek részleteibe nem kívánok belemenni, csak annyit emelnék ki, hogy a hálózat tagja csak akkor küld adatot, ha éppen más nem folytat kommunikációt. Egy magasabb szinten, a hálózati rétegben, olyan problémákat kell megoldani, melyek a vezetékes hálózatok esetén nem merültek fel. Ilyen például az az eset, mikor valaki egy kézi számítógéppel kapcsolódott egy vezeték nélküli hálózathoz (mondjuk egy egyetem saját hálózatához), és sétál az illető a készülékkel a

4

kezében. Az ilyen kiépített vezeték nélküli hálózatok általában úgy vannak megoldva, hogy azon a területen, amit le kívánnak fedni, bizonyos távolságokban úgynevezett elérési pontokat építenek ki, melyekkel a felhasználók készülékei közvetlenül kommunikálnak. Ha a felhasználó sétál, akkor az egyik ilyen elérési pont hatóköréből átkerülhet egy másik hatókörébe, de neki ebből nem szabad észrevennie semmit. A vezeték nélküli hálózatok kialakításának egy másik lehetősége, mikor nincsenek kiépített elérési pontok, mindössze a készülékeket, melyeket közös hálózatba kívánunk kapcsolni, olyan közel helyezzük el egymáshoz, hogy képesek legyenek a többiek által kibocsátott rádióhullámokat megfelelően fogni. Ezen a módon például kialakítható egy ad hoc hálózat egy tárgyalás időtartamára úgy, hogy a tárgyaló felek a laptopjaikkal, PDAikkal leülnek egy asztalhoz, és máris működik a kommunikáció. Napjainkban rohamos léptekkel folyik a vezeték nélküli hálózatok kiépítése. Egyre többet hallhatunk repülőterekről, egyetemekről, bevásárlóközpontokról, ahol lehetőség van ilyen hálózatok elérésére. Mindez azonban semmit sem érne, ha nem lennének olyan eszközök, melyek képesek kihasználni ezt a lehetőséget. Szerencsére a legtöbb megjelenő PDA rendelkezik ezzel a képességgel, vagy kapható hozzá olyan kiegészítő, mely lehetővé teszi a vezeték nélküli hálózatok elérését. Itt jutottunk el addig a pontig, ahol világossá válik, hogy mi köze a vezeték nélküli hálózatoknak a MobilConference-hez. Ha belegondolunk, a konferenciákra ellátogató emberek nagy valószínűséggel rendelkeznek legalább egy mobil telefonnal, de akár PDA-val is. (A mobil telefonok is vezeték nélküli hálózatot használnak, de az különbözik az általam tárgyaltaktól, így ebben a fejezetben csak a PDA-kra figyelünk.) Tehát ha valaki elmegy egy konferenciára, ahol az épületben van kiépített vezeték nélküli hálózat, akkor a PDA-ját elővéve, elindítva a MobilConference-t, máris el tudja érni a központi Conference rendszert, és így hozzájut minden olyan információhoz, melyet a rendszerünk nyújtani hivatott.

2.2. J2ME A Java, mint technológia, 1995-ös megjelenése után dinamikus fejlődésnek indult, és egyre több alkalmazási területen jelent meg. Legfőbb területének a Web-böngészők és a beágyazott megoldások (gondolok itt a JavaCard technológiára) számítottak. Szintén jelentős területnek számított az úgynevezett „set-top box1”-ok piaca, valamint ugyanezen irányvonalon a „webphone”-okba szánt PersonalJava szoftver. A webphone-ok fejlődése '97-ben kezdett igazán beindulni, mikor is három vállalat (Alcatel Alsthom SA, Northern Telecom Ltd. és a Samsung Csoport) is bejelentette, hogy olyan Java alapú telefonokat (webphone-okat) fog készíteni, melyek képesek lesznek hálózatokhoz (így az Internethez is) kapcsolódni, és onnan tartalmakat 1 A set-top box egy olyan készülék, melyet a televízióra kötve lehetővé teszi, hogy böngésszünk az Interneten.

5

letölteni (bővebben lásd George Lawton cikkét [ME01]). 1998. januárjában Antero Taivalsaari és Bill Bush, a Sun két munkatársa, elkezdtek egy olyan Java virtuális gépet fejleszteni, mely a kis, hordozható eszközöket célozza meg, és ezért az addig kereskedelmi forgalomban lévő legkisebb virtuális gépnél is tízszer kevesebb helyet foglal el. Az első implementáció még az év májusában bemutatásra került a Sun belső konferenciáján. Ezek után a Motorola is érdeklődni kezdett a fejlesztés iránt, így felgyorsultak az események, a kísérleti projektből igazi termék lett. Az elkészült virtuális gép a KVM nevet kapta. A legkisebb változata 25-35 kB méretű, de az általánosan használt változata is mindössze 70-80 kB. Érdekességként talán érdemes megemlíteni, hogy a KVM-et C-ben implementálták, és az előbb említett általános változat forráskódja körülbelül 35000 sor (megjegyzésekkel együtt). (További érdekességek olvashatók a „KVM atyjának” is nevezett Antero Taivalsaarival készült interjúban [ME02].) A Java, mint technológia tehát a számítástechnika szinte minden területén megjelent. Az 1. ábrán látható, hogy milyen részekre osztható a technológia. A bal oldalon látható a J2EE, mely a szerverekre szánt változat, ez a legbővebb kiadás. A következő a J2SE, mely az asztali gépeken futó rendszerek megvalósítását teszi lehetővé. A következő két oszlop együtt alkotja a J2ME-t, azaz a Java 2 Platform, Micro Edition-t, mely a mobil, illetve beágyazott technológiákhoz ad eszközrendszert. A család legkisebb tagja a Java Card, mely a Java alapú intelligens kártyák programozási felülete. Most vizsgáljuk meg egy kicsit részletesebben a J2ME-t! Mint az ábrán is látszik, a Java-nak ez a része két irányban is tagolt. Ez a tagoltság azért alakult ki, mert a mobil, illetve a beágyazott eszközök (a hardverek) nagyon sokfélék lehetnek, és ebben a piaci szegmensben különösen fontos (a korlátozott erőforrások miatt), hogy a hardvernek leginkább megfelelő rendszer fusson rajta. Először is meg kell értenünk, hogy mik azok a konfigurációk (configuration), hiszen ezeken alapszik a J2ME vertikális tagolása. Egy konfiguráció egy virtuális gép és osztályok egy minimális halmazának az együttese, mely a hasonló jellemzőkkel (pl. hálózati kapcsolat, memória méret) rendelkező eszközökhöz nyújt alapvető funkcionalitást. Jelenleg két konfiguráció létezik: a CDC (Connected Device Configuration) és a CLDC (Connected Limited Device Configuration). A CDC a J2ME-hez tartozó hardverek gyorsabb processzorral, több memóriával, nagyobb hálózati sávszélességgel rendelkező részét célozza meg. Ilyenek például a már említett set-top box-ok, a járművek navigációs rendszerei, vagy a csúcskategóriás PDA-k. Mint az 1. ábrán is látható, ezeken a gépeken egy teljes értékű JVM fut, amelyet a 32 bites processzor és a legalább 2MB méretű memória tesz lehetővé. 6

Opcionális csomagok

Java 2 Platform, Enterprise Edition (J2EE)

Opcionális csomagok

Opcionális csomagok Personal Profiles

Java 2 Platform, Standard Edition (J2SE)

Personal Basis Profile

Opcionális csomagok

Foundation Profiles

MIDP

CDC

CLDC

Java Card

KVM

Card VM

JVM 1. ábra A Java2 platform

A CLDC az erőforrásokban szegényebb eszközökre szánt Java. Itt tipikusan 16 vagy 32 bites processzorok és 128-512KB memória a jellemző. A szűkös erőforrások miatt itt már nem a megszokott JVM-et találjuk, hanem a kisebb méretű KVM-et. A konfigurációk kiegészülnek ún. profilokkal, melyek az alkalmazások életciklusát és a felhasználói felületet definiálják, valamint elérést biztosítanak az eszközspecifikus tulajdonságokhoz. A profilok létezése jelenti a J2ME horizontális tagoltságát. A CDC legalapvetőbb profilja a Foundation Profile, mely a CDC felhasználói felület nélküli, mélyen beágyazott környezetekbe szánt, hálózati kapcsolatra képes implementációját nyújtja. A CDC következő szinten lévő profilja a Personal Profile, mely a teljes grafikus felhasználói interfésszel rendelkező, applet-ek futtatását is támogató eszközök (például csúcskategóriás PDA-k, kommunikátorok, vagy játék konzolok) profilja. Itt már megjelenik a J2SE-ből jól ismert grafikus könyvtár, az AWT. A Personal Profile része a Personal Basis Profile, mely az előzőnél kevesebb grafikus tudással rendelkezik. Ezen profil által megcélzott eszközök például a set-top box-ok, valamint a járművek navigációs rendszerei. Amint az ábrán is látható, mind a CDC, mind a CLDC „legfölső szintjén” szerepelhetnek opcionális csomagok, melyekkel a gyártók bővíthetik ki a készülékek tudását például olyan funkciókkal, mint a Bluetooth, a webalkalmazások, multimédia, stb. Ami a profilok felsorolásából kimaradt, az a CLDC egyetlen profilja, a MIDP (Mobile Information Device Profile). Ez a profil használható a mobiltelefonoknál, valamint a belépőszintű PDA-k esetén. A MIDP a futtató készülékek számára a következő megkötéseket teszi a hardverek terén: •

legalább 96x54 pixel méretű, legalább két színű kijelző,

•

a következő beviteli lehetőségek közül legalább az egyik: egykezes billentyűzet, 7

kétkezes billentyűzet, érintőképernyő, •

a CLDC által megkövetelt 128KB nem törlődő és 32KB törlődő memóriát kiegészíti 8KB nem törlődő memóriával az alkalmazások által létrehozott adatok tárolásához,

•

két irányú, vezeték nélküli, lehetőleg összeköttetés mentes, kis sávszélességű hálózati kapcsolat.

A hardver követelmények mellett a MIDP szoftveres követelményeket is megfogalmaz: •

minimális kernel, mely képes a hardvert kezelni és a virtuális gépet futtatni,

•

az alkalmazások által létrehozott adatok írásának és olvasásának biztosítása a(z előbb említett) nem törlődő memóriában,

•

a hálózati kapcsolathoz használt csatorna írása és olvasása,

•

a grafikus kijelző kezelése

•

a rendelkezésre álló felhasználói inputok kezelése. A CLDC a java.io, java.lang és java.util csomagok osztályait definiálta.

A MIDP az utóbbi két csomagot kibővíti néhány osztállyal és négy új csomagot is bevezet: •

javax.microedition.lcdui – a felhasználói interfészek létrehozását biztosítja,

•

javax.microedition.rms – a perzisztens adattárolást teszi lehetővé,

•

javax.microedition.midlet – a MIDlet (a mobil készüléken futó alkalmazás) és a futtató környezet kapcsolatáért felelős,

•

javax.microedition.io – a hálózati kapcsolatfelvétel lehetőségeit bővíti ki (HTTP kapcsolattal). Mint látható, a MIDP és a CLDC együtt egy olyan környezetet ad, mely a mobil

készülékek tulajdonságainak megfelelő alkalmazások fejlesztését teszi lehetővé, figyelembe véve ezen készülékek korlátozott erőforrásait. A fönt leírtak a MIDP 1.0 verziójára igazak. 2002-ben megjelent a MIDP 2.0 is mely hozott néhány érdekes újítást illetve fejlesztést: •

a

HTTPS

bekerült

a

szabványba,

aminek

köszönhetően

biztonságosabb

kommunikációt is meg lehet valósítani, •

multimédia támogatás: hangokat (pl. wav fájlokat) tudunk lejátszani,

•

továbbfejlesztett form-ok (új layout-ok, új elemek, stb.),

•

a Game API a játékok fejlesztését teszi hatékonyabbá új grafikai megoldásokkal,

•

RGB képek kezelése, 8

•

aláírt kódok.

Az itt felsoroltakon túl, még számos újítás található a MIDP 2.0-ban. Minderről bővebben a Jonathan Knudsen által írt cikkben olvashatunk [ME03]. A MIDP 2.0 újdonságai nagy mértékben megkönnyítik a programfejlesztő munkáját, de mivel még viszonylag új a szabvány, ezért eddig csak kevés olyan készülék jelent meg, mely támogatja, és ezek is a felső árkategóriába tartoznak. Az általam fejleszteni kívánt alkalmazás nem igényli a MIDP 2.0-ban megjelent újdonságok használatát, így a fejlesztésnél maradok a MIDP 1.0-nál. Természetesen a MIDP 2.0 lefelé kompatibilis, így az elkészült alkalmazást azok a készülékek is képesek lesznek futtatni, melyek már a 2.0-s szabványt támogatják. (Ez a kompatibilitás fordított irányban természetesen nem igaz.)

2.3. Webszolgáltatások A webszolgáltatásokat Gottdank Tibor [WS01] a következőképpen definiálja: „A webszolgáltatások elve az objektum-orientált szemlélet terméke. Minden webszolgáltatás egy külön objektum, amely felhasználható egy másik alkalmazás által vagy beolvasztható egy másik alkalmazásba. Ezzel lehetővé válik, hogy egy hálózatot (pl. az Internetet) roppant nagy, programkomponenseket tartalmazó könyvtárakba képezzük le, s így e könyvtárak a fejlesztők munkája által elérhetővé válhatnak. A webszolgáltatások operációs rendszertől és platformtól függetlenül létrehozhatók és alkalmazhatók.” A webszolgáltatások elődjének (vagy inkább korai megjelenésének) a Hewlett-Packard által 1999-ben megjelent e-Speak nevű e-szolgáltatások fejlesztését segítő termékében alkalmazott technológiát tekinthetjük. 2000-ben a Microsoft már webszolgáltatásokról beszél, és azokat a .Net és az internetes szoftverek elemi részének tekinti. A technológia számos szabványt felhasznált, és ugyanakkor vannak olyan technológiák is, melyek többé-kevésbé a webszolgáltatások fejlődésének köszönhetik szabvánnyá válásukat. Az első, és legfontosabb szabvány az XML2, mely egy olyan nyelv, ami lehetővé teszi tetszőleges információk könnyen értelmezhető módon való leírását. A webalkalmazások egyrészt a kommunikáló felek közti adatcserére használják az XML-t, másrészt ezzel írják le az egyes alkalmazások tulajdonságait is (lásd: UDDI, WSDL). Tehát, mint látjuk, a webszolgáltatások világában az adatok XML dokumentumokként jutnak el az egyik kommunikáló féltől a másikig. Itt tipikusan arra kell gondolni, hogy egy kliens egy kérést küld valamely webszolgáltatásnak (tulajdonképpen meghívja annak egy metódusát), és a szolgáltatás válaszol a kérésre. A MIDlet-ek világában ez a kommunikációs folyamat általánosnak mondható, hiszen a korlátozott erőforrásokkal rendelkező mobil 2 Extensible Markup Language

9

készülékek nem képesek bonyolult számításokat végezni, vagy nagy mennyiségű adatot tárolni, ezért léteznie kell egy szervernek, mely a szükséges adatokat előállítja (vagy tárolja) a MIDlet számára. A MIDlet vezeték nélküli hálózaton, HTTP protokoll fölött (a MIDP 1.0-ban) tud a szerverrel kommunikálni. Az ilyen alkalmazások fejlesztésekor az egyik legnagyobb problémát az jelenti, hogy a MIDP-ben nincs eszköz az objektumok szerializálására/deszerializálására, azaz nem tudunk objektumokat átküldeni a hálózati kapcsolaton. És ez az a pont, ahol a MIDP összekapcsolódik a webszolgáltatásokkal. Mivel ez utóbbiak XML, azaz szöveges formában küldik át az üzeneteiket, és általánosnak mondható, hogy a kommunikációhoz HTTP protokollt használnak, ezért megfelelnek a MIDlet-ek kommunikációs feltételeinek, azaz miért ne alkalmaznánk a webszolgáltatásokban használt (szabványos!) üzenetküldő protokollokat a MIDlet-ek és szervereik közti kommunikációhoz? Ahhoz, hogy ezt meg tudjuk tenni, találnunk kell egy olyan eszközt, mely MIDP-s környezetben implementálja valamely üzenetküldő protokollt. Azt nem szabad elfelejtenünk, hogy a webszolgáltatások fejlesztésénél nem az volt a legfontosabb követelmény, hogy egy 128KB memóriával rendelkező, kis számítási teljesítményű hardverről is könnyedén elérhessünk bármilyen szolgáltatást. Ennek ellenére léteznek MIDlet-ekben használható implementációk. (Folytatást lásd a Kommunikáció c. alfejezetben - 39. oldal.)

2.4. Szervletek A Java szervletek a (web)kiszolgálók bővítéseként használt Java osztályok, melyek betöltése dinamikusan történik. Tehát a szervlet a kiszolgáló funkcionalitását bővíti ki azáltal, hogy annak részeként működve valamilyen feladatot lát el (szolgáltatást nyújt). Leginkább a CGI szkriptekhez lehetne hasonlítani őket, de azoknál biztonságosabbak és hordozhatóbbak, mivel a kiszolgáló JVM-jén belül futnak. További előnyük a CGI-vel szemben, hogy a kiszolgálóval szoros kapcsolatot tartanak fenn, és így olyan dolgokat is megtehetnek, melyekre a CGI nem képes (pl. saját maguk adhatják meg a MIME típusok leképezését).

Szervletkonténer

kliens_1 szál

JVM

kliens_2

szál

szervlet_1

kliens_3

szál

szervlet_2

2. ábra Szervletek működése és helye a konténerben

A Servlet API a J2EE platform részét alkotja opcionális csomagként (lásd: 1. ábra), 10

tehát őrá is jellemző a Java hordozhatósága és platformfüggetlensége. A szervletek futtatását az úgynevezett

szervletkonténerek

végzik.

Ilyen konténer

lehet

egy

önmagában

álló

szervletkonténer, ami egy kiszolgáló, melybe be van építve a szervletek támogatása. Egy másik megoldás, mikor ún. beépülő konténereket használnak, melyek a meglévő kiszolgálókat egészítik ki a szervletek támogatásával – beépülő modulként. Az utolsó csoportba a beágyazható szervletkonténerek tartoznak, melyek alkalmazásokba ágyazható pehelysúlyú szervlet futtató platformok. A kiszolgálón minden szervletből (legfeljebb) egy példány létezik, ha több kérés érkezik ugyanahhoz a szervlethez, akkor azokat különböző szálakban szolgálja ki. Ennek következtében a szervletek meghívása nagyon hatékony, hiszen csak a memóriában lévő példány egy metódusát kell meghívnia a kiszolgálónak egy beérkező kérés esetén. A szervletek (mivel a J2EE részei) képesek használni az egyes Java API-k által nyújtott eszközöket, mint például az adatbázis-kapcsolatok kezelését végző JDBC-t, a távoli metódushívást (RMI), vagy az Enterprise JavaBean-eket, hogy csak néhányat említsünk. Ami számunkra a legfontosabb lesz jelen alkalmazásunk fejlesztésekor, az az adatbázis kezelés, valamint az XML-elemzés lehetősége (lásd az előző alfejezetben). Az olyan MIDP alkalmazásoknál, melyeknél szükség van valamilyen szerver oldali részre is, szervleteket szokás kiszolgálóként használni. A már tárgyalt előnyökön túl lényeges, hogy a szervletek megírásához is a Java nyelvet kell ismernie a fejlesztőnek (tehát a kliens és a szerver oldal is ugyanazon nyelven készül), valamint az is létfontosságú, hogy a szervletek egy speciális csoportja (a HTTP szervletek) a HTTP protokollt használják a kommunikációhoz, csakúgy, mint a MIDP 1.0. Az elkészítendő alkalmazásban a szervletek a webszolgáltatások kiszolgálójaként jelennek meg, azaz egy szervlet kezeli le a kliens-szerver kommunikáció szerver oldali feladatait. Most tehát nem fogok saját szervletet írni, csak olyan osztály(oka)t, melyet az előbb említett szervlet használ a klienstől érkező kérések kiszolgálásához. Ennek ellenére úgy gondolom, hogy érdemes a szervletek jellemzőit, működését ismernünk, mivel így a felhasznált webszolgáltatás-kiszolgáló alapvető tulajdonságaival is tisztában leszünk (és ha esetleg az nem úgy működik, ahogy mi szeretnénk, akkor van esélyünk rá, hogy kijavítsuk).

2.5. Castor A legtöbb alkalmazás (így az általam készítendő is) valamilyen adatbázist használ az adatok tárolásához. A Java a JDBC3 API által egy olyan eszközrendszert biztosít, mellyel SQL utasításokat tudunk kiadni egy (tetszőleges) SQL adatbázis-kezelőnek. Az adatok a Java 3 Java DataBase Connectivity

11

programokban objektumokként vannak reprezentálva, míg az adatbázisban táblákban tárolódnak, ezért az objektumok letárolásánál az SQL parancsok elkészítéséhez az objektumokból ki kell olvasni az adattagokat, és a megfelelő tábla megfelelő sorára le kell azokat képezni. Ugyanezt a technikát kell alkalmaznunk visszafelé, mikor az objektumokat ki szeretnénk olvasni az adatbázisból, azaz az objektum adattagjait be kell állítanunk az adatbázis megfelelő rekordjának megfelelő mezőjén lévő értékekre. Ezek a műveletek jó néhány plusz sort jelentenek a forráskódunkban, aminek következtében csökken a kód átláthatósága. Java objektum

Castor JDO

Adatbázis

3. ábra A Castor JDO helye az alkalmazásokban

Ezt a problémát igyekszik orvosolni az exolab.org4 által fejlesztett Castor JDO5, mely átveszi a programozótól az objektumok és az adatbázis-táblák közti konverzió feladatát. A dolgunk mindössze annyi, hogy elkészítsük az adatokat reprezentáló osztályainkat, az adatbázistáblákat, valamint egy leíró fájlt, melyben megmondjuk, hogy melyik osztály példányát mely táblára akarjuk leképezni, és hogyan (azaz mely adattagot mely oszlophoz kötjük). A leíró (vagy mapping) fájl tulajdonképpen egy XML dokumentum, így könnyen megérthető, hogy milyen leképezési szabályok is vannak benne megadva. A Castor képes kezelni az objektumok 1:1, 1:n és n:m típusú kapcsolatát, valamint azokat az eseteket is, mikor az egyik objektum valamelyik adattagja a másik objektum, vagy az egyik osztály a másiknak a kiterjesztése. Lehetőségünk van az SQL-ből ismert szekvenciák használatára az objektumok azonosítójaként, vagy akár összetett kulcsokat is alkalmazhatunk. A típusokra nem lehet panaszunk, hiszen a Castor dokumentációja az SQL minden típusához leírja, hogy milyen Java objektumot fog a rendszer hozzárendelni. Ha összetett típusokat is szeretnénk használni az osztályainkban, akkor a java.util csomag ArrayList, Hashtable, Map, Set, illetve Vector osztályai jöhetnek szóba, melyek az adatbázisban egy segédtáblában lesznek letárolva. Ha elkészítettük a megfelelő osztályokat, létrehoztuk az adatbázisban a táblákat, megírtuk a mapping fájlt és az adatbázis-elérést leíró (database.xml) fájlt, akkor a programunkban

a

org.exolab.castor.jdo.Database

interfész

metódusaival

(create(), update(), load(), stb.) egy-egy utasításban elintézhetjük az objektumok eltárolását, visszatöltését, stb. Természetesen a Castor-nak is vannak hibái, nehézségei, és léteznek más eszközök is,

4 http://www.exolab.org 5 Java Data Objects

12

melyek a Java objektumainak adatbázisba való leképezését segítik (pl.: Hibernate6), de talán a Castor az egyik legegyszerűbben használható és mégis számos funkcióval ellátott eszköz ezen a területen. A Castor használatáról egy nagyon hasznos és érthető leírást készített Jeff Lowery [CA01].

6 http://sourceforge.net/projects/hibernate/

13

3. A rendszerrel szemben támasztott követelmények Mivel a rendszer nem egy külső megrendelő kérésére készül, ezért nekem kellett eldöntenem, hogy milyen követelményeket támasztok vele szemben. Ez a döntés nagy mértékben befolyásolja a rendszer használhatóságát, ezért fontos jól átgondolni, milyen feltételeket is támasztok a rendszerrel szemben.

3.1. Funkcionális követelmények A rendszer használati eseteit öt nagy csoportba sorolhatjuk, úgy mint: bejelentkezés, az éppen folyó előadások kezelése, a jövőbeli előadások kezelése, olyan konferenciák kezelése, melyekre jelentkezett a felhasználó, valamint az összes meghirdetett konferencia kezelése. Nézzük ezeket a csoportokat bővebben! (A rendszer use case diagramja a 4. ábrán látható. A diagram csak egyetlen aktort – a felhasználót – tartalmaz. Fel kellene tüntetnünk egy másikat is, nevezetesen az adatbázist, mely a felhasználóhoz hasonlóan minden használati esethez kapcsolódik, az ábra áttekinthetősége érdekében azonban ezt az aktort lehagytam.) 1. Bejelentkezés. Ebben a csoportban egyetlen használati eset szerepel, maga a rendszerbe való bejelentkezés. A bejelentkezésre azért van szükség, mert az egyes felhasználók jelentkezhetnek konferenciákra, és a rendszer megjegyzi, hogy mely felhasználó mely konferenciákra jelentkezett. A felhasználó akkor tud a mobiljáról bejelentkezni, ha előtte a webes felületen (lásd 7. fejezet) regisztrálta magát, azaz felhasználónevet és jelszót választott. Ezt a két adatot kell a felhasználónak megadnia, mikor először indítja el a mobilján az alkalmazást. A későbbiekben az alkalmazás indulásakor szintén meg fog jelenni a bejelentkezési adatokat bekérő képernyő, de a rendszer azt automatikusan kitölti az első bejelentkezéskor használt felhasználónévvel és jelszóval. Előfordulhat (bár nem tipikus), hogy más is szeretné használni a felhasználó készülékét, ezért a rendszer bejelentkező képernyőjén az előbb említett adatok bármikor módosíthatók. Ha módosítás történt, akkor a rendszer a továbbiakban az új adatokkal fogja automatikusan kitölteni a mezőket.

14

Bejelentkezés

Mai, még el nem kezdődött előadások listájának megtekintése

Előadás részleteinek megtekintése

Éppen folyó előadások listájának megtekintése

Olyan konferenciák listája, melyekre jelentkezett a felhasználó Konferencia adatainak megtekintése

Felhasználó

Jelentkezés lemondása Konferencia előadásainak listájának megtekintése

A rendszerben szereplő összes konferencia listájának megtekintése

Konferencia adatainak megtekintése

Jelentkezés konferenciára

Konferencia előadásainak listájának megtekintése 4. ábra A rendszer használati esetei

2. Az éppen folyó előadások kezelése Az ide tartozó használati esetek azok, melyek akkor állhatnak fenn, ha például éppen bent ülünk egy konferencián, és szeretnénk róla megtudni a legfontosabb információkat. 15

A rendszernek a bejelentkezés utáni képernyőn az éppen folyó előadások listáját kell megjelenítenie. Elég, ha ez a lista mindössze az előadások címét tartalmazza. (Figyelembe kell vennünk azt, hogy a rendszert mobil készülékekre szánjuk, amelyek viszonylag kis képernyővel rendelkeznek. Lásd a J2ME leírását a 2.2. alfejezetben!) Ha a felhasználó többet szeretne megtudni egy előadásról akkor elő kell tudnia hívni egy képernyőt, melyen megtekintheti az előadás részleteit. Ezen a képernyőn már meg kell jelenítenünk az előzőekben kiválasztott előadás címét, előadóját, időpontját (mikor kezdődött), helyét (a terem, ahol tartják), valamint annak a konferenciának a nevét, melyhez tartozik. Innen továbblépve az előadáshoz tartozó konferencia adatait, konkrétan a nevét, időpontját, helyszínét, a kiírás időpontját, a hallgatóság maximális létszámát, és a konferenciára jelentkezett hallgatók létszámát kell megjelenítenünk. A felhasználó nyilván kíváncsi lehet ennek a konferenciának a további programjára is, ezért egy következő képernyőn elérhetővé kell tennünk a konferencia előadásainak listáját is. Ha a felhasználó úgy dönt, hogy a továbbiakban nem kíván részt venni a konferencián, akkor lemondhatja a jelentkezését, mégpedig a konferencia adatait megjelenítő képernyőn. (Ha a felhasználó lemondja a jelentkezését, akkor a konferencia előadásai a továbbiakban nem fognak megjelenni sem az éppen folyó, sem a még el nem kezdődött előadások listájában.) A képernyők közötti sorrendiséget pontosan definiálni kell, ezt lásd később, a kliens oldal leírásánál (4.1. alfejezet). 3. Jövőbeli előadások kezelése Ide olyan használati esetek tartoznak, melyek az aktuális időpont után (de még az aktuális napon) kezdődő előadásokhoz kapcsolódnak. A mai, még el nem kezdődött előadások listáján időrendben kell felsorolni az előadásokat, így a felhasználó látni fogja, hogy még milyen programokra számíthat az aktuális napon. Ezen a listán fel kell tüntetni az előadások mellett azok időpontját is, hogy a felhasználó könnyebben meg tudja tervezni az időbeosztását. Az éppen folyó előadások kezeléséhez hasonlóan, itt is biztosítani kell egy következő képernyőt, melyen egy kiválasztott előadás minden adata megjelenik. (Az ez után következő, korábban tágyalt képernyőket is elérhetővé kell tenni.) 4. Azoknak a konferenciáknak a kezelése, melyekre jelentkezett a felhasználó Az egyetlen használati eset, mely csak ebbe a csoportba sorolható be, az a fent meghatározott konferenciák neveinek a felsorolása. Itt egy konferenciát 16

kiválasztva az éppen folyó előadások kezelésénél tárgyalt Konferencia adatainak megtekintése nevű használati esethez jutunk. 5. Az összes meghirdetett konferencia kezelése Az utolsó csoportba azok a használati esetek tartoznak, melyek a rendszerben szereplő összes (aktuálisan folyó, vagy még ezután kezdődő) olyan konferencia kezeléséhez kötődnek, melyekre a felhasználó nem jelentkezett. Ide tartozik az az eset, mikor a felhasználó az összes meghirdetett konferencia címét szeretné egy listában látni. Egy konferenciát kiválasztva a felhasználó – a korábbi használati esetekhez hasonlóan – megtekintheti a konferencia adatait, majd továbblépve a konferenciához tartozó összes előadás címét, időpontját és előadóját tartalmazó listát. A konferencia adatait megjelenítő képernyőn kell lehetőséget biztosítanunk, hogy a felhasználó jelentkezhessen az adott konferenciára. Meg kell fogalmaznunk további funkcionális követelményeket is, melyek részben a használati esetekből következnek: 1. A konferenciára való jelentkezés és a jelentkezés lemondása előtt megerősítést kell kérni a felhasználótól, a művelet végrehajtása után pedig egy nyugtázó üzenetet kell megjelenítenünk. 2. Minden képernyőn lehetőséget kell biztosítani arra, hogy a felhasználó az előző képernyőhöz vissza tudjon térni. 3. Azt is lehetővé kell tennünk minden (fontosabbnak ítélt) képernyőn, hogy a felhasználó kilépjen a rendszerből.

3.2. Nem funkcionális követelmények 1. A rendszernek illeszkednie kell a Conference rendszerhez (az ott meghatározott adatbázist kell használnia (lásd 7. fejezet)). 2. A rendszernek kezelnie kell a magyar ékezetes karaktereket. 3. Az egyes képernyőket olyan címkékkel kell ellátni, melyek egyértelműen megmondják, hogy mit is lát a felhasználó. 4. Minden olyan képernyőhöz help képernyőt kell készíteni, mely a felhasználó adatainak módosítására szolgál (ilyenek: bejelentkezés, jelentkezés konferenciára, jelentkezés lemondása). A help képernyőn le kell írni, hogy a végrehajtható művelet milyen következményekkel jár. 5. A kliens oldalon megjelenő listákat (mai, még el nem kezdődött előadások listáját, valamint 17

az éppen folyó előadások listáját) percenként frissíteni kell. 6. Kliens oldalon a futtató hardver rendszeridejét használjuk (például annak megállapítására, hogy egy előadás elkezdődött-e már). 7. A rendszer (kliens oldal) memóriahasználata nem haladhatja meg a CLDC 1.0 szabványban meghatározott legnagyobb memória méretét (512 KB), és lehetőségekhez képest minél alacsonyabb szinten kell azt tartani. 8. A kliens oldal méretét minél kisebbre kell csökkenteni (a maximális méret 100KB). 9. A kliens oldal csak a MIDP 1.0 és a CLDC 1.0 által nyújtott eszközöket használhatja. Ha további eszközökre is szükség van (pl. a kommunikáció megvalósításához), akkor azokat mellékelni kell (bele kell csomagolni a MIDlet JAR fájljába). (Azaz nem számíthatunk arra, hogy bizonyos MIDP 1.0-n és CLDC 1.0-n kívüli eszközök „gyárilag” be vannak építve a futtató hardverbe.) 10. A kliens oldalon ügyelnünk kell arra, hogy minden lehetséges előforduló hibát lekezeljünk (amit le lehet kezelni), és az ne jusson el a felhasználóhoz (ne omoljon össze a rendszer). 11. Ha a szerver oldalon, vagy a hálózati kapcsolatban fordul elő hiba, akkor ezt (naplózás után) tovább kell küldenünk a kliens oldalra (ahol azt az előbb leírtaknak megfelelően kezeljük). 12. Mivel a rendszerben az egyedüli személyes adat a felhasználói név és a jelszó, ezért a biztonságra vonatkozó követelmény mindössze annyi, hogy a jelszót a hálózati kommunikációhoz valamilyen algoritmussal titkosítani kell. (Elegendő egy egyszerű, szimmetrikus kulcsú titkosító algoritmus.) 13. A kliens és szerver oldal kommunikációját HTTP protokollon keresztül kell megvalósítani. 14. A kommunikációs meneteknél időkorlátot kell alkalmazni. Ha a kommunikáció az adott időkorláton belül nem fejeződik be, akkor meg kell szakítani, és a felhasználót tájékoztatni kell a kapcsolat lassúságáról. A megszakítás után a felhasználó kezdeményezheti a kommunikáció újbóli végrehajtását. Az időkorlátot a tesztelési fázisban kell meghatározni. 15. A felhasználó meg tudja szakítani a kommunikációt. (Például a kommunikáció alatt egy „Kommunikáció folyamatban” képernyőt jelenítünk meg, melyen lehetőség van a megszakításra.) 16. Mivel a felhasználó számára az egyik legjelentősebb költséget a hálózati kommunikáció jelenti, ezért a forgalmazott adatok mennyiségét – a lehetőségekhez képest – minimalizálni kell (csak azt kérje le a kliens a szervertől, amire szüksége van).

18

4. A rendszer implementációja A rendszer felépítése a tipikus háromrétegű kliens-szerver architektúrát követi, mint az az 5. ábrán is látható (az adatkezelés rétegének a Castor-t tekinthetjük). A kliensünk egy MIDlet lesz, mely a megjelenítést végzi (tehát egy vékony kliensről van szó). A kliens a kommunikációhoz a webszolgáltatások kliens oldali részét fogja használni, mely a metódushívásokat xml dokumentummá alakítva juttatja el a szerverhez (HTTP kérésben), majd az onnan (HTTP) válaszként érkező xml dokumentumból elkészíti a megfelelő objektumot. A két oldal között a kapcsolat vezeték nélküli hálózaton zajlik, HTTP protokoll fölött. Szerver oldalon a webszolgáltatás kiszolgáló részét találjuk, ami tulajdonképpen egy szervlet. Ez a szervlet fogja az általam megírt osztály(ok)hoz továbbítani a klienstől érkező kéréseket, illetve az osztály által adott választ (objektumot) xml dokumentummá alakítva eljuttatja a klienshez. Az osztályok a kérésnek megfelelően végrehajtják a szükséges adatfeldolgozási lépéseket, illetve elvégzik a kapcsolódó adatbázis-műveleteket (a Castor segítségével). HTTP

Kliens (MIDlet)

objektum ↕ xml

(XML)

objektum ↕ xml

Szerver (Servlet)

Castor

Adatbázis

5. ábra A rendszer architektúrája

Mint látható, az alkalmazott technológiák lehetővé teszik, hogy mind a MIDlet-ben, mind a szerver oldalon megírt osztályokban kizárólag objektumokkal dolgozzon a rendszer. Ez egyrészt gyorsabb fejlesztést, átláthatóbb, érthetőbb kódot jelent, másrészt bármikor megváltoztatható például az adatbázis struktúrája, vagy a két oldal összekötésére használt üzenetátviteli protokoll anélkül, hogy az üzleti logikát megvalósító kódrészletet át kellene írnunk (adat-program függetlenség). Ezek után lássuk az rendszer egyes elemeinek részletes leírását!

4.1. Kliens oldal A kliensnek tehát két feladatot kell ellátnia: egyrészt a felhasználóval kell kapcsolatot tartania (megjelenítés), másrészt a szerverrel kell kommunikálnia (adatok küldése, fogadása). A kliens és a szerver közti kommunikációt majd a 4.4. alfejezetben tárgyalom teljes részletességében, így itt most csak a megjelenítésről lesz szó.

19

Bejelentkezés hibás adatok

else

Előadás adatainak megtekintése

Éppen folyó előadások listája

Konferenciák, melyekre jelentkezett a felhasználó

Mai, még el nem kezdődött előadások listája

Minden konferencia

Konferencia adatainak megtekintése

Előadás adatainak megtekintése

Konferencia adatainak megtekintése

Konferencia előadásainak listája

Jelentkezés az adott konferenciára

Jelentkezés lemondása 6. ábra Aktivitás diagram

Az 6. ábrán látható, hogy a felhasználó milyen műveleteket végezhet a rendszerben. Ezt a diagramot a használati esetekből kiindulva készítettem el (minden használati esetnek megfelel egy tevékenység). A nyilak azt mutatják, hogy hogyan következhetnek egymás után a műveletek. A rombuszok elágazást jelentenek a műveletek sorrendjében, ilyenkor vagy a felhasználó döntésétől, vagy valamely más feltételtől (pl. helyes-e a megadott felhasználónév és jelszó) függ a következő művelet. Látható, hogy a legtöbb műveletből vissza lehet lépni, ez a felhasználó könnyebb navigációját hivatott segíteni. Az olyan elágazásokat, ahol a rombuszból csak kifelé mutató nyíl van, a következőképpen kell értelmezni: •

éppen folyó előadások listájából három csúcsba juthatunk (lefelé), de mindhárom csúcsból csak lefelé mehetünk tovább, vagy visszaléphetünk az éppen folyó előadások listájához;

•

hasonlóképpen a bal oldalon lévő Konferencia adatainak megtekintése nevű csúcsból 20

továbbléphetünk a Jelentkezés lemondása, vagy a Konferencia előadásainak listája nevű csúcsba, de azokból visszalépni csak ugyanebbe a csúcsba lehet. A műveletek sorrendje meghatározza a felhasználó által látott képernyők sorrendjét, így végigjárva a diagramot elkészítjük a képernyők tervét, és leírjuk, hogy hogyan kell viselkednie a rendszernek az adott képernyőn. Ha megvannak a képernyők, tudni fogjuk, hogy milyen adatoknak kell rajtuk megjelenni, illetve milyen adatok keletkezhetnek az adott tevékenység során, így elő fog állni egy interfész, melyet majd a szerver oldalon implementálnunk kell. A képernyőket a következő formában fogom megadni:

Cím Menü/tartalom

Parancs_1 … Parancs_n

Tehát a képernyő tetején szerepel az oldal neve, amely tájékoztatja a felhasználót, hogy mit is lát tulajdonképpen. A megjelenítendő tartalom a képernyő közepére kerül, ez foglalja el a legnagyobb helyet (kihasználjuk, hogy ha nem fér el egy képernyőre a tartalom, akkor a rendszer görgethetővé teszi azt). A képernyő aljára kerülnek az aktuális tartalomhoz kapcsolódó parancsok. Mivel a parancsok elhelyezkedése (jobb oldal, bal oldal, stb.) mindig a futtató J2ME/MIDP implementációtól függ, így azt nem tudjuk előre meghatározni, mindössze annyit tehetünk, hogy a MIDP által előírt módon határozzuk meg a parancsok típusát, illetve prioritásukat (lásd a javax.microedition.lcdui.Command osztály leírását a MIDP API dokumentációjában [ME05]).

21

1.

[nincs] Program neve, verziója; Fejlesztő

Funkció: A program és a fejlesztő nevének megjelenítése. Tartalom: A program neve, verziója, a fejlesztő neve és a fejlesztés éve. Működés: A program elindítása után ez a képernyő jelenik meg. Bármely gomb megnyomására, illetve ennek hiányában öt másodperc elteltével továbblép a rendszer a bejelentkező (2.) képernyőre.

[nincs]

Parancsok: nincsenek

2.

Bejelentkezés Felhasználó név:

Funkció: A felhasználó bejelentkezési adatainak bekérése. Tartalom: Egy form, melyen a felhasználó begépelheti a felhasználói nevét, valamint jelszavát.

Jelszó:

Működés: Amennyiben a felhasználó nem először indítja el a programot (már legalább egyszer bejelentkezett), úgy az eltárolt adatokkal Kilépés Rendben Névjegy Segítség

kitölti a rendszer a form-ot és vár a felhasználó utasítására. (A mezők tartalma ilyenkor is megváltoztatható.) A jelszó mezőben csak csillagok jelennek meg. A Rendben parancsra a rendszer megnézi, hogy a megadott adatok szerepelnek-e az adatbázisban. Parancsok: Kilépés – a felhasználó kilép a rendszerből (ilyenkor egy megerősítést kérő (14.) képernyő jelenik meg). Rendben – a felhasználó bejelentkezik a rendszerbe. Ha hibás adatokat adott meg, akkor a 3. , egyébként a 4. képernyő jelenik meg. Névjegy – a névjegy (22.) képernyő megjelenítése. Segítség – help (13.) képernyő megjelenítése.

22

3.

Hiba

Funkció: Felhasználó tájékoztatása arról, hogy az általa megadott felhasználónév / jelszó páros érvénytelen.

Hibás felhasználó név/jelszó.

Tartalom:

Kérem, ismételje meg a beírást!

Működés:

A képen látható szöveg. Akkor jelenik meg, ha a megadott bejelentkezési adatok nem szerepelnek az adatbázisban. Parancsok:

Rendben

Rendben – visszalépés a bejelentkező (2.) képernyőre.

23

4.

Folyó előadások Előadás_1 Előadás_2 Előadás_3

Funkció: Az éppen folyó előadások megjelenítése. Tartalom: Egy lista, mely minden olyan előadás címét tartaknazza, mely az adott pillanatban tart, és a konferenciára - amihez az előadás tartozik, - jelentkezett

a felhasználó. Egyszerre legfeljebb 10

előadást jelenítünk meg, hogy kevesebb erőforrást használjunk (hálózati kommunikáció, memória). Mai előadások Konferenciák Minden konferencia Frissít Kilépés

Működés: Ha a felhasználó kiválasztja a lista egy elemét (ráviszi a „kurzort” és megnyomja a „fire” gombot a készüléken), akkor a kiválasztott előadás adatait megjelenítő (5.) képernyő jelenik meg. A képernyő tartalma percenként frissül. (A frissítés csak a memóriában lévő adatok alapján történik, hálózati kommunikáció nincs.) Parancsok: Mai előadások – a mai, még el nem kezdődött előadások listáját megjelenítő képernyőre váltás (8. képernyő) Konferenciák – azoknak a konferenciáknak a megjelenítése, melyekre a felhasználó jelentkezett (7. képernyő) Minden konferencia – a rendszerben szereplő összes (még le nem zárult) konferencia listájának megjelenítése (9. képernyő) Frissít – letölti a szerverről az aktuális (legfeljebb 10 darab előadást) Kilépés – kilépés a rendszerből (megerősítéskérő (14.) ablak jelenik meg)

24

5.

Előadás adatai Cím: <előadás_címe> Előadó: <előadó_neve> Helyszín: Kezdés: Konferencia:

Funkció: Egy előadás adatainak megjelenítése. Tartalom: Az előadás címe, helyszíne (terem), kezdetének időpontja, előadó neve, valamint a konferencia neve az ábrán látható elrendezésben egy form-on. Működés: -

Konferencia adatai Vissza Kilépés

Parancsok: Konferencia adatai – az előadás konferenciájának adatait megjelenítő (6.) képernyő Vissza - visszalépés a (láncban) megelőző (4. vagy 8.) képernyőre Kilépés - kilépés a rendszerből (megerősítéskérő (14.) ablak jelenik meg)

25

6.

Konferencia adatai Név: Időpont: Helyszín: Kiírás időpontja: Hallgatóság max. létszáma: Jelentkezett hallgatók száma: <jelentkezett_hallg_száma>

[változó_parancs] Konferencia előadásai Vissza Kilépés

Funkció: Egy konferencia adatainak megjelenítése. Tartalom: A konferencia adatai egy form-on, a képen látható módon. Működés: Parancsok: [változó parancs] – ha az 5. vagy a 7. képernyőről jutottunk ide, akkor: Lemondása – a felhasználó lemondja az aktuális konferenciára tett jelentkezését. Ha a konferencia programja véglegesítve lett, akkor hiba (20.) képernyő, egyébként megerősítéskérő képernyő (6.) jelenik meg. Ha viszont a 9. képernyőről jutottunk ide, akkor: Jelentkezés – a felhasználó jelentkezik a konferenciára. Ha a konferencia hallgatói létszáma betelt, akkor a 21., hibajelző képernyő, egyébként megerősítéskérő képernyő (11.) jelenik meg. Konferencia előadásai – az adott konferencia előadásait felsoroló lista (12. képernyő) megjelenítése Vissza - visszalépés a (láncban) megelőző (5., 7. vagy 9.) képernyőre Kilépés - kilépés a rendszerből (megerősítéskérő (14.) ablak jelenik meg)

26

7.

Konferenciák Konferencia_1 Konferencia_2 Konferencia_3

Funkció: Azon konferenciák címének

megjelenítése,

melyre

a

felhasználó jelentkezett. Tartalom: A konferenciák címeit tartalmazó lista. Működés: Ha a felhasználó valamelyik konferenciát kiválasztja (ld. följebb), akkor a rendszer a 6. képernyőn megjeleníti a kiválasztott konferencia adatait.

Vissza Kilépés

Parancsok: Vissza – visszalépés a 4. képernyőre Kilépés – kilépés a rendszerből (megerősítéskérő (14.) ablak jelenik meg)

8.

Mai előadások Előadás_1 () Előadás_2 () Előadás_3 ()

Funkció: Azoknak az előadásoknak a felsorolása, melyek az adott napon zajlanak, még nem kezdődtek el, és a felhasználó jelentkezett a hozzájuk tartozó konferenciára. Tartalom: Előadások címét és kezdési időpontját tartalmazó lista. Egyszerre legfeljebb 10 előadást jelenítünk meg, hogy kevesebb erőforrást használjunk (hálózati kommunikáció, memória).

Vissza Kilépés Frissít

Működés: Ha a felhasználó kiválaszt egy előadást, akkor a rendszer az 5. képernyőn megjeleníti annak részleteit. A képernyő tartalma percenként frissül. (A frissítés csak a memóriában lévő előadások alapján történik, ilyenkor nincs hálózati kommunikáció.) Parancsok: Vissza – visszalépés a 8. képernyőre Kilépés – kilépés a rendszerből (megerősítéskérő (14.) ablak jelenik meg) Frissít – a még el nem kezdődött előadások legfrissebb listájának letöltése a szerverről (legfeljebb 10 darab előadást töltünk le)

27

9.

Minden konferencia Konferencia_1 Konferencia_2 Konferencia_3

Funkció: A rendszerben szereplő minden olyan konferenciának a felsorolása, melyre a felhasználó nem jelentkezett. Tartalom: Konferenciák címeit felsoroló lista. Működés: Ha a felhasználó kiválaszt egy konferenciát, akkor a rendszer a 6. képernyőn megjeleníti annak adatait. (A képernyő tartalmát nem frissítjük automatikusan, mivel

Vissza Kilépés

viszonylag kicsi a valószínűsége, hogy a rendszerbe új konferencia kerül, viszont a frissítés hálózati forgalmat generál. Ha a felhasználó frissíteni akarja a listát, akkor visszalép a 4. képernyőre, majd ismét ide.) Parancsok: Vissza – visszalépés a 8. képernyőre Kilépés – kilépés a rendszerből (megerősítéskérő (14.) ablak jelenik meg)

10.

Megerősítés Biztosan le kívánja mondani a(z) nevű konferenciára való jelentkezését?

Funkció: Megerősítés

kérés

a

konferenciára

való

jelentkezés

lemondásához. Tartalom: Az ábrán látható szöveg. Működés: Parancsok:

Igen Mégsem Segítség

Igen – a felhasználónak az adott konferenciára vonatkozó jelentkezését törli a rendszer. (A következményeket lásd a Jelentkezés lemondása nevű használati eset leírásánál a 16. oldalon.) A törlés végrehajtása után a rendszer visszaugrik a 4. vagy 7. képernyőre attól függően, hogy a felhasználó milyen úton jutott a törlés képernyőig. Mégsem - a rendszer visszalép a 6. képernyőre (a jelentkezés nem kerül törlésre) Segítség – a jelentkezés törlésének következményeit megjelenítő (13.) képernyőre lépés

28

11.

Megerősítés Biztosan jelentkezni kíván a(z) nevű konferenciára?

Funkció: Megerősítés kérés a konferenciára való jelentkezéshez. Tartalom: Az ábrán látható szöveg. Működés: Parancsok:

Igen Mégsem Segítség

Igen - a rendszer regisztrálja a jelentkezést (a konferencia kikerül a 9. képernyő listájából, és átkerül a 7. képernyőre, illetve a konferencia előadásai megjelennek a 4. illetve 8. képernyőn). A regisztrálás végrehajtása után a rendszer a 18. képernyőn nyugtázza a jelentkezést. Mégsem - a rendszer visszalép a 6. képernyőre (a jelentkezés nem lesz regisztrálva) Segítség – a jelentkezés következményeit megjelenítő (13.) képernyőre lépés

12. Konferencia előadásai Konferencia_név Előadó_1: cím_1 (időpont_1) Előadó_2: cím_2 (időpont_2) Előadó_3: cím_3 (időpont_3)

Funkció: Egy konferenciához tartozó előadások felsorolása. Tartalom: A konferenci neve, valamint a hozzá tartozó előadások előadója, címe és időpontja az ábrán látható formában. Működés: Parancsok: Vissza – visszalépés a 6. képernyőre

Vissza

29

13.

Segítség [A segítség szövege]

Funkció: Információ megjelenítése az éppen elvégezhető feladatról. Tartalom: A segítség szövege. 2. képernyő esetén: „A bejelentkezéshez meg kell adnia a felhasználónevét, illetve jelszavát. Amennyiben már egyszer bejelentkezett, úgy a rendszer automatikusan kitölti a mezőket. Az automatikusan beírt értékek megváltoztathatók.” 10. képernyő esetén: „Ha törli a jelentkezését az adott

Vissza

konferenciára, akkor sem a konferencia, sem annak előadásai nem fognak megjelenni a jelentkezéshez kötött képernyőkön (pl.: Éppen folyó előadások, Konferenciák, stb.).” 11. képernyő esetén: „Ha jelentkezik az adott konferenciára, akkor az, illetve annak előadásai megjelennek a jelentkezéshez kötött képernyőkön (pl.: Éppen folyó előadások, Konferenciák, stb.).” Működés: Parancsok: Vissza – visszalépés az előző (2., 10. vagy 11.) képernyőre

14.

Kilépés Biztosan ki szeretne lépni a rendszerből?

Funkció: Megerősítés kérése a rendszerből való kilépés előtt. Tartalom: A képen látható szöveg. Működés: Parancsok: Igen - a program futása befejeződik

Igen Mégsem

Mégsem - a rendszer visszalép arra a képernyőre, ahonnan ide jutottunk (közvetlenül)

30

15.

[nincs] Kommunikáció folyamatban...

Funkció: A felhasználó tájékoztatása arról, hogy a kliens éppen kommunikál a szerverrel. Tartalom: Tájékoztató szöveg, illetve egy kis animáció. Működés:

Kérem, várjon!

A képernyő közepén látható egy nagyobb téglalap, és abban egy kisebb (szürke) téglalap. Amíg a képernyő látható, addig a kis szürke téglalap ciklikusan jobbra-balra mozog a nagyobb

Megszakít

téglalapban. Ha a kommunikáció közben hiba történik, akkor a 16. képernyő jelenik meg. Parancsok: Megszakít – a kommunikáció megszakítása. Ilyenkor a rendszer visszalép arra a képernyőre, melyről a kommunikációt elindította a felhasználó.

16.

Hiba

Funkció: A felhasználó tájékoztatása arról, hogy a szerverrel való kommunikáció közben hiba történt, vagy a kapcsolat annyira lassú,

A szerverrel való kommunikáció közben hiba történt.

hogy a rendszerben meghatározott időkorláton belül nem fejeződött be a kommunikáció. Tartalom: Az ábrán látható szöveg. Működés: -

Újra próbál Vissza

Parancsok: Újra próbál – a kommunikáció újbóli végrehajtása Vissza – visszalépés arra a képernyőre, melyről a kommunikációt elindítottuk

31

17.

Hiba

Funkció: A rendszer működése közben jelentkező (általános) hibák jelzése.

A rendszer működése közben hiba lépett fel.

Tartalom: A képen látható szöveg. Működés: Parancsok:

Vissza

18.

[nincs] A jelentkezését a(z) nevű konferenciára a rendszer elfogadta.

Vissza - a rendszer visszatér ahhoz a képernyőhöz, melyen végrehajtott parancs a hibát kiváltotta

Funkció: Konferenciára való jelentkezés elfogadásának visszajelzése. Tartalom: A képen látható szöveg. Működés: Parancsok: Rendben - a 9. képernyőre lép a rendszer

Rendben

32

19.

[nincs] A(z) nevű konferenciára szóló jelentkezését a rendszer törölte.

Funkció: Konferenciára szóló jelentkezés törlésének nyugtázása. Tartalom: Az ábrán látható szöveg. Működés: Parancsok: Rendben - a rendszer a 4., 8. vagy 7. képernyőre ugrik (attól függően, hogy a felhasználó milyen úton jutott a 10. képernyőig)

Rendben

20.

Hiba A konferenciára vonatkozó jelentkezését nem vonhatja vissza, mert a konferencia programja véglegesítve van.

Funkció: Tájékoztatja a felhasználót, hogy az adott konferenciára vonatkozó jelentkezését nem vonhatja vissza. Tartalom: A képen látható szöveg. Működés: Parancsok: Vissza - visszalép a rendszer a 6. képernyőre

Vissza

33

21.

Funkció: Tájékoztatja a felhasználót, hogy az adott konferenciára több

Hiba

hallgató már nem jelentkezhet, mivel betelt a létszám.

A konferenciára nem lehet jelentkezni, mert betelt a létszám.

Tartalom: A képen látható szöveg. Működés: Parancsok: Vissza - visszalép a rendszer a 6. képernyőre

Vissza

22.

Funkció: A program nevének és a fejlesztő adatainak megjelenítése.

Névjegy

Tartalom:

MobilConference v1.0

A képen látható szöveg.

Készítette: Novák György

Működés:

e-mail: [email protected] w3.netelek.hu/novakg/ conference

Parancsok: Vissza - visszalépés a rendszer a bejelentkező (2.) képernyőre

Vissza

A kliens oldal osztálydiagramja a 7. ábrán látható (az adattagokat és a metódusokat nem tüntettem fel a jobb áttekinthetőség érdekében, de az öröklődéseket és az implementációkat bejelöltem). A vezérlést ezen az oldalon a MobilConferenceMIDlet osztály végzi, mely a javax.microedition.midlet.MIDlet osztályt terjeszti ki, tehát ő a „központi” osztálya a kliens oldalnak. Ő példányosítja a képernyőket implementáló osztályokat, melyek a hu.novakg.diploma.kliens.kepernyok csomagba kerültek, valamint létrehozza az AKImpl osztály egy példányát is, mely majd az adatbázis-kezelést (tulajdonképpen a kliensszerver kommunikációt) intézi (lásd a 4.4. alfejezetben). Ahhoz, hogy a kliens a szervertől kapott

adatokat

meg

tudja

jeleníteni,

a MobilConferenceMIDlet 34

osztálynak

hu.novakg.diploma.kliens.adat BejelentkezesKommunikalo <> AdatbazisKezelo

MaiEloadasokKommunikalo KonferenciakKommunikalo

AKImpl

MindenKonferenciaKommunikalo KonferenciaKommunikalo

Kommunikalo

KonferenciaEloadasaiKommunikalo JelentkezesKommunikalo

EloadasKliens

LemondasKommunikalo KonferenciaKliens

FolyoEloadasokKommunikalo <> Visszahivas

MobilConferenceMIDlet

hu.novakg.diploma.kliens.kepernyok

Bejelentkezes

KonferenciaEloadasai

Konferenciak

EloadasAdatai

MaiEloadasok

Megerosites

FolyoEloadasok

Hiba

MindenKonferencia

KezdoUzenet

Nyugta

Segitseg

Kommunikacio

KonferenciaAdatai

7. ábra hu.novakg.diploma.kliens csomag osztálydiagramja

35

implementálnia kell a Visszahivas interfészt (erről is bővebben majd a 4.4. alfejezetben írok). A képernyők vagy a javax.microedition.lcdui.List, vagy pedig a javax.microedition.lcdui.Form osztály kiterjesztettjei, attól függően, hogy mit is tartalmaznak (ha menüszerű képernyőt kell készíteni, akkor az előbbi osztályt terjesztjük ki, míg a Form-okon több típusú elemet is el tudunk helyezni). Van azonban két képernyő, melyek a javax.microedition.lcdui.Canvas

osztály

kiterjesztettjei.

Az

egyik

a

KezdoUzenet (1. képernyő), melyre egy képet kell kirajzolnunk, és figyelnünk, hogy a felhasználó megnyomja-e valamelyik gombot. Ezt a funkcionalitást legkönnyebben a Canvas osztállyal lehet megvalósítani (lásd [ME13]). A másik osztály a Kommunikacio (15. képernyő) mely szintén egy képet (animációt) jelenít meg (lásd [ME04]). A legtöbb osztály egyetlen – a nevével „megegyező” című – képernyőt valósít meg,

ilyenek a

Bejelentkezes, EloadasAdatai, FolyoEloadasok, KonferenciaEloadasai, MaiEloadasok, Konferenciak, MindenKonferencia, KonferenciaAdatai és a Segitseg. Vannak azonban olyan osztályok is, melyek több, funkcionalitásában nagyon hasonló képernyőt implementálnak: a Nyugta osztály a 18-19., a Megerosites a 10-11., míg a Hiba a 3., 16., 17., 20. és 21. képernyőket megvalósító osztály. Ezekben az esetekben a képernyő megjelenítése előtt beállítjuk annak módját, azaz egy metódusának meghívásával megmondjuk neki, hogy éppen milyen tartalmat kell megjelenítenie. A hu.novakg.diploma.kliens.kepernyok csomag osztályai működésüket tekintve egyszerűek, mindössze információ megjelenítésre és bevitelre szolgálnak. Az egyetlen adat, amit meg kell jegyezniük, az a megjelenített információ (előadások, konferenciák). Az egyedüli vezérlési feladat, melyet a képernyőknek el kell végeznie, az a FolyoEloadasok és a MaiEloadasok osztályok listájára vonatkozó percenkénti frissítési követelmény megvalósítása. Ezt a működést a java.util.Timer és a java.util.TimerTask osztályok használatával értem el, ugyanis ez a két osztály eszközt ad arra, hogy egy (tetszőleges) feladatot bizonyos idő elteltével, vagy adott időközönként automatikusan elvégeztessünk a futtató rendszerrel. (A feladat elvégzése egy külön szálban történik, így bármit csinálhatunk a rendszerünkben, a feladat a megadott időközönként lefut.) Ugyanezt az eszközt használom a kommunikációs képernyő animációjának működtetésére is. A képernyőkön megjelenő összes parancsot a MobilConferenceMIDlet figyeli, ő vezérel minden képernyőváltást. Ha egy képernyőváltásnál az eltűnő képernyő tartalmától függ az új képernyő tartalma (pl. a mai előadások listájáról kiválasztott a felhasználó egy előadást, és annak az adatait szeretné látni), akkor a MIDlet lekérdezi a régi képernyőtől a megfelelő adatot, és átadja 36

azt az új képernyőnek, még mielőtt megjelenítené. A képernyőkkel szemben támasztott követelmény volt, hogy a felhasználó vissza tudjon lépni az előző képernyőre. Ezt kézenfekvő, hogy egy veremmel valósítottam meg, melybe a MIDlet belepakolja a „régi” képernyőket (az őket implementáló osztályok példányait), és ha vissza kell lépni, akkor csak kiveszi a verem tetejéről az ott lévő képernyőt, és megjeleníti azt. A hu.novakg.diploma.kliens.adat csomag osztályairól a 4.4. alfejezetben lesz szó.

4.2. Szerver oldal MobilConferenceSzerver

EloadasSzerver

-$KULCS : String -$AB_NEV : String -$CONF_FILE : String +() +bejelentkezes(String, String): long +folyoEloadasok(Long, Long): Hashtable +maiEloadasok(Long, Long): Hashtable +konferenciak(Long, Long): Hashtable +mindenKonferencia(Long, Long): Hashtable +konferenciaEloadasai(Long): Hashtable +konferencia(Long): Hashtable +jelentkezes(Long, Long): boolean +lemondas(Long, Long): boolean -kiirHiba(String, String): void

+(novakg.ab.Eloadas, java.util.Date)

KonferenciaSzerver +(novakg.ab.Konferencia)

8. ábra Szerver osztálydiagramja

Mivel a szerver oldalon a kommunikációt teljes egészében az Axis végzi (lásd 4.4. alfejezet), ezért itt csak a kliens számára szükséges adatokat előállító metódusokat kellett implementálnom. Ezen az oldalon így mindössze három osztályt kellett készítenem, melyek a 8. ábrán is láthatók. Ezek az osztályok a hu.novakg.diploma.szerver csomagba tartoznak. A szükséges metódusokat a MobilConferenceSzerver osztály tartalmazza. A metódusok elnevezése általában megegyezik a kliens oldalon szereplő megfelelő képernyő címével. Az adatokhoz (adatbázishoz) való hozzáférést a Castor segítségével kezelem, így csak objektumokkal kell dolgoznom, nem kell SQL insert parancsokat összeállítanom, vagy ResultSet-ek soraiból objektumokat készítenem. Meg van az ára azonban ennek a kényelemnek, ugyanis az adatok lekérdezéséhez használt nyelv (OQL7) nem teszi lehetővé olyan összetett lekérdezések megfogalmazását, melyeket SQL-ben természetesnek gondol az ember. Mindenesetre sikerült minden szükséges adatot lekérdező metódust elkészíteni. Ahol lehetőség volt rá, ott a Conference rendszerben már megírt metódusokat hívom meg, azokat nem írtam meg újra. A MobilConferenceSzerver osztálynak van egy belső osztálya is, mely az előadások kezdési idő szerinti sorba rendezéséhez szükséges. A szerver oldal másik két osztálya az adatok reprezentálására szolgál. Az EloadasSzerver a hu.novakg.diploma.kozos csomag Eloadas osztályát 7 Object Query Language

37

terjeszti ki, míg a KonferenciaSzerver a csomag Konferencia osztályát. A kiterjesztés tulajdonképpen csak annyiból áll, hogy egy olyan konstruktort készítettem az osztályokhoz, melyek a Conference rendszerben használt novakg.ab.Eloadas, illetve a novakg.ab.Konferencia osztályok egy-egy példánya alapján hoznak létre új példányt (átveszik azokból a megfelelő adatokat). Így elértem, hogy a Castor által visszaadott objektumokból (amik a novakg.ab csomag elemei) létre tudok hozni a kliens oldalon is kezelhető, hu.novakg.diploma.kozos csomagbeli Eloadas, vagy Konferencia objektumot. (Az EloadasSzerver objektum konstruktorában azért kell megadni egy java.util.Date objektumot is, mert a Conference rendszerben nem kezeltük az előadások befejezési dátumát, a MobilConference-ben viszont erre is szükségünk van. Mivel ez az adat nem tárolódik az adatbázisban, ezért egy előadás befejezési idejének az ugyanazon konferencián belüli, őt követő előadás kezdési időpontját tekintem, illetve a konferencia utolsó előadásánál a nap utolsó percét.)

4.3. Mindkét oldalon használt objektumok Vannak olyan funkciók, illetve objektumok, melyeknek mind a szerver, mind a kliens oldalon

ugyanúgy

kell

megjelenniük.

Az

ezeket

reprezentáló

osztályokat

a

hu.novakg.diploma.kozos csomag tartalmazza. Kodolo -$KODLAP: String +$kodol(String, String): String +$dekodol(String, String): String

DatumFormazo

Eloadas

Konferencia

-$c:Calendar +() +$formaz(Date):String +$formazCsakDatum(Date):String

+id : long +cim : String +eloado : String +helyszin : String +kezdes : Date +befejezes : Date +konferencia : long +konferenciaNev : String

+id : long +nev : String +idopont : Date +helyszin : String +kiirasIdopontja : Date +hallgMaxLetszam : int +hallgAktLetszam : int +vegleges : boolean

9. ábra Közös osztályok diagramja

A Kodolo osztály arra való, hogy a segítségével a felhasználó jelszavát kódoljuk a kliens oldalon a kommunikációhoz, majd a szerver oldalon dekódoljuk azt. Ennek megfelelően a két metódusának első paraméterként a kódolandó/dekódolandó üzenetet kell átadni, míg második paraméterként a használandó kulcsot. Az implementált titkosító algoritmus az eltolásos titkosítás egy változata, mikor az üzenet karaktereihez (azok számmal kifejezett értékéhez) hozzáadjuk a kulcs karaktereit. (Létezik olyan API – a Bouncy Castle Cryptography API8 –, melyben szinte minden kódoló algoritmus implementálva van, de ez a csomag 500KB körüli méretű, ami kizárja, hogy ezt használjam, inkább készítettem egy saját kódolót. Lehet, hogy az általam implementált kódolást nem túl nehéz feltörni, de ebben a rendszerben nem tárolunk 8 http://www.bouncycastle.org

38

olyan információt (pl. bankkártyaszámot), melyet bármilyen áron meg kellene védenünk.) A kódlapra azért van szükség, mert kódolás közben bájt tömböket kezelünk, míg a kommunikáció közben sztring formájában van jelen az üzenet, és a két állapot közti átalakításnál implicit módon megadjuk a kódlapot, hogy mindkét oldal biztosan ugyanazt a karakterkódolást használja. (A MIDP-ben használt kriptográfiai megoldásokat lásd bővebben a Pári Csabával közösen írt cikkünkben[OT05].) A DatumFormazo osztályt csak a kliens oldalon használom, de olyan funkciókat implementál, ami jól jöhet a szerver oldalon is. Segítségével egy java.util.Date objektumot átalakíthatunk a magyar szokásoknak megfelelő szöveges formára. Erre azért van szükség, mert a MIDP a javax.microedition.lcdui.DateField osztállyal ugyan ad egy eszközt dátumok megjelenítésére, de ez nem paraméterezhető úgy, hogy a számomra megfelelő formában adja vissza az időpontokat. A hátramaradt két osztály (Eloadas és Konferencia) az előadások és konferenciák reprezentálására szolgál. (Az osztálydiagrammon nem tüntettem fel a metódusokat, mivel csak üres konstruktort és az adattagokat lekérdező/beállító metódusokat tartalmaznak az osztályok). Az objektumok adattagjai többé-kevésbé eltérnek a Conference rendszerben használt objektumokétól, ami azért van, mert a kliens oldal szűkös erőforrásai, valamint a kommunikáció költséges volta miatt csak azokat az információkat volt szabad meghagynom az objektumokban, melyeket a kliens oldalon megjelenítünk, vagy feltétlenül szükségesek az objektumok közötti kapcsolatok ábrázolásához. Így eltűntek a az osztályokból az olyan adattagok, melyek egy vektorban tárolták a kapcsolódó objektumok példányait. (Például a Konferencia osztályból eltűnt az eloadasok adattag, és csak az Eloadas osztály long típusú, konferencia nevű adattagja jelzi, hogy az előadás melyik konferencia programján szerepel. Újonnan felvett adattagra példa az Eloadas osztály konferenciaNev adattagja, mely lehetővé teszi, hogy az előadás adatai között a konferencia nevét is megjelenítsük a felhasználónak anélkül, hogy a megfelelő Konferencia objektumot lekérnénk a szervertől.) Az objektumok adattagjai mind publikusak, így függvényhívás nélkül is hozzájuk tudunk férni más osztályokból, ami az erőforrások kisebb terhelését eredményezi (bár az OO világban ez nem megszokott eljárás).

4.4. Kommunikáció A J2ME/MIDP alkalmazások meghatározó részét jelentheti valamilyen szerverrel való kommunikáció, hiszen a futtató környezet erőforrásokban szegény, de lehetőséget ad hálózati kapcsolat kezelésére. Ennek ellenére mind a mai napig nincs egy általánosan elfogadott technika 39

a kommunikáció kezelésére. A problémát az jelenti, hogy a MIDP nem teszi lehetővé objektumok szerializálását/deszerializálását úgy, ahogyan a J2SE-ben azt megszokhattuk, így valamilyen más módon kell az adatokat átküldeni egyik féltől a másiknak. Az egyetlen dolog, ami biztosan működik a MIDP-ben, az a HTTP fölötti kommunikáció. Ezt bizonyítja az is, hogy minden olyan publikáció, mely a MIDP hálózatkezelésére ad valamilyen technikát, az a HTTP protokollt használja. A legtöbb ilyen megoldás esetén létezik egy saját osztály, mely az adatokat valamilyen saját protokoll szerint szöveges formára alakítja, majd azt, mint egy bájt tömböt, átküldi a HTTP csatornán (a HTTP kérés, vagy válasz törzsében). Ez a megoldás, mint mondtam, működik, de azt igényli, hogy mind a kliens, mind a szerver oldalon elkészítsünk 1-1 osztályt, mely a mi saját (HTTP fölötti) protokollunkat kezelni tudja. Innen jött az ötlet, hogy esetleg lehetne a webszolgáltatásokat használni MIDP-s környezetben is, hiszen ott is arról van szó, hogy HTTP (netán SMTP) fölött átküldött szöveges üzenetekkel (XML dokumentumokkal) van lekezelve a távoli eljáráshívás. Természetesen ez a megoldás már rajtam kívül sok embernek eszébe jutott, így nem volt nehéz az Interneten olyan API-kat találni, melyek a webszolgáltatások kliens oldali funkcióit valósítják meg. Az első ilyen megoldás, mely ugyan nem webszolgáltatásokra épül, de az elv ugyanaz, a Sun által kidolgozott kommunikációs technológia, melyet a Sun One Studio 5 ME-be be is építettek. Ennek az eszköznek a segítségével egy „tetszőleges” szervlethez (mely szolgáltatásokat nyújt) automatikusan legenerálhatunk egy MIDlet-et, mely ezeket a szolgáltatásokat használja. A megoldás nagyon elegáns, és egyszerű használni, azonban két problémája is van. Az első, hogy a Sun One Strudio 5 ME nem ingyenes, azaz nem jelentettek meg belőle Community Edition kiadást. A másik, nagyobb probléma az, hogy a Sun által kidolgozott protokoll kizárólag boolean, byte, short, char, int, long és java.lang.String típusú adatokat, valamint ezek tömbjét képes kezelni, tehát pl. saját osztályunk objektumát nem küldhetjük át a kommunikációs csatornán. Ezek után megvizsgáltam a webszolgáltatások világának legegyszerűbb protokollját, az XML-RPC-t. Szerver oldalon az Apache XML project-ben fejlesztett Apache XML-RPC9-t használtam, míg kliens oldalon a kxmlrpc10-t. Ennek az üzenetküldő protokollnak az előnye és egyben hátránya is az egyszerűsége. Előnye azért, mert visznonylag kis hálózati forgalommal jár (ami a vezeték nélküli világban fontos). Hátránya viszony azért, mert (a Sun megoldásához hasonlóan) csak elemi típusokat tud kezelni (legalább is az általam használt implementáció nem tudta kezelni sem a tömböket, sem a hash-táblákat). Végül kipróbáltam a SOAP protokollt, melyet szerver oldalon az Axis11, míg kliens 9http://xml.apache.org/xmlrpc 10 http://kxmlrpc.enhydra.org/ 11 http://ws.apache.org/axis/

40

oldalon a kSOAP212 implementál. Ez a megoldás már tudja kezelni a Hash-táblákat, és a magyar ékezetes karaktereket is (a kxmlrpc ezeket sem tudta megfelelően átküldeni). Mivel szerver oldalon a saját objektumok átalakítását az Axis hibátlanul megoldja, és kliens oldalon is könnyen ki lehet nyerni az objektumokat a kapott SOAP válaszból, így ezt az átviteli protokollt használtam az alkalmazás elkészítéséhez. Mint mondtam, az Axis megbirkózik az objektumok „szerializálásával”, azaz automatikusan

átalakítja

a hu.novakg.diploma.kozos

csomag

Eloadas

és

Konferencia objektumát a megfelelő XML dokumentummá, kliens oldalon viszont nem megy automatikusan a visszaalakítás. Ahhoz, hogy a kliens a kapott SOAP válaszból ki tudja nyerni az objektumokat, készítenem kellett egy-egy metódust, mely a válaszból kiolvasva a adatokat,

felépíti

a

megfelelő

objektumot.

Ezek

a

metódusok

a

hu.novakg.diploma.kliens.adat.EloadasKliens osztály és ugyanezen csomag KonferenciaKliens osztályának deserialize( SoapObject ) metódusa, mely a válaszban kapott SOAP objektumokból (melyeket a kSOAP2-től le tudunk kérdezni) elkészíti a megfelelő, hu.novakg.diploma.kozos csomagba tartozó objektumpéldányt. Ez a visszaalakítás nagyon egyszerű, hiszen a SOAP obejktumtól az adattagok név szerint lekérdezhetők, és a kapott értékekkel be tudjuk állítani a számunkra szükséges objektum állapotát. Így tehát megoldottuk, hogy HTTP protokoll fölött a saját objektumainkat tudjuk eljuttatni az egyik oldalról a másikra. Mivel a mobil világban a hálózati kommunikáció lassabb és költségesebb, mint az asztali gépek világában, ezért itt fokozottan oda kell rá figyelni, hogy a felhasználó megszakíthassa a kommunikációt, ha úgy gondolja. A kommunikáció megszakítására Jonathan Knudsen

[ME04]

ad

egy

módszert,

miszerint

a

kommunikációt

végző

javax.microedition.io.HttpConnection példányra hivatkozó változót állítsuk null-ra a megszakításhoz. Természeresen ilyenkor a rendszer egy kivételt dobhat, amennyiben további kommunikációs tevékenységet kíván végezni az adott kapcsolaton. Ezt a kivételt elkapjuk, és mivel tudjuk, hogy mi szakítottuk meg a kapcsolatot, ezért egyszerűen csak „lenyeljük” azt. Ugyanakkor oda kell figyelnünk arra is, hogy ilyenkor a szerveren is kiváltódik egy kivétel, ugyanis ő sem tud tovább kommunikálni a megszakadt kapcsolaton keresztül. Ez a módszer működik, mindössze annyi a gyengesége, hogy egy megszakítás után el kell telnie bizonyos időnek, míg a szerver „észreveszi”, hogy a kapcsolat már nem él (nem jön visszajelzés az elküldött csomagokra). Ez az idő csak 1-2 másodperc, ám ha eközben kíván a kliens újabb kapcsolatot létrehozni, akkor az nem fog neki sikerülni (de később már képes lesz a szerver új kapcsolat kiépítésére). A gyakorlatban ez azt jelenti, hogy ha a felhasználó megszakít egy 12 http://ksoap.enhydra.org/

41

kapcsolatot, majd rögtön ezután egy újat akar felépíteni, akkor a rendszer egy hibaüzenetet küld neki, miszerint a hálózati kapcsolat nem hozható létre. A következő próbálkozásnál viszont már nagy valószínűséggel létre fog jönni a kapcsolat. Most nézzük, hogy az általam készített rendszerben hogyan is működik a kapcsolat megszakítása. Mint az a 10. ábrán is látható egy kommunikációs menet normál, megszakítás nélküli lefolyása esetén a hálózati forgalmazás alatt a felhasználó a kommunikációs képernyőt látja, majd a kommunikáció befejeződése után a kapott adatokat megjelenítő képernyő válik láthatóvá. Ha a felhasználó úgy dönt, hogy megszakítja a kommunikációt, akkor a kommunikációs képernyő helyett a rendszer újra azt a képernyőt jeleníti meg, melyről a kommunikációt kezdeményezte a felhasználó. Mint az ábrán látható, a kommunikációt kezelő szál még a megszakítás után egy darabig fut. Hogy ez miért van így, az rögtön kiderül.

Normál eset

Megszakítás

Kommunikációt kezelő szál

Kommunikációt kezelő szál

Kommunikációt kezdeményező képernyő

Kommunikációt kezdeményező képernyő

Kommunikációs képernyő

Kommunikációs képernyő MEGSZAKÍTÁS

Kommunikációt kezdeményező képernyő

Következő képernyő

10. ábra Kommunikáció megszakítása

A kommunikáció tehát úgy szakítható meg a kliens oldalról, hogy null-ra állítjuk a kommunikációt intéző objektum referenciáját. Ez a lehetőség megvan a kSOAP2 kommunikációt intéző osztályában (org.ksoap2.transport.HttpTransport) is, azonban ott nem elég hatékony, ezért úgy döntöttem, hogy átveszem ebből az osztályból a kommunikáló

metódust,

és

átírom azt,

amennyire

szükséges.

Ez

a

metódus

a

hu.novakg.diploma.kliens.adat.Kommunikalo osztályba került, és ugyanide került a megszakítást lehetővé tevő metódus is. Az átvett metódust annyiban alakítottam át, hogy minden olyan tevékenység előtt, ami a kommunikációhoz kötődik (pl. kimenő csatorna megnyitása, bejövő adat következő egységének beolvasása, stb.) megvizsgálom, hogy a felhasználó nem szakította-e meg a kommunikációt (ezt egy egyszerű logikai változó jelzi), és 42

ha megszakította, akkor nem folytatom tovább a feldolgozást. (Ha a felhasználó kiadja a megszakítás parancsát, akkor a rendszer rögtön átváltja a képernyőt, de a kommunikáció tovább folyik, míg egy olyan pontra nem ér a kommunikációt kezelő szál, ahol ellenőriznie kell, hogy történt-e megszakítás. Ezért van az, hogy a szál még a képernyőváltás után is fut egy ideig.) Az egyes képernyőkhöz szükséges kommunikációkat megvalósító osztályok az előbb említett Kommunikalo osztályt terjesztik ki annyival, hogy összeállítják a szerverhez átküldendő SOAP kérést, majd a kapott választ feldolgozzák. Mivel az egyes kommunikációs menetek szálakban zajlanak, ezért a programunkat eseményvezéreltté kell alakítani, azaz a kommunikáció nem úgy zajlik, hogy a MIDlet meghív egy metódust, és visszatérési értékként megkapja a szervertől kapott választ, hanem úgy, hogy a MIDlet meghív egy metódust, a kommunikáció elkezdődik egy új szálban, és a vezérlés visszakerül a MIDlet-hez, majd a kommunikáció befejeztével az előbb elindult szál meghívja a MIDlet egy metódusát, visszaadva a kapott választ. A MIDlet a kommunikáció kezdeményezéséhez az AdatbazisKezelo-t implementáló AKImpl osztály valamely metódusát hívja meg, mely létrehozza a megfelelő, Kommunikalo-t kiterjesztő osztály példányát, és elindítja a létrejött szál futását. Itt visszakerül a vezérlés a MIDlet-hez. Ekkor a felhasználó a kommunikációs képernyőt látja, melyen egyetlen parancs, a megszakítás szerepel. Ha a felhasználó kiadja ezt a parancsot, akkor a MIDlet a kommunikáló szál megszakit() metódusát meghívva utasítja azt a kommunikáció megszakítására. Ha viszont a kommunikáció sikeresen véget ér, akkor a kommunikációs szál a Visszahivas interfészben deklarált valamely metódust (melyet a MIDlet implementál) meghívva átadja a MIDlet-nek a kapott választ. Ha a kommunikáció közben valamilyen hiba történik, akkor a felhasználót erről egy képernyő tájékoztatja, melyen lehetősége van a kommunikáció újrakezdésére. Ez az újrakezdés a rendszer szempontjából azt jelenti, hogy újra létre kell hozni a kommunikációt végző szálat. J2SE-ben ez viszonylag egyszerűen megoldható az ún. „önelemzés” eszközeivel, de J2ME-ben nincs meg ez az eszközkészlet, így mást kellett kitalálnom. A megoldás az lett, hogy az ABImpl osztály metódusait (melyeket a MIDlet a kommunikáció kezdeményezéséhez meghív) „megszámoztam”, azaz mindegyikhez hozzárendeltem egy számot. Mikor valamely metódus meghívódik, akkor egy osztályszintű változóban eltárolódik, hogy „hanyas számú” metódus hívódott meg, egy objektum tömbben pedig a hívás paramétereit jegyezzük meg. Ezek után, ha a kommunikációt újra kell indítani, akkor egyszerűen csak meghívjuk az utoljára meghívott metódust (melynek számát eltároltuk) az elmentett paraméterekkel, és az létrehozza a megfelelő kommunikáló szálat. A hálózaton átküldött adatok nem nevezhetők „érzékenynek”, azaz a felhasználónak

43

nem származhat nagy baja például abból, ha valaki a kommunikációt lehallgatva megtudja, hogy a felhasználó mely konferenciákra jelentkezett hallgatónak. Van azonban egy adat, melyre vigyáznunk kell a kommunikáció folyamán legalább annyira, hogy nem küldjük át az eredeti formájában, ez pedig a felhasználó jelszava. Mivel a kommunikáció HTTP fölött zajlik (mely egyáltalán nem nevezhető biztonságosnak), így valamilyen kódolással titkosítanunk kell a jelszót. Erre használom a 4.3. alfejezetben már tárgyalt Kodolo osztályt, melynek segítségével a jelszót kódolni és dekódolni tudom. Ha a jelszót így, kódolva küldjük át a nem biztonságos HTTP csatornán, akkor már valamilyen szinten kizártuk, hogy illetéktelenek kezébe jusson ez az információ. (Tökéletes biztonság persze nem létezik).

44

5. Tesztelés A tesztelésnek a szoftverfejlesztés folyamatában a kódolás kezdetétől jelen kell lennie, hiszen ha megvalósítjuk a rendszer egy-egy funkcióját, akkor azt ki is kell próbálni, hogy működik-e. Így jártam el a MobilConference fejlesztésénél is: mikor kész lett a kliens oldal egy újabb képernyője, és az ahhoz tartozó szerver oldali kiszolgáló metódus, akkor azt rögtön le is teszteltem. (A teszteléseket általában emulátorral13 végeztem. Ahol nem így van, ott erre külön felhívom a figyelmet.) Mikor minden képernyő elkészült, akkor létrehoztam a szerver oldalon egy teszt adatbázist (felvettem egy előadó, egy hallgatót, néhány konferenciát és előadást) és a 6. ábra alapján végigjártam az alkalmazás minden lehetséges állapotát. Ekkor tehát minden képernyő minden parancsát kipróbáltam, és minden képernyőn leellenőriztem, hogy a megjelenített adatok megfelelnek-e annak, ami az adatbázisban szerepel. Ha valamilyen hibát találtam, akkor azt kijavítottam, és újrakezdtem a tesztelést. Így meggyőződtem arról, hogy minden képernyőn az jelenik meg, amit a felhasználó elvár. Ezek után következhetett a rendszer kipróbálása egy mobil telefonon. A teszt készülék egy Siemens MC60-as telefon volt, mely a dokumentációja szerint támogatja a MIDP 1.0-t. A telefonra az alkalmazásnak egy olyan változatát töltöttem, mely nem kommunikál a szerverrel, hanem a Kommunikalo-t kiterjesztő osztályok maguk állítanak elő adatokat. Erre azért volt szükség, mert ennek a tesztnek a feladata mindössze a képernyőváltások és a képernyőkön megjelenő információk helyességének ellenőrzése, amihez nincs szükség (költséges) hálózati kommunikációra. A telefonon is elvégeztem azt a tesztet, amit az előző lépésben, vagyis minden képernyő minden parancsát kipróbáltam, és közben ellenőriztem a megjelenő adatokat (itt az adatok megjelenési formája volt a fontos). Miután ebben a tesztben is mindent rendben találtam, következhetett a végső teszt, melyben a mobil készüléken futó kliens és a szerver kommunikációját vizsgáltam. A szerver oldalt ehhez a teszthez az Informatikai Intézet iam008 nevű szerverére telepítettem, míg a kliens oldalt a már említett Siemens telefonon kívül egy Palm Tungsten C kéziszámítógépen is kipróbáltam. Korábbi tapasztalataimból okulva számítottam rá, hogy az elkészített alkalmazás nem telepíthető zökkenőmentesen tényleges telefonra, így nem lepődtem meg, mikor a telefonon futó kliens egy kivételt dobott, miszerint a szervertől kapott üzenet UTF-8 kódolással van kódolva, de ő ezt nem képes visszafejteni. Mivel nem találtam lehetőséget arra, hogy a szerver oldali kiszolgálóban (Apache Axis) átállítsam az üzenetek karakterkódolását, ezért kliens oldalon kellett megoldanom a problémát. A megoldás az lett, hogy készítettem egy osztályt, mely az UTF-8 kódolású karakterfolyamokat dekódolja (a java.io.Reader 13 J2ME Wireless Toolkit 1.0.4_01

45

osztályt terjeszti ki), és átírtam a kSOAP2-t, hogy ezt az osztályt használja az üzenetek beolvasásához. Ezek után a kliens a telefonon tökéletesen működött, minden képernyőt végigjártam, és mindig a várt eredményt tapasztaltam. A Palm esetében sajnos nem jártam ilyen sikerrel, mivel az a kliens futtatása közben java.lang.OutOfMemoryError kivételt dobott. Mivel a két készüléken (telefon, Palm) ugyanaz a kliens futott, és a Palm memóriája jóval nagyobb, mint a telefoné, így nem tudtam rájönni, hogy mi lehet a probléma. Az egyetlen tippem, hogy a Palm-on lévő Java futtató környezet esetleg nem megfelelően interpretálja az alkalmazást. Miután az alkalmazás tervezésénél és kódolásánál is a 3.1. alfejezetben megfogalmazott követelményeknek megfelelően jártam el, így várható volt, hogy az elkészült rendszer is megfelel ezeknek a követelményeknek. A biztonság kedvéért azért újra átnéztem a követelményeket, és megbizonyosodtam róla, hogy azok mindegyikét kielégíti az alkalmazás. Vannak nagyobb telefongyártó cégek, melyek kidolgoztak olyan saját ellenőrzési rendszert, melyek segítenek meggyőződni arról, hogy az elkészített J2ME/MIDP alkalmazásunk megfelel bizonyos általános elvárásoknak. Ilyen rendszere van például a Nokia-nak is, aki az alkalmazásokkal szembeni elvárásokat egy listában (Developer Checklist for J2METM Applications14) foglalta össze. Ezeket az elvárásokat végignézve mindössze egyetlen olyan pontot találtam, melynek a MobilConference nem felel meg, ez pedig a következő volt: „Érzékeny adatot (pl. bankszámlaszámot) nem tárol az alkalmazás”. Ha úgy vesszük, akkor a felhasználó jelszava érzékeny adatnak tekinthető, és az alkalmazásunk azt kódolás nélkül eltárolja a permanens tárban. Mivel azonban a felhasználó mobil telefonja az ő személyes használati tárgya, vélhetően azt másnak nem adja kölcsön, ezért úgy gondolom, hogy nem jelent problémát, hogy a telefon memóriájában szerepel a felhasználó jelszava.

14 http://forum.nokia.com

46

6. Összefoglalás A dolgozatomban egy olyan rendszer elkészítésének folyamatát írtam le, melynek segítségével a felhasználó mobil készülékéről követheti nyomon egy-egy konferencia programját. A rendszer (mobil készüléken futó részének) elkészítésénél a CLDC 1.0 és MIDP 1.0 által meghatározott eszközöket használtam, így az minden olyan mobil készüléken futtatható, mely támogatja a MIDP valamely verzióját. A dokumentáció mellett természetesen elkészült

a

tényleges

rendszer

is,

az

mindenki

számára

elérhető

(

http://w3.netelek.hu/novakg/conference ), használható. A dolgozat legfontosabb részének a kliens és szerver közötti hálózati kommunikáció megvalósítását leíró részt tartom, mivel a MIDP világában nincs általánosan elfogadott technika ezen feladat megoldására, és az általam tárgyalt módszer működik, és viszonylag kényelmesen használható (a fejlesztő tulajdonképpen csak objektumokkal dolgozik, nem kell bájt tömböket kezelnie). A leírt technikát nem én találtam ki, de sehol nem találkoztam olyan cikkel, vagy példaalkalmazással, mely részletesen bemutatta volna azt. Mindenesetre léteznek mind a kliens, mind a szerver oldalon használható nyílt forráskódú eszközök, melyekkel megvalósítható ez a fajta kommunikáció, és mivel tulajdonképpen egyfajta webszolgáltatásról van szó, ezért a technológia további fejlődése, finomodása várható.

47

7. Mellékletek: A Conference rendszer leírása 7.1. A rendszer rövid leírása A Conference egy olyan rendszer, mely konferenciák szervezését hivatott segíteni. Lehetővé teszi, hogy egy szervező (Adminisztrátor) konferenciákat hirdessen meg, melyekre Előadók és Vendégek jelentkezhetnek. Az Előadók jelezhetik azon szándékukat, hogy előadást kívánnak tartani egy meghirdetett konferencián. Az Előadókkal kapcsolatos műveleteket (regisztráció, előadás felvétele egy konferenciára, stb.) az Adminisztrátor felügyeli.

7.2. A rendszerben előforduló személyek és használati esetek A rendszer use case diagramja a 11. ábrán látható. Az egyes aktorok és használati esetek leírása a következő: Aktorok: •

Adminisztrátor – Ő az a személy, aki a rendszer működését felügyeli. Ő felelős a konferenciák meghirdetéséért, azokhoz előadások felvételéért, valamint Előadók felvételéért a rendszerbe.

•

Előadó – Az előadók tarthatnak előadásokat a konferenciákon. Ahhoz, hogy valaki Előadóként szerepeljen a rendszerben, regisztrálnia kell magát, amit az Adminisztrátornak kell jóváhagynia. Az Előadó tehát jelezheti a rendszer felé, hogy előadást kíván tartani egy adott konferencián, lemondhatja valamely előadását, valamint természetesen részt vehet konferenciákon hallgatóként is.

•

Vendég – A vendégek részt vehetnek a konferenciákon, mint hallgatók. Ahhoz, hogy valaki Vendég legyen a rendszerben, regisztrálnia kell magát.

Használati esetek: •

Előadó jelentkezésének jóváhagyása – Ha valaki regisztrálni kívánja magát a rendszerben Előadónak, akkor ezt a jelentkezést az Adminisztrátornak kell jóváhagynia. A jóváhagyásról a rendszer email-t küld a jelentkezőnek.

•

Előadás jóváhagyása - Ha egy Előadó jelzi a rendszer felé, hogy egy adott konferencián előadást szeretne tartani, akkor az Adminisztrátor megvizsgálja, hogy a jelzett előadás befér-e az adott konferencia keretei közé. A döntésről a rendszer (automatikusan) email-t küld az Előadónak. Ha pozitív döntés született, akkor az előadás felkerül a konferencia programjára.

•

Konferenciák listájának megtekintése – A rendszerben szereplő bármely aktornak lehetősége van megtekinteni a kiírt konferenciák listáját. A listán a konferenciák 48

11. ábra Conference rendszer use case diagramja

neve, időpontja, helye szerepel. •

Konferencia

programjának megtekintése -

Bármely

felhasználó

(aktor)

megtekintheti egy tetszőleges meghirdetett konferencia lényeges adatait, azaz annak programját, időpontját, a kiírás időpontját, helyét, a hallgatóság maximális számát, valamint azt, hogy lehet-e még hallgatónak, vagy előadónak jelentkezni rá. •

Előadás lemondásának jóváhagyása – Ha egy Előadó jelzi a rendszer felé, hogy le kívánja mondani egy előadását, akkor az Adminisztrátor megvizsgálja, hogy az adott előadás eltávolítható-e a konferencia programjáról. Ha úgy találja, hogy igen, akkor az előadás lekerül a konferencia programjáról. Bármilyen döntést is hoz az Adminisztrátor, arról az Előadót email-ben értesíti a rendszer.

•

Konferencia programjának véglegesítése - A konferencia időpontja előtt egy pár nappal az Adminisztrátor lezárja a konferenciára való jelentkezéseket, további jelentkezések ez után már nem lehetségesek sem az előadók, sem a vendégek részéről. Ezután az időpont után nem lehet lemondani sem a vendégek részvételi szándékát, sem az előadásokat. A konferencia végleges programjáról a rendszer email-t küld a konferencia minden előadójának és minden vendégének.

•

Belépés - A felhasználónak (Vendég, Előadó) be kell lépnie a rendszerbe a regisztrációjakor kapott felhasználónévvel és jelszóval, hogy azt használni tudja.

•

Vendég regisztrációja - A vendégnek regisztrálnia kell magát a rendszerben, hogy jelentkezhessen konferenciákra hallgatónak. (A vendégek regisztrációjánál nincs jóváhagyás

az

Adminisztrátor

részéről.)

A

regisztráció

során

a

vendég

felhasználónevet és jelszót kap, mely a rendszerbe való belépéshez szükséges. •

Jelentkezés konferenciára hallgatónak - Ha egy Vendég, vagy Előadó szeretne hallgatóként részt venni egy konferencián, akkor jelentkeznie kell. Ezt a jelentkezését később visszamondhatja. A jelentkezést nem kell jóváhagynia az Adminisztrátornak.

•

Hallgatói jelentkezés visszamondása – Ha egy Vendég, vagy Előadó úgy dönt, hogy mégsem megy el a konferenciára, amelyre hallgatónak jelentkezett, akkor visszamondhatja a jelentkezését feltéve, hogy még nincs véglegesítve az adott konferencia programja.

•

Előadó regisztrációja - Ha valaki előadást szeretne tartani egy konferencián, akkor regisztrálnia kell magát a rendszerben. (Egy regisztráció után akármennyi konferenciára jelentkezhet előadónak.) A regisztrációt az Adminisztrátornak jóvá kell hagynia. A regisztráció során az Előadó felhasználónevet és jelszót kap, mely a rendszerbe való belépéshez szükséges.

•

Előadó jelentkezése konferenciára – Ha egy Előadó valamely meghirdetett 50

konferencián szeretne előadást tartani, akkor jelzi ezt a szándékát a rendszer felé, és ezzel egy időben feltölti a rendszerbe az előadás leírását. Ezek után az Adminisztrátornak kell jóváhagynia a jelentkezést. •

Előadás lemondása - Amennyiben egy Előadó meggondolja magát, és nem kívánja megtartani valamely korábban jelzett előadását, akkor lemondhatja azt. Az előadás csak akkor kerül le az adott konferencia programjáról, ha a lemondást az Adminisztrátor jóváhagyja.

•

Konferencia kiírása – Az Adminisztrátor kiírhat új konferenciákat, azaz megadja, hogy mikor, hol, milyen néven és mennyi hallgatóval kíván konferenciát tartani, és ezután erre a konferenciára is jelentkezhetnek a hallgatók, illetve előadók.

7.3. A rendszerben szereplő objektumok A rendszerben a . ábrán látható objektumok szerepelnek. Az objektumok leírása a következő: •

Eloadas – Előadást reprezentáló objektum. Az objektum attribútumai: ›

id – az előadás azonosítója

›

cím – az előadás címe

›

eloado – az előadást tartó felhasználó

›

terem – az előadás helyszíne

›

idopont – az előadás kezdésének időpontja

›

anyagPath – az előadás ismertető anyagának útvonala (Az előadás ismertetőjét az előadó PDF formátumban tölti föl a szerverre az előadás regisztrálásakor.)

› •

konferencia – az a konferencia, amelynek a programján szerepel az előadás

Konferencia – Konferenciát reprezentáló objektum. Attribútumai:

51

12. ábra A Conference rendszerben szereplő objektumok ›

id – a konferencia azonosítója

›

nev – a konferencia neve

›

idopont – a konferencia időpontja (év, hó, nap)

›

helyszin – a konferencia helyszíne (épület)

›

kiirasIdopontja – az az időpont, amikor az Adminisztrátor kiírta a konferenciát

›

hallgatosagMaxLetszama

–

legfeljebb

ennyi

hallgató

jelentkezhet

a

konferenciára ›

eloadasok – azok az előadások, melyek a konferencián kerülnek megtartásra

›

hallgatok – azok hallgatók, akik eddig jelentkeztek a konferenciára

›

vegleges – azt mondja meg, hogy a konferencia programját véglegesítette-e már az Adminisztrátor

•

Felhasznalo – Felhasználót reprezentáló objektum. Attribútumai: ›

id – a felhasználó azonosítója

›

vezeteknev – a felhasználó vezetékneve

›

keresztnev – a felhasználó keresztneve

›

lakcim – a felhasználó lakcíme

›

telefonszam – a felhasználó telefonszáma

›

email – a felhasználó email címe

›

munkahely – a felhasználó munkahelye

›

szakterulet – a felhasználó szakterülete

52

›

felhasznalonev – a felhasználó által a rendszerbe való belépéshez használat név

›

jelszo - a felhasználó által a rendszerbe való belépéshez használat jelszó

›

szerepkor – azt mondja meg, hogy a felhasználó mint vendég, vagy mint előadó szerepel a rendszerben. (A szerepkört az objektum VENDEG, illetve

ELOADO konstansaival adjuk meg.) ›

eloadasok – azok az előadások, melyeket a felhasználó tart

›

konferenciakHallgato – azok a konferenciák, melyekre a felhasználó hallgatónak jelentkezett

›

konferenciakEloado – azok a konferenciák, melyeken a felhasználó előadást tart

53

Ábrajegyzék 1. ábra A Java2 platform...............................................................................................................7 2. ábra Szervletek működése és helye a konténerben.................................................................10 3. ábra A Castor JDO helye az alkalmazásokban.......................................................................12 4. ábra A rendszer használati esetei............................................................................................15 5. ábra A rendszer architektúrája................................................................................................19 6. ábra Aktivitás diagram............................................................................................................20 7. ábra hu.novakg.diploma.kliens csomag osztálydiagramja......................................................35 8. ábra Szerver osztálydiagramja................................................................................................37 9. ábra Közös osztályok diagramja.............................................................................................38 10. ábra Kommunikáció megszakítása........................................................................................42 11. ábra Conference rendszer use case diagramja.......................................................................49 12. ábra A Conference rendszerben szereplő objektumok..........................................................52

54

Irodalomjegyzék CA01: Jeff Lowery: Using Castor JDO for SQL Mapping. The O'Reilly Network, 2002. In http://www.oreillynet.com/ ME01: George Lawton: Deals drive Java technology into new environments. 1998. In http://www.javaworld.com ME02: Qusay H. Mahmoud: J2ME Luminary Antero Taivalsaari. 2004. In http://java.sun.com ME03: Jonathan Knudsen: What's New in MIDP 2.0. 2002. ME04: Jonathan Knudsen: Networking, User Experience, and Threads. 2002. In http://java.sun.com ME05: MID Profile. Sun Microsystems Inc., 2000. ME06: David A. Umphress: Bringing J2ME Industry Practice into the Classroom. ACM, 2004. In http://portal.acm.org ME07: James White: An Introduction to Java 2 Micro Edition (J2ME); Java in Small Things. IEEE, 2001. ME08: Sangeetha Shekar, Prashant Nair, Abdelsalam (Sumi) Helal: iGrocery - A Ubiquitous and Pervasive Samrt Grocery Shopping System. ACM, 2003. In http://portal.acm.org ME09: Mobile Information Device Profile. Sun Microsystems Inc., 2002. ME10: Java 2 Platform, Micro Edition. Sun Microsystems Inc., 2002. ME11: Java 2 Platform, Micro Edition (J2ME) Connected Device Configuration (CDC). Sun Microsystems Inc., 2003. ME12: Margret Johnston: Sun to license Java for use in Webphones. 1997. ME13: Eric Giguere: Building Splash Screens for MIDlets. 2001. In http://java.sun.com/jdc/J2METechTips/2001/tt0820.h OT01: : Java MIDP Application Developer's Guide for Nokia Devices. Nokia Mobile Phones, 2002. In http://forum.nokia.com OT02: Qusay H. Mahmoud: Wireless Software Design Techniques What every wireless software developer. 2002. In http://java.sun.com OT03: Ian Sommerville: Szoftverrendszerek fejlesztése. Panem, 2002. OT04: Oscar Mayora-Ibarra: A Visual Programming Environment for Devices Independent Generation of User. ACM, In http://portal.acm.org OT05: Novák György, Pári Csaba: Kriptográfiai megoldások MIDP alkalmazásokban. 2003. In http://mobidiak.inf.unideb.hu/kripto SL01: Jason Hunter: Java szervletek programozása. Kossuth, 2002. TE01: Qusay H. Mahmoud: Testing Wireless Java Applications. 2002. In http://java.sun.com WI01: Win Treese: Getting unwired: the WiFi way. ACM, In http://portal.acm.org WI02: Daniel L. Lough, T. Keith Blankenship, Kevin J. Krizman: A Short Tutorial on Wireless LANs and IEEE 802.11. 55

WS01: Gottdank Tibor: Webszolgáltatások. ComputerBooks, 2003. WS02: Java 2 Platform, Micro Edition (J2ME) Web Services Specification. Sun Microsystems Inc., 2003.

56