Slezská univerzita Filozoficko přírodovědecká fakulta Ústav informatiky

Slezská univerzita Filozoficko přírodovědecká fakulta Ústav informatiky Bakalářská diplomová práce Autor: Petr Mrůzek Obor: Informatika a výpočetní technika Opava 2008

Slezská univerzita Filozoficko přírodovědecká fakulta Ústav informatiky Bakalářská diplomová práce Vytvoření systému pro inventarizaci prostředků informačních technologií na Slezské univerzitě (Development of stocktaking and reconciliation system for information technologies on the Silesian University) Autor: Petr Mrůzek Obor: Informatika a výpočetní technika Vedoucí práce: Ing. Lukáš Macura Opava 2008

Prohlašuji, že jsem tuto práci vypracoval samostatně a že jsem použil pouze uvedené zdroje a literaturu. Beru na vědomí, že odevzdáním své bakalářské diplomové práce souhlasím se zveřejněním své práce podle zákona o vysokých školách a s tím, aby sloužila ve schodě s mými autorskými právy zájemcům o mou práci. V Opavě dne...... (podpis)

Na tomto místě bych rád poděkoval vedoucímu této bakalářské diplomové práce, Ing. Lukáši Macurovi, za jeho ochotu, cenné rady a připomínky. Dále bych mu chtěl poděkovat za poskytnutí diskového prostoru a zprovoznění testovacího serveru. Ještě jednou děkuji za vzájemnou spolupráci.

Obsah 1 ÚVOD...6 2 ANALÝZA SOUČASNÉHO STAVU INVENTARIZACE IT NA SLEZSKÉ UNIVERZITĚ...8 2.1 Zabbix...8 2.2 Porty...9 3 VÝBĚR VHODNÉHO OPENSOURCE SOFTWARE A KNIHOVEN PRO TVORBU APLIKACE...10 3.1 PHP...10 3.1.1 Popis jazyka PHP...11 3.1.2 Verze jazyka a některé rozdíly mezi nimi...12 3.2 ODBC...13 3.3 MySQL...13 3.4 Apache HTTP Server...14 3.5 TRAC...14 3.5.1 Wiki...14 3.5.2 Tickets (úkolovací systém)...15 3.5.3 Timeline...16 3.5.4 Browse Source (Procházet zdrojový kód)...16 3.6 SUBVERSION...17 3.6.1 Základní pojmy a postupy...17 3.6.2 Správa verzí pomocí Subversion...19 4 VYTVOŘENÍ STRÁNKY O PROJEKTU A JEHO VÝVOJI...20 4.1 Nastavení prostředí TRAC...20 4.2 Přístup do SVN repozítáře...20 4.3 Nastavení lokálního serveru a databáze...21 4.3.1 Nastavení serveru Apache...21 4.3.3 Nastavení PHP...21 4.3.3 Nastavení ODBC ovladače...22 4.3.4 PhpMyAdmin...22 4.4 Vývoj a podpora projektu...23 4.4.1 Milestone: Roadmap pro verzi 0.1...23 4.4.2 Datový model...23 4.4.3 Popis datového modelu...24 4.4.4 Konzolidace adresářů...29 4.4.5 Programování tříd a jejich metod...29 4.4.6 Plnění jednotlivých úkolů (Tickets)...33 4.5 Testování...39 4.5.1 Testování během psaní zdrojového kódu...39 4.5.2 Testování hotové aplikace zkušebními daty...39 5 PŘEDÁNÍ DO PROVOZU...42 5.1 Nasazení SRSW4IT na Filozofickopřírodovědecké fakultě Slezské univerzity. 42 5.2 Propojení s dalšími systémy...42 5.3 Náměty pro budoucí verze a moduly...43 6 ZÁVĚR...44 7 PŘÍLOHY...47 Příloha I. Soupis tabulek s detailním popisem sloupců...47 Příloha II. Export datového modelu do grafické podoby...51 Příloha III. Unikátní indexy...52 Příloha IV. Zkušební data pro testování aplikace...53 Příloha V. Ukázky výsledku práce programu Doxygen...54 Příloha VI. Výpis výchozích typů událostí z databáze...55

1 ÚVOD Zadání bakalářské diplomové práce bylo inspirováno potřebou Slezské univerzity inventarizovat prostředky informačních technologií. Protože současný stav evidence všech zařízení se podle provedené analýzy ukázal být nevyhovující, je cílem práce vytvořit inventarizační software, který by splňoval zadané požadavky. Mezi nejdůležitější požadavky patřily otevřenost zdrojového kódu a nezávislost aplikace na použitém databázovém systému a platformě. Požadovaná nezávislost na použité databázi měla zajistit, že software bude fungovat pod kterýmkoli systémem řízení báze dat beze změny kódu a funkčnosti. Přestože byl pro práci vybrán databázový systém MySQL, je tak možno použít libovolný databázový systém (MS SQL Server, PostgreSQL atd.). Aby mohl být zdrojový kód včetně dokumentace přístupný veřejnosti, bylo dalším úkolem vytvoření a provoz webových stránek o projektu. Každý návštěvník stránek by tak měl možnost použít aplikaci pro vlastní specifické účely, případně dopracovat nové potřebné funkce. Pomocí úkolovacího systému, který je blíže popsán ve třetí kapitole, by měly být zadávány nové náměty. Na základě veřejné diskuze tak bude možno software postupně rozšiřovat o nové moduly a vylepšení. Dalším požadavkem byla správa softwaru přes webové rozhraní. Software nemá sloužit jako program spouštěný na jedné lokální stanici, ale jako samostatná serverová aplikace. Bude přístupný kterémukoli počítači s připojením na internetovou síť a proto dalšími úkoly bylo vytvoření struktury uživatelských účtů a zabezpečení softwaru proti neoprávněnému zneužití. Dále by měl tento software mít dostatečně obecný datový model. Protože, kromě základních tabulek ze systému Zabbix, nebyly stanoveny žádné konkrétní typy objektů a zařízení, které se v systému budou ukládat, musel datový model umožňovat i vložení takových typů objektů a zařízení, s nimiž se v průběhu vývoje nepočítalo. Vlastní práce je členěna do sedmi kapitol. Po úvodu a části věnované stručné analýze současného stavu inventarizace informačních technologií na Slezské univerzitě 5

následuje třetí kapitola zabývající se výběrem vhodného opensource softwaru a knihoven pro tvorbu aplikace. Ve čtvrté kapitole je shrnuta nejdůležitější část práce. Je zde popsáno nastavení jednotlivých systémů pro podporu vývoje a jejich uvedení do provozu. Důraz je kladen především na popis datového modelu, vytvořených tříd a jednotlivých fází vývoje projektu. Její součástí je také podkapitola o testování softwaru. Stručné informace o předání vyvíjeného softwaru do provozu jsou obsaženy v páté kapitole. Za ní následuje závěrečné shrnutí a seznam použité literatury a zdrojů. Jednotlivé přílohy jsou označeny římskými číslicemi a uvedeny v samostatné kapitole. Hlavní součástí bakalářské diplomové práce je přiložené CD s kompletní adresářovou strukturou vyvíjeného softwaru. Jednotlivé soubory zdrojového kódu jsou rozděleny podle jejich funkce. CD také obsahuje digitální verzi textu bakalářské diplomové práce v originálním formátu ODT (Open Office Document) i ve formátu PDF. 6

2 ANALÝZA SOUČASNÉHO STAVU INVENTARIZACE IT NA SLEZSKÉ UNIVERZITĚ 2.1 Zabbix V současné době je na Slezské univerzitě v provozu dohledový systém Zabbix 1, který má kromě jiných součástí obsažen i modul zvaný Inventory. Tato součást systému uchovává a zobrazuje informace o používaných informačních technologiích. Ovšem vzhledem k tomu, že inventarizace není hlavním účelem systému Zabbix, ale pouze jeho doplňkovou funkcí, není tento stav právě optimální. Neexistují zde šablony pro různé typy zařízení a data jsou tak uchovávána ve stejných tabulkách ať se jedná o stolní počítač nebo serverovou stanici. Důsledkem toho je, že jsou některé tabulky téměř prázdné (viz obr. 1). Obr. 1 Tabulka zařízení (host profile) v systému Zabbix 1 Oficiální stránky programu: http://www.zabbix.com 7

Prvky jsou sice děleny do skupin, ale nelze zde vyhledávat jednotlivá zařízení podle názvu nebo upřesňujících parametrů. Pro účely systému Zabbix je tento stav dostačující, avšak pro důkladný inventář prostředků IT je zcela nevhodný. 2.2 Porty Informace o propojení mezi jednotlivými zařízeními, které jsou ve valné většině případů řešeny ethernetovými porty, jsou v současnosti ukládány do tabulek kancelářského programu MS Excel. Protože jde pouze o tabulkový editor, jsou data uchovávána v nepřehledných tabulkách, mnohdy v několika souborech. Toto řešení se zdá být pouze provizorní a nehodí se pro složitější vyhledávání. Jednotlivé tabulky mezi sebou povětšinou nemají žádnou vazbu a už vůbec nejsou propojitelné se současným stavem inventarizace v systému Zabbix. 8

