NYOMTATOTT TESZTEK ÉS KÉRDŐÍVEK FELDOLGOZÁSÁT SEGÍTŐ SZAKTERÜLET-

Informatika a felsőoktatásban 2011 konferencia Debrecen, 2011. augusztus 24-26. _____________________________________________________________________________________________________

NYOMTATOTT TESZTEK ÉS KÉRDŐÍVEK FELDOLGOZÁSÁT SEGÍTŐ SZAKTERÜLETSPECIFIKUS NYELV

USING DOMAIN-SPECIFIC LANGUAGE FOR PRINTED TEST AND SURVEY PROCESSING Balla Tibor1, Dr. Fazekas Gábor2 Összefoglaló: Az elektronikusan kitölthető tesztek és kérdőívek egyre nagyobb népszerűsége ellenére, még mindig léteznek olyan területek, ahol nehézségbe ütközhet az ilyen tesztek alkalmazása, és az információ gyűjtése hagyományosan papír alapon történik. A nagytömegű papír alapon kitöltött teszt gyors feldolgozására és kiértékelésére használt ipari megoldásokkal, szoftver- és hardverrendszerekkel szemben az OMRL (Optical Mark Recognition Language) egy olyan szakterület-specifikus nyelv, mely segítségével egyszerű terminológiával adhatók meg a digitalizált tesztek és kérdőívek feldolgozásának lépései. Megadható a digitalizált tartalmak feldolgozásához szükséges területek elhelyezkedése. A feldolgozás alatt álló teszt és kérdéseinek validitása egyszerű szabályokkal vizsgálható. A feldolgozást követően az eredmények tényleges kiértékelése és vizualizációja is lehetséges, de az eredményeket elérhetővé tehetjük más (statisztikai) alkalmazások számára is, további feldolgozás céljából. A nyelv kiegészítései segítségével, képes a nyomtatott tesztek és kérdőívek létrehozásához használt legelfogadottabb XML alapú megoldásokkal is együttműködni, tovább egyszerűsítve a feldolgozást. Kulcsszavak: OMR, szakterület-specifikus nyelv, teszt, kérdőív Abstract: Even though online tests gain an ever increasing popularity in most fields of teaching, there are still some cases, where huge difficulties arise and only the traditional paper based data collecting methods can be used. In contrary to the wide-spread software-, or hardware-based methods used to bulk process and evaluate heavy masses of paper-based tests, OMRL (Optical Mark Recognition Language) is a domain-specific language which enables users to set the steps of processing of digitalized tests in a very convenient way. The location of domains needed to process the digitalized content can be set. Validation of questions contained by the test being processed can be examined via simple rules. After the processing, evaluation and visualization of the results is possible. Moreover, one can save the data for other (statistical) applications as well in order to be processed later. To simplify the processing further, through its packages, our language can cooperate with the mostly accepted XML-based methods used to create paper-based tests. Keywords: OMR, domain-specific language, test, survey

1. Motiváció A papír alapú tesztek hatékony feldolgozása még napjainkban is kurrens kérdésnek számít. Az elektronikusan kitölthető tesztek és kérdőívek számos területen egyeduralkodóvá váltak, ám még mindig vannak területek ahol a hatékony adatgyűjtés érdekében az információk megszerzése papír alapon történik. Az iskolai számonkérések, a szociológiai kérdőívek és pszichológiai tesztek esetében sokszor nem lehet megoldani a nagytömegű elektronikus tesztfelvételt. Ilyen esetekben a kitöltő személyek elé sokkal egyszerűbb egy papírlapot letenni. A probléma megoldására több kereskedelmi forgalomban kapható szoftver- és hardverrendszer elérhető, ám ezek a legtöbb esetben igen drágák. Ezek az eszközök sok esetben kiegészülnek saját tesztszerkesztő eszközzel, és vitathatatlanul hatékonyak a saját tesztjeik elsődleges kiértékelésében. Az elsődleges kiértékelés alatt azt a folyamatot értjük, amikor eldől, hogy az egyes kérdések esetében mely válasz vagy válaszok lettek bejelölve. A másodlagos kiértékelés az folyamat, mely során az elsődleges kiértékelés eredményeihez hozzárendelünk egy értéket, mely már a teljes tesztet, vagy a 1

