Informační systém pro výživovou poradnu

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Studijní program: Aplikovaná informatika Obor: Informační systémy a technologie

Informační systém pro výživovou poradnu DIPLOMOVÁ PRÁCE

Student

:

Bc. Jan Švimberský

Vedoucí

:

Ing. Jarmila Pavlíčková

Oponent :

Ing. Irena Burgetová

2014

Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal.

V Praze dne 5. května 2014

................................ Bc. Jan Švimberský

Poděkování Rád bych poděkoval vedoucí mé práce paní Ing. Jarmile Pavlíčkové za konstruktivní připomínky, nápady a za čas, který mi věnovala.

Abstrakt Cílem této práce je návrh a implementace webového informačního systému na zakázku pro výživovou poradnu. Tato práce je rozdělena do několika částí. První část se věnuje popisu a zhodnocení dostupných aplikací pro podporu výživových poraden s odůvodněním proč tyto aplikace poradně, pro kterou je systém vyvíjen, nevyhovují. Druhá část obsahuje analýzu a návrh vyvíjeného systému z hlediska vize, specifikace funkčních a nefunkčních požadavků, popisu případů užití, návrhu obrazovek a návrhu architektury pomocí konceptuálního datového schématu a schématu webových stránek. Tato část je psána dle upravené metodiky MMSP. Třetí část demonstruje implementaci systému ukázkami kódu v jazyce ASP.NET na třech vybraných webových stránkách. Stránky se zabývají obsluhou číselníků a vytvářením receptů. Přílohou práce je aktuální verze projektu vyvíjeného systému.

Klíčová slova informační systém, metodika MMSP, výživová poradna, vývoj systému na zakázku, ASP.NET

Abstract The aim of this diploma thesis is the design and implementation of web based individual information system for nutritional counseling organizations. This work is divided into several parts. The first part is devoted to the description and evaluation of applications available to support nutrition counseling organizations with reasoning why these applications are not very viable option. The second part is devoted to the analysis and design of the system in terms of vision, specification of functional and non-functional requirements, description of use cases, screen designs and architecture design using conceptual data schema and sitemap. This section is written according to the modified methodology MMSP. The third section demonstrates the implementation of the system on code written in ASP.NET language for three selected webpages. These pages are about dealing with the list of values and creating food recipes. The current version of the information system is added as an attachment.

Keywords information system, methodology MMSP, nutrition counseling, development of individual information system, ASP.NET

Obsah 1

2

Úvod ................................................................................................................................................ 1 1.1

Vymezení tématu .................................................................................................................... 1

1.2

Cíle práce ................................................................................................................................. 1

1.3

Struktura práce........................................................................................................................ 2

1.4

Předpoklady a omezení práce ................................................................................................. 2

1.5

Rešerše zdrojů zabývajících se tvorbou informačních systémů a aplikací .............................. 2

Základní popis dostupných aplikací pro podporu výživových poraden .......................................... 4 2.1

NutriDan (4)............................................................................................................................. 4

2.2

Jednohubka (5) ........................................................................................................................ 6

2.3

FitLinie (6) ................................................................................................................................ 8

2.4

Zhodnocení .............................................................................................................................. 9

3

O poradně...................................................................................................................................... 11

4

Vize ................................................................................................................................................ 12 4.1

Vymezení vize ........................................................................................................................ 12

4.1.1

Vymezení problému ...................................................................................................... 12

4.1.2

Vymezení produktu ....................................................................................................... 14

4.2

Popis všech zúčastněných subjektů ...................................................................................... 15

4.2.1

Seznam subjektů ........................................................................................................... 15

4.2.2

Uživatelské rozhraní ...................................................................................................... 15

4.3

Přehled produktu .................................................................................................................. 16

4.3.1 5

Požadavky a funkce ....................................................................................................... 16

Požadavky ...................................................................................................................................... 18 5.1

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

5.1.1

PP001............................................................................................................................. 19

5.1.2

PP002............................................................................................................................. 19

5.1.3

PP003............................................................................................................................. 20

5.1.4

PP004............................................................................................................................. 21

5.1.5

PP005............................................................................................................................. 22

5.1.6

PP006............................................................................................................................. 22

5.1.7

PP007............................................................................................................................. 23

5.1.8

PP008............................................................................................................................. 23

5.1.9

PP009............................................................................................................................. 24

5.1.10

PP010............................................................................................................................. 24

5.1.11

PP011............................................................................................................................. 25

5.1.12

PP012............................................................................................................................. 25

5.1.13

PP013............................................................................................................................. 25

5.1.14

PP014............................................................................................................................. 26

5.2

5.2.1

Použitelnost ................................................................................................................... 26

5.2.2

Spolehlivost ................................................................................................................... 26

5.3

Rozhraní ................................................................................................................................ 27

5.3.1

Uživatelské rozhraní ...................................................................................................... 27

5.3.2

Rozhraní na externí systémy nebo zařízení ................................................................... 28

5.4 6

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

Systémová omezení .............................................................................................................. 29

Případy užití ................................................................................................................................... 30 6.1

Definice aktérů ...................................................................................................................... 30

6.2

Specifikace případů užití ....................................................................................................... 30

6.2.1

Diagram případů užití .................................................................................................... 31

6.2.2

Přihlašování uživatelů.................................................................................................... 32

6.2.3

Tvorba a úprava receptů ............................................................................................... 34

6.2.4

Tvorba a úprava jídelníčků pro klienty .......................................................................... 36

6.2.5

Rozšíření a úprava databáze ingrediencí....................................................................... 38

6.2.6

Registrace a správa klientů............................................................................................ 40

6.2.7

Tvorba a úprava cvičebních plánů a plánů schůzek ...................................................... 42

7

8

6.2.8

Psaní a úprava článků pro veřejnost ............................................................................. 44

6.2.9

Vytváření fotogalerií a vkládání fotek ........................................................................... 45

6.2.10

Prohlížení klientských jídelníčků ................................................................................... 47

6.2.11

Prohlížení klientských cvičebních plánů a schůzek ....................................................... 48

6.2.12

Získání informací o průběhu dietního programu .......................................................... 49

6.2.13

Prohlížení fotogalerií ..................................................................................................... 50

6.2.14

Čtení článků ................................................................................................................... 51

Návrhy obrazovek.......................................................................................................................... 52 7.1

Úvodní obrazovka.................................................................................................................. 52

7.2

Přihlašovací obrazovka .......................................................................................................... 53

7.3

Správa článků ........................................................................................................................ 54

7.4

Přidání receptu ...................................................................................................................... 55

7.5

Přidání jídelníčku ................................................................................................................... 56

7.6

Čtení jídelníčku ...................................................................................................................... 57

7.7

Založení klienta...................................................................................................................... 58

Popis architektury ......................................................................................................................... 59 8.1

8.1.1

Požadavky a omezení .................................................................................................... 59

8.1.2

Předpoklady................................................................................................................... 60

8.2

9

Základní vymezení ................................................................................................................. 59

Architektonická rozhodnutí a jejich vysvětlení ..................................................................... 60

8.2.1

Typ architektury ............................................................................................................ 60

8.2.2

Návrh datové základny .................................................................................................. 61

8.2.3

Návrh schématu webových stránek .............................................................................. 64

Popis implementace ...................................................................................................................... 67 9.1

Použité technologie ............................................................................................................... 67

9.1.1

ASP.NET ......................................................................................................................... 67

9.1.2

HTML a CSS .................................................................................................................... 67

9.1.3

JavaScript....................................................................................................................... 67

9.1.4 9.2

SQL................................................................................................................................. 68

Ukázka postupu ..................................................................................................................... 68

9.2.1

Správa potravin ............................................................................................................. 68

9.2.2

Vytvoření receptu a M:N vazba ..................................................................................... 74

9.2.3

Řešení zabezpečení (3) .................................................................................................. 80

9.3

Databáze ingrediencí ............................................................................................................. 83

9.4

Testování ............................................................................................................................... 84

10

Závěr .......................................................................................................................................... 85

Terminologický slovník .......................................................................................................................... 87 Reference .............................................................................................................................................. 89 Seznam obrázků .................................................................................................................................... 91 Seznam tabulek ..................................................................................................................................... 92 Seznam ukázek ...................................................................................................................................... 93

1 Úvod V dnešní době je stále populárnější otázka zdravého životního stylu a zdravé výživy. Tento trend a zároveň malá znalost problematiky u obecné veřejnosti dává za vznik specializovaným poradnám, které se těmito otázkami zabývají. Převážná většina těchto poraden je malých, regionálních a z konkrétních důvodů si nemohou dovolit velké a drahé informační systémy. Pro jejich potřeby je na trhu několik programů, které ale převážně nevznikly cíleně pro podporu těchto poraden. Protože již několik let pracuji jako vývojář informačních systémů, byl jsem jednou poradnou osloven, zda bych nemohl vytvořit systém, který by splňoval jejich potřeby a požadavky. Vývoj tohoto systému jsem se rozhodl použít jako téma své diplomové práce. Původně jsem systém vyvíjel velmi agilně, protože požadavky se měnily téměř ze dne na den, ale pro účely této práce jsem použil a přizpůsobil metodiku MMSP, která je dostupná na adrese http://mmsp.czweb.org/ .

1.1 Vymezení tématu Práce se zabývá vývojem informačního systému pro výživovou poradnu. Tento systém je vyvíjen na zakázku a v úzké spolupráci se zákazníkem. Na následujících stránkách je popsána analýza a první fáze vývoje systému dle upravené metodiky MMSP. Tato metodika je přizpůsobena tak, aby reflektovala to, že jediný člověk pracuje na analýze, grafickém rozhraní, programování a dalších věcech okolo projektu a zároveň, aby reflektovala agilnější přístup samotného reálného vývoje. V příloze se pak nachází aktuální verze projektu. U čtenářů se předpokládají základní znalosti vývoje webových aplikací.

1.2 Cíle práce Hlavním cílem této práce je vytvoření informačního systému pro výživovou poradnu dle požadavků specifikovaných zákazníkem. Vývoj výsledného systému nekončí s odevzdáním této práce, ale bude pokračovat dále v dalších fázích. Tento cíl je rozdělen na několik následujících dílčích cílů. Prvním dílčím cílem je analýza, popis a zhodnocení aplikací pro podporu výživových poraden, které jsou již na trhu dostupné. Druhým dílčím cílem je zpracování a specifikace požadavků na tvořený systém, včetně návrhu jeho implementace. Závěrečným cílem je samotná implementace systému a popis řešení několika částí.

1

1.3 Struktura práce Nejprve se zabývám aplikacemi pro podporu výživy, které již na českém trhu existují. Ty pak porovnávám z několika daných hledisek. Poté pomocí upravené metodiky MMSP popisuji vizi, přehled požadavků, případy užití, návrhy obrazovek a architekturu vyvíjeného systému. Nakonec je v této práci několik ukázek kódu, včetně vysvětlení, z implementace.

1.4 Předpoklady a omezení práce Práce předpokládá základní znalosti v oblasti vývoje webových aplikací. Vzhledem výsledné k implementaci v jazyce ASP.NET je jeho znalost výhodou. Práce nevysvětluje základy kódování informačních systémů a závěrečné ukázky kódu jsou spíše pro pokročilejší vývojáře. Práce neobsahuje testování výsledného systému, které je prováděno adhoc zákazníkem.

1.5 Rešerše zdrojů zabývajících se tvorbou informačních systémů a aplikací V roce 2013 sepsal Bc. Dominik Šimůnek na Vysoké škole ekonomické v Praze diplomovou práci na téma „Návrh webové aplikace pro řízení tréninkového procesu atletů“. Tato práce, jak již název napovídá, se zabývá návrhem a následnou implementací webové aplikace pro řízení tréninků a obsahuje analýzu existujících možností pro podporu tréninku, specifikaci funkčních i nefunkčních požadavků, analýzu a návrh řešení, implementaci řešení a uživatelskou příručku. Praktickým výstupem je pak samotná aplikace dostupná na adrese http://www.goodathlete.cz/ . Práce je sepsána velmi podrobně a odborně, i když například definice případů užití by mohly být propracovanější (například chybí přiřazení aktérů k jednotlivým případům). (1) Druhou diplomovou prací z téže školy je práce Bc. Martina Müllera z roku 2013 na téma „Vývoj aplikace pro prezentaci produktů zadavatele“. Práce se zabývá vytvořením aplikace na míru a obsahuje popis literatury o vývoji pro operační systém Android, rozbor požadavků zadavatele, specifikaci funkčních a nefunkčních požadavků, návrh architektury (aplikace se skládá ze serverové a klientské části) a uživatelskou příručku. Praktickým výstupem je aplikace pro operační systém Android, která je napojena na server, který je simulován pomocí XML dokumentů. Případy užití by mohly být lépe popsány, jinak se jedná o velmi dobrou práci. (2) „Beginning ASP.NET 4 in C# 2010“ z nakladatelství Apress je kniha vhodná pro začínající vývojáře webových informačních systémů v jazyce ASP.NET. Kniha má více jak tisíc stránek a skládá se 2

z šesti částí. První část je o historii vývoje webových aplikací a o stručném představení jazyka C#. Druhá část obsahuje základy práce s vývojovým prostředím Visual Studio a úvod do ASP.NET. Ve třetí až páté části se kniha zabývá pokročilejšími tématy, jako je například bezpečnost webových aplikací, tvorba uživatelských komponent, tvorba vlastních grafických stylů, atd. Poslední část obsahuje ukázky kódu z různých, na sobě nezávislých, témat. Knihu bych doporučil těm vývojářům, kteří již ovládají jazyk C#, a chtějí ovládnout základy vývoje dynamických webových aplikací. (3)

3

2 Základní popis dostupných aplikací pro podporu výživových poraden V této kapitole představuji a porovnávám několik existujících aplikací, které se dají využít ve výživových poradnách. Z důvodu specifičnosti a relativní novosti oblasti výživového poradenství neexistuje mnoho aplikací na jeho podporu. Je několik programů cílených na individuální uživatele, jako jsou různí osobní trenéři a stravovací deníky, některé jsou ve formě mobilních aplikací, ale softwarů zaměřujících se speciálně na poradny bylo zatím vytvořeno velmi málo (alespoň tedy v České republice) a většinou se ani nejedná o profesionální nástroje. Následující stránky jsou věnované popisu a zhodnocení několika programů, které se k podpoře poraden dají využít. Jedná se asi o nejznámější český nástroj FitLinie (dostupné z http://www.fitlinie.cz/ ) a dále pak programy Jednohubka (dostupné z http://obezita.org/?page=jednohubka ) a NutriDan (http://www.institut-danone.cz/cz/odborna-sekce/nutridan/ ). Aplikace porovnávám z následujících hledisek: 

Funkcionalita



Cena



Uživatelská přívětivost



Databáze potravin



Zda se jedná o webovou aplikaci

Tato hlediska zároveň slouží jako kritéria pro přijetí aplikace zákazníkem. Vhodný program musí obsahovat funkcionalitu pro plánování jídelníčků, musí být cenově dostupný, uživatelsky přehledný a přívětivý, dále musí obsahovat rozšiřitelnou databázi potravin s alespoň tisíci výchozími záznamy a musí se jednat o webovou aplikaci.

2.1 NutriDan (4) Software NutriDan je výsledkem práce MUDr. Dany Müllerové, PhD. a kolektivu. Program vznikl jako speciální nástroj pro lékaře, určený na analýzu jídelníčku jejich klientů. Neslouží ani tak k plánování jídelníčků, jakožto k jejich zpětné analýze během pravidelných vyšetření klientů. Lékař nejprve v systému založí klienta a poté na každé pravidelné prohlídce zadá jeho výšku, váhu a jeho stravu. Pro zadání stravy je k dispozici přibližně osm set potravin. Nevýhodou je nutnost 4

klienta vést si stravovací deník, aby poté údaje z tohoto deníku mohly být přeneseny do systému. Dále je lékařem do programu zadávána pohybová aktivita klienta. Po vyplnění údajů systém provede analýzu nutričních a energetických hodnot stravy, které zobrazí formou grafů a tabulek. Jasným nedostatkem aplikace pro použití v poradnách je chybějící možnost plánování a vytváření jídelníčků. Dále klienti nemají přístup ke svým údajům, které jsou uloženy v lokální databázi programu. Další nevýhodou se mi jeví značná uživatelská nepřívětivost a neintuitivnost ovládání. Program neobsahuje mnoho funkcionality, ale i přes to mi trvalo delší dobu se v něm vyznat. Zadávací formuláře jsou navrženy zmateně a nepřehledně a vývojář nepočítal s možností roztahování zadávacího okna. Nápověda programu chybí, i když je na ní odkaz v menu. Nevím, zda jsem neměl pouze osekanou verzi aplikace, ale mnoho tlačítek nástrojové lišty bylo za jakýchkoliv okolností neaktivních. Z technického hlediska je program psaný jako desktopová aplikace pro MS Windows 98 a vyšší a je dostupný zdarma. Tabulka 1 obsahuje závěrečné zhodnocení.

Tabulka 1 - Zhodnocení aplikace NutriDan

FUNKCIONALITA UŽIVATELSKÁ PŘÍVĚTIVOST DATABÁZE POTRAVIN CENA WEBOVÁ APLIKACE

Nedostatečná (pouze zpětná analýza) Velmi nízká (nepřehledné a zmatené formuláře a ovládání) Velmi dobrá (více jak 800 potravin, rozšiřitelná mimo uživatelské rozhraní aplikace) Zdarma Ne

Na závěr přikládám snímek obrazovky programu se zadávacím formulářem (Obrázek 1).

5

Obrázek 1 - NutriDan obrazovka

Kvůli výše popsaným nevýhodám byl program označen za nevyhovující.

2.2 Jednohubka (5) Jednohubka je program vyvinutý původně k podpoře boje proti obezitě a zároveň je programem, který je aktuálně využíván v poradně pro plánování jídelníčků. Jedná se o aplikaci z roku 1998 a je připravena k distribuci na čtyřech disketách. Stejně jako aplikace NutriDan není její primární účel plánování, nýbrž analýza jídelníčků, ovšem díky použitelnému uživatelskému rozhraní lze tuto aplikaci pro toto plánování použít. Po vytvoření nového klienta v programu a zadání jeho údajů o výšce, váze, pohybové aktivitě a očekávaném cíli, aplikace vypočítá doporučené energetické příjmy na den pro udržení dosavadní váhy a pro dosažení cílové váhy. Poté je možno vstoupit do jednoho ze čtyř modulů. 1) Zadání nového klienta 2) Vložení jídelníčku 3) Vložení pohybové aktivity 4) Statistika Právě v modulu pro jídelníčky jsou vkládána jídla z databáze, která obsahuje něco kolem 1000 položek rozdělených do různých kategorií (brambory, sýry, maso, …) do seznamu, který potom tvoří jídelníček na příslušný den. Pomocí sloupcových grafů jsou pak zobrazeny souhrnné informace o celém jídelníčku (poměry cukrů, tuků, bílkovin a míra energie) a ty jsou porovnány s cílovou hodnotou 6

