UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

UNICORN COLLEGE Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE

Online komunikační systém s kreslícím plátnem

Autor BP: Pavel Šot Vedoucí BP: Ing. Petr Bůva

2015 Praha

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Online komunikační systém s kreslícím plátnem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne 31. 7. 2015

…………………………………… Pavel Šot

Poděkování Děkuji vedoucímu bakalářské práce Ing. Petru Bůvovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

Online komunikační systém s kreslícím plátnem Online communication system with canvas

6

Abstrakt

Tato bakalářská práce pojednává o tvorbě softwarové produktu od jeho úplného začátku, na kterém byl nápad či požadavek na aplikaci, která by řešila přenos kreslící plochy mezi více uživateli v reálném čase, a nabízela další podpůrné funkce jako textový chat a přenos souborů. Nejprve jsou upřesněny požadavky na to, co by taková aplikace měla všechno splňovat, přičemž je preferována platforma Windows. Následně probíhá vyhledání existujících řešení pro tuto platformu, jejich testování, srovnání, načež dojde k inspiraci nabízenými funkčnostmi. Po zjištění, že v současné době neexistuje udržovaná desktopová aplikace nabízející alespoň část požadovaných funkcí, je zpracována vize aplikace nové. Na tuto vizi navazuje softwarová analýza, která obsahuje konkretizaci požadavků a seznamy případů užití. Následuje popis implementace, kde je řešena architektura, grafické rozhraní, business logika a taktéž způsob přenosu dat po počítačové síti. V závěru je provedena realizace prototypu navržené aplikace, shrnutí získaných poznatků a popsány možnosti budoucího rozšíření. Cílem této práce je tedy vyvinout aplikaci, která bude řešit přenos kreslícího plátna mezi uživateli, bude funkční pod nejnovějšími verzemi systému Windows a dle analýzy bude splňovat další funkční i nefunkční požadavky.

Klíčová slova: vývoj, software, síť, online, whiteboard, kreslení, malování, chat

7

Abstract

This bachelor thesis addresses a process of developing software product from the very beginning. There was an idea or a need of an application that will deal with the transfer of graphical canvas between multiple users in real time, and offer other functions like text chat and file transfer. At first, the requirements for searching existing applications are specified. The preferred platform is Windows. Then proceeds to find existing solutions for this platform, perform testing, comparing and gather inspiration by offered functionalities. Having find out that there’s no updated desktop application offering at least a few required functions, the vision of new application is written up. Vision is followed by software analysis, which contains concretization of requirements and list of Use-Cases. After that follows design specification, where architecture, graphical user interface, business logic and also transfer method over the computer network are dealt with. Finally, the prototype of designed application is developed, acquired knowledge is summarized and described, and future extension is proposed. So the goal is to develop an application, that will deal with the transfer of canvas between multiple users, will be able to run under current versions of Windows operating system and as far as possible won’t have a competitor in the desktop segment.

Keywords: development, software, network, online, canvas, draw, paint, chat

8

OBSAH 1

2

Úvod .................................................................................................................................................... 11 1.1

Idea .............................................................................................................................................. 11

1.2

Cíle práce................................................................................................................................... 12

1.3

Terminologie ........................................................................................................................... 12

Vyhledání a analýza existujících aplikací ............................................................................. 14 2.1

Základní požadavky na vyhledávané aplikace ........................................................... 14

2.2

Rozšířené požadavky na vyhledávané aplikace ......................................................... 14

2.2.1

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

2.2.2

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

2.3

2.3.1

Vyhledávání dle klíčových slov ................................................................................ 15

2.3.2

Vyhledávače .................................................................................................................... 15

2.4

Počet a souhrn nalezených řešení ................................................................................... 16

2.5

Testovací prostředí ............................................................................................................... 16

2.6

Seznam a analýza nalezených řešení ............................................................................. 17

2.6.1

Analyzované aplikace .................................................................................................. 17

2.6.2

Popis vybraných aplikací ........................................................................................... 18

2.7

3

Výsledky testování nalezených aplikací........................................................................ 34

2.7.1

Vynechané požadavky ................................................................................................. 34

2.7.2

Seskupení požadavků .................................................................................................. 34

Vize vlastního řešení .................................................................................................................... 36 3.1

Cílová skupina ......................................................................................................................... 36

3.2

Síťová architektura aplikace ............................................................................................. 37

3.3

Typ aplikace ............................................................................................................................. 39

3.3.1

Výhoda webové aplikace ............................................................................................ 39

3.3.2

Výhoda desktopové aplikace .................................................................................... 39

3.3.3

Volba desktopové aplikace nebo webové aplikace .......................................... 40

3.4 4

Způsob hledání ....................................................................................................................... 15

Shrnutí vize .............................................................................................................................. 43

Analýza vlastního řešení ............................................................................................................. 44 4.1

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

4.2

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

4.3

Strukturální model ................................................................................................................ 47

4.3.1

High-level pohled .......................................................................................................... 47

4.3.2

Doménový diagram ...................................................................................................... 47

4.4

Seznam Use-Case ................................................................................................................... 48 9

4.4.1

Obecné funkčnosti aplikace ...................................................................................... 49

4.4.2

Funkce whiteboardu jako celku .............................................................................. 50

4.4.3

Kreslení a manipulace s objekty na whiteboardu ............................................ 50

4.4.4

Textový chat .................................................................................................................... 51

4.4.5

Podpůrné funkce serveru .......................................................................................... 51

4.5 5

Popis Use-Case ........................................................................................................................ 52

Implementace.................................................................................................................................. 59 5.1

Fáze vývoje ............................................................................................................................... 59

5.1.1

První fáze – prototyp ................................................................................................... 59

5.1.2

Druhá fáze ........................................................................................................................ 59

5.1.3

Třetí fáze........................................................................................................................... 60

5.1.4

Čtvrtá fáze ........................................................................................................................ 60

5.2

Použité technologie ............................................................................................................... 61

5.3

Softwarová architektura ..................................................................................................... 62

5.3.1

Prezentační vrstva ........................................................................................................ 64

5.3.2

Vrstva business logiky................................................................................................. 64

5.3.3

Vrstva přenosu a dat .................................................................................................... 68

5.4

Uživatelské rozhraní ............................................................................................................. 73

5.5

Class diagram .......................................................................................................................... 78

5.6

Testování................................................................................................................................... 79

5.7

Rozšiřitelnost aplikace ........................................................................................................ 79

5.8

Distribuce mezi uživatele ................................................................................................... 81

5.9

Nápověda a dokumentace .................................................................................................. 81

6

Závěr ................................................................................................................................................... 82

7

Conclusion ........................................................................................................................................ 83

8

Seznam použitých zdrojů............................................................................................................ 84

9

Seznam zkratek a pojmů ............................................................................................................. 88

10 Seznam obrázků ............................................................................................................................. 89 11 Seznam tabulek .............................................................................................................................. 90 12 Seznam příloh ................................................................................................................................. 91 13 Příloha 1 – Obsah přiloženého CD ........................................................................................... 92

10

1 ÚVOD Tato bakalářská práce se zaměřuje na vývoj nového softwarového produktu, aplikace pro přenos kreslící plochy s dalšími podpůrnými funkcemi. V dalších částech této práce je popsána realizace vzniku této aplikace, a to od počáteční vize, přes analýzu a design až k samotné implementaci.

1.1 Idea Původní myšlenka, která však ve výsledku není hlavní podstatou této práce, byl nový instant messenger, který by měl dobře použitelné a graficky vyvážené uživatelské rozhraní, uživatele by neobtěžoval reklamami, fungoval by bez přeposílání dat třetím stranám a rovněž by byl dostupný zdarma. Od tohoto konceptu bylo nakonec upuštěno, neboť podobné aplikace naráží především na problém s pohodlností uživatele, který raději pošle zprávu jednoduše e-mailem či přes webové stránky typu Gmail nebo Facebook. A především, přidaná hodnota takové aplikace by z jeho pohledu běžného uživatele byla takřka nulová, neboť by ji, na rozdíl od řešení v podobě webových stránek, musel instalovat, učit se s ní zacházet a případně ji i udržovat v aktuálním stavu. Přidaná hodnota aplikace je právě to, co dělá aplikaci výjimečnou, používanou a v případě vhodného provedení i úspěšnou. Přidaná hodnota většinou nespočívá ve zmíněném nezobrazování reklam či ve věcech, které nejdou vidět běžným okem uživatele, ale ve funkčnostech, které nikdo jiný nenabízí, nebo je nenabízí v požadované podobě. Tyto funkčnosti samozřejmě musí řešit, zjednodušovat nebo dále pracovat s nějakou situací či problémem tak, aby uživatel vyhodnotil aplikaci jako užitečnou a nadále ji využíval. Pohledem na tuto myšlenku z druhé strany, namísto ze strany programátora ze strany uživatele, došlo postupem času k vymezení jistých potřeb, které by mohl vyřešit specializovaný software. K těmto potřebám se řadí možnost přenosu kreslícího prostředí mezi více uživateli. Tímto prostředím je myšlen jakýsi softwarový ekvivalent klasické bílé magnetické tabule, nazývané rovněž whiteboard, na kterou může více uživatelů zároveň kreslit a sdílet tak svoje myšlenky s ostatními. Za předpokladu komunikace přes internet nebo jinou rozsáhlou síť, během které se uživatelé nemusí nacházet ve společné místnosti, aby spolu mohli hovořit, je výše uvedená potřeba rozšířena i o existenci textové komunikace. Ta se sice odvíjí od 11

původní myšlenky vlastního instant messengeru, avšak funkce whiteboardu je považována za prioritní. Ačkoliv relativně obyčejné kreslení a textová komunikace samy o sobě zpravidla nejsou považovány za žádané, nezbytné a pro přenos dat dostatečně univerzální funkce, dojde k rozšíření o sdílení souborů, přenos obrázků a jejich grafickou galerii, flexibilní uživatelské rozhraní a mnoho dalších funkcí souvisejících právě s whiteboardem. Takový software při vhodném provedení může poskytovat značnou oporu pro práci v týmu, kde se členové nemusí nacházet v bezprostředním kontaktu a přitom mohou efektivně spolupracovat na projektu, diskutovat, sdílet potřebná schémata a soubory. Samozřejmě je možné i využití pro volnočasové aktivity, lze-li mezi ně řadit i prostou komunikaci mezi uživateli, která se netýká jejich zaměstnání.

1.2 Cíle práce Prvním, očekávaným cílem této práce je vyhledání a následná analýza v současné době dostupného řešení, pokud vůbec nějaké existuje. Tedy takových aplikací, které disponují kreslící plochou, která je přenášena mezi více uživateli. Vyhledávané aplikace musí splňovat i další požadavky, které budou dále upřesněny. Na základě představy a poznatků z analýzy, úvodní ideje a předchozích zkušeností vznikne návrh softwaru s dále popsanými vlastnostmi a funkcemi, které by měla ideální aplikace uživateli nabízet. Po vizi bude následovat softwarová analýza a design, tedy již detailnější návrh aplikace jako takové. Posledním krokem bude implementace, tedy řešení konkrétních praktických problémů, realizace v odpovídajícím vývojovém prostředí a průběžné testování aplikace.

1.3 Terminologie V této práci je obsažena řada pojmů, ať už technických či netechnických, které však nejsou vždy použity ve zcela korektním významu, který udává slovník. Je to z důvodu zlepšení čitelnosti s ohledem na zvyklosti v IT oboru. Některé z těchto pojmů jsou objasněny v následující tabulce č. 1.

12

Tabulka 1: Terminologie použitá v této práci

Pojmy

Popis

kreslení, malování

v této práci se uvedené činnosti nerozlišují, obojí je použito ve shodném významu

křivka

v této práci je křivkou nazývána kresba tužkou nebo malba štětcem, kopírující tah kurzoru myši (nikoliv přímka či jiné útvary)

textový chat

textová komunikace mezi dvěma nebo více uživateli, přenášená pomocí počítačové sítě

kreslící plocha, kreslící plátno, whiteboard

plocha, na kterou je možné kreslit různými nástroji, vkládat obrázky či psát text a jinak manipulovat s obsahem

online aplikace, webová aplikace

aplikace, která běží ve webovém prohlížeči, díky čemuž je často platformově nezávislá, není potřeba ji instalovat a údržba ve smyslu aktualizací a oprav probíhá na straně poskytovatele, bez zásahu uživatele

desktopová aplikace, formulářová aplikace

nativní aplikace sestávající z formulářových oken, která běží přímo v prostředí operačního systému, neboli na pracovní ploše uživatele

technologie

jako technologie je v této práci označován podstatný technický aspekt pro daný kontext, může jít tedy o programovací jazyk, framework, platformu, apod.

13

2 VYHLEDÁNÍ A ANALÝZA EXISTUJÍCÍCH APLIKACÍ Před započetím samotného vyhledávání existujících aplikací je nejprve nezbytné stanovit požadavky, které tyto aplikace musí splňovat, tedy jednak požadavky týkající se nabízených funkčností, dále požadavky nezbytné pro běh, tj. například požadovaná platforma, a v neposlední řadě požadavek na dostupnost zdarma, a to alespoň pro zkušební účely.

2.1 Základní požadavky na vyhledávané aplikace Jedná se o zcela obecné požadavky, dle kterých budou aplikace vyhledávány. Nesplnění některého z těchto požadavků může znamenat, že ačkoliv aplikace existuje a pravděpodobně i funguje, nelze ji v požadovaném prostředí spustit a dále používat, nebo se jedná o aplikaci, která nenabízí žádané funkčnosti, je tedy zřejmě určená pro jiné účely a je zbytečné ji dále analyzovat. Základní funkční i nefunkční požadavky jsou následující: -

Víceuživatelská aplikace (současně spolupracuje více uživatelů v reálném čase, nejedná se tedy např. o MS Paint, Adobe Photoshop či jiné podobné nástroje)

-

Kreslení na whiteboard a přenos jeho obsahu mezi uživateli

-

Dostupnost zdarma a to alespoň pro studentské či testovací účely

-

Funkčnost na operačním systému Windows 7 a novějším

2.2 Rozšířené požadavky na vyhledávané aplikace Aby bylo vyhledané aplikace podle čeho dále hodnotit, následuje výčet vlastností, co by jedna taková aplikace mohla v ideálním případě uživateli nabízet za funkčnosti nebo jak by na něj měla působit.

2.2.1 Funkční požadavky -

Textový chat mezi více uživateli

-

Vkládání vlastních obrázků na whiteboard

-

Přiložení jednoho či více souborů

-

Práce s různými nástroji (nejen tzv. štětec)

-

Export obsahu kreslící plochy do souboru

-

Schopnost alespoň krátkodobě identifikovat autora křivky

14

2.2.2 Nefunkční požadavky -

Spolehlivost (nepřerušování spojení či jiná desynchronizace)

-

Rychlá odezva (přenos běžné akce mezi uživateli by neměl trvat déle než 1 až 2 sekundy, to samozřejmě neplatí pro přenos souborů či vkládaných obrázků)

-

Jednoduché a přehledné uživatelské rozhraní

-

Výsledek přenosu kreslení by měl odpovídat tomu, co uživatel skutečně kreslil (v rámci možností nedopočítávat tahy tak, aby např. místo kruhu vznikl čtverec)

2.3 Způsob hledání V době informačních technologií nelze předpokládat, že by na vyhledání podobných síťových aplikací nestačily běžně dostupné internetové vyhledávače, jako Google či Bing, případně další specializované vyhledávače (např. literatury). Během vyhledávání byly použity různé kombinace klíčových slov v anglickém jazyce, neboť v případě slov v českém jazyce nebyly nacházeny žádné relevantní výsledky.

2.3.1 Vyhledávání dle klíčových slov online, paint, chat, multiuser, canvas, shared, image, drawing, board, whiteboard

2.3.2 Vyhledávače K vyhledání aplikací bylo užito internetových vyhledávačů Google a Bing, později kromě nich byly aplikace vyhledávány i s pomocí webových stránek AlternativeTo1. Počáteční způsob vyhledávání požadovaných aplikací pomocí běžných vyhledávačů se ukázal jako málo účinný, protože nalezené výsledky často neodpovídaly požadavkům. Mnohdy se jednalo o výhradně mobilní aplikace, o blogy nebo o internetová fóra, na nichž probíhaly diskuse s podobnou tématikou. Jako mnohem efektivnější se nakonec ukázalo vyhledávání pomocí uvedeného webu AlternativeTo, který umožňuje snadné nacházení alternativ k vybranému existujícímu softwaru. Tímto způsobem, tj. výběrem určité ověřené aplikace splňující výše uvedené požadavky, tak bylo možné vyhledat další aplikace, podobné vybrané aplikaci.

1

Web AlternativeTo se nachází na adrese http://alternativeto.net/

15

2.4 Počet a souhrn nalezených řešení Naprostá většina nalezených aplikací je realizována ve webovém prohlížeči, nejčastěji pomocí HTML5 a souvisejících technologií. Protože HTML5 se ve větší míře rozšiřuje teprve od roku 20102, mohly tyto aplikace vzniknout nejspíše během posledních 5 let. Ostatní webové aplikace byly distribuovány jako Java applety nebo skrze Adobe Flash Player. Je jich o polovinu méně, přitom by se mohlo zdát, že Flash, který staví na grafice a animacích, bude mít v počtu navrch. Desktopových řešení bylo nalezeno úplné minimum, přesněji dvě, přičemž jedno z nich, z důvodu neaktuálnosti implementace protokolu, ani nebylo možné spustit. Ve výsledku byla tedy testována pouze jediná desktopová aplikace. Počet nalezených aplikací, včetně uvedení technologií užitých k jejich vývoji, je v tabulce č. 2 níže. Poslední řádek tabulky udává počet aplikací, které buď nefungovaly, nebo přestaly být dostupné v průběhu tvorby této práce. Tabulka 2: Počet nalezených aplikací včetně užitých technologií

Typ

Technologie

Počet aplikací

online

HTML5 (HTML, CSS, JavaScript)

10

online

Adobe Flash

5

online

Java applet

2

desktop

.NET Framework

1

- (neurčen)

- (neurčeno z důvodu nefunkčnosti)

5

Celkem

23

2.5 Testovací prostředí Následné testování nalezených aplikací proběhlo zpravidla na běžném notebooku s aktualizovaným 64 bitovým operačním systémem Microsoft Windows 8.1 (anglické lokalizace). Použity byly webové prohlížeče Internet Explorer, Google Chrome a Mozilla Firefox. Krom toho bylo pro testování využito i připojení ke vzdálené ploše stolního PC s Windows 7, kde tento PC se nacházel cca 5 kilometrů daleko, připojen k internetové lince o rychlosti 100 Mbps download / 20 Mbps upload.

HTML Version Statistics. PowerMapper. [online]. [cit. 2015-07-31]. Dostupné z: http://try.powermapper.com/Stats/HtmlVersions 2

16

Webové aplikace, kterých je většina, byly tedy testovány otevřením ve třech odlišných prohlížečích na jednom prostředí zároveň. Přenos dat, ačkoliv aplikace běží na stejném stroji, stejně ve většině těchto případů probíhá skrze internet „tam a zpátky“, není tedy vyloženě nutné simulovat reálného vzdáleného uživatele. Přesto ale pro ověření tohoto bylo ještě ve čtvrtém okně otevřeno připojení ke vzdálené ploše s prohlížečem Google Chrome. Jediná uvedená desktopová aplikace, což je plugin pro Skype nazvaný IDroo, byl testovaný i na dalším velice obdobném stroji s operačním systémem Windows 8.1, kde tento stroj byl umístěný ve stejné místnosti jako zmíněný notebook, ale jejich propojení bylo nasimulováno přes internet. Důvodem bylo testování, jak se bude aplikace chovat při intenzivním kreslení dvou uživatelů ve stejný okamžik. Detailní popis testovacího prostředí je v níže uvedené tabulce č. 3. Tabulka 3: Testovací prostředí

Konfigurace PC

Intel Core i5 2.66 GHz 4 GB RAM 120 GB SSD

Síťové rozhraní

WLAN 802.11n, 130 Mb/s

Operační systém

Windows 8.1 Pro 64bit EN

Webový prohlížeč

Microsoft Internet Explorer 10, 11 Google Chrome 35.0, 36.0, 44.0 Mozilla Firefox 26.0

Připojení k internetu

O2 VDSL, 20 Mbps download / 2 Mbps upload