3 VÝBĚR VHODNÉHO OPENSOURCE SOFTWARE A KNIHOVEN PRO TVORBU APLIKACE S ohledem na uvedené požadavky na software, který je cílem této práce, bylo nutné vyhledat nástroje, pomocí nichž budou tato kritéria splněna. Protože inventarizační aplikace má mít přístup přes webové rozhraní, zvolili jsme kombinaci skriptovacího jazyka PHP 2 a databázového přístupu pomocí rozhraní ODBC. Toto standardizované API 3 umožňuje přístup do většiny nejpoužívanějších databázových systémů. Pro účely práce byl vybrán jeden z nejznámějších systémů řízení báze dat a tím je MySQL 4. Pro zprovoznění serverové aplikace je také nutné použít softwarový webový server, jímž se stal Apache HTTP Server 5. K vytvoření stránky o projektu a jeho vývoji byl použit nástroj přímo určený k vývoji softwarových projektů. Jde o nástroj Trac 6, webové rozhraní, které zprostředkovává komunikaci mezi členy vývojového týmu. Trac také poskytuje přístup k centrálnímu úložišti zdrojových kódů (repository 7 ). Každý větší projekt, ať již na něm spolupracují vícečlenné týmy nebo jej vyvíjí samostatná osoba, potřebuje spravovat jednotlivé verze svého vývoje. Právě kvůli potřebě verzování zdrojových kódů bylo nutné zvolit nástroj, který uspokojí alespoň základní potřeby a funkce pro správu verzí 8. Jelikož systém Trac, pomocí něhož je aplikace vyvíjena, podporuje SVN repository, zvolili jsme nástroj Subversion 9. 3.1 PHP Označení PHP bylo původně zkratkou pro Personal Home Page. Tuto technologii vytvořil v roce 1994 Rasmus Lerdorf kvůli sledování 2 PHP (PHP: Hypertext Preprocessor) 3 API (Application Programming Interface) - rozhraní pro programování aplikací 4 Oficiální stránky: http://www.mysql.org 5 Oficiální stránky: http://httpd.apache.org 6 Oficiální stránky: http://trac.edgewall.org 7 repository centrální úložiště zdrojového kódu projektu. Viz kapitola o systému Subversion 8 vytvoření pracovní kopie, potvrzení provedených změn, apod. Viz kapitola o systému Subversion 9 Oficiální stránky: http://subversion.tigris.org 9

návštěvníků svých webových stránek. Postupem času se ujal rekurzívní název PHP: Hypertext Preprocessor. 3.1.1 Popis jazyka PHP PHP je vloženým skriptovacím jazykem 10. Je-li PHP vložen do HTML, znamená to, že jej lze interpretovat přímo v kódu HTML, což se často uplatňuje při vývoji dynamických webových aplikací. K jeho použitelnosti na webu také přispívá, že není jazykem programovacím, ale skriptovacím, protože je navržen tak, aby vykonal určitou činnost (např. ověření správnosti uživatelského hesla) jako reakci na nějakou událost (např. potvrzení a odeslání formuláře). PHP je technologie nezávislá na platformě a je určena pro servery. Skutečnost, že jde o serverovou technologii, napovídá, že vše, co se v kódu PHP odehrává, se neodehrává na klientském počítači, ale na serveru. Ke klientovi se již dostane jen výsledek vykonané operace, nejčastěji v podobě vygenerované HTML stránky. Protože tato technologie není závislá na platformě, lze jazyk PHP použít na většině operačních systémů (vč. MS Windows, Unix, Linux a Macintosh). Díky tomu také skript napsaný na jednom serveru bude fungovat prakticky bez úprav i na jakémkoli jiném serveru. PHP je také jazyk hybridní. Autoři si vypůjčili jazykovou syntaxi částečně od jiných jazyků, jako jsou C, Perl, Java nebo prostředí Příkazového řádku. Dle vyjádření autorů 11 přebírá PHP od jiných jazyků jen ty nejlepší vlastnosti a vytváří tak snadno použitelný a velmi výkonný skriptovací jazyk. 10 Viz http://www.php.net 11 Mistrovstvi v PHP 10

3.1.2 Verze jazyka a některé rozdíly mezi nimi PHP/FI bylo první verzí nástroje, nazvaného Personal Hompage Tools/Form Interpreter. Byl to vlastně jazyk podobný jazyku Perl a byl schopen zpracovávat odesílání dat z formulářů. Chybělo mu však mnoho základních jazykových konstrukcí (např. Příkaz for). V roce 1997 byl původní nástroj PHP/FI přepracován a v této době si nové verze všimli Andi Gutmans a Zeev Suraski. Zjistili, že PHP/FI není tak účinný jak se domnívali a že mu chybí řada důležitých funkcí. Proto se rozhodli jazyk zcela přepracovat. Spojili se s Rasmusem Lerdorfem a společně připravili verzi PHP 3. V této době také vznikl název PHP: Hypertext Preprocessor. Nástroj již nebyl určen jen pro osobní potřebu, navíc byla implementována nová rozšíření rozhraní API. Po uvolnění třetí verze se odhadovalo, že PHP je nainstalován na 50 000 domén. Skriptovací stroj PHP 3 zpracovával skript během čtení. Verze PHP 4 už přišla s novým přístupem. Místo aby stroj překládal skript do strojového kódu, vytvořil bajtový kód, jenž byl pak zpracován pomocí stroje Zend Engine 12. Tedy nejprve se provedl překlad a až poté zpracování. Tento způsob zpracování skriptů výrazně zvýšil výkon jazyka bez narušení zpětné kompatibility s jazykem PHP 3. Jazyk PHP ve verzi 4 byl oficiálně uvolněn v březnu roku 2002 a dnes je nainstalován na více než 15 milionech domén. Při přepracování PHP 3 na verzi 4 došlo ke změně skriptovacího stroje a zvýšení výkonu. Ovšem objektově orientovaný model, který byl do verze 3 přidán jen jako syntaktická laskomina pro usnadnění přístupu ke kolekcím 13, zůstal prakticky nedotčen. I přes svá zásadní omezení byl tento objektový model široce 12 Zend symbolizuje jména Zeev (Suraski) a Andi (Gutmans) 13 Gutmans A., Bakken S. S., Rethans D.: Mistrovství v PHP 5. 2. vydání. Brno Computer Press, a.s. 2007. s. 33. 11

používán po celém světě a to zejména v rozsáhlejších aplikacích. Tato skutečnost vedla k tomu, že mu v nové verzi autoři věnovali zvláštní pozornost. Kromě vylepšeného objektového modelu však PHP 5 obsahuje i další rozšíření funkcí, např. Funkce pro práci s dokumenty XML nebo podpory dalších technologií. 3.2 ODBC Open Database Connectivity (ODBC) je standardizované softwarové API pro přístup k databázovým systémům (DBMS 14 ). Snahou ODBC je poskytovat přístup nezávislý na programovacím jazyku, operačním systému a databázovém systému. Díky této vlastnosti je možné aplikaci přesunout na web s jiným DBMS bez nutnosti opravovat celý kód. Stačí nainstalovat příslušný ovladač ODBC a pozměnit DSN 15 pro přístup k danému databázovému systému. 3.3 MySQL MySQL je relační databázový systém, vytvořený švédskou firmou MySQL AB, nyní dceřinou společností společnosti Sun Microsystems 16. Komunikace s touto multiplatformní 17 databází probíhá pomocí jazyka SQL 18. Podobně jako u ostatních SQL databází se jedná o dialekt tohoto jazyka s některými rozšířeními. Je k dispozici jak pod bezplatnou licencí GPL, tak pod komerční placenou licencí. MySQL byla vytvořena v roce 1995 jako jednoúčelová databáze pro snadné ukládání a především čtení textových dat v internetových 14 DBMS (DataBase Management systém) Systém řízení báze dat (SŘBD) 15 DSN (Data Source Name) - je logickým názvem používaným rozhraním ODBC (Open Database Connectivity) k odkazu na ovladač a další informace, které jsou vyžadovány pro přístup k datům. 16 Viz článek na stránkách http://news.cnet.com/8301-10784_3-9851644-7.html ze dne 16.1.2008 17 Pracuje např. na platformách: FreeBSD, OpenBSD, Linux, MAC OS, Novell NetWare, Solaris, SunOS, Windows (95, 98, ME, NT, 2000, XP, Vista) 18 SQL (Structured Query Language) strukturovaný dotazovací jazyk používaný v relačních databázích 12

aplikacích. V současné době má vysoký podíl na dnes používaných databázích. Velmi oblíbená je dnes kombinace MySQL, PHP a Apache. 3.4 Apache HTTP Server Apache 19 HTTP Server je softwarový webový server s otevřeným kódem pro Linux, BSD, Microsoft Windows a další platformy. V současné době dodává prohlížečům na celém světě většinu internetových stránek. 3.5 TRAC Jak jsem již uvedl v úvodu této kapitoly, Trac je nástroj k vývoji softwarových projektů, který je určen jednotlivcům i vývojářským týmům. Jde o webové rozhraní, jenž zprostředkovává komunikaci mezi členy vývojového týmu registrovaným osobám podle jejich práv. Tato komunikace probíhá pomocí dvou hlavních funkcí Tracu, stránek wiki a úkolového systému. 3.5.1 Wiki Wiki 20 je software, který umožňuje uživatelům jednoduše tvořit a editovat webové stránky a vzájemně je propojovat pomocí odkazů. Wiki je často používána k tvorbě kolaborativních 21 stránek, či stránek 19 Apache - název vznikl z úcty a obdivu k domorodému kmenu indiánů - Apačů anebo anglického slovního spojení A patchy server (patchovaný server, kdysi byl Apache pouze sada patchů pro jiný web server). Jako indiánský symbol je ve znaku ptačí pero. 20 "wiki", resp. "wikiwiki" pochází z Havajštiny, ve které je to výraz pro "rychlý" resp. "velmi rychlý". Teprve později vznikl tzv. backronym WIKI = "What I Know Is" (To, co vím je). "backronym" je anglický výraz pro akronym, jež nevznikl spojením začátků slov do názvu, ale vznikl z již existujícího názvu, aby dodatečně vysvětlil význam. 21 Slovo kolaborativní se běžně zaměňuje za kooperativní. Skupina kolaboruje (spolupracuje) na dosažení určitého cíle, obvykle na splnění složitější úlohy. Za splnění jsou zodpovědní všichni členové skupiny. Spolupráce vychází z otevřené komunikace, probíhá v atmosféře rovnocennosti, důvěry, sdílení a podpory. Z práce skupiny mají prospěch všichni jednotlivci. Členové skupiny zastávají různé role. 13

