Analýza a návrh informačního systému pro základní školu

Mendelova univerzita v Brně Provozně ekonomická fakulta

Analýza a návrh informačního systému pro základní školu Bakalářská práce

Vedoucí práce: Ing. Stratos Zerdaloglu

Zbyšek Šára

Brno 2014

Poděkování Tímto bych chtěl poděkovat vedoucímu své bakalářské práce Ing. Stratosi Zerdaloglu za jeho přístup a pomoc, které mi v průběhu tvorby práce věnoval.

Čestné prohlášení Prohlašuji, že jsem tuto práci: Analýza a návrh informačního systému pro základní školu vypracoval/a samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 21. května 2014

_______________________________

Abstract Šára, Z. Analysis and design of information system for primary school. Bachelor thesis. Brno, 2014. This thesis deals with design and realization of an information system for the primary school. The opening part of the bachelor thesis is dedicated to the theory of information systems. For the creation of analysis and design, a structured approach is used. Models are created by PowerDesigner and MySQLWorkbench software. On the basis of the created models, the information system in a form of web application is created – using CodeIgniter and Twitter Bootstrap frameworks and the database system MySQL. The ending part of the thesis contains evaluation of the suggested solution. Keywords Information system, structured analysis, CodeIgniter, Twitter Bootstrap, MySQL.

Abstrakt Šára, Z. Analýza a návrh informačního systému pro základní školu. Bakalářská práce. Brno, 2014. Tato práce se zabývá návrhem a tvorbou informačního systému pro základní školu. Úvodní část bakalářské práce je věnovaná teorii informačních systémů. Pro tvorbu analýzy a návrhu je použit strukturovaný přístup. Modely jsou vytvořeny pomocí softwaru PowerDesigner a MySQLWorkbench. Podle vzniklých modelů je vytvořen informační systém ve formě webové aplikace, za použití frameworku CodeIgniter, Twitter Bootstrap a databázového systému MySQL. Závěrečná část obsahuje zhodnocení daného řešení. Klíčová slova Informační systém, strukturovaná analýza, CodeIgniter, Twitter Bootstrap, MySQL.

Úvod a cíl práce

7

Obsah 1

2

Úvod a cíl práce 1.1

Úvod....................................................................................................................................... 10

1.2

Cíl práce................................................................................................................................ 10

Informační systém 2.1

2.1.2

Dílčí architektury.................................................................................................... 12

2.1.3

Vrstvená architektura........................................................................................... 12

Životní cyklus IS ................................................................................................................ 13

2.2.1

Etapy životního cyklu ........................................................................................... 13

2.2.2

Modely životního cyklu ........................................................................................ 14

Přístupy tvorby analýzy

16

Objektově orientovaný přístup ................................................................................... 16

3.1.1

Class diagram ........................................................................................................... 16

3.1.2

Use case diagram .................................................................................................... 16

3.1.3

Statechart diagram ................................................................................................ 16

3.2

5

Architektura IS .................................................................................................................. 11 Globální architektura ............................................................................................ 11

3.1

4

11

2.1.1

2.2

3

10

Strukturovaný přístup .................................................................................................... 16

3.2.1

Model vnějšího chování ....................................................................................... 17

3.2.2

Funkční model ......................................................................................................... 17

3.2.3

Datový model ........................................................................................................... 19

Analýza řešení

21

4.1

Popis aktuálního stavu ................................................................................................... 21

4.2

Formální specifikace ....................................................................................................... 21

4.2.1

Funkční požadavky ................................................................................................ 21

4.2.2

Nefunkční požadavky ........................................................................................... 21

Návrh řešení 5.1

22

Použité nástroje ................................................................................................................ 22

Úvod a cíl práce

5.2

Kontextový diagram ........................................................................................................ 22

5.3

Systémový diagram ......................................................................................................... 24

5.3.1

Dekompozice procesu Správa uživatelů ....................................................... 25

5.3.2

Dekompozice procesu Evidence klasifikace ................................................ 26

5.4 6

8

Entitně relační diagram ................................................................................................. 27

Implementace 6.1

29

Použité technologie ......................................................................................................... 29

6.1.1

PHP .............................................................................................................................. 29

6.1.2

CodeIgniter ............................................................................................................... 29

6.1.3

Twitter Bootstrap................................................................................................... 29

6.1.4

MySQL ......................................................................................................................... 29

6.1.5

SQL ............................................................................................................................... 30

6.2

Použité nástroje ................................................................................................................ 30

6.3

MVC ........................................................................................................................................ 30

6.4

Postup implementace ..................................................................................................... 30

6.5

Registrace účtů .................................................................................................................. 32

6.6

Přihlášení............................................................................................................................. 33

6.7

Uživatelské sekce.............................................................................................................. 34

6.7.1

Popis sekcí uživatele Žák ..................................................................................... 34

6.7.2

Popis sekcí uživatele Rodič................................................................................. 35

6.7.3

Popis sekcí uživatele Učitel ................................................................................ 36

6.7.4

Popis sekcí uživatele Vedení .............................................................................. 37

7

Zhodnocení

38

8

Závěr

39

9

Literatura

40

Úvod a cíl práce

9

Seznam obrázků Obr. 1

Bloky globální architektury Zdroj: Rybička a Talandová, 2009

11

Obr. 2

Vrstvená architektura Zdroj: Rybička a Talandová

13

Obr. 3

Model vodopád Zdroj: Management IS [online] 1995

15

Obr. 4

Model prototyp Zdroj: Management IS [online] 1995

15

Obr. 5 Ukázka kontextového diagramu Zdroj: University of Waterloo [online] 1992 – 2013

17

Obr. 6

Komponenty DFD Zdroj: wikipedia.org, [online]

18

Obr. 7

Crow’s foot notace ERD Zdroj: wikipedia.org [online]

19

Obr. 8

Kontextový diagram

22

Obr. 9

Systémový diagram

24

Obr. 10

Dekompozice procesu Správa uživatelů

26

Obr. 11

Dekompozice procesu Evidence klasifikace

27

Obr. 12

Entitně relační diagram

27

Obr. 13

Tvorba účtu žák

32

Obr. 14

Přihlašování účtů

33

Obr. 15

Stránka uživatele žák – Konečná klasifikace

34

Obr. 16

Stránka uživatele rodič – Aktuální klasifikace dítěte

35

Obr. 17

Stránka uživatele učitel – Třídy a klasifikace

36

Obr. 18

Stránka uživatele vedení – Správa tříd

37

Úvod a cíl práce

10

1 Úvod a cíl práce 1.1

Úvod

V dnešní moderní době můžeme sledovat, jak se vykonávané činnosti jednotlivců, firem nebo organizací výrazně zjednodušují díky využití elektronických informačních systémů. Informační systém může být využit k prezentování, ukládání a k dalším operacím s daty podle charakteru podniku nebo organizace. Pro správné fungování informačního systému je důležitá jeho přístupnost a uživatelská přívětivost, aby i technicky méně zdatný uživatel neměl problém se systémem pracovat a pociťoval tak zefektivnění prováděných činností. Pro bakalářskou práci byl vybrán typ organizace, kde jsou procesy jasně identifikovatelné a pevně dané. Díky tomu můžeme navržené a implementované řešení využít i v jiné organizaci stejného charakteru a je možné ho neustále udržovat a vylepšovat. Kontaktovaná základní škola nemá žádné své vlastní nebo od firmy zavedené řešení. Je zde tedy prostor pro návrh jednoduchého vlastního řešení, které daným subjektům zjednoduší každodenní práci. Práce má tedy smysl.

