Subsections


4. A jelenleg használt programegyüttes

Az előző fejezet végén áttekintettem, hogy melyek azok a feladatok, amelyeket automatizálásra érdemesnek tartok. Természetesen ezek között a feladatok között számos olyan van, amelyekhez már most is létezik működő számítógépes program. Ebben a fejezetben ezeket fogom áttekinteni.

A leghosszabb története a nagy házi feladatokat feldolgozó rendszernek van, nem csoda, hogy ez a programcsomag a létrehozása óta számos változáson ment át, a szkriptek mostanra teljesen kicserélődtek a legelső változathoz képest. Ha nem is ilyen mértékben, de természetesen az összes többi program is változott, fejlődött, tökéletesedett. A fejezetben nem kívánok részletesen kitérni a korábbi változatokra, csak a jelenlegi állapotot mutatom be részletesen (a fejezetcím is ezt sugallja). Egy-egy esetben azonban érdemes lehet megemlíteni, hogy egyik vagy másik szolgáltatás azért került bele a programokba, mert egy korábbi változatuk használata közben derült fény a hiányosságra. Ebben az értelemben tehát helyenként a programok fejlődéstörténete is felbukkan.

4.1 Házi feladatok feldolgozása

4.1.1 Nagy házi feladatok

4.1.1.0.1 A feladat kiadása

Az oktatók és segítőik minden tanévben elkészítik a kiadandó házi feladat részletes leírását, amely tartalmazza a feladvány ismertetését, a be- és kimeneti adatok formátumát, a megírandó Prolog-eljárás és SML-függvény specifikációját, valamint az adattípus-definíciókat. A kiírás mellett elkészítik az ún. keretprogramot, amely gondoskodik a kiírásban specifikált formátumú bemeneti adatok beolvasásáról és a kimeneti adatok kiírásáról, aktualizálják a beadáshoz használandó szkriptet, és mindezeket elérhetővé teszik a tárgy honlapján.4.1

4.1.1.0.2 A megoldás beadása

A házi feladatokat egy erre a célra készített szkript segítségével kell beadni. A BME minden hallgatója hozzáfér a Hallgatói Számítógép Központ Ural2 nevű központi Unix szerveréhez, tehát jogos az a feltételezés, hogy mindenki képes futtatni a szkriptet. (Természetesen nem csak innen lehet beadni a feladatot, bármilyen POSIX szabványú operációs rendszert, például Linuxot futtató, hálózati hozzáféréssel rendelkező gép megteszi.) A szkript ellenőrzi, hogy a szükséges állományok megvannak-e, azonosítja a hallgatót, majd megfelelő módon összecsomagolja a mindkét nyelven elkészített programot és a mellékelt közös dokumentációt, és névvel, hallgatói azonosítóval (NEPTUN kóddal) ellátva elektronikus levélben elküldi a tesztelést végző központi szervernek. A szerver válaszként visszaküldi a teszt naplóállományát a feladó címére (ahonnan a hallgató futtatta a szkriptet), így értesül a hallgató az eredményről.

4.1.1.0.3 A házi feladatok ellenőrzése

Az itt ismertetett folyamatot fig:nhffoly. adatfolyam-ábra szemlélteti. A szerveren a szkript által generált levelet egy program fogadja, amely kicsomagolja, kiolvassa belőle a beküldő nevét, azonosítóját és elektronikus címét, a teljes levelet eltárolja egy állományban - így az összes hallgató megoldásának összes változata archiválva van -, és felveszi egy tesztelési sorba. Ezen tennivalók végeztével siker esetén értesíti a hallgatót levele átvételéről, valamint arról, hogy a sorban hány várakozó van előtte, illetve sikertelenség esetén a felmerült hibáról. Ez a levél-fogadó program akkor indul el, amikor egy levél érkezik - így minden levéllel külön processz foglalkozik -, és munkája végeztével kilép.

