České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce. Bakalářská práce. Informační portál

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce

Bakalářská práce

Informační portál Tomáš Novák

Vedoucí práce: doc. Ing. Ivan Jelínek, CSc.

Studijní program: Softwarové technologie a management Obor: Web a multimédia 25. května 2011

2

3

Poděkování Na tomto místě bych rád poděkoval panu doc. Ing. Ivanu Jelínkovi, CSc. za vedení mojí bakalářské práce a oponentovi, panu Ing. Miroslavu Burešovi, Ph.D., který se mnou v průběhu realizace ochotně konzultoval technické náležitosti mojí aplikace.

4

5

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 25.5.2011

….........................................................

6

7

Abstract The subject of this bachelor thesis is to analyze requirements, design and implement an informational portal. The aim of this information portal is to inform the internet users about action of academic stuff on Department of Computer Science and Engineering at FEE CTU and a few chosen employees from other universities in the Czech Republic.

Abstrakt Cílem této bakalářské práce je analyzovat požadavky, navrhnout a implementovat informační portál. Tento informační portál si klade za cíl informovat uživatele internetu o působení akademických pracovníků Katedry počítačů FEL ČVUT a pár vybraných pracovníků z jiných univerzit v České repulice.

8

9

Obsah 1 Úvod ...................................................................................................................... 13 1.1 Volba tématu ke zpracování a zdůvodnění volby tématu ................................. 13 2 Analýza .................................................................................................................. 14 2.1 Srovnávací rešerše existujících aplikací ............................................................ 14 2.1.1 Web ČVUT FEL ............................................................................................. 14 2.1.2 Web Katedry počítačů na ČVUT FEL ............................................................ 15 2.1.3 Web výzkumné skupiny Webing .................................................................. 16 2.1.4 Web Filozofické fakulty UK .......................................................................... 16 2.1.5 Web Brno International Business School (B.I.B.S.) ...................................... 17 2.2 Analýza požadavků ........................................................................................... 19 2.3 Použité SW technologie .................................................................................... 20 3 Návrh ..................................................................................................................... 21 3.1 Use Case diagram ............................................................................................. 21 3.2 Návrh grafiky a informační architektury ........................................................... 23 3.2.1 Pojmenování projektu a návrh loga ............................................................. 23 3.2.2 Návrh informační architektury publikační části ........................................... 24 3.2.3 Návrh grafické podoby publikační části ....................................................... 25 3.2.4 Ukázka grafické podoby jednotlivých sekcí .................................................. 26 3.2.5 Návrh grfické podoby administračního rozhraní .......................................... 30 3.3 Datový model ................................................................................................... 30 3.4 Návrh jazykové mutace .................................................................................... 32 3.5 Diagram aktivit ................................................................................................. 33 3.6 Diagram nasazení ............................................................................................. 34 4 Implementace …..................................................................................................... 35 4.1 Architektura aplikace ........................................................................................ 35

10 4.2 Popis nejdůležitějších tříd ................................................................................. 36 4.2.1 Obecně využívané třídy ............................................................................... 37 4.2.2 Třídy publikační části .................................................................................... 38 4.2.3 Třídy administračního rozhraní .................................................................... 39 5 Testování …............................................................................................................. 41 5.1 Funkční testování …........................................................................................... 41 5.2 Testování validity XHTML kódu …...................................................................... 41 5.3 Testování kompatibility webových prohlížečů …............................................... 41 6 Závěr …................................................................................................................... 43 6.1 Shrnutí …........................................................................................................... 43 6.2 Možná budoucí rozšíření …............................................................................... 44 7 Použitá literatura …................................................................................................ 45 Příloha A …................................................................................................................. 46 Příloha B …................................................................................................................. 47 Příloha C …................................................................................................................. 49

11

Seznam obrázků Obrázek 1: Ukázka profilu akademického pracovníka v systému Webis …................. 15 Obrázek 2: Ukázka informační architektury webu FF UK …........................................ 17 Obrázek 3: Ukázka profilu lektora na B.I.B.S. ….......................................................... 18 Obrázek 4: Use Case diagram …................................................................................. 22 Obrázek 5: Logo eAcademician.cz ….......................................................................... 23 Obrázek 6: Volba doménového jména …................................................................... 24 Obrázek 7: Grafická podoba sekce Homepage v publikační části …........................... 26 Obrázek 8: Grafická podoba sekce Novinky v publikační části …................................ 26 Obrázek 9: Grafická podoba sekce Výuka v publikační části …................................... 27 Obrázek 10: Grafická podoba sekce Lidé v publikační části ….................................... 28 Obrázek 11: Grafická podoba sekce publikace v publikační části …........................... 29 Obrázek 12: Grafická podoba administračního rozhraní …........................................ 30 Obrázek 13: Datový model informačního portálu ….................................................. 31 Obrázek 14: Ukázka navržené databáze v rozhraní phpMyAdmin ….......................... 32 Obrázek 15: Diagram aktivit workflow správy akademického pracovníka ….............. 33 Obrázek 16: Diagram nasazení …............................................................................... 34

12

13

1

Úvod

1.1

Volba tématu ke zpracování a zdůvodnění volby tématu

V dnešní době době by se dalo říci, že internet téměř hýbe světem. Jedná se o poměrně mladou (zhruba 20 let starou) počítačovou síť, která se však v průběhu těchto 20 let velmi rychle rozvíjela. Tím pochopitelně dramaticky rostl i počet lidí připojených k Internetu. „Mezinárodní telekomunikační unie (ITU) potvrdila, že v loňském roce počet uživatelů internetu překročil magickou hranici 2 miliard – tedy zhruba třetiny celé lidské populace. I počet uživatelů mobilních telefonů přesáhl magickou hranici a to pěti miliard. Podle údajů ITU je největší koncentace internetových nadšenců v Evropě, následuje Amerika, státy bývalého Sovětského svazu a arabské národy.“ 1 Ze statistik ITU je rovněž patrné, že graf počtu uživatelů připojených k internetu v závislosti na čase (v letech) má exponenciální průběh. Internet tedy postupně pronikl téměř do všech oblastí současné lidské činnosti. Jednou z těchto oblastí je pochopitelně i školství, konkrétně vysoké školství, kde v současné době hraje internet nezastoupitelnou roli. A to především z důvodu, že stále více studijní agendy (z pohledu jak studentů, tak i akademických pracovníků) a přijímání důležitých informací probíhá přes internet. Právě vysoké školství bude úzce spjato s touto bakalářskou prací. V současnosti má drtivá většina vysokých škol a univerzit v České republice svoje vlastní webové stránky. Některé jsou zpracované na velmi kvalitní úrovni, některé jsou o poznání horší. Každopádně prakticky všechny webové prezentace tohoto zaměření spojuje vlastnost, že na nich uživatelé najdou nějaké informace pro uchazeče a studenty a kontakty na alespoň pár vybraných akademických pracovníků. Avšak od pana Ing. Bureše (oponenta mojí bakalářské práce) jsem se dozvěděl, že na české akademické sféře chybí univerzální informační portál, který by umožňoval shrnout informace o působnosti akademických pracovníků z různých vysokých škol a univerzit do jedné databáze a prezentovat na jednich, na konkrétní vysoké škole či univerzitě, nezávislých webových stránkách. Proto jsem se rozhodl v rámci svojí bakalářské práce takový informační portál vytvořit. Cílem této práce je tedy analyzovat, navrhnout a implementovat informační portál, který bude uživatele internetu informavat o působení akademických pracovníků na libovolným vysokých školách a univerzitách. 1 http://www.root.cz/zpravicky/pocet-uzivatelu-internetu-v-roce-2010-prekrocil-2-miliardy/

