Systém pro správu požadavků a úkolů. Radek Tobolka

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Systém pro správu požadavků a úkolů Radek Tobolka

Vedoucí práce: Ing. Zbyněk Hora, PhD.

Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimedia 28. května 2010

iv

v

Poděkování Chtěl bych poděkovat mému vedoucímu práce Ing. Zbyněk Hora, PhD. Mé rodině a přítelkyni za podporu při psaní práce.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 28. 5. 2010

.............................................................

viii

Abstract The aim of this work is to design and implement a system for an easy administration of tasks and claims according to a company‘s demand. Furthermore it shall facilitate the process of recording and observing the span of time used for the above-named tasks to the maximum. The thesis implies the task analysis, the dissection of existing explanations and the method of adjusting assignments as well as the implementation‘s concept and solution.

Abstrakt Cílem práce je navrhnout a implementovat systém pro snadnou správu úkolů a požadavků dle potřeb firmy, tak aby maximálně ulehčil také proces zaznamenávání a sledování času stráveného plněním těchto povinností. Práce se zabývá analýzou požadavků, rozborem existujících řešení a metodiky uspořádání úkolů, návrhem a řešením implementace.

ix

x

Obsah

xi

xii

OBSAH

Seznam obrázků

xiii

xiv

SEZNAM OBRÁZKŮ

Kapitola 1

Úvod Práce vzniká na základě potřeby zadavatele vytvořit systém, ulehčující mu jeho každodenní práci při zaznamenávání, správě a sledování požadavků a úkolů. Zadavatelem je firma zaměřená na poskytování počítačových školení a kurzů, konzultací a prodej CAD software. Při sjednání zakázek se zákazníkem a také při vnitřním vedení firmy vznikají úkoly a požadavky, které je nutné zaznamenávat. Zaznamenané požadavky pak dále spravovat a dohlížet nad jejich plněním. Potřeba zaznamenat požadavek nebo úkol se může vyskytnout při jednání se zákazníkem, jízdě v autě či práci v kanceláři. Systém pro zaznamenávání požadavku proto musí být široce dostupný, například pro kombinaci webového prostředí a mobilního telefonu s připojením k internetu.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle 2.1

Zadání

Cílem projektu je vytvořit systém umožňující zadavateli snadné, rychlé a přehledné zaznamenávání a správu zadaných úkolů a požadavků. A to jak krátkodobých tak dlouhodobých. Systém má uživateli zajistit rovněž přehledné sledování času, který na daném úkolu strávil jeho řešením. Uživatelské rozhraní systému má být snadno dostupné přes webový prohlížeč osobního počítače a také z mobilního telefonu s připojením k internetu. Systém musí umět pracovat se stávajícími daty (klienti, uživatelé, zakázky), které již firma používá.

2.2

Současný stav

Zadavatelem je firma zaměřená na poskytování počítačových školení a kurzů, konzultací a prodej CAD software. Při sjednávání zakázek se zákazníkem vznikají vedlejší úkoly a požadavky, jenž je nutné zaznamenávat. Další skupina úkolů souvisí s vnitřním fungováním firmy. Úkol tedy mohou tvořit jednoduchá zadání typu „volat zákazníka X ve 13:00 “, přes poznámky, jako například „poslat tabulku kolegovi“, až po rozsáhlá zadání na několik měsíců. Současný stav správy plnění těchto úkolů a sledování času na nich strávených je ve firmě nejednotný. K zaznamenávání úkolů je využíváno poznámkových bloků, textových editorů, mobilních telefonů, tabulek v Excelu a dalšího softwaru třetích stran. K nutnosti zaznamenat si daný úkol navíc dochází i mimo sídlo firmy a dosah počítače, například na schůzce se zákazníkem, při neformálních jednáních, za jízdy v automobilu atp. Synchronizace a dohledání všech takto vytvořených poznámek bývá pak obvykle zdlouhavé, neefektivní a je často zdrojem nejasností v přehledu úkolů. Rovněž k zaznamenávání času stráveného při řešení úkolů bývá užíváno výše uvedených postupů, které uživatele často odrazují od přesného zaznamenávání. Čas strávený nad jednotlivými úkoly přitom může sloužit jako podklad ke stanovení ceny služby pro zákazníka nebo mzdy pro zaměstnance.

3

4

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

2.3

Funkční požadavky

Nově vytvořený systém by měl sjednotit správu úkolů a zaznamenávání času, stráveného jejich řešením. Systém musí být navržen s ohledem na snadnou použitelnost a efektivitu práce. Pro efektivní správu úkolů a používání systému je nutná také vazba na stávající data o klientech a zakázkách, které se nachází ve firemní databázi. Systém musí uživateli dovolit správu úkolů, která se skládá z těchto konkrétních položek: 1. Přihlášení do systému při využití stávajícího firemního přihlašování uživatelů 2. Zobrazení seznamu úkolů, a to podle různých kriterií (filtrování, řazení) • Zadavatel • Termín zadání / splnění, překročení termínu • Vlastník úkolu 3. Vytváření úkolů a dílčích podúkolů (hierarchie) 4. Úpravu již vytvořených úkolů 5. U každého úkolu možnost vedení informací • Název – stručně pojmenovaný úkol • Zadavatel – společnost či osoba, která zadala úkol • Zadání úkolu – konkrétní popis úkolu • Termín zadání – datum, kdy byl úkol zadán • Požadovaný termín splnění – datum, dokdy má být úkol splněn • Termín splnění – datum skutečného splnění úkolu • Odhad – časový, finanční, personální odhad náročnosti úkolu • Vlastník úkolu 6. Přidávání komentářů k jednotlivým úkolům • Vlastníkem úkolu • Dalšími uživateli systému 7. Zaznamenání související komunikace se zadavatelem • Jednání, telefony, emaily • Datum uskutečnění • Informace 8. Možnost delegování úkolů • Přidělení jinému uživateli • Uložení úkolu bez vlastníka (nabídka)

2.4. OBECNÉ POŽADAVKY

5

• Automatické přidělení podle filtru 9. Sledování času stráveného na jednotlivých úkolech • Datum provádění úkolu • Časové rozmezí • Poznámky k příslušné časové položce 10. Zadávaní času ručně nebo pomocí systému automaticky po spuštění časomíry 11. Možnost zobrazení detailního časového rozpisu nebo celkový čas strávený řešením úkolu

2.4

Obecné požadavky

Systém pro správu požadavků a úkolů má být koncipován jako webová aplikace s přístupem přes webový prohlížeč. To z důvodu snadného přístupu z různých zařízení, jako jsou počítače, chytré mobilní telefony a mobilní telefony s připojením k internetu obecně. Tato forma systému (webová aplikace s přístupem přes webový prohlížeč) zajišťuje platformě nezávislou aplikaci. Firma disponuje fungujícím webovým systémem založeným na jednoduchém firemním PHP frameworku. Systém pro správu úkolů by měl být postaven také na tomto PHP frameworku. Firma disponuje rovněž serverem, na kterém je spuštěna podpora PHP. Dosavadní firemní data (klienti, uživatelé, zakázky), se kterými bude systém pracovat, jsou ukládána v MySQL databázi. Je nutné tedy využívat prostředků vhodných ke komunikaci s tímto typem databází. Uživatelské prostředí systému musí být přístupné a ovladatelné přes webové rozhraní na osobním počítači a také pro chytré mobilní telefony s připojením k internetu a webovým prohlížečem, aby byla aplikace dostupná v co největším měřítku. Shrnutí nefunkčních požadavků • Fungování systému na současném webové serveru • Naprogramování v jazyku PHP s využitím frameworku • Využívání MySQL databáze k práci s daty • Dostupnost systému přes klasické webové i mobilní rozhraní

2.5

Cíle projektu

Cílem projektu je vytvořit webovou aplikaci sloužící k sjednocení, zjednodušení a zefektivnění vedení úkolů, požadavků a sledování času na nich strávených, na základě funkčních i nefunkčních požadavků, které jsou popsány výše. Tato aplikace si bere za cíl vyřešit problémy naznačené v sekci současný stav.[??]

6

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

Kapitola 3

Analýza a návrh aplikace 3.1

Přehled existujících řešení

Systémů a nástrojů pro správu úkolů, projektů a sledování časů existuji stovky, liší se mezi sebou použitou platformou (online, desktop, mobilní), cenou (zdarma, placené), svou náročností na instalaci, možnostmi a poskytovanými službami. Tato kapitola je proto rozdělena na několik částí: aplikace zabývající se správou úkolů, systémy zabývající se sledováním času stráveného na úkolech a komplexní nástroje pro řízení projektů. Existují i aplikace, které patří do obou skupin zároveň. Zde uvedené aplikace jsou výběrem těch nejvíce používaných a nejkvalitněji či zajímavě zpracovaných.

3.1.1

Online nástroje na správu úkolů založené na GTD