Ezzel szemben a háttérben állandóan fut az ún. teszt-démon, amely rendszeres időközönként ellenőrzi a sort, és ha talál várakozó levelet, akkor a legfrissebb változatot először kicsomagolja egy könyvtárba (minden hallgatónak külön-külön könyvtára van), majd mellémásolva a teszteléshez szükséges keretprogramot és a tesztsort tartalmazó állományokat, minden feladványra teszteli a programokat. Ha egy program egy feladványra hiba nélkül - nem feltétlenül hibátlan megoldást adva - lefut, akkor a megoldás egy kimeneti állományba kerül. Ezt egy másik program egy előre legenerált referencia-megoldással összeveti, és feljegyzi, hogy helyes volt-e vagy sem. A teljes folyamatról, azaz a hallgató programjának lefordításáról, a futás közben kiírt esetleges üzenetekről és az egyes tesztesetek eredményéről naplóállomány készül, amelyet a rendszer archivál, és egyúttal elküld levélben az érintett hallgatónak. Így ha a megoldás nem tökéletes, azaz bizonyos tesztesetekre hibásan működik, a diákoknak még van lehetőségük a beadási határidő előtt megkeresni és kijavítani a hibát.

A hallgatók programjainak a megoldások előállítására korlátozott idő áll rendelkezésére, ez a korlát tesztesetenként más és más. Az idő leteltével a program futása megszakad, eredménye olyan, mintha hibás megoldást állított volna elő. Az idő- és ponteredmények - az oktatók kényelmének kedvéért - a naplóállomány mellett egy erre a célra kijelölt állományban külön megjelennek.

Ábra: Az NHF fogadó program adatfolyam-ábrája
\includegraphics{fig/nhffoly.eps}

A megoldásokra adott pontszámok, és az, hogy a házi feladat egyáltalán elfogadható-e, természetesen nem a beadási időszak során használt tesztsor alapján dől el, hiszen akkor könnyű lenne becsapni a rendszert. Az éles teszt eredményéről a hallgató a jelenlegi rendszerben nem levélben értesül, hanem azt a tárgy honlapján nézheti meg, az erre a célra készített HTML űrlapon a NEPTUN kódját megadva.

A feldolgozást végző programok jelenleg a bash Unix shell szkript nyelvén vannak megírva, a levelek és egyéb szöveges állományok feldolgozásához a sed, az awk és a grep nevű segédprogramokat használják. A programegyüttes könyvtárstruktúrájának egy részben kifejtett változatát, amely sokat elárul a lehetőségekről és korlátokról is, fig:olddirst. ábra mutatja.

Ábra: Az NHF feldolgozó programegyüttes könyvtárszerkezete


\fbox{\TheSbox}

4.1.2 Kis házi feladatok

A nagy házi feladatokat feldolgozó keret nem bizonyult minden tekintetben alkalmasnak a kis házi feladatok fogadásához. Ennek okai a következők voltak:

Mivel a KHF-ek kiadásának ötletétől az első beadási határidőig rendelkezésre álló idő igencsak korlátos volt (kb. egy hónap), a meglévő NHF keretrendszer kellő általánosítása nem látszott járható útnak, hiszen csupán a teendők alapos átgondolása hasonló mennyiségű időt vett volna igénybe. Egyszerűbbnek látszott a rendszer lemásolása és apróbb módosítása a megváltozott igényeknek megfelelően, így jelenleg két - nagy mértékben hasonló - rendszer működik egymás mellett. Ennek a megoldásnak a hátrányát szükségtelennek érzem hosszasan ecsetelni, hiszen nyilvánvaló, hogy a megduplázott rendszer karbantartása, hangolása is dupla annyi időt vesz igénybe, mivel minden - általános érvényű - módosítást kétszer kell elvégezni. A két rendszer egyesítése egy általánosabb, összefogó architektúrába már régóta várat magára, és e diplomatervvel remélhetően eljut a tervezés szintjére, amelyet a későbbiekben követhet a megvalósítás is.

Az eltérések az NHF értékelő rendszerhez képest a következők:


4.1.3 Másolatok kiszűrése hasonlóságvizsgálattal

