Studentova berli ka III Jádro aplikace

ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Bakalá ská práce Studentova berli ka III Jádro aplikace Jaromír Van k Vedoucí práce: Ing. Ji í Chludil Studijní program: Softwarové technologie a management, Bakalá ský Obor: Softwarové inºenýrství 24. kv tna 2010

iv

v Pod kování Touto cestou bych rád vyjád il pod kování Ing. Ji ímu Chludilovi, vedoucímu této práce, za jeho as a ochotu p i spole ných konzultacích. Dále pak koleg m Tomá²ovi Králíkovi a Bc. Lu ku Chmurovskému za bezchybnou týmovou spolupráci. V neposlední ad bych rád pod koval svým nejbliº²ím, to jest své rodin a hlavn p ítelkyni, která se mnou má p ese v²e bezmeznou trp livost. Zapomenout bych nem l ani na eský hokejový tým na MS 2010, jehoº neuv itelné výkony zp sobily, ºe jsem málem nestihl dokon it tuto práci v as.

vi

vii Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Praze dne 24. kv tna 2010.............................................................

viii

Abstract This paper describes the design and subsequent implementation of a kernel of the Student's crutch system that has been developed in recent years in bachelor and master thesis. Student crutch system solves the problem of electronic communication between students, instructors and lecturers. The purpose of this paper is to design a new architecture of the system to detach the central part with the data storage from other plugins. Abstrakt Tato práce se zabývá návrhem a následnou realizací jádra systému Studentova berli ka, který byl vyvíjen v minulých letech v rámci bakalá ských a diplomových prací. Systém Studentova berli ka e²í problematiku elektronické komunikace mezi studenty, cvi ícími a p edná²ejícími. Ú elém této práce je navrhnout novou architekturu celého systému tak, aby do²lo k odd lení centrální ásti s datovým úloºi²t m od ostatních roz²i ujících plugin. ix

x

Obsah 1 ²vod 1 2 Popis probl c mu, specikace c le 5 2.1 SouÄ asn stav syst c mu Studentova berliä ka.......... 5 2.2 Specikace c lˆ a poˆ adavkˆ na syst c m............ 7 3 Anal za 9 3.1 Problematika komunikace........................ 9 3.2 Existuj c informaä n syst c my.................. 10 3.2.1 Univerzitn informaä n syst c my............. 10 3.2.2 Syst c my pro podporu jednotliv ch pˆtm edmätˆ... 11 3.2.3 Historie syst c mu Studentova berliä ka........... 11 3.3 Volba programovac ho jazyka...................... 13 3.3.1 Java Enterprise Edition..................... 13 3.3.2 PHP................................ 14 3.3.2.1 V hody PHP..................... 15 3.3.2.2 Nev hody PHP.................... 15 3.4 Datab zov c ³loˆ iˆ tä, komunikace s datab z....... 16 3.4.1 Rozhran PDO.......................... 16 3.4.1.1 Prepared statements.................. 17 3.4.1.2 V hody a nev hody pouˆ it PDO........ 19 3.4.1.3 PˆTM enositelnost SQL................. 19 3.4.2 V bär datab zov c ho stroje............... 20 3.4.3 Historie MySQL.......................... 21 3.4.4 V hody MySQL......................... 21 3.5 ObjektovÄ-relaÄ n mapov n (ORM).............. 21 3.5.1 Moˆ nosti ORM v jazyce PHP................. 22 3.5.1.1 PHP ActiveRecord................... 22 3.5.1.2 Doctrine......................... 23 3.5.2 Vlastn framework....................... 25 xi

xii OBSAH 4 N vrh ˆTM eˆ en 27 4.1 Celkov pohled na architekturu.................... 27 4.2 Architektura j dra........................... 27 4.2.1 Datab zov vrstva...................... 28 4.2.2 PDO vrstva............................ 28 4.2.3 Vrstva entit............................ 28 4.2.4 Core facade............................ 29 4.2.5 Vrstva Web services........................ 29 4.3 Interakce mezi vrstvami......................... 29 5 Realizace 33 5.1 N vod jak rozˆ ˆTM it funkcionalitu j dra........... 33 5.1.1 Datov c ³loˆ iˆ tä..................... 33 5.1.2 Entity............................... 35 5.1.2.1 PˆTM id v n nov ch entit........... 36 5.1.3 Core facade............................ 36 6 Testov n 39 6.1 Testov n pˆtm i implementaci.................... 39 6.2 Testov n v provozu.......................... 39 6.3 Uk zka.................................. 39 7 Z vär 41 7.0.1 Vize do budoucna......................... 41 8 Seznam pouˆ it ch zkratek 43 A Uk zka zdrojov c ho k ªdu entity 47

Seznam obrázk 2.1 SouÄ asn podoba Studentovy berliä ky. Zdroj [1]......... 6 3.1 Uk zka prvn verze syst c mu Studentova berliä ka. Zdroj [1].. 11 3.2 Platforma Java EE............................ 14 3.3 Vloˆ en abstraktn datov vrstva PDO.............. 17 3.4 Architektura frameworku Doctrine................... 24 4.1 Celkov pohled na architekturu syst c mu Studentova berliä ka. 30 4.2 Uk zka interakce mezi vrstvami j dra................ 31 5.1 Uk zka pˆtm id van c ho datov c ho ³loˆ iˆ tä....... 34 6.1 Uk zkov aplikace j dra...................... 40 xiii

xiv SEZNAM OBRÁZK

Seznam tabulek 3.1 Podporovan c datab zov c syst c my.............. 16 xv

xvi SEZNAM TABULEK

Kapitola 1 Úvod Studium na dne²ní moderní vysoké ²kole klade na studenty vysoké nároky a velké mnoºství povinností. Aby mohl student t mto nárok m vyhov t, musí být v prvé ád o svých povinnostech a výsledcích co nejlépe informován. D leºité je najít kompromis mezi náro ností na drahocenný as cvi ícího a informovaností studenta. K e²ení tohoto problému byla v p edchozích letech vyvinuta aplikace s názvem Studentova berli ka, jejíº autor Ing. Ji í Hunka se na vývoji podílel od akademického roku 2005/2006. A i nyní je k dispozici jako externí konzultant. Projekt Studentovy berli ky vznikl pod odborným vedením Ing. Ji ího Chludila, jako jednoduchý nástroj pro zefektivn ní administrativních úkon nutných pro vedení cvi ení (evidence hodnocení, docházky, semestrálních prací). Z jednoduchého systému na po átku se v pr b hu n kolika let stal relativn komplexní nástroj. Problémem sou asné verze, která je nasazena v ostrém provozu, je, ºe se jedná z pohledu architektury o monolitickou aplikaci tvo enou jedním autorem (který je také jediný, jenº se v ní dokáºe orientovat). A koli se systém v praxi osv d il, nebyl od po átku navrhován tak, aby mohl absorbovat mnoºství vylep²ení, které se pozd ji objevilo. Z toho vyplývá, ºe systém není roz²i itelný o nové poºadované funkcionality. Nejd leºit j²ím nedostatkem je, ºe systém není p ístupný p es ºádné vn j²í rozhraní a tudíº nespl uje poºadavky na integrovatelnost s ostatními aplikacemi a pluginy (které byly postupn navrhovány v minulých letech). Tato práce navazuje na bakalá skou[1] a diplomovou[2] práci Ing. Ji ího Hunky, autora sou asné podoby systému Studentova berli ka. V poslední uvedené práci její autor s ohledem na provedenou analýzu v záv ru zmi uje, ºe pro dal²í rozvoj a roz²i ování se jako nejlep²í cesta jeví celý systém kompletn p ed lat. Vzhledem k rozsáhlosti byl tento úkol rozd len do t í samostatných prací: 1

