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

c mu, specikace cle 2 Popis probl

5

2.1 2.2

c mu Studentova berliÄka . . . . . . . . . . SouÄasn stav syst cm . . . . . . . . . . . . Specikace cl a po©adavk na syst

3 Analza 3.1 3.2

3.3

3.4

3.5

5 7

9

Problematika komunikace . . . . . . . . . . . . . . . . . . . . . c my . . . . . . . . . . . . . . . Existujc informaÄn syst c my . . . . . . . . . . 3.2.1 Univerzitn informaÄn syst c my pro podporu jednotlivch pTM edmÄt 3.2.2 Syst c mu Studentova berliÄka . . . . . . . . 3.2.3 Historie syst Volba programovacho jazyka . . . . . . . . . . . . . . . . . . . 3.3.1 Java Enterprise Edition . . . . . . . . . . . . . . . . . . 3.3.2 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2.1 Vhody PHP . . . . . . . . . . . . . . . . . . 3.3.2.2 Nevhody PHP . . . . . . . . . . . . . . . . . c ³lo©itÄ, komunikace s databz . . . . Databzov 3.4.1 Rozhran PDO . . . . . . . . . . . . . . . . . . . . . . . 3.4.1.1 Prepared statements . . . . . . . . . . . . . . . 3.4.1.2 Vhody a nevhody pou©it PDO . . . . . 3.4.1.3 PTM enositelnost SQL . . . . . . . . . . . . . . c ho stroje . . . . . . . . . . . . 3.4.2 VbÄr databzov 3.4.3 Historie MySQL . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Vhody MySQL . . . . . . . . . . . . . . . . . . . . . . ObjektovÄ-relaÄn mapovn (ORM) . . . . . . . . . . . 3.5.1 Mo©nosti ORM v jazyce PHP . . . . . . . . . . . . . . 3.5.1.1 PHP ActiveRecord . . . . . . . . . . . . . . . . 3.5.1.2 Doctrine . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Vlastn framework . . . . . . . . . . . . . . . . . . . . xi

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

9 10 10 11 11 13 13 14 15 15 16 16 17 19 19 20 21 21 21 22 22 23 25

xii

OBSAH

4 Nvrh TM een 4.1 4.2

4.3

Celkov pohled na architekturu Architektura jdra . . . . . . . 4.2.1 Databzov vrstva . . 4.2.2 PDO vrstva . . . . . . . . 4.2.3 Vrstva entit . . . . . . . . 4.2.4 Core facade . . . . . . . . 4.2.5 Vrstva Web services . . . . Interakce mezi vrstvami . . . . .

5 Realizace 5.1

. . . . . . . .

. . . . . . . .

TM

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

Nvod jak roz it funkcionalitu jdra c ³lo©itÄ . . . . . . . . . . 5.1.1 Datov 5.1.2 Entity . . . . . . . . . . . . . . . . . . . . 5.1.2.1 PTM idvn novch entit 5.1.3 Core facade . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

27

27 27 28 28 28 29 29 29

33

33 33 35 36 36

6 Testovn

39

7 ZvÄr

41

6.1 6.2 6.3

Testovn pTM i implementaci . . . . . . . . . . . . . . . . . . . . Testovn v provozu . . . . . . . . . . . . . . . . . . . . . . . . . . Ukzka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.0.1

Vize do budoucna . . . . . . . . . . . . . . . . . . . . . . . . .

39 39 39 41

8 Seznam pou©itch zkratek

43

c ho kªdu entity A Ukzka zdrojov

47

Seznam obrázk· 2.1

SouÄasn podoba Studentovy berliÄky. Zdroj [1] . . . . . . . . .

3.1 3.2 3.3 3.4

c mu Studentova berliÄka. Zdroj Ukzka prvn verze syst Platforma Java EE . . . . . . . . . . . . . . . . . . . . . . . . Vlo©en abstraktn datov vrstva PDO . . . . . . . . . . Architektura frameworku Doctrine . . . . . . . . . . . . . . .

. . . .

11 14 17 24

4.1 4.2

c mu Studentova berliÄka . Celkov pohled na architekturu syst Ukzka interakce mezi vrstvami jdra . . . . . . . . . . . . . . . .

30 31

5.1

c ho datov c ho ³lo©itÄ . . . . . . . Ukzka pTM idvan

34

6.1

Ukzkov aplikace jdra . . . . . . . . . . . . . . . . . . . . . .

40

xiii

[1] . . . . . .

. . . .

6

xiv

SEZNAM OBRÁZK

Seznam tabulek 3.1

c databzov c syst c my . . . . . . . . . . . . . . Podporovan

xv

16

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 POADAVK 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Í INFORMANÍ 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 Server1 , který pouºívá Katedra po£íta£·. Lep²í moºností je vyuºití systému zaloºeném na koncepci wiki (pouºívá nap°íklad Eduweb2 ), 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£ka3 . 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


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 PHP4 . 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


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É ÚLOIT, 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

PDO5 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


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


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


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²úje 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 PostreSQL). 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


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 MySQL6 ), 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


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, MEMORY, CSV . . . • multiplatformní

18

3.5. OBJEKTOV-RELANÍ 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


• 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 denová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 DBAL7 , která kompletn¥ odsti¬uje rozdíly mezi r·znými dialekty jazyka SQL. Vrstva p°iná²í sv·j vlastní dotazovací jazyk nazvaný DQL8 , 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 8 Doctrine