velkých komunit. Ward Cunningham, tvůrce první wiki, ji líčí jako "nejjednodušší online databáze, která by snad měla fungovat" 22. Principem wiki je otevřenost a jednoduchý značkovací jazyk, který je následně interpretován do HTML kódu a zobrazen v prohlížeči. Uživatel se pak neztrácí v nepřehledných párových a nepárových značkách jazyka HTML, ale formátuje text jednoduchými symboly. Editace stránek probíhá kolizní metodou, což znamená, že jakmile chce uživatel uložit upravenou stránku, kterou mezitím změnil a uložil jiný uživatel (čímž dojde ke kolizi), systém stránku neuloží. Bližší informace o wiki lze nalézt na internetu 23. 3.5.2 Tickets (úkolovací systém) Hlavním účelem Tracu je pomoci vývojářům v práci a v tom, mít přehled o již hotových částech projektu, o úlohách, které je potřeba vyřešit, a termínech jejich splnění. Tuto funkci obstarává Roadmap, což je jakýsi seznam mezníků (milestones) na cestě k hotovému projektu. Milestone (mezník) se používá k označení jednotlivých etap vývoje. Nese také informaci o předpokládaném datu splnění všech úkolů, které jsou mezníku přiřazeny. Jakmile jsou všechny splněny (a to pouze tehdy), Milestone je hotov a uzavřen. Pohledem na uzavřené i otevřené mezníky každý ze skupiny vývojářů snadno pozná, jaké části jsou hotovy, na jakých se právě pracuje a do kterého data by měly být uzavřeny. Jednotlivé úkoly (Tickets) jsou přiřazovány registrovaným uživatelům vývojářům. Mohou být různého druhu a mít rozdílnou prioritu. 22 Viz stránky http://wiki.org/wiki.cgi?whatiswiki 23 http://cs.wikipedia.org/wiki/wiki, http://en.wikipedia.org/wiki/wiki 14

Druhy úkolů (ve výchozím nastavení): defect chyba, vada, potřeba odstranit problém enhancement vylepšení, pozvednutí úrovně task problém, těžký úkol request požadavek, přání, dotaz, návrh Priorita (ve výchozím nastavení): blocker blok, překážka critical rozhodující, kritický úkol major důležitý, závažný úkol minor menší, podružný úkol trivial triviální, jednoduchý úkol 3.5.3 Timeline Timeline, neboli časová osa projektu, je další částí systému Trac. Na této stránce je uložena historie změn podle data. Lze nastavit od jakého data, případně v jakém časovém intervalu, mají být provedené změny zobrazeny. Zobrazení je možné dále filtrovat na úkoly, editované stránky, mezníky (milestones), nebo změny v repozitáři 24 (changeset). 3.5.4 Browse Source (Procházet zdrojový kód) Tato stránka zobrazuje aktuální obsah repozitáře. Umožňuje vyhledat, revizi 25 po revizi, posloupnost všech změn, které byly v kódu provedeny. Po změně souborů se zdrojovými kódy nejsou do repozitáře uloženy celé jejich kopie, ale zapíší se pouze rozdíly mezi revizemi (diff 26 ). 24 repository centrální úložiště zdrojového kódu projektu. Viz kapitola o systému Subversion 25 revision pořadové číslo změny. Viz kapitola o systému Subversion 26 diff z anglického difference. Zvýrazňuje řádky, které se liší oproti předchozím verzím kódu 15

3.6 SUBVERSION Tento nástroj, vyvíjený firmou CollabNet, Inc je šířen pod licencí, která umožňuje jeho bezplatné komerční využití a existuje k němu velmi dobře zpracovaná dokumentace 27. Původně vznikl jako náhrada za starší nástroj CVS a je také založen na principu centrálního úložiště. Přestože se starším CVS inspiruje, je mnohem flexibilnější a přístup k centrálnímu úložišti může být realizován pomocí více přístupových metod. Subversion lze provozovat na mnoha platformách, včetně Windows. Skládá se ze dvou hlavních částí serverové a klientské. Klientská část poskytuje nástroje pro práci s verzemi přímo v pracovním adresáři a komunikaci se serverovou částí, která se stará o repository (centrální úložiště). K repository lze přistupovat lokálně, nebo přes nativní protokol svn://. Existuje také několik klientských nástrojů, od příkazové řádky, přes webové rozhraní až po nástroje integrované do GUI operačního systému. Umožňuje tak uživateli vybrat způsob, který mu nejvíce vyhovuje. 3.6.1 Základní pojmy a postupy Repository (repozitář, centrální úložiště) Umožňuje organizovat projekt a spravovat jeho verze. Fyzicky je uloženo na souborovém systému serveru. K repository se přistupuje přes Repository Access Layer (RA) systému Subversion a jeho správa se provádí klientskými nástroji. Branch (větev) Slouží k organizaci repository, jedná se o analogii s adresáři. Pokud se z repository vyzvedne větev, na klientovi vznikne adresářová struktura, která přesně odpovídá větvím v repository. 27 Viz http://svnbook.red-bean.com 16

Revision (revize) Revize je pořadové číslo každé změny. Slouží ke sledování změn ve větvích v čase. Každá změna v nějaké větvi vytvoří novou revizi v rámci celé repository. Revize obsahuje informace o tom, co bylo změněno, kdo změnu provedl, poznámku a čas. Pracovní kopie Kopie dat z určité větve z repository v aktuální revizi uložená na pevný disk lokálního klienta. Do pracovní kopie je možné provádět změny, které je možné commitem uložit zpět do repository. Commit Odeslání změn provedených od posledního commitu do repository. Commit je nejčastěji používaná změna při práci s repository. Pokud se provádí commit celé pracovní kopie, jedná se o atomickou operaci, jsou odeslány veškeré změny ve všech objektech ve správě verzí. Pokud dojde k nějaké chybě při přenosu, není commit pro ostatní uživatele repository zviditelněn a nová revize není vytvořena. Konflikt Konflikt je stav signalizující, že stejný objekt, který má být právě commitován, byl změněn někým jiným a nachází se v repository v aktuální revizi v jiné podobě, než jaká je v pracovní kopii. Nelze provést commit celé pracovní kopie, pokud se v ní nachází jeden nebo více souboru v konfliktu. Changeset Changeset je sada změn, které se posílají z pracovní kopie do repository (nebo sada změn provedených v rámci repository). Subversion ukládá vždy jen informace o provedených změnách, tedy 17

rozdíly mezi jednotlivými revizemi. Tím se spoří místo na disku a snižuje objem dat přenášených z klienta na server. Merge Sloučení změn z větve v repository do pracovní kopie. Lze specifikovat určitý rozsah změn, a to intervalem revizí. Cheap-copy Technika, kterou se realizují kopie prováděné v rámci repository. Objekty nejsou v repository fyzicky duplikovány, ale jsou vytvořeny tzv. odkazy (link) na kopírované objekty. Zjednodušeně lze chápat takový link jako informaci o URL s číslem revize. Díky tomu má SVN nízké nároky na datový prostor. 3.6.2 Správa verzí pomocí Subversion Následující příklad ukazuje, jak probíhá správa verzí pomocí SVN. Jedná se o zjednodušený proces, kdy jsou požadavky vyvíjeny za sebou, nikoliv paralelně, a vyvíjený projekt se již nachází v repository. Postup práce pak probíhá následovně. Vyzvednutí projektu (tzv. checkout) z repository do lokálního adresáře. Tím se vytváří pracovní kopie, která funguje jako pracovní prostor. Editace požadovaných souborů (přidání, mazání). Odeslání změn do repository (tzv. commit). Změny jsou viditelné pro všechny uživatele repository. Spolu se změnami se zapisuje čas jejich poslání do repository, autor a textový komentář. Další vývojář (pokud již má pracovní prostor) provede stažení aktuální verze z repository (tzv. update) a pokračuje ve vývoji. Vytvořené změny opět odešle do repository (tzv. commit). 18

4 VYTVOŘENÍ STRÁNKY O PROJEKTU A JEHO VÝVOJI Před samotným zahájením vývoje softwaru, bylo nutné zprovoznit vývojové prostředí Trac. Pro účely práce byl poskytnut webový prostor na univerzitním serveru 28 s již předinstalovanou aplikací. Dále byl zajištěn přístup do univerzitního SVN repozitáře 29. Aby bylo možné testovat zdrojové kódy aplikace, musel být vytvořen lokální server pomocí Apache HTTP Server. 4.1 Nastavení prostředí TRAC Prvním krokem ve vývojovém prostředí bylo vytvoření uživatelských účtů a nastavení uživatelských práv. Bylo potřeba zajistit, aby měl nepřihlášený uživatel přístup k informacím o projektu a možnost vytvořit nový úkol, ale administrátorské funkce 30 mu zůstaly skryty. Poté následovalo vytvoření stránky o samotném projektu. Úvodní stránka obsahuje informace o licenci budoucího softwaru, programovacím jazyce, použitém databázovém systému i anonymním přístupu do repozitáře. Jsou zde uvedeny i externí odkazy na webové stránky používaných technologií a interní odkazy na další informace (např. datový model). 4.2 Přístup do SVN repozitáře Pro uchovávání verzí budoucího zdrojového kódu byla zprovozněna komunikace mezi lokálním počítačem a vzdáleným úložištěm. Protože systém Subversion má svůj vlastní přístupový protokol svn://, bylo nutné nalézt vhodný program, který tímto protokolem komunikuje. Stal se jím TortoiseSVN. Tento software poskytuje uživatelům operačního systému 28 http://srsw4it.bp.opf.slu.cz 29 svn://srsw4it.bp.opf.slu.cz/srsw4it 30 Např. editace stránek wiki, tvorba mezníků či nastavení samotného prostředí 19