1.2

Cíl práce

Na základě provedené analýzy procesů v dané organizaci bude zhotoven návrh. Modely budou vytvořeny pomocí CASE nástrojů. Z vytvořených modelů strukturované analýzy bude naimplementována prvotní verze webové aplikace, která bude zhodnocena a bude spuštěna do provozu. Aplikační logika aplikace bude vytvořena pomocí PHP frameworku. Pro vylepšení uživatelské rozhranní bude využito frameworku Twitter Bootstrap a javascriptového frameworku jQuery. O veškerou režii s daty se postará databázový systém MySQL. Při implementaci aplikace budou využívány moderní přístupy. Závěr bude obsahovat zhodnocení výsledné práce.

Informační systém

11

2 Informační systém Přesná definice pojmu Informační systém neexistuje, neboť každý specialista na tuto oblast používá různou terminologii. Jednu takovou definici nabízí (Rybička a Talandová, 2009) ta za informační systém považuje soubor prvků, které jsou vzájemně propojeny vazbami. Za prvky se považuje informace, informační technologie, lidé, organizace práce, řízení chodu systému, technické prostředky a metody sloužící ke zpracování dat (Rábová, 2008). Informační technologie představují komplex technických, programových a metodických prostředků (Informační systémy, 2006, [online]).

2.1

Architektura IS

Definuje koncepci řešení postupu tvorby informačního systému. Při vývoji poskytuje určitý směr a jedná se o vhodný komunikační prostředek mezi vedením podniku a analytiky informačního systému. Architektura musí být názorná, jasná, jednoduchá. Existuje několik pohledů na architekturu. Do takzvaného klasického pohledu patří globální a dílčí architektura a do moderního pohledu patří například vrstvená architektura, architektura 4+1 pohledů. Architekturu je možné během vývoje neustále upravovat a přizpůsobovat měnícím se požadavkům při zachování koncepce (Danel, 2011, [online]). 2.1.1

Globální architektura

Hrubý návrh celého IS/ICT. Zobrazující jednotlivé části IS/ICT a jejich vazby. Skládá se z bloků a každý blok obsahuje soubor funkcí a služeb, které slouží k podpoře podnikových procesů. Struktura architektury se skládá ze tří vertikálních úrovní, které znázorňují obvyklé členění managementu (Obr. 1). Horizontální úroveň představuje jednotlivé podnikové útvary (Voříšek, 2007).

Obr. 1 Bloky globální architektury Zdroj: Rybička a Talandová, 2009

 TPS (Transaction Processing System) – aplikace určené k operativnímu řízení podniku. Operace charakterizuje charakter podnikových činností. Nejde-

Informační systém

 

 

12

tailnější část globální architektury. Tento blok pořizuje a aktualizuje data pro další vrstvy architektury (Rábová, 2008). MIS (Management Information System) – blok určený pro taktické řízení podniku (Rábová, 2008). V této úrovni se provádí především analýzy a zpracovávají se přehledy (Rybička a Talandová, 2009). EIS (Executive Information System) – obsahuje aplikace určené ke strategickému řízení podniku a pro podporu vrcholového managementu. Tento blok využívá data poskytované předchozími vrstvami i data z externích zdrojů. Zaměřuje se na delší časový úsek do minulosti i budoucnosti a vytváří komplexní analýzy (Rybička a Talandová, 2009). OIS (Office Information System) – aplikace zaměřené na podporu kancelářských prací a týmové práce (Rábová, 2008). EDI (Electronic Data Interchange) – blok určený pro elektronickou výměnu strukturovaných dat mezi systémy (Rybička a Talandová, 2009).

2.1.2

Dílčí architektury

Prohlubuje návrh systému do detailu z různých pohledů jako například softwaru, hardwaru atd. (Rábová, 2008).  Procesní – zachycuje klíčové procesy, které představují rozhodující vazby podniku s okolím (Rábová, 2008). Pro tento účel se využívá kontextový diagram (Rybička a Talandová, 2009).  Funkční – navazuje na procesní architekturu. Provádí rozklad základních funkcí do dílčích funkčních celků (Rybička a Talandová, 2009). Nástrojem funkční architektury je DFD (Rábová, 2008).  Datová – definuje použitou datovou základnu. Při modelování je použit ERD, který zobrazuje entity a vztahy mezi nimi (Rybička a Talandová, 2009).  Softwarová – určuje, z jakých softwarových komponent se informační systém bude skládat (Rábová, 2008).  Hardwarová – specifikuje technické vybavení informačního systému. Většinou jde o textový popis parametrů a rozmístění jednotlivých hardwarových součástí (Rábová, 2008).  Technologická – propojuje předchozí dílčí architektury a určuje technologické řešení aplikace (Rábová, 2008). 2.1.3

Vrstvená architektura

Využívaná především u webových projektů. Tato architektura se skládá z několika vrstev.  Prezentační vrstva – uživatelské rozhraní. V prostředí webu jde o vzhled a ovládání. Zajištěno například jazyky CSS, JavaScript. Někdy označován jako frontend (Rybička a Talandová, 2009).  Aplikační vrstva – nachází se zde funkcionalita systému (logika). Může být vytvořena například jazyky Perl, PHP nebo pomocí procedur uložených v databázi (Danel, 2011, [online]).

Informační systém

13

 Datová vrstva – provádí databázové operace, poskytuje práci s datovým modelem a se strukturami v databázi. Označuje se též jako backend (Rybička a Talandová, 2009).

Obr. 2 Vrstvená architektura Zdroj: Rybička a Talandová

2.2

Životní cyklus IS

Podle (Rábové, 2008) se jedná o proces tvorby softwarového produktu. Tento proces započne myšlenkou něco řešit nebo vylepšovat a končí likvidací vytvořeného produktu. 2.2.1

Etapy životního cyklu

Životní cyklus vývoje se skládá z několika etap (Rábová, 2008). 1.

Specifikace problému – zpracování úvodní studie, která obsahuje formální a neformální specifikace. Formální specifikace je popis požadavků na vyvíjený systém (Informační systémy, 2006, [online]). Dále může obsahovat časovou a nákladovou náročnost. Součástí studie jsou také technické specifikace na systém. Tento dokument se předkládá nejčastěji při výběrovém řízení (Rybička a Talandová, 2009).

2.

Analýza – hlavní náplní této etapy je modelování, výstupem mohou být modely strukturované analýzy nebo modely objektové analýzy. U strukturované analýzy je to model funkční a datový, v objektové analýze je to diagram UML. Tyto modely slouží ke komunikaci mezi zadavateli a analytiky (Informační systémy, 2006, [online]). Návrh – tato část je výsledkem analýzy systému. Modely z předchozích etap se dekomponují až na úroveň, kdy je možné systém implementovat (Rábová, 2008). Skládá se ze dvou fází, globální a detailní. Globální návrh je prováděn na logické úrovni, je tedy nezávislý na určité hardwarové a softwarové technologii. V detailním návrhu se přechází z logického návrhu k fyzickému, to

3.

Informační systém

14

znamená, že už jsou navrženy konkrétní hardwarové a softwarové části systému. U menších projektů dochází ke spojení detailního návrhu s globálním návrhem (Rybička a Talandová, 2009). 4.

5.

6.

