České vysoké učení technické v Praze Fakulta elektrotechnická
Diplomová práce
Webový návrhář kuchyní Bc. Michal Ponocný
Vedoucí práce: Ing. Martin Klíma
Studijní program: Elektrotechnika a informatika strukturovaný magisterský Obor: Informatika a výpočetní technika leden 2009
iv
Poděkování Na tomto místě bych rád poděkoval Ing. Martinovi Klímovi za odborné vedení, cenné připomínky, rady a za jeho trpělivost. Také bych rád poděkoval kolegům v týmu za spolupráci a testerům za jejich čas, který mi věnovali. v
vi
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Litoměřicích dne 22.1. 2009
.............................................................
vii
viii
Abstract This thesis is about a part of the system, which is used for 3D design of interiors. System has four parts, web application, desktop application, server application and renderer. This work describes only the web application. Web application makes possible design of interiors in a web browser without any plugins, for this purpose the services of server application and renderer are used. The web application is also used for administration of scenes, users and furniture catalogue.
Abstrakt Tato práce se zabývá vytvořením části systému na počítačový návrh interiérů. Systém má 4 části, webovou aplikaci, desktopovou aplikaci, serverovou aplikaci a renderer. Předmětem této práce je jen webová aplikace. Webová aplikace umožňuje sestavení interiérů přímo ve webovém prohlížeči bez nutnosti instalace zásuvných modulů, k tomuto účelu využívá služeb serverové aplikace a rendereru. Používá se také pro administraci scén, uživatelů a katalogu nábytku.
ix
x
Obsah Seznam obrázků
xvi
Seznam tabulek
xvii
1 Úvod
1
1.1
Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Cíle
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Struktura dokumentu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Analýza
5
2.1
Použité termíny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Požadované vlastnosti a funkce . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
Funkční požadavky . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2.1.1
Vytvoření scény . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1.2
Otevření a smazání scény . . . . . . . . . . . . . . . . .
8
2.2.1.3
Přidání objektu do scény . . . . . . . . . . . . . . . . . .
9
Existující implementace . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
2.4
2.3.1
IKEA Home Planner . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3.2
Kitchendraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.3
SmartDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.4
HGTV Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.5
Závěrečná tabulka shrnutí . . . . . . . . . . . . . . . . . . . . . .
15
Technologická studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.1
PHP framework . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.2
Databázový systém . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.3
Webová grafika . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.4
Programovací jazyk na straně klienta . . . . . . . . . . . . . . . .
19
2.4.4.1
Framework . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.4.4.2
Uživatelské rozhraní . . . . . . . . . . . . . . . . . . . .
20
Komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4.5.1
20
2.4.5
Webový klient a server . . . . . . . . . . . . . . . . . . . xi
2.4.5.2 2.4.6
PHP aplikace a editor . . . . . . . . . . . . . . . . . . .
21
Vývojové prostředí . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3 Návrh
23
3.1
Webová aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.1
Datové struktury . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.1.1
Klientská část . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.1.2
Serverová část . . . . . . . . . . . . . . . . . . . . . . . .
25
Grafická plocha scény . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.1.2.1
Objekty ve scéně . . . . . . . . . . . . . . . . . . . . . .
27
3.1.3
Životní cyklus scény . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.4
Uživatelské rozhraní . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.5
Pohledy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.1.6
Editační nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.1.7
Víceuživatelský přístup . . . . . . . . . . . . . . . . . . . . . . . .
33
3.1.8
Administrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.1
Hlavní funkce editoru . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.2
Komunikace klienta s editorem . . . . . . . . . . . . . . . . . . . .
35
Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.3.1
Komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4
Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.5
Databáze
39
3.1.2
3.2
3.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Implementace 4.1
4.2
43
Serverová část . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.1
Propojení s editorem . . . . . . . . . . . . . . . . . . . . . . . . .
44
Klientská část . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.1
Uživatelské rozhraní . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.2
Grafická plocha scény . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.3
Nalezení cílového objektu . . . . . . . . . . . . . . . . . . . . . .
46
5 Testování
47 xii
5.1
Testy komunikačního protokolu . . . . . . . . . . . . . . . . . . . . . . .
47
5.2
Testy použitelnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.2.1
Potencionální problémová místa UI . . . . . . . . . . . . . . . . .
48
5.2.2
Průběh testu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.2.3
Testující uživatelé . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.2.4
Zhodnocení testu a doporučení . . . . . . . . . . . . . . . . . . .
51
6 Závěr
53
6.1
Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.2
Návrhy na zlepšení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
7 Literatura
55
A DTD metadat
57
B Úvodní dotazník pro uživatele webového modeláře
59
C Závěrečný dotazník pro uživatele webového modeláře
61
D Scénář testu použitelnosti webového modeláře
63
E Obsah přiloženého CD
65
xiii
xiv
Seznam obrázků 1.1
Ukázka webové aplikace modelář . . . . . . . . . . . . . . . . . . . . . . .
1
2.1
Use case model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Diagram aktivit pro vytvoření scény . . . . . . . . . . . . . . . . . . . . .
8
2.3
Diagram aktivit pro otevření/smazání scény . . . . . . . . . . . . . . . .
9
2.4
Diagram aktivit pro přidání objektu do scény . . . . . . . . . . . . . . .
9
2.5
Ukázka IKEA Home Planner . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.6
Ukázka Kitchendraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.7
Ukázka SmartDraw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.8
Ukázka HGTV Designer . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.9
Vykreslení křivky div elementy pomocí knihovny Walter Zorn . . . . . .
18
2.10 Ukázka uživatelské rozhraní MochaUI . . . . . . . . . . . . . . . . . . . .
20
2.11 AJAX vs. Klasický web . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.1
Struktura systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2
Datová struktura pro uložení scény na klientovi . . . . . . . . . . . . . .
25
3.3
Složení grafické plochy scény . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.4
Stavy v jakých se může scéna nacházet . . . . . . . . . . . . . . . . . . .
28
3.5
Ukázka uživatelského rozhraní . . . . . . . . . . . . . . . . . . . . . . . .
29
3.6
Ukázka půdorysného pohledu . . . . . . . . . . . . . . . . . . . . . . . .
30
3.7
Ukázka nárysného pohledu . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.8
Ovládací kříž ve scéně . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.9
Vlastnosti objektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.10 Ukázka okna s administrací . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.11 Zarovnání objektů s průnikem . . . . . . . . . . . . . . . . . . . . . . . .
35
3.12 Ukázka XML metadat . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.13 UML Class Diagram databáze . . . . . . . . . . . . . . . . . . . . . . . .
42
4.1
UML Class Diagram MVC architektury PHP aplikace . . . . . . . . . . .
43
4.2
UML Class Diagram propojení s editorem . . . . . . . . . . . . . . . . .
44
5.1
Ukázka testovací aplikace - všechny funkce API . . . . . . . . . . . . . .
47
xv
5.2
Ukázka testovací aplikace - vybraná funkce . . . . . . . . . . . . . . . . .
47
5.3
Pomocník pro tvorbu zdí při zakládání nové scény . . . . . . . . . . . . .
48
5.4
Přístup přes kontextové menu . . . . . . . . . . . . . . . . . . . . . . . .
49
5.5
Administrační okno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.6
Nevhodně pojmenované zaškrtávací pole . . . . . . . . . . . . . . . . . .
50
5.7
Umístění kamery pro 3D pohled . . . . . . . . . . . . . . . . . . . . . . .
50
E.1 Obsah přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
xvi
Seznam tabulek 2.1
Srovnání vybraných existujících návrhářů . . . . . . . . . . . . . . . . . .
16
2.2
Nativně dostupná grafika v oblíbených internetových prohlížečích . . . .
17
3.1
Seznam možných chyb při posílání zprávy . . . . . . . . . . . . . . . . .
37
xvii
xviii
KAPITOLA 1. ÚVOD
1
1 Úvod Snad každý z nás má dnes alespoň nějakou zkušenost s internetem a webovými aplikacemi. Díky rostoucímu výkonu počítačů a počítačových sítí, nabízí internet stále více možností v oblasti komerčního i nekomerčního využití. Člověk dnes může nakupovat z pohodlí domova, může si spravovat své dokumenty, nebo fotografie online a zjišťovat nejrůznější informace. Nové technologie dnes a denně přinášejí další a další využití. Bohužel v oblasti 3D grafiky je web zatím jen v plenkách. Je jen málo technologií, které umožňují práci s 3D grafikou. A i ty fungují pouze s použitím speciálním doplňků, které si člověk musí před použitím nainstalovat. To může být pro řadu uživatelů problematické, nepohodlné a může je to odradit.
Obrázek 1.1: Ukázka webové aplikace modelář S 2D grafikou je to již na webu o trochu lepší. Naskýtá se nám tedy možnost využít moderních webových technologií pro práci s 2D grafikou. Propojením s desktopovou aplikací na straně serveru pak můžeme přinést webu nové funkce a využití i v oblasti 3D
2
KAPITOLA 1. ÚVOD
grafiky. A právě vytvořením takovéto webové aplikace se zabývá tato diplomová práce. Při vytváření jsem spolupracoval s kolegou Jiřím Beranem, jehož diplomová práce spočívá v implementaci desktopové aplikace a serverového editoru, jehož služeb má aplikace využívá. Renderer dodal kolega Michal Hapala.
1.1
Motivace
Naší motivací tedy bylo vytvořit systém, který by umožňoval 3D návrh interiérů (například kuchyní) přímo ve webové aplikaci, aniž by byl uživatel nucen instalovat do prohlížeče nějaké zásuvné moduly. Hlavní idea je tedy taková, že by si uživatel mohl ve svém prohlížeči navrhnout například kuchyň podle svých představ a následně ji odeslat výrobci k detailnímu zpracování. Webová aplikace by uživateli poskytovala stejný komfort jako klasická desktopová aplikace. Výrobce by mohl zadanou kuchyň otevřít buď opět prostřednictvím webové aplikace v administrátorském režimu, nebo pomocí desktopové aplikace. Výhodou pro zákazníka by tedy bylo to, že by si mohl u svého počítače sám, bez nějakých hlubších počítačových znalostí, sestavit kuchyň dle svých představ. Také by mohl získat realistické náhledy na celou sestavu a tak i lepší představu o tom, jak bude jeho kuchyň vypadat. Nakonec by pak mohl zakázku odeslat k dalšímu zpracování.
1.2
Cíle
Mým hlavním úkolem tedy bylo vytvořit webovou aplikaci, která by umožňovala vytváření a práci se scénou s obdobným uživatelským komfortem a funkcionalitou jako je tomu u běžné desktopové aplikace (tzv. Rich Internet application). Aplikace musí být dostupná v naprosté většině dnešních webových prohlížečů a bez nutnosti instalace dalších rozšíření do prohlížeče. Zároveň také musí využívat služeb desktopové aplikace na serverové straně. Druhým úkolem byl společný návrh propojení mezi webovou aplikací a serverovým jádrem. To zahrnovalo návrh databáze, metadat objektů scény a komunikačních protokolů mezi webem a jádrem. Poslední částí pak byl návrh administrační části webu, která by umožňovala správu uživatelů, všech scén a kompletní správu katalogu nábytku.
KAPITOLA 1. ÚVOD
1.3
3
Struktura dokumentu
Dokument je členěn do sedmi kapitol. V první kapitole se nachází úvod a jsou zde specifikovány hlavní důvody, proč tato práce vznikla. Druhá kapitola obsahuje analýzu problému. Jsou zde popsány již existující implementace zabývající se podobným tématem, jaký je řešen v této práci. Hlavně jsou popsány jejich výhody a nevýhody a na závěr i srovnání. V druhé části se kapitola zabývá volbou vhodných technologií, implementačního prostředí a dalších prostředků, které byly použity při vývoji aplikací. Třetí a zároveň nejrozsáhlejší kapitola je o návrhu aplikací. Najdete zde vysvětlení toho, jak je vše postaveno, jak probíhá komunikace mezi jednotlivými aplikacemi a jak se zpracovávají požadavky z jednotlivých částí. Následuje čtvrtá kapitola a stručný popis implementace. Dozvíte se zde o hlavních třídách a funkcích, které tvoří funkčnost celého systému. V dalších dvou kapitolách je pak popis testování aplikací a v závěru vyhodnocení cílů a navržení případných vylepšení. V poslední je pak výpis použité literatury.
4
KAPITOLA 1. ÚVOD
KAPITOLA 2. ANALÝZA
5
2 Analýza V této kapitole jsou rozebrány požadavky na aplikaci, dále jsou zde rozebrány existující implementace modelářů interiéru a technologická studie.
2.1
Použité termíny
Následuje výčet pojmů, které jsou použity v textu: • TCP – Transmission control protocol (TCP) je jedním ze základních protokolů sady protokolů Internetu. Představuje transportní vrstvu. Garantuje spolehlivé doručování dat a také doručování ve správném pořadí. • Desktopová aplikace – Jedná se o aplikaci, která je určená k instalaci a spouštění na stolním počítači. • Webová aplikace – Je to aplikace, které je poskytovaná uživatelům přes počítačovou síť (Internet, intranet). Spouští se přímo ve webové prohlížeči a je tak přístupná na jakémkoli počítači připojeném k dané síti. • 3D (three dimensional) – Zkratka označují třírozměrný prostor, kde každý objekt má svou šířku, délku a výšku. • Rendering - je tvorba reálného obrazu na základě počítačového modelu. Konečný vzhled scény lze měnit velkým množstvím parametrů a nastavení. Software, který rendering provádí se nazývá renderer (raytracer). • API – Aplication programming interface (API). Jde o rozhranní aplikace, které umožňuje využívat funkce aplikace v jiných aplikacích. Je to sbírka procedur, funkcí a tříd, které může programátor využít. • JPG – Formát rastrových obrazových souborů využívající ztrátovou kompresi JPEG. • PNG – Portable network graphics (PNG) je grafický formát používající bezeztrátovou kompresi.
6
KAPITOLA 2. ANALÝZA • XML – Extensible markup language (XML) je univerzální specifikace pro vytváření vlastních značkových jazyků. Umožňuje uživateli definovat vlastní elementy a celkovou strukturu dat, tak aby odpovídala požadavkům na popis daného systému. • DTD – Document type definition (DTD) je jazyk pro popis značkových jazyků. Omezuje skupinu dokumentů spadajících do daného typu nebo třídy. Struktura dokumentu je v DTD popsána pomocí jednotlivých elementů a atributů. • Framework – Framework je znovupoužitelný návrh softwarových systému (nebo podsystému). Softwarový framework může obsahovat podpůrné programy, knihovny a jiný software, který pomáhá vývojáři při tvorbě jiných systémů a aplikací. • Plugin / zásuvný modul - software, který nepracuje samostatně, ale pouze jako doplněk určité aplikace. Rozšiřuje její funkčnost. Obvykle využívá připraveného rozhranní aplikace (API). • RIA (Rich Internet Application) - webové aplikace, které mají rysy a funkcionalitu tradičních desktopových aplikací. RIA typicky přenášejí nezbytná zpracování pro uživatelské rozhraní na webového klienta, ale drží si množství dat na aplikačním serveru.
2.2
Požadované vlastnosti a funkce
Na aplikaci jsou kladeny některé požadavky, které vyplývají přímo, či nepřímo ze zadání a uživatelských potřeb. • Možnost interaktivního sestavení interiéru. • Využití podpory aplikace na serverové straně (editor a renderer). Výchozí platformou pro tyto aplikace je Microsoft Windows. • Podpora 3D zobrazení s využitím aplikací na serverové straně. • Funkčnost webové aplikace ve většině používaných prohlížečů, bez potřeby instalace zásuvných modulů. • Využití pouze volně dostupných technologií.
KAPITOLA 2. ANALÝZA 2.2.1
7
Funkční požadavky
Systém pracuje s čtyřmi rozdílnými uživatelskými rolemi. Jsou to administrátor, desktopový uživatel, registrovaný uživatel a neregistrovaný uživatel. Každý uživatel má svá práva a funkce. Use case model na obrázku 2.1 znázorňuje jak hierarchii jednotlivých uživatelů, tak jejich možnosti práce se systémem.
Obrázek 2.1: Use case model Jak je patrné z use case modelu, rolí s největšími právy v systému je administrátor. Má nejvyšší možná práva, k dispozici má tedy veškerou funkčnost webové aplikace a může využívat i desktopové aplikace. Prostřednictvím webu má tak možnost spravovat uživatele, katalog nábytku a s pomocí webu či desktopu spravovat scény všech uživatelů. Jeho hlavním úkolem je kontrola a správa celého systému. Pod administrátorem je desktopový uživatel, ten není obsahem této práce. Má pov-
8
KAPITOLA 2. ANALÝZA
oleno používat desktopovou aplikaci a zde vytvářet, editovat a ukládat vlastní scény. Jeho právem je i editovat scény ostatních uživatelů. Jeho úkolem je zpracovávat scény webových uživatelů. Již výrazněji omezená práva v systému má registrovaný uživatel. Ten může pouze používat webovou aplikaci a tam vytvářet, editovat a mazat pouze své scény. Nemá žádné úkoly, pouze dle svých potřeb využívá možností systému. Neregistrovaný uživatel je jakýkoliv návštěvník webu. Jeho možností je pouze se zaregistrovat, následně se přihlásit a tím povýšit svá práva na registrovaného uživatele.
2.2.1.1
Vytvoření scény
Vytváření scény ve webové aplikaci je hlavní funkcí celého systému. Předpokladem pro vytvoření scény je přihlášení uživatele. Neregistrovaný uživatel má možnost se nejprve registrovat. Na aktivity diagramu (obrázek 2.2) je zobrazen průběh vytváření scény.
Obrázek 2.2: Diagram aktivit pro vytvoření scény
2.2.1.2
Otevření a smazání scény
Další funkčností je otevření, či smazání scény zobrazené na obrázku 2.3. Předpokladem je opět autentizace uživatele. Běžnému registrovanému uživateli jsou povoleny otevírat pouze jeho vlastní scény. Administrátor i uživatel desktopu má navíc práva zobrazit a
KAPITOLA 2. ANALÝZA
9
následně otevřít/smazat všechny scény.
Obrázek 2.3: Diagram aktivit pro otevření/smazání scény
2.2.1.3
Přidání objektu do scény
Do scény jsou rovněž přidávány, mazány, upravovány objekty (např. zdi, nábytek atd.). Přidání objektu do scény (obrázek 2.4) musí předcházet opět přihlášení. Další podmínkou je předchozí otevření scény. Administrátor a desktopový uživatel má také práva na přidávání objektů do všech scén. Úprava a mazání objektu ve scéně je obdobné.
Obrázek 2.4: Diagram aktivit pro přidání objektu do scény
2.3
Existující implementace
Na trhu lze najít poměrně značné množství návrhářů interiérů, avšak řešení podobné tomu, kterým se zabývá tato diplomová práce jsem nenašel. Většinou se jedná o desktopové aplikace, které je třeba nejprve stáhnout a nainstalovat. Poté sice mohou poskytnout větší možnosti a rychlost především po grafické stránce,
10
KAPITOLA 2. ANALÝZA
nutnost instalace může ale některé uživatele odradit. Dalším problémem může být také dostupnost aplikace pro operační systém uživatele. Další skupinu tvoří návrháře pracující sice přímo v prohlížeči, ale jejich funkčnost je závislá na určitém zásuvném modulu, nebo navíc i na daném prohlížeči. Zásuvný modul nemusí také fungovat pro všechny prohlížeče stejně, ani ho nemusí všechny prohlížeče podporovat, což je velmi časté. Zde uvádím přehled čtyř nejzajímavějších aplikací, na které jsem během hledání narazil a které jsem osobně vyzkoušel. Každá aplikace něčím vyniká, ať již se jedná o přívětivé uživatelské rozhraní, speciální funkčnost, nebo dostupnost. Jedná se o tři desktopové aplikace a jednu webovou.
2.3.1
IKEA Home Planner
Jedná se o desktopovou aplikaci, kterou lze volně stáhnout přímo z webových stránek firmy IKEA. Při navrhování scény se začíná definováním místnosti, kdy si uživatel zvolí základní tvar místnosti a zadá rozměry zdí. K dispozici je poměrně rozsáhlá knihovna objektů. Nevýhodou je, že si uživatel nemůže vkládat nebo vytvářet vlastní objekty. Výběr je tedy omezen pouze objekty z produkce firmy IKEA, u kterých není možné měnit rozměry, je možné pouze vybírat z omezené nabídky materiálů. Návrh scény lze provádět ve dvou pohledech, ve 3D perspektivě a v půdorysu. Přičemž pohyb v perspektivě není příliš uživatelsky příjemný. Po dokončení editace je možnost prohlédnout si seznam objektů scény a provést kalkulaci celé sestavy. Scénu lze lokálně uložit, nebo ji odeslat na server společnosti a poté se můžete vrátit k editaci kdekoliv jinde s přístupem k internetu např. při osobní návštěvě obchodu. K tomu ale musí být uživatel registrován. Aplikace neumožňuje export dat do jiných formátu a tím i přenositelnost scény do jiných 3D návrhářů. Scénu nelze vykreslit v realistickém náhledu. nevýhody • omezené možnosti tvarů místnosti • pouze skřínky z produkce IKEA • omezené možnosti volby materiálů, rovněž z produkce IKEA
KAPITOLA 2. ANALÝZA
11
Obrázek 2.5: Ukázka IKEA Home Planner • žádný realistický náhled scény (rendering) výhody • odeslání dat přímo do IKEA a následná editace kdekoliv jinde • kalkulace ceny
2.3.2
Kitchendraw
Profesionální nástroj na návrh interiérů, který je možné stáhnout z webových stránek. Uživatel má k dispozici 30 hodin používání zdarma, poté již uživatel musí další hodiny zakoupit. Aplikace má mnoho možností při návrhu scény a mnoho nástrojů pro zjednodušené modelování. Navrhování scény začíná zadáním informací o zakázce. Pokračuje se definováním místnosti, které nabízí oproti IKEA Home Planneru více možností a větší volnost ve tvarech
12
KAPITOLA 2. ANALÝZA
Obrázek 2.6: Ukázka Kitchendraw zdí. Zdi lze dodělávat i v průběhu editace scény. Přidávání objektů umožňuje opět rozsáhlá knihovna. U jednotlivých objektů lze měnit rozměry, materiály povrchů a další parametry. Aplikace nabízí i několik pohledů, ze kterých lze scénu modelovat. Hotovu scénu lze exportovat do celé řady formátů. Jedná se hlavně o obrazové formáty (JPG, BMP) a také 3D formáty, čímž umožňuje přenositelnost scény do jiných 3D modelářů. Kitchendraw dává k dispozici i dva vlastní způsoby renderování scény a velkou škálu materiálů. nevýhody • placený provoz • nelze vytvářet vlastni objekty výhody • velké množství funkci pro editaci scény • kalkulace ceny
KAPITOLA 2. ANALÝZA
13
• export dat do širokého spektra formátů
2.3.3
SmartDraw
SmartDraw patří mezi profesionální návrháře interiérů. Je možné stáhnout zkušební verzi zdarma s omezeným počtem spuštění, poté si uživatel musí zakoupit plnou verzi.
Obrázek 2.7: Ukázka SmartDraw Aplikace nabízí velké množství šablon pro tvorbu místností. Při spuštění se otevře okno, ve kterém si uživatel může vybrat šablonu, podle které se mu iniciálně nastaví modelovací prostor. Je zde i možnost prázdného prostoru. Po vybrání šablony se objeví nárysný náhled, který je bohužel jediným možným. Objekty lze opět přidávat z knihovny, která obsahuje velké spektrum objektů rozdělených do mnoha kategorií. Scénu lze exportovat do mnoha formátu, jak obrazových (JPG, BMP), tak i například do formátu HTML. Aplikace neumožňuje export do 3D formátů a tak znemožňuje přenositelnost vytvořené scény, rovněž také není možné vygenerovat realistický náhled scény. nevýhody
14
KAPITOLA 2. ANALÝZA • návrh pouze v nárysu • žádný realistický náhled scény • chybí nastavení materiálů
výhody • velké množství nástrojů pro editaci scény • uživatelsky příjemné prostředí • export dat do širokého spektra formátů
2.3.4
HGTV Designer
HGTV Designer je aplikace, která běží přímo ve webové prohlížeči. Nevýhodou je, že aplikace běží pouze v Internet Explorer verze vyšší než 5.5. Také je potřeba mít nainstalovaný speciální ActiveX doplněk (plugin), který se instaluje při spuštění aplikace.
Obrázek 2.8: Ukázka HGTV Designer
KAPITOLA 2. ANALÝZA
15
Editace scény se odvíjí od výběru šablony, kterou si uživatel vybere v úvodním nastavení scény. Objekty lze přidávat opět s přiložené knihovny. Lze u nich měnit rozměry i materiály. Scénu lze editovat ve dvou základních pohledech, v půdorysu a perspektivě. Navigace ve scéně je velice omezená, pohledem nelze volně otáčet. Vytvořenou scénu si může uživatel uložit, ale bez registrace uživatele je scéna uložená pouze po dobu zapnutého prohlížeče. Není možné exportovat scénu do jiných formátů. Tím pádem není scéna přenositelná. Aplikace nenabízí realistické renderování scény. Editace scény je poměrně uživatelsky nepříjemná. nevýhody • běží pouze v Internet Exploreru 5.5 a výše • nutnost instalace ActiveX prvku • žádný realistický pohled výhody • není nutná instalace na desktop • možnost práce a ukládání scén i pro neregistrované uživatele
2.3.5
Závěrečná tabulka shrnutí
V tabulce 2.1 je znázorněno porovnání hodnocených modelářů dle zvolených parametrů. Parametry jsem volil takové, které by mohli uživatele nejvíce zajímat. Jde zejména o dostupnost, cenu, přenositelnost a možnosti zobrazení.
2.4
Technologická studie
Při hledání vhodného programovacího jazyka jsem se rozhodoval především mezi PHP [12] a Ruby s webovým frameworkem Ruby on Rails. Railsy v poslední době zažívají velký rozmach a mne také poměrně zaujaly tím, jak rychle je v nich možné něco vytvořit a jak krátký kód umožňují psát. Nakonec však padla volba na PHP ve verzi 5.2. Podpora
16
KAPITOLA 2. ANALÝZA
IKEA Home
Kitchendraw
SmartDraw
Planner
HGTV
De-
signer
cena
zdarma
3 euro/hodina
$197
zdarma
online
ne
ne
ne
ano
export
ne
ano
ano
ne
ne
ano
ne
ne
ne
ano
ne
ne
obrazu 3D
re-
alistické zobrazení export
do
3D formátu Tabulka 2.1: Srovnání vybraných existujících návrhářů OOP je v této verzi již v celku dobrá, navíc PHP je široce dostupné na webhostinzích. Dalším důvodem k volbě byla také osobní zkušenost s vývojem aplikací v tomto jazyce.
2.4.1
PHP framework
Výběr kvalitního frameworku nejen pro PHP dokáže značně ušetřit práci a čas vývojáře. Pro PHP existuje celá řada dobrých frameworků. Já jsem volil dnes již asi nejrozšířenější ZEND Framework, důvodem byla také předchozí zkušenost [17]. Jedná se o velmi kvalitní objektově orientovaný framework založený na návrhovém vzoru Model-View-Controller od společnosti ZEND technologies. ZEND Framework je poskytován pod novou BSD licencí. Jeho hlavní snahou a cílem je: • vytvořit standard v tvorbě pokročilejších PHP aplikací • poskytnout vývojářům vysoce kvalitní nástroje pro jejich práci • vytvořit stabilní a bezchybný framework • vytvořit novou štábní kulturu (Zend Framework Coding Standard) Framework obsahuje velké množství komponent, je velmi dobře dokumentovaný a stále v intenzivním vývoji. Rovněž se značně rozrůstá množství vývojářů, kteří jej používají.
KAPITOLA 2. ANALÝZA 2.4.2
17
Databázový systém
Výběr databázového systému proběhl společně s mým kolegou Jiřím Beranem. Zvolili jsme dosti rozšířený systém MySQL verze 5 a vyšší [9]. Nejedná se samozřejmě o špičku ve svém oboru, pro naše účely je však dostačující, dostupný i pod volnou licencí GPL. Rovněž je tento DB systém dostupný na většině webhostingů.
2.4.3
Webová grafika
Výběr vhodné technologie pro grafiku na webu byl poměrně složitý problém, jelikož jak již bylo řečeno výše, v tomto ohledu nejsou webové technologie příliš rozvinuté a zaběhnuté. Pokud se ještě musíme omezit na technologie, které jsou dostupné v prohlížeči nativně, tedy i bez nutnosti instalace zásuvného modulu do prohlížeče, musíme zavrhnout i Flash a Javu. V tabulce 2.2 jsou shrnuty nativně dostupné možnosti, jak vytvářet jednoduchou grafiku v prohlížeči. VML
SVG
CANVAS
NE (plugin Adobe SVG) ANO (excanvas)
div-Pixel
IE 6+
ANO
ANO
Firefox 2+
NE
ANO
ANO
ANO
Safari 3+
NE
ANO
ANO
ANO
Opera 9+
NE
ANO
ANO
ANO
Chrome
NE
ANO
ANO
ANO
Tabulka 2.2: Nativně dostupná grafika v oblíbených internetových prohlížečích Jednou z možností by bylo použití JavaScriptu a CSS na straně klienta v kombinaci s GD knihovnou pro PHP na straně serveru. Pomocí JavaScriptu a změn CSS je možné pohybovat s elementy DOM, v našem případě tedy náhledy jednotlivých objektů ve scéně (elementy typu img). Prostřednictvím GD knihovny by pak byly náhledy rotovány, případně by jim byla změněna velikost. Některé geometrické tvary by bylo možné vykreslit na klientovi s pomocí JavaScriptové knihovny Walter Zorn jsGraphics [16]. Takto vytvořená grafika je složena z elementů typu div (obrázek 2.9), jejich počet je závislý na daném tvaru a jeho velikosti. Tato metoda by byla dostupná pro všechny prohlížeče,
18
KAPITOLA 2. ANALÝZA
znamenala by však řadu omezení. Jednalo by se například o výkonové problémy při vykreslování značného množství elementů typu div, které vygeneruje jedna křivka.
elementy typu div Obrázek 2.9: Vykreslení křivky div elementy pomocí knihovny Walter Zorn Další možností je VML (Vector Markup Language) [19], který umožňuje vytváření vektorové grafiky. Jedná se o obdobu SVG dostupnou pouze pro Internet Explorer. Nejvíce v úvahu připadly zbylé dvě možnosti. První z nich je SVG (Scalable Vector Graphics), jedná se o značkovací jazyk, který popisuje dvojrozměrnou vektorovou grafiku pomocí XML. V budoucnu se měl stát základním otevřeným formátem pro vektorovou grafiku na Internetu, skutečnost je zatím jiná a podpora v prohlížečích není tak dobrá. V době, kdy jsem se rozhodoval zda použít SVG byla situace ještě o něco horší. Lépe je na tom pak poměrně nový element typu canvas [2] z HTML5, který nyní zažívá velký rozmach. Umožňuje kreslení jednoduché grafiky pomocí skriptování (obvykle JavaScriptem). Může to být například vykreslování grafů, komponování obrázku, jednoduchých (i složitějších) animací. Element typu canvas byl poprvé uveden firmou Apple pro Dashboard v Mac OS X a později implementován do Safari. Nyní již tento prvek podporuje i Opera a novější verze prohlížeče založené na jádře Gecko (Firefox). Ve výčtu podporovaných prohlížečů není uveden Internet Explorer. To lze naštěstí řešit instalací zásuvného modulu pro XForms od firmy Novell, jenž poskytuje podporu i pro canvas. Druhou možností je pak emulace s pomocí JavaScriptu a VML. Společnost Google vytvořila projekt s názvem ExplorerCanvas [4], který využívá stejné techniky. Jedná se o 20kB JavaScriptový soubor, který stačí s pomocí podmíněných komentářů vložit do stránky. Dalším problémem je, že canvas API zatím nezahrnuje možnost vykreslování textových řetězců. To lze obejít knihovnou canvastext [3], která za pomoci křivek ručně vykreslí
KAPITOLA 2. ANALÝZA
19
jednotlivé znaky. Zatímco tedy 2D grafika v canvasu se již pomalu stává realitou, na 3D si ještě budeme muset chvíli počkat. V posledních verzích Firefoxu a Opery sice již obsažen je, ale přístup Opery k 3D canvasu se zatím trochu liší od přístupu Mozilly. Otázku renderingu 3D realistického náhledu za nás ale bude řešit serverová aplikace s rendererem, jejíž výstupem bude obrázek ve formátu PNG.
2.4.4
Programovací jazyk na straně klienta
Jelikož navrhovaná aplikace bude mít rysy RIA aplikací, je třeba zvolit vhodný programovací jazyk na straně klienta, pomocí kterého dodáme aplikaci na klientovi požadované dynamické vlastnosti. Volba padla na JavaScript [7]. Tento jazyk je v tomto směru nejpoužívanější, tudíž i podpora dalších technologií (např. canvas, AJAX) a množství všemožných nástrojů pro vývoj je opravdu velká. Další výhodou spojenou s rozmachem RIA, je velká snaha tvůrců internetových prohlížečů o zrychlení interpretace JavaScriptu. V současné době vedou největší souboj Safari s Firefoxem a nový webový prohlížeč Chrome od společnosti Google, který je také současným lídrem. Nadcházející verze Firefoxu 3.1 by měla být díky projektu TraceMonkey dokonce až 22x rychlejší než předchozí verze založené na Gecku 1.8x.
2.4.4.1
Framework
Podobně jako u PHP i zde bylo třeba vybrat vhodný framework pro usnadnění práce a i zde je k dispozici velké množství alternativ. V úvahu bylo možné brát například YUI, dojo, prototype a Mootools [8]. V tomto případě jsou všechny jmenované frameworky vysoce kvalitní a v podstatě jakákoliv volba by nebyla chybou. Nakonec jsem zvolil Mootools. Jedná se o objektově orientovaný framework kompatibilní s naprostou většinou prohlížečů (Safari 3+, Internet Explorer 6+, Firefox 2+, Opera 9+, Chrome). Není sice tak robusní jak jiné frameworky, ale je velmi silný, jednoduchý a výborně dokumentovaný. Také je v něm napsáno značné množství zajímavých projektů, které jsou volně dostupné a je tedy možné je použít. Mootools je poskytováno pod volnou MIT licencí.
20 2.4.4.2
KAPITOLA 2. ANALÝZA Uživatelské rozhraní
Zajímavými projekty, které jsou založeny na frameworku Mootools, jsou bezesporu uživatelská rozhraní webových aplikací. Pomocí nich je možné snadno vytvořit přímo v prohlížeči okenní uživatelské rozhraní. Měl jsem možnost volit ze dvou variant, a sice Windoo a MochaUI [14]. Rozhodl jsem se právě pro aplikaci MochaUI, která je propracovanější a její tvůrci jsou aktivnější. MochaUI využívá také elementu typu canvas při tvorbě oken a v podstatě celého uživatelského rozhraní. Funkčnost je zajištěna ve stejných prohlížečích jako u Mootools frameworku. Ukázka je na obrázku 2.10.
Obrázek 2.10: Ukázka uživatelské rozhraní MochaUI
2.4.5
Komunikace
V následujících dvou kapitolách jsou rozebrány možné druhy komunikace, mezi jednotlivými částmi systému.
2.4.5.1
Webový klient a server
Jedním z požadavků na naší aplikaci je možnost interaktivního sestavení nábytku. Abychom poskytli uživateli podobný komfort jako u desktopové aplikace, budeme muset
KAPITOLA 2. ANALÝZA
21
využít technologie, která nám umožní výměnu dat mezi webovým klientem a serverem bez nutnosti znovunačtení celé stránky. Právě za tímto účelem vznikla dnes velmi populární technologie AJAX (Asynchronous JavaScript and XML). Tato technologie využívá JavaScriptu a XMLHttpRequestu. Pomocí JavaScriptu můžeme zakomponovat do stránky nově přijaté informace ze serveru. Výměna dat mezi klientem a serverem probíhá prostřednictvím XMLHttpRequestu. Obrázek 2.11 ilustruje rozdíly mezi AJAX a klasickou web aplikací [18].
Obrázek 2.11: AJAX vs. Klasický web Typickým přenosovým formátem pro asynchronní výměnu dat s webovým serverem je XML. Dále je možné využít HTML, prostého textu, nebo JSON [13]. My využijeme HTML pro přenos obsahu některých částí stránky a JSON pro výměnu dat. JSON jsem zvolil proto, protože je snadno čitelný i zapisovatelný člověkem a snadno analyzovatelný i generovatelný strojově.
2.4.5.2
PHP aplikace a editor
Další z požadavků na aplikaci je propojení PHP a editoru napsaného v C++. V úvahu připadly následující dvě možnosti. První z nich bylo vytvoření PECL rozšíření PHP [10] a jeho následné zakomponování na webovém serveru.
22
KAPITOLA 2. ANALÝZA
Druhou a snazší možností, bylo využití komunikace posílání zpráv prostřednictvím TCP socketů. Tato možnost je již v PHP běžně dostupná, a proto jsme jí také využili.
2.4.6
Vývojové prostředí
Výběr vývojového prostředí byl usnadněn předchozí velmi dobrou zkušeností s Eclipse s doplňkem PHP Development Tools [11] od firmy ZEND. Jedná se patrně o nejlepší volně dostupné vývojové prostředí pro PHP, které je v podstatě odlehčenou verzí komerčního ZEND Studia. Toto prostředí má velice dobrou správu projektu. Nabízí plno nástrojů pro vývoj aplikace a i pro samotné psaní kódu, například inteligentní doplňování syntaxe, metod objektů a další. Je také poměrně dobře použitelné pro psaní CSS, XML, DTD a javascriptu. Pro ladění projektu jsem použil především vývojářské doplňky dostupné pod prohlížečem Firefox. Jednalo se o Firebug [5], pomocí něhož je možné upravovat, ladit a monitorovat CSS, HTML a JavaScript přímo ve webové stránce. Dalším doplňkem byl Web developer [15] řada vývojářských nástrojů a nakonec HTML Tidy validátor [6].
KAPITOLA 3. NÁVRH
23
3 Návrh Celý systém je složen z několika komponent jak je vidět na obrázku 3.1. Centrem systému je serverová aplikace editor, která spravuje veškerá data webových i desktopových aplikací a synchronizuje všechny operace. Spolu s databází tvoří jádro celého systému. Editor je pak připojen k rendereru a využívá jeho služeb pro vykreslování jednotlivých scén.
Obrázek 3.1: Struktura systému
Přímo k jádru (tedy k editoru a databázi) je připojena desktopová aplikace a webová aplikace na webovém serveru s PHP. Z hlediska editoru jsou to rovnocenní klienti, kteří využívají jeho služeb. Pro komunikaci s ním používají databázi a posílání zpráv prostřednictví TCP spojení. Obě dvě aplikace umožňují svým vlastním způsobem práci se scénami. Webová navíc poskytuje administrátorovi možnost správy uživatelů a katalogu objektů.
24
3.1
KAPITOLA 3. NÁVRH
Webová aplikace
Webová aplikace je určena k vytváření a editaci scén podobně jako desktopová aplikace. Navíc je zde možné v administrátorském režimu spravovat katalog, uživatele a scény všech uživatelů. Uživatel má také možnost otevřít a pracovat na více scénách najednou. Aplikace je vytvořena jako víceuživatelský systém, pro její užívání je však nutné být zaregistrován. Další podmínkou je zapnutý JavaScript v prohlížeči, webová aplikace jako celek je na něm totiž silně závislá. Aplikaci můžeme rozdělit na dvě části, serverová část a klientská část. Klientská část je napsána v JavaScriptu a postavena na JavaScriptovém frameworku Mootools. Využívá také dalších knihoven, jedná se především o webové uživatelské rozhraní MochaUI a kontextové menu ddmenu. Po přihlášení do systému je na klienta nahrána základní webová stránka spolu s klientskou aplikací, která vytvoří desktopové uživatelské rozhraní. Od této doby již probíhá komunikace se serverem téměř výhradně prostřednictvím AJAXu. Díky tomu se chování celé aplikace značně podobá klasické desktopové aplikaci. Serverová část je vytvořena v PHP a založena na ZEND Frameworku. Má přístup k databázi a editoru. Serverová část reaguje na žádosti klienta, zpracovává příchozí data a pracuje s databází. V případě potřeby také komunikuje s editorem o změnách ve scéně, nebo požaduje vyrenderování obrazu scény. Bližší popis komunikačního protokolu editoru a klienta naleznete v kapitole 3.2.2.
3.1.1
Datové struktury
V následujících dvou kapitolách jsou popsány datové struktury na klientské a serverové straně.
3.1.1.1
Klientská část
Vzhledem k tomu, že při práci jsou často potřebná data o scéně a objektech v ní a opakované žádání serveru o tato data by nebylo příliš praktické a efektivní. Z tohoto důvodu je tedy nutné, mít tyto informace uložené i na klientovi, viz UML class diagram
KAPITOLA 3. NÁVRH
25
tříd 3.2, kde jsou data o scéně uložena. Při otevření scény je tedy vše potřebné nahráno ze serveru a uloženo na klienta. Při změnách ve scéně se pak již jen obnovují změněná data.
Obrázek 3.2: Datová struktura pro uložení scény na klientovi
3.1.1.2
Serverová část
Na serveru nejsou potřebné žádné datové struktury, všechny informace o otevřených, nebo zavřených scénách jsou uloženy v databázi, nebo v editoru. V databázi jsou uchovány i informace o tom, zda je scéna otevřena a kdo jí otevřel. Pokud je tedy potřeba získat jakékoliv informace o scéně a objektech v ní, musí být načteny z databáze.
3.1.2
Grafická plocha scény
Základem pro vykreslování scény jak již bylo rozebráno v kapitole 2.4.3, je element typu canvasz HTML5 . Samotný canvas není prvotně určen pro animace. Pro pohyb objektu ve scéně je nutné vykreslit celou scénu znova. To by mohlo na slabších počítačích, nebo prohlížečích s
26
KAPITOLA 3. NÁVRH
pomalejší interpretací javascriptu způsobovat výkonové problémy a pohyb by pak nebyl tak plynulý. V Internet Exploreru je navíc ještě canvas emulován pomocí VML, což celý proces ještě značně zpomalí.
Div s ovládacími prvky
Pohybující se objekt Vrchní canvas
Canvas s objekty
Spodní canvas
Obrázek 3.3: Složení grafické plochy scény Jistým vylepšením tedy je, celou kreslící plochu scény složit ze tří stejných vrstev canvasu umístěných přesně nad sebou, jak je znázorněno na obrázku 3.3. Tímto si vykreslení scény rozdělíme mezi jednotlivé vrstvy a budeme překreslovat jen to, co je v dané akci nezbytně nutné. Ve spodní vrstvě jsou zobrazovány pouze statické prvky scény, s kterými není možné pohybovat. Překresluje se jen při přiblížení, nebo oddálení scény a při pohybu se scénou. Vykreslován je zde především základní obrys scény a kóty. Prostřední vrstva slouží pro vykreslení všech objektů scény. Je překreslována společně se spodní vrstvou, nebo při změně pozice objektu. Účelem vrchní vrstvy je pak zobrazování značek aktivních objektů a obrysu objektu
KAPITOLA 3. NÁVRH
27
při pohybu. Tato vrstva je tedy nejčastěji překreslována, zároveň ale obvykle obsahuje nejméně prvků k vykreslení. Překresluje se, pokud jsou překresleny předchozí vrstvy, při změně aktivního prvku a při pohybu (tedy dle frekvence události onmousemove). Nakonec je nad všemi vrstvami ještě element typu div stejné velikosti a pozice. Na tento element jsou navázány veškeré události, jako pohyb myši a jiné. Dále jsou v něm také umístěny ovládací prvky scény.
3.1.2.1
Objekty ve scéně
Jednotlivé objekty jsou ve scéně reprezentovány náhledy ve formátu PNG, GIF, nebo JPEG. Pro každý objekt musí existovat tolik náhledů, kolik je pohledů na scénu. V našem případě tedy pohled shora, zleva, zprava, zepředu, zezadu. Všechny náhledy jsou načteny na webového klienta při vložení objektu do scény. Výsledná velikost náhledu je uzpůsobena podle aktuálního měřítka přímo v canvasu. Větší problém je natočení objektu. Jelikož je povoleno rotování objektů pouze podle osy z, je situace následovná. V půdorysném pohledu je náhled pouze natočen. Horší situace nastává u zbylých pohledů na scénu. Zde je nutno vypočítat, který náhled je v daném pohledu viditelný. Pokud je objekt natočen jinak než po 90◦ , je zobrazen nejvíce viditelný náhled a zbylá plocha je vyplněna šedou barvou. Zdi jsou zobrazovány oproti klasickému objektu odlišně. A to pouze v půdorysu, kde nejsou zobrazovány způsobem popsaným výše, ale každá zeď je vykreslena jako polygon s šedou výplní.
3.1.3
Životní cyklus scény
U editoru se scéna nachází v permanentně uloženém stavu, každá změna ve scéně je tedy již rovnou uložena. To je z pohledu uživatele poměrně nestandardní chování. Navíc kromě tlačítka zpět a vpřed, by nebylo možné vrátit scénu do původního stavu. Tento problém je tedy řešen na straně webové aplikace. Při otevření každé scény se vytvoří scéna dočasná, s kterou se pracuje ve skutečnosti a jsou do ní ukládány veškeré změny. Při žádosti o uložení je dočasná scéna zkopírována do hlavní otevřené. Naopak pokud je scéna uzavřena bez uložení, je dočasná scéna smazána a žádné změny se tak
28
KAPITOLA 3. NÁVRH
Obrázek 3.4: Stavy v jakých se může scéna nacházet při opětovném otevření neprojeví. V případě, že uživatel nechá po delší dobu beze změn otevřenou scénu, bude tato scéna automaticky uzavřena. Dočasná scéna bude uložena jako nová scéna a původní scéna bude uzavřena beze změn.
3.1.4
Uživatelské rozhraní
Před samotným přihlášením se uživateli zobrazí přihlašovací stránka s možností registrace. Po přihlášení se následně uživatel dostane do samotného modeláře interiéru. Uživatelské rozhraní je zde založeno na knihovně MochaUI, která umožňuje vytvořit rozhraní vypadající jako běžná desktopová okenní aplikace. V horní části lze nalézt hlavní menu, ze kterého lze spouštět a vybírat veškeré funkce, které aplikace nabízí. Tématicky je rozděleno do sedmi částí, v případě administrátora do osmi částí.
KAPITOLA 3. NÁVRH
29
První je nabídka Soubor, která má standardní funkci, na kterou jsou uživatelé zvyklí z jiných aplikací. Umožňuje kompletní správu uživatelových scén. Další nabídkou je Úprava. Sjednocuje volby, jako kopírování objektů, mazání apod. Důležité jsou také volby zpět a vpřed, které nabízejí možnosti vracení při provedení nechtěné operace. Následuje nabídka pro označování objektů ve scéně Vybrat. Další nabídka Objekt, obsahuje veškeré možné operace pro práci s objekty scény. Podobný význam má další nabídka Scéna, zde jsou však obsaženy volby pro práci se scénou samotnou. Pro nastavování různých pohledů a pohyb v nich slouží následující nabídka Pohledy. Zahrnuje veškeré volby, které jsou dostupné i přes nástroje umístěné ve scéně, jako například změna pohledu, přiblížení atd. Předposlední nabídka s názvem Zobrazit shrnuje práci s okny uživatelského rozhraní. Jsou zde volby např. pro různá zobrazení oken, minimalizaci, nastavení oken a další. Uživateli s administrátorskou rolí pak přibyde ještě nabídka Administrace, která obsahuje volby pro správu aplikace.
Obrázek 3.5: Ukázka uživatelského rozhraní Pod hlavním menu se nachází paleta nástrojů, která plní funkci zrychlené volby některých akcí. Obsahuje volby, u kterých je předpoklad, že budou nejvíce využívány. Na spuštění některých akcí lze použít i stisk klávesových zkratek, které můžou velmi usnadnit a zrychlit editaci a pohyb ve scéně. Ve spodní části je panel s právě otevřenými okny, pomocí kterého se mezi nimi může uživatel přepínat. V pravá části se nalézá panel s
30
KAPITOLA 3. NÁVRH
knihovnou objektů. Toto okno nabízí hierarchické procházení všech kategorií. Ve spodní části se po vybrání objektu zobrazí detailnější náhled. Hlavní funkcí je vkládání nových objektů s předem zadanými rozměry. Pro lepší přiblížení běžné desktopové aplikaci, je možné stiskem klávesy F11 zobrazit rozhraní aplikace přes celou obrazovku.
3.1.5
Pohledy
Při tvorbě interiéru jsou poměrně důležité možnosti pohledů. U naší webové aplikace jsme omezeni pouze možností 2D zobrazení. Nabízí se nám tedy celkem 5 různých pohledů ve 2D. Mezi nejvyužívanější patří pohled shora (půdorys), který dává velice jasnou představu o celé scéně a o vzájemných polohách jednotlivých objektů. Zbylé čtyři dvourozměrné pohledy pak slouží především k umístění horních skříněk (pohled zleva, zprava, zepředu, zezadu).
Obrázek 3.6: Ukázka půdorysného pohledu Poslední možností je pak trojrozměrný realistický pohled, který je možné získat díky propojení s editorem a renderem. Před jeho vytvořením je nejprve nutné definovat místo a směr pohledu. Všechny parametry je možné nastavit umístěním kamery v okně, které se otevře při žádosti o zobrazení realistického 3D náhledu. Navigaci ve dvourozměrných pohledech zabezpečuje několik nástrojů. Jedná se především
KAPITOLA 3. NÁVRH
31
Obrázek 3.7: Ukázka nárysného pohledu
o ovládací „kříž” přímo ve scéně (obrázek 3.8), pomocí kterého je možné se pohybovat ve 4 směrech a přibližovat, nebo oddalovat pohled na scénu. Přiblížení, nebo oddálení je možné také pomocí kolečka myši, nebo prostřednictvím jezdce na ovládacím „kříži”. Další možností tohoto nástroje je automatické nalezení nejvhodnější polohy a přiblížení tak, aby byla v okně viditelná celá scéna.
Obrázek 3.8: Ovládací kříž ve scéně
Pohyb se scénou je rovněž možný uchopením plátna myší a jeho následné posunutí zvoleným směrem. Všechny tyto volby jsou samozřejmě dostupné i z hlavního menu.
32 3.1.6
KAPITOLA 3. NÁVRH Editační nástroje
Aplikace nabízí tři základní editační nástroje a další podpůrné nástroje. Rotace, posunutí a změna rozměrů patří mezi ty základní. Jsou umístěny v nabídce Úprava v hlavním menu. Volit se dají i z palety nástrojů pod hlavním menu. Nástroj posunutí umožňuje měnit polohu objektu ve scéně. Dalším editačním nástrojem je rotace. Ta je možná pouze v ose z. Poslední možností úpravy objektu je změna velikosti. Rozměry objektu je možné měnit prostřednictvím vlastností objektu (viz obrázek 3.9). Tato volba je dostupná z hlavního menu, palety nástrojů, nebo kontextového menu objektu. Také se zde nachází možnost změny pozice, či rotace objektu.
Obrázek 3.9: Vlastnosti objektu
Mezi podpůrné nástroje patří především kopírování již existujících objektů se všemi jejich vlastnostmi i z jedné scény do druhé. Dalšími jsou nástroje na označování objektů. Je možné vybírat všechny objekty, dělat inverzní výběry, nebo se stisknutým tlačítkem shift dělat vlastní výběr. Užitečné při editaci mohou být i volby menu zpět a vpřed, které mohou snadno vrátit nechtěnou editaci. To je zajištěno pomocí fronty, která obsahuje vždy akci zpět i vpřed. Jelikož je možné otevřít více scén najednou, je pro každou scénu vytvořena její vlastní fronta. Při provedení jakékoliv editace scény se do fronty uloží provedená operace i operace inverzní. Fronta má omezenou kapacitu, při naplnění této kapacity se nejstarší
KAPITOLA 3. NÁVRH
33
operace nenávratně vymaže. Potřebná data pro tyto operace jsou uložena jen v datové struktuře na webovém klientovi. Při obnovení celé stránky jsou tedy nenávratně ztracena.
3.1.7
Víceuživatelský přístup
Do aplikace je samozřejmě umožněno přistupovat více uživatelům najednou. Systém zajišťuje a dohlíží na přístup uživatele jen do částí systému, kam má daná uživatelská role právo přístupu. Blíže jsou role a jejich práva popsána v kapitole 2.2.1. Rovněž je nutné zajistit, aby dva uživatelé (např. administrátor a registrovaný uživatel ) nemohli současně pracovat na jedné a té samé scéně. Tím by docházelo ke změnám, o kterých by jeden, nebo druhý uživatel nevěděl. Oba by si tedy scénu vzájemně měnili. Serverový editor tento problém neřeší, bylo jej tedy nutné vyřešit na straně webové aplikace. Do databáze byl tedy přidán atribut editor, který určuje, kým je daná scéna právě otevřena. Další uživatel již tedy nemůže scénu otevřít.
3.1.8
Administrace
Administrace je přístupná uživateli s administrátorskými právy přes položku Administrace v hlavním menu. Toto menu umožňuje volit mezi správou uživatelů, scén a katalogu. Po vybrání dané položky menu se zobrazí nové okno (obrázek 3.10) se seznamem položek. Důležitou možností zvláště při větším množství dat je procházení po stránkách, řazení a filtrování seznamu.
Obrázek 3.10: Ukázka okna s administrací Správa scén zahrnuje procházení všech scén uživatelů, jejich upravování a mazání. V ad-
34
KAPITOLA 3. NÁVRH
ministraci katalogu je možné vytvářet jednotlivé kategorie, nábytek a rozřazovat nábytek do kategorií. Při vytváření nového nábytku je kromě běžné kontroly vstupních polí kontrolováno také XML s metadaty. Kontrola spočívá v prověření správné struktury XML pomocí XML Schématu. Dále jsou kontrolovány také materiály a typy segmentů, které odkazují do databáze. Poslední možností administrátorského menu je správa uživatelů. Zde je možné vytvářet, upravovat a mazat uživatele, součástí je také přiřazování uživatelských rolí.
3.2
Editor
Tuto aplikaci vyvíjel kolega Jiří Beran jako součást své diplomové práce. Editor je jádrem celého systému. Komunikuje s databází, rendererem, webovou i desktopovou aplikací. Ve své datové struktuře uchovává veškeré informace o právě otevřených scénách a na požádání vykonává operace s jednotlivými scénami a objekty v nich. Editor je koncipován jako vícevláknová serverová aplikace. Díky tomu je schopna obsloužit více požadavků v jednom okamžiku.
3.2.1
Hlavní funkce editoru
Z hlediska webové aplikace zastává editor tři důležité funkce: 1. Kontrola polohy objektu ve scéně - Tato funkce vznikla ze dvou důvodů. Prvním je zamezení průniku objektů ve scéně a druhým důvodem je usnadnění editace scény, jelikož tato funkce k sobě zarovnává objekty, které mají nenulový průnik viz obrázek 3.11. Bližší informace samotné kontrole naleznete v diplomové práci Jiřího Berana. 2. Uklízení nepoužívaných scén - Jedná se o poměrně důležitou funkci, která zabrání hromadění otevřených a již nepoužívaných scén v editoru. Takové scény mohou vznikat např. vypnutím prohlížeče bez předchozího uzavření scény. Editor se tedy stará o to, aby se uzavřely scény, které již nebyly dlouhou dobu použity. Každých pět minut se probudí vlákno, které kontroluje časovou známku scény (tedy čas poslední změny ve scéně). Pokud je překročen časový limit je scéna automaticky
KAPITOLA 3. NÁVRH
35
Obrázek 3.11: Zarovnání objektů s průnikem uzavřena. 3. Rendererování - Editor samostatný rendering neprovádí, ale potřebná data drží ve svých datových strukturách. Při žádosti o renderování se pak spojí s rendererem, odešle mu vše potřebné a samotné renderování přenechá jemu. Jako odpověď klientovi pak odešle přijatý obrázek od rendereru. Samotná webová aplikace tedy o rendereru vůbec neví.
3.2.2
Komunikace klienta s editorem
Komunikace mezi editorem a webovou, či desktopovou aplikací probíhá prostřednictvím TCP spojení a databáze. Nejprve se vytvoří TCP socket, který představuje otevřené spojení. Webová aplikace pošle požadavek na vykonání určité funkce v podobě textové zprávy. Pokud odpověď přijde v časovém limitu, tak aplikace odpověď zpracuje. Vlastnímu poslání požadavku může předcházet uložení hodnot do databáze, které si následně editor podle typu dané akce načte a zpracuje.
36
KAPITOLA 3. NÁVRH
Zprávy jsou posílány v následujícím formátu: Jmeno_Funkce(param1, ... ,paramN) Souhrn funkcí, na které umí editor reagovat (bez parametrů): • newScene - vytvoření nové scény • openScene - otevření scény • closeScene - zavření scény • deleteScene - smazání scény • addSceneObject - přidání objektu do scény • editSceneObject - změna velikosti, rotace, pozice objektu • removeSceneObject - odstranění objektu ze scény • renderScene - vyrenderování scény • changeMaterial - změna materiálu dle daného módu Jako odpověď mohou přijít 2 typy zpráv. Prvním typem je potvrzení. To říká, že volání funkce bylo v pořádku a funkce byla úspěšně vykonána. V případě chyby zpracování nebo vykonání se pošle chybová hláška, která obsahuje i číslo příslušné chyby viz tabulka 3.1.
3.3
Renderer
Aplikaci renderer vyvíjel kolega Michal Hapala. Webová aplikace využívá služeb rendereru jen prostřednictvím editoru, který s ním komunikuje přímo. Z pohledu webové aplikace je tedy renderer skryt za editorem. Uvádím zde tedy jen hrubý popis. Renderer je vícevláknová serverová aplikace, která na požádání vyrenderuje vybranou polygonální scénu. Díky možnosti využití více vláken je renderer schopen zpracovat více scén v jednom okamžiku. To je důležitá podmínka pro fungování v celém systému, jelikož požadavků na vyrenderování scény může od různých uživatelů přijít několik v jednom okamžiku.
KAPITOLA 3. NÁVRH
Číslo
37
Popis chyby
1
špatný formát zprávy
2
špatné jméno funkce, funkce neexistuje
3
špatný počet parametrů
4
špatný typ parametru
5
scéna neexistuje
6
objekt neexistuje
7
chyba komunikace s databází
8
málo paměti k provedení operace
9
jiná chyba
Tabulka 3.1: Seznam možných chyb při posílání zprávy 3.3.1
Komunikace
Komunikace s rendererem probíhá prostřednictvím TCP spojení. Jakmile editor dostane žádost o vykreslení určité scény, spojí se s rendererem, který neustále poslouchá na určitém portu. Při úspěšném spojení se začínají posílat informace potřebné pro vykreslení. Nejprve pozice kamery, kterou editorem přijme od webové nebo desktopové aplikace. Následují počty objektů a světel. Na závěr se pošle barva pozadí. Další v pořadí jsou materiály. Seznam materiálů se načítá z databáze a postupně se posílají informace o každém z nich. Poté se posílají bloky vrcholů a ploch a vše je zakončeno blokem světel. Mezitím, co renderer počítá výsledný obraz, editor čeká na příjem obrázku. Po dokončení výpočtu, renderer odešle editoru výsledný obrázek ve formátu PNG. Ten si jej uloží do dočasného úložiště a obrázek přepošle aplikaci, která si vykreslení vyžádala. Tímto je proces renderování ukončen.
3.4
Metadata
Metadata jsou v systému určeny pro popis vlastností a geometrie jednotlivých objektů z knihovny. Jsou uložena ve formátu XML v databázi. Mimo to jsou ještě na websereveru pro účel webu uloženy náhledy jednotlivých objektů. Formát byl navržen přesně podle
38
KAPITOLA 3. NÁVRH
potřeb systému. Jedná se o data statická, která tedy zůstávají stejná i při změnách velikosti daného objektu. V příloze A je uvedeno DTD metadat, ukázka XML je na obrázku 3.12.
Obrázek 3.12: Ukázka XML metadat Všechna data jsou uzavřena v párové značce furniture, která je povinná a nemá žádné atributy. Pak následuje série značek, které popisují vlastnosti celého objektu. První je značka name, která v sobě obsahuje jméno objektu. Je párová a bez atributů. Následuje párová značka contact_surface, která je povinná a uzavírá šest nepárových značek (front, back, right, left, bottom a top), které určují to, z jakých stran se mohou ostatní objekty přilepovat. Každá z těchto šesti značek obsahuje atribut dist, který představuje minimální vzdálenost, která musí být mezi touto určitou hranou a dalším objektem. Pokud se k hraně mohou další objekty přilepit, tak se značka neuvádí. Další nepárová značka hang_up říká, zda-li jde o objekt určený k zavěšení (horní skřínka) nebo objekt, který leží na zemi (dolní skřínka, zeď atd.). Rozhoduje o tom nastavení atributu up, ten nabývá hodnot true a false. Poslední značkou je geometry, která v sobě obsahuje geometrický popis objektu a jeho částí. Jedná se o párovou a povinnou značku.
KAPITOLA 3. NÁVRH
39
Prvním nepárovým a povinným potomkem této značky je bounding_box se třemi atributy width, depth a height určuje rozměry objektu v milimetrech v jeho standardním provedení. Následuje značka dimension s šesti atributy (min_w, min_d, min_h, max_w, max_d, max_h) je důležitá pro operaci změny rozměrů objektu. Atributy totiž představují minimální a maximální rozměry objektu. Důvodem pro toto omezení je, že ne všechny rozměry jednotlivých částí jsou závislé přímo na rozměrech objektu a proto by mohlo docházet k nechtěným deformacím objektu. Poslední značkou v této sekci je segments, která popisuje jednotlivé části (segmenty) objektu. Každý segment je uzavřen v párové značce seg, který má tři atributy name, type a material. Atribut type uvádí interní označení typu segmentu, které se používá při některých operacích. Značka bounding_box má stejný význam u segmentu jako u celého objektu. Hodnoty uvedené v jeho atributech mohou být absolutní (rozměry v milimetrech) nebo relativní (procentuální vyjádření vztahu k celkovým rozměrům objektu). Další značkou je pivot, která svými třemi atributy (x, y, z ) určuje umístění počátku segmentu v objektu. K tomuto bodu jsou vztaženy i souřadnice vrcholů popisující segment. Vrcholy jsou uzavřeny v párové značce coord. Každý vrchol je popsán třemi souřadnicemi (x, y, z ), které jsou odděleny čárkou, jednotlivé vrcholy jsou pak odděleny středníkem. Souřadnice mohou být opět relativní i absolutní. Poslední značkou popisující segment je coordindex. Je to pole obsahující seznam ploch (trojúhelníku). Plocha je definovaná třemi indexy do pole chord, které jsou odděleny čárkou. Jednotlivé plochy jsou odděleny středníkem. Takto navržená metadata umožňují inteligentní změnu rozměru všech objektů. To znamená, že rozměry jako například tloušťka desky nebo rozměry madla se při změnách rozměrů celého objektu nemění. Výsledkem je realistický tvar objektu v jakémkoli rozměru v případě vyrenderované scény.
3.5
Databáze
Databáze v tomto systému slouží nejen jako úložiště dat, ale také jako prostředník pro předávání některých informací mezi editorem a webovou aplikací (případně desktopovou aplikací). Skládá se celkem z 10 tabulek, jejichž struktura a vztahy jsou znázorněny pomocí UML Class Diagramu na obrázku 3.13.
40
KAPITOLA 3. NÁVRH
Tabulka user složí k evidenci všech registrovaných uživatelů. Jsou zde i evidovány uživatelské role. Ty jsou uloženy v atributu role nastaveným na admin v případě administrátora a member v případě běžného registrovaného uživatele. Informace o všech vytvořených scénách se drží v tabulce scene. Jedná se pouze o základní informace, není v ní obsažen geometrický popis scén. Ten je uložen v následujících dvou tabulkách scene_item a seg_item. Tabulka scene_item obsahuje všechny objekty ze všech scén. Každý objekt musí být právě v jedné scéně, scéna může obsahovat několik (0 až n) objektů. Každý objekt má pevně určenou svou polohu a rozměry ve scéně. V tabulce seg_item je seznam všech segmentů. Každý segment patří pouze jednomu objektu, objekt může vlastnit několik (0 až n) segmentů. Tabulka scene obsahuje i několik vztahů s nimiž pracuje pouze webová aplikace. Jedná se o vztah scény s editorem (tabulka user ), který nám říká, jakým uživatelem je právě daná scéna otevřena. To je důležité pro administraci, kdy by mohlo dojít k otevření scény více uživateli. Další je vztah scény a dočasné scény, ten je důležitý pro ukládání scén. Další tři tabulky furniture, furniture_category a furniture_relation evidují knihovnu objektů. V tabulce furniture je seznam všech objektů v knihovně. Jsou zde obsažena i XML metadata objektu, konkrétně se jedná o atribut meta typu text, v kterém je celé XML uloženo. Dále jsou zde pro potřeby webu uloženy názvy souborů s jednotlivými náhledy (atribut thumb_top, thumb_front, atd.). Každý objekt v tabulce scene_item je odvozen právě z jednoho objektu z této tabulky. Aby byla knihovna objektů přehledná, tak je rozdělena do různých kategorií. Seznam kategorií je v tabulce furniture_category. Každá kategorie může mít několik podkategorií. To vyjadřuje vztah parent-child, touto konstrukcí můžeme vytvořit v podstatě neomezenou hierarchii, my se však omezíme na hloubku 2. A poslední tabulka furniture_relation určuje vztah mezi objekty a kategoriemi. Každá kategorie může obsahovat několik objektů (0 až n) a objekt může patřit do více (0 až n) kategorií. Zbývají již jen tři tabulky. V první z nich seg_type jsou definovány všechny známé typy segmentů, které jsou povoleny v XML metadatech. Zbylé dvě tabulky material a color drží informace o materiálech a barvách použitých při vykreslování scén. Vztah mezi color a material znamená, že každý materiál je ve zjednodušeném zobrazení vykreslován právě jednou barvou. Barva může být použita k vykreslování více materiálů (0 až n). Tabulka
KAPITOLA 3. NÁVRH
41
material je ve vztahu i s tabulkou seg_item, což znamená, že každý segment je kreslen právě jedním materiálem.
42
KAPITOLA 3. NÁVRH
Obrázek 3.13: UML Class Diagram databáze
KAPITOLA 4. IMPLEMENTACE
43
4 Implementace Implementaci webové aplikace lze rozdělit na 2 různé části. První část se zabývá implementací serverové strany, druhá pak implementací klientské části.
4.1
Serverová část
Serverová část je postavena na PHP a na objektové orientovaném ZEND Frameworku [17]. Tento framework je založen na návrhovém vzoru Model-View-Controller (MVC), konkrétně se jedná o implementaci Front Controlleru. Kdy jediným vstupním bodem do serverové části aplikace je soubor index.php. Veškerá URL (krom obrázků atd.) musí být směrována na tento soubor. Na webserveru apache toho můžeme dosáhnout například díky modulu mod_rewrite a souboru .htaccess. Následně je zadané URL rozpársováno a dle vytvořených přepisovacích pravidel je volán příslušný kontrolér. Přibližný obrázek o MVC struktuře serverové části můžete vidět na UML Class Diagramu 4.1.
Obrázek 4.1: UML Class Diagram MVC architektury PHP aplikace Celá aplikace je rozdělena do tří modulů. Tím prvním je default obsahuje v sobě především registraci a přihlášení. Druhým modulem s názvem modeller je pak samotný webový návrhář. Poslední modul admin obsahuje kompletní administraci. Ze ZEND Frameworku jsem kromě základních tříd také využil celou řadu dalších kni-
44
KAPITOLA 4. IMPLEMENTACE
hoven. Například pro tvorbu formulářů Zend_Form a jemu přidružené třídy Zend_Form_Input.... Dále pak třídy určené pro validaci, filtraci vstupních hodnot Zend_Validate, Zend_Filter. Několik validačních tříd bylo také nutné doimplementovat dle daného rozhraní. Značné usnadněním také přineslo využití Zend_Db a přidružených tříd, které poskytují jednoduché rozhraní pro dotazování nad databází. Případný přechod na jinou relační databázi by pak neměl činit větší problémy. Dalším velmi dobrým pomocníkem jsou třídy Zend_Auth a Zend_Acl. Ty jsem použil pro autentizaci uživatele a práci s přístupovými právy jednotlivých uživatelských rolí. Knihovny ZEND Frameworku jsem samozřejmě využil ve větší míře, uvádím ale jen ty, které mi asi usnadnily nejvíce práce.
4.1.1
Propojení s editorem
V současné době webová aplikace využívá služeb serverového editoru Jiřího Berana. Zde se ale nalézá potenciální bod variace. Jelikož webová aplikace by při zachování databáze, mohla bez větších problému využívat i jiného editoru. Z tohoto důvodu jsem propojení s editorem vyřešil následovně (obrázek 4.2).
Obrázek 4.2: UML Class Diagram propojení s editorem Veškerá komunikace s editorem je skryta v třídě Editor_Adapter_Desktop. Jak již je z názvu patrné, jedná se o implementaci návrhového vzoru Adapter. O vytváření instance adaptéru se stará třída implementující návrhový vzor Factory. Pokud bychom tedy chtěli změnit editor, stačí vytvořit novou třídu, která by implementovala rozhraní Editor_Adapter_Interface. V této třídě by pak byla schována komunikace s novým editorem.
KAPITOLA 4. IMPLEMENTACE
45
Přechod na nový editor by již znamenal jen změnu adaptéru v metodě getAdapter().
4.2
Klientská část
Klientská část je založena na JavaScriptu a objektově orientovaném frameworku Mootools. Tento framework dokáže implementaci v JavaScriptu dosti zpříjemnit. Frameworku jsem hojně využíval, zejména pak funkce pro tvorbu tříd z balíčku Class. Dále pak balíček Request, umožňující komunikaci prostřednictvím XMLHTTPRequestu. Značné ulehčení práce umožnily také balíčky Core, Element, Native a Utilities, které poskytují funkce pro práci s elementy, událostmi, CSS a mnoho dalšího.
4.2.1
Uživatelské rozhraní
Uživatelské rozhraní je založeno na knihovně MochaUI. Celé rozhraní se z patřičně utvořené HTML stránky vytvoří velmi snadno. Stačí na události ondomready vytvořit novou instanci třídy MochaUI.Desktop a poté již jen vytvářet okna, panely, sloupce, případně jiné prvky UI. Každé okno je novou instancí třídy MochaUI.Window, panel je pak instancí třídy MochaUI.Panel. Při vytváření třídy je možné nastavit celou řadu parametrů a událostí, na které lze reagovat. Jejich bližší výčet nechám na manuálové stránky [14].
4.2.2
Grafická plocha scény
Celá grafická plocha je utvořena řadou poměrně rozsáhlých tříd. Kreslící plátno reprezentuje třída KDesigner.SceneCanvas, jejíž hlavním úkolem je vytvoření plátna a vykreslování jednotlivých vrstev plátna v měřítku a daném pohledu. Rovněž obsahuje funkci pro hledání objektu ve scéně. Třída KDesigner.SceneView obsahuje instanci třídy KDesigner.SceneCanvas a vytváří nad plátnem ještě poslední vrstvu, do které jsou vloženy ovládací prvky a registrovány události myši. Zbývají nám třídy KDesigner.SceneMenu a KDesigner.MapControll. První vytváří kontextové menu a druhá ovládací prvky scény. Instance obou tříd jsou opět obsaženy v každé instanci třídy KDesigner.SceneView.
46 4.2.3
KAPITOLA 4. IMPLEMENTACE Nalezení cílového objektu
Při stisknutí tlačítka na ploše scény je vyvolána obsluha události onmousedown. Nejprve je zjištěna pozice kurzoru v okně prohlížeče a je následně přepočítána na pozici ve scéně. Při výpočtu polohy kurzoru musí být zohledněna poloha okna scény, měřítko v jakém je scéna zobrazena a pohled. Následně jsou testovány všechny objekty. Od každého objektu jsou nejprve získány pozice rohů objektu v daném 2D pohledu. Tím jsou získány všechny potřebné parametry pro spuštění algoritmu „Bod v polygonu” [1]. Tento algoritmus zjistí, zda se pozice kurzoru nachází v daném objektu. Nalezených objektů může být samozřejmě více, z těchto objektů je ale vybrán ten nejblíže v daném pohledu. Pokud byl nějaký objekt nalezen, jsou zaregistrovány události na tažení objektu. V opačném případě jsou registrovány události na tažení plátna. V potaz je bráno také zda bylo stisknuto levé, nebo pravé tlačítko. V případě pravého je zobrazeno kontextové menu scény, nebo objektu.
KAPITOLA 5. TESTOVÁNÍ
47
5 Testování V této kapitole jsou popsány testy jaké byly při vývoji provedeny.
5.1
Testy komunikačního protokolu
V systému bylo potřeba otestovat, zda komunikace mezi editorem a oběma aplikacemi (webová a desktopová) probíhá správně. Pro tento účel jsem vytvořil webovou aplikaci.
Obrázek 5.1: Ukázka testovací aplikace - všechny funkce API Úkolem této aplikace bylo snadné posílání požadavků editoru. A to jednak požadavky ve správném formátu, ale také chybně zadané požadavky. Tím se testovalo, zda editor dobře zpracovává přijaté zprávy a zda posílá správná čísla chyb, případně potvrzovací odpověď. Aplikace byla složena z hlavní stránky se seznamem všech funkcí testovaného API 5.1. Po otevření dané funkce se zobrazila stránka, kde se zadávaly posílané parametry jednotlivých funkcí 5.2.
Obrázek 5.2: Ukázka testovací aplikace - vybraná funkce
48
KAPITOLA 5. TESTOVÁNÍ
5.2
Testy použitelnosti
Pro webovou aplikaci byly provedeny testy použitelnosti. Jejich cílem bylo vyvrátit či potvrdit předem vytipovaná problémová místa uživatelského rozhraní.
5.2.1
Potencionální problémová místa UI
V aplikaci jsem určil následující místa, která by mohla činit uživateli problémy. 1. Tvorba zdí při zakládání nové scény. Při prvotním setkání uživatele s tímto pomocníkem pro tvorbu zdí nemusí být zřejmé jak a k čemu jej využít. Viz obrázek 5.3.
Obrázek 5.3: Pomocník pro tvorbu zdí při zakládání nové scény
2. Přístup k vlastnostem a akcím objektu přes kontextové menu (změna rozměrů, materiálu, smazání, rotace). Řada voleb je dostupná pouze přes toto kontextové menu viz obrázek 5.4. To může být pro mnoho uživatelů velmi problematické. Pokud totiž uživatele nenapadne kliknutí pravým tlačítkem myši na objekt, přichází téměř
KAPITOLA 5. TESTOVÁNÍ
49
o všechny tyto volby. V některých prohlížečích může být situace ještě ztížena tím, že se kontextové menu otevře až na stisk Ctrl a levé kliknutí.
Obrázek 5.4: Přístup přes kontextové menu
3. Práce v administrátorském rozhraní, hledání a vytváření nových položek. Viz obrázek 5.5.
Obrázek 5.5: Administrační okno
4. Změna materiálu všech segmentů stejného typu (např. zdi). Nevhodně pojmenované zaškrtávací pole, možná záměna se změnou materiálu všech objektů. Viz obrázek 5.6. 5. Umístění kamery a nastavení všech potřebných parametrů. Zřejmě největší problém, příliš hodnot co může uživatel nastavit. Navíc nastavení kamery omezeno 2D prostorem scény a rozmístěno do dvou oken. Viz obrázek 5.7.
50
KAPITOLA 5. TESTOVÁNÍ
Obrázek 5.6: Nevhodně pojmenované zaškrtávací pole
Obrázek 5.7: Umístění kamery pro 3D pohled 5.2.2
Průběh testu
Testu se zúčastnilo 6 osob. Na začátku byl každému předložen úvodní dotazník (viz příloha B), jehož cílem bylo zjistit profil testovaných osob. Hlavním cílem bylo zjistit, jakou má uživatel zkušenost s prací s počítačem a konkrétně s prací s modelovacími nástroji. Poté přišla hlavní část testu, a sice vykonání testu dle předloženého scénáře (viz příloha C). Nakonec již jen každý vyplnil závěrečný dotazník (viz příloha D), který se týkal scénáře a ovládání aplikace. V tomto dotazníku byl prostor k vyjádření se k případným problémům a k tomu, co by v aplikaci změnil. Všechny testy byly provedeny u mne doma na stolním počítači: Hardware
• AMD Athlon 2600++
KAPITOLA 5. TESTOVÁNÍ
51
• 1GB RAM ¨ • 17LCD - rozlišení 1280x1024@60Hz, 32bitová hloubka barev • myš, klávesnice Software • Microsoft Windows XP • dostupné prohlížeče Mozilla Firefox 3.0.5, Internet Explorer 6, Opera 9.63, Safari 3.2.1 V naprosté většině uživatelé volili jako svůj prohlížeč Mozilla Firefox.
5.2.3
Testující uživatelé
Dle úvodního dotazníku byl zjištěn následující profil testovaných osob: • věk 20-30let • nejvyšší dosažené vzdělání účastníků - střední škola s maturitou, nebo vysoká škola. • týdenní doba strávená u počítače - většinou 30 a více hodin. • všichni testeři byli běžnými uživateli počítače a Internetu. • nikdo neměl předchozí zkušenost s modeláři interiéru.
5.2.4
Zhodnocení testu a doporučení
Testem se nakonec potvrdily vytipované problémová místa 1 až 4, některým uživatelům pak způsobovalo potíže i místo číslo 5. Zhodnocení a některá doporučení, která ať již byla zjištěna testem, nebo závěrečným dotazníkem, jsou uvedena zde: 1. Vytváření zdí při zakládání nové scény působilo problémy asi polovině testovaných uživatelů. Důvodem bylo především prvotní setkání s tímto pomocníkem k tvorbě zdí. Řešením problému by mohlo být přidání nápovědy, nebo poznámky, která by novým uživatelům jistě pomohla.
52
KAPITOLA 5. TESTOVÁNÍ 2. Změna velikosti, materiálu, rotace atd. to vše bylo jedním z největších problému téměř pro všechny účastníky testu. Důvodem je jediná možnost přístupu k těmto volbám, a to přes kontextové menu objektu. To se skrývá pod kliknutím pravým tlačítkem myši na daný objekt, což nemnoho uživatelů napadlo. Dobrým řešením nejen tohoto problému by bylo přidání palety nástrojů. 3. Nevhodné pojmenování zaškrtávacího pole pro změnu všech segmentů daného typu se také projevilo. Většina uživatelů si jej zaměnila se změnou všech segmentů. Zde lze doporučit přejmenování na výstižnější název např. „Použít na všechny x ve scéně.” (x se mění dle vstupního pole Typ). 4. Umístění kamery, se podle předpokladů projevilo jako největší problém uživatelského rozhraní. Tento úkol nesplnil uspokojivě žádný uživatel. Příčin zde nalezneme více. První z nich je nové okno s nastavením kamery, které částečně překrylo okno scény, a tedy i samotnou kameru. Uživatel pak o této možnosti vůbec nevěděl. Dalším a zásadnějším problémem je nastavení velkého množství parametrů kamery, které je navíc omezeno rozmístěním kamery jen v dvojrozměrném prostoru. Uživatel si nedovede dostatečně představit oblast, kterou bude kamera snímat. Jistým zlepšením by bylo umístění nastavení všech hodnot do jednoho okna. Případně ještě zobrazit snímanou oblast kamery. Dle slov účastníků testu, by však nejlepším řešením bylo, nechat uživatele vybrat z několika již přednastavených kamer. Sice se tím poměrně dost sníží možnost vlastního nastavení, ale 3D pohled bude mnohem přístupnějšímu každému i méně zdatnému uživateli. 5. Posledním úkolem byla práce v administraci, zde většina uživatelů bez větších problémů úkoly splnila. Drobným zlepšením by možná bylo zvýraznění záložky pro vytvoření nové položky.
KAPITOLA 6. ZÁVĚR
53
6 Závěr V této kapitole je uvedeno zhodnocení práce a některá doporučení na budoucí vylepšení.
6.1
Zhodnocení
Cílem mé práce bylo navrhnout a implementovat systém, který by sloužil jako webový modelovací nástroj interiérů. Celý systém se skládá ze 4 částí. Na třech částech, rendereru, serverovém editoru a desktopovém modeláři pracovali kolegové v týmu. Mým úkolem bylo navrhnout a implementovat webovou aplikaci. Jako hlavní část práce tedy byla implementována webová aplikace. Její největší výhodou proti desktopovému modeláři měla být možnost použití přímo ve webovém prohlížeči, bez nutnosti jakékoliv instalace. Aplikace je plně funkční na naprosté většině užívaných webových prohlížečů. Chod aplikace není závislý na žádném zásuvném modulu, což bylo hlavním požadavkem. Pro zobrazení grafické plochy bylo využito elementu typu canvas z HTML5. Podpora u stále velmi často používaného prohlížeče Internet Explorer 6+ je zajištěna emulací canvasu přes VML. Webová aplikace také poskytuje administrační rozhraní pro správu všech scén, uživatelů a katalogu objektů. Uživatelské rozhraní bylo založeno na JavaScriptové knihovně MochaUI. Díky tomu a využití AJAX architektury, je webová aplikace značně přiblížena klasické desktopové aplikaci. Webová aplikace využívá služeb serverového editoru, který představuje jádro systému. Editor spravuje všechny otevřené scény a prostřednictvím rendereru dokáže poskytnout i realistický trojrozměrný pohled na scénu v podobě obrázku. Jeho využití bylo rovněž jedním z požadavků zadání. Společnými úkoly pro mne a kolegu Jiřího Berana pak byl návrh komunikačního protokolu a API mezi editorem a jeho klienty, tedy webovou a desktopovou aplikací. Navržený protokol umožňuje rychlou a spolehlivou komunikaci mezi editorem a oběma aplikacemi. Dalším společným úkolem byl návrh metadat, které definují veškeré informace o geometrii a vlastnostech objektů scény. Formát byl založen na XML, čímž se stává snadno čitelný i člověkem. Pro jeho snadnou kontrolu bylo rovněž vytvořeno DTD metadat. Posledním úkolem, který i částečně souvisí s návrhem metadat, byl návrh databáze, které měla plnit
54
KAPITOLA 6. ZÁVĚR
funkci úložiště dat a podporovat tak běh všech částí systému. Databáze rovněž slouží k výměně některých dat při komunikaci mezi editorem a jeho klienty. Nakonec byly na webové aplikaci provedeny testy použitelnosti, které ukázaly některé chyby v uživatelském rozhraní. Vyhodnocením testů byly také získány návrhy na opravu těchto chyb. Následně byla většina chyb opravena.
6.2
Návrhy na zlepšení
V současném stavu, ve kterém se celý systém nachází, umožňuje veškeré funkce, které byly požadovány na začátku. Prostoru ke zlepšování je zde ale stále mnoho. Z pohledu klientské části je zde velký prostor k tvorbě dalších nástrojů. Jako například měření vzdáleností, označování více objektů, rotace, změna velikosti atd. Dále by bylo zajímavé pokusit se vykreslovat objekty scény pomocí dostupných funkcí
