Szolgáltatás-felfededezésre alapozott elektronikus oktatórendszer[1]

 

Dulai Tibor, Medve Anna, Muhi Dániel, Dr. Tarnay Katalin

 

 

Absztrakt: Tanszékünkön kidolgoztunk néhány web-alapú segédanyagot egyes általunk oktatott tárgyak támogatására. A múlt évben azt tapasztaltuk, hogy a hallgatók ezekből a tárgyakból lényegesen jobb eredményeket értek el, mint a webes segédanyag által nem támogatottak esetében. Ez a tény indíttatta azt a döntésünket, hogy második generációs elektronikus oktatórendszert (e-learning system) fejlesszünk ki. Első lépésben megalkottuk a rendszer modelljét. Ebbe három különböző technológiát integráltunk. A rendszer alapját az Elektronikus Oktatási Rendszer (Electronic Education System - EES) nevű modell képezi. Ezt mi szolgáltatás felfedezéssel egészítettük ki, mely előzetes konfiguráció nélkül hálózati oktatási erőforrások felfedezésére ad lehetőséget. Ezen erőforrások leírására az IEEE oktatási metaadat specifikálására kidolgozott szabványát, a Learning Object Metadata-t (LOM) használtuk. A cikkben ezt az integrált modellt mutatjuk be.

 

1. Bevezetés

 

Célunk bemutatni, hogyan fejlesztettünk ki egy elektronikus oktatási modellt három különböző technológia integrálásával, melyek a következők:

Azt várjuk, hogy e modell implementálásával létrehozhatóak, használhatóak és az oktatási rendszerbe integrálhatóak újrafelhasználható, kereshető és platform-független oktatási objektumok.

A világon egyetlen dolog állandó, ez pedig a folyamatos változás. A változás az oktatást sem kerüli el. Rosenberg szerint [1] az oktatás átalakulásának két fő tényezője van:

ˇ  Egyrészt egyre nő az igény a "bármit, bármikor, bárhol" [2] típusú tanulásra, ennek következtében megnő a számítógépes hálózatok - leginkább az Internet - szerepe az oktatásban.

ˇ  Másrészt egyre inkább elfogadottá válik az a tény, hogy a tanulás az ember egész életén át tartó folyamat.

E két tényező biztosítja az elektronikus tanulás elterjedését, melynek legfőbb előnyei a költséghatékonyság, a változások dinamikus követése, a konzisztencia, az egyszerű elérhetőség, interaktivitás és a személyre szabhatóság lehetősége. Sokan azt gondolják, hogy az e-tanulás káros jelenség, mert ki fogja szorítani a hagyományos, tantermi oktatást. Ez azonban nem igaz, egy e-tanulási rendszer célja az, hogy segítse a hagyományos oktatás munkáját, és a kettő egymással együttműködve olyan hátteret biztosít a diákok számára, mellyel tudásuk és képességeik biztosabbá válnak. [3] Ezért minden oktatási intézmény stratégiájában szerepelnie kell az e-tanulási technológiák kifejlesztésének, illetve a hagyományos oktatási rendszerbe való integrálásának.

Az  EU e-Európa programjában [4,5] az elektronikus oktatás terjesztése a kiemelt feladatok közé került. Az ezirányú kutatások eredményei általános és konkrét képzésekre vonatkozóan is, a tanulást segítő intézmények megújítására adnak fő irányelvek köré csoportosított módszertani javaslatokat, a terjesztést segítő szabványokat és szoftveres eszközöket. Ennek fontosságát saját tanszékünkön is megtapasztaltuk: előző évben a már létező WEB-alapú  segédanyag-gyűjteményhez kapcsolódó modulokból a vizsgázók látványosan jobban teljesítettek, mint az elektronikus segédanyaggal még nem támogatott modulokból.

Ezért döntöttünk egy könnyen használható elektronikus oktatási rendszer kifejlesztése mellett. Ennek eléréséhez már létező szabványokat és technológiákat alkalmaztunk. Megalkottunk egy modellt, mely a következő három fő komponensből áll:

A következő 3 fejezetben (2-4) a három komponenst, míg az ötödik fejezetben az integrált modellt mutatjuk be.

 

2. A Learning Object Metadata (LOM)

 