14

2

Analýza

2.1

Srovnávací rešerše existujících aplikací

V úvodní kapitole jsem uvedl, že na české akademické sféře prakticky neexistuje komplexní informační portál, který by umožňoval prezentovat působnost akademických pracovníků na různých vysokých školách a univerzitách. Mnoho vysokých škol univerzit má však na svých webových prezentacích velmi podrobné informace o svých vlastních akademických pracovnících. Proto je potřeba na počátku analýzy této práce udělat srovnávací rešerši, jejímž výsledkem bude informace o tom, jaká data o pracovnících jsou k dispozici na webových prezentacích vybraných vysokých škol a univerzit. V rešerši budu srovnávat a analyzovat tyto webové prezentace: 1) web ČVUT FEL, 2) web Katedry počítačů na ČVUT FEL, 3) web výzkumné skupiny Webing, 4) web Filosofické fakulty UK, 5) web Brno International Business School (B.I.B.S.). 2.1.1

Web ČVUT FEL

Jelikož jsem studentem ČVUT FEL, tak první webová prezentace, jež budu popisovat v této srovnánací řešerši, je právě webová prezentace ČVUT FEL dostupná pod URL adresou http://www.fel.cvut.cz. Na této prezentaci je v sekci Stručně o fakultě 2 podrobně rozepsána organizační struktura fakulty, která je rozdělena na podsekce: 1) vedení fakulty, 2) vědecká rada, 3) akademické poradní sobry, 4) disciplinární komise, 5) děkanát, 6) učební středisko Temešvár. V těchto podsekcích jsou vypsáni pracovníci, jež v příslušných sekcích působí. Avšak o vědecké či pedagogické působnosti jednotlivých pracovníků nenajdeme na samotném webu ČVUT FEL žádné informace. Takové informace nalezneme až na stránkách jednotlivých kateder. Avšak každá katedra na ČVUT FEL má vytvořenou svoji vlastní prezentaci. To má dle mého názoru za důsledek fakt, že data o jednotlivých akademických pracovních nejsou mezi katedrami příliš konzistentní. 2 dostupná pod URL adresou http://www.fel.cvut.cz/glance/structure.html

15 2.1.2

Web Katedry počítačů na ČVUT FEL

Webovou prezentaci Katedry počítačů ČVUT FEL nalezneme pod URL adresou http://cs.felk.cvut.cz/webis. Zde jsou v sekci Lidé k dispozici poměrně podrobné informace o jednotlivých pracovnících katedry. Rozněž se na této prezentaci nalézají informace mj. o vyučovaných předmětech, výzkumných skupinách a událostech, jež nějakých způsobem souvisí se zmíněnou Katedrou počítačů. Proto jsem se při návrhu informační architektury mojí aplikace do jisté míry řidil právě těmito stránkami. Avšak problémem těchto stránek je fakt, že jsou již technicky poměrně zastaralé, což občas přiznávají i samotní akademičtí pracovníci. A to především ti pracovníci, kteří v rámci katedry 36 nebo 39 vyučují webové předměty na oboru Web a multimédia. Zastaralé považuji zejména HTML šablony nakódované prostřednictvím framů.

Obrázek 1: Ukázka profilu akademického pracovníka v systému Webis

16 2.1.3

Web výzkumné skupiny Webing

Web výzkumné skupiny Webing běží pod URL adresou http://webing.felk.cvut.cz. Jestliže jsem v předchozí kapitole 2.1.2 uvedl, že web Katedry počítačů považuji za technicky zastaralý, tak web výzkumné skupiny Webing je v tomto ohledu naopak nesrovnatelně lepsí. A to z důvodu, že je nakódován v (téměř) validním XHTML 1.0 Transitional. Homepage generuje pouze 2 chyby. Grafický design layoutu působí rozněž mnohem čistěji a moderněji ve srovnání se systémem Webis. Z pohledu informační architektury je tato prezentace navržena podobně jako u systému Webis. Informace o akademických pracovnících se nachází v sekci Lidé ve skupině, kde je u každého pracovníka uvedeno: 1) jméno, 2) získané akademické tituly, 3) e-mailová adresa, 4) oblasti zájmu, 5) odkaz na daného pracovníka v systému Webis. Z pochopitelných důvodů jsou zde však k dispozici pouze informace o pracovnících z výzkumné skupiny Webing. 2.1.4

Web Filosofické fakulty UK

Webová prezentace FF UK je k dispozici na adrese http://www.ff.cuni.cz. Web FF UK je rozvržen tak, že horním menu je sekce Fakulta, kde jsou informace o organizační struktuře fakulty. Informační architektura FF UK je navržena podobně, jako třeba webové stránky FEL ČVUT. To znamená, že pokud se chce uživatel dozvědět nějaké informace o tamních akademických pracovnících, tak musí přes tento rozcestník najít jednotlivé katedry. Pod katedrami jsou následně vyjmenovány působící akademičtí pracovníci. Všechny informace jsou však v rámci stejného webového rozhraní jako hlavní stránka fakulty. Takže jsou dle mého názoru tyto informace více konzistentní ve srovnání s web(y) FEL ČVUT, kde má každá katedra svoje speciální stránky. Na druhou stranu ale FF UK má u jednotlivých pracovníků k dispozici pouze e-mailovou adresu a nic víc. Tady je přesně ten problém, o kterém mi říkal na konzultaci pan Ing. Bureš a tedy, že pokud si nějaký akademický pracovník chce na webu FF UK vytvořit prezentaci o své akademické působnosti, tak vlastně nemá kde. Naopak z technického a estetického hlediska na mě působí webová prezentace FF UK velmi dobrým dojmem.

17

Obrázek 2: Ukázka informační architektury webu FF UK

2.1.5

Web Brno International Business School (B.I.B.S.)

V rámci této řeserše jsem dosud srovnával pouze takové webové prezentace, které mají nějakou vazbu na velkou veřejné univerzity v České republice. Jako poslední školu v rámci této řešerše zde naopak uvedu školu, jež je soukromá a má menší počet studentů ve srovnání výše uvedenými veřejnými univerzitami. Řeč bude o Brno International Business School (dále jen B.I.B.S.)

18 B.I.B.S. má svou webovou prezentaci pod URL adresou http://www.bibs.cz a jedná se o vysokou školu ekonomického a právního zaměření, která dlouhodobě spolupracuje s britskou Nottingham Trent University. B.I.B.S. jsem si vybral jako předmět srovávání z důvodu, že tuto školu studuji souběžně s ČVUT FEL, a proto mám informace o její organizační struktuře. B.I.B.S. má cca. 40 stálých kmenových zaměstnanců (akademických pracovníků) a dále zaměstnává cca. 150 externích lektorů, což jsou především odborníci z praxe. Z pohledu informační architektury je webová prezentace vyřešena tak, že těch zhruba 40 stálých je uloženo v sekci Lektorský tým 3. V pozadí této sekce je implementována databáze, ve které je u každého lektora evidováno jeho jméno, získané akademické tituly, e-mailová adresa a případně fotografie. Dále má lektor možnost si do této databáze napsat v odstavcové podobě svůj krátký životopis.

Obrázek 3: Ukázka profilu lektora na B.I.B.S. 3 http://www.bibs.cz/bibs/10/lektorsky-tym/

19

2.2

Analýza požadavků

