012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Poradenský webový portál pro vinohradnictví DIPLOMOVÁ PRÁCE

Bc. Jan Pacek

Brno, jaro 2006

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Vedoucí práce: prof. RNDr. Jiˇrí Hˇrebíˇcek, CSc ii

Podˇekování Rád bych podˇekoval svému vedoucímu práce, panu profesoru RNDr. Jiˇrímu Hˇrebíˇckovi, CSc., za podnˇetné rady a pˇripomínky k mé práci a smˇerování v prubˇ ˚ ehu realizace mé práce. Dík patˇrí také panu Ing. Tomáši Richterovi, tajemníku svazu Integrované produkce hroznu˚ a vína, díky nˇemuž tato zajímavá práce mohla být realizována a který projevil ochotu realizovat takto rozsáhlý portál v rámci diplomové práce. Za podnˇetné rady pˇri realizaci systému meteorologické mapy dˇekuji panu RNDr. Tomáši Litschmannovi z firmy Amet a panu PhDr. Milanu Hluchému z firmy Biocont Laboratory ltd.

iii

Shrnutí Práce analyzuje souˇcasný stav používání internetových poradenských portálu˚ v oblasti pˇestování révy vinné a snaží se nalézt odpovˇedi na otázku, jak by více mohl vliv informaˇcních technologií pomoci vinohradnictví v rámci trvale udržitelného rozvoje. Práce popisuje konkrétní tvorbu poradenského portálu pro Svaz Integrované produkce hroznu˚ a vína, jeho uvedení do praxe a to vše na základˇe informaˇcních potˇreb svazu. V rámci práce byla také vytvoˇrena elektronická online meteorologická mapa vinic Jižní Moravy, která nabízí cenné aktuální meteorologické údaje pro moravské vinaˇrství.

iv

Klíˇcová slova portál, meteorologická mapa, informaˇcní potˇreby, poradenství, integrovaná produkce hroznu˚ a vína, Java, klient - server architektura, Model View Controller

v

Obsah 1 2

3

4

5

6

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Uvedení do rˇ ešené problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . Analýza poradenských portálu˚ v oblasti produkce hroznu˚ vína . . . . . . . . . . 2.1 Seznámení s integrovanou produkcí hroznu˚ a vína . . . . . . . . . . . . . . . . 2.1.1 Definice integrované produkce . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Informaˇcní potˇreby Svazu Integrované produkce hroznu˚ a vína (SIPHV) 2.2 Definice portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Pˇrehled poradenských portálu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 www.Galati.sk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Státní rostlinolékaˇrská správa . . . . . . . . . . . . . . . . . . . . . . . . ˇ 2.3.3 Portál Svazu vinaˇru˚ Ceské republiky . . . . . . . . . . . . . . . . . . . . 2.3.4 www.zahrada.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 www.biocont.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detailní analýza a návrh architektury portálu SIPHV . . . . . . . . . . . . . . . . 3.1 Uživatelé systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Administrátor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ 3.1.3 Clen svazu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Externí uživatelé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ 3.1.5 Ctenáˇ r obsahu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Požadavky na uživatelnost vˇcetnˇe grafického návrh portálu . . . . . . . . . . 3.3 Požadavky na architekturu systému . . . . . . . . . . . . . . . . . . . . . . . . Zvolená architektura rˇešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Model - View - Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Implementace MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Model - Hibernate framework . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Struktura webovské aplikace . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 Hosting aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Alternativní rˇ ešení architektury portálu - použití CMS . . . . . . . . . . . . . . Správa obsahu portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Správa uživatelu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Správa cˇ lenu˚ svazu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Správa obsahu portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Složka webového obsahu . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Dokument webového obsahu . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 Administrativní rozhraní správy dokumentu˚ . . . . . . . . . . . . . . . 5.4 Další rozšíˇrení správy obsahu . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sledování náletu˚ obaleˇcu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 2 2 3 4 7 7 8 8 9 9 10 10 10 11 11 11 11 12 14 16 16 18 18 21 22 23 24 24 27 27 28 30 30 31 33 34 37 vi

6.1 Požadavky na správu sledování náletu˚ obaleˇcu˚ . . . . . . . . . 6.2 Realizace on line sledování náletu˚ obaleˇcu˚ . . . . . . . . . . . . 6.3 Zkušenosti z provozu a možná rozšíˇrení . . . . . . . . . . . . . 7 Meteorologická mapa vinic . . . . . . . . . . . . . . . . . . . . . . . 7.1 Sít’ meteorologických stanic . . . . . . . . . . . . . . . . . . . . 7.2 Problematika sdílení meteorologických dat . . . . . . . . . . . 7.2.1 Stávající rˇ ešení vytvoˇrené v roce 2000 . . . . . . . . . . ˇ 7.2.2 Rešení úpravou stávajícího rˇ ešení zasílání dat . . . . . 7.2.3 Návrh rˇ ešení sdílení meteorologických dat . . . . . . . 7.3 Realizace meteorologické mapy vinic . . . . . . . . . . . . . . . 7.3.1 Komponenta serveru meteorologické mapy . . . . . . . 7.3.2 Klientská aplikace pro synchronizaci dat . . . . . . . . 7.3.3 Distribuce klientské aplikace a její technologické rˇ ešení 7.4 Uvedení do praxe a možná rozšíˇrení . . . . . . . . . . . . . . . 8 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A ERD portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B UML modely portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . C Ukázky zpracování meteorologických dat . . . . . . . . . . . . . . D Meteorologická mapa SIPHV . . . . . . . . . . . . . . . . . . . . . . E Obsah CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rejstˇrík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

37 38 39 41 41 43 43 44 45 46 46 48 50 52 54 55 58 63 65 69 71 72

vii

Kapitola 1

Úvod 1.1

Uvedení do rˇešené problematiky

Závislost na agrochemikáliích, zejména pesticidech a umˇelých hnojivech, patˇrí mezi nejvážnˇejší problémy souˇcasného zemˇedˇelství. Používané chemické prostˇredky vˇetšinou vyhubí cˇ etné druhy pˇrirozených živoˇcichu, ˚ vˇcetnˇe pˇrirozených nepˇrátel škudc ˚ u˚ zemˇedˇelských plodin a paradoxnˇe tak snižují obranyschopnost zemˇedˇelských plodin i pˇred jinými škudci, ˚ než na které byly tyto chemické pˇrípravky puvodnˇ ˚ e urˇceny. Tento stav pak velmi podporuje používání dalších chemických pˇrípravku, ˚ které celou situaci dále zhoršují a pˇrináší další ekologickou zátˇež. To také pˇrináší firmám v chemickém prumyslu ˚ další zisky. Takzvané integrované zemˇedˇelství je nejbližší možnou alternativou pro zemˇedˇelce, kteˇrí nechtˇejí používat ve své produkci chemických prostˇredku˚ a zárovenˇ nemohou naplnit pomˇernˇe pˇrísné standardy ekologického zemˇedˇelství. Integrované zemˇedˇelství (ˇci integrované systémy rostlinné produkce) v ruzných ˚ podobách pˇredstavuje nˇekolik kroku˚ k dlouhodobé udržitelnosti. Je založena na konceptech integrovaného obhospodaˇrování plodin (ICM) a integrované ochrany pˇred škudci ˚ a plevely (IPM), které v podobˇe sady definic a návodu˚ zpracovalo nˇekolik národních i evropských organizací, jež tento zpusob ˚ hospodaˇrení propagují. Integrované zemˇedˇelství a produkce díky propracovaným metodám rˇ ízení podniku, úˇcinným kultivaˇcním postupum ˚ a technikám ochrany rostlin a kontroly plevelu˚ integrované zemˇedˇelství významnˇe snižuje spotˇrebu agrochemikálií. Podobnˇe jako ekologické zemˇedˇelství má také spíše nižší ekonomické náklady, o nˇeco nižší výnosy a celkovˇe pˇribližnˇe stejné ekonomické výsledky jako konvenˇcní hospodaˇrení. Pro udržitelnost konkurenceschopnosti podniku˚ v systému integrované produkce musí být proto pˇrijata rˇ ada integrovaných opatˇrení, které dokáží být dohromady stejnˇe efektivní v ochranˇe pˇred možnými škudci ˚ jako chemické ošetˇrování. Tato opatˇrení se neobejdou bez efektivního pˇrístupu k informacím, bez dostateˇcné odborné pomoci a sledování rizikových faktoru˚ bˇehem vinaˇrské sezóny. Hlavním cílem této diplomové práce bylo proto navrhnout, vytvoˇrit a ovˇerˇ it v praxi vhodný poradenský portál pro konkrétní úˇcely Svazu Integrované produkce hroznu˚ a vína1 tak, aby dokázal pokrýt nejduležitˇ ˚ ejší informaˇcní potˇreby pˇestitelu˚ vinné révy v rámci integrované produkce. 1. <www.vino-ip.cz>

1

Kapitola 2

Analýza poradenských portálu˚ v oblasti produkce hroznu˚ vína V této kapitole bych rád blíže pˇredstavil zákazníka poradenského portálu, svaz integrované produkce, jeho informaˇcní potˇreby a analyzoval souˇcasné portály zabývající se poradenskou cˇ inností nejen pro producenty vína.

2.1

Seznámení s integrovanou produkcí hroznu˚ a vína

2.1.1 Definice integrované produkce Více jak polovina (pˇres 140) producentu˚ vína na Moravˇe se rˇ ídí integrovanou produkcí(dále jen IP) a jsou registrovanými cˇ leny Svazu Integrované produkce hroznu˚ a vína. Smˇernice Integrované produkce hroznu˚ a vína jsou zpracovány s pˇrihlédnutím k požadavkum ˚ na obdobné integrované systémy révy vinné, jež pro švýcarské vinohradnictví zpracovali Basler a Murisier (1990). Tyto smˇernice stanovují limitující a doporuˇcená kritéria pro jednotlivé pˇestební technologie. Pˇri jejich více jak dvouletém dodržování muže ˚ být finální produkt (stolní hrozen, víno) deklarován jako produkt z IP a oznaˇcen ochrannou známkou. Mezi základní prvky integrované produkce patˇrí: •

Správná volba stanovištˇe vinic

•

Vhodný výbˇer odrud ˚ révy vinné

•

Péˇce o pudu, ˚ agrotechnika, protierozní ochrana

•

Výživa a hnojení

•

Regulace chorob

•

Regulace škudc ˚ u˚

•

Systém IP a ekonomika podniku

Z principu IP mají nejvˇetší prioritu pro cˇ lenské podniky regulace chorob a škudc ˚ u. ˚ Pˇri ochranˇe révy vinné pˇred hlavními škudci ˚ (obaleˇci, svilušky, hálˇcivec révový) v systému IP se pˇredpokládá monitorování doby letu a množství obaleˇcu˚ feromonovými lapáky a monitorování populaˇcní hustoty škodlivých roztoˇcu˚ (v pˇrípadˇe mikroskopické velikosti hálˇcivcu˚ 2

˚ A VÍNA 2.1. SEZNÁMENÍ S INTEGROVANOU PRODUKCÍ HROZN U toto hodnocení provádí specializované laboratoˇre). Pˇri ochranˇe jsou upˇrednostnovány ˇ biologické prostˇredky (draví roztoˇci, pˇrípravky na bázi B. thuringiensis), které jsou jednoznaˇcnˇe ekotoxikologicky vhodnˇejší, než chemické preparáty. Provedení ochranného zásahu je podmínˇeno pˇrekroˇcením prahu škodlivosti škudcem. ˚ Pro ochranu vinic pˇred chorobami je v IP nejduležitˇ ˚ ejší prevence. Smˇernice IP napˇríklad stanoví maximální hranici pˇeti ošetˇrení proti padlí révovému a plísni révové, pˇriˇcemž v mˇed’natých preparátech smí být použito pouze 5 kg mˇedi (Cu) na hektar a rok. Správné a vˇcasné provedení preventivních opatˇrení proti tˇemto chorobám je možné na základˇe pˇresného hodnocení srážek, teplot, ovlhˇcení listu˚ a pˇrípadnˇe dalších faktoru˚ vyhodnocující riziko kalamitního výskytu uvedených hlavních chorob i ve vztahu k jednotlivým odrudám ˚ a lokalitám.[3] Dusledné ˚ uplatnování ˇ celého systému IP pˇrináší jak zlepšení zdravotního stavu a fyziologické kondice révy vinné, tak podstatné snížení zátˇeže ekosystému vinice a jeho okolí. Z hlediska ekonomické stability a prosperity podniku je významné ve srovnání s konvenˇcní technologií ochrany rostlin až 50 % snížení nákladu˚ vynakládaných na nákup pesticidu˚ a dosažení podstatnˇe vyšších realizaˇcních cen špiˇckových (ze znaˇcné cˇ ásti pˇrívlastkových) vín. Podnik produkující v rámci IP má také možnost být zaˇrazen do agroenvironmentálního opatˇrení, které je souˇcástí naˇrízení vlády cˇ . 242/2004 Sb., o podmínkách opatˇrení na podporu rozvoje mimoprodukˇcních funkcí zemˇedˇelství, spoˇcívajících v ochranˇe složek životního prostˇredí. Díky tomuto zaˇrazení muže ˚ být producentovi vína finanˇcnˇe kompenzovaná nižší výnosnost vinic dotací z ministerstva zemˇedˇelství. 2.1.2 Informaˇcní potˇreby Svazu Integrované produkce hroznu˚ a vína (SIPHV) Po bližším seznámení se Svazem Integrované produkce hroznu˚ a vína pˇri tvorbˇe této diplomové práce vyplynuly jejich hlavní požadavky na portál, které mˇely naplnit informaˇcní potˇreby cˇ lenu˚ svazu, tak samotného vedení svazu. Tyto informaˇcní potˇreby vyplynuly po úvodním zkoumání a analýze fungování svazu a byly spolu s vedením svazu stanoveny jako hlavní cíle, které by mˇel vytvoˇrený portál naplnit.

Pravidelné poradenství pro cˇ leny Potˇreba informovat všechny cˇ leny svazu v týdenním intervalu v tzv. Signalizaˇcních zprávách. V tˇechto signalizacích jsou cˇ lenové svazu upozornováni ˇ na akutní rizikové faktory jednotlivých chorob a škudc ˚ u˚ a je jim pˇrímo doporuˇcováno rˇ ešení v souladu s pravidly IP. Tato služba by mˇela být pˇrístupná pouze pro cˇ leny svazu.

Legislativa - dokumentový server Pro cˇ leny svazu je duležité ˚ mít snadný pˇrístup k veškeré legislativˇe týkající se jak integrované produkce, tak i agroenvironmentálního opatˇrení, smˇernic. Mˇelo by být také snadné získat k dané legislativˇe veškeré formuláˇre, pˇri3

2.2. DEFINICE PORTÁLU hlášky a kontrolní dokumenty. Pro cˇ leny svazu i veˇrejnost by mˇely být snadno pˇrístupné popisy škudc ˚ u˚ a chorob révy vinné v rámci dokumentového serveru. Rozcestník Odkazy k relevantnímu obsahu na jiných serverech týkajícího se produkce hroznu˚ a vína. Pˇrehled o aktuálních náletech obaleˇcu˚ Snadný pˇrístup k aktuálním náletum ˚ hlavních škudc ˚ u˚ vinné révy do feromonových lapaˇcu˚ tak, aby bylo možné rychle reagovat na pˇrípadnou blížící se kalamitu. Detailnˇejší popis rˇ ešení tohoto požadavku naleznete v kapitole 6. Meteorologická mapa Spolu s poradenskými službami druhý nejduležitˇ ˚ ejší požadavek svazu ˇ IP. Clenský podnik by mˇel mít snadnou možnost získat aktuální meteorologické údaje z cca 40 meteorologických stanic z vinic Moravské vinaˇrské oblasti, vlastnˇených svazem IP. Detailnˇejší popis rˇ ešení tohoto požadavku naleznete v kapitole 7. Aktuality, správa svazu IP V rámci navrhovaného portálu by mˇelo být snadné informovat cˇ leny svazu o konkrétních setkáních, akcích a valných hromadách. Souˇcástí rˇ ešení by také mˇelo být rozhraní pro správu aktuálních kontaktu˚ cˇ lenu˚ svazu.

2.2

Definice portálu

Za webový portál mužeme ˚ považovat ucelený webový systém na internetu nabízející širokou škálu služeb a informací. Tato nabídka služeb a informací portálu se liší podle toho, jaká skupina uživatelu˚ bude dané zdroje používat a v jaké oborové cˇ innosti se skupina uživatelu˚ nachází. Webový portál se z pohledu uživatelského zpravidla skládá z nˇekolika vrstev, kde každá vrstva nabízí každé skupinˇe uživatelu˚ jiné služby. Základní vrstva portálu je administrativní. Patˇrí do ní vˇetšinou redakˇcní systém celého portálu, správa uživatelu, ˚ správa nabízených služeb a další. Administrativní vrstva je urcˇ ena pro lidi starající se o správný chod celého webového portálu. Další vrstvy jsou pro bˇežné uživatele, jimž jsou urˇceny služby portálu. Tyto vrstvy jsou cˇ lenˇeny dle oprávnˇení skupin uživatelu˚ s ohledem na to, k jakým službám a informacím mohou uživatelé v dané skupinˇe pˇristupovat. U placených portálu˚ mohou být skupiny uživatelu˚ rozlišovány dle výše plateb za konkrétní služby a informace.[4] Portál mužeme ˚ rozdˇelit do ruzných ˚ kategorií a druhu. ˚ Napˇríklad dle tématického zamˇerˇ ení lze portál rozdˇelit na: [5]

4