Ezt a specifikációt oktatási objektumok leírására alkalmazzák. Metaadat alatt adatot leíró adatot értünk, vagy más szavakkal információról szóló információt. Metaadat segítségével egy objektum minden lényeges tulajdonsága (pl. tartalma, struktúrája, elérhetősége, stb.) leírható. Ez különösen lényeges nem szöveges objektumok esetén (pl. multimédiás erőforrások). Könnyebbé teszi az információ menedzselését a hálózati adminisztrátorok számára, míg a felhasználók a fontos információt a köztük való böngészés nélkül megtalálhatják.

Az oktatási metaadat oktatással kapcsolatos erőforrásokról nyújt információt. Ezek nem csak elektronikus erőforrások lehetnek, hanem akár könyvek, személyek vagy szervezetek is. Bár a fő feladata az oktatási metaadatnak az elektronikus erőforrások leírása, különösen a hálózaton elhelyezetteké.

Ezen erőforrások rohamosan növekvő száma különösen fontossá teszi a metaadatok alkalmazását. Egy erőforrás akármilyen kiváló is lehet, ha képtelenek vagyunk megtalálni a hálózaton. Az erőforrások leírása metaadattal viszonylag egyszerű, így azok megosztása, keresése, vagy akár személyre szabása szintén könnyebbé válik.

Oktatási környezetben használt metaadatra számos javaslat létezik. A legjelentősebb közülük az IEEE LTSC (Learning Technologies Standardization Committee [6]) munkacsoportja által készített Learning Object Metadata. Az LTSC munkája majdnem minden, az elektronikus oktatással kapcsolatos területet lefed.

Az oktatási erőforrások természetükből adódóan heterogének, ezt a tény tükrözi a metaadat leírása is. A LOM kilenc kategóriát tartalmaz (1. táblázat), több mint 60 különböző attribútummal (adatelemmel).

 

Kategória              Leírás

Általános                 Kontextus-független tulajdonságok és az erőforrások szemantikai leírói

Életciklus                 Erőforrások életciklusával kapcsolatos tulajdonságok

Meta-metaadat        Magának a leírásnak a tulajdonságai

Technikai                 Az erőforrások technikai tulajdonságai

Oktatási                  Oktatási és pedagógiai tulajdonságok

Jogok                      A használat feltételeivel kapcsolatos tulajdonságok

Kapcsolatok            Az erőforrások olyan tulajdonságai, melyek összekapcsolják más erőforrásokkal

Megjegyzések         Megjegyzések a szolgáltatások oktatási használatával kapcsolatban

Osztályozás             Az erőforrások osztályozásában leírt tulajdonságok

                                  

                                               1. táblázat: A LOM kategóriái

A LOM az oktatási erőforrásokat leíró metaadatok szintaxisát és szemantikáját is specifikálja, azaz definiálja azokat az attribútumokat, melyek az erőforrások pontos leírásához szükségesek. Az attribútumoknak azt a minimális halmazát definiálja, mely elég az erőforrások menedzseléséhez. Az erőforrások legfontosabb attribútumai a típus, a szerző, a tulajdonos, a felhasználási mód, illetve a formátum. Amennyiben szükséges, a metaadat tartalmazhat pedagógiai attribútumokat is, mint a szükséges képzettségi fok, nehézségi szint vagy a szükséges előismeretek.

2002. június 12-én a LOM az IEEE által elfogadott szabvánnyá vált (IEEE-SA standard 1484.12.1). A LOM szabványt nemzetközileg jól fogadták és adoptálták, bár ez a folyamat még a kezdeti szakaszában van.

 

3. A szolgáltatás-felfedezés és az SLP

 

Ha egy hálózati szolgáltatást szeretnénk használni, tudnunk kell annak hálózati címét, vagyis egy elektronikus magazin címét be kell gépelnünk ahhoz, hogy elolvashassuk. Minél több szolgáltatást szeretnénk használni, annál több címre kell emlékeznünk. Mitöbb előfordulhat, hogy egy szolgáltatás megszűnik és egy értelmetlen hibaüzenetet kapunk. Szükségünk van egy hálózati protokollra, mely kielégíti a következő kritériumokat:

A megoldást a szolgáltatás-felfedező protokollok szolgáltatják. A szolgáltatás-felfedezés azt jelenti, hogy a szolgáltatások "reklámozzák" magukat a hálózaton. A "reklám" a szolgáltatás típusát, tulajdonságait és elérési módját (pl. IP cím, elérési protokoll) tartalmazza. A kliens (pl. szövegszerkesztő) típusa (pl. nyomtató) alapján találja meg a kívánt szolgáltatást. Ha egy bizonyos típusú szolgáltatásnak számos képviselője található (pl. lézer és tintasugaras nyomtató), akkor a felhasználó a számára legmegfelelőbb tulajdonságút választhatja közülük.