Jako částečnou inspiraci při analýze požadavků jsem použil webové stránky Katedry počítačů ČVUT FEL, jejichž informační architekturu jsem analyzoval v předchozí kapitole. V sekci Lidé jsou vypsáni jednotliví akademičtí pracovníci a jejich působení. U každého pracovníka jsou uvedeny následující údaje: 1) jméno a příjmení, 2) získané akademické tituly, 3) akademická pozice, 4) e-mailová adresa, 5) členství ve výzkumných skupinách, 6) pedagogická činnost (zde se rozlišuje pedagogická činnost aktuálního semestru a pedagogická činnost z minulosti), 7) publikace akademického pracovníka, 8) citace (zde je uveden seznam publikací, kde někdo citoval z publikací od daného autora), 9) granty (zde se rozlišuje pozice v organizační struktuře řešitelského týmu), 10) výbory konferencí. Toto jsou základní požadavky na informační strukturu informačního portálu. Jelikož základní filosofií (a požadavkem zároveň) navrhovaného informačního portálu je být nezávislý na konkrétní škole či fakultě, tak je potřeba u každého akademického pracovníka uvádět ještě školu a fakultu, na níž dotyčný pracovník působí. Dále považuji za vhodné, aby akademičtí pracovníci měli možnost do svého profilu zadat: 1) kontakt na pevný telefon, 2) kontakt na mobilní telefon, 3) adresu kanceláře či kabinetu, kde je možné je navštívit. Jelikož akademičtí pracovníci často působí na zahraničních univerzitách, tak považuji za nutnost, aby informační portál obsahoval alespoň 2 jazykové mutace. A proto si uživatelé internetu budou moci na přepínat mezi českou a anglickou jazykovou mutací. Celý systém musí pochopitelně fungovat na základě dynamicky generované webové aplikaci a musí být založen na nějaké databázi, což podrobně popíši v kapitole 3. Jako další požadavek shledávám nutnost implementace validního XHTML kódu a navrhnout GUI, které bude z estetického hlediska na vysoké designové úrovni a bude splňovat zásady pro vizuální podobu moderního webdesignu.

20

2.3

Použité SW technologie

Celá aplikace bude postavena na známé a v současné době velmi používané kombinaci programů označovaných zkratkou LAMP. LAMP je sada volně šířitelného svobodného software, jež se využívá pro provoz malých a středně velkých webových aplikací. Tato zkratka v sobě zahrnuje následující technologie: 1) Linux – operační systém, 2) Apache – webový server, 3) MySQL – relační databáze, 4) PHP – serverový programovací jazyk. Jak je z označení patrné, zkratka LAMP vznikla vždy s prvního písmene příslušné technologie. Výše uvádím, že LAMP je sada volně šířitelného software. V této souvislosti je potřeba zmínit, že uvedené technologie na sobě nejsou závislé. To znamená, že teoreticky můžeme jakoukoliv technologii nahradit nějakou jinou dle svého uvážení. Takže například, programovací jazyk PHP můžeme nahradit jazykem Ruby a databázi MySQL můžeme nahradit jinou relační databází (například PostgreSQL nebo SQLite) a to celé rozeběhnout pod webovým serverem Apache. A nebo naopak Apache nahradit technologií serverem IIS od Microsoftu a nad ním pracovat s PHP. Takto to funguje teoreticky. Prakticky je potřeba, aby výše zmíněné možnosti záměny podporovala i samotná aplikace. Zde je zejm. důležité, aby aplikace (ať už napsaná v libovolném serverovém programovacím jazyce) podporovala nezávislost na použití relační databáze. Toho ve své aplikaci docílim díky implementace abstraní databázové vrstvy Dibi, o kterou podrobně popíši v kapitole 4.1. Serverová logika bude tedy implementována v jazyce PHP verze 5 s využitím OOP. Při vývoji jsem aplikaci testoval na PHP verze 5.2.9-1d. Pro datovou vrstvu bude použita databáze MySQL s využitím datového úložisté InnoDB. MySQL je v současné verzi vybaveno více datovými úložišti. Úložiště InnoDB zvolim z důvodu, že podporuje kontrolu dodržování referenční integrity mezi tabulkami. Na druhou stranu nutné dodat, že datové úložistě InnoDB není zdaleka nejrychlejší. Za nejrychlejší datové úložistě v MySQL se považuje úložiště MyISAM, které však může dosahovat příznivých výkonnostních parametrů pouze z důvodu, že jeho funkčnost je velmi omezená. Konkrétně kontrolu dodržování referenční integrity nepodporuje. Zmíněná kontrola dodržování referenční integrity je v mojí aplikaci velmi důležitá, protože se v databázi vyskytuje mnoho tabulek, které pomocí cizích klíčů odkazují na jiné tabulky. Z datového modelu, který popisuji podrobně v kapitole 3.4, je patrné, že navržená databáze má celkem 25 tabulek a z toho 10 jich je v mezi sebou v M:N vztahu. A proto by v takovém návrhu databáze bez kontroly dodržování referenční integrity začal v databázi vznikat nekontrolovatelný chaos, jež by se přímoúměrně zhoršoval s nárustem množství dat.

21

3

Návrh

3.1

Use Case diagram

V odborné literatuře o modelování v jazyce UML se můžeme dočíst, že „Případ užití (use case) je metodou pro zachycení funkčních požadavků na systém. Případy užití popisují typické interakce mezi uživateli systému a samostatným systémem, a předkládají nám příběh o tom, jak je systém používaný.“ 4 U mojí aplikace je potřeba zachytit funkční požadavky v souvilosti z uživatelskými rolemi uživatelů, jež do systému vstupují. Celkově jsou v systému tyto 3 uživatelské role: 1) administrátor, 2) akademický pracovník, 3) běžný uživatel internetu. Nejvyšší uživatelské pravomoci má samozřejmě administrátor, o kterém můžeme s jistou nadsázkou říci, že může se systémem dělat cokoliv – tedy kdekoliv číst, editovat, zapisovat a i mazat veškerá data v databázi. Naopak běžný uživatel internetu nemůže na datech zadaných v IS nic měnit a může je pouze číst a to jen v publikační části. Akademický pracovník představuje z pohledu uživatelských rolí určitý kompromis mezi administrátorem a běžným uživatelem internetu. Uživatelé s touto uživatelskou rolí nemají přístup do správy škol, fakult, akademických pozic a přihlašovacích logů. K ostatním datům mají plný přístup pro čtení, přidávání a editaci příslušných dat. Omezená práva však mají u mazání dat. Mazat data mohou pouze tehdy, pokud příslušná data nesdílí jiný akademický pracovník. Například: budou-li akademičtí pracovníci XX a YY členy výzkumné skupiny ZZ, tak není možné, aby pracovník XX mohl smazat skupinu ZZ. A to z důvodu, že by tím ovlivnil i nastavení profilu u pracovníka YY, což je špatně. V tomto případě by tedy systém umožnil pracovníkovi XX smazat skupiny ZZ pouze tehdy, pokud by členem této skupiny nebyl žádný jiný akademický pracovník. Takto je systém navržen především z důvodu nutnosti dodržování referenční integrity za účelem zachování konzistentních dat v databázi. Tabulky v databázi jsou totiž mezi sebou ve vztahu M:N a jsou propojeny cizími klíči s tímto nastavením: ON DELETE SET NULL ON UPDATE CASCADE 4 FOWLER, M. Destilované UML. 1. vydání. Praha: Grada Publishing, a.s., 2009. s. 103