Mint már említettem, az NHF-ek beadásának kötelezővé tétele ugrásszerűen megnövelte a másolások számát. De ez a jelenség egyébként is megfigyelhető, ugyanakkor küzdeni ellene meglehetősen nehéz. Nyilvánvaló, hogy több száz hallgatói program végigolvasása, alapos tanulmányozása szinte lehetetlen feladat. Ez okból készített a BME egyik informatika szakos hallgatója, Lukácsy Gergely egy olyan programot (Prolog nyelven), amely képes programok hívási gráfjának összehasonlítására és az egyezések detektálására (Lukácsy, 2000). A program a gráfokon számos redukciós lépést végez el, hogy azok a strukturális - ám működésbeli eltérést nem okozó - különbségek, melyek például egy eljárás két részre vágásával adódnak, eltűnjenek, ill. lelepleződjenek. A programhoz készített kiegészítő modul alkalmas egy Prolog-program hívási gráfjának feltérképezésére, de a hasonlóságvizsgáló algoritmus megvalósítása nyelvtől független, megfelelő illesztéssel tetszőleges programozási nyelven írt programok összehasonlítására alkalmas.

Az alkalmazott módszer előnye, hogy vele szemben hatástalanok azok a másolást álcázó trükkök, amelyek az eljárások, változók, struktúrák átnevezésén vagy a program primitív átstrukturálásán alapulnak. E program segítségével az elmúlt évben több olyan csalásra is fény derült, amelyek valószínűleg észrevétlenek maradtak volna nélküle. Természetesen csak NHF-ek esetében alkalmazzuk, hiszen a KHF-ek túlságosan egyszerűek ahhoz, hogy ne hasonlítsanak egymásra a megoldások; és egyelőre csak a Prolog-részekre, mivel az SML-hez mindezidáig nem készült hívási gráfot építő modul. sec:mlgraf. fejezetben éppen egy ilyen, általam készített programot mutatok be, amellyel SML-programok összehasonlítása is lehetővé válik.

4.2 Gyakoroltatás

A 2001-es év tavaszi szemeszterével kezdődően az oktatók a nagy és kis házi feladatok kiadása mellett újabb lehetőséget biztosítanak az önálló gyakorlásra. Mivel az ilyen jellegű feladatok megoldása nem igényel többet néhány perc próbálkozásnál, nem sok értelme lenne az englishoffline jellegű ellenőrzésnek. Ehelyett ebben a félévben két korábbi hallgató a tárgyfelelős tanszék által alkalmazott demonstrátorként azt a feladatot kapta, hogy tervezze meg és alakítsa ki a gyakoroltatáshoz szükséges webfelületet és a hozzá tartozó CGI programokat. A rendszer első, élesben kipróbálható változata el is készült, ez jelenleg a következő egyszerű feladat-típusokat ismeri:

  1. Prolog
    kanonikus alakra hozás (szintaktikus édesítőszerek nélküli felírás);
    hívás eredményének megállapítása ,,sikerül/meghiúsul/hiba'' jelleggel, siker esetén a változó(k) értéke;
    hívásra válaszul adott behelyettesítések megadása, a sorrend betartásával;
    egyszerű eljárás írása, pl. lista hosszának kiszámítására.
  2. SML
    ,,mi a típusa a kifejezésnek?'' jellegű kérdések;
    kifejezés értékének megállapítása;
    egyszerű függvény írása.

A hallgatók a NEPTUN kódjukkal azonosítják magukat, és ettől kezdve a program nyilvántartást tud vezetni az egyes diákok haladásáról, ill. a követelmények teljesítéséről. Természetesen a belépések között is emlékszik a legutóbbi állapotra, tehát a hallgató ott folytathatja, ahol legutóbb abbahagyta.

A program igyekszik értelmes hibaüzeneteket adni a hibás válaszokra, ennek megfelelően megkülönbözteti a szintaktikai és a szemantikai hibákat, valamint a formai követelmények be nem tartásából eredő hibákat, és minden esetben többé-kevésbé informatív üzenettel válaszol. Ha egy hallgató az adott feladattal nem boldogul, akkor lehetősége van ugyanabból a típusból másik feladatot kérni, vagy másik típust választani.

4.3 Egyéb adminisztratív teendők

4.3.0.0.1 Jegyzetrendelés