Společným rysem následujících aplikací je jejich pojetí jako online nástrojů, ke kterým je možno přistupovat pomocí webového prohlížeče a také mobilního telefonu. Aplikace jsou postaveny na metodice GTD - getting things done, která je vysvětlena v kapitole 3.6.1 Getting Things Done. Aplikace nenabízejí standardně zaznamenávání časů u jednotlivých úkolů, jelikož tento funkční požadavek metodika nevymezuje.

Task.fm • Jednoduchý a přehledný nástroj • Možnost tagování úkolů, nastavení upomínek přes sms, email, twitter • Nemá podporu týmové spolupráce • cena je $4 za měsíc a osobu • http://task.fm/

7

8

KAPITOLA 3. ANALÝZA A NÁVRH APLIKACE

Google Tasks • Velmi jednoduchý nástroj • Provázanost s emailovou službou Gmail • Nemá nativní podporu týmové spolupráce • Je zdarma • http://mail.google.com/mail/help/tasks/ Get it done • Jednoduchý a komplexní nástroj • Podporuje vytváření projektů, delegování a tagování úkolů, možnost přidávat přílohy, upomínky • Má podporu týmové spolupráce • Aplikace pro iPhone • Je zdarma na 15 dnů, poté $39 ročně • http://getitdoneapp.com/ Remember The Milk • Velmi kvalitní nástroj • Podporuje vytváření projektů, delegování a tagování úkolů, možnost upomínek, nastavení opakování úkolů, má své vlastní api • Je v češtině • Má podporu týmové spolupráce • Podpora aplikací do většiny mobilních telefonů • Je zdarma v základní variantě, za mobilní variantu příplatek $24 • http://www.rememberthemilk.com/ Vitalist • Kvalitní intuitivní nástroj • Podporuje vytváření projektů, delegování a tagování úkolů, možnost upomínek, nastavení opakování úkolů, možnost zaznamenávat předpokládaný čas práce • Má podporu týmové spolupráce • Verze zadarmo je omezená na 5 projektů, verze basic $49, premium $99 • http://www.vitalist.com/

3.2. OFFLINE NÁSTROJE PRO SPRÁVU ÚKOLŮ

9

Nozbe • Kvalitní nástroj • Podporuje vytváření projektů, delegování a tagování úkolů, možnost upomínek, export úkolů, kalendář, možnost zaznamenávat čas stavený na úkolu • Má podporu týmové spolupráce • Aplikace pro iPhone • Zkušební verze zdarma, základní $42, profesionál $408 • http://www.nozbe.com/ Toodledo • Kvalitní nástroj s velkou možností nastavení, horší vzhled • Podporuje vytváření projektů, delegování a tagování úkolů, možnost upomínek, nastavení opakování úkolů, export a import úkolů, možnost nastavovat prioritu, kontexty a cíle úkolů • Má podporu týmové spolupráce • Verze zadarmo je omezená, verze PRO $15, PRO PLUS $30 • http://www.toodledo.com/

3.2

Offline nástroje pro správu úkolů

Následující nástroje je nutno provozovat na pc nebo mobilním telefonu. Přenos úkolu mezi pc a mobilním telefonem se provádí synchronizací těchto dvou zařízení. Tyto nástroje se dají rovněž používat v souladu s GTD metodikou.

Outlook • Poštovní klient, který má podporu zaznamenávání úkolů • Podporuje delegování a tagování úkolů (za pomocí plug-in), možnost upomínek, nastavení opakování úkolů, export a import úkolů • Má podporu týmové spolupráce • Za pomoci dalších produktů, jako např. sharepoint má možnost publikovat online • Platfomra MS Windows • Cena produktu se pohybuje mezi $75 - $349

10


Things • Nástroj vytvořený podle metodiky GTD • Podporuje vytváření projektů, delegování a tagování úkolů, možnost upomínek, nastavení opakování úkolů • Má podporu týmové spolupráce • Platfomra Mac OS • Cena produktu je $50 • http://culturedcode.com/

3.3

Online nástroje pro podporu projektů

Jedná se o webové systémy na podporu týmové spolupráce na projektech. Slouží k řízení projektu, zaznamenávání úkolů a plnění požadavků.

Basecamp • Nejpoužívanější online produkt pro řízení projektů • Podporuje vytváření projektů, delegování a tagování úkolů, možnost upomínek, nastavení opakování úkolů, možnost sdílení dokumentů, sledování času stráveného na projektech • Je založen na podpoře týmové spolupráce • Platformou pro aplikaci je web • Možnost přístupu přes mobilní rozhraní • Cena produktu se pohybuje od $24 do $190 za měsíc, a to podle počtu projektů a sdíleného místa • http://basecamphq.com/

Active collab • Online nástroj, který si uživatel může po zakoupení hostovat na svém serveru a volně upravovat • Podporuje vytváření projektů, delegování a tagování úkolů, možnost upomínek, nastavení opakování úkolů, možnost sdílení dokumentů, sledování času stráveného na projektech, propojení s emailem • Je založen na podpoře týmové spolupráce

3.4. ONLINE NÁSTROJE PRO SLEDOVÁNÍ ČASU

11

• Platformou pro aplikaci je web • Možnost přístupu přes mobilní rozhraní • Cena produktu je $249 za základní verzi pro malé firmy a $499 za pokročilejší verzi • http://www.activecollab.com/

3.4

Online nástroje pro sledování času

Nástroje určené pro sledování času stráveného na projektech. Jedná se o jednoduché nástroje navržené tak, aby neobtěžovaly uživatele náročností použití. Jsou dostupné i přes webové rozhraní. Následující dva nástroje jsou vybraní zástupci této kategorie. • LiveTimer - http://www.syncd.com/ • Simply invoices http://www.simplyinvoices.com/

3.4.1

Souhrn posuzovaných aplikací

Posuzované aplikace se zaměřením na online platformu se vyznačovaly přehledným, jednoduchým vzhledem společně s intuitivním ovládáním, podporovaným JavaScript technologií. Zejména pak za využití JavaScript frameworkových knihoven, jako jsou například jQuery nebo Prototype. Souhrnem rešerše uvedené výše je tabulka. Jedná se o přehledný souhrn zjištěných údajů. Jednotlivé sloupce popisují: • Název - název posuzované aplikace • Platforma - zařízení na kterém je aplikace provozována. Web - online nástroj, Win MS Windows, Mac - Apple Mac OS, Lin - Linux. • Mobilní - posouzení jestli lze k aplikaci přistupovat přes mobilní telefon, x znamená ano, sync - znamená, že se úkoly a požadavky synchronizují po připojení k počítači, znamená, že mobilní verze není nijak podporována • Tým - představuje možnost pracovat v týmu s kolegy za pomocí dané aplikace, jedná se zejména o delegování úkolů • Čas - pokud lze u daných úkolů zaznamenávat čas na nich strávený, je v tabulce označena aplikace x, v opačném případě • Cena - je zde uvedena nejnižší cena, za kterou lze aplikaci provozovat na jeden rok. Pokud je uvedeno -, program je zdarma

12


Název Task.fm Google Tasks Get it done Remember The Milk Vitalist Toodledo Nozbe Outlook Things Basecamp Active collab

Platforma web web web web web web web Win Mac web web

Mobilní x x x x x x x sync sync x x

Tým x x x x x x x x x

Čas x x x

Cena $48 $39 $49 $30 $42 $75 $50 $228 $249

Tabulka 3.1: Souhrn vlastností aplikací

3.5

PHP framework

V zadání práce je uvedeno, že aplikace bude postavena na firemním frameworku. Po dohodě se zadavatelem byl však místo firemního frameworku použit jeden z volně dostupných, běžně používaných frameworků se zachováním konektivity na stávající data. Je to zejména kvůli implementování aplikace při použití některého z navrhových vzorů a standardních postupů tvorby kódu tak, aby výsledný produkt vyhovoval nejen komerčnímu, ale také akademickému pojetí práce. A také proto, aby kód systému byl čitelný na základně volně přístupné dokumentace i pro osoby, které nejsou přímo spojeny s chodem firmy či vývojem firemního frameworku.

3.5.1

Výběr PHP frameworku

Pro výběr vhodného frameworku pro zadanou aplikaci bylo stanoveno několik základních kriterií, která framework musí splňovat. Jelikož existují desítky PHP frameworků, je zde uveden výběr pouze z těch běžně nejvíce používaných. • Volně šiřitelný pod licencí BSD nebo GNU • Podporující práci s MySQL databází • Dobře dokumentovaný • Jednoduchý k ovládání a pochopení • S velkou uživatelskou základnou - pro případně dotazy a problémy • Podporující návrhové vzory, například MVC • S dalšími i knohovnami pro podporu práce

3.6. METODIKY PLÁNOVÁNÍ ÚKOLŮ

3.5.2

13

Vhodné PHP frameworky