Amikor felmerült az igény a szolgáltatás-felfedezésre, számos vállalat és konzorcium kezdte el kutatni a területet, az IETF pedig külön munkacsoportot hozott létre erre a célra. A legtöbb szolgáltatás-felfedező protokoll fejlesztése még most is tart. A legismertebbek a következők:

ˇ        Az IETF által kifejlesztett Service Location Protocol (SLP)

ˇ        A Jini, mely a Sun Java-alapú protokollja

ˇ        A Salutation

ˇ        A Microsoft Universal Plug and Play (UPnP) nevű protokollja

Ezek összehasonlítása megtalálható [7]. Amiért mi az SLP mellett döntöttünk:

A következőkben vizsgáljuk meg az SLP felépítését! Az SLP-t azért érdemes tanulmányozni, mert gyakorlatilag az összes szolgáltatás-felfedező protokoll mintájául szolgált.

 

3.1 Az SLP architektúrája

 

Az SLP architektúrának három fő eleme van:

ˇ        User Agent (UA): A felhasználó gépén futó folyamat, mely lehetővé teszi a felhasználói alkalmazás és a rendszer közötti kommunikációt. Ha valakinek szüksége van egy szolgáltatásra, akkor megadja az alkalmazásnak, hogy milyen típusú szolgáltatást szeretne, az alkalmazás pedig az UA-hoz fordul a kéréssel. Válasz esetén az UA értesíti az alkalmazást az elérhető szolgáltatásokról. Az UA hasonló szerepet játszik az SLP-ben, mint a resolver a DNS-ben.

ˇ        Service Agent (SA): Minden hálózati szolgáltatáshoz tartozik egy ilyen folyamat, feladata a szolgáltatás hirdetése. A hirdetésnek többek között tartalmaznia kell a szolgáltatás típusát és tulajdonságait. A szolgáltatás jellemzőit, ugyanúgy, mint az LDAP-ben, attribútumoknak nevezzük.

ˇ        Directory Agent (DA): Olyan folyamat, mely egyrészt fogadja az SA-k által küldött szolgáltatás-hirdetéseket, és bejegyzi azokat egy adatbázisba, másrészt feldolgozza az UA-k által küldött kéréseket, és válaszol rájuk. A rendszerben lehet több DA is, ezért ez az elem biztosítja a protokoll skálázhatóságát. Kisméretű hálózatok esetén az is előfordulhat, hogy egyáltalán nincs DA, ekkor az UA rögtön az SA-khoz fordul kérésével. Ha nagyon sok szolgáltatás van egy hálózaton, akkor meg lehet osztani a terhelést több DA között. Mivel a szolgáltatáskeresés gyakoribb művelet, mint a szolgáltatásbejegyzés, vagyis gyakrabban kell az adatbázist olvasni, mint módosítani, ezért a DA könyvtár-alapú adatbázist használ, melyet az LDAP segítségével valósít meg.

Felhasználó
 
A fenti elemek közötti kapcsolatokat a következő ábrán láthatjuk:

Alkalmazás
 

Szolgáltatás
 

Service Agent
 

User Agent
 

Directory Agent
 

LDAP
 

           1. ábra: Az SLP felépítése

 

3.2 A szolgáltatás leírása SLP-ben

 

A szolgáltatás-leírás [8] a szolgáltatás legfontosabb tulajdonságait tartalmazza: az egyedi azonosítóját, a típusát és a szolgáltatás attribútumait. A szolgáltatás azonosítóját Service URL-nek hívják. Ez egy speciális URL a következő szintaxissal:

"service:" service_type ":"

network address/path

A szolgáltatás típusa lehet absztrakt vagy konkrét. Az absztrakt típus osztályozza a szolgáltatást, míg a konkrét típus meghatározza az elérési protokollt. Például az "eszközmeghajtó" absztrakt típus lehet. Ez eszközmeghajtókat nyújtó szolgáltatásokat azonosít. Ennek a szolgáltatásnak a használatához ezt ki kell egészítenünk az elérési protokollal, így egy konkrét típust kapunk. A konkrét típus mindig egy absztrakt típusból származik.