Debreceni Egyetem, Informatikai Kar, Információ Technológia Tanszék email cím: [email protected] 2 Debreceni Egyetem, Informatikai Kar, Információ Technológia Tanszék email cím: [email protected]

167


teszt egy részét minősíti. (Egy iskolai számonkérés másodlagos kiértékelése az érdemjegy meghatározása.) A kereskedelmi forgalomban kapható szoftverek sok esetben igen szegényes eszközkészlettel rendelkeznek a másodlagos kiértékeléshez. Egy egyszerűbb számonkérésre adott osztályzat meghatározása még lehetséges, de egy összetettebb, több alskálás, inverz elemeket is tartalmazó pszichológiai teszt kiértékelése már nem. A másodlagos kiértékelések során használható szabályok nagyon sokszínűek és bonyolultak lehetnek. Egy elem értéke függhet attól, hogy mely alskálában szerepel, de akár egy vagy több korábbi kérdésre adott válasz is befolyásolhatja annak értékét. Az ilyen szabályok megadásának a leghatékonyabb eszköze egy erre a célra létrehozott szakterület-specifikus nyelv, amely szemantikájával a lehető legegyszerűbb módon közelít a problémához (Spinellis 2001). A célunk egy olyan beágyazott szakterület-specifikus nyelv megalkotása volt, mely mind az elsődleges kiértékelésben, mind a másodlagos kiértékelésben hatékony segítség lehet. Egy olyan eszköz létrehozása, mely segítségével egy programozásban teljesen járatlan felhasználó is könnyedén megfogalmazhatja a kiértékelésre és validitásra vonatkozó feltételeket.

2. Szakterület-specifikus nyelvek A szakterület-specifikus nyelvek olyan programozási nyelvek, melyek speciális problémákra koncentrálnak, szemben az általános célú programozási nyelvekkel, melyek bármely probléma megoldásában segítségünkre lehetek. A szakterület-specifikus nyelvek korántsem mondhatóak fiatalnak. Már korán felismerték, hogy egy probléma köré épített, a probléma egészét, és csak a problémát lefedő nyelvvel jelentősen növelhető a hatékonyság (Günther 2009). Szakterület-specifikus nyelvek közé sorolható a VeriLog, vagy a VHDL hardverleíró nyelvek, az R statisztikai nyelv, az SQL relációs adatbázisok kezelését segítő nyelv, de ide sorolható a - lexikai elemzéseket megkönnyítő - reguláris kifejezések nyelve is. A szakterület specifikus nyelveket két csoportra bonthatjuk: külső nyelvekre és belső nyelvekre. A belső szakterület-specifikus nyelveket gyakran beágyazott nyelveknek is hívják, a külső szakterület-specifikus nyelveket pedig önálló nyelveknek nevezzük. (Fowler 2010) A külső nyelvek azok a nyelvek, melyek minden más nyelvtől függetlenek. Egy külső nyelv implementálását mindig az alapoktól kell kezdeni. Nekünk kell megalkotni a nyelv szintaxisát, és szemantikáját. Egy ilyen nyelv fejlesztése technikailag nem különbözik egy általános célú programozási nyelv fejlesztésétől, ám a modellezési folyamat jelentősen eltér. Léteznek eszközök, melyek megkönnyítik ezen nyelvek létrehozását ilyen a Lex, Yacc, ANTLR, GOLD Parser vagy a Coco/R. (Spinellis 2001) A belső szakterület-specifikus nyelvek azok a nyelvek, melyeket egy gazdanyelv eszközeivel implementálunk (Ghros 2011). Nyilvánvalóan a beágyazott nyelvek kifejezőképességét és lehetőségeit nagyban behatárolja a gazdanyelv. Ezt az áldozatot kell meghoznunk azért a kényelemért, melyet a gazdanyelv által szolgáltatott implementációt könnyítő eszközök biztosítanak. Az olyan statikus, merev szintaktikájú nyelvek, mint a C++ vagy a Java nem alkalmasak arra, hogy bennük szakterületspecifikus nyelveket hozzunk létre. Azok a nyelvek, melyek szintaktikailag megengedőbbek, sokkal alkalmasabbak, mert az ezekben létrehozott nyelvek kevésbé viselik magukon a gazdanyelv vonásait. Napjainkban a dinamikus, erős metaprogramozási eszközökkel ellátott programozási nyelvek a legnépszerűbbek a beágyazott nyelvek létrehozásához. A dinamikus nyelvek, mint a JavaScript, a Python, vagy éppen a Ruby a típusok ellenőrzését nem hajtják végre fordítási időben. A dinamikus nyelvek, a kódszintézist állítják szembe a - statikus programozási nyelveknél használt - kódgenerálással. A kódszintézis nem más, mint a programkód memóriába történő előállítása futási időben. A dinamikus nyelvek esetében ez a fajta szintézis nagyon egyszerűen megvalósítható. A dinamizmus megfelelő használatával sokkal produktívabbá válhat a fejlesztés. Ez kiegészülve az ezek által a nyelvek által kínált fejlett metaprogramozási eszközökkel teszi igazán alkalmassá ezeket a nyelveket arra, hogy bennük szakterület-specifikus nyelveket hozzunk létre. (Subramaniam 2008)