Při posuzování frameworků je vycházeno z jejich oficiálních popisů, hodnocení uživatelů a obecných testování výkonnosti. Stanoveným podmínkám nejlépe vyhovují následující frameworky: • Zend Framework • Symfony • CodeIgniter • CakePHP • Nette - český framework

3.5.3

CodeIgniter

Pro implementování aplikace byl vybrán framework CodeIgniter. Jedná se o jednoduchý a intuitivní framework, který nenabízí tolik doplňujících tříd jako například Zend Framework nebo Symphony, ovšem pro aplikaci tohoto typu je naprosto dostačující. Lze jej ovšem i kombinovat s pomocnými třídami určenými například pro Zend framework dle případné potřeby. Vyniká svou rychlostí zpracování a vyřízení požadavků. Je velmi přehledně dokumentován, což podporuje strmou křivku učení se s tímto frameworkem. Nastavení frameworku se provádí za pomocí editace 3 souborů a není vyžadována žádná instalace. Využívá návrhový vzor Model View Controler (MVC). Obsahuje podporu pro PHP 4 i 5 a také různé typy databází, včetně MySQL. Jeho součástí je řada podpůrných knihoven. Například to jsou: • Database Class – slouží k vytváření dotazů nad databázovým systémem, inspirováno návrhovým vzorem ActiveRecord • Session Class – ukládání perzistentních dat uživatelského sezení pomocí cookies nebo databáze • Form Validation Class – na základě určených pravidel provádí kontrolu vstupních dat a zobrazuje chybové zprávy, může filtrovat nebezpečné vstupy • Form Helper - generování formulářových prvků • HTML Helper – generuje některé značky jazyka HTML • URL Helper – užitečné funkce pro práci s řetězci URL

3.6

Metodiky plánování úkolů

Metodika plánování úkolů je sada postupů, doporučení a nástrojů pro plánování času, obvykle za účelem zvýšení efektivnosti využití pracovního i osobního času s cílem splnění všech daných úkolů. Existuje celá řada těchto metodik. Většina z nich radí uživateli vymezit si cíle, kterých chce dosáhnout a poté si naplánovat kroky k jejich dosažení.

14


3.6.1

Getting Things Done - GTD

Jedna z celosvětově populárních a uznávaných metodik pod názvem „Getting Things Done“ se, kromě vytyčení si klasického cíle práce, orientuje také na doporučený postup, neboli kroky k třídění a záznamu úkolů, které uživatele potkávají. Jedná se tedy o metodiku, která je vhodná i k řízení pracovního procesu. Metodika se nesnaží o změnu samotného uživatele, ale o navržení technik a postupů pro snazší splnění vytčených úkolů. Tvůrce této metodiky David Allen zakládá svou metodiku na tvrzení, že mozek člověka není uzpůsoben k pamatování si a připomínání každodenních úkolů, schůzek a dalších záležitostí. Za tímto účelem metodika doporučuje použití externího nástroje či systému pro zaznamenávaní všech úkolů, které uživatel nosí v hlavě. To dovoluje využít plné kapacity mozku na soustředění a provedení jednotlivých úkolů. Metoda rozděluje zpracování každého úkolu do 5 základních kroků. Tyto kroky se dají vyjádřit také diagramem. 1. Sesbírat - sepsat všechny dané úkoly a požadavky do systému pro jejich vedení, do takzvané schránky 2. Zpracovat - projít všechny úkoly ve schránce a rozhodnout o jejich dalším postupu (zda, kdy, jak, s kým a jak dlouho bude úkol řešen), rozplánování či případném smazání. Pokud plnění úkolu zabere méně jak 2 minuty, rovnou ho splnit. Pokud se nejedná úkol pro vás určený, delegovat ho. 3. Zorganizovat - jednotlivé úkoly rozřadit do přehledných skupin, doporučeno je přitom používat těchto 5 skupin • Další kroky - jednotlivé kroky vedoucí ke splnění úkolu, například „Volat do banky“ • Projekt - skupina s většími dlouhodobými úkoly • Někdy možná - úkoly, které jsou spíše nápady do budoucna, bez aktuální nutnosti řešit • Kalendář - úkoly s přesným datem nutnosti splnění • Čekám na. . . - úkoly, které byly delegovány, popřípadě vyžadují vyřízení od jiné osoby 4. Zhodnotit - pravidelně kontrolovat jednotlivé kategorie a hodnotit plnění úkolů 5. Udělat - plnit uložené úkoly podle jednotlivých kroků, které byly naplánovány a to podle kontextu místa, času a nutnosti splnit daný úkol Zde uvedený postup je stručnou interpretací celé metodiky. Bližší seznámení s metodikou a další doporučení jsou popsána v knize Getting Things Done, která vyšla v roce 2001 a stala se světovým bestsellerem. Aplikace vytvářená na základě zadání bakalářské práce je navržena s přihlédnutím k doporučením, uvedeným v této metodice. Rovněž se je snaží skloubit se zaznamenáváním času a týmovou spoluprací.

3.7. NÁVRH UŽIVATELSKÉHO ROZHRANÍ

3.7

15

Návrh uživatelského rozhraní

Při tvorbě uživatelského rozhraní bylo dbáno na jednoduchost a přehlednost ovládání a práce s aplikací. Bylo přihlíženo k doporučením ohledně přístupnosti webových stránek. Finální návrh rozložení prvků na stránce vychází také ze vzhledu dalších aplikací na trhu, které byli popsány v přehledu existujících řešení. ??

Obrázek 3.1: Návrh uživatelského rozhraní

3.8

Rozhraní pro mobilní telefon

Systém pro správu požadavků a úkolů má být dle zadání dostupný jednak přes webový prohlížeč počítače, ale také přes mobilní telefon s připojením k internetu. Tyto dva způsoby přístupu k systému se mezi sebou liší a to z několika důvodů: • Fyzická velikost displeje mobilního telefonu je několikanásobně menší než u klasického osobního počítače • Obrazové rozlišení těchto dvou zařízení je velmi rozdílné • Rychlost připojení k internetu bývá u mobilního telefonu standardně nižší než u PC • K ovládání některých typů mobilních telefonů slouží neplnohodnotná klávesnice, je nutné tedy využívat zjednodušených navigačních prvků • Způsob ovládaní a parametry mobilních telefonu jsou více různorodé než je tomu u PC Z těchto důvodů byly vyvinuty odlišné formáty pro tvorbu webových stránek pro mobilní telefony a pro osobní počítače, pro které se v současnosti nejvíce využívá jako základ technologie HTML, XHTML. Formáty pro mobilní telefony svou specifikací ovšem z těchto

16


„klasických“ formátů vychází. Jsou zjednodušeny, a to zejména vypuštěním některých formátovacích značek a také menší podporou dalších funkcí, jako je například JavaScript. S rozvojem mobilních technologií se ovšem tyto rozdíly postupně stírají.

3.8.1

Mobilní webové standarty

Pro mobilními telefony se stále doporučuje využívat formátů právě pro tento způsob publikace určených. Mezi používané standarty dnes patří: • cHTML - Compact HTML, používá se především v Japonsku, jedná se o zjednodušené odvětví HTML, tato technologie je na ústupu • WML 1.x - Jazyk WML patří k nejstarším standardům, vytvořen byl v roce 1997. Podporuje ho stále mnoho prohlížečů a na některých trzích se dosud hojně využívá. Byl zahrnut do specifikace WAP1 • WML 2.x - Nástupce WML 1.x, vytvořen za účelem zpětné kompatibility. Tento jazyk se nevyužívá. • XHTML Basic - verze jazyka XHTML, obsahuje pouze elementy, které nejsou výpočetně složité, používá se proto v zařízeních s malou operační složitostí. Byla zde vypuštěna například podpora CSS stylů a JavaScriptu. • XHTML MP - v současnosti nejpoužívanější jazyk pro tvorbu mobilních webových stránek. Jeho použití je doporučeno také konsorciem W3C2 . Jedná se o oficiální jazyk specifikace WAP 2.x, který nahradil WML. Formát je široce podporován většinou mobilních výrobců. Jako formát svého mobilního webu jej využívají společnosti jako Google, Nokia, Seznam. Vychází z XHTML Basic, přidává formátovací značky, částečně JavaScript a také použití stylů. • WCSS - WAP CSS, jedná se o formátovací jazyk vycházející z klasického CSS. Byly zde vypuštěny pravidla, jenž jsou v mobilním telefonu nepoužitelná. Je zahrnut ve specifikaci WAP 2.x.

3.8.2

Rozložení mobilního webu

Při navrhování rozmístění a vzhledu prvků webové stránky je nutné vycházet z poměru stran a rozlišení displeje, na kterém bude výsledná stránka zobrazena. U mobilních telefonů se v dnešní době pohybuje standardně šířka displeje mezi 128 – 320px. Podle doporučení W3C je vhodné navrhovat layout stránky pro displej s minimální šířkou 200px a optimální šířkou 250px. A to s ohledem na správné nastavení možnosti roztahovaní do šířky. Na obrázku ?? jsou naznačeny běžné rozlišení mobilních telefonů. 1