Implementace – realizace informačního systému podle vzniklých podkladů z předchozích etap vývoje. V této fázi jsou použita testovací data, která jsou testována na správnost poskytovaných výsledků a jejich rychlost. Průběh tvorby by měl být doprovázen dokumentací pro provoz a dodatečné úpravy a opravy (Rybička a Talandová, 2009). Zavedení, testování – zahrnuje instalaci, konfiguraci, testování hardwaru a softwaru potřebného pro provoz systému. Součástí je také konverze dat a pořízení dat, které jsou prozatím v jiné než elektronické podobě. Vše funguje ve zkušebním provozu. Po ověření systému a provedení testů je implementace považována za dokončenou (Rábová, 2008). Provoz, údržba, rozvoj – v průběhu provozování systému dochází k údržbě hardwaru a softwaru. Hardwarová údržba probíhá výměnou nového zařízení. Softwarová údržba se koná při opravě nějaké nalezené chyby nebo při modifikaci systému (Rybička a Talandová, 2009).

2.2.2

Modely životního cyklu

V praktickém životě není u etap životního cyklu dodržováno striktní pořadí. Některé fáze mohou být sloučené nebo se opakovat. Existuje několik modelů vývoje informačního systému. V praxi se nepoužívá pouze jedna metodika, ale většinou kombinace podle charakteru projektu (Rybička a Talandová, 2009).  Model vodopád má své jednotlivé fáze vývoje odděleny (Obr. 3). Postup do další fáze nastává až po úplném a úspěšném vyřešení předchozí fáze. Tato metodika je poměrně rychlá a levná pokud se nevyskytnou problémy. Vhodné je tedy tento postup aplikovat při návrhu systému, kde je jasný způsob jeho řešení. Pro většinu reálných projektů je však tento přístup nevhodný, kvůli přesně definovaným krokům. Případné změny, opravy v systému jsou vysoce nákladné (Rybička a Talandová, 2009).

Informační systém

15

Obr. 3 Model vodopád Zdroj: Management IS [online] 1995

 Model prototyp smyslem tohoto modelu je zrychlená tvorba systému, kdy je řešena pouze část systému v podobě prototypu (Obr. 4). Tento prototyp slouží jako komunikační nástroj mezi realizátorem a zadávajícím. Tento model je vhodný v takových případech, kde chceme obsáhnout co nejpřesněji požadavky na systém a vyžadujeme rychlou možnost úpravy systému. U rozsáhlých systémů se tato metoda nepoužívá, kvůli narůstajícím počtům vytvářených prototypů se tedy stává poměrně ekonomicky nákladnou (Rybička a Talandová, 2009).

Obr. 4 Model prototyp Zdroj: Management IS [online] 1995

Přístupy tvorby analýzy

16

3 Přístupy tvorby analýzy 3.1

Objektově orientovaný přístup

Přístup založený na objektech. Objekt jako struktura, která má vlastnosti (atributy) a chování (metody). Z pohledu objektově orientovaného je informační systém chápán jako množina spolupracujících objektů. Modely vytváříme pomocí nejrozšířenějšího nástroje UML (Unified Modeling Language). UML nabízí k popisu několik typů diagramů. Jednotlivé typy odpovídají pohledům na modelovaný systém (Rábová, 2008).  Statický pohled o Class diagram o Object diagram  Dynamický pohled o Use case diagram o Statechart diagram  Pohled uživatele  Pohled technologický 3.1.1

Class diagram

Představuje statický pohled na systém. Zachycuje všechny třídy objektů, týkajícího se daného systému a vzájemné vztahy. Třída zachycuje atributy a metody. Jednotlivé atributy a metody mají nastavenou viditelnost. 3.1.2

Use case diagram

Vytvářený v prvních fázích analýzy. Účelem je znázornit hranice mezi vyvíjeným systémem a jeho okolím. Z diagramu poznáme, které entity budou systém využívat a jaké funkce bude daný systém plnit. Diagram se skládá ze dvou základních prvků.  Aktor – externí entita, která komunikuje s daným systémem.  Případy užití – scénáře způsobů použití systému 3.1.3

Statechart diagram

Zachycuje stavy objektu v průběhu životního cyklu systému. Zobrazuje počáteční, koncové stavy a také stavy do, kterých se objekt může dostat. Ke změnám dochází po určitém časovém úseku nebo při provedení nějaké operace (Danel, 2011 [online]).

3.2

Strukturovaný přístup

Pohlíží na systém ze dvou různých pohledů:  z pohledu funkcí  z pohledu dat

Přístupy tvorby analýzy

17

Výsledkem jsou grafické diagramy (modely), popisující funkce a strukturu dat. Podle (Kajzar a Polášek, 2003) je můžeme dělit na Statické modely reality a Modely dynamiky systému.  Statické modely reality o Diagram funkční struktury systému o Datový model – ERD o Datový slovník  Modely dynamiky systému o Modely vnějšího chování o Diagram datových toků – DFD o Model řízení – Stavový diagram 3.2.1

Model vnějšího chování

Výchozí model při modelování informačního systému. Slouží k znázornění interakce mezi uvažovaným systémem a externími subjekty. Cílem je zachytit vnější toky dat. Výsledkem je kontextový diagram (Obr. 5) obsahující terminátory (subjekty) a jeden hlavní proces reprezentující celý systém bez vnitřního rozboru (Enterprise Architect, 2013, [online]). Vnějšími entitami mohou být lidé, organizace nebo jiné informační systémy (Kajzar a Polášek, 2003). Součástí diagramu je slovní popis jednotlivých entit a slovní popis datových toků.

Obr. 5 Ukázka kontextového diagramu Zdroj: University of Waterloo [online] 1992 – 2013

3.2.2

Funkční model

Určený k podrobnému znázornění datových toků. Zobrazuje způsob, jakým jsou informace zpracovávány a ukládány v informačním systému. Účelem funkčního modelu je provést rozklad funkčnosti systému. Rozklad provádíme podle principu

Přístupy tvorby analýzy

18

shora dolů, kde se snažíme rozložit proces na více dílčích procesů. Nejvyšší úroveň může představovat náš již vytvořený kontextový diagram, který obsahuje jeden hlavní proces. Další nižší úrovně rozkladu obsahuje detailnější popis procesů systému. U DFD existuje několik notací záznamu, nejčastější se používá DeMarcova nebo Yordanova forma. (Danel, 2011, [online]). Data Flow diagramy jsou tvořené čtyřmi základními komponentami (Obr. 6).  Proces – představuje souhrn činností transformující vstupy na požadované výstupy (Rábová, 2008). Procesy lze dělit na datové a řídící (Kajzar a Polášek, 2003).  Terminátor – externí entity komunikující se systémem, nacházejí se na vnější straně systému. Může se jednat o další systém, lidi, organizaci (Enterprise Architect, 2013, [online]).  Sklad – využívá se ke sdílení dat mezi procesy, které neprobíhají zároveň. Reprezentuje data v klidovém stavu (Enterprise Architect, 2013, [online]). Data do a ze skladu musí vždy procházet procesem. Může se jednat o soubor, databázi atd. (Kajzar a Polášek, 2003).  Tok – představuje přesun dat mezi procesem a skladem. Reprezentuje data v dynamickém stavu (Enterprise Architect, 2013, [online]). Tok směřující z procesu do datastoru reprezentuje modifikaci dat (insert, update, delete) v opačném případě představuje (select). Datový tok může vyjadřovat, také pohyb zboží, materiálu (Kajzar a Polášek, 2003).

Obr. 6 Komponenty DFD Zdroj: wikipedia.org, [online]

Přístupy tvorby analýzy

3.2.3

19

Datový model