168


2.1.

Groovy programozási nyelv

A Groovy programozási nyelv egy fiatal objektum-orientált dinamikus programozási nyelv, mely Java virtuális gépen fut. A nyelv úgy emel át elemeket a Smalltalk, Python, Perl vagy éppen a Ruby világából, hogy közben a lehető legnagyobb mértékben próbálja megőrizni a megszokott Java szintakszist (König 2007). Ez a törekvés olyan jól sikerült, hogy a legtöbb esetben, ha a Java kódjainkat Groovy kódként fordítjuk, és futtatjuk, az hibátlanul fog működni. A Groovy kód dinamikusan fordul Java bájtkóddá és együtt tud működni a már lefordított Java kóddal és csomagolt Java programkönyvtárakkal is. Szigorú értelemben a Groovy nem tekinthető a Java nyelv kiterjesztésének, hiszen nem minden Java kódról mondható el, hogy az egyben Groovy kód is, viszont az mindenképpen elmondható, hogy a Groovy számtalan olyan tulajdonsággal és eszközzel bír, amivel a Java nem. Ilyenek a teljesség igénye nélkül:  dinamikus típusolás  closure  operátor túlterhelés  natív szintaktika a listáknál és a tömböknél  reguláris kifejezések natív támogatása  engedékeny szintaktika (pl: zárójelek elhagyhatósága függvényhívásoknál)  polimorf iterációk  sztringekbe ágyazott kifejezések  metaprogramozás Fontos megemlíteni, hogy nem a Groovy az egyetlen olyan Java virtuális gépen futó nyelv, mely a fent említett tulajdonságokkal, vagy azok egy részhalmazával bír. A JRuby, BeanShell, Scheme, Jaskell, Jython, JavaScript és számos más nyelv közül a Groovyt kiemeli és vonzóvá teszi a Java nyelvhez való közelsége (Subramaniam 2008). Ezért választottunk ezt a nyelvet a megvalósításhoz.

3. Nyomtatott tesztek és kérdőívek feldolgozását segítő szakterület-specifikus nyelv 3.1.

Előfeldolgozás