Wireless Application Protocol, mezinárodní standart zahrnující jazyky XHTML MP a WCSS. Je určen pro tvorbu internetových stránek pro mobilní přístroje. 2 World Wide Web Consortium, Cílem konsorcia je „rozvíjet World Wide Web do jeho plného potenciálu vývojem protokolů a směrnic, které zajistí dlouhodobý růst Webu“. Toto konsorcium vydává doporučení (standarty) pro tvorbu webových stránek

3.9. PŘÍPADY UŽITÍ

17

Obrázek 3.2: Rozlišení mobilního telefonu

Tvorba layoutu stránky je podřízena rovněž poměru stran displeje. Podle doporučení W3C je vhodné navrhovat rozložení prvků řazených pod sebe, nikoliv vede sebe, jak je tomu u klasického webu. Tím se myslí například menu umístěné na levé straně od hlavní obsahové části. ?? Je nutné si také uvědomit, kdy uživatel přistupuje k mobilnímu webu. Většinou je tomu v případech, kdy je někde na cestách, při jednání, kdy potřebuje rychle zapsat nebo dohledat svůj požadavek. Návrh layoutu by měl být tedy velmi snadno ovladatelný a přehledný bez prvků, které by odváděly uživatelovu pozornost.

3.9 3.9.1

Případy užití Uživatelé systému

Systém rozlišuje 3 základní uživatelské role, podle kterých jsou rozdělena oprávnění k funkcím systému. Vztah mezi těmito rolemi je tvořen postupným děděním, každá následující role přebírá možnosti předchozí. • Nepřihlášený uživatel • Přihlášený uživatel

18


Hl a v i č k a

Hl a v i č k a Na v i ga c e

Na v i ga c e

Obs a h

Pa t i č k a

Obs a h

Pa t i č k a

Kl a s i c k ýweb Mobi l ní web

Obrázek 3.3: Rozmístění prvků na stránce

• Vlastník úkolu

3.9.2

Obecné případy

Na obrázku ?? případu užití jsou zobrazeny základní skupiny operací. Složitější uživatelské případy jsou z důvodu přehlednosti UML diagramu popsány dále v textu. Přihlášení Nepřihlášený uživatel má jedinou možnost, kterou je přihlášení do aplikace. Je mu nabídnut přihlašovací formulář pro zadání jména a hesla. Systém ověří platnost zadaných údajů a uživatele po vyhodnocení buď přihlásí nebo mu nabídne formulář k opravě. Registrace Oproti standardnímu návrhu aplikace zde chybí možnost registrovat se. Tato možnost zde není z toho důvodu, že využívá již stávající uživatele, vedené v systému firmy, na který je tato aplikace napojena. Pro zkušební užití lze přidat uživatele do databáze pomocí speciální nadstavbového formuláře. Odhlášení Přihlášený uživatel má možnost zvolit odhlášení. Systém jeho roli přepne do stavu nepřihlášený.


19

Obrázek 3.4: Případy užití - obecné případy

Přidání úkolu Přihlášený uživatel může zapsat svůj úkol do formuláře, systém ověří vstupní formulář a daný úkol uloží do systému. Přihlášený uživatel se tímto stane vlastníkem úkolu. A jsou mu povoleny operace s úkolem popsané dále v této sekci. Vlastníkem úkolu se může stát také pomocí delegování úkolu.

Správa času, správa komentáře, správa komunikace Jedná se o tři triviální skupiny případů užití. Vlastník úkolu tyto funkce může použít u vybraného úkolu • Založení - uživatel vloží informace do formuláře, systém je ověří a uloží • Editace - úprava již vložených informací přes formulář, do kterého systém načte předchozí data a poté je uloží • Smazání - systém na základě uživatelova vstupu vymaže nenávratně danou položku

Správa kategorii Uživatel může přidávat nebo mazat kategorie, do kterých systém řadí na základě uživatelských nastavení úkoly. Každou z těchto kategorií systém umožňuje uživateli zvolit.

20


Obrázek 3.5: Případy užití - správa úkolu

3.9.3

Správa úkolu

Prohlížení úkolu Vlastník může každý svůj úkol prohlížet. Spolu s tím mu systém nabídne příslušné informace k úkolu, jako jsou komentáře, časový přehled prací na úkolu, informace o jednáních, informace o zákazníku, kontakty, kdo na úkolu spolupracuje. Editace úkolu Vlastník při prohlížení úkolu může editovat veškeré informace v zadání úkolu, přidávat kontakty, zákazníky. Systém zadané udaje ukládá. Dokončení úkolu Vlastník má možnost označit úkol jako splněný. Systém tuto možnost zohlední při výpisu úkolů. Přesunutí úkolu do koše Vlastník může přesunout úkol do systémového koše. Systém tento úkol vede poté jako vyřazený, ovšem dovoluje uživateli úkol zpět z koše vrátit a pokračovat s ním v práci.


21

Smazání úkolu Vlastník má možnost smazat úkol zcela ze systému. V takovém případě systém úkol vymaže a není možné jej navrátit zpět. Změna kategorie úkolu Uživateli je umožněno přesouvat úkol libovolně mezi kategoriemi, které si založil. Systém mu nabídne výběr z těchto kategorií a také zajistí zobrazení úkolu v příslušné kategorii. Delegování úkolu Vlastník může zvolit další spolupracovníky úkolu, systém mu nabídne seznam uživatelů. Vlastník vybere uživatele, kterému chce úkol delegovat a nastaví oprávnění k tomuto úkolu, systém uživateli přiřadí oprávnění.

3.9.4

Zobrazení úkolů

Obrázek 3.6: Případy užití - zobrazení úkolů

Filtrování úkolů Uživatel si může nastavit zobrazení pouze některých úkolů, splňujících parametry ve formuláři, které zadal. Systém poté nastaví výpis úkolů. Řazení úkolů Uživateli je dovoleno nastavit, podle kterého parametru chce úkoly řadit, systém toto řazení provede a zobrazí výsledky.

22


Zobrazení splněných úkolů, koše Uživatel může vybrat, zda chce zobrazit pouze úkoly, které již splnil, nebo ty, které přesunul do koše. Systém poté zobrazí úkoly splňující zadání.

3.9.5

Mapování funkčních požadavků

Přihlášení Přidání úkolu Delegování úkolu Prohlížení úkolu Editace úkolu Filtrování úkolů Řazení úkolů Zobrazení úkolů Správa času Správa komentáře Správa komunikace

1 •

2

3

4

5

6

7

8

9

10

11

• • • •

•

•

• •

•

•

• • •

•

• •

Tabulka 3.2: Mapování funkčních požadavků na případy užití Tabulka ?? zobrazuje mapování funkčních požadavků na případy užití. Každý sloupec představuje jeden funkční požadavek stanovený v zadání práce, je zde dodrženo číslování funkčních požadavků. Z tohoto přehledu je tedy patrné, že zvolené případy užití dostatečně pokrývají všechny zadané požadavky.

3.10

Architektura aplikace

Architektura aplikace vychází s návrhového vzoru, který je podporován frameworkem. Stejně, jako u většiny jiných PHP frameworků, i zde je použit návrhový vzor MVC (Model, View, Controller). Tento návrhový vzor rozděluje aplikaci na tři logické části. Na obrázku je znázorněn vztah těchto tří částí společně společně s uživatelem systému. • Model (model) - Reprezentuje datovou strukturu. Obsahuje obvykle metody pro práci s databází, práci se sessions, cookies. Metody modelu jsou obvykle volány controllerem aplikace, kam jsou opět data navráceny. Technologie použité v modelu jsou PHP, MySQL, sessions. • View (pohled) - Slouží pro prezentování dat uživateli za pomocí HTML a jednoduchých PHP procedur, jako jsou rozhodování (if, else) a iterace (for). Předává informace o změně controlleru, který na něj reaguje. Může zobrazovat přímo stav modelu, obvyklejší postup ovšem je, že view je sestaven controllerem.

3.11. NÁVRH DATABÁZE

23

• Controller (řadič) - Slouží k přijímání vstupu od uživatele nebo změn z view. Na tyto změny reaguje a podle potřeb mění model aplikace, načítá data z modelu nebo mění view aplikace. Framework má poměrně volný přístup k nutnosti využívat návrhový vzor MVC tak, jak je standartě doporučeno a veškerá aplikační logika může být obsažena v controlleru aplikace. Je to výhodné pro začínající programátory, jelikož mohou využít postup, který je jim nejbližší. Obecně se ovšem doporučuje využívat standardního pojetí MVC. Tento návrhový vzor [??] je pro danou aplikaci vhodný právě z toho důvodu, že odděluje aplikační logiku od prezentační. To má za důsledek snadné vytvoření mobilní i klasické verze programu, které se liší právě jen v prezentační části. Aplikační logika zůstává stejná. Je tak ušetřeno psaní redundantního kódu.