Az absztrakt típus az objektum-orientált technológia absztrakt osztályával állítható párhuzamba, a konkrét típus egy ebből származtatott osztálynak, míg a Service URL egy osztály megvalósulásának, azaz egy objektumnak felel meg.

 

 

a. service:device-driver://ftp.bean.org/drivers/

 

b. service:device-driver:ftp://ftp.driver.org/vol3/scsi.tgz

 

c. service:device-driver:ftp://ftp.driver.org/vol3/scsi.tgz
     ;driver=scsi;os=linux

 

 

II. táblázat: Példák Service URL-re

A II.a táblázatban szereplő Service URL az "eszközvezérlő" szolgáltatás egy példányát specifikálja. Egy ebből származtatott konkrét szolgáltatás példányát (egy letölthető eszközvezérlőt) tartalmazza a II.b táblázat, mely közvetlenül elérhető. Amint látható, a konkrét szolgáltatás típus az absztrakt típusból és az azt követő ":" után írt elérési protokollból áll elő.

3.3 Az SLP attribútumai

 

Folytatva az előző példát, képzeljük el, hogy az "eszközvezérlő" szolgáltatásnak két attribútuma van:

ˇ        driver az eszköz típusát jelenti

ˇ        os pedig az operációs rendszert azonosítja

A II.c táblázatban szereplő Service URL egy Linux alatti SCSI eszköz meghajtóját specifikálja. Ez a szolgáltatásról minden információt tartalmaz és ez az információ szabványos úton (egy URL-ben) van tárolva. Az SA ezt az URL-t beregisztrálja a DA-nál, ami ezt küldi válaszként az UA szolgáltatás kérésére.

 

3.4 Template SLP esetén

 

A protokoll elemei és a felhasználók kell, hogy ismerjék minden szolgáltatás-típus lehetséges attribútumait. Ez az információ a template-ekben van tárolva. A template egy egyszerű szöveges file, mely mind az ember, mind a számítógép számára érthető.

A template első sora a szolgáltatás típusát tartalmazza, a további sorok az attribútumait definiálják. Például az eszközmeghajtó konkrét szolgáltatás-típus egy lehetséges template-jét mutatja be a III. táblázat.

 

template-type=service:device-drivers:ftp

driver= string

os= string

 

 

III. táblázat: Az eszközmeghajtó konkrét típus template-je

Ha egy attribútum egy absztrakt szolgáltatás-típusban szerepel, akkor annak az ebből a típusból származtatott minden egyes konkrét típusban is szerepelnie kell.

A template egy szolgáltatás interface-eként is felfogható.

3.5 Az SLP üzenetei

 

Az SLP-ben a következő üzeneteket definiálták:

ˇ        Service Request: Az UA küldi ezt az üzenetet, ha információt szeretne kapni valamilyen szolgáltatásról. Az üzenet paramétereként meg kell adnia a szolgáltatás típusát.

ˇ        Service Reply: Az UA kapja a DA-tól vagy az SA-tól, tartalmazza a keresett szolgáltatások adatait.

ˇ        Service Registration: Amikor egy új szolgáltatás elérhető lesz, akkor a hozzá tartozó SA küldi ezt az üzenetet a DA-nak. Hatására a DA bejegyzi a szolgáltatást.

ˇ        Service Deregistration: Az SA küldi a DA-nak, ha megszűnik az általa képviselt szolgáltatás. A DA-nak ilyenkor törölnie kell a szolgáltatást az adatbázisából.

ˇ        Service Acknowledge: A DA küldi az SA-nak egy sikeres szolgáltatásbejegyzés vagy -törlés után.

ˇ        Attribute Request: Az UA ezzel az üzenettel lekérdezheti egy adott szolgáltatás attribútumait, vagy egy szolgáltatástípushoz tartozó összes attribútumot.

ˇ        Attribute Reply: Válasz az előbbi üzenetre.

ˇ        DA Advertisement: A DA küldi periodikusan az UA-nak és az SA-nak, hogy tudomást szerezzenek róla.

ˇ        Service Type Request: A hálózaton elérhető összes szolgáltatástípust tudja lekérdezni az UA ezzel az üzenettel.

ˇ        Service Type Reply: Válasz az előbbi kérésre.

 

Az SLP architektúrája, valamint komponensei közti üzenetváltás látható a 2. ábrán.

 

2. ábra: Az SLP üzenetcseréi

 

 