22 Záměrně jsem tabulky vstupující do vztahu M:N nastavil na SET NULL po spuštění příkazu DELETE a nikoliv na CASCADE. A to z důvodu, že kdyby např. administrátor omylem smazal výzkumnou skupinu, v níž budou akademičtí pracovníci, tak při SET NULL se akademičtí pracovníci nesmažou, ale pouze se jim změní hodnota 1 cizího klíče. Avšak při CASCADE by došlo k automatickému a nevratnému smazání dotyčných akademických pracovníků. Níže uvedený Use Case diagram znázorňuje popsané vztahy mezi jednotlivými uživateli a jejich uživatelskými rolemi.

Obrázek 4: Use Case diagram

23

3.2

Návrh grafiky a informační architektury

Součástí každé webové prezentace by měl být kvalitně navržený grafický návrh splňující požadavky na moderní design a uživatelskou přívětivost. Při navrhování grafiky jsem se snažil vycházet ze svých zkušeností v oblasti tvorby webové grafiky a DTP reklamních tiskovin v komerční sféře. 3.2.1

Pojmenování projektu a návrh loga

„Jedním z nejvýznamnějších vizuálních prvků firmy je firemní značka - logo. Je to základní pilíř kvalitní prezentace a větší důvěry vašich partnerů a zákazníků. Značka by měla být jednoduchá a čitelná "vizuální zkratka". Musí být v souladu s firmou/produktem a to jak obsahově, tak stylově. Svým tvarem, barevností a celkovým pojetím respektovat účel k jakému je tvořena.“ 5

Obrázek 5: Logo eAcademician.cz Jelikož je můj projekt zaměřen na akademické pracovníky a jejich činnost, tak jsem ho pojmenoval názvem eAcademician.cz 6, kde počáteční písmeno „e“ má znamenat, že se jedná o internetovou (elektronickou) prezentaci. Tento název nápadně připomíná internetovou doménu. Takové pojmenování jsem zvolil úmyslně a chtěl jsem tím zdůraznit 2 věci: Za prvné název „eAcademiciam.cz“ definovaný ve stylu internetové domény symbolizuje otevřenost a svobodu projektu vůči vnějšímu okolí, neboť jsem názoru, že internet je v současné době jediné ještě relativně svobodné médium. To odpovídá celkové filosofii projektu, která vychází z požadavku, aby si prakticky každý libovolný akademický pracovník působící na libovolné univerzitě mohl na eAcademician.cz vytvořit svůj vlastní profil, na kterém bude moci na internetu prezentovat své působení v akademické sféře. Za druhé jsem uvažoval nad případným spustěním mého projektu do ostrého provozu, kde je důležité vybrat a zaregistrovat vhodnou doménu. Aby byl projekt na internetu úspěšný a měl vysokou náštěvnost, tak je mj. poměrně důležité vložit do doménového jméno nějaké klíčové slovo, jež souvisí se zaměřením daného projektu. Proto doménu eacademician.cz považuji za vhodnou doménu v situaci, že by pan Ing. Bureš chtěl 5 http://www.amadeusdesign.cz/sluzby-logo.php 6 Výraz „academician“ znamená v anglickém překladu „akademik“.

24 projekt po obhájení této bakalářské práce nasadit do ostrého provozu. Zmiňovaná doména eacademician.cz je v době odevzdání této bakalářské práce (květen 2011) volná. V případě budoucího spustění projektu ji doporučuji bezodkladně zaregistrovat.

Obrázek 6: Volba doménového jména [zdroj: Czechia] 3.2.2

Návrh informační architektury publikační části

„Vybudování informační architektury stránek je proces, od kterého se odvíjí mnoho jiných procesů. Ve své nejjednodušší podobě informační architektura podává přehled o struktuře vašich stránek. Je to proces vytváření kategorií a jejich popisků a rozhodování o tom, kam bude která část stránek patřit a v jakém pořadí. Hypertextové odkazy jsou nelineární – plánování obsahu stránek proto vždy není přímočarý proces. I když informační architektura nijak nesouvisí s grafikou, barvami, animacemi nebo typografií, její vybudování patří k nejdůležitějších aspektům tvorby obsahu webu.“ 7 Prvním krokem při vytváření informační architektury publikační části je stanovení počtu částí a názvů sekcí pro každou část. Publikační část bude mít celkem 9 sekcí (Homepage, Novinky, Lidé, Výzkumné skupiny, Výuka, publikace, Citace publikací, Výbory konferencí a Granty). Tyto sekce se již nebudou dále rozvětvovat, a proto je výhodné navrhovnout tzv. mělkou architekturu a umístit ji do vodorovného menu v horní části webu. Počet sekcí a jejich názvy není potřeba složitě vymýšlet, neboť toto v podstatě vyplývá z požadavků na projekt definovaných v kapitole 2.2. 7 WEINMANOVÁ, L. . 1. vydání. Brno: ZONER software s.r.o., 2004. s. 97

25 3.2.3

Návrh grafické podoby publikační části

Návrh grafické podoby webu považuji za jednu z nejdůležitějších činností při tvorbě každého webu. A to z důvodu, že grafická podoba napomáhá uživateli vytvořit si prvotní dojem o dané webové prezentaci – jak kladný, tak i negativní v případě špatného grafického návrhu. Proto jsem se při tvorbě grafiky snažil dodržovat všechny zásady tvorby moderního grafického designu. „Grafický design by měl pomoci dodat smysl pro důležitost, a sice tím, že by upoutal pozornost na nejdůležitější prvky stránky.“ 8 Stěžejním aspektem při návrhu grafické podoby je volba barev a barevného schématu. „K volbě vhodného barevného schématu pro webové stránky je potřeba znát vztahy mezi barvami. Říká se, že purpurová je barva vášně, červená znamená zlost nebo vyvolávající pozornost, modrá je barva klidu.“ 9 V rámci volby barevného schématu je rovněž potřeba důsledně dbát na zachování vysokého konstrastu mezi jednotlivými prvky. Které barvy jsou mezi sebou konstrastní je dobře poznat na barevném kruhu – nejvíce konstatní barvy jsou vždy proti sobě. Po pečlivém uvážení jsem jako základní komunikační barvy zvolil modrou a oranžovou. Přičemž modrá má zde být ta zmiňovaná „barva klidu“ a oranžová má být výrazná a tedy použita zpravidla pro zbarvení prvků, na než chci nějakým způsobem uživatele upozornit. Pro zjemnění grafických prvků a celkové odlehčení kompozice jsem při návrhu grafického designu často používal barevné přechody.

8 NIELSEN, J; TAHIR, M. Použitelnost domovských stránek. 1. vydání. Brno: ZONER software s.r.o., 2005. s. 31 9 WEINMANOVÁ, L. . 1. vydání. Brno: ZONER software s.r.o., 2004. s. 20

26

3.2.4

Ukázka grafické podoby jednotlivých sekcí

V této kapitole jsou zobrazeny screenshoty, jež mají znázornit grafický design a kompoziční rozvržení stěžejních sekcí v publikační části webu.

Obrázek 7: Grafická podoba sekce Homepage v publikační části

Obrázek 8: Grafická podoba sekce Novinky v publikační části

27

Obrázek 9: Grafická podoba sekce Výuka v publikační části

28

Obrázek 10: Grafická podoba sekce Lidé v publikační části

29

Obrázek 11: Grafická podoba sekce Publikace v publikační části

30

3.2.5

Návrh grafické podoby administračního rozhraní

Grafický návrh pro administrační rozhraní je svým ztvárněním velmi podobný grafickému návrhu publikační části (viz. předchozí kapitola). Z důvodu požadavků na fukčnost je v administračním rozhraní implementováno relativně velké množství formulářů. Proto je celkový design jednotlivých sekcí pro správu webu více uniformní ve srovnání s publikační částí, kde má každá sekce svůj specificky navržený a nakódovaný design.

Obrázek 12: Grafická podoba administračního rozhraní