Slouží k modelování datové struktury informačního systému. Výstupem je ERD (Entity Relationship Diagram). Cílem ERD je zachytit všechna data ukládaná do databáze a vyjádřit jejich vzájemné vztahy. Využívá se opět několik různých notací znázornění. Mezi nejpoužívanější patří Crow’s Foot (Obr. 7). Notace Crow’s foot má následující výhody:  Srozumitelné definování kardinality  Řešena notace povinného vztahu vyjádřená použitím svislé čáry a volitelnost znázorněná prázdnou kružnicí (Wikipedia.org, [online]).

Obr. 7 Crow’s foot notace ERD Zdroj: wikipedia.org [online]

ERD obsahuje tyto prvky:  Entity – každý objekt, o kterém má být uchovávaná informace ve vyvíjeném IS. Například osoba, zboží, firma.  Atributy – prvky přiřazující jednotlivým entitám hodnotu a vyjadřují tím vlastnosti entit. o Primární klíč – atribut sloužící k jednoznačné identifikaci entit. Musí být v množině entit právě jeden. o Cizí klíč – slouží k určení vazeb mezi entitami. Příklad: Entita osoba obsahující cizí klíč id_adresy a id_adresy je primárním klíčem tabulky adresy. o Alternativní klíč – slouží k jednoznačné identifikaci entit, přitom není zvolen primárním klíčem. Příklad: Entita osoba se dá jednoznačně identifikovat nejen podle primárního klíče id_osoba, ale také podle alternativního klíče rodné číslo (Kajzar a Polášek, 2003).  Vztah – vazba mezi dvěma nebo více entitami (Lacko, 2003).  Kardinalita vztahu – počet entit vstupující do vztahu. o Kardinalita 1:1 – jedna entita množiny je ve vztahu s jednou entitou druhé množiny entit. Příklad: Osoba má právě jeden občanský průkaz. o Kardinalita 1:N – jedna entita množiny je ve vztahu s několika entitami druhé množiny entit. Příklad: Faktura má několik položek. o Kardinalita M:N – více entit množiny je ve vztahu s více entitami množiny druhé. Příklad: Uživatel může mít jednu nebo více rolí a jednu roli má více uživatelů.

Přístupy tvorby analýzy

20

 Parcialita vztahu – povinnost nebo volitelnost vztahu (Danel, 2011). o Parcialita volitelná – k výskytu entity z první množiny může a nemusí existovat výskyt entity z druhé množiny. o Parcialita povinná – k výskytu entity z první množiny musí vždy existovat alespoň jeden výskyt entity z druhé množiny.

Analýza řešení

21

4 Analýza řešení 4.1

Popis aktuálního stavu

Při konzultaci s vedením jevišovské základní školy mi bylo sděleno, že škola využívá systém na vedení hospodářství školy, inventarizaci majetku. V těchto oblastech si tedy nepřejí žádné zásahy. Navrhl jsem jim tedy vlastní řešení, ke kterému neměli žádné výhrady. Primárními funkcemi systému tedy bude možnost komunikace mezi subjekty pracující se systémem, evidence uživatelských údajů subjektů systému, práce s klasifikací, administrace období. Výpočetní technika se nachází v několika specializovaných učebnách, ředitelně a ve sborovně. Klasické třídy jsou vyřešeny přenosnými laptopy a v současnosti jsou možné pokrýt dvě třetiny všech tříd. Do budoucna by mělo přibýt šest laptopů a tabletů. Škola je celá pokrytá bezdrátovým připojením k internetu. Podle těchto informací bude vytvořena paleta funkcí, které budou využitelné a budou korespondovat se současným stavem vybavení školy.

4.2

Formální specifikace

Detailnější rozbor požadavků. Skládá se z funkčních a nefunkční požadavků. Pod pojmem funkční požadavky si můžeme představit popis toho co má systém umět a pojem nefunkční požadavky znamenají nároky na řešení (Rábová, 2008). 4.2.1

Funkční požadavky

IS bude umožňovat:  Vytvářet profily žáků, rodičů a učitelů  Evidenci učitelů a vedení  Evidenci jednotlivých tříd a jejich žáky  Evidenci rodičů  Komunikaci vedení s ostatními subjekty pomocí vývěsky  Komunikaci mezi učitelem a žáky všech tříd pomocí třídní nástěnky  Emailovou komunikaci mezi subjekty  Spravovat aktuální a konečnou klasifikaci studenta  Spravovat neomluvené a omluvené absence  Administraci období a tvorbu tříd  Komunikaci s autorem aplikace určená pro budoucí návrhy a opravy chyb 4.2.2

Nefunkční požadavky

 Uživatelská stránka informačního systému bude implementován pomocí frameworku Twitter Bootstrap a javascriptové knihovny jQuery  Aplikační logika bude vytvořena pomocí PHP frameworku Codeigniter  Pro práci s daty bude využit databázový systém MySQL

Návrh řešení

22

5 Návrh řešení 5.1

Použité nástroje  Tvorba kontextového a systémového diagramu byla provedena pomocí softwaru určený pro návrh softwaru s podporou standardů UML, SysML, ERD, DFD, BPMN Visual Paradigm (visual-paradigm.com, [online]). Byla použita metodika Gane and Sarson.  Entitně relační diagram byl modelován za pomocí MySQL Workbench (dev.mysql.com, [online]). Nabízí vynikající uživatelské rozhraní, možnost exportu do obrázkových i dokumentových formátů. Za největší výhodu považuju, možnost synchronizování namodelované databáze s databázovým systémem.

5.2

Obr. 8

Kontextový diagram

Kontextový diagram

Navržený kontextový diagram obsahuje 4 terminátory (externí entity) a jeden hlavní proces reprezentující celý systém (Obr. 8). Entity vnitřní, které jsou součástí organizace, jsou zastoupeny entitami Učitel a Vedení. Mezi entity vnější, které přistupují do systému mimo organizaci, patří Rodič a Žák. Entity s hlavním procesem

Návrh řešení

23

jsou spojené datovým tokem. Veškeré datové toky jsou vyobrazené v daném kontextovém diagramu. Žák: Osoba, která se na základní škole vzdělává. Žák pomocí systému sleduje svou aktuální i konečnou klasifikaci a absenci, kterou si, ale sám nemůže omluvit. Dále udržuje kontakt s děním na škole ve formě vývěsky a se svou třídou pomocí třídní nástěnky. Může si najít kontakt na kohokoliv v systému a odeslat mu emailovou zprávu. Rodič: Entita představující zákonného zástupce dítěte navštěvující danou školu. Rodič má umožněné sledovat aktuální a konečnou klasifikaci svých dětí spolu s absencí, kterou také omlouvá. Dále má umožněno najít si kontakt na kteroukoliv osobu školy a poslat jí emailovou zprávu. O dění na škole se dozvídá přes vývěsku. Učitel: Osoba provádějící výukový proces na škole. Učitel v systému zadává průběžnou i konečnou klasifikaci. Dále zadává déle neomluvenou absenci do systému a kontroluje omluvenky. Udržuje kontakt se svými žáky pomocí třídní nástěnky. Komukoliv může poslat emailovou zprávu. Vedení: Entita představující osobu, která provádí nejen výuku, ale také veškerou další agendu spojenou s oblastí školství. Systém této osobě umožňuje stejné funkce, které má entita učitel, ale také správu nástěnky, období, tvorbu účtu.

Návrh řešení

5.3

Obr. 9

Systémový diagram

Systémový diagram

24

Návrh řešení

25