2.2. DEFINICE PORTÁLU horizontální portály (horizontal portals) Horizontální portály jsou zamˇerˇ eny na co nejširší informaˇcní spektrum a jejich cílem je uspokojit co nejvˇetší poˇcet uživatelu. ˚ Horizontální portály se tak snaží bˇežným uživatelum ˚ nabízet co nejvˇetší a nejrozliˇcnˇejší nabídku služeb, vˇcetnˇe emailového úˇctu, vyhledávání, webového prostoru ale i webových obchodu. ˚ Mezi horizontální portály mužeme ˚ zaˇradit i portál google.com Tento portál nejprve zaˇcínal pouze s jedním úˇcelem a to vyhledávání obsahu na internetu. Google ale brzy zaˇcal své portfolio služeb rozšiˇrovat o další nabízené služby, jako zpravodajství (Google News), mailbox (Gmail), online obchody (Froogle), mapy (Google local) a další. Mezi dnes nejbˇežnˇejší cˇ eské horizontální portály rˇ adíme www.seznam.cz, www.atlas.cz, cˇ i www.tiscali.cz. vertikální portály(community portals) Vertikální portály, nˇekdy také "community portals", jsou tématicky úzce zamˇerˇ ené a jsou urˇceny pro specifický typ uživatelu. ˚ Škála nabízených služeb je možná v porovnání s komerˇcními portály mnohem menší, avšak postaˇcující pro úˇcely, k nimž byl portál zbudován. Tyto služby jsou vˇetšinou vytvoˇreny "na míru" pro konkrétní úˇcel, kterým se daná tématická oblast zabývá. Jako pˇríklad vertikálního portálu bych uvedl zdaˇrilý portál www.enviweb.cz, 1 který se zabývá tématikou životního prostˇredí. Jsou zde uvedeny aktuální znˇení legislativy, naˇrízení a novinky z oblasti environmentalistiky. Uživatel, jehož se daný obor lidské cˇ innosti dotýká, má výhodu, že zde nalezne vše co potˇrebuje a to na jediném místˇe. At’ už se jedná o firmy, které musí splnovat ˇ ruzná ˚ naˇrízení pro ochranu životního prostˇredí. Dle typu obsahu mužeme ˚ portál definovat jako: rozcestníkový portál Portál tohoto typu nabízí pˇredevším zdroje a odkazy na informace z jiných portálu, ˚ importuje napˇríklad novinky z jiných portálu˚ pˇres rozliˇcné komunikaˇcní kanály, jako RSS, webové služby, prohledávacím automatem, apod. dokumentový portál Portál tohoto typu nabízí pˇredevším primární zdroje vlastních dokumentu˚ a tento obsah pak nabízí jiným serverum ˚ napˇríklad pˇres RSS a webové služby. Dle platby za jejich služby mužeme ˚ portál dˇelit na: placený Obsah, informace a služby tˇechto portálu˚ jimi nabízené jsou uživatelum ˚ zpoplatnovány ˇ bud’ pˇrímým (platby on line, platby pˇres mobilního operátora, ...) nebo nepˇrímým zpusobem ˚ (formou registrovaného zpoplatnˇeného cˇ lenství, pˇredplacených bodu, ˚ karet, bonusu˚ z jiných služeb....) 1. <www.enviweb.cz>

5

2.2. DEFINICE PORTÁLU

neplacený Obsah a služby tohoto druhu portálu je uživatelum ˚ nabízen zdarma. Pˇríjmy provozovateli portálu plynou vˇetšinou z reklamy, která je uživatelum ˚ na portálu nabízena. Výše uvedené typy portálu jsou spíše rysy a charakteristikami jednotlivých portálu˚ a v praxi portály cˇ asto nebývají ryze jednoho charakteru a typu. Bˇežnˇe portály kombinují placený a neplacený prostor, obsahují cˇ ást odkazující na pˇríbuzný obsah a cˇ ást s vlastními publikovanými dokumenty. Co se realizace a vzhledu portálu týká, kvalitní webový portál a jeho obsah by mˇel být uživatelum ˚ dobˇre pˇrístupný. Uvádím zde základní doporuˇcení Best practice - Pravidla pro tvorbu pˇrístupného webu vydané ministerstvem Informatiky jako doporuˇcující materiál pro tvorbu pˇrístupného webu portálu˚ veˇrejné správy.[2] Obsah webových stránek je dostupný a cˇ itelný Obsah portálu je dostupný všem uživatelum ˚ všech bˇežných prohlížeˇcu˚ a platforem bez nutnosti mít nainstalované speciální doplnky ˇ jako Macromedia Flash, Javu, .... Stránky jsou pro uživatele snadno cˇ itelné, barvy jejich popˇredí a pozadí jsou dostateˇcnˇe kontrastní za použití standardních písem. Práci s webovou stránkou rˇídí uživatel Obsah WWW stránky se mˇení, jen když uživatel aktivuje nˇejaký prvek a to v mezích samotné stránky. Zmˇenou stránky se nevytváˇrí bez vˇedomí uživatele nová vyskakovací okna a stránky nemanipulují s prohlížeˇcem. Informace jsou srozumitelné a pˇrehledné Webové stránky sdˇelují informace jednoduchým jazykem a srozumitelnou formou a rozsáhlé obsahové bloky stránek jsou rozdˇeleny do menších, výstižnˇe nadepsaných celku. ˚ Úvodní webová stránka portálu jasnˇe popisuje smysl a úˇcel webu. Název webu cˇ i jeho provozovatele je zˇretelný. Ovládání webu je jasné a pochopitelné Navigaˇcní a obsahové informace jsou na webové stránce zˇretelnˇe oddˇeleny. Navigace je provádˇena napˇríklad navigaˇcním panelem, lištou, zatímco textový obsah má urˇcený pˇrímo svuj ˚ blok. Navigace webu je konzistentní ve všech stránkách a položky navigaˇcního menu jsou jednoduché a výstižné. Všechny webové stránky rozsáhlejšího webu obsahují odkaz na pˇrehlednou mapu webu a odkaz na domovskou stránku, stejnˇe jako kontakt na administrátora a provozovatele webu. 6

ˇ ˚ 2.3. P REHLED PORADENSKÝCH PORTÁL U

Odkazy jsou zˇretelné a návodné Odkazy jsou odlišeny od ostatního textu, a to nikoli pouze barvou. Uživatel je také pˇredem jasnˇe upozornˇen, když odkaz vede na obsah jiného typu, než je webová stránka. Takový odkaz je doplnˇen sdˇelením o typu a velikosti cílového souboru Kód je technicky zpusobilý ˚ a strukturovaný Kód webových stránek odpovídá nˇejaké zverˇ ejnˇené finální specifikaci jazyka HTML cˇ i XHTML. Neobsahuje syntaktické chyby, které je správce webových stránek schopen odstranit. Stránky se také zobrazují ve všech internetových prohlížeˇcích pˇribližnˇe stejnˇe.

2.3

Pˇrehled poradenských portálu˚

V této podkapitole uvedu pár obdobných poradenských portálu, ˚ které se zabývají produkcí hroznu˚ a vína a to nejen produkcí integrovanou. Je ovšem pravda, že ryze poradenských ˇ portálu˚ na produkci vína moc v Ceské republice neexistuje. 2.3.1 www.Galati.sk 2 Jediným existujícím poradenským portálem pro integrovanou produkci je portál www.galati.sk,

který vznikl v zhruba stejné dobˇe jako portál svazu IP. Portál www.galati.sk je portál poradenské firmy GALATI Bratislava, jež získala na Slovensku v roce 1998 akreditaci vykonávat posouzení a odzkoušení biologické úˇcinnosti pˇrípravku˚ na ochranu rostlin v rámci integrované produkce. Tato firma spolupracovala spolu se Svazem Integrované produkce v roce 2000 na projektu Phare pro Rozvoj vinohradnictví Jižní Moravy na vytvoˇrení velkoplošné prognózy a signalizace. V rámci tohoto projektu pak Svaz Integrované produkce zakoupil pˇres 50 aktivních meteorologických stanic, na jejichž datech se pak analyzují signalizaˇcní zprávy svazu. Portál je úzce zamˇerˇ en na oblast pˇestování vína v rámci integrované produkce a je podporován chemickoprumyslovou ˚ firmou Syngenta. Obsahuje informace týkající se konkrétních pˇrípravku˚ pro integrovanou produkci a aktuality týkající se integrované produkce na Moravˇe i Slovensku. Souˇcástí portálu je i on line verze signalizaˇcního programu GALATI vitis. Galati Vitis na základˇe informace o poˇcasí (prumˇ ˚ erná teplota a srážky) a ošetˇrení pˇredcházející týden a pˇredpokládané feno fáze v aktuálním týdnu urˇcí infekˇcní tlak chorob a navrhne postˇrik. Program zohlednuje ˇ citlivost odrud, ˚ klima a citlivost polohy vinohradu. Tento program na prognózu a signalizaci je souˇcástí integrované produkce vína a je poskytován na internetu zdarma. Meteorologické údaje jsou bud’ již pro nˇekteré lokality pˇredvyplnˇeny, a nebo je uživatel zadává ruˇcnˇe pˇri zpracování dat pro svuj ˚ vinohrad. 2. <www.galati.sk>

7

ˇ ˚ 2.3. P REHLED PORADENSKÝCH PORTÁL U Portál je napsaný v jazyce PHP a je dobˇre pˇrehledný a cˇ itelný. Jediné, co bych mu vytkl je, že soubory v pˇrílohách ke stažení jsou v ne pˇríliš standardním formátu programu Microsoft Word. 2.3.2 Státní rostlinolékaˇrská správa 3 Státní

rostlinolékaˇrská správa (SRS) je správní úˇrad rostlinolékaˇrské péˇce s pusobností ˚ na ˇ území Ceské republiky a je úˇrední organizací ochrany rostlin podle Mezinárodní úmluvy o ochranˇe rostlin a úˇradem odpovˇedným za výkon pusobnosti ˚ na úseku rostlinolékaˇrské péˇce podle zvláštního pˇredpisu Evropských spoleˇcenství. Rostlinolékaˇrská správa vydává Vˇestník SRS, v nˇemž zveˇrejnuje ˇ informace o dokumentech z oblasti rostlinolékaˇrské péˇce vydaných orgány Evropských spoleˇcenství a jinými mezinárodními institucemi, informace o výskytu škodlivých organismu, ˚ pˇrehledy o registraci pˇrípravku˚ a dalších prostˇredku, ˚ pˇrehledy provozovatelu˚ kontrolního testování mechanizaˇcních prostˇredku˚ a jiné významné informace pro veˇrejnost a vyhlašuje opatˇrení proti zavlékání a rozšiˇrování nebezpeˇcných škodlivých organismu. ˚ Portál státní rostlinolékaˇrské správy je svou strukturou zamˇerˇ en obdobnˇe jako navrhovaný portál Svazu Integrované produkce. Obsahuje legislativu týkající se pˇrípravku˚ používaných v zemˇedˇelství, aktuální meteorologické údaje z cca 16 meteorologických stanic, nálety škudc ˚ u˚ do feromonových lapaˇcu˚ a prognostické zprávy k jednotlivým škudc ˚ um. ˚ Pˇri tvorbˇe internetové prezentace Státní rostlinolékaˇrské správy (SRS) se pˇrihlíželo k doˇ (pravidla tvorby pˇrístupného webu). Prezentaci je poruˇcením Ministerstva informatiky CR možno prohlížet ve všech nejˇcastˇeji používaných prohlížeˇcích internetových stránek. ˇ 2.3.3 Portál Svazu vinaˇru˚ Ceské republiky ˇ portál naleznete na adrese www.svcr.cz a slouží pro prezentaci Svazu vinaˇru˚ Ceské republiky. Z nabízených poradenských služeb zde nalezneme pouze odkaz na prodej cˇ asopisu Vinaˇrský obzor, který svaz vydává. Veškeré informace jsou tedy pro uživatele dostupné po zakoupení tohoto cˇ asopisu, který je nabízen žel jen v papírové verzi. K celkovému rˇ ešení portálu www.svcr.cz bych mˇel tyto dvˇe hlavní pˇripomínky.

4 Tento

Neaktuální informace Nabízené informace jsou neaktuální, napˇríklad je zde stále stará definice vinaˇrských oblastí, statistiky a pˇrehledy jsou 3 roky staré. Nutnost používat Macromedia Flash Pro zobrazení stránek a celou navigaci musí mít uživatel nainstalovaný Macromedia Flash. Bez této komponenty není web funkˇcní, protože zde není nabídnuta alternativa pro zobrazení navigaˇcního panelu v bˇežném pro3. <www.srs.cz> 4. <www.svcr.cz>

8

ˇ ˚ 2.3. P REHLED PORADENSKÝCH PORTÁL U hlížeˇci. V prohlížeˇcích Microsoft Internet Explorer je tˇreba mít povolené prvky ActiveX, což muže ˚ být pro klienta bezpeˇcnostní riziko. 2.3.4 www.zahrada.cz 5 Následující

portál není pˇrímo zamˇerˇ en na produkci hroznu˚ vína, ale jedná se o dobˇre zpracovaný poradenský portál pro ochranu rostlin v zahrádkáˇrství, který stojí za to zmínit. Projekt ZAHRADA.cz se zrodil v polovinˇe roku 1999, kdy se zapoˇcal vývoj první z jeho plánovaných souˇcástí - internetového diskusního fóra, které by plnilo funkci jednoduchého a efektivního nástroje pro sdílení zajímavých rad, zkušeností, postˇrehu˚ a názoru. ˚ V rámci diskusního fóra urˇceného pro zahradníky, zahrádkáˇre, drobné pˇestitele a fandy, stejnˇe jako i pro experty, publicisty, vydavatele, výrobce a obchodníky je vytvoˇren široký prostor nejen pro pˇredávání poznatku˚ ze samotné pˇestební cˇ innosti a následného zpracování nebo skladování, ale kupˇríkladu i pro hodnocení úˇcelnosti a vlastností konkrétních produktu, ˚ pomucek ˚ a nejruznˇ ˚ ejšího vybavení. Toto fórum je dobˇre strukturované a tak se uživatel snadno dostane k informacím, které ho zajímají. Funguje zde samozˇrejmˇe i full-textové vyhledávání v obsahu fóra. Poradenská služba je poskytována uživatelum ˚ zdarma a obsah portálu je upravován autonomnˇe samotnými uživateli. Poskytovatelum ˚ portálu plynou pˇríjmy z reklamy, kterou na svém portálu nabízí. 2.3.5 www.biocont.cz Na tˇechto stránkách nalezneme prezentaci firmy zabývající se ochranou rostlin také v rámci integrované produkce hroznu˚ a vína. Uživatel zde muže ˚ nalézt definici a detailní popis ekologicky šetrných prostˇredku, ˚ používaných nejen užívaných v integrované produkci hroznu˚ a vína. Souˇcástí stránek firmy je i statický objednávkový formuláˇr na tyto prostˇredky. K celkovému rˇ ešení stránek www.biocont.cz bych mˇel tyto pˇripomínky6 Stránky jsou bez navigaˇcního menu Nabízené informace jsou nestrukturované a odkaz na jakýkoliv obsah je nutné dˇelat z úvodní stránky, což je pro uživatele znaˇcnˇe nepˇríjemné, protože obsah na úvodní navigaˇcní stránku je ve vˇetšinˇe pˇrípadu˚ umístˇen až na spodním okraji stránky s obsahem. Server nepoužívá redakˇcní systém Veškerý obsah webu je zobrazen jako statické stránky a jejich styl zobrazení tak není pˇríliš jednotný. Stránky s obsahem jsou také pˇríliš rozsáhlé a nutí uživatele k prohlížení celého obsahu, než se propracuje k požadované informaci. 5. <www.zahrada.cz> 6. <www.biocont.cz>

9

Kapitola 3

Detailní analýza a návrh architektury portálu SIPHV V této kapitole bych se rád zabýval provedenou analýzou požadavku˚ na portál a zvolenou architekturou portálu, která se odvíjela od požadavku˚ nejenom na funkˇcnost portálu, ale i na jeho postupné uvádˇení do provozu. Hned z úvodní analýzy bylo zˇrejmé, že vytváˇrený portál bude úzce tématicky zamˇerˇ ený, vertikálního typu, placený formou pˇredplatného cˇ i cˇ lenství a jeho obsah bude z vˇetší cˇ ásti dokumentový. Dle výˇctu˚ dalších hlavních požadavku, ˚ které mˇel implementovaný systém splnovat ˇ se odvíjela i architektura a samotný postup rˇ ešení, které bylo rozdˇeleno pomyslných etap. Svaz IP, jako zadavatel, potˇreboval mít již pro sezónu 2005 hotovou funkˇcní službu on line signalizaˇcních zpráv pro cˇ leny i platící zákazníky. Samotné rˇ ešení tohoto jediného požadavku zabralo pomˇernˇe více cˇ asu a úsilí, protože rˇ ešení služby signalizaˇcních zpráv mˇelo silný dopad na ostatní požadavky a kladlo duraz ˚ na správnou pˇredbˇežnou analýzu celého systému, který mˇel být do budoucna rozšíˇren o on line meteorologickou mapu a on line sledování náletu˚ do lapaˇcu. ˚ Pˇri implementaci cˇ ásti portálu signalizaˇcních zpráv bylo nutné mít detailnˇeji popsány tyto požadavky: •

Uživatelé systému a jejich funkˇcní požadavky.

•

Požadavky na uživatelnost, vˇcetnˇe grafického návrh portálu.

•

Požadavky na rozšiˇritelnost, spolehlivost a architekturu.

3.1

Uživatelé systému

Zde uvádím uživatele systému a jejich hlavní pˇrípady užití (z pohledu systému) dle úvodních požadavku˚ ze strany Svazu IP. Blíže jsou popsány v pˇríloze v systémovém UML diagramu pˇrípadu˚ užití.B.2 3.1.1 Administrátor Administrátor má právo: •

vytváˇret, spravovat a mazat uživatelské úˇcty, definovat jejich délku platnosti. 10

3.1. UŽIVATELÉ SYSTÉMU •

spravovat databázi cˇ lenských podniku˚ a definovat jim pˇriˇrazené uživatelské úˇcty.

•

zakládat a spravovat mˇerˇ ící stanice meteorologické mapy do systému.

•

provádˇet stejné úkony jako uživatel editor

3.1.2 Editor Uživatel editor má právo: •

vytváˇret, spravovat a mazat obsah webu, stejnˇe jako složky dokumentu˚ stránek, odkazu˚ na jiné stránky.

•

vkládat a spravovat údaje z náletu˚ do feromonových lapaˇcu. ˚

•

provádˇet stejné úkony jako uživatel vinaˇr.

ˇ 3.1.3 Clen svazu Uživatel s oprávnˇením cˇ len svazu má právo: •

cˇ íst obsah urˇcený jen jeho kategorii, vˇcetnˇe oznámení a aktualit pro cˇ leny svazu.

•

upravovat kontaktní informace k asociovanému cˇ lenskému vinaˇrskému podniku.

•

ˇ a vkládat data z/do centrální meteorologické databáze. Císt

•

provádˇet stejné úkony jako externí uživatel.

3.1.4 Externí uživatelé Externí uživatel muže: ˚ •

cˇ íst obsah urˇcený jen jeho kategorii, vˇcetnˇe signalizaˇcních zpráv

•

tento uživatelský úˇcet je pro neˇcleny svazu vytváˇren za poplatek, který pokrývá náklady na zpˇrístupnované ˇ služby

•

mˇenit své údaje, jako login, heslo, kontakt.

ˇ 3.1.5 Ctenáˇ r obsahu ˇ Ctenáˇ r obsahu muže: ˚ •

