Systém pro datové reporty v oblasti trhu nemovitostí

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

Bakalářská práce

Systém pro datové reporty v oblasti trhu nemovitostí Jan Remeš

Vedoucí práce: Ing. Miroslav Bureš, Ph.D.

Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové Inţenýrství 19. května 2011

ii

Poděkování Rád bych poděkoval panu Ing. Miroslavovi Burešovi, Ph.D, za to, ţe mi umoţnil pracovat na tématu, které jsem si zvolil, za jeho odborné rady a čas věnovaný této práci. Dále bych chtěl poděkovat Vítkovi Jeţkovi a firmě Clevis s.r.o za poskytnutá testovací data a konzultace v počátečních fázích práce. Na závěr bych rád poděkoval své rodině a nejbliţším za podporu.

iii

iv

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

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

v

vi

Abstract Real estate market is quite complicated and the opportunity to obtain an overview of market using analysis provides a competitive advantage. This paper is focused on the design and implementation of a web based system. Application should be able to create reports from data collected at the real estate servers. The report will give access to search for lucrative offers, price map, overview of price history, distribution of property and the ability to scan through collected data. The important part of the thesis is finding the optimal adjustment of methods of statistical analysis and data mining, so the result should have ease of decision about real estate price offers.

Abstrakt Trh s realitami je poměrně komplikovaný a příleţitost utvořit si přehled pomocí nástroje na analýzu trhu dává konkurenční výhodu. Tato práce se bude zabývat návrhem a implementací systému, který umoţní vytvořit reporty z dat sebraných na serverech realitních kanceláří. Součástí reportu bude vyhledávání výhodných nabídek, cenová mapa, zachycení historie cen, rozdělení nemovitostí a moţnost prohledávat sebraná data. Důleţitou součástí je hledání optimálního nastavení metod statistické analýzy a dolování dat, aby výsledek měl přidanou informační hodnotu a usnadnil rozhodování ohledně cenových nabídek realit.

vii

viii

Obsah 1

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

2

Cíle práce ................................................................................................................... 3

3

Přehled a analýza existujících řešení .........................................................................5 3.1

Trulia PriceRedux .............................................................................................. 6

3.1.1 3.2

Hlavní výhody ................................................................................................ 6 Rightmove ...........................................................................................................7

3.2.1 3.3

Zillow ................................................................................................................. 8

3.3.1 3.4

Hlavní výhody ..............................................................................................7

Hlavní výhody............................................................................................. 8

Cheerio Maps ..................................................................................................... 9

4

Zdůvodnění vlastního návrhu .................................................................................. 11

5

Soupis poţadavků ..................................................................................................... 13

6

5.1

Funkční poţadavky ........................................................................................... 13

5.2

Nefunkční poţadavky........................................................................................ 14

Analýza a návrh aplikace .......................................................................................... 15 6.1

7

Případy uţití a scénáře ...................................................................................... 15

6.1.1

UC1 – Vyhledej nemovitost ........................................................................... 15

6.1.2

UC2 – Spočítat podklady Price Map ......................................................... 15

6.1.3

Use Case Diagram...................................................................................... 16

6.2

Návrh uţivatelského rozhraní ........................................................................... 17

6.3

Databázový model............................................................................................. 18

6.3.1

Čištění a analýza dat .................................................................................. 18

6.3.2

Relace v databázi ....................................................................................... 19

6.3.3

Relační model pouţité databáze ............................................................... 20

Implementace........................................................................................................... 21

ix

7.1

Postup při implementaci................................................................................... 21

7.2

Pouţité technologie a zdůvodnění ................................................................... 22

7.2.1

Volba frameworku .................................................................................... 22

7.2.2

Google Plugin for Eclipse ......................................................................... 23

7.2.3

Apache Tomcat 6.0.32 .............................................................................. 24

7.2.4

Commons-Math: The Apache Commons Mathematics Library 2.1 ......... 24

7.2.5

Google Chart Tools API 1.1 ....................................................................... 24

1.1.1

jQuery UI 1.8.2 ............................................................................................. 24

7.3

Architektura aplikace ....................................................................................... 25

7.3.1

8

9

x

GWT – RPC .............................................................................................. 26

7.4

Diagram nasazení .............................................................................................27

7.5

Implementace klíčových funkcionalit .............................................................. 28

7.5.1

Price History ............................................................................................. 28

7.5.2

Distribution .............................................................................................. 28

7.5.3

Property search......................................................................................... 30

7.5.4

Automated Valuation model .................................................................... 30

7.5.5

Price Map ................................................................................................... 31

7.5.6

Property Deal Finder ................................................................................. 31

Testování aplikace ................................................................................................... 35 8.1

Funkční testování ............................................................................................ 35

8.2

jUnit testování ................................................................................................. 35

8.3

Testování výkonu a optimalizace ..................................................................... 35

Závěr a moţné rozšíření ...........................................................................................37 9.1

Moţné rozšíření ................................................................................................37

9.2

Zhodnocení .......................................................................................................37

Seznam obrázků Obr. 1: Vědomosti, které jsou potřeba při tvorbě vizualizací dat. Převzato z [3] .............. 1 Obr. 2 : Ukázka mapy v NY, Brooklynu ............................................................................ 6 Obr. 3: Snímek obrazovky z reportu na webu rightmove.com ..........................................7 Obr. 4: Obrázek reportu. Mimo jiné je zde porovnání jednotlivých oblastí v USA a moţnost volby zpřesňujících parametrů. ......................................................................... 8 Obr. 5 : Kaţdá tečka je dům na prodej. Velký zelený kruh v pozadí je luxusní sídlo v centru San Francisca ........................................................................................................ 9 Obr. 6: Náčrt Price History zobrazující porovnání jednotlivých selekcí ......................... 13 Obr. 7: Náčrt distribuce cen nemovitostí. ....................................................................... 14 Obr. 8: Use Case diagram. Zkratka AVM znamená Automated Valuation Model a PM znamená Price Map. Nástroj Visio pouţívá zastaralou specifikaci a pouţívá vztah <<uses>> místo novějšího správného <>. ..................................................... 16 Obr. 9 Zjednodušený návrh uţivatelského rozhraní. Jsou vidět pouţité prvky a základní rozloţení aplikace. ........................................................................................................... 17 Obr. 10: Relační model. .................................................................................................. 20 Obr. 11: Schéma vzoru MVP [14] .................................................................................... 25 Obr. 12 : Porovnání načítání dat ze serveru a sestavení GUI v případě synchronního a asynchronního volání [16] .............................................................................................. 26 Obr. 13 : Diagram nasazení .............................................................................................27 Obr. 14 : Automated Valuation Model jako sloupcový diagram..................................... 30

xi

xii

Seznam rovnic Rovnice 1: Výpočet funkční hodnoty v Price History ..................................................... 28 Rovnice 2: Normální rozdělení pravděpodobnosti ........................................................ 29 Rovnice 3: Střední hodnota ............................................................................................ 29 Rovnice 4: Rozptyl .......................................................................................................... 29 Rovnice 5: Váţený součet ............................................................................................... 32 Rovnice 6: Výhodnost koupě reality. .............................................................................. 32

xiii

xiv

Seznam tabulek Tabulka 1: Porovnání mediánu a průměru u daných hodnot.......................................... 31 Tabulka 2:Váha jednotlivých kritérií. ............................................................................. 32

xv

xvi