Systémový diagram vzniknul dekompozicí hlavního procesu IS ZSJEVISOVICE (Obr. 9). Tato dekomponovaná úroveň obsahuje 7 dílčích procesů Správa uživatelů, Evidence klasifikace, Evidence absence, Správa tříd, Evidence třídních příspěvků, Evidence příspěvků vývěsky, Správa období a 8 datastorů Třídy, Uživatelé, Příspěvky třídy, Období, Příspěvky vývěska, Známky, Konečné známky, Absence (Obr. 9). Správa uživatelů obstarává žádosti externích entit na úpravu a výpis osobních údajů uživatele, tyto údaje ukládá nebo získává z datastoru Uživatelé. Dále vytváří uživatelské účty pro žáky, rodiče a učitele a ukládá do datastoru Uživatelé. Údaje žáků jsou také uloženy do datastoru Třídy. Obstarává přihlášení do systému. Evidence klasifikace uchovává průběžnou i konečnou klasifikaci zadanou učitelem. Záznamy klasifikace zpracovává podle požadavku učitele. Evidované záznamy jsou uložené v datastoru Konečné známky a Známky. Žákům a rodičům umožňuje náhled průběžné klasifikace, která je vložená v aktuálním období. Data o aktuálním období získává z datastoru Období. Žákům umožňuje nahlédnout do konečné klasifikace kteréhokoliv období. Správa tříd je proces, který zpracovává požadavek vedení na tvorbu a úpravy tříd, vytvořené třídy se ukládají do datastoru s názvem Třídy. Evidence třídních příspěvků eviduje třídní příspěvky vytvořené učiteli a žáky. Umožňuje veškeré možné úpravy s příspěvky a využívá k tomu datastor Příspěvky třídy. Zajišťuje zobrazení třídních příspěvků vytvořené v aktuálním období. Data o aktuálním období získává z datastoru Období. Správa období je proces zpracovávající požadavek vedení na vytvoření aktuálního období. Dané záznamy se ukládají do datastoru Období. Evidence příspěvků vývěsky eviduje příspěvky hlavní vývěsky vytvořené vedením, které ukládá do datastoru Příspěvky vývěska. Umožňuje úpravy i odstranění evidovaných příspěvků. Stará se o zobrazení příspěvku aktuálního období ostatním subjektům využívající systém. Informace o aktuálním období přebírá z datastoru Období. Evidence absence uchovává neomluvenou absenci zadanou učitelem a omluvenou absenci rodičem aktuálního období. Evidované záznamy jsou uložené v datastoru Absence. Žákům je umožněn pouze náhled. Rodič jako jediný má pravomoc omluvit neomluvené hodiny svého dítěte. Učitel má možnost výpisu omluvené absence. Data o aktuálním období získává z datastoru Období. 5.3.1

Dekompozice procesu Správa uživatelů

Dekompozicí procesu Správa uživatelů vznikly čtyři procesy Tvorba účtu, Přihlášení účtu, Evidence účtu, Editace účtu. Dekomponovaná úroveň spolupracuje pouze s jedním datastorem Uživatelé. Tvorba účtu je proces, který obstarává tvorbu uživatelských účtů systému. Vytvořit účet je umožněno rodičům a učiteli. V případě, že má rodič vytvořen účet již nějakou dobu a další potomek nastupuje do školy, opět vytváří účet rodič za žáka. Žák je přiřazen k již existujícímu profilu daného rodiče. Veškerá data jsou při tvorbě účtu zapisována do datastoru Uživatele.

Návrh řešení

26

Přihlášení účtu se stará o získání přístupu do systému. Každá entita při přihlašování zadá svoje přihlašovací údaje. Tyto údaje jsou kontrolovány z datastoru Uživatelé. Pokud zadaná data souhlasí s daty v datastoru. Uživatel je přihlášen. Evidence účtu umožňuje provádět veškeré výpisy dat o uživatelích systému. S následnou možností je kontaktovat ve formě emailové zprávy. Data získává z datastoru Uživatelé. Editace účtu provádí požadavky uživatelů na jejich úpravy osobních dat. Data jsou zapisována do datastoru Uživatelé (Obr. 10).

Obr. 10

Dekompozice procesu Správa uživatelů

5.3.2

Dekompozice procesu Evidence klasifikace

Při provedení dekompozice procesu Evidence klasifikace vznikly tři dílčí procesy Evidence známek, Evidence aktualních známek, Evidence konečných známek. Tato úroveň obsahuje také 4 datastory Uživatelé, Známky, Konečné známky, Období. Evidence známek proces umožňující vkládat aktuální známky vedením a učitelům. A entitám rodič a žák umožňuje přehledy známek, které získává z datastoru Známky. Při tomto procesu jsou využívána také data z datastoru Období pro vyfiltrování aktuálních známek. Dále data získává z datastoru Uživatelé pro získání jména zadavatele známky. Evidence aktuálních průmerných známek získává data z aktuálních známek a provádí nad nimi vážený průměr. Dále jsou tyto data použita jako vodítko pro učitele při uzavírání konečné klasifikace. Evidence konečných známek provádí vkládání konečné klasifikace vložené entitami učitel a vedení. Entitám rodič a žák je umožněno nahlédnout k datům zá-

Návrh řešení

27

věrečné klasifikace za určité období. Pracuje s datastory Konečné známky, Období (Obr. 11).

Obr. 11

5.4

Obr. 12

Dekompozice procesu Evidence klasifikace

Entitně relační diagram

Entitně relační diagram

Při tvorbě diagramu byly převzaty datastory z vytvořeného systémového diagramu. Dále byl model obohacen o několik dalších tabulek. Výsledné ERD (Obr. 12), které bylo ve finále použito k implementaci, obsahuje 14 tabulek, kterými jsou ad-

Návrh řešení

28

resy, přiřazení_role, přiřazení_dítěte, uživatelé, příspěvky_vývěsky, žáci_třídy, třídy, příspěvky_třídy, reakce_příspěvky, známky, předměty, položky_vysvědčení (známý jako datastor Konečné známky), období, absence.  Role – slouží k zařazení uživatele. Obsahuje atributy id_role jako primární klíč a povinný atribut nazev dané role.  Přiřazení_role – jedná se o spojovací tabulku mezi tabulkami role a uživatelé, důvodem je vazba M:N, protože jednu roli má více uživatelů a jeden uživatel může mít více než jednu roli. Obsahuje dva cizí klíče id_uzivatele, id_role.  Přiřazení_dítěte – spojovací tabulka pro určení rodiče a jeho dětí. Obsahuje dva cizí klíče id_uzivatele_rodic a id_uzivatele_dite.  Adresy – tabulka definující druhou část osobních údajů uživatelů. Obsahuje primární klíč id_adresy, povinné atributy mesto, cp, psc a nepovinný atribut ulice.  Uživatelé – klíčová tabulka definující osobní údaje všech uživatelů systému. Skládá se s primárního klíče id_uzivatele, nepovinných atributů obrazek, tel_kontakt, titul a s povinných atributů login, heslo, jmeno, prijmeni, email a cizí klíč id_adresy.  Příspěvky_vývěsky – pro zprávy vytvořené vedením slouží tato tabulka. Obsahuje primární klíč id_prispevek, povinné atributy datum, nadpis, text, zadavatel, cizí klíč id_uzivatele a nepovinný atribut priloha.  Žáci_třídy – spojovací tabulka mezi tabulkami uživatelé a třídy. Obsahující dva cizí klíče id_tridy a id_uzivatele.  Třídy – skládá se z primárního klíče id_tridy a povinných atributů znak a rocnik.  Známky – cílem této tabulky je ukládat záznamy průběžné klasifikace. Skládá se z primárního klíče id_znamky, s povinných atributů hodnota, vaha, datum, zadavatel a nepovinného atributu popis. Tabulka dále obsahuje cizí klíče id_predmety, id_uzivatele_zak, id_uzivatele_ucitel.  Předměty – skládá se z primárního klíče id_predmety a povinných atributů nazev a zkratka.  Položky_vysvědčení – tato tabulka slouží k ukládání hodnot výsledné klasifikace za dané pololetí. Skládá se z primárního klíče id_polozky, povinných atributů hodnota, zadavatel a cizích klíčů id_uzivatele_zak, id_uzivatele_ucitel, id_predmety, id_obdobi.  Období – obsahuje primární klíč id_obdobi. Mezi povinné atributy patří od, do definující časový interval období. Další povinné atributy jsou pololetí určující část a atribut aktivní určující právě probíhající období.  Absence – tato struktura slouží k ukládání záznamů neomluvených hodin, skládá se z primárního klíče id_absence a cizích klíčů id_uzivatele_zak, id_uzivatele_ucitel. Mezi povinné atributy patří atribut stav časové údaje od, do a atribut zadavatel. Nepovinné atributy jsou text a omluveno.