cˇ íst veˇrejný obsah, vˇcetnˇe kontaktu˚ na cˇ lenské podniky a pˇrehledu aktuálních náletu˚ obaleˇcu do feromonových lapaˇcu˚ a veˇrejné cˇ ásti meteorologické mapy.

11

ˇ 3.2. POŽADAVKY NA UŽIVATELNOST V CETN Eˇ GRAFICKÉHO NÁVRH PORTÁLU

3.2

Požadavky na uživatelnost vˇcetnˇe grafického návrh portálu

Dnešní spoleˇcnosti, pokud chtˇejí uspˇet v konkurenˇcním boji, musejí mít celistvé rˇ ešení designu, tzv. corporate design. Corporate design pomáhá spoleˇcnostem v budování image nutného pro komunikaci s potenciálními zákazníky, partnery i veˇrejností pˇres jednotný vizuální styl. Na trhu existují ruzné ˚ spoleˇcnosti, zabývající se tvorbou corporate designu. Jednou z takovýchto spoleˇcností je napˇr. Jihomoravské inovaˇcní centrum,1 které nabízí pro zaˇcínající podniky produktový vizuální styl, který obsahuje: •

návrh loga spoleˇcnosti

•

návrh a tisk vizitek

•

návrh dopisního papíru

•

návrh webových stránek

•

návrh stylu PowerPoint prezentace

Obrázek 3.1: Logo Svazu Integrované produkce Dle požadavku˚ Svazu Integrované produkce hroznu˚ a vína se návrh portálu rˇ ídil celkovˇe novým corporate designem, který na požadavek vedení svazu vytvoˇril pan Ing. Michal Stránský. Souˇcástí zavádˇení nového corporate designu svazu IP bylo tedy i vytvoˇrení nového portálu svazu. Navržený design portálu bylo nutné upravit tak, aby pokud možno splnoval ˇ všechna ˇ doporuˇcení Ministerstva informatiky CR (pravidla tvorby pˇrístupného webu). Pˇri konzultacích s designérem SIPHV se vytvoˇrila designová koncepce portálu tak, že rozsáhlejší textový obsah bude vždy pˇrístupný v souboru formátu PDF z toho duvodu, ˚ aby byl nejen snadno tisknutelný, ale aby zachovával celkový vizuální styl obsahu. Tato cˇ ást návrhu portálu byla tudíž v rozporu s pravidly pro tvorbu pˇrístupného webu, nebot’ zadavatel dal pˇrednost grafickému stylu pˇred pˇrístupností. Následné používání portálu v praxi neukázalo, že by porušení tohoto pravidla cˇ inilo uživatelum ˚ výraznˇejší problémy. Vˇetšinu informací, jako napˇr. formuláˇre, situaˇcní zprávy a popisy škudc ˚ u˚ uživatelé cˇ asto tisknou a volba formátu PDF byla pro toto použití více než vhodná. 1. Jihomoravské inovaˇcní centrum

12

ˇ 3.2. POŽADAVKY NA UŽIVATELNOST V CETN Eˇ GRAFICKÉHO NÁVRH PORTÁLU Požadavkem zadavatele na uživatelnost bylo také zpˇrístupnˇení neveˇrejného obsahu pouze oprávnˇenému uživateli, vždy jen po úspˇešném pˇrihlášení a to tak, aby se daný styl zobrazování stránek po pˇrihlášení výraznˇe nemˇenil. Dalším požadavkem SIPHV na uživatelnost portálu byla pˇrístupnost k obsahu stránek bez dalších nutných technologií z hlediska klientského poˇcítaˇce a to tak, aby se styl stránek zobrazoval ve všech typech prohlížeˇcu˚ bez problému a pokud možno stejnˇe. Po analýze obsahu starého portálu a potˇreb svazu byla vytvoˇrena následující struktura menu portálu, kterou pak designér portálu umístil do dvou navigaˇcních panelu. ˚ V levém navigaˇcním panelu se zobrazují tyto položky: Svaz integrované produkce hroznu˚ a vína - SIPHV Zde uživatel nalezne informace týkající se Svazu IP, jako je seznam cˇ lenu˚ svazu, kontakty, smˇernice, doporuˇcení svazu a projekty, na nichž se svaz IP podílí nebo podílel. Vinná réva, choroby a škudci ˚ Obsah této sekce menu nabízí veškerý popis fyziologických poruch, škudc ˚ u˚ a chorob révy vinné vˇcetnˇe informací na jejich ochranu. Veškeré informace jsou dodány v tisknutelné verzi PDF z Obrazového atlasu chorob a škudc ˚ u˚ ovocných dˇrevin a révy vinné se souhlasem vydavatele. Dokumenty ke stažení Zde jsou ke stáhnutí dokumenty týkající se SIPHV, státního zemˇedˇelského intervenˇcního fondu, legislativa týkající se agroenvironmentálního opatˇrení a pro cˇ leny svazu také pˇrednášky již probˇehlých semináˇru˚ Zdroje a odkazy z oblasti vinaˇrství Poslední cˇ ástí levého panelu navigaˇcního menu je malý rozcestník na pˇríbuzné servery z oblasti vinaˇrství a na portály státní správy, související s IP. V pravém navigaˇcním panelu poradenského portálu se zobrazují tyto tˇri položky: Aktuality Zde uživatel nalezne aktuální informace, novinky, upozornˇení a pozvánky. Poˇcasí Obsah této sekce menu nabízí odkaz na informace týkající se poˇcasí, jeho charakteristiky a zajímavosti o nˇem. Služby Poslední a nejobsáhlejší položka pravého navigaˇcního panelu obsahuje poskytované služby jako pravidelné Signalizaˇcní zprávy, informace o náletech obaleˇcu˚ do feromonových lapaˇcu˚ a on line meteorologickou mapu vinic.

13

3.3. POŽADAVKY NA ARCHITEKTURU SYSTÉMU

3.3

Požadavky na architekturu systému

Architektura je dle slovníku výpoˇcetní techniky [8]všeobecné oznaˇcení urˇcující celkovou strukturu a základní konstrukci cˇ ástí nebo kompletního poˇcítaˇcového systému. V pˇrípadˇe architektury internetového portálu se jedná o zpusob ˚ rozdˇelení výstupních stránek, struktury dat a datových toku˚ do logických celku˚ a stanovení vzájemných vztahu˚ a interakcí mezi nimi, a to pokud možno na dostateˇcnˇe obecné úrovni. Je zˇrejmé, že se k návrhu a volbˇe architektury musí pˇristupovat na samém poˇcátku vývoje jakékoliv aplikace a to s velkou opatrností a rozmyslem. Jakékoliv pozdˇejší zmˇeny architektury jsou totiž velmi komplikované nebo témˇerˇ nemožné. Pˇri analýze požadavku˚ a návrhu systému vyvstaly tyto požadavky na architekturu celého portálu:

Možnost rozšíˇrení aplikace za chodu Pˇri vytváˇrení plánu konstrukce celého systému bylo od zadavatele požadováno tvoˇrení nových funkcionalit již za ostrého bˇehu portálu. To kladlo velký požadavek na architekturu, aby se systém mohl bˇehem chodu systému doplnovat ˇ a pˇrípadnˇe i pˇrepisovat nˇekteré funkcionality. Znovupoužitelnost funkcí Nˇekteré funkce portálu, které jsou cˇ asto používány je dobré používat na více místech. Robustnost portálu Robustní aplikace se vyznaˇcují spolehlivostí nebo napˇr. schopností nepˇretržitého provozu 24 hodin dennˇe, 7 dní v týdnu. Tento požadavek byl kritický, protože byl v rozporu s požadavkem na možnost rozšiˇrování aplikace za bˇehu. Bylo nutné proto minimalizovat v návrhu architektury výpadky a nedostupnost systému pˇri jakýchkoliv zmˇenách na vyšší verze, stejnˇe jako i nutnost konzistence dat pˇri pˇrechodech mezi verzemi systému. Samotný portál byl témˇerˇ celý vystavˇen za ostrého bˇehu s uživatelskými daty. Komponentová - modulární architektura Komponentová architektura rozdˇeluje celý systém do komponent. Komponenta obsahuje logicky zapouzdˇrenou funkcionalitu s jasnˇe definovaným rozhraním, která muže ˚ být v pˇrípadˇe potˇreby kdykoliv nahrazena a na druhou stranu muže ˚ být opakovanˇe nasazena v ruzných ˚ jiných aplikacích. Komponenty se mohou v pˇrípadˇe rozsáhlejších systému˚ logicky sdružovat do modulu˚ a ty pak do subsystému. ˚ Tímto zpusobem ˚ je pak vytvoˇrena hierarchická struktura systému, subsystému, ˚ modulu˚ a komponent. Komponentová architektura vytváˇrených aplikací umožnuje ˇ jednoduše, rychle a levnˇe upravovat chování stávajících komponent a pˇridávat další komponenty v souladu s rostoucími požadavky uživatele aplikace, což bylo jedním z hlavních požadavku. ˚ 14

3.3. POŽADAVKY NA ARCHITEKTURU SYSTÉMU

Nadstandardní hosting portálu Dalším z podmínek vyplývající z požadavku na vyvíjení aplikace za bˇehu je nutnost mít nadstandardní hosting pro portál, který umožní neomezený pˇrístup k aplikaci portálu, restart cˇ ástí nebo celé aplikace a dolad’ování aplikaˇcního serveru za chodu.

15

Kapitola 4

Zvolená architektura rˇešení Nyní bych se rád zastavil nad zvolenou architekturou rˇ ešení. Pro celkový návrh aplikace jsem zvolil architektonický návrhový vzor Model - View - Controller, protože splnoval ˇ témˇerˇ veškeré požadavky, které byly na architekturu z uživatelských požadavku˚ na portál kladeny, cˇ i z nich vyplývaly. Návrhový vzor Model - View - Controller jsem aplikoval na serverovou platformu jazyka Java J2EE s použitím objektovˇe - relaˇcního frameworku Hibernate. Zvolený jazyk Java je vyspˇelý programovací jazyk, obsahující všechny vlastnosti, které jsou vyžadovány v moderním programování. Od modularity programu, rˇ ídících konstrukcí, pˇres silnou typovou kontrolu, multithreading, ošetˇrení výjimek, správu pamˇeti i silnou podporu pro databáze, XML a sít’ové operace. K jejím výhodám patˇrí, kromˇe již zmínˇené multiplatformity, robustnost, škálovatelnost a vysoká bezpeˇcnost, která jí profituje pro používání na kritické aplikace na mainfraimových poˇcítaˇcích. Obsah jazyka Java nelze omezit jen na výˇcet jejích pˇríkazu. ˚ Java je pˇredevším silnˇe objektová, což umožnuje ˇ v ní modelovat, vytváˇret, používat a rozšiˇrovat rozsáhlé knihovny a systémy. Právˇe objektovˇe je tˇreba myslet ne jen pˇri psaní programu, ale již pˇri návrhu a analýze.

4.1

Model - View - Controller

Architektonický vzor Model View Controller (dále MVC) [1] je velmi oblíbený zpusob ˚ návrhu aplikace, který má své koˇreny ve Smalltalku. Zde se puvodnˇ ˚ e používal pro zakomponování tradiˇcního postupu vstup–zpracování–výstup do GUI programu. ˚ Neménˇe vhodný je ale i pro použití ve vícevrstvých webových aplikacích. MVC se rozšíˇril zejména v oblasti jazyka Java a souvisejících technologií, ale je možné jej díky jeho obecnosti používat i v jakémkoliv jiném programovacím jazyce.[6] MVC rozdˇeluje aplikaci na tˇri logické cˇ ásti: Model, View a Controller. Každá cˇ ást je pak v aplikaci odpovˇedná za definovanou cˇ ást aplikace. Model je funkˇcním a datovým základem celé aplikace. Poskytuje prostˇredky jak pro pˇrístup k datové základnˇe a stavum ˚ aplikace, tak pro jejich ukládání a aktualizaci. Model se dá pokládat za softwarový obraz objektu˚ a procesu˚ reálného svˇeta. Model by mˇel být 16

4.1. MODEL - VIEW - CONTROLLER jako celek zapouzdˇrený a pro View a Controller nabízet pˇresnˇe definované rozhraní. Nejˇcastˇeji je implementován pomocí objektu˚ v rámci objektovˇe orientovaného programování (OOP). V pˇrístupech odlišných od OOP jej lze realizovat napˇríklad i bˇežnými funkcemi. Na své nižší vrstvˇe je samozˇrejmˇe tvoˇren nˇejakou formou úložištˇe dat, nejˇcastˇeji v objektové implementaci persistentní objektovou tˇrídou. Tato tˇrída pak muže ˚ být uložena bud’ pˇrímo v objektové databázi, nebo pomocí mapování v databázi relaˇcní. View zobrazuje uživateli obsah Modelu, zajišt’uje grafický cˇ i jiný výstup aplikace. View pˇristupuje pˇres Model k datum ˚ a stavum ˚ aplikace a sám specifikuje, jak mají být prezentovány. Pˇri zmˇenˇe stavu Modelu View aktualizuje zobrazení. U webových aplikací generuje View pˇríslušný HTML kód, který je odeslán prohlížeˇci jako odpovˇed’ na požadavek. Jestliže slouží zobrazený výstup zárovenˇ jako oblast pro zachytávání událostí od uživatele (napˇríklad kliknutí myší na daný odkaz ve vykresleném navigaˇcním oknˇe), pˇredává View tyto události Controlleru. Controller definuje chování aplikace. Zpracovává veškeré vstupy a události pocházející od uživatele. Na jejich základˇe volá pˇríslušné procesy Modelu, mˇení jeho stav apod. Podle událostí pˇrijatých od uživatele i podle výsledku˚ akcí v Modelu pak vybírá Controller vhodné View pro další zobrazení. Pro webové aplikace jsou hlavním vstupem Controlleru HTTP GET nebo POST požadavky odeslané uživatelovým prohlížeˇcem.

Obrázek 4.1: Nákres MVC architektonického vzoru, pˇrevzato[7] Mezi hlavní výhody MVC patˇrí:.[1][6] 17

4.2. IMPLEMENTACE MVC •

snadné zpˇrístupnˇení pro ruzné ˚ druhy klientu. ˚ Pro zavedení podpory dalšího klienta je nutné nadefinovat pouze nové View, v pˇrípadˇe zcela rozdílných vstupních událostí i speciální Controller. Nicménˇe Model jako klíˇcová cˇ ást aplikace zustává ˚ stále stejný.

•

minimalizace duplicitního kódu. Souvisí cˇ ásteˇcnˇe s pˇredchozím bodem. Napˇríklad bez oddˇelení a zapouzdˇrení Modelu by se pro každé nové View musela znovu programovat celá aplikaˇcní logika. Ale i v rámci jednoho typu klienta je cˇ asto jedna akce volána z nˇekolika ruzných ˚ míst aplikace.

•

vysoká komplexnost návrhu a snadná budoucí rozšiˇritelnost aplikace, efektivní modularita, snadné rozdˇelení systému do komponent.

•

cˇ istota designu aplikace, snadnˇejší zpusob ˚ pˇremýšlení programátora nad aplikací, jejím návrhem a architekturou. [1]

V rámci MVC se dále rozlišuje mnoho strategií, jak výslednou aplikaci koncipovat. Liší se napˇríklad poˇctem Controlleru˚ a rozdˇelením úkolu˚ mezi nimi, použitím cˇ i nepoužitím šablon v rámci View, jednotným zapouzdˇreným voláním datových zdroju˚ apod. MVC je velice rozšíˇrený a oblíbený pˇrístup k návrhu aplikace. Jak již bylo rˇ eˇceno, používá se zejména v oblasti jazyka Java. [7] Zde je Model obvykle realizován tˇrídami definovanými v JavaBeans komponentách. View jsou generovány pomocí JavaServer Pages (JSP), Controller pak bývá implementován jako skupina servletu. ˚ Místo mnoha ruzných ˚ servletu˚ muže ˚ být také jeden hlavní servlet jako Front Controller. Nejrozšíˇrenˇejšími frameworky poskytujícími vlastní Controller jsou v dnešní dobˇe Apache Struts1 a SpringFramework.2

4.2

Implementace MVC

V této podkapitole bych rád seznámil s implementací jednotlivých cˇ ástí MVC vzoru v rˇ ešení portálu SIPHV. 4.2.1 Model - Hibernate framework K implementaci modelu byly použity persistentní i nepersistentní tˇrídy, které reprezentují jednak objekty reálného svˇeta, ale i funkcionalitu nabízenou systémem. Pro zajištˇení persistence objektových tˇríd byl použit objektovˇe - relaˇcní framework Hibernate. Tento framework výraznˇe snižuje požadavky na práci nad databází. V dnešní dobˇe dobˇe se pˇri vývoji rozsáhlejších aplikací nejˇcastˇeji používá objektovˇe orientovaný pˇrístup, zatímco data jsou ukládána v relaˇcních databázích. V objektovˇe orientovaném a relaˇcním pˇrístupu však existují znaˇcné rozdíly. Podle ruzných ˚ studií je zhruba 70% cˇ asu 3 (na stránkách <www.hibernate.org> dokonce tvrdí, že 95%) stráveného pˇri vývoji 1. http://struts.apache.org 2. http://www.springframework.org 3. <www.hibernate.org>

18

4.2. IMPLEMENTACE MVC aplikací vˇenováno psaní kódu, který se zabývá udržováním persistentních dat. Hlavní snahou je tedy oddˇelit vlastní logiku aplikací od konkrétního zpusobu ˚ uložení dat. Tedy od konkrétní databáze, at’ už relaˇcní cˇ i objektové. Hibernate je nástrojem, který poskytuje objektovˇe relaˇcní mapování (ORM) pro javovské prostˇredí a novˇe také pro platformu .NET. Pod ORM se skrývá technika mapování dat, jež jsou reprezentována javovskými tˇrídami, na relaˇcní struktury reprezentované databázovými tabulkami. Kromˇe toho také Hibernate umožnuje ˇ získávání databázových dat na základˇe vlastního, plnˇe objektovˇe orientovaného jazyka, nazvaného Hibernate Query Language (HQL), který je syntakticky velmi podobný SQL.Hibernate Query Language (HQL) je ale na rozdíl od SQL plnˇe objektovˇe orientovaný. Stejnˇe jako SQL, tak i HQL nerozlišuje velikosti znaku˚ pˇri psaní dotazu˚ až na názvy javových tˇríd a vlastností. Pomocí HQL mužeme ˚ také tvoˇrit o poznání složitˇejší dotazy než naˇctení libovolného objektu. Mužeme ˚ použít vˇetšinu konstrukcí z ANSI SQL: polymorfismus, parametrizované dotazy, javové konstanty a mnoho dalších podporovaných vlastností. Hibernate poskytuje programátorum ˚ aplikací jednoduché API, které umožnuje ˇ mapování objektu˚ do 20 podporovaných relaˇcních databází. V dokumentaci doporuˇcují tvurci ˚ použití hibernate jako persistentní vrstvu ve dvou nejbˇežnˇejších architekturách: ve dvouvrstvé webové architektuˇre Model/View/Controller k persistenci javovských beanu˚ používaných servlety/JSP a v enterprise (tˇrívrstvé) architektuˇre. Jelikož je Hibernate navržen pro práci v mnoha odlišných prostˇredích, existuje pro nˇej velké množství konfiguraˇcních parametru. ˚ Pro nastavení frameworku Hibernate byl použít standardní konfiguraˇcní XML soubor nazvaný hibernate.cfg.xml, který nastavuje Hibernate pro práci s MySQL databází pomocí JDBC spojení. <session-factory> <property name="connection.driver_class"> com.mysql.jdbc.Driver <property name="connection.url"> jdbc:mysql://jmeno_serveru:3306/jmeno_databaze <property name="dialect"> net.sf.hibernate.dialect.MySQLDialect <property name="connection.username">uzivatel <property name="connection.password">heslo <mapping resource="FolderImpl.hbm.xml"/> <mapping resource="DocumentImpl.hbm.xml"/> <mapping resource="VineDresser.hbm.xml"/>