A nyelv működéséhez szükséges előfeldolgozást végző algoritmusok Java programozási nyelven íródtak. Ezen könyvár tartalmazza azon eljárások implementációját, melyek feladata a digitalizált tesztkitöltés egy logikai értéket tartalmazó listára való leképezése. A feldolgozás során az összes olyan területhez, ahová a felhasználó jelölést tehetett hozzárendelődik egy logikai érték, attól függően, hogy az adott területen volt-e jelölés, vagy sem. Ez a folyamat három lépésben történik. Egy teszt feldolgozásának első lépése azon területek meghatározása, melyek tartalmazhatnak jelölést. Erre több lehetőség is van. A területek meghatározása elsődlegesen egy a nyelvhez készített egyszerű XML séma egy példányával történhet. Az XML állomány definiálja az egyes teszt oldalakat, és minden egyes oldalon a jelölést tartalmazó területek koordinátáit, azok szélességét és magasságát. Az XML dokumentum kézzel történő létrehozása még egy rövidebb teszt esetében is nagyon kényelmetlen. A több tíz jelölő négyzet koordinátáinak és méretének megadása rengeteg időt vehet igénybe. Ennek kiküszöbölésére egy nagyon egyszerű megoldás született. A felhasználó egy kitöltetlen teszt digitalizált példányán piros téglalapokkal lefedi azon területeket, melyek jelölést tartalmazhatnak (1. ábra). Ezt megteheti a legegyszerűbb rajzolóprogram segítségével is. Az előfeldolgozás első lépése ezen területek helyének és méretének meghatározása.

169


1. ábra A feldolgozást segítő képek. (A kép szerzői jogi okok miatt nem olvasható.)

A feldolgozás második lépése annak meghatározása, hogy mikor tekintünk egy területet jelöltnek, és mikor nem. Erre két lehetséges módszer van. Az egyik esetben a megadott területről azt feltételezzük, hogy üres. Ilyenkor, ha az üres területen a digitalizálás során keletkezett zajtól szignifikánsan több nem fehér pixel található, akkor az adott területet jelöltnek, ellenkező esetben jelöletlennek tekintjük.

2. ábra Jelölt és jelöletlen terület.

A második esetben az adott terület nem tekintjük üresnek. Ebben az esetben annak eldöntése, hogy az adott területen van-e jelölés egy referencia kép segítségével történik (1. ábra). A feldolgozás során az éppen vizsgált teszt, és a referencia kép egy adott területe kerül összehasonlításra. Egy terültet akkor tekintünk jelöltnek, hogyha az a referencia képhez képest szignifikáns eltérést mutat.

3. ábra Összevetés a referencia képpel.

Az előfeldolgozás utolsó lépése a tényleges tesztfeldolgozás, amely során a megadott területeken a megadott módszerrel eldöntésre kerül, hogy mely ponton történt jelölés, és mely ponton nem. A fent említett folyamatok a felhasználók előtt rejtve maradnak. Az, hogy milyen módon történik a területek meghatározása, és a jelölések vizsgálata attól függ, hogy a felhasználók milyen inputokat adnak meg.

170


3.2.

A nyelv alapjai

