VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Aplikovaná informatika
Plánovací manažer bakalářská práce
Autor: Michal Šebesta Vedoucí práce: Ing. Marek Musil Jihlava 2014
Abstrakt Bakalářská práce se zabývá návrhem a realizací aplikace pro plánování úkolů na platformě Microsoft .NET Framework. Řeší převážně intuitivní grafické zobrazení zadaných úloh pomocí barevných přechodů, které se v ostatních dostupných plánovačích nevyskytuje. Tato skutečnost umožňuje uživatelům rychlou orientaci na časové ose a rychlé rozhodnutí, který úkol by se měl již začít řešit. Výsledkem této práce je funkční aplikace umožňující vytváření, správu a delegování úloh jiným osobám.
Klíčová slova C#, plánovač, úkol, WPF
Abstract The bachelor thesis deals with the design and implementation of application for scheduling tasks on Microsoft .NET platform. It solves mainly graphical view of inserted tasks by color gradients that is not in any other available applications. This fact allows users fast orientation on the timeline and quick decision what task must be started. The result of this thesis is application allows creating, managing and delegation tasks to other people.
Key words C#, Sheduler, task, WPF
Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu 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ů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne 15. 5. 2014
............................................... Podpis
Poděkování Na tomto místě bych rád poděkoval panu Ing. Bc. Michalu Vopálenskému, Ph.D. za poskytnutí tématu a svému vedoucímu práce Ing. Marku Musilovi za možnost vytvářet ho pod jeho vedením.
Obsah 1
Úvod.......................................................................................................................... 8
2
Současný stav ............................................................................................................ 9
3
Požadavky na nový software .................................................................................. 11
4
Popis pojmů v řešení ............................................................................................... 14
5
6
4.1
Objektově orientované programování .............................................................. 14
4.2
Návrhové vzory ................................................................................................ 14
4.2.1
Návrhový vzor Singleton .......................................................................... 15
4.2.2
Návrhový vzor Servant ............................................................................. 16
4.3
Dotazovací jazyk SQL ..................................................................................... 17
4.4
Jazyk C# ........................................................................................................... 17
4.5
Windows Presentation Foundation .................................................................. 18
4.6
Vícevláknové aplikace ..................................................................................... 20
Návrh řešení ............................................................................................................ 22 5.1
Platforma a prostředí ........................................................................................ 22
5.2
Uživatelské rozhraní......................................................................................... 22
5.3
Databáze ........................................................................................................... 24
Realizace ................................................................................................................. 27 6.1
Databáze ........................................................................................................... 27
6.2
Uživatelské rozhraní......................................................................................... 29
6.3
Barevný přechod a časová osa ......................................................................... 30
6.3.1
Barevný přechod ....................................................................................... 30
6.3.2
Časová osa ................................................................................................ 32
6.4
Úloha ................................................................................................................ 34
6.5
Funkcionalita aplikace ..................................................................................... 35
6.5.1
Přidání nové úlohy .................................................................................... 35
6.5.2
Seznam úkolů ............................................................................................ 36
6.5.3
Seznam nesplněných úloh ......................................................................... 37
6.6 7
Aktualizace ....................................................................................................... 38
Závěr ....................................................................................................................... 41
Seznam použité literatury ............................................................................................... 42 Seznam obrázků .............................................................................................................. 43 Seznam použitých zkratek .............................................................................................. 45 Přílohy............................................................................................................................. 46 1
Obsah přiloženého CD ............................................................................................ 46
2
Časová osa .............................................................................................................. 47
3
Manuál .................................................................................................................... 48 3.1
Vytvoření úlohy ............................................................................................... 48
3.2
Přehled úloh ..................................................................................................... 49
3.3
Editování úloh .................................................................................................. 50
1 Úvod V dnešní velmi rychlé době, která nám přináší spoustu luxusu v elektronických komunikacích, kdy na spojení se s ostatními lidmi na druhém konci světa stačí pouhých pár sekund, a kde nejsme prakticky limitováni možnostmi a zdroji informací, se neustále zvyšují požadavky na produktivitu práce. To znamená, že lidé by měli stejné produkce dosahovat v kratším čase, nebo ve stejném čase dosáhnout produkce vyšší. K tomu je samozřejmě zapotřebí jak technický pokrok, tak i efektivní naplánování činností, které se mají provést, aby bylo s časem efektivně a ekonomicky naloženo. Jelikož čas není žádná pružná veličina, která by mohla být rozšířena či přikoupena, je pro každého člověka, ať úspěšného nebo průměrného, stejná. Záleží pouze na kvalitní přípravě a rozplánování svého volného času. Touto problematikou se zabývá, tzv. time management1. Vrcholoví manažeři by si dnes nedokázali představit svůj život bez softwaru, který je každodenně informuje o jejich schůzkách a povinnostech. Daný software jim nejen šetří čas, který mohou později využít například trávením s rodinou, ale také finanční prostředky. Uplatnění dané aplikace lze samozřejmě nalézt i pro další uživatele, nejenom pro manažery, ale je otázkou, zda budou ochotni investovat do jejího pořízení. Tento podpůrný software se obecně označuje jako plánovací manažer. Mezi základní funkčnost plánovacích manažerů patří vytváření a správa úloh a následné upozornění před termínem jejich splnění. Implementace podobného manažeru je tématem této bakalářské práce, jelikož bych rád k této problematice přistoupil jiným způsobem, než jakým jsou tvořeny současné plánovače. Mým cílem je vytvořit uživatelsky přívětivou a hlavně jednoduchou aplikaci, která by svým uživatelům primárně umožňovala vysoce intuitivní zobrazení naplánovaných úloh a dále jim poskytovala snadnou editaci a možnost delegování úkolů jiným osobám.
1
Obor obsahující množinu doporučení a postupů pro plánování času.
8
2 Současný stav Na trhu se v současnosti nachází spousta volně dostupných, ale i komerčních softwarů umožňujících plánování úloh. Mezi často používané aplikace patří: -
Google Calendar,
-
Mozilla Thunderbird,
-
Microsoft Outlook.
Tyto aplikace jsou ve zbývající části kapitoly popsány. Mezi volně dostupné a hojně využívané plánovače patří například online kalendář Google Calendar společnosti Google (www.google.com/calendar), který kromě samotného vytváření plánu úloh umožňuje i synchronizaci s mobilními telefony obsahující operační systém Android, iOS nebo Windows Phone. Výhodou tohoto online kalendáře je aktuálnost a mobilita dat kdekoliv po celém světě a možnost nastavení sdílení s ostatními uživateli kalendáře. Sdílení kalendáře se může efektivně uplatnit například i při práci v týmových projektech, kde každý uživatel daného sdíleného kalendáře může vytvářet a spravovat projekty. Další velice atraktivní funkcionalitou je integrace se službou Gmail. Jedná se o bezplatnou emailovou službu, kterou poskytuje společnost Google. Tato služba umožňuje nejen svým uživatelům posílání a přijímání emailů, ale také rozpozná událost zmíněnou v emailu. Pokud uživatel tuto událost přijme, bude mu automaticky přidána do jeho kalendáře. S tímto kalendářem mám velmi dobré zkušenosti, jelikož splňuje veškeré mé požadavky jak pro osobní, tak i pracovní účely. Nejvíce se mi na něm zamlouvá okamžité synchronizování se všemi mými zařízeními a způsob upozornění na danou událost. Další volně dostupný emailový klient je Thunderbird, který je vyvíjen firmou Mozilla. Defaultně v sobě nemá zabudovaný žádný kalendář, ale umožňuje si jej stáhnout jako doplněk. Bohužel ale postrádá veškeré možnosti synchronizace s ostatními zařízeními a celkově neposkytuje žádné převratné funkční možnosti. Do kategorie komerčních plánovačů se řadí známý emailový klient Microsoft Outlook. Kromě správy emailových účtů, umožňuje vytvářet a plánovat úlohy s možností zasílání 9
těchto úloh ostatním lidem. Pomocí tohoto softwaru lze i domluvit schůzky například v rámci týmu a jejich následné zobrazení v kalendářích všech zúčastněných osob. Hlavní nevýhoda spočívá v nemožnosti oddělení plánovače úloh od samotného emailového klienta, z čehož vyplývá i následně vysoká cena, kterou většina běžných uživatelů není ochotna vynaložit. Proto se Microsoft Outlook používá převážně v podnicích a státních institucí. Plánovače Microsoft Outlook a Google Calendar mají své velké přednosti, díky kterým jsou masivně využívány. Všechny uvedené postrádají nástroj, který by úlohy vyhodnotil a srozumitelnou formou poskytl uživateli informaci, které z úkolů je nutné začít plnit. Například prostřednictvím barevného vizuálního přehledu všech úloh, podle kterého by bylo zřetelné, kdy je nutné na dané úloze začít pracovat. Tyto aplikace dále neumožňují seřadit úlohy podle naléhavosti a termínu jejich splnění. Tyto „drobnosti“ mohou při větším počtu zadaných úloh vést k vynaložení dalšího času a úsilí uživatele pro zorientování a naplánování dalšího kroku.
Obrázek 1 Ukázka úkolů v MS Outlook
Na obrázku 1 vidíme abecední seznam úkolů v aplikaci MS Outlook, který lze řadit a filtrovat podle různých kritérií. Z tohoto zobrazení není na první pohled patrné, který úkol je potřeba začít řešit nebo dokončit nejdříve.
10
3 Požadavky na nový software Na základě veškerých nedostatků, zmíněných v předchozí kapitole jsem se rozhodl vytvořit svůj vlastní plánovací manažer, který vyřeší jednak tyto nedostatky, ale hlavně bude i uživatelsky přívětivý. Bude využívat některé již osvědčené funkcionality konkurenčních produktů, které jsou běžně k dispozici. V aplikaci bude řešeno následující: -
vytvářet nové úkoly a editovat úlohy stávající,
-
pomocí barevného přechodu vizualizovat aktuálnost splnit zadaný úkol,
-
zobrazit úkoly bez vizualizace barevného přechodu,
-
uchovávat a zobrazovat úlohy, které nebyly splněny,
-
možnost předat úlohy k vyřešení jiné osobě,
-
uchovávat historii úkolů.
Jedním z nejdůležitějších požadavků je odlišení naplánovaných úloh barevnými přechody, které budou závislé na potřebném a zbývajícím čase. Barevný přechod bude realizován proměnlivě od zelené barvy po barvu červenou. Zelená barva bude značit skutečnost, že na daný úkol máme ještě dostatek času a můžeme se soustředit na důležitělší úlohy. Úkol, který nabývá žluté barvy, si již vyžaduje lehké povšimnutí. U oranžové nebo dokonce červené úlohy je již nezbytný si rozmyslet, kdy na úloze začít pracovat.
Obrázek 2 Návrh barevného přechodu 1
Úloha, jejíž časové náklady jsou několikanásobně menší než čas zbývající do konce termínu jejího splnění je vybarvena zeleně a s postupem času se postupně přeměňuje přes žlutou a oranžovou barvu na barvu červenou. Někdy úloha již při vytvoření vyžaduje zvýšenou pozornost, a proto nezačíná její barevný přechod zelenou barvou, jak je patrné z obrázku 3.
Obrázek 3 Návrh barevného přechodu 2
11
Úloha, která bude po termínu splnění nebo naplánovaná doba ke splnění již není dostatečná, zčerná a bude k dispozici v agendě nesplněných úkolů, kde jí bude možno později dokončit.
Obrázek 4 Návrh nesplněného úkolu
Úlohy by měly být zobrazeny od aktuálního data bez ohledu na to, kdy mají svůj termín splnění. To nám umožní mít neustále na očích veškeré úlohy, které jsou pořád platné. Tento přístup je odlišný než používají některé jiné plánovače, kde je úloha zobrazena až ve chvíli, kdy má dojít k jejímu splnění. Následkem tohoto přístupu může být i opomenutí dané úlohy, popřípadě všimnutí si jí, až na poslední chvíli.
Obrázek 5 Barevné přechody
Největší výhoda barevného přechodu spočívá v tom, že uživateli na první pohled ukáže, který z úkolů si vyžaduje větší pozornost a tedy i to, jaké bude pořadí v jejich postupném vypracování. Tuto situaci zachycuje obrázek 5, na kterém vidíme tři úlohy. První z nich končí za necelých 5 hodin, druhá za 10 hodin a třetí dokonce až za 11 hodin. Podle zbývajících časů do konce termínů jednotlivých úloh by se mohlo zdát, že pořadí jejich zpracování přesně odpovídá pořadí, ve kterém jsou zobrazeny na časové ose. První by se tedy vypracoval úkol ÚLOHA01, poté ÚLOHA02 a nakonec ÚLOHA03. Skutečnost je ovšem taková, že úloha ÚLOHA03, která končí ze všech třech úloh nejpozději a zároveň vyžaduje větší časovou náročnost na její splnění, si zasluhuje největší pozornost než ostatní úlohy a proto je nutné začít s jejím řešením jako první. To je patrné z barevného přechodu, který začíná oranžovou barvou. Tato barva obsahuje oproti ostatním barvám největší koncentraci červené. Dále je nutné vypracovat úkoly ÚLOHA01 a ÚLOHA02. Toto pořadí vyplynulo z velkého množství zelené barvy, která je obsažena v úkolu ÚLOHA02. To dané úloze zajišťuje relativně dost času k jejímu dokončení, a proto bude vypracována jako poslední. 12
Další funkcionalita, která by se v aplikaci měla nacházet, je možnost předat úlohu někomu jinému k jejímu splnění. Skutečnost delegování úkolu na jinou osobu by měla být na první pohled patrná. To znamená, že každá delegovaná úloha by se měla od těch klasických v něčem lišit. Já jsem zvolil bílé orámování obvodu vizuálního prvku úlohy.
Obrázek 6 Návrh delegovaného úkolu
13
4 Popis pojmů v řešení Tato kapitola si klade za cíl popis nástrojů a vysvětlení pojmů, se kterými se setkáme při samotné realizaci aplikace.
4.1 Objektově orientované programování Při používání objektově orientovaného programování vycházíme z poznání, že každý program je simulací reálného světa. V běžném životě se setkáváme s různými typy objektů. Mezi tyto objekty považujeme osoby, zvířata a věci. Objektově orientované programování toto chápání zobecňuje, takže se může obecně říci, že za objekt lze považovat vše, co můžeme nazvat podstatným jménem. Jelikož se v programech objevuje nespočetné množství těchto objektů, je nutné, abychom je nějakým způsobem roztřídili. Pro třídění do skupin s velice podobnými vlastnostmi se používají třídy, které nám následně umožní se všemi objekty rozumně pracovat. Komunikace mezi objekty je zajištěna pomocí takzvaných zpráv. (Pecinovský, 2010)
4.2 Návrhové vzory Jedná se o doporučené postupy při řešení často se objevujících úloh. Pro přirovnání můžeme říci, že se jedná o jakési vzorečky, se kterými se setkáváme v matematice či fyzice, s tím rozdílem, že do nich nedosazujeme čísla, ale třídy a objekty. Můžeme je tedy
považovat
za
vzorečky,
které
se
používají
při
návrhu
architektury
budoucí aplikace. Pokud dobře známe návrhové vzory, nejenže budeme mít řešení dříve hotové než ti, kteří jej teprve musí objevit, ale také snížíme pravděpodobnost chyb, které vznikají při vymýšlení nových řešení. Jejich znalost nám zjednoduší komunikaci v týmu, protože je mnohem snazší se odvolat na matematiku, nežli slovně popisovat danou problematiku. Dále použití návrhových vzorů počítá s nutností rozšiřitelnosti, takže budoucí úpravy nám zaberou mnohem méně práce a energie a navíc budou i spolehlivější. 14
Při studiu a osvojování návrhových vzorů si uvědomíme klíčové zásady objektově orientovaného programování. (Pecinovský, 2013)
4.2.1 Návrhový vzor Singleton Singleton, neboli v překladu jedináček, je návrhový vzor specifikující, jak vytvořit třídu, která bude mít nejvýše jednu instanci a poskytující k ní globální přístupový bod.
Obrázek 7 Singleton
Princip Singletonu lze implementovat čistě jako statickou třídu. Použití tohoto návrhového vzoru je oproti statické třídě2 výhodnější, protože užitím objektu získáváme mnoho dalších možností, například ve formě implementace rozhraní a předávání odkazu na objekt parametrem. Hlavní výhoda je ale ukryta v možnosti určení pořadí inicializace objektů, která u statických tříd probíhá v režii modulu CLR (Common Language Runtime).
2
Nemůže být instantiována (nelze vytvořit objekt).
15
V implementaci jedináčka se konstruktor definuje jako soukromý, čímž se zamezí komukoliv cizímu ve vytvoření další instance. Požadovaná instance se tedy vytváří uvnitř třídy a odkaz na ni se uloží do statického atributu. Tento odkaz se poté předává těm, kteří jej vyžadují. Jelikož je definován soukromý konstruktor, je tedy i vhodné označit danou třídu jako finální, tedy za takovou, která nemůže mít již žádné potomky. (Pecinovský, 2013)
4.2.2 Návrhový vzor Servant Návrhový vzor Servant, neboli česky služebník se používá v situacích, kdy chceme skupině tříd nabídnout nějakou další funkčnost, aniž bychom do nich implementovali reakci na příslušnou zprávu. Jedná se tedy o třídu poskytující metody, které si přebírají potřebnou činnost na sebe a objekty,
pro
které
danou
činnost
vykonávají,
přebírají
jako
parametry.
(Pecinovský, 2013)
Obrázek 8 Servant
16
Na obrázku 8 vidíme situaci, kdy uživatel předává služebníkovy obsluhované objekty a požaduje po něm, aby je obsloužil.
4.3 Dotazovací jazyk SQL Dotazovací jazyk SQL zabezpečuje komunikaci mezi klientskými aplikacemi a databázovým serverem. Příkazy SQL se dělí do základních dvou podmnožin: -
Data Definition Language (DDL) – příkazy z této množiny nám umožňují definovat strukturu databáze (CREATE DATABASE, CREATE TABLE, ..).
-
Data Manipulation Language (DML) – slouží pro manipulaci s údaji (SELECT, INSERT, UPDATE, DELETE).
(Lacko, 2005)
4.4 Jazyk C# Microsoft Visual C# je jednoduchý a přitom výkonný programovací jazyk zaměřený především na vývojáře aplikací na platformě .NET Framework. Jedná se o jakousi odvozeninu nejlepších vlastností jazyků C++, Java a Visual Basic. První verze se objevila v roce 2001. Pomocí knihovny Task Parallel Library (TPL) umožňuje vyvíjet vysoce škálovatelné aplikace, které dokáží využít plný potenciál vícejádrových procesorů. (Sharp, 2010) Jazyk je založený na moderní metodice objektově orientovaného návrhu a aplikace v něm napsané běží v běhovém prostředí, které se nazývá CLR3. Před samotným spuštěním je kód přeložen do tzv. jazyka IL4. Tyto skutečnosti zajišťují nezávislost dané aplikace na platformě. (Nagel, a další, 2009)
3
Common Language Runtime – překládáno jako „běhový systém“.
4
Intermediate Language - jazyk, do kterého je kód před spuštěním přeložen.
17
Obrázek 9 CLR
Dále jazyk C# vyniká silnou typovou kontrolou dat. Z toho vyplývá, že každá proměnná je jasně označena konkrétním datovým typem, ke kterému patří. Jazyk IL neumožňuje operace, které by nabývaly výsledků neurčitých datových typů. (Nagel, a další, 2009)
4.5 Windows Presentation Foundation Windows Presentation Foundation (WPF) je grafický subsystém pro psaní programů běžícívh v systému Windows. Poskytuje nový vzhled, nové principy přizpůsobení ovládacích prvků, nové grafické funkce
(včetně animace a 3D) a nové
programovací rozhraní. V praxi obsahuje dvě související programovací rozhraní. Programy WPF lze psát celé kompletně v jazyku C# nebo pomocí nového značkovacího jazyka založeného na XML, který se nazývá Extensible Application Markup Language (XAML). Přestože lze v některých případech v jazyku XAML vytvořit celé programy, je obvyklejší skládání aplikace z kódu i značek. Pomocí jazyka XAML se definuje uživatelské rozhraní a grafické prvky aplikací a v procedurálním jazyku se vytváří kód k obsluze událostí uživatelského vstupu. Dochází tedy k oddělení vzhledu aplikace a její funkčnosti.
18
Tento subsystém již nevyužívá k nastavení rozměrů a umístění pixely, ale takzvané jednotky nezávislé na zařízení. Každá tato jednotka odpovídá hodnotě 1/96 palce (0,26 mm). Systém Windows určuje přepočet mezi pixely a palci a dává uživateli možnost jej změnit. Ve výchozím nastavení je použito rozlišení 96 dpi5, které přesně odpovídá pixelům. Využití nezávislých jednotek na zobrazení bude mít přívětivý vliv v budoucnosti, kdy se objeví nové monitory s mnohem větším rozlišením. Pokud by zůstala hodnota 96 dpi, byly by objekty na obrazovce příliš drobné. Tento problém se odstraní zvýšením hodnoty dpi, což povede ke stejným rozměrům. Další vlastností tohoto rozhraní je i koncepce obsahu okna, kdy je možné do obsahu okna přiřadit pouze jeden objekt. To by znamenalo, že v aplikaci bude zobrazeno třeba pouze tlačítko pro kliknutí, nebo pouhý popisek. Tato skutečnost by znamenala velmi mnoho omezení, které by nemohlo vést k příliš efektivní práci. Proto se v praxi přiřazuje obsahu okna objekt, který umožňuje ukládat více jiných objektů. Rozhraní WPF se vyplatí používat v případech, kdy potřebujeme značně upravovat grafický vzhled svých aplikací. (Petzold, 2008) Díky WPF může vývojář společně s návrhářem pracovat na stejném kódu XAML. Návrhář může využít nástroj Expression Blend, zatímco vývojář pracuje ve vývojovém prostředí Visual Studio. Oba tedy mohou začít pracovat na vývoji aplikace současně. Návrhář vytváří a vylepšuje uživatelské rozhraní a vývojář pracuje na funkcích produktu. (Nagel, a další, 2009)
5
Bodů na palec (dots per inch).
19
Obrázek 10 Ukázka kódu XAML
Obrázek 10 demonstruje ukázku práce s kódem XAML v systému WPF při vytváření tlačítka. Vytvořili jsme objekt typu Button o rozměrech 100 x 50 obrazových bodů. Toto tlačítko je v Gridu standardně zarovnáno na střed okna. Z obrázku je na první pohled patrné, že jazyk XAML je velice podobný jazyku XML.
4.6 Vícevláknové aplikace Většina obyčejných jednoduchých aplikací běží jako jednovláknové, což znamená, že v jakémkoliv daném okamžiku program vykonává pouze jednu instrukci. Tento způsob není zrovna efektivní, pokud program provádí časově náročnou operaci a uživatel jej chce obsluhovat. Poté se tato aplikace jeví jako zamrzlá a začne opět reagovat až po ukončení prováděné operace.
20
Vícevláknové aplikace na rozdíl od jednovláknových umožňují provádět více instrukcí současně a využívají mnohem lépe dostupné prostředky daného počítače. Výsledkem je rychlejší běh takovéto aplikace a lepší rezponzivnost. (Sharp, 2010)
Obrázek 11 Vícevláknové aplikace
Výše uvedený obrázek demonstruje rozdíl mezi počtem vykonávaných instrukcí v daný časový okamžik. Vlevo vidíme, že se vždy provádí pouze jedna instrukce, zatímco na pravé straně obrázku ve stejném okamžiku běží současně dva procesy.
21
5 Návrh řešení Tato kapitola má za úkol rozbor návrhu a funkcionalit vytvářené aplikace.
5.1 Platforma a prostředí Pro realizaci desktopové aplikace plánovacího manažeru jsem si zvolil prostředí .NET a objektový programovací jazyk Microsoft Visual C#. Jazyk C# jsem si vybral proto, že je stále populárnější mezi programátory a stává se trendem při vývoji aplikací. Dalším důvodem je jeho moderní přístup k programování. Mezi tyto přístupy patří například automatická správa paměti, ošetření chyb pomocí zachytávání vyjímek a silná typová kontrola dat. Samotná
implementace
aplikace
bude
uskutečněna
ve
vývojovém
prostředí
Microsoft Visual Studio 2012, které umožňuje pomocí kolekcí nástrojů a služeb vývoj aplikací v .NET, které jsou spustitelné na zařízeních s operačními systémy Windows.
5.2 Uživatelské rozhraní Grafické uživatelské rozhraní aplikace je vytvářeno pomocí nové technologie Windows Presentation Foundation (WPF). Oproti standardním formulářovým aplikacím WinForm poskytuje WPF nové grafické funkce a nástroje, které s touto technologií spolupracují. Důležitým nástrojem této technologie je Microsoft Blend. Jedná se o nejnovější interaktivní designový nástroj společnosti Microsoft, který umožňuje grafikům a vývojářům tvorbu graficky bohatých aplikací. Návrh uživatelského rozhraní jsem vytvořil s ohledem na jednoduchost a přehlednost, jak je patrné z obrázku 12, který zobrazuje úvodní obrazovku aplikace. Přepínání se mezi jednotlivými programovými funkcionalitami je řešeno pomocí záložek. Aplikace bude zobrazena v celoobrazovkovém režimu. O počtu aktuálních úkolů informuje stavový řádek, jehož dalším úkolem je i výpis právě prováděných akcí.
22
Obrázek 12 Uživatelské rozhraní – Vytvoření
Jednotlivé úkoly se budou do aplikace zadávat na kartě Vytvoření. Jakmile budou zadána veškerá potřebná data, klikne se na tlačítko Vytvořit. Dojde k přidání úlohy nejen do databáze, ale i na časovou osu v agendě Přehled a do seznamu úloh na kartě Úlohy.
Obrázek 13 Uživatelské rozhraní - Přehled
Grafický přehled úloh si můžeme prohlédnout na kartě Přehled. Kromě jednotlivých úloh zde nalezneme i tlačítka pro přepnutí zobrazovacího režimu a šipky, pomocí 23
kterých se můžeme v datu pohybovat dopředu a zpět. Tímto způsobem přepínání zobrazovacích režimů jsem se inspiroval z aplikace Outlook.
Obrázek 14 Uživatelské rozhraní - Úlohy
Samotný textový výpis úkolů nalezneme na záložce Úlohy. Spolu se seznamem se zde nacházejí dvě tlačítka sloužící k úpravě a odstranění vybrané úlohy.
5.3 Databáze Klíčovým předpokladem aplikace je její určení pro běžné uživatele a přenositelnost. Z tohoto důvodu budou data uložena v databázi typu Microsoft Access, která nevyžaduje explicitní instalaci databázového systému. Tento databázový soubor bude umístěn v místě instalace programu. Aplikace tak může být umístěna na USB disku nebo jiném datovém nosiči a spustitelná na jakémkoliv počítači s operačním systémem Microsoft Windows. Pokud by byla použita databáze MS SQL, byla by nutná instalace databázového serveru SQL a aplikace by nebyla snadno přenositelná mezi jednotlivými počítači. V databázi se budou nacházet dvě tabulky: ukoly a osoby. Tabulka ukoly uchovává veškerá potřebná data všech zadaných úkolů včetně odkazu na osobu, která je pověřena daným úkolem. Seznam všech osob je uložen ve druhé tabulce s názvem osoby.
24
Následující obrázky představují E-R diagramy jednotlivých tabulek.
Obrázek 15 E-R model tabulky „ukoly“
Vysvětlení jednotlivých atributů: -
ID – jednoznačný číselný identifikátor záznamu, který automaticky přiřadí databázový systém;
-
Nazev – slouží ke zřejmé identifikaci úlohy;
-
Osoba – uchovává jednoznačný číselný identifikátor osoby, která je úkolem pověřena;
-
Historie – nabývá logických hodnot „ANO“ / „NE“ a jeho posláním je zajištění historie všech doposud přidaných, splněných, či smazaných úloh;
-
Hodinova_narocnost – udává předpokládaný počet hodin, které si úloha pravděpodobně vyžádá;
-
Stav – jedná se o celočíselný datový typ, který vyjadřuje procentuální dokončení úloh;
-
Nesplneno – označuje úlohy, které již nemohou být splněny;
-
Termin_splneni – obsahuje datum i čas udávající konec termínu pro splnění dané úlohy.
25
Obrázek 16 E-R model tabulky "osoby"
Součástí zadání je i evidence úkolů, které nebyly z jakéhokoliv důvodu splněny. Pro realizaci této funkcionality se do tabulky ukoly přidá příznak, který indikuje, zda úkol nebyl splněn. Díky tomuto příznaku se při vyhledání nesplněných úkolů použije jednoduchý SQL dotaz, který vybere jen ty záznamy, které odpovídají příznaku.
26
6 Realizace 6.1 Databáze Třída realizující styk s bází dat je navržena pomocí návrhového vzoru Singleton. Tato implementace je vhodná, jelikož je pro potřebu práce s danou třídou zapotřebí pouze jedna instance, ke které nám umožňuje přístup odkudkoliv v programu.
Jelikož primárním klíčem je atribut ID, který je typu Automatické číslo, realizuje třída také i dotaz, který zjistí přidělené ID databází nově vytvořenému úkolu a následně jej přiřadí i instanci tohoto úkolu. Tento dotaz seřadí úkoly podle ID sestupně a následně vybere první záznam. Tím je zaručeno, že vždy bude vybrána úloha, která byla zadána naposledy.
27
V tabulce
ukoly
jsou
dva
atributy
nabývající
logických
hodnot
true/false.
Atribut Nesplneno se nastaví do logické jedničky v případě, kdy aplikace vyhodnotí, že se daná úloha již nedá splnit v požadovaném termínu. Po nastavení tohoto příznaku se již úkol nadále nenačítá do seznamu aktuálních úloh ani není zobrazen na časové ose, ale přemístí se do sekce Nesplněné úkoly. Druhý atribut s názvem Historie se využívá při splnění, nebo mazání úkolů, aby nedocházelo k fyzickému odstranění záznamu z databáze. Úloha, která má nastaven tento příznak, se již nezobrazí v aplikaci, ani se s ní už nepracuje. Dále pomocí tohoto příznaku bude možné zobrazovat historii všech dosud kdy vytvořených, splněných a smazaných úloh. Následující obrázek vyjadřuje spojení mezi dvěma použitými tabulkami.
28
Obrázek 17 ERA model
6.2 Uživatelské rozhraní
Obrázek 18 Realizace uživatelského rozhraní
29
Při realizaci uživatelského rozhraní jsem vycházel již z výše uvedeného návrhu, který byl převeden do červeno – šedé kombinace barev. Během implementace programu došlo po konzultaci se zadavatelem k rozšíření o novou agendu, která má na startosti správu nesplněných úloh. Pokud se v této agendě bude nacházet nějaký nesplněný úkol, záložka změní barvu svého pozadí na červenou. Pozadí se vrátí do původního stavu až, když budou veškeré úlohy v této agendě odstraněny nebo vyhodnoceny jako „stihnutelné“.
6.3 Barevný přechod a časová osa 6.3.1 Barevný přechod Další a řekl bych jedna z nejdůležitějších funkčností celé aplikace je generování barevného přechodu jednotlivým úlohám. K tomuto účelu jsem vytvořil statickou třídu BarevnyPrechod. Třída je navržena na základě návrhového vzoru Servant. Následující obrázek ilustruje strukturu této třídy.
Barevný přechod je vypočítán poměrem zbývajícího času do splnění dané úlohy a časovou náročností, která byla uživatelem odhadnuta a zadána jako čas potřebný k úspěšnému dokončení úkolu. Výpočet poměrového čísla a nastavení počáteční barvy 30
přechodu má na starosti metoda pojmenovaná VypocetPrechodu, která přebírá tři parametry a nakonec vrací již nastavený barevný přechod. Pomocí předaných parametrů, počítá poměrová čísla pro dvě barevné složky. První složka je definovaná pro začátek úkolu a druhá pro jeho konec. Zbývající barevné složky mezi těmito dvěma hraničními, jsou vypočítány lineárním způsobem, který implementuje
použitý nástroj
LinearBrush
realizující
vykreslení
tohoto
barevného přechodu. Prvním z parametrů je úloha, pro kterou se má barevný přechod vypočítat. Druhý parametr obsahuje datum, který udává, pro jaký termín se má přechod vypočítat. Poslední z parametrů slouží k určení jaký datum a čas zakončuje aktuálně zobrazenou časovou osu. To je důležité z toho důvodu, abychom mohli určit, zda úloha pokračuje na nadcházejícím časovém úseku či nikoliv. Pokud by úloha dále již nepokračovala, byla by koncová barva jejího přechodu červená. V opačném případě by bylo nutné vypočítat i barvu pro konec barevného přechodu. Samotný výpočet je realizován pomocí poměrového čísla daného vztahem: 𝑝𝑜𝑚ě𝑟 =
𝑠𝑡𝑟á𝑣𝑒𝑛ý č𝑎𝑠 𝑧𝑏ý𝑣𝑎𝑗í𝑐í č𝑎𝑠
Čitatel je určen rozdílem potřebného času, který byl stanoven při vytváření úlohy a již stráveného času věnovaným k řešení daného úkolu. Jmenovatel pouze udává počet hodin do konce splnění termínu.
31
Takto vypočtený poměr se předá metodě, jejímž úkolem je na základě zvolených intervalů přiřazení patřičné barevné složky. Obecně tedy platí, že čím nižší vyjde poměrové číslo, tím světlejší barva bude metodou vrácena. Aby barevné přechody jednotlivých úkolů nezůstávaly pořád stejně barevné, je nutné pomocí nového vlákna6 zajistit aktualizaci aktuálního času a přepočet všech úloh.
6.3.2 Časová osa Aby byly úlohy nějakým přehledným způsobem umístěny na klientské části okna, vytvořil jsem novou třídu poděděnou ze třídy „Grid“, která nám umožňuje vkládané úlohy umisťovat do řádků a sloupců. Plní tedy funkci takzvané časové osy. Nejenže časová osa tyto úkoly vykresluje, ale dokonce se stará i o jejich aktualizaci v čase. V každém předefinovaném časovém intervalu dochází k této aktualizaci, která má na starosti nejen změnu barevného přechodu, ale také i samotnou velikost (šířku) úloh. Velikost je závislá pouze na zbývajícím čase ke splnění dané úlohy, zatímco
6
Jednotka paralelizace.
32
barevný přechod úlohy je dán rozdílem zbývajícího času a času, který již byl na úkol vynaložen. Čím více se krátí čas do konce termínu, zmenšuje se i velikost úlohy a zároveň se mění přechod na nepříliš hezké barvy, které signalizují nutnost začít s řešením tohoto úkolu. O barevný přechod se nám postará další pomocná třída BarevnyPrechod. Osa se mění nejen v rámci časové aktualizace, ale i v závislosti na zvoleném zobrazovacím režimu, který je členěn na dny, týdny a měsíce. Počet sloupců je závislý také na aktuálním zobrazovacím režimu, tedy pokud je zobrazen aktuální den, počet sloupečků je dán počtem hodin, které zbývají od aktuálního času do konce dne. Pokud by byl zobrazen celý týden, bude počet sloupců roven hodnotě sedm, protože je brán v potaz celý týden. V případě zobrazení v měsících, počet sloupců odpovídá počtu dní ve zvoleném měsíci. Z výše uvedeného je patrné, že šířka jednotlivých sloupců by měla být závislá na zobrazeném režimu. O tento i další početní problémy, například velikost zobrazené úlohy, se stará k tomuto navržená třída Pocitadlo, jejímž úkolem je zajistit, aby v denním režimu byly sloupečky užší, než u týdenního režimu a to v poměru 1/24, jelikož jeden den odpovídá 24 hodinám. Obrázek uvedený v příloze číslo 2 se čtveřicí zadaných úkolů demonstruje princip časové osy. Po obou stranách osy jsou umístěna tlačítka pro pohyb mezi dny, týdny či měsíci. Uprostřed se nachází pole pro vybrání datumu, což umožňuje plynuleji a hlavně rychleji zobrazit požadovaný datum. Vlevo nahoře leží sada tlačítek pro přepínání zobrazovaného režimu. Přímo na časové ose je možné editovat veškeré úlohy. Abychom zobrazili editační okno dané úlohy, je nutné na tuto úlohu dvakrát poklepat. Součástí časové osy je i zobrazení aktuálně zvoleného datumu včetně k němu korespondujícímu názvu dne. Aby nebyly názvy dní uvedeny v angličtině, vytvořil jsem vlastní kolekci dní v češtině pomocí enumerátorů a následně zajistil jejich vzájemný převod, jak zobrazuje následující zlomek kódu.
33
public enum DnyTyden { Neděle, Pondělí, Úterý, Středa, Čtvrtek, Pátek, Sobota}; // ze zvoleneho datumu zjisti den v tydnu, ktery pretypuje na jeho index // a nasledne pretypuje na vlastni kolekci dni DnyTyden den = (DnyTyden)((int)CasovaOsa.Datum.DayOfWeek);
6.4 Úloha Pro realizaci samotného úkolu jsem vytvořil dvě na sobě závislé třídy. Třída Uloha má na starosti obalení veškerých potřebných dat, která jsou charakteristická pro vyjádření úlohy. Třída ZobrazitelnaUloha z těchto dat vytvoří vizuální objekt, který je poté zobrazen na obrazovce. Daný vizuální objekt je poděděný ze třídy TextBox, která se obyčejně využívá jako uživatelský vstup. Pro tento případ řešení je ale tato možnost zablokována, takže objekt má pouze informativní charakter. Tento způsob nám dokáže snadno zajistit případnou změnu vizuálního prvku tak, že třídu ZobrazitelnaUloha podědíme z jiného ovládacího prvku, například z popisku typu Label.
Obrázek 19 Závislost tříd
34
6.5 Funkcionalita aplikace 6.5.1 Přidání nové úlohy Abychom mohli do aplikace přidat nový úkol, je nutné, abychom se přepnuli na záložku Vytvoření nového úkolu, kde je nutné zadat požadované údaje. Pokud nezadáme název úkolu, bude mu automaticky přiřazen implicitní název, který se zobrazí na časové ose a bude vypadat takto: -bez názvu-. Datum termínu splnění úkolu je defaultně nastaven na akuální den a čas inkrementovaný o jednu hodinu, aby bylo reálné splnění tohoto nově přidávaného úkolu, protože minimální možná časová náročnost je jedna hodina. Zadávání hodin a minut je realizováno pomocí prvků typu textového pole TextBox a posuvníku Slider. Pro zadání hodinové náročnosti je možné využít buď přímé zadání hodnoty do textového pole, nebo tuto hodnotu zadávat pomocí jezdce. Obě tyto možnosti jsou spolu navzájem provázány pomocí tzv. Bindingu. To znamená, že pokud zadáme do textového pole číselnou hodnotu, projeví se tato hodnota i na posuvném jezdci. Je zřejmé, že stejný postup platí i obráceně. Pokud se ale zadá neplatná hodnota, dojde k červenému orámování, které značí špatný formát zadaných dat.
Obrázek 20 Chybný uživatelský vstup
Realizace v jazyce XAML je velice jednoduchá, jak demonstruje následující obrázek.
Obrázek 21 Binding
35
Je patrné, že vlastnost jménem Text u textového pole s názvem tbNarocnost je nastavena na aktuální hodnotu jezdce sliderNarocnost, která je označena názvem Value. Tímto způsobem je zajištěno propojení dvou na sobě nezávislých ovládacích prvků. Dále při vytváření úlohy můžeme z rozbalovacího seznamu vybrat osobu načtenou z databáze, kterou pověříme splněním tohoto úkolu. V případě takovéhoto delegování bude úloha na časové ose orámována bílým rámečkem.
Obrázek 22 Delegovaný úkol
6.5.2 Seznam úkolů Pro detailnější přehled úloh jsem vytvořil jejich zobrazení v komponentě typu ListBox. Důležitým požadavkem se stalo barevné odlišení těchto úloh, jelikož nebylo jednoduché na první pohled určit, kde začíná a končí konkrétní úkol.
Obrázek 23 Barevné odlišení úloh
Implementace přidávání položky do seznamu, aby měla požadovanou barvu pozadí, se provádí voláním metody, která jej nastaví, při přidávání nového prvku. Tato metoda
36
testuje počet aktuálních prvků v seznamu na dělitelnost dvěma. Daný způsob zajistí střídání barev položek.
Výše uvedená programová realizace barevného odlišení úloh kromě nastavení barvy pozadí popisku typu Label, nastavuje obsah tohoto popisku na objekt typu Uloha. Výpis potřebných údajů o úloze je zajištěn její metodou ToString(). Následuje ukázka tohoto kódu. public override string ToString() { return String.Format("NÁZEV ÚLOHY: {0}\r\nTERMÍN: {1}\r\nNÁROČNOST: {2}\r\nSTAV: {3} ({4}%)", NazevUlohy, DatumSplneni, PotrebnyCas, stav.StavSlovne, stav.StavUlohy); }
6.5.3 Seznam nesplněných úloh Seznam nesplněných úloh obsahuje pouze ty úkoly, kterým již vypršel termín pro jejich splnění, nebo, které byly vyhodnoceny jako „nestihnutelné“. V případě, že tento seznam obsahuje alespoň jednu úlohu, je karta Nesplněné úlohy obarvena červeně, aby uživatele na tuto skutečnost upozornila. Červené obarvení této karty zůstává do té doby, dokud nejsou veškere úlohy odstraněny, nebo editovány tak, aby byly ještě „stihnutelné“, tedy aby byly opět zobrazeny na časové ose. Následující dvojice obrázků zobrazuje rozdíly mezi těmito dvěma stavy.
37
Obrázek 24 Karta bez zvýraznění
Na obrázku 24 vidíme situaci, kdy aplikace neeviduje žádný nesplněný úkol. Opakem je ale situace na obrázku 25, kde se nachází alespoň jedna nesplněná úloha. V případě odstranění veškerých nesplněných úloh dojde opět k defaultnímu obarvení záložky, jak ukazuje obrázek 24.
Obrázek 25 Zvýraznění karty
6.6 Aktualizace Nedílnou součástí aplikace je aktualizace časové osy a synchronizace dat se všemi aktivními prvky. Tuto skutečnost řeší dvě doplňující vlákna, z čehož jedno provádí aktualizaci časové osy dvakrát do jedné minuty a druhé ve velmi krátkých intervalech kontroluje, zda proběhla nějaká změna, kterou je nutné synchronizovat. Toto řešení zamezuje častým pravidelným aktualizacím, které by zbytečně snižovaly výkon aplikace. Pro práci s vlákny jsem použil třídu Thread, která předává delegáta ThreadStart. Tento delegát označuje metodu, kde by vlákno mělo začít svojí činnost. Následující vývojový diagram se snaží přiblížit nekonečnou smyčku pravidelné aktualizace, neboli té aktualizace, ke které dochází vždy v pravidelných intervalech.
38
Obrázek 26 Vývojový diagram aktualizace programu
Dále pro názornost později uvedu i diagram pro realizaci aktualizace, která se provádí, pouze když je zapotřebí. Z diagramu bude patrné, že již před vstupem do nekonečného cyklu se provádí aktualizace, která je při spuštění aplikace nezbytná. Zásadní změnou je ale kontrola ve smyčce, která další aktualizace zavolá, jen když jsou zapotřebí. Dále oproti předchozímu případu se mnohonásobně zmenšila doba prodlevy pro další iteraci. To samozřejmě umožňuje rychlou reakci na uživatelské vstupy, například vytvoření úkolu. Uživatel totiž očekává okamžité přidání úlohy na časovou osu i do seznamu úloh, proto je tedy naprosto nevhodné, aby k této synchronizaci docházelo pouze dvakrát do jedné minuty. V tomto případě bude vyhodnocena změna, kterou zachytí smyčka a provede se okamžitá aktualizace.
39
Obrázek 27 Vývojový diagram nutné aktualizace
40
7 Závěr V této bakalářské práci se mi podařilo za využití nástrojů .NET Framework vytvořit aplikaci vycházející z intuitivního zobrazení naplánovaných úloh, která by měla sloužit jako plánovací manažer. V první řadě bylo nejdůležitější navrhnout a pokusit se realizovat způsob, který by zajistil generování barevného přechodu. Po ověření reálnosti a důkladném otestování tohoto způsobu jsem se teprve mohl pustit do implementace samotné aplikace. Zvládnul jsem jednak vytvoření uživatelsky přívětivé a dokonce i velmi jednoduché aplikace, ale také se mi podařilo jednoznačně odlišit jednotlivé úkoly na časové ose pomocí barevných přechodů, pomocí kterých je na první pohled zřejmé, kdy by měly být úlohy přibližně splněny. Dále se mi podařilo zrealizovat i delegování úloh jiným osobám. Takto delegované úkoly se na časové ose zobrazují s bílým orámováním, aby byly opět na první pohled odlišitelné od těch ostatních. Další druh orámování úloh souvisí s funkcionalitou, která slouží k upozornění, že již nastala doba, ve které je nutné dopracovat daný úkol. V tomto případě je orámování černé. Samozřejmostí jsou i další úspěšně naimplementované možnosti, jako například mazání či editování úloh. Pro správné fungování aplikace, které spočívá v pravidelné aktualizaci barevných přechodů, jsem přidal dvě vlákna. Tato vlákna se starají o veškerou synchronizaci dat mezi všemi zúčastněnými komponentami. Aplikace je připravena pro zobrazení historie všech kdy přidaných, splněných i smazaných úkolů. Další možné rozšíření aplikace by mohlo spočívat v zasílání emailů delegovaným osobám, které by informovaly o podrobnějších detailech jejich úkolu včetně termínu splnění. Jako další vylepšení aplikace by mohla být implementace kompletní správy osob, kterým mohou být úlohy přidělovány. Dále by bylo užitečné vytvořit filtry, které by zajišťovaly například přehled veškerých úloh, které byly zadány nějaké konkrétní osobě.
41
Seznam použité literatury 1.
Caunt, John. Time management: Jak hospodařit s časem. Brno : Computer Press, 2007. ISBN 978-80-251-1538-1.
2.
Lacko, Luboslav. SQL Kapesní přehled. Brno : CP Books, a.s., 2005. ISBN 80-251-0788-4.
3.
Nagel, Christian, a další. C# 2008 Programujeme profesionálně. Brno : Computer Press, a.s., 2009. ISBN 978-80-251-2401-7.
4.
Pecinovský,
Rudolf.
Návrhové
vzory.
Brno :
Computer
Computer
Press,
Press,
2013.
s.,
2010.
ISBN 978-80-251-1582-4. 5.
Pecinovský,
Rudolf.
OOP.
Brno :
a.
ISBN 978-80-251-2126-9. 6.
Petzold, Charles. Mistrovství ve Windows Presentation Foundation. Brno : Computer Press, a. s., 2008. ISBN 978-80-251-2141-2.
7.
Sharp, John. Microsoft Visual C# 2010 krok za krokem. Brno : Computer Press, a. s., 2010. ISBN 978-80-251-3147-3.
42
Seznam obrázků Obrázek 1 Ukázka úkolů v MS Outlook ......................................................................... 10 Obrázek 2 Návrh barevného přechodu 1 ........................................................................ 11 Obrázek 3 Návrh barevného přechodu 2 ........................................................................ 11 Obrázek 4 Návrh nesplněného úkolu .............................................................................. 12 Obrázek 5 Barevné přechody .......................................................................................... 12 Obrázek 6 Návrh delegovaného úkolu............................................................................ 13 Obrázek 7 Singleton........................................................................................................ 15 Obrázek 8 Servant ........................................................................................................... 16 Obrázek 9 CLR ............................................................................................................... 18 Obrázek 10 Ukázka kódu XAML ................................................................................... 20 Obrázek 11 Vícevláknové aplikace ................................................................................ 21 Obrázek 12 Uživatelské rozhraní – Vytvoření ............................................................... 23 Obrázek 13 Uživatelské rozhraní - Přehled .................................................................... 23 Obrázek 14 Uživatelské rozhraní - Úlohy ...................................................................... 24 Obrázek 15 E-R model tabulky „ukoly“ ......................................................................... 25 Obrázek 16 E-R model tabulky "osoby" ......................................................................... 26 Obrázek 17 ERA model .................................................................................................. 29 Obrázek 18 Realizace uživatelského rozhraní ................................................................ 29 Obrázek 19 Závislost tříd ................................................................................................ 34 Obrázek 20 Chybný uživatelský vstup ........................................................................... 35 Obrázek 21 Binding ........................................................................................................ 35 Obrázek 22 Delegovaný úkol ......................................................................................... 36 43
Obrázek 23 Barevné odlišení úloh .................................................................................. 36 Obrázek 24 Karta bez zvýraznění ................................................................................... 38 Obrázek 25 Zvýraznění karty ......................................................................................... 38 Obrázek 26 Vývojový diagram aktualizace programu ................................................... 39 Obrázek 27 Vývojový diagram nutné aktualizace .......................................................... 40
44
Seznam použitých zkratek CLR
Common Language Runtime, běhové prostředí platformy .NET Framework
IL
Intermediate Language, jazyk, do kterého je kód před spuštěním přeložen
SQL
Structure Query Language, strukturovaný dotazovací jazyk pro práci s databázemi
TPL
Task Parallel Library, knihovna pro práci s vlákny
WPF
Windows Presentation Foundation, nový grafický subsystém pro tvorbu programů pod Windows
XAML
Extensible Application Markup Language, značkovací jazyk používaný v technologii WPF
45
Přílohy 1 Obsah přiloženého CD Na přiloženém CD se v kořenovém adresáři nachází tato bakalářská práce ve formátu bakalarska_prace.pdf a zdrojové kódy aplikace s jednoduchým manuálem manual.pdf pro obsluhu programu.
46
2 Časová osa
47
3 Manuál 3.1 Vytvoření úlohy Pro vytvoření nové úlohy slouží záložka Vytvoření nového úkolu.
Název úlohy slouží pro stručný popis dané úlohy. Vyplnění tohoto pole není povinné. Pokud nedojde k vyplnění pole, má úloha implicitní název -bez názvu-. Termín splnění udává konkrétní datum a čas, kdy má být úkol splněn. Hodinová náročnost je reálné číslo udávající kolik času si vypracování úkolu vyžaduje. Toto číslo může zadat buďto manuálním zadáním do textového pole nebo pomocí posuvného jezdce. Delegovat slouží k výběru osoby z databáze, která bude pověřena k vypracování úlohy. Po zadání veškerých potřebných dat se musí pro potvrzení kliknout na tlačítko Vytvořit.
48
3.2 Přehled úloh Přehled aktivních úloh nalezneme na kartě Přehled a Úkoly. Pro grafické zobrazení úloh je určena záložka Přehled, na které se nachází časová osa.
Pro obyčejný textový výpis veškerých úkolů slouží karta Úlohy.
49
3.3 Editování úloh Editování úloh je možné provést buďto na časové ose poklepáním na vybraný úkol nebo v textovém seznamu úloh po kliknutí na tlačítko Editovat.
V obou výše zmíněných případech se objeví editační okno, které je zobrazeno na níže uvedeném obrázku.
50