19

4.2. IMPLEMENTACE MVC <mapping resource="UserImpl.hbm.xml"/> <mapping resource="Url.hbm.xml"/> <mapping resource="Image.hbm.xml"/> .....

Javové tˇrídy perzistentnˇe mapované na tabulky relaˇcní databáze jsou jednoduché JavaBeany, které musí obsahovat bezparametrický konstruktor a "getter/setter" metody pro každou jejich vlastnost. Mapování javových tˇríd na databázové tabulky se provádí pomocí XML souboru umístˇeného v adresáˇri s mapovanými tˇrídami. Tˇechto XML souboru˚ muže ˚ být i více a jsou zaznamenány v konfiguraˇcním souboru hibernate.cfg.xml elementem <mapping resource = "jmenoTridy.hbm.xml" /> Uvádím pˇríklad mapování tˇrídy VineDresser - VineDresser.hbm.xml, která reprezentuje vinaˇrský podnik. <property name="name" not-null="true" /> <property name="adress" type="text"/> <property name="phone"/> <property name="email"/> <property name="web"/> <property name="note" type="text"/> <property name="folder" /> <set name="users" lazy="true" table="VDsUsers" inverse="false"> <many-to-many class="appserver.system.UserImpl" column="user_id"/> <set name="meteostats" inverse="true" lazy="true" order-by="name asc">

20

4.2. IMPLEMENTACE MVC V každé mapované tˇrídˇe musí být deklarovaný primární klíˇc. Každý perzistentní atribut této tˇrídy musí být zachycen elementem <property>, který jej mapuje na pˇríslušný atribut databázové tabulky. Atribut type pak urˇcuje typ této vlastnosti. Hibernate podporuje všechny základní javové datové typy, ale hodnota tohoto atributu muže ˚ být i javový objekt. Pokud není typ zadán, Hibernate se ho pokusí urˇcit sám. Souˇcástí mapování tˇríd muže ˚ být také zachycení jejich vzájemných vztahu˚ (1:1, 1:N, M:N) a další vlastnosti jako dˇediˇcnost a polymorfismus tˇríd. Pro efektivnˇejší práci s objekty v pamˇeti mužeme ˚ definovat, zda chceme naˇcíst celý objekt i s jeho vázanými objekty, nebo samotný objekt bez nich. Vázané objekty jsou pak nacˇ teny do pamˇeti až pˇri jejich samotném použití. Tento druhý pˇrístup zpoždˇeného, líného (lazy) nahrávání objektu˚ vyžaduje vˇetší poˇcet pˇrístupu˚ do databáze, ale menší pamˇet’ovou nároˇcnost pro velké hierarchické struktury objektu. ˚ V rˇ ešení architektury bylo více použito zpoždˇeného nahrávání objektu˚ pro efektivnˇejší práci s pamˇetí, nebot’ provázanost objektu˚ v modelu je veliká. Hibernate provádí zmˇenu objektu dat do databáze ihned po provedení. Mužeme ˚ ale také v konfiguraci nastavit, aby se zmˇena dat na objektu projevila až pˇri mazání objektu z pamˇeti. Tato druhá možnost ale není vhodná pro rozsáhlejší systémy, které pracují souˇcasnˇe nad stejnými, sdílenými daty. Hibernate totiž pˇri zápisu zmˇenˇeného objektu do databáze zneplatní tytéž objekty a nahradí je v pamˇeti novˇejšími. Opoždˇený zápis do databáze tak zvyšuje riziko možných kolizí. Pro provádˇení složitˇejších synchronizaˇcních operací persistentních objektu˚ s databází umožnuje ˇ Hibernate používat transakˇcní manažer - TransactionManager, který provedený sled operací provede v rámci jedné transakce. U databázových systému, ˚ které umožnují ˇ transakˇcní zpracování Hibernate užívá jejich transakˇcního zpracování, u databázových systému˚ neumožnujících ˇ transakce, transakci provede TransactionManager. Na základˇe definice mapování tˇríd vygeneroval hibernate automaticky databázovou strukturu, která je znázornˇena v ERD diagramu v pˇríloze.A.1 4.2.2 View View je implementován pomocí Java Server Pages(JSP). JSP je technologie od spoleˇcnosti Sun Microsystems pro tvorbu dynamických webových stránek na platformˇe Javy (J2EE). JSP stránky jsou souˇcástí javovské web aplikace. Webovská aplikace Javy má tyto cˇ ásti: •

Servlety

•

JSP stránky

•

Podpurné ˚ knihovny

•

Deployment descriptor 21

4.2. IMPLEMENTACE MVC Dokument JSP je kombinací pˇríkazu˚ jazyka Java a formátovacích znaˇcek HTML, které jsou pˇri prvním zavolání pˇreloženy do jazyka Java do formy servletu Tento servlet je pak pˇreložen do proveditelného Java byte kódu JSP umožnuje ˇ pracovat s libovolnými, námi deklarovanými Java objekty cˇ i mnoha implicitními objekty, definovanými pro Java Server Pages. Uvádím zde pˇríklad nˇekolika nejˇcastˇeji užívaných implicitních objektu. ˚ •

request (požadavek) – instance rozhraní HttpServletRequest. Zavoláním tohoto implicitního objektu mužeme ˚ zjistit informace o pˇríchozím požadavku.

•

response (odezva) – instance rozhraní HttpServletResponse. Informace o odpovˇedi jsou ukládány do tohoto implicitního objektu, lze nastavovat vlastnosti odpovˇedi.

•

out (výstup) – instance tˇrídy jspWriter. Metody print(), println() – pˇridání textu do webového dokumentu.

•

session (sezení) – instance tˇrídy HttpSession. Nese informace o uživateli a jeho datech mezi jednotlivými požadavky.

O technologii Java Server Pages by se dalo psát do detailu hodnˇe zajímavého, nebot’ je to technologie robustní a perspektivní pro užití v mnoha webových aplikacích. Rád bych se ale také zmínil o architektonické implementaci Controlleru pomocí Javy. 4.2.3 Controller Controller je v portálu SIPHV implementován pomocí Java servletu, který je základem web aplikace. Servlet je obdoba CGI napsaná v Javˇe. Pˇresnˇeji je to tˇrída odvozená z javax.servlet.Servlet respektive javax.servet.http.HTTPServlet. Oproti tˇemto skriptum ˚ má Java servlet tyto výhody: •

Servlet je jednou zkompilován a naˇcten do pamˇeti, potom už jenom odpovídá na požadavky klientu˚ (takže je rychlejší než PHP nebo ASP, natož pak CGI).

•

Servlet je Java program, máte tedy pˇrístup ke všem možnostem tohoto jazyka (až na gui).

•

Servlet bˇeží v prostˇredí aplikaˇcního serveru, který mu zprostˇredkovává užiteˇcné služby (napˇr. poolování pˇripojení do databáze, bezpeˇcnost, ...).

•

Servlet je nezávislý na protokolu.

Na implementaci množství servletu˚ pro controller lze použít jeden z výše uvedených frameworku˚ Apache Struts nebo Spring. Tyto frameworky umožnují ˇ snazší komunikaci mezi View a Controllerem a umožnují ˇ užívat množství rozšíˇrení pro JSP i servlety, jako vlastní knihovnu znaˇcek v JSP, Java beans, validaci vstupu, ... 22

4.2. IMPLEMENTACE MVC Pro implementaci controlleru žádný framework užit nebyl, nebot’ v dobˇe startu realizace portálu bylo nutné zrealizovat portálovou cˇ ást v krátkém cˇ ase (horizont týdnu) ˚ do zaˇcátku sezóny 2005. Použití mnou zatím nepoužívané technologie frameworku bylo znaˇcným rizikem úspˇešného spuštˇení ostrého provozu aplikace. V rámci každé jednotlivé komponenty jsou tak controller i view implementované bez použití nˇekterého MVC frameworku. Dodržení MVC vzoru v rámci každé komponenty ale dává do budoucnosti možnost libovolnou komponentu pˇreimplementovat (controller i view) pomocí libovolného frameworku.

4.2.4 Struktura webovské aplikace Adresáˇrová struktura Java web aplikace portálu, v nichž je implementována komponentová architektura spolu s MVC vzorem vypadá následovnˇe root +-statické stránky a obrázky +-jsp stránky +- jednotlivé komponenty (VIEW) ... +-WEB-INF +-web.xml (deployment descriptor) +-lib (adresáˇ r do kterého se dávají knihovny) + ... +-classes (adresáˇ r do kterého se dávají servlety a tˇ rídy modelu) +- servlet +- komponenty (CONTROLLER) ... +- appserver +- komponenty (MODEL) ....

Každá komponenta funkˇcnosti portálu má svuj ˚ controller implementován pomocí nˇekolika servletu˚ v jednom balíku tˇríd. Tyto servlety dohromady tak zapouzdˇrují funkˇcnost controlleru celé komponenty. Tyto servlety jako controller pak komunikují s view komponentou implementovanou pomocí kolekce JSP stránek, nacházejících se dohromady v jednom adresáˇri jsp stránek JSP stránky spolu s jejich servlety používají modelové tˇrídy logicky a fyzicky soustˇredˇené také do odpovídajícího balíku tˇríd, java package. Servlet a celá webovská aplikace bˇeží v servlet containeru aplikaˇcního serveru. Mezi nejznámˇejší servlet containery patˇrí Apache Tomcat, Jetty, Jboss, ... Další cˇ ásti java aplikaˇcního serveru je napˇr. enterprise java beans container. Pro bˇeh servlet containeru i dalších cˇ ástí aplikaˇcního serveru je tˇreba mít nainstalovaný Java Development Kit (JDK). 23

ˇ 4.3. ALTERNATIVNÍ REŠENÍ ARCHITEKTURY PORTÁLU - POUŽITÍ CMS 4.2.5 Hosting aplikace Bˇehem návrhu architektury aplikace bylo nutné také vyˇrešit otázku, na kterém serveru provozujícím Servlet/JSP Container, má být samotná aplikace provozována a pˇrípadnˇe s použitím jakého databázového stroje. Jelikož kvalitních a cenovˇe dostupných hostingu˚ pro hostování java web aplikací nebylo v dobˇe implementace aplikace dostatek, bylo nutné vˇenovat úsilí získání dobrého hostingu pro vznikající aplikaci s možností mít vlastní pˇrístup k aplikaˇcnímu serveru a samotnému Servlet/JSP Containeru. Vˇetšina hostingu˚ pro javu provádí deploy (nahrání) aplikací do containeru max. jednou dennˇe pˇri jeho pravidelném restartu. Toto rˇ ešení standardního hostingu by bylo velkým rizikem pro vývoj aplikace za ostrého bˇehu, nebot’ pˇri neúspˇešné zmˇenˇe systému na vyšší by byl systém nefunkˇcní celých 24 hodin, než by bylo možné se vrátit k starší funkˇcní verzi. Toto riziko bylo vyˇrešeno díky panu RNDr. Miroslavu Kˇrípaˇcovi, který spravuje server artemon.cz. Tento menší server poskytuje hostingové služby pro úzký okruh zákazníku˚ hlavnˇe v oblasti yachtingu. Na serveru artemon.cz tedy mohl být zprovoznˇen containter Apache Tomcat verze 5.5.9 pro provoz javovské webové aplikace. Jako databázový server byl použit již na serveru používaný MySQL verze 3.23.58. Na tomto hostingu byl vytvoˇren omezený ssh pˇrístup, který dovoloval provádˇet restart servlet containeru pomocí servlet containeru skriptu kdykoliv bylo potˇreba,. Jelikož naše aplikace byla jedinou java web aplikací, tak pˇrípadný restart Apache Tomcatu neohrožoval okolní zákazníky.

4.3

Alternativní rˇešení architektury portálu - použití CMS

Pˇri návrhu a volbˇe architektury byla zvažována následující alternativní možnosti vývoje portálu a celkové realizace. Pro celkovou realizaci portálu na správu jeho obsahu a uživatelu˚ se nabízela možnost použít nˇekterý stávající volnˇe šiˇritelný redakˇcní systém, tzv. content managment system (CMS). Mezi takové redakˇcní systémy patˇrí napˇríklad open source projekt (pod GNU/GPL licencí) Joomla4 , který je následovníkem úspˇešného mambo redakˇcního systému, PHPWebSite5 z dílny Apalachian State University, nebo PHP Nuke 6 a jeho cˇ eská alternativa United Nuke.7 Tyto redakˇcní systémy umožnují ˇ pomocí administrativního rozhraní oddˇelenˇe spravovat obsah stránek od jejich stylu zobrazování. Výsledný vzhled stránky portálu se definuje pomocí šablon a dá se v prubˇ ˚ ehu mˇenit. Vˇetšina CMS systému˚ umožnuje ˇ editovat obsah pomocí on line WYSIWYG (What You See Is What You Get, neboli co vidíš to dostaneš) HTML editoru. Editor, který svojí funk4. 5. 6. 7.

Joomla PHPWebSite PHPNuke UnitedNuke

24

ˇ 4.3. ALTERNATIVNÍ REŠENÍ ARCHITEKTURY PORTÁLU - POUŽITÍ CMS cionalitou a vzhledem pˇripomíná textový procesor, v on line formuláˇri formátuje všechen psaný text do HTML znaˇcek. Díky tomu se systémem muže ˚ pracovat uživatel bez znalosti HTML.Takto spravovaný obsah stránek se pak ukládá do relaˇcní databáze, odkud jej CMS zobrazuje pˇrímo do stránek portálu. Mezi další, nejˇcastˇeji nabízené funkcionality nejen volnˇe šiˇritelných redakˇcních systému˚ patˇrí: •

Diskusní skupiny

•

Dotazy a odpovˇedi (FAQ)

•

Novinky

•

Odkazy do Internetu

•

Rozesílání novinek emailem

•

RSS kanál pro zobrazování novinek

•

Správa uživatelu˚ a definice jejich práv pro pˇrístup k obsahu

•

Správce souboru˚ pro upload a download

•

Správce menu a vzhledu portálu

•

WYSIWYG html editor Použití existujícího CMS pro portál SIPHV by mˇelo tyto výhody

•

Již implementované administrativní rozhraní pro cˇ ást obsahovou portálu

•

Cenovˇe dostupné rˇ ešení, které lze snadno nakonfigurovat dle vlastních potˇreb

•

Modulární architektura - vˇetšina CMS umožnuje ˇ pˇridávat samostatné moduly a komponenty pro daný CMS

•

Dostupný web hosting pro tyto CMS (PHP, MySQL) Avšak duvody, ˚ proˇc nebylo použito existujícího redakˇcního systému byly následující:

CMS je jen cˇ ástí celého rˇešení portálu. Mezi další cˇ ásti rˇ ešené mimo správu obsahu portálu patˇrí online databáze meteorologických dat, která je propojena s databází cˇ lenu˚ svazu, a uživatelu˚ a online pˇrístup k aktuálním náletum ˚ škodlivého hmyzu do feromonových lapaˇcu. ˚ 25

ˇ 4.3. ALTERNATIVNÍ REŠENÍ ARCHITEKTURY PORTÁLU - POUŽITÍ CMS

GNU GPL licence volnˇe šiˇritelných CMS Volnˇe pˇrístupné CMS jsou nabízeny v GNU GPL licenci. V rámci této licence je šíˇrený program poskytován zdarma. K dispozici k programu je i zdrojový kód. Pokud kód ovšem použijete ve svém projektu, musíte jej automaticky také šíˇrit pod licencí GNU GPL a dávat k dispozici svuj ˚ zdrojový kód. Takto vydávaný program mužete ˚ používat bez omezení jak v komerˇcním, tak i nekomerˇcním prostˇredí. Jelikož pro implementaci dalších funkcí portálu by bylo tˇreba užít zdrojového kódu šírˇ eného pod GNU GPL licencí, také další vytváˇrené moduly a komponenty portálu by musely být šíˇreny v rámci GNU GPL spolu se zdrojovými kódy. Zpˇrístupnˇení zdrojového kódu tˇechto funkcionalit ovšem bylo pro Svaz IP nepˇrípustné. Svoji roli v tomto rozhodnutí hrálo i riziko využití cˇ ásti nebo celého rˇ ešení z rˇ ad chemickoprumyslové ˚ lobby, která se snaží také nabízet prognostické služby, nebo z rˇ ad podniku˚ mimo svaz IP. Nepˇrístupnost ke zdrojovému kódu u placených CMS Pˇrípadné zakoupení nˇekterého z placených redakˇcních systému˚ se také nejevilo jako vhodné rˇ ešení. Svaz IP by nemˇel pˇrístup ke zdrojovým kódum ˚ redakˇcního systému a implementace nových funkcionalit by tak byla velmi obtížná a platformovˇe závislá. Problémem by také byl i hosting takovýchto placených redakˇcních systému, ˚ nebot’ ten je nabízen a úzce spjat spolu s jeho užíváním. Používání PHP v CMS Veškeré známe CMS systémy jsou psány ve skriptovacím jazyce PHP. Tento jazyk nelze považovat za ryze objektový a pˇrípadné užití MVC vzoru pro rˇ ešení dalších funkcionalit není portálu pˇríliš podporováno jako v Java platformˇe. Na základˇe analýzy a oponentury architektury portálu bylo zvoleno vytvoˇrení vlastního redakˇcního systému v Javˇe jako souˇcástí rˇ ešení celého portálu a nevyužití stávajících rˇ ešení redakˇcních systému. ˚