KAPITOLA 1. ÚVOD Studentova Berli ka III Databáze základního jádra (Tomá² Králík) Studentova Berli ka III Jádro aplikace (Jaromír Van k) Studentova Berli ka III (Bc. Lud k Chmurovský) Tato práce se bude zaobírat druhým bodem jádrem aplikace. Klade si za cíl analyzovat a navrhnout e²ení nové architektury s ohledem na n kolik základních poºadavk, které vyplyvají ze zadání: Portabilita Jádro musí být navrºeno tak, aby dal²í vývoj Studentovy berli ky nebyl omezen jen na jednu platformu, p ípadn jeden programovací jazyk. Do budoucna se po ítá s tím, ºe roz²i ující pluginy budou vytvá eny r znými týmy, v r zných programovacích jazycích a r zných platformách, v etn mobilních telefon. Roz²i itelnost Architektura jádra musí být navrºena tak, aby bylo umoºn no jednoduché p idávání nových funkcionalit za podmínky, ºe struktura aplikace z stane maximáln p ehledná. P enositelnost Protoºe sou asné verze systému je pevn svázána s jedním typem databázového stroje, chci navrhnout jádro tak, aby p ípadné poºadavky na migraci na jiný typ SQL databáze p inesl co nejmén práce. Bezpe nost Systém Studentova berli ka nakládá s relativn citlivými osobními údaji. Je krajn d leºité zaru it, ºe se data nedostanou do nepovolaných rukou. Transparentnost P es v²echny p edchozí vlastnosti musí z stat systém maximáln transparentní a p ehledný. A to z dvou d vod : Na vývoji jádra nebude spolupracovat v budoucnu pouze jeden lov k, ale celý tým, jehoº lenové se budou v pr b hu asu obm ovat. Ve zdrojových kódech se musí orientovat i nov p íchozí lenové, kte í se systémem nemají ºádnou p edchozí zku²enost. Systém Studentova berli ka má ambice být nasazen v ostrém provozu v rámci univerzity. P edtím ale musí být prov en odpov dnými osobami, ºe spl uje nároky na bezpe nost a spolehlivost. Proto musí z stat maximáln transparentní a p ehledný, aby toto prov ení v bec bylo proveditelné. 2

Kapitola 2 Popis problému, specikace cíle V této kapitole budou podrobn ji rozebrány d vody, pro byla tato práce zadána a zárove cíle, kterých chceme dosáhnout. 2.1 Sou asný stav systému Studentova berli ka A koliv sou asná verze Studentovy berli ky aº na drobné detaily dosta uje pro p edm ty DSA, TIN, WMM a dal²í, i její autor (Ing. Ji í Hunka) ve své práci p ipou²tí, ºe systém bude t eba pro dal²í rozvoj celý p ed lat: Vizí do budoucna je p evést vlastní Studentovu berli ku v pouhé GUI a ve²keré dal²í innosti ponechat na databázi. Toto rozvrºení by spole n s vyuºitím protokolu SOAP umoºnilo kompletní napojení na jakékoli roz²í- ení, jinou aplikaci i vlastní spojení i s GUI Studentovy berli ky. Ideálním postupem by bylo celou Studentovu berli ku napsat znova. Nejedná se pouze o silná slova, ale o ideální postup, který se navrhuje projekt m, které dosp jí do této fáze.[2] Studentova Berli ka je v podstat typická webová aplikace napsaná v jazyce PHP v dob, kdy PHP po ádn nepodporovalo OOP rysy programování a pomocné frameworky teprve za ínaly vznikat. Z toho nep ímo vyplývá ºe GUI je úzce spojený s aplika ní logikou, aplikace nemá ºádnou architekturu, tudíº není moºno ji dále roz- ²i ovat, nespl uje ani nároky nároky na integrovatelnost s ostatními aplikacemi a pluginy. Tyto zmín né body budou rozebrány více v následující kapitole shrnující cíle této práce. 3

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE Obrázek 2.1: Sou asná podoba Studentovy berli ky. Zdroj [1] V minulém roce (2008/2009) byly zárove rozpracovány první verze plugin, které roz²i ují funkcionalitu Studentovy berli ky. V sou asnosti jsou n které pluginy samostatn funk ní, ale neexistuje ºádná moºnost, jak je propojit se samotným systémem. To je jeden z dal²ích d vod, pro je nutné architekturu Studentovy berli ky modikovat tak, aby poskytla podporu t mto roz²í ením. 2.2 Specikace cíl a poºadavk na systém Hlavním cílem nové verze Studentovy berli ky je, jak jiº bylo zmín no, rozd lit p - vodní monolitickou architekturu na dv samostatné ásti: Jádro Zapouzd uje datová úloºi²t a základní funkcionalitu Studentovy berli ky jako evidenci hodnocení test, docházky a semestrálních prací. Dále poskytuje vn j²í rozhraní pro p ístup k dat m pro ostatní pluginy. Na jád e bude do budoucna spolupracovat malý tým 23 ov ených lidí, kte í jako jedinní budou mít p ístup ke celé databázi a v²em dat m Studentovy berli ky. 4

2.2. SPECIFIKACE CÍL A POšADAVK NA SYSTÉM Pluginy Jsou samostatnými aplikacemi vyuºívajícími rozhraní jádra pro p ístup k dat m, roz²i ují funkcionalitu Studentovy berli ky nad rámec základních poºadavk. Výhodou plugin je, ºe existuje moºnost selektivního omezení p ístupu jen k vymezené ásti dat, tudíº je m ºe vyvíjet kdokoli bez rizika úniku nebo ztráty d leºitých dat. Nap íklad bude vznikat nový plugin, který dostane právo na p ístup pouze k seznamu student na jednotlivých cvi eních bez práva zápisu. To má výhodu i z edukativního úhlu pohledu. Autor nového pluginy pracuje s ostrými aktuálními daty, má p ístup do Studentovy berli ky, vyzkou²í si moºnosti porpojení, ale zárove je zaji²t na bezpe nost proti necht ným chybám. Dobrým p íkladem pluginu m ºe být generátor test, jehoº autorem je Franti²ek Kraml (projekt vzniká jako paralelní bakalá ská práce s touto). Toto rozd lení sebou p iná²í mnoho výhod a moºností, zejména: Moºnost ud lat systém portabilní. Je jisté, ºe do budoucna existuje poºadavek, aby Studentova berli ka nebyla jen webová aplikace. Po ítá se s tím, ºe pluginy budou vytvá eny r znými týmy, v r zných programovacích jazycích a na r zných platformách. Po ítá se i s tím, ºe by Studentova berli ka mohla mít svého tenkého klienta na r zných p enosných za ízeních jako jsou mobilní telefony, PDA apod. Proto musí být jádro navrºeno tak, aby programování nebylo omezeno jen na jednu platformu. Neopomenutelným podstatným poºadavkem je roz²i itelnost. Je d leºité, aby architektura jádra byla navrºena tak, ºe p jdou snáze p idávat nové funkcionality. Tzn. pokud n kdo vytvo í n jaký nový plugin, bude sta it do jádra implementovat novou komponentu. Z poºadavk na roz²i itelnost vyplývá i poºadavek na p enositelnost mezi r znými typy SQL databází. P edchozí a nyní i na²e sou asná verze pracuje na databázi MySQL. V budoucnu m ºe nastat poºadavek na migraci projektu na jiný lep²í databázový stroj. Aplikace by proto m la být navrºena, tak aby tato zm na p inesla co nejmén práce. Dal²ím d leºitým pojmem je bezpe nost. Systém Studentova berli ka nakládá s relativn citlivými osobními údaji (hodnocení student ). Je krajn d leºité zaru it, ºe k t mto dat m nebude mít p ístup nikdo nepovolaný, a to i v p ípad pokud se vyskytne n jaká bezpe nostní slabina v naprogramovaném pluginu. 5

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 6