3.3

Datový model

Pro ukládání dat jsem ve své aplikaci jsem použil oblíbenou relační databázi MySQL, jak jsem uvedl v kapitole 2.3. Při tvorbě datového modelu bylo důležité zaměřit se na správné dodržování referenční intergrity mezi jednotlivými tabulkami. V databázi mám totiž celkem 9 vztahů typu M:N, a proto dodržování referenční integrity je zde nutnost. V opačném případě by se z databáze brzy stal nekontrolovaný a nespravovatelný chaos. Vztahy M:N jsem vyřešil tak, jak se mají takové vztahy navrhovat – tedy pomocí spojové tabulky a definování integritních omezení u všech tabulek, jichž se tato spojení týkají. Dlouho jsem přemýšlel, jak tyto databázové tabulky pojmenovat, aby se v navrženém

31 datovém modelu snadno vyznali i jiní lidé, kteří budou chtít při event. ostrém nasazení v datovém modelu něco upravit. Nakonec jsem vytvořil takový systém pojmenování, kde všechny databázové tabulky, jejichž název je ve formátu číslovka_logickýnázev, tak jsou ve vztahu M:N s jinou tabulkou, která je pojmenována ve stejném formátu. Spojová tabulka takových 2 tabulek pak nese pojmenování ve tvaru číslovka_číslovka. Například: Mějme tabulky akademických pracovníků a vyučovaných předmětů. Obě tabulky musí být ve vztahu M:N, protože 1 akademický pracovník může učit více předmětů a zároveň 1 předmět může učit více akademických pracovníků. Pojmenování příslušných 3 tabulek podle výše definované konvence je následující: • • •

název tabulky akademických pracovníků: 1_akademicky_pracovnik název tabulky vyučovaných předmětů: 8_vyuka název spojové tabulky: 1_8

Obrázek 13: Datový model informačního portálu

32

Obrázek 14: Ukázka navržené databáze v rozhraní phpMyAdmin

3.4

Návrh jazykové mutace

Důležitou součástí zadání této práce bylo navrhnout vhodnou jazykovou mutaci. Tento požadavek má svůj smysl, neboť akademičtí pracovníci velmi často působí na zahraničních vysokých školách a univerzitách a to v rámci různých grantů, výzkumných projektů apod. Proto je potřeba, aby v této webové prezentaci byly implementovány alespoň 2 jazykové mutace. Jako jazyky pro jazykové mutace jsem zvolil češtinu a angličtinu. Angličtinu z toho důvodu, že se v současné době jedná o světový jazyk č. 1. Budu-li podporu jazykové mutace popisovat z technického hlediska „od spoda“ 10, tak jsou v databázových tabulkách vloženy všechny řetezcové atributy, kterých se jazyková mutace týče, dvakrát. Zmíněné atributy se mezi sebou liší označením, které je vždy ve formátu: logickynazevatributu_{cz|en}. Jinými slovy, každý řetězcový atribut, u nehož má být rozlišována jazyková mutace, je v příslušné databázové tabulce vložen s koncovkou „cz“ a „en“. Proto je zde snadná možnost budoucího rozšížení o 3. jazykovou mutaci, při kterém by 10 Myšleno od nejnižší vrstvy webové aplikace – tedy datové.

33 pouze stačilo ke všem těmto atributům přidat ještě 3. verzi. Ta by byla označena koncovkou podle toho, o jaký jazyk by šlo. Takže např. „de“ nebo „ru“ apod. Na tento koncept na datové úrovni navazuje řešení na úrovni aplikace. Na úrovni aplikace je podpora jazykové mutace implementována tak, že se do $_GET['jazyk'] ukládají HTTP požadavky na volbu jazyka. U takto zadaného HTTP požadavku se escapují všechny „nebezpečné“ znaky, jež by mohly pomoci v realizaci útoku SQL Injection. A následně se, z důvodu stability zvoleného jazyka, data z $_GET['jazyk'] převedou do $_SESSION['jazyk']. V této podobě jsou do SQL dotazů v podstatě zadávány požadavky na výpis dat z požadované jazykové mutace. Na úrovni prezentační vrstvy je podpora jazykové mutace naimplementována velmi snadno - a to pomocí vlaječek, jež se nachází v pravé části horního menu.

3.5

Diagram aktivit

V tomto diagramu aktivit je znázorněno kompletní workflow správy akademického pracovníka v administračním rozhraní – tedy funkcí přidání, editace a smazání.

Obrázek 15: Diagram aktivit workflow správy akademického pracovnika

34

3.6

Diagram nasazení

„Diagram nasazení (deployment diagram) ukazuje fyzické rozvržení systému a přitom odhaluje, který software běží na kterém hardwaru.“ 11 Níže uvedený diagram nasazení mj. také vizuálně znázorňuje veškeré použité softwarové technologie, jež jsou popsány v kapitole 2.3.

Obrázek 16: Diagram nasazení

11 FOWLER, M. Destilované UML. 1. vydání. Praha: Grada Publishing, a.s., 2009. s. 101

35

4

Implementace

4.1

Architektura aplikace

Všechny třídy, které nějakým způsobem pracují s databází, jsou děděny z třídy pripojeni, kde je zajištěno připojení k databázi přes abstraktní databázovou vrstvu Dibi. Abstraktní třídu Dibi jsem zvolil z důvodu odstínění výkonné aplikační logiky od databáze a to z důvodu bezpečnosti práce s databází (Dibi automaticky escapuje všechny „nebezpečné“ znaky, jež mohou vstupovat do databáze). Z použití Dibi pro práci s databázi také plyne výhoda nezávislosti aplikace na použité databázi. Dibi totiž obsahuje ovladače pro 8 relačních databází (MySQL, MySQLi, PostgreSQL, SQLite, ODBC a experimentální MS SQL, Oracle a PDO). Dalším důvodem, proč jsem si vybral Dibi je způsob, kterým se do Dibi zapisují SQL příkazy. Samotná třída Dibi podporuje několik způsobů zápisu SQL dotzů. Mě se nejvíce zalíbila forma, jež David Grudl 12 na svém blogu phpfaschion.com označuje, jako „DibiFluent“, což lze lidově nazvat jako „tekuté SQL příkazy“. Zápis SQL příkazu prostřednictvím DibiFluent je velmi intiutivní a lze díky němu efektivně eliminovat syntaktické chyby, kterých se programátoři občas dopustí při ručním psaní SQL příkazů. Struktura SQL příkazu zadaného formou DibiFluent může vypadat např. takto 13: $res = dibi::select('product_id')->as('id') ->select('title') ->from('products') ->innerJoin('orders')->using('(product_id)') ->orderBy('title') ->execute(); // nebo $record = array( 'title' => 'Výrobek', 'price' => 318, 'active' => TRUE, ); dibi::update('products', $record) ->where('product_id = %d', $id); ->execute();

12 Autor Dibi 13 Převzato z http://phpfashion.com/dibifluent-tekute-sql-prikazy

36 Připojení k databázi přes abstraktní vrstvu Dibi může vypadat například takto: class Pripojeni { public function __construct() { require_once 'dibi/dibi/dibi.php'; self::pripojeni(); }

}

public function pripojeni() { try { dibi::connect(array( 'driver' => 'mysqli', 'host' => 'localhost', 'username' => 'root', 'password' => 'heslo', 'database' => 'eacademian', 'charset' => ZNAKOVA_SADA_DB, )); } catch (DibiException $e) { echo get_class($e), ': ', $e->getMessage(), "\n"; }

}

4.2

Popis nejdůležitějších tříd