denního energetického příjmu. Uživatel je upozorněn, je-li cíl překročen. Díky možnosti exportu jídelníčku do textového souboru je možné program efektivně využívat. Údaje zadané do modulu pro pohybovou aktivitu slouží k úpravě cílové hodnoty energetického příjmu. Čím vyšší aktivita, tím vyšší výdaje a tím vyšší musí být denní příjmy. Modul statistiky pak zobrazuje různé analýzy jídelníčků a aktivit formou grafů. Hlavní nevýhodou programu je nerozšiřitelnost jeho databáze potravin, ale hlavní důvod proč má být v poradně nahrazen je, že klienti nemají žádný integrovaný přístup ke svým výsledkům, jídelníčkům a aktivitám (vše závisí na tom, co jim zaměstnanec poradny zašle emailem). K hlavním přednostem patří jeho značná jednoduchost ovládání, uživatelská přívětivost (na rozdíl od programu NutriDan) a celkem dostatečná funkcionalita (i když původně určena k analýze a ne k plánování). Zhodnocení ukazuje Tabulka 2. Obrázek 2 zobrazuje snímek obrazovky aplikace.

Tabulka 2 - Zhodnocení aplikace Jednohubka


Dostatečná (zpětná analýza, ale přizpůsobitelná pro plánování) Dobrá Dobrá (více jak 1000 potravin, ale nerozšiřitelná) Zdarma Ne

Obrázek 2 - Jednohubka obrazovka

7

2.3 FitLinie (6) FitLinie je nejznámějším českým programem pro podporu hubnutí. Na rozdíl od programů popsaných výše je stále vyvíjen a aktualizován. Také nevznikl jako vedlejší produkt, ale jako plnohodnotný software jak pro domácí, tak pro profesionální využití. Funkcionalita systému lze rozdělit do třech oblastí: 1) Pro domácí použití 2) Pro výživové poradny 3) Pro sportovní trenéry Oblast pro domácí použití poskytuje podobné možnosti jako Jednohubka - vypočítávání BMI, cílových hodnot, analýza jídelníčku. V oblasti pro poradny lze navíc i plánovat jídelníčky a poté porovnávat plány s jídly, které klienti skutečně zkonzumovali (za předpokladu, že si klienti vedou svůj deník). Oblast pro trenéry umožňuje vytvářet tréninkové sestavy a dlouhodobě sledovat zlepšování klientů. Databáze potravin čítá přibližně 3200 záznamů a je rozšiřitelná přímo přes uživatelské rozhraní aplikace. Dále je možné tuto databázi přes internet sdílet s jinými FitLinie aplikacemi, což je na jednu stranu výhodné díky neustálému rozšiřování, avšak na stranu druhou nejsou záznamy nijak kontrolovány a pokud nějaký uživatel nasdílí špatné hodnoty, stává se celková databáze méně důvěryhodnou. Uživatelské rozhraní i přívětivost aplikace jsou na vysoké úrovni a je vidět, že program vznikl jako komerční produkt a je relativně mladý, na rozdíl od NutriDanu a Jednohubky. Tento program není zdarma. Licence pro dva uživatele stojí 490Kč a poté 199Kč ročně za aktualizace. V podmínkách poradny je jeden uživatel roven jednomu klientu, stejně jako v předcházejících programech, čili tato licence je nevyhovující. Pro neomezený počet uživatelů je cena 3990Kč plus za aktualizace 999Kč ročně, což není zanedbatelná částka. FitLinie i přes svou vyhovující funkcionalitu a uživatelskou přívětivost byla v poradně zamítnuta právě pro svoji vysokou cenu a proto, že se nejedná o webovou aplikaci a klienti nemají přístup ke svým údajům, stejně jako v předcházejících uvažovaných programech. Závěrečné zhodnocení se nachází v Tabulce 3. Snímek obrazovky zobrazuje Obrázek 3.

8

Tabulka 3 - Zhodnocení aplikace Fitlinie


Vysoká (zpětná analýza, plánování, sportovní aktivity) Velmi dobrá Velmi dobrá (více jak 3200 potravin, rozšiřitelná) FULL Licence 3990Kč + 999Kč/rok Ne

Obrázek 3 - FitLinie obrazovka (6)

2.4 Zhodnocení Z výsledků porovnání nejlépe vychází program FitLinie i přes svou vysokou cenu (pro domácí použití je cena přijatelná). Na druhé místo řadím program Jednohubka a na třetí trochu s odstupem aplikaci NutriDan. Ani jedna z těchto aplikací však nesplňuje základní kritérium poradny – aby aplikace byla webová a klienti měli kdykoli přístup ke svým informacím. V Tabulce 4 se nachází závěrečné srovnání.

9

Tabulka 4 - Závěrečné vyhodnocení

NUTRIDAN

JEDNOHUBKA

FITLINIE

Nevyhovující

Vyhovující

Vyhovující

Nevyhovující

Vyhovující

Vyhovující

DATABÁZE POTRAVIN

Nevyhovující

Nevyhovující

Vyhovující

CENA

Vyhovující

Vyhovující

Nevyhovující

WEBOVÁ APLIKACE

Nevyhovující

Nevyhovující

Nevyhovující

FUNKCIONALITA UŽIVATELSKÁ PŘÍVĚTIVOST

10

3 O poradně Výživová poradna byla založena v roce 2011 s názvem VýživaES a zatím má jediného zaměstnance, a zároveň majitele, PharmDr. Evu Švimberskou. Princip fungování je jednoduchý. Klient se, většinou telefonicky, objedná na konkrétní termín pro úvodní schůzku. Na této schůzce je seznámen se základy zdravé výživy, přeměřen a převážen. Klient společně se zaměstnancem určí optimální cílovou hodnotu váhy, které by chtěl dosáhnout po ukončení programu. Program trvá jeden měsíc. S klientem je domluven termín další schůzky (označena jako kontrolní). Klientovi je poté do tří dnů sestaven jídelníček na týden (dle informací získaných na úvodní schůzce), který mu je e-mailem odeslán. Doposud poradna využívala pouze papírové evidence klientů, kombinované s programem Jednohubka pro tvorbu jídelníčků. Ani jedno není ideální, za tři roky působení se velmi nahromadila kartotéka klientů, ve které se jen obtížně cokoliv vyhledává. Program Jednohubka zase není primárně určen pro plánování (viz výše uvedené nedostatky).

11