Obrázek 3.7: Model, view, controller

3.11 3.11.1

Návrh databáze Konceptuální model

Konceptuální model [?? ]popisuje vztah entit vyplývajících ze zadání práce. Nejednotnost názvů entit vznikla propojením nově navržených entit a entit, které se již ve firemním systému nachází a dle zadání mají zůstat beze změn. Jsou to: Users, Klienti, Nabídky a Kontakty. Atributy jednotlivých tříd vychází z funkčních požadavků. Jelikož se jedná pouze o konceptuální model, nejsou zde uvedeny jejich datové typy. Atributy i s datovými typy jsou uvedeny v datovém modelu. User, Task Hlavním vztahem modelu je vztah entity User (uživatel) a Task (úkol). Jedná se o vztah kardinality N:N, jelikož uživatel může být vlastníkem několika úkolů a úkol může vlastnit několik uživatelů.

24


Comment, Communication, Time Uživatel může k jednotlivým úkolům přidávat komentáře (Comment), informace o komunikaci (Communication), zapisovat časové položky (Time). Tyto tři entity mají stejný vztah k entitě User a Task, kardinality N:1, liší se pouze atributy. Každou z nich vytváří jeden uživatel, který jich může vlastnit neomezeně. Entity patří k jednomu úkolu, který jich může vlastnit neomezeně. Cyklický vztah 1:N na entitě Task značí možnost vytvářet podúkoly, kdy úkol může mít neomezeně podúkolů, pod-úkol má jediný nadúkol. Čili se jedná a vztah otec-syn.

Group Další vztah mezi uživatelem a úkolem je přes entitu Group (skupina). Úkoly se řadí do skupin, ve kterých jich může být neomezeně. Každý úkol přitom patří právě do jedné skupiny, kardinalita N:1. Každá skupina patří právě jednomu uživateli, který jich může vytvořit opět neomezeně, kardinalita 1:N.

Kontakt, Klient, Nabídka Entity Kontakt, Klient, Nabídka jsou převzaty ze stávajícího firemního systému a jsou provázány vztahem s entitou Task s kardinalitou N:1. Úkol má jednoho klienta, kontakt, nabídku a tyto 3 entity mohou být ve více úkolech.

Obrázek 3.8: Konceptuální model


3.11.2

25

Databázový model

Databázový model ?? vychází z konceptuálního modelu aplikace a je upraven tak, aby vyhovoval typu databáze MySQL, na které je využit. V diagramu se nachází české a anglické názvy tabulek; tato nejednotnost vznikla využíváním tabulek, které jsou již vedeny ve firemní databázi a jejich struktura je zachována z důvodu nutnosti propojení na stávající data (vyplývá ze zadání). Pro přehlednost jsou zde z těchto tabulek uvedeny pouze položky, které jsou důležité pro fungování systému. Tabulky již používané ve firemní databázi jsou: • Users - tabulka uživatelů systému • Klienti - tabulka s klienty firmy • Koktany - tabulka s kontakty na klienty • Nabídky - tabulka s nabídkami pro klienty Všechny atributy tabulek byly doplněný o datové typy používané v MySQL databázích. Vysvětlení užití jednotlivých datových typů v kontextu aplikace: • Int - datový typ pro ukládání celých čísel, v aplikace určen zejména k ukládání ID • Tinyint - datový typ integer, používán v aplikaci pro ukládání argumentu typu boolean, reprezentován 0/1 • Text - ukládání rozsáhlých dat, zejména pro popisy úkolů, komentáře a komunikaci • Varchar - ukládání textových řetězců o délce 0-255 znaků, sloužící k ukládání kratších řetězců, jako jsou nadpisy, uživatelská jména, emaily • Date - formát pro ukládání data ve tvaru rrrr-mm-dd • Time - čas ukládaný ve formátu hh:mm:ss, slouží například pro uložení doby trvání úkolu • Timestamp - aktuální datum a čas při ukládání záznamu Owners V konceptuálním modelu byl použit vztah mezi entitou User a Task kardinality N:N. Tato kardinalita musí být pro správný chod databáze interpretována jako další databázová tabulka. V modelu je pojmenována jako Owners (vlastníci). Tato tabulka umožňuje spolupráci několika uživatelů. Sessions Tabulka slouží pro ukládání uživatelských sezení na serveru místo ukládání v uživatelově PC. K těmto údajům uživatel přistupuje pomocí klíče session-id, který se jediný ukládá v podobě cookie do uživatelova zařízení. Tabulka obsahuje argumenty o uživatelově IP adrese, prohlížeči a položku data, do které se ukládají uživatelská data. Více o sesion v implementaci.

26


Items Objekt Items není tabulkou, ale pohled vytvořený za účelem snazší manipulace s daty v tabulkách Owners a Task. Tento pohled zmíněné tabulky spojuje podle task-id tak, aby u každého úkolu byl veden uživatel a jeho čas na úkolu i s dalšími položkami úkolu. Vysvětlivky k modelu • žluté klíče - primární klíč • červená značka - cizí klíč • modrá značka - běžná položka


27

Obrázek 3.9: Databázový model

28


Kapitola 4

Implementace aplikace 4.1 4.1.1

Implementační nástroje Vývojové prostředí

Jako vývojové prostředí byl použit NetBeans, verze 6.8. Toto prostředí je open source programem. Primárně byly NetBeans vytvořeny pro programování v jazyku Java. Postupem času se přidala i podpora dalších programovacích jazyků, jako C++, Ruby, Python. A od verze NetBeans 6.5 také jazyky pro tvorbu webových stránek za pomocí PHP, JavaScript, CSS, HTML a MySQL. NetBeans nabízí kompletní vývojové prostředí pro tvorbu webových stránek. Editor PHP je vybaven automatickým doplňováním kódu, který má přehled o ostatních funkcích, kontrolou a debagováním programu, testováním tříd. Nechybí podpora frameworků Zend, Symphony, Cake. Vývojové prostředí podporuje také tvorbu JavaSript, XHTML a CSS kódu, opět s nástroji pro komfortní práci programátora. Má v sobě také zabudovaného SQL klienta, takže je zde i podpora psaní MySQL kódu s přímým přístupem do databáze. V neposlední řadě je také výhodou zabudovaný FTP klient a tedy podpora vkládání vytvořeného programu přímo na server. Bez dalších prodlev a komplikací. Toto vývojového prostředí lze provozovat na operačních systémech MS Windows, Linux a Apple Mac os.

4.1.2

Testování mobilního webu

Pro testování mobilní verze aplikace při vývoji, bylo využito vestavěné komponenty prohlížeče Safari, web inspector. Ta umí emulovat prostředí mobilního telefonu. Nebylo tak nutné instalovat žádné další doplňky.

4.1.3

Lokální server

Pro snadné testování aplikace, zejména při tvorbě programu, byl využit lokální server, který urychloval práci bez nutnosti odesílat data přes FTP na vzdálené servery. Bylo využito instalačního balíku s názvem MAMP, jenž v sobě zahrnuje Apache 2.0.63 server, PHP 5.3.2 a MySQL 5.1.44. Instalace těchto serverových komponent je tedy velmi jednoduchá. Navíc s balíkem se instaluje i nástroj phpMyAdmin 3.2.5, sloužící k dotazovaní na databázi. MAMP

29

30

KAPITOLA 4. IMPLEMENTACE APLIKACE

je určen pro uživatele Apple Mac os, pro uživatele MS Windows existuje podobný balík pod názvem WAMP a pro uživatele Linuxu LAMP

4.1.4

Návrh databáze

Pro návrh databáze byl použit nástroj MySQL Workbench 5.1. Je to program pro grafické navrhování struktury databáze na základě diagramu vycházejícího z UML. Usnadňuje tak tvorbu složitějších a více provázaných databází. Tento nástroj z diagramu vytvořeného uživatelem vygeneruje SQL kód, kterým lze přímo v nástroji upravit databázi. Program umí z již existující databáze vytvořit reverzním inženýrstvím diagram, který se pak dá dále upravovat. Lze také propojit nástroj s databází a tu pak přes tento nástroj spravovat. Tento nástroj je zcela zdarma a je uživatelsky velmi přívětivý.

4.2

Technologie

Pro implementaci je použit jazyk PHP, verze 5.3. Pro ukládání dat je využito MySQL databáze. Pro tvorbu uživatelského rozhraní jsou použity technologie XHTML, CSS a JavaScript. Tyto implementační předpoklady vychází z nefunkčních požadavků popsaných v zadání a získaných informací, popsaných v kapitole analýza a návrh.

4.2.1