Kapitola 3 Analýza V této kapitole budou postupn probrány kroky vedoucí k návrhu jádra systému Studenova berli ka. Nejd íve se okrajov zam íme na pr zkum existujících systém v rámci univerzity ƒvut. Poté se seznámíme s historií vývoje systému Studentova berli ka, abychom si ujasnili, z eho tato práce vychází a jak nejlépe na p edchozí práce navázat. Dále provedeme analýzu a porovnáme r zné technologie jako programovací jazyky nebo databázová úloºi²t, které v sou asné dob p ipadají pro vývoj aplikace tohoto typu v úvahu. A na záv r analýzy je proberene problematiku ORM mapování datových objekt do rela ních databází. 3.1 Problematika komunikace V n kterých p edm tech není p edávání informací student m o jejich výsledcích vy e- ²eno, nebo je vy e²eno pouze provizorn, coº vede k n kterým nep íjemným jev m: cvi ící nosí výsledky test pouze v písemné form u sebe, nejsou nikde zve ejn ny studenti musí na výsledky ekat minimáln týden i p esto, ºe testy jsou opraveny d íve pokud student na cvi ení absentuje, nemá ²anci se své výsledky dozv d t studenti poté asto pí²í osobní e-maily s ºádostí o sv j výsledek, coº zdrºuje jak cvi ící, tak samotné studenty 7

KAPITOLA 3. ANALÝZA cvi ící zve ej uje výsledky na svých osobních webových stránkách neexistuje ºádný ociální rozcestník jednotlivých webových stránek, student tak netu²í, kde výsledky hledat údrºba vlastních stránek je pro cvi ícího zbyte n asov náro ná studijní výsledky jsou povaºovány za osobní údaj a nem ly by být bez souhlasu zve ej ovány 3.2 Existující informa ní systémy Na základ zmi ovaných nep íjemností vznikají r zné pomocné nástroje, které komunikaci mezi studenty a kantory zjednodu²ují. V rámci ƒvut, potaºmo Fakulty elektrotechnické existuje ada systém, které toto e²í. Jejich problémem ov²em v t- ²inou je, ºe kaºdý takový systém vystupuje sám za sebe, není nijak integrován s ostatními a není moºnost, jak ho dále vylep²ovat a roz²i ovat. Typicky se tak stává, ºe student pot ebuje ke svému fungování v rámci ²koly n kolik r zných uºivatelských jmen a hesel, aby do r zných systém mohl p istupovat. 3.2.1 Univerzitní informa ní systémy Jednou skupinou systém pro podporu výuky jsou velmi rozsáhlé informa ní systémy zam ené na studium na vysoké ²kole jako na celek. P íkladem takového systému je Komponenta Studium (známá jako KOS) doprovázející studenty po celou dobu studia na v²ech fakultách ƒvut. KOS umoº uje student m zápis p edm t, tvorbu a zobrazení rozvrhu, p ihla- ²ování ke zkou²kám, p ehled pln ní studijního plánu, p ehled známek z absolvovaných p edm t a adu dal²ích funkcí, které z velké ásti nahrazují osobní komunikaci se studijním odd lením.[4] A koli by se mohlo zdát, ºe informa ní systém KOS s tématem Studentova berli ka nesouvisí, není to pravda. V²echny systémy v rámci ƒvut, v etn Studentovy berli ky, by m ly být schopné se systémem KOS kooperovat, aby nedocházelo ke zbyte né duplikaci údaj. Pro systém Studentova berli ka bude asem t eba vy e²it importování dat ze systému KOS, coº je v sou asné dob zna n problematické, ale není to sou ástí této práce. 8

3.2. EXISTUJÍCÍ INFORMAƒNÍ SYSTÉMY 3.2.2 Systémy pro podporu jednotlivých p edm t Jak uº bylo zmín no. Nejjednodu²²í formou systému pro podpory je soubor statických webových stránek. Tento p ístup pouºívá Service - K336 Community Web Server 1, který pouºívá Katedra po íta. Lep²í moºností je vyuºití systému zaloºeném na koncepci wiki (pouºívá nap íklad Eduweb 2 ), z d vodu men²í náro nosti p i tvo ení a aktualizaci obsahu. Ideálním e²ením je pouºití úzce specializovaného systému, který je vytvo en p ímo a pouze pro podporu výuky. Takovým systémem je práv Studentova berli ka 3. 3.2.3 Historie systému Studentova berli ka První verze Studentovy berli ky byla vytvo ena v zimním semestru 2005/2006 pro pot eby p edm tu DSA (Datové Struktury a Algoritmy) vedeným Ing. Ji ím Chludilem. Jednalo se (alespo ve srovnání se sou asnou podobou) o primitivní dynamickou stránku, která umoº ovala zadávat a prohlíºet hodnocení v daných t ídách. Obrázek 3.1: Ukázka první verze systému Studentova berli ka. Zdroj [1] V druhé verzi do²lo k zobecn ní systému, aby mohl být pouºit i v jiných p edm tech neº jen DSA. Nová verze p inesla mnohá vylep²ení jako moºnost evidovat docházku nebo zadávat semestrální práce a poté evidovat jejich výsledky. Od roku 2007 je systém pouºíván v ostrém provozu pro p edm ty TIN (Teoretická informatika) a DSA (Datové struktury a algoritmy). Podrobnosti k t mto dv ma verzím lze nalézt v bakalá ské a diplomové práci jejich autora Ing. Ji ího Hunky [1]. 1 http://service.felk.cvut.cz/service.html 2 http://eduweb.fel.cvut.cz/ 3 http://berlicka.jagu.cz 9

KAPITOLA 3. ANALÝZA V dal²ích letech, konkrétn v akademickém roce 2008/2009, bylo rozhodnuto, ºe dal²í vývoj Studentovy berli ky bude sm ován k modulární architektu e. V souvislosti s tím mohla být zahájena práce na n kolika paralelních samostatných projektech, které funkcionalitu Studentovy berli ky roz²i ují: Plug-in support (BP) Marek Sacha Prvotní návrh architektury celé aplikace zaloºené na web services. Zde se poprvé objevuje my²lenka odd lit samostatn jádro s datovým úloºi²t m a ostatní pluginy. Managment webu semestrálních prací (BP) Jakub Fi²er Návrh a implementace roz²í ení Studentovy berli ky o funkcionalitu spojenou se zadáváním, odevzdáním semestrálních prací, systém se zabýval i primitivní kontrolou plagiát. Automatické vyhodnocení test (BP) Petr Kotek Problematika automatického vyhodnocování papírových ru n psaných test. Systém byl dotaºen do podoby, kdy rozpoznával pouze výsledné bodové hodnocení a jméno studenta. Tyto informace potom mohl samostatn zadávat do tabulky výsledk v hlavním úloºi²ti Studentovy berli ky. Generování test (BP) Ji í And l V sou asné dob prioritní projekt, v jehoº vývoji pokra uje kolega Franti²ek Kraml v rámci své bakalá ské práce. Roz²í ení slouºící ke generování zadání test doslova na míru pro kaºdého studenta. Zjednodu²en e eno aplikace vybírá otázky náhodn z p edem nastavených okruh, coº na jednu stranu zaru uje, ºe v²echny testy budou ze stejné látky a srovnateln obtíºné, ale zárove kaºdý test bude rozdílný, tudíº nebude moºno opisovat. 3.3 Volba programovacího jazyka P i výb ru programovacího jazyka pro webovou aplikaci tohoto typu p ipadaly v sou asné dob v úvahu dv nejpouºívan j²í varianty. Jazyk Java na platform Java EE, nebo skriptovací jazyk PHP 4. Pro realizaci byl vybrán, i p es mnoºství nevýhod s ním spojených, jazyk PHP. Bylo to hlavn z d vod : 4 http://php.net/ 10