2.6 Seznam a analýza nalezených řešení Nalezené aplikace byly testovány v uvedeném testovacím prostředí s tím, že všem testovaným aplikacím autor práce věnoval stejné množství času – jednu hodinu na jednu aplikaci. Během testování nebylo síťové připojení zatěžováno jiným způsobem, stejně tak systémové prostředky nebyly nijak zásadně využívány jinými aplikacemi.

2.6.1 Analyzované aplikace Zjištěné rozdíly mezi aplikacemi jsou velmi velké. Od profesionálně vypadajících nástrojů, přes umělecky zaměřené kolektivní malování, až po technologické experimenty programátorů.

17

Následující tabulka č. 4 obsahuje výčet aplikací, které byly analyzovány, a to včetně adresy jejich webových stránek, typu a použité technologie. Poté následuje detailnější popis těchto aplikací včetně tabulek, které mimo jiné udávají, jaké požadavky z požadavků na hledané aplikace, dané aplikace splňují. Tabulka 4: Seznam analyzovaných aplikací (řazeno abecedně)

#

Název

WWW

Typ

Technologie

1

A Web Whiteboard

awwapp.com

online

HTML5

2

Board800

board800.com

online

Flash

3

Conceptboard

conceptboard.com

online

HTML5

4

CoSketch

cosketch.com

online

HTML5

5

Draw It Live

drawitlive.com

online

HTML5

6

drawonthe.net

drawonthe.net

online

HTML5

7

FlockDraw

flockdraw.com

online

Flash

8

Groupboard

groupboard.com

online

HTML5

9

Groupboard (alternativní)

groupboard.com

online

Java

10

IDroo 1.0

idroo.com

desktop

.NET

11

IDroo 2.0

idroo.com

online

HTML5

12

iScribble

iscribble.net

online

Flash

13

MegaScopes Whiteboard

whiteboard.megascopes.com

online

HTML5

14

NoteBookCast

notebookcast.com

online

HTML5

15

RealtimeBoard

realtimeboard.com

online

Flash

16

Scribblar

scribblar.com

online

Flash

17

Scriblink

scriblink.com

online

Java

18

Twiddla

twiddla.com

online

HTML5

2.6.2 Popis vybraných aplikací Pod popisem každé aplikace následuje tabulka, ve které je uvedeno plnění funkčních požadavků dle vize a dále technické informace za účelem srovnání jednotlivých řešení. Níže uvedené údaje byly zjednodušeny za účelem předejití přeplnění tabulek opakujícím se nadbytečným textem. Předně je tedy vhodné uvést, co některé údaje znamenají, případně jak byly získány.

18

Více kreslících nástrojů Pokud aplikace neobsahuje pouze kreslení křivky a s tím související funkčnosti (například změnu barvy, tloušťky aj.), ale například i kreslení elipsy, obdélníku, přímky či jiných obdobných tvarů, je v předmětné tabulce uvedeno, že splňuje požadavek více kreslících nástrojů. Výhodou více kreslících nástrojů, mezi které se řadí například kružnice, obdélník a přímka je, že se aplikace stává lépe použitelnější pro tvorbu diagramů, v důsledku čehož tyto diagramy vypadají významně lépe. Odezva Odezvou je myšlena časová prodleva, za kterou se změna na uživatelově kreslící ploše promítne na plochu ostatních uživatelů. Měření bylo provedeno obyčejnými stopkami na mobilním telefonu, proto je nutné zohlednit to, že takové měření je značně nepřesné, neboť časový okamžik mezi začátkem a koncem měření je velmi krátký a závisí tak tedy především na rychlosti reakce člověka, který toto měření provádí a rovněž i stopkách, které nemusí být uzpůsobeny na to, měřit takto krátké časy. Je také třeba vzít v potaz, že s výjimkou jedné jsou všechny aplikace webové, připojují se tedy ke svým vlastním serverům, které se mohou nacházet a s nejvyšší pravděpodobností se nacházejí v jiných státech světa. Data tak mohou být přenášena například do USA, což i dnes může trvat nezanedbatelný časový okamžik. Ze kterého státu a s jak rychlou konektivitou se uživatel k aplikaci připojuje, pochopitelně není schopen poskytovatel aplikace ovlivnit a nelze tedy konstatovat, že při delší odezvě je aplikace horší než ostatní. Tento údaj je tedy spíše orientační a udává, které aplikace se při testování jevily jako rychlé, středně rychlé či pomalé, což lze odvodit z přibližného času odezvy, uváděného v sekundách. Okamžik přenosu Aplikace tohoto typu mohou přenášet tahy uživatele, neboli obecněji pohyby na kreslící ploše, v několika rozdílných variantách. Ta nejjednodušší je taková, že je přenášena pouze samotná změna a to až poté, co ji uživatel dokončí. Uživatel tedy klikne myší na kreslící plochu, pohybem tvoří obrazec, zatímco ostatní v tento moment nevidí nic. Až poté, co uživatel dokončí pohyb a uvolní tlačítko myši, je tento obrazec přenesen a zobrazen i ostatním. 19

Druhá varianta je okamžitý přenos, tedy v momentě kliknutí a tažení myší i ostatní vidí, jak uživatel kreslí obrazec. To je celkem praktické, neboť se tak dá i lépe gestikulovat a tím něco vysvětlovat ostatním uživatelům. Rovněž je pro člověka přirozenější, když obrazce vznikají postupně, než když se bliknutím náhle zjeví. Třetí způsob rozšiřuje ten druhý pouze o to, že je přenášen i pohyb kurzoru po kreslící ploše v momentech, kdy uživatel nic nekreslí. Obsah plochy Obsah kreslící plochy, ač může vypadat u různých aplikací stejně, lze realizovat několika způsoby. Může se jednat buď o kolekci objektů, kde objekt jde po vytvoření vybrat a lze s ním různě manipulovat, například pohybovat, měnit velikost, barvu, pořadí či jiné vlastnosti. Podobně je tomu například v aplikacích, co pracují s tzv. vektorovou grafikou, či nástrojích jako Microsoft Visio. Naproti tomu se může jednat o bitmapu, tedy dvourozměrné pole, kde se při nakreslení obrazce změní pouze barva konkrétních bodů. S obrazcem nelze více manipulovat, lze jej pouze překreslit obrazcem jiným, nebo smazat, což je de facto rovněž překreslení barvou pozadí. Příkladem takové aplikace je Malování (anglicky Paint) ve Windows. Existuje ještě třetí možnost, která je kombinací obou výše zmíněných. Plocha je tedy částečně bitmapa a částečně je i složena z objektů, se kterými lze dále pracovat. Toto nebývá příliš časté a může to nejspíše značit buď speciální požadavky na aplikaci, nebo přijetí určitého kompromisu co se týká složitosti vývoje a komfortu používání.

20

2.6.2.1 A Web Whiteboard Velice jednoduchá aplikace s kompaktním a elegantním designem, avšak pouze se základními funkcemi, jako je kreslení křivky, volba barvy z osmi předdefinovaných barev a možnost změny tloušťky štětce. Bitmapový obsah plochy neumožňuje žádnou další manipulaci s obrazci. Oficiálně nabízí funkčnost kromě PC i na tabletech a smartphonech. Velikost kreslící plochy záleží na velikosti okna prohlížeče, není tedy fixně daná ze strany aplikace. Odezva různě kolísá, zřejmě podle vytížení serveru. Data po odpojení všech uživatelů uchovává jen dočasně, takže se prakticky není možné vrátit k dříve vytvořenému obsahu. Také není možné zjistit, zda je ještě někdo jiný připojený k relaci, chybí jakýkoliv seznam uživatelů. Ztrátu připojení aplikace občas nebyla schopná ohlásit, případně se znovu připojit, obsah plochy se tak za určitých okolností mezi uživateli lišil a nedocházelo k jeho přenosu. Splněné funkční požadavky

Technické vlastnosti

Textový chat

ne

Technologie

HTML5

Vkládání obrázků

ne

Odezva

< 0,5 s

Připojování souborů

ne

Okamžik přenosu

ihned

Více kreslících nástrojů

ne*

Obsah plochy

bitmapa

Export do souboru

ano

Identifikace autora

ne

Poznámky * mimo kreslení křivky lze vkládat jednoduché jednořádkové texty, kterým ale nelze určit velikost, font či styl, pouze barva

2.6.2.2 Board800 Jedna z méně kvalitních aplikací, která sice na pohled vypadá čistě a použitelně, avšak funkčnost prostředí je nedomyšlená a omezující. Uživatel, který se poprvé setká s touto aplikací, pravděpodobně nebude chápat ovládání. Obsah plochy jsou evidentně objekty, což se zde jeví téměř jako nevýhoda, neboť je nelze klasickým způsobem označit a dále s nimi manipulovat. Lze je pouze kliknutím přesně objekt a tažením posouvat, nebo pravým klikem měnit pořadí. Na toto je potřeba značná přesnost, neboť není zobrazeno obvyklé ohraničení výběru obdélníkem, a je nutné se trefit například na úzkou linku. Odstranit objekt lze jen přetažením do pravého dolního rohu. 21

Kreslící plocha je relativně velmi malá, jak do šířky (640 px), tak do výšky (480 px), pro obrazovky s vysokým rozlišením je značně nepraktická. Jako částečná kompenzace malé plochy lze uvažovat to, že je zde možnost používat více kreslících ploch, teoreticky až neomezené množství, mezi kterými lze snadno přepínat. Kromě prostředí má aplikace i drobné problémy s vykreslováním, dochází k různým zpožděním, především na ploše samotného kreslícího uživatele. Také spolehlivost je diskutabilní, neboť někdy s nakreslenými obrazci nelze pohybovat a po nějaké době se některé z nich vytrácí. Splněné funkční požadavky


Textový chat

ne

Technologie

Flash


ano*

Odezva

< 0,5 s


ne

Okamžik přenosu

po dokreslení


ano

Obsah plochy

objekty

Export do souboru

ano

Identifikace autora

ne

Poznámky * upload přímo z lokálního umístění není možný, lze pouze zadat URL obrázku umístěného na internetu

2.6.2.3 Conceptboard Podle názoru autora se jedná o zdařilý nástroj s kvalitně provedeným prostředím a mnoha funkcemi, který je zaměřen na skutečnou práci v týmu a business používání. Prostředí je krom čistého designu i značně variabilní, panely lze skrývat a vysouvat, reakce na případné zmenšení okna prohlížeče je také docela vhodně vyřešena. Kreslení křivek a všech obrazců je vyhlazeno, takže výsledný obsah plochy vždy vypadá velmi čistě a vzhledně. Velikost plochy se jeví být neomezená, bohužel v základní zkušební variantě je po překročení využití určitého množství místa kreslící plocha zablokována a uživatel je nucen upgradovat na jednu ze zpoplatněných verzí. Obsah plochy je ukládán na serveru a lze se k němu po libovolně dlouhé době vrátit.

22

Po funkční stránce, v prostředí a ovladatelnosti není aplikaci veskrze co vytknout, snad kromě relativně vysoké hardwarové náročnosti a také odezvě, která trochu podezřele kolísá. Pro používání je nutné se nejprve na stránkách registrovat a poté buď zakoupit některou z variant, nebo použít variantu základní (ta byla rovněž použita při analýze). Základní varianta však umožňuje práci pouze jedinému uživateli, ostatní jej mohou jenom sledovat, a jak již také bylo zmíněno, je omezeno využití plochy. Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5


ano

Odezva

0,5 – 1 s


ano

Okamžik přenosu

po dokreslení*


ano

Obsah plochy

objekty

Export do souboru

ano

Identifikace autora

ne*

Poznámky * lze zapnout i okamžitý přenos kurzoru, u kterého se zobrazuje jméno uživatele (kresba je však stejně přenesena až po dokončení tahu)

2.6.2.4 CoSketch Po grafické stránce nevzhledná, zastaralá a nepříliš dobře ovladatelná aplikace, která nemá moc co nabídnout. Odezva je sice nízká, nicméně aplikace špatně funguje v Internet Exploreru a obsah plochy se ukládá na serveru nejvýše na 10 minut – po této době, nejsou-li uživatelé aktivní, je obsah zahozen a uživatelé odpojeni. Zajímavou výhodou aplikace je možnost zobrazit historii provedených kroků na kreslící ploše, přičemž je u každého kroku uveden i autor. Realizováno je to však nevhodně, seznam kroků je malý, naprosto nepřehledný a špatně se používá. Neobvyklé je řešení obsahu plochy, které se skládá z tzv. inkoustu (ink) a razítek (stamps). Razítky jsou myšleny vložené objekty jako vlastní obrázky, obrázky z galerie a text. Vše ostatní, jako křivky, přímky, obdélníky aj. jsou inkoust. Prakticky se toto liší tak, že s razítky jde manipulovat, respektive je vybrat, přesunout, změnit velikost či odstranit. Inkoust jde akorát překreslit nebo vymazat.

23

Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5


ano

Odezva

< 0,5 s


ne

Okamžik přenosu

po dokreslení


ano

Obsah plochy

bitmapa i objekty

Export do souboru

ano

Identifikace autora

ne*

Poznámky * v seznamu uživatelů po dokončení tahu problikne údaj, kdo zrovna kreslil a v historii kroků lze dohledat autora

2.6.2.5 Draw It Live Podobně jako Board800 nebo CoSketch je i toto nepříliš kvalitní aplikace. Odezva je relativně velká, prostředí velmi chudé a ovládání je podivné, objekty lze aspoň snadněji vybrat a manipulovat s nimi. Kreslící plocha je opět neprakticky malá, na šířku má 700 a na výšku 400 pixelů. Vzhledem k tomu, že nalevo od kreslící plochy je chat, který je naprosto zbytečně obrovský, působí kreslící plocha skoro jako vedlejší produkt. V prohlížeči Chrome se špatně zobrazuje nástrojový panel, část jeho funkcí vůbec nelze použít. Aplikace také nabízí možnost zobrazení a procházení historie kroků, toto je realizováno výrazně lépe než u CoSketch. Rovněž je uveden autor a lze se vrátit v historii zpět. Pro použití aplikace se není třeba registrovat či přihlašovat, stačí pouze kliknout na odkaz na hlavní stránce. Ta je ale nebývale obsahově chudá, bez jakýchkoliv relevantních informací a design je velice nevzhledný. S přihlédnutím na všechny tyto fakty se celá aplikace jeví spíš jako demonstrace nových možností HTML5. Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5


ne

Odezva

cca 1 s


ne

Okamžik přenosu

po dokreslení


ano

Obsah plochy

objekty

Export do souboru

ano

Identifikace autora

ne*

Poznámky * identifikace autora je možná pouze v historii provedených kroků 24

2.6.2.6 drawonthe.net Tato aplikace se opět spíš řadí mezi zmíněné „pokusy programátora“ a demonstraci toho, že pomocí HTML5, respektive JavaScriptu lze realizovat například sdílenou kreslící plochu. Její funkce a prostředí je velmi jednoduché, k dispozici je pouze kreslení křivky na bílé pozadí, kde si lze vybrat z 15 barev a 4 tlouštěk čáry. Aplikace vhodně funguje jen v prohlížeči Chrome, v Internet Exploreru kupříkladu nefunguje vůbec, ve Firefoxu dochází k problémům při kreslení. Po čase navíc obrazec začne podivně mizet, což pravděpodobně není zamýšlená vlastnost, ale chyba, neboť vždy mizí jen částečně a v různých místech. Někdy dokonce vůbec nedojde k zaznamenání a přenesení kresby, nestane se nic. Rychlost přenosu mezi uživateli je velmi pomalá a značně kolísající. Aplikace je reálně nepoužitelná, především z důvodu nespolehlivosti. Splněné funkční požadavky


Textový chat

ne

Technologie

HTML5


ne

Odezva

1–6s


ne

Okamžik přenosu

po dokreslení


ne

Obsah plochy

bitmapa

Export do souboru

ne

Identifikace autora

ne

Poznámky -

2.6.2.7 FlockDraw Jednoduchá aplikace, která nenabízí moc možností, funguje především jako sdílené malování. Obsah kreslící plochy je bitmapový, nelze tedy dodatečně s kresbami manipulovat, lze je jen překreslit či vygumovat. Prostředí působí mírně amatérsky, plocha je relativně malá a navíc obklopená rušivými reklamami. Úvodní synchronizace při připojení uživatele je pomalá, nicméně samotná odezva při kreslení je velmi dobrá. Aplikace zaujme pouze okamžitým přenosem kreslení včetně kurzoru se jménem uživatele, snad také stabilní odezvou a kompatibilitou mezi prohlížeči. Nedisponuje ale prakticky ničím, co by se dalo využít v business prostředí. Není vyžadována registrace nebo přihlašování, počet uživatelů v jedné relaci je neomezený, kreslit jich najednou může až deset. 25



Textový chat

ano

Technologie

Flash


ne

Odezva

0,5 – 1 s


ne

Okamžik přenosu

ihned (i kurzor)


ano

Obsah plochy

bitmapa

Export do souboru

ano*

Identifikace autora

ano

Poznámky * obsah plochy lze uložit jako obrázek ve formátu PNG, ten ale není automaticky stažen do uživatelova PC, je publikován na webu

2.6.2.8 Groupboard Aplikace s přehledným a snadno použitelným prostředím, které nevypadá nijak výjimečně, ale plní přesně to, co se od něj očekává. Nástroje jsou jasně uspořádány, lze vidět, kolik a jací uživatelé jsou připojeni, kdo a co zrovna kreslí. Plocha je v základním provedení malá, lze ji však přepínat mezi několika velikostmi, včetně režimu celé obrazovky. Prakticky se mění pouze velikost zobrazení, pokud je něco nakresleno mimo hranice malé plochy, tak to na ní nelze vidět, lze to vidět ale na ploše větší. Odezva je přijatelná, a to 1 až 2 sekundy. V ukázkové variantě lze přepínat mezi verzí napsanou v HTML5 a Java appletem. Disponuje také možností uložit plochu v nějakém stavu přímo na server, nebo ji zase z uloženého stavu načíst. Při použití bezplatné varianty lze uchovávat až 20 stavů. Jsou nabízeny tři placené varianty a jedna zdarma. V bezplatné variantě může pracovat maximálně pět uživatelů na kreslící ploše, má omezené některé funkce, není potřeba registrace a zřejmě není poskytována podpora, což je očekávané. Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5 / Java


ne

Odezva

1 – 2 s*


ne

Okamžik přenosu

ihned


ano

Obsah plochy

bitmapa

Export do souboru

ne

Identifikace autora

ano

Poznámky * verze napsaná v Javě se jeví být nepatrně rychlejší a plynulejší 26

2.6.2.9 IDroo 1.0 Jedná se o plugin pro Skype, který se ale zobrazuje jako běžná desktopová aplikace. Přestože od jisté verze Skype přestalo podporovat pluginy3 a v reakci na to byl vývoj tohoto softwaru ukončen, se staršími verzemi normálně funguje a teoreticky jej lze použít i jako samostatný offline kreslící nástroj. Aplikace je velice zdařilá a nabitá funkcemi, ovládání je jednoduché, prostředí přehledné a design vyvážený. Kreslící plocha je neomezeně veliká a je možnost používat více kreslících ploch, mezi kterými jde přepínat. Plochu lze také uložit do formátu, ze kterého lze opět načíst, nebo vyexportovat jako obrázek. Tahy na kreslící ploše jsou vyhlazovány a přenášeny ihned, i když je obsah plochy objektový, což je pozoruhodné. S objekty na ploše lze velice snadno manipulovat a dále upravovat jejich tvar i barvu. Splněné funkční požadavky


Textový chat

ne*

Technologie