PHP

PHP (Hypertext Preprocessor) je skriptovací programovací jazyk. Využívá se převážně pro programování webových aplikací a dynamických internetových stránek. Skripty jsou vykonávány a zpracovány na straně serveru na základě vstupů uživatele a po zpracování na serveru jsou vráceny výstupy zpět na klientskou část. Uživatel nemá přístup k samotnému PHP kódu bez přístupu k serveru, na němž je kód umístěn. Syntaxe jazyka je podobná jazyku C nebo Java. Jedná se o interpretovaný jazyk s multiplatformní podporou. Je široce podporován poskytovatelem webhostingových služeb. Pro ulehčení práce obsahuje několik knihoven, například pro práci s grafikou, soubory, texty. Má podporu komunikace s databázemi typu MySQL, PostgreSQL a dalších. Vyvíjí se od roku 1994, současná nejnovější verze jazyka PHP je verze 5.3.2 z března 2010, pracuje se na verzi PHP 6.0. Od verze 5.0 podporuje objektově orientované programování. Pro vývoj aplikace bylo použito PHP ve verzi 5.3.

4.2.2

MySQL

MySQL je relační databázový systém typu DBMS (database managment system). MySQL je tvořena z tabulek, mezi kterými mohou existovat vztahy (relace). Práce s databází se provádí pomocí dotazů. Dotazy vycházejí z deklarativního programovacího jazyka SQL (Structured Query Language). Jedná se o velmi rychlý a výkonný typ databáze, který je volně šiřitelný a má tak vysoký podíl na trhu. Využívají ho i firmy, jako například Facebook, Google či Wikipedia. V současné době vývoj MySQL zajišťuje firma Oracle. Podporuje cizí klíče, transakce, poddotazy, uložené procedury, triggery. Aktuálně je používán ve verzi 5.1.44

4.2. TECHNOLOGIE

31

MySQL nabízí různé úložné enginy pro tabulky, které se liší svými vlastnostmi a schopnostmi. Nejpoužívanějšími (a také užitými při implementaci) jsou typy MyISAM a InnoDB. MyISAM postrádá možnost transakcí, používá se pro rychlé vyhledávání a dobrou podporu indexace. Naopak InnoDB podporuje transakce a cizí klíče, ale vyhledávání v tabulce je o něco pomalejší. Pro vývoj aplikace bylo použito MySQL 5.1.44.

4.2.3

XHTML

XHTML (Extensible HyperText Markup Language) je značkovací jazyk pro tvorbu dokumentů pro webové prostředí. Slouží pro vytváření statického obsahu, zobrazeného na webové stránce. Využívá zákonitostí jazyka HTML, které vyhovují podmínkám jazyka XML (Extensible Markup Language) při zachování zpětné kompatibility. Byl vyvinut společností W3C v roce 2000. V aplikaci je použita verze XHTML 1.0 Strict. Tedy ta verze jazyka, která nejvíce dbá na oddělení obsahu stránky od vzhledu. Výhodou této verze je přepnutí všech typů prohlížečů z nestandardního (quirk) módu vykreslování do standardního módu, kdy je chování prohlížeče předvídatelné a je tak ulehčena tvorba CSS stylu.

4.2.4

XHTML MP

XHTML Mobile Profile je jazykem pro tvorbu mobilních webových aplikací, vycházejících z jazyka XHTML a XHTML basic. Tento jazyk byl upraven pro použití v mobilních telefonech, zejména vypuštěním některých tagů. Více v sekci mobilní návrh. V této práci byla použita verze XHTML MP 1.1

4.2.5

CSS

CSS - Cascading Style Sheets, neboli kaskádové styly. Značkovací jazyk, definující zobrazení elementů XHTML stránky. Oproti XHTML nedefinuje obsah, ale vzhled výsledné webové stránky. CSS bylo vyvinuto společností W3C v roce 1996. Poslední vydaná verze je CSS 3.0; ta ovšem není podporována prohlížečem s největším zastoupením na trhu, proto se nejvíce používá verze CSS 2.1 V aplikaci je použita verze CSS 2.1.

4.2.6

WCSS

WCSS - WAP CSS, je verzí CSS pro mobilní telefony. Tato CSS verze je oproti standardní zjednodušena s ohledem na mobilní telefony. Více v sekci mobilní návrh.

4.2.7

Diagram nasazení

Diagram nasazení ?? zobrazuje základní komponenty a jejich propojení. Na straně klienta je to uživatelův osobní počítač nebo mobilní telefon. Na straně serveru webový a databázový server.

32


Obrázek 4.1: Diagram nasazení

Uživatelský počítač musí pro přístup k systému být připojený do sítě internet a vybaven standardním webovým prohlížečem, který dokáže zobrazit hmtl, css a javascript. Podporované jsou následující prohlížeče: • Firefox 0.8+ • Google Chrome • Safari 1.3+ • Konqueror • Netscape Navigator 7.1+ • Opera 6+ • Microsoft Internet Explorer 5.5+ • Mozilla 1.4+ Pro přístup do systému je také vyžadované připojení k internetu a mobilní webový prohlížeč s podporou XHTML (XHTML MP) a CSS (WCSS). JavaScript pro mobilní verzi stránek není vyžadován. Doporučené mobilní webové prohlížeče jsou: • Mobile Safari • Nokia Mini Map Browser

4.3. IMPLEMENTACE APLIKACE

33

• Opera Mini • Opera Mobile • Skyfire • Google Android • Microsoft IE for Mobile • Firefox Mobile Webové prohlížeče zasílají HTTP požadavky webovému serveru, na kterém je nainstalován Apache server, pod kterým je nainstalováno PHP s frameworkem. Webový server komunikuje pomocí SQL příkazů s databázovým serverem, na kterém je MySQL databáze.

4.3

Implementace aplikace

Obrázek 4.2: Výsledná aplikace

4.3.1

Model,View, Controller

Jak již bylo popsáno v návrhu, architektura aplikace se skládá ze tří častí. Jako model aplikace slouží dvě třídy data a user. Třída data se stará o práci s daty v databázi, která je implementována dle návrhu. Třída user reprezentuje množinu funkcí, starající se o data spojená s uživatelem aplikace. Jako controller aplikace bylo implementováno 6 tříd dle konceptuálního modelu. Pro prezentaci aplikace je použito několik view, které byly navrženy v případech užití.

34

4.3.2


Autorizace

Každý uživatel aplikace musí být přihlášený, chce li v aplikaci pracovat. Uživatelé se nemohou do aplikace sami registrovat. Tato nemožnost vychází z principu používání uživatelských účtů již zavedených ve firemním systému. Po zadání jakékoliv url adresy s domovskou adresou systému nebo provádění práce s třídou kontroléru je automaticky kontrolováno, zda je uživatel přihlášen. Pokud ne, je přesměrován na stránku s přihlášením. Automatická kontrola probíhá za pomoci volání funkce v konstruktéru každé třídy reprezentující kontrolér. Je zde volána funkce isLogged z modelu user_model, jenž udržuje uživatelův stav. Ta navrací hodnotu TRUE nebo automaticky zavolá stránku s přihlášením. Po přihlášení se uživatel dostane automaticky zpět na URL kde bylo zjištěno, že není přihlášen. Přihlášení Pro přihlášení do systému je uživatel nucen zadat svoje uživatelské jméno a heslo. Toto jméno a heslo je stejné jako k ostatním aplikacím používaných firmou. Uživatel jméno a heslo zadává do formuláře na samostatné stránce. Po stisknutí tlačítka "přihlásit"se data odešlou metodou POST do kontroléru user, kde je pomocí validátoru implementovaného frameworkem rozhodnuto, zda jsou pole vyplněny. Veškerý vstup je automatický frameworkem očištěn a poté jsou údaje porovnány s uživatelskými údaji v databázi. Je vytvořena session s tímto přihlášením. Po vytvoření sessions funkce zjistí, zda se uživatel přihlásil z mobilního telefonu nebo přes některý z počítačových prohlížečů. Na základě tohoto zjištění se rozhodne, kam uživatele přesměruje; zda na mobilní verzi stránek nebo na adresu, kterou zadal před tím, než se mu zobrazilo okno pro přihlášení. Systém si totiž tuto adresu zapamatuje při přihlašování. Toto řešení je uživatelský velmi přívětivé. Odhlášení Odhlášení uživatele se provede změnou uživatelského modelu user_model. Technicky se v modelu zavolá funkce, která změní parametr přihlášený na FALSE v uživatelově session. Tím je uživatel odhlášen ze systému.

4.3.3

Sessions