3.3. VOLBA PROGRAMOVACÍHO JAZYKA P vodní verze Studentovy berli ky je také postavena na PHP Osobní preference a zku²enost autora ƒást projektu (rozhraní web services) bylo rozpracováno v p edchozím semestru v jazyce PHP 3.3.1 Java Enterprise Edition Java EE (d íve ozna ovaná jako J2EE nebo Java 2 Enterprise Edition) je platforma pro vývoj tzv. enterprise aplikací. Poskytuje sadu specikací pro vytvá ení a provoz v t²ích distribuovaných multivrstevných Java aplikací. Specikace byla vytvo ena rmou Sun Microsystems. B hovým prost edím pro tyto aplikace je tzv. aplika ní server. Sou ástí platformy Java EE jsou p edev²ím specikace pro: vývoj webových aplikací - Java Servlets, Java Server Pages (JSP), Java Server Faces (JSF) vývoj sdílené business logiky - Enterprise Java Beans (EJB), Spring p ístup ke zprávovému middleware - Java Messaging Services (JMS) podpora technologie Web Services Zdroj [6] 3.3.2 PHP Skriptovací programovací jazyk ur ený hlavn k vývoji webových aplikací. Historie PHP sahá aº do roku 1995, kdy p vodní autor Rasmus Lerdorf p edstavil sadu skript, které nazval Personal Home Page Tools. Do roku 1997 byla vytvo ena verze 2.0, která uº byla implementována v jazyce C, zatímco p vodní skripty byly v jazyku Perl. V roce 1997 zárove p vodní zdrojové kódy p evzali pánové Andi Gutmans a Zeev Suraski. Tyto kompletn p epsali a v polovin roku vydali jako verzi PHP 3.0, která dokonce roku dosáhla 10% podílu mezi webovými servery na internetu. Okamºit po vydání t etí verze za ali oba auto i pracovat na dal²ím vylep²ení jazyka. Nová verze 4.0 zaloºená na Zend Engine (Zend jako zkratka jmen Zeev a Andi) byla p edstavena v polovin roku 1999, zárove byla zaloºena rma Zend Technologies, která se o vývoj jazyka PHP stará dodnes. 11

KAPITOLA 3. ANALÝZA Obrázek 3.2: Platforma Java EE V sou asnosti nejpouºívan j²í verzí jazyka PHP je verze 5 (p edstavena v roce 2004) a od ní odvozené varianty (nap íklad v sou asné dob nejnov j²í verze 5.3.2). Nejd leºit j²ími novinkami, které p i²ly s verzí PHP 5, byla nová vylep²ená podpora OOP a abstraktní datová vrstva PDO, o které se také budu podrobn ji zmi ovat dále v textu v souvislosti se svojí prací.[9] 3.3.2.1 Výhody PHP Velká rozsáhlost funkcí p ímo v základní verzi Velké mnoºství roz²i ujících knihoven, které pokrývají v t²inu b ºných pot eb Nativní podpora mnoha databázových systém Multiplatformnost Pravd podobn stále nejpouºívan j²í jazyk pro psaní webových aplikací a z toho vyplývající rozsáhlost uºivatelské komunity Jednoduchá instalace na serveru, velké mnoºství server podporující hosting PHP Dobrý manuál 12

3.4. DATABÁZOVÉ ÚLOšI T, KOMUNIKACE S DATABÁZÍ 3.3.2.2 Nevýhody PHP Zatíºenost historickým vývojem Nedokonalá podpora OOP Míchání objektového a procedurálního p ístupu v²echny p vodní nativní funkce jsou pouºívány jako procedurální Nekonzistentní pojmenování nativních funkcí a nejednotnost v logice po- adí parametr Není zaru ena zp tná kompatibilita Nativní funkce nevyhazují výjimky (ty byly p idány do PHP aº od verze 5) Po zpracování poºadavku se ztrácí kontext aplikace p i kaºdém poºadavku vzniká nové vlákno, p ípadn proces, musí se navázat nové spojení s databází apod. Z p edchozího bodu vyplývající slab²í výkon 3.4 Databázové úloºi²t, komunikace s databází Výb r konkrétní databáze byl teoreticky limitován moºnostmi jazyka PHP. Pro p ístup do databáze bylo pouºito rozhraní PDO[7], které podporuje v t²inu znám jích databázových systému. Kompletní seznam uveden níºe v tabulce 3.1. 3.4.1 Rozhraní PDO PDO 5 je abstraktní datová vrstva slouºící k jednotnému p ístupu k r zným databázovým systém m z jazyka PHP. PDO se v jazyce PHP objevuje od verze 5.1. Jedná se o sadu databázových ovlada, z nichº kaºdý musí implementovat dané standardizované rozhraní. To znamená, ºe kaºdý ovlada musí s konkrétní databází umoºnit provád t základní akce typu: poslání SQL dotazu vytvá ení tzv. prepared statements (vysv tleno níºe) 5 PHP Data Objects 13

KAPITOLA 3. ANALÝZA Ovlada Podporované databáze PDO_DBLIB FreeTDS / Microsoft SQL Server / Sybase PDO_FIREBIRD Firebird/Interbase 6 PDO_IBM IBM DB2 PDO_INFORMIX IBM Informix Dynamic Server PDO_MYSQL MySQL 3.x/4.x/5.x PDO_OCI Oracle Call Interface PDO_ODBC ODBC v3 (IBM DB2, unixodbc and win32 ODBC) PDO_PGSQL PostgreSQL PDO_SQLITE SQLite 3 and SQLite 2 PDO_4D 4D Tabulka 3.1: Podporované databázové systémy za átek transakce a následný commit nebo rollback zpracování vrácených dat z databáze do podoby asociativního pole nebo rovnou objektu zpracování chybových kód 3.4.1.1 Prepared statements Prepared statements, esky o²kliv ale výstiºn p ipravené dotazy jsou zjednodu²en e eno SQL dotazy, které jsou do databáze poslány a zpracovány jen jednou, ale mohou být vyvolány vícekrát. P íkladem takového dotazu m ºe být: SELECT * FROM user WHERE id = :uid P i emº p edchozí dotaz vyuºívá vázané prom nné :uid, která je nahrazena konkrétní hodnotou aº ve chvíli zavolání. Tedy nám sta í jeden dotaz, a se ptáme na uºivatele s uid 1,2 nebo 3. K oz ejmení výhod pouºití prepared statements je t eba se podívat trochu blíºe na princip zpracování SQL dotaz na databázovém stroji: 1. P ijde SQL dotaz ke zpracování 2. Databáze provede syntaktickou a sémantickou analýzu dotazu 14