3.6 Felfedezés az SLP-ben

 

A legalapvetőbb művelet az SLP-ben az, amikor egy felhasználó információt szeretne kapni valamilyen hálózati szolgáltatásról. Kisebb méretű implementációkban minden szolgáltatás SA-ja külön-külön válaszol az UA kérésére. Nagyobb hálózatok esetén a szolgáltatások bejegyzik magukat egy vagy több DA adatbázisába, és az UA-nak a DA-hoz kell fordulnia, ha meg szeretne találni egy szolgáltatást.

Az UA kétféleképpen kezdheti el a szolgáltatáskeresést:

ˇ        Ha van a hálózaton DA, akkor elküld neki egy Service Request üzenetet, és paraméterként megadja a szolgáltatás típusát. Ekkor a DA kikeresi az adatbázisából az adott típushoz tartozó szolgáltatások adatait, és elküldi azokat az UA-nak.

ˇ        Ha egyetlen DA sincs a hálózaton, akkor multicast-tal kell elküldenie a kérést, vagy ha ez nem lehetséges, akkor broadcast-tal.

 

A broadcast és a multicast üzenetszóró szolgáltatás. A broadcast-tal egy lokális hálózaton minden gépnek elküldhetjük ugyanazt az adatcsomagot, függetlenül attól, hogy szüksége van-e rá, vagy sem. A multicast viszont lehetővé teszi, hogy csak azok a hosztok kapják meg az adatcsomagot, melyeknek szükségük van rá.

Tegyük fel, hogy az Interneten van négy számítógép, melyek rendelkeznek IP-címmel, és mind a négynek el szeretnénk küldeni egy adatcsomagot. Megtehetjük azt is, hogy külön-külön elküldjük mind a négy címre az üzenetet, de ez nem jó megoldás, mert mi van akkor, ha ötven címre szeretnénk elküldeni?

Erre a problémára a multicast ad megoldást. Segítségével csoportokat tudunk létrehozni, és megadhatjuk, hogy egy csoportba mely hosztok tartozzanak. Minden csoportnak lesz egy IP-címe, és ha erre a címre küldünk egy adatcsomagot, akkor azt a csoportba tartozó összes hoszt meg fogja kapni.

Egy hoszt több csoportnak is tagja lehet. Egy csoport címére általában azok is küldhetnek adatot, akik nem tagjai a csoportnak. Nem minden esetben van szükség új csoport létrehozására, mert vannak állandó csoportok is, melyeknek címe előre adott. A multicast címek D osztályúak, tehát első négy bitjük 1-es. Ez azt jelenti, hogy a multicast címtartomány a 224.0.0.0 és a 239.255.255.255 címek közé esik. A multicast elvileg nem korlátozódik a lokális hálózatra, egy csoport tagjai az Interneten bárhol elhelyezkedhetnek. A gyakorlatban ez nem így van, mert ehhez az kellene, hogy az Internet összes routere ismerje a multicast címzést.

Tehát ha nincs a hálózaton DA, akkor az UA multicast-tal küldi el a kérést. Az SLP-ben definiáltak 1024 darab állandó multicast címet. Ezeket szolgáltatás-specifikus multicast címeknek nevezzük. A szolgáltatástípus neve alapján egy hash függvény segítségével minden szolgáltatástípushoz hozzá lehet rendelni egy specifikus címet. Az alkalmazás megadja az UA-nak a szolgáltatás típusát, az UA pedig ebből a típusból a hash függvénnyel meghatároz egy multicast címet. Ez a cím lesz a szolgáltatás-specifikus multicast cím, és az UA-nak erre a címre kell elküldeni a kérést. Természetesen a helyes válasznak az az előfeltétele, hogy az SA-k csatlakozzanak a saját szolgáltatásukhoz tartozó multicast csoporthoz, és figyeljék az oda érkező üzeneteket. Ha valamelyik SA rendelkezik a kért szolgáltatással, akkor válaszol az UA-nak.

Ha a hálózaton már van DA, akkor az UA-nak az összes kérést hozzá kell küldenie. És az SA-nak is kötelező regisztrálnia magát legalább egy DA adatbázisába. Ekkor viszont felmerül az a kérdés, hogy a kliensek honnan tudják meg a DA címét? A következő megoldásokat lehet alkalmazni:

ˇ        Ha a hálózaton sem broadcast-ra, sem multicast-ra nincs lehetőség, akkor a klienseknek előre meg kell adni a DA-k címét. Ez a statikus konfiguráció.