26

Kapitola 5

Správa obsahu portálu V této kapitole jsou popisovány vytvoˇrené komponenty portálu, které slouží pro správu obsahu, uživatelu˚ a kontaktu˚ na cˇ leny svazu a to z hlediska funkˇcnosti, návrhu a implementace.

5.1

Správa uživatelu˚

Mezi požadavky na správu obsahu portálu patˇrí vždy administrativní cˇ ást pro správu uživatelu. ˚ Správa uživatelu˚ zahrnuje pro administrátora možnosti spravovat uživatelské úˇcty pro pˇrístup k obsahu portálu. Uživatelé systému jsou kategorizováni do cˇ tyˇr úrovní dle oprávnˇení, jak lze pˇreˇcíst v analýze požadavku˚ na portál 3.1 Uživatelské úˇcty mohou mít svoji platnost definovanou jen na urˇcitý cˇ asový úsek. Jedná se zvláštˇe o uživatele z rˇ ad platících zákazníku˚ za služby pro jednotlivou sezónu. Mezi platící uživatele patˇrí vˇetšinou vinaˇrské obce, které se snaží v rámci své místní samosprávy informovat pˇestitele vína z rˇ ad obˇcanu˚ obcí. Administrátor v rámci správy uživatelu˚ muže ˚ Vytvoˇrit uživatelský úˇcet Po vyplnˇení povinných údaju˚ administrátorem (login, jméno, úrovenˇ oprávnˇení, e-mail), systém vygeneruje uživateli heslo a informace o vytvoˇrení úˇctu vˇcetnˇe hesla je zaslána uživateli na danou e-mailovou adresu. Uživatel pak má po pˇrihlášení možnost toto heslo si kdykoliv zmˇenit. Upravovat uživatelské úˇcty Administrátor má možnost pro libovolné uživatelské úˇcty upravovat jeho nastavení. Muže ˚ také prodlužovat platnost daného úˇctu. Odebrat uživatele Administrátor odstraní konkrétní uživatelský úˇcet ze systému. V pˇrípadˇe, že je daný uživatelský úˇcet asociovaný s konkrétním cˇ lenským podnikem svazu, je spolu s uživatelem odstranˇena i tato asociaˇcní vazba. Zobrazit uživatele pro export a tisk Administrátor si muže ˚ zobrazit dané uživatele ve formátu pro tisk. Takto zobrazený textový formát seznamu uživatelu˚ lze snadno exportovat napˇríklad do tabulkového procesoru Microsoft Excel, cˇ i OpenOffice Calculator. 27

ˇ ˚ SVAZU 5.2. SPRÁVA CLEN U Uživatel s vytvoˇreným uživatelským úˇctem pak muže ˚ po úspˇešném pˇrihlášení na úvodní stránce svazu pˇristupovat k obsahu a službám, ke kterým je oprávnˇen. V pˇrípadˇe zadání nesprávného hesla cˇ i pˇrihlašovacího jména je po krátké prodlevˇe uživatel upozornˇen na svuj ˚ omyl. Tato krátká prodleva tak zabranuje ˇ možným pokusum ˚ o útok hrubou silou na prolomení uživatelského jména a hesla. Za vˇetší a pravdˇepodobnˇejší bezpeˇcnostní riziko, než pokusy o útok hrubou silou Svaz Integrované produkce pokládá možnost sdˇelování pˇrihlašovacích údaju˚ tˇretím osobám, zvláštˇe od platících uživatelu. ˚

5.2

Správa cˇ lenu˚ svazu

Jelikož svaz integrované produkce je tvoˇren cˇ lenskými vinaˇrskými podniky, které jsou v reálném svˇetˇe jak podnikajícími fyzickými osobami nebo velkými vinaˇrskými závody o mnoha zamˇestnancích. Z tohoto duvodu ˚ bylo tˇreba vytvoˇrit samostatnou databázi cˇ lenu˚ svazu tak, aby jednotlivý vinaˇrský podnik mohl mít k sobˇe asociovaný libovolný poˇcet uživatelu˚ portálu. Du˚ ležité bylo zachování informace o vazbˇe uživatel - cˇ len svazu. Tato vazba byla navržena 0,m:0,n. Systém tak umožnuje, ˇ aby vˇetší cˇ lenský podnik mˇel možnost mít asociováno více oprávnˇených uživatelu, ˚ napˇríklad z rˇ ad zamˇestnancu. ˚ V budoucnosti se dá také oˇcekávat, že díky možnosti cˇ erpání dotací na ruzné ˚ druhy agroenvironmentálních opatˇrení muže ˚ jedna fyzická osoba být zˇrizovatelem více podniku˚ produkujících víno v rámci integrované produkce. ˇ Clenský podnik má také asociovánu právˇe jednu složku, pro internetový obsah, zobrazitelnou na portálu. Do této složky se již ukládá struktura informací k meteostanicím daného podniku a v budoucnosti bude mít vinaˇrský podnik možnost ukládat sem a publikovat i informace a soubory týkající se jeho cˇ innosti v rámci integrované produkce. Funkcionalita správy webového obsahu pro cˇ leny svazu v asociované složce k danému cˇ lenskému podniku bude implementována po detailnˇejším prostudování požadavku˚ v pru˚ bˇehu sezóny 2006, nebot’ jednotlivé hodnotící zprávy, formuláˇre a povinný reporting podniku˚ se odevzdává vedení svazu až v prubˇ ˚ ehu podzimu a zimy každého roku. V souˇcasnosti ještˇe není jisté, zda se vedení Svazu integrované produkce podaˇrí prosadit mezi svými cˇ leny povinnost uvádˇet tyto údaje elektronickou formou pˇres vytvoˇrený portál. Podstatná cˇ ást uživatelu˚ z rˇ ad cˇ lenu˚ Svazu integrované produkce není pˇríliš naklonˇena užívání jim dosud neznámých a nových informaˇcních technologií. Pro tyto laické poˇcítacˇ ové uživatele, kteˇrí jsou ale odborníky v produkci vína, je tˇežké se uˇcit novinkám na poli informaˇcních technologií. Z poˇcítaˇcové gramotnosti vˇetšinou tito uživatelé maximálnˇe zvládnou cˇ íst a odesílat elektronickou poštu a cˇ íst obsah portálu po úspˇešném pˇrihlášení. Dalším problémem je nedostateˇcná dostupnost pˇripojení k internetu v malých obcích Jižní Moravy a malá vybavenost poˇcítaˇci u producentu˚ vína. Tuto problematiku cˇ ásteˇcnˇe rˇ ešil projekt svazu IP a Evropské unie prostˇrednictvím fondu PHARE v roce 2000. V rámci tohoto projektu byla vybavena cˇ ást cˇ lenských podniku˚ výpoˇcetní technikou spolu s meteorologickými stanicemi, 28

ˇ ˚ SVAZU 5.2. SPRÁVA CLEN U které slouží pro monitoring poˇcasí. Implementace jednotlivých funkcí správy obsahu portálu nejen z tohoto duvodu ˚ probíhá iterativním vývojem, kdy celá struktura systému, objektového a relaˇcního modelu byla vytvoˇrena již na zaˇcátku tvorby portálu a jednotlivé dílˇcí rozšiˇrující funkce a pˇrípady užití portálu jsou vytváˇreny v jednotlivých krocích a iteracích dle priority užívání. Pˇrípadná implementace této funkcionality není díky architektuˇre portálu nikterak složitá, nebot’ bude staˇcit využít model i controller od stávajícího redakˇcního systému a naimplementovat pouze view složku a rozšíˇrit controller metody na zobrazován administrativní cˇ ásti dle aktuálního pˇrihlášeného uživatele s oprávnˇením na úrovni vinaˇrského podniku.

Obrázek 5.1: Nákres UML diagramu tˇríd pro správu obsahu Administrátor v rámci správy cˇ lenu˚ svazu muže ˚

29

5.3. SPRÁVA OBSAHU PORTÁLU Vložit cˇ lenský podnik Po vyplnˇení povinných údaju˚ administrátorem pro cˇ lenský podnik (jméno, kontaktní údaje, název složky pro ukládání dat ), systém vytvoˇrí cˇ lenský podnik spolu s asociovanou složkou pro webový obsah. Po vytvoˇrení daného cˇ lena svazu je nabídnut pˇrímo pˇredvyplnˇený formuláˇr pro založení asociovaného uživatele k danému podniku. Upravovat údaje k cˇ lenskému podniku Administrátor má možnost upravovat kontaktní údaje k danému podniku svazu integrované produkce. V budoucnosti bude mít tuto možnost.i asociovaný uživatel. Vložit asociovaného uživatele Tato funkcionalita vloží k danému cˇ lenskému podniku asociovaného uživatele, který má pak právo spravovat informace k podniku a údaje k jeho meteostanicím. Zobrazit cˇ leny svazu pro export a tisk Administrátor si muže ˚ nechat zobrazit cˇ lenské podniky ve formátu pro tisk. Takto zobrazený textový formát seznamu cˇ lenu˚ svazu lze také snadno exportovat jako u seznamu uživatelu. ˚ Funkcionalita pro odstranˇení cˇ lena svazu dosud nebyla implementována. Ve specifikaci tohoto požadavku od svazu integrované produkce byla požadována jako málo prioritní. Za celý rok užívání systému bylo nutné manuálnˇe odstranit totiž pouze jediný cˇ lenský podnik, který byl ze svazu integrované produkce vylouˇcen pro neplnˇení podmínek cˇ lenství.

5.3

Správa obsahu portálu

V této cˇ ásti je popisována konkrétní funkˇcnost a implementace správy obsahu stránek portálu, která bývá vždy jádrem každého redakˇcního systému. Webový obsah je tvoˇren dvˇema základními objekty: složkami a dokumenty. 5.3.1 Složka webového obsahu Složka webového obsahu je objekt, který reprezentuje urˇcitou logickou kategorii - sekci webového obsahu. Tato složka je pak pˇrímo vázána na konkrétní položku navigaˇcního menu a to jak nižší tak i vyšší úrovnˇe. Objekt složka je definován tˇemito atributy: •

Název složky, který je zobrazován v navigaˇcním menu.

•

Html obsah složky, který je zobrazován v prostˇredním hlavním panelu stránky.

•

Adresáˇr - cesta k adresáˇri na souborovém systému v serveru - slouží pro ukládání souboru˚ v dané složce. 30

5.3. SPRÁVA OBSAHU PORTÁLU •

Kolekce dokumentu, ˚ které jsou v ní obsaženy, setˇrídˇeny dle názvu.

•

Kolekce podsložek, které jsou v ní obsaženy, setˇrídˇeny dle názvu.

•

Minimální oprávnˇení pro pˇrístup k obsahu v této složce

•

Rodiˇcovská, nadˇrazená složka

•

Obrázek (odkaz na soubor obrázku) ikony dané složky v detailnˇejším stylu zobrazení u aktualit- dosud nevyužito

Vazba mezi objekty dokumenty a složkami je popsána v podkapitole správa cˇ lenu˚ svazu této kapitoly. Kolekce dokumentu˚ a podsložek je z databáze naˇcítána pomocí opoždˇeného (líného) naˇcítání objektu. ˚ Díky tomu se nenaˇcítá spolu se složkou z databáze celá její stromová struktura podsložek a dokumentu˚ do pamˇeti, ale jen její základní atributy. Toto rˇ ešení výraznˇe zefektivnuje ˇ práci s pamˇetí, protože naˇctení dokumentu˚ a podsložek dané složky se dˇeje až teprve pˇri jejich použití. V koˇrenové složce Menu je obsaženo pˇet složek, které se vytváˇrí automaticky do databáze pˇri instalaci portálu pomocí instalaˇcních skriptu: ˚ •

Levý panel - tato složka reprezentuje levý panel navigaˇcního menu portálu, její podsložky jsou jednotlivými bloky levého panelu a jejich obsah pak položkou tˇechto bloku. ˚

•

Main Page - složka zobrazující se na úvodní stránce jako výchozí stránka.

•

Pravý panel - tato složka reprezentuje levý panel navigaˇcního menu portálu a obsahuje pˇredem tˇri definované podsložky, bloky odkazu˚ - aktuality, poˇcasí a služby

•

Signalizace vinic proti obaleˇcum ˚ - složka obsahující signalizaˇcní zprávy pro nálety obaleˇcu˚ do feromonových lapaˇcu. ˚ Složka je použita v rámci komponenty sledování aktuálních náletu˚ obaleˇcu. ˚

•

SIPHV data - složka obsahující složky asociované k vinaˇrským podnikum. ˚ V souˇcasnosti není vázána na žádnou položku menu, bude rˇ ešena souˇcasnˇe s již zminovanou ˇ implementací administrace složek uživateli z rˇ ad cˇ lenu˚ svazu.

5.3.2 Dokument webového obsahu Základním objektem obsahu na webu je dokument, který reprezentuje webový obsah zobrazený v hlavním prostˇredním panelu. Dokument má definovány tyto základní atributy: •

Název dokumentu který je zobrazován v navigaˇcním menu

•

Titulek dokumentu - delší popisný text, upˇresnující ˇ název dokumentu a popisující blíže obsah dokumentu 31

5.3. SPRÁVA OBSAHU PORTÁLU

Obrázek 5.2: Ukázka pˇeti základních složek portálu z administrace obsahu •

Html obsah dokumentu, který je zobrazován v prostˇredním hlavním panelu stránky

•

Soubor pˇripojený k dokumentu pomocí upload stránky (cesta k souboru uloženém v filesystemu serveru) Tyto soubory jsou vˇetšinou PDF dokumenty s legislativou, informacemi a signalizaˇcními zprávami.

•

Datum poslední zmˇeny, editace dokumentu. Na úvodní stránce portálu jsou zobrazeny odkazy na poslední 3 modifikované dokumenty.

•

Relevantní odkazy vztahující se k danému dokumentu.

•

Kolekce klíˇcových slov, které se k danému dokumentu vztahují. Doposud nebyla implementována podpora na vyhledávání dle klíˇcových slov, protože tento požadavek od zadavatele má nízkou prioritu.

•

Minimální oprávnˇení pro pˇrístup k obsahu tohoto dokumentu

•

Rodiˇcovská, nadˇrazená složka

•

Obrázek (odkaz na soubor obrázku) ikony daného dokumentu v detailnˇejším stylu zobrazení u aktualit - dosud nevyužito

Zobrazování složek a dokumentu˚ v hlavním panelu rˇ ídí centrální controller pro navigaci mezi stránkami, který zobrazí obsah požadované složky cˇ i dokumentu. Složka v hlavním panelu zobrazuje jak svuj ˚ HTML obsah, tak také seznam svých podsložek a dokumentu. ˚ Dokumenty ve složce jsou podle svého druhu obsahu zobrazovány ruznými ˚ styly a ikonkami. 32

5.3. SPRÁVA OBSAHU PORTÁLU V pˇrípadˇe, že daný dokument nemá vlastní HTML obsah, ale má pˇripojený soubor, zobrazuje se položka webového dokumentu s ikonkou znázornující ˇ soubor a odkaz dokumentu je vázaný pˇrímo na pˇriložený soubor. V pˇrípadˇe, že opˇet daný dokument nemá vlastní HTML obsah a má pˇripojený právˇe jeden relevantní odkaz, zobrazuje se obdobnˇe položka dokumentu s ikonkou znázornující ˇ odkaz, který je pak pˇrímo vázaný na daný relevantní odkaz. Zobrazené odkazy na podsložky složky jsou také odlišeny ikonkou složky.

Obrázek 5.3: Ukázka popisovaného obsahu složky v hlavním panelu portálu

5.3.3 Administrativní rozhraní správy dokumentu˚ Správa obsahu portálu nabízí administrátorum ˚ a editorum ˚ tyto funkˇcnosti: •

Procházení stromové struktury všech složek a dokumentu˚ v administrativním rozhraní

•

Vytvoˇrit složku s minimálním oprávnˇením rodiˇcovské složky.

•

Upravit vlastnosti složky

•

Smazat složku vˇcetnˇe jejího obsahu (veškerý obsah složky je smazán vˇcetnˇe podsložek rekurzivnˇe)

•

Vytvoˇrit dokument v dané složce s minimálním oprávnˇením cˇ tení v této složce

•

Upravit obsah dokumentu

•

Pˇripojit soubor k dokumentu jako pˇrílohu

•

Vložit a upravovat relevantní odkazy k dokumentu 33

ˇ 5.4. DALŠÍ ROZŠÍ RENÍ SPRÁVY OBSAHU •

Odstranit dokument

Odkaz na funkˇcnost pro úpravu konkrétní složky cˇ i dokumentu se editorum ˚ zobrazuje pˇrímo v hlavním panelu pˇri zobrazení stránky s danou složkou cˇ i dokumentem, což usnadnuje ˇ editorum ˚ správu. Vrstva zobrazení obsahu portálu je tak tímto zpusobem ˚ více provázána s administrativní vrstvou. Pro úpravu textového obsahu složky a dokumentu byl použit volnˇe šiˇritelný HTML editor FCKeditor.1 Ten je šíˇren pod licencí GNU LGPL, která umožnuje ˇ použití dynamických knihoven bez nutnosti zveˇrejnování ˇ zdrojového kódu, cˇ ímž je tento produkt použitelnˇejší pro použití i v komerˇcních projektech. Pro funkˇcnost HTML editoru nebylo nutné upravovat zdrojové kódy a tudíž bylo možné tento produkt použít. HTML editor FCKeditor je použitelný ve všech používaných prohlížeˇcích pro webové aplikace psané v PHP, Perlu, ASP.NET, Javˇe a mnoha dalších díky široké podpoˇre integraˇcních komponent pro tyto jazyky. FCKeditor je napsaný ve skriptovacím jazyce Java Script, tudíž se spouští na stranˇe klienta pˇrímo v internetovém prohlížeˇci a jeho bˇeh zatˇežuje ménˇe aplikaˇcní server. Vzhled, použití funkcí editoru a pˇreddefinované šablony stránky lze snadno upravovat a konfigurovat. FCKeditor umožnuje ˇ díky nahrávací komponentˇe uploadovat na server obrázky cˇ i jiné HTML objekty, které pak lze použít pˇrímo v obsahu stránky. Mezi nesporné výhody tohoto editoru patˇrí i možnost editace HTML formuláˇru. ˚ Tuto funkcionalitu lze v budoucnosti využít na vytváˇrení anket a dotazníku˚ pˇri užití pˇredem definované šablony pro takový formuláˇr.

5.4

Další rozšíˇrení správy obsahu