Moje aplikace má implementovaných zhruba 50 tříd. Z těchto cca. 50 tříd jsou některé pouze doplňkové, ale mnohé z nich pochopitelně tvoří jádro aplikace a bezproblémový chod aplikace je na nich závislý. Jsem názoru, že by bylo nad rámec rozsahu této bakalářské práce podrobně popsat úplně všechny implementované třídy. A proto dále v této kapitole popíši alespoň význam a způsob implementace těch nejdůležitěších z nich. V pro lepší přehlednost popisu nejdůležitějších tříd rozdělím implementované třídy do těchto 3 kategorií: 1) obecně využívané třídy, 2) třídy publikační části, 3) třídy administračního rozhraní. Do kategorie obecně využivaných tříd zařazuji takové třídy, které nějakým způsobem využívá celá aplikace (tady publikační část i administrační rozhrani). Třídy spadající do zbylých 2 kategorií slouží, jak název napovídá, pro implementaci buď publikační části, nebo administračního rozhraní.

37 4.2.1

Obecně využívané třídy

Pro celou aplikaci je zcela nejdůležitější třída pripojeni. V této třídě totiž probíhá připojení k databázi přes databázovou vrstvu Dibi, jak jsem popsal v kapitolách 3.3 a 4.1 A jelikož je celá aplikace postavena, jako dynamická aplikace založená na databázi, tak je pro chod aplikace tato třída naprosto nepostradatelná. Proto všechny třídy, které nějakým způsobem pracují s databází, jsem naimplementoval tak, že s této třídy dědí. Další velmi důležitou obecně využívanou třídou je třída popisky. Tato třída obsahuje implementaci metod, jež mají v celé aplikaci na starost generování různých stavových a chybových hlášek, práci s řetězci, metodami pro validaci dat apod. Metody v této třídě jsou implementovány jako statické a s přístupem public. Volání nějaké metody s třídy popisky může vypadat např. takto: popisky::pocet_zaznamu_databaze('je uložena', 'je uloženo', 'škola', 'škol', $pocet); popisky::chybova_hlaska('V databázi není vložena žádná škola.');

Třídy popisky_jazyk obsahuje implentaci podpory jazykových mutací a to konkrétně textů, které jsou v aplikaci dány na pevno a uživatel je nemůže měnit. K tomu slouží zpravidla jedno či více rozměrná asiociativní pole, kde vždy jeden z parametrů je zvolený jazyk, který se při běhu aplikaci ukladá do $_SESSION['jazyk'], kde jsou možné pouze 2 klíče – buď „cz“ nebo „en“ podle vybrané jazykové mutace. Ukládání uživatelem zvolené jazykové mutace do $_SESSION['jazyk'] probíha automaticky pomocí skriptu jazyk.php, který je volán v magické metodě __autoload na začátku každého funkčního sktripu. Takto například vypadá implementace pro podporu jazykové mutace pro horní menu v publikační části: /* jazykově mutovaný text pro konkrétní sekce */ static public function horni_menu($jazyk, $sekce) { $horni_menu=array( 'cz'=>array( 'homepage' => 'Homepage', 'novinky' => 'Novinky', 'lide' => 'Lidé', 'vyzkumne_skupiny' => 'Výzkumné skupiny', 'vyuka' => 'Výuka', 'publikace' => 'Publikace', 'citace' => 'Citace publikací', 'vybory' => 'Výbory konferencí', 'granty' => 'Granty' ), 'en'=>array(

38 'homepage' => 'Homepage', 'novinky' => 'News', 'lide' => 'People', 'vyzkumne_skupiny' => 'Research groups', 'vyuka' => 'Education', // nevim 'publikace' => 'Publications', 'citace' => 'Citations',//nevim 'vybory' => 'Conference Commitees', 'granty' => 'Grants')); return $horni_menu[$jazyk][$sekce];

}

4.2.2

Třídy publikační části

Publikační část samozřejmě hojně využívá obecně užívané třídy popsané v předchozí kapitole. K tomu obsahuje implementaci tříd, jež jsou logicky rozděleny podle 9 hlavních sekcí webu. A dále společnou třídu pro všech těchto 9 sekcí je třída nadpis_text. V této třídě se načítají data z databázové tabulky x_sekce s příslušným ID (podle vybrané sekce) a s příslušnou jazykovou mutací (podle hodnoty v $_SESSION['jazyk']). Jedná se tedy o data, která se v administračním rozhraní zadávají ve správě hlavních dat prostřednictvím JavaScriptového editoru TinyMCE. Ostatní třídy v publikační části vždy načítají data z databázových tabulek k příslušným sekcím v horním menu. Implementace těchto tříd je u všech sekcí velmi podobná, proto považuji za zbytečné je všechny jednotlivě popisovat. Avšak bohužel nejsou tak moc podobné, aby je bylo možné nějakým efektivním způsobem generalizovat. Například implementace třídy novinky, jež vypisuje všechny novinky po otevření sekce Novinky vypadá takto: class novinky extends pripojeni { public $pocet_zaznamu = NULL; function vypis() { $select = dibi::select('id_novinky, nadpis_' . $_SESSION['jazyk'] . ' AS nadpis, text_' . $_SESSION['jazyk'] . ' AS text') ->from('novinky') ->orderBy(array('id_novinky'=>'desc', 'nadpis'=>'asc')); $i=1; foreach($select as $row) { $id_novinky = popisky::naplnit_id($row['id_novinky']); $nadpis = (($row['nadpis'] != NULL) ? $row['nadpis'] : '---'); $text = (($row['text'] != NULL) ? $row['text'] : '---'); $text = strip_tags($text); $text = substr($text, 0, 200); }

// zde probíhá výpis dat ze zadaného SQL dotazu

39 $this->pocet_zaznamu = intval(count($select)); }

}

Výše jsem popsal, že implementace všech těchto tříd je podobná. Jedinou výjimku tvoří třída, která má za úkol vypisovat data v sekci Lidé. U této třídy je jinak koncipován SQL dotaz na SELECT dat z databáze. A to z důvodu, že v této sekci se vypisují nejen data z tabulky 1_akademicky_pracovnik, ale zároveň i data z ostatních tabulek, jež jsou s touto tabulkou propojeny pomocí cizích klíčů (např. 2_fakulta, 3_pracovnik_pozice apod.) Proto v SQL dotazech, jež v souvisí se sekcí Lidé, je potřeba spojovat tabulku pomocí spojení typu LEFT JOIN. Například takto: class lide extends pripojeni { public $pocet_zaznamu = NULL; function vypis() { $select = dibi::select('ap.id_akademicky_pracovnik, ap.tituly_pred, ap.jmeno, ap.prijmeni, ap.tituly_za, ap.fotka, s.zkratka_' . $_SESSION['jazyk'] . ' AS skola, f.nazev_' . $_SESSION['jazyk'] . ' AS fakulta, p.nazev_' . $_SESSION['jazyk'] . ' AS pozice') ->from('1_akademicky_pracovnik ap') ->leftJoin('1_6') ->using('(id_akademicky_pracovnik)') ->leftJoin('6_skola s')->using('(id_skola)') ->leftJoin('1_2') ->using('(id_akademicky_pracovnik)') ->leftJoin('2_fakulta f')->using('(id_fakulta)') ->leftJoin('1_3') ->using('(id_akademicky_pracovnik)') ->leftJoin('3_pracovnik_pozice p') ->using('(id_pozice)') ->orderBy(array('ap.prijmeni'=>'asc', 'ap.jmeno'=>'asc', 'ap.id_akademicky_pracovnik'=>'asc'));

4.2.3

Třídy administračního rozhraní

Třída prihlasit je první třída, se kterou se setkáme při přihlašování do administračního rozhraní aplikace. Do jejího konstruktoru se předávají instanční proměnné login a heslo, které (jak jejich název napovídá) v sobě nesou informace o uživateli. Úkolem této třídy je porovnat uživatelem zadané údaje proti databázi a v případě úspěšné validace uživatele přihlásit. V opačném případě tato třída vygeneruje hlášku o neúspěšném přihlášení. Každopádně třída prihlasit uloží do databáze následující informace: 1) login uživatele, který se chtěl přihlásit,

40 2) datum a čas pokusu o přihlášení, 3) IP adresa pokusu o přihlášení, 4) výsledek přihlašovacího procesu (zda-li byl úspěšný či neúspěšný). Některé aplikace ještě při neúspěšném přihlášení zadají jako informaci, pro administrátora heslo, kterým se uživatel zkoušel (neúspěšně) přihlásit. Tuto funkci jsem se po zvážení rozhodl záměrně neimplementovat, protože to v sobě nese jedno bezpečností riziko. Aby mělo smysl tuto informaci do databáze ukládat, tak musí být toto heslo v otevřené podobě (tedy nikoliv jeho SHA1 otisk). Kámen úrazu nastává v okamžiku, kdy se uživatel při zadávání hesla překlepne byť jen o 1 znak a systém pokus o přihlášení vyhodnotí, jako neúspěšný. Systém by uložil heslo v otevřené podobě mezi neúspěšné pokusy a potencionální útočník by tak měl snadno k dispozici text, jež se velmi podobá skutečnému heslu dotyčného uživatele. Proto jsem názoru, že je nejlepší v databázi ukládat hesla pouze v tabulkách, kde jsou evidováni příslušní uživatelé a v jen zahashované podobě. K tomu používám hashovací funkci SHA1 a každé heslo před převedením na jeho SHA1 otisk ještě tzv. „osolím“ do podoby heslo + login a až tento řetězec následně předevedu do SHA1. Toto solení je zde implementováno opět kvůli zvýšení bezpečnosti. Kdyby totiž implementováno nebylo, tak by v databázi byli poznat ti uživatelé, kteří mají stejné heslo (např. značně naivní řetězec „heslo“ apod.). A to je opět další informace „k dobru“ pro případného útočníka. Další důležitou třídou v administračním rozhraní je třída wysiwyg. Tato třída, jak již její název napovídá, slouží k tomu, aby editovala data mezi WYSIWYG editorem TinyMCE a databázovou tabulkou x_sekce. Jedná se tedy v podstatě o modifikaci třídy nadpis_text z publikační části do podoby takové, aby vyhovovala funkčním požadavkům v administračním rozhraní. Jinak je v administračním rozhraní situace podobná, jako u publikační části. Opět platí, že pro správu dat jednotlivých sekcí je implamantace příslišných tříd mezi vzájemně sebou podobná. Úmyslně jsem se rozhodl správu těchto dat impelentovat nikoliv přímo do administračního rozhraní, nýbrž do vyskakovacích oken, která se otevírají přes JavaScript prostřednictvím odkazů v administračním rozhraní. V tomuto rozhodnutí mě vedla myšlenka, že je dobré, aby měl uživatel souběžně k dispozici správu dat ve WYSIWYG editoru a správu ostatních dat, jež souvisí s danou sekcí. A toho lze efektivně docílit v podstatě pouze na základě implentace vyskakovacích oken.