4 Vize Při tvorbě informačního systému pro tuto poradnu jsem vycházel z metodiky MMSP (dostupné z http://mmsp.czweb.org/ ), kterou jsem přizpůsoboval dle svých potřeb. Například jsem přeskočil fázi plánování projektu, protože v této práci jsem všechny role (projektový manažer, analytik, architekt, vývojář, tester) zastával sám a samotné plánování jednotlivých etap bylo tedy zbytečné. (7) Tato kapitola popisuje vizi tak, jak je definována metodikou MMSP. Jedná se o základní pohled na tvořený systém jako na celek.

4.1 Vymezení vize Kapitola vymezení vize se skládá ze dvou částí. Tyto části jsou Vymezení problému a Vymezení produktu.

4.1.1

Vymezení problému Vymezení problému má čtyři části a to Definici problému, Kdo problém ovlivňuje, Dopady

problému a Přínosy úspěšného řešení problému.

4.1.1.1

Definice problému Tento projekt řeší chybějící počítačově založený informační systém u výživové poradny

VýživaES. Poradna v současné době využívá pouze papírové evidence klientů, manuální tvorby jídelníčků a jejich následného ručního rozesílání elektronickou poštou. Dále má poradna pouze velmi omezenou a nerozšiřitelnou databázi potravin a jejich energetických hodnot. Poradna sice vlastní webové stránky za účelem své propagace, avšak tyto stránky jsou neaktualizované a nedávají návštěvníkům žádný důvod pro opětovný návrat na ně. Zákazníci poradny také nemají z těchto stránek žádnou užitnou hodnotu. V neposlední řadě projekt řeší neexistující elektronickou podporu pro klienty, kde by nalezli svůj jídelníček, dietní a cvičební plán a informace o aktuálním průběhu jejich dietního programu.

4.1.1.2

Koho problém ovlivňuje Problém ovlivňuje zaměstnance poradny, kteří bez pomoci automatizovaných nástrojů stráví

velmi mnoho času řešením individuálních potřeb jednotlivých klientů. 12

Zároveň se projekt týká klientů poradny a návštěvníků její webové prezentace (potenciálních klientů), kde ani jedna z těchto skupin nemá přístup k potřebným informacím, které za normálních okolností vyžadují.

4.1.1.3

Dopady problému Prvním dopadem je nízká časová efektivnost zaměstnanců poradny. Při přepočtu aktuálních

cen služeb pro jednoho klienta na čas věnovaný plnění služeb tomuto klientovi, vychází cena přibližně 100 Kč /hod. Dále se velmi hromadí papírová administrativa, která zabírá velký prostor a také bez opětovné správy a přerovnávání neumožňuje rychlé vyhledávání, což opět zabírá čas zaměstnancům poradny. Třetím dopadem je nízké povědomí mezi veřejností o této poradně. Poradna si sice zakládá na velmi kvalitním, levném a individuálním přístupu ke svým klientům, ale bez patřičné reklamy plynoucí z webové prezentace, má pouze omezený počet klientů, zvláště pak ze širšího okolí poradny. Kvůli nízké atraktivnosti a návštěvnosti webových stránek jsou při vyhledávání upřednostňovány jiné poradny a, i když tato poradna nabízí kvalitnější služby, klienti jdou jinam. Posledním dopadem je velká zahlcenost zaměstnance poradny technickými dotazy klientů, kteří bývají většinou z méně technicky zdatné kategorie obyvatel a mají problémy s otevíráním příloh emailů, formátováním a kódováním češtiny u rozeslaných jídelníčků, nepamatují si termíny naplánovaných schůzek, apod.

4.1.1.4

Přínosy úspěšného řešení problému Úspěšné řešení těchto problémů přinese v první řadě IT podporu každodenních činností

poradny. Ať už se jedná o správu klientů, tvorbu jídelníčků, či jiných aktivit. Elektronická správa klientů znamená nižší nároky na fyzický úložný prostor, podporu rychlého vyhledávání a upravování informací o konkrétních klientech. Podpora tvorby jídelníčků urychlí jejich vytváření, jejich automatické vystavování klientům odstraní faktor rozesílání elektronické pošty, který může být občas nespolehlivý (pošta mlže mít zpoždění na ucpaném uzlu, být zachycena spamovými filtry, …). Tyto přínosy by celkově měly zvýšit časovou efektivitu zaměstnanců (v korunách na hodinu) a tím zvýšit zisk poradny. Dalším přínosem je zviditelnění poradny prostřednictvím webové prezentace. Větší a opakovaná návštěvnost webových stránek klienty znamená lepší pozici ve vyhledávačích, což znamená 13

větší počet klientů. Klienti budou mít důvod se na stránky vracet kvůli jejich klientské sekci, zatímco noví zákazníci budou stránky vyhledávat kvůli zdravým receptům, článkům o zdravé výživě, atd. V neposlední řadě je přínosem pro samotné klienty klientská sekce systému, kde budou moci získat informace o stavu svého dietního programu, svůj aktuální jídelníček bez potíží, které můžou nastat s elektronickou poštou a další užitečné údaje.

4.1.2

Vymezení produktu Tato podkapitola název vyvíjeného IS, jeho kategorie, definici koncových uživatelů a klientů a

jeho klíčové přínosy.

4.1.2.1

Název vyvíjeného IS/ICT Názvem je VýživaES IS. Vzhledem k jeho vysoce individuální povaze a zaměření na podporu

služeb je jeho kategorizace poměrně náročná, ale dal by se zařadit do kategorie ERP s úzkým vztahem k podpoře klientů.

4.1.2.2

Koncoví uživatelé a zákazníci IS Koncovými uživateli IS jsou zaměstnanci poradny, kteří využívají administrativní části IS pro

tvorbu jídelníčků, plánování schůzek, správě klientů poradny, vytváření receptů, doplňování a úpravě databáze potravin, psaní článků o zdravé výživě a úpravě fotogalerie. Dalším typem uživatelů jsou stávající klienti poradny. Tito klienti využívají klientskou část systému pro získávání svých jídelníčků, získávání informací o průběhu jejich dietního programu a získávání informací o naplánovaných schůzkách. Třetím typem uživatelů jsou potenciální klienti poradny, kteří využívají systém pro čtení článků o zdravé výživě, k prohlídkám fotogalerie a k získání informací o poradně, jejím provozu, metodách, případně o místě působení a kontaktu.

4.1.2.3

Klíčové přínosy vyvíjeného IS Klíčové přínosy IS jsou uvedeny v kapitole Přínosy úspěšného řešení problému, vzhledem

k tomu, že problémem je právě neexistence IS.

14

4.2 Popis všech zúčastněných subjektů Tato kapitola obsahuje vymezení subjektů prostřednictvím Seznamu subjektů a poté speciální požadavky a omezení na Uživatelské rozhraní.

4.2.1

Seznam subjektů Seznam subjektů se skládá z názvu subjektu, stručného popisu a popisu role subjektu

k vyvíjenému informačnímu systému. Seznam se nachází v Tabulce 5. Tabulka 5 - Seznam subjektů

NÁZEV

POPIS

ODPOVĚDNOST

Majitel poradny

Majitel poradny, v jehož zájmu je úspěšnost informačního systému

Zaměstnanec poradny

Zaměstnanci, kteří budou aktivně pracovat s informačním systémem

Schvaluje uživatelské rozhraní a specifikuje požadavky na informační systém, definuje akceptační testy Specifikace požadavků na uživatelské rozhraní, vytváří jídelníčky pro klienty, sepisuje články, spravuje galerii

Klient

Klienti jsou zákazníci poradny, kteří budou využívat některé funkce, které systém nabízí – např. zobrazení jídelníčku

4.2.2

Uživatelské rozhraní V této podkapitole jsou definovány základní požadavky na vyvíjený informační systém

z hlediska jeho uživatelů. Systém musí pracovat ve webovém prostředí, je nutné, aby umožňoval přístup z jakéhokoli současného prohlížeče a z jakéhokoliv počítače, který má přístup na internet. Současně by měl systém být schopen obsloužit neomezený počet uživatelů, samozřejmě v rámci možnosti propustnosti a kapacity linky. Systém bude rozdělen z hlediska rolí uživatelů do třech částí, a to administrátorské, klientské a veřejné. Po identifikaci uživatelovy role (přihlášením) mu systém zobrazí patřičné uživatelské rozhraní. V administrátorské části bude mít uživatel přístup ke správě číselníku potravin, možnost vytvářet a spravovat články, spravovat galerii, vkládat fotky, tvořit recepty, zakládat a upravovat klienty, vytvářet jídelníčky a pohybové plány. 15

V klientské sekci si bude uživatel moci prohlédnout své přiřazené jídelníčky, pohybové plány a průběh svého dietního programu. Veřejná část bude k dispozici všem (i anonymním, respektive nepřihlášeným) uživatelům. V této části budou moci uživatelé číst články a recepty, které byly vloženy prostřednictvím administrátorské sekce a stejně tak prohlížet fotky. Dále budou moci získat informace o poradně, případně zjistit kontakt na její zaměstnance.

4.3 Přehled produktu Tato kapitola obsahuje Požadavky a funkce. V těch jsou definovány klíčové požadavky na informační systém z hlediska jeho funkcionality a slouží jako základ pro souhrn požadavků a případy užití. Všechny požadavky jsou vytvořeny v úzké spolupráci se zákazníkem.

4.3.1

Požadavky a funkce Následující Tabulka 6 obsahuje seznam požadavků. Jejich priority jsou v rozmezí 1 až 5, kde 1

je nejvyšší a 5 nejnižší priorita. Obvykle tato tabulka obsahuje ještě Datum spuštění u požadavků, které jsem z důvodu úspory místa vynechal (navíc všechny požadavky mají datum spuštění květen 2014).

Tabulka 6 - Seznam požadavků a funkcí

POŽADAVEK

PRIORITA

Přihlašování uživatelů

PODROBNÝ POPIS Uživatelé budou autentizováni a dle jejich uživatelského

1

jména a hesla. Po úspěšné autentizaci jim bude přidělena odpovídající role (klient, nebo zaměstnanec).

Možnost tvorby a úpravy vlastních

Systém umožní oprávněným uživatelům (zaměstnancům 2

receptů Tvorba a úprava jídelníčků pro klienty

skládat jídelníčky. 1

Rozšiřitelná databáze ingrediencí

poradny) tvorbu a úpravu receptů, ze kterých se poté budou

Zaměstnanci poradny budou moci z databáze receptů vytvořit jídelníčky, které potom přiřadí konkrétním klientům. Zaměstnancům bude umožněno prostřednictvím

3

uživatelského rozhraní rozšiřovat a upravovat existující databázi ingrediencí.

16

Registrace a správa klientů Tvorba a úpravy cvičebních plánů Psaní a úprava článků pro veřejnost

1

3

4

Vytváření fotogalerií a vkládání fotek

Zaměstnanci budou moci zakládat a následně upravovat klienty poradny. Systém umožní zaměstnancům vytvářet a upravovat cvičební plány pro jednotlivé klienty. Zaměstnancům bude umožněno psát a publikovat (na veřejnou část systému) články o zdravé výživě. Zaměstnanci budou moci vytvářet a upravovat fotogalerie a

4

vkládat do nich fotky. Tyto galerie pak budou viditelné ve veřejné části systému.

Prohlížení klientských jídelníčků Prohlížení svého cvičebního plánu

1

3

Získání informací o průběhu dietního

Klienti si budou moci zobrazit jídelníčky, které jim byly přiděleny zaměstnancem poradny. Klienti si budou moci prohlížet svůj cvičební plán, který jim byl vytvořen zaměstnancem poradny. Systém klientům umožní zobrazení průběhu jejich dietního

2

plánu sestaveného z výsledků pravidelných kontrol.

programu Získání informací o naplánovaných

Klienti se budou moci z webu dozvědět termíny 4

naplánovaných schůzek.

schůzkách Prohlížení fotogalerie Čtení článků

4

4

Všichni (i anonymní) uživatelé budou moci prohlížet fotky nahrané zaměstnanci poradny. Všichni (i anonymní) uživatelé budou moci číst články napsané zaměstnanci poradny.

17

5 Požadavky Tato kapitola vychází z předpisu dokumentu Požadavky dle metodiky MMSP. Jsou zde podrobněji popsány požadavky na vyvíjený informační systém a to jak funkční a nefunkční požadavky, tak požadavky na rozhraní, obchodní pravidla, atd. Zároveň tato kapitola, respektive tento dokument, je základem pro Případy užití, kde jsou podrobně rozepsány scénáře a průběhy funkčních požadavků. Jak již bylo avizováno, požadavky jsou vytvořeny na základě požadavků zákazníka.

5.1 Funkční požadavky Kapitola Funkční požadavky popisuje to, co by měl systém dělat a jaké služby by měl poskytovat svým uživatelům. Vše vychází z vize, konkrétně z části Přehled produktu – Požadavky a funkce. Seznam funkčních požadavků obsahuje Tabulka 7. V kolonce Podrobný popis uveden pouze odkaz na podrobnější popis, který je uveden formou podkapitol.

Tabulka 7 - Seznam funkčních požadavků

ID

NÁZEV POŽADAVKU

PODROBNÝ POPIS

PRIORITA

POŽADAVKU F001 F002

F003

F004

F005

F006

F007

ODKAZ NA PŘÍPAD UŽITÍ

Přihlašování Tvorba a úprava receptů Tvorba a úprava jídelníčků pro klienty Rozšiřitelná databáze potravin Registrace a správa klientů Tvorba a úpravy cvičebních plánů Psaní a úprava článků pro veřejnost

PP001

1

UC001

PP002

2

UC002

PP003

1

UC003

PP004

3

UC004

PP005

1

UC005

PP006

3

UC006

PP007

4

UC007

18

Vytváření fotogalerií a

F008

vkládání fotek Prohlížení klientských

F009

jídelníčků Prohlížení svého

F010

cvičebního plánu

PP008

4

UC008

PP009

1

UC009

PP010

3

UC010

PP011

2

UC011

PP012

4

UC010

Získání informací o F011

průběhu dietního programu Získání informací o

F012

naplánovaných schůzkách

F013

Prohlížení fotogalerie

PP013

4

UC012

F014

Čtení článků

PP014

4

UC013

5.1.1

PP001 Po kliknutí na odkaz pro přihlášení nebo po pokusu o vstup do klientské/administrátorské

sekce, systém přesměruje nepřihlášeného uživatele na přihlašovací stránku. Zde uživatel vyplní své uživatelské jméno a heslo, případně zaškrtne funkci zapamatování hesla. Kombinace jména a hesla bude kontrolována proti databázi. V databázi budou uloženy pouze zabezpečené hashe hesel, uživatelské role a další autorizační prvky dle ASP.NET Membership Frameworku (podrobněji popsáno níže). Po úspěšném přihlášení bude uživatel přesměrován do klientské, respektive administrátorské sekce. Přihlášení uživatele vydrží do zavření webového prohlížeče nebo do kliknutí na odkaz pro odhlášení, a pro udržení informace o uživateli bude systém používat klientské cookies. Pokud uživatel zaškrtl funkci zapamatování přihlášení, bude se moci odhlásit jedině pomocí odkazu na odhlášení. Při neúspěšné autentizaci bude uživatel informován o neplatnosti uživatelského jména nebo hesla. Uživatelské jméno a heslo půjde změnit pouze zaměstnancem poradny.

5.1.2

PP002 Po úspěšném přihlášení jako zaměstnanec poradny (umožněn vstup do administrátorské

sekce) bude uživateli nabídnut odkaz pro správu receptů. 19

První stránka správy receptů se bude skládat z tabulky, ve které budou zobrazeny všechny dostupné recepty v databázi. Sloupce tabulky budou tvořeny názvem receptu, zaškrtávacím tlačítkem, které bude určovat, zda je recept zveřejněn a sloupcem akce, kde budou dvě tlačítka, jedno pro editaci vybraného receptu a druhé pro jeho smazání. Defaultně budou záznamy v tabulce řazeny abecedně s možností řazení změnit. Tato stránka bude také obsahovat textové pole a tlačítko pro vyhledávání receptů dle názvu. Dalším tlačítkem bude tlačítko Přidat pro přidání nového receptu. Po kliknutí na tlačítko Přidat nebo na tlačítko pro editaci receptu bude uživatel přesměrován na druhou stránku tohoto rozhraní. Ta bude obsahovat prázdný (přidat) nebo předvyplněný (editovat) formulář pro přidání, respektive úpravu receptu. Formulář se bude skládat z: 

textového pole pro název receptu



kombobox pro výběr typu receptu (snídaně, svačina, oběd, večeře, jiné)



textové oblasti pro popis receptu



polí pro výběr ingrediencí do receptu



informací o aktuálním složení a energetických hodnotách receptu

Ingrediencí v receptu je neurčitý počet, čili je nutné, aby systém umožnil zadání jedné až n ingrediencí. Ingredience budou vybírány z komboboxů, které umožní zadáním části názvu ingredience rychlé vyhledávání. Dále k výběru ingrediencí bude patřit textové pole pro zápis množství (obvykle v gramech). Po stisknutí tlačítka pro vypočítání energetické hodnoty receptu bude u každé ingredience, v závislosti na množství, uveden její počet (v gramech) tuků, cukrů a bílkovin a stejně tak její energetická hodnota (v kilojoulech). Dále bude na stránce zobrazena celková suma těchto údajů pro aktuální recept a graf s rozložením cukrů, tuků a bílkovin. Systém umožní z této stránky rychlou navigaci na předchozí stránku (s tabulkou) a dále na stránku pro správu ingrediencí. Stisknutím tlačítka odeslat systém uloží nový záznam do databáze, případně upraví stávající.

5.1.3

PP003 Autorizovaní uživatelé (zaměstnanci) budou mít ze svého rozhraní přístup k vytváření jídelníčků

pro konkrétní klienty. Po výběru klienta z jejich seznamu budou zobrazeny záložky se dny v týdnu, ve kterých budou tabulky s listem jídelníčků, které má již klient přiřazeny. Sloupce tabulky budou tvořeny 20

názvem jídelníčku, datem vytvoření, celkovou energetickou hodnotou jídelníčku a sloupcem akcí. Sloupec akcí bude obsahovat tlačítka pro editaci a smazání jídelníčku. Dále zde bude tlačítko přidat pro přidání nového jídelníčku. Po stisknutí tohoto tlačítka, případně po stisknutí editace jídelníčku bude uživatel přesměrován na formulář pro vytváření a úpravu jídelníčků. Tento formulář bude obsahovat: 

textové pole pro zadání názvu jídelníčku



oblasti pro zadávání receptů – celkem 5 oblastí (snídaně, svačina, oběd, svačina, večeře)

Výběr receptů pro zadávací oblasti bude opět formou komboboxů s možností vyhledávání. Recepty v komboboxech budou seřazeny tak, že recepty z příslušné oblasti budou v pořadí jako první (recepty z ostatních oblastí budou však stále k dispozici pro výběr – například do oblasti snídaně bude možné zadat recept z kategorie oběd). Zadávací formulář také umožní opětovné použití již existujících jídelníčků, které jsou přiřazeny k jiným klientům. Po výběru příslušného jídelníčku budou oblasti předvyplněny patřičnými recepty. Opět zde bude tlačítko pro výpočet a zobrazení dodatečných informací, jako je rozložení cukrů, tuků a bílkovin v jídelníčku, či celková energetická hodnota. Každý klient bude mít, v závislosti na jeho dietním programu, přiřazenu optimální hodnotu energie na den. Systém zobrazí graf, který porovná aktuální energetickou hodnotu jídelníčku a optimální hodnotu klienta. Dále bude tento formulář obsahovat rychlou navigaci na předcházející tabulku s jídelníčky klienta a odkaz na správu receptů.

5.1.4

PP004 V rozhraní pro zaměstnance poradny se bude nacházet odkaz na správu databáze ingrediencí.

Z těchto ingrediencí budou potom sestavovány recepty a z těchto receptů poté jídelníčky. Po kliknutí na patřičný odkaz systém zobrazí opět tabulku, ve které bude seznam potravin z databáze. Seznam bude řazený abecedně dle názvu potraviny a bude stránkován po 100 záznamech. Opět zde bude textové pole a tlačítko pro rychlé vyhledávání. Sloupce tabulky budou tvořeny názvem potravin, hodnotou cukrů, tuků a bílkovin ve 100 gramech potraviny a energetickou hodnotou v kilojoulech pro 100 gramů ingredience. Dále zde bude opět sloupec akcí, který bude obsahovat tlačítka pro editaci a mazání potraviny. Na stránce se dále bude nacházet tlačítko přidat.

21

Tlačítka přidat a editovat přesměrují uživatele na zadávací formulář, kde budou textová pole pro zadávání názvu ingredience, její energetické hodnoty pro 100 gramů a objem cukrů, tuků a bílkovin v těchto 100 gramech. Před odesláním formuláře bude zkontrolováno, zda jsou všechna pole vyplněna. Po úspěšné validaci bude záznam uložen do databáze, respektive v ní upraven. Formulář bude obsahovat rychlou navigaci na předcházející stránku.

5.1.5

PP005 Systém umožní zaměstnancům zakládat nové klienty, případně upravovat informace o

klientech stávajících. V uživatelském rozhraní zaměstnanců poradny bude odkaz na správu klientů. Správa klientů bude opět reprezentována tabulkou, která bude tvořena jménem a příjmením jednotlivých klientů a checkboxem, který určí, zda je klient aktivní (aktuální klient poradny). Klienti budou seřazeni nejprve dle toho, zda jsou aktivní, a poté podle jejich příjmení. Tabulka bude dále obsahovat sloupec akcí pro editaci a smazání klienta a dále tlačítka pro přiřazení cvičebních plánů a schůzek, jídelníčků a vložení výsledků pravidelných kontrol. Tato stránka bude dále obsahovat tlačítko pro přidání nového klienta a samozřejmě také textové pole a tlačítko pro vyhledávání dle příjmení. Odkazy na přidání, respektive editaci klienta povedou na druhou stránku tohoto rozhraní. Toto rozhraní bude obsahovat zadávací a editovací formulář. Údaje pro tento formulář budou získávány na úvodní schůzce mezi klientem a zaměstnancem poradny. Formulář bude obsahovat zadání jména, příjmení, pohlaví, věku, uživatelského jména pro identifikaci v tomto systému, emailu, výšky, váhy, cílové váhy a sportovní aktivity (lehká, střední, vysoká). Heslo bude generováno systémem při založení uživatele. Editovací verze formuláře bude obsahovat tlačítko pro vygenerování hesla nového. Po odeslání formuláře bude klient založen, respektive upraven v databázi. Tato stránka bude také obsahovat rychlou navigaci na stránku předcházející.

5.1.6

PP006 Ze seznamu klientů pomocí tlačítka ze sloupce akce bude moci zaměstnanec přiřadit klientům

cvičební plán. Po stisknutí tohoto tlačítka bude zaměstnanec přesměrován na zadávací formulář.

22

Tento formulář bude obsahovat scheduler (kalendář) komponentu, kde bude moci zaměstnanec vytvářet události pro cvičební plán. Stejný formulář bude použit i pro plánování schůzek. Události budou po vytvoření uloženy v databázi.

5.1.7

PP007 V administrátorském menu zaměstnance bude odkaz pro správu článků. Správa článků bude

opět tvořena dvěma stránkami. První stránka bude obsahovat tabulku všech napsaných článků. Tabulka bude tvořena sloupci s datem vytvoření, názvem článku, checkboxem, zda je článek publikován, a sloupcem akcí. V sloupci akcí bude tlačítko pro editaci a tlačítko pro smazání článku. Dále bude na této stránce textové pole pro vyhledávání dle názvu článku a tlačítko přidat. Odkazy z tlačítek přidat a editovat povedou na druhou stránku rozhraní. Ta bude obsahovat zadávací formulář. Součástí tohoto formuláře bude: 

textové pole pro datum



textové pole pro název článku



zaškrtávací tlačítko pro publikování



textová oblast pro abstrakt článku



textová oblast pro článek

Textové pole s datem bude předvyplněno, v případě nového článku, aktuálním dnem. Po kliknutí do tohoto pole se zobrazí kalendář, ve kterém bude moci zaměstnanec vybrat datum dle libosti. Textová oblast pro psaní článku bude editovatelná pomocí WYSIWYG editoru (what you see is what you get, což je editor, který poskytuje funkce pro psaní podobné, jako jsou v MS Wordu). Do databáze se tyto styly budou ukládat pomocí HTML tagů. Bude-li zaškrtnuto publikovat tlačítko, bude tento článek přístupný z veřejné sekce.

5.1.8

PP008 Zaměstnancům poradny systém poskytne rozhraní pro správu galerií. Tato správa se bude opět

skládat z několika stránek, tentokrát ze tří. První stránkou bude tabulka se seznamem všech galerií v databázi. Sloupce tabulky budou složené z názvu galerie, data vytvoření galerie, zaškrtávacího tlačítka, které bude určovat, zda je galerie zveřejněna, a ze sloupce akcí. Sloupec akcí bude obsahovat tlačítka pro editaci galerie, smazání galerie 23

a pro správu obrázků v galerii. Dále bude na stránce vyhledávací pole, které bude hledat dle názvu galerie a tlačítko Přidat. Druhá stránka, na kterou se zaměstnanec dostane po pomocí tlačítek editovat, či přidat, bude obsahovat zadávací formulář pro údaje o galerii. Tento formulář se bude skládat z: 

textového pole pro název galerie



textového pole pro datum galerie



zaškrtávacího tlačítka pro určení, zda má být galerie zveřejněna

Po kliknutí do pole pro zadávání data vyjede uživateli kalendář. Pole bude předvyplněno aktuálním dnem. Po odeslání formuláře bude v databázi vytvořena nová galerie a uživatel bude přesměrován zpět na seznam, odkud bude moci kliknout na tlačítko pro přidání nových fotek do galerie. Toto tlačítko odkáže uživatele na třetí stránku rozhraní. Toto rozhraní bude obsahovat vyobrazení všech obrázků galerie. U každého obrázku bude tlačítko smazat, které obrázek případně smaže. Dále zde bude tlačítko pro přidání obrázků. Stisknutí tohoto tlačítka otevře dialogové okno pro výběr souborů. Uživatel bude moci vybrat i několik obrázků najednou a potvrzením se okno zavře a vybrané obrázky se nahrají na server. Do databáze se uloží pouze odkazy na obrázky, které budou nahrány do speciální složky aplikace. Poté se aktualizuje seznam obrázků.

5.1.9

PP009 Uživatel, který po přihlášení získá status klient, bude mít pomocí svého rozhraní přístup

k jídelníčkům, které mu přiřadil zaměstnanec poradny. Toto rozhraní bude tvořeno jednou stránkou, ve které bude vyobrazen jeho jídelníček. Stránka bude obsahovat záložky pro dny v týdnu (od pondělí do neděle). Po vybrání patřičného dne se uživateli zobrazí nejnověji přiřazený jídelníček na ten den. Zároveň zde bude kombobox pro výběr starších jídelníčků.

5.1.10 PP010 Systém umožní klientům, prostřednictvím rozhraní, prohlížení jejich cvičebních plánů. Po kliknutí na patřičný odkaz bude uživateli zobrazen jeho cvičební plán formou kalendáře s událostmi (scheduler). V tomto kalendáři se také budou nacházet naplánované schůzky. Scheduler bude 24

zobrazený s týdenní granularitou a bude standardně nastaven na aktuální týden. Uživatel nebude moci upravovat naplánované události (ty budou naplánovány společně se zaměstnancem poradny na pravidelné kontrole).

5.1.11 PP011 Klient si bude moci zobrazit průběžný stav svého dietního programu. Po každé pravidelné kontrole zadá zaměstnanec do systému údaje, které naměřil (váha, výška, …). Tyto údaje bude zadávat pomocí tlačítka ve sloupci akcí v rozhraní pro správu klientů (stránka se seznamem klientů). Klient poté po kliknutí na patřičný odkaz obdrží report výsledků těchto kontrol jak v textové (tabulka), tak v grafické podobě (graf). Textová podoba bude pouze seznam naměřených hodnot s daty měření. Grafická podoba se bude skládat ze sloupcového grafu.

5.1.12 PP012 Získávání informací o naplánovaných schůzkách bude probíhat stejně jako získávání informací o cvičebním plánu (PP010). Bude se jednat o stejné rozhraní.

5.1.13 PP013 Systém bude zobrazovat fotky ze zveřejněných fotogalerií všem návštěvníkům webové prezentace v několika formách. Zaprvé v hlavičce stránky bude zobrazeno posledních 10 zveřejněných fotek nezávisle na galerii, do které patří. Tyto fotky budou obsahovat odkaz na stránku se svojí galerií. Mezi těmito fotkami bude systém plynule listovat. Dále budou mít všichni uživatelé v menu k dispozici odkaz na zveřejněné fotogalerie. Tato stránka bude obsahovat jejich seznam, který bude vypadat formou gridu, kde jedna buňka bude tvořena názvem galerie a její nejnovějším obrázkem. Po kliknutí na obrázek nebo na název bude uživatel přesměrován na stránku, která bude vypadat podobně, ale bude obsahovat všechny fotky galerie. Po kliknutí na libovolný obrázek bude tento obrázek zvětšen pro bližší prohlížení.

25

5.1.14 PP014 Všichni uživatelé budou mít umožněno čtení publikovaných článků o zdravé výživě. Po dostání se na stránku s články pomocí rychlé navigace odkudkoli ze systému bude zobrazen seznam článků, který se bude skládat z jejich názvu, abstraktu a data publikace. Uživatelé budou moci kliknout na název článku a budou přesměrováni na celý článek. Zároveň bude odkaz na nejnovější článek zobrazen v domovské sekci webové prezentace.

5.2 Nefunkční požadavky Nefunkční požadavky, neboli také požadavky na kvalitu, specifikují věci typu Podpora, Spolehlivost, Použitelnost a Výkon. Požadavky, které nesouvisí přímo s tím, co má systém vykonávat, jsou zaznamenány v této kapitole. Vzhledem k omezeným zdrojům a závislosti na externím hostingu jsem vynechal požadavky na podporu a výkon.

5.2.1

Použitelnost Tato podkapitola se věnuje požadavkům na například lokalizaci systému, zda používat nějaké

zavedené standardy pro jeho ovládání, jak zajistit intuitivnost ovládání, atd. Seznam požadavků je v Tabulce 8.

Tabulka 8 - Seznam požadavků Použitelnosti

ID

NÁZEV

PODROBNÝ POPIS

PRIORITA

1

POŽADAVKU POŽADAVKU PO001

Lokalizace

Systém bude lokalizován v českém jazyce

PO002

Odeslání

Tlačítko pro odeslání formuláře bude umístěno

formuláře

v pravém dolním rohu formuláře

5.2.2

1

Spolehlivost Zde (Tabulka 9) jsou vypsány požadavky na spolehlivost systému, jako je např. limit pro závažné

a méně závažné chyby po nasazení, maximální doba obnovy při havárii, atp.

26

Tabulka 9 - Seznam požadavků na Spolehlivost

ID

NÁZEV

PODROBNÝ POPIS

PRIORITA

POŽADAVKU POŽADAVKU SP001

Závažné chyby

Systém bude po nasazení obsahovat nejvýše jednu závažnou chybu (závažné chyby jsou takové, které

1

nedovolí pokračování v rozdělané činnosti) SP002

SP003

Obnova po

Maximální doba obnovy systému při jeho výpadku je

havárii

12 hodin od nahlášení

Zálohování

Databáze klientů bude zálohována každý den

databáze

v 01:00 hodin

1

1

5.3 Rozhraní Zde jsou uvedeny požadavky jak na uživatelské rozhraní (GUI), tak na rozhraní pro napojení na externí systémy.

5.3.1

Uživatelské rozhraní Podkapitola specifikuje požadavky na grafické uživatelské rozhraní. Z této kapitoly jsem

vynechal požadavky na personalizaci z důvodu, že uživatelé si nebudou moci přizpůsobovat uživatelské rozhraní. 5.3.1.1

Vzhled V této podkapitole jsou sepsány požadavky na tzv. Look and Feel aplikace (Tabulka 10).

Tabulka 10 - Seznam požadavků na vzhled

ID

NÁZEV

PODROBNÝ POPIS

PRIORITA

POŽADAVKU

POŽADAVKU

VHZ001

Zelená barva

Systém bude stylizován do zelené barvy

1

VHZ002

Čitelnost

Výběr písma a barevných kombinací bude proveden s ohledem na osoby se zhoršenou

2

schopností rozpoznávání barev a vidění

27

5.3.1.2

Rozložení a navigace Zde jsou sepsány základní požadavky na rozložení ovládacích prvků uživatelského rozhraní

(Tabulka 11). Hrubé návrhy obrazovek jsou zobrazeny v kapitole Návrhy obrazovek.

Tabulka 11 - Seznam požadavků na Rozložení a navigaci

ID

NÁZEV

PODROBNÝ POPIS

PRIORITA

POŽADAVKU POŽADAVKU ROZ001

Hlavní menu

Hlavní menu bude horizontálního typu a nebude se měnit v závislosti na identitě uživatelů

ROZ002

Submenu

2

Submenu bude vertikální a bude se měnit v závislosti na uživatelích (zaměstnanec poradny bude mít jiné submenu než klient, případně než

1

nepřihlášený uživatel) ROZ003

Optimalizace

Uživatelské rozhraní musí zobrazovat všechny

pro rozlišení

důležité informace bez výrazného scrollování již při

2

rozlišení obrazovky 1366x768 pixelů

5.3.1.3

Konzistence V této části jsou uvedeny požadavky na systém z hlediska konzistence (Tabulka 12) v jeho

ovládání (například zda se má ovládat jako jiný, podobný systém).

Tabulka 12 - Seznam požadavků Konzistence

ID

NÁZEV

PODROBNÝ POPIS

POŽADAVKU

POŽADAVKU

KON001

Webová

Ovládání systému musí být podobné, jako je

aplikace

ovládání dnešních klasických webových aplikací (navigace pomocí odkazů, automatická

PRIORITA

1

přesměrovávání, potvrzení vpravo, …)

5.3.2

Rozhraní na externí systémy nebo zařízení Tato kapitola obsahuje požadavky na napojení vyvíjeného systému na systémy existující

(definice protokolů, požadavky na komunikační síť, definování komunikačního rozhraní, …). 28

Tento systém nebude v úvodní verzi napojen na žádný externí systém. V budoucnu se počítá s napojením mobilní verze na tento systém. Komunikační rozhraní bude nejspíše realizováno pomocí webových služeb.

5.4 Systémová omezení Zde (Tabulka 13) jsou definovány požadavky na pravidla a omezení z hlediska návrhu, implementace a zavedení systému (programovací jazyk, databáze, implementační prostředí, …).

Tabulka 13 - Seznam Systémových omezení

ID

NÁZEV

PODROBNÝ POPIS

PRIORITA

POŽADAVKU POŽADAVKU SYS001

Webová

Systém bude realizován formou webové aplikace

aplikace

v jazyce ASP.NET Framework 4.0

SYS002

Databáze

Databáze bude MSSQL 2008

1

SYS003

Externí hosting

Systém bude vystaven na webovém hostingu web4u

1

1

29

6 Případy užití Kapitola Případy užití se zabývá podrobnými scénáři užití systému. Základ, ze kterého tyto scénáře vycházejí je podrobný popis požadavků z kapitoly Požadavky – Funkční požadavky.

6.1 Definice aktérů V Tabulce 14 jsou vypsáni aktéři, kteří se vyskytují v případech užití, a kteří nějakým způsobem interagují se systémem.

Tabulka 14 - Seznam aktérů

NÁZEV

POPIS AKTÉRA

AKTÉRA Zaměstnanec Zaměstnanec je zaměstnancem poradny (případně její majitel). Obsluhuje administrátorskou část systému, která se skládá ze správy klientů, receptů, jídelníčků, schůzek a cvičebních plánů, vystavování foto galerií a článků o zdravé výživě. Zaměstnanec má přístup do všech sekcí systému. Klient

Klient je zákazník poradny (ať už stávající nebo bývalý). Klient má přístup do veřejné a klientské sekce systému. V klientské sekci může zobrazovat své jídelníčky, schůzky a pohybové plány. Dále má přístup k reportům průběhu svého dietního programu.

Anonymní

Anonymní uživatel je jakýkoli nepřihlášený návštěvník webové aplikace. Má přístup

uživatel

pouze do veřejné sekce, kde si může prohlížet fotogalerie, či číst články. Dále může na webu získat základní informace o poradně.

6.2 Specifikace případů užití Specifikace případů užití podrobně rozepisuje scénář pro funkční požadavky vyjmenované ve stejnojmenné kapitole. Tabulka je převzata ze šablony metodiky MMSP. Alternativní scénář pomocí čísla kroku může navazovat na příslušný krok scénáře základního.

30

6.2.1

Diagram případů užití Následující diagram (Obrázek 4) souhrnně zobrazuje všechny případy užití, které jsou pak

rozepsány v tabulkách níže. Panáčci reprezentují aktéry a bublinky činnosti, které jednotliví aktéři vykonávají.

Obrázek 4 - Schéma případů užití

31

6.2.2

Přihlašování uživatelů Tabulka 15 - Přihlašování uživatelů

NÁZEV PU

Přihlašování uživatelů

IDENTIFIKACE PU

UC001

IDENTIFIKACE

F001

FUNKČNÍHO POŽ. CÍL PU

Přihlášení uživatele do systému

PRIMÁRNÍ AKTÉŘI

Anonymní uživatel

POMOCNÍ AKTÉŘI VSTUPNÍ PODMÍNKY

Uživatel existuje v systému (byl zaregistrován zaměstnancem poradny).

VÝSTUPNÍ PODMÍNKY

Přihlášený uživatel

ZÁKLADNÍ SCÉNÁŘ

Krok

Role

Akce

1

Anonymní

Kliknutí na odkaz pro přihlášení do

uživatel

systému

Systém

Přesměrování uživatele na přihlašovací

2

obrazovku 3

4

Anonymní

Vyplnění polí pro uživatelské jméno a

uživatel

heslo

Anonymní

Stisknutí tlačítka Přihlásit

uživatel 5

Systém

Kontrola vyplnění obou polí

6

Systém

Kontrola přihlašovacích údajů proti databázi

7

Systém

Přihlášení uživatele, přidělení patřičné role uživateli, povolení vstupu do příslušných sekcí

ALTERNATIVNÍ

Krok

Role

Akce

SCÉNÁŘ

6

Systém

Zobrazení zprávy uživateli o neplatnosti jeho uživatelských údajů

7

Anonymní

Návrat na krok 3 základního scénáře

uživatel

32

Krok

Role

Akce

5

Systém

Zobrazení zprávy uživateli o nevyplnění povinných polí (jména nebo hesla)

6

Anonymní


uživatel

33

6.2.3

Tvorba a úprava receptů Tabulka 16 - Tvorba a úprava receptů

NÁZEV PU

Tvorba a úprava receptů

IDENTIFIKACE PU

UC002

IDENTIFIKACE

F002


Recept v databázi, připravený na použití

PRIMÁRNÍ AKTÉŘI

Zaměstnanec


Přihlášený uživatel jako zaměstnanec poradny, existence databáze potravin

VÝSTUPNÍ PODMÍNKY ZÁKLADNÍ SCÉNÁŘ

Systém připraven na další požadavek Krok

Role

Akce

1

Zaměstnanec

Kliknutí na odkaz pro správu receptů

2

Systém

Přesměrování uživatele na stránku se správou receptů

3

Zaměstnanec

Kliknutí na tlačítko Přidat, nebo nalezení receptu pro úpravu a kliknutí na tlačítko Editovat

4

Systém

Přesměrování uživatele na zadávací formulář

5

Zaměstnanec

Vyplnění polí formuláře (název receptu, zda je recept veřejný, popis receptu a výběr ingrediencí + vyplnění množství každé ingredience)

6

Zaměstnanec

Kliknutí na tlačítko Odeslat

7

Systém

Validace formuláře – všechna pole, kromě popisu receptu jsou povinná

8

Systém

Přidání nebo úprava receptu v databázi

9

Systém

Přesměrování uživatele na stránku s tabulkou receptů

34

ALTERNATIVNÍ

Krok

Role

Akce

SCÉNÁŘ

8

Systém

Zobrazení zprávy o neúspěšnosti validace a výzvě k opravě příslušných polí

9

Zaměstnanec


Krok

Role

Akce

6

Zaměstnanec

Kliknutí na tlačítko Vypočítej

7

Systém

Zobrazení energetických hodnot a hodnot bílkovin, cukrů a tuků, zobrazení grafu poměru bílkovin, cukrů a tuků v receptu

8

Zaměstnanec


35

6.2.4

Tvorba a úprava jídelníčků pro klienty Tabulka 17 - Tvorba a úprava jídelníčků pro klienty

NÁZEV PU

Tvorba a úprava jídelníčků pro klienty

IDENTIFIKACE PU

UC003

IDENTIFIKACE

F003


Jídelníček sestavený a přiřazený klientovi

PRIMÁRNÍ AKTÉŘI

Zaměstnanec


Přihlášený uživatel jako zaměstnanec poradny, existence klienta v databázi, existence databáze receptů



Role

Akce

1

Zaměstnanec

Kliknutí na odkaz pro správu klientů

2

Systém

Přesměrování uživatele na stránku se správou klientů

3

Zaměstnanec

Nalezení klienta pro přiřazení jídelníčku a kliknutí na tlačítko Přiřadit jídelníček

4

Systém

Přesměrování uživatele na tabulku se seznamem přiřazených jídelníčků

5

Zaměstnanec

Výběr záložky se dnem, na který je jídelníček tvořen, kliknutí na tlačítko Přidat, nebo výběr jídelníčku a kliknutí na tlačítko Editovat

6

Systém

Přesměrování uživatele na zadávací formulář, výpočet optimálních hodnot cukrů, tuků, bílkovin a energie klienta ze vzorců dodaných poradnou

7

Zaměstnanec

Vyplnění polí formuláře (název jídelníčku, výběr receptů z komboboxů pro každou sekci (snídaně, oběd, večeře, svačina), ze kterých se jídelníček skládá), případně výběr již hotového jídelníčku jako šablony pro předvyplnění (výběr z komboboxu)

36

8

Zaměstnanec

Odeslání formuláře

9

Systém

Validace formuláře – název je povinný

10

Systém

Přidání nebo úprava jídelníčku v databázi

11

Systém

Přesměrování uživatele na stránku se seznamem jídelníčků

ALTERNATIVNÍ

Krok

Role

Akce

SCÉNÁŘ

10

Systém


11

Zaměstnanec


Krok

Role

Akce

8

Zaměstnanec

Stisknutí tlačítka Vypočítej

9

Systém

Zobrazení informací u každé sekce jídelníčku o energetické hodnotě receptu a o poměru cukrů, bílkovin a tuků, zobrazení porovnání celkové energetické hodnoty jídelníčku a hodnot cukrů, bílkovin a tuků s vypočítanými optimálními hodnotami pro klienta

10

Zaměstnanec


37

6.2.5

Rozšíření a úprava databáze ingrediencí Tabulka 18 - Rozšíření a úprava databáze ingrediencí

NÁZEV PU

Rozšíření a úprava databáze ingrediencí

IDENTIFIKACE PU

UC004

IDENTIFIKACE

F004


Databáze ingrediencí připravena na použití pro recepty

PRIMÁRNÍ AKTÉŘI

Zaměstnanec


Přihlášený uživatel jako zaměstnanec poradny


Systém připraven na další požadavek


Krok

Role

Akce

1

Zaměstnanec

Kliknutí na odkaz pro správu ingrediencí

2

Systém

Přesměrování uživatele na stránku se správou ingrediencí

3

Zaměstnanec

Kliknutí na tlačítko Přidat, nebo nalezení potraviny pro úpravu a kliknutí na tlačítko Editovat

4

Systém


5

Zaměstnanec

Vyplnění polí formuláře (název potraviny, energetická hodnota, množství tuků, cukrů a bílkovin ve 100 gramech), kliknutí na tlačítko Odeslat

6

Systém

Validace formuláře - všechna pole jsou povinná, energie, cukry, tuky a bílkoviny musí být čísla

7

Systém

Přidání nebo úprava potraviny v databázi

8

Systém

Přesměrování uživatele na stránku s tabulkou potravin

38

ALTERNATIVNÍ SCÉNÁŘ

Krok

Role

Akce

7

Systém


8

Zaměstnanec


39

6.2.6

Registrace a správa klientů Tabulka 19 - Registrace a správa klientů

NÁZEV PU

Registrace a správa klientů

IDENTIFIKACE PU

UC005

IDENTIFIKACE

F005


Zaregistrovaný klient poradny

PRIMÁRNÍ AKTÉŘI

Zaměstnanec






Krok

Role

Akce

1

Zaměstnanec


2

Systém


3

Zaměstnanec

Kliknutí na tlačítko Přidat, nebo nalezení klienta pro úpravu a kliknutí na tlačítko Editovat

4

Systém


5

Zaměstnanec

Vyplnění polí formuláře (jméno, příjmení, uživatelské jméno, věk, výška, váha, cílová váha, pohlaví (výběr z komboboxu), sportovní aktivita (výběr z komboboxu – nízká, střední, vysoká), zaškrtnutí, zda je klient aktivní), heslo je generováno automaticky)