Jelikož rozsah požadavku, ˚ které byly již specifikovány, není koneˇcný a stále se objevují nové požadavky na funkˇcnost, uvádím zde nˇekolik požadavku, ˚ které nejsou pro svaz IP v soucˇ asné dobˇe prioritní, a tak bud’ nejsou ještˇe úplnˇe implementovány,aby mohly být nasazeny do ostrého provozu, nebo jsou již využívány.

Mapa stránek nebo-li strukturovaný seznam odkazu˚ na všechny WWW stránky webu je výborným pomocníkem pro orientaci v rámci složitého, rozsáhlého webu. Uživatel, který potˇrebuje konkrétní informaci a pro kterého by bylo jinak velmi obtížné procházet složitou strukturu webu, jednoduše navštíví mapu webu, kde si relevantní WWW stránku najde a rovnou na ni pˇrejde. Tato funkcionalita je již implementována a slouží svému úˇcelu.2

1. FCKeditor 2. Mapa stránek SIPHV

34

ˇ 5.4. DALŠÍ ROZŠÍ RENÍ SPRÁVY OBSAHU Vyhledávání v obsahu portálu Tato funkcionalita nemá z pohledu vedení svazu IP velkou prioritu, ale každý dobˇre vytvoˇrený portál ji nabízí a proto je jí od zaˇcátku vˇenována zvýšená pozornost i v návrhu objektového modelu. Jelikož podstatná cˇ ást obsahu je zabezpeˇcena pˇres uživatelské jméno a heslo, nelze použít k vyhledávání obsahu stránek funkcionalit cizích vyhledávaˇcu˚ (google, Atomz, Jyxo). Další možností je vyhledávání pomocí existujícího Java search engine, který bˇeží na stranˇe serveru spolu s aplikací. 3 Java Search engine je poskytován zdarma a prochází daný dynamický obsah stránek i PDF souboru˚ a vytváˇrí indexovou databázi slov. Umožnuje ˇ také obsah stránek kategorizovat, což lze využít pro definování ruzných ˚ kategorií a úrovní dle oprávnˇení uživatelu˚ portálu. V rámci webové aplikace lze využít i jeho API. Jako tˇretí možnost se jeví implementace vyhledávání vlastním rˇ ešením vˇcetnˇe indexování klíˇcových slov z PDF dokumentu. ˚ RSS (Really Simple Syndication) export novinek V pˇrípadˇe zájmu o obsah z portálu SIPHV lze snadno vytvoˇrit komponentu pro export novinek pˇres RSS exportní kanál. Zasílání hromadných emailu˚ uživatelum ˚ cˇ i jejich skupinˇe. Pro efektivnˇejší možnost poskytovat informace a spravovat cˇ leny svazu i jiné uživatele bude bˇehem sezóny 2006 vytvoˇrena komponenta pro zasílání emailových zpráv z administrátorského rozhraní Správy uživatelu. ˚ Vícejazyˇcný portál V souˇcasnosti, ani v dohledné budoucnosti, neuvažuje vedení Svazu Integrované produkce o provozu portálu ve více jazycích. S pˇrípadným pˇrechodem cˇ ástí View a Controlleru aplikace na MVC framework Struts je možné, že nˇekteré view komponenty budou nabízeny v jazykových mutacích (meteorologická mapa a signalizace náletu˚ obaleˇcu). ˚ Vytváˇrení anket Pomocí šablony HTML editoru by mˇelo být možné v kombinaci s aplikací portálu vytváˇret dotazníky a formuláˇre, jejichž vyplnˇený obsah by byl automaticky serverem odesílán na danou adresu. Jelikož aplikace portálu podporuje možnost pˇrijímat i odesílat elektronickou poštu, mˇel by tento požadavek být snadno realizovatelný. Zasílání informace o zmˇenˇe v dané složce V pˇrípadˇe, že o obsah dané složky dokumentu˚ je pro uživatele relevantní, mohl by získávat uživatel informace emailem o pˇrípadných zmˇenách obsahu v této složce. Pˇri vložení nového dokumentu by obsah tohoto 3. Java Search Engine

35

ˇ 5.4. DALŠÍ ROZŠÍ RENÍ SPRÁVY OBSAHU dokumentu mohl být i uživateli pˇrímo zaslán na jeho emailovou adresu, nebo pouze jeho odkaz. Této funkcionality by šlo využít pˇri duležitých ˚ upozornˇeních, novinkách a signalizacích.

36

Kapitola 6

Sledování náletu˚ obaleˇcu˚ Svaz Integrované produkce spolupracuje v rámci své poradenské cˇ innosti s mnoha soukromými i veˇrejnými spoleˇcnostmi. Jednou soukromou spoleˇcností je firma Biocont Laboratory ltd., jež pro své potˇreby sleduje aktuální nálety obaleˇcu˚ do feromonových lapaˇcu. ˚ Feromony se z lapaˇce šíˇrí vzduchem a pusobí ˚ na vzdálenost nˇekolika desítek až stovek metru. ˚ Sameˇcci jsou tak lákáni vuní ˚ feromonu do feromonového lapaˇce, kde se pˇrilepí. Informace o poˇctu náletu tˇechto samcu˚ je duležitá ˚ pro pˇestitele vína nejen z rˇ ad cˇ lenu˚ Svazu Integrované produkce. V rámci spolupráce s firmou Biocont tak byla vytvoˇrena komponenta portálu SIPHV pro sledování tˇechto náletu˚ obaleˇcu. ˚

6.1

Požadavky na správu sledování náletu˚ obaleˇcu˚

Požadavky na danou komponentu byly následující:

Administrativní rozhraní pro zadávání hodnot Požadavkem bylo rozhraní pro správu jednotlivých feromonový lapaˇcu˚ do systému, druhu hmyzu, který daný lapaˇc monitoruje a pro samotné vkládání poˇctu hmyzu pˇri náletu v daném období. Monitoring náletu do lapaˇcu˚ se provádí v pravidelných intervalech vždy 3x v týdnu, v pondˇelí, stˇredu a pátek.

Online generování grafu pro jednotlivou lokalitu Monitorované údaje daného feromonového lapaˇce se automaticky vykreslí v grafu. Mˇerˇ ítko hodnot grafu bude pro všechny lapaˇce stejné(kvuli ˚ porovnatelnosti grafu). ˚

Zobrazení signalizaˇcní zprávy pro nálety obaleˇcu˚ Souˇcástí komponenty na zobrazování grafu˚ náletu˚ obaleˇcu˚ je i možnost zobrazovat signalizace a varování na stejných stránkách, spolu s doporuˇceními pro pˇrípadnou prevenci pˇred rozmnožením škudce. ˚ Tato signalizace by mˇela být veˇrejnˇe pˇrístupná, nebot’ tuto službu provozuje firma Biocont.

37

ˇU ˚ OBALE C ˚ 6.2. REALIZACE ON LINE SLEDOVÁNÍ NÁLET U Grafický styl zobrazení komponenty Komponenta má odlišný styl zobrazení od stylu portálu SIPHV tak, aby bylo zˇrejmé, že provozovatelem služby je firma Biocont Laboratory ltd. Formuláˇr pro získávání signalizací emailem Souˇcástí stránek s nálety obaleˇcu˚ by mˇel být i ˇ formuláˇr pro pˇrihlášení se k odbˇeru signalizaˇcních zpráv na emailovou adresu. Rešení zasílání signalizaˇcních zpráv není souˇcástí požadavku. Komponenta souˇcástí portálu SIPHV Pro snadnˇejší implementaci komponenty bylo vhodné využít již fungujících cˇ ástí portálu SIPHV a to tak, aby správa sledování náletu obaleˇcu˚ byla jeho souˇcástí. Díky úzké provázanosti firmy Biocont a svazu IP, kde lidé z firmy Biocont mají uživatelský úˇcet u svazu IP a to na úrovni editora portálu, mohla být tato komponenta takto vytvoˇrena.

6.2

Realizace on line sledování náletu˚ obaleˇcu˚

Realizace komponenty probíhala v úvodu vinaˇrské sezóny 2005 ve spolupráci s Ing. Markétou Broklovou z firmy Biocont Laboratory. Na základˇe prvotního požadavku bylo žádoucí, aby majitelé, správci feromonových lapaˇcu˚ zadávali údaje pˇres internet sami a odpadla tak zbyteˇcná administrativa. Po detailnˇejší analýze, kde z 6 zadavatelu˚ údaju˚ mˇel pouze jeden z nich pˇrístup na internet a ostatní zadavatelé namˇerˇ ené údaje sdˇelovali Ing. Broklové telefonicky, byla tato možnost on line správy oznaˇcena jako ménˇe prioritní. V budoucnosti lze komponentu o tuto funkcionalitu kdykoliv snadno rozšíˇrit. V první fázi byla navržena následující struktura tˇríd: •

Škudce, ˚ druh hmyzu (Ant) - sledovaný druh škudce, ˚ který nalétává do feromonového lapaˇce.

•

Feromonový lapaˇc (Catcher) - zaˇrízení do nˇehož nalétávají škudci ˚ a jsou u nˇej sledována mˇerˇ ení náletu

•

Mˇerˇ ení náletu(Catch), ˚ poˇcet zachycených jedincu˚ urˇcitého druhu hmyzu v daném lapaˇci v urˇcitý den. Tuto strukturu tˇríd v UML , stejnˇe jako ERD diagram A.1 , mužete ˚ nalézt v pˇríloze B.1. Implementované administrativní rozhraní umožnuje ˇ správci komponenty

•

Vkládat jednotlivé mˇerˇ ení náletu˚ konkrétního škudce ˚ pro daný feromonový lapaˇc

•

Upravovat hodnotu tohoto mˇerˇ ení 38

ˇ 6.3. ZKUŠENOSTI Z PROVOZU A MOŽNÁ ROZŠÍ RENÍ •

Odstranit mˇerˇ ení

•

Vkládat a spravovat signalizaˇcní zprávy k náletum ˚ (uložené ve složce Signalizace k náletum ˚ obaleˇcu, ˚ která je jednou ze základních složek systému 5.2)

Vkládání druhu˚ škodlivého hmyzu a nových feromonových lapaˇcu˚ do systému muže ˚ pouze uživatel s oprávnˇením administrátora. Editace a odstranˇení druhu hmyzu a feromonového lapaˇce nemá implementované webové rozhraní, nebot’ dané pˇrípady užití jsou používány velmi zˇrídka. Odstranˇení a editace tˇechto údaju˚ jsou tak provádˇeny pˇrímo na úrovni databáze pˇres SQL pˇríkazy. Údaje o náletech obaleˇcu˚ jsou na veˇrejnˇe pˇrístupných stránkách generovány do formy grafu ve formátu PNG. Vytváˇrení a online generování grafu˚ z kolekce numerických dat umožnuje ˇ v dnešní dobˇe pro platformu java rˇ ada produktu˚ na bázi frameworku. Takovými produkty jsou napˇríklad placený SwiftChart 1 popˇrípadˇe GNU licencovaný JFreeChart2 . Pro vytvoˇrení jednoduchého generování grafu byl implementován servlet generující tento graf bez použití produktu˚ tˇretích stran. Použití uvedených produktu˚ v této komponentˇe bylo v dobˇe realizace zbyteˇcné a pˇríliš komplikované. Zvláštˇe složitá se jevila integrace grafového frameworku s komponentou. Samotná Implementace grafového servletu nezabrala pˇríliš cˇ asu, nebot’ jsem pˇri ní cˇ erpal z volnˇe pˇrístupných pˇríruˇcek a tutoriálu˚ s ukázkami zdrojového kódu generovaných grafu. ˚ Java obsahuje širokou podporu pro práci s bitmapami v rámci standardní knihovny AWT - java.awt. Knihovna nabízí možnosti vkládat text do obrázku, ˚ pracovat se základními geometrickými obrazci, vykreslovat výstup do ruzných ˚ bitmapových formátu˚ a další.34 Pro budoucí rozšiˇrování nabízených služeb a tím i rozšiˇrování informací objevujících se v grafu, bude výhodnˇejší použití produktu JFreeChart, který umožnuje ˇ svoji integraci do Java servletu. Pˇrípadné nahrazení grafové komponenty tedy bude pˇri rozšíˇrení snadné.

6.3

Zkušenosti z provozu a možná rozšíˇrení

Komponenta pro sledování náletu˚ obaleˇcu˚ již úspˇešnˇe funguje druhou sezónu. Pˇrípadné požadavky na rozšíˇrení této komponenty zatím vzneseny nebyly. Nejzajímavˇejší a také relativnˇe jednoduchou možností rozšíˇrení této komponenty je zpˇrístupnˇení zadávání hodnot více uživatelum. ˚ Rozšíˇrením více feromonových lapaˇcu˚ mezi cˇ leny svazu a jejich pravidelným monitoringem by mohla vzniknout unikátní a cenná databáze škudc ˚ u˚ nejen révy vinné celé jižní cˇ ásti Moravy. Takto vybudovaná sít’ feromonových lapaˇcu˚ ve spojení s vybudovanou meteorologickou sítí je duležitým ˚ prvkem rozvoje ekologicky šetrného ošetˇrování plodin. Své využití tyto cenné údaje mají pro studium druhu˚ hmyzu, klimatu i biodiverzity. Monitorovací sít’ 1. 2. 3. 4.

SwiftChart JFreeChart JavaWorld interval.cz

39

ˇ 6.3. ZKUŠENOSTI Z PROVOZU A MOŽNÁ ROZŠÍ RENÍ feromonových lapaˇcu˚ by mˇela mít vysokou prioritu hned po vybudování a uvedení do plného provozu meteorologické mapy vinic.

Obrázek 6.1: Ukázka grafu náletu obaleˇce z kvˇetna 2006

40

Kapitola 7

Meteorologická mapa vinic V této kapitole je popsána meteorologická mapa vinic, jedna z hlavních služeb portálu, co se nejen významu a pˇrínosu, ale i složitosti realizace týká.

7.1

Sít’ meteorologických stanic

Sít’ meteorologických stanic byla vybudována v roce 2000 Svazem Integrované produkce v rámci projektu PHARE s názvem Jižní Morava - Rozvoj vinohradnictví. Investorem cˇ eského podílu finanˇcního zajištˇení cˇ ásti projektu "Integrovaná produkce" byl Svaz integrované produkce hroznu˚ a vína ( SIPHV), dodavatelem této cˇ ásti projektu byla firma GALATI Bratislava. Cíle projektu byly: •

zavést technologii integrované produkce v okresech Bˇreclav a Znojmo

•

vybudovat automatickou sít’ meteostanic pro potˇreby ochrany vinic

•

zˇrídit Národní vinaˇrské centrum ve Valticích pro úˇcely prezentace domácích vín a zvyšování kultury spotˇreby vína

•

zˇrídit vinaˇrské stezky ve Valticích a v Mikulovˇe

V rámci cˇ ásti projektu související s integrovanou produkcí byla zavedena sít’ meteostanic MeteoVitis od firmy AMET, Velké Bílovice, v poˇctu 40ks v okresech Bˇreclav a Znojmo ke sledování meteorologických prvku˚ ovlivnujících ˇ výskyt houbových chorob révy vinné a tyto meteostanice byly dovybaveny poˇcítaˇci a programy na ochranu révy vinné. Tato sít’ byla v dalších letech rozšíˇrena o meteostanice z dalších okresu˚ Jižní Moravy.1 Meteostanice MeteoVitis patˇrí mezi malé, uživatelsky zamˇerˇ ené meteorologické stanice, registrující potˇrebné meteorologické veliˇciny pro signalizaci vˇetšiny houbových chorob, pro nˇež jsou dostupné metodiky a zpracované poˇcítaˇcové programy. Výstupní datový formát umožnuje ˇ zpracování vˇetšinou programu˚ vytvoˇrených Státní rostlinolékaˇrskou správou se sídlem v Brnˇe, GALATI Bratislava, popˇrípadˇe i jiné provenience. Namˇerˇ ené hodnoty jsou ukládány v textovém ASCII souboru s pˇríponou .DAT s formátem podobným formátu CSV, kde každé mˇerˇ ení všech hodnot je zadáváno na jeden textový rˇ ádek. Takto navržený formát dat je snadno cˇ itelný programy všech platforem a parsery textu. 1. Amet

41

7.1. SÍ Tˇ METEOROLOGICKÝCH STANIC V každém souboru je na zaˇcátku za rˇ ádkem "JMENO" identifikátor meteostanice, který ji identifikuje v rámci sítˇe meteostanic. Uvádím pˇríklad cˇ ásti souboru stanice MeteoVitis Velehrad, ze Slovácké oblasti. "JMENO","velehrad" "TYP","00048" "VYROBNI CISLO","00002" "OBSAH ZAZNAMU" "DATUM","CAS","RELATIVNI CAS","STAV","T1[C] ","VV[%] ","OL[-]","T2[C]","SRA[mm]" "10.05.2006","09:24:26", 100,"JOB", 14.85, 46.7, 1.0, 14.47, 0.0 "10.05.2006","09:39:26", 100,"JOB", 15.23, 45.9, 1.0, 15.23, 0.0 "10.05.2006","09:54:26", 100,"JOB", 15.62, 42.5, 1.0, 15.62, 0.0 "10.05.2006","10:09:26", 100,"JOB", 16.38, 42.0, 1.0, 16.0, 0.0 "10.05.2006","10:24:26", 100,"JOB", 17.14, 38.3, 1.0, 17.14, 0.0 "10.05.2006","10:39:26", 100,"JOB", 17.52, 38.3, 1.0, 17.14, 0.0 "10.05.2006","10:54:26", 100,"JOB", 18.28, 37.0, 1.0, 17.9, 0.0 "10.05.2006","11:09:26", 100,"JOB", 18.66, 35.9, 1.0, 18.28, 0.0 "10.05.2006","11:24:26", 100,"JOB", 19.04, 35.1, 1.0, 18.66, 0.0 "10.05.2006","11:39:26", 100,"JOB", 19.42, 34.3, 1.0, 19.04, 0.0 "10.05.2006","11:54:26", 100,"JOB", 19.81, 34.3, 1.0, 19.42, 0.0 "10.05.2006","12:09:26", 100,"JOB", 19.81, 32.8, 1.0, 19.42, 0.0 "10.05.2006","12:24:26", 100,"JOB", 20.19, 32.3, 1.0, 19.42, 0.0 "10.05.2006","12:39:26", 100,"JOB", 19.81, 30.2, 1.0, 19.42, 0.0 "10.05.2006","12:54:26", 100,"JOB", 20.19, 31.9, 1.0, 19.81, 0.0 "10.05.2006","13:09:26", 100,"JOB", 20.19, 34.2, 1.0, 19.81, 0.0 "10.05.2006","13:24:26", 100,"JOB", 20.57, 35.5, 1.0, 20.19, 0.0 "10.05.2006","13:39:26", 100,"JOB", 20.95, 33.8, 1.0, 20.57, 0.0 "10.05.2006","13:54:26", 100,"JOB", 20.95, 30.5, 1.0, 20.19, 0.0 "10.05.2006","14:09:26", 100,"JOB", 20.57, 31.8, 1.0, 20.19, 0.0 "10.05.2006","14:24:26", 100,"JOB", 20.57, 31.8, 1.0, 19.81, 0.0 "10.05.2006","14:39:26", 100,"JOB", 20.19, 33.2, 1.0, 19.81, 0.0 "10.05.2006","14:54:26", 100,"JOB", 20.19, 34.1, 1.0, 20.19, 0.0 .......