.NET (C#, WF)


ano

Odezva

< 0,5 s


ne

Okamžik přenosu

ihned (i kurzor)


ano

Obsah plochy

objekty

Export do souboru

ano

Identifikace autora

ano

Poznámky * textový chat je součástí Skype, aplikace jej tedy pochopitelně neobsahuje

2.6.2.10 IDroo 2.0 (idroo.com) Nová verze softwaru IDroo už není desktopovou aplikací, ale webovou. Aplikace je velice rychlá a jednoduchá na ovládání, prostředí má plochý, přehledný jednobarevný „Metro“ design, který zaujme svou jednoduchostí. Na rozdíl od verze původní má vlastní textový chat a lze vkládat soubory, bylo zachováno vyhlazování tahů na ploše a také neomezená velikost kreslící plochy. Obsah plochy je trvale ukládán na serveru.

EDELSTEIN, Noah: Feature evolution and support for the Skype Desktop API. Skype Blogs. [online]. 11. 6. 2013 [cit. 2015-07-10]. Dostupné z: http://blogs.skype.com/2013/11/06/feature-evolution-andsupport-for-the-skype-desktop-api/ 3

27

Oproti původní verzi zde chybí některé funkčnosti, například značnou nevýhodou je absence možnosti přiblížit či oddálit zobrazení, na neomezeně veliké kreslící ploše se tak lze poměrně snadno ztratit. Kreslící plocha je zde pouze jediná. Při výpadku spojení o tom není uživatel nijak informován a je mu umožněno dále kreslit, takže prakticky není schopen zjistit, že jej ostatní uživatelé nevidí. Pro používání je třeba se zdarma registrovat, nebo přihlásit některým z Facebook, Google nebo Windows Live účtu. Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5


ano

Odezva

< 0,5 s


ano

Okamžik přenosu

ihned (i kurzor)


ano

Obsah plochy

objekty

Export do souboru

ano

Identifikace autora

ano

Poznámky -

2.6.2.11 iScribble Jedná se o kooperativní online nástroj spíše umělecky nebo volnočasově zaměřený s vizuálně zastaralým a chudým prostředím, které připomíná IRC klienta s přidanou kreslící plochou. Plocha je navíc docela malá. Nezvykle se ale skládá ze tří vrstev, kde si uživatel může vybrat, do které vrstvy kreslí a které vrstvy se zobrazují, rovněž je lze mezi sebou slučovat. Aplikace je i přes původní 8 let staré prostředí velmi využívaná různými nadšenci do kreslení, je značně rychlá a evidentně nemá žádné problémy se synchronizací i okamžitým přenosem tvorby několika uživatelů najednou. Je dostupná zdarma, vyžaduje ale registraci, ověření účtu a následně i schválení administrátorem, což se může jevit jako podstatná překážka v používání. Celé prostředí je jaksi komunitně zaměřeno, pro business použití zcela nevhodné.

28



Textový chat

ano

Technologie

Flash


ne

Odezva

< 0,5 s


ne

Okamžik přenosu

ihned


ano

Obsah plochy

bitmapa

Export do souboru

ne

Identifikace autora

ano

Poznámky -

2.6.2.12 MegaScopes Whiteboard Tato kreslící online aplikace je nejspíš demonstrací možnosti kreslit online a sdílet toto s ostatními uživateli. Prostředí aplikace je až dětské, i přesto by ale jeho použitelnost mohla být lepší. Kromě klasického kreslení křivky jsou zde ukryty nástroje pro kresbu elipsy, obdélníku, přímky a jejich variant. Jediná kresba křivky se přenáší ihned, vše ostatní až po dokončení tahu. V aplikaci vůbec nelze rozeznat, zda je k relaci připojen i nějaký jiný uživatel, pokud zrovna nepíše zprávy do chat okna pod kreslící plochou. Po otevření stránky je uživateli zobrazena veřejná kreslící plocha, která je obvykle již zaplněná různými cizími obrazci. Kliknutím na odkaz „Request a private session“ nad touto plochou je uživatel automaticky nasměrován do své vlastní relace s prázdnou kreslící plochou. Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5


ne

Odezva

0,5 – 1 s


ne

Okamžik přenosu

ihned / po dokr.


ano*

Obsah plochy

bitmapa

Export do souboru

ne

Identifikace autora

ne

Poznámky * nástroje jsou skryté, lze je zobrazit kliknutím a podržením tlačítka myši na malé šipce u některého tlačítka s barevnou křivkou, umístěného vlevo dole

29

2.6.2.13 NoteBookCast Promyšlené a funkční řešení online kreslící plochy nabízí NoteBookCast. Design prostředí je jednoduchý, snadno se v něm orientuje, je použitelný na mobilních zařízeních a obecně malých obrazovkách. Tato flexibilita ale naopak zhoršuje praktičnost na velkých displejích. Velikost kreslící plochy lze vybrat před založením relace. Kreslení křivky je přenášeno ihned, ostatní až po dokončení tahu a aplikace má překvapivě rychlou odezvu. Zajímavostí je možnost použití laserového ukazovátka, tuto funkci má jako jediná aplikace. Možné nedostatky spočívají spíše v detailech, jako je třeba malá maximální tloušťka tahu nebo omezený výběr barev. Jako nevýhoda pak může působit omezená velikost plochy, kde rozměry lze nastavit maximálně na 1200 x 800 pixelů. Pro použití není vyžadována registrace, nicméně je při zakládání nutné zadat název plochy, její velikost, jméno uživatele a volitelně popis plochy. Chce-li se připojit další uživatel, musí také nejprve zadat vlastní uživatelské jméno. To však není žádnou překážkou a naopak je to vhodné. Na webu je obsažen popis kompatibility i významných funkcí a vypadá to, že aplikace je stále dál vyvíjena. Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5


ano

Odezva

< 0,5 s


ne

Okamžik přenosu

ihned


ano

Obsah plochy

bitmapa

Export do souboru

ano

Identifikace autora

částečně*

Poznámky * momentálně kreslící uživatel je zobrazen v pravém horním rohu, není však asociován s konkrétním tahem či obrazcem

2.6.2.14 RealtimeBoard Tato aplikace se funkčně a částečně i designem podobá Conceptboard, je však o něco rychlejší a má okamžitou odezvu. Provedení je výborné, prostředí moderně vypadající, funguje dle očekávání. Velikost plochy není omezena, rozšiřuje se automaticky dle vyplnění. 30

Nebyl shledán žádný významný nedostatek, aplikace je zaměřena na business použití, není vhodná pro malování ve smyslu uměleckém nebo volnočasovém. Licencování je o něco volnější, uživatel není nucen ke koupi, bezplatná verze není nijak výrazně omezená, akorát maximální množství kreslících ploch jsou tři. Naopak verze placené disponují různými pokročilými funkcemi, jako je hlasová komunikace, videohovory, nebo sdílení obrazu. Splněné funkční požadavky


Textový chat

ano

Technologie

Flash


ano

Odezva

< 0,5 s


ano

Okamžik přenosu

po dokreslení


ano

Obsah plochy

objekty

Export do souboru

ano*

Identifikace autora

ne

Poznámky * export v placených verzích nabízí lepší rozlišení

2.6.2.15 Scribblar Výjimečná a vybavená aplikace, disponuje velkým množstvím nástrojů a funkcí. Ovládání je velmi snadné, neboť všechny nástroje jsou přehledně rozmístěny ve dvou malých panelech konzistentního designu. Odezva je velmi rychlá, akorát v případě přenosu pohybů kurzoru se jeví pomaleji. Velikost plochy zřejmě není omezena, při kreslení za roh se automaticky zvětšuje. Mezi nedostatky patří krom zpoplatnění pouze nedotažené detaily. Například nabízená funkce pro převrácení obrazce vertikálně nebo horizontálně funguje jen na některých obrazcích, přičemž na ostatních tato funkce pouze nic neprovede, místo aby upozornila uživatele, že nelze, nebo byla zcela zablokovaná. Dle nastavení lokalizace operačního systému se aplikace automaticky přepnula do českého jazyka. To by mohlo působit jako výhoda, bohužel překlad místy zcela chybí a jeho kvalita je značně nízká, vypadá to, že byl použit nějaký webový překladač. Zkušený uživatel toto bude považovat za nevýhodu. Celá aplikace je výrazně komerčně založená, pro relativně základní funkci jako je uchovávání obsahu plochy po odpojení, je nutno zakoupit licenci. Bezplatná verze obsahuje jen jednu kreslící plochu, ke které se mohou připojit maximálně dva uživatelé. I pro bezplatnou verzi je nutné se registrovat a přihlásit se. 31



Textový chat

ano

Technologie

Flash


ano

Odezva

< 0,5 s


ano*

Okamžik přenosu

po dokreslení


ano

Obsah plochy

objekty

Export do souboru

ano

Identifikace autora

ne**

Poznámky * typ souboru může být pouze PDF, PPT nebo PPTX ** lze zapnout okamžitý přenos kurzoru, obrazce jsou však zobrazeny až po dokončení tahu

2.6.2.16 Scriblink Jediná aplikace napsaná pouze jako Java applet. Prostředí se vizuálně řadí mezi průměr, ničím nezaujme, ale je dobře použitelné. Kromě kreslení lze vložit i matematické rovnice. K dispozici je 5 různých kreslících ploch, kde zobrazení plochy lze přepínat mezi dvěma velikostmi, malé a větší. Obsah stránky je obklopen dvěma reklamami, které nejenže působí rušivě, ale při přepnutí plochy na větší velikost i jedna z reklam překáží a částečně tak znemožňuje používání. Aplikace nevyžaduje žádnou registraci, přihlášení nebo zakoupení, po otevření domovské stránky je uživatel rovnou přesměrován na vlastní, prázdnou kreslící plochu. Splněné funkční požadavky


Textový chat

ano

Technologie

Java


ano

Odezva

0,5 s


ano*

Okamžik přenosu

ihned


ano

Obsah plochy

bitmapa

Export do souboru

ano

Identifikace autora

ne

Poznámky * soubory lze uploadovat a tím je nabídnout ke stažení ostatním uživatelům, to ale probíhá mimo kreslící plochu

32

2.6.2.17 Twiddla Poslední aplikace v seznamu spadá mezi průměr. Prostředí sice vypadá uhlazeně a dotaženě, jeho reálná použitelnost je ale docela špatná. Nástroje jsou rozmístěny zmatečně a některé funkce jsou neprakticky skryté. Například používání funkcí pro vkládání obrázků nebo souborů je značně chaotické. Manipulace s nástroji a kreslení na ploše je ovšem velmi rychlé, a přenos mezi ostatní uživatele trvá 1 až 2 sekundy. Obsah plochy se po odpojení z bezplatné verze neukládá a velikost plochy je sice velká, ale její hranice nejsou nijak jasné, viditelné či definovatelné. Aplikace je v základní verzi dostupná zdarma. Pro další funkce je vyžadována registrace a zakoupení licence. Splněné funkční požadavky


Textový chat

ano

Technologie

HTML5


ano

Odezva

1–2s


ano

Okamžik přenosu

po dokreslení


ano

Obsah plochy

objekty

Export do souboru

ano*

Identifikace autora

ano**

Poznámky * uložit obsah do souboru mohou pouze registrovaní uživatelé ** po dokončení tahu se na cca 3 sekundy objeví u obrazce jméno autora

33

2.7 Výsledky testování nalezených aplikací Bylo nalezeno a otestováno celkem 17 různých aplikací. Některé z nich lze označit jako profesionální nástroje, jiné jako nástroje spíše pro volnočasové zabavení, některé ostatní jako technologickou demonstraci. Mezi aplikacemi lze porovnávat velké množství uvedených i neuvedených drobných odlišností ve funkčnostech i mezi prostředími či technickým řešením. Nicméně vzhledem k malému počtu aplikací a relativně velké variabilitě by takové srovnávání detailů bylo zbytečné, neboť každá lepší aplikace určitě nabízí svým způsobem unikátní vlastnosti, které by teoreticky mohly obsahovat i aplikace ostatní, a tak by se jejich absence dala vždy považovat za nevýhodu. Což pochopitelně nedává dobrý smysl.

2.7.1 Vynechané požadavky Větší odlišnosti, respektive takové, které stojí za to zmínit, ačkoliv aplikace dle nich nebyly srovnávány, jsou uvedeny v následujícím krátkém výčtu. Tyto vlastnosti byly zaznamenány až během samotné analýzy jednotlivých aplikací. -

více než jedna kreslící plocha v jedné relaci

-

velikost kreslící plochy

-

zobrazení historie kroků a možnost učinit krok zpět, případně vpřed

-

funkce copy+paste na kreslící ploše

-

možnost vrátit se k dříve vytvořenému obsahu (ukládání na serveru, apod.)

Další rozdíly, které jsou však s ohledem na tuto práci méně relevantní, se týkají registrace, přihlašování uživatele a zpoplatnění. Pro uživatele je jistě výhodné, když se nemusí registrovat, neustále přihlašovat a stejně tak když může aplikaci neomezeně využívat zadarmo.

2.7.2 Seskupení požadavků Zjednodušením a seskupením všech výše uvedených požadavků je vytvořen seznam, dle kterého lze reálně, z pohledu nově příchozího uživatele stanovit určitou užitečnost a teoretickou žádanost aplikace. Lze se tedy zaměřit na dále uvedený výčet pozitivních vlastností.

34

-

snadná použitelnost a atraktivní design grafického prostředí

-

velké množství dostupných funkcí

-

dobrá odezva, rychlost a spolehlivost přenosu

-

očekávatelné chování v nestandardních, chybových situacích

-

trvalé ukládání obsahu kreslící plochy

-

bezplatnost, snadné první spuštění

-

kontinuální podpora aplikace (aktualizace, vývoj)

Striktní aplikací tohoto seznamu na nalezené aplikace dojde prakticky k vyřazení všech. Žádná aplikace není dokonalá, a když už má k dokonalosti blízko, tak je řádně zpoplatněná. Volnějším přístupem, vyloučením zcela nevhodných aplikací a takových, které se rozhodně nehodí pro použití jako pracovního nástroje, zůstává následujících pět, respektive šest aplikací. Tyto lze mezi svými alternativami považovat za velice kvalitní nástroje. -

Conceptboard

-

IDroo 1.0, 2.0

-

RealtimeBoard

-

Scribblar

-

Twiddla

Za samostatnou zmínku stojí dvojice aplikací IDroo 1.0 a IDroo 2.0, kde novější verze je dostupná pouze ve webovém provedení. Obě mají dobře zpracovaná prostředí, disponují všemi možnými praktickými funkcemi, které patří k „elektronickému whiteboardu“, jsou stabilní a zcela zdarma. Je politováníhodné, že desktopová verze již není vyvíjena, byť i jako samostatný produkt, tedy bez nutnosti používat Skype. Disponuje více funkcemi, které verze 2.0 nemá a z důvodu složitosti implementace pro webový prohlížeč, je možná ani mít nebude. Také prostředí je diskrétnější a působí profesionálněji, lépe se ovládá a lze jej použít i offline. Ze seznamu analyzovaných aplikací je mimo jiné zřejmé, že v současnosti neexistuje

žádná

aktualizovaná

a

veřejné

v desktopovém provedení.

35

dostupná

obdoba

whiteboardu,

3 VIZE VLASTNÍHO ŘEŠENÍ Vizí je tedy aplikace, co slouží jako textový i kreslící chat, kde v případě kreslícího prostředí může být toto rozšířeno jednak o různé pokročilé kreslící nástroje, ale také o další funkčnosti, jako vkládání obrázků či souborů a tedy jejich přenos a sdílení. Aplikace by měla disponovat příjemným designem, který půjde vhodně využít jak v pracovním, tedy velkém formátu, tak i formátu kompaktním. Prostředí by mělo být srozumitelné a jednoduché, nebýt přílišně přebarvené a odezva by měla být taková, aby nebyla uživateli jakkoliv na obtíž. Před dalším návrhem je potřebné učinit několik zásadních rozhodnutí. Mezi ty patří, pro koho bude aplikace určena, jakou bude mít síťovou architekturu a zda bude desktopová či webová.

3.1 Cílová skupina První, podstatnou volbou je, k čemu, respektive komu by měl takový software sloužit, tedy kdo je cílová skupina uživatelů. To hraje významnou roli jak v návrhu aplikace ze strany uživatelského rozhraní, tak i obslužného kódu, konkrétněji třeba zabezpečení komunikace. Uvažované možnosti byly shrnuty do dvou. -

firemní uživatelé, aplikace tedy nabízí funkce pro použití v business prostředí, je v rámci možností zabezpečená, kreslící plocha je spíš plochou pracovní

-

domácí či graficky zaměření uživatelé, aplikace je tedy orientovaná na malování a související funkčnosti pro práci s bitmapovou grafikou

Jistě by se mohlo jevit nejlépe, kdyby byla aplikace dobře využitelná v rámci obou zmíněných skupin. Možnosti obou lze do určité míry zkombinovat, jenže to nemusí být vždy žádoucí. Obecně řečeno, domácímu uživateli mohou některé business prvky používání softwaru zbytečně komplikovat, firemnímu zase mohou ty věci, určené pro domácí uživatele překážet nebo působit na jeho okolí značně neprofesionálně. Konkrétnější rozdíly se především v praxi týkají poskytované podpory, zpoplatnění a licencování. To je však pro tuto práci irelevantní, není třeba se tím dále zabývat. Mezi ty rozdíly, co reálně ovlivňují další vývoj aplikace, spadá například výchozí nastavení prostředí, obsah kreslící plochy (bitmapa nebo objekty), zabezpečení a šifrování komunikace, síťová architektura a úroveň logování.

36

Pokud jde o nastavení prostředí, zabezpečení a úroveň logování, lze tyto vlastnosti naimplementovat pro firemního uživatele a zpřístupnit je takovým způsobem, že to případného domácího uživatele vůbec nemusí žádným výrazným způsobem obtěžovat. Obsah kreslící plochy pouze jako bitmapa je značně omezující a prakticky vylučuje použití jako plochy pracovní, kam půjdou vkládat obrázky, soubory, kreslit schémata a poté s nimi manipulovat. Plocha obsahující objekty však nevylučuje možnost použití bitmapy, jakožto vykreslený obsah, například právě pro okamžitý přenos kreslení. Nevýhodou objektů je nemožnost použití pokročilejších nástrojů pro malování, například možnosti typu rozmazání či rozostření, neboť by jejich implementace byla velice náročná. Nicméně výsledná aplikace nemá být určena jako náhrada profesionálních kreslících nástrojů typu Adobe Photoshop, takže je upřednostněn objektový obsah kreslící plochy.

3.2 Síťová architektura aplikace Před vymezením síťové architektury v tom správném slova smyslu je potřeba zmínit, že o architektuře rozhoduje to, kde bude software používán, tedy zda především na lokálních sítích, nebo snad online (přes internet). Aby toto bylo jasnější, je níže uveden výčet možností spadajících pod oba zmíněné typy sítí. Uspořádání vhodné pro lokální síť (LAN): 1. klient – server 2. klient – klient (spojení typu peer-to-peer) Uspořádání vhodné pro internet (WAN): 1. klient – server, k tomu veřejný master server poskytující seznam serverů 2. klient – virtuální server (jeden server, na kterém běží všechny relace) 3. klient – klient, k tomu proxy server, který klienti používají jako mezičlánek Architektura typu klient – klient neboli peer-to-peer, s sebou v obou případech nese řadu nevýhod. Pro programátora je to především náročné řešení správné synchronizace všech klientů a také způsob, jakým se připojí nový klient do již započaté relace. Rovněž distribuce objemnějších dat jako souborů se může jevit problematicky.

37

Nutnost implementace specializovaného proxy serveru, který by zajistil vzájemné nalezení a komunikaci klientů, v případě použití této architektury v rámci internetu, je oproti zmíněným problémům relativně nepodstatná věc. Dále je zde architektura klient – virtuální server. Jedná se o to, že klienti nevidí žádné servery, ale pouze relace, které všechny běží u jednoho poskytovatele, na jednom nebo více strojích (clusteru). Příchozí klient si pak může založit novou relaci, ke které se budou připojovat klienti další. Tato možnost se docela vylučuje s použitím softwaru v rámci lokální sítě třeba v prostředí firmy, neboť by jednak celá funkčnost softwaru závisela na stabilní konektivitě ze strany klienta, jednak na dostatečně dimenzovaném serveru, kde by muselo být vhodně vyřešeno zálohování dat pro případ selhání či výpadku. Také by mohlo být problémem zajištění dostatečné bezpečnosti dat vůči zneužití. S ohledem na požadavek přenosu souborů by bylo neefektivní, kdyby se přenos mezi několika uživateli, kteří se nacházejí na stejné síti, prováděl přes internet zpět na lokální síť. Zbývá tedy klasická architektura klient – server. Mezi nevýhody by se dalo zařadit obtížnější použití běžnými uživateli, kde v případě neexistence serveru je potřeba nejprve server založit, a to méně zkušeným uživatelům nemusí být zřejmé. To však lze do jisté míry zjednodušit dostatečně přívětivým uživatelským prostředím. Jedním z častých problémů také je, že uživatel nedisponuje veřejnou IP adresou a nemá tedy možnost založit server v rámci internetu, ale pouze na lokální síti. Případně naráží na striktně nastavený firewall poskytovatele internetového připojení. Toto lze do jisté míry vyřešit například podobně jako v případě architektury peer-to-peer, a sice pomocným serverem dostupným na internetu, který bude mezi klienty pouze přeposílat data. Tato síťová architektura se jeví jako nejvhodnější volba. Aplikaci lze správnými zásahy přizpůsobit tak, ať působí profesionálním dojmem a je tedy vhodná pro firemní použití, ale ať disponuje i příjemným prostředím s jednoduchou ovladatelností a je tedy použitelná také pro domácího uživatele. Další případná rozhodování však budou směřovány ve prospěch aplikace určené pro firemní použití.

38

3.3 Typ aplikace Poslední uvažovanou, neméně důležitou volbou je, zda se bude jednat o desktopovou nebo webovou aplikaci. Krom relativně značně vzájemně odlišných možností těchto typů aplikací, pochopitelně rozdílného návrhu a vývoje, jde ve výsledku o to, na jaké platformě je možné takovou aplikaci používat.

3.3.1 Výhoda webové aplikace Webová aplikace se může jevit jako univerzální a moderní řešení, které lze spustit a používat na kdejakém zařízení. Výhodou je tedy jistě multiplatformita. Aplikaci postavenou na rozumné technologii by tedy bylo možné bez citelných omezení používat jak na operačních systémech Windows a OS X, tak i různých Linuxových distribucích, kde je dostupné grafické prostředí a další potřebný software. S vhodnými úpravami by ji šlo používat i na mobilních zařízeních typu tablet nebo smartphone. Další podstatnou výhodou takové aplikace je to, že uživatel se o ní nemusí prakticky starat. Nemusí ji instalovat, aktualizovat či odinstalovat, pouze přistupuje k hotové věci. Část systémových prostředků, především tedy úložiště, je využíváno pouze na serveru, nezatěžuje tedy klientovo zařízení. Dle poznatků nasbíraných při analýze výše uvedených aplikací, by tedy aplikace mohla být postavena na technologii HTML5 a souvisejících, na platformě Adobe Flash, na frameworku Microsoft Silverlight, nebo jako Java applet.

3.3.2 Výhoda desktopové aplikace Je-li od aplikace očekávána jistá rychlost a spolehlivost, kompaktnost uživatelského rozhraní a možnost práce offline, je desktopové řešení velmi vhodné. Výhod je, co se týká návrhu tohoto konkrétního softwaru, pouze několik, avšak důležitých. Jednou z nich je lepší práce se soubory, kde webové aplikace mají z bezpečnostních důvodů obvykle zakázáno zasahovat do souborů uživatele. Dále možnost přístupu k užitečným systémovým funkcím a vlastnostem, relativně neomezený přístup k síťovým prostředkům a nezávislost na přílišně předimplementovaném prostředí. Rovněž absence různých funkcí typických pro webové prohlížeče, které jsou v tomto případě nadbytečné anebo nepoužitelné.

39

Možností ze strany softwarových technologií, na kterých může být desktopová aplikace postavená, je teoreticky celá řada. Prakticky se výběr liší a zužuje dle cílové platformy, tedy zda bude aplikace od začátku multiplatformní, nebo bude-li cílená na konkrétní operační systém. Pro nejrozšířenější desktopový operační systém Windows v současných verzích je obvykle použita některá z technologií .NET, C/C++, Java, Qt nebo Adobe Air4.

3.3.3 Volba desktopové aplikace nebo webové aplikace Ačkoliv se toto může jevit jako kontroverzní volba, je potřeba uvažovat racionálně a vyhnout se neopodstatněným závěrům. Rozhodnutí závisí především na kladených požadavcích na tento software a také množství konkurenčních aplikací. Z požadavků a předchozího textu lze odvodit, že je kladen důraz na uživatelské rozhraní. To by mělo být schopné se přizpůsobit uživateli tak, jak jej zrovna vyžaduje. Lze uvažovat dvě rozhraní, mezi kterými půjde přepínat. Jedno rozhraní bude pracovní, tedy velké a druhé kompaktní. Právě pro kompaktní rozhraní není webový prohlížeč nejvhodnější, neboť si s sebou vždy ponese adresní řádek, navigační tlačítka a různé lišty. Minimalizace do tray ikony a přidání vlastního menu k této ikoně je pak už zcela nemožné, stejně jako případná upozorňující popup okna mimo prohlížeč. Některé tyto věci lze do jisté míry zrealizovat nebo se jim vyhnout, nicméně to není vždy stoprocentní, hlavně co se týká kompatibility mezi různými prohlížeči. Spoléhat na to, že uživatel vždy používá moderní webový prohlížeč konkrétní verze, s povolenými popup okny, zapnutým JavaScriptem, zapnutými Cookies a třeba i nainstalovaným Flash Playerem, je značně omezující. Rovněž rozdíly v kvalitě a schopnostech jednotlivých prohlížečů jsou i dnes nezanedbatelné. Optimalizace pro spolehlivou funkci v co nejvíce verzích bývá časově náročná, neekonomická a programátora pouze obtěžuje. Po optimalizaci a uplynutí nějakého času, ale často nastane v prohlížeči změna taková, že se začne chovat jinak a tím způsobí v aplikaci problémy. V ten moment je nutné provádět další a další úpravy.

KOWALCZYK, Krzysztof: Which technology for writing desktop software? Krzysztof Kowalczyk (blog). [online]. 5. 12. 2010 [cit. 2015-05-07]. Dostupné z: https://blog.kowalczyk.info/article/7ez5/Whichtechnology-for-writing-desktop-software.html 4

40

Podstatným aspektem je i to, že vývoj veškerého pohyblivého a dynamického kontextu v prohlížecích je v jazyce JavaScript, případně v nějaké nadstavbě, která je ale opět vytvořená v JavaScriptu. Tento jazyk byl původně určen pro tzv. dynamické HTML, tedy pro změnu kódu stránky ze strany uživatele a tím určité rozpohybování, ve smyslu změny barvy textu, pozadí, zobrazení obrázku či skryté části stránky, a vytváření jiných efektů či pomocných funkčností. Tím s sebou nese možná určitou jednoduchost pro programátory laiky, obzvláště v případě, když chtějí realizovat některou zmíněnou „dynamickou vlastnost“. Nicméně pro použití jako základ sofistikovaného systému se tento jazyk jeví jako problematický. Lze uvést několik konkrétních, trvalých nedostatků: -

málo datových typů a práce s nimi není dostatečně jednoznačná a striktní

-

pochybné a funkcemi nedostatečné OOP

-

nekompiluje se

-

zcela chybí jakékoliv předpřipravené knihovny se standardními funkcemi

-

možnost zobrazit a teoreticky i modifikovat zdrojový kód uživatelem

-

obtížný debugging

Rozdílnou podporu ve webových prohlížečích asi nemá smysl dále rozvádět. Tato se ale rovněž mění s novými verzemi, kde ne vždy k lepšímu. Mimo realizaci v jazyku JavaScript je vhodné zmínit i nepříliš častou možnost, a to je aplikace jako plugin do webového prohlížeče. Obvykle se jedná o speciální balíček nebo knihovnu, která webový prohlížeč rozšíří o patřičné funkce. Tím lze teoreticky rozšířit prohlížeč natolik, že se v určitém smyslu bude dát spojit to dobré z desktopové aplikace s výhodami prohlížeče jako takového. Jednu konkrétní realizaci, byť se jedná o značně odlišnou business doménu, lze zmínit, je tím online hra Quake Live. Tato hra byla oficiálně vydána roku 2010 jako port z původního desktopového provedení do webového prohlížeče ve formě pluginu. Funkčnost byla zajištěna pod prohlížeči Internet Explorer, Firefox, Safari a později i Chrome. Už po třech letech ale bylo rozhodnuto o návratu zpět na desktopového klienta5.

QUAKE LIVE Standalone Game. QUAKE LIVE Forums. [online]. 7. 11. 2013 [cit. 2015-07-10]. Dostupné z: http://www.quakelive.com/forum/showthread.php?34313 5

41

Jak uvedeno, vývojáři webového prohlížeče Chrome ukončili podporu NPAPI6 a obdobně vývojáři Firefoxu konstatovali, že pluginy tohoto typu jsou nežádoucí zastaralá technologie, a omezili jejich používání. Shrnutí zmíněných vlastností, výhod i nevýhod obou řešení je uvedeno v následující srovnávací tabulce č. 5. Tabulka 5: Porovnání některých nedostatků webového a desktopového řešení

Vlastnost

Desktop

Web

Podpora napříč různými operačními systémy

-

+

Považováno za moderní řešení dostupné i v mobilních zařízeních

-

+

Dostupnost aplikace „world-wide“ bez potřeby instalace

-

+

Netřeba distribuovat nové verze klientům při upgrade

-

+

Snazší vývoj, testování a debugging

+

-

Dostupnost předpřipravených oficiálních knihoven a funkcí

+

-

Lepší ohebnost uživatelského rozhraní

+

-

Nižší odezva, snazší a přímočařejší práce se sítí a prostředky OS

+

-

Nezávislost na softwarových produktech třetích stran (a netřeba kontinuálně testovat, přizpůsobovat se, vydávat upravené verze)

+

-

Lepší standardní bezpečnost a odolnost proti vandalismu

+

-

Netřeba dalších prostředků pro hostování nezbytného web serveru, webových služeb a dalších souvisejících technologií

+

-

Málo konkurenčních aplikací pro stejnou platformu7

+

-

Z tabulky je patrné, že kvalitní desktopová aplikace by měla mít vůči webovému řešení řadu technologických výhod, kde webová aplikace hraje spíš na určitou bezúdržbovost a snadnou dostupnost ze strany uživatele. Pro další analýzu, design a vývoj je i z výše popsaných důvodů zvoleno řešení v podobě desktopové aplikace.

6 7

NPAPI je platformově nezávislé rozhraní pro pluginy, používané některými webovými prohlížeči Platí jen v případě této konkrétní řešené aplikace, určené pro přenos kreslící plochy mezi uživateli

42

3.4 Shrnutí vize Pro účely této práce a vzhledem k absenci existujícího funkčního řešení, je preferována desktopová aplikace. Od tohoto provedení je očekáváno spolehlivé a přívětivé uživatelské rozhraní, rovněž i efektivní využití funkcí operačního systému, které by v případě webové aplikace nemusely být vůbec dostupné. S variabilnějším prostředím lze realizovat i možnost přepínání mezi více způsoby zobrazení, které jsou navrženy dva. Díky těmto by měla aplikace zajistit dostatečný komfort jako pracovní nástroj (tedy nejspíše velké, pracovní rozpoložení) a rovněž pro vedlejší používání, například pro pouhý textový chat s ostatními. Jako síťová architektura bude postačovat standardní klient – server s vhodně přizpůsobeným prostředím tak, aby uživatel laik nepotřeboval vědět, co je to server a jak jej nejlépe nastavit.

43

4 ANALÝZA VLASTNÍHO ŘEŠENÍ Softwarovou analýzou se rozumí sestavení logického modelu, který je schopen popsat aplikaci nezávisle na technologiích následně použitých při vývoji. Analýza tedy popisuje, jaké jsou požadavky na aplikaci, jací aktéři budou s aplikací interagovat, s jakými objekty bude aplikace pracovat a jaké jsou vztahy mezi těmito objekty. Kvalitní analýza je základem pro úspěšný proces vývoje softwaru.

4.1 Funkční požadavky Seznam funkčních požadavků je obecný a do určité míry zjednodušený souhrn toho, co by aplikace měla umět, tedy co by měla uživateli či uživatelům poskytovat za funkčnosti. Následující seznam v tabulce č. 6 vychází částečně z požadavků uvedených v kapitole 2 a ze zkušeností získaných analýzou existujících aplikací. Byl vypuštěn požadavek na zobrazení identifikace aktuálně kreslícího uživatele. Další komplexní popis následuje v kapitole zabývající se Use-Case modelem. Tabulka 6: Seznam funkčních požadavků

ID

Popis

FW01

uživateli je zobrazen whiteboard, který lze konfigurovat (velikost, barva, aj.)

FW02

na whiteboard lze kreslit a vkládat objekty (útvary, obrázky, soubory, aj.)

FW03

obsah whiteboardu je sdílen a přenášen mezi připojenými uživateli

FW04

lze změnit styl kreslení (nástroj, barva, tloušťka čáry, výplň, případně další)

FW05

lze různě manipulovat s obrazci na whiteboardu (posun, odstranění, aj.)

FW06

obsah whiteboardu lze uložit a znovu jej načíst, nebo exportovat jako obrázek

FC01

uživateli je zobrazeno rozhraní pro textovou komunikaci, včetně již proběhlé (případně i archivní) komunikace

FC02

uživatel může odesílat zprávy a přijímá zprávy od ostatních, zprávy jsou tedy přenášeny mezi připojenými uživateli

FA01

uživatel může založit nebo se připojit k relaci (může ji vyhledat nebo zadat adresu), pochopitelně taky může relaci ukončit nebo se odpojit

FA02

stav relace lze uložit a později obnovit

FA03

relace má své parametry, kde některé se zadávají při zakládání, jako jméno a vstupní heslo, dalšími jsou např. datum a čas založení, počet připojených uživatelů, odezva, IP adresa a port, aj.

FA04

uživatel vidí, kdo další je k relaci připojen a v případě, že je zakládající, má kontrolu nad ostatními uživateli

FA05

uživatel si volí vlastní jméno či přezdívku

44

4.2 Nefunkční požadavky Tyto požadavky, jak je z názvu patrné, se nezabývají tím, co má systém nabízet za funkce uživateli, ale tím, jakým způsobem tyto funkce budou realizovány. Nefunkční požadavky lze obvykle kategorizovat dle systému FURPS+8 na 4 dané skupiny a jednu rozšiřující, zahrnující ostatní požadavky či další skupiny požadavků. Popis kategorií je pro přehlednost uveden i v následující tabulce č. 7. Tabulka 7: Kategorie nefunkčních požadavků

Zkratka

Význam (EN)

Význam (CS)

Popis

U

Usability

Použitelnost

Konzistence a estetika uživatelského rozhraní, dokumentace

R

Reliability

Spolehlivost

Četnost a závažnost chyb, stabilita, přesnost, dostupnost, doba zotavení

P

Performance

Výkonnost

Odezva, efektivita, datová propustnost, spotřeba výkonu

S

Supportability

Podporovatelnost

Testovatelnost, rozšiřitelnost, flexibilita, lokalizovatelnost

+

Other

Ostatní

Další nefunkční požadavky

V případě této práce se nejedná o nijak rozsáhlý software či dokonce informační systém, není tedy vyloženě nezbytné řešit tuto kategorizaci do detailu, například rozšířením o další skupiny nefunkčních požadavků. Konkrétní nefunkční požadavky a zařazení do skupin tedy uvádí tabulka č. 8 níže. Tabulka 8: Seznam nefunkčních požadavků

ID

Popis

Skupina

NU01

prostředí nabízí jak pracovní, tak i kompaktní rozhraní, mezi kterými je možno přepínat

U

NU02

zobrazení textového chatu je volitelné, tuto komponentu a její součásti lze při nevyužívání skrýt

U

NU03

možnost omezené funkčnosti i v offline režimu

U

NU04

rozhraní aplikace je kompatibilní s displeji menších rozlišení, mělo by být použitelné na 1024 x 600 (tímto disponují některé netbooky)

U

NU05

zakládané relace jsou ve výchozím stavu zabezpečeny heslem

U

EELES, Peter: Capturing Architectural Requirements. IBM developerWorks. [online]. 15. 11. 2005 [cit. 2015-07-10]. Dostupné z: http://www.ibm.com/developerworks/rational/library/4706.html 8

45

NU06

pozice, velikosti oken a jiná nastavení prostředí jsou ukládána a při opětovném přístupu znovu obnovena/použita

U

NP01

prostředí aplikace má velmi rychlou odezvu, běžnou pro obvyklé desktopové aplikace (konkrétně např. méně než 0,5 sekundy)

P

NS01

aplikace je funkční na hardwaru a softwaru, kterým disponuje běžný kancelářský PC

S

NS02

aplikace loguje veškerá chybová hlášení a nestandardní stavy

S

NX01

aplikace je v rámci možností vyvíjena tak, aby nebyla striktně omezena na danou platformu (tedy např. ji bylo možno s relativně malým úsilím portovat z Windows na Linux/OS X)

+

NX02

aplikace nevyužívá žádných komerčních komponent či knihoven

+

NX03

síťová komunikace bude probíhat pomocí TCP, případně UDP

+

46

4.3 Strukturální model 4.3.1 High-level pohled Znázornění základní struktury aplikace je zaneseno na obrázku 1 níže. Z něj je zřejmé, že uživatelé přistupují k relaci, která odkazuje, respektive zprostředkovává přístup ke konkrétní instanci whiteboardu, chatu a sdíleným souborům. Obrázek 1: High-level pohled na systém

4.3.2 Doménový diagram Detailnější popis struktury zachycuje doménový diagram na obrázku 2 dále. Kromě multiplicity a vztahů mezi entitami jsou zde vyznačeny i některé důležité atributy. Entity nazvané Chat a Whiteboard jsou pomocné mezivrstvy, respektive kontejnery mezi relací a jejím textovým a grafickým obsahem.

47

Obrázek 2: Doménový diagram

4.4 Seznam Use-Case Use-Case model vychází především z funkčních požadavků a zachycuje interakce mezi rolemi (aktéry) a systémem. Jako aktér může vystupovat i samotný systém, což v tomto případě může být dáno existencí serveru, který vyvolá nějakou akci u klienta (např. zobrazení nové křivky). Viz znázornění na obrázku 3 níže. Obrázek 3: Komunikace mezi aktéry a systémy

Pro přehlednost je seznam Use-Case této aplikace rozdělen na 4 skupiny, kde každá skupina obsahuje více logicky souvisejících nebo podobných případů užití. 48

Níže uvedené tabulky obsahují krom identifikátoru případu užití „ID“ a krátkého popisu také identifikátor funkčního požadavku „FP“, ze kterého daný případ užití vzešel. Dále je zde uvedena i priorita, která, především pro pozdější implementaci, udává důležitost daného Use-Case na stupnici od 1 (nejvíce důležitý) do 3 (nejméně důležitý). Mezi uvedené případy užití by se dalo uvést ještě mnohem více dalších, nebo některé rozdělit na menší, zcela elementární funkce. Nicméně v případě této, relativně malé aplikace, se takovéto zabíhání do detailů jeví jako nadbytečné. Ze seznamu Use-Case jsou rovněž vynechány potenciální budoucí rozšíření, například správa galerie obrázků, které je možné vložit na whiteboard, změna oprávnění uživatele kreslit na whiteboard nebo do jeho určitých částí, a také další možnosti manipulace s grafickými objekty.

4.4.1 Obecné funkčnosti aplikace Tabulka 9: Seznam Use-Case 1

ID

FP

Krátký popis

Aktér

UC01

FA01

Založit novou relaci

Uživatel

1

UC02

FA01

Připojit se k cizí relaci

Uživatel

1

UC03

FA01

Korektně ukončit vlastní relaci

Uživatel

1

UC04

FA01

Korektně se odpojit od cizí relace

Uživatel

1

UC05

FA02

Uložit relaci pro pozdější obnovení

Uživatel

3

UC06

FA02

Obnovit uloženou relaci

Uživatel

3

UC07

FA01

Vyhledat dostupné relace

Uživatel

3

UC08

FA05

Zvolit a uložit vlastní uživatelské jméno (alias)

Uživatel

2

UC09

FA04

Zobrazit seznam uživatelů připojených k relaci

Uživatel

2

UC10

FA04

Spravovat uživatele připojené k relaci

Uživatel

3

UC11

FW02 FW03

Přiložit (sdílet) a odeslat soubor

Uživatel

3

UC12

FW03

Přijmout přiložený soubor

Systém

3

UC13

FW02 FW03

Odstranit přiložený soubor

Uživatel

3

49

Priorita

4.4.2 Funkce whiteboardu jako celku Tabulka 10: Seznam Use-Case 2

ID

FP

Krátký popis

Aktér

Priorita

UC14

FW01 FW03

Načíst a zobrazit kreslící plochu

Uživatel

1

UC15

FW01

Změnit velikost plochy

Uživatel

3

UC16

FW01

Změnit barvu pozadí plochy

Uživatel

3

UC17

FW01 FW05

Jít o krok zpět (vrátit akci)

Uživatel

3

UC18

FW06

Uložit obsah plochy jako obrázek

Uživatel

2

UC19

FW06

Uložit obsah plochy do formátu, ze kterého půjde obnovit

Uživatel

3

UC20

FW03

Odeslat změnu obsahu plochy ostatním uživ.

Uživatel

1

UC21

FW03

Přijmout změnu obsahu plochy od ostatních uživ.

Systém

1

4.4.3 Kreslení a manipulace s objekty na whiteboardu Tabulka 11: Seznam Use-Case 3

ID

FP

Krátký popis

Aktér

UC22

FW02

Kreslit křivku

Uživatel

1

UC23

FW02

Kreslit přímku

Uživatel

2

UC24

FW02

Kreslit obdélník

Uživatel

2

UC25

FW02

Kreslit elipsu

Uživatel

2

UC26

FW02

Kreslit polygon

Uživatel

3

UC27

FW04

Změnit barvu/zobrazování čáry

Uživatel

1

UC28

FW04

Změnit barvu/zobrazování výplně

Uživatel

3

UC29

FW04

Změnit tloušťku čáry

Uživatel

1

UC30

FW04

Změnit styl čáry

Uživatel

3

UC31

FW02

Vložit text

Uživatel

2

UC32

FW02

Vložit vlastní obrázek

Uživatel

2

UC33

FW02

Vložit obrázek z galerie

Uživatel

3

UC34

FW05

Vybrat objekt

Uživatel

2

UC35

FW05

Posunout objekt

Uživatel

2

UC36

FW05

Odstranit objekt

Uživatel

2

UC37

FW05

Zkopírovat objekt

Uživatel

3

50

Priorita

4.4.4 Textový chat Tabulka 12: Seznam Use-Case 4

ID

FP

Krátký popis

Aktér

Priorita

UC38

FC01 FC02

Načíst a zobrazit komunikaci mezi uživateli

Uživatel

1

UC39

FC02

Odeslat zprávu jinému uživateli

Uživatel

1

UC40

FC02

Přijmout zprávu od uživatele

Systém

1

UC41

FC01

Zobrazit a procházet historii zpráv

Uživatel

2

UC42

FC02

Vložit nestandardní znak do zprávy

Uživatel

3

4.4.5 Podpůrné funkce serveru Tabulka 13: Seznam Use-Case 5

ID

FP

Krátký popis

Aktér

UC43

FW03

Distribuovat změnu kreslící plochy mezi uživatele

Server

1

UC44

FC02

Distribuovat textovou zprávu mezi uživatele

Server

1

UC45

FW03

Distribuovat soubor mezi uživatele

Server

3

51

Priorita

4.5 Popis Use-Case Jak je patrné ze seznamu, jako aktér ve většině evidovaných případech užití vystupuje uživatel, který aplikaci používá. Pouze v několika málo případech je aktérem systém, který aktualizuje data lokálnímu uživateli, po změně vyvolané vzdáleným uživatelem. Teoreticky by bylo možné zmínit i tohoto vzdáleného uživatele jakožto aktéra, to by ale mohlo vést k duplikaci veškerých případů užití, neboť většina akcí provedených lokálním uživatelem ovlivňuje i uživatele vzdáleného. Proto se toto jeví jako zbytečné uvádět, popis případů užití by to mohlo pouze zkomplikovat a učinit nepřehledným. Založí-li uživatel vlastní relaci, spustí tak ve skutečnosti nejprve server, ke kterému se jako klient následně připojí. Je předpoklad takové implementace a designu uživatelského rozhraní, že běžný uživatel nebude muset tento krok „připojení se k sám sobě“ činit ručně, ale bude proveden automaticky. Tento způsob připojení mu nebude muset být ani žádným způsobem oznamován, jedná se totiž o čistě technickou záležitost. Proto je u některých Use-Case zjednodušeně uvedeno, že „uživatel je připojen k relaci“, přičemž tato relace ale může být i jeho vlastní. Tabulka 14: Popis UC01

UC01 – Založit novou relaci

Priorita: 1

Aktér

Uživatel

Podm. pro spuštění

Není založena vlastní relace a není navázáno připojení k cizí relaci

Základní tok

Je zobrazen formulář pro nastavení údajů relace, uživatel vyplní potřebné informace a tlačítkem toto potvrdí. Proběhne založení relace a s tím související započetí naslouchání příchozích spojení, inicializace potřebných datových struktur a vykreslení GUI.

Alternativní tok 1

Nepodařilo se otevřít naslouchání příchozích spojení Uživatel je upozorněn vhodným hlášením, relace není založena. Zadané parametry relace jsou nedostatečné nebo neplatné

Alternativní tok 2

Stav po dokončení

Uživatel je upozorněn vhodným způsobem, relace není spuštěna, formulář se zadáním údajů zůstává otevřený. Je založena relace o zadaných parametrech, ke které se dle nastavení mohou připojit další uživatelé.

52

Tabulka 15: Popis UC02

UC02 – Připojit se k cizí relaci

Priorita: 1

Aktér

Uživatel


Není založena vlastní relace a není navázáno připojení k cizí relaci

Základní tok

Pokud uživatel dosud nezadal svoji přezdívku, je vyzván, aby ji zadal (UC08). Poté je zobrazeno okno s možností vyhledání lokálně dostupných relací (UC07) a s možností ručně zadat adresu/název relace. Po potvrzení je odeslán požadavek pro připojení na server. Pokud jej server akceptuje, je uživatel připojen k relaci, se kterou provede úvodní synchronizaci potřebných datových struktur. Ve finále dojde k vykreslení GUI a naplnění jeho obsahu.

Alternativní tok 1

Nelze se připojit k relaci (není spuštěna, uživatel je odmítnut, nebo nelze navázat spojení např. z důvodu nevhodného nastavení firewallu) Uživatel je upozorněn vhodným hlášením, není připojen k relaci, okno se zadáním/vyhledáním relace zůstává otevřené.

Alternativní tok 2

Stav po dokončení

Zadané údaje pro připojení k relaci jsou nedostatečné nebo neplatné Uživatel je upozorněn vhodným způsobem, není připojen k relaci, okno se zadáním/vyhledáním relace zůstává otevřené. Uživatel je připojen k relaci, má načtena potřebná data, vykreslené uživatelské rozhraní a dle dalšího nastavení může s relací pracovat. Tabulka 16: Popis UC03

UC03 – Korektně ukončit vlastní relaci

Priorita: 1

Aktér

Uživatel


Je založena vlastní relace

Základní tok

Uživatel je dotázán, zda chce relaci uložit a ukončit, ukončit bez uložení nebo stornovat ukončení. V případě potvrzení ukončení relace buď je, nebo není uložena (UC05), dojde k informování ostatních uživatelů o ukončení, je uzavřeno spojení a případně i uzavřena další okna GUI.

Alternativní tok 1 Stav po dokončení

Ukončení je stornováno ve zobrazeném dialogu s dotazem Relace zůstává založena a funkční. Relace je ukončena.

53


UC04 – Korektně se odpojit od cizí relace

Priorita: 1

Aktér

Uživatel


Uživatel je připojen k cizí relaci

Základní tok

Uživatel je dotázán, zda se chce opravdu odpojit od relace. Pokud ano, je odeslána tato zpráva serveru, uzavřeno spojení a případně i uzavřena další okna GUI.


Odpojení je stornováno ve zobrazeném dialogu s dotazem Připojení k relaci zůstává aktivní. Uživatel je odpojen od relace. Tabulka 18: Popis UC14

UC14 – Načíst a zobrazit kreslící plochu

Priorita: 1

Aktér

Uživatel


Uživatel se právě připojil k relaci, nebo z jiného důvodu vyžádal synchronizaci kreslící plochy se serverem

Základní tok

Je zobrazena kreslící plocha v příslušném okně, jsou zobrazeny i nástroje pro ovládání této plochy, dojde k synchronizaci potřebných datových struktur, vykreslí se obsah plochy a uživateli je umožněno s plochou dále pracovat.

Stav po dokončení

Je načten a zobrazen obsah kreslící plochy. Tabulka 19: Popis UC20

UC20 – Odeslat změnu obsahu plochy ostatním uživatelům

Priorita: 1

Aktér

Uživatel


Uživatel je připojen k relaci a provedl změnu na kreslící ploše

Základní tok

Změna je promítnuta do příslušných datových struktur uživatele a je odeslána na server (do relace).

Stav po dokončení

Změna obsahu plochy byla odeslána na server.

54


UC21 – Přijmout změnu obsahu plochy od ostatních uživatelů

Priorita: 1

Aktér

Systém


Uživatel je připojen k relaci, kde jiný uživatel provedl změnu na kreslící ploše a tuto odeslal (UC20), změnu přijal server a rozeslal ostatním uživatelům (UC43)

Základní tok

Systém přijme změnu, promítne ji do lokálních datových struktur a vykreslí ji uživateli.

Stav po dokončení

Přijatá změna obsahu plochy je promítnuta do lokálních datových struktur a vykreslena uživateli. Tabulka 21: Popis UC22

UC22 – Kreslit křivku

Priorita: 1

Aktér

Uživatel


Uživatel je připojen k relaci, je zobrazena kreslící plocha

Základní tok

Uživatel stiskem tlačítka myši na kreslící ploše a tažením nakreslí křivku požadovaného tvaru. Průběh kreslení je skrze server přenášen ostatním uživatelům. Po dokreslení, ke kterému dojde puštěním tlačítka myši, je křivka zapsána do příslušné kolekce objektů a stejně tak i tato provedená akce do kolekce akcí. Křivka je nyní automaticky vykreslována uživateli. Následně je proběhlá akce odeslána na server (UC20). Uživatel stiskl tlačítko myši na kreslící ploše, ale neprovedl tah (zůstal kurzorem na stejném místě), a tlačítko myši opět pustil

Alternativní tok 1

Stav po dokončení

V takovém případě je vykreslen bod, nebo dle zvolené tloušťky štětce malý kruh (lze předpokládat, že je štětec kulatý). Tento je zapsán do příslušné kolekce objektů a provedená akce do kolekce akcí. Bod je nyní automaticky vykreslován uživateli. Následně je proběhlá akce odeslána na server (UC20). Na kreslící plochu je zakreslena křivka nebo bod určité barvy, tloušťky, stylu, tvaru a pozice. Objekt je uložen v příslušné kolekci, provedená akce taktéž. Akce byla odeslána na server.

55


UC27 – Změnit barvu/zobrazování čáry

Priorita: 1

Aktér

Uživatel


Uživatel je připojen k relaci, je zobrazena kreslící plocha a nástroje pro kreslení

Základní tok

Uživatel pomocí nástrojového panelu zobrazí výběr barvy, kde zvolí požadovanou barvu. Má-li uživatel vybrán vhodný objekt, pak je tomuto změněna barva čáry. Vybraná barva je vhodným způsobem zapamatována tak, aby se aplikovala na následně tvořené objekty.

Stav po dokončení

Ve vhodném umístění je uživateli zobrazena aktuálně zvolená barva čáry. Případně vybraný objekt má změněnou barvu čáry. Vybraná barva je zapamatována. Tabulka 23: Popis UC29

UC29 – Změnit tloušťku čáry

Priorita: 1

Aktér

Uživatel


Uživatel je připojen k relaci, je zobrazena kreslící plocha a nástroje pro kreslení

Základní tok

Uživatel pomocí nástrojového panelu zobrazí výběr tloušťky čáry, kde vybere požadovanou tloušťku. Výběr sestává z několika předdefinovaných velikostí a umožňuje i ruční zadání tloušťky. Vybraná tloušťka je vhodným způsobem zapamatována tak, aby tuto měly následně kreslené objekty. Je zadána neplatná tloušťka čáry (není číslo, je záporné nebo příliš vysoké)

Alternativní tok 1

Stav po dokončení

V rámci implementačních možností je toto omezeno maskou, takže lze zadat pouze správná čísla. Nelze-li maska použít, je zobrazeno upozornění například formou varovné ikony vedle pole pro zadání čísla. Neplatná tloušťka není brána v potaz. Ve vhodném umístění je uživateli zobrazena aktuálně zvolená tloušťka čáry. Případně vybraný objekt má změněnou tloušťku čáry. Vybraná tloušťka je zapamatována.

56


UC38 – Načíst a zobrazit komunikaci mezi uživateli

Priorita: 1

Aktér

Uživatel


Uživatel se právě připojil k relaci, nebo z jiného důvodu vyžádal synchronizaci textových zpráv se serverem

Základní tok

Je zobrazeno textové pole se zprávami v příslušném okně, je zobrazeno i textové pole pro odesílání nových zpráv. Dojde k synchronizaci potřebných datových struktur a zobrazení proběhlé komunikace do textového pole. Založená relace je nastavena tak, že neodesílá historii zpráv

Alternativní tok 1

Do textového pole se zprávami nejsou načteny dříve odeslané/přijaté zprávy, okno bude na začátku prázdné.

Stav po dokončení

Je načtena a zobrazena proběhlá textová komunikace. Tabulka 25: Popis UC39

UC39 – Odeslat zprávu jinému uživateli

Priorita: 1

Aktér

Uživatel


Uživatel je připojen k relaci, je zobrazeno okno pro odesílání textových zpráv

Základní tok

Uživatel vybere buď konkrétního příjemce, nebo všechny připojené uživatele. Vyplní textové pole textem zprávy a stiskem tlačítka zprávu odešle. Zpráva je uložena do kolekce textových zpráv. Vybraný příjemce již není připojen k relaci

Alternativní tok 1

Stav po dokončení

Toto je vhodně ošetřeno v uživatelském rozhraní. Dojde-li přesto k pokusu o odeslání zprávy, je uživatel odesílatel informován, že příjemce již není dostupný a zpráva není odeslána. Zpráva je odeslána ostatním uživatelům relace nebo uživateli, pro kterého byla určena a je uložena v kolekci textových zpráv odesílajícího uživatele.

57


UC40 – Přijmout zprávu od uživatele

Priorita: 1

Aktér

Systém


Uživatel je připojen k relaci, kde jiným uživatelem byla odeslána textová zpráva (UC39), kterou následně přijal server a rozeslal příjemcům (UC43)

Základní tok

Systém přijme novou zprávu od jiného uživatele. Tuto zprávu vloží do příslušné kolekce textových zpráv, dle potřeby upraví do vhodného formátu a zobrazí v textovém poli se zprávami.

Stav po dokončení

Přijatá zpráva je zobrazena uživateli a uložena v jeho kolekci textových zpráv. Tabulka 27: Popis UC43

UC43 – Distribuovat změnu kreslící plochy mezi uživatele

Priorita: 1

Aktér

Server


Je založena relace a serverem byla přijata změna kreslící plochy od některého připojeného uživatele (UC20)

Základní tok

Změna kreslící plochy je odeslána ostatním aktuálně připojeným uživatelům kromě toho, kdo ji vyvolal. Akce je aplikována na stávající uložené grafické objekty. Nakonec je akce uložena do příslušné kolekce nebo kolekcí.

Alternativní tok 1

Stav po dokončení

K relaci není připojený žádný jiný uživatel Změna je pouze uložena do příslušné kolekce nebo kolekcí. Změna kreslící plochy je odeslaná ostatním uživatelům, je aplikována na stávající grafické objekty a je uložena v příslušné kolekci nebo kolekcích na serveru. Tabulka 28: Popis UC44

UC44 – Distribuovat textovou zprávu mezi uživatele

Priorita: 1

Aktér

Server


Je založena relace a serverem byla přijata textová zpráva od některého připojeného uživatele (UC39)

Základní tok

Zpráva je dle obsaženého příjemce odeslána buď tomuto konkrétnímu příjemci, nebo všem k relaci aktuálně připojeným uživatelům kromě toho, který ji odeslal. Poté je uložena do kolekce textových zpráv.


K relaci není připojený žádný jiný uživatel Zpráva je pouze uložena do příslušné kolekce zpráv. Zpráva je odeslaná příjemci nebo příjemcům a je také uložena v příslušné kolekci zpráv na serveru. 58

5 IMPLEMENTACE 5.1 Fáze vývoje Se zajištěním dostatečné pružnosti vývoje, ale i možností průběžného testování v reálných podmínkách, je navrženo rozdělení na čtyři relativně malé vývojové fáze. Tyto fáze souvisí s prioritou konkrétních případů užití, uvedených výše.

5.1.1 První fáze – prototyp První fáze se zabývá vývojem prototypu, který obsahuje, demonstruje a v podstatě i testuje zcela základní funkce, tedy základní především z implementačního pohledu programátora. Mezi tyto funkčnosti lze obecně zařadit kreslení křivky na kreslící plochu a přenos této činnosti po síti, mezi více počítači. Samozřejmě sem spadá pro tuto činnost použitelné uživatelské rozhraní a vhodné navázání spojení mezi uživateli. 

UC01 – Založit novou relaci



UC02 – Připojit se k relaci



UC14 – Načíst a zobrazit kreslící plochu



UC20 – Odeslat změnu plochy ostatním uživatelům



UC21 – Přijmout změnu plochy od ostatních uživatelů



UC22 – Kreslit křivku



UC43 – Distribuovat změnu kreslící plochy mezi uživatele Prototyp nemusí implementovat kompletní UC14, lze vynechat načítání

stávajícího obsahu plochy pro nově připojeného klienta. Prototyp se také nezabývá korektním odchytem chyb, jejich logováním či vhodnou reakcí na ně. Uživatelské rozhraní nemusí obsahovat všechny formuláře a nástroje, některé prvky mohou být vypnuty nebo nevyužity. Proces založení relace nebo připojení se k relaci lze vizuálně zjednodušit a některá nastavení obvykle volená uživatelem učinit přímo v kódu.

5.1.2 Druhá fáze Ve druhé fázi jsou doimplementovány Use-Case s nejvyšší prioritou a je dolaďována jejich funkčnost. Rovněž je dostavěno uživatelské rozhraní, a to i pro kompaktní zobrazení. Také jsou implementovány základní funkce týkající se textového chatu, tedy odesílání, příjem a zobrazování zpráv.

59



UC03 – Korektně ukončit vlastní relaci (server)



UC04 – Korektně se odpojit od cizí relace



UC27 – Změnit barvu / zobrazování čáry



UC29 – Změnit tloušťku čáry



UC38 – Načíst a zobrazit komunikaci mezi uživateli



UC39 – Odeslat zprávu jinému uživateli



UC40 – Přijmout zprávu od uživatele



UC44 – Distribuovat textovou zprávu mezi uživatele

5.1.3 Třetí fáze V této fázi jsou implementovány Use-Case se prioritou číslo 2. Jedná se o rozšíření o některé nezbytné funkce, které doplňují ty již implementované. 

UC08 – Zvolit vlastní uživatelské jméno (alias)



UC09 – Zobrazit seznam uživatelů připojených k relaci



UC18 – Uložit obsah plochy jako obrázek



UC23 – Kreslit přímku



UC24 – Kreslit obdélník



UC25 – Kreslit elipsu



UC31 – Vložit text



UC32 – Vložit vlastní obrázek



UC34 – Vybrat objekt



UC35 – Posunout objekt



UC36 – Odstranit objekt

5.1.4 Čtvrtá fáze Poslední fáze řeší zbývající Use-Case, které mají prioritu číslo 3. Týkají se operací se soubory, jako je jejich přikládání a přenos, dále také možnosti uložení a obnovení uložené relace, obecně jde o doplnění o pokročilejší funkce, jejichž implementace je předpokládána jako náročnější. 

UC05 – Uložit relaci pro pozdější obnovení



UC06 – Obnovit uloženou relaci



UC07 – Vyhledat dostupné relace



UC10 – Spravovat uživatele připojené k relaci 60



UC11 – Přiložit (sdílet) a odeslat soubor



UC12 – Přijmout přiložený soubor



UC13 – Odstranit přiložený soubor



UC15 – Změnit velikost plochy



UC16 – Změnit barvu pozadí plochy



UC17 – Jít o krok zpět (vrátit akci)



UC19 – Uložit obsah plochy do formátu, ze kterého půjde obnovit



UC26 – Kreslit polygon



UC28 – Změnit barvu/zobrazování výplně



UC30 – Změnit styl čáry



UC33 – Vložit obrázek z galerie



UC37 – Zkopírovat objekt



UC42 – Vložit nestandardní znak do zprávy



UC45 – Distribuovat soubor mezi uživatele

5.2 Použité technologie Pro implementaci byla zvolena technologie .NET Framework od společnosti Microsoft, původně v konkrétní verzi 4.0, přičemž tato verze byla zvolena jako poslední kompatibilní se stále velmi rozšířeným operačním systémem Windows XP. Tento argument se však nyní stává neaktuálním, neboť podpora Windows XP oficiálně skončila a dochází k masivnímu přechodu uživatelů na systémy novější. Ačkoliv verze 4.0 pro implementaci postačuje, nelze zcela zanedbat nové možnosti asynchronního volání metod a okrajově i opravu nedostatků a zlepšení výkonu ve verzi 4.5 či novější. Podpora pro obě tyto verze je zakotvena i v platformě Mono, aspoň co se týká pro tuto práci relevantních součástí či technologií. Uživatelské rozhraní je implementováno pomocí Windows Forms. Novější technologie pro realizaci grafického rozhraní, nazvaná Windows Presentation Foundation (dále jen WPF), tedy není použita. WPF nemá žádnou podporu v platformě Mono pro jiné operační systémy, výkonnost WPF a spotřeba systémových prostředků se může jevit jako diskutabilní9, navíc vývoj s nutností občasné práce s kódem XAML

MORRILL, Jeremiah: A Critical Deep Dive into the WPF Rendering System. Jer’s Hacks. [online]. 14. 2. 2011 [cit. 2015-05-22]. Dostupné z: https://jeremiahmorrill.wordpress.com/2011/02/14/a-criticaldeep-dive-into-the-wpf-rendering-system/ 9

61

nemusí být pro každého programátora zrovna komfortní. Tento krok může působit jako zbytečná komplikace a zhoršení výsledné kvality uživatelského rozhraní. WPF totiž umožňuje snazší zacházení s grafikou, respektive se správou a vykreslováním vlastních grafických objektů. Také nabízí větší ohebnost designu formulářů, skiny, nové ovládací prvky, animace a další možnosti, které se pro tuto aplikaci přímo nabízí. Nicméně nelze předpokládat, že by použití Windows Forms bylo výrazně omezující. Například analyzovaná desktopová aplikace IDroo verze 1.0 je taktéž postavená pouze na WF, přitom nevykazuje žádné nedostatky, aspoň tedy co se týká použitelnosti uživatelského rozhraní. Jako programovací jazyk je zvolen C#, alternativou by byl např. VB.NET, jehož syntaxe se však nemusí jevit natolik efektivní, jako v případě C#. Oba jazyky umožňují prakticky totéž a dokonce existují jednoduché webové konvertory z jednoho jazyka do druhého. Pro základní funkčnosti není nutné použít databázový systém, aplikace ukládá pouze konfiguraci prostředí a to do registrů Windows, či do konfiguračního souboru. V dalším vývoji a implementaci galerie vlastních obrázků, sady souborů nebo různých podrobnějších nastavení však bude databáze vhodná. Pro tyto účely postačí malá relační databáze, buď SQL LocalDB nebo SQLite.

5.3 Softwarová architektura Aplikace je postavena na jednoduché třívrstvé architektuře. Ta zajišťuje dostatečnou přehlednost a modifikovatelnost ze strany zdrojového kódu. Na rozšiřitelnost nemá podstatný vliv, neboť aplikace není stavěna jako komplexní informační systém (kde by například každý jeden geometrický útvar vystupoval jako samostatná komponenta) a při přidání nové funkčnosti je tedy pravděpodobně vždy nezbytná modifikace na více než pouze jedné vrstvě. Dobře nejen navržená, ale i realizovaná architektura má samozřejmě tyto případné modifikace maximálně zjednodušit a zaručit, že s přidáváním nových funkcí nebude kód nabývat na nepřehlednosti. High-level pohled na systém znázorňuje obecné uspořádání součástí aplikace a jejich kooperaci s okolím. Na obrázku 4 je šipkami vyznačen jeden iniciovaný směr komunikace, například když uživatel A pošle zprávu uživateli B.

62

Obrázek 4: High-level pohled na architekturu systému

Zjednodušená struktura jednotlivých vrstev aplikace je zachycena na obrázku 5 níže. Obrázek 5: Vrstvy architektury aplikace

Vrstvy jsou řazeny logicky, kde vrchní je prezentační, střední business logika a spodní je vrstva přenosu a dat. Za zmínku stojí oddělení síťové komunikace klienta a serveru ve vrstvě přenosu tak, aby byl server mohl samostatně obsluhovat více 63

připojených klientů a také, aby byla implementace serveru vhodně oddělitelná pro budoucí server jako stand-alone aplikaci. Na komunikaci mezi vrstvami či vlákny, která je vyvolána například příchozími daty ze serveru, jsou použity eventy.

5.3.1 Prezentační vrstva Vrstva, se kterou přijde uživatel do styku, je postavena na obvyklé formulářové logice Windows Forms patřící pod .NET Framework. Jsou použity standardní vizuální komponenty z namespace System.Windows.Forms, přičemž pro whiteboard je použita komponenta PictureBox. Tato ve výchozím stavu disponuje double bufferingem10, který zajišťuje korektní zobrazování obsahu i při kreslení. Whiteboard s obslužnými funkcemi je vyčleněn do svého user controlu, aby bylo možné jej znovupoužít na pracovním či kompaktním zobrazení aplikace. Veškeré formuláře spadají pod společný namespace, který simuluje prezentační vrstvu. Konkrétní funkčnosti, které tato vrstva implementuje, se týkají čistě jen vykreslování uživatelského rozhraní. Tedy zobrazení formulářových oken, menu, nabídky nástrojů pro kreslení, textových polí pro chat, dalších formulářů pro přenos souborů či nastavení aplikace, a tak podobně. Většinu těchto věcí, co se týká korektního vykreslování, interaktivity a naplnění přednastavenými hodnotami, zajišťuje již sám .NET Framework, respektive Visual Studio je schopno vygenerovat kód designu, tedy prezentační vrstvy, z části automaticky.

5.3.2 Vrstva business logiky Obsluha logiky je rozdělena na tři skupiny souvisejících funkcí, kde jedna obsluhuje whiteboard, druhá textový chat a třetí řeší ostatní, sdílené funkce. 5.3.2.1 Whiteboard logika Jedná se o velmi podstatnou část celé aplikace, která zajišťuje manipulaci s grafickými objekty. Protože kreslící plochu je nutné opakovaně překreslovat, musí mít metoda obsluhující překreslení dostupná data, dle kterých tak lze učinit. Tato data jsou tedy zahrnuta v kolekci grafických objektů, přes které se iteruje, a postupně se tyto objekty vykreslují. Uspořádání objektů v kolekci teoreticky odpovídá vrstvení, tedy objekt umístěný na nižším indexu se vykreslí jako první, takže bude v nižší vrstvě, než později STEPHENS, Rod: Use double buffering to prevent flicker in a PictureBox in C#. C# Helper. [online]. 7. 11. 2014 [cit. 2015-07-08]. Dostupné z: http://csharphelper.com/blog/2014/11/use-doublebuffering-to-prevent-flicker-in-a-picturebox-in-c/ 10

64

vykreslený objekt s vyšším indexem. Kromě vykreslování je tato kolekce využita i pro úvodní synchronizaci, když se uživatel připojí k relaci, pro synchronizaci když dojde k výpadku spojení, ale také pro uložení relace do souboru pro pozdější obnovení. Tímto však nejsou pokryty akce, které mohou uživatelé na kreslící ploše provádět. K těm patří již několikrát zmíněné nakreslení křivky, dále posun, odstranění, změna barvy čáry nebo výplně. V budoucím rozšíření mohou přibýt další manipulace, jako například změna velikosti či rotace. Sledování těchto uživatelem prováděných akcí je velmi podstatná, až kruciální funkce, která jednak zajišťuje možnost přejít o krok zpět či vpřed, ale především umožňuje snadno přenášet provedené akce mezi uživateli a tak udržovat kreslící plochu aktuální. Bez záznamu akcí by se vždy musela přenášet celá kolekce grafických objektů a hledat mezi ní rozdíl oproti lokálnímu stavu, nebo by se muselo různě dopočítávat, co má server vlastně odeslat ostatním. Pro toto sledování akcí tedy slouží druhá kolekce, kde se jako vhodná datová struktura může jevit zásobník. Nicméně u samotného zásobníku by nastal problém s funkcí krok vpřed, neboť po odebrání akce krokem zpět by již tato akce byla trvale vzata zpět a zahozena. K tomuto účelu bude v dalším rozšíření aplikace použitý ještě druhý zásobník, který bude udržovat seznam zpět vzatých akcí. Samotné provádění operací krok zpět a vpřed lze efektivně implementovat například s pomocí návrhového vzoru Command, nebo vzoru Memento11. U akcí je rovněž nezbytné rozlišovat, který uživatel ji provedl a dle toho mu dovolit či odepřít tuto akci vzít zpět. To je realizovatelné více odlišnými způsoby, tedy odlišnými v tom smyslu, že i výsledek, se kterým bude přímo nebo nepřímo pracovat uživatel, se bude lišit. Obecně lze toto rozdělit na dva vhodné způsoby řešení, které mohou mít různé podvarianty. Společná kolekce akcí První způsob je takový, že všichni uživatelé mají společnou, respektive vzájemně sdílenou stejnou kolekci provedených akcí. Každá akce má u sebe mimo jiné zaznamenáno, který uživatel ji vyvolal, a tyto akce jsou v kolekci uspořádány podle toho, v jakém pořadí byly provedeny. Tím však při jednoduché implementaci dojde RAZAN, Paul: Multilevel Undo and Redo Implementation in C#. CodeProject. [online]. 17. 2. 2009 [cit. 2015-07-09]. Dostupné z: http://www.codeproject.com/Articles/33371/Multilevel-Undo-and-RedoImplementation-in-C-Part 11

65

k tomu, že například krok zpět vezme zpět akci jiného uživatele, a to nejspíše jeden či druhý uživatel nemusí očekávat. Výsledek, z čistě logického hlediska, je ale správný a předvídatelný. Vlastní kolekce akcí pro každého uživatele Druhá varianta řešení, jak může vyplývat z popisu varianty první, je, že každý uživatel má vlastní kolekci provedených akcí. To se na první pohled může jevit velice efektivní, ale není tomu tak docela. Zásadní problém nastane, dojde-li k interakci s nějakým objektem střídavě od více uživatelů. Například uživatel A nakreslí kružnici, uživatel B ji přesune doprava. Následně ji původní uživatel A přesune nahoru. Zaznamenané akce obou uživatelů v pořadí ABA jsou zřejmé. Co zřejmé není, je, když se po těchto třech akcích uživatel B pokusí provést krok zpět. Z pohledu objektu by mělo dojít ke zpětvzetí poslední akce A, tedy přesunu nahoru. To ale provedl uživatel A, a z logiky věci není žádoucí, aby si uživatelé zasahovali do provedených akcí. Takže by mělo dojít ke zpětvzetí poslední akce uživatele B, tedy přesunu doprava. To však nelze učinit, neboť by došlo buď k posunu kružnice na místo, kde nikdy nebyla, nebo by tím byla i neočekávaně zpět vzata akce posunu nahoru uživatelem A. Ani jedna z těchto variant nedává smysl. Upravená společná kolekce akcí Standardním zpětvzetím akce tedy nelze nastalý konfliktní stav řešit. Je ale uvažováno, že kolekce akcí bude společná. Zde vznikají zmíněné podvarianty s odlišným přístupem řešení. Jejich výčet je uveden v následujícím seznamu. A) uživatel bude moci standardně manipulovat jen se svými objekty B) možnost kroku zpět bude zrušena, provede-li akci s daným objektem nějaký jiný uživatel C) dle typu akce bude rozhodnuto, zda lze provést krok zpět (je-li po sobě následující akce uživatele A a B kolizní, krok zpět provést nelze, pokud kolizní není, tedy např. změní-li uživatel A barvu a uživatel B objekt přesune, tak lze krok zpět provést, aniž by se tím akce druhého uživatele narušila) Složitost implementace těchto variant se dle očekávání liší, přičemž nejsnazší varianta A je pro uživatele méně komfortní. Varianta B již tolik uživatele neomezuje. Varianta C se zdá být nejlepší volbou, nicméně se lze domnívat, že přidaná hodnota je oproti 66