1 Úvod Orientovat se na trhu realit je pro laika vţdy poněkud obtíţné. Trh je ovlivňován mnoha ukazateli, například výší úrokové sazby u hypoték, deregulací nájemného, výstavbou nových bytů apod. Vzhledem k tomu, ţe kaţdý musí někde bydlet, je poptávka zaručena. Často je ale náročné orientovat se v nabídkách realitních společností a zároveň můţe být rizikové spoléhat na to, co Vám doporučí realitní agent. Díky tomu, ţe probíhá velký a rychlý rozvoj na poli „dolování dat“ (data mining) a vizualizace, je často moţné situaci lépe analyzovat a zvolit optimální řešení. Jak říká Eric Schmidt, ředitel společnosti Google, za dva dny vytvoříme více informací neţ lidstvo od svého vzniku po rok 2003 dohromady. [1] Práce s rostoucím mnoţstvím ukládaných informací nám umoţňuje lépe pochopit i současné mechanismy trhu a jeho chování. Lze předpokládat, ţe během následujících let poroste zájem o odborníky, kteří rozumí zároveň statistice i principům vytěţování dat a vizualizace. [2] Správně interpretovaná data umoţňují lépe se rozhodovat a mohou upozornit na důleţité detaily, které by jinak zůstaly skryty.

Obr. 1: Vědomosti, které jsou potřeba při tvorbě vizualizací dat. Převzato z [3]

Na výše uvedeném obrázku jsou vidět obory, které zasahují do obecného postupu tvorby vizualizace dat, jak byl popsán v dizertační práci Bena Fry, jeţ je výsledkem jeho dlouholetého výzkumu. Taktéţ se věnuje vývoji populárního nástroje pro usnadnění práce s vizualizacemi.(Processing) [3] Je zřejmé, ţe pro tvorbu kvalitního výsledku, je potřeba zapojit poznatky a zkušenosti z různých odvětví. Podrobněji rozepíšu jednotlivé kroky. 1. Získání dat (acquire) – základní je nalezení dat, která chceme interpretovat. Je moţné, ţe se nalézají na pevném disku, někde na síti nebo je potřeba získat je výzkumem pomocí dotazníku.

1

2. Nalezení struktury dat (parse) – je nutné sebraná data setřídit do kategorií a připravit je pro pozdější zpracování 3. Profiltrování dat (filter) a hledání zajímavých informací (mine) – nejprve je potřeba z dat vybrat, ta která chceme zkoumat a pak se pokusit pomocí metod statistické analýzy a dolování dat nalézt zajímavé vlastnosti. 4. Zvolení vhodné reprezentace pomocí grafu (represent) a jeho zpřehlednění (refine) - aby se výsledek dal lépe interpretovat a zobrazit je potřeba zvolit jeho vhodnou reprezentaci pomocí grafu. Existuje mnoho moţností od sloupcového grafu po koláčový diagram. Je nutné zvolit přiměřené barvy, aby zobrazení bylo přehledné a čitelné. 5. Interakce s vizualizací (interact) – samotná křivka grafu poskytuje stále pouze hrubý obrys zobrazovaných dat a proto je dobré zdůraznit důleţité body při interakci s myší apod. Výše uvedený obecný postup budu sledovat i při tvorbě vlastního návrhu a následné implementaci aplikace. V současné době jiţ nabízené nástroje natolik pokročily, ţe tvoření podobných aplikací je moţné i pro jednotlivé pracovníky. Mou hlavní motivací je jednak moţnost kombinovat jiţ výše zmíněné přístupy, jednak zájem o poměrně nové odvětví, ve kterém probíhá rychlý vývoj. Myslím, ţe tento obor má budoucnost, a chtěl bych se mu věnovat i z tohoto důvodu. Trhu nemovitostí nabízí široké pole moţností jak ho znázornit, pochopit a interpretovat. Data se mění v čase, jsou vztaţená k nějaké lokaci a obsahují širokou škálu parametrů. Tak se vytváří velký prostor pro různé přístupy v analýze dat a hledání ideálního zobrazení.

2

2 Cíle práce Cílem této bakalářské práce je dle zadaných poţadavků navrhnout a realizovat webovou aplikaci pro práci s daty v oblasti nemovitostí. V současné době jiţ existuje databáze, ve které jsou uloţená data ze dvou největších českých realitních serverů, a to sreality.cz a reality.cz. Z této databáze budu vycházet a s ní pracovat. Aplikace by měla být stabilní, přístupná a intuitivní na pouţití. Výstup musí být spolehlivý, protoţe na jeho základě budou činěna důleţitá rozhodnutí. Přepokládá se rozvoj do budoucna, tudíţ je třeba, aby aplikace byla modulární a její architektura byla dobře navrţena. Cílem je rovněţ minimalizovat náklady na pouţité nástroje, a tedy pokud moţno pracovat s open source nástroji, kde licence umoţňuje komerční pouţití bez nutnosti zveřejňovat kód.

3

4

3 Přehled a analýza existujících řešení Většina kvalitních známých řešení pochází z USA nebo z Velké Británie. Lidé jsou zde zvyklí stěhovat se za prací a měnit své obydlí častěji. Jedna ze součástí „amerického snu“ je, ţe kaţdý má právo na svůj dům. Tato myšlenka sice byla konfrontována krizí v roce 2008, stále je ale v Americe největší počet vlastníků realit na světě. Trh je v anglosaských zemích mnohem transparentnější a všechna důleţitá data jsou veřejná. Existující řešení jsem vyhledával na populárních webových stránkách, které se věnují problematice vizualizace dat. Díky tomu, ţe je toto téma v současné době stále populárnější, existuje několik specializovaných webových stránek a blogů, které se tímto tématem dopodrobna zabývají. Jde o pravidelně aktualizované stránky, a kdykoliv se na internetu objeví něco zajímavého a inovativního na poli zpracování dat a jejich vizualizace, můţe si být člověk jist, ţe dané blogy to najdou a analyzují. Krátce zde popíšu ty nejdůleţitější a nejznámější, ze kterých jsem čerpal. a. Flowing Data - Nathan Yau studuje PhD. v statistice na Yale University. Na svém blogu se zaměřuje na návody, jak pracovat s nástroji pro tvorbu vizualizací. Také analyzuje zajímavá řešení, která se nově objevují na internetu, a dále je popularizuje. Nejzajímavější partie budou popsány v připravované knize Visualize This, půjde o praktického průvodce k vizualizacím a návod, jak přistupovat k rozsáhlým kolekcím dat. [4] b. Visual Complexity – O tento web se stará interakční designér a vědec Manuel Lima. Jde o setříděnou databázi infografických projektů a komplexních vizualizací. Kaţdý projekt je opatřen popisem, klíčovými slovy a několika obrázky. [5] c. Information is Beautiful – David McCandless je novinář pracující s daty a informační designér. Napsal knihu The Visual Miscellaneum, ve které se věnuje zajímavým projektům na poli informačního designu. Jím vytvořené stránky jsou dobře organizovány a kvalitní příspěvky jsou setříděné do kategorií. [6]

5

3.1 Trulia PriceRedux Trulia [7] je realitní společnost, která se orientuje na běţnou populaci i na profesionální agenty, kteří se zabývají nákupem a prodejem nemovitostí. Hlavní sídlo je Kalifornii, USA. V roce 2005 firma přišla na trh s interaktivními mapami, které zobrazují ceny nemovitostí tak, jak se měnily v čase. Navíc mapy zachycují procentuální rozdíl v ceně nemovitosti v okamţiku, kdy je poprvé nabízena, a výslednou cenou při uskutečněném prodeji. Jejich posledním počinem je mapa USA, na které je vidět, kolikrát se změní cena, neţ se nemovitost prodá.