Stanice MeteoVitis mˇerˇ í a registruje tyto meteorologické prvky: •

teplota vzduchu

•

vlhkost vzduchu

•

ovlhˇcení listu˚

•

teplota pudy ˚

•

úhrn srážek 42

7.2. PROBLEMATIKA SDÍLENÍ METEOROLOGICKÝCH DAT Údaje ze snímaˇcu˚ meteostanice jsou v pravidelných cˇ asových intervalech (nejˇcastˇeji 15 min) ukládány do vnitˇrní pamˇeti registrátoru, který je lehce odnímatelný a po pˇrenesení k poˇcítaˇci lze namˇerˇ ené údaje pomocí rozhraní RS232 uložit na pevný disk a dále zpracovávat výše uvedenými programy. V mimo vegetaˇcním období lze získat pˇrehled (napˇr. pomocí programu MeteoDAT) o prubˇ ˚ ehu teploty vzduchu, což je duležité ˚ napˇr. pˇri hodnocení intenzity mrazu˚ v zimˇe. Vnitˇrní pamˇet’ registrátoru je natolik dostaˇcující, že pˇri uvedeném intervalu mˇerˇ ení 15 min. vydrží zaznamenávat údaje po dobu 20 dnu, ˚ aniž by jej bylo nutno spojit s PC. Stanice MeteoVitis je vybavena dvˇema nezávislými registrátory, což zvyšuje její spolehlivost v provozu [9].

7.2

Problematika sdílení meteorologických dat

V této sekci bych se rád zabýval problematikou centralizace a sdílení meteorologických hodnot namˇerˇ ených stanicemi MeteoVitis. 7.2.1 Stávající rˇešení vytvoˇrené v roce 2000 Po pˇrenesení údaju˚ z datového boxu meteostanice MeteoVitis do poˇcítaˇce probíhá další zpracování jak po stránce meteorologické, tak dochází i k vyhodnocení prognózy a signalizace houbových chorob. K meteorologickému zpracování je používán program MeteoDAT (autoˇri Perutka, Juroch, Hrubý), který umožnuje ˇ z namˇerˇ ených dat provádˇet nejruznˇ ˚ ejší výbˇery (napˇr. denní, týdenní, dekádní, mˇesíˇcní), poˇcítat sumy aktivních a efektivních teplot, popˇrípadˇe vyhodnocovat další podmínky [10]. Ukázku provedeného výbˇeru pro denní a týdenní hodnoty je možno spatˇrit v pˇríloze.C.1 V rámci obou projektu˚ (ale nejen u nich) bylo nutno vyˇrešit pˇredávání namˇerˇ ených údaju˚ dalším uživatelum, ˚ popˇrípadˇe do dalších poradenských center. Jak se ukázalo, v rámci projektu˚ se podaˇrilo získat finanˇcní prostˇredky na poˇrízení meteorologických stanic, nikoliv však již na další náklady spojené s distribucí údaju˚ po dobu následujících let. V rámci rˇ ešení pˇredávání údaju˚ byla již v poˇcátku projektu zavržena varianta zasílání dat prostˇrednictvím internetu na urˇcitý server, z duvodu ˚ nutné údržby takového serveru, pˇrípadnˇe pronájmu a financí, které pro tento úˇcel nebyly urˇceny. Data tak byla distribuována programem MeteoDAT na zadané e-mailové adresy jako pˇrílohy ke zprávám. Na stranˇe pˇríjemce dat byl pak nainstalován program Mcentrum, který provedl kontrolu e-mailové schránky a pokud nalezl zprávy s pˇríslušnými datovými pˇrílohami, doplnil již existující soubory na disku. Schéma puvodního ˚ rˇ ešení zasílání meteodat dalším uživatelum ˚ pomocí elektronické pošty naleznete také v pˇríloze C.2. Toto rˇ ešení synchronizace dat mˇelo své závažné nedostatky:

Problémy smtp serveru pˇri odesílání dat Program MeteoDat zasílající e-mailovou zprávu s meteodaty byl vytvoˇren v roce 2000 a nepoˇcítal s podporou odesílání zpráv pˇres autentizovaný smtp server. S rozšíˇrením vysokorychlostního internetu ve formˇe ADSL, 43

7.2. PROBLEMATIKA SDÍLENÍ METEOROLOGICKÝCH DAT bezdrátových technologií (Wi-Fi) a dalších, se vyskytli poskytovatelé internetu používající k odesílání elektronické pošty autentizovaný smtp server. Od tˇechto uživatelu˚ nebylo možné tak získávat údaje, byt’ paradoxnˇe byly na technologicky vyspˇelejší úrovní, než uživatelé pˇripojení k internetu pˇres modem. Nedostateˇcný pˇrístup k namˇerˇeným údajum ˚ Pravidelnˇe byly zasílány údaje pouze na dvˇe adresy, které musely být nastaveny v programu MeteoDAT. Pˇrípadné pˇridání dalšího pˇríjemce meteodat znamenalo objet všech pˇribližnˇe 50 vinaˇrských podniku˚ vlastnících meteostanice a pˇridat dalšího pˇríjemce. Nedostateˇcná kontrola meteostanic V rámci systému zasílání dat bylo aktivních pouze pˇribližnˇe 25 stanic z více jak 55, které pravidelnˇe zasílaly údaje na pouze uvedené adresy. Vedení Svazu IP nemˇelo dostateˇcný pˇrístup k informacím o stavu meteostanic, chybˇela katalogizace meteorologických stanic a nebylo je možné efektivnˇe spravovat. Povinnost použití programu MeteoDat pro pˇrístup k meteorologickým údajum ˚ Pˇrípadní zájemci z rˇ ad cˇ lenu˚ SIPHV, kteˇrí by získávali meteodata ve formˇe e-mailových aktualizací, by museli mít nainstalovaný program MeteoDat na svém poˇcítaˇci. Tento program je sice pro cˇ leny SIPHV urˇcen zdarma, ale v souˇcasné dobˇe se objevila jeho cˇ ásteˇcná neˇ kompatibilita s novˇejšími systémy Windows. Rada cˇ lenu˚ svazu také nepotˇrebuje mít detailnˇejší analýzy o meteodatech, k vˇetšinˇe signalizací staˇcí týdenní úhrny srážek, prumˇ ˚ erné týdenní teploty a ovlhˇcení listu. ˚ ˇ 7.2.2 Rešení úpravou stávajícího rˇešení zasílání dat V úvodní fázi realizace meteorologické mapy byla silnˇe zvažována a cˇ ásteˇcnˇe zrealizována možnost úpravy stávajícího rˇ ešení zasílání meteorologických dat za pomocí elektronické pošty. Bylo vytvoˇreno rozhraní portálu SIPHV, které pˇrijímalo meteorologická data z vytvorˇ ené e-mailové schránky [email protected]. Soubor meteostanice z elektronické zprávy tato komponenta vkládala do systému portálu jako webový dokument s pˇrílohou do urˇcené složky patˇrící konkrétní meteostanici. Tato data pak byla pˇrístupná ve formˇe aktualizací pro program MeteoDAT. V prubˇ ˚ ehu sezóny toto rˇ ešení bylo testováno ve spolupráci s nˇekolika cˇ leny svazu a ta již ve svém prubˇ ˚ ehu ukázala na nutnost toto rˇ ešení provždy opustit a vytvoˇrit nové, lépe odpovídající požadavkum ˚ a technicky realizovatelnˇejší. Duvody ˚ k tomuto kroku byly následující: Stále zustávala ˚ nutnost používat program MeteoDAT jak pro zasílání aktualizací, tak i pro pˇrístup k namˇerˇ eným údajum, ˚ nebyla by vyˇrešena nedostateˇcná kontrola nad stavem meteostanic a aktualizace programového vybavení a nastavení. 44

7.2. PROBLEMATIKA SDÍLENÍ METEOROLOGICKÝCH DAT 7.2.3 Návrh rˇešení sdílení meteorologických dat Z požadavku˚ na zpracování dat a dukladnˇ ˚ ejší analýze stávajícího rˇ ešení distribuce bylo navrženo následující schéma pro realizaci daného problému centralizace meteorologických dat. Bylo zvoleno rˇ ešení klient - server aplikace, kde pro synchronizaci dat z lokálního poˇcítaˇce by sloužila klientská aplikace, jež by data zasílala na centrální server.

Obrázek 7.1: Schéma zpracování meteorologických dat pˇres centrální server SIPHV Z detailnˇejší analýzy rˇ ešení interaktivní meteorologické mapy vyplynuly následující požadavky. Požadavky na rˇ ešení klientské aplikace pro synchronizaci dat byly následující: •

Snadná uživatelská instalace

•

Automatický update aplikace pˇres internet pˇri nové verzi

•

Nezávislost na operaˇcním systému a konfiguraci poˇcítaˇce

•

Schopnost komunikace se serverem pˇri libovolném typu pˇripojení k internetu (pˇres HTTP)

•

Uživatelsky jednoduchá aplikace

•

Autentizace uživatele pˇri komunikaci se serverem 45

7.3. REALIZACE METEOROLOGICKÉ MAPY VINIC •

Aplikace synchronizuje namˇerˇ ená meteorologická data pro program MeteoDAT se serverem

Požadavky na cˇ ást serveru centrální meteorologické mapy byly následující: •

Meteorologická data jsou uložena v relaˇcní databázi pro snadné zpracování a analýzy

•

Výstupy namˇerˇ ených hodnot jsou zobrazovány více zpusoby ˚ (grafy, tabulka, soubor pro program MeteoDAT ke stažení)

•

Uživatelská navigace pro pˇrístup k informacím dané meteorologické stanice je pˇres interaktivní mapku vinaˇrských oblastí.

•

Meteorologické stanice v systému serveru se dají snadno spravovat administrativním rozhraním

•

Meteostanice jsou rˇ azeny do vinaˇrských oblastí dle zákona

•

Server synchronizuje namˇerˇ ená meteorologická data pro program MeteoDAT s klientskou aplikací

•

Robustnost a výkon aplikace serveru

V pˇríloze B.3 je uveden UML model pˇrípadu˚ užití pro správu a pˇrístup k údajum ˚ meteorologické mapy vinic.

7.3

Realizace meteorologické mapy vinic

Realizace se skládala z implementace serveru a klientské aplikace. Nejprve bych se rád zmínil o implementaci serverové cˇ ásti meteorologické mapy. 7.3.1 Komponenta serveru meteorologické mapy Implementace architektonické cˇ ásti modelu z MVC serveru je identifikována tˇemito persistentními tˇrídami •

meteorologická stanice a k ní vázaný vinaˇrský podnik

•

mˇerˇ ení teploty vzduchu dané stanice v urˇcitý cˇ as

•

mˇerˇ ení teploty pudy ˚ dané stanice v urˇcitý cˇ as

•

mˇerˇ ení relativní vlhkosti vzduchu dané stanice v urˇcitý cˇ as

•

mˇerˇ ení ovlhˇcení listu dané stanice v urˇcitý cˇ as

•

mˇerˇ ení stavu srážkomˇeru dané stanice v urˇcitý cˇ as 46

7.3. REALIZACE METEOROLOGICKÉ MAPY VINIC Základní mˇerˇ ení hodnot je provádˇeno v 15 minutových intervalech a tak mˇesíˇcní mˇerˇ ení 1 meteostanice obsahuje pˇribližnˇe 3000 záznamu. ˚ Tyto údaje jsou pro základní použití pˇríliš podrobné. Pro zpracování dat v dalších meteorologických programech jsou použity denní hodnoty, které jsou odvozené a ukládají se v objektech, jež jsou souˇcástí datového skladu odvozených hodnot, jejichž naˇcítání z primárního zdroje dat by neúmˇernˇe zatˇežovalo databázový server. Tyto odvozené hodnoty datového skladu jsou: •

denní prumˇ ˚ er z mˇerˇ ení teploty vzduchu dané stanice

•

denní prumˇ ˚ er z mˇerˇ ení relativní vlhkosti vzduchu dané stanice

•

denní prumˇ ˚ er z mˇerˇ ení teploty pudy ˚ dané stanice

•

denní mˇerˇ ení ovlhˇcení listu dané stanice

•

denní úhrn srážek dané stanice

Prumˇ ˚ erné teploty jsou poˇcítány dle metodiky poˇcítání prumˇ ˚ erné denní teploty uvedené na Státní rostlinolékaˇrské správˇe v charakteristice teplotních modelu[12]. ˚ pr˚ umˇ erná denní teplota =

(denní minimum + denní maximum) ---------------------------2

V budoucnosti by bylo dobré tyto odvozené objekty datového skladu rozšíˇrit o maximální a minimální denní hodnoty a sumy hodinových teplot za den, které se dají též využít v analýzách. Objekt meteorologické stanice v je definován tˇemito atributy: •

Identifikátor meteostanice, stejný jako v souboru .DAT programu meteostanice

•

Název

•

Popis polohy meteostanice (druh umístˇení vinohradu,...)

•

Vinaˇrská oblast ve které se meteostanice nachází (oblasti jsou definovány dle aktuální kategorizace oblastí)

•

Asociovaná složka pro webový obsah - slouží pro vkládání souboru˚ k meteostanici a pro zálohu

•

Vinaˇrský podnik(ˇclen svazu) odpovˇedný za provoz meteostanice a na jehož vinici je meteostanice umístˇena

•

Pozice v mapˇe dané oblasti pro navigaci

•

Poznámka - Textová poznámka k meteostanici, týkající se jejího stavu cˇ i jiných vlastností. 47

7.3. REALIZACE METEOROLOGICKÉ MAPY VINIC V pˇríloze B.4 je uveden doménový model tˇechto objektu. ˚ Implementace view na stranˇe serveru je reprezentována tˇemito cˇ ástmi: •

Webovým rozhraním pro správu meteostanicD.4

•

Navigací meteorologické mapy D.1

•

Výstupy denních teplot vzduchu ve formˇe grafu (ˇrešení obdobné jako u náletu˚ obaleˇcu) ˚ D.2

•

Výstupy odvozených hodnot ve formˇe tabulky D.3

•

Výstupem ve formátu souboru .DAT pro program MeteoDAT

Implementace controlleru rˇ eší navigaci a operaˇcní logiku mezi modelem a view v administrativní cˇ ásti a v cˇ ásti pro zobrazování hodnot. Uvádím zde dva duležité ˚ controllery v systému meteorologické mapy a jejich funkˇcnost. První controller slouží pro vkládání meteorologických dat ve formátu .DAT do systému a to pro všechna klientská rozhraní (Web, klientská aplikace) . Controller pˇrijímá multipart -request z Http se souborem programu MeteoDAT jenž je zpracován pomocí tˇrídy pro parsování dat a uložen do databáze SIPHV. Druhý controller má opaˇcnou funkˇcnost a slouží pro generování souboru .DAT z meteorologických dat uložených v systému za urˇcité období. To umožnuje ˇ uživatelum ˚ si stáhnout soubor ve formátu programu MeteoDat a pracovat s ním na svém lokálním poˇcítaˇci v MeteoDATu stejnˇe, jakoby uživatel fyzicky vlastnil tuto meteostanici. 7.3.2 Klientská aplikace pro synchronizaci dat Aplikace pro synchronizaci dat je jednoduchý javovský program s jednoduchým uživatelským rozhraním. Klientská aplikace po stisknutí tlaˇcítka "zobraz meteostanice" naˇcte meteostanice uložené v datovém úložišti meteorologických dat. Toto úložištˇe je v adresáˇri programu MeteoDAT C:\Meteo. Aplikace po naˇctení stanic z pevného disku provˇerˇ í aktuálnost - stav jejich dat ve srovnání daty uloženými na serveru SIPHV. Nastat mohou tyto stavy meteorologických dat:

Meteostanice v poˇcítaˇci má aktuálnˇejší mˇerˇení Data v souboru meteostanice jsou novˇejší než na serveru a tato data budou odeslána z lokálního poˇcítaˇce na server (v aplikaci je u stanice zobrazeno status: –>>) Meteostanice v poˇcítaˇci má starší mˇerˇení Na serveru se vyskytuje aktualizace pro meteostanici, jejíž data mám uložena v poˇcítaˇci (byla stažena z portálu SIPHV). (v aplikaci je u stanice zobrazeno status: << –) 48

7.3. REALIZACE METEOROLOGICKÉ MAPY VINIC

Data jsou synchronizovaná Data meteostanice jsou na serveru i v lokálním poˇcítaˇci identická.(v aplikaci je u stanice zobrazeno status: OK)

Meteorologická stanice není v systému serveru Meteorologická stanice s identifikátorem (uvedený v souboru stanice) neexistuje v seznamu meteostanic serveru. V tomto pˇrípadˇe je tˇreba se obrátit na správce meteostanic.(v aplikaci není u stanice zobrazena žádná informace o statutu dat) Po stisknutí tlaˇcítka "synchronizuj data" se nejprve klientská aplikace autentizuje na server pomocí uživatelského jména a hesla uživatele s minimálním oprávnˇením cˇ lena Svazu IP a teprve poté jsou data synchronizována. Uživateli je pak zobrazen aktuální stav meteostanic a jejich dat.

Obrázek 7.2: Ukázka klientské aplikace pro synchronizaci meteorologických dat Aplikace komunikuje se serverem pˇres protokol HTTP. Byly zvažovány i jiné protokoly komunikace klient-server. Možné se jevily protokoly RMI, CORBA, SOAP. Jejich využití bylo 49