ˇ        Van egy olyan multicast csoport (Directory Agent Discovery Group), melyhez minden DA-nak csatlakoznia kell. Ennek a csoportnak az IP-címe 224.0.1.35. Ha egy kliens egy Service Request üzenetet küld erre a címre, és a szolgáltatás típusaként "directory-agent"-et ad meg, akkor minden DA visszaküld a kliensnek egy DA Advertisement üzenetet. A kliens ebből tudja meg a hálózaton lévő DA-k címét.

ˇ        Létezik egy másik multicast csoport (Service Location General Group), melyhez minden UA-nak és SA-nak csatlakoznia kell. Ennek a csoportnak az IP-címe 224.0.1.22. Amikor egy DA elindul, DA Advertisement üzenetet kell küldenie erre a címre. Ezután a DA-nak bizonyos időközönként meg kell ismételnie ezt az üzenetet. Így azok a kliensek is tudomást szereznek a DA-ról, melyek később csatlakoztak a hálózathoz.

Mielőtt egy szolgáltatás megszűnik, törölni kell a DA adatbázisából. Ezt az SA teszi meg úgy, hogy elküld a DA-nak egy Service Deregistration üzenetet. A DA akkor is törölhet egy szolgáltatás-bejegyzést, ha nem érkezett erre vonatkozó kérés, mivel minden bejegyzéshez tartozik egy ún. élettartam, melyet az SA ad meg. Ha az SA bejegyez a DA-nál egy szolgáltatást, és letelik az élettartamban meghatározott idő, akkor a DA törli a bejegyzést, kivéve ha az SA időközben megújítja azt.

 

4. Az Elektronikus Oktatási Rendszer (EES) modell

 

Az első elektronikus tanulási rendszerek majdnem kizárólag a tanulási folyamat menedzselésére és mérésére koncentráltak, anélkül, hogy ehhez bármilyen értéket adtak volna. Ezek voltak az első generációs "Tanulási Menedzsment Rendszerek" ("Learning Management Systems" - LMS). Ezek képesek voltak megjeleníteni bármilyen oktatási erőforrást, de azok szervezése és újrafelhasználása nem volt megoldott. Ismail [9] alapján a következő generációs rendszereknek képesnek kell lenniük az újrafelhasználható, kereshető és platform-független oktatási objektumok menedzselésére.

Cloete [10] egy olyan elektronikus oktatási modellt javasolt, mely alkalmas lenne a második generációs eLearning rendszerek megvalósítására. Javaslata, az Electronic Education System Model (EES) e-tanulási rendszereket tervező szakemberek számára nyújt segítséget egy specifikus tanulási szituáció megtervezése és implementálása során. Modellje négy rétegből áll, a rétegek pedig objektumokra vannak bontva. Minden réteg jól meghatározott feladatot hajt végre, és egy réteg az alatta lévő réteg szolgáltatásait használhatja. Az objektumok egy-egy szolgáltatás biztosításáért felelősek, ezért szolgáltatás-objektumoknak is hívják őket.

A következő ábrán az EES részei láthatóak:

3. ábra: Az EES modell

 

A rétegek funkciója a következő:

 

5. Munkánk: A kiterjesztett EES

 

Amint látjuk, a legfelső rétegben oktatási szolgáltatások vannak. Tudjuk, hogy lokális hálózatokban gyakran okoz problémát a megfelelő szolgáltatás megtalálása. Erre a problémára fejlesztették ki a szolgáltatás-felfedező protokollokat, melyek előzetes konfiguráció nélkül lehetővé teszik a hálózati szolgáltatások felfedezését egy lokális hálózaton.

Rögtön adódik tehát a gondolat: illesszük be a szolgáltatás-felfedezést az EES modellbe, megkönnyítve ezzel a különböző oktatási szolgáltatások megtalálását. Ehhez először is szétbontottuk a 4. réteget két alrétegre: a komplex szolgáltatásokra és a szolgáltatásokra (4. ábra). Erre azért van szükség, hogy modellezni tudjuk azokat az eseteket, amikor egy szolgáltatás több rész-szolgáltatásból tevődik össze. Ezután a réteg aljára harmadik alrétegként beillesztettük a felfedezést, mely a szolgáltatások és ezeken keresztül a komplex szolgáltatások számára biztosítaná a felfedezhetőséget. Ezután a szolgáltatásokat dinamikusan lehetne módosítani, a felfedezés alréteg nyomon követné a változásokat, és jelezné a felhasználók számára:

4. ábra: A kiterjesztett EES modell

 

Ha az oktatási szolgáltatásokat az LOM segítségével jellemeznénk, és a jellemzést beillesztenénk az EES felfedezés alrétegébe, akkor egy olyan elektronikus oktatási rendszert kapnánk, melyben egy oktatási intézmény minden résztvevője egyszerűen megtalálná a számára fontos információt. Ez az információ szinte bármi lehet, a tananyagtól a terembeosztásokig. Mivel a szolgáltatás-felfedezés lényege az, hogy a felhasználó előzetes konfiguráció nélkül megtalálja az őt érdeklő erőforrásokat, ebből következően egy felfedezőklienst elindítva azonnal használni lehetne a rendszert.

Ezért az SLP-t alkalmassá kell tennünk a LOM kategóriák kezelésére. Először is létrehozunk egy absztrakt szolgáltatás-típust az oktatási szolgáltatásoknak. Ezt mi "edu.ve"-ként jelöljük, ahol "edu" az "education", a "ve" pedig a Veszprémi Egyetem rövidítése. Ezen szolgáltatás-típus attribútumai megegyeznek a LOM-ban definiáltakkal. Nevük is azonos a LOM-beliekkel, kivéve, hogy SLP-ben az attribútumok neveit kisbetűvel írjuk és szóköz helyett alulvonást használunk. Így például "Interactivity level" helyett "interactivity_level"-t írunk. Az attribútumok az "edu" szolgáltatás template-jében vannak specifikálva.

 

service:edu.ve:http://instructor.irt.vein.hu/gsm.pdf;

interactivity_type=expositive;

learning_resource_type=slide;

interactivity_level=very low;

semantic_density=high;

intended_end_user_role=learner;

context=higher education;

typical_age_range=18-;

difficulty=medium;

typical_learning_time=2h;

language=hu

 

IV. táblázat: egy oktatási URL része

A konkrét szolgáltatás-típus az absztrakt típus leszármazottja. Az összes ott definiált attribútumot tartalmazza, valamint definiálja a szolgáltatás elérési protokollját. Egy Service URL (más néven "reklám") része a IV. táblázatban látható. Ez csak a szolgáltatás oktatás-specifikus attribútumait tartalmazza, mely szolgáltatás esetünkben egy slide-gyűjtemény. Az URL önleíró, minimális magyarázattal megérthető.

Ezzel a LOM szabványt beillesztettük a szolgáltatás-felfedezés környezetébe, ami a kiterjesztett EES modell része. Ez a három különböző technológia előnyeinek egyesítését és eddig nem megvalósítható új vonások megszületését jelenti:

ˇ        Könnyű használat: Mivel a szolgáltatás-felfedezés lényege a felhasználó adminisztrációs tevékenységektől való mentesítése, ezért modellünk a "felhasználóbarát" fogalom új jelentését vezeti be: ha valaki használni akarja a rendszert, csak futtatnia kell a szoftvert, minden más a rendszer feladata. Semmi konfiguráció, semmi frusztráció, semmi időveszteség.

ˇ        Személyre szabás: Mindenki különböző, így mindenkinek más az érdeklődési köre. Az alapos erőforrás-leírás segítségével mindenki könnyedén megtalálhatja az érdeklődésének megfelelő témát.

ˇ        Kommunikáció: A hagyományos elektronikus oktatási rendszerek a kommunikációs lehetőségek hiányától küszködtek, bár a kommunikáció elkerülhetetlen a hallgatói visszajelzések esetén, továbbá ez a kiértékelés alapja. Az általunk készített modell megkönnyíti a kommunikációt, pl. a tanár e-mail címének felfedezésével.

Vizsgáljuk meg, hogyan elégíti ki modellünk a második generációs oktatási rendszerek kritériumait!

ˇ        Újrafelhasználhatóság: Ezt az alap és összetett szolgáltatások külön rétegeinek megalkotásával értük el. Ez azt jelenti, hogy egyszerű objektumok létrehozása után előállíthatunk belőlük sokoldalú, összetett objektumokat is. Akkor használhatjuk fel ezeket az egyszerű objektumokat, amikor csak szükségünk van rájuk.