3.1.1 Hlavní výhody Mapa je jasná a přehledná. Jsou na ní jasně vidět problémové oblasti, do kterých se nikdo nechce stěhovat a kde je vysoká nezaměstnanost. A pokud se dům dlouho neprodává, je pravděpodobně nadhodnocen. To vše usnadní základní orientaci na trhu i laikovi, který se snaţí za své peníze získat maximální uţitek.

Obr. 2 : Ukázka mapy v NY, Brooklynu

6

3.2 Rightmove Sídlí v Londýně a zaměřuje se především na britský trh. Jde o největší společnost zabývající se prodejem nemovitostí ve Velké Británii a jejich stránky patří k dvaceti nejnavštěvovanějším webům v zemi. [8] Kaţdý měsíc vytváří House Price Index, kde je zobrazeno, o kolik se kaţdý měsíc mění ceny v dané oblasti. To je doprovázeno stručným popisem situace a vysvětlením důvodů, proč ke změně ceny dochází.

3.2.1 Hlavní výhody Přehled lze vytvářet poměrně podrobně pro jednotlivé oblasti, a to podle PSČ. Na jeho základě lze vidět počet prodaných nemovitostí a jejich průměrnou cenu. Výhodné je rozdělení na jednotlivé typy nemovitostí. Protoţe graf je dobře rozvrţen, z přehledu jasně vyplývá, kdy nastává nejvhodnější doba pro nákup.

Obr. 3: Snímek obrazovky z reportu na webu rightmove.com

7

3.3 Zillow Jde o americkou společnost, která vlastní databázi nemovitostí. Produkuje pomocí vlastních algoritmů odhad reálné ceny nemovitosti. Vydělává peníze na reklamě, která je přítomná na jejich webových stránkách. V tuto chvíli má Zillow data o 100 milionech realit v USA. [9] Zachycuje i ty, které nejsou aktuálně v prodeji. Zillow umoţní odhadnout cenu nemovitosti. Dále poskytuje podrobné letecké snímky a vlastní wikisystém k nemovitostem.

3.3.1 Hlavní výhody Lze porovnávat jednotlivé oblasti USA v jednom grafu. Report je propojen i s vývojem cen hypoték. Zillow poskytuje také mobilní aplikaci, takţe lze vysledovat cenu nemovitosti i při procházení městem.

Obr. 4: Obrázek reportu. Mimo jiné je zde porovnání jednotlivých oblastí v USA a možnost volby zpřesňujících parametrů.

8

3.4 Cheerio Maps Poskytují další moţný pohled na data, avšak spíše se snahou o umělecký záměr. Data o nemovitostech pocházejí z amerického serveru Zip Reality. [10] Mapa se snaţí zobrazit velikost, cenu a stáří domů napříč San Franciskem v USA. Velikost kruhu znázorňuje hodnotu dané nemovitosti. Výsledek působí poměrně nepřehledným dojmem a zdá se, ţe tvůrci spíše tak dlouho upravovali parametry zobrazení, dokud se jim nelíbilo to, co viděli.

Obr. 5 : Každá tečka je dům na prodej. Velký zelený kruh v pozadí je luxusní sídlo v centru San Francisca

9

10

4 Zdůvodnění vlastního návrhu Důvody pro vytvoření vlastního návrhu a jeho následné implementace: 1. Potřeba mít různé funkcionality pohromadě v jedné aplikaci. 2. Lokální specifika českých realit. Na malém českém trhu chybí aplikace, ve které by se dalo pracovat s daty, která lze získat z největších českých realitních portálů. Moţnost utvořit si rychle přehled o stavu cen poskytuje výraznou konkurenční výhodu a moţnost být první u nákupu výhodných nemovitostí. Předpokládá se, ţe některé součásti systému budou natolik atraktivní, ţe po dostatečném otestování budou lidé ochotní platit za jejich uţívání. Návštěvnost realitních serverů je poměrně vysoká a návštěvníci se často vracejí, můţeme tudíţ předpokládat i nezanedbatelné příjmy z reklamy. Ţádná z existujících aplikací na reporty v trhu nemovitostí nepodporuje importování dat v nějakém rozšířeném formátu. Z logiky věci plyne, ţe jsou tajné, protoţe za reporty stojí komplexní výpočty a sofistikované algoritmy (Zillow).

11

12

5 Soupis požadavků V první části kapitoly se budeme věnovat poţadované funkcionalitě aplikace, ve druhé části se budeme zabývat nefunkčními poţadavky, které definují nároky a omezení systému.

5.1 Funkční požadavky 1. Umoţnit výběr nemovitostí pomocí specifických proměnných, a to: a. čas – interval, rozmezí b. místo – např.: Praha 7 c. typ nemovitosti – 1+kk, 2+1…. d. velikost bytu e. rozsah cen f.

pronájem/prodej

2. U grafů umoţnit porovnání různých selekcí. 3. Price History – sestavit graf cen za dané období, z grafu by mělo být zřejmé, jak se v průběhu času mění ceny v dané oblasti. Je důleţité umoţnit vybírat data pomocí více kritérií.

Obr. 6: Náčrt Price History zobrazující porovnání jednotlivých selekcí

13

4. Distribuce – rozdělení/počet nemovitostí za daných kritérií. Cílem grafu je znázornit rozloţení nemovitostí ve vybrané oblasti, a tsk zjistit, které jsou nejčastěji zastoupeny v nabídce.

Obr. 7: Náčrt distribuce cen nemovitostí.

5. Automated valuation model (AVM) – umoţní spočítat průměrnou cenu či cenový rozsah v dané oblasti. Je třeba zvolit vhodný statistický výpočet, aby model byl přehledný a uţitečný. 6. Property search – jednoduché vyhledávání nemovitostí. U vybrané nemovitosti zobrazit její detaily a podrobnou nabídku. Jde o podobnou funkcionalitu, jakou nabízí většina současných realitních serverů. Výpisem by mělo být moţné listovat a řadit ho dle parametrů ceny a data přidání. 7. Price map – mapa cen ve městě. Vytvoří se seznam dle městských částí a průměrná cena v dané oblasti. Výpis můţe být ještě doplněn o některé další údaje související s cenovou hladinou v dané oblasti. 8. Property Deal Finder – program projde všechny uloţené nemovitosti a najde ty s výhodnou cenou. Důleţité je zohlednit stav reality a její umístění.

5.2 Nefunkční požadavky 1. Při implementaci pokud moţno pouţívat bezplatné a ověřené nástroje. 2. Aplikace bude spuštěná na web serveru a půjde k ní přistupovat skrze libovolný prohlíţeč. 3. Data jsou v současné době uloţeny v MySQL databázi a aplikace musí mít moţnost s nimi pracovat.

14

6 Analýza a návrh aplikace Při návrhu byl pouţit Microsoft Visio 2010 [11] a Enterprise Architect [12] pro nakreslení diagramů a uţivatelského návrhu. V analýze se budu zabývat nejprve případy uţití a v návrhu pak uţivatelským rozhraním, databází a diagramem nasazení.

6.1 Případy užití a scénáře V kapitole se blíţe zabýváme pouze dvěma případy uţití. UC1 se bude totiţ objevovat jen v nepatrně pozměněné podobě například i u UC - Vytvoř Price History atd. Dále se podrobněji budeme zabývat UC2 – Spočítat podklady Price Map, a to z důvodu, ţe do něj nebude zasahovat uţivatel a bude se spouštět automaticky. Zadané poţadavky na aplikaci v tuto chvíli nevyţadují více uţivatelských rolí, a proto si vystačíme pouze s rolí Uţivatele a se znázorněním času v podobě hodin.