Implementace

29

6 Implementace 6.1 6.1.1

Použité technologie PHP

PHP (PHP Hypertext Preprocesor) je Open Source a jeden z nejrozšířenějších skriptovacích jazyků běžících na straně serveru. Především je určený pro tvorbu webových aplikací. Dostupná podpora pro většinu známých databází a webových serverů. Od verze 5 podporuje OOP. Lze využít na všech rozšířených systémech Linux, Solaris, Microsoft Windows, Mac OS X a další (wikipedia.com, [online]). 6.1.2

CodeIgniter

Výkonný open source PHP framework napsaný v PHP společností EllisLab. Založený na principu návrhového vzoru MVC. Určený k rychlému vývoji webových aplikací malého a středního rozsahu. Podporuje databázový návrhový vzor Active record (Myer, 2008). Mezi jeho největší výhody patří: rychlost, nulová konfigurace, obrovská komunita využívající framework a brilantně zpracovaná dokumentace (ellislab.com, [online]). 6.1.3

Twitter Bootstrap

Vyvinul Mark Otto a Jacob Thorton z Twitteru. Jedná se o balík souborů umožňující jednoduše vytvářet prvky moderního webu a tvorbu responzivního designu webu (getbootstrap.com, [online]). Bootstrap struktura obsahuje kompilované a minimalizované CSS a JS soubory, které můžeme využít v jakémkoliv webovém projektu. Použití tohoto frameworku je závislé na javascriptové knihovně jQuery (Cochran, 2012).  jQuery Form Validator - jQuery plugin, který usnadňuje kontrolu uživatelských vstupních dat ve formulářích (formvalidator.net, (online)). 6.1.4

MySQL

MySQL je relační databázový systém vycházející z deklarativního jazyka SQL v současnosti vlastněný dceřinou společností Oracle Corporation (oracle.com, [online]). Mezi výhody patří rychlost, jednoduchost a při komerčním využití nízké náklady v porovnání s konkurenčními platformami. Nejčastěji využíván u malých a středních webových projektů ve spojení se skriptovacím jazykem PHP. Důvodem výběru bylo, že je součástí balíku XAMPP (apachefriends.org, [online]).

Implementace

6.1.5

30

SQL

SQL (Structured Query Language) je neprocedurální dotazovací jazyk určený pro práci s daty v relačních databázích (Lacko, 2003). Jazyk můžeme rozdělit na dvě základní podmnožiny:  Data Definition Language (DDL) – umožňuje v databázi vytvářet, měnit a rušit tabulky, pohledy, indexy a další.  Data Manipulation Language (DML) – provádí manipulaci se záznamy, to znamená výběr, vkládání, aktualizaci, smazání (SELECT, UPDATE, INSERT, DELETE).

6.2

Použité nástroje

Celá bakalářská práce byla tvořena na platformě Mac OS X. Bylo tedy důležité vybrat takové nástroje, které tuto platformu podporují.  Na vývoj aplikace bylo použito IDE NetBeans (netbeans.org, [online]). Open source projekt s rozsáhlou uživatelskou základnou a komunitou vývojářů. Je naprogramovaný v Javě, takže je možné ho provozovat na všech známých platformách.  Pro správu obsahu databáze a tvorbu databázových dotazů jsem využil software existující pouze pro platformu Mac OS X s názvem SequelPro (sequelpro.com, [online]). Za největší výhodu považuji vynikající uživatelské rozhraní, editor pro SQL dotazy a je ke stažení zdarma. Za drobnou nevýhodu může být považováno pouze podpora MySQL a dostupnost pouze na Mac OS X.

6.3

MVC

Návrhový vzor Model-View-Controller dělí aplikaci na tři části, které spolu navzájem komunikují. Toto rozdělení představuje v praxi zjednodušení vývoje, snadnou údržbu aplikace a usnadňuje práci více lidí na projektu. Existuje také varianta Model-View-Presenter (MVP), kde Presenter zastává totožnou funkci jako Controller (doc.nette.org, [online]).  Model – obsahuje aplikační logiku a stará se o veškerou režii s daty.  View – tato vrstva má na starost prezentaci výsledků uživateli, obvykle využívá nějakou šablonu.  Controller – zpracovává požadavky uživatele a představuje prostředníka mezi modelem a view, který se stará o celkové provázání aplikace (Vrána, 2012).

6.4

Postup implementace

Prvním krokem implementace bylo nainstalování lokálního webového a databázového serveru XAMPP. Následován stažením frameworku CodeIgniter a Twitter Bo-

Implementace

31

otstrap. Soubory CodeIgniteru byly vloženy do adresáře htdocs XAMPP aplikace. Zde také byla vytvořena nová složka s názvem assets, kde se nachází všechny obrázkové, css a javascriptové soubory tedy i soubory, které byly součástí balíku Twitter Bootstrap. Poté ve složce config v adresáři application a souborech config.php a database.php byla nastavena url adresa k root adresáři dané aplikace a připojení k databázi. V souboru autoload.php bylo nastaveno automatické nahrávání knihoven database, session, upload a těchto helperů url, array, form. Po tomto kroku bylo vše nastaveno a připraveno k implementaci. Implementaci byla řešena dvěma postupy:  pokud nastal případ, kdy bylo potřeba data zobrazovat, vytvořil jsem si prvně SQL dotaz, který jsem testoval v již zmíněné aplikaci SequelPro. Poté jsem v modelu vytvořil metodu pro tento dotaz. Dále byla vytvořena v controlleru metoda, která data z modelu získala a následně data poslala do určeného view, který data prezentoval.  v případě, že byla data vkládána nebo upravována, byl postup přesně opačný. V prvním případě byl vytvořen daný view, který například obsahuje formulář. Poté příslušné metody v cotrolleru, které data zpracovávají a zajišťují provázanost views. Nakonec byla vytvořena metoda v modelu a zde byl vložen otestovaný SQL dotaz, který splňoval dané požadavky.

Implementace

6.5

Obr. 13

32

Registrace účtů

Tvorba účtu žák