variantě B relativně malá. Analyticky a implementačně je však náročnější, proto pro začátek postačuje právě varianta B. V budoucím rozšíření bude počítáno s variantou C jako s optimálním řešením. V souhrnu mají tedy uživatelé dvě kolekce související s kreslící plochou, jednu pro vykreslované objekty, a jednu pro záznam provedených akcí. Kolekce s vykreslovanými objekty je držena i na serveru, aby mohli nově příchozí uživatelé načíst aktuální stav kreslící plochy. Na serveru je držena i kolekce akcí, která dovolí vidět historii a případně učinit požadované zpětvzetí některých akcí. Také slouží při různých opakovaných synchronizacích či v případě kolizí. 5.3.2.2 Chat logika Obsluha odesílání a příjmu textových zpráv je poměrně jednoduchá. Je použito samostatné vlákno mimo whiteboard, které zajišťuje čekání na příjem zprávy a následné vhodné předání zprávy grafickému rozhraní. Pro odesílání je sice možné implementovat frontu, kterou lze postupně, třeba periodicky odbavovat, to by ale mělo význam nejspíše pouze pro „veřejné použití“, tedy jako ochrana proti floodingu. Toto pro firemní prostředí nejspíše není vůbec potřebné, ale lze o této variantě uvažovat v budoucím rozšíření. Přenos zpráv je tedy okamžitý. Textové zprávy jsou ukládány v kolekci objektů na serveru, kde je mimo obsahu samotné zprávy i identifikace uživatele, datum a čas odeslání a také příjemce, který je buď konkrétní uživatel, nebo všichni. Budoucím rozšířením by mohlo být to, že příjemce může být vybraná skupina uživatelů. V takovém případě si ale může vybraná skupina uživatelů založit vlastní, novou relaci. Po připojení klienta k relaci dochází buď ke stažení všech zpráv ze serveru, nebo naopak žádné zprávy staženy nejsou a klient vidí buď prázdné okno, nebo pouze takové, které viděl naposledy, tedy při posledním připojení k relaci. Archivaci všech zpráv a jejich přenos uživatelům lze nastavit ze strany serveru. Zprávy jde posílat i víceřádkové, je ale doporučeno omezení délky (výchozí maximum např. 1000 znaků) a rovněž i nepřenášení prázdných zpráv. Za prázdnou zprávu lze považovat takovou, která se skládá pouze z bílých znaků.