Windows jednoduchou integraci verzovacího nástroje přímo do kontextového menu Průzkumníka. Vytvoření pracovní kopie je tak snadným úkolem. Stačí pravým tlačítkem vybrat složku a v kontextovém menu zvolit možnost SVN Checkout. Stejně jednoduché jsou pak i další funkce. Pro účely projektu bylo využito především základních funkcí k vytvoření a aktualizaci pracovní kopie, vyhledání provedených změn a vytvoření nové revize příkazem commit. 4.3 Nastavení lokálního serveru a databáze Pro správnou funkci testovacího provozu na lokálním serveru byla nainstalována trojice nástrojů Apache, PHP 5 a MySQL. Kvůli splnění požadavku nezávislosti aplikace na platformě či použité databázi bylo dále nutné nainstalovat ovladač pro přístup k databázi MySQL pomocí ODBC. Pro snadnější kontrolu změn provedených v databázi byl využit nástroj phpmyadmin. 4.3.1 Nastavení serveru Apache Vzhledem k tomu, že server Apache nepotřebuje složitou konfiguraci, stačilo jej nastavit velmi jednoduše editací souboru httpd.conf. Důležitými kroky byla změna výchozího pracovního adresáře, pojmenování serveru (na localhost) a nastavení výchozí stránky na index.php 31. 4.3.2 Nastavení PHP V konfiguračním souboru php.ini bylo nutné pozměnit několik základních parametrů. 31 Volby DocumentRoot, ServerName a DirectoryIndex 20

short_open_tag = Off error_reporting = E_ALL display_errors = On display_startup_errors = On register_globals = Off Proměnná short_open_tag umožňuje začínat skripty PHP zkrácenou verzí tagu <??> místo plného tagu <?php?>. Nastavení na hodnotu On může mít za následek kolizi se zkrácenými značkami jiných jazyků, např. XML. Funkci register_globals vypínáme z bezpečnostních důvodů. Umožňuje totiž automaticky definovat proměnné ze superglobálních polí GET, POST a COOKIE jako globální proměnné. Je to ovšem jen pojistka, neboť v celém kódu jsou používána právě superglobální pole (např. $_GET['what']). 4.3.3 Nastavení ODBC ovladače Aby skripty komunikovaly s databází MySQL pomocí ODBC, je potřeba nastavit DSN (Data Source Name). To se provádí v Nástrojích pro správu ve volbě Datové zdroje (ODBC). Je nutné vyplnit pole DSN, Server, User, Password a Database. 4.3.4 PhpMyAdmin Pomocí nástroje PhpMyAdmin se musí vytvořit pracovní databáze, která v našem případě nese název srsw4it. Také je možné nastavit heslo k MySQL databázi změnou v tabulce user v databázi mysql. 21

4.4 Vývoj a podpora projektu Samotný vývoj probíhal hlavně ve dvou rovinách. První se týkala plnění úkolů v systému Trac, plánování nových úkolů, debaty nad těmi nesplněnými a doplňování stránek Wiki. Druhá pak obsahovala samotné programování v textovém editoru a testování na lokálním serveru. 4.4.1 Milestone: Roadmap pro verzi 0.1 Na počátku vývoje jsme potřebovali sepsat hlavní myšlenky a požadavky na budoucí aplikaci. Pro tento účel jsme vytvořili mezník, který tyto požadavky shrnuje. Kromě samotných požadavků je v něm popsán postup pro zadání návrhu na funkci či jiná vylepšení softwaru. Nový požadavek může zadat každý návštěvník stránek o projektu, stačí pouze vyplnit formulář pro zadání úkolu New Ticket a přiřadit tento ticket uživateli mruzek. 4.4.2 Datový model Datový model je základem celého softwaru, neboť je-li navržen nevhodně, nezbývá než jej přepracovat a začít od začátku. Vzhledem k důležitosti této části práce bylo diskuzím kolem datového modelu věnováno velké množství času a úsilí. Model musel být dostatečně obecný, aby byla aplikace použitelná v širším měřítku a ne jen pro jednu organizaci. Datový model byl v průběhu práce měněn a doplňován o další entity vždy, když bylo nutné použít další relace či doplnit stávající tabulky 32 o nové sloupce. Protože se naše databáze skládá z jednoduchých tabulek, které jsou mezi sebou propojeny, nebyl vytvářen žádný ER diagram, ale přímo 32 V této práci používáme slova relace a tabulka jako synonyma, i přes to, že mezi nimi existuje jistý rozdíl. 22

model databáze. Pro tento účel jsme použili freeware program Data Toad Modeler 33. Tento nástroj umožňuje jednoduchým způsobem definovat relace (jako tabulky v logickém modelu) a vazby mezi nimi. Pomocí exportu tabulek do grafického formátu byl vytvořen obrázek datového modelu (viz Příloha II.). 4.4.3 Popis datového modelu Model je v současné době tvořen 18-ti relacemi, které jsou vzájemně propojeny cizími klíči. Protože má být aplikace nezávislá na platformě i databázi, jsou cizí klíče v tabulce tvořeny přidáním sloupce, který obsahuje identifikátor záznamu z jiné tabulky. Tyto sloupce jsou pojmenovány tak, aby bylo na první pohled zřejmé, že jde o cizí klíč, a to jak v datovém modelu, tak v databázi samotné. Každý takový klíč začíná písmeny ID a pokračuje buď názvem tabulky, k níž se identifikátor vztahuje, nebo výstižným popisem toho, co klíč v této tabulce představuje. Např. V tabulce Device představuje sloupec IDDeviceType cizí klíč z tabulky DeviceType a sloupec IDOwner označuje osobu z tabulky User, která je vlastníkem tohoto zařízení. Následují odstavce shrnují pouze základní informace o jednotlivých tabulkách. Celkový soupis sloupců, spolu s detailním popisem jejich významu, je uveden v Příloze I. Device (zařízení) Zařízením se rozumí základní datová jednotka, kterou budeme používat. Zařízením se rozumí také část již existujícího zařízení, o němž si chceme udržet informace. Tabulka Device definuje základní parametry každého zařízení. Kromě povinných atributů obsahuje také tři nepovinné 33 Program je ke stažení na stránkách http://www.casestudio.com/csy a to jak v bezplatné tak v komerční verzi 23

sloupce začínající písmeny Img. Tyto sloupce jsou zde nachystány pro případ vytvoření modulu, který všechna uložená zařízení rozmístí po vytvořené 2D či 3D mapě. DeviceType Typ zařízení je šablona, která definuje doplňující parametry pro zařízení. Tabulka DeviceType obsahuje pouze název a popis šablony, samotné parametry jsou k zařízení přiřazovány pomocí tabulky DeviceTypeAttribute. AttributeType Atribut je jeden parametr zařízení. Jako atribut se může použít jakákoli informace, ať již chceme uchovávat informaci o stavu zařízení, nebo potřebujeme popsat nějakou část zařízení, které nechceme věnovat samostatný záznam v tabulce Device. Jako příklad můžeme uvést např. atribut procesor, životnost projektoru nebo provozní stav zařízení. Tabulka AttributeType tak potvrzuje obecnost datového modelu. ConnectorType Typ propojení definuje možnost propojení dvou atributů mezi sebou. Tabulka ConnectorType obsahuje seznam všech možných propojovacích typů. Pro vytvoření propojovací vazby mezi atributy je nutné, aby byl typ propojení u obou atributů stejný. Příkladem mohou být ethernetové porty. DeviceTypeAttribute Tato tabulka slouží pro přiřazení jednotlivých atributů k typům zařízení. Jde o implementaci vztahu M:N mezi relacemi DeviceType a AttributeType. Tímto se teprve vytváří šablona pro určitý typ zařízení. Kromě cizích klíčů z obou tabulek obsahuje tato relace sloupce, které 24

určují maximální počet atributů pro jedno zařízení s touto šablonou a dědičnost či unikátnost hodnoty pro jedno zařízení nebo celou šablonu. AttributeData Tato tabulka obsahuje hodnoty atributů, které jsou danému zařízení definovány skrze šablonu. Mimo cizích klíčů a hodnoty atributu obsahuje každý záznam pořadové číslo, které udává pořadí instance typu atributu v rámci zařízení. Dále obsahuje informace o datu vložení, datu poslední úpravy a o tom, který uživatel poslední změnu provedl. Link Tato relace slouží pro vytvoření vztahu (vazby) mezi atributy. Slouží jako implementace unárního vztahu M:N nad tabulkou AttributeData. Jak již bylo uvedeno, spojovat lze pouze atributy se stejným typem propojení. Kombinace vstupního a výstupního atributu je jedinečná a proto je na ni vytvořen unikátní index. DeviceGroup Zařízení je potřeba rozdělovat do skupin podle různých parametrů. Jedno zařízení může být zařazeno do několika skupin. Např. zařízení Projektor může patřit do skupiny Vizuální technika a zároveň do skupiny Zařízení ústavu informatiky. DeviceGroupDevice Pomocí této tabulky je implementováno přiřazení zařízení ke skupinám. Tak jako již v předchozích případech jde o implementaci vztahu M:N a to mezi tabulkami DeviceGroup a Device. I zde je použit unikátní index na dvojici cizích klíčů. 25