A létrehozott nyelv egy beágyazott szakterült-specifikus nyelv, mely állhat önmagában, de akár egy Groovy nyelven írt program részeként is. A tesztek kiértékelését végző kódot az omrl blokkban kell elhelyezni. Egy ilyen blokk minden esetben egy tesztkitöltés feldolgozását végzi. omrl{ … } A feldolgozandó, digitalizált tesztkitöltés megadása az input parancs két lehetséges alakjával történhet. Az input.file parancs után felsorolhatóak a feldolgozandó fájlok, az input.directory parancs után megadható egy könyvtár, és opcionálisan egy reguláris kifejezés. Az input.directory a paraméterként megadott könyvtár összes fájlját feldolgozza. Abban az esetben, ha paraméterként egy reguláris kifejezést is megadtunk, akkor az összes olyan fájlt feldolgozza, melynek nevére illeszkedik az adott kifejezés. Elsődleges kiértékelés A digitalizált tesztkitöltések képfeldolgozását végző, Java nyelven implementált eljárások hívása és paraméterezése néhány egyszerű paranccsal történik. Ezen parancsok teljes mértékben elfedik a felhasználó elől az összetett zajszűrő, vágó, illesztő és pozíciókereső algoritmusokat. Szinte minden automatikusan történik. Természetesen az ilyen szintű automatizmussal bizonyos hibák valószínűsége jelentősen megnő, azonban a digitalizált tartalmakkal szemben támasztott előfeltételek betartásával a felhasználó megakadályozhatja a hibák előfordulását. A felhasználónak figyelnie kell arra, hogy a digitalizálás minden kép esetében (beleértve a referencia képet is) ugyanolyan felbontáson és ugyanolyan színbeállításokkal történjen, valamint törekedni kell arra, hogy a digitalizálás során az elmozdulásból eredő hibák a lehető legkisebbek legyenek. Az előfeldolgozást végző parancsok megadása minden esetben a preprocessing blokkban történik. preprocessing{ … } A pozíciók meghatározása a layout paranccsal történik. Abban az esetben, ha a felhasználó XML állományt ad meg paraméterként, akkor ennek az állománynak az ORML elrendezést leíró XML séma példányának kell lennie. Abban az esetben, ha a layout parancs kép fájlt kap paraméterül, akkor feltételezi, hogy azon homogén vörös négyzetekkel van lefedve a jelöléseket tartalmazó terület. Az előfeldolgozás ezen négyzetek meghatározásával kezdődik. Több oldalas tesztfeldolgozás esetén a képeket megfelelő sorrendben kell paraméterül adni. layout ”sample.xml” layout ”sample1.png”, ”sample2.png”, ”sample3.png” Az előfeldolgozás hatékonyságának növelésére lehetőség van referencia képek megadására, amelyeket a reference paranccsal tehetünk meg. A parancs paraméterül egy kitöltetlen teszt digitalizált lapjait várja. layout ”ref_ sample1.png”, ” ref_sample2.png”, ”ref_ sample3.png”

171


Listák – másodlagos kiértékelés A nyelv alapja a lista adatszerkezet. Szigorú értelemben véve a program írása nem más, mint az elsődleges kiértékelés során előállított logikai értékeket tartalmazó lista speciális feldolgozása. Ezeket az értékeket újabb listákba szervezhetjük, majd ezeket a listákat is újabb és újabb listákba. Első szinten előállnak a kérdések, majd eggyel magasabb szinten az alskálák, melyek fölött újabb skálák és végezetül a legfelső szinten a teljes teszt áll.

4. ábra Listák

Minden lista estében - tartalmazzon az logikai értéket, vagy további listákat - megadhatóak azok a szabályok, melyek alapján meghatározható az adott lista értéke és az adott lista validitása. A lista értékének meghatározása: LIST.value{ … } A lista validitásának meghatározása: LIST.valid{ … } A lista adatszerkezet kiegészül számos olyan metódussal, mely növeli a kezelésének hatékonyságát. Olyan eszközökkel, melyek segítségével a lista bejárása, a részlista képzés, a listán belüli csoportosítás és a keresés jelentősen leegyszerűsíthető. Ilyen például a create.subscale() metódus, mely segítségével skálákat definiálhatunk, vagy a create.group(), amely adott elemszámú részlistákra bontja az eredeti listát. Az adott tulajdonsággal bíró elemek leválogatására a find(), a listák bejárása pedig az each() metódus használható: LIST.each{ … }

172


3.3.

Kiegészítések

A nyelvet tartalmazó csomag előre definiáltan tartalmaz számos - gyakran használt - kérdés és teszt típushoz használható validitást és értéket meghatározó eszközt. Ez még egyszerűbbé teszi a feldolgozást végző programok megírását. A kiegészítések között megtalálható néhány fájlművelet megvalósítása is, mely a különböző eredményű tesztek kiválogatásában, átnevezésében és törlésében segít. Nem szabad elfelejteni, hogy az itt bemutatott nyelv egy beágyazott nyelv, melyben a bemutatott elemeken kívül a gazdanyelv bármely eszköze használható. A tesztek kiértékelését követően a rendelkezésre álló statisztikai csomagok és az eredmények vizualizációját segítő csomagok segítségével, további feladatok is megoldhatóak.

3.4.

Példa

5. ábra Egy kitöltött teszt