Přihlašovací údaje se skládají z hesla a loginu. Heslo je tvořeno z 8. místného znakového řetězce a do databáze se ukládá zaheshované pomocí funkce SHA-1 (Baraja, 2013 [online]). Login je generován z jména a přijmení uživatele ve formátu: Login: typ_uzivatele + dva znaky jména + dva znaky přijmení Antonín Veselý (Rodič): rodicAnVe V systému lze vytvářet účty ve třech případech.  účet žák – účet žák je vytvářen v případě, že rodič je již v systému registrován z dřívějška. Účet žáka vytváří jeho zákonný zástupce. Při úspěšném odeslání formuláře dochází v databázi ke kontrole existence rodiče a následnému přiřazení daného typu uživatele, přiřazení rodiče a žákovy je přiřazena adresa rodiče a třída spolu s jeho přihlašovacími údaji. Poté jsou přihlašovací údaje zaslané na emailovou adresu rodiče (Obr. 13).  účet rodič a žák – dochází k němu v případu, že žák a jeho zákonný zástupce nemají v systému zastoupení. Rodič při registraci vyplní své osobní údaje a adresu a údaje žáka spolu s přiřazení třídy. Při úspěšném vyplnění formuláře dochází k zápisu v databázi a vytvoření přihlašovacích údajů pro oba účty, které jsou následně odeslány na emailovou adresu rodiče.  účet učitel – registrace pro nově přicházející učitele. Součástí je vyplnění osobních údajů spolu s adresou. Po úspěšném odeslání formuláře jsou data

Implementace

33

zapsaná do databáze a vytvořené přihlašovací údaje do systému jsou zaslány na email učitele uvedený při registraci.

6.6

Obr. 14

Přihlášení

Přihlašování účtů

O proces přihlašování a odhlašování se stará knihovna Session. Controller zpracovává data získané z formuláře (Obr. 14) a pomocí dat vrácená z modelu zjišťuje existenci daného účtu. Pokud účet existuje, metody knihovny Session uloží data uživatele do relace session. Poté dojde k přesměrování na úvodní stránku zobrazující vývěsku příspěvků aktuálního pololetí. Uživatel typu vedení má na této úvodní stránce také možnost přidávat, upravovat a mazat dané příspěvky. Součástí příspěvku může být příloha obrázkového nebo dokumentového formátu.

Implementace

6.7

34

Uživatelské sekce

6.7.1

Popis sekcí uživatele Žák

Obr. 15

Stránka uživatele žák – Konečná klasifikace

 Osobní profil – výpis a úprava osobních údajů s možností nahrávat profilový obrázek a změnit heslo. Uživatel může nahlédnout na své neomluvené hodiny.  Třídní příspěvky – nástěnka třídních příspěvků s možností přidat příspěvek bez přílohy ve své vlastní třídě. Autor příspěvku může příspěvek editovat, smazat.  Moji spolužáci – výpis kontaktních údajů spolužáků uživatele.  Učitelé – výpis kontaktních údajů všech učitelů školy s možností zaslat email.  Klasifikace – zobrazuje výpis průběžné klasifikace aktuálního pololetí s možností zobrazit známky za určitý předmět a konečnou klasifikaci s možností náhledu všech klasifikovaných pololetí (Obr. 15).

Implementace

6.7.2

35

Popis sekcí uživatele Rodič

 Osobní profil – výpis a úprava osobních údajů s možností nahrávat profilový obrázek a změnit heslo.  Moje děti – zobrazuje osobní údaje dětí uživatele a jejich průběžnou klasifikaci aktuálního pololetí. Klasifikace obsahuje také tabulku současných průměrných známek a hodnocení je možné filtrovat podle předmětu (Obr. 16). Dále může nahlédnout na neomluvené hodiny svých dětí s následnou možností je omluvit.  Rodiče – přehled kontaktních údajů ostatních rodičů s možností vyhledat podle příjmení a zaslat email.  Učitelé – výpis kontaktních údajů všech učitelů školy s možností zaslat email.

Obr. 16

Stránka uživatele rodič – Aktuální klasifikace dítěte

Implementace

6.7.3

36

Popis sekcí uživatele Učitel

 Osobní profil – výpis a úpravy osobních údajů s možností nahrávat profilový obrázek a změnit heslo.  Třídní příspěvky – výpis jednotlivých tříd s nástěnkami třídních příspěvků s možností přidat příspěvek s přílohou ve všech třídách. Autor příspěvku může příspěvek editovat, smazat.  Žáci – přehled osobních údajů žáků jednotlivých tříd a jejich zákonných zástupců s možností vyhledat pomocí příjmení nebo třídy s možností zaslat email.  Rodiče – přehled kontaktních údajů rodičů s možností vyhledat podle příjmení a možností poslat email.  Kolegové – výpis kontaktních údajů kolegů uživatele a možnost zaslat email.  Třídy a klasifikace – sekce určená pro přidání průběžné a závěrečné klasifikace. Upravovat nebo mazat hodnocení může pouze zadavatel. Součástí je také výpis zadaných známek s tabulkou aktuálních průměrných známek. Učitel zde také zadává neomluvenou absenci a kontroluje následné omluvení těchto hodin (Obr. 17).

Obr. 17

Stránka uživatele učitel – Třídy a klasifikace

Implementace

6.7.4

37

Popis sekcí uživatele Vedení

 Osobní profil – výpis a úpravy osobních údajů s možností nahrávat profilový obrázek a změnit heslo.  Žáci – přehled osobních údajů žáků jednotlivých tříd a jejich zákonných zástupců s možností vyhledat danou osobu pomocí příjmení nebo třídy a také ji zaslat email.  Rodiče – přehled kontaktních údajů rodičů s možností vyhledat pomocí příjmení a poslání emailu.  Kolegové – výpis kontaktních údajů kolegů uživatele s možností zaslat email.  Administrace období – obsahuje sekci pro tvorbu nových tříd a jejich správu společně s nástěnkami třídních příspěvků a správy klasifikace s možnostmi stejnými jako uživatel typu učitel. Dále se zde nachází tvorba nových pololetí společně s jejich správou a funkcí na přestup do dalšího pololetí (Obr. 18).

Obr. 18

Stránka uživatele vedení – Správa tříd

Zhodnocení

38

7 Zhodnocení Byl vytvořen informační systém formou bakalářské práce pro základní školu a tím pádem pro neziskovou organizaci. Z ekonomického pohledu tedy můžeme hodnotit pouze náklady na zřízení a provoz takového řešení. Protože si škola nepřeje zřizovat server, tak mezi tyto náklady patří registrace domény a vhodný hosting splňující požadavky dané aplikace (žádná reklama, cenová dostupnost domény, dostatečný diskový prostor, podpora nejnovějších verzí PHP a MySQL). Cena za tuto kombinaci služeb podle cen většiny poskytovatelů se pohybuje kolem 500 Kč ročně (endora.cz a wedos.cz [online]). Byl použit hosting od poskytovatele WEDOS Internet, a.s.. Z hlediska funkčnosti se podařilo naimplementovat vše, co bylo navrženo ve strukturovaných modelech. Rodičům je díky systému umožněno především sledovat klasifikaci a absenci svých dětí. Žáci mají možnost nahlédnout na svou průběžnou a konečnou klasifikaci a mají možnost komunikace v rámci třídy. Učitel zadává klasifikaci, absenci a komunikuje pomocí nástěnek jednotlivých tříd. Vedení, kromě učitelských funkcí, také spravuje období a třídy. Všichni uživatelé mají možnost vyhledat si kontakt na osobu podle svých potřeb a mají možnost ji kontaktovat. Pro mě osobně bych mezi budoucí vylepšení zařadil vytváření různých výstupů z dat klasifikace a absence, rozšíření administrátorských možností, přidání možnosti formátovat příspěvky tříd a vývěsky. Pokud škola získá dotaci na tablety, nebylo by špatné zapracovat na responzivní verzi systému pro tato zařízení.

Závěr

39