User V této relaci jsou uloženy informace o uživatelích aplikace. Kromě iniciál, uživatelského jména a hesla jsou zde kontaktní informace a také skupina a organizační jednotka, ke které osoba náleží. Jedinou povinnou kontaktní informací je telefonní číslo. V systému mohou být uvedeny osoby, které nepotřebují být přihlášeny k aplikaci. Tyto osoby mají uloženo nulové heslo. UserGroup Uživatelská skupina slouží nejen k rozdělení uživatelů, ale také k nastavení uživatelských oprávnění pro zařízení. Uživatel může být pouze v jedné skupině. UserGroupRights Tabulka UserGroupRights slouží pro implementaci vztahu M:N mezi tabulkami UserGroup a Rights, tedy definuje oprávnění dané skupiny uživatelů k zařízením. Rights Pro každé vložené zařízení se vytvoří tři záznamy v této tabulce. Každý z těchto záznamů má různou hodnotu oprávnění, jeden pro čtení (r), druhý pro čtení a modifikaci neklíčových atributů (w) a třetí pro úplnou editaci zařízení (a). OU Organizační jednotkou je myšlen jakýkoli útvar v organizaci. Na Slezské univerzitě může jít o fakulty, ústavy apod. Jednotky jsou do tabulky OU ukládány hierarchicky pomocí tzv. tečkové syntaxe. Názvem jednotky je zkratka následovaná tečkou a názvem nadřazené jednotky. Název bez tečky značí hierarchicky nejvýše položený útvar. 26

Při vkládání nového útvaru se pak testuje existence organizační jednotky uvedené za tečkou. Každá jednotka má přiřazenu skupinu uživatelů, kteří v ní mohou měnit či vytvářet zařízení. Building V tabulce Building jsou uvedeny budovy, které k organizaci patří. Sloupec adresy sice nesplňuje podmínku nedělitelnosti hodnoty v relaci, ale pro účely této aplikace předpokládáme, že nebude třeba hledat zařízení např. podle poštovního směrovacího čísla. Adresa je zde tedy chápána jako atomická (dále nedělitelná) hodnota. Room Pro umístění zařízení je třeba evidovat také jednotlivé místnosti. Tabulka Room obsahuje základní informace o tom, ve které budově a poschodí se místnost nachází a také kontaktní osobu, na kterou je možno se v případě potřeby obrátit. EventType Pro administraci systému jsou uchovávány důležité události a změny v aplikaci. Výchozí data vyvíjené práce obsahují základní typy událostí, které mohou být uchovávány. Podle hodnoty sloupce Importance (Důležitost) se dají jednotlivé záznamy filtrovat např. pouze na závažné chyby v aplikaci. Event Tabulka Event je místem pro uložení všech událostí, které systém zaznamenává. Vzhledem k tomu, že změny v aplikaci jsou nevratné, uchovává se zde datum změny, identifikátor přihlášeného uživatele, jeho IP adresa, typ události a popisný text. Ten může například při chybném přihlášení obsahovat zadané uživatelské jméno. 27

4.4.4 Konsolidace adresářů Před začátkem programování bylo třeba zvážit adresářovou strukturu projektu. V každém adresáři by měly být uloženy soubory, které spolu souvisí. Soubory tříd by měly být pro přehlednost odděleny od zbylého kódu, stejně jako kaskádové styly a obrázky. Vzniklá počáteční struktura je zobrazena na obrázku č.2. Obr. 2. Počáteční adresářová struktura projektu Třídy samotné jsme uložili do zvláštního adresáře classes, obrázky potřebné pro zobrazení aplikace do složky images, soubory, které se načítají do hlavní stránky, jako například hlavička, menu a pata, jsou uloženy v adresáři includes. V další složce scripts jsou PHP skripty pro zobrazení a ošetření jednotlivých formulářů a také inicializační skript init.php, který načte do databáze počáteční data. Složka styles je určena pro soubory kaskádových stylů CSS. 4.4.5 Programování tříd a jejich metod Třídy tvoří jádro výsledné aplikace a veškeré vkládání, zobrazování nebo editace objektů se bez nich neobejde. Základem jsou tři třídy: db.class.php logger.class.php globalclass.class.php. 28

Třída db Tato třída zajišťuje komunikaci s databází, což obnáší připojení k databázi, provádění SQL dotazů a zjišťování výsledků těchto dotazů. Na začátku této třídy je nutné definovat konstanty, které jsou potřeba pro zdárné připojení. Jsou jimi DSN, typ databáze, uživatelské jméno a heslo. Při každém zobrazení webové stránky aplikace se vytváří globální proměnná, která je instancí této třídy. V okamžiku vytváření této instance se zavolá konstruktor 34 třídy db, který provede připojení k databázi a uložení identifikátoru tohoto připojení do proměnné instance. Tato proměnná je privátní, tedy k ní lze přistupovat jen metodami třídy db, přesněji metodami její instance. Odesílání SQL dotazů obstarává metoda query(), která vrací identifikátor výsledku. Třída dále obsahuje metody pro uvolňování výsledků dotazu, zjištění posledního vloženého identifikátoru či příkazů pro potvrzení a odvolání provedené transakce. Třída logger Přes metody této třídy probíhá komunikace s uživatelem a zobrazení i zaprotokolování chybových a ladících zpráv. Zobrazení těchto zpráv závisí na nastavené úrovni logování. Ta může nabývat čtyř hodnot a těmi jsou: trace nejdetailnější zprávy včetně ladících zpráv, zobrazení prováděných SQL dotazů a jejich výsledků. debug zobrazují se chybové zprávy, varování a důležitější informace pro účely ladění. warning toto je výchozí úroveň logování, zobrazují se pouze varovné a chybové zprávy. 34 Konstruktor je metoda třídy, která se volá automaticky při vytváření nové instance třídy. V případě PHP se dá její chování dodefinovat funkcí construct(). 29

error nastavení logování na tuto úroveň bude znamenat zobrazování pouze závažných chyb v aplikaci. Tato třída také obsahuje nepoužité metody, které v budoucnu zajistí odesílání varovných a chybových zpráv do systému Zabbix. Třída globalclass Tato abstraktní 35 třída je tvořena metodami, které je potřeba volat z ostatních tříd a proto je jim hierarchicky nadřazena. Je zde využita vlastnost objektového přístupu k programování. Každá ze tříd má ve své deklaraci uvedenu právě tuto třídu jako rodičovskou. Díky tomu mohou být společné metody uloženy na jednom místě a nemusí se definovat pro každou třídu zvlášť. Zděděné třídy lze volat pomocí identifikátoru rodičovské třídy parent::, např. parent::getidifexist() zavolá metodu getidifexist() třídy globalclass. Tyto metody slouží výhradně jako jakési rozhraní mezi jednotlivými třídami a třídou db, komunikující s databází. Jsou to metody pro zjištění existence záznamu v dané tabulce, metody pro vkládání a úpravy záznamů v tabulce, metoda pro vytváření SQL dotazu a také metody pro získání výsledků v požadované podobě. Touto podobou může být pole nebo textový řetězec. Důležitá je metoda transaction(), která provede potvrzení provedených SQL příkazů v případě, že nebyla zaznamenána žádná chyba a pokud chyba zaznamenána byla, provedené změny budou zahozeny. Další třídy Každá tabulka, která neslouží jako implementace vztahu mezi jinými tabulkami má svou vlastní třídu. Jedinou výjimkou jsou relace Room a EventType. Metody pro obsluhu tvorby a modifikace 35 Abstraktní třída znamená, že nelze vytvořit instanci této třídy. 30

místností jsou obsaženy ve třídě, která se zabývá budovami a metody patřící k typům událostí mají své místo ve třídě Event. Všechny tyto třídy mají některé metody se stejným názvem. Protože jsou v celém kódu volány nejen jménem metody, ale také jménem třídy, nebylo potřeba názvy rozlišovat. Chceme-li použít nějakou funkci v jiné metodě stejné třídy, použijeme identifikátor self:: 36, za nímž následuje název požadované funkce. Pokud ale chceme stejnou funkci zavolat z třídy jiné, musíme již použít název třídy. Například při modifikaci zařízení ve třídě device chceme zjistit, zda dané zařízení existuje v databázi a použijeme konstrukci self::getidifexist(). Při stejném zjišťování z jiné třídy musíme zavolat funkci takto: device::getidifexist(). Metoda, jež je všem těmto třídám společná je právě metoda pro nalezení identifikátoru záznamu podle hodnoty jednoho z jejích sloupců. Je to funkce uvedená v příkladu, s názvem getidifexist(). Tato metoda je definována v rodičovské třídě globalclass a všechny třídy ji dědí. Avšak pro každou ze tříd je definice této metody poněkud pozměněna, neboť každá třída pracuje s jinou tabulkou. Tato metoda se používá ve valné většině případů k ověřování existence objektů v databázi ať už k udržování unikátnosti hodnoty ve sloupci nebo získání identifikátoru záznamu podle jména. Důležitými metodami jsou create a modify, které, jak již jejich názvy napovídají, slouží k vytváření a modifikaci objektů v databázi. Jednotlivými řádky kódu těchto metod není třeba se zde zabývat, neboť jsou popsány v podrobnější dokumentaci na stránkách projektu. Ostatní funkce jednotlivých tříd, které se vztahují k vyřešení některého ze zadaných úkolů budou popsány níže v textu. 36 Obdobně se používá již dříve zmiňovaný identifikátor parent::. Oba tyto identifikátory jsou překladačem nahrazovány za název dané třídy. 31