41

5

Testování

V rámci testování jsem na své aplikaci prováděl tato testování: 1) funkční testování, 2) testování validity XHTML kódu, 3) testování kompatibility webových prohlížečů.

5.1

Funkční testování

Cílem funkčního testování je zjistit, zda-li naprogramované funkce pracují tak, jak pracovat mají a zda-li se aplikace při práci s ní chová stabilně. Za tímto účelem jsem otestoval následující důležité funkce v systému: 1) přidání, editaci a smazání akademického pracovníka, 2) přidání, editaci a smazání novinky, 3) přidání, editaci a smazání výzkumné skupiny, 4) přidání, editaci a smazání školy, 5) přídání, editaci a smazání fakulty, 6) zobrazení logu přihlášení do systému, 7) změna textu v sekci Homepage prostřednictvím WYSIWYG editoru, 8) změna hesla administrátorského účtu, 9) změna heslo účtu akademického pracovníka, zobrazení profilu akademického pracovníka v publikační části, 10) odolnost vstupů do aplikace vůči útoku SQL Injection.

5.2

Testování validity XHTML kódu

U webových prezentací je velmi důležité, aby byl XHTML kód validní. Pouze tak je totiž relativně jistota, že se uživatelům zobrazí v prohlížeči to, co se zobrazit má. Proto jsem testoval validitu XHTML kódu v publikační části programem Html Validator verze 0.9.0.4. Tento validátor funguje ve Firefoxu, jako zásuvný modul.

5.3

Testování kompatibility webových prohlížečů

Dalším neméně důležitým faktorem pro posuzení použitelnosti, přístupnosti a funkčnosti webových stránek je testování kompatibility webových prohlížečů. Tato problematika se ze své postaty týká pouze klientské části aplikace a je důležité aplikaci otestovat v nejvíce používaných webových prohlížečích. A to z důvodu, že se často stává, že některé prohlížeče zobrazují nakódované šablony stránek se špatnými velikostmi HTML elementů

42 nebo dokonce tak, že jsou dané HTML elementy „rozházené“. Těmito problémy trpí zejména webový prohlížeč Microsoft Internet Explorer. Proto jsem svou aplikaci testoval celkem na 2 různých počítačích: 1) Fujitsu-Siemens LIFEBOOK E-8410, s operačním systémem Microsoft Windows Vista Business, 2) Fujitsu-Siemens CELSIUS Mobile H230, s operačním systémem Microsoft Windows XP Professional. Na těchto počítačích jsem aplikaci testoval v prohlížečích: 1) Mozilla Firefox 4.0.1, 2) Opera 11.01, 3) Google Chrome 4.0.249.78, 4) MS Internet Explorer 8. Protože se ve všech výše zmíněných prohlížečích zobrazovaly všechny HTML elementy správně, tak lze testování považovat za úspěšné.

43

6

Závěr

6.1

Shrnutí

Výsledkem mojí bakalářské práce je webová aplikace informačního portálu, jež má sloužit jako online databáze akademických pracovníků. Zadání na tuto bakalářkou práci vzešlo od pana Ing. Bureše, od kterého jsem se dozvěděl, že by potřeboval naimplementovat informační portál akademických pracovníků. Základním požadavkem na tento informační portál bylo, aby byl nezávislý na působnosti (škole, příp. fakultě) dotyčných akademických pracovníků. A to z důvodu, že mnohé vysoké školy a univerzity neumožňují tamním akademickým pracovníkům vytvořit si profilovou stránku, která by prezentovala jejich pedagogickou činnost a vědecké výsledky. A zároveň přinejmenším na českém internetu není k dispozici komplexní informační systém, který by umožnil akademickým pracovníkům vytvořit si svou prezentaci nezávisle na vzdělávací instituci, kde působí. Tento fakt jsem znalyzoval na vybraných českých vysokých školách a univerzitách v kapitole 2.1. Z této analytické srovnávací řešerše jsem dospěl k analýze požadavků, co vlastně bude potřeba implementovat. Následně jsem začal vytvářet grafický návrh vizuální podoby budoucího informačního portálu. Tento proces je posán v kapitole 3.2 Po vytvoření grafického návrhu jsem se pustil do samotného programování, k němuž jsem použil známou kombinaci softwaru označovaného zkratkou LAMP (Linux, Apache, MySQL a PHP). Po dokončení implementace jsem u vytvořené aplikace otestoval funkčnost důležitých funkcí v administračním rozhraní a publikační části, validitu XHTML kódu a kompatibilitu prezentace v závislosti na použití různých webových prohlížečů. Dále jsem aplikaci naplnil základními daty pro testování. Prostřednictvím WYIWYG editoru jsem do aplikace vysázel odstavce vygenerovaného textu Lorem ipsum. Co se týče naplnění naplnění databáze akademických pracovníků (včetně tabulek, jež souvisí s akademickými pracovníky), tak tuto databázi jsem po dohodě s doc. Jelínkem, prostřednictvím administračního rozhraní, naplnil daty z výzkumné skupiny Webing. Tedy v současné době jsou v databázi pracovníci, jež jsou členy této skupiny. Testovací verze publikační části v této podobě je k dispozici na mém hostingu pod URL adresou: www.tn-design.cz/ecademician/ Testovací verze administračního rozhraní je k dispozici pod URL adresu: www.tn-design.cz/ecademician/administrace/