67

5.3.2.3 Společná logika Společná logika je soubor vnitřních funkcí a tříd, které se starají o přístup k systému souborů, k databázi, registrům a dalším prostředkům operačního systému. Tyto funkce jsou shodně dostupné jak whiteboardu, tak textovému chatu. Sem spadá i logika správy uživatelů, kteří aplikaci využívají. Uživateli je po prvním spuštění aplikace vygenerováno unikátní ID, respektive GUID12. Ten je následně trvale zapsán do registrů, případně jiného umístění závislého na uživatelském účtu, pod kterým je uživatel aktuálně přihlášen v operačním systému. V budoucím rozšíření aplikace je uvažováno nad možností volit mezi více uživateli s různými jmény a nastavením, proto je datová struktura, kam se ukládá GUID a další nastavení uživatele, řešena vhodně univerzálně.

5.3.3 Vrstva přenosu a dat Tato vrstva slouží pro zajištění aktivního spojení mezi klienty a serverem, a předně pro obsluhu přenosu dat. Výměna důležitých dat probíhá pomocí protokolu TCP, okamžitý přenos kreslení a zjišťování stavu spojení využívá protokol UDP. Jsou použity běžně dostupné knihovny spadající pod .NET Framework a jejich funkce, kde podstatná část je obsažena pod namespace System.Net.Sockets. 5.3.3.1 Více vláken Aplikace má komunikuje v reálném čase v návaznosti na provedené akce uživatelů. Z tohoto důvodu je použito více vláken pro obsluhu síťové komunikace. Na straně klienta musí jedno samostatné vlákno neustále čekat na příchozí data ze serveru, obdobně odesílání je asynchronní tak, aby v případě vzniklého zpoždění nebo nastalé chyby nedošlo k paralýze uživatelského rozhraní. Také serverová část vyžaduje více vláken. Pro každého klienta, který se připojí, je založeno samostatné vlákno. Pod tímto vláknem probíhá odesílání, respektive přeposílání zpráv přijatých od ostatních klientů. Stejně tak, jako v klientské části, je i zde ještě další samostatné vlákno pro čekání na příchozí data. Orientační schéma vláken je naznačeno na obrázku 6.