6

Systém

Validace formuláře – všechna pole jsou povinná, věk, váha, výška a cíl jsou čísla

7

Systém

Přidání nebo úprava klienta v databázi

8

Systém

Přesměrování uživatele na stránku s tabulkou klientů

40


Krok

Role

Akce

7

Systém


8

Zaměstnanec


41

6.2.7

Tvorba a úprava cvičebních plánů a plánů schůzek Tabulka 20 - Tvorba a úprava cvičebních plánů a plánů schůzek

NÁZEV PU

Tvorba a úprava cvičebních plánů a plánů schůzek

IDENTIFIKACE PU

UC006

IDENTIFIKACE

F006


Cvičební plán nebo schůzka sestaveny a přiřazeny klientovi

PRIMÁRNÍ AKTÉŘI

Zaměstnanec


Přihlášený uživatel jako zaměstnanec poradny, existence klienta v databázi



Role

Akce

1

Zaměstnanec


2

Systém


3

Zaměstnanec

Nalezení klienta pro přiřazení cvičebního lánu a kliknutí na tlačítko Přiřadit cvičební plán nebo schůzku

4

Systém

Přesměrování uživatele na kalendář s cvičebními plány a schůzkami

5

Zaměstnanec

Výběr příslušného termínu a vytvoření nové události druhu Cvičební plán (kliknutí na vybranou oblast otevře popup s poli pro název události a výběru typu události)