ˇ        Kereshetőség: Ezt a tulajdonságot a szolgáltatás-felfedezés nyújtja, mitöbb a "felfedezhetőség" kifejezést használhatjuk esetünkben.

ˇ        Platform-függetlenség: Célunk Java nyelven elkészíteni rendszerünket és az oktatási objektumokat. Még az objektum leírások is platform-függetlenek, mivel egyszerű szöveges file-ban vannak tárolva.

 

6. Összefoglalás

 

Munkánk egy elméleti modell, célunk elkészíteni a követelményelemzést, az implementációt és az újrafelhasználhatósági mintákat egy elektronikus oktatási rendszer esetében erre a modellre alapozva, továbbá a rendszer alkalmazása és működtetése a tanszékünkön lévő telekommunikációs csoportunkban. Számos feladat van még a cél eléréséig, például jelenleg nincs publikus szolgáltatás-böngésző (User Agent az 1. ábrán) SLP-hez. Már kifejlesztettünk egy ilyen szoftvert C nyelven, de ezt Java-ba kell átültetnünk a platform-függetlenség biztosításához. A tananyag fejlesztés szintén egy fontos feladat. Végül, de nem utolsósorban a teljes rendszert be kell vezetnünk az oktatásba.

Elektronikus oktatási rendszer modellünk a hagyományos oktatási rendszer minden tagjának nyújt előnyöket. A hallgatók számára a haladásuknak megfelelő tananyagot biztosít személyre szabott ellenőrzéssel. Az információ dinamikus szolgáltatásként érhető el. Az automatikus ellenőrzés mellett a rendszer lehetőséget nyújt a tanárral vagy más hallgatókkal való kapcsolatfelvételre mintegy e-konzultáció keretében. Ezáltal gyors, kétirányú információcserét biztosít a hallgatók és a tanár közt a modern telekommunikációs technológiák felhasználásával.

Megoldja a tananyag-menedzsmentet könnyítve a tanár feladatát, és segít a hallgatók felkészültségének ellenőrzésében. Rugalmasságának köszönhetően alkalmas a létező rendszerek integrálására és megkönnyíti új szolgáltatások alkalmazását. A rendszer hordozható formában kínálja fel az információt, mivel figyelmet fordítottunk az elektronikus oktatás szabványosítására a kutatás során.

Az oktatási intézmények hallgatókért való harcában a rugalmas, személyre szabott képzésnek, a dinamikus tananyagnak és a speciális kurzusoknak nagy szerepük van. További jelentős feladat hárul azokra a módszerekre, melyek az eddig elérhetetlen tanulócsoportokat célozzák meg. Minél inkább személyre szabott egy kurzus, illetve minél több segítséget kap a tanuló, miközben hatékonyan és a lehető leggyorsabban tanul, annál valószínűbb, hogy a tanulóidejére az adott intézményt választja.

 

7. Köszönetnyilvánítás

 

Kutatómunkánkat az Oktatási Minisztérium támogatta (IKTA5-128/2002).

 

8. Irodalomjegyzék

 

[1] M. J. Rosenberg: E-Learning: strategies for delivering knowledge in the digital age. New York: McGraw-Hill Companies, Inc., 2001

 

[2] T. Vold: "Whatever, whenever, wherever"-learning. Proceedings: 3rd International Conference on Information Technology Based Higher Education and Training (ITHET 2002), Budapest, 2002. július

 

[3] Kellog, D. W. Viehland, Education and the Internet, Computers and Education, Vol. 30., No. 1-2.

 

[4] http://www.cordis.lu/

 

[5] Komenczi Bertalan: Elektronikus Európa - Az Európai Unió akcióterve 2002-ig (Új Pedagógiai Szemle, 2000. 09.), http://www.oki.hu/

 

[6] http://ltsc.ieee.org

 

[7] C. Betstetter and C. Renner (2000), "A Comparison of Service Discovery Protocols and Implementation of the Service Location Protocol," http://www.lkn.e-technik.tu-muenchen.de/lkn/mitarbeiter/chris/publica-tions/eunice2000-slp.html

 

[8] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Service: Schemes", RFC2609, Jun. 1999.

 

[9] J. Ismail, "The design of an e-learning system", Internet and Higher Education, 4 (2002), pp. 329-336.

 

[10] E. Cloete: Electronic education system model, Computers & Education, 36 (2001), 171-182


[1] Az előadás hátteréül szolgáló kutatás az IKTA5 keretein belül folyik