A Deklaratív programozás tárgyhoz a teljes órai anyagot felölelő és valamivel azon túlmutató, rendszerezett, papírborítású könyv formájában évről évre rendszeresen kiadott jegyzet áll a hallgatók rendelkezésére, ez azonban nem kapható az egyetemi könyvesboltban. Ehelyett a félév első néhány hetében a hallgatóknak nyilatkozniuk kell arról, hogy kérnek-e jegyzetet (a keresztfélévesek, és azok, akik felsőbbévesektől megkapják, nem szoktak rendelni). A rendelés eleinte az előadáson körbeadott ívek aláírásával történt, ám a tárgyat felvett hallgatók számottevő része egyáltalán nem jár előadásra, ilyen módon többen lemaradtak róla. Az utóbbi két évben ennek a problémának a megkerülésére a jegyzetrendelés Weben keresztül zajlik, a NEPTUN kód megadásával. A rendeléssel egyidőben a hallgatóknak meg kell adniuk egy elektronikus levelezési címet is, hogy szükség esetén elérhessük őket.

4.3.0.0.2 Jelentkezés ZH-ra

A vizsgákra az egyetemi szabályozásnak megfelelően a NEPTUN hallgatói információs rendszeren keresztül jelentkezni kell, így a vizsgát megelőző napon már pontos létszámadatok állnak az oktatók rendelkezésére. A névsor segítségével elkészíthető a szóbeli vizsga időbeosztása, ill. a korábbi években megállapítható volt, hogy az írásbeli vizsgára a feladatsort hány példányban kell sokszorosítani. A zárthelyi dolgozat esetében azonban nincs ilyen közös jelentkezési rendszer. Emiatt rendszeresen előfordult, hogy az oktatók jelentősen túlbecsülték a ZH-n megjelenő hallgatók létszámát, és a feladatsorból szükségtelenül és aránytalanul sokat sokszorosítottak. A pazarlás minimalizálása érdekében az utóbbi időben a ZH-ra is jelentkezni kell egy weblapon keresztül. A jelentkezés ténye nem ró kötelezettségeket a hallgatóra, a megjelenése továbbra sem kötelező, az így kapott létszámbecslés tehát még mindig meghaladhatja a ténylegeset, a kapott kép mégis pontosabb.

4.3.0.0.3 Terembeosztás, ültetési rend

A jelentkezők névsora, a ZH-ra megkapott termek mérete és elrendezése alapján előállítható a hallgatók terembeosztása és az ültetés rendje is. Ez utóbbira azért van szükség, mert ezzel is csökkenthető a csalás esélye.

4.3.0.0.4 Kísérőlap készítése

Az oktatók kényelmét szolgálja az a program is, amely a szóbeli vizsgáztatáshoz nyújt segítséget. A vizsgajegybe számos félévközi eredmény beleszámít, ám ezek nyilvántartása odafigyelést igénylő munka. Ezt megkönnyítendő a program használatával kísérőlap nyomtatható minden vizsgázó hallgatónak, amely automatikusan tartalmazza a félév közben megszerzett összes pontszámot, továbbá különböző rovatokat a vizsga során megoldott feladatok pontszámainak feltüntetésére. Így a vizsga végén a megszerzett jegy gyorsan megállapítható akkor is, ha a hallgatót többen vizsgáztatták, és ebben esetleg a jegyet az indexbe beíró tanár nem is vett részt.

4.4 A programegyüttes értékelése

A tárgy történetét ismerve érthető, hogy ezen programok fejlesztése mindig ad-hoc jellegű volt, soha nem előzte meg alapos tervezés és előkészítés, az időkorlátok miatt mindig a lehető legegyszerűbb és leggyorsabb megoldást választottuk megvalósításukkor. Mostanra talán az vált a legfőbb hátrányukká, hogy ebből adódóan nem állnak össze átgondolt, egységes rendszerré.

Külön-külön vizsgálva őket azt tapasztalhatjuk, hogy - érthető módon - némelyikük mára egészen letisztult, feladatai részleteiben is világossá váltak, mások azonban még nem ennyire kiforrottak. A nagy házi feladat ellenőrző, legelsőként elkészített - ám azóta folyamatosan átalakított és továbbfejlesztett - rendszer például önálló egységként tekintve alapvetően logikus struktúrájú, koncepcionálisan tiszta, még ha a programozási munka hagy is némi kívánnivalót maga után.

Mostanra az automatizált és automatizálni kívánt feladatok száma elért egy olyan szintet, hogy érdemes a teljes feladatcsoportot újra átgondolni, és az alapoktól kezdve egy egységes rendszerbe fogva megtervezni. Erről lesz szó cha:ets. fejezetben.

Hanák Dávid <dhanak@inf.bme.hu>