6

Systém

Vložení cvičebního plánu do databáze

7

Zaměstnanec

Stisknutí tlačítka Zpátky pro návrat na seznam klientů


Krok

Role

Akce

5

Zaměstnanec

Výběr příslušného termínu a vytvoření nové události druhu Schůzka

6

Systém

Vložení schůzky do databáze

42

7

Zaměstnanec

Stisknutí tlačítka Zpátky pro návrat na seznam klientů

43

6.2.8

Psaní a úprava článků pro veřejnost Tabulka 21 - Psaní a úprava článků pro veřejnost

NÁZEV PU

Psaní a úprava článků pro veřejnost

IDENTIFIKACE PU

UC007

IDENTIFIKACE

F007


Publikovaný článek do veřejné části systému

PRIMÁRNÍ AKTÉŘI

Zaměstnanec






Krok

Role

Akce

1

Zaměstnanec

Kliknutí na odkaz pro správu článků

2

Systém

Přesměrování uživatele na stránku se správou článků

3

Zaměstnanec

Kliknutí na tlačítko Přidat, nebo nalezení článku pro úpravu a kliknutí na tlačítko Editovat

4

Systém


5

Zaměstnanec

Vyplnění polí formuláře (název, datum, zda je článek veřejný, abstrakt a text), kliknutí na tlačítko odeslat

6

Systém

Validace formuláře – všechna pole jsou povinná

7

Systém

Přidání nebo úprava článku v databázi

8

Systém

Přesměrování uživatele na stránku s tabulkou článků


Krok

Role

Akce

7

Systém


8

Zaměstnanec


44

6.2.9

Vytváření fotogalerií a vkládání fotek Tabulka 22 - Vytváření fotogalerií a vkládání fotek

NÁZEV PU

Vytváření fotogalerií a vkládání fotek

IDENTIFIKACE PU

UC008

IDENTIFIKACE

F008


Publikované fotografie do veřejné části systému

PRIMÁRNÍ AKTÉŘI

Zaměstnanec






Krok

Role

Akce

1

Zaměstnanec

Kliknutí na odkaz pro správu galerií

2

Systém

Přesměrování uživatele na stránku se správou galerií

3

Zaměstnanec

Nalezení příslušné galerie a kliknutí na tlačítko Přidat obrázky do galerie

4

Systém

Přesměrování uživatele na stránku pro zadávání fotek

5

Zaměstnanec

Kliknutí na tlačítko Přidat

6

Systém

Otevření dialogového okna pro výběr souborů

7

Zaměstnanec

Výběr fotek a potvrzení

8

Systém

Validace zda fotky splňují požadovaný formát a velikost

9

Systém

Nahrání fotek do odpovídající složky na serveru a umístění odkazu na ně do databáze

10

Zaměstnanec

Stisknutí tlačítka Zpátky pro návrat na tabulku s fotogaleriemi

45

ALTERNATIVNÍ

Krok

Role

Akce

SCÉNÁŘ

9

Systém

Zobrazení zprávy o neúspěšnosti validace a výzvě k novému výběru

8

Zaměstnanec


Krok

Role

Akce

3

Zaměstnanec

Kliknutí na tlačítko Přidat nebo nalezení příslušné galerie a kliknutí na tlačítko Editovat

4

Systém


5

Zaměstnanec

Vyplnění polí formuláře (název, datum, zda je galerie veřejná), kliknutí na tlačítko odeslat

6

Systém

Validace formuláře – všechna pole jsou povinná

7

Systém

Přidání nebo úprava galerie v databázi

8

Systém

Přesměrování uživatele na stránku s tabulkou galerií

46

6.2.10 Prohlížení klientských jídelníčků Tabulka 23 - Prohlížení klientských jídelníčků

NÁZEV PU

Prohlížení klientských jídelníčků

IDENTIFIKACE PU

UC009

IDENTIFIKACE

F009


Klient informovaný o svém jídelníčku

PRIMÁRNÍ AKTÉŘI

Klient


Přihlášený uživatel jako klient, existence jídelníčku vytvořeného zaměstnancem



ZÁKLADNÍ SCÉNÁŘ Krok

Role

Akce

1

Klient

Kliknutí na odkaz pro čtení jídelníčků

2

Systém

Přesměrování uživatele na stránku s jídelníčky

3

Klient

Výběr dne ze záložky

4

Klient

Přečtení aktuálního jídelníčku


Krok

Role

Akce

3

Klient

Výběr z komboboxu dřívějších jídelníčků

4

Klient

Přečtení dřívějšího jídelníčku

47

6.2.11 Prohlížení klientských cvičebních plánů a schůzek Tabulka 24 - Prohlížení klientských cvičebních plánů a schůzek

NÁZEV PU

Prohlížení klientských cvičebních plánů a schůzek

IDENTIFIKACE PU

UC010

IDENTIFIKACE

F010, F012


Klient informovaný o svém cvičebním plánu a naplánovaných schůzkách

PRIMÁRNÍ AKTÉŘI

Klient


Přihlášený uživatel jako klient, existence cvičebního plánu nebo schůzky vytvořených zaměstnancem




Role

Akce

1

Klient

Kliknutí na odkaz pro prohlížení plánů

2

Systém

Přesměrování uživatele na stránku s kalendářem obsahujícím plány

3

Klient

Přečtení cvičebního plánu či schůzky


48

6.2.12 Získání informací o průběhu dietního programu Tabulka 25 - Získání informací o průběhu dietního programu

NÁZEV PU

Získání informací o průběhu dietního programu

IDENTIFIKACE PU

UC011

IDENTIFIKACE

F011


Klient informovaný o průběhu svého programu

PRIMÁRNÍ AKTÉŘI

Klient


Přihlášený uživatel jako klient, informace z minimálně úvodní schůzky zadány do systému zaměstnancem poradny




Role

Akce

1

Klient

Kliknutí na odkaz pro report průběhu

2

Systém

Přesměrování uživatele na stránku s reportem

3

Klient

Přečtení reportu (tabulka měření a graf porovnávající naměřenou a cílovou hodnotu)


49

6.2.13 Prohlížení fotogalerií Tabulka 26 - Prohlížení fotogalerií

NÁZEV PU

Prohlížení fotogalerií

IDENTIFIKACE PU

UC012

IDENTIFIKACE

F013


Uživatel si prohlédl publikované fotky

PRIMÁRNÍ AKTÉŘI

Anonymní uživatel/Klient/Zaměstnanec (dále jen uživatel)


Existence fotogalerie vytvořené zaměstnancem




Krok

Role

Akce

1

Uživatel

Kliknutí na odkaz pro prohlížení fotogalerií

2

Systém

Přesměrování uživatele na stránku s fotogaleriemi

3

Uživatel

Výběr fotogalerie k prohlédnutí

4

Systém

Přesměrování uživatele na stránku s fotkami galerie

5 ALTERNATIVNÍ SCÉNÁŘ

Uživatel

Prohlédnutí fotek

Krok

Role

Akce

4

Systém

Informování uživatele, že vybraná galerie neobsahuje žádné fotky

5

Uživatel

Návrat ke kroku 3 základního scénáře

50

6.2.14 Čtení článků Tabulka 27 - Čtení článků

NÁZEV PU

Čtení článků

IDENTIFIKACE PU

UC013

IDENTIFIKACE

F014


Uživatel si přečetl článek

PRIMÁRNÍ AKTÉŘI

Anonymní uživatel/Klient/Zaměstnanec (dále jen uživatel)


Existence článku napsaného zaměstnancem




Role

Akce

1

Uživatel

Kliknutí na odkaz pro čtení článků

2

Systém

Zobrazení seznamu článků s jejich abstrakty

3

Uživatel

Kliknutí na nadpis vybraného článku

4

Systém

Přesměrování uživatele na vybraný článek

5

Uživatel

Přečtení článku

ALTERNATIVNÍ

Krok

Role

Akce

SCÉNÁŘ

1

Uživatel

Kliknutí na nadpis posledního vydaného článku na úvodní stránce aplikace

2

Systém

Přesměrování uživatele na tento článek

3

Uživatel

Přečtení článku

51

7 Návrhy obrazovek Na následujících stránkách jsou zobrazeny některé hrubé návrhy obrazovek systému, které vychází z definice požadavků. Návrhy jsou doplněny o lístečky s poznámkami, které obsahují bližší informace o účelu některých umístěných komponent. Z důvodu značné podobnosti některých obrazovek (zvláště obrazovky se seznamem pro správu klientů/potravin/receptů/… jsou prakticky stejné), případně kvůli jejich přímému prototypování s konzultacemi se zákazníkem, nejsou v této kapitole všechny obrazovky z definovaných požadavků, ale pouze jejich výběr.

7.1 Úvodní obrazovka

Obrázek 5 - Úvodní obrazovka

Úvodní obrazovka (Obrázek 5) se zobrazí jako první při zadání čisté webové adresy aplikace, případně po stisknutí tlačítka Domů. Vzhledem k použití konceptu MasterPage je pouze zde zobrazena celá stránka. V následujících návrzích jsou zachyceny pouze vnitřky tzv. PlaceHolderu, což je v případě této stránky pouze úvodní slovo a nejnovější článek. 52

Při pohledu shora a zleva doprava začíná obrazovka logem poradny. Poté následuje odkaz na přihlášení uživatele, který přesměruje anonymního uživatele na stránku s přihlášením. Je-li uživatel přihlášený, místo tohoto odkazu je zde jméno uživatele a odkaz na odhlášení. Dále následuje sekce s horizontálním menu, které je stejné pro všechny uživatele. Obsahuje odkazy na základní stránky veřejné sekce, které obsahují informace o poradně, kontakt, články a fotogalerii, tzn. typické věci pro webovou prezentaci. Vertikální menu se mění v závislosti na roli uživatele. Anonymní uživatel zde má odkazy pro výpočet BMI, ceník poradny a vstup do klientské sekce, který přesměruje, stejně jako tlačítko přihlásit, uživatele na login obrazovku. Zaměstnanec poradny zde bude mít odkazy na stránky administrátorské sekce (správy receptů, klientů, článků, …) a klient zde bude mít možnost dostat se na stránky své klientské sekce. Vpravo od vertikálního menu je náhled fotek galerie. Zobrazuje se zde posledních 10 publikovaných fotek. Dále následuje PlaceHolder, kde se mění obsah v závislosti na stránkách. V tomto případě je zde tedy úvodní slovo a abstrakt nejnovějšího publikovaného článku s odkazem na tento článek. V patičce stránky, která je již opět součástí MasterPage jsou poslední čtyři publikované recepty.

7.2 Přihlašovací obrazovka

Obrázek 6 - Přihlašovací obrazovka

Přihlašovací obrazovka (Obrázek 6) je velmi jednoduchá. Obsahuje vstup pro uživatelské jméno a heslo a navíc také zaškrtávací tlačítko pro pamatování těchto údajů a tlačítko přihlásit. Na obrázku je