Framework poskytuje knihovny pro práci se sessions (sezení). Sessions jsou v aplikaci vyžívána pro přihlášení uživatele a také pro zachování některých krátkodobých nastavení, jakou jsou například volby filtrování úkolů. Sessions jsou ukládána v databázi. Vedou se zde informace o uživatelově prohlížeči, ip adrese, času, kdy se přihlásil a další volitelná data. Jsou to jméno uživatele, id, stav přihlášení. Je tím ulehčen počet dotazů na databázi, jelikož tyto údaje jsou potřebné po celou dobu uživatelova sezení. Uživatel je propojen ze session uloženým v databázi pomocí cookie, které se uloží do uživatelova pc. Obsahuje identifikační číslo sezení. Toto číslo je kontrolováno automaticky


35

oproti číslu sezení v databází, ip adrese počítače a webovému prohlížeči. Tyto opatření slouží ke zvýšení bezpečnosti. Při nečinnosti uživatele 2 hodiny je automaticky session smazána a tím pádem je uživatel odhlášen.

4.3.4

Bezpečnost

Framework obsahuje několik mechanismů pro zvýšení bezpečnosti aplikace. Ty jsou doplněny o vlastní zabezpečení tak aby, veškerá data v aplikaci zůstala zabezpečena. Cross-site scripting - XSS Ve frameworku je zapnuto globální filtrování proti tomuto typu útoku. Útok XSS je založen na tom, že uživatel vloží do aplikace svůj vlastní script, kterým poté ovládá aplikaci. Veškeré uživatelské vstupy, jako je zadáni URL, metoda POST, cookie vstupy přes formulářové pole jsou tímto filtrem „čištěny“ Validování Data přijímaná z formulářů od uživatele jsou validována za pomocí validační knihovny frameworku. Ta dovoluje snadno nastavit, zda je pole povinné vyplnit a jaký datový formát obsahuje. Framework v případě nesplnění daných pravidel navrátí uživateli formulář k opravě. SQL injections Veškeré dotazy do databáze jsou frameworkem filtrovány oproti tomuto typu útoku, kdy uživatel provede speciální dotaz do databáze přes formulářové pole s cílem ji poškodit. Pro správnou funkci filtrování je využita doporučená syntaxe pro zadávání dotazů do databáze. Je použito: $this->db->select(’title, content, date’); $query = $this->db->get(’mytable’); Namísto: $query = $this->db->query(’SELECT title, content, date FROM mytable’);$ Ukradení sezení Zabezpečení oproti tomuto typu útoku je vysvětleno v sekci Sessions.

4.3.5

Správa úkolů

Základem aplikace je zadávání a správa úkolů. Při návrhu aplikace bylo dbáno na co nejjednodušší a intuitivní zadávání úkolů. Po přihlášení uživatele do aplikace je na jeho domovské stránce zobrazeno pole pro přidávání úkolů a seznam 10 posledně zadaných úkolů. Při všech krocích správy úkolu jsou kontrolovány oprávnění pro práci s daným úkolem. Tyto oprávnění jsou vedena v databázi v tabulce owners

36


Přidávání Přidání nového úkolu je navrženo a implementováno tak, jak nejjednodušeji to bylo možné. Uživatel napíše svůj úkol do pole a zmáčkne tlačítko přidat. Může nastavit, do jaké skupiny se má úkol přidat. Kontrolér ověří vstupní pole a předá data modelu společně s id uživatele, který úkol ukládá. Model data uloží do databáze. Ukládá přitom samotný úkol do jedné tabulky a poté referenci mezi uživatelem a úkolem do tabulky druhé. Do této tabulky se rovněž zapíše, v jaké skupině se úkol nachází. Rozdělení uživatele a úkolu slouží k pozdějšímu delegování úkolu.

Přesunutí do koše Každý úkol se může nacházet v několika stavech. Podle těchto stavů mohou být zobrazovány. Jedním z nich je přesun do koše. Tento stav znamená, že uživatel úkol nechce mít mezi svými úkoly, ale nechce úkol zatím vymazat ze systému úplně; například pro jeho další obnoveni. Po kliknutí u úkolu na tlačítko koš kontrolér aplikace změní parametr u daného úkolu modelu aplikace. Tento úkol poté není zobrazen mezi klasickými úkoly, ale v kategorii koš, kde jsou vypisovány úkoly s takto nastaveným parametrem. Každý úkol se dá opět z koše vrátit.

Smazání úkolu Po zvolení "smazat úkol"kontrolér převede příkaz vymazat do modelu, který smaže položku s úkolem v databázi i se všemi referencemi na ní. Tento krok je již nevratný.

Splnění úkolu Volba tlačítka "úkol splněn"nastaví u úkolu parametr na dokončený. To znamená, že již není vypisován mezi ostatními úkoly. Tato volba se dá přepínat. Tento úkol je ale stále veden v samostatné skupině splněných úkolů, která se dá zobrazit. Parametr úkolu lze opět přepnout zpět na nedokončený úkol. Je zde použit stejný přístup jako u přesunutí do koše.

4.3.6

Zobrazení úkolu

V aplikaci se vyskytují zobrazení dvou typů. Prvním je celkový přehled úkolů, který je možno filtrovat a zobrazovat jednotlivé skupiny. Tím druhým je detailní náhled jednoho úkolu. Celkový přehled První zobrazení, čili hromadné zobrazení úkolů. Vypisuje úkoly dle zvoleného pořadí. U každého úkolu vypíše začáteční část textu úkolu, a to prvních 100 znaků. Pokud má úkol zvolený název, nahradí text úkolu tímto názvem. Dále se u každého úkolu zobrazí celkový čas na něm strávený. Pokud uživatel s někým na úkolu spolupracuje, zobrazí se mu vedle času společného i čas pouze jeho. U každého úkolu jsou také ovládací tlačítka pro editaci úkolu, dokončení úkolu, přesunutí úkolu do koše nebo úplné smazání. Všechny tyto udaje jsou načtené z databáze.


37

Detailní náhled Druhé zobrazení je detailní zobrazení úkolu, kdy jsou zobrazeny všechny parametry a editační pole pouze pro daný úkol. Společně s informacemi o úkolu jsou zobrazena pole pro přidávání komentářů, delegování úkolů a zaznamenávání časů.

4.3.7

Filtrování a řazení

Při celkovém zobrazení úkolů si uživatel může volit, podle kterého parametru chce mít úkoly seřazeny. Nastavuje tím parametry řazení pro model, který pak řadí položky při výpisu z databáze. Stejně tak při filtrování položek jsou vybírány podmnožiny úkolů z modelu. Dají se například zobrazit úkoly, které překročily požadované datum splnění.

4.3.8

Skupiny

Pro přehlednost mohou být úkoly řazeny do jednotlivých skupin. Je na uživateli, jak si skupiny pojmenuje a kolik si jich založí. V metodice GTD popsané v analýze práce jsou názvy a významy skupin doporučeny, není nutné ovšem tohoto doporučení se držet. Jednotlivé skupiny mohou být přidávány a také mazány. Úkoly se mezi skupinami dají přesouvat. U každého úkolu je uvedeno číslo skupiny, do kterého patří. Změnou tohoto čísla v modelu aplikace se úkol přesune do jiné skupiny.

4.3.9

Vedení časů

U každého úkolu je veden přehled časů, který na něm strávili jeho řešitelé. Z pohledu uživatele jsou vedeny dva časy. Čas celkový, který je součtem všech, kteří na úkolu pracovali a čas konkrétního pracovníka. Po přidání času uživatelem se jeho čas přičte či odečte od obou časů zároveň. Počítání Výsledné hodnoty časů jsou zobrazeny ve formátu hh:mm:ss. Pro počítání s těmito údaji jsou časy převedeny funkcí na počty sekund, poté provedeny výpočty a převedeny zpět do uvedeného formátu. Převod času na sekundy $array = explode(’:’, $time); $sec = $array[0]*3600; $sec += $array[1]*60; $sec += $array[2]; Převod sekund na čas $hour = floor($sec/3600); $min = floor(($sec - $hour*3600)/60); $sec = $sec - $min*60 - $hour*3600; $time = $hour.’:’.$min.’:’.$sec;

38

4.3.10


Delegování úkolů

Úkoly mohou být delegovány. To znamená, že vlastník přidá další vlastníky úkolu. Ti automaticky dostanou plná práva, uživatel, který nastavuje delegování může tyto práva omezit. Z pohledu aplikace delegování znamená, že se přidá nový záznam do tabulky owners, který je relací mezi uživatelem a úkolem. Nemusí se tak nijak přenastavovat již vytvořený úkol.

4.4

Mobilní verze

