1 Budapesti Műszaki és Gazdaságtudományi Egyetem DIPLOMATERV Hálózati információs rendszer oktatáshoz Készítette: Pecsenyánszky István BME Villamosmér...
DIPLOMATERV Hálózati információs rendszer oktatáshoz
Készítette:
Pecsenyánszky István BME Villamosmérnöki és Informatikai Kar Villamosmérnöki szak 2001. május
Konzulens:
Dr. Máray Tamás adjunktus BME Irányítástechnika és Informatika Tanszék
Nyilatkozat
Alulírott Pecsenyánszky István, a Budapesti Műszaki és Gazdaságtudományi Egyetem hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomatervben csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem.
...................................................... Pecsenyánszky István
II
III
Összefoglalás Diplomatervezési feladatom során egy olyan szoftvert fejlesztettem, amely a későbbiekben az egyetem hasznára is válhat: egy olyan webes alkalmazást, amely az oktatókat támogatja a számonkérésben, a hallgatóságot pedig segíti a felkészülésben. Ebben a dolgozatban a fejlesztés során végzett munkámat foglalom össze. A dolgozat első részében egy általános leírást adok az elkészítendő szoftverről, és bemutatom az ehhez hasonló, már létező rendszereket. Ezt követően ismertetem a tervezett szoftver által alkalmazott és igénybevett technológiákat, továbbá bemutatom azokat a szoftverkomponenseket, amelyek nem én terveztem, de az általam fejlesztett szoftver működéséhez elengedhetetlenek, és a szoftver megtervezéséhez ezek alapos ismerete nélkülözhetetlen. Ezután a rendszerről pontos specifikációt adok. A dolgozat következő részében ismertetem a rendszer tervezési lépéseit, különös figyelmet szentelve a biztonsági kérdéseknek és a felhasználói felület kialakításának. Ezt követően bemutatom a szoftver főbb moduljainak implementálásának a menetét, kitérve a fontosabb programozási megoldásokra, majd kitérek a rendszer tesztelési kérdéseire. Végezetül összegzem a rendszerről alkotott véleményemet, és szót ejtek az esetleges továbbfejlesztési lehetőségekről.
IV
Abstract
V
Tartalomjegyzék 1. BEVEZETÉS (1).....................................................................................................1 2. FELADAT DEFINÍCIÓ (2-3) ...............................................................................3 3. ÁTTEKINTÉS (5-6) ...............................................................................................5 3.1 TOPCLASS ...........................................................................................................6 3.2 LEARNLINC .........................................................................................................6 3.3 CYBERPROF.........................................................................................................7 3.4 WEBCT ...............................................................................................................7 4. TECHNOLÓGIA (8-10) ........................................................................................8 4.1 INTERNET ............................................................................................................8 4.1.1 World Wide Web..........................................................................................8 4.1.2 HTTP .........................................................................................................10 4.1.3 HTML ........................................................................................................11 4.1.4 JavaScript ..................................................................................................11 4.2 FELHASZNÁLT SZOFTVEREK ..............................................................................12 4.2.1 Operációs rendszer....................................................................................12 4.2.2 Adatbázis-kezelő ........................................................................................12 4.2.3 PHP ...........................................................................................................14 4.2.4 Webszerver ................................................................................................15 5. SPECIFIKÁCIÓ (1-2)..........................................................................................16 6. TERVEZÉS (SW + DB + BIZT + UI, 12-15) .....................................................19 6.1 SZOFTVER ÉS ADATBÁZIS TERVEZÉS ..................................................................19 6.1.1 Adatfolyam ábrák ......................................................................................21 6.1.2 Logikai adatmodell....................................................................................23 6.1.3 Táblák, adattípusok meghatározása..........................................................24 6.2 BIZTONSÁGI KÉRDÉSEK .....................................................................................29 6.2.1 Hálózati topológia.....................................................................................29 6.2.2 Titkosított kommunikáció ..........................................................................30 6.2.3 Számítógép, operációs rendszer ................................................................32 6.2.4 A rendszer biztonsági kérdései ..................................................................32 6.3 USER INTERFACE ...............................................................................................34 6.3.1 Általános szempontok ................................................................................34 6.3.2 Megvalósítási tervek..................................................................................35 7. IMPLEMENTÁLÁS ÉS TESZTELÉS (6-8) .....................................................40 7.1 KÖZÖS PROGRAMKÓDOK ...................................................................................40 7.1.1 Adatbázis kezelő függvények .....................................................................41 7.1.2 Naplózás ....................................................................................................42 7.1.3 Session-kezelés ..........................................................................................43 7.2 A FŐBB FUNKCIÓK IMPLEMENTÁLÁSA ...............................................................47 7.2.1 Belépés, authentikáció...............................................................................48 7.2.2 Oktatói adminisztrációs felület..................................................................49 7.2.3 Tesztelés.....................................................................................................54 8. ÉRTÉKELÉS (1-2)...............................................................................................56
9. IRODALOMJEGYZÉK, FORRÁSOK (1-2) ....................................................57 10. FÜGGELÉK .......................................................................................................57 A MELLÉKLET – TÁVOKTATÓ SZOFTVEREK .............................................................57
VII
1. Bevezetés (1) Az utóbbi időben a fiatalok egyre nagyobb része dönt az érettségi után a továbbtanulás mellett. Ezt a tendenciát támasztják alá a témával foglalkozó statisztikák. Ezen kimutatások szerint, míg az alapfokú oktatásban résztvevők száma közel állandónak mondható, a középiskolákban tanulók száma növekszik, a felsőoktatásban részesülő hallgatók száma még ennél is dinamikusabb növekedést mutat. (1.1 ábra) A felsőfokú oktatásban résztvevő oktatók számának növekedése azonban már közel sem ennyire lendületes, az egy oktatóra jutó hallgatók száma az elmúlt pár évben mind nagyobb és nagyobb. (1.2 ábra)
Beiratkozottak száma, ezer 1990/91 1997/98 1998/99 1999/00 Általános iskola, nappali 1130,7 964,0 964,2 960,6 Szakmunkásképzés 209,4 132,6 119,7 109,5 Középiskola 291,9 368,6 376,6 386,6 Felsőfokú oktatás 102,4 233,8 258,3 279,8 1.1 ábra: beiratkozottak száma [1] Felsőfokú oktatás Egy oktatóra jutó hallgató
1990/91 1997/98 1998/99 1999/00 4,4 7,8 7,6 8,1
1.2 ábra: egy oktatóra jutó hallgató a felsőfokú oktatásban [1]
A Budapesti Műszaki és Gazdaságtudományi Egyetemen kevés kivétellel szinte az összes karon több száz feletti létszámmal indulnak az elsőéves évfolyamok, de a népszerűbb karokon nem ritkák a 400-500 fős évfolyamok sem. A nagy létszámból adódóan az oktatóknak esetenként igen nagy feladatot jelent a hallgatók félévközi beszámoltatása, vizsgáztatása, holott a legtöbb tárgy esetében a számonkérés bizonyos részei valamilyen szinten automatizálhatóak lehetnének. A zárthelyi dolgozatok és vizsgák nagy része írásbeli, de a feladatsor összeállításán és a vizsga lebonyolításán felül egyes tárgyak esetén jellegüknél fogva akár a dolgozatok kijavítása és értékelése is automatikussá tehető lenne. A vizsgák mellett a laboratóriumi
mérések
lebonyolításánál
és
egyéb,
feladatbeadással
járó
1
laborgyakorlatok, házi feladatok esetén is felmerül az igény mind a hallgatók, mind pedig az oktatók részéről egy egységes mechanizmusra, amely képes lenne átvenni az adminisztrációval járó terheket. A vázolt problémák megoldásához és kívánalmak megvalósításához az infrastruktúra a legtöbb helyen már jó ideje rendelkezésre áll: a hallgatói számítógéplaborok, illetve a számítógép-hálózat, az Internet technológia képes biztosítani egy ilyen információs rendszerhez szükséges hátteret. Az Internet, illetve ezen belül a web technológiának az alkalmazása lehetővé teszi azt is, hogy a rendszer használatához ne legyen szükség a felhasználó által egy speciális szoftver telepítésére, hanem a megszokott böngészővel (pl. Netscape Navigator, Internet Explorer) azt kényelmesen igénybe lehessen venni.
2
2. Feladat definíció (2-3) A feladat egy on-line, interaktív adatbázis elkészítése, amely segíti az oktatókat a hallgatók beszámoltatásában, továbbá egy egységes felületet nyújt a félévközi
feladatok
megoldásainak
a
begyűjtéséhez.
A
feladat
pontos
megismeréséhez meg kell ismerkedni azokkal a problémákkal, fel kell mérni azokat az igényeket és követelményeket, amelyek az oktatók részéről jelentkeznek, természetesen figyelembe véve a hallgatók szempontjait is. A megvalósítást illetően körbe kell tekinteni, milyen módszerek, technológiák léteznek, illetve ezekből konkrétan melyek állnak rendelkezésre, és melyek azok, amelyek használata csak körülményesebbé, nehézkesebbé tenné a születendő rendszer használatát. Végül mindezek ismeretében pontosan fel kell térképezni azokat a területeket, amelyek a megvalósítandó rendszerrel ésszerűen lefedhetőek, megoldhatóak. Az oktatók részéről alapvető elvárás a rendszerrel szemben, hogy az képes legyen tantárgyak szerint csoportosítva eltárolni kérdéseket ezekből egyfajta adatbázist kialakítva, és adjon lehetőséget ezekből tetszőleges feladatsorok összeállítására. Az ily módon létrehozott feladatsorokból válogatva legyen mód vizsgák, zárthelyi dolgozatok, egyéb írásbeli számonkérések definiálására pontos hely és idő meghatározásával, és ezek után természetesen adja meg a lehetőséget, hogy az oktató által megszabott koordináták szigorú ellenőrzése mellett a hallgatók megoldhassák a feladatsort, és rendszer gyűjtse is be a válaszokat. További igényként felmerül, hogy a hallgató által megoldott feladatsorokat, ahol a rendszert erre alkalmassá lehet tenni, értékelje ki, de legalábbis segítse az oktatót a dolgozatok kijavításában, és ebből közvetlenül adódik, hogy a rendszer legyen képes az oktató által bevitt kérdésekhez a helyes válasz eltárolására is. A válasz beviteléhez szükség van a válasz típusának a meghatározásához. Ez típus lehet szöveges, teszt és file típusú is, ez utóbbi pl. házi feladatok beadásakor lehet hasznos. A típusoknál azonban nem szabad kizárni a későbbiekben más, az eddigiektől eltérő típusú feladatok bekerülését a rendszerbe. A feladat megvalósításánál az egyik leglényegesebb szempont, hogy a már meglévő technikai hátteret lenne kívánatos igénybe venni. Ezt a hátteret a hallgatói
3
számítógéplaborok, az itt található hálózatba kötött számítógépek jelentik, illetve az ezekre a gépekre telepített weblapok letöltésére és megjelenítésére használt ún. böngésző program vagy angol nevén browser. Végül, a rendszer lehetőleg ne tartalmazzon kereskedelmi szoftvert, amelyek használatáért fizetni kell.
4
3. Áttekintés (5-6) A
piacon
számos
web
alapú
oktatást
segítő
szoftver
létezik.
A legfőbb eltérés e szoftverek és a fentiekben említett rendszer között, hogy ezek a programok sokkal nagyobb hangsúlyt fektetnek magára az oktatásra, kurzusok összeállítására, a diplomamunka keretein belül megvalósuló rendszer azonban inkább csak a tananyag számonkérésére összpontosít. További különbség, hogy a programok többsége nagy szabadságot biztosít az oktató számára az anyag bevitelében, képi megjelenítésében, ehhez segítségképpen egyes szoftverek saját HTML szerkesztővel is rendelkeznek. Ez a saját rendszerről nem mondható el; az oktatók a kérdések és feladatsorok összeállításakor csak előre definiált formátumok közül választhatnak, speciális HTML elemeket nem alkalmazhatnak. Ez azonban nem jelent olyan nagy mértékű megkötést, mint gondolhatnánk, hiszen itt kizárólag a kérdésekről beszélünk, nem pedig magáról a tananyagról, továbbá saját fejlesztésű, szabad forráskódú szoftverről lévén szó, a későbbi igényeknek megfelelően bármikor módosítható, bővíthető a rendszer. Nem elhanyagolható szempont, hogy míg ezek a szoftverek többsége kereskedelmi termék, használatukért fizetni kell, a diplomamunka részeként megvalósuló rendszernél egyik fő szempont, hogy kizárólag szabadon hozzáférhető modulokból építkezzen. Mindezek mellett szem előtt kell tartani azt is, hogy már létező távoktató szoftverek használatához elengedhetetlen a nyelvismeret, míg a saját fejlesztésű rendszer magyar nyelvű lesz. Az
alábbiakban
bemutatjuk
az
elterjedtebb
távoktató
programokat,
a függelékben pedig egy teljes listát is megtalálunk ezekről a szoftverekről.
5
3.1 TopClass A WBT Systems által kifejlesztett multimédia alapú oktatóprogram, melynek segítségével web alapú intranet vagy Internet oktatóanyagot lehet létrehozni, és magát az oktatást, vagyis a szemináriumot is lebonyolítani. A TopClass rendszer háromféle felhasználót különböztet meg: •
a virtuális szemináriumon résztvevő diákot,
•
a diák munkáját segítő-irányító tanárt és
•
a rendszer-adminisztrátort, aki a TopClass rendszer egészének működéséért felelős, de nincs közvetlen kapcsolatban a rendszer többi felhasználójával. A web-böngészőn keresztül elérhető rendszerbe való belépés jelszóhoz kötött.
A diák hozzáférési joga a legszűkebb körű, nincs lehetősége újabb kurzus létrehozására, a jelenlegi megváltoztatására, illetve nem tekinthet be a többi diák adataiba, de természetesen hozzáfér mindazon kurzusok anyagaihoz, amelyekre beiratkozott. Az oktató jogosultságait az adminisztrátor állítja be, míg az adminisztrátor jogait természetesen semmi sem korlátozza: létrehozhat diák és tanári jogosultságot, és a szemináriumok menetébe is betekintést nyerhet. A rendszer beépített üzenetküldő mechanizmussal is rendelkezik, amely nem csupán az oktató és diák közötti kapcsolattartása alkalmas, hanem levelezési listák, fórumok is létrehozhatók, így egyéb kiegészítő alkalmazás nélkül kialakítható a virtuális szeminárium összes szükséges kommunikációs csatornája.
3.2 LearnLinc Az ILINC terméke. A szoftver célja elsősorban a szinkron jellegű internetes oktatás támogatása videokonferencia-rendszerrel. A szoftver nagy sávszélességet igényel, így elsősorban campuson belüli intraneten használható. A rendszerbe bekapcsolódó munkaállomások feltétele a nagyobb teljesítmény és a multimédia támogatottság. A kétirányú audió és videó kapcsolat mellett lehetővé teszi az oktató által előre elkészített multimédia anyagok bemutatását, továbbá hagyományos
6
tantermi szituáció szimulálására is képes. A rendszerben lehetőség van az oktatói moderálásra, azaz az óra menetét az oktató ütemezheti.
3.3 CyberProf Aszinkron oktatási formát támogató szoftver. A rendszer több modult is tartalmaz, amelyek együttes használatával a virtuális szeminárium minden eleme megvalósítható. A rendszer tartalmaz webszerkesztőt, amely a tananyag elkészítését segíti, és feladatszerkesztőt, amellyel ellenőrző kérdéseket lehet összeállítani. A szoftver chat-modullal is rendelkezik, amellyel on-line szöveges párbeszéd is kialakítható. A szoftvert a University of Illinois-on fejlesztették ki.
3.4 WebCT Szintén aszinkron oktatási formára kifejlesztett web-alapú rendszer. Virtuális kurzusok hozhatók létre. A tananyag webre tételét különféle eszközökkel segíti, tartalmaz beszélgető-fórumot, feladatűrlapokat és hallgatói nyilvántartást is.
7
4. Technológia (8-10) 4.1 Internet 4.1.1 World Wide Web Az utóbbi években a számítógépes hálózatok leggyorsabban terjedő és fejlődő szolgáltatása a World Wide Web (röviden WWW vagy web), 1990-es megszületése óta hatalmas sikert mondhat magáénak. A történet egy évvel korábbra nyúlik vissza, amikor Tim Berners-Lee és Robert Cailliau, a genfi CERN (European Organization for Nuclear Research) kutatói 1989-ben egy hypertext alapú rendszer létrehozását indítványozták, amely az elképzelések szerint a különböző, esetenként egymástól nagy távolságra lévő szervereken fellelhető információkat egy egységes felületen lenne képes elérhetővé tenni. A rendszer eredeti célja az volt, hogy használatával több adatbázisban szétszórtan található szakmai információkat egyszerűen tehessék elérhetővé a CERN részecskefizikusai számára. Egyéves munka után üzembe állították az első szervert és elkészítették az első kliens programokat.
4.1 ábra: a WWW elterjedésének megindulása [2]
8
Az áttörés ugyan néhány évet váratott magára, de ekkor a fejlődés robbanásszerűen megindult, az Interneten gombamód kezdtek szaporodni a WWW szerverek, és számos kliens program is napvilágot látott, ezek közül a legjelentősebb az NCSA Mosaic volt. A fejlődés lendületét mutatja, hogy rövid időn belül a hálózati forgalom túlnyomó részét a web forgalom tette ki, túlszárnyalva a WWW elődjének számító gopher-t is (4.1 ábra). A haladás a kezdeti lelkesedés után sem csökkent, és a mai napig gőzerővel tart. Mára már számos webszerver változat napvilágot látott a legkülönbözőbb
számítógéptípusokra,
kereskedelmi
és
szabadon
letölthető
verzióban, a hálózaton pedig egyre-másra jelennek az újabbnál újabb szerverek, a webes tartalmat szolgáltató szerverek száma exponenciális növekedést mutat (4.2 ábra). A WWW roppant elterjedését az is tanúsítja, hogy a ma Internetezők többsége számára a világméretű hálózat tulajdonképpen nem is jelent mást, mint magát a WWW-t.
4.2 ábra: webszerverek száma az Interneten [3] A web technológia hatalmas sikerét annak köszönheti, hogy integrálni képes az eddigi információs rendszereket. A rendszer platformfüggetlen, és egyszerű, egységes grafikus felhasználói felülettel rendelkezik, amelynek használatához számítógépes tudás sem szükséges, továbbá teljes mértékben támogatja az interaktivitást. Mindezek az ismérvek lehetőséget teremtettek arra, hogy az Internet ne csupán a számítástechnikusok birodalma legyen, hanem egy sokkal tágasabb kör számára vonzó médiummá váljon. Mára már sok minden részben vagy teljes egészében a „valós világból” az Internetre költözött, a világméretű hálózaton ma már számtalan alkalmazást láthatunk az elektronikus kereskedelemtől kezdve a virtuális egyetemeken keresztül a reklámszakmáig, rendelhetünk mozijegyet, beszélgethetünk tőlünk több ezer km-re lévő ismerősünkkel, megnézhetjük a várható időjárást, 9
nyomon követhetjük a tőzsdei árfolyamokat, vásárolhatunk autót, a lehetőségek száma határtalan. A
WWW
rohamos
elterjedése a számítógépes
hálózat
ugrásszerű
igénybevételét eredményezi, és ezt a megnövekedett terhelést nem csupán a felhasználói tábor gyarapodása okozza, hanem maga a WWW jellege is: az eddigi, többnyire szöveges információk helyét egyre inkább grafikus állományok veszik át, esetenként egyéb multimédiás anyagokkal kiegészülve. A felhasználó így egyetlen kis kattintással akár több nagyságrenddel nagyobb forgalmat generálhat, mint azelőtt, márpedig a webet használók többsége előbb kattint, aztán gondolkozik!
4.1.2 HTTP A fentebb leírtakból kitűnik, hogy a WWW egy kliens-szerver architektúra, a szerver, amely az információt szolgáltatja, a kliens, azaz a böngésző vagy angol nevén browser, pedig a felhasználó számítógépén futtatott alkalmazás. A kliens és a szerver közötti kommunikációra egy egységes nyelvet dolgoztak ki, és ennek a HTTP (HyperText Transfer Protocol) nevet adták. A protokoll egyidős a WWW-vel, és megjelenése óta a WWW-vel együtt ez is jelentős változásokon ment keresztül. A HTTP protokollnak jelenleg az 1.0-ás és 1.1-es verziója használatos. Az eredeti HTTP rendkívül egyszerű volt, fő feladata egyszerű ASCII adatok továbbítása a kliens és a szerver között, ez volt a HTTP/0.9. Ezt váltotta fel a HTTP/1.0. A protokollt kibővítették: az üzeneteket MIME-típusú fejlécekkel látták el, amelyek a továbbított állományokról hordoznak plusz információkat, pl. a továbbított állomány típusát. A protokollt továbbfejlesztve a HTTP/1.1 már támogatást nyújt hierarchikus proxy szerverekhez, cache szoftverekhez, továbbá képes perzisztens kapcsolatra (persistent connection: egyetlen kapcsolaton több kérés kiszolgálása), ill. támogatja az ún. virtuális hosztolást (virtual hosting: egyetlen webszerveren több website kiszolgálása).
10
4.1.3 HTML A HTTP-t, mint nevéből is látszik, elsősorban hypertext típusú szöveges állományok átvitelére tervezték és hozták létre. Ez a típus a HTML (HyperText Markup Language), amely tulajdonképpen nem más, mint a World Wide Web dokumentumok szerkesztésekor használt stíluselemek gyűjteménye, illetve az ezeket a stíluselemeket felhasználva készített dokumentum. A HTML nyelvet 1990-ben Tim Berners-Lee, a WWW egyik kezdeményezője és Daniel W. Connolly alkották meg. Az SGML sablonjára építve Berners-Lee megtervezte a HTML-t, míg Connolly megírta a HTML DTD-t (Document Type Definition), amely a HTML szintaxis formális definiálása az SGML alapján. Az SGML (Standard Generalized Markup Language, ISO 8879) [x] egy olyan rendszer, amelynek segítségével ún. jelölőnyelveket lehet definiálni. A dokumentumok szerzői itt különböző jelölésekkel adják meg a szerkezeti, prezentációs és szemantikai információkat. A HTML az SGML ilyen tipikus alkalmazása.
4.1.4 JavaScript A JavaScript, mint a neve is mutatja, egy script nyelv. A JavaScript kódot HTML lapokba lehet beágyazni, a kód a lappal együtt töltődik le a szerverről, majd a böngésző értelmezi és futtatja azt. A JavaScript tehát integráns része a HTML lapnak, nem csak, hogy a teljes program forrása a lapon található, de a dokumentum többi részével is közeli kapcsolatban áll: közvetlenül hivatkozhat a lapon lévő elemekre (pl. az űrlapok egyes összetevőire), de még a böngésző megjelenését, viselkedését is befolyásolhatja. Szintaxisa a C nyelvre hasonlít, és bizonyos mértékig objektumorientáltnak minősíthető. Nem kínál ugyan teljes objektumorientált eszközrendszert, mint pl. a C++, a JavaScript inkább csak objektum-alapú (object based) nyelvnek nevezhető: lehetőségünk van objektumok létrehozására, de osztályokat (típusokat) nem definiálhatunk, így természetesen sem öröklődésről, sem polimorfizmusról nem beszélhetünk. [4] A JavaScript nyelvet először a Netscape Navigator 2.0-ás verziója támogatta, de manapság már a legtöbb grafikus böngésző képes JavaScript kódot futtatni, bár esetenként az egyes implementációkban komoly eltérések figyelhetők meg. 11
4.2 Felhasznált szoftverek A rendszer és szorosabb környezete négy alapvető szoftverből tevődik össze, illetve ezekből építkezik: az operációs rendszer, a webszerver, az adatbázis szerver és a PHP. Ezek kapcsolatát mutatja a 4.3-as ábra:
webszerver
kliens
P H P
SQL
DB
4.3 ábra: a rendszer sematikus felépítése
4.2.1 Operációs rendszer Az operációs rendszerrel szemben elvárás a rá telepített szoftverek (webszerver és adatbázis-kezelő) megbízható futtatása, a TCP/IP hálózat kezelése, a biztonságosság. A számos alternatíva közül a FreeBSD-re esett a választás, de a fenti rendszer minden különösebb változtatás nélkül a legtöbb Unix típusú operációs rendszeren működik, ha az említett feltételeknek eleget tesz.
4.2.2 Adatbázis-kezelő A rendszernek nagy mennyiségű információ eltárolására kell alkalmasnak lennie, továbbá ezeknek az információknak pillanatok alatt rendelkezésre is kell tudni állniuk bizonyos szempontok szerint kiválogatva, rendszerezve, sorrendezve. E funkció legegyszerűbben egy SQL alapú relációs adatbázis-kezelő szoftverrel oldható meg. Felmerült lehetőségként az LDAP (Lightweight Directory Access Protocol) rendszer használata, azonban rövid vizsgálódást követően ezt az ötletet el kellett vetni. Az LDAP kiválóan megfelel olyan alkalmazásokhoz, ahol az adatbázisból való lekérdezések száma jóval meghaladja az adatbázisba való írások számát, ez azonban a megvalósítandó rendszer esetén közel sincs így, ezen felül a
12
rendszerben eltárolni szándékozott adatok típusa, hierarchiája is kézenfekvőbben írható le és tervezhető egy SQL alapú adatbázisban, mint az LDAP fastruktúrájában. Az adatbázis-kezelő kiválasztásakor számos alternatíva jön számításba aktív fejlesztői hátterük és széles körben való elterjedtségük miatt. Ezekből emeli ki és foglalja össze az ismertebbeket a következő táblázat: FreeBSD támogatás X linux X linux linux linux X X linux X X X
Adabas D 10.01.00 EMPRESS 6.1 FrontBase 2.1 Informix 7.30C1 Interbase 6.0Beta Mimer SQL 8.2.0C mSQL 2.0.10 MySQL 3.23.25 Oracle 8.1.6.0.0 PostgreSQL 7.0 SOLID Server 2.3.26 Sybase enterpr. 11.x
ingyenes
PHP X X X X
X X X
X X X X X X
X X
tranzakciókezelés X X nem szabv. nem szabv. nem szabv. X X X X X nem szabv.
külső kulcsok X
X
subquery X X X X X X
X X X X
X X X X
X X
view X X X X X
X X X X
4.4 ábra: adatbázis-kezelők összehasonlító táblázata A táblázatban csak azok az adatbázis szerverek szerepelnek, amelyek rendelkeznek SQL lekérdező nyelvvel és létezik FreeBSD alatti verziója, de ezen felül a táblázatban helyet kaptak azok a szoftverek is, amelyekből ugyan nem létezik natív FreeBSD-s bináris, azonban a FreeBSD által nyújtott Linux emulációval mégis futtathatók ezek a programok. (FreeBSD-vel kapcsolatban lásd még a 4.5-ös fejezetet). A táblázat a platform mellett az adatbázis-kezelővel szemben támasztott legfontosabb követelményeket tartalmazza, és ezek szerint jellemzi azokat: •
Ingyenes:
az
adott
szoftver
szabadon
hozzáférhető-e
és
felhasználható-e oktatási célokra •
PHP: az adatbázis kezelőt támogatja-e a PHP (lásd a következő fejezetet)
•
Tranzakciókezelés: van-e beépített tranzakciókezelés az SQL szerverben
•
Subquery: támogatja-e a beágyazott lekérdezéseket
•
View: lehet-e ún. view-kat létrehozni
13
Az itt említett követelmények közül nem mind elengedhetetlen, azonban e rendszer implementálásakor nagy könnyebbséget jelentenek. Webes alkalmazások készítéséhez a gyakorlatban túlnyomórészt két adatbázis-kezelőt használnak: a MySQL-t és a PostgreSQL-t. A MySQL előnye a gyorsaság, azonban pillanatnyilag a fent említett elemek hiányoznak belőle. Ezek a hiányzó tulajdonságok az egyes tesztek szerint lassabban teljesítő PostgreSQL-ben viszont mind megvannak, így a választás végül erre az adatbázis-kezelőre esett. Megjegyzésképpen mindehhez még annyit hozzá kell tenni, hogy a rendszer alapjában véve nem függ attól, milyen adatbázis-kezelővel dolgozik. Az SQL alapú adatbázis-kezelők egy többé-kevésbé egységes felületen keresztül érhetők el, ezt a felületet pedig az ún. lekérdező nyelv, az SQL (Simple Query Language) biztosítja, ami azt jelenti, hogy a későbbiekben elvben elképzelhető az SQL szerver teljes cseréje.
4.2.3 PHP A PHP (hivatalosan „PHP: Hypertext Preprocessor”) egy szerver oldali HTML-be ágyazott programnyelv. A PHP használatával mindazt el lehet érni, amit 700000
600000
400000
300000
200000
100000
0 Ju n98 Au g98 O ct -9 8 D ec -9 8 Fe b99 Ap r-9 9 Ju n99 Au g99 O ct -9 9 D ec -9 9 Fe b00 Ap r-0 0 Ju n00 Au g00 O ct -0 0 D ec -0 0 Fe b01 Ap r-0 1
darabszám
500000
4.5-ös ábra: a PHP használata Apache modulként [Netcraft]
14
egy CGI programmal: formok lekezelése, dinamikus tartalomelőállítás vagy cookiekezelés. A PHP számos beépített funkcióval segíti a webes programozást, az egyik leghasznosabb tulajdonsága az adatbázisok széles körű támogatása. A PHP nyílt forráskódú program, szabadon letölthető, felhasználható bármilyen célra.
4.2.4 Webszerver A webszerver esetén ugyanúgy, mint a rendszer többi összetevőjénél, elsődleges szempont az ingyenesség, az aktív fejlesztés, az operációs rendszer által való támogatottság, továbbá a PHP-val való együttműködés. Mindezen feltételeknek a sokak által használt Apache HTTP Server felel meg leginkább. A 4.6-os ábra az Apache
sikerességét
mutatja,
a
legelterjedtebb
kereskedelmi
szoftverekkel
(Microsoft IIS, iPlanet Web Server) is felveszi a versenyt.
5. Specifikáció (1-2) A feladat egy web alapú kliens-szerver architektúrájú rendszer létrehozása, pontosabban egy weben keresztül elérhető on-line adatbázis. A kliens szoftver elkészítése nem része a feladatnak, hiszen a webes interfész miatt ez már adott: a rendszer eléréséhez a felhasználó oldalán a hálózati csatlakozáson túl csupán egy egyszerű web böngészőprogram szükséges. A böngészőnek ismernie kell a HTML3at és támogatnia a JavaScript futtatását, ezek a rendszer használatához elengedhetetlenek. A rendszer felhasználói az oktatói gárda és a hallgatóság. A rendszer az oktatók által tanított tárgyakkal kapcsolatos mindennemű számonkérést hivatott támogatni. A rendszer használatával az oktató saját tantárgyaihoz tárgyanként csoportosítva tetszőleges számú ellenőrző kérdést tölthet fel, amelyekhez opcionálisan a helyes válaszok is megadhatóak. A bevitt kérdésekből feladatsorok állíthatók össze, és a feladatsorok vizsgákhoz rendelhetők hozzá. A kérdések a válasz típusát tekintve többfélék lehetnek:
•
szöveges: a kérdésre esszé jellegű válasz adható, a válasz formátumára ezen kívül semmilyen formai vagy méretbeli megkötés nincs;
•
teszt: ez esetben a lehetséges válaszokat is meg kell adni a kérdés mellé, a feladat megoldása során ezek közül választja ki a hallgató az általa helyesnek gondoltakat. A lehetséges válaszok száma tetszőleges, a kérdés bevitele során ezt is meg kell adni;
•
file: megoldásként egy file-t kell feltöltenie a hallgatónak. Ez a típusú kérdés nagy házi feladatok leadásánál vagy mérési gyakorlatok alkalmával lehet hasznos.
Ezek az általános jellegű típusok igény szerint a későbbiekben tetszőleges újakkal egészíthetők ki.
16
A rendszer rendelkezik a tantermek egyszerűsített alaprajzával, hol milyen számítógépek találhatóak. A vizsga kiírásánál az oktató megadhatja, mely teremben mettől meddig tart vizsga, és a teremben lévő munkaállomásokat a vizsgára jelentkezett hallgatókkal összerendelheti. A vizsgára jelentkezettek névsora áttölthető az egyetemen használt Neptun rendszerből. A vizsgáknál megadható a kezdés és a befejezés időpontja is, továbbá opcionálisan a vizsga időtartama, amely megoldást ad arra, hogy minden hallgató pontosan egyforma időt kapjon a feladatsor megoldására még akkor is, ha egyszerre több teremben folyik a vizsga. A termek adatbázisát a rendszer-adminisztrátor módosíthatja. A hallgató a vizsgán bejelentkezik a számítógéppel a rendszerbe, kiválasztja a megoldandó feladatsort, választ ad a kérdésekre, majd „beadja” a megoldott feladatsort. A vizsga során a felügyelő tanár a saját terminálján nyomon tudja követni, melyik gépen ki jelentkezett be, ki hogyan áll a feladat megoldásával, illetve ki az, aki meg sem jelent a vizsgán. A hallgatók azonban nem csak a vizsga vagy a feladat beadás alkalmával találkoznak a rendszerrel, az oktatók lehetőségük van gyakorló feladatok kiadására is, amelyen a hallgatók lemérhetik tudásokat. A vizsgák összeállításán és megíratásán túl a rendszer támogatást nyújt az oktatónak a hallgatók által beadott feladatsorok feldolgozásában. Amennyiben a feladatlap kizárólag teszt típusú kérdéseket tartalmaz, úgy automatizáltan képes azokat kijavítani, osztályozni, de egyéb esetekben is segíti az oktatót a munkában a helyes és a hallgató által beadott válaszok összehasonlításával, a bevitt pontszámok alapján az osztályzásban. A rendszer nem csupán vizsgák, zárthelyi dolgozatok és egyéb, konkrét időhöz és esetlegesen adott számítógéphez kötött számonkérés lebonyolítására alkalmas. Az oktatónak lehetősége van feladatkiadásra és a megoldások begyűjtésére is igénybe venni a rendszert, a hallgató pedig megtekinteni az egyes tárgyakból kiírt vizsgaidőpontokat és feladatbeadási határidőket, és megoldhatja az oktató által bevitt gyakorló-feladatsorokat.
17
A rendszer minden eseményt naplóz. A naplóhoz a rendszer-adminisztrátor fér hozzá, aki az esemény-típust és/vagy az esemény fontossági szintjét megadva kérheti le a bejegyzéseket.
18
6. Tervezés (sw + DB + bizt + UI, 12-15) 6.1 Szoftver és adatbázis tervezés A szoftver tervezése több lépcsőben történik. Elsőként a rendszer adatfolyam ábráinak meghatározására kerül sor. Az adatfolyam modellezés célja, hogy: •
ábrázolja a rendszert és annak környezetét, kijelöli a projekt határát,
•
meghatározza azokat a rendszeren kívüli elemeket, amelyektől a rendszer adatot fogad, illetve amelyeknek adatot szolgáltat,
•
leírja a rendszeren belüli adatfolyamok áramlását,
•
kijelöli az adattárakat, továbbá
•
meghatározza azokat az eljárásokat, amelyek feldolgozzák az adatokat, kiváltják az adatfolyamokat és az adatok tárolását.
Felvázoljuk a rendszer kontextus és 0. szintű diagramját, illetve összetettebb modulok esetén az 1. szintű adatfolyam ábrájának meghatározására is sor kerül. A tervezés második lépésében a rendszer logikai adatmodelljének definiálása történik meg. Ennek feladata a logikailag összetartozó elemi adatok alapján csoportok definiálása és a csoportok közötti összefüggések meghatározásával egy olyan általános leírás megadása, amely: •
egyértelművé teszi a szoftver alkalmazási területét,
•
diagramjai révén pontosan leírja a kommunikációs rendszert,
•
az adatbázis tervezésének alapjául szolgál. A logikai adatmodell meghatározása után sor kerül az adatbázis tábláinak
definiálására, az adattípusok meghatározására és az egyes táblamezők szerepének magyarázatára. Az adattípusok meghatározásakor kihasználtuk a PostgreSQL adatbázis-kezelő által nyújtott előnyöket:
19
•
Szöveges jellegű adatoknál nem szükséges az SQL92 kompatibilis char, ill. varchar típusokat használnunk, hanem megadhatjuk a PostgreSQL-re jellemző text típust, amelynek előnye, hogy nem szükséges a mezőben tárolt szöveg hosszára felső korlátot megadni.
•
PostgreSQL-nél a file típusú kérdések esetén a file-ok eltárolására kétféle lehetőség is adódik. Az egyik, hogy a file-okat a UNIX filerendszer részeként kezeljük, az adatbázisban pedig csak a file nevét tároljuk el, a másik alternatíva pedig, hogy kihasználjuk, hogy a PostgreSQL alkalmas nagyméretű bináris objektumok közvetlenül az adatbázisban történő eltárolására. A tervezés során a második variációra esett a választás, mert ugyan az első eset megvalósítása egyszerűbb és a file-ok elérése is gyorsabb, addig a második változat szigorúbb adatintegritást és nagyobb biztonságot tesz lehetővé.
•
Az adatbázisban a kapcsolótábláktól eltekintve minden tábla, pontosabban a táblákban minden rekord saját azonosítóval rendelkezik. Az ilyen jellegű mezőknél a típus megjelölése serial, ami azt jelenti, hogy az adatbázis-kezelő a tábla létrehozásakor megalkot a serial típusú mezőhöz egy szekvenciát azzal a céllal, hogy ennek a mezőnek alapértelmezett értéke mindig az automatikusan növekvő szekvencia következő értéke legyen. A serial típus tehát valójában egy integer-t jelöl, amely alapértelmezett értékkel is rendelkezik: integer default nextval('szekvencia_név'::text). A szekvencia neve a tábla és a mező nevéből áll össze a következőképpen: _<mezőnév>_seq, pl. subject_sid_seq.
felhasználói nyilvántartás napló szgép- és teremnyilvántartás tantárgyak listája
adminisztrátor
6.1-es ábra: kontextus diagram
21
0. szintű diagram
hallgató
oktató
kérdések, feladatsorok, vizsgák, pontszámok
hallgatók megoldásai, eredmények
vizsgáztató, feladatbeszedő eredményjelző modul
rendszernapló
kérdés, feladatsor és vizsga admin modul
óra session dolgozatjavító modul
szgép- és teremnyilvántartás
felhasználók
hozzáférésellenőrző modul
tantárgyak
naplókészítő modul
felhasználó, szgép, terem és tantárgy admin. modul
adminisztrátor
6.2-es ábra: a rendszer 0. szintű adatfolyam diagramja 22
6.1.2 Logikai adatmodell A rendszer adatbázisának entitás-relációs diagramját mutatja be a 6.3-as ábra:
users 1 n ref_su n 1 subject 1
1
n examination n
1
1
n n
1
n
1
worksheet 1
ref_ew
n 1
n
n ref_wq
1
question 1 n checkbox
1
n
location 1
examinee n
n
1
n
1
1
n
machine
answer
session
log
6.3-as ábra: ER diagram
23
6.1.3 Táblák, adattípusok meghatározása
•
A USERS tábla tartalmazza az oktatók és a rendszer-adminisztrátorok adatait. Ezek az adatok: a belépési név (login), az ehhez tartozó jelszó (passwd), a felhasználó teljes neve (fname), e-mail címe (email), illetve annak jelzése, hogy az adott felhasználó oktatói vagy rendszer-adminisztrátori státusszal
rendelkezik
(professor,
admin).
Megadható
továbbá
egy
megjegyzés (note). (Megjegyzés: a hallgatók nincsenek nyilvántartva a rendszerben.) USERS uid login passwd professor admin fname email note
•
serial NOT NULL text NOT NULL text NOT NULL boolean NOT NULL default 'n' boolean NOT NULL default 'n' text NULL text NULL text NULL
A rendszer által felölelt tantárgyak listája a SUBJECT táblában található. Az egyes bejegyzésekhez a tantárgy neve (name) és a Neptun kódja (code) tartozik. SUBJECT sid serial NOT NULL name text NOT NULL code text NOT NULL
•
Az egyes oktatókhoz tartozó tantárgyakat a REF_SU tábla tartalmazza. Egy tárgy természetesen több oktatóhoz is tartozhat. REF_SU sid integer NOT NULL uid integer NOT NULL
24
•
A WORKSHEET tábla tartalmazza az oktatók által az egyes tantárgyakhoz készített feladatsorokat. A tábla egy megjegyzés mezőt is tartalmaz (note), amely az
oktatóknak
nyújt
segítséget
a
már
elkészült
feladatsor
használatában: itt adhatják meg pl., hogy a feladatsor az adott tárgynak mely témakörét öleli fel, de a megadott szöveg tetszőleges, a lényege annyi, hogy az oktató könnyen beazonosíthassa a feladatsort. Ugyanebben a táblában lehet meghatározni a feladatsorhoz tartozó ponthatárokat (five, four, three, two), amely a későbbiekben a feladatsor javításakor az automatikus osztályzást teszi lehetővé. WORKSHEET wid serial NOT NULL note text NOT NULL sid integer NOT NULL five integer NULL four integer NULL three integer NULL two integer NULL
•
Az egyes tárgyakhoz betáplált kérdések a QUESTION táblában sorakoznak. A tábla mezői megadják a kérdés típusát (type), a kérdés szövegét (text), illetve szöveges és file típus esetén opcionálisan tartalmazza magát a választ is (tans, file, filename, filetype). QUESTION qid serial NOT NULL sid integer NOT NULL type smallint NOT NULL text text NULL tans text NULL file oid NULL filename text NULL filetype text NULL
•
Teszt típusú kérdés esetén a lehetséges válaszok szövegei a CHECKBOX táblában találhatók (text), illetve opcionálisan megadható ugyanitt, hogy az adott kérdéshez tartozó válasz helyes-e vagy helytelen (checked). CHECKBOX cid integer NOT NULL serial qid integer NOT NULL text text NOT NULL checked boolean NULL
25
•
A feladatsorok és a kérdések összerendelését a REF_WQ tábla tartalmazza, és egyben meghatározza az adott kérdés feladatsorbeli sorszámát (seq) és opcionálisan a pontértékét (score). REF_WQ wid integer NOT NULL qid integer NOT NULL seq integer NOT NULL score integer NULL
•
A hallgatók számára adott tantárgyból kiírt vizsgák, ZH-k, illetőleg bármilyen feladatbeadással járó események az EXAMINATION táblában kaptak helyet. Megadható az esemény kezdési és befejezési időpontja (start, finish), továbbá egy időintervallum (duration). Ennek az időintervallumnak a lényege, hogy az oktató tágabb határok között adhassa meg a vizsga időpontját, de ennek ellenére a hallgatóknak csak az időintervallumban meghatározott idő álljon rendelkezésre a feladatsor megoldásához. Értelemszerűen az itt megadott intervallumnak kisebbnek kell lennie, mint a kezdéstől a befejezésig eltelt időnek. Mindezek mellett a táblában megadható a vizsga helyszíne is (lid). EXAMINATION eid serial NOT NULL sid integer NOT NULL start integer NULL finish integer NULL duration integer NULL lid integer NULL
•
A vizsgák lehetséges helyszínei a LOCATION táblában vannak definiálva. A tábla meghatározza az egyes termek neveit (descr). LOCATION lid integer NOT NULL serial descr text NOT NULL
26
•
Az egyes termekben található munkaállomások listáját a MACHINE tábla tartalmazza. Megadja az egyes munkaállomások termen belüli sorszámát (ordnum), x,y pozícióját (x, y) és IP címét (ip). MACHINE mid serial NOT NULL lid integer NOT NULL ordnum integer NOT NULL x smallint NOT NULL y smallint NOT NULL ip host NOT NULL
•
A vizsgák és a feladatsorok összerendelését a REF_EW tábla tartalmazza. Természetesen egy vizsgára több feladatsort is ki lehet adni (A, B, C csoport), de egy feladatsor több vizsgához is hozzárendelhető (lusta tanár esete). REF_EW eid integer NOT NULL wid integer NOT NULL
•
Az EXAMINEE is részben referencia jellegű tábla. Ebben vannak nyilvántartva a vizsgákra jelentkezett hallgatók, és az is, hogy ki melyik feladatsort kapja a vizsgán. Ez utóbbi megadása nem kötelező, az oktatón múlik, meg akarja-e ezt előre határozni, de a vizsga megkezdésekor mindenképp kitöltésre kerül ez a mező. Ezeken kívül tartalmazza a vizsgázó nevét (fname), Neptun kódját (neptun) és opcionálisan az e-mail címét (email), továbbá azt is, hogy a vizsgán mely számítógépnél ül a hallgató (mid). Ez a mező a feladatsorhoz hasonlóan kap értéket: előre is meghatározható az oktató által, de amennyiben nincs megadva, akkor a vizsga megkezdésekor töltődik fel értékkel. EXAMINEE nid serial NOT NULL eid integer NOT NULL wid integer NULL neptun text NOT NULL fname text NOT NULL email text NULL mid integer NULL
27
•
A hallgatók által beadott feladatsorok, illetve az elkészített nagyházi feladatok megoldásai az ANSWER táblában kerülnek eltárolásra. Az adott kérdés típusától függően kerülnek kitöltésre vagy maradnak üresen az egyes mezők. Az egyes mezők jelentése hasonló a QUESTION és a CHECKBOX táblák hasonló nevű mezőivel. ANSWER aid qid tans checked file filename filetype
•
serial NOT NULL integer NOT NULL text NULL boolean NULL text NULL text NULL text NULL
A rendszer két további, a többitől független táblával rendelkezik. Az egyik a LOG, amely a rendszernaplót tartalmazza. Egy bejegyzés megadja az adott esemény időpontját (time); azt, hogy melyik felhasználóhoz kötődik, illetve mi az objektum azonosítója, amelyet érint az esemény (id); a kliens IP címét (ip); az esemény típusát, azaz milyen típusú objektumot érint az esemény (fac); az esemény fontosságát (pri); s végül tartalmaz egy rövid szöveges leírást az eseményről. LOG lid time uid id ip fac pri descr
•
serial NOT NULL integer NOT NULL integer NULL integer NULL inet NULL smallint NOT NULL smallint NOT NULL text NOT NULL
A másik független tábla a SESSION, amely a bejelentkezett felhasználókról tartalmaz információkat. Egy session-bejegyzés információt hordoz a felhasználó pontos belépési időpontjáról (date), továbbá a session-höz hozzárendelt változókról (vars). SESSION sid text NOT NULL date integer NOT NULL vars text NULL
28
6.2 Biztonsági kérdések A
rendszer
elsődleges
célja
a
hallgatók
vizsgáztatása
és
egyéb
számonkéretése, beszámoltatása, így nagy hangsúlyt kell fektetni a rendszert érintő biztonsági kérdésekre. Semmiképpen sem szabad arra számítani, hogy a működő rendszert nem akarják majd feltörni, különösen a BME Villamosmérnöki és Informatikai Karán, ahol a hallgatók már az előadásokon megkapják az ehhez szükséges ismereteket. Számos eset bizonyítja, hogy a hallgatók nagy része gyakran hajlamos a könnyebb utat választani a sikeres vizsga érdekében, és a tananyag elsajátítása helyett más módszereket választ, ha erre adott a lehetősége. Természetesen 100%-os biztonság nem létezik (mint ahogyan valaki egy hálózati biztonsággal foglalkozó fórumon megjegyezte: „még a kikapcsolt gép sem biztonságos, mert azt még el lehet lopni”), de mindent meg kell tenni a teljes körű, kockázattal arányos és folyamatos védelem elérése érdekében. A biztonság kialakításánál a szem előtt tartandó rendszerelemek a környezet, a hardver infrastruktúra és a szoftver elemek. A szoftver további összetevőkre bontható, ezek az operációs rendszer, a webszerver, az adatbázis-kezelő, illetve maga a saját fejlesztésű programkód. A rendszer alapfenyegetettségei a bizalmasság, a hitelesség, a sértetlenség, a rendelkezésre állás és a funkcionalitás. A feladat tehát többrétű: a webes felületnek biztosítania kell, hogy a benne tárolt adatokhoz csak az arra jogosult férjen hozzá, esetenként csak adott helyhez és időhöz kötve, azonban korántsem elegendő a problémának csak a rendszert közvetlenül érintő részével foglalkozni, ugyanekkora figyelmet kell szentelni annak a környezetnek, amelyben majd a rendszer helyet foglal, először ezeket vesszük sorra.
6.2.1 Hálózati topológia A rendszer egyszerűen fogalmazva egy hálózatba kötött számítógépen futó alkalmazás, amellyel a felhasználók a hálózaton keresztül tartják a kapcsolatot. A használt hálózati protokoll a TCP/IP, amely a biztonságot tekintve igen gyenge láncszem. A gondot az jelenti, hogy kellő körültekintés nélkül kezelve a problémát a TCP/IP hálózaton történő forgalom lehallgatható, sőt, hamisítható, miközben a
29
rendszer használata közben adminisztrátori hozzáférést biztosító jelszavak, vizsgakérdések és hasonló, nem publikus adatok is folyhatnak át a hálózaton. A probléma kezelésére több lehetőség is van, ezek együttes alkalmazása hozhat megnyugtató eredményt. Mindenekelőtt biztosítani kell, hogy a számítógép olyan hálózatra kerüljön, ahol fizikailag nem lehetséges a hálózat lehallgatása. Javasolt, hogy a rendszert futtató számítógép a többi számítógéptől külön, saját hálózatba vagy hálózati szegmensre kerüljön. A biztonságot és a rendelkezésre állást növelheti, ha a számítógépre menő hálózati forgalmat tűzfallal korlátozzuk.
6.2.2 Titkosított kommunikáció A lehallgatás és hamisítás problémájára egy másik megoldás a Netscape által bevezetett és elterjedt Secure Socket Layer, röviden SSL. A technika lényege, hogy a kliens és a szerver között a TCP feletti kommunikáció titkosítottan történik:
browser
webszerver
HTTPS SSL TCP IP LAYER2
HTTPS SSL TCP IP LAYER2 LAYER1
LAYER1
A módszernek a lehallgatás és a hamisítás mellett további előnyei is vannak: IP cím, ill. DNS hamisítás ellen is véd. A megoldás az ún. nyilvános kulcsú titkosítás, melynek során a kommunikáló felekhez (jelen esetben a browserhez és. a szerverhez) egy-egy kulcspár tartozik, ahol a kulcspár két részből áll: egy titkos és egy nyilvános kulcsból. A titkos és a nyilvános kulcs szerepe szimmetrikus. Ha N jelöli a nyilvános kulcs alkalmazását, T a titkos kulcsét és x egy kódolandó információ, akkor
30
N(T(x)) = x és T(N(x)) = x A módszer lényege, hogy rendkívül nehéz T-ből N-et meghatározni, továbbá T nem törhető fel választott nyílt szöveggel. A kommunikációban részt vevő feleknek generálniuk kell a maguk részére egy nyilvános/titkos kulcspárt. Ezután a nyilvános kulcsot minél szélesebb körben ismertté kell tenni, miközben a titkos kulcsra értelemszerűen vigyázniuk kell. Bárki, aki titkosított üzenetet akar küldeni, nem kell mást tennie, mint a fogadó nyilvános kulcsával kódolnia az üzenetet. A nyilvános kulcs ismerete nem segít abban, hogy a titkos kulcsot megfejtsük, ezért ha egy üzenetet egy nyilvános kulccsal kódoltunk, akkor már magunk sem tudjuk azt visszafejteni, csakis aki ismeri az adott nyilvános kulcshoz tartozó titkos kulcsot.
A módszer alkalmas titkosítás nélkül csak
hitelesítésre is, azonban ezt a lehetőséget a web technológia nem használjuk ki. A nyilvános kulcsú titkosítás megvalósításához szükséges követelményeket teljesíti például az MIT-n kidolgozott RSA algoritmus. Az RSA algoritmus neve a szerzők nevének kezdőbetűiből származik: Rivest-Shamir-Adleman. Az RSA algoritmus védett, nem ingyenes, tulajdonosa az RSA Security Inc. Biztonság alapelve a nagy számok tényezőkre bontásának nehézsége, például egy 200 jegyű szám felbontása a mai számítógépekkel 4 milliárd évig tart. Az algoritmus a következő: 1. válasszunk két nagy prímszámot (p, q), mindkettő legyen > 10100 2. n = p*q és z = (p-1) * (q-1) 3. d legyen z-hez képest relatív prím 4. keressünk egy olyan e-t, amelyre e*d mod z = 1 Ekkor a titkos kulcs: a (d, n) pár, a nyilvános kulcs: az (e, n) pár Kódolás: C = Pe mod n Dekódolás: P = Cd mod n
31
A kódolás fix méretű blokkokra tördelve történik, a kódolandó blokkok log2n-nél kevesebb bites egységek. A kód feltöréséhez feltöréshez n-et fel kellene bontani p-re és q-ra, hogy z és ebből d meghatározható legyen. Igen fontos, hogy ha valakinek a nyilvános kulcsát használjuk, akkor biztosak legyünk abban, hogy nem hamis, lejárt vagy érvénytelen a kulcs. A kulcsok hitelesítését az ún. kulcstanúsító szervezetek végzik. Egy hitelesített kulcs beszerzése azonban pénzbe kerül, így a jelenlegi rendszer nem hitelesített kulccsal üzemel, amely azért a fent vázolt biztonsági előnyök nagy részét ugyanúgy nyújtja.
6.2.3 Számítógép, operációs rendszer Biztonsági szempontból kritikus a magát a rendszert futtató számítógép biztonsága, hiszen ha valaki plusz jogosultságokhoz jut a gépen, akkor a rendszer teljes adatbázisához is hozzáférhet, akár magát a programot is tetszés szerint módosíthatja. Ennek a veszélynek a minimalizálása miatt javasolt, hogy a számítógépen ne legyenek felhasználók és minél kevesebb szolgáltatás fusson rajta (webszerver, adatbázis szerver, sshd), azaz dedikált szerver legyen. Felhasználók létrehozása azért is ellenjavallott, mert egyrészt a támadó egy felhasználó jelszavát megszerezve könnyebben juthat be a gépre, így egyszerűbben tehet szert plusz jogosultságokra, mintha csak távolról, hálózaton keresztül lenne lehetősége próbálkozni. Másik indok a helyi felhasználók ellen, hogy a PHP kód jelszavakat is tartalmaz, amelyekkel az adatbázishoz lehet hozzáférni, és ezeket a jelszavakat a gépen belül ismét csak sokkal könnyebb megszerezni. Előfordulhat, hogy a gép operációs rendszerében vagy az egyéb futtatott alkalmazásban idővel biztonsági hibákra derül fény, ezért a folyamatos felügyeletre és karbantartásra is szükség van.
6.2.4 A rendszer biztonsági kérdései A rendszer háromféle felhasználótípust különböztet meg, melyekhez különböző jogosultságok tartoznak, ezek a típusok: a hallgató, az oktató és a rendszeradminisztrátor.
32
A legkorlátozottabb hozzáférése a hallgatónak van: ő csak bizonyos feladatsorokhoz férhet hozzá, és természetesen ezeket is csak olvashatja, ill. a kérdésekre válaszokat vihet be, ez utóbbi történik pl. egy vizsga során. Maguk a hallgatók tulajdonképpen nincsenek is nyilvántartva a rendszerben, ez csak felesleges plusz adminisztrációs terhet jelentene. A vizsga során a hallgatónak meg kell adnia a Neptun kódját, a rendszer ez alapján tárolja el a hallgató által bevitt válaszokat. Annak biztosítása, hogy tényleg az a hallgató ül a számítógép előtt, mint akinek a Neptun kódjával a vizsgasor megoldása történik, az a hagyományos vizsgáztatáshoz hasonlóan a felügyelő tanár feladata. A felügyelő tanár szerepe elkerülhetetlen, hiszen hiába történne a hallgatók azonosítása jelszóval és/vagy TIRISZ kártyával, a hallgatók ezeket ugyanúgy elmondhatják, ill. odaadhatják egymásnak, és így könnyedén
vizsgázhatnának
egymás
helyett.
Az
azonosításra
megoldást
jelenthetnének a biometrikus alapokon működő rendszerek, pl. ujjlenyomat-, írisz-, nyelvmintázat vagy DNS vizsgálat, azonban ezek alkalmazása körülményessé és drágává tenné a rendszert, továbbá a hallgatók felügyelete ezeknek az eszközök használata mellett szükséges maradna, hiszen egy hagyományos vizsgához hasonlóan ugyanúgy meg kell akadályozni, hogy a vizsgán a hallgatók egymást segítség a feladatok megoldásánál vagy nem megengedett segédeszközöket használjanak. Az oktató jogosultsága jóval nagyobb a hallgatóénál, a hozzá tartozó tantárgyakkal bármilyen műveletet végezhet: létrehozhat új kérdést, feladatsort, kiírhat vizsgát, ezeket törölheti is, továbbá hozzáfér a hallgatók által beadott feladatsorokhoz, és azokat kijavíthatja, pontozhatja. A rendszeradminisztrátor jogosultsági köre a legszélesebb: joga van mindahhoz, amihez az összes oktatónak, ezen kívül új oktatókat és tantárgyakat vehet fel, és megtekintheti a rendszernaplót.
33
6.3 User Interface A fentebb vázolt rendszer emberekkel kommunikál, így különös figyelmet kell szentelni a felhasználói felület kialakítására. A felületnek nem csak funkcionálisan, hanem vizuálisan is könnyen kezelhetőnek és áttekinthetőnek kell lennie, hogy a felhasználók a rendszert szívesen használják. Nem szabad azt gondolni, hogy a felület kevésbé fontos, mint a mögöttes tartalom, hiszen a legtöbb felhasználó számára a felület jelenti magát a rendszert!
6.3.1 Általános szempontok A menük, dialógusok kialakításánál általános szempont, hogy a rendszeren belül mindenhol legyenek egységesek, érthetőek, egyszerűek, továbbá illeszkedjenek az
ergonómiai
követelményekhez.
Ugyanakkor
viszont
arról
sem
szabad
elfeledkeznünk, hogy a rendszer mégsem átlagos felhasználók számára készül, hanem olyanok számára, akik nap mint nap számítógéppel dolgoznak, a legkülönbözőbb szoftverekkel kerülnek kapcsolatba, a felhasználói felületen alkalmazott felesleges magyarázatok, eltúlzott segítség csak gátolhatják a rendszer kényelmes használatát a gyakorlottabb felhasználók számára. A rendszer első verziója nem tartalmaz design elemeket, grafikákat, ikonokat, színes ábrákat, hanem pusztán szöveges képernyőkkel dolgozik, illetve az űrlapok esetén a HTML által nyújtott lehetőségeket használja ki. A későbbiekben természetesen adott a lehetőség a csinosításra. Amire mindenképp ügyelni kell egy webes felület esetén, az a grafikus állományok mérete, hiszen ezek a szerverről töltődnek le a hálózaton keresztül a felhasználó kattintásai nyomán. Ha ezek a file-ok túl nagyok, úgy a szervert és a hálózatot is erősen leterhelhetik, az oldalak lassabban töltődnek le, a kliensoldalon a böngészőtől is nagyobb erőforrást igényel, vagyis végeredményként a rendszer válaszideje jelentősen megnőhet, ami egy időhöz kötött alkalmazásnál (mint pl. a vizsga) nem szerencsés. A számítógépes adatfeldolgozás egyik nagy előnye, hogy a számítógép képes az adatok bevitelekor bizonyos szintű validációra, így a felhasználó azonnal
34
visszajelzést kaphat az általa bevitt adat helyességéről. Az adatellenőrzés lehetséges szempontjai: szintaktikai és szemantikai ellenőrzés, adat-összefüggés vizsgálat, intervallum ellenőrzés. Hiba esetén a hiba lehetséges okairól tájékoztatni kell a felhasználót, továbbá megoldási javaslatokat lehet tenni. Ha ezt a webes felület lehetővé teszi, a fókuszt a hiba helyére kell állítani. Törekedni kell arra, hogy a felhasználónak minél kevesebb adatot kelljen megadnia az űrlapok kitöltésénél. Ahol lehetséges, biztosítani kell a default értékek automatikus megadásának a lehetőségét. Ha a felhasználó hibát vét, módot kell adni, hogy ezt minél egyszerűbben javíthassa: ne csupán a felhasználó feladata legyen az eredeti állapot visszaállítása és a műveletsor újrakezdése, hanem a rendszer a kontextus megőrzésével visszavonási, visszalépési funkciókkal támogassa ebben a felhasználót. Fontos tényező a biztonság: kritikusabb események esetén mindig megerősítést kérő ablak nyílik fel, hogy ezzel elkerülhetőek legyenek a véletlen, nem szándékos műveletek érvényre jutása. Ilyen esemény pl. az oktató által egy feladatsor törlése, vagy a hallgató által egy vizsga vagy egy feladat beadása. A dialógusok tervezésénél további szempont az utak egyértelmű kijelölése, a felhasználó folyamatosan legyen tájékoztatva arról, éppen merre jár, honnan jött és merre tart. Az ablakok azonos struktúrájú képernyőformákat használjanak, továbbá egy képernyő ne vonatkozzon egyszerre több feladatra. Speciális jellegű a számonkérések során alkalmazott képernyő, itt a kényelemnél fontosabb szempont az, hogy a hallgatók ne lássák egymás megoldásait, ez egyszerűen kisebb fontmérettel megoldható.
6.3.2 Megvalósítási tervek A tervezett HTML felület kereteket (frame) használ, melynek célja a navigáció megkönnyítése és a tájékoztatás. A belépő oldaltól eltekintve minden oldal legalább két keretet tartalmaz: egy felső, vékony keretet, amely mindig a felhasználó aktuális helyzetét jelzi, illetve egy alsót, amelyben a tényleges számítógép-
35
felhasználó párbeszéd folyik. Bizonyos esetekben, ahol ezt az alkalmazás megkívánja, az alsó keret további részekre oszlik, ilyen pl. a kérdésekkel foglalkozó oldal, ahol az adott kérdésre kattintva az alsó keretben megjelenik az arra adott válasz. A navigációs keretben kijelzésre kerül az éppen bejelentkezett felhasználó neve vagy Neptun kódja, az alsó keretben látható oldal címe, illetve itt kapnak helyet olyan gombok, amelyek a rendszeren belüli gyors funkcióváltást teszik lehetővé. A felület kialakítása a következőképpen történik. A felhasználó a belépés után a jogosultságainak megfelelő menürendszerrel találkozik. Hallgató esetén következő lehetőségeket ajánlja fel a rendszer: •
vizsgázás, egyéb feladatbeadás,
•
eredmények megtekintése.
A vizsgázás során a hallgató kiválasztja a megoldandó vizsgasort. Ha a hallgató olyan számítógép előtt ül, amelyre az adott időpontban vizsgát definiáltak, akkor ezt a vizsgasort a könnyebb megtalálás érdekében megkülönböztető jelzéssel látja el. Az eredmények megtekintése hasonló a vizsgázáshoz: ha a hallgató olyan vizsgasort választ ki, amelyet már korábban megoldott, akkor a rendszer csak olvasható módban hozza be a dolgozatot, úgy, ahogy a hallgató azt előzőleg megoldotta, és ha az oktató már kijavította, akkor az egyes feladatok mellett megjelennek a pontszámok és a képernyő alján az osztályzat is. Oktató esetén először ki kell választani egy tantárgyat, és ezután az alábbiak közül lehet választani: •
kérdések szerkesztése,
•
feladatsorok összeállítása,
•
vizsgák, feladatok kiírása,
•
dolgozatjavítás, értékelés.
A kérdések szerkesztésekor megkapjuk az adott tantárgyhoz eddig felvitt összes kérdés listáját. A rendszer kijelzi a kérdés szövegét, ill. hosszabb szöveg
36
esetén annak első 64 karakterét, a kérdés típusát és a kérdésre kattintva a képernyő alsó felén megjelenik a kérdés teljes szövege és amennyiben a tanár ezt megadta, a kérdésre adott helyes válasz is. Itt új kérdést vihetünk be a rendszerbe, vagy a meglévőeket módosíthatjuk és törölhetjük. A feladatsorok adminisztrálása hasonló a kérdésekéhez: a rendszer kijelzi az adott tárgyhoz tartozó összes feladatsort, amelyeket módosíthatunk, törölhetünk, illetve új feladatsort is létrehozhatunk. A feladatsor szerkesztésekor a tantárgy kérdései közül kell kiválasztanunk azokat, amelyeket a feladatsorhoz kívánunk hozzárendelni. A kijelölés meghatározza a feladatok sorszámát, azonban ezt még a következő ablakban módosítani lehet, és ugyanitt lehet megadni az egyes kérdésekre járó pontszámot, illetve a ponthatárokat is itt lehet megadni. A vizsgák menüpontban vizsgát, ZH-t lehet kiírni, illetve ugyanitt tetszőleges feladatbeadást is lehet definiálni, ugyanis az egyszerűség és az egységesség miatt a feladatbeadásra nincs külön beviteli oldal. Ezen a lapon lehet meghatározni az esemény helyszínét, kezdő- és befejezési időpontját, illetve a vizsga maximális időtartamát. Az űrlap lehetőséget ad a hallgatók névsorának file-ból való feltöltésére, de ha úgy egyszerűbb, egy szöveges beviteli mező is rendelkezésre áll, ahova kézzel be lehet gépelni vagy copy & paste-tel be lehet másolni a hallgatói névsort. A feladatsor kiválasztása hasonló a már fentebb részletezett kérdés-feladatsor összerendeléshez. Egy alkalomra természetesen több feladatsor is kiválasztható, így csoportok kialakítása is lehetséges. Ezt követően kerül sor a hallgatók, a feladatsorok és a munkaállomások összerendelésére. Ez a lépés természetesen opcionális. Itt megjelenik a korábban megadott teremben található számítógépek. Az összerendelés során minden számítógéphez hozzá kell rendelni egy hallgatót és egy feladatsort, ez utóbbit természetesen csak abban az esetben, ha az adott vizsgához több feladatsor is hozzá lett rendelve. Lehetőség van az ülésrend automatikus (véletlenszerű) megadására, illetve több feladatsor esetén egy gombnyomással hozzá lehet rendelni egy sorhoz vagy oszlophoz egy feladatsort. A dolgozatok kijavítása a vizsgák menüpont alatt található, itt van lehetőség a hallgatók által beadott feladatok megtekintésére, javítására, pontozására és osztályzására. A dolgozatok között idő- vagy névsorrendben lehet keresni. Miután az 37
oktató kiválasztotta, mely dolgozattal kíván foglalkozni, a rendszer megjeleníti a hallgató válaszait, az oktató által bevitt helyes válaszokat és minden feladathoz egy egysoros szöveges beviteli mezőt, ahol az adott feladatra adott pontszámot lehet beírni. Ahol azt a feladatsor jellege lehetővé teszi, és ha az ehhez szükséges információkat az oktató előzőleg megadta, a javítás során rendszer automatikusan kitölti ezeket a mezőket. Az oldal alján a beállított ponthatárok és az összpontszám alapján megjelenik az osztályzat. Az adatbázis tervezésekor láthattuk, hogy a rendszer felhasználója egyszerre egy személyben lehet oktató és rendszer-adminisztrátor is. Ha a rendszerbe olyan oktató lép be, amely rendszer-adminisztrátori jogosultsággal bír, úgy ő egy kibővített menürendszert kap, az oktatói funkciókon kívül a következő lehetőségek közül választhat: •
felhasználói adatbázis karbantartása,
•
számítógép- és teremnyilvántartás,
•
tantárgy adminisztráció,
•
napló.
Amennyiben a belépett felhasználó rendszer-adminisztrátori jogosultsággal rendelkezik, de nem oktató, úgy természetesen csak ezek az utóbbi funkciók jelennek meg a képernyőjén. A felhasználói adatbázis karbantartása oldalon megkapjuk a rendszerben regisztrált összes felhasználó (azaz az oktatókat és a rendszer-adminisztrátorokat) tartalmazó listát. Ezek közül egyet kiválasztva egy űrlapban megjelennek a felhasználó adatai. Új felhasználót is létrehozhatunk és a meglévők közül törölhetünk is. A számítógép- és teremnyilvántartás oldalon a vizsgák, zárthelyi dolgozatok, egyéb számonkérések helyszíneit adhatjuk meg. Új terem bevitelekor meg kell adni a terem nevét, pl. V2.103, majd a teremben lévő munkaállomások számát. A következő oldalon a munkaállomások adatait kell megadni sorszám szerint
38
rendezve: x,y pozíció és IP cím. A pozíció megadását kis legördülő menü segíti: ki lehet választani, hányszor hány gép van a teremben, és ekkor a pozíció mezők ennek megfelelően automatikusan kitöltésre kerülnek. IP cím megadásakor a legelső számítógéphez megadott cím első három byte-ja az összes többi ablakba magától bekerül, feltételezve azt, hogy az egy teremben található gépek címei azonos C osztálybeli címtartományból kerülnek ki. A
tantárgy
adminisztrációs
felületen
tantárgyakat
hozhatunk
létre,
törölhetünk, illetve meglévőeket módosíthatunk. Létrehozásnál, módosításnál meg kell adnunk azt is, mely oktatókhoz tartozik az adott tantárgy. Napló: a rendszer által rögzített eseményeket tekintheti meg itt a rendszeradminisztrátor. Az események különböző jellegűek és fontosságúak lehetnek. A napló lekérdezésekor ezeket a szempontokat lehet beállítani, továbbá megadható a lekérdezés időintervalluma is.
39
7. Implementálás és tesztelés (6-8) A megvalósítandó rendszer egy webes alkalmazás, így ennek jellegéből adódóan a feladat egy olyan szoftver elkészítése, amely sok, kis, egymástól jól elkülöníthető funkcióval rendelkezik. Ez ugyan megoldható egy nagyobb, bonyolultabb program elkészítésével, de sokkal könnyebben átláthatóbb eredményt kapunk, ha több kisméretű programot állítunk elő, amelyek természetesen közös programkódot is tartalmazhatnak. E különálló programok közös jellemzői, hogy •
a felhasználó egy pontosan meghatározott akciója váltja ki az adott program futását,
•
a programhoz a felhasználótól adatok érkeznek, amelyek alapján a program elvégzi feladatát,
•
a program kimenete egy HTML oldal, amely a felhasználó képernyőjén jelenik meg.
Minden alapfunkciót különálló programok egy csoportja valósít meg, de vannak olyan programrészletek is, amelyek a többi program által közösen használatosak, mint az adatbázis-kezelés, a session-kezelés és a naplózás.
7.1 Közös programkódok Ezek a programrészletek többnyire olyan függvényeket és eljárásokat jelentenek, amelyekre a különböző programokban gyakran, sokhelyütt szükség van: •
adatbázis kezelő függvények
•
naplózás
•
session-kezelés
Megvalósításukat tekintve ezek a kódok külön file-ban kaptak helyet, amelyeket a PHP require() függvényének segítségével ér el a többi program. (A require() működése hasonló a C-beli #include direktívához.)
40
7.1.1 Adatbázis kezelő függvények Ezek a függvények a db_connect.inc és a db_sql.inc file-okban kaptak helyet. A db_connect.inc tartalmazza a db_connect() függvényt, amelynek feladata az adatbázishoz való kapcsolódás, visszatérési értéke a kapcsolat-azonosító:
function db_connect() { $conn = pg_connect("","","","","exam"); if (!$conn) { require('header.inc'); echo "Az adatbázis nem elérhetõ! \n"; require('footer.inc'); } return $conn; }
A következő függvény a db_sql.inc file-ban található, feladata tetszőleges SQL query elküldése az SQL szervernek:
function sql($query) { if (!$GLOBALS["conn"]) { $conn = db_connect(); $GLOBALS["conn"] = $conn; } $res = pg_exec($GLOBALS["conn"], $query); if (!$res) { echo "database query failed\n"; exit; } return $res; }
A függvény először megvizsgálja, van-e élő adatbázis kapcsolat. Ha nincs, kapcsolódik, majd a visszakapott kapcsolat-azonosítót eltárolja egy globális változóban. Ezután elküldi az SQL query-t, a függvény visszatérési értéke pedig a pg_exec() által visszaadott eredmény-azonosító.
41
7.1.2 Naplózás A rutin egyszerű felületet biztosít a többi program számára a naplózásra. A naplózás során alkalmazott módszer a Unix rendszerekből ismerősnek tűnhet: minden esemény mellé naplózásra kerül az esemény típusa és fontossági szintje, ez a megoldás megkönnyíti a naplóban való keresést. Az események típusai jelenleg a következők lehetnek: •
rendszer (LOG_SYSTEM): az egész rendszert érintő események naplózására szolgál,
•
be- és kilépés (LOG_LOGINOUT): be- és kilépések, továbbá a rendszer által történt automatikus kiléptetések (inactivity timeout) feljegyzéseihez,
•
felhasználó (LOG_USER): a felhasználói adatbázisban történt módosítások naplózására,
•
tantárgy (LOG_SUBJECT): tantárgyak, illetve az ehhez tartozó kérdések, feladatsorok, vizsgaalkalmak változásainak nyomonkövetésére,
•
vizsga
(LOG_EXAM):
a
hallgató
által
bekövetkezett
események,
pl. feladatbeadás, •
helyszín (LOG_LOCATION): a számítógép- és teremnyilvántartásban bekövetkezett változások naplózására.
A fontossági szintek: •
hiba
(LOG_ERROR):
súlyos
rendszerhiba
jelzése,
adminisztrátori
beavatkozás szükséges a rendszer további helyes működéséhez, •
figyelmeztetés (LOG_WARNING): kisebb rendellenesség jelzése, a rendszer képes a további működésre,
•
tájékoztatás
(LOG_INFO):
a
rendszerben
bekövetkező
normál
eseményekhez tartozó szint, •
debug (LOG_DEBUG): hibakereséshez ajánlatos
42
A függvény az esemény típusán és fontossági szintjén kívül rögzíti az aktuális időpontot, a kliens IP címét, az esemény kiváltójának felhasználói-azonosítóját, a módosított objektum azonosítóját, továbbá egy rövid szöveges eseményleírást. A naplózó rutin:
7.1.3 Session-kezelés A rendszerhez kizárólag csak a rendszerbe való belépés után lehet hozzáférni. A rendszerhez való első hozzáférés alkalmával a rendszer a felhasználó kilététől függetlenül generál egy ún. session azonosítót, amely egy véletlenszerűen előállított 32 hexadecimális számjegyből álló karaktersorozat. A session létrehozása után számos adatot rendel ehhez hozzá, pl. a kliens IP címét, belépés után a felhasználó kilétét és jogosultságait. A PHP beépített session-kezelője megkönnyítette a feladat megoldását, azonban módosítani kellett rajta. A PHP alapértelmezés szerint a session információkat file-okban tárolja, ez azonban nem felelt meg a célnak. Egyrészt nehézkéssé vált volna a session file-okban tárolt információk közötti keresés, másrészt egy saját megvalósítás nagyobb flexibilitást biztosít a session-ök automatikus lejáratának megvalósításában. Szerencsére a PHP lehetővé teszi a
A függvényben az egyes paraméterek meghatározzák azokat a függvényeket, amelyek az egyes session-eseményeket lekezelik. Ezeknek a függvényeknek az önálló meghívására rendszerint nincs szükség, a PHP ezt automatikusan megteszi.
43
session_handler_open(): feladata a session inicializálása, vagy ha már létező session-ről van szó, akkor a dátum mező frissítése az aktuális időpont alapján. function session_handler_open($save_path, $session_name) { $ret = sql("select count(*) from session where sid = '". addslashes(session_id())."'"); switch (pg_result($ret, 0, 0)) { case 0: sql("insert into session (sid, date) ". "values ('".addslashes(session_id())."', ". time().")"); break; case 1: sql("update session set date = ".time()." ". "where sid = '".addslashes(session_id())."'"); break; default: echo "session id inconsistency: ". pg_result($ret, 0, 0); exit; } return true; }
session_handler_close(): nem használjuk. function session_handler_close() { return true; }
session_handler_read(): a session-höz kötött (regisztrált) változók kiolvasására szolgál. Ezeket a változókat a PHP egyetlen sztringgé alakítja, ez kerül a session táblában eltárolásra. function session_handler_read($key) { return pg_result(sql("select vars from session where sid = '". addslashes($key)."'"), 0, 0); }
session_handler_write(): a session változók beírására szolgál. function session_handler_write($key, $val) { sql("update session set vars = '".addslashes($val). "' where sid = '".addslashes($key)."'"); return true; }
44
session_handler_destroy(): feladata a session megszűntetése, az adatbázisból való törlése. Törölt session-azonosítóval a rendszerbe való belépés nem lehetséges. function session_handler_destroy($key) { sql("delete from session where sid = '". addslashes(session_id())."'"); return true; }
session_handler_gc(): belépett, de kilépni elfelejtett felhasználók automatikus kiléptetésére szolgál. A PHP bizonyos időközönként magától futtatja ezt a függvényt. A függvényben szereplő INACT konstans tartalmazza azt az időtartamot (mp-ben), amely után a rendszer az automatikus kiléptetést kezdeményezi. Ez a konstans a rendszer konfigurációs állományaiban állítható. function session_handler_gc($maxlifetime) { sql("delete from session where date<”.(time()-INACT)); return true; }
Az itt bemutatott függvények a session.inc file-ban szerepelnek, továbbá itt található az a rutin, amely a session-kezelést megindítja, és alapvető ellenőrzéseket is elvégez:
function is_valid_sid($sid) { $ret = sql("select vars from session where sid = '" .addslashes($sid)."'"); if (pg_numrows($ret) != 1) return false; $vars = pg_result($ret, 0, 0); if ($vars == "") return true; ereg('[;\|]ip\|s:[0-9]+:"([0-9\.]+)"', $vars, $tmp); // IP cim if ($tmp[1] != getenv("REMOTE_ADDR")) return false; return true; } if (ereg('^/([0-9a-f]+)/', $REQUEST_URI, $tmp)) { if (is_valid_sid($tmp[1])) { session_id($tmp[1]); } else { // hamis sid eseten visszahajit a legelejere header("Location: /"); exit; } } else { // ha nincs sid, uj sid generalas, session_id(md5(uniqid(rand()))); session_start(); // es redirect az uj sidre header("Location: /".session_id()."/"); exit; } session_register('type','login','professor','admin','ip'); $SID = "/".session_id();
45
Session-kezelésnél alapvető feladat a session-azonosító HTML lapról HTML lapra való folyamatos továbbadása. Erre több lehetőség is adott: •
cookie használata: a session-azonosítót egy ún. cookie-ban tároljuk le a kliensoldalon, amelyet a kliens ezután minden oldalhoz automatikusan elküld. A megoldás előnye az egyszerűség, a PHP minden tekintetben támogatja ezt a módot, hátránya viszont, hogy ez a megoldása rendszer használatához megköveteli a cookie-k engedélyezését;
•
URL-ben továbbítás GET típusú változóként: előnye, hogy nem igényli a cookie támogatást, azonban hátránya, hogy minden egyes oldalon, minden hivatkozásnál tovább kell adni a változót. A PHP ugyan lehetővé teszi egy speciális opcióval, hogy minden hivatkozáshoz automatikusan fűzze hozzá a session-azonosítót tartalmazó változót is, azonban ennek a megoldásnak a hátránya, hogy ez a beállítás az egész webszerverre vonatkozik, így olyan hivatkozásokhoz is bekerül a változó, amelyet nem szeretnénk;
•
URL-ben továbbítás, speciálisan az URL-be kódolva, ez a választott megoldás: előnye, hogy nem szükséges hozzá cookie támogatás, továbbá kiküszöböli az előző megoldás hátrányát is: a session-azonosítót mint egy alkönyvtárat helyezzük el az URL-ben, így a kliens automatikusan megkapja és továbbítja minden egyes kattintásnál. Az URL a következőképpen néz ki: http(s)://szerver.neve/session_azonosító/tényleges_file A megoldás kivitelezéséhez a webszerver konfigurációs állományában egyetlen sort kell hozzáfűzni, lásd a függelékben.
A rendszeren belüli védett oldalakhoz tartozó programok (a belépést végző oldalon kívül gyakorlatilag az összes) a fenti kódot futtatják, így nem létező sessionazonosítóval vagy olyannal, amelyben az IP cím nem egyezik meg a kliens címével, a rendszeren belül semmihez sem lehet hozzáférni, a program rögtön kidobja a felhasználót a főoldalra.
46
7.2 A főbb funkciók implementálása Az egyes funkciókat megvalósító programok szoros kapcsolatban állnak a felhasználói felülettel, mert mint ahogy feljebb is megemlítettük, a felhasználó minden egyes akciójára külön program áll rendelkezésre, amely ezt az akciót lekezeli, a feladatot elvégzi. A megvalósítandó főbb funkciók: •
belépő oldal
•
tanár adminisztrációs felület o kérdések szerkesztése o feladatsorok összeállítása o vizsgák, feladatok kiírása o dolgozatjavítás, értékelés
•
hallgatói felület o vizsgázás, feladatmegoldás o eredmények megtekintése
•
adminisztrátori funkciók o felhasználói adatbázis karbantartása o számítógép- és teremnyilvántartás o tantárgy adminisztráció o napló lekérdezés
Nem ejtünk szót részletesen minden funkcióról, hiszen a megvalósítást tekintve hatalmas különbségek nincsenek az egyes modulok között, az egyes adminisztrációs modulok implementálásakor hasonló technikák alkalmazására került sor. Eltér a többitől a belépő oldal, továbbá részletesebben megvizsgáljuk a tanár adminisztrációs felület egyes részmoduljait.
47
7.2.1 Belépés, authentikáció Belépő oldal a loginout.php file-ban található, ez csupán egy űrlapot tartalmaz, amely bekéri a felhasználó login nevét és az ehhez tartozó jelszót, illetve hallgató esetén a Neptun kódot és opcionálisan a hallgató teljes nevét. Mivel a rendszer a hallgatókat nem tartja nyilván, a belépést csupán egy egyszerű szintaktikai vizsgálat követi. Oktató esetén a vizsgálat egy fokkal összetettebb, le kell kérdezni az adatbázisból a felhasználó adatait. Ezt követően regisztrálni kell a megfelelő session változókat: •
ip: a kliens IP címe
•
status: az authentikáció sikerességét/sikertelenségét jelzi
•
login: a felhasználó azonosítója
•
type: hallgatótól vagy oktatóról/adminisztrátorról van-e szó
•
professor és admin: a megfelelő jogosultságok jelzése
Hallgató esetén részben eltérő változók regisztrálására kerül sor: •
ip: a kliens IP címe
•
status: az authentikáció sikerességét/sikertelenségét jelzi
•
login: a hallgató Neptun kódja
•
type: hallgatótól vagy oktatóról/adminisztrátorról van-e szó
•
name: a hallgató teljes neve
A program a megadott adatok helyességének függvényében a megfelelő oldalra „dobja” a klienst a Location HTTP fejléc alkalmazásával. Hibás jelszó/helytelen adat esetén természetesen visszadob az űrlaphoz, míg helyes adatok esetén a felhasználótól jogosultságaitól függő oldalra jutunk.
48
Az oktató és rendszer-adminisztrátor belépését ellenőrző program:
7.2.2 Oktatói adminisztrációs felület A tantárgy kiválasztása Ahogyan a user interface ismertetésekor már megtudhattuk, az oktató adminisztrációs felülete a tantárgyak bemutatásával indul. Itt egy ún. SELECT ablakban lehet kijelölni azt a tantárgyat, amellyel foglalkozni kívánunk. Ennél az oldalnál már JavaScript kód is szerepel a programban, amely ugyan némi kényelmetlenség árán feladható lett volna, azonban látni fogjuk, hogy a későbbiekben a JavaScript alkalmazása szinte elkerülhetetlen. A program a már megismert jogosultsági ellenőrzések után kilistázza a belépett oktatóhoz tartozó tantárgyakat. A tárgyak közül egyet kell kiválasztani, kérdések, feladatsorok vagy vizsgák adminisztrálásának céljából. JavaScript használatával megoldható, hogy egyetlen SELECT ablakhoz három különböző gombot rendeljünk hozzá, és ezekkel különböző funkciókat érjünk el. Amennyiben az oktató egyetlen tárgyat sem jelölt ki a listából, úgy erre egy popup ablak figyelmezteti. A JavaScript kód:
49
function form_submit(what) { if (document.sidbyname.sid.selectedIndex == -1) { alert('Válasszon ki egy tantárgyat a listából!'); return true; } eval("document.location.href='prof_"+what+".php?sid="+document. sidbyname.sid[document.sidbyname.sid.selectedIndex].value+"'"); return true; }
Ezt rendeljük a nyomógombok onClick eseményeihez:
Kérdések szerkesztése Itt az előző oldalhoz hasonló SELECT ablak tartalmazza a kiválasztott tantárgyhoz tartozó kérdéseket. Az ablak melletti nyomógombok szintén JavaScript kódot futtatnak:
A törlés és az új kérdés létrehozás funkció gombokhoz tartozó kód szerepe, hogy figyelmeztesse a megfelelő kérdés kijelölésére, továbbá törlés esetén megerősítést kérjen a felhasználótól: function form_submit(what) { if (document.qidbytext.qid.selectedIndex == -1) { alert('Válasszon ki egy kérdést a list<E1>bl!'); return true; } eval("document.location.href='prof_"+what+".php?sid="+do cument.sidbyname.sid[document.sidbyname.sid.selectedIndex].value+ "'"); return true; }
function form_delete()
50
{ if (document.qidbytext.qid.selectedIndex == -1) { alert('Válassza ki a törlendõ kérdést a listából!'); return true; } if (confirm("Biztos, hogy töröljem az alábbi kérdést?\n\n"+docu ment.qidbytext.qid[document.qidbytext.qid.selectedIndex].text )) { eval("parent.location.href='prof_q_del.php?qid="+docu ment.qidbytext.qid[document.qidbytext.qid.selectedIndex].value+"' "); } return true; }
A SELECT ablak onChange eseményéhez is tartozik JavaScript, ennek rendeltetése, hogy az adott kérdésre kattintva az alsó keretben megjelenjen a kérdés teljes szövege, továbbá a kérdésre adott válasz. function show_full_text() { if (document.qidbytext.qid.selectedIndex == -1) { return true; } eval("parent.text.location.href='prof_q_fulltext.php?qid="+docu ment.qidbytext.qid[document.qidbytext.qid.selectedIndex].value+"' "); return true; }
A kérdésre adott válasz típusa többféle is lehet. Szöveges és teszt típus esetén egyszerűen megjelenik – ha meg van adva – a válasz. Tesztkérdés esetén a helyes válaszok betűjelei megkülönböztetett színnel, a helytelen válaszok áthúzva jelennek meg. File típus esetén összetettebb a helyzet: a program megjeleníti a file nevét és MIME típusát, majd e típustől függően megjeleníti a file tartalmát és/vagy felajánlja letöltésre. Képet tartalmazó file esetén a kép kisméretben (pontosabban fix 100 pontos magassággal) megjelenik a keret jobb oldalán. A kép megjelenítését, illetve az egyéb file-ok letöltését külön program végzi. Ez a program az adatbázisból letölti a file-t, majd meghatározott MIME típussal, mindenféle módosítás nélkül átadja azt a kliensnek. A MIME típus lehet a file eredeti típusa (letöltés felirat), ez esetben a kliens beállításaitól függ, mi történik a file-lal a letöltés során, vagy az elmentés feliratra kattintva fixen application/octet-stream típussal történik meg a letöltés, amely szokványos esetben a kliensen a file lementése ablak megnyílását eredményezi. Kivételes esetekben szükség lehet a file forrásának a megtekintésére, pl. ha a kliensen az adott MIME típushoz nincs megfelelő szoftver telepítve. Erre
51
szolgál a forrás gomb, amelyre kattintva a letöltő program text/plain típussal adja át a kliensnek a file-t, ami a kliensen a kívánt hatást eredményezi. A letöltést végző program részlete: $res = sql("SELECT file,filename,filetype FROM question ". "WHERE qid=$qid"); $oid = pg_result($res, 0, "file"); $filename = pg_result($res, 0, "filename"); $filetype = pg_result($res, 0, "filetype"); if (empty($oid)) { echo "A file nem található!"; exit; } if ($save == 1) { header("Content-type: application/octet-stream"); } else if ($view == 1) { header("Content-type: text/plain"); } else { if (empty($filetype)) $filetype = "application/octet-stream"; header("Content-type: $filetype"); } header("Content-Disposition: attachment; filename=$filename"); sql("begin"); $fd = pg_loopen($GLOBALS["conn"], $oid, "r"); pg_loreadall($fd); sql("commit");
Feladatsorok összeállítása A főoldal megvalósítása teljes mértékben megegyezik az előzőekben tárgyalttal: hasonló JavaScript kódok találhatók az oldalon megegyező funkciókkal. Új feladatsor létrehozása vagy meglévő módosítása esetén a kérdések kiválasztására két MULTIPLE SELECT ablak szolgál. Az ablakokat PHP-ból generált JavaScript kód tölti fel: a baloldali ablakban található az összes kérdés, a jobboldaliban pedig az ezek közül kiválasztottak. A feltöltést végző függvény: function initform(n, text, value) { var option; len = eval("document.wform.elements[n].length"); option = new Option(text,value); eval("document.wform.elements[n].options[document.wform.element s[n].length] = option"); return true; }
52
A feltöltés a következőképpen néz ki pl.: initform("2","Jelölje meg a helyes válaszokat!","50"); initform("2","Hello world!","1"); initform("2","Írjon C programot...","52"); initform("5","Jelölje meg a hatlábú állatokat!","44"); initform("5","Mennyi 11000110011101 kettes komplemense?","3"); initform("5","Mennyi egy meg egy?","36");
Az első paraméter 2 vagy 5, ez jelzi, melyik SELECT ablakba kell feltölteni az adott kérdést, a második paraméter a kérdés szövege, a harmadik pedig a kérdés azonosítója, a tovább gombra kattintva ezeket az azonosítókat adja át a kliens a következő oldalnak. A két ablakban tetszőleges számú kérdés kiválasztható és a két ablak közötti nyilak megnyomásával átmozgatható a másik ablakba. Az átmozgató függvények: function additem() { var option; len = document.wform.elements[2].length; for (var i=len-1; i>=0; i--) { if (document.wform.elements[2][i].selected == true) { option = new Option(document.wform.elements[2][i].text,docu ment.wform.elements[2][i].value); document.wform.elements[5].options[document.wform.elements[ 5].length] = option; document.wform.elements[2][i] = null; } } return true; } function delitem() { var option; len = document.wform.elements[5].length; for (var i=len-1; i>=0; i--) { if (document.wform.elements[5][i].selected == true) { option = new Option(document.wform.elements[5][i].text,docu ment.wform.elements[5][i].value); document.wform.elements[2].options[document.wform.elements[ 2].length] = option document.wform.elements[5][i] = null; } } return true; }
A tovább gomb megnyomásakor JavaScript kód kijelöli az összes kiválasztott kérdést, így lehet elérni, hogy a kliens valóban az összes kérdés azonosítóját átadja.
53
A következő oldal megjeleníti a kiválasztott kérdéseket. Itt még módosítani lehet a kérdések sorrendjét, illetve meg lehet adni az egyes kérdésekre járó pontszámot és a ponthatárokat. A pontszámok összeállításánál JavaScript program segíti az oktatót: a táblázat alján automatikusan kiíródik az összpontszám.
7.2.3 Tesztelés Az itt fejlesztett rendszer számos egyéb, korábban bemutatott szoftverre épül, melyek helytelen működése az egész rendszer helytelen működését eredményezheti. Ezeknek a szoftvereknek az önálló mélyebb tesztelésétől itt mégis eltekinthetünk, hiszen ezt a feladatot az adott szoftvert fejlesztő csapat folyamatosan végzi, a felszínre került hibákat folyamatosan javítja, és újabb és újabb verziójú szoftvereket adnak ki. Egyetlen feladat ezeknek a szoftvereknek a követése. A tesztelés során mindenekelőtt azt kell megvizsgálni, hogy a szoftver valóban azt csinálja, amit elvárunk tőle. A tesztelés különböző szinteken történik. Hiba javítása esetén először a hibát közvetlenül érintő egységet teszteljük, de ennek helyes működése után az összes olyan modult tesztelnünk kell, amely az adott egységgel kapcsolatot tart. Természetesen 100%-os megoldást csak a kimerítő tesztelés adhat, amikoris minden lehetséges bemeneti adattal megvizsgáljuk az eredményt, azonban ez gyakorlatilag lehetetlen vállalkozás. A rendszer kliens-szerver architektúrájú. Amiért ezt a tesztelés szempontjából fontos kiemelni, az az, hogy könnyen előfordulhat, hogy ugyanaz a programrész azonos bemeneti adatokkal az egyik felhasználónál helyesen működik, azonban máshol, más klienssel próbálva rendellenes viselkedést mutat. Az implementáció során a Netscape Communicator 4.76-os, a Netscape Communicator 6-os és az Internet Explorer 5.5-ös verziójával történt a rendszer tesztelése, és már ezeknél a web browserek esetén is számos eltérés volt megfigyelhető. Egyik különbség a SELECT ablakok viselkedése, ha abba JavaScript-tel helyezünk el vagy veszünk el elemeket. NS6 és IE esetén a SELECT ablak szélessége dinamikusan változik a beés kivett elemek hosszától függően, míg NS4-nél mindvégig olyan széles, mint a HTML oldal kirakása pillanatában. NS6 és IE esetén ezért szükségessé vált az
54
elemek bizonyos karakterszám feletti csonkolása, NS4 esetén pedig különböző trükköket lehet alkalmazni: a HTML oldalban a SELECT mezőbe egyetlen, üres sort helyezünk el ( -kel kitöltve, hogy ne is látszódjon a képernyőn), amelyet később JavaScript-tel kitörlünk, így tetszőleges méretűre állíthatjuk a SELECT ablak szélességét. A JavaScript alkalmazása miatt azok a browserek, amelyek hivatalosan sem támogatják ezt a nyelvet, szóba sem jöhetnek a rendszer használatára, a tesztelést így a Netscape, az Internet Explorer és az Opera különböző verzióira lehet szűkíteni. Fontos megjegyezni, hogy az operációs rendszer is szerepet játszhat a browser működésében, pl. egy Unix alatt futó Netscape bizonyos esetekben más viselkedést mutat, mint egy MS Windows alatti. Tesztelés során meg kell vizsgálnunk a szoftver terhelhetőségét, amely jelenti a sok felhasználó egyidejű használata melletti és a nagyobb adatmennyiség okozta sebességlassulást mérését. Elképzelhető az is, hogy pl. indexhatár vagy egyéb korlát elérése miatt a rendszer egyáltalán nem is terhelhető egy bizonyos szint fölé. A tesztek közül a legvégső az ún. akceptancia teszt, amely során a késznek gondolt rendszert a fejlesztő egy vállalkozó felhasználói csoport kezébe adja. Alfa tesztelésről beszélünk, ha ezt a tesztet házon belül végzik, beta teszt pedig, ha kvázi idegenek számára tesszük elérhetővé a szoftvert. E tesztelés azért fontos, mert a szoftver fejlesztője a tervezés és az implementálás során nem gondol valamire, akkor valószínűsíthető, hogy a tesztelés során sem veszi észre a problémát. Ezek a tesztek még váratnak magukra.
55
8. Értékelés (1-2) Egyik legnagyobb problémának azt érzem, hogy a feladat megfogalmazása során csak kevés véleményt volt alkalmam meghallgatni, így valószínűsíthetően számos funkció jelenlegi formájában nem lesz maradéktalanul alkalmas a neki szánt feladat betöltésére. A szoftver még korántsem nevezhető késznek, így bizonyos modulok implementálása és a komolyabb tesztelési fázisok is későbbre maradnak. Biztonsági szempontok: a jelenlegi megvalósításnak hátránya, hogy ha valaki megszerzi egy éppen belépett másik felhasználó session-azonosítóját, és ha az illető el tudja érni, hogy azonos IP címről látsszon a szerver felé (pl. a másik felhasználóval azonos proxy használata), úgy hozzá lehet férni a másik felhasználó adataihoz, a jogosultságaival módosításokat lehet véghezvinni. Továbbfejlesztési lehetőségek •
a rendelkezésre álló idő folyamatos kijelzése a hallgató számára a vizsga során
•
a kérdésekhez tetszőleges számú file melléklet csatolási lehetőség
•
webes felület csinosítása, design
•
valódi CA által aláírt szerver oldali certificate használata
•
authentikáció kliens oldali certificate-tel
A dolgozat végén szeretnék köszönetet mondani.....
56
9. Irodalomjegyzék, források (1-2) [1] a Központi Statisztikai Hivatal adatai alapján [2] ftp://nis.nsf.net/statistics/nsfnet/1992-1994 [3] http://www.netcraft.com/Survey/ [4] Kiss István: A Jáva testvérkéje: JavaScript http://home.euroweb.hu/infopen/cikkek/java/javascr.html, 1996. [5] dr. László Zoltán: Programozás technológiája Műegyetemi Kiadó, 1993. [6] Hegedüs Heléna, Sinkóné Mányoki Andrea: Az információ-rendszerek elemzésének és tervezésének a gyakorlata SZÁMALK Kiadó, 2001. ISBN: 963 553 354 3 [7] UNESCO, Virtual Learning Communities adatbázis http://www.szit.bme.hu/vlc/ PHP dokumentáció: http://www.php.net/manual/en/ PostgreSQL dokumentáció: http://postgresql.bnv-bamberg.de/develcorner/docs/
10. Függelék A melléklet – Távoktató szoftverek
•
Asymetrix Librarian, Asymetrix Learning Systems Inc. http://www.asymetrix.com/
•
Blackboard CourseInfo, Blackboard Inc. http://www.blackboard.com/
57
•
ClassNet, Iowa State University Computation Center http://classnet.cc.iastate.edu/
•
Convene Learning Internet Platform, Convene http://www.convene.com/
•
CyberProf, University of Illinois, Department of Physics http://www.howhy.com/home/index.html
•
CyberWISE Online, The Saratoga Group http://www.saratogagroup.com/
•
Digital Trainer, MicroMedium Inc. http://www.micromedium.com/