4.4.6 Plnění jednotlivých úkolů (Tickets) Přístupová práva k zařízením Každé zařízení by nemělo být přístupné všem uživatelům a proto bylo potřeba vyřešit přístupová oprávnění. Vzhledem k tomu, že udělování práv jednotlivým uživatelům by mohlo být velmi nešikovné, rozhodli jsme se rozdělit jednotlivé uživatele do skupin a vyřešit pro každé zařízení přístup uživatelské skupiny. Při vložení každého nového zařízení se v tabulce Rights vytvoří trojice záznamů. Každý z těchto záznamů je cizím klíčem přiřazen právě vloženému zařízení a má rozlišnou hodnotu oprávnění. Přístupová práva jsou tedy tři 37 : Právo pro čtení ('r'): Umožňuje zobrazení daného zařízení, ale znemožňuje v něm editovat jakoukoli položku. Právo pro zápis ('w'): Uživatelská skupina s právem pro zápis může upravovat neklíčové atributy zařízení, což znamená atributy, které jsou v zařízení definovány pomocí šablony. Nejsou to tedy záznamy v tabulce Device, nýbrž hodnoty sloupce Data v relaci AttributeData. Administrátorské právo ('a'): Povolení pro jakoukoli modifikaci atributů a to jak v tabulce Device (klíčové atributy) tak v tabulce AttributeData (atributy neklíčové). Toto právo také umožňuje přidělit jakékoli právo k tomuto zařízení kterékoli skupině uživatelů. Vložením zařízení se však nepřiřadí právo žádné skupině. Pouze se uloží tři řádky do tabulky Rights. Jakmile chceme přidělit právo pro nějaké zařízení, použijeme metody třídy rights. Nejdříve metodou 37 Pro symboly označující hodnoty jednotlivých oprávnění jsou použita počáteční písmena anglických názvů umožňovaných funkcí, tedy Read, Write a Administrate (číst, zapisovat, spravovat). 32

checkdeviceright() zjistíme, zda skupina má přiřazeno k tomuto zařízení některé z práv. Jestliže zjistíme, že nemá, funkce getidrightsbydevice() nalezne identifikátor oprávnění podle zadaného zařízení a požadované hodnoty práva. Poté se vytvoří záznam v tabulce UserGroupRights, čímž se vytvoří vazba mezi skupinou a oprávněním. Jestliže již skupina nějaké právo k tomuto zařízení má, nebudeme záznam do vazební tabulky vkládat, ale upravíme ten existující. Ve zvláštním případě nepotřebujeme použít žádnou z těchto tabulek. Tímto případem je vedoucí skupina organizační jednotky. Patří-li zařízení pod útvar, jež má uvedenu vedoucí skupinu, a je-li uživatel přiřazen do této skupiny, automaticky má administrátorské právo. Oprávnění pro nepřihlášené návštěvníky V aplikaci bylo myšleno i na zpřístupnění některých zařízení všem návštěvníkům aplikace. Pro tento případ je vytvořena skupina guest. Této skupině je možné přiřadit pouze právo pro čtení. Hierarchická struktura útvarů Logickým požadavkem bylo ukládání organizačních jednotek v hierarchické struktuře. Chceme ukládat veškeré útvary a vždy mezi nimi bude nadřazenost či podřazenost. Zde bychom mohli uvést příklad: Máme organizaci, které aplikace slouží, pro naše účely je to Slezská univerzita. Vytvoříme tedy organizační jednotku s názvem su. Všechny další útvary jsou tomuto podřazeny a proto každý z následujících názvů organizačních jednotek obsahuje i název nejblíže nadřazené. Pro vytvoření útvaru fpf (filozoficko-přírodovědecká fakulta) uložíme název fpf.su. Tímto dáváme jasně najevo, že je tato 33

fakulta podřazena celé organizaci. Můžeme tedy vytvořit hierarchickou strukturu a to velmi jednoduše. Název útvaru, který neobsahuje tečku je vždy uložen jako nejvýše hierarchicky postavený. Názvy s tečkou jsou aplikací rozděleny na počáteční a koncový segment, přičemž oddělujícím znakem je první nalezená tečka. Před uložením útvaru se hledá nadřazená jednotka a bez její existence není uložení povoleno. Pro vložení nižší úrovně tedy vždy musí existovat ta vyšší. Jednotná dokumentace Aby nebylo nutné zvlášť popisovat veškeré metody jednotlivých tříd, museli jsme již při jejich psaní myslet na dokumentaci. Na webu je spousta dostupných aplikací, které dokáží při správně psaných komentářích extrahovat tyto informace a vytvořit vcelku kvalitní dokumentaci. V našem případě šlo o open source software Doxygen 38. Díky tomuto nástroji stačí psát vhodné komentáře přímo do zdrojového kódu a po skončení prací spustit tvorbu dokumentace. Ukázka výsledku práce Doxgenu je uložena v Příloze V. Indexování Indexování je součástí každé databáze a proto zde zmíníme jen několik informací. Kvůli rychlejšímu vyhledávání v databázi vytváříme index pro veškeré pole typu VARCHAR. Dále definujeme unikátní indexy (UNIQUE INDEX) na množiny atributů v jednotlivých tabulkách. Zamezíme tím případné chybě, protože databáze odmítne uložit záznam, který unikátnost porušuje. Množiny, pro které jsou unikátní indexy definovány jsou popsány v Příloze III.. 38 Oficiální stránky http://www.stack.nl/~dimitri/doxygen 34

Dědičnost a unikátnost atributů zařízení Dědičnost i unikátnost jsou zajištěny pomocí parametru UniqueNumber v tabulce DeviceTypeAttribute. Tento parametr tedy omezuje pouze daný typ atributu v dané šabloně. Pro jiný typ zařízení může být hodnota tohoto parametru jiná. UniqueNumber může nabývat čtyř hodnot, z nichž pouze jedna určuje dědičnost. Je to hodnota -1 a znamená, že se hodnoty tohoto atributu mohou v rámci šablony dědit. Chceme-li vlastnost použít, pak při vkládání zařízení uvedeme ve formuláři klíčové slovo inherit. Záznam se uloží do databáze s tímto textem jen tehdy, existuje-li nějaké rodičovské zařízení stejného typu, jehož hodnota tohoto atributu je konkrétní (tedy není inherit). Při zobrazení detailů o zařízení se pak hledá nejbližší konkrétní hodnota atributu. Nulová hodnota parametru znamená klasické chování. Do atributu je možné uložit jakoukoli hodnotu odpovídající datovému typu. Kladné hodnoty značí požadavek na jedinečnost hodnoty atributu a to buď v rámci jednoho zařízení nebo v rámci všech zařízení tohoto typu (se stejnou šablonou). První možnost (zadáme hodnotu 2) může být použita pro jedinečnou identifikaci hodnoty, např. číslo ethernetového portu, zatímco možnost druhá (hodnota 1) umožní uložit např. sériové číslo zařízení, které nemůže být pro žádné zařízení v šabloně shodné. Kladné hodnoty nemají žádnou vazbu na parametr MaxPerDevice, ale pro zápornou hodnotu je ze zřejmých důvodů 39 nutné, aby byl tento typ atributu uveden v šabloně pouze jednou. Hodnota parametru UniqueNumber může tedy být záporná pouze je-li parametr MaxPerDevice roven jedné. 39 Při větším počtu stejných atributů by nebylo možné zjistit, kterou hodnotu je potřeba zdědit. 35

Události (Events) Administrátor jakékoli aplikace si potřebuje udržovat přehled o chování, chybách a změnách, které provoz přináší. Proto byla navržena tabulka pro ukládání jednotlivých informací. Typy jednotlivých událostí mají nastavenu potřebnou důležitost, podle níž bude možno tyto události zobrazovat. Už v počátečních datech je nastaveno 32 výchozích typů událostí, které se v systému dějí. Výpis z databáze lze nalézt v Příloze VI. Každá uložená událost v sobě nese informace o uživateli, který byl právě přihlášen, o IP adrese, ze které se do systému přihlásil a také krátký popis změny. Například při vytvoření záznamu v tabulce se uloží událost daného typu s textovým popisem obsahujícím identifikátor záznamu, případně hodnotu dalšího atributu. Transakce Transakce zaručují, že žádná posloupnost změn v databázi nebude uložena, pokud neproběhne celá a bez chyby. Právě z tohoto důvodu byla ve třídě db zrušena volba automatického potvrzování jednotlivých SQL příkazů 40. Potvrzení i případné odvolání změn se provádí metodou transaction() ve třídě globalclass. Je-li globální proměnná, která zaznamenává počet chyb prázdná, změny se potvrdí a uloží v databázi natrvalo 41. V opačném případě se změny zruší 42 a uživateli se zobrazí zpráva. Webové rozhraní Ačkoli je komunikace s databází prováděná třídami a jejich metodami, aplikace samotná musí komunikovat s uživateli. Proto bylo vytvořeno jednoduché webové rozhraní, pro které bylo třeba napsat 40 Funkce PHP pro ODBC přístup k databázi - odbc_autocommit 41 Funkce PHP pro ODBC přístup k databázi - odbc_commit 42 Funkce PHP pro ODBC přístup k databázi - odbc_rollback 36

jednotlivé formuláře pro vkládání a editace objektů. Samotná webová stránka je psána podle standardu XHTML 1.0 Transitional a stylována podle standardu CSS 2.1. Stránka splňuje všechny podmínky konsorcia W3C na validitu obou standardů viz Obr. 3. Obr. 3. Validita stránky Tvorbu formulářů pro úpravu obstarávají skripty ve složce scripts, které začínají symboly edit_. Načítání těchto skriptů a ošetření odeslaných formulářů uskutečňuje skript edit.php, který je umístěn ve stejné složce. Zabezpečení uživatelského vstupu Každý uživatelský vstup musí být v aplikaci kontrolován a upraven, aby se zamezilo záměrnému nebo neúmyslnému poškození. Proto jsou všechna data z formulářových polí, adresy URL a cookies upravována metodou uprav_promenne. Tato metoda, jejímž jediným argumentem je pole proměnných, odstraní všechna zpětná lomítka, která mohla být přidána automatickou funkcí magic_quotes, všechny speciální znaky převede na escape sekvence 43 a odstraní zbylé tagy a nadbytečné mezery. Funkce uprav_promenne počítá i s takovou situací, kdy je prvkem pole další pole. Ta nastává v případě, že je ve formuláři obsaženo více textových polí stejného typu, např. ve formuláři pro přidání nového zařízení. 43 Escape sekvence převádí problematické znaky na sekvence znaků pomocí zpětného lomítka (\). Problematickými znaky mohou být apostrofy, uvozovky, zpětné lomítko apod. 37