6.1.1 UC1 – Vyhledej nemovitost 1. Uţivatel vyplní formulář výběru dat. 2. Formulář proběhne validací. 3. V případě, ţe byl formulář vyplněn správně, zobrazí se tabulka s poţadovaným výsledkem.

6.1.2 UC2 – Spočítat podklady Price Map Podklady se přepočítají dopředu z důvodu urychlení aplikace. Dotaz při velkém mnoţství dat by zabral příliš mnoho času. 1. V zadanou hodinu se spustí naplánovaná úloha. 2. Spočítají se poţadované hodnoty a jsou zapsány do databáze.

15

6.1.3 Use Case Diagram

Obr. 8: Use Case diagram. Zkratka AVM znamená Automated Valuation Model a PM znamená Price Map. Nástroj Visio používá zastaralou specifikaci a používá vztah <<uses>> místo novějšího správného <>.

16

6.2 Návrh uživatelského rozhraní Cílem bylo co moţná nejvíce zjednodušit rozloţení prvků tak, aby bylo intuitivní a jasné. Po levé straně budou odkazy na výběr funkcionality aplikace. Po pravé straně v horní části se budou volit specifické proměnné pro výběr nemovitosti. Ty jsou nadefinované v poţadavcích. Zbylý prostor bude slouţit pro zobrazování výstupu aplikace. Nejdůleţitější informace se tak vyskytnou ve středu obrazovky. Návrh uţivatelského rozhraní vychází ze snahy co nejlépe vyuţít jiţ dostupné komponenty. Pro pole Lokace bych chtěl zuţitkovat nápovědu při doplňování. Nápověda bude čerpat z databáze unikátních lokací. Jako nejvhodnější pro výběr intervalu velikosti bytu a jeho plochy byly vybrány jezdce. Jejich ovládání myší je rychlejší a zároveň umoţní představu o rozsahu hodnot. Pole pro počet zpracovávaných nemovitostí je důleţité, protoţe zlepší odhad, jak dlouho bude operace trvat.

Obr. 9 Zjednodušený návrh uživatelského rozhraní. Jsou vidět použité prvky a základní rozložení aplikace.

17

6.3 Databázový model K databázi byl získán přístup od zadavatele. Data byla sebrána pomocí crawleru ze dvou realitních serverů, a to sreality.cz a reality.cz. Nejprve bylo pomocí reverzního inţenýrství zjištěno relační schéma a vztahy mezi tabulkami. Bohuţel se ukázalo, ţe v tabulkách se často objevují duplicity a neplatné hodnoty, jako například záporná cena. To by později znamenalo v implementaci velký problém, a proto bylo nejprve provedeno pročištění databáze.

6.3.1 Čištění a analýza dat Nejprve jsem se zaměřil na duplicitní hodnoty a neplatná čísla. Napsal jsem jednoduchý program v Javě. Šlo o velký objem dat, a proto jsem se musel pokusit o optimalizaci práce s databází. Stačilo posílat SQL příkazy v dávkách a vypnout autocommit. Nedošlo k ţádné komplikaci a velikost databáze se zmenšila přibliţně osmkrát. Dále jsem pokládal za uţitečné provést základní analýzu dat, a pokud moţno odhalit další chyby. Pouţil jsem nástroj Google Refine [13], který pracuje hlavně s takzvanými „facet“. Lze vytvořit nad sloupcem a můţe být textový, číselný nebo můţe být reprezentován korelačním diagramem (scatter plot). Vytvoření facetu umoţní udělat si okamţitě jasný přehled nad strukturou dat a jejím rozdělením. Nereálné a krajně nepravděpodobné hodnoty jsem potom odstranil z databáze. Při prohlíţení textových hodnot jsem objevil problém s některými sloupci. Šlo zejména o PSČ nebo o hodnotu město. Vyskytovaly se zde podobné zápisy stejného významu. Jako příklad uvedu Poštovní směrovací číslo Prahy 10, bylo do databáze vloţeno jako „10 000“ a na některých místech jako „10000“ bez mezery. Google Refine umoţňuje shlukování řetězců na základě jejich podobnosti. Pouţil jsem algoritmus k-nejbliţších sousedů (k-NN) a podobné hodnoty sloučil. S databází jsem pracoval na lokálním počítači. Aby aplikace byla skutečně pouţitelná na aktuální reportování, bude potřeba vyřešit třídění a čištění dat na úrovni webového crawleru, to ale není cílem této bakalářské práce.

18

6.3.2 Relace v databázi Popíšu zajímavé relace, které ovlivňují základní funkcionalitu a které nemusí být na první pohled zřejmé.

6.3.2.1 Relace property Obsahuje základní vlastnosti kaţdé nemovitosti, jako je primární klíč a jméno, popis a souřadnice GPS.

6.3.2.2 Relace history Ukládá se zde číslo nemovitosti, s cenou a datem, kdy byly zaznamenány.

6.3.2.3 Relace url_stack Slouţí pro potřeby webového crawleru, aby se dalo zjistit, zda se záznam nemovitosti od posledního navštívení změnil.

6.3.2.4 Relace reality_cz a sreality_flats Reprezentují jednotlivé webové servery, z nichţ byla data staţena. Kaţdý server má některé informace o záznamech jednotlivých realit specifické.

19

6.3.3 Relační model použité databáze Model

jsem

zjistil

pomocí

reverzního

inţenýrství,

avšak

byly

nevhodně

popsány některé relace a například mezi property a reality_cz a sreality_flats není vazba 1…N ale logicky 1…1. Na diagramu nejsou vidět všechny sloupce.

Obr. 10: Relační model.

20

7 Implementace 7.1 Postup při implementaci Zvolil jsem si metodologii Rapid Application Development (RAD) a bral na to ohled při výběru nástrojů a technologií. RAD klade důraz na rychlé tvoření prototypů spíše neţ na důkladné plánování. Vývoj probíhá v krátkých cyklech a v kaţdém cyklu se o něco více zdokonalí funkcionalita vyvíjeného software. Pouţívají se automatizované nástroje, generátory kódu a nástroje vizuálního programování pro rychlou tvorbu uţivatelského rozhraní. Metodologie RAD nasazená ve firmě je vhodná pro menší týmy, kde panuje vysoká soudrţnost a kde všichni mají zkušenosti v pouţívání CASE nástrojů pro zvýšení produktivity. Důleţité je taktéţ aktivní zapojení zadavatele do vývoje. Stručně popíšu jednotlivé iterace, ve kterých jsem postupoval. Zajímavé momenty a architekturu rozeberu pak níţe. 1. Přístup k databázi – nejprve jsem se rozhodl napsat servlet na připojení k databázi. Součástí byly metody na základní operace s daty. 2. Ovládací panel – vytvořil jsem uţivatelské rozhraní s moţností přepínat mezi

jednotlivými

funkcionalitami.

Rovněţ

jsem

implementoval

poţadavek na moţnost selekce podle dispozice, rozlohy bytu atd. 3. Property Search – jde pravděpodobně o nejméně náročný poţadavek a slouţil i k ověření správné funkčnosti ovládacího panelu. 4. Price History – slouţilo k ověření práce s vizualizační knihovnou a moţností zvoleného frameworku. 5. Distribution – poprvé jsem pouţil Java knihovnu na práci se statistikou. 6. Moţnost porovnání různých selekcí – přidal jsem funkcionalitu a upravil Price History a Distribution. Ukázalo se, ţe by bylo výhodnější tuto vlastnost implementovat dříve. 7. Automated Valuation Model – tvorba třídy na práci se statistickými daty a vyuţití sloupcového diagramu.

21

8. Price Map - pouţil jsem znovu kód a komponenty z Property Search a AVM. 9. Property Deal