3.4. DATABÁZOVÉ ÚLOšI T, KOMUNIKACE S DATABÁZÍ Obrázek 3.3: Vloºená abstraktní datová vrstva PDO 3. Databáze se podívá do sdílené pam ti (shared pool), jestli nebyl v minulosti tento dotaz jiº vy izován. Pokud ano Databáze z pam ti vytáhne hotový provád cí plán (execution plan) Pokud ne Databáze provádí tzv. hard parse. Pro dotaz musí vytvo it nový provád cí plán, coº je netriviální operace a zabírá mnoho asu 4. Databáze spustí dotaz podle provád cího plánu Provád cí plány jsou ve sdílené pam ti identikovány pomocí otisku (hashe) p - vodního dotazu. Z toho vyplývá, ºe jakákoli, i minimální, zm na (nap íklad mezera navíc) v dotazu zap í iní to, ºe provád cí plán pro daný dotaz musí být vytvo en znovu. SELECT * FROM user WHERE id = 1 SELECT * FROM user WHERE id = 2 SELECT * FROM user WHERE id = 3 Pro p edchozí t i dotazy tedy budou muset být vytvo eny t i tém totoºné provád cí plány, a to úpln zbyte n. Pokud budeme mít v databází nap íklad 10 tisíc 15

KAPITOLA 3. ANALÝZA uºivatel a budeme se na n postupn dotazovat, v pam ti databázového stroje bude 10 tisíc r zných provád cích plán, de facto pro jednu a tu samou v c. Tím se dostávám k výhod pouºití prepared statements s vázanými prom nnými. Pokud namísto t chto t ech dotaz pouºijeme prepared statement z prvního p íkladu, provád cí plán bude vypracován pouze jednou (hash dotazu je po ád stejný, dotaz samotný se nem ní), v pam ti bude uloºen také pouze jednou, coº p iná²í nezanedbatelné rozdíly ve výkonu. Informace erpány z [3] 3.4.1.2 Výhody a nevýhody pouºití PDO Z p edchozí textu vyplývá, ºe PDO zaji² uje konzistentní a jednotný p ístup ke v²em podporovaným databázovým stroj m. Tím pádem je zaru eno, ºe teoreticky m ºeme vym nit databázový stroj tém za b hu za jiný (nap. sou asné MySQL za Postre- SQL). Problémem ov²em je, ºe a koli v²echny uvedená databáze podporují SQL a SQL je ociálním standardem, obvykle má kaºdá databáze standard implementován v n em neúpln a v n em ho naopak roz²i uje. P enositelnost SQL dotaz mezi jednotlivými databázemi je proto omezená. 3.4.1.3 P enositelnost SQL První verze jazyka SQL byla standardizována jiº v roce 1986 (SQL-86) práv z d vodu, aby se sjednotil p ístup k rela ním databázím od r zných výrobc (Oravle, IBM... ). Standard byl postupn modikován do verzí SQL-92, SQL:1999, SQL:2006, SQL:2008. Tyto detaily v²ak nejsou pro tuto práci d leºité. V této kapitolce se krátce zmíníme o konkrétních rozdílech mezi jednotlivými databázemi, na které bude moºné p i migraci narazit. Pro zjednodu²ení se budeme zabývat pouze databázemi PostreSQL a MySQL, protoºe pouze tyto dv p ipadají v sou asné dob pro Studentovu berli ku v úvahu. azení výsledk (ORDER BY) Standard neur uje, jak se mají adit NULL hodnoty PostrgreSQL defaultn adí NULL hodnoty na za átek (dá se zm nit pomocí NULLS FIRST a NULLS LAST) MySQL adí NULL hodnoty na konec Omezení po tu výsledk (LIMIT) 16

3.4. DATABÁZOVÉ ÚLOšI T, KOMUNIKACE S DATABÁZÍ Standard SQL:2008 ur uje klí ová slova FETCH FIRST n ROWS ONLY PostrgreSQL podporuje FETCH FIRST od verze 8.4, d íve stejn jako u MySQL MySQL pouºívá klí ové slovo LIMIT Datový typ BOOLEAN Standard denuje BOOLEAN jako t ístavový (TRUE, FALSE, NULL) PostrgreSQL respektuje standard MySQL datový typ BOOLEAN nemá, místo toho se pouºívá TINYINT, do kterého se vejde rozsah 256 ísel, coº m ºe být matoucí Reprezentace datu a asu, datový typ TIMESTAMP Standard denuje datový typ TIMESTAMP k ukládání roku, m síce, dne, hodiny, minuty a sekundy v etn desetinné ásti (formát nap. 2003-07-29 13:19:30.5 ) PostrgreSQL respektuje standard MySQL má datový typ TIMESTAMP, který se chová úpln odli²n od standardu (viz. manuál MySQL 6 ), standardu se nejvíce p ibliºuje datový typ DATETIME, který ale operuje pouze s p esností jedné sekundy (neukládá destiny sekund). Automatické generování klí Standard denuje atribut GENERATED... AS IDENTITY PostrgreSQL pouºívá datový typ SERIAL Pouºívá atribut AUTO_INCREMENT P edchozí vý et je zam ený pouze na nejd leºit j²í rozdíly. Seznam není vy erpávající, detaily lze dohledat na webové stránce[5], p ípadn v manuálech jednotlivých databází. 6 http://dev.mysql.com/doc/ 17

KAPITOLA 3. ANALÝZA 3.4.2 Výb r databázového stroje Z p edchozího textu vyplývá, ºe díky abstraktní datové vrstv PDO není výb r databáze pro tuto práci klí ový. Jádro musí fungovat s jakoukoli ze zmi ovaných v tabulce podporovaných databázových ovlada [tabulka 3.1]. Tématu výb ru databáze se proto budeme v novat jen okrajov. Detaily jsou k nalezení v práci mého kolegy Tomá²e Králíka. Z moºných kandidát byla vybraná jako nejvhodn j²í databáze MySQL. Rámcové d vody byly následující: p vodní systém Berli ky pouºívá také databázi MySQL pro jednodu²²í migraci dat je vhodné pouºít stejnou databázi na testovacím serveru dostupná zku²enosti len týmu nejvíce s touto databází osobní preference 3.4.3 Historie MySQL Vydání první verze databázového systému MySQL se uskute nilo roku 1995 rmou MySQL AB (která se pozd ji stala sou ástí Sun Microsystems nyní sou ástí Oracle). Tato první verze fungovalo pouze pod OS Linux a UNIX. Verze pro opera ní systém MS Windows byla p idána v roce 1998. Od roku 2005, kdy vychází MySQL verze 5.0 se stává plnohodnotnou databází, která podporuje funkce jako: p ipravené dotazy (prepared statements), uloºené procedury (stored procedures), triggery, pohledy (views), transakce (transactions). 3.4.4 Výhody MySQL ²í ena pod licencí GPL moºnost pouºití zdarma moºnost pouºití r zných úloºi² (storage engines) MyISAM, InnoDB, ME- MORY, CSV... multiplatformní 18

