}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
ˇ B AKALÁ RSKÁ PRÁCE
Jakub Vágner
Brno, jaro 2012
Prohlášení Prohlašuji, že tato bakaláˇrská 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. Ing. Václav Pˇrenosil, CSc. ii
Podˇekování Na tomto místˇe bych chtˇel podˇekovat prof. Ing. Václavu Pˇrenosilovi, CSc., za odborné vedení této práce, vˇenovaný cˇ as a podporu, jíž se mi dostalo.
iii
Shrnutí Cílem této bakaláˇrské práce je navrhnout a implementovat informaˇcní systém, který bude monitorovat provoz vozového parku elektromobilu. ˚ Na každém z vozidel je umístˇena senzorová sít’, která v urˇcitých momentech posílá data do informaˇcního systému, který je bude sbírat, tˇrídit a zobrazovat obsluze.
iv
Klíˇcová slova doprava, elektromobil, monitoring, informaˇcní systém, analýza, návrh
v
Obsah 1
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . 1.3 Využití . . . . . . . . . . . . . . . . . . . . . . . . 2 Analýza požadavku˚ na IS . . . . . . . . . . . . . . . . 2.1 Rozhraní pro klienty i automat . . . . . . . . . . 2.2 Evidence, výkaznictví, administrace . . . . . . . 2.3 Generátor testovacích dat . . . . . . . . . . . . . 2.4 Rozšiˇritelnost, udržovatelnost . . . . . . . . . . . 3 Návrh IS . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 metodiky návrhu IS . . . . . . . . . . . . . . . . . 3.1.1 metodiky strukturovaného návrhu . . . . 3.1.2 objektovˇe orientované metodiky návrhu 3.1.3 výbˇer metodiky . . . . . . . . . . . . . . . 3.2 návrh IS . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Diagram datových toku˚ . . . . . . . . . . 3.2.1.1 kontextový diagram . . . . . . . 3.2.1.2 DFD diagram . . . . . . . . . . . 3.2.2 Stavovˇe pˇrechodový diagram . . . . . . . 3.2.3 Entitnˇe relaˇcní diagram . . . . . . . . . . 3.2.4 Datový slovník . . . . . . . . . . . . . . . 3.2.5 Architektura, Technologie . . . . . . . . . 3.2.5.1 Technologie . . . . . . . . . . . . 3.2.5.2 Architektura . . . . . . . . . . . 4 Implementace IS . . . . . . . . . . . . . . . . . . . . . 4.1 využívané knihovny . . . . . . . . . . . . . . . . 4.1.1 PHP framework . . . . . . . . . . . . . . . 4.1.2 XML-RPC . . . . . . . . . . . . . . . . . . 4.1.3 grafy, mapy .. . . . . . . . . . . . . . . . . 4.2 optimalizace (aneb prohˇresky proti návrhu) . . . 4.3 možnosti rozšíˇrení . . . . . . . . . . . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . A obsah pˇriloženého CD . . . . . . . . . . . . . . . . . . B datové typy hodnot atributu˚ . . . . . . . . . . . . . . C instalaˇcní manuál . . . . . . . . . . . . . . . . . . . . . C.1 minimální konfigurace . . . . . . . . . . . . . . . C.2 instalaˇcní návod . . . . . . . . . . . . . . . . . . . D Instalaˇcní skript pro vytvoˇrení struktury databáze .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 1 3 3 3 4 4 5 5 5 6 7 8 8 8 9 12 12 15 17 17 20 22 22 22 22 23 23 23 25 27 28 29 30 30 30 31
vi
Kapitola 1
Úvod 1.1
Motivace
Jedna z velkých aktuálních výzev energetiky plyne z Kirchhoffových zákonu˚ [9] [10], které se týkají elektˇriny a, zjednodušenˇe, rˇ íkají, že aktuální výroba a aktuální spotˇreba elektˇriny musí být stejná. Problém plyne ze stále se zvˇetšujícího podílu elektráren využívajících obnovitelné zdroje, zejména sluneˇcních a vˇetrných. Podstata problému tkví v tom, že zatímco spotˇreba elektˇriny je v cˇ ase konstantní, výroba elektˇriny z takových zdroju˚ kolísá podle aktuálních a tˇežko pˇredpovˇeditelných pˇrírodních podmínek. V síti tak vzniká chvíli pˇrebytek a chvíli nedostatek energie, protože elektˇrina se zatím nedá nˇejak rozumnˇe a efektivnˇe skladovat. Problém se ted’ rˇ eší tˇreba vodními pˇreˇcerpávacími elektrárnami. Dalším z možných zpusob ˚ u, ˚ jak trochu „ulevit“ kolísající rozvodné síti, je zvednout podíl zapojených nabíjecích spotˇrebiˇcu˚ v provozu, zejména tˇech velkokapacitních, napˇríklad baterií pro elektromobily.
1.2
Cíl práce
Do oblasti praktické aplikace z této oblasti je namíˇrena i tato bakaláˇrská práce. Jejím cílem je navrhnout a realizovat informaˇcní systém (dále jen „IS“), který bude moci využít provozovatel vozového parku elektromobilu. ˚ Protože oblast komerˇcního provozu vozového parku elektromobilu˚ je u nás témˇerˇ neprozkoumaná, na každém z vozidel bude instalována senzorová sít sbírající statistická data o stavu vozidla (rychlost vozidla, teplota baterie apod). Na pˇredpokládané trase vozidel budou rozmístˇeny vysílaˇce, které informace ze sítˇe naˇctou a odešlou ke zpracování. Informaˇcní systém si musí poradit i s daty z této sítˇe a pˇrehlednˇe je zobrazovat správci. Z rozmístˇení vysílaˇcu˚ zárovenˇ plyne možnost on-line sledování aktuální polohy vozidel. Díky tomu pak lze doplnit data o geolokaˇcní atributy, jako je nadmoˇrská výška a zemˇepisná šíˇrka a délka.
1.3
Využití
Mezi komerˇcní aplikace muže ˚ patˇrit napˇríklad pujˇ ˚ covna elektromobilu˚ pro mˇestské popojíždˇení, s rozmístˇením vysílaˇcu˚ na vybraných kˇrižovatkách. Konkrétnˇe tˇreba pujˇ ˚ covna pro turisty, kde díky lokalizaci auta muže ˚ operátor, spravující informaˇcní systém, poskytovat informace o aktuálnˇe míjených památkách, ale samotná trasa a délka setrvání v okolí památky zustane ˚ na volbˇe turisty. To muže ˚ být zajímavá konkurenˇcní výhoda proti vyhlídkovým 1
1.3. VYUŽITÍ jízdám s rˇ idiˇcem-moderátorem. Navíc by provozovatel nepotˇreboval zamˇestnávat rˇ idiˇce. Úplná novinka je zrovna v platnost vcházející novela [13]umožnující radnicím omezit vjezd do konkrétních oblastí, napˇríklad historických center mˇest, vozidlum ˚ s urˇcitými emisemi. Elektromobily bez emisí se omezení nedotknou. Zajímavé by mohly být elektromobily pro safari, kde by nulové emise a tichý chod motoru mohly být výhodou pro nerušené sledování zvíˇrat, navíc s on-line pˇrehledem pro správce safari, at’ už pro rˇ ešení pˇrípadných problému, ˚ cˇ i navigování rˇ idiˇce za pˇresunujícím se stádem vzácné zvˇerˇ e. Další z pˇekných aplikací by mohly být tˇreba vozidla pro velké veletrhy, bohužel ale tak velké veletrhy, aby se muselo ˇ popojíždˇet, u nás nejsou a další Expo v Ceské Republice ještˇe dlouho nebude. Typickou aplikací jsou golfové vozíky, pro popojíždˇení hráˇcu˚ po rozlehlém hˇrišti.
2
Kapitola 2
Analýza požadavku˚ na IS Aby IS dobˇre sloužil svému uživateli, musí mu pomáhat s jeho prací, nikoli ji pˇridávat. Aby tuto úlohu IS plnil, musí dˇelat pˇresnˇe to, co uživatel potˇrebuje. Ten, kdo neví a neví, že neví, je hlupák. Ten, kdo neví a ví, že neví, se muže ˚ nauˇcit. Ten, kdo ví a neví, že ví, spí. Ten, kdo ví a ví, že ví, je prorok. —stará perská písenˇ Problém s vˇetšinou uživatelu˚ je v tom, že pˇrevážnˇe spadají do prvních 3 kategorií. Je to také jedna z hlavních pˇríˇcin tristní bilance softwarových projektu˚ [14], kdy vˇetšina zakázek nebyla dodána, akceptována, pˇrípadnˇe nebyla nasazena do reálného provozu cˇ i nˇekolikanásobnˇe pˇrekroˇcila rozpoˇcet. Fáze analýzy uživatelských požadavku˚ tak nesmí chybˇet v žádném projektu. V této kapitole se zmíním o uživatelských požadavcích kladených na tento konkrétní IS. Návrh IS, který je splnuje, ˇ je v další kapitole.
2.1
Rozhraní pro klienty i automat
IS musí poskytovat grafické rozhraní pro lidskou obsluhu pro bˇežnou správu (napˇr sledování aktuální polohy aut, výkaznictví, administrace). Autorizace uživatele není vyžadována, ale pro pˇrípad komerˇcního nasazení bude nutná, tudíž musí být snadno implementovatelná. Zárovenˇ musí IS poskytovat strojové rozhraní pro vysílaˇce, pro sbˇer dat ze senzorových sítí.
2.2
Evidence, výkaznictví, administrace
Pro potˇreby výkaznictví a administrace je nutné umožnit správu následujících typu˚ dat: •
evidence vozidel a jejich provozuschopnosti
•
evidence hodnot parametru˚ vozidel v cˇ ase (data ze senzorové sítˇe)
•
evidence vysílaˇcu˚ 3
2.3. GENERÁTOR TESTOVACÍCH DAT Správou se rozumí bˇežné operace pˇridávání, mazání a editace. Protože se dá oˇcekávat rozšiˇrování senzorové sítˇe o další mˇerˇ itelná data, rozsah sbíraných dat (respektive množina atributu) ˚ musí být modifikovatelná bez zásahu do kódu. Hodnoty budou nabývat jednoduchých datových typu˚ (text, cˇ íslo, cˇ íslo s desetinou cˇ árkou, gps souˇradnice), pro pˇrípad chyb pˇri pˇrenosu musí být data ruˇcnˇe editovatelná obsluhou. Nasbíraná data bude umˇet systém prezentovat v nˇekolika formátech, podle výbˇeru obsluhy. Napˇríklad jednu jízdu vozidla bude, krom klasického zobrazení v tabulce, umˇet promítat na mapu, nebo do grafu zmˇen hodnot atributu˚ vozidla (napˇríklad graf zobrazující úrovenˇ nabití baterie bˇehem jízdy). Z dalších promítání na mapu zminme ˇ zobrazení aktuální polohy vozidel nebo pozice všech vysílaˇcu. ˚
2.3
Generátor testovacích dat
Aby bylo možné ovˇerˇ it, že IS skuteˇcnˇe funguje i bez napojení na reálné senzory, je potˇreba pˇripravit modul, který bude umˇet senzory simulovat a bude plnit IS testovacími daty. Zárovenˇ bude možné data ruˇcnˇe zadat.
2.4
Rozšiˇritelnost, udržovatelnost
Protože pujde ˚ o pilotní projekt, riziko dalších úprav IS je velmi vysoké (až jisté). IS proto musí být navržen tak, aby umožnoval ˇ rozšiˇrování a úpravy. Tento požadavek se dá splnit kombinací dobrého návrhu (ˇcím víc toho pujde ˚ nastavit bez zásahu do kódu, tím lépe), dokumentace (úpravy IS zpravidla nedˇelá puvodní ˚ autor), kvality kódu (tím se myslí formální cˇ istota, dodržování standardu˚ a konvencí apod.) a použití bˇežnˇe používaných technologií a postupu. ˚
4
Kapitola 3
Návrh IS 3.1
metodiky návrhu IS
Návrh informaˇcního systému je inženýrská disciplína, rozvíjející se od 80. let minulého století. Za tu dobu se objevilo nˇekolik ruzných ˚ metodik, rˇ ešících problém návrhu, historicky souvisely zmˇeny s vývojem programovacích jazyku˚ od imperativních (procedurálních, modulárních) k neimperativním jazykum ˚ (funkcionální, logické, objektové). [4] Další vliv na vývoj metodik návrhu mˇely metodiky vývoje, napˇríklad agilní metodiky zkrátily fázi analýzi a návrhu a rozpustili ji do nˇekolika menších iterací. Metodiky návrhu se v podstatˇe dˇelí na 2 hlavní skupiny — puvodní ˚ metodiky strukturovaného návrhu a novˇejší objektivnˇe orientované.
3.1.1
metodiky strukturovaného návrhu
Tyto metodiky jsou velmi silné na poli IS, kde nevadí oddˇelení datové struktury od funkˇcní (procesní). V praxi tímto pˇrístupem vzniknou 2 oddˇelené modely (datový a funkˇcní), které jsou spolu jenom volnˇe svázány. Právˇe slabost vazby je zdrojem potenciálních problému˚ a zbyteˇcné pracnosti navíc, pˇri úpravách se musí neustále dohlížet, že se modely nerozchází. Pokud je navíc implementujícím programovacím jazykem nˇekterý z objektovˇe orientovaných, muže ˚ to vést k znaˇcnˇe neefektivnímu využívání možností jazyka a/nebo zbyteˇcné komplexitˇe, výstup takového návrhu totiž svádí k procedurálním postupum ˚ programování. Tento typ návrhu vyhovuje formálním metodikám vývoje jako jsou waterfallˇci prototypea vˇetším programátorským týmum. ˚
Warnier/Orr — datovˇe strukturovaný pˇrístup Pˇrístup má puvod ˚ v roce 1972, vychází ze strukturovaného programování a návrhu shoradolu˚ ( top-downpˇrístup), z puvodního ˚ použití pro návrh programových modulu˚ se rozrostla na návrh celého IS. Pˇri rˇ ešení problému se vychází z hierarchického cˇ lenˇení komplexních celku˚ na jednodušší cˇ ásti, které jsou propojeny jednoduššími vazbami. Vazby mezi cˇ ástmi jsou zobrazovány pomocí diagramu˚ entit. Z téhož vychází metodika modelování datových struktur HIT. [2] 5
3.1. METODIKY NÁVRHU IS Gane/Sarson logické modelování První metodika, která použila diagram datového toku ( DFD,z angl. data flow diagram), který popisuje základní objekty systému a jejich interakci. Tento typ diagramu se stal standardem pro strukturovaný popis dynamického chování systému. ERA modelování Autorem je Peter Chen. Patˇrí mezi nejˇcastˇejší metodiku pro návrh datových struktur IS. Protože se zabývá pouze datovou stránkou a nikoli funkcionalitou, bývá použita jako souˇcást jiné metodiky. Používá konceptuální ERAdiagram (z angl. entity relation atribute), který se stal standardem pro popis datových struktur v IS. YMSA(z angl. Yourdon modern structured analysis) — shrnuje všechny výše uvedené metodiky. Používá mimo jiné i DFDdiagramy pro modelování funkcionalit, ERAdiagramy pro datové modely a diagramy zmˇeny stavu systému ( STD,z angl. state-transition diagram) popisující závislosti systému v cˇ ase. 3.1.2
objektovˇe orientované metodiky návrhu
Vychází z objektovˇe orientovaného paradigmatu známého z programovacích jazyku. ˚ Modelují systém jako rˇ adu objektu, ˚ které obsahují jak datovou strukturu, tak funkˇcní logiku nad tˇemi daty. Tyto objekty mezi sebou komunikují pomocí posílání zpráv. Navíc jsou mezi nimi vazby delegace (skládání, abstrakce) a závislosti (dˇediˇcnost). Výstupy návrh v tomto stylu je bližší koncovému klientovi a tak je pro nˇej jednodušší se domluvit s analytikem. Výstup navíc odpovídá podrobnému zadání pro objektové programovací jazyky, které jsou nyní v drtivé pˇrevaze. Výhodou jsou též již hotové knihovny tzv. návrhových vzoru˚ ( DP, z angl. desing patterns), abstrahovaného problému s rˇ ešením, které mužou ˚ pomoci návrháˇri vyˇrešit problém elegatní a rychlou cestou. Narozdíl od separovaných vrstev ze strukturovaných metodik cˇ astˇeji využívá vertikální cˇ lenˇení, což ale pˇrináší riziko zbyteˇcnˇe komplikovaného návrhu. Navíc metodice by více sedˇely objektovˇe orientované databáze, které se ale komerˇcnˇe moc neprosazují. Tento pˇrístup každopádnˇe sedí pro agilní metodiky vývoje s malým týmem vývojáˇru, ˚ kdy se modeluje a implemetuje vždy jenom jedna cˇ ást systému najednou a díky cˇ astým iteracím je udržena celková koncepce systému. [5] OMT(z angl. Object Modelling Technique) Jde o hybridní metodiku datovanou do roku 1991, která používá mix objektových i strukturovaných metodik. Nejˇcastˇeji využívaná pro modelování databázovˇe orientovaných aplikací s objektovými klienty a relaˇcním serverem. 6
3.1. METODIKY NÁVRHU IS Coad-Yourdon metodika, jejímž spoluautorem je tentýž Yourdon, který stojí za YMSA. Metoda byla publikována roku 1989 .Do poˇctu používaných pojmu˚ je metodika z nejjednodušších. Od zaˇcátku je k dispozici i CASE nástroj ji podporující.
OOSD(z angl. Object Oriented SoftwareDevelopment) Komplexní metodika urˇcená pro návrh a týmový vývoj rozsáhlých aplikací v jazyce C++ a Smalltalk. Autorem je G. Booch. Ze všech metod pokrývá nejvíce objektových vlastností.
RUP(z angl. Rational Unified Process) objektovˇe orientovaná metodika postavená na standardu UML a vycházející z knowhow firmy RationalRose (divize IBM), metodika krom návrhu pokrývá celý životní cyklus vývoje software od analýzy po implementaci a nasazení. Od firmy je k dispozici i komerˇcní CASE nástroj.
Objectory (nebo take OOSE, z angl. Object Oriented Software Engineering) z dílny I. Jacobsona. Jako první zavedla tzv pˇrípad užití ( UC, z angl. use case), který byl velmi rychle pˇrijat do všech ostatních objektovˇe orientovaných metodik.
BORM(z angl. business object relation mapping) metodika cˇ eských projektantu˚ z firmy Deloitte&Touche, využívající komponentový pohled na model architektury organizace.
OOERnotace (z angl. Object-Oriented Entity Relation) metodika používá ER diagramy v klasické Chenovˇe syntaxi, ale obohacené o objektové vlastnosti. Je výhodná pro návrh objektovˇe orientovaných databází.
3.1.3
výbˇer metodiky
Vzhledem k faktu, že IS, jež je pˇredmˇetem bakaláˇrské práce, neobsahuje žádné komplikované algoritmy (jediné komplikovanˇejší se týkají zpracování dat z automatického rozhraní, kde je ale procedurální pˇrístup chtˇený) a že jednotlivé entity vyskytující se v IS neobsahují specifické chování a jsou jenom evidenˇcní, tak pro návrh jsem vybral Yourdonovu strukturovanou metodu. [1] 7
3.2. NÁVRH IS
3.2
návrh IS
3.2.1
Diagram datových toku˚
DFD (z angl. data flow diagram) diagramy modelují funkˇcní pohled na IS, interakce jednotlivých entit mezi sebou, interakci systému s okolním svˇetem a datové toky obecnˇe. Na diagramu se mohou objevit 4 typy objektu: ˚ datové úložistˇe — reprezentuje úložištˇe dat (vˇetšinou dabázi, ale muže ˚ jít napˇríklad o souborový systém), entita pouze pˇrijímající nebo poskytující data, bez vlastní funkcioˇ nality. Ctení dat z úložištˇe je nedestruktivní a „náhodné“ (v tom smyslu, že pˇreˇctená data nejsou nijak rˇ azena cˇ i filtrována). terminátor — reprezentuje entitu vnˇe IS, se kterou IS komunikuje cˇ i s ní vymˇenuje ˇ data. Zpravidla jde o nˇejakou osobu, roli nebo externí systém. proces — reprezentace procesu, který operuje s daty. Jediná entita, která transformuje vstupy na výstupy. V diagramu má pouze jméno a unikátní identifikátor, ale existuje pro nˇej bud minispecifikace (slovní popis), nebo je rozložen na podprocesy v DFD nižších úrovní. Pokud na DFD zakreslíme i tzv. „ˇrídící procesy“, které netransformují vstupy a výstupy, ale pouze urˇcují orchestraci (poˇradí spouštˇení) procesu, ˚ dostaneme diagram datových toku˚ s rˇ ízením (CDFD, z angl. Control Data Flow Diagram). Bˇežné datové procesy jsou znaˇceny plnou cˇ arou, rˇ ídící se znaˇcí pˇrerušovanou. datový tok — reprezentuje pohyb dat uvnitˇr IS, šipka urˇcuje smˇer kterým data proudí (zápis, cˇ tení). V CDFD se vyskytují i rˇ ídící toky, znaˇcené stejnˇe jako rˇ ídící procesy pˇrerušovanou cˇ arou.
Obrázek 3.1: Grafická notace objektu˚ na DFD dle Yourdona
3.2.1.1 kontextový diagram Jde v podstatˇe o DFD nejvyšší úrovnˇe. Modeluje interakce IS s okolím, definuje tím hranice IS. Oproti klasické notaci DFD, samotný systém je zde dobrazen jako 1 proces s nejvyšším cˇ íslem. Jednotlivé iterakce okolí s IS jsou znázornˇeny jako datové toky z/do systému. Terminátory jsou aktéˇri vykonávající se systémem nˇejakou aktivitu. 8
3.2. NÁVRH IS
Obrázek 3.2: Kontextový diagram IS Abych byl úplnˇe korektní, mˇel bych napˇríklad interakci „správa vozidel“ rozepsat do 5 ruzných ˚ ( „zobraz detail vozidla“, „pˇridej nové vozidlo“, „uprav vozidlo“, „archivuj vozidlo“, „odarchivuj vozidlo“), ale diagram by se stal velmi nepˇrehledným. Jednotlivé interakce jsou proto rozepsány v seznamu událostí níže. Operátor — terminátor prezentující lidskou obsluhu, která IS používá. V požadavcích není uvedena specifická autorizace uživatele, ale protože bude IS dostupný na veˇrejné adrese, asponˇ základní autorizace je na místˇe. Informaˇcní systém každopádnˇe umožnuje ˇ zavést složitˇejší autorizaˇcní omezení na uživatele, více v kapitole implementace. Sbˇerný bod — terminátor prezentuje jeden z vysílaˇcu˚ na pˇredpokládané trase vozidel. Když se dostane auto do jeho dosahu, naˇcte z jeho senzorové sítˇe aktuální data a odešle je do IS GoogleMaps — server GoogleMaps je uveden, protože IS ho využívá pro generování map, at’ už zobrazování polohy vozidel, polohy sbˇerných bodu˚ nebo trasy vozidel. 3.2.1.2 DFD diagram Uvedl jsem cílenˇe pouze nejvyšší vrstvu DFD diagramu, protože témˇerˇ všechny procesy se rozpadají na menší podprocesy, podobnˇe jako jsem zjednodušil interakce v kontextovém diagramu. Výˇcet všech procesu˚ by byl ale v diagramu neˇcitelný, proto jsem je uvedl v seznamu událostí níže. seznam událostí a minispecifikace procesu˚ •
1.1.1 zobrazení detailu vozidla — zobrazí podrobné hodnoty k vozidlu: kapacitu baterie, datum poslední servisní kontroly, poznámka k vozidlu (napˇríklad pro spz). 9
3.2. NÁVRH IS
Obrázek 3.3: Horní úrovenˇ DFD diagramu Zárovenˇ umožnuje ˇ editaci hodnot pro dané vozidlo. Pro archivované vozidlo není akce pˇrípustná. •
1.1.2 pˇridání vozidla — zavedení nového vozidla do evidence. Pouze kapacita baterie je povinný parametr.
•
1.1.3 archivování vozidla — protože vozidla figurují v cˇ árových statistikách (pˇresnˇeji v grafu hodnot atributu vozidla bˇehem jízdy), nelze je kvuli ˚ jejich konzistenci smazat. Smazáním vozidla ho pouze pˇresune do archivu. Pro archivované auto nelze zakládat nové jízdy. Stejnˇe tak nelze archivovat auto, které je pˇriˇrazené k nˇejaké neuzavˇrené jízdˇe.
•
1.2.1 zobrazení detailu sbˇerného bodu — umožnuje ˇ i jeho editaci. Sbˇerný bod muže ˚ v události 1.6 bud’to posílat pˇrímo geolokaˇcní atributy, nebo svoji identifikaci — geolokaˇcní atributy pro danou jízdu se pak doplní podle sbˇerného bodu.
•
1.2.2 pˇridání sbˇerného bodu — zavedení nového sbˇerného bodu do evidence. Sbˇerný bod má pouze geolokaˇcní atributy. Bod po svém uložení získá identifikaˇcní cˇ íslo, které muže ˚ posílat místo geolokaˇcních atributu˚ v události 1.6
•
1.2.3 smazání sbˇerného bodu — odstranˇení sbˇerného bodu z evidence, operace je ˚ poslání identifikace smazaného bodu selhání. nevratná. V události 1.6 zpusobí
•
1.2.5 promítnutí pozice sbˇerného bodu na mapu, napˇríklad pro kontrolu operátorem. Operátor muže ˚ vybrat vícero bodu˚ naráz, napˇríklad pro kontrolu pokrytí dojezdové oblasti.
•
1.3.1. zobrazení detailu atributu vozidla, zárovenˇ umožnuje ˇ jeho editaci. Typ hodnoty atributu a kód atributu nelze zmˇenit, protože je již zaveden v statistikách.
•
1.3.2 pˇridání atributu vozidla. Atribut obsahuje povinné parametry „kód“ (použije se jako identifikátor hodnoty v události 1.6), „typ“ (urˇcuje datový typ hodnot, jaký 10
3.2. NÁVRH IS bude systém zpracovávat v události 1.6, možné hodnoty a jejich významy viz pˇríloha B) a volitelný popis. Kód musí být mezi nearchivovanými atributy unikátní. •
1.3.3 archivace atributu vozidla — atribut nelze smazat kvuli ˚ jeho výskytu ve statistikách hodnot atributu. ˚ Aby se zachovala jejich konzistence, smazání ho pouze pˇresune do archivu. Uvedení kódu archivovaného atributu v události 1.6 zpusobí ˚ její selhání. Archivovaný atribut lze obnovit událostí 1.3.4.
•
1.3.4 vyjmutí atributu vozidla z archivu — opaˇcný proces k 1.3.3 Nelze vyjmout atribut z archivu, pokud by tím byla porušena unikátnost kódu nearchivovaných atributu. ˚
•
1.4.1 zobrazení detailu jízdy. Krom parametru˚ jízdy (datum zahájení, ukonˇcení, identifikace vozidla) jsou zobrazeny i hodnoty už bˇehem jízdy nashromáždˇené. Zárovenˇ umožnuje ˇ editaci atributu˚ jízdy i hodnot namˇerˇ ených bˇehem ní.
•
1.4.2 Založení nové jízdy. Operátor vybere vhodné nearchivované a neobsazené auto a zadá datum a cˇ as zaˇcátku. Neukonˇcená jízda blokuje auto pro další jízdy.
•
1.4.3 Úprava hodnot namˇerˇ ených bˇehem jízdy. V detailu jízdy muže ˚ operátor editovat jednotlivé namˇerˇ ené hodnoty. Ukládané hodnoty jsou kontrolovány podle typu atributu.
•
1.4.4 Ukonˇcení jízdy. Operátor vybere neukonˇcenou jízdu a zadá datum ukonˇcení. Tím je auto uvolnˇeno pro další jízdy.
•
1.5.1 Aktuální poloha aut. Operátorovi je na mapˇe zobrazena poslední známá poloha vozidel získaná z posledních namˇerˇ ených údaju˚ v otevˇrených jízdách.
•
1.5.2 Volná vozidla. Operátorovi se zobrazí seznam momentálnˇe dostupných vozidel (tj vozidel, které se neúˇcasní neukonˇcené jízdy).
•
1.5.3 Export geolokaˇcních atributu˚ jízdy do formátu GPX. Operátor vybere jednu cˇ i více jízd z tabulkového pˇrehledu a nechá si vygenerovat výsledné xml podle standardu GPX (standard pro geolokaˇcní data, používají ho napˇríklad satelitní navigace). [11]
•
1.5.4 Export geolokaˇcních atributu˚ jízdy do formátu KML. Operátor vybere jednu cˇ i více jízd z tabulkového pˇrehledu a nechá si vygenerovat výsledné xml podle standardu KML (jiný standard, používá ho napˇríklad Google Earth). [12]
•
1.5.5 Export hodnot atributu˚ jízdy do grafu. Operátorovi vybere jednu cˇ i více jízd z tabulkového pˇrehledu a nechá si vygenerovat výsledné grafy, generované pro hodnoty atributu˚ typu int namˇerˇ ených bˇehem vybraných jízd. 11
3.2. NÁVRH IS •
1.6 uložení dat jízdy — událost vyvolaná sbˇerným bodem. Sbˇerný bod jí ukládá aktuální hodnoty ze senzorové sítˇe pro vozidlo ve svém dosahu. Data se neuloží v následujících pˇrípadech poslaných dat: –
žádná identifikace vozidla
–
identifikace vozidla, které se zrovna neúˇcastní žádné jízdy
–
identifikace archivovaného vozidla
–
ani identifikace sbˇerného bodu, ani geolokaˇcní atributy v datech
–
neexistující kód atributu, nebo kód archivovaného atributu
Pro hodnoty atributu˚ neodpovídající typu atributu se hodnota atributu neuloží. Krom geolokaˇcních atributu˚ (nebo identifikace sbˇerného bodu) není žádná hodnota povinná. •
3.2.2
1.7 zjisti mˇerˇ itelné atributy — událost vrací aktuální nastavení mˇerˇ ených atributu, ˚ slouží pro ladící úˇcely. Zobrazují se povinné a/nebo volitelnlé atributy, spolu s kódem a typem. Stavovˇe pˇrechodový diagram
STD (z angl. state transition diagram) diagram slouží k modelování posloupnosti stavu˚ kterých muže ˚ nˇejaký objekt nabývat, nebo poˇradí procesu, ˚ v jakém musí být vykonány. Pokud je souˇcástí analýzy i CDFD diagram, je STD povinný a zakresluje právˇe poˇradí spouštˇených procesu˚ a jejich návaznost na stavy objektu. ˚ Z tohoto typu diagramu vychází UML state diagramy. Pokud bych modeloval práci obsluhy jako rˇ ídící proces, CDFD a STF by mohly vypadat pro IS zhruba takto: 3.2.3
Entitnˇe relaˇcní diagram
ERD diagram modeluje cˇ istˇe datovou strukturu jednotlivých elementu˚ IS (entity a jejich atributy, vztahy mezi entitami) IS, bez funkcionality. V praxi se pak témˇerˇ bez úprav pˇrevádí na strukturu relaˇcní databáze. Na diagramu se muže ˚ objevit nˇekolik typu˚ objektu: ˚ entita — reprezentuje 1 datový objekt, mající jméno a nˇejaké atributy (asponˇ jeden). Hodnoty atributu˚ pak urˇcují konkrétní „instance“ objektu. ˚ atribut — reprezentuje vlastnost entity, má jméno, hodnotu a datový typ, který urˇcuje jeho pˇrípustné hodnoty. Nˇekteré atributy urˇcují identitu objektu, ˚ tˇem se rˇ íká klíˇcové. relace — modeluje vztah mezi 2 entitami. Každý z „koncu“ ˚ relace má ještˇe kardinalitu, která urˇcuje možný poˇcet výskytu˚ jedné entity (jednoho jejího reprezentanta) vuˇ ˚ ci druhé (jejím reprezentantum). ˚ Zpravidla se uvádí hodnoty 0, 1 nebo N pro každou ze stran, znamenající popoˇradˇe žádnou, právˇe jednu nebo vícero výskytu˚ reprezentanta. Pro interval se používají jejich kombinace, napˇríklad 0-1 znamená maximálnˇe 1 výskyt (nebo žádný). Složitˇejší relace typu N:N (libovolný poˇcet výskytu˚ na obou stranách) se vˇetšinou modelují novou entitou, s níž jsou puvodní ˚ entity spojeny vazbou 1:N 12
3.2. NÁVRH IS
Obrázek 3.4: CDFD a STD a jejich vzájemná souvislost
Obrázek 3.5: ERD notace 2 entit s relací 0..1 : 1..N Doplnˇení k notaci, kterou používá muj ˚ CASE nástroj (Enterprise Architect [1]): •
povinný atribut entity je znaˇcen hvˇezdiˇckou pˇred jménem atributu
•
klíˇcový atribut má pˇred jménem PK
•
cizí klíˇc (1:1 relace mezi klíˇcovým atributem 1. entity a atributem 2.) má pˇred jménem 2. entity FK, a u obou koncu˚ relace jsou vypsané jména pˇríslušných atributu˚
•
datový typ atributu je za jeho jménem
•
<
> v originální notaci také není, podobnˇe jako ikonka v záhlaví entity
Návrh ERD pro IS zde 13
3.2. NÁVRH IS
Obrázek 3.6: návrh ERD Car entita reprezentující jedno vozidlo. Atributy: id — identifikace entity checked — datum poslední technické kontroly max_battery — kapacita baterie elektromobilu deleted — pˇríznak, že je auto archivované Ride entita reprezentující jednu jízdu vozidla. Atributy: id — identifikace entity start — datum a cˇ as zaˇcátku jízdy end — datum a cˇ as konce jízdy 14
3.2. NÁVRH IS car_id — odkaz na konkrétní vozidlo
Node entita reprezentující jeden sbˇerný bod (vysílaˇc). Atributy: id — identifikace entity width — zemˇepisná šíˇrka, polovina GPS souˇradnice, použije se v 1.6 height — zemˇepisná výška, polovina GPS souˇradnice, použije se v 1.6
Datatype cˇ íselník typu˚ hodnot atributu˚ vozidel. Urˇcuje konrétní typ validace, který se bude nad atributy daného typu provádˇet, a konkrétní typy reportu, ˚ které pro atribut pujdou ˚ zobrazit. Atributy: id — identifikace entity name — popisek pro zobrazení v nabídce formuláˇre
CarAttribute entita reprezentující 1 mˇerˇ itelný a sledovatelný atribut vozidla. Atributy: id — identifikace entity name — kód atributu description — popis system — pˇríznak, že je atribut povinný. 1.6 bez hodnoty tohoto atributu selže deleted — pˇríznak, že je atribut archivovaný datatype_id — odkaz do cˇ íselníku typu˚ hodnot atributu˚
RideData entita reprezentující 1 zmˇerˇ enou hodnotu atributu vozidla pro danou jízdu. Atributy: id — identifikace entity ride_id — odkaz na konkrétní jízdu ride_round — cˇ íselná stoupající rˇ ada, všechny hodnoty z jedné události 1.6 mají toto cˇ íslo stejné attribute_id — odkaz na konkrétní atribut vozidla attribute_value — namˇerˇ ená hodnota
3.2.4
Datový slovník
Obsahuje kompletní výˇcet všech datových objektu˚ a jejich možných hodnot ze všech modelu˚ návrhu (datové toky z DFD, STD a samozˇrejmˇe i ERD). Každý datový objekt je popsán za použití jednodušších prvku˚ a specifické syntaxe. 15
3.2. NÁVRH IS symbol = + { .. }
[ .. | .. ] ( .. ) ’ .. ’ \ .. \
význam složený z spolu s neomezené opakování
jeden z volitelnˇe hodnota komentáˇr
popis objekt nalevo od „=“ je složený z prvku˚ napravo sluˇcuje objekty do neseˇrazené množiny (výˇcet) neomezené opakování prvku uvnitˇr závorek. Lze napsat cˇ íslo pˇred první a za poslední závorku, znamenají pak maximální horní, resp minimální dolní, hranici (napˇr „2{ A }4“ znamená 2—4 opakování objektu A) právˇe jedna z možností (prvky oddˇelené „|“) výskyt prvku je nepovinný hodnota mezi uvozovkami mezi lomítky je uveden komentáˇr pro cˇ tenáˇre diagramu
Tabulka 3.1: Syntaxe používaná v datovém slovníku Datový slovník navrhovaného IS Kompletní datový slovník byl vygenerovaný v podstatˇe pouze z ERD diagramu, datové objekty figurující v DFD jsou ty samé. Vozidlo = id + posledníKontrola + baterie + archivace + popisek id = cˇ íslo posledníKontrola = datum baterie = cˇ íslo archivace = pravda popisek = text Jízda = id + start + konec + autoId start = datum + cˇ as konec = datum + cˇ as autoId = cˇ íslo SbˇernýBod = id + šíˇrka + výška šíˇrka = gpsSouˇradnice výška = gpsSouˇradnice typHodnoty = [ ’int’ | ’gps_width’ | ’gps_height’ | ’text’ ] AtributAuta = id + kód + popisek + typHodnoty + archivace + povinný kód = { text | ’-’ | ’_’ } povinný = pravda dataJízdy = id + idJízdy + cˇ ísloMˇerˇ ení + idAtributu + hodnota idJízdy = cˇ íslo idAtributu = cˇ íslo cˇ ísloMˇerˇení = cˇ íslo 16
3.2. NÁVRH IS hodnota = { text | cˇ íslo | ’.’ | ’,’ } text = { a až z | A až Z } cˇ íslo = {0 až 9} pravda = [ ano | ne ] cˇ as = 2{ˇcíslo}2 + ’:’ + 2{ˇcíslo}2 + ’:’ + 2{ˇcíslo}2 / HH:MM:SS / datum = 4{ˇcíslo}4 + ’-’ + 2{ˇcíslo}2 + ’-’ + 2{ˇcíslo}2 / YYYY-MM-DD / gpsSouˇradnice = {ˇcíslo} + "," + 4{ˇcíslo} 3.2.5
Architektura, Technologie
Poslední sekce návrhu se zabývá technickými aspekty navrhovaného systému, jako je napˇríklad výbˇer vhodných technologií, standardu˚ komunikace a architekturou celé „aplikace“. 3.2.5.1 Technologie Vzhledem k požadavkum ˚ kladeným na IS jsem uvažoval následovnˇe. Protože IS musí poskytovat rozhraní pro sbˇerné body, které budou umístˇené nˇekde v terénu, podle puvodního ˚ plánu v mˇestské zástavbˇe, omezil jsem výbˇer technologií jen na serverové. Zárovˇen musí IS poskytovat rozhraní pro lidskou obsluhu, teoreticky i víc osob najednou z ruzných ˚ míst (pro každé parkovištˇe vozidel). Abych nekladl zbyteˇcné nároky na poˇcítaˇcové stroje obsluhy, zvolil jsem webové technologie. Obsluha si tak vystaˇcí tˇreba s chytrým telefonem a pˇripojením k internetu. Navíc v požadavcích je promítání objektu˚ na mapu, variantu lokálnˇe uložených map jsem zavrhl z duvodu ˚ jejich zastarávání a kalibrace (pˇrepoˇcty gps souˇradnic do konkrétního mˇerˇ ítka v posunuté mapˇe). Pro pˇrenos dat ze sbˇerných bodu˚ (vysílaˇcu) ˚ na HTTP vrstvˇe (kvuli ˚ infrastuktuˇre, vˇetšinou je povolený pouze port 80) jsem pak váhal mezi nˇekolika standardy pro vzdálené volání procedur (viz RPC). Klíˇcovým kritériem byly co nejmenší nároky na vyrobení požadavku, abych usnadnil implementaci sbˇerných bodu. ˚ Nejdˇríve zvažovaný SOAP jsem brzy zavrhl a zvolil jeho jednoduššího pˇredchudce, ˚ XML-RPC. Díky zvolené architektuˇre ale nebude problém implementovat nˇejaký jiný, ještˇe jednodušší standard (napˇr. REST). Z webových technologií bych vybral PHP, zejména z duvodu, ˚ že další práce s IS témˇerˇ jistˇe budou. PHP je skriptovací jazyk s širokou paletou implementovaných knihoven, což se bude hodit pokud pro sbˇerné body nebude navrhovaný standard z nˇejakého duvodu ˚ vhodný (a napˇr. CORBA by byl vhodnˇejší). Zárovenˇ široká uživatelská základna jazyka znamená levnˇejší pracovní sílu. Vzdálené volání procedur (RPC, z angl. remote procedure call) je technologie dovolující aplikaci vykonat jinou metodu cˇ i rutinu v jiném adresním prostoru, napˇríklad na jiném poˇcítaˇci, aniž by se programátor musel starat o konkrétní implementaci jiné procedury nebo se starat o pˇrenos dat. V doménˇe objektových jazyku˚ se témuž principu také rˇ íká remote method invocation. Motivací muže ˚ být napˇríklad sdílení výpoˇcetní kapacity — delegace výpoˇctu na rychlejší stroj. Nebo odstranˇení závislosti na konkrétní implementaci, protože 17
3.2. NÁVRH IS z pohledu volajícího se metoda chová jako absolutní black box, známé jsou pouze parametry a jejich formát. Poslední typickým duvodem ˚ je absence funkcionality lokálnˇe. Oproti volání lokálních metod navíc hrozí riziko chyby vzniklé nˇekde pˇri pˇrenosu (napˇr. pˇrerušení spojení). Krom toho, že se s takovou potenciální chybou musí klient poˇcítat, se navíc nedozví, jestli byla cílová metoda zavolána, cˇ i ne (jedna z poˇcítaˇcových obdob problému "Schrödingerovy koˇcky" [15]). Drtivá vˇetšina takových volání je synchronní, tzn že klient cˇ eká na odpovˇed’ druhé strany) Komunikace mezi klientem a serverem (volajícím a volaným) probíhá v principu následovnˇe: 1. klient volá chtˇenou metodu, ale na lokálním zástupném objektu (jinak též proxy, stub cˇ i mock objekt) 2. ten zakóduje identifikaci metody spolu s parametry do standardizované zprávy a pošle ji serveru 3. server pˇrijme zprávu a reverzních procesem k zakódování ji rozbalí 4. server pustí metodu s danými parametry, její návratovou hodnotu zakóduje a pošle klientovi 5. klientuv ˚ zástupný objekt dekóduje návratovou hodnotu a vratí její výsledek Protože problém má velmi široké uplatnˇení, existuje celá rˇ ada ruzných ˚ standardu˚ a implementací pro ruzné ˚ programovací jazyky. [16] Zaˇcnu od tˇech složitˇejších. SOAP (z angl. Simple Object Access Protocol) je protokol pro výmˇenu strukturovaných dat postavený na standardu XML. Zpráva posílaná pˇres SOAP je cˇ istˇe v XML formátu, obsahuje následující cˇ ásti: obálku která urˇcuje, jaká je struktura uvnitˇr zprávy a jak to zpracovat (napˇríklad ) hlaviˇcka nepovinná cˇ ást zprávy, umožnuje ˇ rozširovat SOAP protokol pro potˇreby konkrétních aplikací (napˇríklad pˇredávání dat nikoli pro metodu, ale pro SOAP serializéry). tˇelo povinná cˇ ást zprávy, obsahuje zakódovaný identifikátor metody a parametry pro ní Protokol podporuje široké možnosti autorizace, datové pˇrílohy cˇ i tˇreba šifrování dat. SOAP jako protokol se týká pouze formátu zpráv a komunikace se serverem, transportní vrstva ale není omezena pouze na HTTP, zvládne tˇreba i SMTP nebo JMS. Další zajímavá vlastnost je schopnost validovat parametry a jejich strukturu na základˇe veˇrejnˇe viditelného popisu — wsdl (z angl. web service definition language) souboru. ˚ Kritici standardu vytýkají, že pomˇer dat ve zprávˇe ku obsahu vynucenému standardem je pˇríliš malý, je to danˇ za cˇ itelnost komunikace i cˇ lovˇekem. Ukázka zprávy [27] [28] XML-RPC jde o pˇredchudce ˚ protokolu SOAP. Také používá zprávy dle standardu XML. Narozdíl od SOAPu dovoluje pouze jeden typ serializace dat, SOAP jich umí vícero. I jeho 18
3.2. NÁVRH IS POST /InStock HTTP/1.1 Host: localhost Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> <soap:Body> <m:GetStockPrice xmlns:m="http://www.example.org/stock"> <m:StockName>IBM
Pˇríklad 3.2.1: Ukázka jednoduché SOAP zprávy autorizaˇcní možnosti jsou omezené na nástroje HTTP vrstvy (HTTPS pro šifrování, autorizace pˇres kombinaci pˇrihlašovací jméno — heslo). Taktéž neumí nativnˇe zveˇrejnovat ˇ poˇcet a strukturu parametru, ˚ to musí být rˇ ešeno aplikaˇcnˇe (metodou typu „dejKonfiguraciMetod“). Ikdyž je protokol oproti SOAPu ménˇe upovídaný, kritici by šli ještˇe dál. Ukázka zprávy [29] POST /InStock HTTP/1.0 Host: localhost Content-Type: text/xml Content-length: 160 <methodCall> <methodName>GetStockPrice <params> <param><string>IBM
Pˇríklad 3.2.2: Ukázka jednoduché XML-RPC zprávy
REST (z angl. representational state transfer) je typ architektury, nikoli protokol nebo standard. Stojí stejnˇe jako XML-RPC na HTTP protokolu (resp vznikl s ním souˇcasnˇe), ale používá ho plnˇeji, napˇríklad narozdíl od XML-RPC serveru, který používá z HTTP akorát POST a GET metody, REST server rozumí i PUT a DELETE. Stejnˇe jako v již zmínˇených protokolech existují 2 strany volání — klient a server. Server klientovi posílá reprezentaci nˇejakého stavu. Klient posílá serveru požadavek na zmˇenu stavu. Formát výmˇeny dat není 19
3.2. NÁVRH IS urˇcen, narozdíl od protokolu, ˚ které komunikovaly v XML. Tím odpadají formální hlaviˇcky požadavku˚ a metod, tím se zmenšuje objem komunikace. Nejvˇetší implementace systému s touto architekturou je WWW. Webový server klientovi reprezentuje stav objektu „aktuálnˇe zobrazená stránka“. Jakmile klient chce zmˇenit stav, resp pˇrejít napˇríklad na jinou stránku, pošle serveru HTTP požadavek GET s parametrem jiné URL. Ukázka zprávy [24] GET /InStock/StockPrice/IBM HTTP/1.0 Host: localhost
Pˇríklad 3.2.3: Ukázka jednoduché REST zprávy
3.2.5.2 Architektura IS musí poskytovat 2 ruzná ˚ rozhraní, jedno pro lidskou obsluhu, druhé pro strojové volání. Zárovenˇ musí být systém jednoduše rozšiˇrovatelný napˇríklad co se týˇce typu˚ hodnot atributu, ˚ jejichž zmˇena se promítne do všech rozhraní. Nemˇel by proto být rozpadnutý na nesouvislé celky spojené napˇríklad pouze na úrovni datové vrstvy. Hledal jsem nˇejaký architektonický návrhový vzor, který splnil obˇe podmínky. Zvolil jsem architekturu MVC, která splnuje ˇ požadavky z nˇekolika duvod ˚ u: ˚ •
oddˇelený výkonný kód od rozhraní (tzn rozhraní nezávislá na logice)
•
známý návrhový vzor (tzn další programátor se rychle zorientuje)
•
pro zvolené technologie existuje celá rˇ ada frameworku, ˚ které tuto architekturu podporují
architektonický vzor MVC (z angl. model view controler) od sebe oddˇeluje výkonnou, doménovou, logiku (do komponenty „model“), od prezentaˇcní logiky (komponenta „view“) a rˇ ídící logiky (komponenta „controller“). Typický požadavek od uživatele na aplikaci pak probíhá (diagramem zde): 1. uživatel vyvolává požadavek na prezentaˇcní vrstvˇe (kliknutí na tlaˇcítko) 2. prezentaˇcní vrstva pˇredá požadavek rˇ ídící komponentˇe, která ho identifikuje 3. rˇ ídící komponenta spustí metodu nebo si vyžádá data od doménové logiky 4. komponenta doménové logiky provede co jí bylo naˇrízeno rˇ ídící komponentou a vrátí data 5. rˇ ídící komponenta pˇredá data do prezentaˇcní vrstvy, ta zobrazí výsledek uživateli 20
3.2. NÁVRH IS Mezi bežné modifikace patˇrí i komunikace mezi prezetaˇcní komponentou a doménovou logikou pro potˇreby naˇcítání dat. Další velmi cˇ astá úprava je spojení prezentaˇcní komponenty a rˇ ídící logiky do jedné. Uvedené má následující výhody: •
separace jednotlivých implementací od sebe zvyšuje cˇ istotu kódu (jasnˇe dané rozhraní)
•
jednotlivé komponenty se mužou ˚ specializovat na to, co dˇelat mají, bez ohledu˚ na ostatní komponenty
•
každá z komponent má jinak cˇ asovaný životní cyklus, napˇríklad prezentaˇcní vrstva se mˇení v prubehu ˚ životního cyklu neustále, naopak doménová se zpravidla nemˇení (tam se vˇetšinou jenom pˇridává). Oddˇelením do odlišných komponent se snižuje riziko zavleˇcení chyby s úpravou jiné komponenty
•
bezproblémové pˇridávání dalších rozhraní
Návrhový vzor se v souˇcasné dobˇe nejvíce využívá právˇe u webových projektu, ˚ kde je zpravidla prezentaˇcních vrstev nˇekolik (www, webové služby, rss apod), ale všechny sdílejí stejnou doménovou logiku.
Obrázek 3.7: Schéma komunikace v návrhovém vzoru MVC
21
Kapitola 4
Implementace IS V této kapitole rozeberu dílˇcí detaily z fáze implementace. Výsledný kód je na pˇriloženém CD. Funkˇcní verze IS bˇeží na adrese , instalaˇcní manuál pro nasazení na jiném serveru je též v pˇríloze.
4.1
využívané knihovny
Abych usnadnil práci dalšímu vývojáˇrí, snažil jsem se používat pouze knihovny používané v bˇežné praxi. 4.1.1
PHP framework
Zvažoval jsem pouze ty frameworky, které pasují do zvoleného architektonického rˇ ešení, mají dostupnou dokumentaci a jsou bˇežnˇe používané. V užším výbˇeru zustal ˚ pouze Zend Framework [30], CakePHP [8] a Nette [21], splnují ˇ všechny požadavky (Nette má slabší dokumentaci, ale má aktivní cˇ eskou komunitu). Zend jsem vylouˇcil jako první, je to pˇríliš velký framework pro potˇreby takhle malého a jednoduchého IS, navíc není nejrychlejší, tˇreba v porovnání s Nette. [7]. Pˇri výbˇeru mezi Nette (ˇceský) a CakePHP (americký) jsem dal preferenci cˇ eskému frameworku, jelikož v poslední dobˇe získal hodnˇe na popularitˇe a zajímalo mne proˇc. Nette Nette je velmi mladý framework, jeho vydání spadá do roku 2008. Ze zajímavých vlastností, které má proti konkurenci, bych vyzdvihl ladící nástroje, rychlost, používání jmenných prostoru˚ (jako první PHP framework) a velmi cˇ istý kód. Bohužel oproti starším konkurentum ˚ ztrácí na dokumentaci a tutoriálech (díky velmi rychlému vývoji je vˇetšina tutoriálu˚ psaná pro staré verze Nette). Framework je navržen cˇ istˇe objektovˇe a podporuje architekturu MVC, pro databázovou abstrakci používá knihovnu Dibi [17]. Má zabudované ochrany proti ruzným ˚ typum ˚ webových útoku˚ (napˇr XSS, XSRF) a vlastní šablonovací systém. Pro moderní webové aplikace je urˇcitˇe zajímavá podpora „cool url“ a definice ruzných ˚ deploymentu˚ v 1 konfiguraˇcním souboru. 4.1.2
XML-RPC
Pˇri výbˇeru xml-rpc knihovny jsem mˇel nˇekolik možností. Bud’ použít implementaci dodávanou s verzí PHP [22], nebo zvolit nˇejakou knihovnu. Nicménˇe dokumentace k XML-RPC 22
ˇ 4.2. OPTIMALIZACE (ANEB PROH RESKY PROTI NÁVRHU) serveru pro vlastní knihovnu PHP stále tvrdí, že jde o experimentální kód. [23] Zvolil jsem IXR knihovnu [3], díky jednoduššímu API, navíc jsem ji potkal v praxi v komerˇcní sféˇre. IXR knihovna je také novˇejší než projekt „XML-RPC for PHP“. [25] 4.1.3
grafy, mapy ..
K promítání na mapu jsem využil API poskytované firmou Google [19], kvalita a šíˇre jejich rozhraní, dokumentace k nˇemu cˇ i rychlosti odezvy zdaleka zastinuje ˇ konkurenci, navíc nabízí statické obrázky bez JS komponent (narozdíl tˇreba od API k mapám od Seznamu [26] cˇ i Atlasu [6]). Statické obrázky se více hodí pro potˇreby evidence, navíc se zobrazují nehledˇe na nastavení klientova prohlížeˇce. Pro kreslení grafu˚ jsem zvolil populární knihovnu JpGraph [20], setkal jsem se s ní již pˇred nˇekolika lety. Grafy by se samozˇrejmˇe daly vyrábˇet pˇrímo v systému, ale možnosti by byly daleko omezenˇejší. Až po dokonˇcení práce jsem objevil poskytované API od firmy Google, rozhodnˇe by to byla zajímavá varianta. [18]
4.2
optimalizace (aneb prohˇresky proti návrhu)
V prubˇ ˚ ehu implementace samozˇrejmˇe dochází k optimalizacím kódu a databázové struktury, aby bylo dosaženo optimálních provozních parametru˚ (rychlost odpovˇedi, složitost implementace, apod). Bohužel, vetšina optimalizací není podchycena v žádném z diagramu˚ cˇ i dokumentu, ˚ vzniklých pˇred samotnou implementací. Zárovenˇ takové nezmapované vlastnosti zpusobují ˚ pˇri údržbˇe IS nemalou práci navíc a jsou cˇ asto zdrojem zcela nepochopitelných chyb. Proto níže uvádím zmˇeny, kde jsem se odchýlil od návrhu z kapitoly 3. databáze — tabulka DataType byla zcela vynechána a puvodní ˚ cizí klíˇc, který do ní odkazoval, byl nahrazen sloupcem s výˇctovým typem. Pˇridání typu hodnoty stejnˇe vyžaduje zásah do kódu (minimálnˇe specifické validace), takže je zbyteˇcné mít výˇcet dvojmo v kódu i v databázi. Navíc se tím zjednodušily nˇekteré dotazy do databáze.
4.3
možnosti rozšíˇrení
Seznam úprav, které bude vhodné provést z duvodu ˚ jednodušší správy IS v budoucnu. Zárovenˇ jsou to vˇeci, které ted’ fungují a není potˇreba je mˇenit. Jelikož je IS stavˇen na zelené louce, chvilka bˇežného provozu je duležitˇ ˚ ejší než podobné drobné úpravy. databáze v datovém modelu je skryta jedna drobná vada, hodnoty namˇerˇ ené bˇehem jízdy auta se ukládají do sloupce s datovým typem varchar(100). Což je sloupec urˇcený pro text, z požadavku˚ to ale vypadá, že drtivá vˇetšina namˇerˇ ených hodnot bude cˇ íselná (možná s desetinnou cˇ árkou). Jelikož se pˇres namˇerˇ enou hodnotu nevyhledává ani nijak neparametrizují dotazy, niˇcemu tato neefektivita nevadí. Databázovˇe cˇ isté rˇ ešení by bylo ten sloupec zkopírovat s jinými datovými typy, na úrovni implementace pak vybírat správný sloupec pro zápis/ˇctení. 23
ˇ 4.3. MOŽNOSTI ROZŠÍ RENÍ kreslení grafu˚ v souˇcasné dobˇe používá knihovnu JpGraph, což pro potˇreby IS bohatˇe dostaˇcuje. Na druhou stranu, zpusobuje ˚ to nároky na instalované moduly na serveru. Lepší rˇ ešení by bylo pˇrepsat logiku generování na používání Google Chart Tools [18], podobnˇe jako se používá Google Maps API [19]. Sjednotí se tím používané knihovny a klesnou nároky na server, jediná výhoda JpGraph proti Google Chart Tools je funkˇcnost i na lokální síti bez pˇrístupu na internet.
24
Kapitola 5
Závˇer Myslím, že se mi podaˇrilo navrhnout dostateˇcnˇe otevˇrený IS, který bude plnit svoji roli, pˇrestože napˇr. formáty ani množství dat není dopˇredu známo. Pˇri návrhu jsem pˇrihlédl k pravdˇepodobným budoucím úpravám tak, abych usnadnil práci pˇri jejich zapracování a nasazení do provozu.
25
Literatura [1] Enterprise Architect, , dostupné dne 2012-05-15. 3.1.3, 3.2.3 [2] Staníˇcek, Z.: Datové modelování s použitím metody HIT, CS-COMPEX a.s., 1996, 80-902250-5-5, . 3.1.1 [3] The Incutio XML-RPC Library for PHP, , dostupné dne 2012-05-15. 4.1.2 [4] Polák, J. a Merunka, V. a Carda, A.: Umˇení systémového návrhu, Grada Publishing, 2003, 80-247-0424-2, . 3.1 [5] Kadlec, V.: Agilní programování, Computer Press a.s., 2004, 80-251034-2-0, . 3.1.2 [6] Atlas AMapy API, , dostupné dne 2012-05-15. 4.1.3 [7] srovnání rychlosti php frameworku, ˚ , 2008-09-11. 4.1.1 [8] CakePHP, , dostupné dne 2012-05-15. 4.1.1 [9] Grohmann, J.: Baterie pro ukládaní pˇrebytku energie z rozvodné sítˇe, 2011-04-05, . 1.1 [10] Heˇrmánek, J.: Zná Ondˇrej Liška fyzikální zákony?, 2011-02-28, . 1.1 [11] GPX: the GPS Exchange Format, , dostupné dne 2012-05-15. 3.2.1.2 [12] KML, , dostupné dne 2012-05-15. 3.2.1.2 [13] Mˇesta zavedou nizkoemisní zóny, , 2012-05-11. 1.3 [14] The Software crisis, , dostupné dne 2012-05-15. 2 26
[15] Schrödinger’s cat, . 3.2.5.1 [16] Remote procedure call, , dostupné dne 2012-05-15. 3.2.5.1 [17] Dibi is Database Abstraction Library for PHP 5., . 4.1.1 [18] Google Chart Tools, , dostupné dne 2012-05-15. 4.1.3, 4.3 [19] Google Maps API, , dostupné dne 2012-05-15. 4.1.3, 4.3 [20] JpGraph, , dostupné dne 2012-05-15. 4.1.3 [21] Nette, , dostupné dne 2012-05-15. 4.1.1 [22] XML-RPC dodávané s PHP distribucí, , dostupné dne 2012-05-15. 4.1.2 [23] dokumentace k api XMLRPC knihovny z distribuce PHP, , dostupné dne 2012-0515. 4.1.2 [24] RESTful Web services: The basics, , 2008-10-06. 3.2.5.1 [25] XML-RPC for PHP, , dostupné dne 2012-05-15. 4.1.2 [26] Mapy.cz API, , dostupné dne 2012-05-15. 4.1.3 [27] SOAP Version 1.2 Part 0: Primer (Second Edition), , dostupné dne 2012-05-15. 3.2.5.1 [28] SOAP, , dostupné dne 2012-05-15. 3.2.5.1 [29] XML-RPC, , dostupné dne 201205-15. 3.2.5.1 [30] Zend Framework, , dostupné dne 2012-05-15. 4.1.1
27
Pˇríloha A
obsah pˇriloženého CD Na pˇriloženém CD se nachází následující adresáˇre: /src/ — obsahuje zdrojové soubory IS /text/docbook/ — obsahuje zdrojové soubory bakaláˇrské práce, pro pˇrípadné exporty do jiných formátu˚ /text/ — obsahuje text bakaláˇrské práce ve formátu pdf /conf/ — obsahuje instalaˇcní skripty (založení databáze, instalaˇcní manuál)
28
Pˇríloha B
datové typy hodnot atributu˚ Seznam již implementovaných datových typu: ˚ int cˇ íslo s desetinnou cˇ árkou text libovolné znaky gps_width datový formát stejný jako int, ale umí se promítat na mapu, urˇcuje zemˇepisnou šíˇrku gps_height datový formát stejný jako int, ale umí se promítat na mapu, urˇcuje zemˇepisnou výšku
29
Pˇríloha C
instalaˇcní manuál C.1
minimální konfigurace
•
php, verze 5.1 a víc
•
mysql, verze 4.1 a víc
•
php má podporu GD, verze 2.0 a víc
•
php má alesponˇ 150MB pˇridˇelené pamˇeti (Nette pˇri prvním spuštˇení prohledává adresáˇre a indexuje tˇrídy)
C.2
instalaˇcní návod 1. vytvoˇrit mysql databázi, jméno databáze, pˇrihlašovací jméno a heslo si nˇekam zapsat 2. pˇripojit se k databázi a vytvoˇrit nezbytné tabulky, viz instalaˇcní skript pro vytvoˇrení struktury databáze 3. zkopírovat obsah adresáˇre /src/ do adresáˇre viditelného z webu, v dalším textu ho budu nazývat „www_root“ 4. upravit soubor /www_root/app/config.ini, nastavit hodnoty podle vytvoˇrené databáze, hodnoty plnte ˇ do sekce [development < production] pokud instalujete na svuj ˚ poˇcítaˇc, nebo sekce [production < common] pokud instalujete na server. database.database — jméno vytvoˇrené databáze database.host — jméno serveru, kde databáze bˇeží database.username — pˇrihlašovací jméno do databáze database.password — heslo pro pˇrihlášení do databáze 5. ujistit se, že server muže ˚ zapisovat do adresáˇru˚ /www_root/app/log/ a /www_ root/app/temp/. 6. ovˇerˇ it funkˇcnost JpGraph
30
Pˇríloha D
Instalaˇcní skript pro vytvoˇrení struktury databáze SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; CREATE TABLE IF NOT EXISTS ‘car‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘max_battery‘ int(11) NOT NULL, ‘checked‘ varchar(40) NOT NULL, ‘deleted‘ bit(1) NOT NULL DEFAULT b’0’, ‘note‘ text, PRIMARY KEY (‘id‘) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; CREATE TABLE IF NOT EXISTS ‘carattribute‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘name‘ varchar(200) NOT NULL, ‘description‘ text, ‘system‘ bit(1) NOT NULL DEFAULT b’0’, ‘deleted‘ bit(1) NOT NULL DEFAULT b’0’, ‘datatype‘ enum(’int’,’gps_width’,’gps_height’,’text’) NOT NULL, PRIMARY KEY (‘id‘) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; CREATE TABLE IF NOT EXISTS ‘node‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘width‘ float NOT NULL, ‘height‘ float NOT NULL, PRIMARY KEY (‘id‘) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; CREATE TABLE IF NOT EXISTS ‘ride‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT, ‘start‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, ‘end‘ timestamp NULL DEFAULT NULL, ‘car_id‘ int(11) NOT NULL, PRIMARY KEY (‘id‘) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ; CREATE TABLE IF NOT EXISTS ‘ride_data‘ ( ‘id‘ int(11) NOT NULL AUTO_INCREMENT,
31
ˇ ˇ D. I NSTALA CNÍ SKRIPT PRO VYTVO RENÍ STRUKTURY DATABÁZE
‘ride_id‘ int(11) NOT NULL, ‘ride_round‘ int(11) NOT NULL, ‘attribute_id‘ int(11) NOT NULL, ‘attribute_value‘ varchar(100) DEFAULT NULL, PRIMARY KEY (‘id‘) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
32