GUID, anglická zkratka pro globally unique identifier, je standardně nabízená datová struktura v .NET Frameworku, která dokáže generovat unikátní identifikátor v podobě alfanumerického řetězce 12

68

Obrázek 6: Vlákna v aplikaci

5.3.3.2 Kolizní stavy Protože různé zacházení s objekty je možné nehledě na to, kdo který objekt vytvořil, musí se předcházet vzniku kolizí. Přesněji tomu, že s objektem začnou ve stejný moment manipulovat dva a více uživatelů, a systém bude muset rozhodovat, která změna kterého uživatele je ta správná. Zde se nabízí použití zámku, tedy v momentě výběru objektu dochází k jeho uzamčení tak, aby jej nemohl jiný uživatel jakkoliv ovlivňovat. Po zrušení výběru, například vybráním jiného objektu, je zase odemknut. V dalším, pozdějším rozšíření aplikace, může jít vybrat více objektů najednou. V takovém případě jich, dle očekávání, bude uzamknuto více najednou. Uzamknutí se ale může stát překážkou práce jiných uživatelů. V případě výpadku spojení uživatele, který vybral některý objekt, se po nějakém čase objekt automaticky odemkne. Tato situace je zřejmá, ovšem dojde-li k nechtěnému vybrání a opuštění práce s aplikací (minimalizace, odejití od PC, aj.), tak objekt zůstane trvale zablokovaný. Uživatelům bude umožněno daný objekt ručně odemknout, ale až po nějakém čase, který bude standardně 10 sekund od poslední manipulace s objektem. I přes uzamykání objektů může dojít ke kolizi, buď vlivem pomalého připojení jednoho či více klientů, nebo z důvodu krátkého výpadku. Uživatel po 4 sekundách zjistí, že je problém s konektivitou a v ten moment se plocha uzamkne, nicméně již mohlo dojít například k vymazání objektu. Vzhledem k tomu, že toto nemuselo být přeneseno na server, a při opětovném navázání spojení by mohla vzniknout nekonzistence v obsahu plochy klienta a plochy uložené na serveru, zprávy oznamující změnu obsahu plochy obsahují i index pořadí akce a celkový počet akcí zaznamenaných v kolekci. Je-li zjištěn rozdíl mezi klientem a serverem, dojde k opakované synchronizaci.

69

Řešení kolize takové, kdy se s objektem pokusilo najednou manipulovat více uživatelů, je provedeno tak, že se vezme v potaz první na server příchozí zpráva oznamující uzamčení objektu uživatelem. Akce tohoto uživatele je upřednostněna. 5.3.3.3 Výpadek spojení klienta nebo serveru V praxi je nutné počítat i s výpadkem spojení, ať už se jedná o internet nebo lokální síť. Protože nelze spolehlivě vzájemně identifikovat, zda výpadek spojení nastal na straně serveru nebo klienta, je nutné k tomuto přistupovat dostatečně univerzálně a tak, aby nedošlo k neočekávané ztrátě dat. Aby byl server i klient informován o dostupnosti druhé strany, je zapotřebí provádět periodické odesílání a potvrzování kontrolních zpráv. Zpráva tohoto typu je pojmenovaná jako „heartbeat“. Pro server je z hlediska režie, ale i logiky lepší, když je zdrojem těchto zpráv klient. Server si pouze udržuje vhodně krátkou historii těchto přijatých zpráv a podle toho informuje ostatní klienty o výpadku spojení jednoho z nich. A samozřejmě na tyto zprávy odpovídá. Aplikace klienta tak může včas zablokovat kreslící plochu, přestane-li se server ozývat. Zablokovat proto, aby uživatel jednak nebyl dezinformován, že jeho tvorbu vidí i ostatní, ale jednak i kvůli tomu, aby se v maximální možné míře předešlo vzniku kolizí při manipulaci s objekty. Pozastavení plochy uživatele a informování ostatních uživatelů na serveru nastane již po 4 sekundách bez odezvy, je-li uvažováno odesílání heartbeatu každou 1 sekundu. Pokud dojde k včasnému obnovení spojení, proběhne opětovná synchronizace kolekcí objektů a vyřešení případných kolizí. V případě neobnovení spojení je po 30 sekundách spojení s klientem ze strany serveru zastaveno a případné jím uzamknuté objekty jsou odemčeny. Lze tedy rozlišovat mezi třemi stavy spojení mezi klientem a serverem, jak uvedeno na obrázku 7. Obrázek 7: Stavy spojení klienta a serveru