4.5 Testování 4.5.1 Testování během psaní zdrojového kódu Veškeré metody bylo nutné v průběhu programování testovat, aby se zjistily případné chyby a nedostatky. Teprve až daná funkce pracovala podle představ, bylo možné řešit další problém. Pro samotné testování slouží skript test.php, který je nahráván do úvodní stránky index.php. V tomto souboru jsou zapoznámkovány řádky s použitím jednotlivých metod. Vzhledem k tomu, že byly metody postupně dolaďovány a přepisovány, nemusí být každý z řádků aktuální. Protože však tento soubor nepatří do výsledné aplikace, není třeba jej aktualizovat. 4.5.2 Testování hotové aplikace zkušebními daty Pro zkušební provoz hotové aplikace bylo potřeba zprovoznit webový server. K dispozici jsme dostali diskový prostor na počítači s operačním systémem Linux (distribuce Debian). Stejně jako při instalaci serveru na lokální stanici bylo i zde nutné nainstalovat potřebné aplikace. Zajištění vzdáleného přístupu k diskovému prostoru Aby bylo možno systém serveru nastavovat a spravovat na dálku přes internetovou síť, museli jsme vytvořit ssh klíče 44 pro jednotlivé uživatele a uložit je v kořenovém adresáři systému ve skryté složce 44 SSH neboli Secure Shell je klient/server protokol v síti TCP/IP, který umožňuje bezpečnou komunikaci mezi dvěma počítači pomocí transparentního šifrování přenášených dat. Pracuje na portu TCP/22. Pokrývá tři základní oblasti bezpečné komunikace: autentizaci obou účastníků komunikace, šifrování přenášených dat a integritu dat. SSH klíč slouží jako identifikace uživatele a je navíc chráněn heslem. Ve Windows jej bylo potřeba vygenerovat, k čemuž posloužil program Puttygen (viz http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) 38

.ssh/authorized_keys. Díky tomu bylo možné připojit se pomocí ssh protokolu a vzdáleně spouštět příkazy systému. Pro vzdálené připojení jsme použili dva programy, z nichž jeden spouští přímo linuxový shell a druhý funguje na principu správce souborů 45. Těmito programy jsou PuTTY (viz Obr. 4) a WinSCP (viz Obr. 6). Obr. 4 Autentifikace vzdáleného přístupu pomocí programu PuTTY Instalace virtuálního serveru Oproti instalaci v operačním systému Windows, kde bylo nutné stáhnout veškeré aplikace z jejich domovských stránek, byla instalace v systému Linux o něco jednodušší. Tento operační systém instaluje téměř všechny potřebné programy v podobě balíčků (packages). Pro instalaci jednotlivých balíčků slouží příkaz apt-get install, následovaný názvem příslušného balíčku. Touto metodou nainstalujeme potřebné aplikace, jimž odpovídají balíčky apache2, php5, mysql, libmyodbc a phpmyadmin. Podpora verzovacího nástroje Subversion byla obsažena již v samotné distribuci. Po instalaci a nastavení jednotlivých aplikací byly zdrojové kódy zkopírovány do adresáře webového serveru, tedy /var/www/. Odtud je aplikace přístupná všem uživatelům internetu na URL adrese http:// srsw4it.opf.slu.cz/index.php. 45 Jako například aplikace Total Commander pod windows 39

Obr. 5 Okno správce souborů WinSCP Zkušební data Teprve na virtuálním serveru bylo možné otestovat aplikaci jako celek. Při lokálním testování vyšly najevo chyby, které byly ihned provedeny a znovu otestovány. Ale funkce, které mohou být vyzkoušeny až při ostrém provozu, se takto vyladit nedaly. Proto byla vytvořena zkušební data, na kterých se testy prováděly. Jeden z nejdůležitějších se týkal dědičnosti hodnot atributů. Protože se jedná o popis zařízení, muselo být nejprve nějaké vloženo. To však nelze bez předchozích dat. Museli být vytvořeni imaginární uživatelé, organizační jednotky, budovy s místnostmi, typy atributů a samozřejmě také šablony. Teprve tehdy mohla být vložena pokusná zařízení. Zkušební data jsou popsána v Příloze IV. 40

5 PŘEDÁNÍ DO PROVOZU V současné době vzniká na Slezské univerzitě potřeba vytvářet ucelený soupis veškerých prostředků informačních technologií. Protože stávající stav evidence těchto zařízení nesplňuje kritéria kladená na inventarizační software, bude již na začátku akademického roku 2008/2009 tento stav aktualizován nasazením softwaru SRSW4IT do provozu. 5.1 Nasazení SRSW4IT na Filozoficko-přírodovědecké fakultě Slezské univerzity Ve spolupráci s Bc. Jiřím Sléžkou DiS. bude počátkem září 2008 probíhat implementace inventarizačního softwaru mezi ostatní používané aplikace na této univerzitě. Bude nutné instalovat a nastavit základní parametry systému a naplnit jej informacemi. Většina zařízení, která jsou již dnes evidována, bude možno i s jejich daty uložit do inventarizační databáze. Pro nové objekty bude nutné nejprve vypracovat šablony a typy atributů. Implementace bude probíhat v komunikaci s vývojáři softwaru. 5.2 Propojení s dalšími systémy V době ukončování prací na projektu bylo projednáváno propojení vyvíjeného softwaru zejména se dvěma dalšími systémy. Jeden z nich umožňuje obnovu disků pracovních stanic v učebnách po celé univerzitě. Vyvíjený software by měl být schopen se systémem obnovy komunikovat a sdílet data. Druhým systémem, na nějž by měla být vytvořena vazba je systém Zabbix, který byl popsán výše. Pro účely propojení s tímto systémem se plánuje dopsání modulu pro import a export dat ve formátu XML. Obě tyto vazby jsou prozatím ve fázi plánování. 41

5.3 Náměty pro budoucí verze a moduly Mimo modulů pro import a export bude jistě nalezeno několik dalších námětů na vylepšení či tvorbu nových funkcí. Každý z těchto námětů bude možno uvést na stránkách projektu, kde se vývojářský tým bude zabývat jejich relevancí a možností zapracování potřebných úprav do projektu. Již nyní se naskytlo několik vylepšení, která by následující verze mohla obsahovat, například uživatelské rozhraní pro přiřazování oprávnění jednotlivým uživatelským skupinám. Ve zdrojovém kódu jsou pro tento případ nachystány metody, pomocí nichž se samotné přiřazení uskuteční, ale prozatím není tato možnost přístupná přes uživatelské rozhraní. Dále je možno vytvořit tabulky pro zobrazování informací o jednotlivých objektech v databázi. Při vývoji se kladl důraz na vyhledávání zařízení a proto jsou detailní informace ostatních objektů přístupné pouze při jejich editaci. Všechny dodatečné úpravy a změny budou průběžně uváděny na stránkách http://srsw4it.bp.opf.slu.cz. 42

6 ZÁVĚR Na základě požadavků popsaných v úvodu jsem vytvořil inventarizační software s otevřeným zdrojovým kódem a správou přes webové rozhraní. Kromě samotného softwaru byly uvedeny do provozu stránky o projektu obsahující mimo jiné informace o jeho vývoji a všech součástech. Vytvořený inventarizační software je složen z jednotlivých souborů tříd a obslužných skriptů v jazyce PHP, dále ze souborů, tvořících tělo HTML dokumentu webového rozhraní, a kaskádového stylu, který definuje jeho vzhled. Pro pozdější vývoj je v adresářové struktuře nachystána definice typu dokumentu (Document Type Definition) pro import a export typů zařízení pomocí formátu XML. Tabulky v databázi jsem vytvořil na základě navrženého datového modelu. Díky obecnosti tohoto modelu je možné, kromě výchozích objektů (jako jsou organizační jednotky, budovy, místnosti, a ostatní objekty), pro něž existují databázové tabulky, definovat vlastní typy objektů, ukládaných do systému. Je to způsobeno tím, že do tabulky Device se může uložit jakákoli abstraktní či konkrétní entita, která bude v systému vystupovat jako zařízení. Postačí pro ni definovat správné typy atributů a poskládat je do šablony. Všechna uložená zařízení jsou dělena do skupin a přiřazována k organizačním jednotkám. Webové rozhraní inventarizačního systému bylo navrženo tak, aby komunikovalo s uživatelem pomocí HTML formulářů pro ukládání, vyhledávání a editaci jednotlivých objektů a zařízení. Možnost vyhledávání objektů, které v systému nevystupují jako zařízení, je ve zdrojovém kódu podporována, ale pro funkci systému není důležitá a proto pro ni prozatím nebyl vypracován formulář ani obslužný skript. Software byl zabezpečen proti neoprávněnému zneužití. Díky tomu, že uživatelská data vstupující přes formulář do aplikace jsou upravována a problematické znaky jsou převáděny na neškodné, nedají se zneužít SQL dotazy. Zneužít nelze ani proměnné, neboť jsou porovnávány s polem očekávaných hodnot. Pro přístup do aplikace jsou vytvořena uživatelská konta chráněná heslem. 43