3.5. OBJEKTOV -RELAƒNÍ MAPOVÁNÍ (ORM) 3.5 Objektov -rela ní mapování (ORM) Z d vodu, ºe jádro Studentovy berli ky vyuºívá prvk objektov -orientovaného programování (OOP), které podporuje jazyk PHP, data jsou reprezentována jako objekty. Kaºdý objekt zapouzd uje svá data a implementuje sadu metod. Jako úloºi²t je pouºita rela ní databáze. Tímto vzniká problém, ºe je t eba n jakým zp sobem e²it propojení objektového sv ta (objekt v pam ti, který má atributy) s rela ním sv tem (tabulka v databázi se sloupci). Obecné e²ení tohoto problému se nazývá objektov -rela ní mapování. ORM slouºí k p evodu datových objekt do rela ních tabulek a naopak. A to tak, aby na stran objektového z stala moºnost vyuºití v²ech výhod OOP, jako jsou vazby mezi objekty, d di nost. A zárove na stran rela ní databáze moºnost vyuºívat indexy, primární klí e, cizí klí e, pohledy apod. 3.5.1 Moºnosti ORM v jazyce PHP S p íchodem PHP verze 5 a podporou OOP vyvstala pot eba e²it objektov -rela ní mapování i v tomto jazyce. V sou asné dob existuje pro PHP n kolik ORM framework. V t²ina z nich, moºná v²echny, jsou zaloºeny na návrhovém vzoru Active record. Pro pouºití v systému Studentova berli ka jsme uvaºovali následující dva: 3.5.1.1 PHP ActiveRecord Active record je architektonický návrhový vzor publikovaný v roce 2002 Martinem Fowlerem ve své knize Patterns of Enterprise Application Architecture. Tento vzor íká, ºe kaºdý objekt (entita) nese jak svoje data, tak chování. Objekt implementuje rozhraní pro CRUD operace (Create, Read, Update, Delete). Jinak e eno, objekt implementuje takové metody, aby se sám dokázal na íst a uloºit z/do tabulky v databázi. Rela ní data jsou reprezentována jako objektov -orientovaný kód, kde databázové tabulky odpovídají t ídám, ádky tabulek objekt m (instancím t íd) a nakonec jednotlivé sloupce tabulky atribut m objektu. PHP ActiveRecord je framework zaloºený práv na vzoru Active record. Inspirace pochází z implementace Active record ve webovém frameworku Ruby on Rails. Ociální webová stránka s dokumentací je dostupná na [8]. Framework nabízí základní, ale dosta ující paletu moºností: 19

KAPITOLA 3. ANALÝZA Finder methods Nad kaºdým entitní t ídou lze volat statické metody, které vyhledávají data v databázi a vrací instaneci objektu. Framework dokonce podporuje i tzv. dynamic nder methods, coº znamená, ºe lze volat metody typu User::nd_by_rst_name, aniº by taková metoda ve t íd User musela být de- nována. Volání je dynamicky odchyceno a z et zce postaven SQL dotaz, který je následn p edán databázi. Vztahy mezi entitami Mezi entitami m ºou existovat r zné typy vztah (one-to-one, one-to-many, many-to-one, many-to-many). Framework tyto vztahy dokáºe e²it a objekty spojovat. Vede to k tomu, ºe s nimi potom lze pracovat velmi pohodln. Validace vstupních hodnot U kaºdého atributu obejektu je moºné nadenovat podmínky, které musí být spln ny, aby mohl být objekt uloºen do databáze. P estoºe se tento framework zdá býti vhodným a pouºitelným nástrojem, existuje zde n kolik nevýhod, které jeho nasazení v rámci jádra Studentovy berli ky vylu ují: funguje pouze s jazykem PHP verze 5.3 a vy²²í dokumentace je velmi strohá, ze subjektivního pohledu nedostate ná projekt je v sou asné dob teprve ve verzi 1.0 RC1, coº znamená, ºe nelze o ekávat 100% spolehlivost 3.5.1.2 Doctrine Framework Doctrine je jednozna n inspirován frameworkem Hibernate z jazyka Java. Oproti p edchozímu frameworku nabízí mnohem pokro ilej²í funkce. Vkládá do aplikace dal²í abstraktní databázovou vrstvu Doctrine DBAL 7, která kompletn odsti uje rozdíly mezi r znými dialekty jazyka SQL. Vrstva p iná²í sv j vlastní dotazovací jazyk nazvaný DQL 8, který je následn p ekládán do konkrétního SQL dialektu podle pouºité databáze. Tím je vy e²en problém s r znými implementacemi standardu SQL, který byl nastín n v kapitole 3.4.1.3. Krom uºite né vrstvy DBAL p iná²í framework n kolik dal²ích klí ových vlastností: 7 DataBase Abstraction Layer 8 Doctrine Query Language 20

3.5. OBJEKTOV -RELAƒNÍ MAPOVÁNÍ (ORM) Obrázek 3.4: Architektura frameworku Doctrine Behaviors Jedná se o vlastnosti, které m ºeme p idávat tabulkám a jednotlivým sloupc m. Tyto vlastnosti potom denují chování t chto prvk, coº slouºí k elegantnímu e²ení nej ast j²ích problém u webových aplikací. Pro lep²í pochopení bude vhodné se podívat na konkrétní p ípady: Versionable Tato vlastnost u tabulky e²í její tzv. verzování. To znamená, ºe ve²keré zm ny záznam v tabulce jsou zaznamenávány a kdykoli je moºno se vrátit k n které z p edchozích verzí. P ibliºn je to implementováno tak, ºe p i smazání nebo zm n záznamu (DELETE nebo UPDATE) se p vodní data p esunou do vedlej²í verzovací tabulky, jako záloha pro p ípadné obnovení. Timestampable Do tabulky jsou p idány sloupce created_at a updated_at, které nesou informaci o asu vytvo ení záznamu a asu jeho poslední zm ny. Aktualizace t chto dat e²í framework sám. SoftDelete P i smazání záznamu je tento záznam pouze ozna en informací deleted_at, ale k jeho faktickému smazání nedochází. Ve vyhledávání se poté neobjevuje, ale je moºné ho kdykoli obnovit. Sluggable Vlastnost, která do tabulky p idává jeden sloupec, do kterého je automaticky generován et zec, který slouºí k vytvá ení hezkých URL. Nap íklad z nadpisu lánku PHP framework Doctrine vytvo í 21

KAPITOLA 3. ANALÝZA php-framework-doctrine. Lazy-loading Reference a atributy objektu nejsou na ítány z databáze hned, jsou na teny explicitním dotazem aº ve chvíli, kdy jsou poºadovány. Dochází tak k ²et ení pam ti i p enosové linky mezi aplikací a databází. A koli framework Doctrine obsahuje uºite né funkce, které by se v jádru systému Studentova berli ka daly vyuºít, je zde n kolik zásadních p ekáºek, kv li kterým nebude nasazen. Nejv t²ím problémem je, ºe entitní t ídy objekt musí povinn roz²i ovat t ídu Doctrine_Record, ze které zd dí velké mnoºství pomocných metod a atribut. Vzhledem k tomu, ºe jádro s objekty nemá za úkol nijak dál pracovat, pouze je poskytuje skrz rozhraní Web services venkovnímu sv tu, nastává zde velký problém. P íjemce objektu na druhém konci nemusí pouºívat tento framework, tudíº p ijatý objekt typu Doctrine_Record nebude kompatibilní, nehled na mnoºství odeslaných interních informací o objektu, které by se mimo jádro nem ly dostat. Tento problém by se pravd podobn dal e²it pomocí tzv. Data Transfer Objects (DTO), coº znamená, ºe objekt typu Doctrine_Record by se p etransformoval do n jakého jednodu²²ího, který by slouºil pouze pro p enos. Tento koncept se ale zdá pon kud t ºkopádný. 3.5.2 Vlastní framework Poslední uvaºovanou moºností je napsání jednoduchého ORM frameworku p ímo na míru dané aplikaci. Je z ejmé, ºe s tím je spojeno mnoho nevýhod. Jednomu autorovi se b hem n kolika m síc nepoda í vytvo it srovnatelný framework s frameworky tvo- enými celými týmy, p ípadn komunitou, po mnoho let. Zárove tento jednoú elový framework ve srovnání s ve ejn dostunými nebude d kladn otestován mnoºstvím uºivatel. P es tyto nevýhody se po provedené analýze a otestování p edchozích dvou framework jeví napsání vlastního jako ideální e²ení. Existuje pro to n kolik d vod : Plná kontrola nad zdrojovými kódy. e²ení na míru podle poºadavk aplikace. P edchozí zmi ované frameworky jsou v tomto ohledu robustn j²í, ale obsahují velké mnoºství funkcionalit a knihoven, které by nebyly vyuºity. 22