A szemléltetéshez használt pszichológiai teszt (5. ábra) első ránézésre nem tűnik bonyolultnak, hiszen mindössze húsz darab Likert-skálás kérdés található benne. (A teljes teszt közlése szerzői jogi okok miatt nem lehetséges.) Valójában a teszt kiértékelése jóval bonyolultabb, mint azt gondolnánk. A teszt három skálát tartalmaz. Az egyes elemek értéke megváltozhat attól függően, hogy melyik skálában szerepelnek. Ezen kérdőív esetében az egyes kérdéseknek megfelelően, négyesével listákba szervezzük az elsődleges kiértékelés során előállított logikai értékeket tartalmazó listát. Megadjuk ezen újonnan létrehozott listák validitását, és értékét. Egy kérdésre adott válasz csak akkor érvényes, ha a kérdést reprezentáló listában pontosan egy igaz érték található, az értékük pedig ennek az igaz értéknek a listabeli pozíciója. Mivel a Likert-skála nagyon gyakori mérőeszköz, rendelkezünk előredefiniált validitást és értéket meghatározó eszközzel. Ezek után alskálákat definiálunk. Alapértelmezetten egy lista akkor érvényes, ha minden eleme érvényes, és az értéke egyenlő az összes elemének az összegével. Az alskálál esetében megfelelő az alapértelmezett validitás és érték. A teljes skála esetében a dolog nem ilyen egyszerű. Az alapértelmezett validitás megfelelő, de az érték meghatározása már bonyolultabb, hiszen ebben a skálában már inverz értékek is vannak.

173


A kiértékelést végző szkript omrl{ input.file aes1265.png result = preprocessing{ layout "sample1.png" reference "ref1.png" }

}

aes = result.create.group(4){ valid{likert.valid} value{likert.value} } ain = aes.create.subscale(3,5,6,10,12,14,15,18) aout = aes.create.subscale(2,7,9,11,13,17,19,20) aes.value{ invert.value {5-x} invert.items(1,3,5,6,8,10,12,14,15,16,18) } println aes + ”;” + ain + ”;” + aout

4. Összefoglalás A bemutatott egyszerű nyelvet a gyakorlatban is megvalósítottuk és működőképessége bizonyítottnak tekinthető. A felhasználás során egy gyakorlottabb felhasználónak a kiértékelést végző szkript megírása alig tartott több ideig, mint egyetlen teszt tényleges kiértékelése. Az előállított szkripttel a digitalizált tesztek nagytömegű feldolgozása sokkal hatékonyabbá vált. A tesztek kiértékelése után az eredmények elektronikus formában állnak a felhasználó rendelkezésére, megkönnyítve ezzel a további feldolgozást. A validitási vizsgálatokon megbukott tesztek automatikus kiválogatásával a felhasználó könnyedén gondoskodhat ezen tesztek eltávolításáról, vagy kézi ellenőrzéséről. A teszt kiértékelését végző szkript valójában független a digitalizált teszt előfeldolgozását végző utasításoktól, így tulajdonképpen előállítunk egy olyan egyszerű programot, mely logikai értékeket tartalmazó listákhoz a kiértékelési szabályok és validitási feltételek szerint rendel értéket. A kiértékelést végző kódrészlet nem feltételezi a digitalizált papíralapú bemenetet, így ezek a programok megfelelő input esetén használhatóak akár elektronikusan kitöltött tesztek kiértékeléséhez is. Irodalomjegyzék Spinellis D. (2001) Notable design patterns for domain-specific languages. The Journal of Systems and Software, 56, 91-99. König D. (2007). Groovy in Action. Manning Publications Co. Subramaniam V. (2008) Programming Groovy: Dynamic Productivity for the Java Developer. The Pragmatic Bookshelf Günther S. (2009) Engineering Domain-Specific Languages with Ruby. 3. Workshop des Centers for Very Large Business Applications,Aachen, 11-21. Fowler M. (2010). Domain-Spacific Languages. Addison-Wesley Ghros D. (2011). DSLs in Action. Manning Publications Co.

174

NYOMTATOTT TESZTEK ÉS KÉRDŐÍVEK FELDOLGOZÁSÁT SEGÍTŐ SZAKTERÜLET-

Recommend Documents