Po odpojení klienta zůstanou pochopitelně jím vytvořené objekty uložené v datových strukturách serveru. Pozdější opětovné připojení nebude nijak odlišné od toho, jako když se klient připojí standardně, od znovu. 70

Konkrétní implementace heartbeatu je taková, aby šla zjistit skutečná odezva, tedy za jak dlouho se dostanou data od klienta na server. Implementace tohoto závisí na časovém razítku, které klient vloží do první odesílané zprávy. Po doručení na server vygeneruje server okamžitou odpověď a odešle ji klientovi zpět. V této odpovědi je obsaženo časové razítko, které poslal klient na server. Jakmile klient přijme tuto odpověď, bude mu zřejmé, odečtením přijatého původního časového razítka od aktuálního času, jak dlouho trval přenos. 5.3.3.4 Protokol a výměna informací Pro přenos informací jsou využity protokoly TCP a UDP. V případě protokolu TCP se po připojení klienta k serveru vytváří jedno stále otevřené spojení, skrze které jsou přenášena veškerá data. Krom tohoto dochází k přenosu zpráv typu heartbeat protokolem UDP, které server informují o stavu připojení klienta, a server zase o tomto informuje ostatní připojené klienty. UDP je použit i pro vyhledání relací dostupných na lokální síti. Výměna dat probíhá pomocí předdefinovaných zpráv uvedených v tabulce 29 níže. Tabulka 29: Zprávy použité pro výměnu informací

Popis

Kategorie

Zdroj

Cíl

Protokol

Uživatel vyhledá dostupné lokální relace

Vyhled. rel.

Klient

Broadcast

UDP

Odpověď od serveru, že relace existuje

Vyhled. rel.

Server

Klient

UDP

Žádost o synchronizaci všech dat

Synchroniz.

Klient

Server

TCP

Odeslání všech dat

Synchroniz.

Server

Klient

TCP

Potvrzení přijetí všech dat

Synchroniz.

Klient

Server

TCP

Odeslání notifikace klientem

Heartbeat

Klient

Server

UDP

Potvrzení přijetí notifikace serverem

Heartbeat

Server

Klient

UDP

Oznámení, že má uživatel výpadek

Heartbeat

Server

Ostatní

TCP

Uživatel se chce připojit

Uživatelé

Klient

Server

TCP

Uživatel byl akceptován serverem

Uživatelé

Server

Klient

TCP

Uživatel byl zamítnut serverem

Uživatelé

Server

Klient

TCP

Uživatel byl připojen

Uživatelé

Server

Ostatní

TCP

Uživatel se odpojil

Uživatelé

Klient

Server

TCP

Uživatel byl odpojen

Uživatelé

Server

Ostatní

TCP

Uživatel byl odstraněn správcem

Uživatelé

Klient

Server

TCP

Server odstraní uživatele z relace

Uživatelé

Server

Klient

TCP

Oznámení, že byl uživatel odstraněn

Uživatelé

Server

Ostatní

TCP

71

Odeslání textové zprávy uživatelem

Chat

Klient

Server

TCP

Server rozešle přijatou textovou zprávu

Chat

Server

Ostatní

TCP

Uživatel kreslí křivku

Whiteboard

Klient

Server

UDP

Server informuje ostatní o kreslení křivky

Whiteboard

Server

Ostatní

UDP

Uživatel provedl změnu kreslící plochy

Whiteboard

Klient

Server

TCP

Server rozešle změnu ostatním

Whiteboard

Server

Ostatní

TCP

Uživatel vybral – uzamkl objekt

Whiteboard

Klient

Server

TCP

Server rozešle uzamknutí ostatním

Whiteboard

Server

Ostatní

TCP

Uživatel zrušil výběr – odemkl objekt

Whiteboard

Klient

Server

TCP

Server rozešle odemknutí ostatním

Whiteboard

Server

Ostatní

TCP

Žádost o přenos – sdílení souboru

Soubory

Klient

Server

TCP

Server potvrdí žádost o přenos

Soubory

Server

Klient

TCP

Server zamítne žádost o přenos

Soubory

Server

Klient

TCP

Přenos souboru od klienta na server

Soubory

Klient

Server

TCP

Přenos souboru ze serveru k uživateli

Soubory

Server

Klient

TCP

Server oznámí dostupnost souboru

Soubory

Server

Ostatní

TCP

Zprávy jsou odesílány a přijímány jako serializované objekty. Serializovány jsou do binární podoby a dle dalšího vývoje a testování mohou být zkomprimovány vhodným algoritmem (např. deflate, který je standardně dostupný v knihovnách .NET, pod namespace System.IO.Compression). Komunikační protokol má vždy určenou svoji aktuální verzi, aby nemohlo docházet k problémům s kompatibilitou při jeho upgradu, respektive při upgradu aplikace. 5.3.3.5 Port a technické detaily Oba protokoly transportní vrstvy, tedy TCP a UDP komunikují skrze jeden port, ideálně z rozsahu uživatelských portů (1024 – 49151), který lze určit v rozšířené konfiguraci relace. Jako výchozí je navržen port 40004. Protože protokol TCP používá algoritmus pro předejití zahlcení sítě, který ale může zbrzdit odesílání dat, což je zde velice nežádoucí, lze uvažovat o použití vlastnosti NoDelay13 třídy Socket.

NoDelay je standardně vypnutá vlastnost TCP protokolu, povolením které je vypnut Nagleův algoritmus, který zlepšuje efektivitu TCP/IP sítí redukováním počtu odeslaných malých paketů 13

72

Preferováno je využití adresního schématu protokolu IP verze 4, neboť verze 6 již nemá broadcast a ačkoliv lze podobného efektu dosáhnout multicastem na „all nodes“ adresu14, mnoho aktivních prvků v síti přenos typu multicast pod IP verze 6 bohužel nepodporuje.

5.4 Uživatelské rozhraní Návrh uživatelského rozhraní je ovlivněn nezanedbatelným množstvím nefunkčních požadavků, především ze skupiny Usability. Na základě těchto jsou realizována dvě rozhraní, jedno pracovní – velké a druhé kompaktní – malé. Kompaktní rozhraní by mělo zaručit nikoliv snad použitelnost aplikace na mobilních zařízeních, ač to není zcela vyloučeno, avšak spíše určité nepřekážení, pokud bude uživatel aplikaci používat jen jako „vedlejší komunikátor“. Tedy aby nemusel mít okno přes celou obrazovku, ale podobně jako například Google Talk či jiné Instant Messengery, disponoval malým oknem, ve výchozím stavu umístěném třeba v rohu obrazovky. Dvě rozhraní nejsou problém ze strany textového chatu, problém jsou však pro whiteboard. Předpokládejme, že mezi prostředími půjde za běhu snadno přepínat. Pracovní rozhraní bude disponovat velkou kreslící plochou, kompaktní rozhraní, aby přineslo něco víc, než jen textový chat, bude disponovat malou kreslící plochou. Jak se však bude přenášet několikanásobně větší pracovní plocha na menší, kompaktní zobrazení? Tento problém má čtyři možná racionální řešení. 1. Velká kreslící plocha se zmenší do malé (resizing či resampling) 2. Obě kreslící plochy budou nezávislé 3. Malá kreslící plocha bude obsahovat veškerý obsah plochy velké, se scrollbary 4. Malá kreslící plocha bude jen určitý daný výřez z plochy velké Ani jedno z těchto řešení však není ideální. Rovnou lze zavrhnout první zmíněný bod, neboť změna z plochy velikosti například 900 x 600 na 180 x 120 pixelů by natolik degradovala obsah, že by rozeznatelnost na ploše zaznamenaných údajů byla obtížná až zcela nemožná. Také by plocha musela být ve stavu pouze pro čtení, neboť

BOUŠKA, Petr: TCP/IP – Internet Protocol Version 6 – IPv6. Samuraj. [online]. 5. 3. 2009 [cit. 2015-0710]. Dostupné z: http://www.samuraj-cz.com/clanek/tcpip-internet-protocol-version-6-ipv6/ 14

73

transformace obsahu z malé plochy (pokud by zde uživatel kreslil) na velkou by byla velmi nepřesná a nekvalitní. Druhé řešení lze zavrhnout taktéž. Další, tedy nezávislá kreslící plocha, by musela být zobrazitelná i v pracovním prostředí. Není totiž možné, aby kompaktní rozhraní nabízelo navíc funkčnost, kterou pracovní rozhraní nebude disponovat (miniaturní plochu se zcela jiným obsahem). A umístění další, malé plochy do pracovního prostředí se nejeví zrovna vhodně, ať už jde o samotnou implementaci (přenos obsahu 2 ploch najednou, kde do každé mohou ve stejný moment zasahovat jiní uživatelé), nebo začlenění do designu, ale i o pocit uživatele, který by asi těžko chápal, proč musí být plochy právě dvě. Zbývají dvě řešení. Použití scrollbarů je sice možné, ale vzhledem k větší velikosti pracovní plochy je užitečnost posouvání celého tohoto obsahu ve velmi malém okně poněkud špatná až nevhodná. Poslední možností je výřez z plochy velké. V tomto případě se takové řešení může jevit uživatelům jako neobvyklé, nicméně je dobře použitelné a tuto funkčnost jako celek lze dále rozšiřovat, např. možností přesunu výřezu na jiné místo, uzamykáním pro zápis, a dalšími. Tento způsob řešení byl tedy vybrán jako nejvhodnější. Dále, obě rozhraní by měla být navržena tak, aby zbytečně uživatele nenutila do nových zvyklostí nebo mu používání aplikace nečinila jakkoliv složitější. Z funkčních požadavků lze vyvodit, že podstatné komponenty, ze kterých bude pracovní rozhraní sestávat, jsou následující. 1. samotná kreslící plocha 2. hlavní nástrojový panel, kde půjde zvolit nástroj pro kreslení 3. pomocný nástrojový panel, kde půjde upřesnit způsob kreslení (barvy aj.) 4. textové pole pro zápis a odeslání nové textové zprávy 5. víceřádkové textové pole pro zobrazení již odeslaných a přijatých zpráv 6. seznam připojených uživatelů Pochopitelně bude obsaženo i menu, buď v klasické podobě, nebo jako ribbon, či snad podobě vlastní. Klasická podoba, tedy pouze text v jednobarevných stripech, může působit zastarale a nevábně, pro dočasné použití však postačuje. Ribbon není v klasických Windows Forms k dispozici, je obsažen pouze ve WPF nebo v komerčních 74

sadách komponent. Existují však i přídavné knihovny pro WF15, které ribbon zdarma nabízejí. Jedná se však o přidání závislosti na knihovně, kterou psala třetí strana a která je tedy potenciálním zdrojem chyb či licenčních problémů. Tomu je potřeba se v nejvyšší možné míře vyhnout. Nejlepším řešením by tedy mohlo být menu vlastní. Bez větší námahy lze takové menu sestavit pouhými tlačítky umístěnými blízko sebe s vhodně navázanými eventy, které na rozdíl od klasického menu mohou obsahovat i popis obrázkem. Těmto tlačítkům lze docela jednoduše změnit vzhled z klasických šedých na moderní jednobarevné ploché, stylu Windows 8, a navodit tak pocit určité přívětivosti prostředí. Uvedené komponenty se tedy týkají především rozhraní pracovního. Jejich vhodným umístěním na formulář by rozložení základní verze mělo vypadat přibližně tak, jak načrtnuto dále na obrázku č. 8. Obrázek 8: Návrh hlavního okna s whiteboardem

15

Například Office Ribbon Project, zdarma ke stažení na webu http://officeribbon.codeplex.com/

75

Kompaktní rozhraní musí být co nejstručnější, avšak stále dobře použitelné. Funkční požadavky může do jisté míry naplňovat tím, že budou ukryty do standardně nezobrazených součástí, například do menu, podmenu a rozevíracích částí formulářů. Některé textové popisky lze nahradit odpovídajícími ikonami. Rozložení kompaktního rozhraní by tedy mělo vypadat přibližně tak, jak načrtnuto na obrázku č. 9. Obrázek 9: Návrh kompaktního okna pro komunikaci

První z tlačítek po levé straně otevírá menu, které především substituuje vrchní menu pracovního rozhraní, samozřejmě vhodně přeuspořádané. Další tlačítko s ikonou uživatele zobrazí připojené uživatele a umožní jejich správu a výběr, se kterými probíhá textová komunikace, také může zobrazit informace o současné relaci. Poslední tlačítko otevírá levou část formuláře, kde je malý whiteboard bez nástrojových panelů. Ty jsou nahrazeny pomocí menu, které se otevře nově zobrazeným tlačítkem s ikonou tužky (nebo lépe štětce). Toto tlačítko při zavření whiteboardu mizí. Část funkcí lze rovněž vymístit do menu, které půjde otevřít pravým kliknutím do kreslící plochy. Kompaktní rozhraní s otevřeným whiteboardem by tedy mělo vypadat obdobně následujícímu obrázku č. 10. Obrázek 10: Návrh rozšířeného kompaktního okna pro komunikaci

76

Design různých informačních či chybových dialogů by měl být vlastní, neboť používání standardně dostupných, připravených dialogových oken je často značně omezující a jejich grafika nekoresponduje s aplikací, nýbrž s aktuální verzí operačního systému.

77

5.5 Class diagram Diagram tříd zde vychází z doménového diagramu uvedeného v kapitole 4.3.2. Zde je tedy upřesněno pouze několik detailů. Tento diagram také popisuje pouze relevantní datovou strukturu ve vrstvě business logiky, není zde zanesena jak vrstva prezentační, tak ani datová. Obrázek 11: Class diagram logické vrstvy

V diagramu jsou použity nejen standardní datové typy .NET Frameworku, ale také datové typy z namespace System.Drawing. Mezi tyto spadají Point, Pen, Brush, Image, Size, Rectangle, Font a PointF.

78

5.6 Testování Vyjma obvyklého testování při vývoji, jsou implementovány i Unit testy. Přestože je aplikace z velké části tvořená grafickým rozhraním, které nelze jednoduše testovat, jsou testovány alespoň nižší vrstvy. Konkrétně jsou do testování zahrnuty například funkce pro zpracování přijaté zprávy o změně kreslící plochy a manipulace se souvisejícím objektem v kolekci objektů, stejně jako ukládání těchto zpráv do příslušné kolekce.

5.7 Rozšiřitelnost aplikace Již během analýzy a dále i během implementace je zmíněno více potenciálních budoucích rozšíření, které mohou učinit aplikaci ještě lepší. Určité přidávání nových funkcí a související designové úpravy jsou zřejmé, nicméně nelze vyloučit ani budoucí přechod na jiné technologie. Stručný seznam některých již zmíněných a dalších takových, které stojí za to uvést, je uveden níže. -

více možností kreslení (více nástrojů, různé druhy štětce, další geom. útvary, …)

-

více různých manipulací s objekty (změna velikosti, rotace, …)

-

manipulace s více objekty najednou

-

provést krok vpřed (po kroku zpět), nebo zrušit konkrétní vybraný krok

-

možnost definice oprávnění v relaci pro konkrétní uživatele

-

vlastní definice galerie obrázků a její další správa

-

možnost použití stencilů z produktu Microsoft Visio pro galerii

-

lokální jednosouborová databáze pro galerii, nastavení a další

-

možnost posílat emotikony či formátovaný text v textovém chatu

-

textový chat mezi více vybranými uživateli

-

možnost kroku zpět dle typu předchozí akce

-

zobrazení seznamu jednotlivých kroků a možnost zrušení vybraného

-

rozšíření možných nastavení relace

-

zakládání více relací na jednom serveru

-

více uložených uživatelských profilů v aplikaci

Dále, dle průběžného testování aplikace a vlivu na síťové prostředky by mohla proběhnout optimalizace síťového protokolu, tedy doplnění o další podpůrné zprávy, u některých změna použitého protokolu transportní vrstvy, přidání komprese a další. 79

Server jako stand-alone aplikace Někdy se toto nazývá také dedikovaný server. Kupříkladu ve firemním prostředí je užitečné mít stále běžící server, ke kterému se uživatelé mohou kdykoliv připojit bez toho, aniž by si zakládali relace vlastní. Samostatný server jako konzolová aplikace má také řadu výhod. -

může být provozován i na jiných operačních systémech bez grafického rozhraní

-

má menší spotřebu systémových prostředků

-

bez GUI a dalších nepotřebných součástí lze předpokládat, že je stabilnější

-

lze naskriptovat jeho spouštění, restartování, sledování a další akce

Implementace samostatného serveru je více než vhodná a při kvalitní realizaci hlavní, desktopové aplikace by mohlo stačit vyčlenit příslušné společné části a funkce do samostatného projektu tak, aby tyto byly sdílené mezi oběma projekty. WPF namísto Windows Forms Ukáže-li se časem použití Windows Forms jako nedostatečně ohebné či jiným způsobem omezující, lze uvažovat o přejití na UI framework WPF. To způsobí nutnost přepsání celé prezentační vrstvy a vhodné nové navázání vrstvy business logiky, takže se tato akce může jevit jako nerentabilní a nesmyslná. Dalším přínosem by ale, vyjma uvedené lepší ohebnosti a dalších nabízených vlastností, byla například podpora vykreslování použitím Direct3D grafického rozhraní a tím nejen zapojení výkonu grafické karty, ale možné použití pokročilých grafických technologií16. Pluginy a rozšíření třetími stranami Není uvažováno o tom, že bude aplikace rozšiřitelná třetími stranami, tedy formou jakýchkoliv pluginů. Serverovou část lze podle potřeby rozšířit tak, aby nabízela určité API například pro zjištění stavu obsazenosti jiným softwarem, ale toto poskytované rozhraní bude vždy pouze pro čtení.

ŠTURALA, Aleš: Direct3D ve WPF? JO! vyvojar.cz. [online]. 13. 12. 2006 [cit. 2015-07-28]. Dostupné z: http://new.vyvojar.cz/direct3d-ve-wpf-jo/ 16

80

5.8 Distribuce mezi uživatele Aplikace bude stažitelná volně z webových stránek, které teprve vznikají. Budou nabízeny dvě verze, jedna s instalátorem a jedna jako archiv bez instalátoru. Důvod existence instalátoru je takový, aby instalátor sám mohl ověřit dostupnost potřebné verze .NET Frameworku, případně požadovanou verzi stáhnout a nainstalovat. Aby byl zaručen bezproblémový chod aplikace a předejito konfrontaci operačním systémem a ochranou proti škodlivému softwaru, je aplikace podepsána vhodným certifikátem. Dále je provedena certifikace od společnosti Microsoft, aby byla zaručena kompatibilita s novými operačními systémy.

5.9 Nápověda a dokumentace Samo rozhraní aplikace je dostatečně uživatelsky přívětivé a intuitivní. Možnosti volby, nástroje a různé další součásti rozhraní obsahují tzv. tooltipy, které se automaticky zobrazí při najetí kurzorem myši na onen prvek. Standardně je dostupné i okno „O aplikaci“, kde jsou uvedeny základní údaje o tomto produktu, jakožto název, autor, kontakt na autora, webové stránky, rok vzniku, důvod vzniku a případné další detaily. Klasická nápověda není v aplikaci obsažena, tento způsob se nejeví dostatečně prakticky, ať už co se týká aktualizací a nutnosti vydávat v takovém případě novou verzi, nebo potřebnosti implementace vlastního rozhraní pro zobrazování nápovědy. Nápověda, tedy spíš dokumentace, se bude nacházet na webových stránkách ve formě wiki encyklopedie.

81