7.3. REALIZACE METEOROLOGICKÉ MAPY VINIC zavrženo z nutnosti upravovat i serverovou cˇ ást pro komunikaci a nemožnost využít již stávajícího HTTP rozhraní webového serveru. Pˇrenos dat nevyžadoval pˇrenos žádných složitých objektu, ˚ pouze ASCII textu a pro toto se také díky své jednoduchosti hodil i protokol HTTP. Možnost použití SOAP protokolu, který je postaven na HTTP, bylo zavržena pro nároˇcnost SOAPu na systémové prostˇredky klientského stroje i serveru. Pro komunikaci pˇres HTTP je použita komponenta HTTPClient od Apache foundation2 . Díky této komponentˇe lze v klientské aplikaci používat výhody práce javy s HTTP. Komponentˇe také neˇciní problém komunikace pˇres proxy server, odesílání GET i POST HTTP requestu, ˚ vˇcetnˇe multipart requestu˚ s pˇrílohami. 7.3.3 Distribuce klientské aplikace a její technologické rˇešení K vytvoˇrení klientské aplikace byla použita technologie Java Web Start3 , která umožnuje ˇ snadnou distribuci a instalaci klientské GUI aplikace bez nutnosti složité distribuce na klientské aplikace. Java Web Start technologie má oproti klasicky distribuovaným desktopovým aplikacím v Javˇe mnoho výhod. Web Start aplikace používají internetový prohlížeˇc (Web Start - spustitelné z webu) jako prostˇredek k instalaci aplikace. V praxi to probíhá tak, že koncový uživatel klikne na spouštˇecí skript Java Web Start (soubor JNLP) na internetových stránkách a aplikace se sama nainstaluje a spustí. Potom tuto aplikaci mužete ˚ spouštˇet také z prostˇredí Java Web Start, které vytváˇrí jakousi druhou pracovní plochu s aplikacemi, nebo pˇrímo z pracovní plochy, kam se vám pˇri instalaci vytvoˇrí ikonka vaší aplikace. Web Start aplikace si muže ˚ vyžádat ruzné ˚ verze Javy, které potˇrebuje. Tato verze se také automaticky nainstaluje. Odpadá tedy problém s kompatibilitou jednotlivých verzí javy. Bezpeˇcnostní práva aplikací, které spustíte ze sítˇe, jsou omezená. V pˇrípadˇe, že chcete mít pro svoji aplikaci veškerá práva pˇrístupu, musí mít digitálnˇe podepsané jar soubory. Aplikace je tak podepsána certifikátem a uživatel si muže ˚ být jist, že aplikace nainstalovaná v jeho poˇcítaˇci je opravdu od daného poskytovatele.[11] Aplikace Java Web Start je klasická java aplikace. Nemusí mít tedy žádného pˇredka typu Applet a její provoz není závislý na webovém prohlížeˇci. Pouze pro cˇ innosti, které vyžadují další práva, musíte používat speciální API, pokud ovšem nemáte aplikaci digitálnˇe podepsánu. Nainstalovaná aplikace je cachována v prostˇredí Java Web Start a proto se spouští velice rychle. Ještˇe pˇredtím, než se ale aplikace spustí, Java Web Start zkontroluje, jestli není k dispozici novˇejší verze, kterou by potom automaticky nainstalovalo. Java Web Start je referenˇcní implementací, která je zdarma poskytována spolu s JRE/JDK. Instalace Java Web Start se distribuuje spolu s JRE (runtime environment), které si mužete ˚ zdarma stáhnout z java.sun.com. Na windows se nainstaluje toto prostˇredí nainstaluje automaticky. Výhoda aplikace klientské v prostˇredí java je tak její platformová nezávislost. Vytvoˇrená klientská aplikace je uložena na webovém serveru a je definována v souboru 2. Amet 3. Java WebStart

50

7.3. REALIZACE METEOROLOGICKÉ MAPY VINIC JNLP, který funguje jako spouštˇecí skript. Finální odkaz na aplikaci není odkaz na soubor jar, ale na soubor JNLP, který zajistí spuštˇení Java Web Start. Uvádím okomentovaný pˇríklad souboru JNLP pro klientskou aplikaci Svazu IP. <jnlp codebase="http://siphv.artemon.cz:8080/vino-ip/client/" href="MeteoClient.jnlp" version="0.9.85"> SIPHV MeteoClient SIPHV - Svaz integrovane produkce hroznu a vina <description>Klient pro synchronizaci meteodat se serverem <shortcut online="false"> <desktop/> <menu submenu="SIPHV"/> <j2se href="http://java.sun.com/products/autodl/j2se" version="1.5+"/> <jar href="dist/lib/commons-httpclient-3.0.jar" /> <jar href="dist/lib/commons-codec-1.3.jar" /> <jar href="dist/lib/commons-logging.jar" /> <property name="SIPHV_SERVER" value="http://siphv.artemon.cz:8080/vino-ip/"/> <jar href="dist/MeteoClient.jar" main="true"/> <jar href="dist/lib/swing-layout-1.0.jar" />

51

ˇ 7.4. UVEDENÍ DO PRAXE A MOŽNÁ ROZŠÍ RENÍ <jar href="dist/lib/jnlp.jar" /> <jar href="dist/lib/jnlp-servlet.jar" /> <argument>SIPHV_SERVER=http://siphv.artemon.cz:8080/vino-ip/ <security>

7.4

Uvedení do praxe a možná rozšíˇrení

Meteorologická mapa vinic byla oficiálnˇe uvedena do provozu a prezentována na veletrhu Vinex v Brnˇe v bˇreznu tohoto roku. Do systému meteorologických stanic byly vloženy stanice s namˇerˇ enými údaji z minulých let a ty jsou také dnes pˇrístupné. Zprovoznˇení aktualizace tˇechto meteorologických stanic novˇe namˇerˇ enými údaji se potýká s následujícími pˇrekážkami, které jsou charakteristické pro zavádˇení nové technologie do systému s velkým poˇctem uživatelu: ˚

Neochota uživatelu˚ meteostanic používat nové technologie Pˇri zavádˇení nového informaˇcního systému se vyskytne urˇcité množství uživatelu, ˚ kteˇrí se neradi uˇcí používat nové technologie a postupy. Aˇc byl vytvoˇrený systém meteorologické mapy dostateˇcnˇe prezentován na semináˇrích Svazu IP, je rozšiˇrování systému meteorologické mapy mezi ˇ uživatele stále v zárodku. Rada uživatelu˚ z rˇ ad producentu˚ vína k této nové technologii pˇristupuje s neduvˇ ˚ erou. Problém proškolení administrativního pracovníka na správu meteostanic Systém správy meteostanic potˇrebuje k svému chodu mít dostateˇcnˇe schopného pracovníka pracujícího s celým systémem meteorologické mapy. Pro úˇcely administrace byl Svazem IP urˇcen pan RNDr. Tomáš Litschmann, který má na starost servis meteorologických stanic ve vlastnictví svazu. Po úvodním pˇredstavení systému bylo tˇreba pana Litschmanna dostateˇcnˇe proškolit na chování systému meteorologické mapy spolu s klientskou aplikací. 52

ˇ 7.4. UVEDENÍ DO PRAXE A MOŽNÁ ROZŠÍ RENÍ

Vkládání stanic do systému Jelikož z více jak 60 stanic je v systému meteorologické mapy vloženo necelých 40 meteostanic, je stále dostatek stanic, které nejsou v systému zaneseny. Problém s nastavením klientské aplikace Pro nˇekteré uživatele klientské aplikace je problém správnˇe nakonfigurovat pˇripojení klientské aplikace pˇres HTTP proxy server, pokud jej používají. Cílem Svazu Integrované produkce je mít bˇehem sezóny 2006 zaneseny v systému meteorologické mapy veškeré své stanice a od všech svých funkˇcních stanic mít k dispozici jejich aktuální data. Po splnˇení tohoto cíle lze pak uvažovat o dalších rozšíˇreních pro systém meteorologické mapy a to: •

rozšíˇrení odvozených hodnot pro analýzu ze základních namˇerˇ ených údaju. ˚

•

rozšíˇrení výstupu˚ odvozených meteorologických údaju˚ ve formátu grafu publikovaných na internetu.

•

povýšení databáze MySQL na novˇejší verzi nebo zmˇena na jiný robustnˇejší databázový systém. Systém meteorologické mapy je rozsáhlý a už v této dobˇe obsahuje pˇres 10 000 000 meteorologických záznamu˚ a zatˇežuje tak databázový server.

•

používání nových online meteorologických stanic MeteoUNI4 , které jsou pˇripojeny do internetu pˇres GPRS modem a samy komunikují se serverem pˇres protokol HTTP. Toto rˇ ešení by v budoucnosti nevyžadovalo tak cˇ asté návštˇevy meteostanic ze strany vinaˇre. Navíc by data byla poskytována serveru aktuálnˇeji v denních intervalech. Jedinou pˇrekážkou pro používání nových meteostanic MeteoUNI, nebo pro rozšíˇrení stávajících o komunikaˇcní modul, je nedostatek potˇrebných financí.

4. MeteoUNI

53

Kapitola 8

Závˇer Tato práce popisuje realizaci a uvedení v praxi poradenského portálu pro integrovanou produkci hroznu˚ a vína, který je svými poskytovanými službami unikátní nejen v rámci integrované produkce vína, ale v rámci celé ekologicky šetrné produkce. Díky trendum, ˚ které ve vyspˇelé Evropˇe vládnou, bude duležitost ˚ ekologie a trvale udržitelného rozvoje ve všech cˇ lenských zemích dále rust. ˚ Práce tak svojí praktickou realizací ukazuje potenciál a duleži˚ tost používání moderních informaˇcních technologií ve spolupráci s tradiˇcními, ekologicky šetrnými, zemˇedˇelskými odvˇetvími. Práce na konkrétní realizaci portálu popisuje analýzu, architekturu, realizaci nasazení a zkušenosti z provozu celého systému, pokud možno v souladu s postupy ovˇerˇ enými ˇ v praxi. Ctenáˇ r práce má tak možnost setkat se s principy unikátní realizace na míru vytvoˇreného informaˇcního systému v ekologicky šetrné produkci. Dodržení tˇechto principu, ˚ jako správnˇe navržené architektury a pochopení požadavku˚ zákazníka, je duležité ˚ pro následující rozvoj informaˇcního systému. Stejnˇe tak i portál Svazu Integrované produkce byl navržen pro budoucí možnost rozšiˇrování svých služeb. Tyto rozsáhlé a plánované možnosti rozšiˇrování služeb portálu jsou v práci u každé komponenty zmínˇeny. Vytvoˇrený portál naleznete na internetu na stránkách <www.vino-ip.cz>.

54

Pˇríloha A

ERD portálu

Obrázek A.1: ERD databáze vygenerované frameworkem Hibernate, 1. cˇ ást

55

A. ERD PORTÁLU

Obrázek A.2: ERD databáze vygenerované frameworkem Hibernate, 2. cˇ ást 56

A. ERD PORTÁLU

Obrázek A.3: ERD databáze vygenerované frameworkem Hibernate, 3. cˇ ást

57

Pˇríloha B

UML modely portálu

Obrázek B.1: Ukázka diagramu tˇríd komponenty pro sledování náletu˚ obaleˇcu˚

58

B. UML

MODELY PORTÁLU

Obrázek B.2: Model systému z pohledu high level pˇrípadu užití

59

B. UML

MODELY PORTÁLU

Obrázek B.3: Model pˇrípadu˚ užití správy meteorologických dat a meteostanic

60

B. UML

MODELY PORTÁLU

Obrázek B.4: Doménový model objektu meteostanice a mˇerˇ ených údaju, ˚ 1. cˇ ást

61

B. UML

MODELY PORTÁLU

62

Obrázek B.5: Doménový model objektu meteostanice a mˇerˇ ených údaju, ˚ 2. cˇ ást

Pˇríloha C

Ukázky zpracování meteorologických dat

Obrázek C.1: Ukázka zpracování meteorologických dat programem meteoDat, pˇrevzato [10].

63

C. U KÁZKY ZPRACOVÁNÍ METEOROLOGICKÝCH DAT

Obrázek C.2: Ukázka schématu puvodního ˚ zpracování dat, autor G. Vanˇek, pˇrevzato [10].

64

Pˇríloha D

Meteorologická mapa SIPHV

Obrázek D.1: Ukázka navigace v meteorologické mapˇe

65

D. M ETEOROLOGICKÁ MAPA SIPHV

Obrázek D.2: Ukázka výstupu mˇerˇ ení v podobˇe grafu

66


Obrázek D.3: Ukázka výstupu mˇerˇ ení v podobˇe tabulky

67


Obrázek D.4: Ukázka rozhraní administrace meteostanic

68

Pˇríloha E

Obsah CD Souˇcástí této práce je také CD. Obsah: •

Zdrojový kód této práce ve formátu XML (podle DTD DocBook), samotná práce v nˇekolika ruzných ˚ formátech.

•

Zdrojové kódy aplikace portálu. Tyto zdrojové kódy jsou ve vlastnictví Svazu Integrované produkce a jejich použití je urˇceno licenˇcními podmínkami uvedenými na disku CD.

•

UML modely tˇríd vygenerované ze zdrojových textu˚ pomocí CASE nástroje Enterprise Architect.

69

Literatura [1] Barray, C.: The Model–View–Controller Design Pattern, Indiana University, 1999, . 4.1, 4.1 [2] Kolektiv autoru: ˚ Best practice – Pravidla pro tvorbu pˇrístupného webu, Ministerˇ stvo informatiky Ceské republiky, 2004, . 2.2 [3] Hluchý, M. a Ackermann, P. a Zacharda, M. a Bagar, M. a Jetmarová, E. a Vanˇek, G.: Obrazový atlas chorob a škudc ˚ u˚ ovocných dˇrevin a révy vinné, Biocont Laboratory ltd., 1997, 80-901874-2-1. 2.1.1 [4] Macháˇcek, L.: Webový portál vˇenovaný syntaktické analýze pˇrirozeného jazyka, Bakaláˇrská práce, Fakulta informatiky Masarykovy univerzity v Brnˇe, 2002, . 2.2 [5] Schiefer, G. a Kreuder, A.: Vertical and horizontal information portals: cooperation models for sector and chain information services, 2001 World Food and Agribusiness Forum Presentations„ 2001, . 2.2 [6] Sun Microsystems: Model–View–Controller, Sun Microsystems, 2002, . 4.1, 4.1 [7] Tichý, J.: Programová podpora tvorby webových aplikací, diplomová práce, Praha, Vysoká škola ekonomická, 2004, http://www.jantichy.cz/diplomka/ . 4.1, E [8] Woodcock, J.: Slovník výpoˇcetní techniky, Praha, Microsoft Press, 1993, 80-85297-485.. 3.3 [9] Litschmann, T.: Meteostanice MeteoVitis, Amet spol. s.r. o., 2001, <www.amet.cz/ meteovitis.htm>. 7.1 [10] Litschmann, T.: VYUŽITÍ MIKROKLIMATICKÝCH STANIC V SYSTÉMU IN˚ NA JIŽNÍ MORAVE, ˇ Amet spol. s.r. TEGROVANÉ PRODUKCE HROZNU o., 2005, . 7.2.1, C.1, C.2, E [11] Patrný, V.: Java Web Start, Linuxzone.cz, 2003, . 7.3.3 70

[12] Referát metod ochrany rostlin Státní rostlinolékaˇrské správy v Brnˇe, .: Automatické meteorologické stanice SRS - Teplotní modely, Státní rostlinolékaˇrská správa v Brnˇe, 2003, . 7.3.1

71

Rejstˇrík agroenvironmentální opatˇrení, 3 architektura, 14 AWT, 39 CMS, 24 Content Managment System, 24 corporate design, 12

redakˇcní systém, 24 Rozcestník, 4 rozcestníkový portál, 5 RSS - Really Simple Syndication, 35 Složka webového obsahu, 30 Spring framework, 22 Struts, 22, 35

datový sklad, 47 Dokument webového obsahu, 31 dokumentový portál, 5

Uživatelé systému, 10 UML, 10, 29, 38, 46

FCKeditor, 34

vertikální portály, 5 Vyhledávání obsahu portálu, 35

GNU/GPL, 24 Hibernate Framework, 16, 18 horizontální portály, 5 HQL Hibernate Query Language, 19 HTML Editor, 24

webový portál, 4 www.vino-ip.czí, 1, 54 WYSIWYG, 24

integrovaná produkce, 2 internet, 43 Java, 16 Java Web Start, 50 JDK, 50 JNLP, 50, 51 JRE, 50 klient - server aplikace, 45 komponentová architektura, 14 Mapa stránek, 34 MeteoDAT, 43 Meteorologická mapa, 4, 41 meteorologická stanice, 41 MeteoVitis, 43 Model - View - Controller, 16 MVC, 26 ORM - objektovˇe relaˇcní mapování, 19 PHARE, 41 72

Seznam obrázku˚ 3 Detailní analýza a návrh architektury portálu SIPHV . . . . . . . . . . . . . . . . . 3.1 Logo Svazu Integrované produkce 12 4 Zvolená architektura rˇ ešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Nákres MVC architektonického vzoru, pˇrevzato[7] 17 5 Správa obsahu portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Nákres UML diagramu tˇríd pro správu obsahu 29 5.2 Ukázka pˇeti základních složek portálu z administrace obsahu 32 5.3 Ukázka popisovaného obsahu složky v hlavním panelu portálu 33 6 Sledování náletu˚ obaleˇcu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Ukázka grafu náletu obaleˇce z kvˇetna 2006 40 7 Meteorologická mapa vinic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Schéma zpracování meteorologických dat pˇres centrální server SIPHV 45 7.2 Ukázka klientské aplikace pro synchronizaci meteorologických dat 49 A ERD portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1 ERD databáze vygenerované frameworkem Hibernate, 1. cˇ ást A.2 ERD databáze vygenerované frameworkem Hibernate, 2. cˇ ást A.3 ERD databáze vygenerované frameworkem Hibernate, 3. cˇ ást

. . . . . . . . . . . 55 56 57

B UML modely portálu . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1 Ukázka diagramu tˇríd komponenty pro sledování náletu˚ obaleˇcu˚ B.2 Model systému z pohledu high level pˇrípadu užití 59 B.3 Model pˇrípadu˚ užití správy meteorologických dat a meteostanic B.4 Doménový model objektu meteostanice a mˇerˇ ených údaju, ˚ 1. cˇ ást B.5 Doménový model objektu meteostanice a mˇerˇ ených údaju, ˚ 2. cˇ ást

. . . . . . . . . 58 60 61 62

C Ukázky zpracování meteorologických dat . . . . . . . . . . . . . . . . . . . . . . . . C.1 Ukázka zpracování meteorologických dat programem meteoDat, pˇrevzato [10]. 63 C.2 Ukázka schématu puvodního ˚ zpracování dat, autor G. Vanˇek, pˇrevzato [10]. 64 D Meteorologická mapa SIPHV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.1 Ukázka navigace v meteorologické mapˇe 65 D.2 Ukázka výstupu mˇerˇ ení v podobˇe grafu 66 D.3 Ukázka výstupu mˇerˇ ení v podobˇe tabulky 67 D.4 Ukázka rozhraní administrace meteostanic 68

73

Seznam tabulek

74

012345

Recommend Documents