8 Závěr Předmětem této práce bylo provést návrh a implementaci informačního systému pro základní školu. Prvním krokem bylo provedení analýzy současného stavu organizace. Škola nevyužívala žádné řešení typu výsledné aplikace ani žádné komerční řešení. Došlo tedy k návrhu prvotní verze aplikace korespondující s danou situací. Daný návrh byl vytvořen pomocí programu Visual Paradigm a MySQL Workbench. Implementace prvotní verze byla vytvořena za použití moderního přístupu (MVC) a technologií (CodeIgniter, Twitter Bootstrap). Během těchto dvou etap jsem si uvědomil náročnost charakteru této práce. Člověk musí ovládat znalosti nejen technického rázu, ale měl by také rozumět problematice, kterou má daný systém řešit. Po úspěšném úvodním testování s fiktivními daty na lokálním serveru byla aplikace přesunuta na http://is.zsjevisovice.cz a byla představena vedení školy, kde byla kladně přijata hlavně za své uživatelské prostředí a jednoduché ovládání a tvorbu jednotlivých účtů. Připomínky byly směřovány hlavně k některým chybějícím prvkům v přehledu absence, které jsem při vývoji neuvažoval a byly objeveny až lidmi, kteří se v této problematice pohybují. Informační systém tedy bude ještě upraven o návrhy vylepšení z (kap. 7) a bude doplněn o funkce, které si nadiktovalo vedení školy. Díky využití návrhového vzoru MVC nebude další rozvoj aplikace problém. Výsledkem je tedy informační systém, který se stane součástí školy a díky současnému a očekávanému stavu výpočetní techniky bude každodenně využíván a umožní větší efektivitu činností. Zde uvádím názor zástupkyně ředitele Evy Dohnalové: „Na základě konzultace o nastavení prvotních vstupních údajů a výstupů byl vytvořený tento informační systém, ve kterém jsou všechny potřebné informace k tomu, aby si učitel vedl data o žákovi a rodič měl zpětnou vazbu s možností kontaktu na učitele. Velice často se nám stává, že přichází od rodičů stížnosti na klasifikaci svého dítěte, ale důvodem je to, že dítě tají své veškeré obdržené průběžné hodnocení a doma ukáže pouze to, které se mu hodí. Po dohodě s autorem bude tento systém spuštěn na naší škole pro dvě až tři třídy v novém školním roce, tj. od 1. 9. 2014."

Literatura

40

9 Literatura APACHE FRIENDS. Xampp. [online]. [cit. 2013-11-10]. Dostupné z: http://www.apachefriends.org/en/xampp.html BARÁŠEK, L. Hashovací funkce. [online]. [cit. 2013-1130]. Dostupné z: http://php.baraja.cz/index.php?kategorie=navody&page=ha shovani COCHRAN, D. Twitter bootstrap web development. New Edition. S.l.: Packt Publishing Limited. ISBN 978-184-9518-826. DANEL, L. Objektový přístup k analýze a návrhu IS. [online]. [cit. 2013-1215]. Dostupné z: http://homel.vsb.cz/~dan11/metproj/Danel%20%20MP%20-%20Objektovy%20pristup%20k%20navrhu%20systemu.pdf DANEL, L. Strukturovaný přístup k návrhu systémů - přehled. [online]. [cit. 2013-1015]. Dostupné z: http://homel.vsb.cz/~dan11/aps/texty/Danel%20%20APS%20%20Strukturovany%20pristup%20k%20navrhu%20systemu.p df ELLISLAB. CodeIgniter php framework [online]. [cit. 2013-11-11]. Dostupné z: http://ellislab.com/codeigniter/user-guide ENDORA. Webhosting nabídka. [online]. [cit. 2013-12-15]. Dostupné z: http://www.endora.cz/vlastnosti ENTERPRISE ARCHITECT. Data Flow diagramy. [online]. [cit. 2013-11-10]. Dostupné z: http://www.enterprise-architect.cz/content/data-flow-diagramy FORM VALIDATOR. jQuery form validator. [online]. [cit. 2013-12-25]. Dostupné z: http://formvalidator.net/ KAJZAR, D. Projektování informačních systémů: strukturovaný a objektový přístup. Vyd. 1. Opava: Slezská Univerzita, 2003, 219 s. ISBN 80-724-8214-9. LACKO, L. PHP a MySQL: hotová řešení. 1. vyd. Brno: CP Books, 2005, 299 s. ISBN 80-251-0397-8. LACKO, L. SQL hotová řešení: k okamžitému použití. Vyd. 1. Brno: Computer Press, 2003, 298 s. ISBN 80-7226-975-5. MYER, T. Professional CodeIgniter. Indianapolis, IN: Wiley, 2008, 314 p. ISBN 9780-470-28245-8. MYSQL. MySQL Workbench. [online]. [cit. 2013-10-20]. Dostupné z: http://www.mysql.com/products/workbench NETBEANS. NetBeans IDE. [online]. [cit. 2013-1110]. Dostupné z: https://netbeans.org/downloads NETTE FOUNDATION. MVC aplikace & presentery. [online]. [cit. 2013-11-11]. Dostupné z: http://doc.nette.org/cs/2.1/presenters RÁBOVÁ, I. Informační systémy, 2006 [online]. [cit. 2013-10-11]. Dostupné z: https://is.mendelu.cz/auth/eknihovna/opory/index.pl?opora=177

Literatura

41

RÁBOVÁ, I. Podnikové informační systémy a technologie jejich vývoje. Brno: Tribun EU, 2008. ISBN 978-80-7399-599-7. RYBIČKA, J., ČAČKOVÁ, P. Informatika pro ekonomy. 1. vyd. Praha: Alfa Nakladatelství, 2009, s. 229-244. Informatika (Alfa Nakladatelství). ISBN 978-80-8719724-0. SEQUEL PRO. Sequel Pro database management. [online]. [cit. 2013-1111]. Dostupné z: http://www.sequelpro.com ŠMÍD, V. Management informačního systému. [online]. [cit. 2013-10-14]. Dostupné z: http://www.fi.muni.cz/~smid/mis-zivcyk.htm TWITTER. Twitter Bootstrap. [online]. [cit. 2013-11-25]. Dostupné z: http://getbootstrap.com UNIVERSITY OF WATERLOO. Context diagram. [online]. [cit. 2013-10-10]. Dostupné z: https://uwaterloo.ca/information-systems-technology/projects/projectresources/methodology-toolkit/context-diagram VISUAL PARADIGM. Visual paradigm for UML. [online]. [cit. 2013-12-25]. Dostupné z: http://www.visual-paradigm.com/ VOŘÍŠEK, J. Informační systémy a jejich řízení. 3. vyd. Praha: Bankovní institut vysoká škola, 2007, 278 s. ISBN 978-80-7265-100-9. VRÁNA, J. 1001 tipů a triků pro PHP. Vyd. 1. Brno: Computer Press, 2010, 456 s. ISBN 978-80-251-2940-1. WEDOS. Webhosting nabídka. [online]. [cit. 2013-12-15]. Dostupné z: http://hosting.wedos.com/cs/webhosting.html WIKIPEDIA. Entity relationship diagram [online]. [cit. 2013-10-05]. Dostupné z: http://en.wikipedia.org/wiki/Entity-relationship_diagram WIKIPEDIA. Structured analysis. [online]. [cit. 2013-10-02]. Dostupné z: http://en.wikipedia.org/wiki/Structured_analysis WIKIPEDIA. PHP. [online]. [cit. 2013-11-10]. Dostupné z: http://en.wikipedia.org/wiki/Php