České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Diplomová práce
Systém pro sběr a distribuci meteorologických údajů Bc. Dominik Mervart
Vedoucí práce: Ing. Jiří Chludil
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 12. května 2011
iv
v
Poděkování Děkuji panu Ing. Jiřímu Chludilovi za vedení mé diplomové práce. Dále bych chtěl poděkovat své rodině a snoubence Lídě za podporu a trpělivost. Mé díky patří také čtyřnohé kamarádce Tině za to, že mě půl života doprovázela. Děkuji také panu Obi-Wanu Kenobimu za inspiraci a morální podporu.
vi
vii
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
Abstract This diploma thesis deals with analysis, design and implementation of the system for gathering and distribution of meteorological data. This system allows reading of data from sensors and meteorological stations, sending of measured data to server and providing to another users or creating statistics and graphs. For places that are not covered by a client station are provided data from external providers of meteorological data. The objective of this thesis is to provide users an opportunity to obtain weather data in their area that are more accurate than data available elsewhere. Ease of use and multi-platform functionality are taken into account in the design and implementation phases. In the first part of the thesis is essential information about meteorology, meteorological values and kinds of meteorological stations. The second part describes features and requirements laid on the system. The third part deals with analysis and design of the system. The fourth part attends to its implementation and testing.
Abstrakt Tato diplomová práce se zabývá analýzou, návrhem a implementací systému pro sběr a distribuci meteorologických údajů. Tento systém umožňuje čtení údajů z čidel a meteorologických stanic, jejich zasílání na server a poskytování dalším uživatelům nebo vytváření statistik a grafů. Pro místa, která nejsou pokryta klientskou stanicí, jsou poskytovány převzaté údaje od externích poskytovatelů meteorologických dat. Cílem této práce je poskytnout uživatelům možnost získat údaje o počasí v jejich oblasti, které jsou přesnější než údaje dostupné jinde. Při návrhu a implementaci je dbáno na jednoduchost použití a multiplatformnost systému. V první části jsou uvedeny základní informace o meteorologii, meteorologických veličinách a druzích meteorologických stanic. Druhá část popisuje vlastnosti a požadavky kladené na systém. Třetí část se zabývá analýzou a návrhem systému. Čtvrtá část se věnuje jeho implementaci a testování.
D Grafické uživatelské rozhraní E Uživatelská příručka E.1 Příručka centrální části . . . . . . . . . . . . . . . . . . E.2 Příručka aplikace pro komunikaci s měřícími stanicemi . E.3 Příručka aplikace pro zobrazení meteorologických údajů E.4 Instalační příručka serveru . . . . . . . . . . . . . . . . . F Obsah přiloženého CD
Testování použitelnosti - Hlavní stránka systému . . . . . . Testování použitelnosti - Seznam převzatých stanic s mapou Testování použitelnosti - Údaje převzaté stanice . . . . . . . Měsíční graf naměřené teploty na stanici Labská louka . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
82 83 83 84
použití frameworku PEAR - přístup k databázi použití frameworku PEAR - vytvořený graf . . . použití šablonovacího systému Smarty . . . . . . mapy převzatých stanic . . . . . . . . . . . . . .
Úvod Změny počasí jsou pozoruhodný přírodní jev, který odjakživa působí na veškerý zemský povrch a jeho obyvatele. A to často velmi razantním způsobem. Znalost toho, jaké počasí přijde, byla vždy velmi důležitá, rozhodovala například o tom, zda bude dostatek úrody nebo je potřeba mít dostatečné zásoby, zda bude mírná či krutá zima nebo zda je možné očekávat záplavy nebo sucho. Ve své podstatě počasí vždy bylo jedním z velmi důležitých faktorů přežití lidí, zvířat i rostlin. V průběhu času lidstvo postupně vypozorovalo určité zákonitosti a naučilo se předvídat (nebo spíše odhadovat), jaké počasí bude v budoucnu. Jako první indicie sloužily projevy v rostlinné a živočišné říši, srážky či sucho, chlad či horko. S rozvojem vědy a techniky vznikly první přístroje schopné určit mnohem přesněji hodnoty fyzikálních jevů, matematika posloužila svým aparátem k definování zákonitostí a vytváření statistik. Po vzniku počítače se jedním z jeho primárních využití stalo i interpretování těchto dat a vytváření krátkodobých a dlouhodobých předpovědních modelů. Meteorologická data mohou ale také velmi snadno interpretovat i lidé. Vysoká vlhkost a prudký pokles tlaku může znamenat blížící se déšť, nízká teplota nás zase nutí vytáhnout ze skříně teplé oblečení. Protože hlavní meteorologické stanice nejsou v každé obci v republice a často nejsou ani ve městech, ale spíše mimo ně, aby nebyly ovlivněny specifickými teplotními a jinými charakteristikami městské zástavby, může se často skutečná teplota, vlhkost nebo oblačnost v místě našeho bydliště lišit od údajů, které nám poskytují profesionální meteostanice vzdálené několik desítek kilometrů. Jsou také údaje, např. teplota, které jsou velmi důležité nejen venku, ale i uvnitř budov. Firmy často potřebují monitorovat teplotu v serverovnách nebo provozech, aby byly upozorněny na případný výpadek chlazení a zabránily škodám na majetku nebo životech. Průmyslové využití měřících přístrojů je tedy velké. Meteorologie, jako snad každá vědní disciplína, také přitahuje mnoho nadšenců, kteří by uvítali možnost používat ke svým účelům více levnějších zařízení na různých místech než jednu drahou poloprofesionální stanici na jediném místě nebo by si přáli umístit údaje na centrální shromaždiště dat, kde by byly dostupné také pro ostatní. Existují i méně složité přístroje umožňující měřit několik základních veličin, které by často většině lidí plně postačovaly, ale zase je problém, jak naměřená data poskytnout dalším zájemcům v okolí. Přímo se nabízí využít fenoménu doby: Internetu.
1
2
KAPITOLA 1. ÚVOD
Pro výše nastíněné problémy se pokusím najít univerzální a přitom cenově přijatelné řešení a poskytnout tak alternativu drahým poloprofesionálním meteostanicím a jednoúčelovým čidlům. Cílem této diplomové práce je navrhnout a vytvořit systém, který umožní sbírat data z jednoduchých měřících stanic připojených k počítači, nahrávat je na centrální server a umožní uživateli mít rychlý přehled o počasí přímo v jeho lokalitě, a to i zpětně například formou grafů a statistik. Bude umět upozornit různými způsoby při překročení kritické teploty. Jiní lidé v okolí se budou moci přihlásit k odebírání dat z těchto klientských stanic nebo případně podle své volby z údajů převzatých z jiných zdrojů, aby i oni měli k dispozici přesnější informace, než je kupříkladu denní předpověď v novinách.
Jak už bylo řečeno, počasí přímo utváří naše životy, naši budoucnost i naši náladu. Proto bych si dovolil na závěr úvodu připojit dva velmi pravdivé citáty. „Sunshine is delicious, rain is refreshing, wind braces us up, snow is exhilarating; there is really no such thing as bad weather, only different kinds of good weather.“ John Ruskin „There is little chance that meteorologists can solve the mysteries of weather until they gain an understanding of the mutual attraction of rain and weekends.“ Arnot Sheppard
Kapitola 2
Popis problému, cíle a požadavky V této kapitole budou popsány základní meteorologické pojmy a způsoby měření meteorologických údajů, což je nutné k pochopení funkčnosti a výhodám navrhovaného systému, dále bude uveden popis implementovaného systému a cíle diplomové práce. Na závěr kapitoly bude srovnání s funkčně obdobnými systémy.
2.1
Meteorologie a meteorologické údaje
V této části byly čerpány informace z [1] a [2].
2.1.1
Meteorologie
Slovo meteorologie pochází z řeckého meteoros (vznášející se ve výši) a logia (nauka). Meteorologie je věda zabývající se zkoumáním atmosféry. Zabývá se například studiem složení a stavby atmosféry, oběhu tepla a tepelným režimem v atmosféře a na zemském povrchu, oběhu vody a jejími fázovými změnami v interakci se zemským povrchem, elektrickým polem a optickými a akustickými jevy v atmosféře. Své studium zaměřuje hlavně na spodní vrstvy atmosféry troposféru a stratosféru, které se nachází do 50 km od zemského povrchu. Postupně osamostatňujícím se oborem se stává klimatologie, která studuje obecné zákonitosti klimatických jevů a utváření a změny zemského klimatu s cílem využít tyto poznatky pro dlouhodobé předpovědi klimatologických změn. Počátky meteorologie se datují do období antiky, neboť už tehdy si lidé všímali vlivu počasí na růst obilí a jiné polní práce. Další pokrok ale nastal až v 17. století, kdy byl vynalezen teploměr a barometr. V 19. století došlo k velkému rozmachu, stejně jako u jiných vědních disciplín, díky průmyslové revoluci. Vznikly první povětrnostní (synoptické) mapy, vysokohorské observatoře a byly vypouštěny první výzkumné balóny. Od poloviny 20. století začaly hrát hlavní roli družice na oběžné dráze kolem Země (buď nad stejným místem na geostacionární dráze ve výšce 36 000 km nebo na polárních drahách podél poledníků přes póly). Družice umožňují nejen sledování proudění vzduchu, ale také poskytují informace v infračerveném a viditelném spektru a o rozložení vlhkosti ve vzduchu.
3
4
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
2.1.2
Meteorologické prvky
Soubor meteorologických prvků definuje okamžitý stav atmosféry. Dále bude následovat popis základních meteorologických prvků, jejich význam a jakým přístrojem je možné je změřit. 2.1.2.1
Teplota vzduchu
Teplota je charakteristika tepelného stavu hmoty. Jednotkou SI je kelvin (K ), ale v meteorologii se po celém světě používá vedlejší jednotka stupeň Celsia (1 ◦ C = 1 K ) a v USA stupeň Fahrenheita (1 ◦ F = 5/9 ◦ C, C = 5 · (F − 32)/9). Teplota vzduchu je základní a pro člověka nejdůležitější meteorologickou veličinou. Vzduch se převážně ohřívá od Sluncem zahřátého zemského povrchu a částic ve vzduchu a to prostřednictvím vertikálních vzdušných proudů. V troposféře klesá teplota o 0,65 ◦ C/100 m. Teplotu vzduchu je vhodné měřit ve výšce 2 metry nad zemí a několik metrů od budovy, aby nebylo měření ovlivněno sálavým teplem ohřáté budovy. Taktéž je nutné zabránit přímému slunečnímu osvětlení čidla, k čemuž slouží např. takzvaná psychometrická (meteorologická) budka. Teplota se měří pomocí teploměru, které mohou fungovat na několika principech. První teploměr využívající roztažnosti vzduchu sestrojil začátkem 17. století Galileo Galilei. První lihový teploměr sestavil roku 1641 toskánský velkovévoda Ferdinand II. V meteorologii se používají hlavně teploměry: • kapalinové – jsou založené na teplotní roztažnosti kapalin (rtuť, líh - obrázek 2.1). • bimetalové – využívají pásek složený ze dvou kovů s různou teplotní roztažností k přenesení výchylky na ručičku přístroje. • plynové – využívají závislosti tlaku plynu na teplotě při stálém objemu nebo závislosti objemu na teplotě při stálém tlaku. • odporové – využívají závislosti elektrického odporu vodiče nebo polovodiče na teplotě. Polovodičový teploměr se nazývá termistor.
2.1.2.2
Vlhkost vzduchu
Vlhkost vzduchu udává, jaké množství vodní páry (vody v plynném skupenství) je přítomno v daném objemu vzduchu. Vlhkost vzduchu má zásadní vliv na vznik a průběh meteorologických jevů. Rozlišujeme absolutní a relativní vlhkost. Absolutní vlhkost je hustota vodních par ve vzduchu, jednotkou je kg/m3 . Relativní vlhkost je podíl okamžitého množství par a maximálního množství, které by vzduch o stejné teplotě a tlaku obsahoval při nasycení (tedy v okamžiku, kdy by se pára začala přeměňovat zpět na vodu). Relativní vlhkost se udává v procentech. Dalším údajem je rosný bod, což je teplota, při níž je vzduch daného tlaku nasycený a páry se začnou srážet.
2.1. METEOROLOGIE A METEOROLOGICKÉ ÚDAJE
5
Obrázek 2.1: Lihový teploměr Zdroj: [3]
Metody měření vlhkosti: • absolutní metoda je založena na rozdílu hustot vlhkého a plně vysušeného vzduchu. • kondenzační metoda využívá ochlazení měřícího kontaktu tak, aby páry zkondenzovaly a byl stanoven rosný bod. Pak je spočítána relativní vlhkost. • hygrometrická metoda využívá látkové změny v závislosti na vlhkosti. Např. vlasový hygrometr měří změnu délky lidského vlasu v závislosti na vlhkosti. • elektrická metoda je založena na změně kapacity kondenzátoru. • psychometrická metoda využívá dvou teploměrů, jednoho suchého a jednoho mokrého, a podle rozdílu teplot, tlaku a tabulek je určena relativní vlhkost. Příkladem je Assmanův aspirační psychrometr nebo Augustův psychrometr. 2.1.2.3
Atmosférický tlak
Atmosférický tlak je vyvolán tíhou vzduchového sloupce na zemský povrch, nejvyšší je u povrchu a s výškou klesá. Jednotkou je hektopascal [hPa] nebo milibar [mbar], 1 hP a ∼ 1 mbar. Starší jednotkou je 1 mm rtuťového sloupce [torr], 1 torr ∼ 4/3 hP a. Tlak vzduchu klesá s nadmořskou výškou přibližně na polovinu každých 5,5 km (v troposféře platí pokles 1 hPa na každých 8 metrů výšky). Spojnice míst se stejným tlakem se nazývá izobara. Změny tlaku jsou nepravidelné (např. nerovnoměrně ohřátým povrchem) a pravidelné (denní, roční).
6
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
Tlak měříme kovovým tlakoměrem (aneroidem), který využívá principu deformace kovové krabičky, nebo rtuťovým tlakoměrem, který udává tlak jako výšku rtuťového sloupce, který vytlačí vzduch, viz. obrázek 2.2.
Obrázek 2.2: Rtuťový tlakoměr Zdroj: [4]
2.1.2.4
Rychlost a směr větru
Vzduch má tendenci proudit z míst s vyšším tlakem do míst s nižším tlakem a tak vzniká vítr. Čím vyšší je rozdíl tlaku, tím vyšší rychlost vítr má. Směr větru udáváme ve stupních větrné růžice (platí: 0 ◦ = S, 90 ◦ = V, 180 ◦ = J, 270 ◦ = Z), přičemž směr označuje, odkud vítr vane. Rychlost větru se měří v m/s (příp. km/h). Odhad rychlosti větru nám poskytuje Beaufortova stupnice síly větru, viz. tabulka 2.1. K měření rychlosti a směru větru se používá anemometr (větroměr) umístěný 10 metrů nad zemí. Existuje několik druhů anemometrů: • mechanický – energie větru se přenáší na konstrukci, která rotuje nebo je vychylována. Příkladem jsou miskové (obrázek 2.3) nebo lopatkové anemometry. • aerodynamický – tlak proudícího vzduchu je porovnáván s tlakem atmosférickým. • zchlazovací – kovové čidlo je vystaveno větru a z rychlosti zchlazování lze spočítat rychlost větru. • akustické – měří rychlost a směr větru ze změn šíření zvuku ve vzduchu.
2.1.2.5
Srážky
Srážky jsou zkondenzované vodní páry v ovzduší. Dělí se podle skupenství nebo podle toho, zda padají z oblohy (vertikální) nebo kondenzují přímo na povrchu (horizontální).
2.1. METEOROLOGIE A METEOROLOGICKÉ ÚDAJE
0
rychlost [km/h] 0-1
1
1-5
vánek
2
6 - 11
slabý vítr
3
12 - 19
mírný vítr
4
20 - 28
dosti čerstvý vítr
5
29 - 38
čerstvý vítr
6
39 - 49
silný vítr
7
50 - 61
prudký vítr
8
62 - 74
bouřlivý vítr
9
75 - 88
vichřice
10
89 - 102
silná vichřice
11
103 - 117
mohutná vichřice
12
118 a více
orkán
stupeň
označení
rozpoznávací znaky
bezvětří
kouř stoupá svisle vzhůru kouř už nestoupá úplně svisle, korouhev se nehýbe vítr je cítit ve tváři, listí šelestí, korouhev se pohybuje listy stromů a větvičky jsou v trvalém pohybu vítr zdvihá prach, pohybuje slabšími větvemi hýbe listnatými keři, malé stromky se ohýbají vítr pohybuje silnějšími větvemi, je těžké používat deštník vítr pohybuje celými stromy, chůze proti větru je obtížná láme větve, vzpřímená chůze proti větru je téměř nemožná vítr způsobuje menší škody na stavbách vyvrací stromy, způsobuje větší škody na stavbách působí rozsáhlá zpustošení ničivé účinky, odnáší domy, pohybuje těžkými hmotami
7
Tabulka 2.1: Beaufortova stupnice síly větru Zdroj: [5]
Mezi kapalné srážky patří déšť a mrholení (vertikální) a rosa (horizontální). Mezi tuhé srážky patří mrznoucí déšť, mrznoucí mrholení, sníh, sněhové krupky, sněhová zrna, zmrzlý déšť, krupky, kroupy a ledové jehličky (vertikální) a zmrzlá rosa, jinovatka, námraza a ledovka (horizontální). U srážek se měří množství (úhrn, obvykle za 6/12/24 hodin), doba trvání a intenzita (množství za kratší dobu, např. 1 hodina). Množství se udává v mm kapalné vody spadlé na vodorovný povrch, přičemž 1 mm = 1 l/m2 . U sněhu 1 mm odpovídá přibližně 1 cm prachového sněhu. Intenzita srážek se dělí podle tabulky 2.2. K měření množství se používají srážkoměry (hyetometry, ombrometry), které jsou tvaru válce s nálevkou. Pro měření průběhu srážek slouží ombrografy, které jsou složeny z nádoby s plovákem a registračního zařízení, nebo modernější člunkové srážkoměry. Ty čítají četnost překlopení člunku při jeho naplnění srážkami z jedné poloviny, což určuje celkový úhrn srážek. Ke sledování intenzity srážek na velké ploše se využívá meteorologických radarů.
8
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
Obrázek 2.3: Miskový anemometr Zdroj: [6] intenzita velmi slabá slabá mírná silná velmi silná
Tabulka 2.2: Rozdělení intenzity srážek Zdroj: [7]
2.1.2.6
Oblačnost
Oblačnost je stupeň pokrytí oblohy oblaky. Obvykle se oblačnost vyjadřuje v osminách, viz tabulka 2.3. 2.1.2.7
Další prvky
Mezi další meteorologické prvky patří: • Záření – např. množství UV záření dopadajícího na zemi. • Délka slunečního svitu – dokresluje průběh počasí v daném místě a udává počet hodin za danou jednotku času, kdy svítí slunce. Měří se slunoměrem. • Vypařování a kondenzace vody v ovzduší • Výška a stav sněhové pokrývky • Aerosoly – malé pevné (dým) nebo kapalné (mlha) částečky v ovzduší. Jsou jednou z příčin znečištění a určují dohlednost.
2.2. METEOROLOGICKÉ STANICE
9
Obrázek 2.4: Radarový snímek intenzity srážek nad ČR Zdroj: [8]
• Přírodní a umělá radioaktivita • Extrémní hodnoty – minima a maxima (denní, měsíční, roční) výše uvedených meteorologických prvků
2.2
Meteorologické stanice
V této části budou uvedeny různé druhy meteorologických stanic, jejich výhody a nevýhody.
2.2.1
Profesionální stanice
Za profesionální meteorologické stanice jsou považována měřící stanoviště státních institucí, která využívají moderní drahé a přesné měřící přístroje. V ČR jsou tyto stanice provozovány Českým hydrometeorologickým ústavem (ČHMÚ) a několik stanic Armádou ČR. Stanice ČHMÚ se dělí do tří kategorií: Hlavní profesionální stanice – měří široké spektrum údajů (teplota, vlhkost, rosný bod, oblačnost, spodní vrstva mraků, rychlost a směr větru, nárazový vítr, tlak vzduchu
10
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY pokrytí 0/8 1/8 2/8 3/8 4/8 5/8 6/8 7/8 8/8 9
význam jasno skoro jasno skoro jasno polojasno polojasno oblačno oblačno skoro zataženo zataženo nelze rozeznat (mlha, silný déšť, sníh, ...) Tabulka 2.3: Stupně oblačnosti Zdroj: [9]
a jeho tendence, úhrn a intenzita srážek, vizuální průběh počasí). V současné době ČHMÚ provozuje 39 těchto stanic po celé ČR a jsou obsluhovány zaměstnanci ČHMÚ. Tyto stanice jsou také označovány jako synoptické, což znamená, že jejich úkolem je pořizovat meteorologická data pro účely synoptické meteorologie, jejímž hlavním cílem je diagnóza a předpověď počasí. Automatické základní stanice (AMS) – tyto stanice měří pouze základní údaje (teplota, rychlost a směr větru, vlhkost, srážky), které jsou převážně využívány pro potřeby klimatologie. V ČR jich je přibližně 150. Srážkoměrné stanice – měří obvykle pouze množství srážek a sněhu a slouží pro potřeby klimatologie a spolu s hlásnými profily povodňové služby k monitoringu rizika záplav. Po České republice jich je rozmístěno více než 200. Data z těchto profesionálních stanic jsou velmi přesná a jsou využívána k oficiálním předpovědím počasí, pro klimatologické účely a jsou také využívána i dalšími institucemi, médii atp. Vychází se z nich při vyhlašování varování před záplavami, vichřicí a jiným živelným ohrožením. Stanoviště stanic se obvykle nachází mimo hustou městskou zástavbu, často na louce na okraji malých obcí. To je nutné kvůli tomu, aby nebyla měření zkreslována (vyzařování tepla nebo lámání větru budovami) a také kvůli tomu, že je nutná určitá výška pro umístění přístrojů (např. 2 m od země pro teploměry a vlhkoměry nebo 10 m pro větroměry). Ochranu před slunečními paprsky poskytuje pro většinu přístrojů psychometrická budka (obrázek 2.5). Data z hlavních stanic jsou veřejně dostupná online na serveru ČHMÚ v textové i grafické podobě a jsou aktualizována v hodinových intervalech. Údaje z některých stanic jsou také předávány do celosvětového systému výměny meteorologických dat. Odkaz na aktuální údaje: http://pr-asv.chmi.cz/synopy-map/
2.2. METEOROLOGICKÉ STANICE
11
Obrázek 2.5: Psychometrická budka Zdroj: [10]
Oproti tomu data ze stanic AMS jsou veřejně dostupná online pouze ve formě grafů. Interval aktualizace je 10 minut. Odkaz na aktuální údaje: http://portal.chmi.cz/files/portal/docs/poboc/PR/grafy/grafy-ams-lnk.htm
2.2.2
Poloprofesionální stanice
Poloprofesionální stanice jsou obvykle ucelená komerční řešení, která jsou provozována obecními úřady, školami nebo nadšenci. V několika případech jde o vlastnoručně vyrobené stanice, které se funkčností blíží těm komerčním. Tyto stanice většinou měří teplotu, vlhkost vzduchu, tlak a často také rychlost a směr větru a srážky. Tyto stanice obvykle mají připojení k počítači a umožňují pomocí softwaru nahrávat data na internet. Často jsou ale pouze na vlastní stránce majitele, což je pro centralizované shromažďování a poskytování údajů problematické. Proto vznikl např. zahraniční server Weather Underground (WU), který shromažďuje data z těchto poloprofesionálních stanic a je možné je snadno vyhledat a získávat z nich údaje. WU poskytuje přímo na svých stránkách přehledy, statistiky a grafy, a také veřejné API pro získávání aktuálních a denních údajů. Adresa Weather Underground: http://www.wunderground.com/weatherstation/ Poloprofesionální stanice mají ale také své nevýhody. Někdy poskytují nepřesné údaje při nízkých či vysokých teplotách. Dalším problémem může být připojení PC se stanicí k internetu a některé stanice tak mají časté výpadky poskytování údajů. Na druhou stranu, je jich poměrně velké množství a doplňují tak profesionální stanice tam, kde nejsou. Na WU jich je zaregistrovaných přes 100. Další nevýhodou je jejich cena, která je často u lépe vybavených
12
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
stanic pro obyčejného meteo-amatéra příliš vysoká. Levnější stanice zase postrádají některé funkce, dodávané programy nemohou nahrávat na internet, čidla jsou horší kvality a po čase odcházejí.
2.2.2.1
Komerční meteostanice
Zde následuje přehled nejpoužívanějších komerčních meteostanic a jejich cena a možnosti.
Davis Vantage Pro2 Tato stanice patří k těm nejlepším poloprofesionálním stanicím, je vyráběna v USA a má kvalitní a přesná čidla. Sada obsahuje teploměr (vnitřní a venkovní), tlakoměr, srážkoměr, větroměr, vlhkoměr a další doplňky (UV čidlo, senzor solární radiace). Umí zobrazit množství statistik za volitelné období. Velké množství různých alarmů. Připojení k PC je možné po zakoupení programové sady WeatherLink a připojení probíhá buď po USB, RS-232 nebo LAN. Cena: 14 000 Kč kabelová varianta, 17 000 Kč bezdrátová varianta, dodatečná sada WeatherLink stojí 5000 Kč. Odkaz: http://www.davis.cz/vantage-pro-2.html
Obrázek 2.6: Meteostanice Davis Vantage Pro2 Zdroj: http://www.davis.cz/vantage-pro-2.html
2.2. METEOROLOGICKÉ STANICE
13
Davis Vantage Vue Vue je levnější varianta Pro2, vyrábí se pouze v bezdrátové variantě. Sada obsahuje teploměr (vnitřní a venkovní), tlakoměr, srážkoměr, větroměr a vlhkoměr - tedy umožňuje měřit všechny základní údaje. Pamatuje si údaje pouze 25 dní zpětně a není tolik rozšiřitelná jako Pro2. Dosah bezdrátového signálu je 300 m. Cena: 10 500 Kč, dodatečná sada WeatherLink stojí 5000 Kč. Odkaz: http://www.davis.cz/vantage-vue.html Oregon Scientific WMR 200 WMR 200 je velmi podobný Davis Vantage Vue s podobnými možnostmi, lze také přikoupit UV čidlo. Oproti Vue má menší dosah bezdrátového signálu (100 m). Součástí sady je omezená verze programu Weather Display, která má některé funkce zablokované, např. nahrávání na internet. Připojení k PC je možné pouze přes USB. Cena: 12 500 Kč Odkaz: http://www.ab-com.cz/meteostanice-oregon-scientific-wmr200-pc-usb.html TFA 35.1075 Nexus Tato stanice umožňuje měření teploty, vlhkosti, tlaku, rychlosti a směru větru a srážek a to bezdrátově a až na vzdálenost 100 m. Připojení k PC je možné pouze pomocí USB portu, dodávaný program Wetterstation neumí nahrávat na internet. Cena: 8 500 Kč Odkaz: http://www.aceselectronics.co.uk/product.php?xProd=509 Technoline WS 2300 Tato bezdrátová stanice je z těch levnějších a umožňuje měření teploty, vlhkosti, tlaku, rychlosti a směru větru a srážek. Maximální vzdálenost venkovního čidla je 25 m. Připojení k PC je možné pomocí RS-232 portu, dodávaný program neumí nahrávat na internet. Pamatuje si pouze minima a maxima. Cena: 4 000 Kč Odkaz: http://www.alza.cz/technoline-ws-2300-d129367.htm Watson WH1080 Tato bezdrátová stanice je další z těch levnějších, pochází z Číny a umožňuje měření teploty, vlhkosti, tlaku, rychlosti a směru větru a srážek. Maximální vzdálenost venkovního čidla je 25 m. Připojení k PC je možné pomocí USB portu, dodávaný program EasyWeather neumí nahrávat na internet. Podle ohlasů uživatelů nejsou měření moc přesná, hlavně co se větru a srážek týče, a čidla nemají příliš dlouhou výdrž. Cena: 2 800 Kč Odkaz: http://www.seguro.cz/eshop/3994-meteostanice-wh1080-t104.html
Sencor SWS 180 USB Tato stanice je ve všech ohledech velmi podobná Watson WH1080. Cena: 2 800 Kč Odkaz: http://www.videotech.cz/meteostanice/sws-180-usb-meteostanice-sencor
2.2.3
Amatérské stanice
Do této kategorie spadají všechny ostatní levné meteostanice. Jejich cena se pohybuje od 500 do 1500 Kč. Umožňují měřit pouze základní údaje jako je venkovní teplota, vlhkost a tlak a nemohou být připojeny k PC. Pro účely této práce nejsou zajímavé. Jejich přesnost ani životnost není příliš velká.
2.3. POPIS SYSTÉMU A CÍLE DIPLOMOVÉ PRÁCE
2.3
15
Popis systému a cíle diplomové práce
Systém pro sběr a distribuci meteorologických údajů je komplexní systém, který dovolí uživateli mít přehled o počasí v jeho lokalitě a to i zpětně formou grafů a statistik. Pracovní název je systém Meteoris. Systém se bude skládat z klientských měřících stanic, které budou pravidelně odesílat naměřené údaje na centrální server. Centrální server bude poté údaje poskytovat dalším uživatelům. Pro oblast pokrytou klientskou stanicí budou poskytována přesná data z klientské stanice, pro nepokrytou oblast budou poskytována převzatá data z externích serverů poskytujících meteorologické údaje. Klientské stanice mohou být od velmi levných čidel měřících jednu veličinu až po komplexní stanice. Software pro komunikaci s klientskými stanicemi bude modulární, aby ho bylo možné snadno rozšířit o podporu dalších stanic. Systém se zaměřuje na odstranění některých nedostatků profesionálních a hlavně poloprofesionálních meteostanic, které byly nastíněny v části 2.2. Zde jsou uvedeny ty největší: • stanice nejsou v každé obci, takže údaje z té nejbližší našemu bydlišti nemusí být přesné • poloprofesionální stanice nemusí poskytovat data 24 hodin denně nebo mohou mít i delší výpadky • čidla levnějších stanic se mohou snáze porouchat, což způsobí výpadky či chyby měření • cena poloprofesionálních meteostanic je vysoká, řádově několik tisíc až desítek tisíc korun • poloprofesionální meteostanice jsou komplexní, přitom by některým uživatelům stačila např. jen teplota • použití některých PC programů dodávaných se stanicemi je problematické • dodávaný software je téměř bez výjimky pouze pro OS Windows • zpřístupnění dat ze stanice na internetu může být komplikované • export dat a generování statistik může být také komplikované Současně budou implementovány některé další užitečné funkce tak, aby systém mohl fungovat jako celek, např. pro uživatele, který se zajímá o počasí ve svém bydlišti, nebo meteorologa-amatéra.
2.3.1
Komponenty systému
Systém se bude skládat ze tří samostatných komponent: centrální serverové části, klientských měřících stanic a aplikací s nimi komunikujících a odesílajících data na server a klientských zobrazovacích aplikací, které přebírají údaje ze serveru a zobrazují je uživateli na jeho počítači. V případě potřeby bude server ještě komunikovat s externími poskytovateli meteorologických údajů. Schéma komunikace je zobrazeno na obrázku 2.8.
16
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
Obrázek 2.8: Komponenty systému
Systém bude navržen velmi univerzálně, takže bude možné jednoduše přidávat implementaci komunikace s různými měřícími čidly a stanicemi, taktéž odesílaní nebo přijímání dat bude možné na libovolný server, jaký si uživatel zvolí (při patřičné modifikaci URL adresy a jejích parametrů). V serverové části bude možné jednoduše přidávat nové poskytovatele externích údajů, bude stačit přidat implementaci metody parsující data z dané www adresy. Obecně bude moci být klientská stanice jakákoliv (pokud bude známý komunikační protokol), aplikace obstarávající komunikaci s ní na to bude připravena. Tato diplomová práce se, v souladu se zadáním práce, zaměří hlavně na možnosti měření teploty. Jednotlivé části systému bude možné používat samostatně nebo v kombinaci. Například bude možné mít umístěnu klientskou stanici v jedné místnosti, odesílat data na server a v jiné místnosti je monitorovat (včetně alarmů) pomocí zobrazovací aplikace. Tím bude umožněno např. i průmyslové využití systému.
2.3.2 2.3.2.1
Co bude systém umožňovat Centrální serverová část
• příjem a uchovávání naměřených dat z klientských stanic • data budou uchována po neomezenou dobu • zobrazování aktuálních údajů uživatelům - z vlastních klientských stanic nebo převzatých z externích meteoserverů • komunikace serveru s uživateli bude probíhat buď prostřednictvím webového prohlížeče nebo klientských aplikací • API pro poskytování údajů stanic zobrazovacím aplikacím nebo jiným programům (textovou nebo obrazovou formou) • vytváření statistik a grafů z aktuálních údajů i za uplynulé období (dny, měsíce, roky)
2.3. POPIS SYSTÉMU A CÍLE DIPLOMOVÉ PRÁCE
17
• export dat • možnost měřit údaje klientskou stanicí pro vlastní potřebu (např. teplota v místnosti) • zobrazení aktuálních údajů na mapě Poznámka: V textu dále budou používány pojmy „stanice“ a „místo“. Stanicí je myšlena klientská stanice nebo převzatá profesionální či poloprofesionální stanice (resp. její údaje). Místem je myšleno spojení daného uživatele a zvolené stanice, ze které chce přijímat údaje do klientské aplikace pro zobrazení meteorologických údajů. Místa tedy využívají údajů ze stanic, ale jinak jsou stanice a jejich správa na serveru naprosto samostatné. Dále se rozlišuje „vlastní“ klientská stanice a „převzatá“ stanice. Vlastní stanicí jsou myšleny uživatelské stanice, které odesílají údaje na centrální server systému. 2.3.2.2
Klientská aplikace komunikující s měřícími stanicemi
• čtení a zobrazení údajů z meteostanice připojené k počítači uživatele • bude pracovat zcela samostatně, i bez využití funkcí serveru • ukládání dat do souboru a jejich volitelné odesílání na server (obecně libovolný) • několik nastavitelných alarmů (obrazové a zvukové upozornění) • v budoucnu bude možné odeslání emailu při spuštění alarmu • v budoucnu by místo vlastní komunikace s portem, ke kterému je stanice připojená, aplikace mohla číst údaje ze souboru, do kterého data zapisuje jiná aplikace obsluhující vlastní komunikaci (tak by byla značně zjednodušena případná složitá implementace komunikačního protokolu) • v budoucnu by mohla být aplikace naprogramována také pro „chytrý“ mobilní telefon, ke kterému by se čidlo připojilo a data či alarmy by mohly být odeslány např. formou SMS nebo emailem 2.3.2.3
Klientská aplikace zobrazující údaje
• zobrazení údajů převzatých z centrálního serveru (obecně libovolného) v počítači uživatele • může mít různou podobu - aplikace v systémové liště nebo mini-aplikace do Windows 7 • ukládání přijatých dat do souboru • několik nastavitelných alarmů (obrazové a zvukové upozornění) • v budoucnu bude možné odeslání emailu při spuštění alarmu
18
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
2.3.3
Požadavky na systém
• Reálná využitelnost systému (chci aby byl přínosný, dostal se mezi lidi a nezapadl prachem). • Bude umožňovat také připojení levnějších měřících čidel, jako alternativu k drahým meteostanicím. • Server a základní verze aplikací budou použitelné a šiřitelné zdarma, rozšířené verze a zdrojové kódy za úplatu. • Server bude uchovávat klientská data po neomezenou dobu. • Systém musí být uživatelsky přívětivý a nenáročný na ovládání. • Server poskytne základní míru bezpečnosti - přístup do uživatelské části bude pouze po přihlášení jménem a heslem (neuloženým v databázi), server bude chráněn proti běžným metodám napadení. • Multiplatformnost - desktopové aplikace budou fungovat na operačních systémech Microsoft Windows a Linux. • Desktopové aplikace budou fungovat i bez nutnosti využití serverových funkcí. • Data budou snadno zálohovatelná. • Aplikace budou co nejméně zasahovat do systému, na kterém běží, a jeho nastavení. • Aplikace budou snadno přenositelné na jiný počítač.
2.3.4
Cíl diplomové práce
Cílem této diplomové práce je analyzovat, navrhnout a implementovat funkční systém, který co nejlépe splní uvedené vlastnosti a požadavky. V úvahu bude vzato zadání práce a bude implementován zatím pouze způsob měření teploty, další druhy čidel nebo kompletních meteostanic mohou být přidány později v případě zájmu uživatelů nebo firem. Některé méně podstatné funkce, které jsou uvažovány navíc oproti zadání diplomové práce (zejména diskuzní fórum nebo odesílání emailů při alarmu) zatím nebudou implementovány a mohou být přidány v budoucnu. Systém a aplikace ale budou navrženy obecně, aby bylo možné tyto další funkce později přidat co nejjednodušeji.
2.4
Struktura diplomové práce
Kapitola 2 se zabývá shrnutím základních faktů o mteorologii, meteorologických údajích a stanicích. Jsou ukázány nedostatky a problémy, které jsou spojené s už dostupnými řešeními a uvedeny návrhy, jak je řešit. Je uveden přehled vlastností a požadavků na navrhovaný Systém pro sběr a distribuci meteorologických údajů. V poslední části je přehled a srovnání s již existujícími aplikacemi obdobného zaměření.
2.5. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU
19
Kapitola 3 se věnuje analýze projektu a softwarovému návrhu systému. Proběhne rešerše způsobů měření teploty pomocí počítače. Budou vybrány externí poskytovatelé údajů, jejichž import bude v prototypu systému implementován. Budou zvoleny formy aplikací a serveru, programovací jazyky a datové úložiště. Také bude diskutována výkonnost systému při větším množství uživatelů a její optimalizace. Kapitolu uzavře softwarový návrh systému včetně vybraných UML diagramů. Kapitola 4 popisuje použitá řešení dílčích implementačních problémů. Kapitola 5 nastíní proces testování, předvede výsledky testování funkčního systému a navrhne případné změny. Kapitola 6 shrne splnění vytyčených cílů a načrtne možný budoucí vývoj systému.
2.5
Existující implementace obdobného systému
Systémy, které by mohly plně konkurovat mnou navrhovanému projektu, neexistují, protože komplexnost systému (kombinace serveru, měřících aplikací a zobrazovacích aplikací) je poměrně velká a systém je jako celek poměrně neobvyklý. Existují pouze aplikace, které se zaměřují vždy na určitou část funkční domény, a nyní jich několik uvedu a popíšu v čem můj systém bude jiný nebo výhodnější.
2.5.1
Centrální server
Hlavní funkcí centrálního serveru je shromažďovat a poskytovat meteorologické údaje. A to hlavně z českých, případně slovenských stanic. Proto má smysl uvažovat pouze servery spolupracující s česko-slovenskými stanicemi. Servery poskytující aktuální přehled a předpovědi počasí v celé ČR nemá smysl uvažovat, jejich účel je značně odlišný od mnou navrhovaného systému. To samé platí pro weby sloužící pro poskytování údajů pouze z jedné stanice. meteo.Amut.NET Adresa: http://meteo.amut.net Primárně je tato stránka domovem amatérské meteorologické stanice v Písku, obsahuje ale také přehled meteostanic v České republice, a to jak profesionálních, tak amatérských (poloprofesionálních). U stanic ČHMÚ zobrazuje informace o aktuálním počasí ze serveru ČHMÚ, u amatérských stanic zobrazuje obrázek s počasím poskytnutý stránkou dané amatérské stanice. Kromě stanice Písek tedy na serveru nejsou přímo data z jiných stanic a ani není umožněno je tam nahrávat, data ostatních stanic jsou přebírána odjinud. Amatérská meteorologie v České republice Adresa: http://www.amaterskameteorologie.cz Tato stránka slouží jako registr amatérských meteorologů s odkazy na jejich stránky, server sám neposkytuje ani nepřijímá žádné meteorologické údaje. Možná ještě důležitější funkcí tohoto webu je diskuzní fórum o amatérské meteorologii, které je pravděpodobně největší v ČR a je zde množství užitečných rad.
20
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
Weather Underground Adresa: http://www.wunderground.com WU shromažďuje data z registrovaných poloprofesionálních stanic a je možné je snadno vyhledat a získávat z nich údaje. Poskytuje přímo na svých stránkách přehledy, statistiky a grafy a také veřejné API pro získávání aktuálních a denních údajů v XML formátu pro další zpracování. Weather Underground je podobný mnou navrhovanému systému co se týče klientských stanic, nemá ale žádnou funkčnost poskytování převzatých údajů pro místa, kde nejsou dostupné klientské stanice. Drobnou nevýhodou je také to, že WU je americký server a přijímá údaje ze stanic pouze v amerických měrných jednotkách, takže je před odesláním nutné udělat konverze z u nás používaných metrických jednotek. Poskytované údaje už jsou také v metrických jednotkách, ale kupodivu obsahují také chyby (např. špatně převádí srážky z palců na milimetry). Dále neumožňuje měření pro vlastní potřebu (např. teplotu v místnosti) a nemá upozornění při překročení nastavené teploty. WU také doporučuje, aby si uživatelé registrovali pouze poloprofesionální stanice, které umí měřit více údajů, což by mohl být problém pro jednoduchá a levná teplotní či vlhkoměrná čidla. Server uchovává data po celou dobu činnosti stanice. Stanice ani jejich údaje není možné zobrazit na mapě ČR a i jejich vyhledání je poměrně problematické, server nemá funkci zobrazení seznamu stanic podle země, je nutné hledat podle města. Protože je na Weather Underground registrovaných více jak 100 českých poloprofesionálních stanic (většina z nich aktivních) z různých míst České republiky a vzhledem k jeho veřejnému API, bude WU vhodný pro poskytování převzatých údajů v mém systému. Server je částečně počeštěn. Wedaal-Board Adresa: http://www.wedaal.de Wedaal-Board se obdobně jako WU zaměřuje primárně na příjem a poskytování údajů z klientských stanic, neumožňuje zobrazit převzaté údaje. Oproti WU uchovává pouze aktuální údaje a souhrné měsíční statistiky, takže data nejsou zpětně dostupná a proto také nedokáže generovat grafy. Je zde registrováno 8 českých poloprofesionálních stanic, většinou i těch, které jsou na Weather Underground. Server je kompletně v němčině. AWEKAS - Automatic Weather Map System Adresa: http://www.awekas.at Awekas je další ze serverů sbírajících data z klientských stanic. Také se zaměřuje pouze na klientské stanice. Uchovává data pouze 24 hodin a měsíční statistiky. Nahrávání na server je uděláno trochu jinak, než u jiných serverů, a sice Awekas automaticky v pravidelných intervalech kontroluje soubor na webech klientských stanic a importuje si data z tohoto daného souboru. Soubor musí být v určitém specifickém formátu, podporovány jsou formáty
2.5. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU
21
většiny programů pro obsluhu poloprofesionálních meteostanic. Jednoduché amatérské meteostanice nejsou tedy podporovány. V systému je evidováno přibližně 15 aktivních českých meteostanic. Server je kompletně v angličtině nebo němčině. Citizen Weather Observer Program Adresa: http://www.wxqa.com Tento server slouží jako velká veřejná databáze dat z amatérských klientských meteorologických stanic. Data pak případně poskytuje dalším meteorologickým serverům. Zkratka webu WXQA znamená Weather Quality Assurance a o to se web také snaží, poskytovat kvalitu. Stanice mohou být pouze poloprofesionální stanice měřící všechny základní údaje a kvalita poskytovaných údajů je pravidelně kontrolována. Údaje ze stanic jsou veřejně dostupné, ale pouze maximálně za poslední 2 měsíce zpětně. Data na něj nahrává přibližně 15 aktivních českých amatérských stanic. Server je kompletně v angličtině a je poměrně velmi nepřehledný (např. dostat se k údajům ze stanic chvíli trvá). Foreca, AccuWeather adresy: http://www.foreca.com, http://www.accuweather.com Tyto dva servery jsou uvedeny pro úplnost. Lze na nich vyhledat meteorologické údaje pro téměř jakékoliv město v České republice, ale po bližším zkoumání jsou všechna data převzatá od ČHMÚ. 2.5.1.1
Shrnutí
Jak bylo zjištěno, existující servery jsou zaměřeny výhradně buď na poskytování převzatých údajů nebo na sběr a poskytování vlastních údajů. Části pro sběr a zobrazení dat z klientských stanic mnou navrhovaného systému se nejvíc blíží Weather Underground, Awekas a Citizen Weather Observer Program. Awekas a CWOP uchovávají data pouze omezenou dobu a tudíž nejsou vhodné pro dlouhodobý sběr údajů a vytváření statistik. Ani jeden z těchto serverů neumožňuje příjem dat pouze pro vlastní potřebu (bez poskytování dále, např. měření teploty v místnosti). Kvůli tomu, že servery data poskytují veřejnosti, vyžadují obvykle zasílání všech základních meteorologických údajů a tudíž preferují poloprofesionální stanice. Kromě WU není žádný z těchto serverů v češtině. Všechny tyto servery nabízejí svou funkčnost zdarma. Celkově vzato, žádný z uvedených serverů nesplňuje všechny nebo alespoň většinu vlastností a funkcí mnou navrhované serverové části systému.
2.5.2
Klientská aplikace komunikující s měřícími stanicemi
Existuje několik freeware aplikací, které se zaměřují obvykle pouze na jeden typ konkrétního čidla (často jen teplotního) a fungují velmi problematicky, nestabilně nebo postrádají
22
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
požadované vlastnosti, jako je nahrávání na internet atd. Tyto aplikace nebudou v této rešerši dále uvažovány a uvedeny budou pouze kvalitnější aplikace, které obsahují mimojiné funkčnost podobnou mnou uvažované komponentě systému. Wetterstation Adresa: http://www.pc-wetterstation.de Tento program je vyvíjen německým amatérským meteorologem. Je na profesionální úrovni a umožňuje velké množství funkcí - zobrazení údajů, grafů, statistik, odesílání údajů na libovolný server (pomocí volitelných parametrů v URL adrese), export do souboru a zpětný import, alarmy a upozornění také přes email. cena: 750 Kč pro osobní použití, 1250 pro firmy multiplatformnost: ne (pouze OS Windows) podporované stanice: Oregon WMR-918, Davis VantagePro, Honeywell TE923/TN924, Irox Pro-X USB, TFA Nexus a všechny stanice La Crosse
Obrázek 2.9: GUI programu Wetterstation Zdroj: http://www.pc-wetterstation.de
WeatherLink Adresa: http://www.weatherlink.com WeatherLink je špičkový software a datalogger pro meteostanice firmy Davis, s jinými nespolupracuje. Obsahuje datalogger, což je záznamové zařízení připojitelné ke stanici, které zaznamenává údaje, když zrovna není stanice připojena k PC. Nahrávat na internet umí pouze varianta WeatherLinkIP a to na některé vybrané weby (např. Weather Underground, Citizen Weather Observer Program), podporuje alarmy pomocí emailů, umí grafy a export do různých formátů.
2.5. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU
23
cena: základní varianta 2800 Kč (buď USB nebo RS-232), WeatherLinkIP 5000 Kč jazyk: český, německý, anglický multiplatformnost: ne (pouze OS Windows a Mac OS X) podporované stanice: Davis Vantage Pro2 a Davis Vantage Vue
Virtual Weather Station Adresa: http://www.ambientweather.com/virtualstation.html Další profesionální program s velkým množstvím funkcí včetně nahrávání na internet na Weather Underground a další servery, nebo pomocí FTP. Prodává se ve variantách Základní a Pro (bez nahrávání na internet) a Internet (s nahráváním na internet). cena: Base Edition 850 Kč, Pro Edition 1200 Kč a Internet Edition 1700 Kč jazyk: anglický multiplatformnost: ne (pouze OS Windows) podporované stanice: všechny stanice od Davisu, Oregonu, La Crosse, Rainwise MKIII, Kestrel 4000 a další
Weather View 32 Adresa: http://www.weatherview32.com Software pro komunikaci s běžnými poloprofesionálními stanicemi s podobnou funkčností jako programy výše, včetně odesílání údajů na Weather Underground nebo CWOP. Zvlášť se prodává základní varianta a varianta s odesíláním dat na internet. cena: Home Edition 850 Kč, Professional Edition 1700 Kč jazyk: anglický multiplatformnost: ne (pouze OS Windows) podporované stanice: stanice od Davisu (pouze s dataloggerem WeatherLink), Oregon WMR-918, RainWise MK-III, několik sérií od Texas Weather Instruments a další
Weather Display Adresa: http://www.weather-display.com Weather Display má obdobné funkce jako Weather View 32, včetně nahrávání na Weather Underground. cena: 1200 Kč jazyk: anglický multiplatformnost: ano (OS Windows, Linux, Mac OS X) - samostatné aplikace pro jednotlivé OS podporované stanice: všechny stanice od Oregonu, Davisu (pouze s dataloggerem WeatherLink), Conrada, La Crosse a další
24
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
Obrázek 2.10: GUI programu WeatherDisplay Zdroj: http://www.weather-display.com
WUHU Adresa: http://home.comcast.net/~wuhu_software/ WUHU znamená Weather Underground / HeavyWeather Uploader a je primárně určen pro nahrávání na tyto servery. Dokáže nahrávat také na CWOP. Dále umí zobrazit načtená data, ale neumí z nich dělat statistiky, grafy. Má funkci alarmu a exportu. cena: 0 Kč jazyk: anglický multiplatformnost: ne (pouze OS Windows) podporované stanice: všechny stanice od La Crosse, Oregon WMR-918/WMR-968, Davis Vantage Pro2, Peet Bros 2100, Campbell CR1000 2.5.2.1
Shrnutí
Většina uvedených aplikací jsou rozsáhlé programy se spoustou funkcí podporující množství stanic a není překvapivé, že firmy si za tyto neustále vyvíjené komplexní produkty nechají zaplatit. Kromě Weather Display nejsou aplikace multiplatformní. Žádný z programů výše není naprogramován tak, aby bylo možné uživatelsky přidat vlastní jednoduché čidlo měřící jednu veličinu (teplotu, vlhkost) či dosud nepodporovanou stanici, přestože komunikační protokol může být velice jednoduchý (např. přes port RS232). Navíc z programů výše je zdarma pouze WUHU a ceny nejsou zrovna malé. Kromě Wetterstation také žádný program neumí nahrávat na libovolný server, ale pouze na několik předdefinovaných, takže nejsou vhodné pro komunikaci s navrhovaným centrálním serverem. Primární zaměření mnou navrhované komunikační aplikace je odesílání dat na server, export do souboru a alarmy. Grafy, statistiky a složitá zobrazovací činnost je funkcí serveru
2.5. EXISTUJÍCÍ IMPLEMENTACE OBDOBNÉHO SYSTÉMU
25
a není od aplikace požadována. Z počátku bude implementována komunikace pouze s jednoduchým teplotním čidlem, ale aplikace bude navržena tak, aby bylo možné jednoduše přidat podporu dalších čidel a stanic. Poplatek za přidání stanice pro jednotlivce může být nulový nebo pouze symbolický (pro firmu větší), což vyjde uživatele mnohonásobně levněji než koupě většiny programů výše. To jsou důvody, proč je vhodné naprogramovat vlastní komunikační aplikaci, která bude snadno rozšiřitelná.
2.5.3
Klientská aplikace zobrazující údaje
Existuje velké množství aplikací, které dokáží z internetu přečíst a zobrazit meteorologické údaje. Většina z nich přebírá data z několika málo velkých celosvětových serverů jako je Foreca.com nebo AccuWeather.com, které poskytují údaje převzaté od jednotlivých národních meteorologických institucí. Mezi tyto programy patří například i mini-aplikace Počasí, která je standardní součástí Windows 7. Některé programy (obvykle vytvořené uživatelem z dané země) přebírají údaje přímo od národního meteorologického úřadu. Nepodařilo se mi ale najít žádný program, který by uměl přijímat a zobrazovat údaje z libovolného serveru po zadání správné URL adresy, což je požadavek na moji klientskou zobrazovací aplikaci.
2.5.4
Zhodnocení existujících aplikací obdobného typu
Jak již bylo uvedeno výše, systémy, které by plně obsáhly funkčnost mnou navrhovaného projektu, neexistují. Některé aplikace se mu částečně blíží, ale nevyhovují v některých zásadních parametrech, jsou příliš drahé nebo zbytečně komplexní nebo by jejich využití pro dané účely bylo značně obtížné. Proto zde vidím mezeru na trhu, kterou by mohl zaplnit Systém pro sběr a distribuci meteorologických údajů.
26
KAPITOLA 2. POPIS PROBLÉMU, CÍLE A POŽADAVKY
Kapitola 3
Analýza a návrh řešení V této kapitole bude provedena rešerše způsobů měření teploty pomocí počítače. Budou vybrány externí poskytovatelé meteorologických dat a analyzovány jejich exportní formáty. V další části bude popsán výběr typu serveru a forma klientské komunikační a zobrazovací aplikace, výběr programovacích jazyků u jednotlivých komponent a bude zvolen typ databáze na serveru. Zbylá část této kapitoly se bude věnovat softwarovému návrhu aplikace.
3.1
Měření teploty pomocí počítače
Teplotu lze měřit pomocí meteostanic připojených k počítači (viz 2.2.2.1), ale toto řešení je poměrně dost drahé a pro někoho také třeba zbytečně komplexní. Proto provedu rešerši možností měření teploty pomocí počítače s důrazem na nízkou cenu, vysokou přesnost a kvalitu čidla a jednoduchost použití.
3.1.1
Rozhraní
Zařízení se k počítači běžně připojují drátově nebo bezdrátově. U kabelového připojení se dnes téměř vyhrádně používá USB rozhraní, v menší míře také RS-232 neboli sériové rozhraní či COM port (hlavně pro účely jednoduchých zařízení, jimiž jsou právě například měřící čidla). USB porty jsou dostupné v každém moderním PC, zatímco sériové převážně jen u stolních počítačů, v noteboocích jen výjimečně. Existují ale redukce RS-232 –> USB, které v počítači vytvoří virtuální COM port a lze tak s RS-232 zařízení snadno komunikovat. Jejich výhodou je obvykle nižší cena než u jejich USB variant, v některých případech výrazně. Nativní USB zařízení buď také využívají integrovaný virtální sériový port nebo komunikují pomocí USB HID, což je univerzální protokol navržený pro potřeby USB nebo Bluetooth rozhraní. Paralelní rozhraní (LPT) pro svoji složitost a pomalost už z počítačů téměř úplně vymizely. Bezdrátová komunikace je možná prostřednictvím rozhraní Bluetooth nebo přenosem po rádiových frekvencích (oboje typicky na frekvenci 2,4 GHz). Bluetooth využívá také protokolu HID. Jeho využití oproti USB je složitější v tom, že nejdříve musí proběhnout spárování vysílače a přijímače. Připojení zařízení pomocí infračerveného přijímače není už příliš rozšířené a ani vhodné, protože je velmi pomalé, na vzdálenost jen několika metrů a je nutná
27
28
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
přímá viditelnost vysílače a přijímače. Dosah Bluetooth se liší podle třídy, používaná je třída 2 s dosahem 10 metrů a v současnosti i rychlejší třída 1 s dosahem přibližně 100 metrů. Typický dosah rádiových vysílačů se pohybuje od několika desítek po několik stovek metrů. Je nutno podotknout, že bezdrátové varianty přístrojů jsou téměř bez výjimky mnohem dražší než jejich kabelové varianty. Hledání vhodného čidla rozdělím na dvě části - čidla vlastní výroby a komerční řešení.
3.1.2
Měřící čidla vlastní výroby
Výhodou čidel vlastní výroby je bezpochyby to, že můžeme čidlo navrhnout přesně podle našich požadavků a poskládat ho z námi vybraných součástek s danými kvalitativními a výkonnostními vlastnostmi. Většinou se nám také podaří čidlo sestavit levněji, než kdybychom ho měli koupit hotové. Na druhou stranu jsou zde ale i nevýhody a to hlavně nutnost čidlo navrhnout a sestrojit (vlastnoručně nebo na zakázku, což ho může prodražit). Složitější návrh může zabrat větší množství času a komerční řešení by nás tak mohlo vyjít levněji. Také ruční výroba tištěných obvodů vyžaduje vhodné zařízení (mikropáječku, součástky) a rovněž zručnost a zkušenosti a hotový výrobek obvykle nebude dosahovat kvality strojové výroby, nehledě na horší odolnost vlivům počasí, které musí být u venkovního použití vzaty v potaz.
3.1.2.1
Čidlo do paralelního portu
Problémem paralelních portů je to, že už se v počítačích téměř nevyskytují. Existují ale redukce LPT –> USB, které v počítači vytvoří virtuální paralelní port. Cena těchto redukcí se pohybuje mezi 200 - 300 Kč. Jako základ je možné použít integrovaný obvod Smartec SMT160-30 v pouzdře T092 (teplotní rozsah od -45 ◦ C do +150 ◦ C s absolutní přesností ±0,7 ◦ C), jehož cena je přibližně 100 Kč. Toto čidlo převádí teplotu na obdélníkový signál o frekvenci 1 - 4 kHz podle teploty se střídou D = 0, 32 + 0, 0047 · t, kde t je teplota. Čidlo Smartec lze připojit přímo k paralelnímu konektoru CANON 25-pin, viz obrázek 3.1. Potřeba je pouze čidlo, konektor a 20 nF kondenzátor. Čidlo se napájí z pinů 1 a 14 +5 V. Signál z čidla se přivádí na pin 15. Zem čidla (GND) se připojí na pin 25. Ochranu čidla před vlhkem je dobré provést např. smršťující bužírkou a protože konektor je poměrně robustní, čidlo tak bude jako celek poměrně dobře odolné vnějším vlivům. Případně existuje ještě velmi obdobná varianta připojení ke konektoru CANON 15-pin (GAME port). U obou variant lze připojit až 4 čidla k jednomu konektoru. Toto řešení je jednoduché, protože komunikace s paralelním portem je velmi jednoduchá a nejsou potřeba žádné další obvody kromě teplotního čidla, konektoru a jednoho kondenzátoru. Čtení z čidla je pak poměrně přímočaré pomocí jednoduchého programu, který testuje počet změn logické 0-1 a spočítá teplotu ze střídy podle vzorce uvedeného výše. [11] Cena tohoto řešení je přibližně 200 Kč (včetně 10 metrů kabelu). V případě nutnosti použití LPT - USB redukce je cena celkem 400 - 500 Kč.
3.1. MĚŘENÍ TEPLOTY POMOCÍ POČÍTAČE
29
Obrázek 3.1: Teploměr do 25-pinového paralelního portu Zdroj: [11]
3.1.2.2
Čidlo do sériového portu
U sériového portu už je to trochu složitější než u paralelního portu. Jako čidlo lze použít např. digitální teploměr Dallas Semiconductor DS18S20 (teplotní rozsah od -55 ◦ C do +125 ◦ C s absolutní přesností ±0,5 ◦ C). Toto čidlo má rozhraní DS 1-Wire, které umožňuje připojit několik čidel k jednomu sériovému portu. Jedno čidlo lze připojit ke COM konektoru (CANON 9-pin) pomocí pasivního adaptéru DS9097, což jsou 4 diody a jeden odpor, viz obrázek 3.2. Při použití aktivního adaptéru DS9097U by bylo možné připojit více čidel, např. i vlhkoměrné, převodník DS9097U ale stojí 500 - 600 Kč. Čidlo DS18S20 stojí přibližně 100 Kč a adaptér DS9097 dalších několik desítek Kč. Ochranu čidla před vlhkem je také dobré provést smršťující bužírkou a odolnost je obdobná jako u paralelního řešení výše. Komunikace s tímto čidlem připojeným k sériovému rozhraní je složitější kvůli RS-232 protokolu, ale je dostupný zdrojový kód programu DigiTemp, který umožňuje komunikaci jak s pasivním, tak s aktivním adaptérem. Program i zdrojový kód je dostupný na http://www.digitemp.com/software.shtml. Cena tohoto řešení je také přibližně 200 Kč (včetně 10 metrů kabelu). V případě nutnosti použití RS-232 –> USB redukce se cena navýší o přibližně 200 - 250 Kč na celkových 400 450 Kč. Poznámka: některé druhy redukcí neumožňují změnu některých parametrů přenosu, jako např. kódování, počet bitů parity atp. Ideálně je vhodné koupit osvědčený model s ovladači funkčními pod novými verzemi operačních systémů, například mohu doporučit převodník od firmy PremiumCord, který úspěšně používám. 3.1.2.3
Čidlo do USB portu
Čidla do USB portu jsou obvykle založena na integrovaném převodníku RS-232 na USB, případně se nechají postavit i na převodníku LPT na USB. Tato čidla po připojení k PC vytvoří
30
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.2: Teploměr do sériového portu Zdroj: [12]
virutální sériový resp. paralelní port a programy komunikují s těmito porty. LPT převodník může být založen např. na mikrokontroléru Atmel ATmega8 a cena všech potřebných součástek je 200 - 250 Kč. USB převodník může být založen např. na integrovaném obvodě FTDI FT232BM a převodníku Dallas MAX232 pro převod úrovní RS-232 na TTL, cena součástek je zhruba 250 Kč. K tomu je samozřejmě nutné přičíst cenu použitého teplotního čidla. Založení komunikace přímo na protokolu USB HID je výrazně komplikovanější, protože potřebné převodníky USB, např. Silicon Labs CP2104, jsou v ČR obtížně k sehnání. V zahraničí stojí 80 - 100 Kč (bez poštovného). K tomu je potřeba připočíst ještě cenu vlastního teplotního čidla a pasivní nebo aktivní adaptér (při použití např. digitálního teploměru Dallas DS18S20). Z uvedených důvodů se nevyplatí USB čidla stavět, ale případně použít běžně prodávané redukce, např. redukce RS-232 na USB stojí kolem 200 Kč, což vyjde levněji a s lepší kvalitou výrobku.
3.1.2.4
Bezdrátová čidla
Rádiové a Bluetooth čipy jsou velmi drahé a jejich cena začíná na 300 Kč za samotný vysílací modul. K tomu je třeba připočíst cenu teplotního čidla a převodníku na USB. Také návrh a výroba celého tištěného spoje jsou mnohem složitější než u drátových variant. Proto si nemyslím, že by bylo výhodné tuto variantu ručně vyrábět a distribuovat uživatelům systému.
3.1. MĚŘENÍ TEPLOTY POMOCÍ POČÍTAČE
3.1.3
31
Komerčně vyráběná měřící čidla
Výhodou komerčně vyráběných čidel je většinou kvalitnější konstrukce než u vlastnoručně vyrobených. Zároveň odpadá problém s distribucí uživatelům systému, mohou si čidlo objednat sami v obchodě vlastní volby. Nevýhodou je vyšší cena. Dále jsou u některých čidel (hlavně levných čidel čínského původu) problémy s nestabilitou, nepřesností a nefunkčností v nových verzích operačního systému Windows. 3.1.3.1
Čidla do sériového portu
Našel jsem pouze RS-232 čidlo prodávané českou firmou Papouch. Ve své podstatě je to komerční řešení čidla popsaného v části 3.1.2.2. Papouch TM Adresa: http://www.papouch.com/cz/shop/product/tm-rs232-teplomer/ Toto komerční měřící čidlo lze připojit ke COM portu a poskytuje teplotu v ASCII formátu přímo ve stupních Celsia. Teplotní rozsah je od -55 ◦ C do +125 ◦ C s absolutní přesností ±0,5 ◦ C. Čidlo indikuje blikáním diody probíhající měření.
Obrázek 3.3: RS-232 teplotní čidlo Papouch TM Zdroj: http://www.papouch.com/cz/shop/product/tm-rs232-teplomer/ Toto čidlo jsem zakoupil a vyzkoušel a funguje naprosto spolehlivě i v nových verzích operačních systémů Windows XP, Vista a 7 a také v OS Linux.
32
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Cena je 500 Kč, při odběru 30 a více kusů 432 Kč (délka kabelu 2,8 metru). Na přání prodejce dodá i čidlo s delším kabelem, ale stejně tak lze použít USB prodlužovací kabel za několik desítek Kč. 3.1.3.2
Čidla do USB portu
Teplotních čidel do USB existuje větší množství, většinou velmi levných nebo poměrně drahých profesionálních řešení. Některá zařízení jsou prodávána jako tzv. data-loggery, které zaznamenávají teplotu v daném místě a pak je lze připojit k PC a jednorázově data stáhnout. Tento způsob měření není pro moje využití vhodný, je potřeba měření v reálném čase. V České republice není příliš velká nabídka USB teploměrů. V zahraničí je těchto výrobků velké množství a z většiny jde o klony jednoho a toho samého designu (a možná i stejného čínského výrobce). Zbývající produkty jsou buď drahá profesionální průmyslová čidla nebo vzorkovací čidla pro měření teploty kapalin, směsí atp. Pro praktické použití jsem našel pouze dvě varianty - čidla z rodiny TEMPer od čínského výrobce a čidlo TMU od české firmy Papouch. Rodina čidel TEMPer Adresa: http://www.pcsensor.com/index.php?_a=viewCat&catId=6 Firma RDing Tech. prodává několik druhů USB teploměrů už několik let, jejich výrobky se rozšířily do celého světa a prodává je také mnoho „gadgets“ obchodů (zaměřují se na počítačové vychytávky). Vyrábějí jak čidla integrovaná přímo do USB klíčenky a tudíž pouze pro interní použití (TEMPer), tak čidla s externím a interním senzorem (TEMPer2, TEMPerNTC). Pro účely systému Meteoris jsou zajímavé pouze čidla pro venkovní použití, a to je jen TEMPerNTC, který je narozdíl od TEMPer2 chráněn proti vlhkosti a dešti. TEMPerNTC obsahuje jako teplotní čidlo NTC termistor (u něj se zahřátím součástky klesá odpor a podle toho lze měřit teplotu). Přesnost měření je ±1,5 ◦ C, což už je poměrně velká odchylka. Toto čidlo obsahuje interní senzor u USB konektoru a externí čidlo na kabelu délky 0,8 metru. Rozsah teplot je -40 ◦ C až +120 ◦ C u interního čidla a -50 ◦ C až +150 ◦ C u venkovního čidla. Verze prodávané do poloviny roku 2009 měly v sobě integrován adaptér RS-232 na USB a vytvořily si tak v počítači virtuální sériový port, takže bylo možné snadno implementovat čtení jejich teploty a bylo dostupných několik programů a jejich zdrojové kódy, které to umožňovaly. Od poloviny roku 2009 ale čidla začala fungovat nad protokolem USB HID a protože nebyl uvolněn formát komunikace, tak spolupracovala pouze s programem od prodejce. Protože cena není nijak závratná, rozhodl jsem se vyzkoušet TEMPerNTC a objednal jsem z Hong Kongu 2 kusy. Po vyzkoušení musím bohužel konstatovat, že čínská čidla TEMPerNTC nefungují podle očekávání. Jak už bylo řečeno, nové verze čidla založené na USB HID fungují pouze s programem dodávaným prodejcem. Ten ale nefunguje ve Windows Vista a Windows 7, pouze ve Windows XP čtení teploty fungovalo.
3.1. MĚŘENÍ TEPLOTY POMOCÍ POČÍTAČE
33
Obrázek 3.4: USB teplotní čidlo TEMPerNTC Zdroj: http://www.pcsensor.com/index.php?_a=viewProd&productId=32
Stojí za zmínku, že výrobce prodává také čidlo kombinující měření teploty a vlhkosti jménem TEMPerHUM. To je ale integrované do formátu USB klíčenky a proto nevhodné pro venkovní použití, a také vzhledem ke špatné funkčnosti vyzkoušeného TEMPerNTC ho nelze použít pro účely systému Meteoris. Cena TEMPerNTC je přibližně 300 Kč (plus poštovné z Číny 130 Kč). Papouch TMU Adresa: http://www.papouch.com/cz/shop/product/tmu-usb-teplomer/ Jde o teplotní čidlo stejných parametrů jako varianta TM pro RS-232 (3.1.3.1), pouze navíc s integrovaným převodníkem RS-232 do USB. Po připojení k počítači (a nainstalování ovladačů) si čidlo vytvoří virtuální COM port. Cena je 1152 Kč (kabel délky 3 m) nebo 1512 Kč (kabel délky 10 m). Vzhledem k ceně je podstatně výhodnější zakoupit variantu pro RS-232 a k ní redukci na USB. Firma Papouch vyrábí také kombinovaný teploměr s vlhkoměrem THT2 včetně výpočtu rosného bodu a prodává ho za 2500 Kč. Toto měřící čidlo je ale určeno pro průmyslové rozhraní RS-485. Nejlevnější převodník RS-485 na RS-232 stojí 500 Kč (obdobný převodník prodávaný firmou Papouch stojí 1188 Kč). Také existuje větroměr pro RS-232 od Firmy Papouch, ale jeho cena je 4000 Kč. Vzhledem k ceně nemá smysl tato profesionální řešení vůbec uvažovat, mnohem levnější a užitečnější by bylo zakoupit si rovnou profesionální meteostanici. 3.1.3.3
Bezdrátová čidla
Komerčně vyráběná teplotní čidla připojitelná k počítači pomocí Bluetooth nebo rádiového přijímače se mi nepodařilo nalézt. Vzhledem k jejich případné ceně (odhadem více jak 1000 Kč) je poměrně pravděpodobné, že se je nevyplatí ani vyrábět, protože zákazníci by dali rovnou přednost multifunkčním meteostanicím.
34
3.1.4
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Shrnutí a výběr čidla pro systém
Vlastnoručně vyrobit čidlo je řešení vhodné pro jednotlivce, ale navrhnout a vyrobit dostatek čidel (nebo případně zajistit jejich výrobu) a ještě obstarat distribuci těchto čidel případným uživatelům Systému pro sběr a distribuci meteorologických údajů je poměrně komplikované a přinejmenším nepraktické. Vzhledem k nákladům na výrobu čidel, jejich kvalitě a odolnosti vůči vlivům prostředí a cenám komerčních řešení, považuji komerčně prodávané výrobky pro využití v této diplomové práci za vhodnější a snáze použitelnější v navrhovaném systému. Z komerčně prodávaných teplotních čidel je po provedené rešerši použitelné pouze teplotní čidlo TM pro RS-232 od české firmy Papouch (případně jeho USB varianta TMU), u kterého bylo ověřeno, že je funkční a dokáže dlouhodobě a spolehlivě měřit teplotu. Vzhledem k tomu, že kombinace čidla Papouch TM a redukce z RS-232 na USB vyjde mnohem levněji než USB čidlo Papouch TMU, bude pro účely této diplomové práce použito RS232 teplotní čidlo Papouch TM a pro něj proběhne analýza a implementace komunikačního protokolu a bude poskytovat testovací data serverové části. Poznámka: Protože ale USB čidlo Papouch TMU vytváří také virtuální COM port, je kdykoliv možné ho plně zaměnit za RS-232 čidlo Papouch TM (pouze to není cenově výhodné).
3.2
Externí poskytovatelé meteorologických údajů
V částech 2.2 a 2.5.1 bylo popsáno, kdo a jakým způsobem poskytuje naměřené meteorologické údaje veřejnosti prostřednictvím internetu. Jsou to státní instituce Česhý hydrometeorologický ústav a dále pak jednotliví amatérští meteorologové s poloprofesionálními stanicemi. Ti buď tyto údaje poskytují na svých vlastních webových stránkách, což je pro účely přebírání údajů velmi nepraktické, nebo prostřednictvím centralizovaných systémů. Z nich nejvíce jich je registrováno na serveru Weather Underground (více jak 100 uživatelů). Na serverech Wedaal-Board, AWEKAS a CWOP je celkem přibližně pouze 40 registrovaných uživatelů, z nichž část je na více serverech a část není aktivních. Pro účely této diplomové práce jsem tedy vybral jako vhodné poskytovatele externích údajů server Českého hydrometeorologického ústavu, kde jsou dostupná data ze 39 desítek profesionálních českých stanic a přibližně 150 automatických stanic AMS. Jako druhého poskytovatele převzatých údajů jsem zvolil Weather Underground, který zastřešuje většinu českých meteorologů-amatérů a jejich poloprofesionálních stanic. Dále popíšu, jak je možné k datům na serverech ČHMÚ a Weather Underground přistupovat, jaký mají formát a jaké meteorologické prvky budou poskytovány dále uživatelům. Poznámka: Popis jednotlivých meteorologických veličin je blíže zpracován v kapitole 2.1.2.
3.2.1
ČHMÚ
ČHMÚ poskytuje na svém serveru údaje ze 39 profesionálních stanic a to v textové i grafické podobě. Pro účely přebírání dat je nutná textová podoba, kterou lze vhodně programově zpracovat a dále poskytovat. Protože data ze stanic AMS jsou veřejnosti dostupná pouze ve formě grafů, nejsou pro další využití vhodná a stanice AMS nebudou dále uvažovány.
3.2. EXTERNÍ POSKYTOVATELÉ METEOROLOGICKÝCH ÚDAJŮ
35
ČHMÚ poskytuje údaje buď přehledně v tabulce se všemi stanicemi, kde ale některé méně důležité údaje chybí, nebo také pro jednotlivé stanice samostatně (v textové podobě nebo dostupné na mapě). Data budou přebírána ze stránek jednotlivých stanic, přehledná tabulka (s několika chybějícími méně důležitými údaji) bude sloužit pouze jako záloha pro případ, že by stránky jednotlivých stanic nebyly dostupné. Seznam stanic ČHMÚ je uveden v tabulce 3.1. 3.2.1.1
Tabulka
Odkaz: http://pr-asv.chmi.cz/synopy-tab/ Tabulka obsahuje meteorologické údaje ze všech stanic (pouze v případě, že stanice chvilkově není dostupná, není v této tabulce uvedena). Data stanic jsou uvedena v tabulce (HTML tag
). Popisky údajů jsou uvedeny na prvním řádku tabulky (tag
). Každá stanice je dále vždy na samostatném řádku tabulky (tag
) a v každém sloupci (tag
) je uvedena hodnota údaje. Údaje obsažené v tabulce: • čas měření údajů – aktualizace vždy v celou hodinu • název stanice – město • oblačnost – míra oblačnost ve stupnici 0/8 - 8/8 • směr větru • rychlost větru • teplota vzduchu • rosný bod • počasí – stav počasí v termínu pozorování • průběh – průběh počasí od předchozího měření • srážky – úhrn srážek za posledních 6/12 hodin • srážky 1 h. – úhrn srážek za poslední hodinu 3.2.1.2
Mapa a jednotlivé stanice
Odkaz (mapa): http://pr-asv.chmi.cz/synopy-map/ Odkaz (jednotlivé stanice): http://pr-asv.chmi.cz/synopy-map/stanice.php Na odkazu výše se nachází mapa se všemi stanicemi (obrázek 3.5), na stránce se po kliknutí na název stanice otevře okno s vlastními údaji stanice (dostupné také z druhého
Brno - Tuřany Čáslav Červená u Libavé České Budějovice Doksany Dukovany Holešov Cheb Churáňov Karlovy Vary Kocelovice Kopisty Kostelní Myslová Košetice Kuchařovice Liberec Luká Lysá hora Milešovka Náměšť nad Oslavou Ostrava - Mošnov Pardubice Pec pod Sněžkou Plzeň-Mikulka Polom Praha Karlov Praha Kbely Praha Libuš Praha Ruzyně Přerov Přibyslav Přimda Sněžka Svratouch Šerák Temelín Tušimice Ústí nad Labem Ústí nad Orlicí
Tabulka 3.1: Seznam profesionálních stanic ČHMÚ Zdroj: [13], [14]
3.2. EXTERNÍ POSKYTOVATELÉ METEOROLOGICKÝCH ÚDAJŮ
37
Obrázek 3.5: Mapa stanic ČHMÚ Zdroj: [13]
odkazu výše). Lze zvolit jiné druhy map, např. s údaji o dohlednosti, oblačnosti, směru a rychlosti větru, tlaku, teplotě a relativní vlhkosti vzduchu nebo úhrnu srážek. Adresa stránky s údaji dané stanice je http://pr-asv.chmi.cz/synopy-map/pocasinawin.php?indstanice=XXXXX, kde XXXXX je označení stanice, viz tabulka 3.1. Ukázka stránky stanice je na obrázku 3.6. Údaje stanice jsou uvedeny v tabulce (HTML tag
). Každý údaj je vždy na samostatném řádku tabulky (tag
), v levém sloupci (tag ) je popisek a v pravém sloupci je uvedena hodnota. Jednotlivé stránky stanic obsahují tyto údaje: • čas měření údajů – aktualizace vždy v celou hodinu • název stanice – město • oblačnost – míra oblačnosti ve stupnici 0/8 - 8/8 • spodní vrstva – výška spodního okraje mraků • vítr – směr a rychlost větru • náraz větru v rychlost nárazového větru • tlak vzduchu • tendence tlaku vzduchu
38
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.6: Ukázka údajů stanice na serveru ČHMÚ Zdroj: [13]
• teplota vzduchu • rosný bod • relativní vlhkost • počasí – stav počasí v termínu pozorování • průběh – průběh počasí od předchozího měření • srážky – úhrn srážek za posledních 6/12 hodin • srážky 1 h. – úhrn srážek za poslední hodinu Stránky jednotlivých stanic tedy oproti tabulce obsahují navíc údaje o spodní vrstvě, nárazovém větru, tlaku vzduchu a relativní vlhkosti.
3.2.2
Weather Underground
Z více než 110 stanic registrovaných na WU bylo vybráno 84 stanic aktivních k datu 20.4.2011, ze kterých bude systém Meteoris přebírat údaje. Jak se ukázalo, ne všechny jsou aktivní neustále, ale většina ano a poskytují většinou kvalitní údaje. Seznam stanic je v tabulce 3.2.2. Import meteorologických dat stanic z WU je jednodušší než z ČHMÚ, protože WU poskytuje veřejné API pro údaje ze svých webových stránek. API poskytuje dva druhy souborů, jeden s posledním měřením a druhý obsahuje všechna měření z daného dne. Pro
3.2. EXTERNÍ POSKYTOVATELÉ METEOROLOGICKÝCH ÚDAJŮ
39
účely přebírání dat je vhodný soubor s posledním měřením. Oba soubory jsou strukturované XML dokumenty, formát souboru s posledním měřením je uveden na obrázku 3.7. Adresa stránky s údaji dané stanice je http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=XXXXX a adresa XML souboru s posledním měřením je http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=XXXXX, kde XXXXX je označení stanice, viz tabulka 3.2.2.
Benešov nad Černou Břeclav Břístev Brno Brumov-Bylnice Bruntál Čachovice Česká Třebová Chrudim Chrustenice Chudčice Dolní Čermná Dubíčko Frýdlant nad Ostravicí Habartov Halamky Holasice Horní Jiřetín Horní Újezd Horoměřice Hovězí Hradec nad Moravicí Světlice Hunčice Jedovnice Jindřichův Hradec Kralupy nad Vltavou Kyjov - Boršov Nová Ves Liberec Lichnov Malé Svatoňovice Maršov u Úpice Milevsko Mnichovo Hradiště Moravany Mořina Mukařov
Napajedla Němčičky Nová Paka Nová Pec Nové Město nad Metují Nový Dvůr Pardubice Pelhřimov Písek Ploskovice Plzeň-Radčice Počátky Pozorka Praha 10 - Strašnice Praha 3 - Žižkov Praha 1 Praha 6 - Břevnov Praha 9 - Vysočany Praha-Šeberov Prostějov Ratíškovice Rotava Rožnov pod Radhoštěm Ruda Senomaty Šlapanice Slatinice Smržovka Stéblová Šternberk Strážnice Strážný Suchá Rudná Sudoměřice Třebíč Trutnov Týniště nad Orlicí Ústí nad Orlicí Deštnice Velhartice Velká Úpa Velké Svatoňovice Véska Volary Zbýšov Štípa
Data, která je možné z XML souboru získat: • čas měření údajů – element observation_time_rfc822 - v anglickém formátu (např. Sat, 07 May 2011 21:02:53 GMT ) • oblačnost – element weather - míra oblačnosti je vyjádřena anglickými zkratkami FEW (1-2/8), SCT (3-4/8), BKN (5-7/8), OVC (8/8), RA (déšť), SN (sníh) a dalšími • teplota vzduchu – element temp_c - ve ◦ C • relativní vlhkost – element relative_humidity - v procentech • směr větru – element wind_degrees - ve stupních • rychlost větru – element wind_mph - v mílích za hodinu • nárazový vítr – element wind_gust_mph - v mílích za hodinu • tlak vzduchu – element pressure_mb - v hPa • rosný bod – element dewpoint_c - ve ◦ C • srážky 1 h. – element precip_1hr_metric - úhrn srážek za poslední hodinu v cm (posílá v cm, přestože je uvedena jednotka mm, pravděpodobně jde o chybu) • srážky 24 h. – element precip_today_metric - úhrn srážek za celý den v cm Ostatní údaje uvedené v XML souboru jsou buď prázdné nebo nepodstatné, proto nebudou poskytovány uživatelům. Pokud stanice není v daný den aktivní, tak jsou v souboru elementy prázdné. Stanice je považována za aktivní, pokud poskytne WU alespoň jedno měření denně. V případě, že stanice neposkytla všechny údaje nebo poskytla chybné údaje, mohou se v souboru objevit i nesmyslné hodnoty (např. relativní vlhkost −999 %) a s tím je také potřeba počítat při implementaci.
42
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.7: Formát XML souboru s údaji z Weather Underground Zdroj: [15]
3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI
3.3
43
Výběr technologií pro implementaci
Z popisu komponent systému 2.3.1 vyplývá, že klientské části systému musí být desktopové aplikace (aplikace běžící přímo na počítači uživatele). Jak aplikace pro komunikaci se stanicí, tak aplikace zobrazující údaje, nejsou nijak komplexní komponenty. Komunikační aplikace v zásadě čte data z čidel, umožňuje je ukládat do souboru a odesílat na server a v případě překročení nastavené hodnoty spustí alarm. Zobrazovací aplikace čte údaje ze serveru a zobrazuje je uživateli, s možností ukládání do souboru případně spuštění alarmu. Obě aplikace tedy nepotřebují databázové úložiště (to je na serveru) ani nezávisí na jiných aplikacích v systému. Poznámka: Klientská aplikace pro zobrazování údajů bude navržena jako samostatná desktopová aplikace, protože to umožní její použití v mnoha různých operačních systémech, narozdíl např. od mini-aplikace do Windows 7 (pluginu). V budoucnu pak může být tato mini-aplikace vytvořena také. Typ klientských aplikací je proto dán požadavky na systém a je potřeba pouze blíže specifikovat komunikaci uživatele a serveru a vlastnosti serverové části.
3.3.1
Architektura systému
Serverová část systému bude kompletně umístěna na serverovém stroji a přístup uživatele k ní bude pomocí webového prohlížeče nebo zprostředkovaně prostřednictvím klientských aplikací. Datové úložiště bude taktéž umístěno na serveru, přičemž to může být ten samý server jako u systému, nebo případně kvůli většímu výkonu může být použit samostatný databázový server. Tento typ architektury se nazývá klient-server. Obecně jde o klienta (v našem případě webový prohlížeč nebo desktopové aplikace), který zprostředkovává interakci s uživatelem prostřednictvím grafického uživatelského rozhraní, a server, který poskytuje klientovi služby a je od klienta oddělen počítačovou sítí. Uvedu nyní několik obecných výhod klient-server řešení a také několik nevýhod, které budou muset být minimalizovány. Výhody: • Uživatel není závislý na použité technologii serveru, používá k přístupu pouze svůj webový prohlížeč. • Přístup odkudkoliv z libovolného počítače vybaveného internetem. • Sdílená data mohou být poskytována velkému množství uživatelů. • Zapouzdření - snadná správa a úpravy aplikace, které nemají obvykle žádný dopad na uživatele. Nevýhody: • Výhradní závislost serverové části na internetu - v případě poruchy serverového stroje by aplikace nebyla vůbec dostupná (použitelná).
44
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
• Nekompatibilita různých prohlížečů a nových verzí podporovaných prohlížečů by mohla způsobit špatnou funkčnost aplikace. • Při větším množství měřících klientských stanic by rychle přibýval počet dat v databázi. • Zpracování dat z měření ke tvorbě grafů za delší období je časově náročný úkol a server by mohl být zpomalen, pokud by tuto činnost najednou provádělo větší množství lidí. • Náklady na provoz serveru nejsou nulové a je potřeba správce serverového stroje. • Data všech uživatelů by byla uložena na jednom centrálním místě, pokud by došlo k havárii serveru a ztrátě dat, následky by byly vážné. Nekompatibilitu prohlížečů je nutné řešit softwarově (např. sledovat aktualizace prohlížečů a provést drobné úpravy). V dnešní době ale všechny nejvíce používané prohlížeče zobrazují už stránky s validním kódem téměř bez výjimek dobře (problémy Internet Exploreru byly odstraněny od verze 8). Ostatní nevýhody záleží hlavně na použitém hardwaru. Abych minimalizoval některé z těchto nevýhod, zvolím nyní vhodné parametry a provozovatele serveru.
3.3.2 3.3.2.1
Výběr serveru a jeho parametry Umístění serveru a zálohování dat
Server může být umístěn buď na vlastním serverovém stroji nebo na stroji některého z poskytovatelů webových hostingů. Nevýhodou vlastního stroje je počáteční investice do vybavení, taktéž jsou potřeba prostory a rychlé dedikované připojení k internetu. Pokud by si na sebe systém vydělal, např. díky zájmu firem o zdrojový kód nebo rozšíření aplikací, tak je tato volba možná. Schůdnější cestou pro začátek ale je webový hosting. Funkce, které poskytovatelé webhostingových služeb nabízejí se různí, v zásadě jde ale o 3 základní typy hostingů: sdílený hosting, virtuální nesdílený hosting a dedikovaný hosting. Výpočetní kapacita je u sdíleného hostingu sdílena mezi více uživatelů (při zaručení minimálních výkonnostních parametrů). Problémem v tomto případě obvykle je, že pokud spadne některý ze systémů nebo databází v rámci dané sdílené skupiny, přestanou fungovat i ostatní systémy v dané skupině. U virtuálního nesdíleného hostingu je tento problém vyřešen tak, že každý systém běží sám ve svém kontejneru a v případě pádu nemůže ohrozit ostatní systémy v rámci sdílené skupiny. Technologií, která toto umoňuje je např. OpenVZ, což je kontejnerově založená virtualizace výkonu a diskového prostoru, která je snadno výkonově škálovatelná a zaručuje bezpečnost a samostatnost jednotlivých kontejnerů. Cena obou řešení se pohybuje v řádu desítek až stovek Kč za měsíc (podle výkonu). Dedikované hostingy znamenají vlastně pronájem celých serverových strojů umístěných v datacentru poskytovatele. Toto by byla nejlepší alternativa vlastnímu serverovém stroji, server by měl výbornou konektivitu do internetu a kvalitní výkonnostní parametry. Problémem je, že cena pronájmu se pohybuje v řádu tisíců Kč za měsíc. Výhodou webhostingového řešení je také poskytovatelem zaručená minimální dostupnost serveru, která se obvykle pohybuje nad 99 %, což je hlavně díky kvalitní infrastruktuře
3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI
45
v datacentru. Výpadky kvalitních webhostingů tak nejsou vůbec časté, jde řádově maximálně o několik hodin ročně. Další výhodou je neustálá podpora ze strany poskytovatele a v případě výpadku či potřeby změny parametrů hostingu nebo dotazu se stačí obrátit na poskytovatele. Další velkou výhodou webhostingu je samozřejmost pravidelného zálohování dat, obvykle v denních či několika hodinových intervalech. Zálohovány jsou jak soubory na disku, tak data v databázích. V případě vlastního serveru by toto bylo mnohem problematičtější, protože by zálohy musely být umísťovány ideálně na jiný server v lokální síti. Protože systém bude navržen univerzálně a nebude problém provést jeho přemístění na výkonnější serverový stroj v případě potřeby, do začátku je vhodná varianta virtuálního nesdíleného hostingu, jehož pronájem nestojí mnoho peněz a poskytuje přijatelný výkon. Požadavky na výkon serveru při větším množství uživatelů budou prozkoumány v následující části. 3.3.2.2
Výkon serveru, jeho škálování a optimalizace
Protože součástí práce je také navrhnout a implementovat levné měření teploty pomocí počítače (a do budoucna také dalších údajů), je nutné počítat s tím, že by systém mohlo začít používat větší množství uživatelů než kolik v současné době provozuje drahé poloprofesionální stanice. Proto musí být systém navržen a provozován tak, aby dokázal rychle vyřídit požadavky uživatelů. Největší nároky na výkon systému bude klást ukládání dat měření a zpracování uložených dat (hlavně pro tvorbu statistik a grafů) a dále poskytování vlastních a převzatých měření. Počet přijímaných měření denně může být poměrně velký a pokud nebude server dostatečně rychlý s velkou databází, nedokázal by je zpracovat v přijatelném čase. Nyní tedy provedu odhad maximálního počtu měření v databázi a délku vhodného intervalu odesílání dat na server a s tím spojený maximální počet uživatelů systému a dále jak velké množství dat zvládne server určitého výkonu zpracovat. Dále budou uvedeny optimalizační metody, které by bylo možné použít v případě potřeby k urychlení systému. Velikost dat v databázi a počet uživatelů Maximální velikost databáze u hostingů je obvykle omezena na 2 GB. Měření budou zabírat většinu místa databáze a tabulka měření bude navržena co nejúsporněji. Například průměrná velikost pro řádek měření [ID stanice (int), ID veličiny (int), čas měření (datetime) a hodnota(decimal 8,2)] včetně indexů je podle testů přibližně 80 bajtů. Co řádek měření, to jedna uložená veličina. Při odesílání více veličin na server dojde tedy k uložení více řádků. Maximální počet měření všech veličin je pro max. 2 GB databázi teoreticky přibližně 27 milionů. Hodnoty některých veličin kolísají méně rychle nebo nejsou tak důležité a nemusí být tedy ukládány tak často jako jiné. Dále, u čidel měřících pouze několik málo údajů (např. jen teplotu) je teoretický maximální počet měření v databázi mnohem vyšší než u poloprofesionálních stanic odesílajících např. 8 veličin. V potaz také musíme vzít, že v současnosti je v ČR méně než 100 uživatelů s aktivními poloprofesionálními stanicemi nahrávajícími údaje na internet a určitě ne všichni by využívali tento systém. Proto budu v následující úvaze uvažovat poměr měření a uložených hodnot veličin v databázi 1:3, tedy odhad, že do databáze by se vešlo celkem zhruba 9 milionů měření.
46
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Protože data z měření budou ukládána dlouhodobě, je nutné uvažovat čas ukládání v řádu let, dále budu uvažovat 3 roky. Možností jak uchovat a pracovat se staršími daty je více. Starší data by uživatel mohl mít exportovaná u sebe a při požadavku vytvoření grafů a statistik by je nahrál do systému a systém je rovnou zpracoval a poskytl výsledek, bez ukládání do databáze. Případně by se systém mohl skládat z více databází, aktuální a archivních, nebo je také řešení přesunout ho z hostingu na vlastní serverový stroj s větším množstvím místa pro databáze. Obrázek 3.8 uvádí závislost počtu zaslaných měření denně na počtu uživatelů a intervalu zasílání. Obrázek 3.9 uvádí maximální počty dnů do zaplnění databáze v závislosti na počtu uživatelů a intervalu zasílání a teoretickém limitu 9 milionů měření v databázi. Bylo vzato v úvahu, že veličiny, které se mění pomaleji, mohou být zasílány s 2 - 3x delším intervalem. Protože zdaleka ne všichni by využili nejmenšího povoleného intervalu odesílání dat, je potřeba také počítat s poměrně velkou tolerancí.
Obrázek 3.8: Závislost počtu zaslaných měření denně na počtu uživatelů a intervalu ukládání
Obrázek 3.9: Závislost maximálního počtu dnů do zaplnění databáze na počtu uživatelů a intervalu ukládání
Tučně znázorněné počty dnů splňují výše uvedená kritéria. Tedy např. pro 50 uživatelů je ještě vhodný interval zasílání cca 7,5 minuty, pro 100 uživatelů 15 minut a pro 200 uživatelů 30 minut. Interval ale bude moci být případně mnohem kratší, protože je potřeba vzít v potaz také fakt, že kratší intervaly měření jsou dobré hlavně k tomu, aby měl uživatel v daném čase
3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI
47
k dispozici přesné údaje, ale pro tvorbu statistik a grafů (které vynášejí na osu zprůměrované údaje) mohou být klidně použity i delší intervaly ukládání. Starší data by tedy mohla být periodicky promazávána tak, aby byl zvětšen interval mezi jednotlivými uloženými měřeními. Z uvedených údajů lze s velkou pravděpodobností odhadnout, že systém bude moci dlouhodobě používat najednou několik stovek uživatelů s průměrným intervalem 10 - 15 minut. Pro testování a počáteční provoz bude uživatelům doporučen nejmenší interval 5 minut, tak časté měření ale není většinou potřeba a většině uživatelů bohatě postačí i intervaly 15 nebo 20 minut. Po delší době provozu systému a podle vývoje počtu jeho uživatelů by došlo k vyhodnocení zátěže na server a přehodnocení minimálního intervalu. Jednou z dalších optimalizačních variant je méně časté odesílání dat na server a častější ukládání dat do souboru v počítači uživatele s tím, že v případě potřeby by data uživatel nahrál do systému a systém by je zpracoval a rovnou poskytl statistiky a grafy bez nutnosti ukládání dat do databáze. Varianty zvětšení maximální doby ukládání měření na více jak 3 roky byly uvedeny výše. Rychlost zpracování dat Druhým důležitým faktorem je zpracování dat a to hlavně spočítání statistik a vytvoření grafů. Tato činnost nebude prováděna příliš často (pro jednoho uživatele nejspíš maximálně několikrát denně), ale pokud by byla příliš pomalá, uživatel by byl otráven čekáním. Pokud bude v databázi velké množství dat, pak rychlost jejich zpracování bude záležet hlavně na návrhu tabulky (délka databázových řádků, použití indexů), na obecné rychlosti a optimalizaci databázového enginu, na optimalizaci databázových dotazů a na výkonu hardwaru serverového stroje. Návrh databáze a dotazů bude proveden s důrazem na co největší rychlost provádění a databáze bude vybrána podle možností serveru (webhostingu) a rychlostních srovnání. Provedu nyní testy rychlosti zpracování dat podle jejich množství. Řádky tabulky jsou stejné jako při odhadu velikosti dat výše a to [ID stanice (int), ID veličiny (int), čas měření (datetime) a hodnota(decimal 8,2)] s indexy nad [ID stanice] a [ID stanice, ID veličiny]. Použitý databázový engine je rychlý MySQL InnoDB. Použitý server je reálný webhostingový server s procesorem o výkonu 800 MHz a 512 MB paměti RAM. Pro danou veličinu, stanici a časový úsek jsem provedl opakovaně dotaz používající agregační funkci (průměr, maximum, minimum) nad hodnotou a v grafu 3.10 jsou zjištěné doby trvání dotazu (čas je vždy zprůměrován z 5 měření). Test byl proveden pro dotaz využívající agregační funkci, protože statistiky se počítají a do grafů se vynáší agregované údaje (za hodiny, dny, měsíce a roky), a proto záleží hlavně na rychlosti provádění těchto dotazů. Jak je z grafu vidět, tak čas trvání roste přibližně lineárně s počtem řádků v tabulce (od zhruba 250 tisíc řádků). Pro 2 miliony řádků je doba trvání jednoho dotazu přibližně 0,8 sekundy. Pro jednu statistiku to je dobrý čas, ale pokud se do grafu vynáší číslo za každý den v roce (nejnáročnější typ grafu), tak je potřeba zjistit 365 těchto údajů a to už je dost dlouhá doba. Pro představu, 2 miliony řádků jsou měření 50 uživatelů za 140 dnů při intervalu 15 minut (poměr měření ku počtu přijímaných veličin je 1:3, viz výše). Pokud by systém využívalo takto intenzivně takové množství uživatelů, lze samozřejmě optimalizovat. Nejjednodušší, ale finančně nákladná, je optimalizace zrychlením serveru (rychlost procesoru, počet jader). Další způsob je zmenšení dat v tabulce, čehož je možné
48
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
dosáhnout promazáním starších dat tak, aby byl zkrácen interval (neboť u statistik není krátký interval potřeba, stačí 30 - 60 minut). Případně lze také rozdělit starší data do nových tabulek pojmenovaných podle roků a měsíců, čímž by se dosáhlo výrazného zrychlení pro menší zvolené období statistik (srovnatelné s poměrem délky vybraného období ku délce fungování systému). Při intervalu 15 minut a 50 uživatelích systému by počet měření za měsíc byl zhruba 450 000, takže vytvoření grafu po dnech za období měsíce by trvalo přibližně 3,5 vteřiny, což je přijatelné.
Obrázek 3.10: Závislost doby trvání agregovaného dotazu na počtu řádků v tabulce
Rychlost poskytování dat Výše uvedené propočty se týkaly ukládání dat klientských stanic. Rychlost odezvy serveru více uživatelům (resp. prohlížečům), kteří se systémem v jednom konkrétním okamžiku pracují, bude okamžitá (samozřejmě kromě generování statistik a grafů), protože v jednom okamžiku bude se serverem pracovat maximálně několik uživatelů, a takové množství zvládne server obsloužit velice rychle. Poslední případ, který je nutno zvážit, je poskytování údajů z vlastních klientských stanic nebo převzatých z jiných serverů zobrazovacím aplikacím. Server dokáže obsloužit v jednom okamžiku několik desítek klientů. Čas získání aktuálního údaje vlastní stanice je velmi rychlý, data jsou dostupná v databázi. Doba trvání načtení převzatých údajů ale závisí hlavně na konektivitě mezi servery a může být například i vteřina. Zhruba lze odhadnout, že server by pak obsloužil několik desítek žádostí za vteřinu, uvažujme např. 20. Pokud by zobrazovací aplikace načítala data ze serveru jednou za 10 minut a žádosti byly časově rovnoměrně rozdělené, dokázal by server obsloužit 12 000 klientů, což je velmi pěkné číslo. Přesto by při větším počtu uživatelů využívajících tuto službu serveru stálo za to data cacheovat. Vhodné intervaly platnosti položky v cache by mohly být například 10 minut. U vlastních stanic by časová úspora nebyla příliš velká, ale u převzatých údajů ze 123 stanic (celkem bude implementováno 39 profesionálních stanic ČHMÚ a 84 stanic z Weather Underground) by počet dotazů na externí servery poklesl na 123 dotazů za 10 minut (při
3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI
49
pokrytí všech stanic), což při počtu uživatelů např. 10 000 činí snížení na 1 %, tím by došlo k 99 % úspoře času stráveného čekáním na odezvu externích serverů a rapidně by se tak zlepšila odezva vlastního systému.
3.3.2.3
Shrnutí
Nevýhody uvedené v části 3.3.1 byly diskutovány a jsou z většiny minimalizovatelné použitím dobře nakonfigurovaného a dostatečně výkonného serveru a dobrým návrhem systému. Z výše uvedených důvodů bude pro testování a do počátečního provozu použit virtuální nesdílený hosting. Takový hosting mám už k dispozici od firmy Webhosting Savana.cz, parametry použitého tarifu Savana 1000 jsou následující: • kontejnerová virtualizace pomocí technologie OpenVZ • 1 procesor o výkonu 800 MHz a 512 MB paměti RAM, 30 GB diskového místa, 150 MB pro databáze • procesor vykonává i činnost databáze • minimální dostupnost 99, 45 % • zálohování všech dat jednou denně • neomezený přenos dat • serverový skriptovací jazyk PHP 5.3 • databáze MySQL, MySQL InnoDB (umožňující transakce) nebo PostgreSQL
Pronájem webhostingu s tímto tarifem stojí přibližně 1600 Kč na rok (včetně pronájmu domény). Server takového výkonu je podle mých propočtů schopen obsloužit dlouhodobě několik stovek uživatelů s klientskými stanicemi a několik desítek tisíc uživatelů získávajících údaje, takže pro testování a do začátku plně postačuje a pravděpodobně bude stačit i v budoucnu (vzhledem k celkovému počtu amatérských meteorologů v ČR, kterých je v současnosti přibližně 200 a ne všichni mají aktivní měřící stanice). Na druhou stranu vzhledem k cíli systému umožnit měřit základní údaje velice levně, se nechá očekávat nárůst počtu uživatelů a je potřeba být na to připraven. V případě potřeby lze změnit tarif a výkon plynule navýšit až na 2 procesory 1400 MHz a 1280 MB paměti RAM a 120 GB diskového místa a k tomu samostatný databázový server s dvěma 1000 MHz procesory, 768 MB paměti RAM, 2 GB prostorem na data a maximálně 30 současnými přístupy do databáze.
50
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.3.3 3.3.3.1
Výběr programovacích jazyků a technologií Použití architektonického vzoru Model-View-Controller
Jak na serveru, tak u desktopových aplikací bude použit architektonický vzor Model-ViewController (MVC). MVC je softwarová architektura, která rozděluje uživatelské rozhraní aplikace, její datový model a řídící logiku do tří nezávislých komponent ([17]). Změna některé komponenty má tak minimální vliv na ostatní komponenty. Model je reprezentací dat, View (pohled) transformuje data poskytovaná modelem do podoby vhodné k prezentaci uživateli, Controller (řadič) reaguje na události od uživatele a zajišťuje provedení změny v modelu a pohledu. Tato architektura je označována také jako Model-2. Existuje ještě varianta Model-1, kdy je uživatelské rozhraní s řídící logikou sloučeno. Komunikace komponent obvykle probíhá následovně: • Řadič zaregistruje uživatelskou akci a zpracuje ji v akci, které model rozumí. • Řadič informuje model o akci uživatele, což může vést ke změně stavu modelu. • Pohled požádá model o data, aby mohl vygenerovat uživatelské rozhraní. • Čeká se na další akci uživatele a cyklus pak začíná od začátku. Serverová část systému bude podle vzoru MVC rozdělena na 3 vrstvy: prezentační (představuje pohled), bussiness (představuje řadič) a integrační (představuje model). Desktopové aplikace budou využívat model MVC, resp. jeho variantu Model-1, neboť grafická knihovna Swing se chová spíše jako řadič a pohled dohromady (uživatelské rozhraní s řídící logikou). Model u těchto aplikací nebude klasický datový model spojený s databází, ale spíše bude za tuto část vzoru MVC považován přímo vnitřní stav a nastavení aplikace. 3.3.3.2
Centrální serverová část
Na serveru bude použita klasická třívrstvá architektura skládající se z prezentační, bussiness a integrační vrstvy. Prezentační vrstva je zodpovědná za zobrazení dat uživateli (zde poskytnutí dat klientovi), bussiness vrstva za zpracování dat a integrační vrstva pro komunikaci s databází. Skriptovací programovací jazyk serverové části závisí na použitém serveru. V tomto případě jsem se rozhodl pro webhosting pouze s podporou skriptovacího jazyka PHP a proto bude pro implementaci použit jazyk PHP verze 5.2. Skriptovací jazyk PHP slouží pro vytváření dynamických internetových stránek a je velmi rozšířený hlavně na webových hostinzích. Je multiplatformní a je obvykle distribuován spolu se serverem Apache. Mezi vývojáři je velmi rozšířený pro svoji jednoduchost a obrovský rozsah možností. Jeho konkurenti ASP, JavaServer Pages a Perl se používají hlavně na firemních serverech. Je to interpretovaný jazyk a jeho vykonávání probíhá na straně serveru a ke klientovi je přenášen pouze výsledek čili HTML (XHTML) kód. V PHP bude napsána bussiness a integrační vrstva.
3.3. VÝBĚR TECHNOLOGIÍ PRO IMPLEMENTACI
51
Na straně serveru budou také využity PHP knihovny PEAR (skupina různorodých balíčků, např. pro komunikace s databází, grafy, export dat atd.) a Smarty, což je šablonovací systém se svojí vlastní syntaxí, který se používá pro oddělení bussiness logiky a vzhledu stránek (ve Smarty tedy bude také částečně napsána prezentační vrstva). Smarty je vlastně mezivrstva mezi (X)HTML a PHP, pomocí PHP vkládá data do šablony a vytváří (X)HTML stránku. Tyto knihovny použiji, protože s nimi mám rozsáhlé zkušenosti, umožňují velký rozsah činností a jsou velmi rychlé. Smarty je zde alternativou k rozšířenému a možná známějšímu aplikačnímu frameworku Zend a jeho šablonovacímu systému View, který místo šablon používá směs HTML a PHP. Vytvářené webové stránky budou založeny na kombinaci programovacích jazyků XHTML 1.0 Strict, jazyka pro definici formátovacích stylů CSS a skriptovacího jazyka vykonávaného na straně prohlížeče JavaScript. Tato kombinace je v dnešní době nejpoužívanější pro návrh webových stránek. V XHTML, CSS a JavaScriptu bude napsána zbývající část prezentační vrstvy. Všechny tři jazyky budou kontrolovány na validitu, což zmenší riziko nekompatibility v různých prohlížečích a jejich nových verzích. Dynamičnost na klientské straně zajistí použití javascriptové technologie AJAX (případně jeho synchronní varianty SJAX). 3.3.3.3
Desktopové klientské aplikace
U desktopových aplikací je požadavkem multiplatformnost (fungování na OS Windows a Linux) a proto jsem zvolil jako programovací jazyk Javu. V současné době je Java rozšířený, oblíbený, podporovaný a rozvíjený jazyk, má velký potenciál a měl by umožnit implementaci všech funkčních prvků aplikací. Jistou nevýhodou Javy může být její závislost na Java Virtual Machine a verzi JRE (Java Runtime Environment) - prostředí umožňujícího běh Java aplikací. V současné době je aktuální verze Java 6 a verze JRE 6 Update 25. Na této verzi budou aplikace vyvíjeny a testovány. Uživatel musí mít pro spuštění aplikací nainstalované na svém počítači běhové prostředí Java Runtime Environment, které je možné stáhnout z: http://www.oracle.com/technetwork/java/javase/downloads/index.html Uživatelské rozhraní aplikací bude naprogramováno pomocí GUI knihovny Swing, která je přímo součástí jazyka Java. Aplikace nebudou po stránce GUI nijak složité a proto není potřeba zvažovat použití externích knihoven.
3.3.4
Výběr datového úložiště
Výběr databáze je zúžen použitým serverem, na kterém jsou dostupné jen databáze MySQL 5.1, MySQL 5.1 InnoDB a PostgreSQL 8.4 (které jsou ale na webových hostinzích nejvíce rozšířené). Základní verze MySQL 5.1 (engine MyISAM) nebude použita, protože oproti verzi InnoDB postrádá podporu transakcí, referenční integrity (cizí klíče) a clustrovaného indexu. Při aktualizaci údajů tabulky engine InnoDB zamyká na úrovni řádků a ne na úrovni celé tabulky jako engin MyISAM, více uživatelů tedy může najednou a bez čekání měnit data ve stejné tabulce. Ve většině případů je také InnoDB při provádění dotazů rychlejší.
52
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Rychlostní rozdíly mezi InnoDB a PostgreSQL vynikají až u komplexních databází a složitých SQL dotazů, kdy PostgreSQL bývá rychlejší, neboť je optimalizována na složité dotazy, zatímco MySQL je optimalizována spíše na jednodušší dotazy ([18]). Na centrálním serveru nebude komplexní databáze ani velmi složité SQL dotazy a protože je MySQL rozšířenější a mám mnohem větší zkušenosti s její syntaxí, bude v tomto projektu použita databáze typu MySQL InnoDB.
3.4. SOFTWAROVÝ NÁVRH APLIKACE
3.4
53
Softwarový návrh aplikace
V rámci analýzy jsem provedl softwarový návrh systému, který byl v některých částech zjednodušen, protože vlastní systém nebude natolik komplexní, aby byla vyžadována podrobná dokumentace. Jako dostačující považuji katalog požadavků, uživatelské role a jejich práva, scénáře užití, diagramy tříd, diagramy složitějších aktivit, diagram komponent aplikace a návrh relační databáze. Zvlášť bude rozlišován návrh serverové části systému a klientských desktopových aplikací. Diagramy byly vytvořeny v programu Enterprise Architect od firmy Sparx Systems.
3.4.1
Katalog požadavků
Katalog požadavků udává požadavky, které musí implementovaný systém splňovat. Funkční požadavky udávají, jakou funkčnost musí program mít. Nefunkční požadavky kladou omezení na vzhled a způsob fungování aplikace. 3.4.1.1
Serverová část
Funkční požadavky F1. Server bude umožňovat vytváření a správu více nezávislých uživatelských účtů. F1.1. Administrátor bude moct zobrazit seznam uživatelů a smazat uživatele. F1.1. Uživatel se bude moct do systému sám registrovat. F1.2. Po přihlášení do systému budou uživateli nabídnuty možnosti dostupné pouze pro registrované uživatele. F1.3. Registrovaný uživatel bude moct změnit své přihlašovací heslo a další nepovinné údaje. F2. Registrovaný uživatel bude moct přidávat do systému své klientské stanice. F2.1. Každá stanice může odesílat více veličin. F2.2. Každá stanice má neměnitelnou zeměpisnou polohu. F2.3. Systém bude přijímat a ukládat data dané klientské stanice. F2.4. Stanice může být pro vlastní potřebu a data z ní se nebudou zobrazit nikomu dalšímu. F2.5. Registrovaný uživatel bude moct zobrazit seznam svých stanic. F3. V systému bude volně dostupný seznam vlastních stanic. F3.1. Polohy stanic budou vyneseny do mapy. F4. Pokud není stanice pro vlastní potřebu, bude moct každý zobrazit naměřené údaje zvolené stanice.
54
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
F4.1. Údaje stanice pro vlastní potřebu bude moct zobrazit pouze její majitel. F4.2. Z naměřených údajů budou spočítány statistiky (průměr, minimum, maximum) a vytvořeny grafy. F4.3. Vhodný typ grafu bude zvolen podle období (denní, měsíční, roční). F4.4. Registrovaný uživatel bude moct naimportovat naměřené údaje ke své vybrané stanici. F4.5. Registrovaný uživatel bude moct exportovat naměřené údaje své vybrané stanice. F5. V systému bude volně dostupný seznam převzatých stanic. F5.1. Údaje budou přebírány z ČHMÚ a Weather Underground. F5.2. Polohy stanic budou vyneseny do mapy. F5.3. Systém umožní zobrazení aktuálních údajů dané převzaté stanice. F5.4. Na stránce stanice bude dostupný odkaz na původní zdroj dat. F6. Registrovaný uživatel bude moct přidat do systému místa, ze kterých chce přijímat meteorologické údaje. F6.1. Místo bude moct přijímat údaje z vlastních klientských stanic i převzaté údaje. F6.2. Každé místo má neměnitelnou zeměpisnou polohu. F6.3. Uživatel si bude moct vybrat ze stanic vzdálených maximálně zvolený počet kilometrů. F6.4. Údaje pro dané místo bude možné poskytovat klientské aplikaci pro zobrazení údajů. F7. Administrátor bude moct zobrazit seznam všech míst v systému. F8. Administrátor bude moct zobrazit log chyb (např. výpadky spojení s databází). F9. Administrátor bude moct zobrazit log návštěv přihlášených uživatelů. F9.1. Návštěva uživatele z dané IP adresy bude logována pouze jednou denně. F10. V systému budou všichni uživatelé moct zobrazit informace o tomto projektu, jeho funkce a výhody. Nefunkční požadavky N1. Bezpečné uložení hesel v databázi formou otisku. N2. Databáze bude založena na MySQL InnoDB enginu. N3. Naměřená data ze stanic budou uchovávána po neomezenou dobu. N4. Veškerá data ze serveru bude možné bez komplikací přemístit na jiný server.
3.4. SOFTWAROVÝ NÁVRH APLIKACE
3.4.1.2
55
Klientská aplikace komunikující s měřícími stanicemi
Funkční požadavky F1. Klientská aplikace bude umožňovat komunikaci s meteorologickými čidly a stanicemi a čtení jejich aktuálních údajů. F1.1. Aplikace bude navržena obecně pro měření libovolných údajů a komunikaci s různými stanicemi. F1.2. Implementováno bude měření teploty z čidla Papouch TM - RS-232. F1.3. Bude možné změnit interval snímání údajů z čidla. F2. Bude možné ukládat údaje do souboru. F2.1. Bude možné změnit interval ukládání do souboru. F2.2. Data budou dle volby ukládána do jednoho souboru nebo každý den do samostatného souboru. F3. Bude možné odesílat všechna naměřená data na server pomocí HTTP metody GET. F3.1. Při použití serveru Meteoris budou data přiřazena ke zvolené stanici daného uživatele. F3.2. Adresa serveru včetně parametrů bude libovolná a půjde změnit. F3.3. Heslo bude možné odesílat nezašifrovaně nebo jako otisk SHA-1. F3.4. Bude možné změnit interval odesílání na server. F4. Bude možné nastavit 3 alarmy, které se spustí při překročení teploty a vizuálně upozorní uživatele. F4.1. Bude možné přehrát s alarmem zvuk, každý alarm bude mít jiný zvuk, bude možné zvuk nekonečně opakovat. F4.2. Alarm se spustí dle volby při vzestupu nad nastavenou teplotu nebo při poklesu pod nastavenou teplotu. F5. Bude možné nastavit odesílání emailu při spuštění alarmu. F5.1. Aplikace nebude implementovat vlastní poštovní server, ale využije externí poštovní server. F5.2. Bude možné specifikovat adresu příjemce, odesílatele, parametry poštovního serveru a použití autorizace a šifrování. F6. Při chybě komunikace s čidlem, se serverem či jiné chybě bude informace zalogována do souboru a při vážné chybě také zobrazena uživateli. F7. Aplikaci bude možné minimalizovat do systémové lišty. F7.1. Při najetí na ikonu v systémové liště bude zobrazena teplota. F8. Aplikace bude obsahovat uživatelskou příručku a informaci o autorovi.
56
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Nefunkční požadavky N1. Aplikace bude multiplatformní - bude fungovat na operačních systémech Microsoft Windows a Linux. N2. Aplikace bude desktopová. N3. Aplikace bude uživatelsky přívětivá a jednoduchá na ovládání. N4. Aplikace bude snadno přenositelná. 3.4.1.3
Klientská aplikace zobrazující údaje
Funkční požadavky F1. Klientská aplikace bude umožňovat komunikaci se serverem a získávání a zobrazení meteorologických údajů pomocí HTTP metody GET. F1.1. Při použití serveru Meteoris budou čtena data zvoleného místa daného uživatele. F1.2. Adresa serveru včetně parametrů bude libovolná a půjde změnit. F1.3. Heslo bude možné odesílat nezašifrovaně nebo jako otisk SHA-1. F1.4. Bude možné změnit čtení údajů ze serveru. F2. Bude možné ukládat údaje do souboru. F2.1. Bude možné změnit interval ukládání do souboru. F2.2. Data budou dle volby ukládána do jednoho souboru nebo každý den do samostatného souboru. F3. Bude možné nastavit 3 alarmy, které se spustí při překročení teploty a vizuálně upozorní uživatele. F3.1. Bude možné přehrát s alarmem zvuk, každý alarm bude mít jiný zvuk, bude možné zvuk nekonečně opakovat. F3.2. Alarm se spustí dle volby při vzestupu nad nastavenou teplotu nebo při poklesu pod nastavenou teplotu. F4. Bude možné nastavit odesílání emailu při spuštění alarmu. F4.1. Aplikace nebude implementovat vlastní poštovní server, ale využije externí poštovní server. F4.2. Bude možné specifikovat adresu příjemce, odesílatele, parametry poštovního serveru a použití autorizace a šifrování. F5. Při chybě komunikace se serverem či jiné chybě bude informace zalogována do souboru a při vážné chybě také zobrazena uživateli. F6. Aplikaci bude možné minimalizovat do systémové lišty.
3.4. SOFTWAROVÝ NÁVRH APLIKACE
57
F6.1. Při najetí na ikonu v systémové liště bude zobrazena teplota. F7. Aplikace bude obsahovat uživatelskou příručku a informaci o autorovi. Nefunkční požadavky N1. Aplikace bude multiplatformní - bude fungovat na operačních systémech Microsoft Windows a Linux. N2. Aplikace bude desktopová. N3. Aplikace bude uživatelsky přívětivá a jednoduchá na ovládání. N4. Aplikace bude snadno přenositelná.
3.4.2
Uživatelé a jejich práva
V systému budou následující tři uživatelské role: Neregistrovaný uživatel nebo také nepřihlášený registrovaný uživatel mají právo zobrazit informace o projektu, jeho funkcích a výhodách. Dále je veřejně dostupný seznam převzatých stanic a jejich aktuální údaje a seznam vlastních klientských stanic a jejich naměřené údaje, statistiky a grafy. Mohou využívat aplikaci pro komunikaci s měřícími stanicemi, ale nemohou odesílat data na centrální server systému. Dále mohou využívat aplikaci pro čtení údajů ze serveru jiného než je centrální server systému. Registrovaný uživatel má práva neregistrovaného uživatele a dále možnost přidávat stanice a místa a zobrazit seznam vlastních stanic a míst. Registrovaní uživatelé mohou odesílat a přijímat data z centrálního serveru v klientských aplikacích systému. Dále mohou importovat a exportovat data ze svých stanic. Také mohou změnit své registrační údaje a změnit údaje stanic a míst a případně je smazat (stanici pouze pro vlastní potřebu). mohou zobrazit naměřené údaje stanic pro vlastní potřebu. Administrátor má práva registrovaného uživatele a navíc může zobrazit seznam všech uživatelů, stanic a míst, mazat uživatele a jejich stanice a místa, zobrazit log chyb a návštěv.
Obrázek 3.11: Diagram hierarchie uživatelů
58
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.4.3
Scénáře užití
Scénáře užití slouží k identifikaci činností, které bude každý uživatel moci vykonávat. Vycházejí z katalogu požadavků. Scénáře užití pro všechny tři systémové komponenty jsou z důvodu přehlednosti uvedeny v příloze C.1.
3.4.4
Diagramy tříd
Diagramy tříd zobrazují statickou strukturu systému prostřednictvím tříd a vztahů mezi nimi. Serverová část je poměrně specifická v tom, že zde není použit plně objektový přístup, ale objektově jsou navrženy jen třídy, které představují databázové entity (tedy třídy integrační vrstvy) a dále pomocné třídy bussiness logiky (pro Smarty, pro práci se soubory, kalendářem, log a pro tvorbu grafů), tedy třídy, u kterých se vyplatí zapouzdřit jejich funkčnost. Třídy bussiness logiky jsou většinou pomocné třídy se statickými metodami a nejsou ve vztahu k jiným třídám, třídy integrační vrstvy mezi sebou vztah mají. Desktopové aplikace mají plně objektový návrh. Některé třídy slouží jako pomocné třídy se statickými metodami. Diagramy tříd pro všechny tři systémové komponenty jsou z důvodu přehlednosti uvedeny v příloze C.2.
3.4.5
Diagramy aktivit
Diagramy aktivit se používají pro popis dynamických prvků systému. Ukazují, jak jdou po sobě jednotlivé dílčí aktivity od začátku činnosti do jejího konce. Vybrané diagramy aktivit jsou z důvodu přehlednosti uvedeny v příloze C.3.
3.4.6
Diagramy nasazení
Diagram nasazení na obrázku 3.12 ukazuje rozmístění hardwarových zdrojů a jaké softwarové komponenty na nich běží a jaké mezi sebou mají tyto komponenty vztahy. Komponenta je modulární část systému, která zapouzdřuje svůj obsah a je vyměnitelná za jinou komponentu, která má stejnou funkčnost a používá stejná rozhraní. Systém se bude skládat ze čtyř uzlů: • Klientské PC • Měřící stanice • Server Apache • MySQL InnoDB server
3.4. SOFTWAROVÝ NÁVRH APLIKACE
Obrázek 3.12: Diagram nasazení
59
60
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Na PC uživatele může běžet webový prohlížeč a obě desktopové aplikace v Java Virtual Machine (virtuální stroj umožňující běh aplikací napsaných v programovacím jazyce Java). Aplikace pro komunikaci s měřícími stanicemi bude komunikovat s měřící čidly buď po RS-232 nebo USB. Všechny tři komponenty budou komunikovat se serverovou komponentou systému pomocí internetového protokolu HTTP. Serverová komponenta běží v PHP enginu a skládá se z prezentační vrstvy, bussiness vrstvy a integrační vrstvy, které jsou také na sobě v tomto pořadí závislé. Prezentační vrstva využívá šablonovací systém Smarty a bussiness vrstva i integrační vrstva využívají framework PEAR (bussiness vrstva např. pro tvorbu grafů a integrační vrstva pro komunikaci s databází). Integrační vrstva dále komunikuje prostřednictvím jazyka SQL se Systémem řízení báze dat (DBMS) na serveru MySQL InnoDB.
3.4.7
Relační databázový model
Schéma relační databáze je z důvodu přehlednosti uvedeno v příloze C.4. Tabulka uzivatele obsahuje registrační údaje o uživatelích. Tabulka navstevy obsahuje informace o tom, kdy registrovaní uživatelé navštívili webové stránky systému. Tabulka stanice obsahuje údaje o klientských stanicích uživatelů. Tabulka stanice_prevzate obsahuje seznam převzatých stanic. Tabulka stanice_veliciny obsahuje seznam veličin, které měří daná klientská stanice. Tabulka mereni obsahuje naměřené hodnoty klientských stanic. Tabulka mista obsahuje místa, která si uživatel vytvořil pro příjem údajů ze stanic. Poznámka: Cizí klíč id_stanice odkazuje buď do tabulky stanice nebo stanice_prevzate a to se řídí podle atributu typ_mereni (jehož hodnota je buď „vlastní“ nebo „převzaté“). Funkce vzdalenostZeSouradnic uložen v databázi slouží k výpočtu vzdušné vzdálenosti v kilometrech dvou míst podle jejich zeměpisných souřadnic.
Kapitola 4
Implementace V této kapitole bude přiblížena implementace Systému pro sběr a distribuci meteorologických údajů. Budou zde uvedeny technologie a implementační postupy použité u jednotlivých komponent systému. Pro usnadnění implementace desktopových aplikací jsem použil vývojové prostředí NetBeans IDE 6.9.1, které umožňuje velmi efektivní psaní zdrojového kódu programu a obsahuje i velmi dobře propracovaný designér grafického uživatelského rozhraní. Mezi další dovednosti NetBeans IDE patří spouštění a debuggování programu, podpora verzování kódu, kontrola syntaxe, obsahuje různé šablony a dokáže chytře doplňovat zdrojový kód či zobrazit dokumentaci. Vývoj serverové části probíhal v českém pokročilém textovém editoru PSPad, který umožňuje obarvování zdrojového kódu a tím velmi usnadňuje kontrolu syntaxe. Implementace probíhala iterativní vývojovou metodou, kdy byla vždy naprogramována malá část systému (jeden funkční celek) a důkladně otestována, případné chyby opraveny a poté jsem postoupil k implementaci dalšího malého funkčního celku. Po dokončení aplikace komunikující s čidlem tato aplikace několik měsíců sbírala měření, aby byly dostupné podklady pro testovací provoz serveru.
4.1
GUI - grafické uživatelské rozhraní
Grafické uživatelské rozhraní (GUI) je uživatelské rozhraní, které umožňuje ovládat aplikaci pomocí grafických prvků zobrazených na obrazovce monitoru. Vzhled GUI je obvykle jedním z nejdůležitějších aspektů aplikace, protože je to první věc, se kterou uživatel přijde po spuštění programu do kontaktu. Pokud GUI nevypadá pěkně a neovládá se dobře, může uživatel být odrazen od používání jinak velice dobře fungující aplikace. K tvorbě GUI desktopových aplikací jsem použil designér integrovaný v NetBeans IDE, protože manuální tvorba grafického rozhraní by vzhledem k většímu množství ovládacích prvků u jednotlivých dialogových oken zabrala výrazně více času bez většího přínosu. Designér například umožňuje dodržet pravidla rozložení prvků v okně, která mohou být velmi komplexní a bylo by namáhavé je ručně popsat zdrojovým kódem. Designér na základě vytvořené grafické podoby vygeneruje zdrojový kód pro grafické komponenty sám.
61
62
KAPITOLA 4. IMPLEMENTACE
GUI webové části systému bylo vytvářeno ručně pomocí kombinace XHTML kódu a značek šablonovacího systému Smarty (který je velmi užitečný např. pro vytváření tabulek). Bylo dbáno na kontrolu validity kódu a správný vzhled byl průběžně ověřován v současných verzích všech běžně používaných prohlížečů. Při tvorbě GUI jsem se snažil dbát na správné rozmístění ovládacích prvků v okně a decentní používání barev. Okna neobsahují příliš velké množství ovládacích prvků, dělá je to nepřehlednými a složitými na orientaci. Použití málo kontrastních barev není vhodné, protože celé rozhraní poté působí nevýrazným dojmem a nemotivuje k používání. Naopak používání přiliš kontrastních barev také není vhodné, neboť působí únavně na oči. Část ovládacích prvků byla u desktopových aplikací přesunuta kvůli zpřehlednění do menu. Ovládací prvky, které zobrazují text, byly vybaveny kontextovým menu, které umožňuje například zkopírovat vybraný text do schránky. Ve webové části systému byly také použity některé nepovinné elementy pro zvýšení dostupnosti ovládacích prvků (např. použití popisků formulářových polí, na které když se klikne, tak je textový kurzor přesunut do pole svázaného s popiskem). Těmito prvky se zvýšila interaktivnost komponent. V aplikacích je používán standardní systémový vzhled komponent neboli nativní Look & Feel, který jsou součástí platformy Java, a uživatel se tak bude pohybovat ve známém prostředí. Pokud je nezbytné, aby v okně bylo větší množství ovládacích prvků, přidal jsem k nim popisné texty a plovoucí nápovědu, která se zobrazí při najetí myší na prvek (tzv. tool-tip). Pokud je uživatel vyzván k zadání údajů, je mu přesně oznámeno co a v jakém tvaru má zadat a jaké jsou povolené hodnoty. Pokud zadá špatnou hodnotu, aplikace mu oznámí, kde udělal chybu. Ke zvýšení dostupnosti ovládacích prvků (accessibility) v aplikacích a rychlosti práce s nimi jsem využil přiřazení klávesových zkratek, ať už běžně používaných (např. Ctrl+C/V pro kopírování resp. vložení textu, F1 pro nápovědu atp.) nebo tzv. mnemoniky, která umožňuje rychlou navigaci pomocí klávesnice (označení komponenty nebo provedení akce po stisknutí Alt + podtržené písmeno v popisce komponenty). Do programu byla také integrována nápověda ve formě uživatelské příručky, viz příloha E. Dodržováním těchto pravidel jsem se snažil udělat program uživatelsky přívětivý. Jak grafické uživatelské rozhraní jednotlivých komponent vypadá, je možné vidět z obrázků v příloze D.
4.2
Struktura systému
Systém se skládá ze tří komponent - centrální serverové části, aplikace pro komunikaci s měřícími stanicemi a aplikace pro zobrazování meteorologických údajů. Tyto části lze dále členit na menší funkční celky. Všechny tři komponenty lze používat v součinnosti i samostatně.
4.2.1
Centrální serverová část
• informace o projektu
4.2. STRUKTURA SYSTÉMU
• přihlášení a registrace do systému • seznam vlastních stanic • měření stanic, statistiky a grafy • seznam převzatých stanic • aktuální údaje z převzatých stanic • přidání vlastní stanice a změna jejích parametrů • import a export naměřených údajů • přidání místa pro odběr údajů a změna jeho parametrů • seznam všech míst • změna registračních údajů • log chyb a log návštěv
4.2.2
Aplikace pro komunikaci s měřícími stanicemi
• čtení údajů z měřící stanice • nastavení parametrů čidla • ukládání naměřených údajů do souboru • odesílání naměřených údajů na server • alarmy při překročení teploty • odeslání emailu při spuštění alarmu (v prototypu aplikace neimplementováno) • nastavení uživatelského rozhraní aplikace • nápověda (uživatelská příručka) a informace o autorovi
4.2.3
Aplikace pro zobrazování meteorologických údajů
• čtení údajů zvoleného místa ze serveru • ukládání přijatých údajů do souboru • alarmy při překročení teploty • odeslání emailu při spuštění alarmu (v prototypu aplikace neimplementováno) • nastavení uživatelského rozhraní aplikace • nápověda (uživatelská příručka) a informace o autorovi
63
64
KAPITOLA 4. IMPLEMENTACE
Implementace, testování a provoz serverové komponenty probíhá na serveru popsaném v části 3.3.2.3. Implementace, testování a provoz desktopových aplikací probíhá jak na počítači s operačním systémem Windows (konkrétně Windows 7), tak na OS Linux, aby byla ověřena multiplatformnost.
4.3
Použité technologie
Technologie použité při implementaci byly popsány v části návrhu 3.3.3. Nyní bude fungování některých těchto technologií popsáno blíže.
4.3.1
Framework PEAR
PEAR (PHP Extension and Application Repository) funguje jako nadstavba pro serverový skriptovací jazyk PHP ([19]). Je to modulární balíčkovací systém, kdy si programátor sám zvolí a jednoduše nainstaluje, které balíčky (funkčnost) chce využívat. PEAR původně vznikl kvůli potřebě zapouzdření jednotného přístupu k různým databázím v roce 1999, ale od té doby obsahuje několik stovek balíčků, které umožňují například: • správu uživatelských oprávnění • šifrování dat • ukládání, načítání a konverzi různých souborových formátů • nástroje pro HTML - AJAX, JavaScript, HTML formátování • práci s protokolem HTTP - zpracovávání HTTP žádostí, hlaviček, upload souborů • práci s obrázky (2D i 3D) • odesílání a přijímání emailů • práci s textem (např. captcha - opsání textu z obrázku kvůli zamezení zneužití stránky roboty) • práci s XML - pársování, formátování, konverze • a již zmíněná komunikace prakticky s libovolnou databází Požadované balíčky se jednoduše nainstalují pomocí webového rozhraní umístěného do adresáře na našem serveru. PEAR využívá plně objektový přístup. V této diplomové práci byly využity balíčky DB pro komunikaci s databází (ukázka 4.1) a Image Graph pro vytváření grafů z naměřených údajů v obrázkové podobě (ukázka 4.2).
4.3. POUŽITÉ TECHNOLOGIE
65
Obrázek 4.1: Ukázka použití frameworku PEAR - přístup k databázi
Obrázek 4.2: Ukázka použití frameworku PEAR - vytvořený graf
4.3.2
Šablonovací systém Smarty
Smarty je šablonovací systém pro serverový skriptovací jazyk PHP ([20]). Umožňuje oddělit vzhled webových stránek od aplikační logiky použitím šablon, což zpředhledňuje vyvíjený systém a umožňuje také např. snazší dělbu práce mezi programátory a webovými designery. V šablonách se pomocí HTML kódu a formátovacích značek Smarty definuje vzhled. Při první HTTP žádosti o danou stránku je poté text přeložen do čistého PHP kódu, který odesílá obsah HTML stránky klientovi (při dalších žádostech už je použit rovnout přeložený kód šablony). Ukázka šablony Smarty je na obrázku 4.3. Na centrálním serveru systému jsou Smarty šablony použity pro všechny webové stránky. Formátovací značky Smarty například umožňují: • použití modifikátorů ke změně textu - změna velikosti, nahrazení znaků, escapování
66
KAPITOLA 4. IMPLEMENTACE
HTML značek (zabraňuje HTML injection) • použití funkcí pro snazší vytvoření formulářových prvků a jejich naplnění daty (HTML prvky select a input různých typů) • podmínečné vyhodnocení části šablony podle hodnoty proměnné (v závislosti na ní se může odeslat na výstup jiný kus HTML kódu) • opakování části kódu - využití např. pro velmi snadnou tvorbu tabulek • vložení kódu z jiné šablony - umožňuje snadné strukturování stránek a zabránění duplikaci kódu (např. jeden kód pro menu, hlavičku a patičku)
Obrázek 4.3: Ukázka použití šablonovacího systému Smarty
4.3.3
Dynamická komunikace s využitím AJAXu
AJAX je způsob komunikace prohlížeče se serverem prostřednictvím asynchronního posílání zpráv za účelem změny obsahu webové stránky bez nutnosti jejího znovunačtení. Využívá jazyk JavaScript a pro přenos se obvykle používá formát XML (případně také prostý text, HTML či jiné). AJAX není technologie, ale spíše označení pro kombinaci technologií. Využívá javascriptového objektu XMLHttpRequest pro komunikaci se serverem a XML reprezentaci dokumentu (Document Object Model - DOM) pro změnu elementů webové stránky. Asynchronnost AJAXu spočívá v tom, že vykonávaný javascriptový kód nečeká na odezvu serveru a pokračuje dále, přitom je registrován handler, který kontroluje stav žádosti a při příchodu dat ze serveru se provede požadovaná činnost. Použití AJAXu výrazně zvyšuje dynamičnost stránky a interaktivitu s uživatelem a zároveň zjednodušuje ovládání stránky (není např. nutné po výběru elementu provést potvrzení, části stránky lze načítat na vyžádání atp.).
4.4. IMPLEMENTACE VYBRANÝCH ČÁSTÍ SYSTÉMU
67
V tomto projektu byl AJAX použit pro zjištění souřadnic podle zadaného města a je také využíván u map poskytovaných serverem Mapy.cz. Pro získání seznamu stanic nacházejících se od vybraného místa do zvolené maximální vzdálenosti byla použita synchronní varianta SJAX, u které se vykonávání javascriptového kódu pozastaví, dokud nepřijde odezva ze serveru.
4.4
Implementace vybraných částí systému
V této části budou popsány zajímavé postupy použité při implementaci.
4.4.1
Desktopové aplikace
Obě aplikace využívají některé společné části, které budou popsány pro obě společně po popsání implementace částí, které má každá aplikace unikátní. Aplikace byly úspěšně otestovány pod operačními systémy Windows 7 a Linux (distribuce Ubuntu), včetně čtení údajů z RS-232 teplotního čidla. 4.4.1.1
Komunikace s měřícími stanicemi
Přestože zadání této diplomové práce požaduje pouze návrh a implementaci měření teploty, navrhl jsem aplikaci pro komunikaci s měřícími stanicemi obecně, aby bylo možné v budoucnu přidat podporu pro čtení dalších údajů a podporu dalších typů měřících čidel a stanic. K tomu byl vytvořen interface MericInterface s metodami nastavMeric(cisloPortu), otevriKanal(), isOtevrenyKanal(), zavriKanal(), volnePorty() a zmerTeplotu(). Pro přidání podpory čtení teploty z nové stanice tak stačí pouze implementovat tento interface. Pro čtení dalších meteorologických veličin či všech najednou stačí přidat nové metody do dané stanici příslušející třídy (ne do interface). Nutnou podmínkou je ale pouze čtení teploty, protože některá čidla jiné údaje číst neumí, a proto interface nebude v této fázi projektu obsahovat metody pro čtení dalších veličin. Po provedené analýze jsem se rozhodl implementovat komunikaci s čidlem Papouch TM prostřednictvím sériového rozhraní RS-232. Komunikace probíhá se skutečným nebo virtuálním portem, takže lze sériové čidlo připojit k počítači i přes RS-232 –> USB redukci nebo připojit přímo dražší USB čidlo Papouch TMU. Pro komunikaci se sériovým portem byla použita multiplatformní javovská knihovna GiovynetDriver verze 1.1, která je šířena pod licencí LPGL a je tak umožněna její modifikace a komerční využití programů, které ji používají (což je hlavní rozdíl od licence GPL). Tato knihovna je dostupná na adrese http://java.giovynet.com/Giovynet/. Komunikace s čidlem funguje následovně: Nejdříve se zjistí volné COM porty v počítači pomocí getFreeSerialPort() třídy giovynet.nativelink.SerialPort. Po zvolení správného portu, ke kterému je čidlo připojeno, je otevřen komunikační kanál s rychlostí 9600 bit/s pomocí metody open() třídy giovynet.serial.Com. Minimální prodleva před čtením prvního znaku po otevření portu a délka čtecího intervalu mezi dvěma znaky jsou ponechány na výchozích hodnotách (0 ms pro Windows a 10 ms pro Linux pro iniciální prodlevu, resp. 50 ms pro délku intervalu).
68
KAPITOLA 4. IMPLEMENTACE
Poté už stačí jen přečíst hodnotu pomocí metody receiveToString(počet znaků) třídy Com s parametrem 7, což je počet znaků přijímaného řetězce teploty včetně znaménka a jednotky. Dále je číslo v řetězci už jen zformátováno na desetinné číslo pevné délky (objekt třídy BigDecimal). Interval mezi čteními teploty z čidla je volitelný v nastavení aplikace a výchozí hodnota je 5 sekund. 4.4.1.2
Uživatelské rozhraní
Uživatelské rozhraní bylo navrženo v NetBeans IDE a využívá grafické knihovny Swing jazyka Java. Obě aplikace jsou tvořeny jednoduchým hlavním oknem a pomocnými dialogovými okny, která slouží pro změnu nastavení aplikace nebo zobrazení uživatelské příručky. Místo výchozího multiplatformního vzhledu je použit systémový Look & Feel, aby aplikace vypadala vzhledoě podobně, jako ostatní aplikace v systému. Aplikace podporují minimalizaci do systémové lišty a zobrazení údajů při najetí kurzoru myši na ikonu v liště. Takto mohou být obě aplikace spuštěny nepřetržitě a nebudou uživatele nijak rušit svým během. 4.4.1.3
Ukládání údajů do souboru
Změřené nebo načtené údaje je možné ukládat do souboru. U komunikační aplikace měřící zatím pouze teplotu je na každý řádek uloženo jedno měření a to jako čas a hodnota teploty oddělené tabelátorem. Tento formát je možné naimportovat k dané stanici na server. U zobrazovací aplikace jsou uloženy kompletně všechny informace přijaté ze serveru. V nastavení aplikace lze zvolit, zda se má pro každý den použít jiný soubor nebo se mají data ukládat do jednoho a toho samého souboru. Ukládání do souboru probíhá prostřednictvím třídy PrintWriter využívající stream třídy FileOutputStream. 4.4.1.4
Odesílání a čtení údajů ze serveru
Obě aplikace komunikují s centrálním serverem. Aplikace měřící teplotu odesílá data na server, kde jsou pro danou stanici uloženy, a aplikace zobrazující data přijímá údaje pro dané místo. Stanice i místo mají své ID, které se v aplikacích musí zadat. Dalším nutným údajem je uživatelské heslo, které bude na server odesláno zašifrované jako otisk SHA-1 (40 znaků). K šifrování hesla je využita knihovna java.security, která je součástí Java Development Kitu. Komunikační API systémového serveru je blíže popsáno v sekci 4.4.2.7. V případě, že by chtěl uživatel použít svůj vlastní nebo jiný server, může zvolit formát parametrů adresy tak, jak potřebuje. Před odesláním je řetězec {ID} nahrazen ID stanice, řetězec {heslo} je nahrazen otiskem uživatelského hesla. Veličiny a jejich hodnoty jsou odesílány jako zřetězení potřebného počtu řetězců &id_velicinyX = [ID veliciny]&hodnotaX = [hodnota], kde X je nahrazeno pořadovým číslem veličiny (číslováno od 1) a hodnoty v hranatých závorkách jsou nahrazeny příslušnou hodnotou.
4.4. IMPLEMENTACE VYBRANÝCH ČÁSTÍ SYSTÉMU
69
Při čtení ze serveru jsou parametry adresy jednodušší a je pouze provedeno nahrazení {ID} ID místa a {heslo} otiskem uživatelského hesla. V případě použití vlastního serveru nejsou parametry ID a heslo samozřejmě požadovány. Interval odesílání na server je volitelný po sekundách a je doporučeno použít alespoň 5 minut, kratší interval je zbytečný, neboť měřené veličiny se zas tak často nemění. Interval čtení údajů ze serveru je u druhé aplikace volitelný po minutách a přednastavený na 10 minut. Odesílání i čtení ze serveru využívají shodně klasické komunikační třídy java.io.InputStreamReader, která čte ze streamu otevřeného pomocí metody openStream() objektu třídy java.net.URL. 4.4.1.5
Alarmy
V obou aplikacích je možné nastavit upozornění po překročení teploty pod nebo nad nastavenou mez. Při spuštění alarmu lze přehrát zvuk, který je pro každý ze tří alarmů jiný, a je možné nastavit, aby se přehrávání zvuku ve smyčce opakovalo. K přehrávání zvuku ve formátu PCM (typický soubor WAV) je použit package javax.sound.sampled. Jeho třída AudioSystem otevře stream k souboru v resource (neboli v JAR archivu) a pomocí metody AudioSystem.getClip().open(stream) otevře soubor se zvukem. Klip lze poté opakovaně přehrát a v případě vypnutí alarmu zastavit. 4.4.1.6
Odeslání emailu při alarmu
Přestože vlastní odesílání emailů nebylo v prototypu systému implementováno, uživatelské rozhraní aplikací ale obsahuje možnosti nastavení parametrů emailu a poštovního SMTP serveru, aby v budoucnu mohla být tato funkčnost přidána co nejjednodušeji. K odesílání emailů se nebude využívat integrovaný poštovní server, protože to je poměrně složitá a komplexní komponenta, ale místo toho bude využito externího SMTP serveru (např. G-mail), kterému se email prostřednictvím SMTP protokolu předá. Bude možné využít autorizaci uživatelským jménem a heslem nebo šifrovaný přenos pomocí SMTP Secure. K odesílání emailů může být použita například jednoduchá knihovna JavaMail firmy Oracle, která poskytne svoji funkcionalitu jako package javax.mail. 4.4.1.7
Ukládání nastavení programu do XML souboru
Nastavení programu se ukládá do XML souboru nastaveni.xml ve stejném adresáři, jako je aplikace. Nástroje pro práci s XML dokumenty jsou standardní součástí jazyka Java a jsou obsaženy v balíčku javax.xml a jeho podbalíčcích parsers, transform a další. Načtení dokumentu je možné pomocí objektu třídy javax.xml.parsers.DocumentBuilder a jeho metody parse(). Tím je vytvořen dokument reprezentující Dcument Object Model (DOM) daného dokumentu a lze snadno přistupovat k jednotlivým XML elementům. Zde je využita reflexe jazyka Java (možnost objektu zkoumat sebe sama, hodnoty svých proměnných, svoji třídu a její návrh atp.) a názvy a typ členských proměnných objektu Nastaveni jsou zjištěny pomocí metody Nastaveni.class.getFields() a tak je ušetřeno zdlouhavé vypisování jmen několika desítek proměnných (a zároveň usnadněna případná budoucí modifikace třídy Nastaveni).
70
KAPITOLA 4. IMPLEMENTACE
Z XML dokumentu se pak hodnoty jednotlivých proměnných získají pomocí metody getElementsByTagName() kořenového elementu daného dokumentu. K zápisu nastavení do souboru je využito tříd DocumentBuilder a javax.xml.transform.Transformer a i v tomto případě je využito reflexe.
4.4.2 4.4.2.1
Centrální serverová část Struktura webových stránek
Protože implementované webové stránky nejsou příliš komplexní, byla zvolena struktura jednoho souboru index.php a dělení stránek podle parametru page (např. index.php?page=seznam_stanic). Navenek se tedy webové stránky tváří jako jeden soubor. V systému jsou ale jejich jednotlivé části systematicky rozčleněné do jednotlivých .php souborů, které se v případě potřeby zahrnou při provádění skriptu příkazem include. Stejně tak šablony jsou použity pro každou stránku samostatné, přičemž se includují z hlavní šablony (index.html), která obsahuje menu, hlavičku a patičku (mění se tedy pouze obsah odstavce telo. Tím se neduplikuje zbytečně zdrojový kód a navíc není nutné v ostatních šablonách definovat HTML hlavičku. Každá webová stránka má tedy svůj vlastní php soubor a svoji vlastní Smarty šablonu. Na serveru jsou soubory umístěny přehledně do následujících adresářů: • / (kořenový adresář domény) – soubor index.php a php soubory pro jednotlivé stránky, pomocné php soubory a také setup.php s nastavením cest ke knihovnám a metodou pro připojení k databázi, a také chybová stránka 404.html • /obrazky/ – logo, pozadí, ikona webu a podsložka pro vygenerované grafy • styly – soubor kaskádových stylů a soubor s JavaScriptem • templates – složka se Smarty šablonami • templates_c – přeložené Smarty šablony do php souborů • tmp – složka s dočasnými soubory pro potřeby session manageru • tridy – složka s objektově navrženými třídami databázových entit a pomocných tříd 4.4.2.2
Práce se session a cookies
Pro uchování stavu komunikace (protokol HTTP je jinak bezestavový) se používá sezení (session). To se vždy spustí v souboru index.php metodou session_start() a tím dojde k vytvoření globálního pole s parametry session, které se načtou z dočasného souboru session na serveru, který se vyhledá podle přijatého identifikátoru sezení (předáván jako cookie, ne jako součást adresy). Při odeslání přihlašovacího formuláře jsou ověřeny přihlašovací údaje (přihlašovací jméno a SHA-1 otisk přijatého hesla) proti údajům v databázi. Pokud je uživatel správně ověřen, jsou mu odeslána cookies s jeho přihlašovacím jménem a SHA-1 otiskem hesla s platností 1 rok. Při dalším požadavku na stránku jsou pak tyto přijaté cookies použity k autentizaci
4.4. IMPLEMENTACE VYBRANÝCH ČÁSTÍ SYSTÉMU
71
uživatele ověřením otisku hesla proti otisku v databázi, pokud server nepřijal identifikátor sezení (např. při zavření prohlížeče), jinak dojde k vytvoření sezení automaticky a objekt s údaji uživatele je nalezen v dočasném souboru sezení v adresáři tmp na serveru. Při první návštěvě uživatele v daném dni je do databáze zalogován čas návštěvy, ID uživatele a jeho IP adresa. Seznam návštěv může sloužit jako menší statistika oblíbenosti stránek. Platnost odesílaných cookies se při každé návštěvě prodlouží. Tato forma přihlášení je známá jako trvalé přihlášení. Uživatel má vždy možnost odhlásit se ze systému ručně. 4.4.2.3
Komunikace s databází
Ke komunikaci s databází je použit balíček DB frameworku PEAR (viz jeho popis 4.3.1), který tuto komunikaci značně zjednodušuje. V souboru setup.php je definována metoda connectDB(), která obsahuje přihlašovací údaje k databázi a po připojení vrací objekt databázového spojení. Soubor setup.php je includován v souboru index.php, takže všechny další php soubory mají tutu metodu k dispozici. Protože persistence (ukládání) dat je věcí integrační vrstvy, starají se o veškerou komunikaci s databází třídy integrační vrstvy neboli databázové entity. Každá entita reprezentuje jednu databázovou tabulku a obsahuje třídní proměnné, které odpovídají jednotlivým sloupcům dané tabulky. Dále obsahuje metody pro vytváření nových řádků tabulky, jejich čtení, změnu a mazání, neboli zapouzdřuje CRUD operace (create, read, update, delete). CRUD operace jsou u webových projektů velmi obvyklé, protože reprezentují typický koloběh dat. Nejdříve jsou data vytvořena a vložena do databáze, poté se z databáze čtou, mění a opět ukládají a nakonec se mohou případně z databáze smazat. Balíček DB nejenže zprostředkovává komunikaci s databází a poskytuje pro všechny databáze stejné komunikační metody a není tak potřeba používat různé metody pro každý typ databáze, ale také se automaticky stará o escapování dat vkládaných do SQL dotazů (z řídících znaků udělá obyčejné textové znaky např. vložením zpětného lomítka před znak) a není to nutné dělat ručně. Escapování údajů je nutné kvůli možnosti hacknutí serveru pomocí SQL injection, více viz v další části o zabezpečení serveru 4.4.2.4. PEAR používá tzv. metodu Prepare & Execute, která funguje na principu vložení zástupných znaků (otazníku) do SQL dotazu a jejich nahrazení v execute fázi vlastními daty (která jsou automaticky escapována). Tím není nutné řetězit textový řetězec s daty, což může být u složitých dotazů velmi nepřehledné. Načítat data z databáze je možné přímo formou objektů - databázových entit (typ získávání DB_FETCHMODE_OBJECT ) nebo případně jako pole hodnot (typy DB_FETCHMODE_ORDERED a DB_FETCHMODE_ASSOC ), které je číselně řazené nebo asociativní s názvem sloupce použitým jako klíč. PEAR také umožňuje snadné stránkování nalezených záznamů, čehož se využívá při tvoření stránek různých seznamů. Načtení všech záznamů z databáze by trvalo delší dobu a často není vůbec potřeba a proto se načte jen zlomek záznamů a seznam se stránkuje. Pokud uživatel potřebuje, tak si zvolí další stránky a potřebná data se mu načtou. Tohoto je využíváno např. u seznamu měření stanice, kdy v databázi za delší dobu může existovat i několik desítek tisíc záznamů. Příklad na komunikaci s databází s využitím frameworku PEAR a načtení dat (včetně využití metody Prepare & Execute) byl uveden už dříve na obrázku 4.1.
72
4.4.2.4
KAPITOLA 4. IMPLEMENTACE
Zabezpečení serveru a ochrana proti nabourání
Každý veřejně dostupný server může být vystaven útoku zvenčí. Motivy lidí za nimi stojících mohou být různé, každopádně je potřeba se těmto útokům bránit. Existují různé formy pronikání do systémů nebo alespoň jejich zavalení požadavky a zpomalení jejich odezvy pro uživatele nebo rovnou pádu serveru (DOS útoky). DOS útokům se brání jen velmi obtížně (u webhostingu je to spíše věc poskytovatele), ale ostatní slabá místa lze většinou poměrně jednoduše odstranit a zabránit tak většině možností, jak do systému proniknout. Mezi základní techniky průniky do systému patří HTML a SQL injection. HTML injection (nebo také Cross-site scripting, XSS) znamená vložení HTML kódu (často skriptu) do odesílaných dat, která se pak mohou uživateli vrátit s odezvou serveru (např. při chybě) a uživateli je tak změněn obsah. Vložená data jsou interpretována jako zdrojový kód a mohou pak na dané stránce vykonat nějakou nekalou činnost. Tomu se zabrání escapováním dat odesílaných uživateli (nahrazení znaků se speciální, řídící, funkcí jejich variantami bez speciálního významu), např. u HTML kódu jde o nahrazení znaků < a > za < a >. Tedy jako bezpečnostní prvek a také jako ochrana před uložením vadných dat či jejich použitím a následnému pádu některých metod je použita validace formulářových dat. Validace probíhá na straně klienta prostřednictvím JavaScriptu, ale protože ten lze vypnout, je prováděna také na straně serveru. Pokud uživatel odešle neúplná nebo špatná data, je mu stránka vrácena s uvedením toho, kde udělal chybu. Data ve formuláři jsou předvyplněna přijatými daty, k čemuž opět jednoduše slouží šablonovací systém Smarty (viz jeho popis 4.3.2). Data jsou také escapována metodou htmlspecialchars(). Validací dat na straně klienta pomocí JavaScriptu je také zabráněno zbytečnému zatěžování serveru. Druhým typem injection je SQL injection, kdy se útočník snaží pozměnit význam prováděných SQL dotazů a např. se tak neoprávněně přihlásit do systému. Textové řetězce jsou v SQL uzavřeny v apostrofech a pokud by mezi ně byl vložen přebytečný apostrof, tak část řetězce za ním bude vyhodnocena jako část SQL příkazu a ne jako řetězec. Tomuto lze bránit escapováním dat vkládaných do databáze, což u mnou použitého balíčku DB frameworku PEAR automaticky dělají všechny metody. Protože toto escapování ukládaných dat escapuje řídící znaky jazyka SQL, ale ne jazyka HTML, je nutné před vložením data z databáze do webové stránky escapovat i tato data na řídící znaky HTML. K tomu se v šabloně používá modifikátor Smarty escape:’html’. Bezpečnost serveru spočívá také ve správném udělení přístupu do částí systému omezených jen pro přihlášené uživatele či pouze pro administrátora. K tomu se používá autentizace (ověření totožnosti uživatele) a autorizace (ověření jejich práv). V mém systému provádím autentizaci pomocí ověření přijatého uživatelského jména a hesla proti SHA-1 otisku hesla daného uživatele v databázi. Práva uživatele na zobrazení stránky určuje jejich role, která je také uložena v databázi. Na serveru jsou role neregistrovaný a registrovaný uživatel a administrátor. Před zobrazením stránky se nejdříve ověří, zda je uživatel vůbec přihlášen (stránky pro registrované uživatele) a pokud jde o stránku administračního rozhraní, tak se ověří, zda má uživatel roli administrátor. V adresářích na serveru, kam uživatelé nemají mít přístup, je vypnuta funkce serveru „zobrazení obsahu adresáře pokud není v adresáři indexový soubor“ a do adresáře je umístěn soubor .htaccess s direktivou zákaz vstupu (deny from all). Tak je zabráněno uživateli
4.4. IMPLEMENTACE VYBRANÝCH ČÁSTÍ SYSTÉMU
73
zvenku, aby zpřístupnil obsah například adresářů templates (šablony), tmp (data sezení) a tridy (soubory s třídami) a tím potenciálně zkompromitoval systém. Dalším bezpečnostním prvkem centrálního systému je aktivace protokolu HTTPS na serveru neboli šifrovaného přenosu dat pomocí SSL mezi serverem a uživatelem (oproti nešifrovanému protokolu HTTP). Server tedy naslouchá také na adresách začínajících na https://. Jako certifikát serveru je použit obecný certifikát vystavený pro servery hostované Savana.cz. Posledním typem zabezpečení je aktivace tzv. safe režimu na serveru, což je příkaz k zakázání používání některých potenciálně nebezpečných funkcí přímo na úrovni zdrojového kódu PHP. Za pomoci všech těchto bezpečnostních opatření jsem poskytl serveru alespoň základní míru bezpečnosti a pokusil se minimalizovat riziko útoku na server (ač ze zjevných důvodů není velké). 4.4.2.5
Zjištění zeměpisných souřadnic z adresy
Při přidání stanice nebo místa byla implementována funkčnost zjištění zeměpisných souřadnic z adresy (tzv. geocoding). K tomu se využívá služby poskytované API serveru Mapy.cz ([14]). Princip fungování je následující: Do stránky se vloží javascriptový skript ze serveru beta.api.mapy.cz obsahující potřebné třídy API serveru Mapy.cz. Dále je v javascriptovém skriptu mého serveru metoda obsluhující kliknutí na tlačítko, která vytvoří objekt SMap.Geocoder, kterému v konstruktoru předá adresu, call-back funkci a odkaz na proxy soubor. Call-back funkce provede zpracování nalezených souřadnic ve chvíli, kdy jí je Geocoder poskytne. Protože nelze ze skriptu na jednom serveru kontaktovat server na jiné doméně, je nutné použít proxy soubor umístěný na serveru (v našem případě /geocode.php), který se dotáže na server beta.api.mapy.cz a vrátí pak skriptu nalezený seznam adres včetně jejich souřadnic. Geocoder tedy využívá technologii AJAX. Nalezené adresy se projdou a jsou nabídnuty uživateli, který si z nich vybere tu svoji (pokud je zadána kompletní adresa, tak je obvykle nalezená adresa právě jedna) a po potvrzení výběru jsou její souřadnice vloženy do formulářových polí. 4.4.2.6
Načtení stanic v určité vzdálenosti a počítání vzdáleností ze souřadnic
Technologie AJAX, resp. přesněji SJAX (viz jejich popis v sekci 4.3.3), je využito také při načtení seznamu stanic nejbližších městu zadanému uživatelem (resp. jeho souřadnicím) při přidání místa. Uživatel vyplní souřadnice místa, maximální vzdálenost, ve které se stanice mohou nacházet, vybere typ poskytovaných měření (vlastní a převzatá) a poté je pomocí SJAXu dotázán server, který podle poskytnutých informací vrátí seznam stanic (měst, ve kterých se nacházejí) spolu se vzdáleností od zvoleného města a pokud je vybraný typ poskytovaných měření měření vlastní pak také informaci o tom, jestli je stanice aktivní (poslala během posledních 3 dní na server data). Uživatel si z nich pak musí vybrat tu, ze které chce dostávat informace. Vzdálenost dvou bodů se ze zeměpisných souřadnic počítá jako vzdálenost dvou bodů na zeměkouli (resp. na kouli, což způsobí velmi malou a zanedbatelnou odchylku) podle vzorce pro výpočet ortodromy ([21]). Ortodroma je z řečtiny nejkratší spojnice dvou bodů
74
KAPITOLA 4. IMPLEMENTACE
na kulové ploše a určení její délky vychází ze sférické trigonometrie. Pokud souřadnice dvou bodů jsou [φ1 ; λ1 ] a [φ2 ; λ2 ], pak se délka ortodromy spočítá podle následujícího vzorce vzdalenost = r · arccos(sin φ1 · sin φ2 + cos φ1 · cos φ2 · cos(λ2 − λ1 )) kde r je poloměr Země, tedy přibližně 6371 km, a výsledná vzdálenost pak vyjde taktéž v kilometrech. Vzdálenost se vyhodnocuje přímo při provedení databázového dotazu prostřednictvím v databázi uložené funkce vzdalenostZeSouradnic(), která jako argumenty bere šířku a délku první stanice a šířku a délku druhé stanice a jako výsledek vrací spočítanou vzdálenost. Díky tomu je možné funkci použít přímo v SQL dotazu a porovnat její výsledek s maximální vzdáleností, kterou si uživatel zvolil. 4.4.2.7
API poskytované serverem pro čtení a nahrávání údajů stanic
Server poskytuje 2 druhy API - veřejné a pro desktopové aplikace. Oba dva druhy fungují na principu metody HTTP GET, přijmou údaje a poskytnou odezvu. Veřejné API Veřejné API poskytuje ty samé údaje, které jsou dostupné v detailu vlastní nebo převzaté stanice, a to textovou formou (do budoucna je možné přidat i obrázkovou formu, ale to je už mnohem náročnější na zátěž serveru i diskové místo, pokud by tuto funkci využívalo větší množství lidí). Pro přístup k těmto údajům není potřeba být registrovaný a stačí vědět ID stanice (vlastní nebo převzaté), které je možné zjistit ze seznamů stanic. Adresa pro údaje vlastních stanic je: http://www.server.cz/mereni_stanice_vlastni.php?id_stanice=X, kde X je ID vlastní stanice. Adresa pro údaje převzatých stanic je: http://www.server.cz/mereni_stanice_prevzate.php?id_stanice=X, kde X je ID převzaté stanice. Při požadavku na tyto adresy odpoví server časem posledního měření a pak postupně posílá hodnoty naměřených údajů (každá hodnota je na novém řádku) ve formátu: nazev_veliciny: hodnota jednotka. Pokud stanice s daným ID neexisuje (nebo je to vlastní stanice, která měří pouze údaje pro vlastní potřebu majitele), pak je odeslána místo údajů chyba. API pro desktopové aplikace API pro desktopové aplikace se od veřejného liší v tom, že vyžaduje otisk uživatelského hesla a ID stanice resp. ID místa musí patřit místu resp. stanici daného uživatele. Pro uložení údajů stanice do databáze serveru slouží adresa: http://www.server.cz/uloz_mereni.php?id_stanice=ID&heslo=otisk&id_velicinyX= [IDvelicinyX]&hodnotaX=[hodnotaX],
4.4. IMPLEMENTACE VYBRANÝCH ČÁSTÍ SYSTÉMU
75
kde ID je ID dané stanice, otisk je SHA-1 otisk uživatelského hesla, X značí pořadové číslo veličiny (počítáno od jedné), ID velicinyX je ID veličiny s pořadím X a hodnotaX je hodnota veličiny X. Řetězec &id_velicinyX = [ID velicinyX]&hodnotaX = [hodnotaX] se může za sebou opakovat a X musí být v řetězci zleva doprava postupně v intervalu od 1 maximálně do 10 (v systému je zatím 10 přednastavených meteorologických veličin). Pokud bylo přijato správné ID stanice a otisk hesla a pokud daná stanice měří všechny přijímané veličiny a jejich hodnoty jsou ve správném formátu, tak jsou jednotlivé hodnoty uloženy do databáze a klientovi je odeslána zpráva OK, stanice: nazev_stanice (název stanice se posílá z toho důvodu, aby klientská aplikace mohla tento údaj zobrazit při najetí na ikonu v systémové liště). V opačném případě je klientovi odeslána chybová zpráva. Pro přečtení údajů místa slouží adresa: http://www.server.cz/nacti_mereni.php?id_mista=ID&heslo=otisk, kde ID je ID daného místa a otisk je SHA-1 otisk uživatelského hesla. Pokud bylo přijato správné ID místa a otisk hesla, tak jsou uživateli odeslány údaje meteorologické stanice (vlastní nebo převzaté podle nastavení daného místa). V opačném případě nebo pokud se vyskytla chyba při čtení údajů převzatých stanic z externího serveru je klientovi odeslána chybová zpráva. Formát odeslaných meteorologických údajů je stejný jako u veřejného API výše. Klientem u API pro desktopové aplikace nemusí být vlastní systémové aplikace, ale může to být i jakákoliv aplikace, která bude odesílat adresu (data) ve správném formátu. Tím je zajištěna další forma univerzálního použití jednotlivých komponent. 4.4.2.8
Mapy stanic
V seznamech vlastních i převzatých stanice je zobrazena interaktivní mapa České republiky se značkami, které udávají polohu jednotlivých stanic. Po kliknutí na značku se zobrazí bližší údaje o stanici a odkaz na aktuální naměřené údaje. U vlastních stanic se v okénku zobrazí i poslední změřená teplota. U převzatých stanic barva značky rozlišuje poskytovatele údajů - modře jsou stanice ČHMÚ a červeně jsou stanice Weather Underground. Ukázka mapy převzatých stanic je na obrázku 4.4. Mapa využívá API serveru Mapy.cz ([14]), které je zpřístupněno pomocí JavaScriptu při načtení stránky. Nejdříve je v konstruktoru třídy SMap předán prázdný odstavec velikosti 1000 x 575 px a souřadnice středu mapy (středu ČR). Poté je aktivována výchozí vrstva pomocí metody addDef aultLayer(SM ap.DEF _BASE).enable() vytvořeného objektu třídy SMap a přidány základní ovládací prvky pomocí addDefaultControls(). Poté je vytvořena nová vrstva pro značky (třída SMap.Layer.Marker), je přidána do mapy a aktivována pomocí metody enable(). Poté jsou v cyklu vloženy do vrstvy značky pro každou stanici. Seznam stanic je uložen v HTML prvku textarea, který je pomocí stylu skrytý. Poskytované rozhraní serveru Mapy.cz je možné volně používat pro nekomerční i komerční využití. 4.4.2.9
Uložená měření, grafy, statistiky
Uložené naměřené údaje každé stanice lze zobrazit ze seznamu stanic. Po zvolení období a veličiny se načtou příslušné statistiky, grafy a stránkovaný seznam naměřených hodnot.
76
KAPITOLA 4. IMPLEMENTACE
Obrázek 4.4: Ukázka mapy převzatých stanic
jako statistiky jsou uvedeny: poslední naměřená hodnota (a čas měření) a dále průměrná, maximální a minimální hodnota dnes, včera, před 7 dny a před 30 dny za předpokladu, že je zvoleno dnešní datum, jinak se zobrazí průměrná, maximální a minimální hodnota za zvolené období. Typ a počet grafů se řídí zvoleným obdobím. Pokud je jako období vybrán 1 den, zobrazí se spojitý denní graf průběhu hodnoty a denní graf průměrné hodnoty po hodinách. Pokud jsou zvolena dvě různá data stejného měsíce, zobrazí se měsíční graf průměrné hodnoty po dnech a měsíční graf průměrné hodnoty po dnech ve zvolené hodině. Pokud jsou jako období různé měsíce stejného roku, zobrazí se spojitý roční graf průměrné hodnoty každého dne, spojitý roční graf průměrné hodnoty ve zvolené hodině, roční graf průměrné teploty v každém měsíci a dále roční graf průměrné teploty ve zvolený den v měsíci. Pokud se liší i roky, zobrazí se meziroční graf průměrné hodnoty ve zvolený den v roce a meziroční graf průměrné hodnoty ve zvolený měsíc v roce. Ke generování grafů je použita knihovna Image Graph frameworku PEAR. Příklad grafu vývoje teploty je na obrázku 4.2. Výběr dat období lze provést kromě ručního zadání také prostřednictvím kalendáře, který se zobrazí po kliknutí na formulářová pole. Komponenta kalendáře je upravená verze kalendáře z volně šiřitelné knihovny DHTMLSuite [22]. Využívá HTML, JavaScriptu a kaskádových stylů, lze libovolně vybírat měsíce a roky a po kliknutí na zvolený den se umístí datum do komponenty, na kterou bylo kliknuto (při události onclick se zavolá metoda pickDate(this), kde se jako argument předá právě formulářový prvek, na který bylo kliknuto).
4.5. VERZOVÁNÍ ZDROJOVÉHO KÓDU
4.4.2.10
77
Export a import údajů
Ze stránky naměřených údajů lze také importovat a exportovat data měření. Exportují se údaje zvolené veličiny za zvolené období. Import dat je možný ve dvou textových formátech. U prvního z nich jsou měření ve tvaru čashodnota a jednotlivá měření jsou oddělena novým řádkem. Tento formát vytváří například aplikace pro komunikaci s měřícími stanicemi systému Meteoris. Druhý formát je klasický CSV formát, kde jako oddělovač slouží středník (měření ”čas”;”hodnota” jsou oddělena novým řádkem). K parsování obou formátů se používá pomocná třída CSV, kdy se metodě parse() předá obsah načteného souboru a oddělovač (buď tabelátor nebo středník). Pomocná třída obsahuje lepší implementaci pársování CSV než je pomocí PHP metody fgetcsv(), která se plně nedrží normy RFC 4180 a v některých případech může text špatně spársovat, oproti tomu implementace v třídě CSV tuto normu splňuje. Zdrojem je [23] a třída může být využívána bez omezení. Export dat probíhá formou textového souboru formátu CSV, kdy je jako oddělovač použit středník.
4.4.3
Logování varování a chyb
Jak na serveru tak u desktopových aplikací jsou logovány vzniklé chyby. Pokud vznikne výjimka v aplikaci, je zapsána (zalogována) do souboru. Běžný uživatel desktopových aplikací nebo administrátor serveru tak má možnost zjistit podrobnější informace, proč k výjimce došlo a zabránit opakovanému vzniku takovéto situace. Uživateli je také oznámeno přímo v aplikaci, že k výjimce došlo a podle povahy výjimky se pokračuje v běhu programu (varování) nebo se program ukončí (chyba). Pokud vznikne neočekávaná běhová (run-time) výjimka, která je způsobena chybou v programu, následovaná jeho pádem, není pochopitelně zalogována a je na uživateli, aby o ní dal vědět tvůrci aplikace, aby mohla být opravena.
4.5
Verzování zdrojového kódu
Zdrojový kód systému byl po celou dobu implementace verzován pomocí systému pro správu a verzování zdrojových kódů Subversion. Díky tomu není problém podívat se kdykoliv na předchozí verzi zdrojového kódu, např. z důvodu opravení chyby v programu, která do něj byla zanesena např. změnou jiné části programu. Vzhledem k tomu, že je plánováno poskytovat případně zdrojové kódy jednotlivých komponent systému za úplatu, byl použit neveřejný Subversion server.
4.6
Dokumentace zdrojového kódu
Zdrojový kód byl pečlivě komentován, tam kde si to situace žádala. Kromě toho byl u desktopových aplikací využit standardní dokumentační nástroj jazyka Java - Javadoc, pomocí kterého je možné vytvořit dokumentaci aplikačního programového rozhraní celé aplikace ve formátu HTML. Vygenerovaná dokumentace Javadoc pro obě desktopové aplikace systému je umístěna na přiloženém CD.
78
KAPITOLA 4. IMPLEMENTACE
Kapitola 5
Testování V této kapitole bude popsán postup a výsledky provedených testů systému.
5.1
Funkční testování
Po celou dobu vývoje aplikace bylo prováděno funkční testování jednotlivých komponent systému vždy po dokončení implementace jednotlivých dílčích funkčních celků. Tento typ testování lze popsat jako „testování šedé krabičky“ (grey box testing) [24], které stojí na pomezí mezi white a black box testováním. U white box testování má tester k dispozici použité algoritmy a zdrojový kód aplikace, to umožňuje otestovat všechny varianty reakce systému na interakci uživatele, bez toho, aby se na nějakou zapomnělo, protože tester o všech alternativách ví. Naopak to může způsobit neobjektivitu při testování, protože tester nepatří do cílové skupiny uživatelů, nebo nemusí chyby vysloveně vyhledávat a pátrat po chybově neošetřených scénářích. Black box testing uvažuje software jako černou skříňku bez znalosti vnitřní implementace. Nejčastější používané je testování podle specifikací, kdy se testuje, zda jsou plně a bezchybně splněny jednotlivé funkční požadavky. Výhodou tohoto přístup je to, že tester ví, že systém musí mít nějaké chyby a tak je různými způsoby hledá, na druhou stranu bez znalosti systému nemusí otestovat všechny možné varianty interakce s uživatelem (říká se tomu průchod bludištěm bez baterky). Grey box testování je kombinací obou přístupů, kdy tester zná (alespoň částečně) implementaci softwaru, ale testuje software jako černou skříňku a pátrá po chybách. Může dělat lépe informovaná rozhodnutí a zvolených testech, protože systému lépe rozumí. Přestože jsem systém vyvíjel sám, jsem ke své práci velmi kritický a perfekcionistický a proto si myslím, že jsem splnil tyto vlastnosti testování šedé skříňky. Všechny nalezené chyby byly odstraněny a reakce na chybné uživatelské vstupy patřičně ošetřeny a protože testování bylo důkladné, předpokládám, že se jich podařilo objevit většinu. Díky důkladnému používání všech základních metod pro odstranění bezpečnostních děr na serveru (viz 4.4.2.4) bylo také značně sníženo riziko ponechání slabého místa, které by mohlo sloužit k proniknutí záškodníka. Systém bude v budoucnu rozšířen například o diskuzní fórum, takže nebude problém, aby uživatelé nahlásili případné chyby, které sami objevili.
79
80
KAPITOLA 5. TESTOVÁNÍ
5.2
Testování použitelnosti
Otázkou je, zda systém neobsahuje také chyby návrhu grafického uživatelského rozhraní, které by způsobily, že uživateli se bude systém hůře ovládat a bude mít horší porozumění jeho funkcí. Při návrhu a implementaci bylo ale dbáno na to, aby uživatelské rozhraní bylo jednoduché, přehledné a systém se choval předvídatelně. Případné chyby tohoto charakteru by odhalilo pouze důkladné testování použitelnosti, které by ukázalo míru porozumění uživatelů systému. To je ale velmi náročné na přípravu a čas a rovněž na výběr a ochotu skutečných testovacích subjektů cílové uživatelské skupiny (obzvlášť pokud by participace nebyla za odměnu). Poznámka: V komerční praxi testování webového systému zabere několik desítek hodin práce a desítky tisíc korun. Protože GUI systému není příliš komplexní, jednotlivé jeho části mají jasný a srozumitelný význam, obsahují vysvětlivky a ovládání je rovněž kompletně popsáno v uživatelské příručce, nebude rozsáhlé uživatelské testování provedeno. K testování použitelnosti uživatelského rozhraní byla místo toho zvolena méně náročná metoda kognitivního průchodu neboli testování bez reálných uživatelů přímo vývojářem systému. Pro tento účel byly navrženy tři persony (fiktivní uživatelé systému), které budou simulovat chování většiny potenciálních uživatelů systému. Dále byly navrženy základní úkoly a jejich správný průchod, který byl poté odsimulován kognitivním průchodem podle scénářů. Při každém průběhu bylo odpovězeno na otázky: • Ví uživatel, kde v aplikaci se nachází, jak se tam dostal a jak má pokračovat dál pro dosažení daného cíle? • Je akce nutná k dalšímu kroku dosažitelná a dobře viditelná? • Použil by tuto akci pro postup k dalšímu kroku? • Dozví se uživatel po provedení akce, že akce správně proběhla? Odpovědi na otázky jsou typu ano, spíše ano, spíše ne a ne.
5.2.1
Persony
Persona představuje typického uživatele systému, který systém používá s určitým úmyslem a cílem. Persony byly navrženy tak, aby pokryly různé možnosti práce se systémem a jeho funkčnost. Registrovaný uživatel - Karel Karel je muž středního věku a pracuje jako učitel zeměpisu na základní škole. Má vysokoškolské pedagogické vzdělání. Jeho uživatelské znalosti ovládání počítače a webového prohlížeče jsou na základní uživatelské úrovni. Karel měl by rád přehled o vývoji počasí (aktuálním i v minulosti) ve svém bydlišti na okraji malé obce v Krkonoších, ale nejbližší stanice ČHMÚ je 25 km daleko a on nemá k dispozici poloprofesionální stanici ani prostředky, aby si ji koupil.
5.2. TESTOVÁNÍ POUŽITELNOSTI
81
Registrovaný uživatel - Petr Petr je 25-letý muž a pracuje jako správce datacentra v Praze. Vystudoval střední průmyslovou školu se zaměřením na počítačové sítě. Protože to je v jeho zaměstnání nutné, jeho znalosti ovládání počítače jsou na vysoké úrovni. Petr by rád měřil teplotu v serverovnách datacentra. Přitom by chtěl mít údaje o teplotě v místnostech k dispozici ve své kanceláři a být upozorněn při překročení teploty, kdyby náhodou vypadla klimatizace. Nedostal ale od šéfa dostatek peněz na nákup profesionálních čidel. Neregistrovaný uživatel - Jana Jana je studentka vyšší odborné školy uměleckého zaměření a bydlí v Čáslavi. Předtím než půjde do města, by chtěla vědět, jaká je venku teplota, aby se podle toho mohla obléknout. Předpovedi počasí považuje za nespolehlivé a teploměr jí je k ničemu, protože má všechna okna na jih a svítí na ně většinu dne slunce. Jana má dobré uživatelské znalosti počítače a webového prohlížeče.
5.2.2
Ukázka kognitivního průchodu
Protože úkoly prováděné uživately jsou poměrně podobné a jednoduché, nebudou zde všechny scénáře podrobně popsány a bude zde pouze uvedena ukázka, jak takový testovací kognitivní průchod vypadá. Následuje ukázku průchodu kognitivního testování persony Jana, která chce zjistit jaké je aktuální počasí v jejím městě. V každém kroku bylo odpovězeno na otázky: • Ví uživatel, kde v aplikaci se nachází, jak se tam dostal a jak má pokračovat dál pro dosažení daného cíle? • Je akce nutná k dalšímu kroku dosažitelná a dobře viditelná? • Použil by tuto akci pro postup k dalšímu kroku? • Dozví se uživatel po provedení akce, že akce správně proběhla? Odpovědi mohly být ano, spíše ano, spíše ne a ne. Testovací scénář - Jana Jana dostala tip od kamarádky na stránky systému s tím, že tam je možné zjistit aktuální údaje o počasí ve všech větších městech v republice. Úkol: Zjistit jaké je počasí v jejím městě. Sled kroků pro dosažení cíle: Zde je uveden správný sled kroků pro dosažení cíle.
82
KAPITOLA 5. TESTOVÁNÍ
Zobrazení stránky s údaji stanice blízko místu mého bydliště 1. (Uživatel načte stránku systému v prohlížeči.) 2. Přečte si, že pro zobrazení aktuálního počasí ve svém město má zvolit Seznam vlastních stanic nebo Seznam převzatých stanic. 3. V menu zvolí odkaz Seznam vlastních stanic. 4. Na mapě najde své město a vidí jaké jsou stanice v jeho okolí. 5. Pokud neexistuje stanice blízko jejímu bydlišti, zkusí odkaz Seznam převzatých stanic a v něm opět najde své město a vidí stanice v blízkosti. 6. V některém ze seznamů si na mapě vybere stanici blízko jeho města a klikne na její značku. 7. Zvolí odkaz pro zobrazení aktuálních měření této stanice. 8. Načte se stránka s požadovanými údaji. Průchod testovacím scénářem Jana si přete pokyny na hlavní stránce (obrázek 5.1) a vidí, že musí zvolit Seznam vlastních stanic nebo Seznam převzatých stanic. Stanoví si tedy správný cíl a ví jak ho dosáhnout.
Obrázek 5.1: Testování použitelnosti - Hlavní stránka systému
Jana vidí seznam stanic a v něm na první pohled najde město Čáslav (své bydliště) a klikne na značku stanice poblíž (obrázek 5.2). Jana je orientovaná a ví jak má postupovat dále.
5.2. TESTOVÁNÍ POUŽITELNOSTI
83
Obrázek 5.2: Testování použitelnosti - Seznam převzatých stanic s mapou
Jana zvolí odkaz pro zobrazení aktuálních měření této stanice a v novém okně se jí načte stránka s údaji (obrázek 5.3). Jana dosáhla svého cíle a zjistila údaje o počasí ve svém městě. Během těchto několika kroků neměla vůbec žádný problém.
Obrázek 5.3: Testování použitelnosti - Údaje převzaté stanice
84
5.2.3
KAPITOLA 5. TESTOVÁNÍ
Zhodnocení testování kognitivním průchodem
Po vytvoření plně funkční verze systému byl systém otestován z pohledu každé persony metodou kognitivního průchodu. Pokaždé byl zvolen scénář použití systému typický pro danou personu. Ani v jednom případě testování nebyly nalezeny žádné závažné nedostatky, které by omezovaly použitelnost systému, uživatelé se snadno orientovali a věděli jak dosáhnout požadovaného cíle, případně konzultovali uživatelskou příručku, aby se ujistili, že akce kterou chtějí provést je správná. Provedené kognitivní testování považuji pro tento typ projektu s vizuálně nepříliš komplexními komponentami za dostatečné.
5.3
Dlouhodobé testování v ostrém provozu
Systém byl provozován několik měsíců v ostrém provozu. Server přijímal data od aplikace pro komunikaci s testovacím teplotním čidlem Papouch TM a poskytoval je několika aplikacím pro zobrazování meteorologických údajů uživatelů v mém okolí. Tím byla důkladně otestována dlouhodobá spolehlivá spolupráce všech tří komponent systému a nebyly odhaleny žádné chyby. Na grafu 5.4 je ukázka průměrných naměřených hodnot teploty během měsíce dubna 2011 z testovacího čidla Papouch TM na stanici Labská louka v Hradci Králové.
Obrázek 5.4: Měsíční graf naměřené teploty na stanici Labská louka
Kapitola 6
Závěr Systém pro sběr a distribuci meteorologických údajů byl úspěšně navržen, implementován a otestován. Implementaci předcházela důkladná analýza. Splněny byly všechny požadavky na něj kladené v souladu se zadáním diplomové práce a byly implementovány také některé dodatečné funkce. Analýzou možností měření teploty pomocí počítače bylo vybráno vhodné měřící čidlo, které je přesné a levné, a bylo implementováno čtení jeho údajů. Protože poloprofesionální měřící stanice jsou poměrně drahé, nebyla v současné verzi systému implementována jejich podpora, ale přesto byl systém navržen dostatečně obecně, aby tomu bylo možné v budoucnu. Aby systém mohl poskytovat údaje o počasí také v začátcích, kdy v něm bude registrováno málo klientských stanic, bylo implementováno přebírání meteorologických údajů ze dvou spolehlivých meteorologických serverů a externími měřícími stanicemi je tak pokryta většina České republiky. Podle provedené rešerše neexistují zatím systémy s obdobnou funkcí, pouze částečně se jí mohou blížit. V tom vidím mezeru na trhu, kterou by mohl mnou navržený systém zaplnit. Systém je možné nasadit a používat v ostrém provozu a to také bude provedeno. Zda ho začnou uživatelé a případně firemní zákazníci opravdu používat, je otázkou budoucnosti a šikovné propagace.
6.1
Budoucí vývoj systému
Systém obdobného rozsahu lze vyvíjet prakticky neustále a pořád bude nějaká funkcionalita, kterou bude stát za to přidat. V následujícím seznamu je uvedeno několik takových zajímavých funkcí: • Implementovat komunikační protokol dalších čidel a měřících stanic. • Aplikace pro komunikaci s čidly by mohla číst údaje ze souboru, do kterého periodicky zapisuje jiná aplikace čtoucí data z poloprofesionální meteostanice. Tím by se nechala řešit složitější implementace komunikačního protokolu nebo uzavřený protokol. • Zanést naměřené údaje ze stanic do mapy, například u teploty by byla vytvořena barevná teplotní mapa.
85
86
KAPITOLA 6. ZÁVĚR
• Implementovat odeslání emailu při spuštění alarmu, GUI aplikací je na to už připraveno. Také by bylo možné při dosažení nastavené teploty odesílat emaily i ze serveru. • Do API pro poskytování údajů stanic přidat možnost poskytnutí obrázku s aktuálními údaji. • Přidat další možnosti exportu dat, ve formě HTML nebo PDF. • Přidat diskuzní fórum, které by mimo jiné umožnilo zpětnou vazbu od uživatelů, návrhy na nové externí stanice a označení stávajících za neaktivní, upozornění na chyby v systému. • Přidat externí stanice i z dalších států, například Slovenska. • Přidat do administrační sekce správu převzatých stanic (nyní jsou nutné zásahy do databáze). • Vytvořit plugin do Windows 7, který umožní obdobnou funkčnost jako aplikace zobrazující údaje. • Přidat sekci s předpovědí počasí na příští dny pro daný region, údaje a grafy mohou být převzaty například z webu ČHMÚ. • Napsat rady a tipy pro výběr vhodného měřícího čidla nebo stanice, jeho umístění venku, připojení k počítači atp. • Prozkoumat blíže možnosti připojení čidla k „chytrému“ mobilnímu telefonu (s operačním systémem Windows Mobile nebo Android). Tyto funkce se většinou týkají nekomerčního využití a byly by naprogramovány zdarma. Je zde ale také možnost úpravy některé z částí systému na zakázku a implementování firmou požadované funkcionality, nebo případně rovnou prodej zdrojového kódu. Současná implementace všech komponent je více než dostatečná pro předvedení funkčnosti zákazníkovi. Jak je vidět, možnosti budoucího rozvoje systému, který vznikl jako součást této diplomové práce, jsou obrovské a ukáže až čas, jakým směrem se jeho život bude ubírat.
[14] Mapy.cz. Mapy České republiky [online]. [cit. 20.4.2011]. Dostupné z: http://www.mapy.cz. [15] Weather Underground, Inc. Weather Underground: Personal Weather Stations [online]. [cit. 21.4.2011]. Dostupné z: http://www.wunderground.com/weatherstation/. [16] Tůma Pavel. Odkazy na jiné meteorologické stanice v ČR [online]. [cit. 21.4.2011]. Dostupné z: http://meteo.amut.net/odkazy.php. [17] Přispěvatelé Wikipedie. Model–view–controller [online]. [cit. 10.5.2011]. Dostupné z: http://cs.wikipedia.org/wiki/Model-view-controller. [18] Stěhule Pavel. Rozdíly mezi MySQL a PostgreSQL [online]. [cit. 8.5.2011]. Dostupné z: http://www.root.cz/clanky/postgresql-9-1-aneb-stale-vpred/nazory/ 382492/. [19] The PHP Group. PEAR - PHP Extension and Application Repository [online]. [cit. 10.5.2011]. Dostupné z: http://pear.php.net. [20] New Digital Group, Inc. PEAR - PHP Extension and Application Repository [online]. [cit. 10.5.2011]. Dostupné z: http://www.smarty.net. [21] Přispěvatelé Wikipedie. Ortodroma [online]. [cit. 11.5.2011]. Dostupné z: http://cs.wikipedia.org/wiki/Ortodroma. [22] Kalleland Alf Magne. DHTML Goodies [online]. [cit. 7.3.2011]. Dostupné z: http://www.dhtmlgoodies.com. [23] Blogger Thue. CSV parser [online]. [cit. 2.3.2011]. Dostupné z: http://thuejk.blogspot.com/2010_01_01_archive.html. [24] Přispěvatelé Wikipedie. Software testing [online]. [cit. 11.5.2011]. Dostupné z: http://en.wikipedia.org/wiki/Software_testing.
Příloha A
Seznam použitých zkratek AJAX Asynchronous JavaScript and XML API Application Programming Interface ASCII American Standard Code for Information Interchange CWOP Citizen Weather Observer Program CSS Cascading Style Sheets CRUD Create, Read, Update, Delete CSV Comma Separated Values ČHMÚ Česhý hydrometeorologický ústav DBMS Database Management System DOM Document Object Model DOS Denial of Service GPL GNU General Public License GUI Graphical User Interface HID Human Interface Device HTML HyperText Markup Language HTTP HyperText Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IDE Integrated Development Environment JDK Java Development Kit JRE Java Runtime Environment
89
90
PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK
JVM Java Virtual Machine LGPL GNU Lesser General Public License OS Operační systém PCM Pulse-Code Modulation PEAR PHP Extension and Application Repository PHP Hypertext Preprocessor SJAX Synchronous JavaScript and XML SQL Structured Query Language SMS Short Message Service SMTP Simple Mail Transfer Protocol SSL Secure Sockets Layer TXT TeXT UART Universal Asynchronous Receiver/Transmitter UML Unified Modeling Language URL Uniform Resource Locator USB Universal Serial Bus WU Weather Underground WAV Waveform Audio File Format WWW World Wide Web XHTML eXtensible HyperText Markup Language XML eXtensible Markup Language XSS Cross-Site Scripting
Příloha B
Slovník Atmosféra je plynný obal tělesa, v našem případě Země. Skládá se ze 78% dusíku, 21% kyslíku a dalších stopových prvků. Poskytuje kyslík pro dýchání a chrání život na Zemi před vesmírnou radiací. Rozpíná se do vzdálenosti přibližně 50 tisíc kilometrů od povrchu. Autentizace je proces ověření identity uživatele. Autorizace je akce, jíž se ověřuje, jestli má uživatel práva k provedení určité činnosti. Cache je dočasná paměť, do které se ukládají použité položky, protože se předpokládá, že budou brzy znovu použity (princip časové lokality). Přístup do cache je obvykle mnohem rychlejší než přístup do hlavní paměti a proto pokud je položka v cache nalezena, dojde ke značné úspoře času. Databázová transakce je operace nad databázovými daty, která má následující vlastnosti: provede se buď celá nebo vůbec (atomicita); poté, co se provede, bude databáze obsahovat pouze platná data (konzistence); různé transakce o sobě navzájem neví a nevidí data zpracovávaná jinou transakcí (izolovanost); změny provedené v databázi jsou trvalé a nemohou být ztraceny (persistence). Freeware je software poskytovaný zdarma. Geostacionární oběžná dráha je taková dráha, při níž se družice zdá být stále na stejném místě na obloze. Družice se musí pohybovat nad rovníkem stejnou úhlovou rychlostí jako se Země otáčí a musí být ve výšce 35 800 km. Hacker bylo dříve označení pro počítačového odborníka, nyní je toto označení užíváno pro osobu nabourávající se do počítačových systémů. Nejčastějším cílem je poukázat na jejich špatné zabezpečení nebo v mnohem horším případě získat tajné údaje, peníze nebo prostředky k jejich nabytí (např. čísla kreditních karet). HTML tag je značka v jazyce HTML, který se používá k návrhu webových stránek. Značky jsou buď párové (např.
a
, což je odstavec), kdy je vždy otevírací a uzavírací značka, nebo nepárové (např. , což je nový řádek). Jazyk HTML je podmnožinou obecného značkovacího jazyka XML.
91
92
PŘÍLOHA B. SLOVNÍK
Java Virtual Machine (JVM) je virtuální prostředí pro běh programů napsaných v jazyce Java, využívá model virtuálního stroje pro interpretaci a vykonávání počítačových programů v jazyce Java. Look & Feel je pojem používaný k popisu grafického uživatelského rozhraní (GUI). Look znamená vzhled a rozmístění ovládacích prvků a Fell jejich chování vzhledem k činnostem uživatele. Meteorologie je věda zabývající se zkoumáním všech jevů probíhajících v atmosféře. Slovo meteorologie pochází z řeckého meteoros (vznášející se ve výši) a logia (nauka). Model-View-Controller je softwarová architektura, která rozděluje uživatelské rozhraní aplikace, její datový model a řídící logiku do tří nezávislých komponent. Změna některé komponenty má tak minimální vliv na ostatní komponenty. Model je reprezentací dat, View (pohled) transformuje data poskytovaná modelem do podoby vhodné k prezentaci uživateli, Controller (řadič) reaguje na události od uživatele a zajišťuje provedení změny v modelu a pohledu. Tato architektura je označována také jako Model-2. Existuje ještě varianta Model-1, kdy je uživatelské rozhraní s řídící logikou sloučeno. Open source je počítačový software s otevřeným zdrojovým kódem. Slovem otevřenost je myšleno, že autor veřejně poskytuje zdrojový kód a licence softwaru, pokud jsou dodrženy podmínky, tak umožňuje uživatelům zdrojový kód využívat, například prohlížet, upravovat, kompilovat a dále poskytovat. Opakem je uzavřený zdrojový kód, který není veřejně poskytován nebo je poskytován za úplatu. Psychometrická budka se používá k ochránění měřících čidel od vlivu slunečního záření. Je to bíle natřená dřevěná skříň s žaluziemi umožňujícími volné proudění vzduchu, ale zabraňujícími přímému osvitu. Dno budky je volné a umístěné ve výšce 180 cm. Viz. obrázek 2.5. Reflexe (nebo také typová introspekce) umožňuje objektu zkoumat a modifikovat svoji strukturu. Objekt tak může například zjistit názvy a hodnoty svých proměnných, jméno své třídy a její předky, zjistit názevy metod a zavolat je. Reflexe může být readonly (pouze pro čtení), kdy lze zjistit pouze hodnoty elementů, nebo může být plná, kdy je možné i elementy (proměnné, metody ale i třídy) přidávat, měnit jejich názvy nebo hodnoty atp. Read-only reflexi umožňuje například jazyk Java. Plnou reflexi umí např. jazyk Smalltalk. Většina moderních jazyků umožňuje nějakou formu reflexe. Synoptické mapy jsou mapy zachycující různé meteorologické prvky, např. frontální systém, tlakové níže a výše, izobary (čáry spojující místa stejného tlaku) a další. Synoptický znamená „sestavující a přehlížející současně různé paralelní jevy“. Systém řízení báze dat (Database Management System - DBMS) je modul zapouzdřující ukládání dat a nabízející rozhraní pro další aplikace, které tato data mohou využívat.
Příloha C
UML diagramy V této části jsou uvedeny vybrané UML diagramy, které nebyly zařazeny do hlavní části práce z důvodu přehlednosti.
Obrázek C.9: Diagram aktivit - Přidání místa k odběru údajů
101
102
C.4
PŘÍLOHA C. UML DIAGRAMY
Schéma relační databáze
Obrázek C.10: Schéma relační databáze
Příloha D
Grafické uživatelské rozhraní V této příloze je několik ukázek grafického uživatelského rozhraní jednotlivých komponent a částí systému.
Obrázek D.1: Server - Hlavní stránka
103
104
PŘÍLOHA D. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
Obrázek D.2: Server - Seznam převzatých stanic
105
Obrázek D.3: Server - Přidání stanice
106
PŘÍLOHA D. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
Obrázek D.4: Server - Seznam mých stanic
107
Obrázek D.5: Server - Přidání místa
108
PŘÍLOHA D. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
Obrázek D.6: Server - Detail převzaté stanice s daty
109
Obrázek D.7: Server - Naměřené hodnoty a statistiky
110
PŘÍLOHA D. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
Obrázek D.8: Server - Grafy 1
111
Obrázek D.9: Server - Grafy 2
112
PŘÍLOHA D. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
Obrázek D.10: Měřící aplikace - hlavní okno
Obrázek D.11: Měřící aplikace - nastavení ukládání do souboru a odesílání na server
113
Obrázek D.12: Měřící aplikace - nastavení alarmů
114
PŘÍLOHA D. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
Obrázek D.13: Aplikace zobrazující údaje - hlavní okno
Obrázek D.14: Aplikace zobrazující údaje - spuštěný alarm
Příloha E
Uživatelská příručka Systém pro sběr a distribuci meteorologických údajů (Systém Meteoris) autor: Dominik Mervart email: [email protected], [email protected] květen 2011, verze 1.0
E.1
Příručka centrální části
1. Úvod Tato uživatelská příručka je určena uživatelům Centrální serverové části systému Meteoris a obsahuje rady a postupy pro její ovládání.
2. Popis aplikace Server Meteoris se zabývá sběrem a distribucí meteorologických údajů přijatých z klientských měřících stanic a poskytováním údajů převzatých z externích stanic. Funkce serveru: • na serveru jsou volně dostupné seznamy vlastních a převzatých stanic (profesionální stanice ČHMÚ a poloprofesionální klientské stanice odesílající data na Weather Underground) • uživatelé mohou volně zobrazit naměřené údaje vlastních stanic a údaje převzatých stanic • registrovaný uživatel může přidávat do systému své klientské stanice
115
116
PŘÍLOHA E. UŽIVATELSKÁ PŘÍRUČKA
• vlastní stanice může být pro vlastní potřebu jejího majitele a pak její data nejsou zobrazena nikomu jinému • z naměřených údajů jsou spočítány statistiky (průměr, minimum, maximum) a vytvořeny různé druhy grafů • lze naimportovat data ke své stanici (stejný formát jako ukládá aplikace Meteoris Čidlo nebo klasický CSV) • lze exportovat uložená data ve formátu CSV • registrovaný uživatel může přidat do systému místa, ze kterých chce přijímat meteorologické údaje (např. pomocí aplikace Meteoris - Údaje) Vlastnosti serveru: • hesla jsou v databázi uložena šifrovaně pomocí SHA-1, nelze je zpětně rekonstruovat • naměřená data ze stanic jsou uchovávána po neomezenou dobu Požadavky na počítač uživatele: • některý z běžně používaných webových prohlížečů (Firefox 4, IE9, Opera, Chrome)
3. Registrace do systému Registrovat se do systému není povinné ani nutné, pokud uživatel chce pouze využít webu ke zjištění údajů klientských stanic odesílajících údaje na server nebo údaje převzatých meteorologických stanic (viz body 4.1. a 4.2.). Pokud uživatel chce využít aplikací Meteoris - Čidlo nebo Meteoris - Údaje, např. k nahrávání dat z vlastního počítače na server nebo přijímání dat do svého počítače, pak se musí registrovat. K registrace stačí zvolit odkaz z menu, vyplnit přihlašovací jméno, heslo a jednoduchou antispamovou kontrolní otázku, potvrdit a v tom okamžiku je uživatel registrován. Poté se stačí pro využívání funkcí registrovaného uživatele jen kdykoliv přihlásit. Uživatel zůstane trvale přihlášen, dokud se neodhlásí.
4. Práce se serverem 4.1. Veřejný seznam vlastních stanic a jejich měření Tento seznam je dostupný z menu volbou Seznam vlastních stanic. Zobrazí se seznam všech stanic registrovaných v systému (kromě stanic, které mají nastavenu volbu pouze pro vlastní potřebu) a také mapa, na které jsou stanice podle své polohy umístěny. Po kliknutí na značku se zobrazí teplota v dané lokalitě a odkaz vedoucí na stránku s aktuálními naměřenými daty, statistikami a grafy.
E.1. PŘÍRUČKA CENTRÁLNÍ ČÁSTI
117
4.2. Veřejný seznam převzatých stanic a jejich měření Tento seznam je dostupný z menu volbou Seznam převzatých stanic. Zobrazí se seznam stanic, jejichž údaje jsou přebírány buď z ČHMÚ (modrá barva) nebo z Weather Underground (červená barva), kam nahrávají svá měření poloprofesionální stanice meteorologů-amatérů. Zobrazí se také mapa, na které jsou stanice podle své polohy umístěny. Po kliknutí na značku se zobrazí informace o stanici a odkaz vedoucí na stránku systému s aktuálními převzatými daty. Stanice ČHMÚ jsou profesionální stanice Českého hydrometeorologického ústavu a jejich přesné údaje slouží mimojiné pro výpočet předpovědí počasí. 4.3. Klientské vlastní stanice Registrovaný uživatel, který má meteorologickou stanici může nahrávat její data na server. K tomu může buď využít aplikaci Meteoris - Čidlo nebo nastavit svoji vlastní aplikaci tak, aby odesílala údaje ve formátu, který přijímá API serveru. Uživatel musí nejdříve přidat v systému svoji stanici, vyplnit několik údajů jako např. souřadnice a poté může použít ID stanice při komunikaci se serverem. Pokud uživatel nechce, aby byly údaje poskytovány a zobrazeny dalším uživatelům systému, musí zvolit, že stanice je pro vlastní potřebu. To je vhodné pokud jde např. o měření teploty v interiéru nebo stanice není momentálně aktivní atp. API serveru pro přijímání naměřených dat ze stanice je popsáno dále. Pro uložení údajů stanice do databáze serveru slouží adresa: http://www.server.cz/uloz_mereni.php?id_stanice=ID&heslo=otisk&id_velicinyX= [IDvelicinyX]&hodnotaX=[hodnotaX] kde ID je ID dané stanice, otisk je SHA-1 otisk uživatelského hesla, X značí pořadové číslo veličiny (počítáno od jedné), ID velicinyX je ID veličiny s pořadím X a hodnotaX je hodnota veličiny X. Řetězec &id_velicinyX = [ID velicinyX]&hodnotaX = [hodnotaX] se může za sebou opakovat a X musí být v řetězci zleva doprava postupně v intervalu od 1 maximálně do 10 (v systému je zatím 10 přednastavených meteorologických veličin). Pokud bylo přijato správné ID stanice a otisk hesla a pokud daná stanice měří všechny přijímané veličiny a jejich hodnoty jsou ve správném formátu, tak jsou jednotlivé hodnoty uloženy do databáze a klientovi je odeslána zpráva OK, stanice: nazev_stanice (název stanice se posílá z toho důvodu, aby klientská aplikace mohla tento údaj zobrazit při najetí na ikonu v systémové liště). V opačném případě je klientovi odeslána chybová zpráva. 4.4. Naměřená data Uložené naměřené údaje každé stanice lze zobrazit ze seznamu stanic. Po zvolení období a veličiny se načtou příslušné statistiky, grafy a stránkovaný seznam naměřených hodnot. jako statistiky jsou uvedeny: poslední naměřená hodnota (a čas měření) a dále průměrná, maximální a minimální hodnota dnes, včera, před 7 dny a před 30 dny za předpokladu, že je zvoleno dnešní datum, jinak se zobrazí průměrná, maximální a minimální hodnota za zvolené období.
118
PŘÍLOHA E. UŽIVATELSKÁ PŘÍRUČKA
4.5. Import a export dat Ze stránky naměřených údajů lze také importovat a exportovat data měření. Formát importního souboru je taktéž popsán na stránce naměřených údajů. Exportují se údaje zvolené veličiny za zvolené období. Export dat probíhá formou textového souboru formátu CSV, kdy je jako oddělovač použit středník. 4.6. Příjem meteorologických údajů ze serveru Pokud chce uživatel přijímat meteorologické údaje stanic (vlastních i převzatých) přímo do svého počítače, musí si přidat „místo“, kde zvolí mimojiné data z jaké stanice chce přijímat. ID místa pak vyplní v aplikaci Meteoris - Údaje. Případně může také využít API serveru pro poskytování údajů a to buď API pro místa ve formátu: Pro přečtení údajů místa slouží adresa: http://www.server.cz/nacti_mereni.php?id_mista=ID&heslo=otisk, kde ID je ID daného místa a otisk je SHA-1 otisk uživatelského hesla. Pokud bylo přijato správné ID místa a otisk hesla, tak jsou uživateli odeslány údaje meteorologické stanice (vlastní nebo převzaté podle nastavení daného místa). V opačném případě nebo pokud se vyskytla chyba při čtení údajů převzatých stanic z externího serveru je klientovi odeslána chybová zpráva. Formát odeslaných meteorologických údajů je stejný jako u veřejného API výše. nebo může použít veřejné API: Adresa pro údaje vlastních stanic je: http://www.server.cz/mereni_stanice_vlastni.php?id_stanice=X, kde X je ID vlastní stanice. Adresa pro údaje převzatých stanic je: http://www.server.cz/mereni_stanice_prevzate.php?id_stanice=X, kde X je ID převzaté stanice. Při požadavku na tyto adresy odpoví server časem posledního měření a pak postupně posílá hodnoty naměřených údajů (každá hodnota je na novém řádku) ve formátu: nazev_veliciny: hodnota jednotka. Pokud stanice s daným ID neexisuje (nebo je to vlastní stanice, která měří pouze údaje pro vlastní potřebu majitele), pak je odeslána místo údajů chyba. 4.7. Změna registračních údajů Registrační údaje včetně hesla může uživatel změnit v menu Moje údaje. 4.8. Zobrazení nápovědy Tuto uživatelskou příručku je na serveru možné zobrazit v menu Funkce a výhody.
E.2. PŘÍRUČKA APLIKACE PRO KOMUNIKACI S MĚŘÍCÍMI STANICEMI
E.2
119
Příručka aplikace pro komunikaci s měřícími stanicemi
1. Úvod Tato uživatelská příručka je určena uživatelům aplikace Meteoris - Čidlo a obsahuje rady a postupy pro její ovládání. Aplikace smí být volně šířena.
2. Popis aplikace Aplikace je součástí systému Meteoris, který se zabývá sběrem a distribucí meteorologických údajů přijatých z klientských měřících stanic a také poskytováním údajů převzatých z externích stanic. Tato aplikace primárně slouží pro komunikaci s uživatelskými měřícími stanicemi a odesílání naměřených hodnot na server Meteoris. Funkce aplikace: • čtení a zobrazení údajů z meteostanice připojené k počítači uživatele • pracuje i samostatně, bez využití funkcí serveru • odesílání údajů na server • ukládání změřených údajů do souboru • 3 nastavitelné alarmy - upozorní při překročení teploty grafickou a zvukovou formou (plánuje se i odeslání emailu) • v současné době je podporováno čtení z čidel: teplotní čidla Papouch TM (RS-232) a TMU (USB) Vlastnosti aplikace: • aplikace je multiplatformní - funguje pod operačními systémy Microsoft Windows, Linux, Solaris, Mac OS X • aplikace se nemusí instalovat, stačí ji spustit, nevyžaduje žádnou dodatečnou konfiguraci systému ani údržbu • složku s aplikací je možné libovolně přemisťovat v rámci počítače i mezi počítači (pouze je nutné dbát na to, aby byly přesunuty všechny soubory a složky) Požadavky na počítač uživatele: • výkon počítače: běžný kancelářský počítač vyrobený po roce 2000 • operační systém: Microsoft Windows 2000, XP, Vista, 7, Linux, Solaris, Mac OS X • dostupný příslušný hardwarový port - COM (nebo redukce na USB), USB • nainstalované Java Runtime Environment verze 6 (možno stáhnout zde: http://www.oracle.com/technetwork/java/javase/downloads/index.html)
120
PŘÍLOHA E. UŽIVATELSKÁ PŘÍRUČKA
3. Práce s aplikací 3.1. Spuštění aplikace Aplikace je distribuována v archivu RAR. Rozbalte ji nejdříve do libovolné složky některým z běžných archivačních programů (WinRAR, WinZip, Unrar). Aplikace vyžaduje pro svůj běh nainstalované Java Runtime Environment (JRE). Pokud je JRE správně nainstalováno, stačí spustit aplikaci poklepáním na spouštěcí soubor MeteorisCidlo.jar v hlavním adresáři aplikace. Pokud se nepodaří aplikaci takto spustit, je třeba otevřít příkazový řádek, (ve Windows: Start - Spustit - cmd.exe) a spustit aplikaci příkazem: java -jar cesta/MeteorisCidlo.jar případně cesta_k_JRE/java -jar cesta/MeteorisCidlo.jar Aplikace nevyžaduje instalaci ani jinou konfiguraci v systému. V případě vzniku chyby nebo varování je podrobnější informace zapsána do logovacího souboru cesta/log.txt. 3.2. Čtení údajů z čidla V současnosti je podporováno pouze čtení teploty z čidel Papouch TM (RS-232) a TMU (USB). Doporučuji použít levnější RS-232 variantu a pokud na PC není COM port, tak použít RS-232 -> USB redukci, která vytvoří v PC uživatele virtuální COM port. Cena verze RS-232 je 500 Kč, cena redukce je kolem 200 Kč. Tedy žádná drahá záležitost. Na hlavní obrazovce jsou napsány dostupné volné porty v systému. Před zahájením čtení údajů z čidel je nutno zvolit typ čidla v menu Nastavení -> Nastavení čidla. Zde je možné také nastavit interval čtení údajů z čidla. Po výběru čidla a jeho portu je možné zahájit čtení údajů z čidla (musí být připojeno k počítači). 3.3. Ukládání do souboru V menu Nastavení -> Nastavení ukládání je možné zvolit název souboru, do kterého chcete načtené údaje ukládat. Lze také zvolit interval ukládání a to, zda se má pro každý den použít nový soubor. 3.4. Odesílání na server Nastavení odesílání na server je v menu Nastavení -> Nastavení ukládání. Jako server lze použít libovolný server, formát adresy je možné změnit. U serveru Meteoris je adresa včetně parametrů předvyplněna a stačí vyplnit ID stanice (viz seznam mých stanic na serveru Meteoris) a uživatelské heslo. U serveru Meteoris je heslo odesíláno zašifrované jako otisk SHA-1. Interval odesílání je doporučen alespoň 5 minut. Na vytvoření grafů ale stačí i 15 minut nebo 20 minut.
E.2. PŘÍRUČKA APLIKACE PRO KOMUNIKACI S MĚŘÍCÍMI STANICEMI
121
3.5. Alarmy V menu Nastavení -> Nastavení upozornění lze nastavit až 3 typy alarmů. Lze definovat teplotu při jejímž překročení se alarm spustí a také zda jde o překročení přes nebo pod nastavenou teplotu (vzestup či pokles teploty). Při spuštění alarmu lze přehrát zvuk (každý alarm má jiný) a tento zvuk je možné nechat nekonečně opakovat. 3.6. Odeslání emailu při alarmu Tato funkčnost zatím není implementována, ale je plánována v budoucnu. K odeslání emailu bude možné využít externí poštovní SMTP server (např. G-mail). Bude podporován také šifrovaný režim pomocí SSL. 3.7. Minimalizace aplikace Aplikace se standardně minimalizuje do systémové lišty. Při měření je teplota zobrazena při najetí myší na ikonu v systémové liště (není nutné okno otevírat). Minimalizaci do systémové lišty je možné změnit v menu Nastavení -> Nastavení aplikace. 3.8. Zobrazení nápovědy Tuto uživatelskou příručku je v programu možné zobrazit v menu Nápověda -> Uživatelská příručka nebo stisknutím klávesy F1.
4. Chybová hlášení Pokud dojde v aplikaci k závažné chybě a nelze pokračovat v běhu programu, je zobrazeno okno o tom, že se stala chyba, podrobnější informace je zapsána do logovacího souboru cesta/log.txt a aplikace je ukončena. Pokud není chyba závažná, je pouze zobrazena informace o chybě a je zapsána do logu jako varování, ale program není ukončen. Pokud vznikne neočekávaná běhová (run-time) výjimka způsobená chybou v programu, není zalogována a je na uživateli, aby o ní a okolnostech jejího vzniku dal vědět tvůrci aplikace, aby mohla být opravena. Možné chybové zprávy a jejich řešení: Nebyly nalezeny žádné volné RS-232 porty. Tato chyba se objeví, pokud nebyly nalezeny žádná volné RS-232 porty. Buď není žádný COM port v počítači nebo je už obsazen (např. aplikace už byla spuštěna a měří). Došlo k chybě při měření teploty. Ujistěte se prosím, že je teploměr připojen a nepracuje s ním už jiná aplikace. Také je možné, že čidlo dodalo vadná data (u Papouch TM se stane přibližně jednou za týden, lze směle ignorovat). Došlo k chybě při odesílání teploty na server. Teplota nebyla odeslána na server, chyba je blíže specifikována. Je možné, že jde o dočasný výpadek serveru nebo byla chybně uvedena adresa serveru.
122
PŘÍLOHA E. UŽIVATELSKÁ PŘÍRUČKA
Nelze přidat ikonu do systémové lišty. Váš systém nemá systémovou lištu, nemůžete tudíž tuto funkčnost využívat. Nelze nastavit Look & Feel. Požadovaný vzhled není v této verzi Java Runtime Environment podporován, nainstalujte si prosím aktuální verzi JRE. Nelze číst/zapisovat z nebo do souboru. Nemáte přístupová práva ke čtení nebo zápisu do tohoto souboru nebo je název souboru neplatný. Změňte cestu nebo název souboru. Nelze načíst dokument z JAR archivu. Spouštěcí soubor aplikace byl poškozen, nahraďte ho prosím originálním souborem. Nelze spočítat otisk řetězce hešovací funkcí SHA-1. Hešovací funkce SHA-1 není v této verzi Java Runtime Environment podporována, nainstalujte si prosím aktuální verzi JRE. Bez této funkce nebude aplikace fungovat.
E.3
Příručka aplikace pro zobrazení meteorologických údajů
1. Úvod Tato uživatelská příručka je určena uživatelům aplikace Meteoris - Údaje a obsahuje rady a postupy pro její ovládání. Aplikace smí být volně šířena.
2. Popis aplikace Aplikace je součástí systému Meteoris, který se zabývá sběrem a distribucí meteorologických údajů přijatých z klientských měřících stanic a také poskytováním údajů převzatých z externích stanic. Tato aplikace primárně slouží pro čtení a zobrazování meteorologických údajů vlastních nebo převzatých stanic ze serveru Meteoris. Funkce aplikace: • přijímání meteorologických údajů ze serveru (Meteoris nebo i jiného) • ukládání přijatých údajů do souboru • 3 nastavitelné alarmy - upozorní při překročení teploty grafickou a zvukovou formou (plánuje se i odeslání emailu) Vlastnosti aplikace: • aplikace je multiplatformní - funguje pod operačními systémy Microsoft Windows, Linux, Solaris, Mac OS X • aplikace se nemusí instalovat, stačí ji spustit, nevyžaduje žádnou dodatečnou konfiguraci systému ani údržbu
E.3. PŘÍRUČKA APLIKACE PRO ZOBRAZENÍ METEOROLOGICKÝCH ÚDAJŮ 123
• složku s aplikací je možné libovolně přemisťovat v rámci počítače i mezi počítači (pouze je nutné dbát na to, aby byly přesunuty všechny soubory a složky) Požadavky na počítač uživatele: • výkon počítače: běžný kancelářský počítač vyrobený po roce 2000 • operační systém: Microsoft Windows 2000, XP, Vista, 7, Linux, Solaris, Mac OS X • nainstalované Java Runtime Environment verze 6 (možno stáhnout zde: http://www.oracle.com/technetwork/java/javase/downloads/index.html)
3. Práce s aplikací 3.1. Spuštění aplikace Aplikace je distribuována v archivu RAR. Rozbalte ji nejdříve do libovolné složky některým z běžných archivačních programů (WinRAR, WinZip, Unrar). Aplikace vyžaduje pro svůj běh nainstalované Java Runtime Environment (JRE). Pokud je JRE správně nainstalováno, stačí spustit aplikaci poklepáním na spouštěcí soubor MeteorisUdaje.jar v hlavním adresáři aplikace. Pokud se nepodaří aplikaci takto spustit, je třeba otevřít příkazový řádek, (ve Windows: Start - Spustit - cmd.exe) a spustit aplikaci příkazem: java -jar cesta/MeteorisUdaje.jar případně cesta_k_JRE/java -jar cesta/MeteorisUdaje.jar Aplikace nevyžaduje instalaci ani jinou konfiguraci v systému. V případě vzniku chyby nebo varování je podrobnější informace zapsána do logovacího souboru cesta/log.txt. 3.2. Čtení údajů ze serveru Po prvním spuštění aplikace je nutné nastavit parametry „místa“, pro které se budou číst údaje. Nastavení čtení ze serveru je v menu Nastavení -> Nastavení čtení a ukládání. Jako server lze použít libovolný server, formát adresy je možné změnit. U serveru Meteoris je adresa včetně parametrů předvyplněna a stačí vyplnit ID místa (viz seznam mých míst na serveru Meteoris) a uživatelské heslo. U serveru Meteoris je heslo odesíláno zašifrované jako otisk SHA-1. Interval čtení ze serveru je doporučen alespoň 10 minut. 3.3. Ukládání do souboru V menu Nastavení -> Nastavení ukládání je možné zvolit název souboru, do kterého chcete přijaté údaje ukládat. Lze také zvolit interval ukládání a to, zda se má pro každý den použít nový soubor.
124
PŘÍLOHA E. UŽIVATELSKÁ PŘÍRUČKA
3.4. Alarmy V menu Nastavení -> Nastavení upozornění lze nastavit až 3 typy alarmů. Lze definovat teplotu při jejímž překročení se alarm spustí a také zda jde o překročení přes nebo pod nastavenou teplotu (vzestup či pokles teploty). Při spuštění alarmu lze přehrát zvuk (každý alarm má jiný) a tento zvuk je možné nechat nekonečně opakovat. 3.5. Odeslání emailu při alarmu Tato funkčnost zatím není implementována, ale je plánována v budoucnu. K odeslání emailu bude možné využít externí poštovní SMTP server (např. G-mail). Bude podporován také šifrovaný režim pomocí SSL. 3.6. Minimalizace aplikace Aplikace se standardně minimalizuje do systémové lišty. Při čtení ze serveru je teplota zobrazena při najetí myší na ikonu v systémové liště (není nutné okno otevírat). Minimalizaci do systémové lišty je možné změnit v menu Nastavení -> Nastavení aplikace. 3.7. Zobrazení nápovědy Tuto uživatelskou příručku je v programu možné zobrazit v menu Nápověda -> Uživatelská příručka nebo stisknutím klávesy F1.
4. Chybová hlášení Pokud dojde v aplikaci k závažné chybě a nelze pokračovat v běhu programu, je zobrazeno okno o tom, že se stala chyba, podrobnější informace je zapsána do logovacího souboru cesta/log.txt a aplikace je ukončena. Pokud není chyba závažná, je pouze zobrazena informace o chybě a je zapsána do logu jako varování, ale program není ukončen. Pokud vznikne neočekávaná běhová (run-time) výjimka způsobená chybou v programu, není zalogována a je na uživateli, aby o ní a okolnostech jejího vzniku dal vědět tvůrci aplikace, aby mohla být opravena. Možné chybové zprávy a jejich řešení: Došlo k chybě při čtení údajů ze serveru. Údaje nemohly být ze serveru přečteny, chyba je blíže specifikována. Je možné, že jde o dočasný výpadek serveru nebo byla chybně uvedena adresa serveru. Nelze přidat ikonu do systémové lišty. Váš systém nemá systémovou lištu, nemůžete tudíž tuto funkčnost využívat. Nelze nastavit Look & Feel. Požadovaný vzhled není v této verzi Java Runtime Environment podporován, nainstalujte si prosím aktuální verzi JRE.
E.4. INSTALAČNÍ PŘÍRUČKA SERVERU
125
Nelze číst/zapisovat z nebo do souboru. Nemáte přístupová práva ke čtení nebo zápisu do tohoto souboru nebo je název souboru neplatný. Změňte cestu nebo název souboru. Nelze načíst dokument z JAR archivu. Spouštěcí soubor aplikace byl poškozen, nahraďte ho prosím originálním souborem. Nelze spočítat otisk řetězce hešovací funkcí SHA-1. Hešovací funkce SHA-1 není v této verzi Java Runtime Environment podporována, nainstalujte si prosím aktuální verzi JRE. Bez této funkce nebude aplikace fungovat.
E.4
Instalační příručka serveru
Nasadit serverovou část systému na server je velmi jednoduché. Je vyžadován server Apache s PHP 5.2 nebo vyšším. Poté stačí umístit obsah složky Server ze složky src na CD do kořenového adresáře na serveru, který je viditelný i vně serveru (často www nebo public_html). Poté je potřeba změnit absolutní cesty a přístupové údaje k databázi v souborech setup.php a mojesmarty.php na údaje odpovídající použitému serveru.
126
PŘÍLOHA E. UŽIVATELSKÁ PŘÍRUČKA
Příloha F
Obsah přiloženého CD Na přiloženém CD jsou následující soubory a adresáře: - index.html - rozcestník k jednotlivým souborům a složkám na CD - readme.txt - popis obsahu CD a postup spuštění aplikace - text/ - adresář s textem diplomové práce ve formátu PDF a zdrojový kód LATEX - dist/ - adresář se spustitelnými programy a knihovnami - src/ - zdrojové kódy všech tří komponent systému - data/ - doplňkové soubory - prevzate_stanice/ - soubory s údaji převzatých stanic - uml/ - UML diagramy a projekt v nástroji Enterprise Architect - html/ - dokumentace - abstrakt/ - český a anglický abstrakt - dokumentace/ - dokumentace zdrojového kódu Javadoc - prirucky/ - uživatelské příručky