Finder

–

nejkomplikovanější

funkcionalitu

jsem

implementoval jako poslední.

7.2 Použité technologie a zdůvodnění 7.2.1 Volba frameworku Nejprve bylo potřeba zvolit framework a tím pádem implementační prostředí. Porovnal jsem dva nejrozšířenější webové frameworky, které obsahují vizualizační knihovny na tvorbu grafů. Vizualizace jsou totiţ klíčovou částí aplikace, na kterou bude vhodné pouţít jiţ existující komponenty. Oba dva porovnávané frameworky jsou zamýšlené pro rychlou tvorbu internetových aplikací a mají open-source SDK. Srovnal jsem výhody a nevýhody a na jejich základě vybral ten, s kterým budu dále pracovat.

7.2.1.1 Porovnání Adobe Flex 3 a Google Web Toolkit 2.3 7.2.1.1.1 Vývojové prostředí Srovnávané IDE jsou postavené na Eclipse. Bohuţel Flex Builder 3 je zdarma pouze pro studenty a vědecké pracovníky. Eclipse je jedno z nejrozšířenějších vývojových prostředí, podporuje statickou analýzu kódu a není problém v něm ladit webové aplikace. Díky tomu, ţe je často pouţíváno, existuje mnoho rozšíření na doplnění poţadované funkcionality.

7.2.1.1.2 Návrh uživatelského rozhraní Komponenty ve Flexu vypadají lépe a v základním SDK je jich mnohem více. Bohuţel chybí specializované tabulky pro práci s daty, které obsahuje GWT. Ty jsou optimalizované na práci s velkým mnoţstvím dat a usnadňují základní operace, jako je třídění. Oba dva frameworky podporují vizuální programování uţivatelského rozhraní a také jeho tvorbu pomocí xml značek, coţ značně zrychluje vývoj.

22

7.2.1.1.3 Programovací jazyk V GWT se vyvíjí v Javě, která se překládá do Javascriptu. Na klientské straně nelze pouţít všechny třídy z JRE, jako například vlákna. V Flexu se vyvíjí v Action Scriptu, s kterým bohuţel nemám zkušenosti. Výsledek se překládá do Flashe, na který je potřeba mít v prohlíţeči zásuvný modul. Naučit se Action Script ale půjde pravděpodobně rychle, protoţe podporuje objektově orientovaný přístup v programování.

7.2.1.1.4 Nástroje pro tvorbu grafů Jak jiţ bylo řečeno, ve Flashi komponenty vypadají lépe a jsou vizuálně bohatší, na druhou stranu nepostrádají ţádnou základní funkčnost oproti Google Chart Tools. Ty bohuţel nejsou součástí základního GWT. Primárně jsou vyvíjeny pro práci s čistým Javascriptem a Google se stará o to, aby se alespoň část přizpůsobila práci s Javou v GWT. Flex má o něco menší paletu, pokud jde o jednotlivé typy grafů, například nepodporuje heatmapy a další nástroje na provázání s mapami. Flex v současné době převládá ve tvorbě vizualizací na webu a je o něco rozšířenější v tomto specifickém zaměření.

7.2.1.2 Shrnutí Zvolil jsem GWT, protoţe s programováním v Javě jsem lépe seznámen. Seznam komponent je pro mě dostačující a je pravděpodobné, ţe moţnost mobilního přístupu na stránky bude později uţitečná. To by s Flashem nebylo moţné. Taktéţ vyuţiji GWT komponenty pro práci s daty.

7.2.2 Google Plugin for Eclipse Pouţíval jsem poslední verzi Eclipse 3.6 (Helios). Výhodou byla rychlá odezva a stabilita. Klíčovou vlastností je ale přítomnost rozšíření, které vyvíjí Google a které usnadňuje práci s GWT a Google Api. Lze pomocí něj jednoduše zakládat nové projekty, editovat stávající a přidávat funkcionalitu. Pro tvorbu uţivatelských rozhraní je moţné pouţít GWT Designer, který usnadní a zrychlí práci například při tvoření jednoduchých formulářů. Na základě návrhu se pak vygeneruje Java kód. Součástí rozšíření je i plugin do prohlíţeče. To je v současné době dostupné pro všechny nové verze nejrozšířenějších

23

prohlíţečů. Aplikaci lze pak ladit bez nutnosti opětovné kompilace a změny v uţivatelském rozhraní se v prohlíţeči projeví po uloţení.

7.2.3 Apache Tomcat 6.0.32 Jde o open source web-server podporující práci s Java Servlety. Je značně rozšířen, a navíc dobře zdokumentován. Ocenil jsem jeho kompaktnost a relativně nízkou náročnost na paměť oproti alternativám. Tomcat v sobě obsahuje uţitečnou administrátorskou konzoli, přes kterou lze provádět nahrávání aplikací a kontrolu stavu serveru. Důleţité bylo i to, ţe spolupracuje bez problému s IDE Eclipse. Zvaţoval jsem, zda nevybrat řešení Google App Engine. Bohuţel ale pouţívá vlastní systém uloţení dat a neumoţňuje přímé připojení do databáze. V mém případě je pouţití relační databáze zásadní a vyplývá z nefunkčních poţadavků.

7.2.4 Commons-Math: The Apache Commons Mathematics Library 2.1 Apache Commons je projekt, který je zaměřen na všechny aspekty Java knihoven, u kterých se předpokládá opakované pouţití napříč projekty. Zvolil jsem Commons-Math. Knihovna je to malá a kompaktní, zahrnuje v sobě třídy na řešení běţných problému ve statistice a matematice. Pouţívám ji na počítání základních statistických veličin, jako je střední hodnota nebo rozptyl.

7.2.5 Google Chart Tools API 1.1 Poskytují přístup ke komponentám grafů. Nejčastěji jednu z komponent pouţívám pro tvorbu spojnicového grafu. Je mnoho moţností, jak výsledný vzhled přizpůsobit poţadovanému výsledku. Klíčová místa grafu jsou interaktivní, coţ zvyšuje přehlednost. Vizualizace je vykreslena pomocí SVG nebo VML, a tudíţ není problém zobrazit výsledek i v mobilních zařízeních, která nepodporují Adobe Flash. Původní verze nástroje je napsaná v Javascriptu a toto je pouze obal pro práci s ní v GWT.

1.1.1 jQuery UI 1.8.2 Abych mohl implementovat komponentu jezdec dle návrhu uţivatelského rozhraní, musel jsem nalézt alternativní řešení, neboť GWT jej v základu nepodporuje. Pouţil jsem jiţ existující knihovnu, kde jsou poţadované prvky implementované pomocí Javascriptu.

24

7.3 Architektura aplikace Nejprve jsem měl v plánu aplikaci stavět v pojetí MVC, to znamená, ţe budu vše důsledně dělit na tři logické části, a to Model,View a Controller. Model reprezentuje data a byznys logiku, View uţivatelské rozhraní a Controller se stará o aplikační logiku. Ukázalo se však, ţe komponentám v GWT mnohem více vyhovuje prezentační vzor MVP. Zdá se být mnohem vhodnější pro RIA technologie a tvoření uţivatelských rozhraní. Například na tlačítko je navěšena logika Controlleru a View zároveň, čili se stará o své vykreslení a zároveň zachytává události myši.

Obr. 11: Schéma vzoru MVP [14]