6 ZÁVĚR Předmětem této práce bylo vyhledat a analyzovat současně dostupná softwarová řešení pro přenos kreslící plochy mezi více uživateli, po lokální počítačové síti nebo internetu. Poté dle zjištěných poznatků sestavit vizi takové ideální aplikace, provést softwarovou analýzu, design a samotnou realizaci v podobě prototypu. Při vyhledávání a analýze aktuálně dostupných aplikací bylo zjištěno, že jsou všechny, až na jednu výjimku, v provedení pro webový prohlížeč. Toto provedení s sebou nese určité výhody i nevýhody, které byly v práci popsány a mezi které patří například nedostatečně ohebné prostředí a omezená, až nemožná práce bez připojení k internetu. Na základě těchto poznatků byla zformována vize desktopové aplikace. Na vizi navázala softwarová analýza, která obsahuje konkretizaci funkčních i nefunkčních požadavků, základní strukturální diagramy, seznam případů užití a popis případů užití s nejvyšší prioritou. V analýze se ukázalo, že v případě obdobné aplikace lze stanovovat stále další případy užití, které se mohou vázat na stejné funkční požadavky. Proto byly případy užití rozděleny dle priorit, a některé další byly uvedeny pouze jako možnost budoucího rozšíření aplikace. Kapitola zabývající se implementací zařadila jednotlivé případy užití do různých vývojových fází, popsala architekturu a také objasnila způsob řešení práce s objekty na kreslící ploše a jejich přenos mezi uživateli. Realizací prototypu byla odhalena některá úskalí, co s sebou přináší tento druh síťové aplikace, kde mezi sebou může komunikovat více uživatelů. Jako obtížnější se ukázalo řešení předávání výsledků od jednotlivých vláken tak, aby byla zachována architektura se souvisejícím rozvrstvením, a zároveň nemohlo dojít k nevalidní operaci mezi vlákny. Naopak práce s prezentační vrstvou a grafikou se ukázala být relativně snadná. Třídy frameworku .NET nabízejí pro grafiku připravená funkční řešení, které lze i dle potřeby přizpůsobit aktuálním požadavkům. Během vývoje se ukázalo jako nezbytné vyvinout nejprve robustní a do určité míry abstraktní základ, na kterém bude dále stavěno. Bez tohoto základu není možné aplikaci rozvíjet udržitelným způsobem. Vyvinutý prototyp implementuje navržené prioritní funkce a demonstruje přenos obsahu kreslící plochy mezi připojené uživatele. Práce byla pro autora velkým přínosem, neboť řešení analýzy a návrhu obdobných aplikací v .NET Frameworku je i jeho pracovní činností, a zpracováním této bakalářské práce si ujasnil některé metody a procesy, které je nutné dodržovat. 82

7 CONCLUSION The object of this study was to find and analyze currently available software solutions for the transfer of canvas between multiple users, over a local network or the Internet. Then, according to the findings to create a vision of the ideal application, to perform software analysis, design and implementation itself in the form of a prototype. While searching and analyzing currently available applications, it was found that they all, with one exception, run in the web browser. This brings certain behavior that was described in the thesis, and which include, for example, insufficiently flexible user interface and limited possibilities of work without an Internet connection. Based on these findings the vision of desktop application was formed. The vision was followed by software analysis, which includes specification of functional and non-functional requirements, basic structural diagrams, list of use cases and description of use cases with the highest priority. The analysis showed that in case of similar application it’s possible to continuously add new use cases based on the same functional requirements. Therefore, the use cases are divided according to priorities, and some others were only given as an option for future extension. Chapter dealing with implementation ranked individual use cases in various stages of development, described the architecture and clarified the way the solution works with objects on the canvas as well as their transfer between users. By realization of the prototype some of the pitfalls, that brings this kind of network application, were revealed. As it turned out, passing the results between individual threads is difficult. On the other side working with graphic in presentation layer proved to be relatively easy. The .NET Framework graphical classes offer ready and working solution that can adapt to the current requirements. During the development it has proved necessary to develop robust and abstract base on which can be build further. Without this base, it’s not possible to develop an application in sustainable manner. The developed prototype implements the proposed priority functions and demonstrates the transfer of canvas between connected users. This work was a great benefit for the author, because software analysis and design of similar applications based on the .NET Framework is also his work activity. Making of this Bachelor thesis helped him to clarify some of the methods and processes that must be followed. 83

8 SEZNAM POUŽITÝCH ZDROJŮ 1. .NET Framework System Requirements. Microsoft Developer Network: Visual Studio. [online]. [cit. 2015-06-14]. Dostupné z: https://msdn.microsoft.com/en-us/library/vstudio/8z6watww(v=vs.110).aspx 2. About Mono – Compatibility. Mono Project. [online]. [cit. 2015-07-22]. Dostupné z: http://www.mono-project.com/docs/about-mono/compatibility/ 3. Adobe Flash Player – Features. Adobe Systems. [online]. [cit. 2015-07-13]. Dostupné z: http://www.adobe.com/products/flashplayer/features.html 4. AFROZ, Mubashir: An Introduction to Socket Programming in .NET using C#. CodeProject. [online]. 10. 6. 2005 [cit. 2015-07-29]. Dostupné z: http://www.codeproject.com/Articles/10649/An-Introduction-to-SocketProgramming-in-NET-using 5. BARBER, Sacha: WCF / WPF Chat Application. CodeProject. [online]. 22. 7. 2011 [cit. 2015-07-27]. Dostupné z: http://www.codeproject.com/Articles/19752/WCF-WPF-Chat-Application 6. Benefits of Windows certification. Microsoft Dev Center. [online]. [cit. 2015-07-26]. Dostupné z: https://msdn.microsoft.com/cs-cz/windows/desktop/hh968450.aspx 7. BOUŠKA, Petr: TCP/IP – Internet Protocol Version 6 – IPv6. Samuraj. [online]. 5. 3. 2009 [cit. 2015-07-10]. Dostupné z: http://www.samuraj-cz.com/clanek/tcpip-internet-protocol-version-6-ipv6/ 8. BREUER, Gordon: When creating a new GUI, is WPF the preferred choice over Windows Forms? Stack Overflow. [online]. [cit. 2015-07-30]. Dostupné z: http://stackoverflow.com/questions/57909/when-creating-a-new-gui-is-wpfthe-preferred-choice-over-windows-forms 9. Can TCP and UDP sockets use the same port? Stack Overflow. [online]. [cit. 201507-20]. Dostupné z: http://stackoverflow.com/questions/6437383/can-tcp-andudp-sockets-use-the-same-port 10. CLEARY, Stephen: Socket Operations. Stephen Cleary’s Blog. [online]. 5. 5. 2009 [cit. 2015-07-29]. Dostupné z: http://blog.stephencleary.com/2009/05/socket-operations.html 11. Creating a class that holds/draws some graphics. Stack Overflow. [online]. [cit. 2015-07-19]. Dostupné z: http://stackoverflow.com/questions/4676998/creating-a-class-that-holdsdraws-some-graphics 12. EDELSTEIN, Noah: Feature evolution and support for the Skype Desktop API. Skype: Garage & Updates. [online]. 6. 11. 2013 [cit. 2015-07-06]. Dostupné z: http://blogs.skype.com/2013/11/06/feature-evolution-and-support-for-theskype-desktop-api/ 84

13. EELES, Peter: Capturing Architectural Requirements. IBM developerWorks. [online]. 15. 11. 2005 [cit. 2015-05-25]. Dostupné z: http://www.ibm.com/developerworks/rational/library/4706.html 14. FAQ and Support. QUAKE LIVE. [online]. [cit. 2015-07-22]. Dostupné z: http://www.quakelive.com/#!faq/faq_question_1 15. FIEDLER, Glenn: Networking for Game Programmers – UDP vs. TCP. Gaffer on Games. [online]. [cit. 2015-07-28]. Dostupné z: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/ 16. GOŠOVÁ, Věra: Rozdíl mezi kreslením a malováním. Metodický portál: Pedagogický lexikon. [online]. 26. 5. 2011 [cit. 2015-06-10]. Dostupné z: http://goo.gl/4wLjhr 17. Graphic – DrawLine – draw line and move it. Stack Overflow. [online]. [cit. 201507-20]. Dostupné z: http://stackoverflow.com/questions/10768570/graphicdrawline-draw-line-and-move-it 18. Graphics Class. Microsoft Developer Network. [online]. [cit. 2015-07-20]. Dostupné z: https://msdn.microsoft.com/en-us/library/System.Drawing.Graphics.aspx 19. GUI – WPF. Mono Project. [online]. [cit. 2015-07-25]. Dostupné z: http://www.mono-project.com/docs/gui/wpf/ 20. HTML Version Statistics. PowerMapper Software. [online]. [cit. 2015-07-20]. Dostupné z: http://try.powermapper.com/Stats/HtmlVersions 21. IDroo Alternatives and Similar Software. AlternativeTo.net. [online]. [cit. 2015-0706]. Dostupné z: http://alternativeto.net/software/idroo/ 22. KOWALCZYK, Krzysztof: Which technology for writing desktop software? Krzysztof Kowalczyk (blog). [online]. 5. 12. 2010 [cit. 2015-05-07]. Dostupné z: https://blog.kowalczyk.info/article/7ez5/Which-technology-for-writing-desktopsoftware.html 23. LEVENHAGEN, Greg: Is WPF Dead? – NO. greglevenhagen.com. [online]. 11. 2. 2014 [cit. 2015-07-30]. Dostupné z: http://greglevenhagen.com/is-wpf-dead-no/ 24. MAKOVETSKIYD, Dmitry: How do you send a serialized object over net? Stack Overflow. [online]. [cit. 2015-07-27]. Dostupné z: http://stackoverflow.com/questions/4814552/how-do-you-send-a-serializedobject-over-net 25. MITCHELL, Richard: 5 Reasons why I hate WPF. simple talk. [online]. 16. 6. 2011 [cit. 2015-07-30]. Dostupné z: https://www.simple-talk.com/blogs/2011/06/16/5-reasons-why-i-hate-wpf/ 26. MORRILL, Jeremiah: A Critical Deep Dive into the WPF Rendering System. Jer’s Hacks. [online]. 14. 2. 2011 [cit. 2015-05-25]. Dostupné z: https://goo.gl/vgLJMq

85

27. NASH, Trey: C# 2010 – Rychlý průvodce novinkami a nejlepšími postupy. Brno: Computer Press, 2010. ISBN 978-80-251-3034-6. 28. Office Ribbon Project. CodePlex: Project Hosting for Open Source Software. [online]. [cit. 2015-07-25]. Dostupné z: http://officeribbon.codeplex.com/ 29. QUAKE LIVE Standalone Game. QUAKE LIVE Forums. [online]. 7. 11. 2013 [cit. 2015-07-22]. Dostupné z: http://www.quakelive.com/forum/showthread.php?34313 30. RAZAN, Paul: Multilevel Undo and Redo Implementation in C#. CodeProject. [online]. 17. 2. 2009 [cit. 2015-07-20]. Dostupné z: http://www.codeproject.com/Articles/33371/Multilevel-Undo-and-RedoImplementation-in-C-Part 31. SCHUH, Justin: Saying Goodbye to Our Old Friend NPAPI. Chromium Blog. [online]. 23. 9. 2013 [cit. 2015-07-24]. Dostupné z: http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friendnpapi.html 32. SHANNON, Ross: DHTML Explained. HTML Source. [online]. [cit. 2015-06-13]. Dostupné z: http://www.yourhtmlsource.com/javascript/dhtmlexplained.html 33. SMEDBERG, Benjamin: Plugin Activation in Firefox. Mozilla: Future Releases. [online]. 24. 9. 2013 [cit. 2015-07-24]. Dostupné z: https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-infirefox/ 34. Socket.NoDelay Property. Microsoft Developer Network: .NET Framework Class Library. [online]. [cit. 2015-07-26]. Dostupné z: https://msdn.microsoft.com/en-us/library/y2tx9e5f(v=vs.110).aspx 35. STEPHENS, Rod: Use double buffering to prevent flicker in a PictureBox in C#. C# Helper. [online]. 7. 11. 2014 [cit. 2015-07-24]. Dostupné z: http://csharphelper.com/blog/2014/11/use-double-buffering-to-prevent-flickerin-a-picturebox-in-c/ 36. SUDELBÜCHER, Ralf: WCF is not the solution but the problem. Ralf’s Sudelbücher (blog). [online]. 20. 2. 2010 [cit. 2015-07-28]. Dostupné z: http://weblogs.asp.net/ralfw/wcf-is-not-the-solution-but-the-problem 37. ŠTURALA, Aleš: Direct3D ve WPF? JO! vyvojar.cz. [online]. 13. 12. 2006 [cit. 201507-28]. Dostupné z: http://new.vyvojar.cz/direct3d-ve-wpf-jo/ 38. TCP vs. UDP – Difference and Comparison. Diffen. [online]. [cit. 2015-07-29]. Dostupné z: http://www.diffen.com/difference/TCP_vs_UDP 39. Using UDP Services. Microsoft Developer Network. [online]. [cit. 2015-07-30]. Dostupné z: https://msdn.microsoft.com/en-us/library/tst0kwb1.aspx

86

40. VAN DER SCHEE, Maurits: 10 very good reasons to stop using JavaScript. LeaseWeb labs. [online]. 4. 7. 2013 [cit. 2015-07-24]. Dostupné z: http://www.leaseweblabs.com/2013/07/10-very-good-reasons-to-stop-usingjavascript/ 41. VOGEL, Peter: Architecting Code in the Presentation Layer. Visual Studio Magazine: Practical .NET. [online]. 27. 7. 2013 [cit. 2015-07-21]. Dostupné z: https://visualstudiomagazine.com/articles/2013/07/01/architecting-code-inthe-presentation-layer.aspx 42. Windows XP End of Support. Microsoft: For business. [online]. [cit. 2015-07-25]. Dostupné z: https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support

87

9 SEZNAM ZKRATEK A POJMŮ Pojem

Popis

C#

C Sharp, programovací jazyk používaný v .NET Frameworku

cookie

Malé množství dat, které web odeslal a uložil do uživatelova prohlížeče

CSS

Cascading Style Sheets, kaskádové styly pro design webových stránek

DBMS

Database management system, databázový systém (SQL Server, MySQL, aj.)

Firefox

Webový prohlížeč od společnosti Mozilla

Flash

Multimediální a softwarová platforma pro tvorbu grafiky, animací, her, aj.

GUI

Graphical User Interface, grafické rozhraní které vidí a ovládá uživatel

heartbeat

Obvykle krátká zpráva, která oznamuje protějšku aktivitu/dostupnost systému

HTML

HyperText Markup Language, značkovací jazyk pro vývoj webových stránek

HTML5

HTML nové verze 5, obsahující různá multimediální rozšíření

HTTP

HyperText Transfer Protocol, protokol pro přenos webových stránek

Chrome

Webový prohlížeč od společnosti Google

Java

Programovací jazyk a softwarová platforma od společnosti Oracle

JS

JavaScript, skriptovací jazyk pro webové stránky

netbook

Malý, obvykle 9 až 11 palcový notebook

OS

Operační systém

plugin

Zásuvný, či spíše přídavný modul, který rozšiřuje aplikaci o další funkce

popup

Malé vyskakovací okno, které obvykle obsahuje nějaké hlášení pro uživatele

resampling

Změna velikosti obrázku se změnou počtu pixelů (přepočet nebo dopočtení)

resizing

Změna velikosti obrázku beze změny počtu pixelů

ribbon

Prvek GUI, který sdružuje více nástrojových lišt a přepíná mezi nimi

Safari

Webový prohlížeč od společnosti Apple

scrollbar

Posuvník na okraji okna, pokud je okno malé a obsah se do něj celý nevejde

Silverlight

Aplikační framework pro vývoj multimediálních aplikací pro web i desktop

smartphone

„Chytrý telefon“, mobilní telefon s pokročilým operačním systémem

stencil

Šablona grafického objektu v aplikaci Visio

tablet

Malý přenosný počítač ve tvaru desky s dotykovou obrazovkou

TCP

Transmission Control Protocol, protokol transportní vrstvy, ze sady TCP/IP

tooltip

Malý textový popisek, který se zobrazí při najetí kurzorem myši na něco

UDP

User Datagram Protocol, protokol transportní vrstvy, ze sady TCP/IP

Unit testing

Automatické testování založené na jednoduchých testech částí programu

Use-Case

Případ užití, pojem používaný v softwarovém inženýrství

VB.NET

Visual Basic .NET, programovací jazyk použivaný v .NET Frameworku

Visio

Aplikace od společnosti Microsoft pro kreslení schémat

WF

Windows Forms, systém pro vykreslování GUI v .NET Frameworku

WPF

Windows Presentation Foundation, novější grafický systém .NET Frameworku

88

10 SEZNAM OBRÁZKŮ Obrázek 1: High-level pohled na systém ........................................................................................ 47 Obrázek 2: Doménový diagram ......................................................................................................... 48 Obrázek 3: Komunikace mezi aktéry a systémy .......................................................................... 48 Obrázek 4: High-level pohled na architekturu systému........................................................... 63 Obrázek 5: Vrstvy architektury aplikace........................................................................................ 63 Obrázek 6: Vlákna v aplikaci ............................................................................................................... 69 Obrázek 7: Stavy spojení klienta a serveru ................................................................................... 70 Obrázek 8: Návrh hlavního okna s whiteboardem..................................................................... 75 Obrázek 9: Návrh kompaktního okna pro komunikaci ............................................................ 76 Obrázek 10: Návrh rozšířeného kompaktního okna pro komunikaci ................................ 76 Obrázek 11: Class diagram logické vrstvy ..................................................................................... 78

89

11 SEZNAM TABULEK Tabulka 1: Terminologie použitá v této práci .............................................................................. 13 Tabulka 2: Počet nalezených aplikací včetně užitých technologií ....................................... 16 Tabulka 3: Testovací prostředí .......................................................................................................... 17 Tabulka 4: Seznam analyzovaných aplikací (řazeno abecedně) ........................................... 18 Tabulka 5: Porovnání některých nedostatků webového a desktopového řešení .......... 42 Tabulka 6: Seznam funkčních požadavků...................................................................................... 44 Tabulka 7: Kategorie nefunkčních požadavků ............................................................................. 45 Tabulka 8: Seznam nefunkčních požadavků................................................................................. 45 Tabulka 9: Seznam Use-Case 1 ........................................................................................................... 49 Tabulka 10: Seznam Use-Case 2 ........................................................................................................ 50 Tabulka 11: Seznam Use-Case 3 ........................................................................................................ 50 Tabulka 12: Seznam Use-Case 4 ........................................................................................................ 51 Tabulka 13: Seznam Use-Case 5 ........................................................................................................ 51 Tabulka 14: Popis UC01 ........................................................................................................................ 52 Tabulka 15: Popis UC02 ........................................................................................................................ 53 Tabulka 16: Popis UC03 ........................................................................................................................ 53 Tabulka 17: Popis UC04 ........................................................................................................................ 54 Tabulka 18: Popis UC14 ........................................................................................................................ 54 Tabulka 19: Popis UC20 ........................................................................................................................ 54 Tabulka 20: Popis UC21 ........................................................................................................................ 55 Tabulka 21: Popis UC22 ........................................................................................................................ 55 Tabulka 22: Popis UC27 ........................................................................................................................ 56 Tabulka 23: Popis UC29 ........................................................................................................................ 56 Tabulka 24: Popis UC38 ........................................................................................................................ 57 Tabulka 25: Popis UC39 ........................................................................................................................ 57 Tabulka 26: Popis UC40 ........................................................................................................................ 58 Tabulka 27: Popis UC43 ........................................................................................................................ 58 Tabulka 28: Popis UC44 ........................................................................................................................ 58 Tabulka 29: Zprávy použité pro výměnu informací .................................................................. 71

90

12 SEZNAM PŘÍLOH Příloha 1: CD s textem této práce, diagramy a projektem prototypu aplikace

91

13 PŘÍLOHA 1 – OBSAH PŘILOŽENÉHO CD Přiložené CD obsahuje projekt prototypu, tento dokument verzi PDF a rovněž všechny diagramy obsažené v tomto dokumentu. \BP_Sot_Pavel_1-4196-1.pdf

- bakalářská práce (tento dokument)

\Diagramy

- diagramy z tohoto dokumentu

\Projekt

- prototyp (Visual Studio 2012 solution)

92

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Recommend Documents