44 Pro přístup do administračního rozhraní je v databázi vytvořen administrátorský účet, jehož přihlašovací údaje jsou: uživatelské jméno: admin heslo: admin Spustěním a naplněním dat u testovací verze jsem vlastně znovu otestoval fukčnost systému. Všechny testy dopadly úspěsně, a tudíž by tato aplikace měla být stabilní a dobře ovladatelná. Jsem proto přesvědčen, že cíl mojí bakalářské práce byl úspěšně splněn.

6.2

Možná budoucí rozříření

V případě, že tuto aplikaci pan Ing. Bureš bude chtít po obhájení mojí bakalářské práce nasadit do ostrého provozu, tak bych navrhoval v budoucnu implementovat následující rozšíření: 1) implementace vyhledávacího filtru, 2) propojení se systémem Webis Katedry počítačů ČVUT FEL. Vyhledávací filtr bych doporučoval implementovat v případě, že bude dramaticky narůstat objem dat způsobený nárustem počtu akademických pracovníků v databázi. V takové situaci by totiž mohlo docházet ke zbytečnému zatížení databázového serveru, které zatím není poznat, protože je aplikace naplněna malým objemem dat. Zmiňovaný vyhledávací filtr by tento možný budoucí problém mohl efektivně vyřešit, neboť by se díky němu uživatelům vypisovala pouze ta data, jež uživatel zadá do vyhledávacího filtru. Jako další případné rozšíření vidím možnost propojit tento systém se systémem Webis, jež běží na Katedře počítačů ČVUT FEL, eventuelně s jinými systémy podobného zaměření. Zde je ovšem potřeba důkladně zvážit výhody a nevýhody tohoto propojení. V případě, že by se do databáze ukládala většina pracovníků ze zmíněné Katedry počítačů, tak by určitě takové propojení smysl mělo. Pokud by však byl tento systém v ostrém provozu skutečně nezávislý a registrovaní akademičtí pracovníci by byli ze širokého spektra vysokých škol a univerzit, tak si myslím, že podobné propojování ztrácí význam. A naopak by mohlo systému uškodit z důvodu vzniklé závislosti na systému, s nímž by byl propojen. To vše však lze poznat až při reálném provozu.

45

7

Použitá literatura

[1]

Blog Davida Grudla. Dostupné na:

[2]

BUREŠ, M. Materiály z cvičení z předmětu Y39TW1 na ČVUT FEL

[3]

Dokumentace k Dibi. Dostupné na:

[4]

Dokumentace k PHP. Dostupné na:

[5]

Dokumentace k MySQL. Dostupné na:

[6]

FOWLER, M. Destilované UML. 1. vydání. Praha: Grada Publishing, a.s., 2009. 176 s. ISBN 978-80-247-2062-3.

[7]

KLÍMA, M. přednáškové slidy z předmětu Y39TW1 na ČVUT FEL

[8]

KREJČÍ, L. PHP Kapesní přehled. 1. vydání. Brno: Computer Press, a.s., 2006. 108 s. ISBN 80-251-0808-2.

[9]

NIELSEN, J; TAHIR, M. Použitelnost domovských stránek. 1. vydání. Brno: ZONER software s.r.o., 2005. 324 s. ISBN 80-86815-18-8.

[10] SVOBODA, V. Systém pro tvorbu internetových stránek. Praha, 2010. 88 s. Bakalářská práce. ČVUT FEL. [11] VALENTA, M. přednáškové slidy z předmětu Y36DBS na ČVUT FEL [12] WEINMANOVÁ, L. . 1. vydání. Brno: ZONER software s.r.o., 2004. 504 s. ISBN 80-86815-10-2. [13] http://www.bibs.cz [14] http://cs.felk.cvut.cz [15] http://cs.wikibooks.org/wiki/PHP_prakticky/Odstranění_diakritiky [16] http://www.fel.cvut.cz [17] http://www.ff.cuni.cz/ [18] http://interval.cz/clanky/umoznete-pridat-stranku-k-oblibenym-odkazum/ [19] http://webing.felk.cvut.cz [20] http://webtrh.cz/58625-pridani-stranky-oblibenych

46

Příloha A Instalační a uživatelská příručka V této příloze popíši, jak informační portál nasadit na nějakém serveru (ať už lokálním či vzdáleném) a co vše je potřeba nastavit, aby systém fungoval správně. Popis instalace: 1) Z přiloženého CD nakopírujte na server celý obsah složky www. 2) Na stejném serveru založte nějakou relační SQL databázi. Díky implementaci Dibi je aplikace nezávislá na volbě relační databáze. Doporučuji však použít databázi MySQL s datovým úložištěm InnoDB, protože na této databázi je aplikace otestována. Zvolená databáze musí podporovat kontrolu dodržování referenční integrity. 3) Do založené databáze spusťe SQL dump s názvem eacademician.sql uložený ve složce sql_dump na přiloženém CD. 4) V souboru pripojeni.php, který se nachází ve složce www, zadejte parametry pro připojení k databázi vytvořené v kroku 2. 5) Otevřte z webového přohlížeče složku /administrace nacházející se na serveru, kam jste systém nahrál v kroku 1. V případě, že je aplikace úspěšně nainstalována, tak by se nyní mělo objevit rozhraní pro přihlášení do administračního rozhraní systému. Pokud se systém povedlo úspěšně nainstalovat, tak bych nyní doporučoval u tohoto administrátorského účtu změnit heslo z hesla „admin“ na nějaké, které bude složitější a obtížněji uhodnutelné.

47

Příloha B Seznam použitých zkratek Níže je uveden seznam zkratek, které se v této práci vyskytují, a jejich význam: B.I.B.S. – Brno International Business School ČVUT – České vysoké učení technické v Praze FEL – Fakulta elektrotechnická ČVUT FF – Filozofická fakulta Univerzity Karlovy v Praze GUI – Graphical User Interface HTML – HyperText Markup Language HTTP – HyperText Transfer Protocol IIS – Internet Information Services IS – Informační systém LAMP – Linux, Apache, MySQL, PHP PHP – PHP: Hypertext Preprocessor SHA1 – Secure Hash Algorithm UK – Univerzita Karlova v Praze UML – Unified Modeling Language WYSIWYG – What you see is what you get

48

Příloha C Obsah přiloženého CD Adresáře na CD: •

/sql_dump – SQL dump pro vytvoření databáze

•

/text – tento text bakalářské práce

•

/www – zdrojové kódy naprogramované webové aplikace