V MVP se stará o uţivatelský vstup a výstup View. Pouţívá k tomu komponenty a prvky uţivatelského rozhraní. Například Cell Table v GWT umí třídit výstup a zároveň se postará o správné zobrazení, stačí jí předat pouze data. Model je v MVP stejný jako v MVC, tedy stará se o data a byznys logiku. Presenter obsahuje aplikační a prezentační logiku. [14] Dostává data od modelu a naformátuje je pro zobrazení pomocí View. V GWT je vestavěn framework pro vývoj v MVP. [15] Usnadňuje vývoj pomocí tříd Activity a Place. Activity reprezentuje Presenter a Place se stará o jednotlivé stavy uţivatelského rozhraní. Tyto novinky přišly aţ s novější verzí po zahájení vývoje a rozhodl jsem se zpětně aplikaci neměnit.

25

7.3.1 GWT – RPC Abych mohl komunikovat mezi serverem a klientskou částí aplikace, musel jsem si zvolit vhodnou implementační strategii. Na serveru pouţívám Javu, a tak jsem mohl implementovat GWT RPC mechanismus na posílání Java objektů přes standardní HTTP. V případě, ţe je RPC pouţit správně, je moţné vykonávání veškeré logiky uţivatelského rozhraní přesunout ke klientovi, a tím odlehčit serveru, sníţit vyuţití sítě a zlepšit výkon. [16] Volání jsou asynchronní, to znamená, ţe zatímco se vykonává poţadavek, můţe aplikace zpracovávat další úkol. To je uţitečné z mnoha důvodů. 

Dnešní prohlíţeče jsou nastavené tak, ţe v případě delšího vykonávání a čekání na odpověď se objeví dialog, ţe aplikace neodpovídá. V případě asynchronního volání aplikace nečeká s načtením například GUI prvků na výsledek volání.



Můţe proběhnout více asynchronních volání paralelně.



V případě, ţe server je nedostupný nebo neodpovídá, nezpůsobí to zamrznutí aplikace.

Obr. 12 : Porovnání načítání dat ze serveru a sestavení GUI v případě synchronního a asynchronního volání [16]

Metody pouţívané v GWT RPC musí mít parametry a návratové typy odpovídající poţadavkům na serializaci. Důvodem je, ţe jsou posílány přes síť mezi klientskou a serverovou částí aplikace. Serializace znamená převedení datové struktury nebo objektu do formátu, kdy můţe být uloţen nebo poslán po síti. [17]. Je moţné takto poslat pouze některé typy. [16] Vyjmenuji ty, které pouţívám.

26



Jestliţe jde o primitivní typ, jako je char, byte, short, int, long, boolean, float nebo double.



Jde o instanci String, Date.



Vlastní třída, která implementuje rozhraní Serializable.



Jde o pole objektů splňující poţadavky na serializaci.

7.4 Diagram nasazení Zobrazuje rozloţení softwarových komponent na hardware a jejich vzájemnou spolupráci. Klientskou část zastupuje libovolné zařízení s webovým prohlíţečem, které podporuje Javascript. Na serveru je pak nasazen Apache Tomcat spolu s databázi MySQL. deployment Deployment Mo... «device» Web Serv er

«device» Client

«executionEnviron... Apache Tomcat «executionEnviron... Brow ser

GWT RPC «use»

HTTP «use»

«executionEnviron... MySQL database

Obr. 13 : Diagram nasazení

27

7.5 Implementace klíčových funkcionalit 7.5.1 Price History Sestavení historie cen probíhá na serveru. Jeden objekt Price History reprezentuje jedno konkrétní datum, dále v něm je uloţen počet nemovitostí, který byl k danému datu nalezen, a součet jejich ceny. Kolekci pak na serveru setřídím od nejstaršího k nejnovějšímu datu. V klientské části aplikace pak lze data slučovat do týdnů, měsíců či let. Ke kaţdému datu se vytvoří průměrná cena tak, ţe se podělí počet nemovitostí s celkovou sumou cen. Na ose

je tedy datum a na ose

leţí cenový průměr.

∑

Rovnice 1: Výpočet funkční hodnoty v Price History

Stálo by za zváţení, zda by nebylo vhodnější na rozdíl od průměrné ceny pouţít medián, který je o něco přesnější, protoţe omezí vliv extrémních hodnot.

7.5.2 Distribution Při pohledu na křivku rozdělení by si člověk měl hned utvořit představu, kterých nemovitostí se zadanými parametry je na trhu nejvíce. A kdyţ se na trhu objeví nová nemovitost, na kolik bude pravděpodobně oceněna.

7.5.2.1 Normální rozdělení pravděpodobnosti Pro počítání jsem pouţil Normální rozdělení pravděpodobnosti (nebo téţ Gaussovo). Je to funkce jedné reálné proměnné rozptylem

se dvěma parametry, a to střední hodnotou µ a

. Gaussova křivka je symetrická a střední hodnota je právě pod vrcholem

Normální rozdělení dobře znázorňuje náhodné chyby, a proto bývá také nazýváno zákonem chyb. Lze jím dobře ilustrovat řadu v přírodě náhodných jevů, jako je například rozloţení IQ v populaci.

28

(

( )

)

√

Rovnice 2: Normální rozdělení pravděpodobnosti

Číslo µ je libovolné reálné a

musí být kladné,

je Eulerovo číslo (2,71828…).

7.5.2.2 Střední hodnota Je místo, okolo kterého se vyskytuje nejvíc hodnot náhodné veličiny. Dle definice „Je-li X náhodná veličina, pak vážený průměr jejich hodnot podle pravděpodobností nazýváme střední hodnotou náhodné veličiny X a označujeme ji E (X)“ [18], potom pro diskrétní rozdělení s pravděpodobností funkcí p platí:

( )

∑

( )

Rovnice 3: Střední hodnota

7.5.2.3 Rozptyl Je pouţit pro měření, jak moc jsou od sebe čísla v mnoţině vzdálená, tedy jak daleko leţí od střední hodnoty. Je to druhý centrální moment náhodné veličiny a spočítá se takto:

( )

(

( ) )

Rovnice 4: Rozptyl

7.5.2.4 Výpočet a zobrazení křivky Střední hodnotu a rozptyl jsem spočítal na serveru pomocí knihovny Commons-Math (7.2.4). V klientské části aplikace pak ze vzorce zjišťuji funkční hodnoty. Počet hodnot se odvíjí od toho, jak je velká mezera mezi globálním maximem a minimem funkce v případě více selekcí. To plyne ze snahy o větší přesnost. Kdyţ je zobrazena pouze jedna křivka, stoupá hodnota

(tedy cena) vţdy o milion korun.

29

7.5.3 Property search Pro výpis nemovitostí jsem pouţil Cell Table, která byla představena ve verzi GWT 2.2. Jde o komponentu sestavenou z tzv. Cell‘s. Jsou navrţené ke zpracování velkých kolekcí dat. Vykreslují uţivatelské rozhraní jako HTML řetězec namísto tradiční manipulace s DOM. [19]

Existují různé druhy Cell’s. Pouţívám například ty, které usnadňují

zpracování data, čísla nebo textového řetězce. Jednotlivé sloupce lze v tabulce řadit a provádět selekce. Tabulka se také umí postarat o stránkování. Doplnil jsem k řádkovému výpisu ještě moţnost zobrazit detaily vybrané nemovitosti.

7.5.4 Automated Valuation model Podle selekce z panelu ovládacích prvků se na serveru vytvoří statistiky. Ty se pak textově zobrazí na výstupu. Pro větší zpřehlednění a názornost jsem pouţil na reprezentaci hodnot sloupcový diagram. Jako ukazatele rozsahu cen jsem pouţil průměr, medián, minimální a maximální cenu. Nejuţitečnější se mi zdá být právě hodnota medián.

Obr. 14 : Automated Valuation Model jako sloupcový diagram

