Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze
Vladimír Petrík
Reengineering informačního systému pro tvorbu posudků bakalářských a absolventských prací.
Bakalářská práce
2011
(Zadávací formulář)
Prohlášení Prohlašuji, že jsem bakalářskou práci na téma „Reengineering informačního systému pro tvorbu posudků bakalářských a absolventských prací“ vypracoval samostatně a použil jsem pouze zdrojů, které cituji a uvádím v seznamu použité literatury.
V Praze dne 23. července 2011
………………………………… Vladimír Petrík
Poděkování Rád bych poděkoval Ing. Bc. Davidu Klimánkovi, Ph.D. za ochotu, trpělivost a věcné připomínky, kterými mi výrazně pomohl při vypracování této bakalářské práce. Osobní poděkování patří mé rodině a všem blízkým, kteří mě po celou dobu studia plně podporovali.
Abstrakt Cílem této práce je navrhnout a realizovat jednotný komplexní systém pro správu témat absolventských a bakalářských prací a zároveň pro rezervaci konzultačních hodin. Sjednocením daných systémů a přidáním možnosti správy posudků pro dané absolventské a bakalářské práce, by měl vzniknout komplexní systém, jehož používání by usnadnilo práci všech profesorů i studentů. Nejprve bude nutné analyzovat současný stav daných systémů a určit jejich silné a slabé stránky. Na základě důkladné analýzy nejprve vznikne nová struktura systému včetně databáze. Prakticky bude zadaná problematika řešena pomocí jazyků HTML a PHP respektive pomocí jazyka SQL pro databázovou část. Stěžejní částí této bakalářské práce je praktická část, kde je blíže popsána realizace aplikace pro spravování posudků absolventských a bakalářských prací a jejich generování do formátu PDF.
Abstract The aim of this work is to design and realize unified complex system for administration themes of graduation and bachelor works and for reservation of consulting. By unifying of those systems and adding the possibility for administration reviews of graduate and bachelor works, should form a complex system, whose use might make the work of professors and students easier. First is necessary to analyze current state of those systems and determine their strengths and weaknesses. A whole new structure of the system will be created from this analysis, including new database. Practically this problematic will be solved by languages HTML and PHP respectively by language SQL for database part. The main part of this thesis is the practical part, where is described the realization of application for administration graduate and bachelor works and their generation to PDF format.
Obsah Obsah................................................................................................................. 7 Použité zkratky .................................................................................................. 9 1
Použité zkratky AP – Absolventská Práce BCNF – Boyce-Coddova Normální Forma BP – Bakalářská Práce CASE – Computer Aided Software Engineering ERA – Entity Relationship Attribute HTML – HyperText Markup Language IS – Informační systém ISO – International Organization for Standardization IT – Informační Technologie kB – kiloByte MD5 – Message Digest Algorithm 5 NF – Normální Forma PDF – Portable Document Format PHP – Hypertext Preprocessor SHA1 – Secure Hash Algorithm 1 SQL – Structured Query Language SŘBD – Systém Řízení Báze Dat UML – Unified Modeling Language UP – Unified Process URL – Uniform Resource Locator UTF – UCS Transformation Format XML – Extensible Markup Language
9
1
Úvod
Toto téma jsem si vybral za účelem zdokonalení mých znalostí v oblasti vývoje webových aplikací pomocí jazyka PHP a zároveň s myšlenkou zdokonalení a sjednocení stávajících systémů. V současné době již existuje jak systém pro rezervaci absolventských a bakalářských prací (dále jen AP a BP), tak systém pro rezervaci konzultací. Bohužel je využíván pouze minimem učitelů z této školy. Jedním z důvodů by mohl být fakt, že obě aplikace vyžadují individuální registraci pro jednotlivé úkony. Aby tak učitel mohl spravovat absolventské práce a konzultace, respektive aby si student mohl rezervovat práci, či konzultaci musí mít vytvořeny účty na obou systémech. Výsledný systém bude i nadále obsahovat všechny současné funkční prvky. Učitel bude moci vytvářet nové AP a BP, které bude moci následně editovat či odstraňovat. I nadále bude mít možnost vytváření nových konzultací a správy již stávajících. Studenti si pak budou moci rezervovat AP a BP, respektive konzultace. Další přidanou hodnotou, která by mohla oba typy uživatelů přilákat k užívání tohoto systému, by pak měl být systém pro generování dokumentů do formátu PDF. Na straně učitele, nalezne uplatnění především při tvorbě posudků absolventských a bakalářských prací. Učitel bude mít pomocí tohoto systému neustálý přehled o všech svých vypsaných tématech včetně údajů, kdo má dané téma zaregistrováno. Po dokončení práce pak učitel již nebude muset celý posudek vypisovat ručně, pouze vybere práci a v jednoduchém webovém formuláři vypíše hodnocení, včetně navržené známky a doplňujícího hodnocení. Zadané hodnocení může ještě následně upravovat, či využít možnosti pro vygenerování dokumentu ve formátu PDF. Studenti pak budou mít možnost obdobným způsobem vygenerovat zadávací formulář na základě svého vybraného tématu. Veškeré skripty, které jsou součástí informačního systému (dále jen IS), včetně skriptu pro vytvoření databáze, jsou vzhledem ke svému rozsahu k nahlédnutí v elektronické dokumentaci, která je přiložena k bakalářské práci.
10
TEORETICKÁ ČÁST
11
2
Analýza současného stavu informačních systémů
V současné době tedy existují dva oddělené systémy, z nichž každý využívá vlastní databázi. Vzhledem k tomu, že každý systém byl navržen a realizován jiným autorem, nejspíše nebude možné využít žádných hotových kódů. Celý IS tak zřejmě bude nutné naprogramovat znovu.
2.1 Popis funkčnosti informačních systémů Funkčnost rezervačního systému Současně používaný rezervační systém pracuje na 3 uživatelských úrovních. Základní funkcionalitu může využívat libovolný návštěvník webu. Nepřihlášený uživatel může zobrazovat seznam témat BP a AP, dále je mu umožněno zobrazovat pouze neobsazená témata, a také témata příslušející jednotlivým učitelům. Existují zde dvě úrovně registrací, jedna pro studenty, která je volně přístupná a jedna skrytá pro učitele. Po registraci se pak uživatel může přihlásit jako student či jako učitel. Po přihlášení do systému jako student vidí uživatel již pouze seznam volných témat, která si může rezervovat. Po rezervaci tématu může student v záložce Zadání práce zobrazit finální verzi názvu a cíle práce vytvořené vedoucím práce, které následně vyplní do zadávacího formuláře. Přes tuto stránku zároveň může navrhnout osnovu práce, kterou může případně doplňovat i vedoucí. Po přihlášení do systému jako učitel, jsou uživateli zobrazena všechna jím zadaná témata. Tyto může dále upravovat, blokovat, ale i mazat. Nechybí samozřejmě možnost přidávat nová témata. Dále zde učitel vidí seznam prací rezervovaných studenty. Jednotlivým studentům pak může určovat finální verzi názvu a cílu práce a zasahovat do návrhu osnovy. Učitel má také možnost danému studentovi práci odebrat. Funkčnost systému konzultačních hodin Systém pro správu konzultačních hodin pracuje také na 3 uživatelských úrovních. Anonymní uživatel může vyhledávat v databázi konzultací podle mnoha dostupných prvků. Konzultace je možné vyhledávat podle těchto kritérií – datum, pedagog, místnost a doby konzultace. Na bočním panelu pak může vidět nejnověji přidané a nejaktuálnější konzultace.
12
Opět zde figurují dvě rozdílné registrace, veřejná pro studenta a skrytá pro učitele. Po registraci si uživatel vybere typ uživatele, podle statutu studenta či učitele, a může se přihlásit. Po přihlášení se může student přihlásit k jednotlivým konzultacím. U těch uvádí stručný i detailnější popis účelu konzultace a může připojit i přílohu k dané konzultaci. Dále pak může zobrazit seznamy rezervovaných konzultací, kterých se již zúčastnil, či které se teprve uskuteční. Učitel pak po přihlášení do systému může přidávat, odebírat a mazat jednotlivé konzultace. Dále může zobrazovat seznam již vytvořených konzultací a přihlášených studentů na tyto konzultace. Má také přístup ke stažení dokumentů připojených ke konzultaci.
2.2 ERA diagram a datový slovník současného stavu systémů 2.2.1 Systém rezervací AP a BP
Obrázek 2.2.1 – ERA diagram systému rezervací AP a BP, zdroj: překresleno autorem [8]
• Password: varchar(255) – heslo uživatele • Email: varchar(255) – email uživatele • Datum_Narozeni: Date – datum narození uživatele • Bydliště varchar(255) tabulka „DBKonzultace_Konzultace“ • ID_Konzultace: int – identifikační číslo konzultace, primární klíč • Cas_Konzultace_Od: datetime – počáteční čas konzultace • Cas_Konzultace_Do: datetime – koncový čas konzultace • Poznamka_Ko: text – poznámka ke konzultaci • Kapacita: int – kapacita konzultace • Datum_Pridani_Konzultace: datetime – datum přidání konzultace • ID_Uzivatel: int – identifikační číslo uživatele, cizí klíč • ID_Mistnost: int – identifikační číslo místnosti, cizí klíč tabulka „DBKonzultace_Prihlaska“ • ID_Prihlaska: int – identifikační číslo přihlášky, primární klíč • ID_Konzultace: int – identifikační číslo konzultace, cizí klíč • Nazev_Prihlaska: varchar(255) – název přihlášky ke konzultaci • Poznamka_Pr: text – poznámka k přihlášce • Priloha: varchar(255) – odkaz na přílohu ke konzultaci • Datum_Prihlaseni: datetime – datum přihlášení ke konzultaci • ID_Uzivatel: int – identifikační číslo uživatele, cizí klíč tabulka „DBKonzultace_Mistnost“ • ID_Mistnost: int – identifikační číslo místnosti • Nazev_Mistnost: varchar(255) – název místnosti vazební tabulka „DBKonzultace_Uzivatele_Role“ • ID_Uzivatel: int – identifikační číslo uživatele, složený primární klíč • ID_Role: int – identifikační číslo role, složený primární klíč tabulka „DBKonzultace_Role“ • ID_Role: int – identifikační číslo role, primární klíč • Nazev: varchar(255) – název role • Popis: varchar(255) – popis dané role
2.3 Výhody a nevýhody Výhodou aplikace pro rezervaci konzultačních hodin je moderní vzhled a vcelku dobrá přehlednost. Dále pak dobře vypadající boční panel, který ukazuje několik nejaktuálnějších a nejnověji přidaných konzultací. Největší nevýhodou však pro budoucnost obou systémů spočívá v jejich nejednotnosti. Systémy totiž nejsou rozdílné pouze v databázovém základu, ale velké rozdíly lze sledovat i ve vzhledu obou aplikací. Mezi další nevýhody obou systémů lze zařadit také formu rozdělení typu uživatele na studenta a učitele. To je především zřejmé při přihlašování do obou aplikací, kde uživatel musí vybrat správně svoji roli. V systému rezervací AP a BP je to způsobeno existencí dvou tabulek pro jednotlivé typy uživatelů. V systému konzultačních hodin se 15
setkáváme s poněkud přebytečným rozšířením databáze o dvě tabulky - tabulka s rolemi a její vazební tabulka. To by mohlo být jednoduše řešeno použitím booleovského typu proměnné přímo v tabulce uživatel. V návrhu databáze u tohoto systému je pouze jedna tabulka uživatele, a proto by zde mohla být snadno zajištěna unikátnost přihlašovacího jména. V obou systémech pak chybí možnost editace uživatelských údajů včetně hesla. To je pro budoucí systém nezbytné, neboť údaje o studentech, respektive vedoucích do generovaných dokumentů budou získávány z databáze. Při nemožnosti změny těchto prvků, by pak bylo nutné při jakékoliv chybě provést novou registraci. Dalším elementem, který je v obou systémech poněkud komplikovaně dostupný, je registrace učitele. Ta může být prováděna pouze na základě zaslání nezobrazeného odkazu či manuálním přidáním do databáze. Drobnou nevýhodou je také u systému rezervací AP a BP zmizení původních položek menu. Kde například pokud chce učitel před přidáním nové práce porovnat, jestli podobnou již nevypsal někdo z jiných pedagogů, musí se znovu odhlásit a procházet seznam prací ještě před přihlášením.
3
Návrh databáze
Jedním z nejdůležitějších faktorů při vývoji nového IS je správný návrh databáze. Vhodné sestavení výchozích položek do tabulek může ušetřit mnoho práce při následném kódování. Je proto nutné této etapě práce věnovat stejnou pozornost, jako samotnému procesu vývoje aplikace.
3.1 Metodika návrhu databáze Při tvorbě internetové aplikace, stejně jako u každého softwarového projektu, je nejdůležitější datové modelování. Na základě konzultací se zadavatelem vznikne základní představa o systému, jeho základních funkcích a datových strukturách. Cílem analýzy vznikajícího projektu je specifikace těchto základních požadavků na strukturu a funkčnost systému. Na konceptuální úrovni, tj. nezávisle na implementačním prostředí a užité platformě, řeší tuto problematiku konceptuální datový model.[5] Konceptuální datový model Model, který zobrazuje datové požadavky pouze obecně, oproti konkrétní implementaci např. v relační databázi. Čímž vznikne model nezávislý na databázovém systému, který bude zvolen pro implementaci. Tento model již obsahuje popis požadovaných datových 16
struktur, entit a jejich vzájemných vztahů. Zároveň by u těchto vztahů měla být definována kardinalita a parcialita a rovněž základní integritní omezení.[9] Logický datový model Konceptuální datový model následně transformujeme do logického datového modelu, který je již závislý na technologickém prostředí. Nejčastějším prostředím je relační databáze, ale používá se i objektová či XML. Tato transformace vyžaduje především definici všech množin entit, atributů, dále pak určení primárních a cizích klíčů a normalizaci dat.[9] Fyzický datový model Z předchozího modelu vznikne fyzický datový model, který zobrazuje datovou strukturu pro konkrétní aplikaci a databázový systém. V modelu jsou již tedy zahrnuta specifika konkrétního zvoleného implementačního prostředí. Pro vytvoření tohoto modelu musí být převedeny množiny entit na tabulky a atributy na sloupce, u kterých je nutné specifikovat datové typy. Dále musí být realizovány vztahy pomocí cizích klíčů a také veškerá integritní omezení a další požadavky (např. denormalizace). Na základě navrženého fyzického datového modelu vzniká již konkrétní databáze pro námi vybraný SŘBD.[9]
3.2 Normalizace databáze 3.2.1 Co je to normalizace databáze? Normalizace je jedním z nejdůležitějších kroků při návrhu relačních databází. Jedná se o sadu pravidel, podle které by se mělo postupovat při transformaci ze struktury ER modelu na strukturu fyzického uspořádání tabulek a relací v databázi. Normalizace by měla vést ke vzniku tabulek, které lze snadno udržovat a nad kterými lze provádět co nejefektivnější dotazy. Zároveň však musí zachovat všechny závislosti původního schématu a relace musí zachovat původní data. Zejména u objemných databází je nutné provést normalizaci, protože práce s normalizovanými daty je pro databázový stroj rychlejší a také značně snižuje nároky na velikost úložného prostoru. Normalizovaná databáze může být v budoucnu snáze rozšiřována. Model databáze pomocí normalizace upravujeme především se třemi základními cíli – omezení redundance dat, omezení složitosti a zabránění aktualizačním anomáliím. Omezením redundance dat, tj. odstraněním duplicitních údajů, zajistíme jedinečnost uložených dat v databázi. Omezení složitosti spočívá především v nahrazení složitých 17
vztahů dvojrozměrnými tabulkami. Zabránit aktualizačním anomáliím je nutné především pokud bychom smazáním určitých prvků z databáze ztratili určité údaje obsažené jen v dané relaci, např. v tabulce zboží v obchodě, kde by u každého výrobku bylo uvedeno přímo jméno a kontakt dodavatele a při smazání všech těchto výrobků by byl z databáze odstraněn i tento dodavatel. Existuje 6 úrovní normalizace, ale v praxi se obvykle využívá normalizace po třetí normální formu, s možností následné denormalizace (především z výkonnostních důvodů).[5][14] 3.2.2 Jak a proč normalizaci použít 1.NF – První normální forma První normální formy je dosaženo za předpokladu, že každý atribut relace obsahuje jen atomické hodnoty, tj. hodnoty z pohledu databáze již dále nedělitelné. Například v relaci obsahující data o filmech budeme mít více herců: Filmy ID 1 2 3
Název
Herci
Přelet nad kukaččím hnízdem Jack Nicholson; Louise Fletcher Forrest Gump Tom Hanks;Robin Wright Kmotr Marlon Brando;Al Pacino;Diane Keaton Tabulka 3.2.2.a – Příklad 1.NF, zdroj: autor
V takovéto tabulce by se špatně prováděly změny v buňce herci a vyhledávání podle herců by bylo také hůře proveditelné. Proto musíme atribut herci oddělit do samostatné tabulky: Filmy
Herci
ID
Název
ID_filmu
1 2 3
Přelet nad kukaččím hnízdem Forrest Gump Kmotr
1 1 2 2 3 3 3
Herec Jack Nicholson Louise Fletcher Tom Hanks Robin Wright Marlon Brando Al Pacino Diane Keaton
Tabulky 3.2.2.b – Transformace do 1.NF, zdroj: autor
18
2.NF – Druhá normální forma Jestliže je relace v první normální formě a každý neklíčový atribut je plně závislý na celém primárním klíči, nachází se relace v druhé normální formě. Druhou normální formu tedy musíme řešit pouze v případě, že máme vícehodnotový primární klíč. Například v tabulce sklad v obchodě bude název zboží, výrobce, kontakt na výrobce, cena produktu a množství dostupné na skladě: Sklad Název zboží
Klíčem této relace je kombinace atributů Název zboží a Výrobce, ale telefon výrobce je závislý pouze na atributu Výrobce. Mohla by zde snadno vzniknout aktualizační anomálie, při odstranění všech výrobků od Výrobce Plzeňský Prazdroj a.s., by z databáze rovněž zmizel telefon na tohoto výrobce. Ideálním řešením je opět rozdělení do dvou tabulek: Výrobek Název zboží
Tabulky 3.2.2.d – Transformace do 2.NF, zdroj: autor
3.NF – Třetí normální forma Jestliže tabulka splňuje předcházející dvě formy a žádný z jejich atributů není tranzitivně závislý na klíči, tj. pokud jsou všechny neklíčové atributy navzájem nezávislé. Například v případě, že firma spravuje relaci zaměstnanců s těmito atributy:
19
Kromě závislosti všech atributů na klíči, je
Zaměstnanec ID 1 2 3 4 5
Jméno Jan Stanislav Petr Pavel Jan
Příjmení Vomáčka Novák Koukal Dlouhý Veselý
Město Praha 1 Plzeň Praha 1 Ostrava Plzeň
PSČ 11000 30100 11000 70800 30100
také patrná závislost PSČ a Města, aby byla splněna podmínka 3.NF musí být všechny neklíčové atributy navzájem nezávislé. Proto musíme opět rozložit tuto tabulku do více relací:
Tabulky 3.2.2.f – Transformace do 3.NF, zdroj: autor
Kromě těchto nejvíce používaných norem existují ještě Boyce-Coddova normální forma (dále jen BCNF), čtvrtá normální forma (dále jen 4.NF) a pátá normální forma (dále jen 5.NF). BCNF je pokládána za variaci 3.NF a je její původní definicí ze 70. let. Je vymezena stejnými pravidly jako 3.NF, ale tyto pravidla musí platit i mezi hodnotami uvnitř složeného primárního klíče. Ve 4.NF je relace pokud je v BCNF, a všechny vícehodnotové závislosti v relaci jsou zároveň funkčními závislostmi. V 5.NF je relace, pokud je ve 4.NF a nemůže-li být dále rozložena bez ztráty dat.[12]
4
Třída FPDF
Skriptovací jazyk PHP neumožňuje implicitně vytvářet dokumenty PDF. Nejprve je nutné stáhnout jednu z řady knihoven, která tvorbu těchto dokumentů umožňuje. Aby PHP mohlo tuto knihovnu využívat, musí být umístěna do adresáře s PHP kódy. Nejlepší funkcionalitu a podporu nabízí oficiální PDFlib, tato verze knihovny je ovšem licencovaná. Existuje ovšem i mnoho opensource tříd, které se svoji funkčností a nabízenými službami téměř rovnají oficiální verzi knihovny. Mezi jedny z nejlepších, patří například mPDF, TCPDF, nebo mnou použitá FPDF.[15]
20
4.1 Co je FPDF? FPDF je třída, která umožňuje generování PDF dokumentů pouze pomocí použití kódu PHP. Je tedy nezávislá na využívání knihovny PDFlib. F v názvu znamená „Free“, tj. tato třída může být užívána i modifikována bezplatně podle potřeb uživatele. Pro použití třídy FPDF jsem se rozhodl kvůli tomu, že už s ní mám určité zkušenosti, ale především díky dobré jazykové podpoře. Umí vytvořit dokumenty v mnoha jazycích, kromě západních jazyků zvládá také jazyky středoevropské, řecké, azbuku, baltské a thajské. Rychlost generování dokumentu je sice u FPDF nižší než u knihovny PDFlib, což je způsobeno tím, že tato třída generuje dokument přímo v PHP a nevyužívá žádné knihovny. U méně složitých dokumentů je však tento rozdíl téměř nepostřehnutelný.[9]
4.2 Základy práce s FPDF Pro umožnění vytváření dokumentu je nutné nejdříve v kódu, použitím funkce require(), načíst soubor fpdf.php. Poté již můžeme začít vytvářet PDF dokument pomocí následujících příkazů: FPDF() – základní konstruktor třídy, umožňuje nastavit formát stránky, její orientaci a základní měrnou jednotku (s výjimkou velikostí fontů) SetAuthor() – definuje autora dokumentu AddPage() – přidá novou stranu dokumentu, opět umožňuje nastavit formát a orientaci stránky, pokud nejsou specifikovány, používá hodnoty konstruktoru AddFont() – importuje font pro použití v dokumentu, při přidávání vlastních fontů je nutné vytvořit definiční soubor pomocí vnořené utility, který musí být v adresáři font SetFont() – nastavení písma, které bude použito pro tisk dokumentu, metoda musí být zavolána alespoň jednou před tiskem textu SetXY() – nastaví pozici osy x a y, existují i metody pro individuální nastavení pouze osy x, respektive pouze osy y Cell() – vytiskne obdélníkovou buňku s textem, v parametrech je možné nastavit šířku a výšku buňky, její ohraničení, následné pozice, zarovnání textu a také pozadí buňky Write() – jednoduchá funkce pro tisk víceřádkového textu, při dosažení pravého okraje pokračuje tisk dalším řádkem od levého okraje MultiCell() – podobně jako předchozí funkce pro tisk textu s více řádky do určité definované buňky, s možnostmi nastavení ohraničení kolem buňky, jejího pozadí a zarovnání textu v buňce 21
Image() – vložení obrázku do dokumentu, parametry tvoří název souboru, pozice, šířka výška a popřípadě typ Output() – ukončí dokument a odešle jej pod zadaným jménem k vybranému cíli, kterým může být uložení souboru, čí odeslání souboru do prohlížeče, kde může být automaticky zobrazen pomocí plugi-nu nebo vynuceno jeho uložení Třída FPDF obsahuje mnoho dalších funkcí a metod, ale při použití těchto základních je možné vytvořit dokument, za který se nemusíme stydět.[9]
4.3 Podpora kódování a přidávání nových fontů S použitím češtiny při vytváření dokumentů pomocí FPDF může nastat několik potíží. Tato třída totiž nepodporuje kódování UTF-8, ale pouze ISO-8859-5 nebo Windows 1250. Přestože tato třída obsahuje vlastní písma, nelze většinu z nich úspěšně použít z toho důvodu, že neobsahují české znaky. Při tvorbě dokumentu je však možné použít vlastních fontů, u kterých je možné zvolit kódování fontu. Existují dvě možnosti, jak použít nový font, a sice jeho přiložením čí nepřiložením do PDF. Pokud font není přiložen, je použit font obsažený v systému. Výhodou tohoto řešení je menší velikost výsledného dokumentu. Na druhou stranu pokud tento font v systému není nalezen, je použit náhradní font, který určité znaky nemusí zobrazovat korektně. Je tedy lepší zajistit, aby byl font na systémech klientů, kteří k tomuto dokumentu budou přistupovat. Druhou, vysoce doporučovanou možností je přiložení tohoto fontu k dokumentu. Přidání nového fontu vyžaduje splnění tří základních kroků: •
vygenerování metrického souboru (.afm)
•
vygenerování definičního souboru fontu (.php)
•
deklarace fontu ve skriptu (pomocí metody AddFont())
Takto přidaný font však může zvětšit velikost výsledného dokumentu až o několik set kB. Je tedy nutné výsledný font ještě upravit, abychom snížili jeho výslednou velikost. První možností je využít knihovnu zlib, což je bezeztrátová kompresní knihovna, kterou lze použít nezávisle na platformě. Jako druhá varianta se nabízí převedení fontu z TrueType na Typ1, který zachová pouze znaky pro vybrané kódování a sníží tak velikost tohoto souboru o celý řád.[9]
22
PRAKTICKÁ ČÁST
23
5
Návrh nového informačního systému
5.1 Analýza a návrh Analýza je především zaměřená na požadavky a jejich bližší rozpracování. Záměrem analýzy je tvorba analytických modelů, které se zaměřují na funkčnost systému, aniž by se zabývaly způsobem, jakým systém jednotlivé funkce bude provádět. Analytický model zachycuje problém z určité perspektivy a prakticky „vypráví“ příběh o požadovaném systému. Měl by být také užitečný pro maximální počet uživatelů a zúčastněných osob. Analýza tedy tvoří hlavně logický model připravovaného systému, který znázorňuje funkce, jež tento systém musí poskytovat za účelem uspokojení požadavků uživatelů. Smyslem návrhu je již konkrétní specifikace způsobu, jak budou tyto funkce implementovány. Aktivity analýzy a návrhu mohou probíhat paralelně, ale je důležité správně rozlišit jednotlivé artefakty obou aktivit. Návrhový model je založen na analytickém modelu, a proto jej můžeme považovat za upřesnění a rozpracování analytického modelu. Tento model tedy do původního analytického modelu doplňuje podrobnosti a konkrétní technická řešení.[1] 5.1.1 Specifikace systémových požadavků Požadavky jsou základem všech systémů a jsou v podstatě vyjádřením toho, co by měl systém dělat (nikoli jak by toho měl dosáhnout). Specifikace systémových požadavků začíná obecným dokumentem, v němž je popsána představa, co bude nový systém dělat. Smyslem toho dokumentu je zachycení cílů, které jsou pro budoucí funkčnost systému z pohledu zainteresovaných osob nejpodstatnější. Kvalita výsledného systému je přímo závislá na procesu inženýrství požadavků, a proto by neměla být podceňována. V podstatě rozlišujeme dva typy požadavků – funkční požadavky, které určují, jaké chování bude systém nabízet a nefunkční požadavky, které specifikují vlastnosti a omezující podmínky daného systému. Jazyk UML sice neposkytuje žádné doporučení, které by se týkalo psaní specifikací systémových požadavků, neboť je zobrazuje pomocí mechanismu případu užití. Přesto je však pro vývoj systému doporučováno, mimo případů užití, používat také specifikaci systémových požadavků. Kromě rozdělení
24
požadavků na dva typy, může každý požadavek obsahovat množinu atributů, obsahujících dodatečné informace, týkající se daného požadavku.[1] Funkční požadavky •
Systém bude rozlišovat 4 úrovně uživatelů – anonymní, student, učitel, administrátor.
•
Systém bude umožňovat registraci nového studenta všem anonymním uživatelům.
•
Do systému se může přihlásit libovolný anonymní uživatel.
•
Zobrazit všechna vypsaná témata může každý uživatel.
•
Každý uživatel může zobrazit témata, která nejsou rezervována.
•
Seznam učitelů, kteří mají vypsaná témata, může být zobrazen libovolným uživatelem.
•
Každý uživatel může zobrazit seznam konzultací.
•
Každý přihlášený uživatel si může změnit své uživatelské údaje.
•
Měnit si heslo může každý přihlášený uživatel.
•
Systém povolí odhlášení pouze přihlášeným uživatelům.
•
Systém bude umožňovat rezervaci konzultací pouze uživatelům typu student.
•
Systém bude umožňovat rezervaci témat pouze uživatelům typu student.
•
Každý student může změnit své rezervované téma.
•
Každému učiteli bude umožněno zobrazit jím vypsaná témata.
•
Přidávat nové téma bude moci pouze učitel.
•
Každý učitel bude moci spravovat svá témata a konzultace.
•
Přidávání nových konzultací náleží pouze učiteli.
•
Systém umožní učiteli přidávání posudků pro odevzdané práce.
•
Posudky bude možné upravovat.
•
Systém umožní učiteli zobrazit seznam vypracovaných posudků.
•
Vypracované posudky bude systém generovat do PDF.
•
Systém bude umožňovat resetování hesla administrátorem.
•
Všechny uživatele systému bude moci zobrazit pouze administrátor.
•
Mazání uživatelů bude příslušet pouze administrátorovi.
Nefunkční požadavky •
Systém bude napsán ve skriptovacím jazyce PHP. 25
•
Data budou uložena v databázi MySQL.
•
Registrace učitele nebude dostupná všem uživatelům.
•
Určité části systému budou přístupné pouze registrovaným uživatelům.
•
Zabezpečení hesel v databázi bude řešeno kombinací šifrování SHA1 a MD5.
5.1.2 Označení aktérů Aktér je role, kterou určitá externí entita přijímá v okamžiku započetí používání systému. I když jsou aktéři z pohledu systému externí entitou, obvykle systém obsahuje interní reprezentaci jednoho nebo více aktérů. Pro specifikaci jednotlivých aktérů, musím zvážit kdo, nebo co daný systém používá a jakým způsobem. Pokud je potřeba v systému modelovat události, které nastanou v určitých časových bodech, ale bez působnosti aktéra, můžeme zavést aktéra čas. Což by se mohlo hodit např. pro automatické zálohy systému.[1]
Obrázek 5.1.2 – Diagram aktérů, zdroj: autor
26
Vyvíjený systém bude rozlišovat mezi čtyřmi úrovněmi aktérů – Administrátor, Anonymní Uživatel, Student a Učitel (viz. Obr 5.1.2). Administrátor bude moci měnit určitá nastavení, skrytá všem ostatním uživatelům, ale nezbytná pro korektní chod systému. Jako Anonymní Uživatel bude k systému moci přistupovat libovolný uživatel. Základní práva tohoto uživatele zdědí aktéři Student i Učitel, nicméně jejich role v systému bude značně odlišná. 5.1.3 Modelování případů užití Modelování případů užití je jednou z forem inženýrství požadavků. Jedná se o doplňkové modely k vytvořené specifikaci systémových požadavků. Modelování případů užití se skládá z těchto prvků – nalezení hranic systému, vyhledání aktérů, specifikace případů užití (popřípadě jejich alternativních scénářů). Případ užití je vlastně funkce, kterou od systému očekává aktér, jedná se tedy o případ užití určitým aktérem. Případy užití jsou vždy iniciovány aktérem a jsou napsány vždy z pohledu aktéra. Model případu užití obsahuje čtyři komponenty: •
Hranice systému – což je ohraničení zobrazené kolem případů užití a jedná se o vyznačené území námi modelovaného systému.
•
Aktéři – role přidělené osobám nebo předmětům, které používají daný systém.
•
Případy užití – činnosti, které systém umožňuje aktérům vykonávat.
•
Relace – vztahy mezi aktéry a případy užití
Tyto modely jsou hlavním zdrojem objektů a tříd a prvotním vstupem, který slouží k modelování tříd.[1]
27
Obrázek 5.1.3.a – Celkový model případů užití, zdroj: autor
Takto vypadá pohled na celkový model případu užití v našem případě, který jsem pro zvýšení přehlednosti rozdělil do šesti modulů, včetně speciálního diagramu aktérů (viz Obrázek 5.1.2).
28
Obrázek 5.1.3.b – USE CASE diagram pro uživatelský přístup, zdroj: autor
Na tomto modelu je znázorněn přístup uživatelů do systému. Zatímco anonymní uživatel má pouze možnost registrace, registrovaní uživatelé učitel a student mohou v modulu správy uživatelských účtů využívat větší množství funkcí. Pro větší přehlednost zde byl vytvořen abstraktní aktér uživatel, který zachycuje společné chování dvou konkrétních aktérů.
29
Obrázek 5.1.3.c – USE CASE diagram správy systému, zdroj: autor
Modul správy systému byl znázorněn odděleně, protože jeho jediný aktér administrátor je jedinečný a značně se odlišuje od ostatních aktérů. Tyto funkce mu umožňují spravovat veškeré potřebné aspekty nezbytné pro bezproblémový chod systému a zároveň mu dávají pravomoci nastavovat určité plošné parametry.
30
Obrázek 5.1.3.d – USE CASE diagram správy posudků, zdroj: autor
Na tomto diagramu jsou zachyceny případy užití v modulu správy posudků. K jejich vytváření a modifikací bude mít přístup pouze aktér učitel. Základním předpokladem pro vytvoření posudku bude fakt, že daná práce již byla odevzdána.
31
Obrázek 5.1.3.e – USE CASE diagram rezervace témat, zdroj: autor
Tento diagram znázorňuje možnosti aktérů v modulu rezervace témat AP a BP. Aktéři student a učitel zde dědí všechny entity a relace přístupné aktérovi anonymní uživatel, což je umožněno generalizací.
32
Obrázek 5.1.3.f – USE CASE diagram rezervace konzultací, zdroj: autor
Poslední modul se zabývá rezervací konzultací, ke které mají opět přístup všichni aktéři (mimo administrátora). Takto zpracované diagramy případu užití by nám měli nyní pomoci ke konkrétnější představě o systému. Každý specifikovaný požadavek by měl být pokryt alespoň jedním případem užití.
33
5.1.4 Specifikace případů užití Když máme označeny všechny aktéry a klíčové případy užití, je nyní nezbytné provést jejich specifikaci. Pro specifikaci případu užití, někdy také nazývanou detail případu užití, opět neexistuje žádný standard UML. Je však nutné specifikovat každý vytvořený případ užití, protože jejich detaily nám pomohou nabýt lepších představ o systému. Specifikace případu užití by mohla vypadat například takto:[1] Případ Užití: ZměnitÚdaje ID: 6 Stručný popis: Umožňuje uživateli měnit personální údaje. Hlavní aktéři: Student, Učitel. Vedlejší aktéři: Žádní. Vstupní podmínky: 1. Uživatel je přihlášen. Hlavní scénář: 1. Případ užití začíná, jakmile chce uživatel provést změnu uživatelských údajů. 2. Systém zobrazí uživateli současné údaje. 3. Uživatel změní požadované údaje. 4. Systém ověří správnost zadaných údajů 5. Pokud systém označí údaje jako správné: 5.1. Systém vyhledá uživatele v databázi. 5.2. Systém změní aktuální údaje na požadované 5.3. Systém informuje uživatele o úspěšné změně údajů. 6. Nebo: 6.1. Systém informuje uživatele o nesprávnosti zadaných údajů. Výstupní podmínky: 1. Změna uživatelských údajů. Alternativní scénáře: Žádné. Tabulka 5.1.4.a – Příklad specifikace případu užití, zdroj: autor
Tento scénář případu užití popisuje, jak by měl vypadat průběh úkonu daného případu užití (v tomto případě změny uživatelských údajů). Zadaný detail obsahuje jednoznačný identifikátor, který by měl být použit pro případ, kdyby se v pokročilejší fázi návrhu měnilo jméno případu užití. Detail dále specifikuje všechny aktéry, kteří budou přímo či nepřímo tímto případem ovlivněni. Vstupní podmínka pro tento případ je splněna za předpokladu, že uživatel je přihlášen. Dále následuje detailní popis průběhu případu užití, výstupní podmínky a případné alternativní scénáře.
34
Případ Užití: PřihlásitSe ID: 3 Stručný popis: Umožňuje registrovanému uživateli přihlášení a využívání výhod z toho plynoucích. Hlavní aktéři: Učitel, Student. Vedlejší aktéři: Žádní. Vstupní podmínky: 1. Uživatel není přihlášen. Hlavní scénář: 1. Akce začíná zadáním a odesláním přihlašovacích údajů. 2. Zahrnout (OvěřitHeslo). 3. Pokud bylo heslo úspěšně ověřeno: 3.1. Uživatel je úspěšně přihlášen. 3.2. Je přesměrován na stránku svého profilu. 4. Nebo: 4.1. Systém informuje uživatele, že zadané heslo nebo jméno není správné. Výstupní podmínky: 1. Uživatel je úspěšně přihlášen. Alternativní scénáře: Žádné Tabulka 5.1.4.b – Příklad specifikace klientského případu užití, zdroj: autor
Na tomto detailu případu užití je zobrazen scénář aplikace pro přihlášení uživatele. Opět zde nechybí stručný popis, aktéři, vstupní a výstupní podmínky a samotný scénář. Ten je ovšem specifický tím, že využívá vnořeného případu užití OvěřitHeslo. To nám může značně usnadnit práci, protože při modelování případu užití můžeme narazit na proces, který bude systém prováděn opakovaně. Místo abychom daný prvek v modelu několikrát opakovali, využijeme relace <>, která nám umožní zahrnout takto vytvořený případ užití do příslušných případů užití (nazývané také klientské případy užití), kde je to potřebné. Zahrnovaný scénář (dodavatelský případ užití) OvěřitHeslo by poté mohl vypadat takto:
35
Případ Užití: OvěřitHeslo ID: 4 Stručný popis: Systém ověřuje, zda se zadané heslo a uživatelské jméno shodují s údaji v databázi. Hlavní aktéři: Učitel, Student. Vedlejší aktéři: Žádní. Vstupní podmínky: 1. Uživatel zadá své jméno a heslo a potvrdí stiskem přihlásit se. Hlavní scénář: 1. Systém načte jméno a heslo zadané uživatelem. 2. Tyto údaje porovná s údaji v databázi. 3. Pokud se shodují: 3.1. Systém odešle informaci o úspěšné identifikaci. 4. Nebo: 4.1. Systém odešle informaci o špatně zadaném jménu či heslu. Výstupní podmínky: 1. Systém odešle informaci o úspěšné kontrole hesla Alternativní scénáře: ŠpatnéHeslo Tabulka 5.1.4.c – Příklad specifikace dodavatelského případu užití, zdroj: autor
5.1.5 Diagramy aktivit Diagramy aktivit umožňují modelování procesů jako aktivit, které se skládají z kolekce uzlů spojených hranami. Zaměření se na komunikaci s jedním specifickým aspektem dynamického chování systému napomáhá skutečnosti, že vznikne dobrý diagram aktivit. Během analýzy se diagramy aktivit nejčastěji používají pro grafické modelování scénáře případu užití nebo při modelování cest mezi jednotlivými případy užití, kdy na sebe berou podobu nazývanou zjednodušený diagram interakce. Během návrhu se pak tyto diagramy využívají k modelování podrobností operace nebo k modelování detailů algoritmu. Aktivity se skládají ze sítí spojených hranami. Rozlišujeme tři kategorie uzlů – akční uzly, které zastupují samostatné nedělitelné jednotky v rámci aktivity, řídící uzly, které řídí cestu uvnitř aktivity a objektové uzly, jež zastupují objekty použité v rámci dané aktivity. Aktivity mohou mít stejně jako případy užití také vstupní a výstupní podmínky. Často začínají jedním počátečním řídícím uzlem, který označuje výchozí bod, v němž bude proces po spuštění této aktivity zahájen. Ukončení aktivity označuje koncový uzel, kterých může být případně i více.[1] 36
Obrázek 5.1.5 – Diagram aktivit, zdroj: autor
Názorný příklad diagramu aktivit pro proces tvorby absolventské práce, který začíná tvorbou tématu a končí vytvořením posudku na odevzdanou práci.
37
5.2 Návrh vlastní databáze pro IS 5.2.1 Model a popis databáze
Obrázek 5.2.1 – Fyzický datový model, zdroj: autor
38
Na obrázku 4.2 je již zobrazen fyzický datový model budoucí databáze, kterou bude IS využívat. Databáze se skládá z pěti hlavních relací – Student, kde budou uložena data o uživatelích typu student; Ucitel, která bude podobným způsobem archivovat údaje o uživatelích typu učitel; Temata, má za úkol uchovávat informace o vypsaných absolventských a bakalářských pracích; relace Rezervace_Tematu, v níž budou uloženy detaily o rezervacích témat určitým studentem; a relace Posudek, do které se budou ukládat jednotlivé posudky. Dále je databáze tvořena třemi vazebními tabulkami – Nabidka_Temat, Nabidka_Konzultaci a Rezervovane_Konzultace. Poslední jmenovaná relace obsahuje mimo cizích klíčů také detaily studentem rezervované konzultace. Kardinalita (uvedená v závorce za vztahem) a parcialita jednotlivých relací vypadá následovně: Ucitel – Nabidka_Konzultaci (1:N) - volnost na straně Nabidka_Konzultaci, protože každý učitel může mít n konzultací, ale každá nabídka musí mít učitele Konzultace – Nabidka_Konzultaci (1:N) - konzultace musí být nabízena určitým učitelem, nabídka musí mít určitou konzultaci Ucitel – Nabidka_Temat (1:N) - volnost na straně Nabidka_Temat, protože každý učitel může přidat n témat, ale každá nabídka musí mít svého učitele Temata – Nabidka_Temat (1:N) - pro téma musí existovat nabídka, nabídka tématu musí mít určité téma Konzultace – Rezervovane_Konzultace (1:N) - volnost na straně Rezervovane_Konzultace, protože každá konzultace může dosáhnout až n rezervací, ale rezervovaná konzultace musí mít konzultaci Student – Rezervovane_Konzultace (1:N) - volnost na straně Rezervovane_Konzultace, protože každý student může rezervovat až n konzultací, ale rezervace musí být provedena určitým studentem Student – Rezervace_Tematu (1:1) - volnost na straně Rezervace_Tematu, protože každý student může rezervovat právě jedno téma, ale každá rezervace musí být provedena právě jedním studentem Temata – Rezervace_Tematu (1:1) - volnost na straně Rezervace_Tematu, protože každé téma může být rezervováno, ale každá rezervace musí mít své téma 39
Rezervace_Tematu – Posudek (1:1) - volnost na straně Posudek, protože každá rezervace může mít právě jeden posudek, ale ke každému posudku musí existovat právě jedna rezervace 5.2.2 Datový slovník Datový slovník je soubor, který poskytuje ucelené informace o struktuře a složení datové základny. Zahrnuje seznam všech relací a atributů včetně popisu datových prvků a údajů o integritních omezeních a také popis jednotlivých atributů. Relace Ucitel •
id_Ucitele: int – primární klíč, jedinečný identifikátor učitele
•
jmeno: varchar(30) – křestní jméno učitele, minimální délka 3 znaky
•
prijmeni: varchar(30) – příjmení učitele, minimální délka 3 znaky
•
username: varchar(20) – přihlašovací jméno učitele, jedinečné, min. 6 znaků
•
heslo: varchar(20) – heslo učitele, šifrování, minimální délka 6 znaků
•
email: varchar(30) – email učitele, kontrola validity emailu
Relace Student •
id_Studenta: int – primární klíč, jedinečný identifikátor studenta
•
jmeno: varchar(30) – křestní jméno studenta, minimální délka 3 znaky
•
prijmeni: varchar(30) – příjmení studenta, minimální délka 3 znaky
•
username: varchar(20) – přihlašovací jméno studenta, jedinečné, min. 6 znaků
•
heslo: varchar(20) – heslo studenta, šifrování, minimální délka 6 znaků
•
email: varchar(30) – email studenta, kontrola validity emailu
•
typ_Studia: tinyint(1) – booleovská proměnná pro rozlišení typu studia
Relace Konzultace •
id_Konzultace: int – primární klíč, jedinečný identifikátor konzultace
•
start_Konzultace: datetime – datum a čas začátku konzultace
•
konec_Konzultace: datetime – datum a čas konce konzultace
•
kapacita: int – počet možných rezervací dané konzultace
•
mistnost: varchar(10) – místo konání konzultace
•
poznamka: text – poznámka učitele ke konzultaci
Relace Temata •
id_Tematu: int – primární klíč, jedinečný identifikátor tématu
•
nazev: varchar(255) – název tématu 40
•
popis: text – detailnější popis tématu
•
k_Dispozici: tinyint(1) – booleovská proměnná pro rozlišení dostupnosti tématu
Relace Rezervace_Tematu •
id_Rezervace: int – primární klíč, jedinečný identifikátor rezervace
•
id_Studenta: int – cizí klíč, kaskádová reference
•
id_Tematu: int – cizí klíč, kaskádová reference
•
finalni_Nazev: varchar(255) – finální název práce
•
cil_Prace: text – cíl práce
•
osnova: text – návrh osnovy práce
•
odevzdana: tinyint(1) – booleovská proměnná pro rozlišení, zda již byla práce odevzdána
Relace Rezervovane_Konzultace •
id_Konzultace: int – sdílený primární klíč, cizí klíč, kaskádová reference
•
id_Studenta: int – sdílený primární klíč, cizí klíč, kaskádová reference
•
poznamka: text – poznámka studenta k rezervaci
•
nadpis: varchar(20) – nadpis k poznámce studenta k rezervaci
•
priloha: varchar(255) – odkaz na přílohu přiloženou studentem k rezervaci
Relace Nabidka_Konzultaci •
id_Ucitele: int – sdílený primární klíč, cizí klíč, kaskádová reference
•
id_Konzultace: int – sdílený primární klíč, cizí klíč, kaskádová reference
Relace Nabidka_Temat •
id_Ucitele: int – sdílený primární klíč, cizí klíč, kaskádová reference
•
id_Tematu: int – sdílený primární klíč, cizí klíč, kaskádová reference
Relace Posudek •
id_Posudku: int – primární klíč, jedinečný identifikátor posudku
•
id_Rezervace: int – cizí klíč, kaskádová reference
•
pripominky: text – připomínky a otázky připojené k posudku
•
viditelnost: tinyint(1) – booleovská proměnná pro označení vyhotovených posudků, z nichž mohou být generovány posudky
•
datum: date – datum uložení posudku
41
Veškeré ostatní atributy z relace Posudek jsou typu integer. Jedná se o položky, které ukládají hodnocení posudku na náročnost tématu, obsah bakalářské práce, provedení bakalářské práce, a také navržená známka.
6
Implementace systému pro tvorbu posudků
Vkládání posudku je podmíněno faktem, že zadaná práce již byla odevzdána. Proto byl do tabulky rezervací témat přidán atribut odevzdana, který umožňuje mapovat, jestli už byla daná práce odevzdána. V ideálním případě se tedy student po dopsání a odevzdání práce přihlásí do systému, kde v menu vybere položku Moje téma. Zde stačí již pouze zatrhnout checkbox a uložit vybranou volbu (viz. Obrázek 5). Učiteli se po přihlášení do systému zobrazí tato práce mezi odevzdanými, které čekají na ohodnocení. Učitel pak pouze vybere práci, kterou chce ohodnotit a může začít vytvářet posudek. Zde ovšem může nastat drobný problém či prodleva, protože student dlouho po odevzdání ještě nezměnil statut práce na „odevzdaná“, nebo na to úplně zapomněl. V takovém případě, by učitel práci ohodnotit pomocí systému nemohl. Aby se zamezilo těmto nesnázím, je umožněno měnit statut práce také učiteli.
Obrázek 6 – Odevzdání práce v IS, zdroj: autor
6.1 Vkládání hodnocení Vlastní vkládání hodnocení je vytvořeno za účelem minimalizace úkonů pro učitele. Po vybrání práce se učiteli zobrazí stránka pro vlastní realizaci posudku. Ta již obsahuje 42
všechny parametry, které budou vkládány z databáze do výsledného posudku. Konkrétně se jedná o jméno vedoucího práce, studenta a název dané práce. Tyto parametry již nemusí učitel při vyplňování posudku zadávat, zde jsou vypsány pouze pro kontrolu. Během zadávání má také neustálý přehled o práci, jejíž posudek v dané chvíli vytváří.
Obrázek 6.1.a – Tvorba posudku 1, zdroj: autor
Hodnocení probíhá výběrem jednotlivých známek pomocí jednotlivých přepínačů. Jedinou výjimku tvoří vkládání připomínek a doplňujících otázek k dané práci. Kdykoli během procesu tvorby posudku je možné práci uložit, přerušit a následně pokračovat
43
v dalším hodnocení. Jakmile učitel dokončí tvorbu daného posudku, výběrem označí práci jako ohodnocenou a může posudek uložit.
Obrázek 6.1.b – Tvorba posudku 2, zdroj: autor
6.2 Způsob ukládání a editace hodnocení Kdyby učitel během tvorby posudku musel svoji činnost přerušit, nebo pokud by chtěl již vypracovaný posudek v budoucnu měnit, je nezbytné, aby mohl svoji práci uložit. Proces uložení do databáze je velice jednoduchý, všechna data vložená do formuláře se jednoduše odešlou na stránku, kde proběhne jejich vložení do databáze. Musíme ovšem zajistit předání identifikátoru rezervace, který určuje, jaký posudek má být v databázi uložen, respektive upraven. Toho je docíleno velice lehce, a sice pomocí skrytého vstupního typu, jehož hodnota je nastavena na tento identifikátor.
Samotné zapsání dat do databáze je již triviální. Všechna data poslaná formulářem jsou uložena do proměnných. Tyto proměnné se následně příkazem update uloží do databáze. $id_Rezervace=$_POST['id_Rezervace']; $teorie=$_POST['teorie']; ... $datum=$_POST['datum']; mysql_query("UPDATE Posudek SET id_Rezervace =‘$id_Rezervace', teorie='$teorie', … datum='$datum' WHERE id_Rezervace=$id_Rezervace");
44
Větší problém nastává při zpětném načítání dat z databáze, respektive v nastavení hodnot formuláře podle atributů v databázi. Samotné načtení dat je opět velice triviální, ale nastavení správných hodnot přepínačům je již o poznání komplikovanější. $dotaz1=mysql_query("SELECT * FROM Posudek WHERE id_Rezervace=$id_Rezervace"); //načtení Posudku z databáze $posudek=mysql_fetch_array($dotaz1); //vložení posudku do pole
Pro nastavení hodnot se u každého přepínače stejného jména testuje hodnota načteného atributu. V případě rovnosti je volán příkaz, který označí pozici daného přepínače.
na teoretické znalosti
Předchozí postup je opakován u všech načítaných hodnot posudku, kromě data a připomínek. Tyto vstupní typy umožňují přímou definici hodnoty, jak je vidět v následujícím skriptu.
6.3 Generování výsledného dokumentu ve formátu PDF Jakmile učitel nastaví práci v parametru „ohodnocená“, může nechat systém vygenerovat dokument PDF. Vzhledem ke složitosti formuláře byl jako ideální vybrán následný postup vytváření výsledného dokumentu. Nejprve je na dokument aplikována šablona výsledného vzhledu. Přes tuto šablonu jsou poté natištěna veškerá hodnocení, která jsou uložena z databáze. Tento postup je nutný pouze pro první stranu formuláře, připomínky a doplňující otázky jsou již do výsledného PDF tištěna přímo. 6.3.1 Implementace šablony výsledného vzhledu Pro vytvoření šablony, která bude použita pro tvorbu dokumentu jsem zvolil následující variantu. V té je nejprve načteno PDF prázdného formuláře posudku, který je použit 45
jako šablona pro tvorbu výsledného dokumentu. Prázdný formulář jsem do formátu PDF převedl pomocí volně dostupného programu PDFCreator. Tato varianta tvorby PDF je vhodnější než užití obrázku jako šablony, zejména ze dvou důvodů. Zaprvé velikost výsledného dokumentu by byla nesrovnatelně větší a zadruhé kvalita takového dokumentu by byla podstatně nižší. Jedinou nevýhodou užití tohoto postupu je nutnost užití FPDI, což je rozšiřující třída pro FPDF. Vzhledem k tomu, že budeme do dokumentu používat dvě různé šablony, musíme nejprve rozpoznat, kterou šablonu máme pro daný posudek použít. Toho je dosaženo za pomoci atributu typ_Studia, který si každý student nastavuje ve svém uživatelském účtu. Tento atribut, který nabývá dvou hodnot, nám pomůže rozlišit studenty na dva typy – absolventy a bakaláře. $dotaz=mysql_query("SELECT typ_Studia FROM Student s JOIN Rezervace_Tematu rt ON s.id_Studenta=rt.id_Studenta WHERE id_Rezervace='$id_Rezervace'"); $student=mysql_fetch_array($dotaz); //vložení výsledku dotazu do pole $typ_Studia=$student[0]; if($typ_Studia==0){$pozadi='../img/bp_sablona.pdf';} else {$pozadi='../img/ap_sablona.pdf';}
Proces založení nového dokumentu a implementace této šablony pak vypadá následovně. $pdf=& new FPDI(); $pagecount = $pdf->setSourceFile($pozadi); $tplidx = $pdf->importPage(1, '/MediaBox'); $pdf->AddPage(); $pdf->useTemplate($tplidx, 0, 0, 0);
//hlavní konstruktor //zdrojový soubor šablony //načtení strany 1 ze šablony //vytvoření nové strany //aplikace šablony
6.3.2 Vložení vlastního hodnocení z databáze Postup výběru všech potřebných elementů, které jsou nezbytné pro vygenerování PDF, je následující. Nejprve potřebujeme rozlišit posudek, který chce učitel vygenerovat, což probíhá pomocí identifikačního čísla posudku. Ten je posílán z předchozí stránky přímo v URL, tj. jako bychom posílali formulář s metodou GET. Zápis takového kódu v HTML a získání čísla posudku v PHP vypadá v našem případě následovně. //kde x je číslo posudku z předchozí stránky $id_Posudku=$_GET['id_ Posudku‘];
Poté je nutné zjistit id rezervace, což je provedeno snadno pomocí následujícího skriptu, který zároveň slouží k načtení hodnocení posudku. 46
$dotaz1=mysql_query("SELECT * FROM Posudek WHERE id_ Posudku =$id_ Posudku "); $posudek=mysql_fetch_array($dotaz1); $id_Rezervace=$posudek[1]; //uložení id rezervace do proměnné
Dalším krokem je načtení zbývajících údajů pro vygenerování posudku, těmi jsou jméno vedoucího, finální název práce a jméno studenta. Pro zjištění identifikačního čísla učitele je využito sessions, do kterých je tato hodnota uložena automaticky po přihlášení učitele. $dotaz=mysql_query("SELECT CONCAT(jmeno,' ',prijmeni),typ_Studia,finalni_Nazev FROM Student s JOIN Rezervace_Tematu rt ON s.id_Studenta=rt.id_Studenta WHERE id_Rezervace='$id_Rezervace'"); $student=mysql_fetch_array($dotaz); $id_Ucitele=$_SESSION['id']; $dotaz2=mysql_query("SELECT CONCAT(tituly_Pred,' ',jmeno,' ',prijmeni,' ',tituly_Za) FROM Ucitel WHERE id_Ucitele=$id_Ucitele"); $ucitel=mysql_fetch_array($dotaz2);
Tímto jsou všechny potřebné prvky pro vygenerování dokumentu načteny a na PDF je aplikována šablona vzhledu. Pro dohotovení zbývá jen „natisknutí“ načtených hodnot do výsledného dokumentu. 6.3.3 Formátování vkládaných textů Po aplikaci vzhledové šablony a načtení dat z databáze nás od výsledného dokumentu již dělí pouze jeden drobný krok. „Natisknout“ na dokument údaje na správné pozice podle šablony. Stejně jako u aplikace šablony musíme i zde rozlišovat, jestli je generován posudek AP nebo BP. Způsob tohoto rozpoznání již sice známe (viz. kapitola 6.3.1), ale vzhledem k rozdílnému rozložení obou formulářů musíme tento postup aplikovat i na jednotlivé buňky textu vkládané do PDF. Vzhledem k tomu, že jsou veškeré pozice u obou formulářů rozdílné, jeví se jako ideální způsob použití jednoduché podmínky. if($typ_Studia==0){ else {
… …
} }
//blok vkládání buněk pro posudek BP //blok vkládání buněk pro posudek AP
Toto rozlišení je pak vloženo ihned za vložení šablony posudku. V obou blocích jsou identicky vyplňovány všechny buňky daného posudku, ovšem s rozdílnými pozicemi. Pro zjednodušení vyplňování formuláře je pak ještě užita tato jednoduchá funkce, která
47
vrací hodnotu pozice na ose x, pro číselná hodnocení jednotlivých dílčích bodových hodnot. function pozice($x){ //funkce vrací pozici osy x na základě vložené hodnoty switch ($x) { case '1': return 92; break; case '2': return 100; break; case '3': return 107; break; case '4': return 114; break; }}
Vyplňování pak probíhá pro každou buňku zvlášť, přičemž pozice na ose y se liší pro každou vkládanou hodnotu. Následující skript pak ukazuje konkrétní příklad, který vyplní buňku týkající se obsahu bakalářské práce, konkrétně stupeň splnění cíle. $cil=$posudek[5]; //uložení prvku z pole posudek do proměnné cil $pdf->setXY(pozice($cil),95); //nastavení pozice tisku $pdf->Cell(4,4,$symbol,1,0,'C'); //vložení proměnné symbolu do buňky
Pro tisk samotného prvku do buňky jsem použil u všech buněk proměnnou, což značně usnadní práci, kdybychom v budoucnu chtěli změnit symbol vkládaný na všechny pozice. Po vyplnění všech buněk je potřeba „natisknout“ ještě druhou stranu posudku, kterou tvoří připomínky. Pokud byly do posudku vloženy, jsou vypsány na druhou stranu dokumentu, jak ukazuje následující kód. $pripominky=$posudek[19]; $nadpis=“Připomínky a otázky, vyžadující doplnění:“; if (strlen($pripominky)>1){ //zjišťování délky řetězce $pdf->AddPage(); //přidání nové strany $pdf->SetFont('Times','B',10); //nastaví tučné písmo velikosti 10 $pdf->Cell(40,4, $nadpis,1,1,'L'); //vytištění nadpisu $pdf->SetFont('Times','',12); //vrátí zpět běžné písmo velikosti 12 $pdf->Write(4,$pripominky);
}
K finalizaci dokumentu zbývá pouze výběr odeslání výstupu. To je provedeno pomocí následujícího příkazu, který přiřadí dokumentu jméno na základě zadaného řetězce a přiřadí mu cíl na základě zvoleného parametru. $pdf->Output(“Posudek_“.$id_Posudku,'D');
//ukončení a odeslání dokumentu
Tento konkrétní příkaz odešle dokument prohlížeči s požadavkem vynuceného stažení a názvem souboru Posudek_id.pdf, kde id značí jednoznačný identifikátor posudku. 48
6.4 Přehled hodnocení pro daného učitele U každého posudku má učitel možnost nastavit parametr, který určuje, zda daná práce již byla ohodnocena (viz. Obrázek 5.1.b). Tento parametr má tři užitečné funkce. $id_Ucitele=$_SESSION['id']; $dotaz=mysql_query("SELECT finalni_Nazev,CONCAT(jmeno,' ',prijmeni) AS cele_jmeno,rt.id_Studenta,rt.id_Rezervace,viditelnost,id_Posudku FROM Rezervace_Tematu rt JOIN Posudek p ON rt.id_Rezervace=p.id_Rezervace JOIN Student s ON rt.id_Studenta=s.id_Studenta JOIN Nabidka_Temat nt ON rt.id_Tematu=nt.id_Tematu WHERE id_Ucitele='$id_Ucitele' AND odevzdana=1"); //výběr odevzdaných prací
V prvé řadě se jedná o zobrazení v kategorii odevzdaných prací. Po změně tohoto atributu na „ohodnocená práce“ daná práce v tomto seznamu, zobrazuje učiteli jako ohodnocená. Což mu značně vylepšuje přehled o jeho pracích, které již ohodnotil, a které ještě ne. Samozřejmě nechybí možnost odfiltrování ohodnocených, respektive neohodnocených prací. Implicitně jsou ovšem zobrazeny všechny práce. Takto vypadá skript pro výpis odevzdaných prací, který je vypisován v cyklu a zobrazuje pro každou práci, zda již byla ohodnocena. $pocet_radku = mysql_num_rows($dotaz); for ($i = 0; $i < $pocet_radku; $i++) { $odevzdana= mysql_fetch_array($dotaz); echo ('
Ve druhé řadě je tento parametr určitým bezpečnostním prvkem, zamezuje totiž vygenerování prázdného dokumentu PDF. Možnost vygenerování dokumentu je tedy podmíněna faktem, že práce již byla učitelem kompletně ohodnocena. To je znázorněno v pokračování předchozího cyklu. if ($odevzdana==1){ echo ("
A v posledním případě zajišťuje učiteli určitou kontrolu, protože ho nelze změnit bez správného vyplnění všech požadovaných položek. 49
7
Vlastní přínos
V průběhu vlastní tvorby systému jsem se potýkal s mnoha překážkami. Nejvíce jich souviselo především s generováním výsledných dokumentů z posudků. Prvním velkým problémem, který jsem musel řešit, byla implementace šablony výsledného vzhledu. Původně jsem měl v plánu využít naskenovaného dokumentu, který bych do PDF vkládal na pozadí jako obrázek. Výsledná kvalita ovšem nebyla uspokojující, ani při značné velikosti souboru. Po objevu rozšiřující třídy FPDI byl ovšem problém vyřešen nad očekávání. Tato třída totiž rozšiřuje použití základní třídy o možnost použití PDF jako šablony. Velikost šablony, vytvořené převodem z dokumentu Word do PDF, nedosahuje ani 50 kB. Další problém, který jsem musel vyřešit, byl tisk českých textů. Výrobu fontu, který by třída FPDF dokázala použít, a který by podporoval české znaky, jsem dokončil úspěšně. Nepodařilo se mi však vytvoření funkčního fontu typu 1 z původního TrueType. Poslední překážku pak představovalo nastavení lokací buněk pro vyplnění formuláře posudku. Ve skutečnosti jako největší potíž figuroval v tomto případě čas. Precizní centrování veškerých textů ve všech dokumentech, totiž zabralo několik hodin. Myslím si, že jsem současné systémy spojil úspěšně. Podařilo se mi zachovat většinu jejich předchozí funkčnosti, kterou jsem v mnoha ohledech ještě vylepšil. Díky práci na systému jsem si zdokonalil a osvěžil mnoho znalostí, především tvorbu PHP skriptů, SQL dotazů, ale také proces unifikovaného vývoje aplikací. Velice užitečná se prokázala také moje předchozí znalost třídy FPDF, kterou jsem si při této práci ještě více rozvinul. Nadto mě práce na praktické části vůbec nenudila a pokaždé když se mi podařilo něco vyřešit, byť jen dílčí problém, jsem měl upřímnou radost.
50
8
Závěr
Úkolem mojí práce byl reengineering systému pro tvorbu posudků bakalářských a absolventských prací. Tento systém měl být implementován do aktuálně provozovaného systému pro tvorbu a editaci bakalářských a absolventských prací. Vzhledem k mojí práci v předmětu Projekt, kde jsem systém správy témat AP a BP měl sjednotit s rezervačním systémem konzultačních hodin, probíhala moje práce na celém systému unifikovaně. Teoretická část této práce je zaměřena především na analýzu současného stavu systémů (systém správy témat AP a BP; rezervační systém konzultací) a popisu jejich funkčnosti. Pokusil jsem se formulovat jejich silné a slabé stránky, na nichž jsem chtěl postavit tvorbu nového informačního systému. Dále jsem se v teorii zabýval metodikou správného návrhu a vývoje databáze. V závěrečné kapitole teoretické části jsem popisoval třídu FPDF, kterou nový IS systém využívá ke generování PDF dokumentů posudků, respektive zadávacích formulářů AP a BP. V praktické části jsem se zaměřil na proces analýzy a návrhu nového informačního systému. Kde jsem na základě unifikovaného procesu vývoje aplikací naznačil proces vytváření systému pomocí UML diagramů. V poslední kapitole jsem popsal proces samotné tvorby a implementace modulu pro správu posudků AP a BP. Výsledky mé práce jsou v této kapitole doplněny o úryvky skriptů, které byly využity během tvorby systému. U každého úryvku kódu jsem se pokusil stručně formulovat, jakým způsobem daný kód funguje, a jaký je jeho účel. Vzhledem k tomu, že jsem v praktické části tvorby systému nevyužil prakticky žádných kódů z původních systémů, byla tato část značně časově náročná. Také z tohoto důvodu se mi nepodařilo dodělat některé aspekty systémů podle původních předpokladů. Nejvíce patrné je to především na vzhledu celého systému. Ten ovšem nebyl zdaleka tak prioritní jako samotná funkčnost. Bohužel také v tomto ohledu jsem několik prvků systému nestihl realizovat. Zejména se jedná o možnost resetování zapomenutých hesel pomocí emailu, a také možnost ukládání posudků přímo na server. Míst toho jsou posudky vždy nově generovány a nabídnuty uživateli pro přímé stažení pomocí prohlížeče. Tímto způsobem bude ušetřeno mnohem více úložného prostoru a vzhledem k faktu, že se většinou jedná o dvoustránkové dokumenty, jejich generování třídou FPDF bude dostatečně rychlé a spolehlivé. Poslední problém, který se mi nepodařilo 51
vyřešit, se týkal zmenšení fontu užívaného touto třídou. Přesto se však velikost výsledného dokumentu pohybuje v řádech stovek kB, což považuji za poměrně uspokojivý výsledek. V průběhu vývoje jsem do systému zakomponoval četná vylepšení, ale bohužel jejich implementace, do mnohdy již hotového kódu, byla místy značně komplikovaná. Proto by bylo potřeba provést důkladnou optimalizaci vytvořených kódů, která by však opět zabrala mnoho času. Přesto mě již nyní napadají určitá vylepšení, která by se do systému mohla integrovat. Poměrně užitečným vylepšením by mohla být vyskakovací okna pro potvrzení smazání (např. uživatele, tématu, atd.), která by zabránila nechtěnému smazání dat. Dále stránkování u seznamu prací či konzultací, s možností nastavení individuálního počtu vypisovaných prací pro každého uživatele. A v poslední řadě by dobrým zdokonalením mohlo být přidání modulu pro zasílání soukromých zpráv.
52
9
Seznam literatury a použitých zdrojů
Tištěné publikace: [1] ARLOW, Jim, NEUSTADT, Ila. UML 2 a unifikovaný proces vývoje aplikací – Průvodce analýzou a návrhem objektově orientovaného softwaru. 2. Computer Press a.s., 2007. 568 s. ISBN 978-80-251-153-9 [2] CASTRO, Elisabeth. HTML, xHTML a CSS – Názorný průvodce tvorbou WWW stránek. 1. Brno : Computer Press a.s., 2007. 438 s. ISBN 978-80-251-1531-2 [3] CYROŇ, Miroslav. CSS – kaskádové styly: praktický manuál. 1. Grada Publishing a.s., 2005. 340 s. ISBN 80-247-1420-5 [4] KOSEK, Jiří. PHP – tvorba interaktivních internetových aplikací. 1. Grada Publishing a.s., 1999. 492 s. ISBN 80-7169-373-1 [5] LAVIN, Petr. PHP – objektově orientované: koncepty, techniky a kód. 1. Grada Publishing a.s., 2009. 224 s. ISBN 978-80-247-2137-8 [6] POKORNÝ, Jan. MySQL profesionálně – Optimalizace pro vysoký výkon. 1. Zoner press, 2009. 712 s. ISBN 978-80-7413-035-9 [7] STANÍČEK, Petr. CSS Kaskádové styly : Kompletní průvodce. 2. vyd. Brno :Computer Press, 2003. 178 s. ISBN 80-7226-872-4. Elektronické zdroje: [8] BURIÁNEK, Jan. Webový portál pro rezervaci témat bakalářských prací na VOŠIS v Praze. Praha, 2010. Bakalářská práce. Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Vyšší odborná škola informačních služeb. [9] FPDF Library : PDF generator [online]. 2001. Dostupné z WWW: . [10] Metodika tvorby webových prezentací [online]. 2007. Dostupné z WWW: . [11] MUSIL, Libor. Webová aplikace pro podporu vypsaných konzultačních hodin na VOŠIS. Praha, 2010. Bakalářská práce. Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Vyšší odborná škola informačních služeb. [12] Normalizace [online]. 2008. Dostupné z WWW: .
53
[13] PHP.net [online].2008. Session Handling. Dostupné z WWW: . [14] Teorie relačních databází – Normalizace [online]. 2007. Dostupné z WWW: . [15] W3C [online]. 2002. XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). Dostupné z WWW: . [16] ZÁBOJNÍK, Ondřej. Interval.cz [online]. 2003. Vytváření dokumentů PDF v PHP. Dostupné z WWW: . [17] ZAJÍC, Petr. Linuxsoft.cz [online]. 2005. Seriál článků o PHP. Dostupné z WWW: .
54
10 Přílohy Příloha č.1 – Terminologický slovník Artefakt – jako artefakty jsou v metodice UP označovány vstupy a výstupy projektu, např. zdrojový kód, spustitelné programy, skripty, databázové tabulky, standardy, dokumentaci apod. Bit – základní jednotka informace používaná v číslicové a výpočetní technice; 1 bit reprezentuje informaci, která může nabývat pouze dvou rozdílných stavů Byte – skupina 8 bitů CASE (Computer-Aided Software Engineering) – nástroje pro tvorbu programového vybavení pomocí počítače Cizí klíč – integritní omezení u relačních databází, které vytváří spojení mezi relacemi. Databáze – uspořádaná množina dat vztahující se k určitému tématu nebo účelu a popisující část objektivní reality Entita – cokoliv v našem okolí, co považujeme za natolik důležité, abychom tomu věnovali zvláštní pozornost a opatřili to jménem; objekt ERA (Entity Relationship Attribute) – schematický zápis k popisu a dokumentování ERA modelu, který zobrazuje jedinečně pojmenované entity, jímž přísluší jednotlivé atributy, vztahy mezi entitami jsou naznačeny linkami, které mají znázorněnu kardinalitu a parcialitu Font – sada grafických znaků, které odpovídají určitému typu písma Generalizace – česky také zobecnění; relace mezi obecnějším prvkem a prvkem přesněji specifikovaným, v níž přesněji specifikovaný prvek je zcela konzistentní s obecnějším prvkem, ale obsahuje více informací HTML (HyperText Markup Language) – hypertextový značkovací jazyk; jazyk sloužící k tvorbě www stránek Informační systém – systém, který užívá informační technologii k zachycování, přenosu, ukládání, vyhledávání, zpracování nebo zobrazování informací používaných v jednom nebo více podnikatelských procesech Integritní omezení – tvrzení vymezující korektnost databáze, stupeň souladu datového obrazu s předlohou, jsou definována na konceptuální i databázové úrovni. Instance – výskyt entity; konkrétní prvek množiny (třídy) IT (Informační Technologie) – hardware a software, který umožňuje existenci IS Kardinalita – mohutnost vztahu; omezení v počtu instancí druhé entity, které jsou v relaci s jakoukoli instancí první entity, definuje se vždy maximální a minimální kardinalita kB (kilobyte) – násobek jednotky byte; 1 kB = 1024 Bytes Konstruktor – speciální metoda tvorby nových objektů příslušné třídy, musí mít platnost třídy
55
MD5 (Message-Digest Algorithm 5) – hashovací funkce, která vytváří ze vstupních dat otisk fixní délky; malá změna na vstupu vede k velké změně výstupu MySQL – open sourcový relační databázový systém Open source – počítačový software s legálně dostupným zdrojovým kódem Parcialita – v relačních databázích označení pro povinnost či volitelnost existence vztahu PDF (Portable Document Format) – otevřený multiplatformní standard tvorby a sdílení informací vyvinutý firmou Adobe PHP (Hypertext Preprocessor) – skriptovací jazyk pro tvorbu dynamického webu Plug-in – zásuvný modul určité aplikace, který rozšiřuje její funkčnost Primární klíč – jednoznačný identifikátor v dané relaci Relační databáze – databáze vyhovující relačnímu modelu dat, který je založený na matematické teorii množin a predikátové logice a definuje způsob reprezentace dat, způsob jejich ochrany a možné operace nad daty SHA1 (Secure Hash Algorithm 1) – rozšířená hashovací funkce SQL (Structured Query Language) – deklarativní programovací jazyk určený pro tvorbu relačních databází a následnou manipulaci s daty SŘBD (Systém Řízení Báze Dat) – rozhraní mezi aplikační a datovou vrstvou Šifrování – kryptografie; nauka o metodách utajování smyslu zpráv TrueType – standard pro popis fontů vyvinutý firmou Apple Třída – výsledek abstrakce; množina prvků se shodnými atributy UML (Unified Modeling Language) – unifikovaný jazyk pro vizuální modelování systémů UP (Unified Process) – metodika využívaná pro vývoj aplikací URL (Uniform Resource Locator) – jednoznačný řetězec určený k přesné identifikaci informace na internetu USE CASE – případ užití; způsob zachycení požadavku při tvorbě systému podle UP XML (Extensible Markup Language) – rozšiřitelný značkovací jazyk pro popis logické struktury dat
56
Příloha č.2 – Seznam obrázků a tabulek: Obrázek 2.2.1 – ERA diagram systému rezervací AP a BP .......................................... 13 Obrázek 2.2.2 – ERA diagram systému pro rezervaci konzultací ................................. 14 Tabulka 3.2.2.a – Příklad 1.NF...................................................................................... 18 Tabulky 3.2.2.b – Transformace do 1.NF ...................................................................... 18 Tabulka 3.2.2.c – Příklad 2.NF ...................................................................................... 19 Tabulky 3.2.2.d – Transformace do 2.NF ...................................................................... 19 Tabulka 3.2.2.e – Příklad 3.NF ...................................................................................... 20 Tabulky 3.2.2.f – Transformace do 3.NF....................................................................... 20 Obrázek 5.1.2 – Diagram aktérů .................................................................................... 26 Obrázek 5.1.3.a – Celkový model případů užití ............................................................ 28 Obrázek 5.1.3.b – USE CASE diagram pro uživatelský přístup ................................... 29 Obrázek 5.1.3.c – USE CASE diagram správy systému ............................................... 30 Obrázek 5.1.3.d – USE CASE diagram správy posudků .............................................. 31 Obrázek 5.1.3.e – USE CASE diagram rezervace témat ............................................... 32 Obrázek 5.1.3.f – USE CASE diagram rezervace konzultací ........................................ 33 Tabulka 5.1.4.a – Příklad specifikace případu užití ...................................................... 34 Tabulka 5.1.4.b – Příklad specifikace klientského případu užití ................................... 35 Tabulka 5.1.4.c – Příklad specifikace dodavatelského případu užití ............................. 36 Obrázek 5.1.5 – Diagram aktivit.................................................................................... 37 Obrázek 5.2.1 – Fyzický datový model ......................................................................... 38 Obrázek 6 – Odevzdání práce v IS ................................................................................ 42 Obrázek 6.1.a – Tvorba posudku 1 ................................................................................ 43 Obrázek 6.1.b – Tvorba posudku 2 ............................................................................... 44