53

pouze oblast, která je vložena do PlaceHolderu minulé obrazovky (stejně jako na všech následujících návrzích).

7.3 Správa článků

Obrázek 7 - Správa článků

Správa článků (Obrázek 7), stejně jako všechny další základní obrazovky správy, obsahuje tlačítko Přidat, vyhledávací oblast a tabulku se záznamy. Tabulka obsahuje sloupce v závislosti na požadované funkcionalitě, v tomto případě tedy Datum, Nadpis, a zda je článek publikován. Zároveň má každá tabulka sloupec Akce, kde jsou tlačítka pro práci s jednotlivými záznamy (většinou pro editaci a mazání).

54

7.4 Přidání receptu

Obrázek 8 - Přidání receptu

Obrazovka pro přidání receptu (Obrázek 8) se skládá z pole pro název receptu, výběru typu receptu (snídaně, oběd, večeře, svačina, jiné) a checkboxu zda recept publikovat. Dále je sekce se samotnou tvorbou receptu. Každý recept se skládá z jedné až x ingrediencí. Počet ingrediencí lze regulovat pomocí tlačítek Přidat, resp. Odebrat ingredience. Ingredience jsou vybírány z comboboxu, ve kterém je možné vyhledávání dle názvu. Pokud ingredience neexistuje, je třeba ji vytvořit. Od toho je na obrazovce odkaz na správu ingrediencí. Každé ingredience je v receptu určité množství (v gramech). Po výběru ingredience a vyplnění množství lze stisknout tlačítko Vypočítej pro vyplnění dodatečných informací. U každé ingredience se poté zobrazí v přepočtu na množství její hodnota cukrů, tuků, bílkovin a energie v receptu. Dále se vyplní koláčový graf, který zobrazuje poměr cukrů, tuků a bílkovin, který je výsledkem všech ingrediencí v receptu. Také jsou poté vyplněny celkové součty. Nakonec je na obrazovce textový editor pro vytvoření popisu receptu a tlačítka pro odeslání formuláře a pro návrat na správu receptů. Stejná obrazovka je použita i pro editaci receptů, akorát obsah jejích komponent je již ze začátku předvyplněn.

55

7.5 Přidání jídelníčku

Obrázek 9 - Přidání jídelníčku

Obrazovka přidání jídelníčku (Obrázek 8) je rozdělena do několika sekcí. V první sekci jsou obecné údaje o jídelníčku, jako je jméno klienta, pro kterého je jídelníček vytvářen, název jídelníčku, combobox pro výběr některého z dříve vytvořených jídelníčků jako šablony. Po výběru názvu jídelníčku z tohoto comboboxu budou předvyplněny ostatní sekce formuláře. Následuje odkaz na správu receptů (protože jídelníček lze sestavovat pouze z vytvořených receptů). Další sekce jsou všechny stejné a liší se pouze typem jídla (snídaně, oběd, …). Obsahují pole pro výběr jídla a oblast pro dodatečné informace. Tyto informace jsou stejné jako při vytváření jídla (poměry a součty cukrů, tuků, bílkovin a energie). Pod těmito sekcemi je graf, který zobrazuje

56

porovnání hodnot cukrů, tuků, bílkovin a energie jídelníčku s optimálními hodnotami pro klienta. Formulář je zakončen tlačítky pro odeslání, výpočet informací a návrat na seznam klientů.

7.6 Čtení jídelníčku

Obrázek 10 - Čtení jídelníčku

Tato obrazovka (Obrázek 10) je dostupná z klientské sekce. Začíná výběrem jídelníčku (předvyplněn je nejnovější jídelníček, ale klient si může prohlédnout i historii) a tlačítkem pro tisk jídelníčku. Následují záložky dle dní v týdnu a sekce s recepty na jídla, která tvoří jídelníček.

57

7.7 Založení klienta

Obrázek 11 - Založení klienta

Obrazovka (Obrázek 11) je dostupná ze správy klientů administrátorské sekce pomocí tlačítka Přidat, případně pomocí tlačítka Editovat u vybraného klienta. Jedná se o zadávací formulář pro založení nového klienta a vyplnění údajů z úvodní schůzky. Po vyplnění formuláře, a kliknutí na tlačítko Uložit, systém založí nového uživatele (případně upraví stávajícího).

58

8 Popis architektury Tato kapitola vychází z dokumentu Popis architektury metodiky MMSP. Je rozdělena na dvě části: 

Základní vymezení



Architektonická rozhodnutí a jejich vysvětlení

Základní vymezení obsahuje výčet požadavků, z kterých návrh architektury vychází, popis omezení, která je třeba při návrhu respektovat, dále pak zda existují nějaké specifické požadavky na výkon, bezpečnost, robustnost systému, … Druhá část základního vymezení předpoklady, které musí být splněny pro úspěšnou implementaci architektury, jestli jsou zvláštní požadavky na schopnosti projektového týmu nebo jestli má být preferována určitá technologie. Architektonická rozhodnutí a jejich vysvětlení obsahuje seznam rozhodnutí a vysvětlení, která se týkají například toho, jaký typ architektury byl zvolen (dvou vrstvá, tří vrstvá, …), jaké budou použity technologie, jak bude vypadat infrastruktura, navržení datové základny, …

8.1 Základní vymezení Základní vymezení se dělí na Požadavky a omezení a na Předpoklady.

8.1.1

Požadavky a omezení Návrh architektury vychází ze systémových požadavků SYS001 a SYS002. SYS001 je požadavek

o tom, že aplikace má být webová, založená na technologii ASP.NET Framework 4.0. SYS002 je požadavek na databázi MSSQL 2008 RC2. Tyto požadavky ovlivňují typ architektury, použité technologie a schéma datové základny. Další požadavky, které jsou brány do úvahy, jsou všechny funkční požadavky, které dávají základ schématu webových stránek. Jeden funkční požadavek je transformován do, obvykle, jedné až dvou stránek.

59

8.1.2

Předpoklady Prvním předpokladem pro úspěšnou implementaci architektury je přístup k databázovému

serveru s MSSQL 2008 RC2 databází a zároveň přístup k webovému serveru IIS 7, který podporuje ASP.NET technologii. Druhým předpokladem je, že členové implementačního týmu disponují znalostmi .NET technologie, jazyka C# a jazyka SQL.

8.2 Architektonická rozhodnutí a jejich vysvětlení Zde, jak již bylo výše zmíněno, se nachází seznam architektonických rozhodnutí.

8.2.1

Typ architektury Architektura je navrhována jako tří vrstvá (Obrázek 12), kde prezentační vrstva bude na

klientských stanicích (PC, Notebook, Mobilní telefony, Tablety, …) zobrazena pomocí webového prohlížeče. Aplikační vrstva bude umístěna na webovém serveru s podporou ASP.NET a datová vrstva bude nahrána na databázový server s podporou MSSQL 2008.

Obrázek 12 - Tří vrstvá architektura

Tento typ architektury je dnes typem velmi běžným, alespoň co se webových aplikací týká. Rozdělení na část serverovou a část klientskou umožňuje pohodlný víceuživatelský přístup. Rozdělení serverové části na aplikační a datovou umožňuje snadnou správu a přizpůsobení výkonu každé části.

60

8.2.2

Návrh datové základny Aplikace bude komunikovat s relační databází přímo, tzn. nebude mít žádné objektově-relační

mapování, a tedy ani žádný objektový model. Struktura dat je dána přímo datovou základnou. Následující konceptuální model je pro přehlednost rozdělen do několika menších. Pro větší robustnost a bezpečnost systému je správa uživatelů (klientů a zaměstnanců) řešena pomocí standardizovaného Frameworku ASP.NET Membership.

Obrázek 13 - Celkový pohled na datovou základnu

Tento model (Obrázek 13) zobrazuje celkový pohled na datovou základnu. Opět z důvodu přehlednosti v něm nejsou zakreslené číselníky a všechny atributy entit. Klient (client) má na sebe přiřazeny zaměstnancem vytvořené jídelníčky a události. Zároveň je entita client propojena s entitou aspnet_Users, která je součástí Membership frameworku pro správu rolí a uživatelů. Entity articles, fotogallery a foto pak slouží k reprezentaci článků, galerií a fotek.

61

Obrázek 14 - Schéma pro entitu Client

Model (Obrázek 14) znázorňuje detailnější pohled na entitu client. Gender je pohlaví klienta (muž, žena), sport_activity je míra sportovní aktivity (nízká, střední, vysoká) a entita client_messures označuje výsledky přeměření a převážení pravidelných kontrol během dietního programu.

62

Obrázek 15 - Schéma entity Jídelníček

Zde (Obrázek 15) je vyobrazen detail entity jídelníček. Jídelníček se skládá z receptů. Obsahuje název, datum vytvoření a den, na který je určen (pondělí, úterý, …). Recept je složen z ingrediencí (surovin, např. rajče, mouka, chléb, maso). Dodatečným atributem M:N vazby mezi receptem a ingrediencemi je množství, které značí, kolik gramů ingredience recept obsahuje.

63

Obrázek 16 - ASP.NET Membership databázové schéma (8)

Toto schéma (Obrázek 16) zobrazuje entity vygenerované Membership frameworkem a obstarává správu uživatelů (jmen, hesel, emailů, …), jejich profilů a jejich rolí. Tento framework je velmi robustní a standardizovaný.

8.2.3

Návrh schématu webových stránek Následující obrázky ukazují rozvržení webových stránek a jejich propojení odkazy. Pro

přehlednost schémat zde není vyobrazeno, že z každé stránky se lze dostat na stránku domovskou.

64

Obrázek 17 - Schéma rozložení sekcí webové aplikace

Obrázek 17 znázorňuje celkové rozložení sekcí systému.

Obrázek 18 - Schéma veřejné sekce

65

Schéma veřejné sekce (Obrázek 18), která je dostupná všem uživatelům.

Obrázek 19 - Schéma klientské sekce

Schéma (Obrázek 19) zobrazuje klientskou sekci pro klienty poradny.

Obrázek 20 - Administrátorská sekce

Obrázek 20 znázorňuje rozložení administrátorské sekce pro zaměstnance poradny.

66

9 Popis implementace V této kapitole je popsán proces samotné implementace. Nejprve jsou rozebrány použité technologie a jazyky, a poté je uvedena ukázka průběhu implementace na konkrétní webové stránce.

9.1 Použité technologie Tato podkapitola se zabývá použitými technologiemi při implementaci systému.

9.1.1

ASP.NET ASP.NET je framework od společnosti Microsoft pro vytváření dynamických webových stránek.

Jedná se o serverový jazyk (dle zapsaného kódu server vygeneruje HTML kód, který pošle klientovi webovému prohlížeči). ASP.NET byl vyvinut jako nástupce technologie ASP a vyšel v lednu 2002. Je založen na technologii CLR (Common Language Runtime), což znamená, že si vývojáři mohou sami zvolit z několika jazyků, které budou v rámci ASP.NET používat (visual basic, csharp, …). (3)

9.1.2

HTML a CSS HTML je standardizovaný značkovací jazyk pro tvorbu webových stránek. Skládá se

z definovaných elementů (například ) a jejich atributů (). Pomocí těchto prvků je vytvořen HTML dokument, který umí přečíst webový prohlížeč. Ten nezobrazuje HTML kód, ale jeho grafickou reprezentaci (například je značka pro obrázek a src=““ je atribut pro adresu k obrázku, čili prohlížeč ví, že má zobrazit obrázek ze zadané adresy). (9) CSS, neboli kaskádové styly, je jazyk pro popis způsobu zobrazení HTML stránek. Hlavní jeho úlohou je oddělení vzhledu od obsahu. Například výše uvedenému obrázku může být pomocí CSS jazyka zapsána výška, šířka, otočení, umístění na obrazovce, barevné ohraničení, atd. Syntaxe jazyka využívá selektory, což jsou odkazy na HTML prvky, kterým je grafika nastavována, a deklarace, což je zápis konkrétní grafiky (ohraničení červenou barvou silnou dva pixely). (10)

9.1.3

JavaScript JavaScript je programovací jazyk, který je nejčastěji používán jako součást webových

prohlížečů. Jeho implementace umožňuje tzv. programování na straně klienta. Používá se pro vytvoření bohatého webového prostředí a komunikace s uživatelem. Díky JavaScriptu nemusí být všechny reakce

67

na uživatelské akce přeposílány na server, ale jdou vyřešit přímo v prohlížeči bez zdlouhavého obnovování webové stránky. (11)

9.1.4

SQL SQL je dotazovací jazyk pro práci s daty v relačních databázích. Skládá se ze dvou částí – jazyka

pro definici dat (vytváření, mazání, úprava tabulek) a jazyka pro manipulaci s daty (vkládání, úprava, mazání a čtení řádků). SQL se také často označuje jako jazyk čtvrté generace. (12)

9.2 Ukázka postupu Zde na ukázku rozebírám postup implementace tří obrazovek v ASP.NET. První dvě obrazovky se týkají klasických číselníků, respektive jejich obsluhy (v tomto systému se jedná například o správu ingrediencí). Třetí obrazovka je pro vytváření receptů, která ukazuje implementaci složitější části. Nakonec je v této kapitole pojednání o řešení bezpečnosti systému.

9.2.1

Správa potravin Správa potravin (ale i článků, klientů, receptů, …) se skládá ze dvou stránek. První stránka je

v podstatě tabulka se seznamem všech položek a druhá je formulář, který slouží pro přidávání nebo úpravu konkrétní položky. V jazyce ASP.NET jsou jednotlivé stránky tvořeny dvěma základními prvky – ASPX stránkou a tzv. codebehindem. Vizuální prvky jsou definovány v ASPX části v jazyce, který je založen na bázi XML a případná logika je pak napsána v codebehind třídě. Při implementaci stránky je dobré začít od vzhledu. Lze identifikovat dva hlavní přístupy k vytváření stránky. Buď je možné snažit se zapsat co nejvíce kódu deklarativně v ASPX části, anebo zde vypsat pouze nezbytné minimum a zbytek dodělat v codebehindu. Oba přístupy mají svoji filozofii (snaha o minimum kódu vs snaha o striktní oddělení logiky od vzhledu). Já v tomto případě jednoduché stránky používám první způsob. Samotná ASPX část je pak tvořena z ASP.NET komponent (ASP.NET Controls) a navíc lze přidat i HTML, JavaScript, CSS a další client-side jazyky. Pomocí speciálních tagů lze samozřejmě umístit i server-side kód do této části, což však nedoporučuji (pokud se nejedná opravdu o něco velmi jednoduchého).

68

Následuje příklad komponenty sloužící pro zobrazení tabulky položek (Ukázka 1).

Ukázka 1 - ASPX zápis pro GridView

Název komponenty je GridView a jako první jsou definovány základní parametry, jako je ID (identifikace komponenty), runat=“server“ (toto znamená, že se jedná o serverovou komponentu), dále povolení stránkování položek, kolik položek se má na stránce zobrazit, že budou sloupečky tabulky definovány manuálně, ID datového zdroje, povolení třídění a název sloupce pro identifikaci položek (obvykle sloupec obsahující primární klíč). 69

Dále následuje definování jednotlivých sloupečků. Je možné také si je nechat vygenerovat automaticky podle sloupců v databázi, ale pro lepší kontrolu preferuji ruční definici. Zajímavý je poslední sloupec (Akce), který nereprezentuje konkrétně žádný databázový sloupec, ale obsahuje tlačítka akcí pro editaci a smazání konkrétní položky. První tlačítko je dynamicky vytvořený odkaz (zde je ukázka vložení server.side kódu do ASPX části), druhé pak pomocí parametru CommandName volá na datovém zdroji akci Delete. Komponenta samotná se postará o všechny ostatní věci, jako je například její HTML vykreslení. Sama podle nastavených parametrů vygeneruje HTML tabulku s odpovídajícími sloupci a odkazy, sama se postará o stránkování položek a o třídění pokud uživatel klikne na záhlaví sloupce. Zbývá už jen definovat datový zdroj s patřičným ID (Ukázka 2).

" SelectCommand="SELECT id, name, energy, sugar, fat, protein FROM food_sources ORDER BY name ASC" DeleteCommand="DELETE FROM food_sources WHERE id = @id;">

Ukázka 2 - ASPX zápis pro SQL datový zdroj

Pro tuto aplikaci používám SQL datový zdroj, lze také použít objektový nebo LinQ. Nejprve je definováno ID, že se jedná o serverovou komponentu a připojení k databázi. Toto připojení je v konfiguračním souboru (kde se nachází adresa databáze, přihlašovací údaje, …) a zde je na něj pouze odkaz. Poté následuje definice dotazů SelectCommand je pro sloupce v GridView a DeleteCommand je pro CommandName=“Delete“ u tlačítka pro smazání položky. Výsledná stránka vypadá následovně (Obrázky 21 a 22) - neobsahuje žádný kód v codebehindu:

Obrázek 21- Zobrazení GridView část 1

70

Obrázek 22 - Zobrazení GridView část 2

Finální implementace obsahuje samozřejmě další prvky, jako tlačítko přidat a vyhledávací pole, ale to není pro tuto ukázku důležité. Druhou stránkou správy je zadávací formulář. Ten obsahuje sice několik řádek v codebehindu, ale stále je většina práce v ASPX části (Ukázka 3).

71

<EditItemTemplate>

Ukázka 3 - ASPX zápis FormView

V tomto případě je použita komponenta FormView. Tato komponenta nemá žádný svůj daný vzhled (alespoň tedy po nastavení RenderOuterTable na false) a vše je definováno v jejích šablonách (template). V tomto případě používám dvě šablony, pro vkládání (InsertItemTemplate) a pro editaci (EditItemTemplate). V každé šabloně se nachází AddEditFoodSources uživatelská komponenta, kde jsou zapsány HTML reprezentace formulářových polí. Šlo by je zapsat i přímo do této šablony, ale pro lepší upravitelnost, jsou-li formulářová pole v obou šablonách stejná) je výhodnější vytvoření vlastní komponenty. Dále jsou zde dvě tlačítka, pro uložení formuláře a pro návrat na předchozí stránku.

72

V šabloně pro editaci jsou pomocí server-side tagu <%# Eval(…) %> namapovány sloupce tabulky na jednotlivá formulářová pole. Datový zdroj pro tuto stránku je obsáhlejší (Ukázka 4) než u stránky předchozí. " SelectCommand="SELECT [id], [name], [sugar], [energy], [fat], [protein] FROM [food_sources] WHERE ([id] = @Id)" InsertCommand="INSERT INTO [food_sources] ([name], [sugar], [energy], [fat], [protein]) VALUES (@name, @sugar, @energy, @fat, @protein);" UpdateCommand="UPDATE [food_sources] SET [sugar] = @sugar, [name] = @name, [energy] = @energy, [fat] = @fat, [protein] = @protein WHERE [id] = @id;"> <SelectParameters>

Ukázka 4 - SQL datový zdroj pro FormView

Jsou deklarovány tři dotazy – pro SELECT, INSERT a UPDATE. SELECT dotaz využívá parametru QueryString, který je posílán v parametru adresní řádky (za otazníkem). Díky použití parametrů 73

(InsertParameters a UpdateParameters) je systém automaticky chráněn před tzv. SQL Injection. ASP.NET sám upravuje uživatelské vstupy, aby nebyly potenciálně nebezpečné pro databázi. Stisknutím tlačítka uložit se podle šablony zavolá patřičný dotaz, který si pomocí parametrů vybere data z příslušných polí. Zbývá ukázat codebehind (Ukázka 5). Ten se stará o přepínání FormView mezi editačním a vkládacím módem. Defaultně je nastaven mód pro editaci, pokud ovšem datový zdroj po provedení SELECT dotazu nebude obsahovat žádné položky, přepne se FormView do módu pro vkládání. protected void fvIngredience_DataBound(object sender, EventArgs e) { if (fvIngredience.DataItemCount == 0) { fvIngredience.ChangeMode(FormViewMode.Insert); } }

Ukázka 5 - Codebehind pro událost DataBound u FormView

Toto je odchytnutí události, která je volána po ukončení navázání datového zdroje na FormView (v ASPX části ondatabound). ASP.NET hojně využívá tento událostní model a prakticky veškeré programování v codebehind se dělá jako obsluha nějaké události, ať už globální, například načtení stránky, nebo právě u jednotlivých komponent – vykreslení, navázání dat, mazání dat, … Na závěr ještě ukázka formuláře (Obrázek 23):

Obrázek 23 - Ukázka formuláře FormView

9.2.2

Vytvoření receptu a M:N vazba Při vytváření receptu není předem známo, z kolika ingrediencí se bude skládat (může být

z jedné, nebo také z padesáti). Výsledný zadávací formulář tedy není pouze statický – předpřipravený, ale má dynamickou oblast – výběr ingrediencí.

74

Mé řešení spočívá v tom, že má uživatel k dispozici dvě tlačítka – pro přidání, respektive odebrání ingredience. Toto je jednoduché v desktopové aplikaci, avšak ve webové se jedná o složitější záležitost, kde už se vývojář bez kódu v codebehindu neobejde.

Ukázka 6 - ASPX zápis pro UpdatePanel

Základem dynamické oblasti je UpdatePanel (Ukázka 6). Tato komponenta umožňuje aktualizaci části stránky (partial postback) bez obnovení stránky celé (postback). UpdatePanel vyžaduje ScriptManager pro své fungování. ScriptManager vloží do stránky potřebné JavaScript metody. UpdatePanel stejně jako FormView nemá žádnou grafickou reprezentaci a vše je definováno v šabloně (ContentTemplate). V mém případě je zde PlaceHolder, což je oblast, do které se budou dynamicky vkládat další komponenty. Dále má UpdatePanel definované spouštěcí události, které vynutí jeho obnovení. V podstatě, jakmile je stisknuto jedno z tří definovaných tlačítek, obsah UpdatePanelu se znovu načte. Zbytek práce je v codebehindu.

75

public int SourceCount { get { int number = Session["SourceCount"] != null ? int.Parse(Session["SourceCount"].ToString()) : 3; return number; } set { Session["SourceCount"] = value; } }

Ukázka 7 - Proměnná ovládající Session

Nejprve je definována proměnná (Ukázka 7), která do Session atributu uloží počet ingrediencí. Pokud tento atribut neexistuje, je počet nastaven na tři. protected void Page_PreInit(object sender, EventArgs e) { Control myControl = GetPostBackControl(Master.Master.Page); if (myControl != null) { if ((myControl.ClientID.ToString().Contains("btnAddSource"))) { SourceCount = SourceCount + 1; } else if ((myControl.ClientID.ToString().Contains("btnRemoveSource"))) { SourceCount = SourceCount == 1 ? 1 : SourceCount - 1; } } }

Ukázka 8 - Událost PreInit

Poté v PreInit události stránky je zjištěno jaký prvek vyvolal obnovu (Ukázka 8). Pokud se jedná o tlačítko přidat, nebo odebrat, je výše uvedená proměnná zvětšena nebo zmenšena o jedničku (počet ingrediencí nemůže klesnout pod jedna).

76

private private private private private private

DropDownListChosen[] drpList; TextBox[] txtAmountList; Label[] lblSugarList; Label[] lblProteinList; Label[] lblFatList; Label[] lblEnergyList;

protected override void OnInit(EventArgs e) { base.OnInit(e); List foodToFoodSourceList = new List(); drpList = new DropDownListChosen[SourceCount]; txtAmountList = new TextBox[SourceCount]; lblSugarList = new Label[SourceCount]; lblProteinList = new Label[SourceCount]; lblFatList = new Label[SourceCount]; lblEnergyList = new Label[SourceCount]; for (int i = 0; i < SourceCount; i += 1) { InitiateComponents(i, foodToFoodSourceList); } }

Ukázka 9 - Událost OnInit

Dále v OnInit události stránky (Ukázka 9) jsou vytvořeny pole komponent o velikosti počtu ingrediencí. Tato pole poté budou obsahovat odkazy na konkrétní komponenty tvořící dynamickou část formuláře. Metoda InitiateComponents() vytvoří ony komponenty, nastaví jim ID, CSS styly, případně je předvyplní, uloží do patřičných polí a zároveň je vloží do PlaceHolderu, který je definován v ASPX části.

77

protected void btnSend_Click(object sender, EventArgs e) { string insertCommand = "INSERT INTO food (name, note, publicate, food_type) output inserted.id VALUES (@name, @note, @publicate, @food_type)"; string updateCommand = "UPDATE food SET name = @name, food_type = @food_type, note = @note, publicate = @publicate output inserted.id WHERE id = @food_id"; var id = -1; if (Request.QueryString["id"] != null) { id = Int32.Parse(Request.QueryString["id"]); } using (SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["vyzivaes"].Conn ectionString)) { conn.Open(); SqlTransaction myTransaction = conn.BeginTransaction(); try { SqlCommand cmd1 = id == -1 ? new SqlCommand(insertCommand, conn) : new SqlCommand(updateCommand, conn); cmd1.Transaction = myTransaction; cmd1.Parameters.AddWithValue("@name", HtmlUtility.Instance.SanitizeHtml(txtName.Text)); cmd1.Parameters.AddWithValue("@food_type", ddlcFoodTypes.SelectedValue); cmd1.Parameters.AddWithValue("@note", richBox.Text); cmd1.Parameters.AddWithValue("@publicate", cbPublicate.Checked); if (id != -1) { cmd1.Parameters.AddWithValue("@food_id", id); } var foodId = Convert.ToInt32(cmd1.ExecuteScalar()); SqlCommand cmd2 = new SqlCommand("DELETE FROM food_to_food_source WHERE food_id = @food_id", conn); cmd2.Transaction = myTransaction; cmd2.Parameters.AddWithValue("@food_id", foodId); cmd2.ExecuteNonQuery(); for (int i = 0; i < drpList.Length; i++) { SqlCommand cmd3 = new SqlCommand("INSERT INTO food_to_food_source (food_id, food_source_id, amount) VALUES (@food_id" + i + ", @food_source_id" + i + ", @amount" + i + ")", conn); cmd3.Transaction = myTransaction;

78

cmd3.Parameters.AddWithValue("@food_id" + i, foodId); cmd3.Parameters.AddWithValue("@food_source_id" + i, drpList[i].SelectedValue); cmd3.Parameters.AddWithValue("@amount" + i, Int32.Parse(HtmlUtility.Instance.SanitizeHtml(txtAmountList[i].Text))); cmd3.ExecuteNonQuery(); } myTransaction.Commit(); } catch { myTransaction.Rollback(); throw; } } Response.Redirect("~/Administration/ManageRecepts.aspx"); }

Ukázka 10 - Událost pro odeslání formuláře

Tato událost (Ukázka 10) je volána při stisknutí tlačítka Uložit. Jedná se v ní o uložení vyplněných záznamů do databáze (to co dělal datový zdroj pomocí několika ASPX řádků je zde rozepsáno v codebehindu na více než stránku). Protože se jedná o vkládání do dvou tabulek, je dobré využít transakcí. Tím je docílena jistota konzistence databáze (transakce buď proběhne celá a obě tabulky budou aktualizovány, nebo neproběhne a tabulky se vrátí do stavu před jejím zahájením). Ještě jedna poznámka … ASP.NET si ukládá stav komponent do tzv. ViewState (pokud ho vývojář nevypne). Dojde-li k obnovení stránky, případně k jejímu částečnému obnovení, jsou hodnoty uložené ve ViewState automaticky přiděleny zpět (zachová-li si komponenta své ID). To znamená, že například hodnota vyplněná v textovém poli v něm zůstane i po obnovení stránky. Na závěr ještě přikládám snímek formuláře:

Obrázek 24 - Část formuláře pro přidání ingredience do receptu

79

9.2.3

Řešení zabezpečení (3) Otázka bezpečnosti webových aplikací je velmi důležitá. Zvláště aplikace, které pracují se

soukromými daty klientů, musí být chráněné před různou formou útoků. V této podkapitole je popsán způsob řešení této otázky ve vyvíjeném systému. Prvním (a dle mě nejdůležitějším) druhem zabezpečení je omezení uživatelských vstupů. Čím méně může uživatel se systémem interagovat, tím je systém méně zranitelný. Vyvíjený systém nedává, kromě přihlašovacího formuláře, anonymním uživatelům a klientům k dispozici žádná textová pole, či jiné prvky, které jsou potenciálním zdrojem nebezpečí. Kromě odkazů je jediný prvek dostupný klientům poradny kombobox při výběru starších jídelníčků, který je však ošetřen pomocí ASP.NET parametrů. Zaměstnanci poradny sice mají k dispozici celou řadu zadávacích polí, ale u nich se nepředpokládá žádná sabotážní činnost (i přes to jsou všechny vstupy ošetřeny následujícími způsoby).

9.2.3.1

Ošetření vstupů Každé zadávací pole, jehož obsah je odesílán na server, s sebou přináší riziko útoku (nemusí se

jednat ani o textové pole, změnit odesílanou hodnotu například v komboboxu není složitá záležitost). Nejčastěji jsou tyto útoky dvojího typu – SQL Injection a XSS (Cross-site scripting). SQL-Injection funguje na principu odeslání škodlivého dotazu do databáze, která jej vykoná. Uvedu příklad. Do textového pole pro uživatelské jméno vyplní uživatel následující: “); DROP TABLE client;. Pokud by bylo pole napojené na databázi přímo bez jakékoli kontroly vstupu, došlo by ke smazání tabulky s klienty poradny, protože uvozovky, závorka a středník ukončí dotaz pro porovnání jména a hesla a databáze poté spustí dotaz nový – na smazání klientů. ASP.NET má pro tento druh útoku řešení v podobě parametrů. Všechny hodnoty formulářových polí, které jsou odesílány na server, nejdou do databáze přímo, ale nejprve jsou umístěny do parametru, kde jsou všechny potenciálně nebezpečné znaky nahrazeny (například umístěním lomítka před uvozovky). Databáze pak tyto znaky nepovažuje za klíčové, ale za součást hodnoty pole a přistupuje k nim jako k běžnému textu. XSS je útok, při kterém útočník vloží do databáze škodlivý skript (většinou se jedná o JavaScript umístěný mezi <script> HTML tagy). Pokud se někde na stránce vykreslují dynamicky informace dle obsahu databáze, je tento skript vykreslen také. Prohlížeč se k němu pak chová, jako by byl originální součást stránky a spustí ho. V lepším případě skript pouze přesměruje stránky na stránky konkurence. V horším může krást klientům autorizační cookies a přeposílat je útočníkovi. Ten je pak může použít k vydávání se za poškozeného a získat přístup do jeho sekce systému. Obranou je nikdy neukládat žádné HTML a JavaScript kódy do databáze. ASP.NET stránky mají v deklaraci parametr

80

ValidateRequest (defaultně nastavený na true). Pokud je hodnota tohoto parametru true, stránka vyhodí výjimku, zjistí-li nepovolený znak odesílaný v políčku formuláře (například znaky < a >). Někdy ale je nutné ukládat HTML znaky do databáze. Například u tvorby receptů je WYSIWYG editor, který formátování textu ukládá právě jako HTML a CSS. Pro tyto případy mám vstupy ještě ošetřeny pomocí AntiXSS knihovny, která sama o sobě není příliš povedená, ale po několika úpravách, které spočívaly v napsání nové třídy, která pouze využívá přístup k HTML elementům a atributům z AntiXSS, vzniklo použitelné řešení. Toto řešení pracuje na bázi seznamu povolených elementů a jejich atributů. Objeví-li se v ošetřeném vstupu element/atribut, který není na seznamu, je smazán i s jeho obsahem.

9.2.3.2

ASP.NET Membership Framework (17) Na konec se ještě zmíním o ASP.NET Membership Frameworku. Tato sada knihoven slouží

k automatické správě uživatelů, jejich rolí a profilů. Tento Framework je standardizovaný, a tedy aplikace, které na něm mají správu uživatelů postavenou, mohou sdílet uživatelské účty. Díky jeho přímé integraci v ASP.NET je jeho použití velmi snadné. Nejprve je potřeba v databázi vytvořit tabulky a uložené procedury, které tento Framework využívá. Toho lze docílit pomocí aspnet_regsql.exe souboru, který je umístěn v adresáři se soubory .NET Frameworku. Buď pomocí příkazové řádky, nebo grafického rozhraní, lze jednoduše spustit vytvoření Membership objektů na konkrétní databázi. Poté stačí jen upravit soubor web.config následujícím způsobem (Ukázka 11) a je hotovo. <membership> <providers>

Ukázka 11 - Membership konfigurace

81

Atribut loginUrl elementu forms definuje stránku, která obsahuje přihlašovací formulář. Na tuto stránku budou přesměrovány všechny pokusy o vstup neautorizovaných uživatelů do chráněné sekce systému. Označení sekce, která je chráněná se taky dělá pomocí souboru web.config (Ukázka 12). <system.web> <deny users="*" />

Ukázka 12 - Chránění sekce webu

Konfigurace znamená, že všechny role, které nejsou Administration mají zakázaný přístup do adresáře Administration a všech jeho podadresářů a souborů (stránek). Membership Framework lze také využít pro zobrazování prvků na stránce pouze konkrétním uživatelským rolím. Například odkazy pro vstup do administrátorské sekce vidí pouze uživatel přihlášený jako zaměstnanec. Vše je jednoduché pomocí komponenty LoginView (Ukázka 13).

