VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky
Katedra informatiky
Absolvování individuální odborné praxe Individual Professional Practice in the
Company
Abstrakt
Tato bakalářská práce popisuje absolvování odborné praxe ve firmě GX Solutions Bohemia s.r.o. ve Frýdku-Místku. Po dobu své praxe jsem se zabýval vývojem webové aplikace pro GPS monitoring vozidel a strojů, získal jsem cenné zkušenosti v oblasti ASP.NET MVC aplikací, jejich návrhů a impletentací. V první části praxe jsem se seznámil s aplikací a řešil úkoly na její rozšíření. Ve druhé, hlavní, části své práce jsem se věnoval návrhu modulu pro predikci AETRu, který slouží ke sledování pracovního režimu řidičů v silniční dopravě a jejich doby řízení a odpočinku.
Klíčová slova: odborná praxe, GX Solutions Bohemia s.r.o., ASP.NET MVC, webová aplikace, AETR
Abstract
The thesis deals with author’s own professional practice in the company GX Solutions Bohemia s.r.o., located in Frýdek –Místek. The practice as based on developing a web application that would provide GPS monitoring of vehicles and machines. Not only I have improved my knowl- edge of this field, but I have also gained great experience in ASP.NET MCV applications, their designing and implementation. The first part of the practice included becoming acquainted with the application as well as solving problems with its extension. The second part of the practice was founded on designing a module for predicting AETR. This module will monitor working regimes of drivers in road transport, just as their driving and rest period.
Key Words: professional practice, GX Solutions Bohemia s.r.i., ASP.NET MVC, web applica- tion, AETR
Obsah
Seznam použitých zkratek a symbolů 8
1 Úvod 9
2 O firmě 10
2.1 Zaměření firmy . . . 10
2.2 Technický systém . . . 10
2.3 Aplikace GX-GO . . . 11
3 Průběh praxe 12 3.1 Pracovní úkoly . . . 12
3.2 Seznámení s aplikací . . . 12
3.3 Kalendář státních svátků . . . 12
3.4 Opravy chyb v aplikaci . . . 13
3.5 Tvorba sestav . . . 13
3.6 Úprava optimalizátoru . . . 14
3.7 Predikce AETRu . . . 15
4 Získané znalosti 21
5 Závěr 22
Literatura 23
Přílohy 23
A Příloha 24
Seznam použitých zkratek a symbolů
AETR – Evropská dohoda o práci osádek vozidel v mezinárodní silniční do- pravě
ASP – Active Server Pages
CSS – Cascading Style Sheets
ER – Entity-relationship
DEC – DevExpress Control
GPRS – General Packet Radio Service
GPS – Global Positioning System
GX-GO – Webová aplikace firmy GX Solutions Bohemia s.r.o.
HTML – Hyper Text Markup Language
JS – JavaScript
SVN – Subversion
LINQ – Language Integrated Query
Mantis – Systém pro evidenci chyb a úkolů
MVC – Model View Controller
PDF – Portable Document Format
PostgreSQL – Postgres Structured Query Language Resources – Lokalizované zdroje textů
Tachograf – Zařízení pro záznam rychlosti vozidla v závislosti na čase View – Zobrazení uživatelského rozhraní
WWW – World Wide Web
8
1 Úvod
Na následujících stránkách této práce budu popisovat své působení a výsledky dosažené ve firmě GX Solutions Bohemia s.r.o. (dále pouze firma), která se zabývá GPS monitoringem vozidel a strojů. Odbornou praxi jsem si zvolil jako alternativu bakalářské práce, jelikož mne lákalo vyzkoušet si spolupráci na vývoji velkého softwaru a práci v týmu.
Při svém působení ve firmě jsem pracoval v softwarovém oddělení na různých modulech a částech pro webovou aplikaci GX-GO (dále pouze aplikace), která je vyvíjena ve frameworku ASP.NET s architekturou MVC. Aplikace umožňuje uživatelům sledovat jejich vozidla a stroje na mapě a spoustu dalších doplňkových funkcí (např. kniha jízd, přehled spotřeby paliva, styl jízdy, optimalizované plánování jízd), na kterých jsem mimo jiné pracoval. Z počátku jsem se musel seznámit s celou aplikací, její přesnou architekturou (např. entity databáze) a také si nastudovat potřebný framework, což bylo nezbytně nutné abych se mohl zapojit do jejího vývoje.
Od svého nástupu do firmy jsem byl na pozici programátora, kde jsem plnil přiřazené úkoly, které byly z počátku jednodušší, pro seznámení s aplikací. Typově šlo o úpravy view a opravy nejrůznějších chyb v kódu. Poté jsem dostal přístup do systému Mantis, kde jsem si volil sám úkoly, které jsem konzultoval s vedoucím a vypracovával diagramy aktivit a ER diagramy dle potřeby. Zde jsem pracoval na tiskových sestavách a vylepšování stávajících modulů podle zadání.
Později jsem se začal věnovat svému hlavním úkolu, což byl modul pro predikci AETRu (dále pouze modul). Modul je značně rozsáhlý a zasahuje do všech částí aplikace. Modul je již v konečné fázi a měl by být nasazen do ostré verze.
2 O firmě
GX SOLUTIONS BOHEMIA, s .r. o. poskytuje produkty a služby firmám, které provozují ja- kýkoliv vozový park a druh dopravy. Firma je průkopníkem ve vývoji telemetrických řešení pro potřeby firemní flotily v jakémkoliv typu, složení a využití. Z počátku byly produkty jednodu- ché pro monitorování vozidel a strojů, v době, kdy GPS technologie byla méně rozšířená a tyto služby firma zajišťuje zákazníkům dodnes. Hlavním zaměřením se však postupně staly komplex- nější softwarové řešení pro fleet management, která zasahují do nových podnikatelských oblastí.
Každé řešení je s vazbou na pohyb, stav a výkony vozidel; činnost zaměstnanců a jakékoliv jiné požadované parametry sledování. [1]
2.1 Zaměření firmy
Firma se specializuje v těchto službách: [1]
• GPS monitoring
• Telemetrické řešení
• SW a HW řešení na míru zákazníka
• Odborné konzultace, poradenství a školení
• Servisní služby
Firma se zabývá vývojem aplikaci, které se specializují na GPS monitoring. Několik aplikací vydali v minulosti. Byly vyvíjeny na platformu Android, tedy pro mobilní zařízení, dále webová aplikace byla postavena na platformě Silverlight a dnes je zastaralá, proto započal vývoj nové aplikace s názvem GX-GO.
2.2 Technický systém
Do vozidel se instaluje GPS/GSM telematická jednotka. Vozidla se připojují z externího pro- středí na server GX. Komunikace mezi vozidlem a serverem probíhá on-line prostřednictvím GPRS. Data naměřená v reálném čase a zaznamenaná do paměti jednotky se přenášejí do sys- tému, kde se zpracují a uloží do databáze. Systém je postavený na vztahu klient-server. Uživatel musí mít nainstalovaný SW klienta SmartTDM, který se připojuje do aplikačního serveru s ce- lou aplikační logikou systému. Data z aplikačního serveru jsou k dispozici i prostřednictvím API rozhraní formou webové služby. [1]
Na schématu (viz. Obrázek 1) lze vidět popis systému. Jednotky ve vozidlech obsahují mnoho funkcí a naměřená data poté posílají na server. Pro uživatele je vyvíjena mimo jiné webová aplikace GX-GO.
10
Obrázek 1: Schéma fungování systému 2.3 Aplikace GX-GO
Jedná se o rozsáhlou webovou aplikaci, která využívá framework ASP.NET MVC. Pro uživatel- ské rozhraní jsou použity ovládací prvky DevExpress (dále pouze DEC), které nabízejí mnoho možností pro kreativní návrhy. Aplikace je primárně navržena pro sledování vozidel na mapě, ale nabízí velké množství dalších funkcí. Od běžných jako je kniha jízd, měření spotřeby vozi- dla, přes hodnocení stylu jízdy řidičů až po vypočtení optimální trasy nákladních vozidel. Tato aplikace je stále ve vývoji, avšak pro zákazníky je již dostupná z WWW stránek (viz. Citace [2]).
3 Průběh praxe
Ve firmě jsem pracoval v týmu jako jeden z programátorů na webové aplikaci GX-GO. Po dobu své praxe jsem splnil mnoho jednodušších úkolů, které se týkaly funkcionality z hlediska uživatele, tedy úpravy skriptů v jazyce JS, tvorba nových nebo úprava stávajících view v jazyce HTML. Poté několik složitějších úkolů, které zahrnovaly i práci s databází, tedy tvorbu metod pro práci s tabulkami v jazyce C#, kde jsem pro dotazy využil pomocný jazyk LINQ. Databáze je typu PostgreSQL, která má open source licenci. Pracovalo se s ní pomocí entity frameworku, který usnadnil práci s entitami. Používal jsem vývojové prostředí Visual Studio 2013 od firmy Microsoft, na které jsem byl zvyklý ze školy, proto mi práce v něm vyhovovala. Pro přístup do databáze jsem používal program pgAdmin III, který je určen pro postgreSQL databáze. Zdrojový kód aplikace a dokumentace k ní byla sdílena pomocí verzovacího systému SVN. Všechny úkoly, na kterých jsem pracoval, byly úspěšně dokončeny a výsledky jsou k vidění v ostré verzi aplikace.
3.1 Pracovní úkoly
Za svou dobu ve firmě jsem plnil několik úkolů, většina z nich byly jednoduché opravy chyb a malá rozšíření stávajících modulů. Zde jsem se rozhodl chronologicky napsat o svých úkolech a rozsáhlejší z nich popsat podrobněji. Přesný pracovní deník s rozpisem úkolů a jejich časového rozpoložení najdete v příloze na cd.
3.2 Seznámení s aplikací
Za můj první úkol lze považovat nastudování potřebných frameworků a technologií, které jsou v aplikaci použity. Proto jsem si nastudoval ASP.NET MVC, tedy hlavně jeho strukturu a významy jednotlivých souborů. Jelikož jsou v aplikaci použity uživatelské prvky DEC, musel jsem se seznámit i s nimi. Firma DevExpress na svých stránkách má přehledné ukázky použití ovládacích prvků a pro přesnější seznámení jsem četl dokumentaci(viz. Citace [10]). Tato příprava mi zabrala několik týdnů, poté jsem dostal přístup k aplikaci samotné. V dalších týdnech jsem se s aplikací seznamoval z uživatelského hlediska.
3.3 Kalendář státních svátků
Dostal jsem zadaný úkol, který spočíval ve vytvoření kalendáře státních svátků pro vybrané evropské státy. Úkol nebyl příliš složitý, měl hlavně posloužit jako pomůcka na poznání projektu.
Nejdříve jsem vytvořil návrh databázové tabulky pro státní svátky (viz. Tabulka 1). V da- tabázi již byla tabulka států, proto jsem k ní navázal tabulku svátků. Kardinalitu vztahu mezi tabulkami jsem zvolil M:N. Svátky mají název ve formě anglické zkratky, aby mohl být v apli- kaci později lokalizován neboli přeložen do požadovaného jazyka. Dále je zde atribut nazvaný IsFloating, který zodpovídá otázku, zda-li se jedná o pohyblivý svátek. Samotné vytvoření entit v databázi zpracoval můj nadřízený, já vytvořil metody v aplikaci pro práci s tabulkou. Dotazy
12
jsem psal za pomocí jazyka LINQ a byly pouze pro čtení, ostatní operace (přidávání, mazání, upravování) se prováděly mimo aplikaci v programu pgAdmin. Poté jsem entity namapoval a přidal metody do aplikačního serveru, tak jsem dostal data o svátcích až do webové aplikace.
Tabulka 1: Tabulka Holidays
Název Klíč Typ Nulový
HolidayID Primární Serial Ne
Title Ne Varchar(250) Ne
Day Ne Integer Ne
Month Ne Integer Ne
IsFloating Ne Boolean Ne
Webová aplikace pracuje na architektuře MVC, proto bylo nutné zajistit tyto 3 části. Nejdříve jsem vytvořil controller pro dané uživatelské rozhraní (View). Dále bylo zapotřebí získat data z databáze a upravit je pro potřeby view. Za tímto účelem jsem vytvořil pomocnou třídu, která volala metodu pro získání svátku pro jednotlivé státy a dále data upravovala, tedy zjištění překladu názvu a případný výpočet data pohyblivého svátku. Pro uživatelské rozhraní jsem použil již zmiňované ovládací prvky DEC. Pro tyto účely posloužil jejich plánovač (scheduler), který má vzhled kalendáře s upomínkami (appointments). Plánovač jsem upravil tak aby vypadal jako nástěnný kalendář a funkci upomínek jsem použil pro zobrazení státních svátků. Tedy jsem využil model od DEC a ten upravil pro státy a svátky. Pro rychlejší a efektivnější načítání dat jsem načítal svátky pouze vybraného státu a právě zobrazený interval dnů, pro jehož získaní jsem použil JS funkci. Tedy plánovač reagoval na každou změnu státu a data. Výsledek (viz.
Obrázek 2) jsem musel umístit do menu aplikace, což vyžadovalo pouze přidání několika odkazů.
Tento úkol mi zabral delší čas, avšak jsem se s jeho pomocí dověděl mnoho věcí o aplikaci, hlavně pak práci s některými prvky DEC. Tento úkol by se dal popsat jako ukázkový, protože většina dalších úkolů byla velice podobného charakteru.
3.4 Opravy chyb v aplikaci
Mezi mé další úkoly patřily úpravy již hotových view nebo opravy chyb. Dostal jsem přístup do
Obrázek 2: Ukázka kalendáře státních svátků
jsem vytvářel v nástroji DEC pro tvorbu sestav, který fungoval na principu přetahování prvků a zdrojový kód se generoval automaticky. Poté se pouze k sestavě přiřadil model a sestava mohla zobrazovat jeho data. View bylo velice jednoduché, pouze přednastavený zobrazovač sestav, kde byla možnost manipulace se sestavou před tiskem nebo převodem do některého z vybraných formátů (např. PDF). Metody byly potřeba za účelem získání dat pro sestavy a dále metody pro převod do jiných formátů. Takovýchto sestav jsem tvořil několik, které si byly podobné, avšak u každé bylo potřeba trochu jiné řešení zpracování dat.
U tohoto úkolu jsem si také vyzkoušel unit testing. Jedná se o metodu testování, při které se bez nutnosti spuštění celé aplikace testují jednotlivé metody. Používal jsem ji, abych si ověřoval zda aplikační server správně zpracovává data z databáze, které se poté zobrazují v sestavě. Tato metoda mi ušetřila spoustu času, jelikož spouštění celé aplikace bylo velice zdlouhavé. Namísto kompilace, spuštění, přihlášení a načtení sestavy stačilo pouze zkompilovat a sledovat výsledek, který metoda vrací. Unit testy jsem poté častokrát při práci využil.
3.6 Úprava optimalizátoru
Po sestavách jsem dostal za úkol úpravu modulu na optimalizaci a plánování tras. Hlavní bylo upravit view podle popisu a doplnění několika zobrazovacích funkcí do mapy. Upravit view vy- žadovalo přidat několik metod v JS a úpravy prvků DEC. Přidání zobrazovacích funkcí do mapy bylo už složitější. Nejdříve jsem vyhledal informace o knihovně OpenLayers, která umožňuje zobrazení a práci s mapou. K mapě jsem napsal několik událostí (event). Při najetí kurzoru na bod se zobrazila bublina s informacemi o bodu, styl bubliny jsem napsal v jazyce CSS. Bylo potřeba také body tvořit, a proto při kliknutí na jakékoliv místo na mapě se načetly GPS sou-
14
řadnice, kde se poté bod mohl zobrazit. Veškeré práce s mapou tedy probíhaly pouze v rámci skriptů.
3.7 Predikce AETRu
Nakonec jsem se dostal až ke svému hlavnímu úkolu, což je i téma mé praxe. Predikce AETRu je název modulu, který jsem navrhl a implementoval do aplikace. AETR je evropská dohoda o práci osádek vozidel v mezinárodní silniční dopravě, tedy jde o vyhlášku pro řidiče z povolání, přesné znění zmiňují citace [5] a [6]. Vyhláška určuje jaký čas mohou řidiči strávit řízením, jak často musí mít přestávky, jak dlouhé odpočinky atd. Vycházel jsem přesně z vyhlášky č. 561/2006 Sb. [4], která upřesňuje pravidla pro státy Evropské unie. Přestože vyhláška zmiňuje i provoz více řidičů (nejčastěji dvou), kteří se střídají v řízení, dle pokynu nadřízených jsem modul navrhl pouze pro jednoho řidiče.
Jak z názvu modulu napovídá, jedná se pouze o predikci, tudíž závisí na čestnosti řidiče, který ovládá digitální tachograf. Tachograf má každý řidič ve vozidle, do kterého se přihlásí čipovou kartou a na zařízení přepíná stavy. Data se poté posílají na server, kde si je přebírá mimo jiné i modul AETRu. Pokud však řidič tachograf nemá zapnutý nebo jej nepoužívá správně dojde k nesprávným výpočtům a data v aplikaci nebudou odpovídat realitě. Další funkce je předpověď, kdy z nasbíraných dat lze zjistit, jak dlouho řidič může ještě řídit, kolik mu zbývá do odpočinku atd.
3.7.1 Oficiální zadání
Podílení se na vývoji nového systému v GX. Student musí nastudovat problematiku AETRu. Na základě Evropské legislativy a zadání od GX implementovat tzv. predikci AETRu do systému GX vycházející ze zdrojových dat vozidel zákazníků GX. Implementace spočívá v zobrazení aktuálních stavů, predikcí, historický grafů a tabulek včetně rozhraní pro napojení na další částí systému jako např. routing. [3]
3.7.2 Analýza
Než jsem začal s návrhem, bylo nutné si nastudovat vyhlášku AETRu, kterou jsem našel na
• Pohotovost (Přestávka)
• Odpočinek
Tachograf se buď zapne automaticky po nastartování vozidla a přepíná základní stavy sám, nebo se musí zapnout a přepínat ručně. Automatický funguje tak, že po rozjetí vozidla se přepne na stavŘízení a při zastavení přejde na stavPohotovost. Další stavy si však musí řidič přepínat ručně. Pokud jde o neautomatizovaný přístroj, tak vše ovládá řidič, tudíž je správnost údajů založena na poctivosti řidiče.
Dle vyhlášky jsou stanoveny časy pro každý stav, které pak musí řidiči dodržovat. Některé jsou definovány jednoduše a snadno se počítají (např. Doba řízení), poté jsou zde však doby, které se počítají složitějším způsobem, například vyžadují data z více dnů (týdenní doba odpočinku atd). Na obrázku 5 jsou zjednodušená pravidla pro pracovní dobu řidiče.
Tyto pojmy a další, které jsem využil ve své práci jsou ve vyhlášce definovány takto:
• „dobou řízení“ celková doba řízení od okamžiku, kdy řidič začne řídit vozidlo po době odpočinku nebo přestávce, do okamžiku, kdy začne další doba odpočinku nebo přestávka.
Doba řízení může být nepřetržitá nebo přerušovaná. [4]článek 4
• „denní dobou řízení“ celková doba řízení mezi skončením jedné denní doby odpočinku a začátkem druhé denní doby odpočinku nebo mezi denní dobou odpočinku a týdenní dobou odpočinku. [4] článek 4
• „týdenní dobou řízení“ celková doba řízení během jednoho týdne. [4]článek 4
• „přestávkou v řízení“ doba, během níž nesmí řidič řídit ani vykonávat žádnou jinou práci a která je určená výhradně k jeho zotavení. [4] článek 4
• „dobou odpočinku“ nepřerušená doba, během níž může řidič volně nakládat se svým ča- sem. [4] článek 4
• „denní dobou odpočinku“ denní doba, během níž může řidič volně nakládat se svým časem a která zahrnuje „běžnou denní dobu odpočinku“ nebo „zkrácenou denní dobu odpočinku“:
– „běžnou denní dobou odpočinku“ se rozumí doba odpočinku v celkovém trvání nejméně 11 hodin. Tuto běžnou dobu odpočinku lze případně rozdělit do dvou časových úseků, z nichž první musí být nepřerušená doba v celkovém trvání nejméně 3 hodin a druhý nepřerušená doba v celkovém trvání nejméně 9 hodin,
– „zkrácenou denní dobou odpočinku“ se rozumí doba odpočinku v celkovém trvání nejméně 9 hodin, ale kratší než 11 hodin; [4] článek 4
• „týdenní dobou odpočinku“ týdenní doba, během níž může řidič volné nakládat se svým časem a která zahrnuje „běžnou týdenní dobu odpočinku“ a „zkrácenou týdenní dobu odpočinku“:
16
– „běžnou týdenní dobou odpočinku“ se rozumí doba odpočinku v celkovém trvání nejméně 45 hodin,
– „zkrácenou týdenní dobou odpočinku“ se rozumí doba odpočinku kratší než 45 hodin, která smí být za podmínek stanovených v čl. 8 odst. 6 zkrácena na nejméně 24 po sobě následujících hodin; [4] článek 4
• „týdnem“ období mezi 00.00 hodin v pondělí a 24.00 hodin v neděli. [4] článek 4
Dále jsou pravidla týkající se přímo času, jak dlouho která doba může maximálně nebo musí minimálně trvat a jak se dají tyto doby případně rozdělit na části.
Seznam nejdůležitějších pravidel, která jsem použil pro výsledný program:
• Denní doba řízení nesmí přesáhnout 9 hodin.
Nejvýše dvakrát za týden může být prodloužena na 10 hodin. [4] článek 6
• Týdenní doba řízení nesmí přesáhnout 56 hodin. [4] článek 6
• Celková doba řízení nesmí přesáhnout 90 hodin za období dvou po sobě následujících týdnů. [4] článek 6
• Po čtyřech a půl hodinách řízení musí mít řidič nepřerušenou přestávku nejméně 45 minut, pokud mu nezačíná doba odpočinku.
Tato přestávka může být nahrazena přestávkou v délce nejméně 15 minut, po níž následuje přestávka v délce nejméně 30 minut, které jsou v období rozloženy tak, aby byly v souladu s odstavcem 1. [4] článek 7
• V průběhu každých 24 hodin po skončení předchozí denní nebo týdenní doby odpočinku musí mít řidič novou denní dobu odpočinku.
Je-li denní doba odpočinku v průběhu těchto 24 hodin alespoň 9 hodin, ale kratší než 11 hodin, považuje se dotyčná denní doba odpočinku za zkrácenou. [4] článek 8
– jednu běžnou týdenní dobu odpočinku a jednu zkrácenou dobu odpočinku v celkové délce 24 hodin. Zkrácení však musí být vyrovnáno odpovídající dobou odpočinku vybranou v celku před koncem třetího týdne následujícího po dotyčném týdnu.
Týdenní doba odpočinku musí začít nejpozději po uplynutí šesti 24hodinových časových úseků od skončení předchozí týdenní doby odpočinku. [4] článek 8
• Každá doba odpočinku vybraná náhradou za zkrácení týdenní doby odpočinku musí bez- prostředně navazovat na jinou dobu odpočinku trvající nejméně 9 hodin. [4] článek 8
• Týdenní doba odpočinku, která začíná v jednom týdnu a pokračuje do týdne následujícího, může být připojena k jednomu nebo druhému z těchto týdnů, avšak nikoli k oběma. [4]
článek 8
Po vytvoření modulu, který bude data zpracovávat, je také bude ukládat do databáze. Také bude potřeba data zobrazit a pro tento účel budou sloužit 2 view. Jedno pro zobrazení aktuálního stavu řidičů a druhé pro zobrazení historických dat v tabulce nebo grafu.
3.7.3 Řešení
Práci na úkolu jsem si rozdělil do několika fází. Nejdříve jsem si nastudoval problematiku AETRu, kde jsem zjistil potřebná pravidla, která jsem implementoval do programu, jak je uve- deno výše v analýze.
Proto jsem nejdřív navrhl tabulku v databázi (viz. Obrázek 3). Byla potřeba pouze jedna tabulka (PersonHistoryAETR), která byla pomocí cizího klíče spojená s tabulkou osob (Person).
Jelikož jedna osoba bude mít mnoho záznamů o stavu a tyto záznamy se budou vztahovat pouze na tuto osobu, zvolil jsem tedy kardinalitu 1:N. Tabulka obsahuje parametr pro stav v podobě slovní (Status) a čísla (StatusCode), které odpovídá výčtovému typu v aplikaci. Další parametry jsou časy od (Since) a do (Until), kdy stav začal a kdy skončil. Čas Until může být nulový a podle toho poznáme, zda-li je stav právě probíhající, což usnadní dotazování nad aktivními stavy.
Navíc je zde parametr, který určuje přesnou dobu trvání stavu v sekundách (Duration) a slouží hlavně pro sledování trvání právě probíhajícího stavu. Parametr TimeStatus odpovídá dalšímu výčtovému typu v aplikaci, proto je celočíselného typu a určuje podrobnosti o stavu (např.
Příliš dlouhá doba řízení, Týdenní odpočinek atd.) a nakonec parametrIsTimeForDayOK nám ukazuje zda je stav pro stávající den v pořádku. Tabulku jsem do systému mapoval pomocí entity frameworku, tudíž je v aplikaci třída s totožnými parametry, což velice usnadňuje manipulaci s daty.
Po tabulce jsem vytvořil v aplikaci potřebné výčtové typy (enum), které jsem se rozhodl použít pro usnadnění práce v aplikaci a ušetření místa v databázi. Také porovnávání čísel probíhá mnohem rychleji než porovnávání řetězců (string) a navíc výčtový typ si zachová srozumitelnost
18
Obrázek 3: ER diagram tabulky PersonHistoryAETR
pro čtenáře jako řetězec. První výčtový typ určoval přesný stav řidiče (např. řízení, odpočinek atd.) a druhý zase určoval podrobnosti onoho stavu, které se však musely vypočíst.
Další fáze tedy byla implementace modulu do serveru poskytovatele GPS, který sbírá příchozí data od všech jednotek (vozidel) a hlavní třída je poté zpracovává dále. Hlavní třída funguje na vzoru pozorovatel-vydavatel (observer-observable), tedy po přijetí dat rozešle všem pozoro- vatelům zprávu a ti na ni reagují. Implementoval jsem tedy třídu se vzorem pozorovatele. Po přijetí dat z hlavní třídy se spustila metoda pro výpočet a uložení záznamu do databáze. Pro přehlednost tohoto procesu jsem vytvořil diagram aktivit (viz. Obrázek 4) a ten je nyní i součástí dokumentace aplikace. Diagram popisuje řadu podmínek souvisejících s dobou stavu, kterými projde záznam než se může uložit do databáze. Mimo jiné i ověřuje, zda-li novým stavem nepři- šel v platnost stav minulý, který mohl být samostatně vyhodnocen jako špatný, pokud taková situace nastane, starý stav se v databázi upraví. Pro testování jsem vytvořil testovací projekt a kód ověřoval metodou unit testing, kterou jsem znal už z předchozích úkolů. Tato část byla ze všech nejnáročnější co se týče návrhu a složitosti kódu.
V návrhu jsem postoupil na aplikační server, kde jsem opět vytvořil vlastní projekt, za účelem přivádění dat do uživatelského rozhraní. Zde jsem kód rozděloval na 2 části, aktuální stav (online) a historie. Začal jsem s online částí, která poskytuje data pro aktuální stavy řidičů.
Implementoval jsem podmínky v souladu s pravidly vyhlášky. Mimo aktuálního stavu, bylo
jak aplikační server, tak webová aplikace. Data byly následně předány do view k zobrazení.
Druhá část modulu v aplikačním serveru byly metody pro zobrazení historie. Tady však nebyly potřeba dodatečné výpočty a šlo pouze o získání dat podle časových parametrů pomocí dotazů nad databází.
V poslední fázi bylo potřeba navrhnout rozhraní pro uživatele (view). Opět jsem se řídil postupy z dřívějších úkolů a využil prvků DEC. Pro zobrazení aktuálního stavu řidičů jsem zvolil tabulku (gridview), ve které byli všichni řidiči se záznamem z AETRu (viz. Obrázek 6). Tabulka zobrazovala data, které získala z modulu v aplikačním serveru. Po kliknutí na řádek tabulky se zobrazily detailní údaje pro řidiče. Druhé zobrazení sloužilo k prezentaci historických dat (viz.
Obrázek 7). Pro tento účel jsem zvolil prvek DEC plánovač, u kterého jsem využil zobrazení časové osy (timeline). Jednotlivé stavy figurují jako upomínky v kalendáři a ve výsledku jde o zobrazení stavů v jedné dlouhé časové ose. Stavy jsou od sebe barevně odlišeny.
Modul predikce AETRu je nyní ve fázi testování, jelikož jde o rozsáhlou část systému. V blízké době bude nasazen do ostré verze aplikace. Úkol jsem dokončil, avšak budu dále pracovat na jeho rozšíření a optimalizaci. Bylo by možné přidat indikaci, když pojede více než jeden řidič, to by zahrnovalo zcela nové a daleko komplikovanější výpočty dob řidičů. Do budoucna je naplánována implementace rozhraní pro spolupráci s ostatními částmi systému, například při plánování optimální trasy lze snadno zjistit, kam by byl vybraný řidič schopný dojet za daný čas nebo jak dlouho by mohla cesta trvat.
20
4 Získané znalosti
Během svého působení ve firmě jsem nabyl mnoho vědomostí v oblasti programování. Ze školy jsem využil znalostí, avšak většina z nich byla pouze základní a bylo nutné je rozšířit pro potřeby firmy. Nastupoval jsem se znalostí některých .NET technologií, tedy objektově orientovaný jazyk C#, dotazovací jazyk LINQ a framework pro tvorbu webových aplikací ASP.NET, tyto informace jsou k nalezení citované knize [7]. Mimo technologie .NET jsem zahajoval praxi se znalostí dotazovacího jazyku SQL (postgreSQL) pro práci s databází a také jazyků pro tvorbu WWW stránek jako je HTML, tedy základní jazyk pro tvorbu webu, dále JS a pro návrh vzhledu stránek byly užitečné kaskádové styly CSS. Tyto znalosti byly dostačující pro nástup do firmy.
Za dobu ve firmě jsem své vědomosti zdokonalil. Jelikož aplikace pracuje na frameworku ASP.NET MVC, bylo nutné si nastudovat rozšíření MVC. K tomuto účelu mi posloužil inter- netový kurz společnosti Microsoft (viz. citace [8]), kde jsem se seznámil se základními principy.
Své znalosti jsem doplňoval v průběhu praxe, povětšinou s pomocí svého konzultanta.
Celé uživatelské rozhraní bylo navrženo s ovládacími prvky firmy DevExpress (DEC). S pomocí dokumentace a ukázek na internetových stránkách této firmy (viz. citace [10]) jsem se naučil využívat jejich knihovnu, která obsahovala vše od tabulek a formulářů až po kalendáře a tiskové sestavy.
Dále jsem se seznámil s metodou testování zvanou unit testing (viz. citace [9]). Jde o velice efektivní způsob ověřování funkčnosti částí (třídy, metody) programu. Proces spouštění aplikace byl poměrně zdlouhavý a testování jednotlivých metod by tak zabralo mnoho času nebo by mohlo dojít k pádu systému či dokonce k poškození dat. Touto metodou se spouští pouze vybraná metoda a testování se značně urychlí.
Mezi neocenitelné zkušenosti bych zařadil práci v týmu, pro kterou ve škole není mnoho prostoru. S tím souvisí používání verzovacího systému SVN, který byl při práci nenahraditelný nástroj. Sdílení kódu je pro práci ve firmě zcela zásadní i z hlediska zálohování systému a možnosti vrátit se do určitého stavu aplikace, když je potřeba.
5 Závěr
Mezi největší přínosy své praxe počítám zdokonalení v .NET technologiích, tedy hlubší porozu- mění jazyka C#, nabytí znalostí o frameworku ASP.NET MVC a v neposlední řadě komplexní využití jazyka JS. Neocenitelná zkušenost byla práce v týmu a zapojení se do vývojového pro- cesu, kde velkou roli hrají zkušení odborníci v dané problematice, od kterých jsem dostal mnoho užitečných rad.
Podílel jsem se na vývoji webové aplikace GX-GO, kde jsem pracoval na mnoha zajímavých úkolech při jejím rozšiřování. Všechny úkoly jsem úspěšně dokončil, stejně tak i můj hlavní úkol, modul pro predikci AETRu, při kterém jsem mimo programování, také nastudoval legislativu řidičů v dopravě. Modul by bylo možné rozšířit o možnosti nastavení řízení více než jednoho řidiče, což by vyžadovalo zahrnout zcela nová pravidla výpočtů a také úpravu view. Pro větší využití modulu z hlediska celé aplikace by bylo možné implementovat rozhraní, které by využí- valy ostatní části systému. Například u výpočtu optimální trasy řidiče nebo pro hodnocení řidiče z hlediska využití pracovní doby. Modul je nyní ve fázi testování, ale do ostré verze aplikace bude již brzo nasazen.
Ve firmě bych rád i nadále pokračoval a rozvíjel své znalosti. Dle mého názoru je praxe velmi dobrá příprava na přechod ze školy do zaměstnání a absolventi mají větší přehled, co mohou očekávat.
22
Literatura
[1] Informace o firmě GX Solutions Bohemia s.r.o. [online]. Dostupné z: http://www.
gxsolutions.cz
[2] Aplikace GX-GOGX Solutions Bohemia s.r.o. [online]. Dostupné z:https://gx-go.com/
[3] Téma praxe NETFEI [online]. Dostupné z: https://katis.vsb.cz/netfei/tema.php?
rok=2015
[4] Vyhláška č. 561/2006 ze dne 15. března 2006 Ministerstvo dopravy [online]. Dostupné z: http://www.mdcr.cz/NR/rdonlyres/8861CCFB-1749-49EC-B007-D215B0AFEFD8/0/
5612006.pdf
[5] Evropská dohoda o práci osádek vozidel v mezinárodní silniční dopravě AETR Ministerstvo dopravy [online]. Dostupné z: http://www.mdcr.cz/NR/rdonlyres/
23DAC24A-F96E-4744-8488-83BAF71C96F0/0/AETR622010Sbms.pdf
[6] Evropská dohoda o práci osádek vozidel v mezinárodní silniční dopravě AETR (do- datek) Ministerstvo dopravy [online]. Dostupné z: http://www.mdcr.cz/NR/rdonlyres/
B06289E9-E5D1-4529-8152-B9B4C70395E0/0/821010SbmsAETR.pdf
[7] PROSISE, Jeff.Programování v Microsoft .NET: webové aplikace v .Net Framework, C# a ASP.NET. Vyd. 1. Brno: Computer Press, 2003. ISBN 80-7226-879-1.
[8] Kurz ASP.NET MVC Microsoft [online]. Dostupné z: http://www.asp.net/mvc
[9] Testování částí kódu Microsoft [online]. Dostupné z: https://msdn.microsoft.com/
cs-cz/library/dd264975.aspx
[10] Stránky firmyDevExpress [online]. Dostupné z: https://www.devexpress.com/
[11] Pracovní doba řidiče Tachospeed [online]. Dostupné z: http://tachospeed.cz/
pracovni-doba-ridice/
A Příloha
Obrázek 4: Diagram aktivit pro zpracování záznamů AETRu
24
Obrázek6:UkázkapredikceAETRuonline
26
Obrázek7:UkázkapredikceAETRuhistorie