Pro možnost přístupu k aplikaci přes mobilní rozhraní byla vytvořena odlehčená verze stránek, která se nachází na adrese .../task/mobile. Na tuto adresu je uživatel přesměrován, pokud se přihlásí k aplikaci přes mobilní telefon automaticky. Jak již bylo uvedeno v sekci přihlášení. Při přihlášení je totiž zjištěno, z jakého prohlížeče se uživatel hlásí. Pokud v zaslané hlavičce prohlížeče je některé z „hlídaných“ slov, jedna se o mobilní telefon, a uživatel je přesměrován. Nemusí si tudíž pamatovat další URL adresy, na přístup k aplikaci mu stačí jedna. Kód pro rozpoznání prohlížeče je založen na regulárním výrazu, který kontroluje, zda se v hlavičce prohlížeče nenachází některý z názvu výrobce mobilního telefonu. Když ano, jedná se o mobilní telefon. $regex_match="/(nokia|iphone|android|motorola|^mot\|softbank|foma|docomo|kddi|up\.browser|up\.link|"; $regex_match.="htc|dopod|blazer|netfront|helio|hosin| huawei|novarra|CoolPad|webos|techfaith|palmsource|"; $regex_match.="blackberry|alcatel|amoi|ktouch|nexian |samsung|^sam\-|s[cg]h|^lge|ericsson|philips |sagem|wellcom|bunjalloo|maui|"; $regex_match.="symbian|smartphone|midp|wap|phone |windows ce|iemobile|^spice|^bird|^zte\-|longcos |pantech|gionee|^sie\-|portalmmm|"; $regex_match.="jig\s browser|hiptop|^ucweb|^benq |haier|^lct|opera\s*mobi|opera\*mini|320x320|240x320|176x220"; $regex_match.=")/i"; return isset($_SERVER[’HTTP_X_WAP_PROFILE’]) or isset($_SERVER[’HTTP_PROFILE’]) or preg_match($regex_match, strtolower($_SERVER[’HTTP_USER_AGENT’]));$

Kapitola 5

Testování 5.1

Testování na zařízení

Výsledná aplikace byla testována na webových prohlížečích klasického PC a také přes webový prohlížeč na mobilním telefonu. Testování proběhl na následujících prohlížečích, aplikace i přes drobné změny ve vzhledu byla plně funkční

• Firefox 3.6,3

• Google Chrome 5

• Safari 4

• Microsoft Internet Explorer 8

• Mobile Safari 3.1.3 - Apple iPhone

• NetFornt - Sony Ericsson K770i

39

40

KAPITOLA 5. TESTOVÁNÍ

5.2

Kognitivní průchod

Testování aplikace bylo provedenou metodou testování bez dalších uživatelů, kdy sám programátor se stává testerem. Tato metoda má výhodu v rychlosti vyhodnocení, není časově ani finančně nákladná, nepotřebuje specializované prostředí. Její nevýhodou je menší objektivita. Základem metody kognitivního průchodu je stanovení si základních cílů, které chce tester při průchodu aplikací dosáhnout. V každém kroku, si musí zodpovědět a později vyhodnotit otázky, které si před začátkem stanovil. Obvykle to bývají tyto otázky. 1. Vím, kde jsem? 2. Je další akce k dispozici? Je akce dobře viditelná/zřetelná? 3. Je to to pravé? (Chápe to uživatel?) Je z názvu poznat co akce udělá? 4. Rozumí uživatel zpětné vazbě systému? Dostane uživatel srozumitelnou odezvu? 5. Co se stane, když uživatel udělá chybu? jak bude systém reagovat? Zvolené úkoly při testování 1. Přidat úkol do kategorie schránka a tento úkol delegovat uživateli jménem Petr. 2. Potvrdit úkol s nejstarším datem za splněný. 3. Zaznamenat dva časy k jednomu úkolu a poté jede smazat. 4. Přidat komentář ke sněnému úkolu. 5. Smazat všechny úkoly. Výsledkem tohoto testování bylo uspokojivé hodnocení, případné nedostatky byli odstraněny.

5.3

Testování v ostrém provozu

Aplikace v době psaní této práce nebyla spuštěna do „Ostrého“ provozu.

Kapitola 6

Závěr 6.1

Zhodnocení

Cílem projektu bylo vytvořit systém umožňující zadavateli snadné, rychlé a přehledné zaznamenávání a správu zadaných úkolů a požadavků. A to jak krátkodobých tak dlouhodobých. Systém měl uživateli zajistit rovněž přehledné sledování času, který na daném úkolu strávil jeho řešením. Zadané cíle práce byly splněný. Byla navržena a implementována správa úkolu i sledování času na úkolech strávených za pomocí PHP frameworku. Použité technologie jsou HTML, CSS, MySQL, PHP. Uživatelské rozhraní systému je snadno dostupné přes webový prohlížeč osobního počítače a také z mobilního telefonu s připojením k internetu. Systém umí pracovat se stávajícími daty (klienti, uživatelé, zakázky), které již firma používá. V průběhu analýzy a návrhu aplikace byla provedena rešerše existujících aplikací zabývající se danou tématikou. Byla provedena také analýza metodiky Getting things done zaměřené na správu úkolů. Bylo navrženo a provedeno testování aplikace s dobrými výsledky.

6.2

Diskuze možného pokračování

Další pokračování práce, by bylo vhodné v oblasti zlepšení uživatelského rozhraní aplikace. Například v implementaci AJAX prvků, a také javascript knihoven jakou jsou například jQuery, pro vytvoření příjemnějšího uživatelského rozhraní. Přínosná další funkcionalita, by bylo podpora sdílení souborů, zasílání upomínek prostřednictvím emailu, implementace kalendáře pro zobrazení úkolu.

41

42

KAPITOLA 6. ZÁVĚR

Literatura [1] Přehled nástrojů pro GTD http://www.priacta.com/Articles/Comparison_of_GTD_Software.php/ [2] Stránky frameworku http://codeigniter.com/ [3] Mobilní web http://www.mobilniweb.info/ [4] Mít vše hotovo http://www.mitvsehotovo.cz/ [5] W3C http://www.w3c.org/

43

44

KAPITOLA 6. ZÁVĚR

Příloha A

Seznam použitých zkratek PHP Hypertext Preprocessor MySQL My Structured Query Language xHTML eXtensible Hypertext Markup Language xHTML MP eXtensible Hypertext Markup Language Mobile Profie URL Uniform Resource Locator HTTP Hypertext Transfer Protocol CSS Cascading Style Sheets GTD Getting things done W3C World Wide Web Consortium

45

46

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Příloha B

Instalační a uživatelská příručka B.1

Instalační příručka

Pro správnou funkčnost aplikace je vyžadována webový server Apache, MySQL databáze podpora PHP. Postup instalace: 1. Na MySQL serveru spustě skript s název create.sql, který naleznete na přiloženém CD. Tímto skriptem vytvoříte databázovou strukturu 2. Pokud potřebujete aplikaci pouze pro zkušební účely, spustě na v MySQL skript insert.sql. Ten vytvořené tabulky naplní zkušebními daty. 3. Přesuňte celý obsah adresáře aplikace na webový server do kořenového adresáře. 4. Je nutné nastavit přístupové údaje k MySQL databází. Ty se nastavují ve souboru application/config/database.php. Zde pomocí jakého textového editoru nastavte vaše přístupové údaje. $db[’default’][’hostname’] $db[’default’][’username’] $db[’default’][’password’] $db[’default’][’database’] $db[’default’][’dbdriver’]

= = = = =

"localhost"; "root"; "root"; "taskmanager"; "mysql";

5. Pro správnou funkčnost aplikace je nutné nastavit domovskou adresu stránek v konfiguraci. Konfiguraci naleznete zde application/config/config.php. Změňte URL adresu na tu kam jste umístili aplikaci $config[’base_url’] = "http://localhost/taskmanager/"; 6. Nyní jste dokončili instalaci aplikace, přihlásit se můžete na adrese, kde jste nahráli instalační soubory, pod uživatelským jménem a heslem jméno: test heslo: test

47

48

PŘÍLOHA B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

B.2

Uživatelská příručka

Pro vstup do aplikace zadejte URL adresu, kde máte aplikaci nainstalovanou. Objeví se vám přihlašovací formulář a do něj napište následující údaje a zmáčkněte tlačítko přihlásit. jméno: test heslo: test Poté se vám zobrazí následující obrazovka, kde můžete: • Přidávat nové úkoly • Prohlížet již zadané úkoly - kliknutím na text úkolu • Přidávat nové kategorie - v levém panelu se nachází editační pole • Mazat kategorie - x vedle názvu kategorie • Zobrazit kategorie - kliknutím na název kategorie • Zobrazit obsah koše - kliknutím na koš • Zobrazit pouze splněné úkoly - kliknutím na splněné úkoly • Smazat úkoly • Přesunout do koše • Dokončit Chcete li upravovat některý z úkolů klikněte na jeho text. Otevře se vám editační obrazovka, • Editovat časy • Delegovat úkol • Přidat komentář

Příloha C

Obsah přiloženého CD Adresáře označené * nemají uvedené vnořené soubory ani složky z důvodu velkého rozsahu

Obrázek C.1: Seznam přiloženého CD

49

Systém pro správu požadavků a úkolů. Radek Tobolka

Recommend Documents