82

Správa Klientů

Správa Článků

Správa Galerie

Správa Ingrediencí

Správa Receptů

Klientská sekce

Ceník

Ukázka 13 - Zobrazení odkazů pro konkrétní role

Anonymní uživatelé vidí odkazy na klientskou sekci (přesměrování na přihlášení) a ceník, zatímco zaměstnanci vidí odkazy na administrátorskou sekci. Vše je definováno pomocí šablon, stejně jako již několikrát výše (například ve FormView).

9.3 Databáze ingrediencí Databáze ingrediencí byla částečně převzata z energetických tabulek ze serveru www.musculus.cz/kulturistika (autor Libor Diviš). (13)

83

9.4 Testování Testování je prováděno formou černé skřínky přímo zaměstnancem poradny. Důraz je v této fázi kladen převážně na funkčnost. Testovací scénáře zatím nebyly použity (oficiální testování je plánováno po nasazení nové grafiky, kdy začnou přípravy na ostré nasazení).

84

10 Závěr Cílem mé práce bylo vytvoření informačního systému na zakázku pro výživovou poradnu. Pro tento hlavní cíl jsem si definoval několik cílů dílčích. Prvním dílčím cílem byla analýza dostupných produktů na trhu, kterou jsem provedl v kapitole 2 (Základní popis dostupných aplikací pro podporu výživových poraden). Během analýzy jsem zjistil, že žádný nevyhovuje definovaným požadavkům zákazníka. Druhým dílčím cílem bylo zpracování a specifikace požadavků na tvořený systém, včetně návrhu jeho implementace. Tento cíl jsem splnil v kapitolách 3 (O poradně) – 8 (Popis architektury). Dle upravené metodiky MMSP jsem vytvořil vizi (kapitola 4) vyvíjeného systému a spolu se zákazníkem specifikoval funkční a nefunkční požadavky na systém (kapitola 5). Z těchto funkčních požadavků jsem odvodil případy užití (kapitola 6). Z případů užití jsem pak vytvořil návrhy obrazovek (kapitola 7). V této práci nejsou uvedeny návrhy úplně všech obrazovek, protože některé obrazovky vznikaly jako prototypy s přímou konzultací zákazníka, případně jsou si některé velmi podobné a nemělo by smysl je zde znovu uvádět. Následuje popis architektury (kapitola 8), kde jsem hlavně vytvořil návrh konceptu datové základny a schéma webových stránek systému. Základní implementace jazyka ASP.NET (na rozdíl od ASP.NET MVC) využívá ani ne tak objektového, jakožto událostně řízeného přístupu (většina logiky je vykonávána jako reakce na určitou událost, ať už životního cyklu stránky, nebo na událost volané komponentou), a proto nebylo potřeba vytvářet i objektový model. Třetím a posledním dílčím cílem byla samotná implementace a popis některých částí řešení. Tímto se zabývá kapitola 9 (Popis implementace) a samozřejmě přílohou této práce je výsledná aplikace. Ukázal jsem implementaci třech stránek aplikace. U prvních dvou se jednalo o celkem standardní implementaci číselníku s proklikem na detail, který slouží pro editaci a přidávání nových položek. Tyto dvě stránky jsou skoro celé zapsány deklarativně ve své ASPX části. Třetí stránkou byla tvorba nového receptu. Zde bylo ukázáno programování složitější logiky stránky (než jen obsluha číselníku) v části nazvané codebehind. Nakonec jsem se ještě zmínil o řešení zabezpečení celého systému. Za největší přínos své práce považuji hotový systém, jehož aktuální verze je dostupná na adrese http://skola.vyzivaes.cz , případně na přiloženém CD. Přihlašovací údaje do administrátorské sekce jsou následující: 

Uživatelské jméno – admin



Heslo – materidouska8 85

Pro instalaci systému z přiloženého CD je nutné mít VisualStudio 2012 a upravit ConnectionString v souboru web.config pro aktuální umístění databázového souboru (mdf). Největší obtíže mi činil fakt, že systém je vyvíjen značně agilně a úzké spolupráci se zákazníkem a pro účely této práce, jsem musel jeho vývoj udělat rigidnějším. Požadavky zákazníka se ale bohužel i přes tuto skutečnost velmi často měnily, což vedlo k tomu, že je občas na stránce tlačítko, či textové pole jinak, než bylo naplánováno. Vývoj systému nekončí odevzdáním této práce. Pro další fáze vývoje je připravován nový, mnohem zajímavější vzhled a z funkční oblasti například algoritmy, které umožní automatizovat plánování jídelníčků, systém pro kategorizaci klientů, hromadné vytváření událostí, atd.

86

Terminologický slovník

Tabulka 28 - Terminologický slovník

TERMÍN ASP. NET AUTENTIZACE AUTORIZACE CASCADING STYLE SHEETS CHECKBOX

ZKRATKA VÝZNAM [AUTOR] Framework od společnosti Microsoft pro tvorbu dynamických webových stránek a aplikací [vlastní definice autora] Zjištění, zda je uživatel ten, za koho se vydává (například porovnáním jména a hesla) [vlastní definice autora] Přiřazení práv autentizovanému uživateli dle určitých pravidel (například dle role) [vlastní definice autora] CSS Jazyk pro zápis vzhledu webových stránek (10) Zaškrtávací tlačítko [vlastní definice autora]

CLIENT-SIDE CONNECTIONSTRING CROSS-SITE SCRIPTING DATABÁZE

XSS DB

FRAMEWORK GRAPHICAL USER INTERFACE HYPERTEXT MARKUP LANGUAGE IDENTIFIKAČNÍ ČÍSLO INFORMAČNÍ SYSTÉM JAVASCRIPT KOMBOBOX LOOK AND FEEL M:N RELAČNÍ DATABÁZE SERVER-SIDE

GUI HTML ID IS JS

Kód, který je vykonáván v internetovém prohlížeči uživatele [vlastní definice autora] Element konfiguračního souboru we.config pro nastavení parametrů připojení k databázi [vlastní definice autora] Forma útoku, kdy je do stránky vložen útočníkem škodlivý skript [vlastní definice autora] Uspořádaná množina dat [vlastní definice autora] Soubor tříd, aplikací a knihoven, díky kterému mohou rozdílné komponenty spolupracovat (13) Grafické uživatelské rozhraní mezi aplikací a uživatelem [vlastní definice autora] Značkovací jazyk pro zápis struktury webových stránek (9) Číslo, které jednoznačně identifikuje konkrétní objekt [vlastní definice autora] Systém pro zpracování informací (v této práci je myšlen počítačově založený systém) [vlastní definice autora] Programovací jazyk, který implementuje většina internetových prohlížečů (11) Komponenta, která umožňuje výběr jednoho z určité množiny prvků [vlastní definice autora] Obecný vzhled a dojem z uživatelského rozhraní [vlastní definice autora] Druh vazby mezi dvěma tabulkami v relační databázi [vlastní definice autora] Databáze, jejíž prvky reprezentovány pomocí tabulek [vlastní definice autora] Kód, který je vykonáván na serveru [vlastní definice autora] 87

STRUCTURED QUERY LANGUAGE SQL-INJECTION

SQL

EXTENSIBLE XML MARKUP LANGUAGE WYSIWYG EDITOR

Strukturovaný dotazovací jazyk pro práci s daty v relačních databázích (12) Forma útoku, kdy útočník pomocí zranitelného pole formuláře spustí škodlivý SQL dotaz na databázi systému [vlastní definice autora] Rozšiřitelný značkovací jazyk [vlastní definice autora] Editor, který poskytuje funkce formátování textu [vlastní definice autora]

88

Reference 1. ŠIMŮNEK, Dominik. Návrh webové aplikace pro řízení tréninkového procesu atletů. Diplomová práce. Praha : Vysoká škola ekonomická, 2013. 2. MÜLLER, Martin. Vývoj aplikace pro prezentaci produktů zadavatele. Diplomová práce. Praha : Vysoká škola ekonomická, 2013. 3. MACDONALD, Matthew. Beginning ASP.NET 4 in C# 2010. New York : Apress, 2010. ISBN 14-3022608-0. 4. MÜLLEROVÁ, Dana. Výživový software NutriDan. DANONE INSTITUT. [Online] [Citace: 11. Leden 2014.] http://www.institut-danone.cz/cz/odborna-sekce/nutridan/. 5. Jednohubka. obezita.org. [Online] [Citace: 12. Leden 2014.] http://obezita.org/?page=jednohubka. 6. ROUBEC, Martin. O programu. FitLinie. [Online] 2014. [Citace: 10. Leden 2014.] http://fitlinie.cz/program.php. 7. Úvod do metodiky. MMSP. [Online] [Citace: 12. Únor 2014.] http://mmsp.czweb.org/. 8. OLIVEROS, Patrick. ASP.NET Membership Schema. The Web Developer. [Online] 21. Listopad 2007. [Citace: 20. Duben 2014.] http://webthinker.wordpress.com/2007/11/21/aspnet-membershipschema/. 9. W3C. W3C HTML. [Online] 2013. [Citace: 20. Duben 2014.] http://www.w3.org/html/. 10. —. Cascading Style Sheets. W3C. [Online] 2014. [Citace: 20. Duben 2014.] http://www.w3.org/Style/CSS/. 11. —. Your first look at JavaScript. W3C. [Online] 2012. [Citace: 20. Duben 2014.] http://www.w3.org/wiki/Your_first_look_at_JavaScript. 12. w3schools. Introduction to SQL. w3schools.com. [Online] 2014. [Citace: 20. Duben 2014.] http://www.w3schools.com/sql/sql_intro.asp. 13. DIVIŠ, Libor. Energetické tabulky potravin. Bezsteroidová kulturistika. [Online] 2010. [Citace: 12. Prosinec 2013.] http://www.musculus.cz/kulturistika/programy/energeticke-tabulky-potravin. 14. Definition of Framework. About.com. [Online] 2012. [Citace: 18. Duben 2014.] http://cplus.about.com/od/glossar1/g/frameworkdefn.htm. 15. BRUCKNER, Tomáš. Tvorba informačních systémů: principy, metodiky, architektury. 1. vyd. Management v informační společnosti. Praha : Grada, 2012. ISBN 978-80-247-4153-6. 89

16. BASL, Josef a BLAŽÍČEK, Roman. Podnikové informační systémy: podnik v informační společnosti. 3., aktualiz. a dopl. vyd. Management v informační společnosti. Praha : Grada, 2012. ISBN 978-80247-4307-3. 17. Microsoft. Microsoft Developer Network. Introduction to Membership. [Online] 2012. http://msdn.microsoft.com/en-us/library/yh26yfzy%28v=vs.100%29.ASPX.

90

Seznam obrázků Obrázek 1 - NutriDan obrazovka ............................................................................................................. 6 Obrázek 2 - Jednohubka obrazovka ........................................................................................................ 7 Obrázek 3 - FitLinie obrazovka (6) ........................................................................................................... 9 Obrázek 4 - Schéma případů užití ......................................................................................................... 31 Obrázek 5 - Úvodní obrazovka .............................................................................................................. 52 Obrázek 6 - Přihlašovací obrazovka....................................................................................................... 53 Obrázek 7 - Správa článků ..................................................................................................................... 54 Obrázek 8 - Přidání receptu................................................................................................................... 55 Obrázek 9 - Přidání jídelníčku................................................................................................................ 56 Obrázek 10 - Čtení jídelníčku................................................................................................................. 57 Obrázek 11 - Založení klienta ................................................................................................................ 58 Obrázek 12 - Tří vrstvá architektura...................................................................................................... 60 Obrázek 13 - Celkový pohled na datovou základnu .............................................................................. 61 Obrázek 14 - Schéma pro entitu Client ................................................................................................. 62 Obrázek 15 - Schéma entity Jídelníček .................................................................................................. 63 Obrázek 16 - ASP.NET Membership databázové schéma (8) ................................................................ 64 Obrázek 17 - Schéma rozložení sekcí webové aplikace ........................................................................ 65 Obrázek 18 - Schéma veřejné sekce ...................................................................................................... 65 Obrázek 19 - Schéma klientské sekce ................................................................................................... 66 Obrázek 20 - Administrátorská sekce.................................................................................................... 66 Obrázek 21- Zobrazení GridView část 1 ................................................................................................ 70 Obrázek 22 - Zobrazení GridView část 2 ............................................................................................... 71 Obrázek 23 - Ukázka formuláře FormView ........................................................................................... 74 Obrázek 24 - Část formuláře pro přidání ingredience do receptu ........................................................ 79

91

Seznam tabulek Tabulka 1 - Zhodnocení aplikace NutriDan ............................................................................................. 5 Tabulka 2 - Zhodnocení aplikace Jednohubka ........................................................................................ 7 Tabulka 3 - Zhodnocení aplikace Fitlinie ................................................................................................. 9 Tabulka 4 - Závěrečné vyhodnocení ...................................................................................................... 10 Tabulka 5 - Seznam subjektů ................................................................................................................. 15 Tabulka 6 - Seznam požadavků a funkcí ................................................................................................ 16 Tabulka 7 - Seznam funkčních požadavků............................................................................................. 18 Tabulka 8 - Seznam požadavků Použitelnosti ....................................................................................... 26 Tabulka 9 - Seznam požadavků na Spolehlivost .................................................................................... 27 Tabulka 10 - Seznam požadavků na vzhled ........................................................................................... 27 Tabulka 11 - Seznam požadavků na Rozložení a navigaci ..................................................................... 28 Tabulka 12 - Seznam požadavků Konzistence ....................................................................................... 28 Tabulka 13 - Seznam Systémových omezení ......................................................................................... 29 Tabulka 14 - Seznam aktérů .................................................................................................................. 30 Tabulka 15 - Přihlašování uživatelů ....................................................................................................... 32 Tabulka 16 - Tvorba a úprava receptů .................................................................................................. 34 Tabulka 17 - Tvorba a úprava jídelníčků pro klienty ............................................................................. 36 Tabulka 18 - Rozšíření a úprava databáze ingrediencí .......................................................................... 38 Tabulka 19 - Registrace a správa klientů ............................................................................................... 40 Tabulka 20 - Tvorba a úprava cvičebních plánů a plánů schůzek.......................................................... 42 Tabulka 21 - Psaní a úprava článků pro veřejnost................................................................................. 44 Tabulka 22 - Vytváření fotogalerií a vkládání fotek............................................................................... 45 Tabulka 23 - Prohlížení klientských jídelníčků ....................................................................................... 47 Tabulka 24 - Prohlížení klientských cvičebních plánů a schůzek ........................................................... 48 Tabulka 25 - Získání informací o průběhu dietního programu.............................................................. 49 Tabulka 26 - Prohlížení fotogalerií ........................................................................................................ 50 Tabulka 27 - Čtení článků ...................................................................................................................... 51 Tabulka 28 - Terminologický slovník ..................................................................................................... 87

92

Seznam ukázek Ukázka 1 - ASPX zápis pro GridView ...................................................................................................... 69 Ukázka 2 - ASPX zápis pro SQL datový zdroj ......................................................................................... 70 Ukázka 3 - ASPX zápis FormView........................................................................................................... 72 Ukázka 4 - SQL datový zdroj pro FormView .......................................................................................... 73 Ukázka 5 - Codebehind pro událost DataBound u FormView ............................................................... 74 Ukázka 6 - ASPX zápis pro UpdatePanel................................................................................................ 75 Ukázka 7 - Proměnná ovládající Session ............................................................................................... 76 Ukázka 8 - Událost PreInit ..................................................................................................................... 76 Ukázka 9 - Událost OnInit ...................................................................................................................... 77 Ukázka 10 - Událost pro odeslání formuláře......................................................................................... 79 Ukázka 11 - Membership konfigurace .................................................................................................. 81 Ukázka 12 - Chránění sekce webu ......................................................................................................... 82 Ukázka 13 - Zobrazení odkazů pro konkrétní role................................................................................. 83

93

Příloha A - CD Na samostatném CD se nachází aktuální verze systému VýživaES v podobě projektu pro VisualStudio 2012.

Příloha B – Obrazovka pro úpravu receptu

Přílohou B je snímek obrazovky pro úpravu a vytváření receptů hotové aplikace. Pozadí je tvořeno fixním obrázkem, což znamená, že se obrázek při scrollování stránky neposouvá. Bohužel nástroj pro zachycení celé webové stránky si s tímto faktem neumí poradit a použil šedou barvu pozadí jako kompenzaci.

Informační systém pro výživovou poradnu

Recommend Documents