Abstraction Layer

Query Language

20


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


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


• 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


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 EENÍ

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²úje 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 EENÍ

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


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


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

KAPITOLA 7. ZÁVR

• Projekt, který by °e²il import dat z univerzitního systému KOS (údaje o cvi£eních, zapsaných studentech, rozvrhy a podobn¥). • Rozvoj dal²ích samostatných plugin·

38

Kapitola 8 Seznam pouºitých zkratek • CRUD (Create, Read, Update and Delete) £ty°i základní operace, které umoº¬uje provád¥t datové úloºi²t¥ • VUT eské vysoké u£ení technické v Praze • DB Databáze • DBAL (DataBase Abstraction Layer) abstraktní databázová vrstva frameworku Doctrine • GPL (General Public License) licence pro svobodný software • GUI (Graphical User Interface) uºivatelské rozhraní, které umoº¬uje ovládání aplikace pomocí grackých interaktivních prvk· • HTTP (Hypertext Transfer Protocol) síóvý protokol aplika£ní vrstvy vytvo°ení pro vým¥nu dokument· ve formátu HTML • KOS (KOmponenta Studium) studijní informa£ní systém univerzity VUT • OOP (Object-oriented programming) objektové orientované programování • ORM (Object-relational mapping) technika pro p°evod dat mezi rela£ními databázemi a objektov¥ orientovanými jazyky • PDA (Personal Digital Assistant) kapesní po£íta£ • PDO (PHP Data Objects) abstraktní databázová vrstva v jazyce PHP • PHP (Personal Home Page) skriptovací programovací jazyk 39

KAPITOLA 8. SEZNAM POUITÝCH ZKRATEK

• SOAP (Simple Object Access Protocol) protokol slouºící pro vým¥nu zpráv ve formátu XML, pomocí HTTP jako protokolu niº²í vrstvy • SQL (Structured Query Language) standardizovaný dotazovací jazyk pouºívaný pro práci s daty v rela£ních databázích • URL (Uniform Resource Locator) °et¥zec znak· s denovanou strukturou, který slouºí k p°esné specikaci umíst¥ní zdroj· informací na internetu • WSDL (Web Services Description Language) popisuje co nabízí webová sluºba za funkce a zp·sob, jak se jí na to zeptat

40

Literatura [1] HUNKA, J. Studentova Berli£ka. 2007. [2] HUNKA, J. Studentova Berli£ka II. 2009. [3] KOCMAN, J. Ji°í Kocman - Podce¬ované Prepared Statements [online]. Dostupné z: < >. [4] KOTEK, P. Studentova berli£ka II - Automatické vyhodnocení test·. 2009. [5] TROELS, A. Comparison of dierent SQL implementations [online]. Dostupné z: < >. [6] VOBORNíK, D. Softwarový systém pro podporu rozhodování a °ízení. 2008. [7] PHP: PDO - Manual [online]. Dostupné z: < >. [8] PHP ActiveRecord - An easy to use ORM for PHP [online]. Dostupné z: < >. [9] PHP: History of PHP - Manual [online]. Dostupné z: < >.

41

LITERATURA

42

Dodatek A Ukázka zdrojového kódu entity
string */ $name; string */ $surname; string */ $login; string */ $password;

/** * @static * @var array */ private static $references = array( ); /** @var Attendance[] */ private $attendance = array(); /** @var array */ private $validation = array( 'name' => 'required', 'surname' => 'required', 'login' => 'required', 'password' => 'required', ); /** * Name of database in db config * * @var string */ private static $db_name = "core_db";

43

DODATEK A. UKÁZKA ZDROJOVÉHO KÓDU ENTITY

/** * Name of database table to store this object * * @var string */ private static $table_name = "user"; /********** BEGIN OF GENERATED METHODS ****************/

public function __set($name, $value) { $this->$name = $value; } public function __get($name) { return $this->$name; } /** * Convert object into readable string * * @return string */ public function __toString() { $attributes = $this->getVars(); foreach ($attributes as $attribute => $content) { $output[] = $attribute." = ".DaoFactory::getDao(self::$db_name)->quote($content); } return get_class()." = {".implode(', ',$output)."}"; } /** * Return associative array of object's non-static attributes * * @return array */ public function getVars() { $arr = get_object_vars($this); foreach ($arr as $key => $value){ if (is_array($value)) unset($arr[$key]); if (array_key_exists($key, self::$references)) unset($arr[$key]); } return $arr; } /** * Return object instance by id * * @param int $id * @return object */ public static function getById($id) { $where = array('id' => $id);

44

return EntityManager::selectOne(self::$db_name, self::$table_name, get_class(), $where); } /** * Return all instances * * @return array */ public static function getAll(){ return EntityManager::selectArray(self::$db_name, self::$table_name, get_class()); } /** * Insert or update instance into database * Return saved id * * @return int */ public function save() { $this->preSave(); $validator = Validator::getInstance(); if ($validator->validate($this)){ if (self::getById($this->id)) { $result = EntityManager::update(self::$db_name, self::$table_name, $this->getVars()); } else { $result = EntityManager::insert(self::$db_name, self::$table_name, $this->getVars()); } return $result; } return 0; } /** * Triggered before entity saving */ public function preSave(){ }

45

Studentova berli ka III Jádro aplikace

Recommend Documents