3.5. OBJEKTOV -RELAƒNÍ MAPOVÁNÍ (ORM) Doba k plnému ovládnutí a p izp sobení cizího frameworku je del²í neº napsání svého jednoduchého e²ení, které sice není tak komplexní, ale na daný problém funguje. 23

KAPITOLA 3. ANALÝZA 24

Kapitola 4 Návrh e²ení V této kapitole bude konkrétn popsána architektura navrºená pro jádro systému Studentova berli ka. 4.1 Celkový pohled na architekturu A koliv se tato práce zabývá návrhem pouze ásti jádra aplikace, je d leºité se podívat na celkovou architekturu z v t²í perspektivy. Jak bylo zmín no v úvodní ásti, primárním cílem této práce je rozd lit architekturu aplikace na dv základní ásti: Jádro B ºí na samostatném serveru. Zaloºené na technologii PHP, jako databázi vyuºívá MySQL. Poskytuje vn j²í rozhraní pro komunikaci postavené na protokolu SOAP. Na architekturu jádra se podrobn ji podíváme níºe. Vrstva plugin Samostatné aplikace roz²i ující základní funkcionalitu jádra. Vyuºívají datové úloºi²t na serveru jádra, které není vázáno na databázi MySQL (plugin m ºe jako své úloºi²t vyuºívat i jinou databázi). 4.2 Architektura jádra Jádro vyuºívá tzv. vícevrstvé nebo také n-vrtsvé architektury, coº znamená, ºe implementace aplikace je rozd lena do n kolika nezávislých vrstev, které spolu vzájemn spolupracují p es p edem denované rozhraní. Kaºdá vrstva komunikuje pouze s nejbliº²í niº²í a nejbliº²í vy²²í vrstvou. Tato práce se implementa n zabývá pouze vrstvami PDO, Entities, Core facade. P esto jsou ostatní vrstvy zmín ny kv li úzké prová- 25

KAPITOLA 4. NÁVRH E ENÍ zanosti jak na aplika ní úrovni, tak na úrovni spolupráce len týmu. Diagram vrstev viz obrázek 4.1. 4.2.1 Databázová vrstva Vrstva reprezentující datové úloºi²t v n které z rela ních SQL databází. Logicky rozd lena na dv ásti: Core DB hlavní datové úloºi²t Studentovy berli ky pot ebné pro základní funkcionalitu, coº je administrativa cvi ení (evidence hodnocení, docházky, semestrálních prací) Plugin DB datová úloºi²t jednotlivých plugin. Je po ítáno s tím, ºe kaºdý plugin bude pot ebovat ke svému fungování ukládat dal²í data nad rámec základního úloºi²t (nap íklad plugin na generování test bude pot ebovat ukládat do databáze zadání otázek, vygenerované testy, správné odpov di apod.). Bylo rozhodnuto, ºe tato úloºi²t nemohou být umíst na p ímo v míst, kde b ºí daný plugin, ale budou obsaºena p ímo na serveru samotného jádra. Uloºení v²ech dat na jednom míst sníºí pravd podobnost úniku nebo ztracení, jedná se tedy o bezpe nostní opat ení. 4.2.2 PDO vrstva Vrstva z jazyka PHP zmi ovaná v kapitole 3.4.1. Zaji² uje moºnost jednotného p ístupu k r zným databázovým stroj m z vy²²í vrstvy. 4.2.3 Vrstva entit Kaºdá entita reprezentuje jeden datový objekt. Entity jsou navrºeny podle návrhového vzoru Active record (viz kapitola 3.5.1.1), coº znamená, ºe objekt nese svoje atributy a logiku. Kaºdý objekt je schopen se sám uloºit do správné tabulky ve správné databázi. Kaºdý objekt nese informaci o tom, do které databáze a tabulky se má ukládat. To znamená, ºe z vy²²í vrstvy m ºeme ke v²em entitním objekt m p istupovat jednotn, aniº bychom museli e²it, ke kterému pluginu, potaºmo databázi, pat í. 26

4.2. ARCHITEKTURA JÁDRA Obrázek 4.1: Celkový pohled na architekturu systému Studentova berli ka 27

KAPITOLA 4. NÁVRH E ENÍ 4.2.4 Core facade Vrstva inspirovaná návrhovým vzorem Facade. P edstavuje vn j²í rozhraní celého subsystému. Poskytuje komplexní metody skrývající sloºitost vnit ní implementace jádra. 4.2.5 Vrstva Web services Zjednodu²en e eno se jedná o vrstvu, která je branou do celého systému. Fakticky zp ístup uje metody denované v Core facade vn j²í sv tu pomocí protokolu SOAP, který komunikuje nad protokolem HTTP. Detaily k implementaci této vrstvy k nalezení v diplomové práci kolegy Bc. Lu ka Chmurovského. 4.3 Interakce mezi vrstvami Na obrázku 4.2 je podrobn rozkreslena interakce mezi jednotlivými vrstvami jádra p i volání ve ejné metody getstudentbyid(id), která vrací objekt typu Student obsahující kolekci s objekty Attendance, které reprezentují jeho docházku. Obrázek 4.2: Ukázka interakce mezi vrstvami jádra 28

Kapitola 5 Realizace Vzhledem k tomu, ºe popis samotné implementace by byl pom rn nezajímavý, bude omezen na naprosté minimum. Implementace uº je jen obrazem toho, co bylo navrºeno na základ analýzy, detaily se dají vyhledat ve zdrojových kódech. V druhé ásti této kapitoly bude popis realizace formou návodu pro budoucí autory a správce jádra. 5.1 Návod jak roz²í it funkcionalitu jádra Následující návod popisuje, jaké v²echny innosti musí správce provést, aby mohlo být jádro roz²í eno o nové funkcionality. Typicky se bude jednat o p idání podpory n kterého nového pluginu. Pro ná² p íklad si m ºeme p edstavit nap íklad plugin Generátor test kolegy Franti²ka Kramla, který bude s jádrem Studentovy berli ky propojován v pr b hu následujícího léta. Nyní tedy návod krok za krokem: 5.1.1 Datové úloºi²t P edpokladem je, ºe nový plugin bude pot ebovat n jaké své vlastní datové úloºi²t, které uº je navrºeno. To znamená, ºe máme databázové schéma, která spl uje následující podmínky: Kaºdá entita (tabulka reprezentující objekt) musí mít jednozna ný identikátor pojmenovaný id, který je automaticky generován (AUTO_INCREMENT u MySQL) 29