30

7.5.4.1 Medián Je uţitečnější neţ průměr, protoţe nebere ohled na extrémní hodnoty. Ty se v nemovitostech vyskytují často v podobě luxusních sídel, kde je cena nastavena vysoko oproti ostatním nabídkám. Medián dělí setříděnou posloupnost na dvě poloviny. Pokud je počet prvků v něm lichý, stačí vzít ten uprostřed. V případě sudého počtu se medián rovná průměru prvků na pozicích

a

, kde

je počet prvků.

1 000 000 1 350 000 1 400 000 1 800 000 2 000 000 17 000 000 Průměr:

4 091 666,66

Medián:

1 600 000

Tabulka 1: Porovnání mediánu a průměru u daných hodnot.

7.5.5 Price Map Kombinuji zde pouţití Cell Table a statistik zpracovaných na serveru. Vzhledem k tomu, ţe při zpracování se procházejí všechny nemovitosti a mohl by dotaz trvat příliš dlouho, vytvořil jsem tabulku v databázi pro uloţení dat, abych nemusel vše pokaţdé přepočítávat. V případě nasazení aplikace na reálná data, výpočet bude spouštěn opakovaně, pravděpodobně kaţdý den. Při dotazu od klienta se pak data rychle načtou a zobrazí.

7.5.6 Property Deal Finder V této části aplikace jsem řešil problém vícekriteriálního rozhodování (MCDM), ten je obvykle definován na tom, ţe existuje

proměnných a

rozhodovacích kritérií.

Vybrání nejlepší metody MCDM je poměrně sloţité a vedlo k formulaci rozhodovacího paradoxu. [20]. Nejlepším řešením by bylo porovnat jednotlivé metody na datech z nemovitostí a nalézt ideální nastavení daného algoritmu.

31

Já jsem zvolil metodu váţeného součtu (VS), která je pravděpodobně nejznámější. U ní platí předpoklad, ţe všechna kritéria jsou kladná a čím větší je jejich hodnota, tím se blíţí nejlepšímu výsledku. Ve vzorci váţeného součtu

značí váhu kritéria

a

je jedna z hodnot

. [21]

∑ Rovnice 5: Vážený součet

V následující tabulce je zobrazeno, jakou váhu jsem přisoudil jednotlivým kritériím. Nejdůleţitější je u nemovitostí její lokace, občanská vybavenost a dostupnost sociálního a kulturního zázemí. w=1

w = 0,4

w = 0,2

lokace

stav obydlí

internet, nemocnice, supermarket, atd.

Tabulka 2:Váha jednotlivých kritérií.

Hodnoty nabývají čísel v intervalu od 0 do 99. Pro zjednodušení jsem ocenil jednotlivé lokace náhodně v daném intervalu, protoţe propojení s cenovými mapami nemovitostí [22] se ukázalo příliš technicky náročné. I další hodnoty jsem přepočítal do zmíněného rozsahu, abych je mohl porovnávat. Ohodnocením nemovitostí dle následného modelu jsem zjistil, které jsou výhodně umístěné a dobře vybavené, nicméně ještě zbývá začlenit do propočtů také jejich cenu. Rozhodl jsem se spočítat podíl váţeného součtu kritérií (VS) s cenou za nemovitosti (CN). Ve výsledné hodnotě (VK) je tak zohledněna i inzerovaná cena vůči kvalitě nabízené reality.

Rovnice 6: Výhodnost koupě reality.

V aplikaci se zobrazí prvních dvacet nemovitostí, které jsou vyhodnoceny jako nejvýhodnější. Podobně jako v případě vyhledávání nemovitostí lze zobrazit jejich podrobnosti.

32

7.5.6.1 Návrh dalšího postupu Výsledek by se dal určitě ještě dále zlepšovat. Nastíním dvě řešení, která by pravděpodobně vedla k jeho zpřesnění. 1. Klasifikační algoritmy – v systému by byly označeny nemovitosti, o kterých rozhodneme, ţe jsou výhodné. Na jejich základě by se vytvořila trénovací mnoţina a pomocí ní by se rozhodovalo u ostatních případů. 2. Porovnávání s průměrem – spočítá se cenová hladina v dané oblasti a na základě odchylek se bude hodnotit výhodnost. Je pravděpodobné, ţe uspokojivých výsledků se dosáhne pouze kombinací přístupů a k správné funkčnosti je nezbytné mít kvalitní a kompletní data.

33

34

8 Testování aplikace 8.1 Funkční testování Jde o testování zaloţené na případech uţití. Po jejich průchodu lze konstatovat, ţe veškerou poţadovanou funkčnost se podařilo implementovat. Aplikace umoţňuje tvořit reporty a zároveň se stará a pravidelné přepočítávání aktuálních dat, kde je tomu tak potřeba.

8.2 jUnit testování GWT umoţňuje testovat aplikaci za pouţití nástroje jUnit. To je uţitečné zejména v případě rozšiřování aplikace, aby bylo moţné ověřit, zda se tím nenarušil původní kód. Rozhodl jsem se otestovat hlavně metody, které pouţívám na statistické výpočty. To provádím tak, ţe zavolám příslušnou metodu a pak výsledek porovnám s asercí. Otestoval jsem takto všechny výpočetní metody. U testování komponent se objevil problém, protoţe jsem na testování nemyslel dostatečně uţ při tvorbě aplikace a bylo obtíţné testovat kód, který byl skryt uvnitř komponent uţivatelského rozhraní (Widget). Tvorba testů probíhá tak, ţe vlastní testovací třídu rozšířím o „GWTTestCase“ a načtu modul, se kterým budu pracovat. Vyvíjená aplikace se skládá pouze z jednoho modulu, a to výrazně zrychluje provádění testů.

8.3 Testování výkonu a optimalizace Snaţil jsem se zrychlit načítání a najít úzká hrdla aplikace, která prodluţují čekání na odpověď. Vzhledem k tomu, ţe klientská část je postavená na Javascriptu, je důleţité k jejímu spouštění pouţívat moderní prohlíţeče, ve kterých je zpracování Javascriptu optimalizované. Na základě auditu pomocí nástroje SpeedTracer [23], jsem zjistil, ţe nejdéle trvají dotazy na databázi a pokusil jsem se o jejich optimalizaci tím, ţe jsem zapnul cache

35

v MySQL. Bylo by vhodné statická data, jako je například nápověda u pole lokace, ukládat u uţivatele.

36

9 Závěr a možné rozšíření 9.1 Možné rozšíření Vzhledem k tomu, ţe trh nemovitostí je poměrně obsáhlé téma, existuje velký prostor pro přidávání funkcionalit a dalších vylepšení. V pouţitém frameworku GWT probíhá rychlý vývoj a nové verze se objevují poměrně často. Díky tomu aplikace rychle morálně zastarává. To je ovšem dáno i rychlým vývojem webových technologií. V klientské části aplikace lze například rozšířit formulář pro výběr nemovitostí o další zajímavé proměnné, podobně jako tomu je na webových stránkách realit. Bylo by také uţitečné, vyuţít geolokační data v databázi a umoţnit výběr prohledávané oblasti na interaktivní mapě. Funkčnost Price Map by byla rovněţ názornější, v případě ztvárnění pomocí heatmapy. Existující řešení, která jsem analyzoval, také poskytují v některých případech export reportu do souboru typu pdf. To by bylo vhodné implementovat z důvodu zpřístupnění aplikace potencionálním klientům. Jasně strukturovaný report zaslaný například na email by umoţnil laikovi se pohodlně zorientovat před nákupem nemovitosti. Zajímavé by také bylo zpracovávat nabídky v reálném čase, během nasazení webového crawleru. Zde je ale zásadním poţadavkem zlepšení kvality uloţených dat.