Vyvíjený software je možno instalovat na serveru s libovolným operačním systémem, na němž pracuje technologie PHP, a díky funkcím ODBC propojit s vybraným systémem řízení báze dat. Tím byl splněn požadavek nezávislosti na použité platformě a databázi. Software byl v průběhu práce testován na lokálním i zkušebním serveru. Veškeré problémy zjištěné při testování byly opraveny. Uvedení do provozu sice může ukázat problémy, které nebylo možno během vývoje a testování podchytit, avšak zdrojový kód je vytvořen tak, aby po pročtení dokumentace nebyla jeho úprava nijak složitá. Jakékoli případné problémy tak mohou být rychle vyřešeny. Vypracovaný software splňuje všechny požadavky uvedené v zadání bakalářské diplomové práce a věřím, že plně uspokojí potřeby Slezské univerzity v oblasti inventarizace prostředků informačních technologií. Přestože je schopen fungovat samostatně, může se stát jádrem daleko většího systému. Do budoucna se totiž plánuje rozšíření jeho funkcí a také jeho propojení s jinými aplikacemi používanými na Slezské univerzitě. 44

Seznam použité literatury a zdrojů Použitá literatura: [1] Gutmans A., Bakken S. S., Rethans D.: Mistrovství v PHP 5. 2. vydání. Brno Computer Press, a.s. 2007. 655 s. [2] Ullman L.: PHP a MySQL - Názorný průvodce tvorbou dynamických WWW stránek. 1. vydání. Brno Computer Press, a.s. 2004. 534 s. [3] Husseby S. H.: Zranitelný kód. 1. vydání. Brno Computer Press, a.s. 2006. 207 s. [4] Riordan R. M.: Vytváříme relační databázové aplikace. 1. vydání. Praha Computer Press, a.s. 2000. 280 s. [5] Staníček P.: CSS Kaskádové styly - Kompletní průvodce. 2. vydání. Brno Computer Press, a.s. 2003. 178 s. Internetové zdroje [1] http://www.zabbix.com 27.7.2008 [2] http://www.mysql.org 27.7.2008 [3] http://httpd.apache.org 27.7.2008 [4] http://trac.edgewall.org 27.7.2008 [5] http://subversion.tigris.org 27.7.2008 [6] http://www.php.net 27.7.2008 [7] http://news.cnet.com/8301-10784_3-9851644-7.html 16.1.2008 [8] http://wiki.org/wiki.cgi?whatiswiki 27.7.2008 [9] http://cs.wikipedia.org/wiki/wiki 27.7.2008 [10] http://en.wikipedia.org/wiki/wiki 27.7.2008 [11] http://svnbook.red-bean.com 27.7.2008 [12] http://www.stack.nl/~dimitri/doxygen 27.7.2008 [13] http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html 27.7.2008 45

7 PŘÍLOHY Příloha I. Soupis tabulek s detailním popisem sloupců Sloupec ID je obsažen v každé tabulce jako jednoznačný identifikátor záznamu a proto je zde vynecháván. Device (zařízení) Name jedinečný název zařízení. Jedinečnost je zde použita kvůli usnadnění hledání v databázi. IDOU cizí klíč z tabulky OU (Organization Unit), označuje organizační jednotku, pod kterou zařízení spadá. IDRoom cizí klíč z tabulky Room (Místnost), označuje umístění zařízení IDDeviceType cizí klíč z tabulky DeviceType, označuje typ zařízení, neboli šablonu. IDParentDevice cizí klíč z tabulky Device (unární vazba), označuje nadřazené zařízení, k němuž toto zařízení patří, respektive jehož je součástí. Může být prázdný. IDPersonMaintenance osoba (její identifikátor) z tabulky User zodpovědná za údržbu a obsluhu zařízení IDOwner osoba, která má za zařízení hmotnou zodpovědnost. Při vložení nového záznamu se do tohoto sloupce uloží uživatel, který zařízení vytvořil. IDUserAdded osoba, která zařízení vložila, nebo též osoba, která přidělila tomuto zařízení vlastníka. IDUserChanged uživatel, který provedl poslední změny v tomto záznamu. DateAdded časové razítko označující datum a čas vytvoření zařízení. DateChanged časové razítko poslední provedené změny. ImgCoordX nepovinný atribut pro případné zaznamenání pozice na mapě nebo obrázku. ImgCoordY nepovinný atribut pro pozici na mapě ImgLayer nepovinný atribut určující vrstvu. DeviceType Name jedinečný název typu zařízení Description textový popis 46

AttributeType Name jedinečný název typu atributu Description textový popis s detaily o atributu Type datový typ a povolené hodnoty pro atribut. Možné jsou typy boolean - logická hodnota true nebo false integer - celé číslo string:max:min - textový řetězec, kde celočíselné hodnoty max a min označují maximální a minimální délku řetězce. Maximální délka je omezena na 50 znaků. enum:{h1,h2,...} - množina povolených hodnot h1,h2,... IDConnectorType typ propojení atributu. ConnectorType Name jedinečný název typu propojení Description textový popis MaxConnections počet atributů, které mohou být propojeny ImgColor nepovinný atribut pro případné zaznamenání na mapě nebo obrázku. ImgLineType typ propojovací čáry (solid - plná, dashed - čárkovaná, dotted - tečkovaná, apod.). DeviceTypeAttribute IDDeviceType Cizí klíč označující typ zařízení (šablonu) IDAttributeType Cizí klíč označující typ atributu MaxPerDevice Maximální počet atributů stejného typu pro jedno zařízení s touto šablonou UniqueNumber Parametr určující dědičnost či unikátnost hodnoty atributu. AttributeData Data Hodnota atributu IDAttributeType Typ atributu IDDevice Zařízení, ke kterému atribut patří IDDeviceType Šablona zařízení RankPerDevice Pořadové číslo atributu v zařízení (zejména v případě většího počtu atributů stejného typu DateAdded Datum vložení záznamu do tabulky DateChanged Datum poslední úpravy záznamu IDUserChanged Identifikátor uživatele, který provedl změnu 47

Link IDAttributeIn Identifikátor vstupního atributu IDAttributeOut Identifikátor výstupního atributu DeviceGroup Name jedinečný název skupiny zařízení Description textový popis DeviceGroupDevice IDDevice Zařízení přiřazované do skupiny IDDeviceGroup Skupina zařízení User Username Uživatelské jméno Pwd Uživatelské heslo Name Jméno uživatele Surname Příjmení uživatele Mail Kontaktní informace, e-mail Jabber Kontaktní informace, Jabber ID Icq Kontaktní informace, ICQ číslo Phone Kontaktní informace,telefonní číslo IDOU Organizační jednotka IDUserGroup Uživatelská skupina UserGroup Name jedinečný název skupiny Description textový popis UserGroupRights IDUserGroup Uživatelská skupina IDRights Identifikátor záznamu v tabulce Rights Rights IDDevice Zařízení, pro nějž platí hodnota oprávnění Value Hodnota oprávnění OU Name Jedinečný název organizační jednotky (tečková syntaxe) Description Textový popis IDLeaderGroup Vedoucí skupina uživatelů 48

Building Name Jednoznačný název budovy Description Textový popis Adress Adresa IDContactPerson Identifikátor kontaktní osoby Room Name Jednoznačný název místnosti Description Textový popis Level Poschodí IDBuilding Identifikátor budovy IDContactPerson Identifikátor kontaktní osoby EventType Name Jednoznačný název typu události Description Textový popis Importance Důležitost události Event Date Datum uložení události IDUserLogged Uživatel přihlášený v době uložení UserIP IP adresa přihlášeného uživatele IDEventType Typ události SQLquery Text obsahující pozměněné informace, uživatelské jméno nebo identifikátor zařízení 49

Příloha II. Export datového modelu do grafické podoby 50

Příloha III. Unikátní indexy Device DeviceType ConnectorType DeviceTypeAttribute AttributeData Link DeviceGroupDevice User UserGroup UserGroupRights Rights (Name) (Name) (ImgColor, ImgLineType) (IDDeviceType, IDAttributeType) (IDDevice, IDDeviceType, IDAttributeType, RankPerDevice) (IDAttributeIn, IDAttributeOut) (IDDevice, IDDeviceGroup) (Username) (Name) (IDUserGroup, IDRights) (IDDevice, Value) 51

Příloha IV. Zkušební data pro testování aplikace Organizační jednotky: su Slezská univerzita, nejvyšší útvar fpf.su Filozoficko přírodovědecká fakulta na SU opf.su Obchodně podnikatelská fakulta na SU ui.fpf.su Ústav informatiky na FPF SU Budovy: BN13 Bezručovo náměstí 13, FPF, děkanát BN14 Bezručovo náměstí 14, FPF, ústav ošetřovatelství Místnosti B1 Učebna na BN13 B2 Učebna na BN13 B3 PC učebna na BN13 C10 PC učebna na BN14 Uživatelské skupiny guest Výchozí skupina pro nepřihlášené uživatele admin Výchozí skupina pro správce aplikace zamestnanci Zkušební skupina Typy propojení atributů: Ethernet UDP kabel s konektorem RJ-45 Typy atributů IP adresa Identifikace zařízení v síti MAC adresa Fyzická adresa zařízení CPU Procesor RAM Operační paměť HDD Pevný disk VGA Grafická karta CD/DVD Mechanika, CD/DVD, ROM/RW Operační systém Primární operační systém Operační systém 2 Sekundární operační systém (při dualbootu) Provozní stav Stav zařízení, může nabývat několika definovaných hodnot 52

Příloha V. Ukázky výsledku práce programu Doxygen 53

Příloha VI. Výpis výchozích typů událostí z databáze 54