KAPITOLA 5. REALIZACE Ve schématu jsou zahrnuty pouze tabulky, které nejsou obsaºeny v centrální databázi Studentovy berli ky. Lze na n v²ak referencovat. (Pro konkrétní p íklad: databáze nového pluginu nem ºe obsahovat entitu User, která uº je v centrální databázi). Obrázek 5.1: Ukázka p idávaného datového úloºi²t Nyní sta í zaloºit na serveru novou databázi, do které se importuje dané schéma, p i emº nezáleºí na tom, který databázový stroj bude zvolen. Jakmile je databáze zaloºena, je nutné p idat n kolik ádk do /Core/cong/db.php, aby do²lo ke spojení s novou databází: $core_db = DaoFactory::createDao("mysql:host=localhost;dbname=berlicka", "username","password", "core_db"); $core_db->exec('set CHARACTER SET utf8'); $core_db->setattribute(pdo::attr_errmode, PDO::ERRMODE_EXCEPTION); D leºité jsou parametry metody createdao($dsn_string, $username, $password, $name): $dsn_string Data Source Name, et zec ur ující spojení s databází, detaily nap íklad na http://pear.php.net/manual/en/package.database.db.intro-dsn.php $username uºivatelské jméno pro p ihlá²ení k databázi $password heslo pro p ihlá²ení k databázi $name p i azení názvu spojení, které se pozd ji v aplikaci vyuºívá 30

5.1. NÁVOD JAK ROZ Í IT FUNKCIONALITU JÁDRA 5.1.2 Entity Pokud je spojení s databází funk ní, je pot eba p idat entitní t ídy do datové vrstvy. Entitní t ída je p ímým obrazem tabulky v databázi. Kaºdá entita musí povinn roz- ²i ovat t ídu AbstractEntity, která vynucuje, ºe bude mít implementovány následující metody: set($name, $value) magic setter get($name) magic getter tostring() metoda, která formátuje objekt k tisku getvars() metoda, která vrací asociativní pole vnit ních atribut objektu static getbyid($id) vrací instanci objektu podle id static getall() vrací pole v²ech dostupných instancí objektu save() zajistí samostatné uloºení instance presave() funkce automaticky zavolaná t sn p ed uloºením (slouºí k p ípadným modikacím p ed uloºením objektu) A zárove kaºdá entita musí mít základní sadu povinných atribut : $id jednozna ný identikátor static $db_name název spojení denovaný v congu static $table_name název tabulky v databázi, se kterou je entita propojena static $references asociativní pole ve tvaru (odkazovaný objekt => název cizího klí e) k odli²ení cizích klí od klasických atribut Ukázkový kód entity je k dispozici v dodatku A, p ípadn ve zdrojových kódech. 31

KAPITOLA 5. REALIZACE 5.1.2.1 P idávání nových entit P i vytvá ení nových t íd máme v podstat dv moºnosti: Entitní t ídy napsat ru n podle vzoru v dodatku A, potom je p idat do vlastního adresá e v /Core/entities/, tedy nap íklad /Core/entities/test_gen/. P i psaní t íd lze podstatnou ást zkopírovat z jiº hotových, hlavn povinné metody, u kterých se implementace nem ní. Kaºdá entita musí mít precizn okomentované atributy pomocí syntaxe phpdoc (tzn. hlavn datový typ), protoºe z t chto informací je potom generován WSDL soubor pro vrstvu Web services. Pokud je jako úloºi²t pouºita databáze MySQL, lze vyuºít primitivního generátoru entitních t íd, který se nechází v adresá i /Core/generator/. Spustit generátor lze pomocí skriptu generate.php (pozor, server musí mít povolen zápis do adresá e generátoru). Generátor oskenuje v²echny databáze a jejich tabulky denované v kongura ním souboru db.php. Pokud v²e prob hne v po ádku, v adresá i /Core/generator/entities se budou nacházet nov vygenerované entity se základními metodami a atributy. Odtud vybrané zkopírujeme do adresá e /Core/entities/. 5.1.3 Core facade Core facade se nechází v souboru /Core/Core.php a obsahuje seznam metod, který chceme zp ístupnit okolnímu sv tu. Do této t ídy proto musíme p idat v²echny metody, které bude daný plugin vyuºívat. Pokud budeme vycházet z p edchozího p íkladu s Generátorem test, m ºe být dobrým p íkladem metoda getalltests(), která bude vracent kolekci objekt typu Test. V kódu bude vypadat n jak takto: /** * @return Test[] tests */ public function getalltests(){ return Test::getAll(); } Krom nových metod je nutné do souboru Core.php p idat jeden ádek, který zajistí na tení nov vygenerovaných a p idaných entitních t íd: 32

5.1. NÁVOD JAK ROZ Í IT FUNKCIONALITU JÁDRA EntityLoader::loadDir(dirname( FILE ). '/entities/test_gen/'); 33

KAPITOLA 5. REALIZACE 34

Kapitola 6 Testování 6.1 Testování p i implementaci V rámci implementace prob hlo ov ení funkcí z vrstvy Core facade, zda-li vracejí správné a kompletní výsledky. Dále do²lo k testování jádra jako celku po propojení s ostatními z prací koleg Králíka a Chmurovského. 6.2 Testování v provozu Ostré testování testování s reálnými daty prob hne v pr b hu p í²tího semestru (zimní 2010/2011) ve spolupráci s Franti²kem Kramlem, který se ve své bakalá ské práci v nuje rozvoji jednoho z plugin pro systém Studentova berli ka. 6.3 Ukázka Vzhledem k tomu, ºe fungování jádra systému nelze ádn otestovat bez n jakého funk ního pluginu, který by sluºby jádra mohl vyuºívat, byla pro ú ely testování vytvo ena jednoduchá webová aplikace, která imituje jeden z plugin. Tato aplikace je k dispozici na adrese http://bd.felk.cvut.cz/berlicka_core/modultest/, kde je moºno vyzkou²et fungování komunikace s jádrem a základní operace jako vypsání seznamu uºivatel, p idání nového uºivatele nebo editace jeho osobních údaj. Vzhled aplikace na obrázku 6.1. 35

KAPITOLA 6. TESTOVÁNÍ Obrázek 6.1: Ukázková aplikace jádra 36

Kapitola 7 Záv r V rámci této práce byl navrºen a implementován relativn rozsáhlý systém, který zprost edkovává ostatním aplikacím ízený p ístup k databázi Studentovy berli ky. Vzhledem k rozsahu byl kladen d raz hlavn na d kladnou analýzu r zných e²ení, implementována byla jen nezbytná ást. Dal²í rozvoj uº nem ºe probíhat samostatn, ale za spolupráce s autory plugin. Autor této práce si uv domuje, ºe daná problematika není probrána a vy e²ena celém rozsahu. Jedná se spí²e o nazna ení sm ru, kudy by se vývoj aplikace Studentova berli ka m l dále ubírat. Dal²í vývoj bude stát je²t mnoho úsilí, na kterém se bude podílet jak autor této práce, tak dal²í zájemci. 7.0.1 Vize do budoucna Jak bylo zmín no, práce na tomto projektu nejsou zdaleka dokon eny. Existuje v²ak n kolik úkol, které bude t eba e²it prioritn : V pr b hu léta a následujícího semestru otestovat propojení s n kterými hotovými pluginy P epsání webového GUI tak, aby ²lo propojit se samostatným jádrem p es protokol SOAP Verzování a monitoring zm n Taková zm na úloºi²t, aby mohly být evidovány v²echny zm ny s moºností obnovení p vodních dat. To znamená, aby bylo nap íklad moºné, ºe v p ípad chyby nebo zneuºití p ihla²ovacích údaj p - jdou v²echny zm ny vykonané daným uºivatelem za posledních x dní vrátit do p vodního stavu. 37