9.2 Zhodnocení V této práci jsem se nejprve pokusil za pomoci analýzy existujících řešení, přijít na to, jak se pracuje efektivně s realitními daty. Na jejich příkladu je vidět, ţe o komplexní reporty je na trhu velký zájem. Na základě zjištěných poznatků jsem se pokusil nadefinovat poţadavky, které jsem pak podrobil analýze a návrhu. Důleţitá byla vhodná volba implementační platformy. Myslím, ţe v počátcích vývoje byla volba správná, i kdyţ v současné době se jiţ objevují vhodnější nástroje. Je to jeden z faktorů, díky kterému se povedlo úspěšně implementovat poţadavky a v tuto chvíli aplikace umoţňuje zobrazit historii cen, jejich

37

rozdělení na trhu, produkovat základní reporty a vyhledávat výhodné nabídky. To vše souvisí se snahou analyzovat trh realit a utvořit si v něm lepší přehled. Pro případ dalšího vývoje se povedlo poloţit základní kámen, na kterém lze dále stavět, a aplikace by mohla dospět aţ do podoby expertního systému pro podporu rozhodování nebo jako doplněk jiţ existujícího realitního serveru. Mně osobně přišla práce na aplikaci zajímavá z toho důvodu, ţe nešlo jen o to „naklikat“ web, ale bylo třeba hledat optimální řešení za pomoci matematiky a statistiky. Práce s reálnými daty nemovitostí byla taktéţ zajímavým prvkem v implementaci a umoţnila lépe si představit podmínky produkčního nasazení.

38

Citovaná literatura [1]. Eric Schmidt: Every 2 Days We Create As Much Information As We Did Up To 2003. Techcrunch. [Online] [Citace: 17. 5. 2011] http://techcrunch.com/2010/08/04/schmidt-data/ [2]. Rise of the Data Scientist. FlowingData . [Online] [Citace: 11. 5. 2011] http://flowingdata.com/2009/06/04/rise-of-the-data-scientist/ [3]. Fry, Ben. Computational information design. [Online] [Citace: 17. 5. 2011] http://benfry.com/ [4]. Flowing Data. [Online] [Citace: 11. 5. 2011] http://flowingdata.com/ [5]. Visual Complexity. [Online] [Citace: 11. 5. 2011] http://www.visualcomplexity.com/vc/ [6]. Information is Beatiful. [Online] [Citace: 11. 5. 2011] http://www.informationisbeautiful.net/ [7]. Trulia. [Online] [Citace: 11. 5. 2011] http://www.trulia.com/ [8]. Rightmove Key Stats. Rightmove. [Online] [Citace: 11. 5. 2011] http://www.rightmove.co.uk/rightmoveplc//key-stats.html [9]. Wikipedia. [Online] [Citace: 11. 5. 2011] http://en.wikipedia.org/wiki/Zillow.com [10]. Stamen Design. [Online] [Citace: 11. 5. 2011] http://content.stamen.com/cheerio_maps [11]. Microsoft Office Visio 2010. [Online] [Citace: 11. 5. 2011] http://office.microsoft.com/en-us/visio/ [12]. Enterprise Architect. [Online] [Citace: 11. 5. 2011] http://www.sparxsystems.com.au/ [13]. Google Refine. [Online] http://code.google.com/p/google-refine/ [14]. Prezentační vzory z rodiny MVC. [Online] [Citace: 11. 5. 2011] http://zdrojak.root.cz/clanky/prezentacni-vzory-zrodiny-mvc/

39

[15]. GWT MVP Development with Activities and Places. [Online] [Citace: 5. 11. 2011] http://code.google.com/intl/csCZ/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html [16]. Communicate with a Server. [Online] [Citace: 11. 5. 2011] http://code.google.com/intl/csCZ/webtoolkit/doc/latest/DevGuideServerCommunication.html [17]. Serialization. [Online] [Citace: 11. 5. 2011] http://en.wikipedia.org/wiki/Serialization [18]. Průcha, Ladislav. Typy rozdělení. [Online] [Citace: 12. 5. 2011] http://math.feld.cvut.cz/prucha/ubmip/p6u.pdf [19]. Developer's Guide - Cell Widgets. [Online] [Citace: 14. 5. 2011] http://code.google.com/intl/csCZ/webtoolkit/doc/latest/DevGuideUiCellWidgets.html [20]. Decision making paradox. [Online] [Citace: 16. 5. 2011] http://en.wikipedia.org/wiki/Decision_making_paradox [21]. Weighted sum model. [Online] [Citace: 16. 5. 2011] http://en.wikipedia.org/wiki/Weighted_sum_model [22]. Cenové mapy. [Online] [Citace: 16. 5. 2011] http://www.cenovemapy.cz/ [23]. Speed Tracer. [Online] [Citace: 11. 5. 2011] http://code.google.com/intl/csCZ/webtoolkit/speedtracer/ [24]. Commons - Math. [Online] [Citace: 11. 5. 2011] http://commons.apache.org/math/

40

Příloha A

Seznam použitých zkratek

AVM – Automated Valuation Model MCDM – Multi Criteria Decision Making GWT – Google Web Toolkit RPC – Remote procedure call DOM – Document Object Model MVP – Model View Presenter MVC – Model View Controller SVG – Scalable Vector Graphics VML – Vector Markup Language IDE – Integrated development environment API – Application Programming Interface XML – Extensible Markup Language SDK – Software development kit AVM – Automated Valuation Model RAD – Rapid Application Development CASE – Computer-aided software engineering SQL – Structured Query Language

41

42

Příloha B

Instalační příručka

Zde popíšu stručně instalaci a spuštění aplikace z DVD disku. Uţivatel má na výběr z dvou moţností. Pokud jiţ na svém počítači provozuje MySQL databázi a server Apache Tomcat, je moţné provést import dat do datábaze a deploy war balíčku na server. Nastavení připojení k databázi je uloţeno ve sloţce server data. Podrobněji rozepíšu druhou moţnost a to spuštění aplikace z přiloţeného virtuálního disku. 1. Nejprve je potřeba nainstalovat VirtualBox. 2. Po úspěšné instalaci program spustíme a kliknutím na „nový“ spustíme průvodce vytvořením nového virtuálního počítače. 3. V průvodci vybereme typ operačního systému Linux a verzi Ubuntu. 4. Velikost paměti můţeme ponechat na přednastavených 512 MB. 5. Při výběru virtuálního pevného disku zvolíme pouţít existující disk a vybereme ten, co je přiloţen na DVD. 6. Pak uţ je moţné virtuální počítač spustit a po zobrazení plochy kliknout na odkaz

bakalářka

nebo

otevřít

firefox

a

do

adresy

zadat:

http://localhost:8080/data-reporting/

43

44

Příloha C

Obsah přiloženého DVD

Zde je stručně popsán obsah a hierarchie sloţek přiloţeného DVD.



analýza – Obsahuje projekty Microsoft Visio a Enterprise Architect pouţité při tvorbě modelů a diagramů.



server data – Data aplikace připravené pro umístění na server v podobě war balíčku a obsahu databáze připravené na import. Je přiloţen, textový dokument se správným nastavením připojení k mysql databázi.



text práce – Text práce v pdf a formátu Microsoft Word



virtual box – Obsahuje instalační soubor Virtualbox pro operační systém Windows a virtuální disk s připraveným prostředím a aplikací.



zdrojové kódy – Projekt připravený pro práci v Eclipse IDE 3.6

45