UNIVERZITA PARDUBICE FAKULTA EKONOMICKO-SPRÁVNÍ
Tvorba aplikace pro logistickou firmu Miroslav Pásler
Bakalářská práce 2011
Prohlašuji: Tuto práci jsem vypracoval samostatně. Veškeré literární prameny a informace, které jsem v práci vyuţil, jsou uvedeny v seznamu pouţité literatury. Byl jsem seznámen s tím, ţe se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorský zákon, zejména se skutečností, ţe Univerzita Pardubice má právo na uzavření licenční smlouvy o uţití této práce jako školního díla podle § 60 odst. 1 autorského zákona, a s tím, ţe pokud dojde k uţití této práce mnou nebo bude poskytnuta licence o uţití jinému subjektu, je Univerzita Pardubice oprávněna ode mne poţadovat přiměřený příspěvek na úhradu nákladů, které na vytvoření díla vynaloţila, a to podle okolností aţ do jejich skutečné výše. Souhlasím s prezenčním zpřístupněním své práce v Univerzitní knihovně. V Pardubicích dne 24. dubna 2011
Miroslav Pásler
Poděkování Velmi rád bych poděkoval Ing. Milanu Tomešovi za čas, který mi při tvorbě práce věnoval a za připomínky a rady, kterými přispěl k vypracování této bakalářské práce. Dále bych rád poděkoval pracovníkům firmy ROZLÍVKA TRANSPORT s.r.o. za jejich spolupráci při získávání informací a podkladů k této práci.
Anotace Práce se zabývá návrhem a následnou implementací informačního systému pro konkrétní firmu podnikající v oboru logistiky. Systém má být navrţen tak, aby usnadnil práci zaměstnancům firmy a podpořil základní práci managementu firmy.
Klíčová slova aplikace, informační systém, programování, Java, PHP MyAdmin, databáze, logistika, ţivotní cyklus, SQL
Title Creating of aplication for logistic company
Annotation The work deals with the design and subsequent implementation of an information system for a particular company engaged in the field of logistics. The system should be designed to facilitate the work of employees of the company and support the essential work of management.
Keywords information system, programming, Java, PHP MyAdmin, database, logistics, life cycle, SQL
Obsah Úvod..............................................................................................................................................9 1.
Teorie vývoje informačního systému .................................................................................... 10 1.1.
Systém.......................................................................................................................... 10
1.2.
Informační systém ........................................................................................................ 10
1.3.
Ţivotní cyklus vývoje IS ............................................................................................... 11
1.3.1.
Specifikace cílů a specifikace poţadavků .............................................................. 12
1.3.2.
Návrh systému ...................................................................................................... 13
1.3.3.
Implementace systému .......................................................................................... 13
1.3.4.
Testování .............................................................................................................. 13
1.3.5.
Zavádění do provozu ............................................................................................. 13
1.3.6.
Provoz a údrţba systému ....................................................................................... 15
1.4. 2.
Poţadavky na IS ........................................................................................................... 15
Vybrané pojmy z logistiky.................................................................................................... 17 2.1.
Logistika ...................................................................................................................... 17
2.2.
Informační systémy a informační technologie v logistice .............................................. 18
2.2.1. 3.
4.
Vymezení problému a stanovení poţadavků na IS ................................................................ 19 3.1.
Vymezení problému...................................................................................................... 19
3.2.
Informace o firmě ......................................................................................................... 19
3.3.
Průzkum prostředí ........................................................................................................ 20
3.4.
Cíle IS .......................................................................................................................... 22
3.5.
Poţadavky na IS ........................................................................................................... 22
3.5.1.
Poţadavky na funkce IS ........................................................................................ 22
3.5.2.
Nefunkční poţadavky na IS................................................................................... 24
Návrh aplikace ..................................................................................................................... 25 4.1.
Návrh aplikace a procesu vypisování objednávky .......................................................... 25
4.2.
Návrh databáze ............................................................................................................. 27
4.2.1.
Konceptuální úroveň ............................................................................................. 28
4.2.2.
Logická úroveň ..................................................................................................... 29
4.2.3.
Normalizace.......................................................................................................... 29
4.3. 5.
Spediční databanka RaalTrans ............................................................................... 18
Implementace databáze ................................................................................................. 30
Implementace aplikace ......................................................................................................... 34 5.1.
Vybrané vlastnosti jazyka Java ..................................................................................... 34
5.1.1.
Objektová orientovanost ....................................................................................... 34
5.1.2.
Základní datové typy ............................................................................................. 34
5.1.3.
Řídící struktury ..................................................................................................... 35
5.1.4.
Grafické uţivatelské rozhraní ................................................................................ 36
5.1.5.
Další klíčové vlastnosti jazyka Java....................................................................... 36
5.2.
5.2.1.
Spojení s databází ................................................................................................. 36
5.2.2.
Architektura klient/server ...................................................................................... 40
5.2.3.
Hlavní okno .......................................................................................................... 40
5.2.4.
Zadávací formulář pro výpis objednávek ............................................................... 41
5.2.5.
Okno správy databáze ........................................................................................... 46
5.2.6.
Okno správy finančních výstupů ........................................................................... 46
5.2.7.
Řešení tiskových výstupů ...................................................................................... 47
5.2.8.
Integritní omezení a ošetření výjimečných událostí ................................................ 49
5.3. 6.
Vybrané problémy řešené při tvorbě apliakce ................................................................ 36
Moţnosti dalšího rozšíření ............................................................................................ 50
Zavedení aplikace v prostředí firmy...................................................................................... 51
Závěr ........................................................................................................................................... 52 Pouţitá literatura .......................................................................................................................... 53 Seznam zkratek ............................................................................................................................ 55
Seznam obrázků Obrázek 1 - Vodopádový model ŢC IS. Zdroj [5] ......................................................................... 12 Obrázek 2 - Souběţný systém zavádění IS. Zdroj [4] .................................................................... 14 Obrázek 3 – Pilotní systém zavádění IS. Zdroj [4] ........................................................................ 14 Obrázek 4 – Postupný systém zavádění IS. Zdroj [4] .................................................................... 15 Obrázek 5 – Nárazový systém zavádění IS. Zdroj [4] ................................................................... 15 Obrázek 6 – Use case diagram – funkce a vyuţití aplikace. Zdroj vlastní ...................................... 23 Obrázek 7 – Základní struktura aplikace. Zdroj vlastní ................................................................. 25 Obrázek 8 - Schéma architektury přístupu uţivatelů do databáze. Zdroj vlastní............................. 27 Obrázek 9 - ERD návrhu databáze. Zdroj vlastní .......................................................................... 28 Obrázek 10 - RMD databáze. Zdroj vlastní ................................................................................... 30 Obrázek 11 - Prostředí nástroje PHP MyAdmin. Zdroj vlastní ...................................................... 32 Obrázek 12 - Ilustrace zdrojového kódu pro připojení k databázi MySQL. Zdroj vlastní ............... 37 Obrázek 13 - Demonstrace zápisu do databáze. Zdroj vlastní ........................................................ 39 Obrázek 14 - Výsledná podoba metody GetConnection(). Zdroj vlastní ........................................ 40 Obrázek 15 - Otevírání panelů zadávacího formuláře. Zdroj vlastní .............................................. 41 Obrázek 16 - Výsledná podoba zadávacího formuláře. Zdroj vlastní ............................................. 45 Obrázek 17 - Přidání dalšího místa nakládky a vykládky do formuláře. Zdroj vlastní .................... 46 Obrázek 18 - Výpis objednávek z databáze. Zdroj vlastní ............................................................. 46 Obrázek 19 – Okno správy finančních výstupů. Zdroj vlastní ....................................................... 47 Obrázek 20 - Postup vytvoření tiskové sestavy pomocí JasperReports. Zdroj [19] ........................ 48 Obrázek 21 - Tvorba výstupu do PDF. Zdroj vlastní ..................................................................... 48
Seznam tabulek Tabulka 1 - Informace o firemních počítačích. Zdroj Vlastní ........................................................ 22 Tabulka 2 - Seznam entit. Zdroj vlastní ........................................................................................ 28 Tabulka 3 - Seznam relací. Zdroj vlastní. ..................................................................................... 29 Tabulka 4 - Struktura databáze na úrovni implementace. Zdroj vlastní.......................................... 31 Tabulka 5 - Základní datové typy jazyka Java. Zdroj vlastní upraveno na základě [13] ................. 35 Tabulka 6 - Komponenty zadávacího formuláře. Zdroj vlastní ...................................................... 43
Seznam příloh Příloha 1 – Původní podoba objednávky. Příloha 2 – Tabulka původního způsobu sepisování informací o objednávkách. Příloha 3 – EPC diagram práce s aplikací. Příloha 4 – Nynější podoba objednávky.
Úvod V dnešní době, kdy informatika a informační a komunikační systémy prostupují veškerou
činností
člověka
a
pro
většinu
konkurenceschopných
firem
jsou
nepostradatelným nástrojem, stále existují firmy, které ICT vyuţívají nedostatečně nebo dokonce vůbec. S rozvojem internetu vzrostly i poţadavky na alternativní způsoby prezentace firem při zachování konkurenceschopnosti na daném trhu. Neexistuje dnes prakticky firma, která by se nějakým způsobem neprezentovala na internetu. Vyhledatelnost a viditelnost v prostředí internetu se pro některé firmy stává existenční nutností. Stejně tak i vyuţívání speciálních prostředků z oblasti informačních technologií, různého programového vybavení a komunikačních technologií se postupem času stává nezbytnou součástí kvalitního chodu firem na všech úrovních velikosti i specializace. S ohledem na to, vyuţití prostředků ICT můţe být rozhodujícím faktorem pro dynamiku práce firmy, usnadnění rozhodovacích procesů a její vnější prezentaci ve výsledku vedoucí k dlouhodobě udrţitelné konkurenceschopnosti firmy. Úkolem této práce je poskytnout podklad pro řešení problému nedostatečného vyuţití moţností pouţití ICT v konkrétní firmě zabývající se spedicí a logistikou, navrhnout počítačovou aplikaci jako součást IS, která by usnadnila spedičním pracovníkům firmy sepisování objednávek a evidenci a management firmy podpořila v jeho rozhodovacích procesech poskytnutím automatických součtů některých finančních ukazatelů. Na základě návrhu pak zvolit vhodný implementační nástroj a tuto aplikaci vytvořit. Návrh informačního systému je sloţitý teoretický proces vyţadující jistou míru specializace, proto je této problematice věnována první část této práce. Na základě těchto teoretických faktů je poté uskutečněna samotná realizace návrhu včetně stanovení poţadavků a systémového vymezení problému. Dále jsou v práci popsány významné problémy související s implementací na základě zvoleného nástroje.
9
1. Teorie vývoje informačního systému V této kapitole bude obecně pojednáno o vývoji IS, tedy o aspektech, postupech a dalších sounáleţitostech souvisejících s tvorbou IS. Budou zde vysvětleny vybrané pojmy týkající se teorie informačních a komunikačních systémů.
1.1.
Systém
Dříve neţ budou blíţe vysvětleny vybrané pojmy z teorie informačních systémů, je třeba obecně definovat pojem systém. Pro pojem systém existuje velké mnoţství definic. Pro účely této práce se jeví jako vhodná tato definice: „Systémem rozumíme obecně soubor prvků, mezi nimiž existují vzájemné vztahy a jako celek má určité vztahy ke svému okolí.“ [1] Systém odděluje od jeho okolí hranice systému. Pomocí hranice systému je systém
jasně prostorově vymezen.
1.2.
Informační systém
Pojem informační systém můţeme chápat jako konkretizaci pojmu systém, jeţ byl definován. Pro pojem informační systém zná vymezení i naše legislativa. „Informačním systémem se rozumí funkční celek zabezpečující cílevědomé a systematické shromažďování, zpracovávání, uchovávání a zpřístupňování informací. Každý informační systém zahrnuje informační základnu, technické a programové prostředky, technologie a procedury a pracovníky.“ [2]
„Pro účely tohoto zákona se rozumí informačním systémem funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost. Každý informační systém zahrnuje data, která jsou uspořádána tak, aby bylo možné jejich zpracování a zpřístupnění, a dále nástroje umožňující výkon informačních činností.“ [3] Informačním systémem můţeme rozumět funkční propojení lidí, dat, procesů (softwaru) a technologií (hardwaru) navzájem spolupracujících tak, aby usnadňovali a podporovali kaţdodenní operace a podporovali řešení problémů a rozhodovací procesy. [4]
10
1.3.
Ţivotní cyklus vývoje IS
Jedná se o posloupnost po sobě následujících fází - etap. Ţivotní cyklus vývoje IS jednoznačně definuje všechny jednotlivé etapy vývoje od plánování aţ po ukončení provozu IS. „Informační systém je produkt jako kterýkoliv jiný, má proto také svůj životní cyklus podchycující celý jeho „život“ od počátku až do konce.“ [4] Existuje mnoho různých způsobů vymezení fází ţivotního cyklu IS. Stejně tak existuje několik modelů ţivotního cyklu IS, které popisují jednotlivé etapy a jejich náplň. Nejstručněji lze jednotlivé fáze definovat následujícím výčtem:
plánování
analýza a design
zavádění do provozu (implementace)
provoz a údrţba
Vymezení ŢC IS v předchozích čtyřech bodech nám nenabízí veškeré etapy, které lze do vývoje IS zařadit. Jako samostatnou fázi lze jistě vymezit fázi vyřazení IS z provozu. [4] Ţivotní cyklus vývoje IS lze znázornit pomocí několika modelů, kaţdý s těchto modelů přistupuje k popisu etap, k jejich náplni a především k jejich návaznosti odlišným způsobem. Mezi nejběţnější modely ŢC IS patří vodopádový model (Obrázek 1), Vmodel, spirálový model, objektově-orientovaný model a další. V rámci rozsahu této práce se jeví jako nejvhodnější uvést a podrobněji rozebrat vodopádový model, který je také někdy nazýván jako tradiční nebo kaskádový model. „Základní charakteristikou modelu vodopád je, že při návrhu IS se provádí postupně jednotlivé etapy životního cyklu, které na sebe navazují a vzájemně se neprotínají. Etapy se provádí podle přesného plánu realizace a zpětně se k nim nevrací, dokončená etapa je vstupem etapy následující.“ [5] Tento model je typický tím, ţe se testuje správnost jednotlivých fází a v případě zjištění chyb, se lze vrátit do fáze předchozí a chyby napravit. Tento systém zajišťuje vyšší kvalitu a menší pravděpodobnost přehlédnutí důleţitých záleţitostí. Na druhou stranu při pouţití tohoto modelu je konečný výsledek znám aţ po poslední fázi. 11
Obrázek 1 - Vodopádový model ŢC IS. Zdroj [5]
1.3.1. Specifikace cílů a specifikace poţadavků „Základem celkového návrhu, vývoje i jakékoli úpravy stávajícího systému jsou požadavky uživatelů a cíle organizace. V této části se musí dané požadavky shromáždit, v hrubých rysech rozebrat a odhadnout dobu realizace a náklady.“ [5] Cílem této fáze je tedy sestavit základní rámec poţadavků a vytyčit základní cíle. Specifikace cílů a poţadavků na IS se dá souhrnně nazvat jako analýza systému. Rozdílem mezi specifikací cílů a specifikací poţadavků je v tom, ţe specifikace cílů předchází v rámci vodopádového modelu specifikaci poţadavků. Specifikace cílů je tedy jakási předběţná analýza systému. Samotná fáze analýzy je pro vývoj IS v rámci vodopádového modelu ŢC jedna z klíčových, protoţe chyby, kterých se dopustíme v této fázi, a neodhalíme je, se později velice těţko napravují a jejich odstranění bývá velice časově náročné a v neposlední řadě i velice nákladné. [5] Součástí projektu specifikace cílů tedy dle [5] jsou:
Časový plán projektu.
Zdroje nutné k řešení (HW, SW, lidé, finanční prostředky).
Odhad funkčnosti, rozsahu systému, ekonomické efektivnosti a návratnosti investice.
12
Pro specifikování daných cílů se pouţijí nástroje:
Analýza současného stavu
Získání poţadavků uţivatelů a zjištění poţadovaných vstupních a výstupních informací.
Seznam problémů, které jsou známy.
Specifikace poţadavků:
Formální specifikace
Neformální specifikace
1.3.2. Návrh systému Návrh systému představuje popis způsobu realizace systému. Podkladem pro návrh IS jsou výsledky z předcházející fáze ŢC tedy z analýzy. S návrhem systému velice úzce souvisí pojem procesní modelování. Modely vzniklé při procesním modelování můţeme rozdělit na formální (přirozený jazyk) a neformální (pomocí dané syntaxe). Pro účely procesního modelování nám slouţí nástroje jako je UML diagram, Use-case diagram, vývojový diagram, EPC diagram a další.
1.3.3. Implementace systému Implementace představuje převedení návrhu IS do podoby reálného výrobku pomocí nějakého programovacího jazyka nebo nástroje. Někdy bývá jako implementace označována ta etapa ŢC, kdy je jiţ hotový IS zaváděn do provozu.
1.3.4. Testování V této etapě se provádí připravené testy na hotovém IS. Je nutné vyzkoušet veškeré moţné reakce systému na zadávaná data a zjištěné nedostatky opravit. Testování se často provádí na systému, který ještě není v reálném prostředí, neboť případné selhání by mohlo mít rozsáhlé následky. [5]
1.3.5. Zavádění do provozu Tato etapa představuje uvedení nového IS do provozu. Při zavádění nového systému do provozu lze dle [4] a dle [5] pouţít jednu z uvedených strategií:
13
Souběžné zavádění – po jistou dobu pokračuje provoz starého IS za současného provozu systému nového. Tato metoda je bezpečná a spolehlivá, ale náročná pro zaměstnance (Obrázek 2).
Obrázek 2 - Souběţný systém zavádění IS. Zdroj [4]
Pilotní zavádění – nový systém je zaveden jen na některých pracovištích podniku a teprve po jeho odzkoušení je zaveden i ve zbytku podniku. U této strategie mohou nastat problémy v souvislosti s komunikací mezi pracovišti, kdy jedna část podniku pracuje jiţ s novým IS a zbylá se starým. Jinak je tato forma zavádění bezpečná (Obrázek 3).
Obrázek 3 – Pilotní systém zavádění IS. Zdroj [4]
Postupné zavádění – pouţívá se u sloţitých systémů. Postup zavádění je od částí systému, na kterých zbylé části závisí na klíčová pracoviště k systémům závislým na sekundární pracoviště (Obrázek 4).
14
Obrázek 4 – Postupný systém zavádění IS. Zdroj [4]
Nárazové zavádění – jedná se o úplné nahrazení starého systému systémem novým v jednom okamţiku. Tento postup je velice riskantní, ale přináší významnou úsporu času (Obrázek 5).
Obrázek 5 – Nárazový systém zavádění IS. Zdroj [4]
1.3.6. Provoz a údrţba systému Tato etapa představuje zajištění správného provozu systému. Spadá sem zabezpečení systému a ochrana dat před neoprávněným přístupem, chránění dat před ztrátou pomocí archivace apod. Chyby, které nastaly v předešlých fázích a jsou odhaleny aţ ve fázi provozu, se jen velmi těţko napravují a tato náprava bývá velice nákladná.
1.4.
Poţadavky na IS
Na informační systémy jsou dle [4] kladeny různé poţadavky. IS by měl být:
otevřený - v závislosti na vnějším prostředí. Pokud se systém nazývá otevřeným, musí existovat moţnost doplňování všech komponent systému od různých dodavatelů, kteří potom mají moţnost systém upravovat (i programově), v reakci na příslušné změny v místě. 15
dynamický – systém tzv. „půjde s dobou“. Obvykle se problém řeší formou garance vývoje na několik let.
podporovaný -
podpora českého prostředí (komunikuje s uţivatelem
v češtině).
komplexní - tj. systémy, které systematicky zabezpečují informacemi veškeré sloţky řízení a organizace.
kompaktní - neboli vnitřně propojené. Takovýto systém má všechny poţadované (odůvodněné) vnitřní vazby mezi jednotlivými subsystémy i jednotlivými daty. Má vytvořené jak vazby horizontální (na stejné rozlišovací úrovni), tak vazby vertikální (na hierarchicky odlišných rozlišovacích úrovních).
standardizovaný - respektující všeobecně platné technické i datové předpisy, české obzvláště. Tato vlastnost umoţňuje realizovat vazby na vnější okolí, zajišťuje, aby byl systém kompatibilní s dalšími systémy.
stavebnicový - kdy jednotlivé softwarové komponenty lze vyměňovat po blocích.
chráněný - jak před zneuţitím tak před úmyslným i neúmyslným poškozením techniky, dat, a softwarové části. Zajištění bezpečnosti dnes patří mezi významné poţadavky na IS. Jde přitom o komplexní a nikdy nekončící proces, který vyţaduje systematický přístup začínající definováním strategie informační bezpečnosti a analýzou rizik, pokračující definováním bezpečnostní politiky organizace a bezpečnostními směrnicemi a standardy, po nichţ následuje jejich zavedení do praxe včetně školení pracovníků a následuje neustálá kontrola a monitorování, která zajišťuje zpětnou vazbu.
kompatibilní - neboli slučitelný. Jde o to, aby jednotlivé systémy bylo moţno vzájemně propojovat – interoperabilita systémů (schopnost spolupráce bez ohledu na platformu jednotlivých systémů) patří dnes ve veřejné správě (a nejen v ní) k významným poţadavkům při tvorbě nových systémů
minimalizovat datové redundance – data, která se vyskytují na jednom místě, by se neměla vyskytovat nezávisle i na jiných místech, ale pouze ve formě propojení.
16
2. Vybrané pojmy z logistiky Informační systém vytvořený v rámci praktické části této práce je zaměřený pro potřeby logistické firmy. Z tohoto důvodu v této kapitole budou popsány vybrané pojmy z logistiky a oborů s ní úzce souvisejících. Protoţe daná logistická firma se zaměřuje především na automobilovou dopravu a spedici, budou v této kapitole popsány především pojmy související s touto problematikou.
2.1.
Logistika
Pro pojem logistika existuje několik moţných definic. Jedna z nich zní: „Logistika je disciplína, která se zabývá pohybem zboží a materiálu z místa vzniku do místa spotřeby.“ [6] Pojem logistika dále souvisí s mnoha dalšími pojmy, pro účely této práce byly k podrobnějšímu popisu vybrány následující a popsány dle [7] a [8]:
Spedice – dle [7] je spedice zajištění přepravy. V praxi tento pojem znamená poskytnutí sluţby distribuce nebo zajištění přepravy zboţí z jednoho místa na místo jiné a velice úzce souvisí s pojmem logistika, protoţe na ni navazuje i vykládka, nakládka a skladování zboţí, které uţ do samotné spedice nepatří, ale firmy, které se spedicí zabývají, často poskytují i tyto sluţby a hranice mezi spedicí a logistikou (jako širší nabídkou sluţeb neţ je pouze spedice) se smazává.
Dopravce – poskytovatel přepravních sluţeb.
Vozidlový park – soubor dopravních prostředků trvale patřící do systému silniční nebo ţelezniční dopravy.
Skladování – je část logistického systému, která zabezpečuje uskladnění produktů a informace o stavu, podmínkách a rozmístění skladovaných produktů.
Zásobování – jedná se o uţší pojem neţli logistika. Jedná se o zajišťování hmotných statků a sluţeb.
17
2.2.
Informační systémy a informační technologie v logistice
2.2.1. Spediční databanka RaalTrans Databanka RAALTRANS slouţí pro zadávání, vyhledávání a třídění nabídek přeprav a volných vozů. Jedná se o centrální databázi vytíţení vozidel. V praxi to znamená, ţe uţivatelé této databanky skrze programové rozhraní RAALTRANS Editor zveřejňují, kde se nacházejí jejich volné vozy popřípadě zboţí, které chtějí přepravovat a naopak v databázi hledají volné vozy, jeţ by mohly uskutečnit poţadovanou přepravu. Databanka RAALTRANS je tedy v podstatě virtuální trh, kde se setkává nabídka a poptávka po volných vozech a zboţí, jeţ je třeba přepravit za účelem maximálního vytíţení vozů a maximálního urychlení a usnadnění přepravy. [9] V rámci databanky RAALTRANS se jednotliví dopravci rozlišují pomocí kódu RAAL.
18
3. Vymezení problému a stanovení poţadavků na IS V této kapitole je vymezen problém řešený v této práci. Dále popsány vybrané informace o firmě ROZLÍVKA TRANSPORT s.r.o., průzkum tamního prostředí a na jejím základě stanoveny poţadavky na IS a aplikaci.
3.1.
Vymezení problému
Byl stanoven poţadavek, na vytvoření počítačové aplikace jako součásti IS pro potřeby konkrétní logistické firmy ROZLÍVKA TRANSPORT s.r.o., konkrétně pro usnadnění práce spedičního oddělení. Tato firma se zabývá automobilovou nákladní dopravou vnitrostátní i mezinárodní a dalšími logistickými sluţbami.
3.2.
Informace o firmě
Informace o firmě ROZLÍVKA TRANSPORT s.r.o. byly čerpány jednak přímo na místě od pracovníků firmy a jednak z webových stránek firmy [10]. Firma
ROZLÍVKA
TRANSPORT
s.r.o.
vznikla
v roce
2004
převedením
z firmy AUTODOPRAVA Jiří Rozlívka, která byla zaloţena v roce 1991. Stěţejní činností firmy je vnitrostátní a mezinárodní nákladní doprava. Firma nabízí spektrum logistických sluţeb, mezi které patří zajištění přepravy nákladů v rozmezí 1kg aţ 24t formou expresních zásilek, sběrných sluţeb či celovozovou dopravu, skladování a vykládka a nakládka. Zásilky firma dopravuje po celém světě zejména pak po tuzemsku, do Německa, Polska, Maďarska a na Slovensko. Firma sídlí na adrese Semanínská 2094 Česká Třebová. Areál firmy se nachází v bezprostřední blízkosti hlavního vlakového nádraţí města Česká Třebová a rozkládá se na rozloze 11600 m2, na tomto prostoru se nachází 1500m2 skladových prostor a zařízení uzpůsobená k nakládkám a vykládkám nákladních aut i ţelezničních vagonů. Firma zaměstnává celkem 12 zaměstnanců, které pod sebou zaměstnávají dva ředitelé, tedy jednatelé firmy p. Rozlívka a jeho otec. Mezi tyto zaměstnance patří dva spediční pracovníci, jedna účetní a devět řidičů. Firma má základní kapitál 200 000 Kč a přibliţný roční obrat 20 – 25 mil. Kč.
19
Spediční pracovníci firmy zajišťují zprostředkování přepravy zásilek vnitrostátních i mezinárodních především automobilovou dopravou, ale i ţelezniční námořní a leteckou. K těmto účelům firma vyuţívá buď vlastních vozidel, nebo pronájem vozidel jiných firem na základě spolupráce skrze spediční databanku RAALTRANS. Firma má k dispozici 8 vlastních vozů a vyuţívá sluţeb přibliţně stovky dalších dopravců. O spediční sluţby firmy se starají dva spediční pracovnicí. Pokud k přepravě zboţí není vyuţito vlastních vozidel, zpravidla spediční pracovníci k přepravě pronajímají sluţby jiného dopravce, přičemţ cena této sluţby je obvykle niţší neţ suma, kterou firmě platí za sluţbu zákazník, rozdíl těchto cen pak představuje marţi. Spediční pracovníci na základě údajů o přepravě vypisují objednávky (smlouvy o přepravě zboţí), které elektronicky nebo faxem zasílají danému dopravci. K tomuto úkolu vyuţívají pouze omezené programové vybavení, jak je popsáno v následující kapitole.
3.3.
Průzkum prostředí
Přes svou velikost (viz předchozí kapitola) firma ROZLÍVKA TRANSPORT s.r.o. nevlastní ţádný sofistikovaný software, který by usnadňoval proces vypisování objednávek a poskytoval rychlou zpětnou vazbu o stavu práce spedičního oddělení z finančního hlediska. Pro vypisování spedičních zakázek vyuţívají pracovníci firmy nástrojů, které jim nabízí balík MS Office, zejména pak aplikace MS Word. Dále vyuţívají sluţeb aplikace pro přístup do databáze RAALTRANS a aplikace Route66 pro vyhledávání tras, tyto však nijak neusnadňují proces vypisování objednávek. V dokumentu MS Word mají spediční pracovníci firmy před-vytvořenu tabulku, do které vyplňují patřičné údaje o objednávce. Těmito údaji jsou:
informace o dopravci – název dopravce (tím je myšlen dopravce, u kterého spediční pracovníci firmy objednají danou přepravní zakázku), kontaktní telefon dopravce, fax dopravce, a RAAL kód dopravce.
číslo objednávky (smlouvy) – představuje pořadové číslo objednávky za daný rok. Kaţdý nový rok se objednávky číslují znovu od jedné.
údaje o nakládce – místo nakládky (tj. adresa, kde je zboţí naloţeno), náklad (tj. informace o druhu zboţí, váze, počtu atp.), datum a čas nakládky. Na jedné smlouvě mohou být aţ 3 místa nakládky a další informace na ně navázané.
20
údaje o vykládce – místo vykládky (ekvivalentně k místu nakládky), datum a čas vykládky. Na jedné smlouvě mohou být aţ 3 místa nakládky a další informace na ně navázané.
poznámka – v poznámce bývá zpravidla uvedeno kupříkladu, jak se má naloţit s paletami po sloţení zboţí atp.
cena – představuje cenu, za kterou poskytne daný dopravce svoje přepravní sluţby.
spz – představuje státní poznávací značku vozidla, jímţ bude přeprava uskutečněna.
další položky – objednávka obsahuje další prvky, mezi které patří kontaktní údaje na firmu ROZLÍVKA TRANSPORT s.r.o., její RAAL kód a údaje o podmínkách smlouvy.
Podoba objednávky vyplněné pomocí MS Word je uvedena v příloze. Tento způsoby vypisování objednávek neumoţňuje prakticky ţádnou moţnost automatizace, přestoţe z povahy procesu vypisování objednávek existuje vysoký potenciál pro usnadnění a zautomatizování některých prvků této práce při faktu, ţe v průměru spediční pracovníci za jeden den vypíší mezi 2 a 10 objednávkami. Dále díky tomuto způsobu vypisování objednávek jsou hodnoty ceny a marţe zaznamenávány pouze ručně na papír se všemi nevýhodami, které z toho plynou. Především tento způsob neumoţňuje rychlý přehled souhrnných částek s ohledem na období nebo dopravce a veškeré případné ţádané informace jsou zdlouhavě získávány pomocí sčítání na kalkulačce. Podoba způsobu vypisování informací o objednávce je uvedena v příloze. Ve firmě jsou umístěny 3 pevné počítače. Tyto počítače jsou propojeny pomocí místní sítě LAN tak, ţe kaţdý z nich má v rámci vnitřní sítě nastavenou pevnou IP adresu. Počítače v rámci firmy byly označeny jako PC 1, PC 2 a PC X. PC X představuje abstraktní počítač, tj. jakýkoli další PC připojený do sítě popřípadě třetí počítač instalovaný ve firmě, který převáţně vyuţívá účetní firmy, popřípadě ke kontrole stavu i ředitel firmy. Informace o počítačích zobrazuje tabulka ( Tabulka 1).
21
Tabulka 1 - Informace o firemních počítačích. Zdroj Vlastní Počítač
Uživatel
OS
Rozlišení monitoru
HW parametry Procesor: AMD 7750 DUAL-CORE 2,7 GHz Paměť: 2 GB RAM
PC 1
Spediční prac. 1 Windows XP 1024x768 px
PC 2
Spediční prac. 2 Windows XP 1680x1050 px Procesor: AMD SEMPRON 2200+ 1,5 GHz Paměť: 256 MB RAM
3.4.
Cíle IS
Společně s pracovníky logistické firmy a na základě předběţného průzkumu prostředí logistické firmy byly stanoveny základní cíle, které má aplikace v rámci IS splnit.
usnadnění vypisování objednávek přepravy zboţí
usnadnění získávání informací pro podporu manaţerského rozhodování pomocí poskytnutí souhrnných i dílčích součtů ceny a marţe přepravy zboţí za jednotlivé roky, měsíce a dopravce.
3.5.
Poţadavky na IS
Společně s pracovníky firmy a zadávajícím práce byly vymezeny základní poţadavky na podobu a především funkce aplikace v rámci IS. Funkce aplikace ilustruje use-case diagram (Obrázek 6). Aktér na obrázku pojmenovaný jako „manaţer“ symbolizuje především vedení firmy, resp. kohokoli, kdo má zájem na tom získávat souhrnné výstupy systému v souladu s druhým cílem IS.
3.5.1. Poţadavky na funkce IS
moţnost částečného automatického vyplnění zadávacího formuláře pro vypisování objednávek přepravy, tj. automatické vyplnění čísla objednávky a údajů o dopravci na základě zvoleného dopravce
schopnost ukládání informací do databáze
moţnost exportovat vyplněný formulář do tisknutelného souboru (PDF)
moţnost prohlíţení údajů uloţených v databázi
schopnost automatického zpracování dat z databáze do souhrnných výstupů a to ve formě číselné i grafické (jedná se o zaznamenanou cenu a marţi)
22
moţnost prohlíţení souhrnných výstupů
schopnost sdílení databáze dvěma paralelně běţícími aplikacemi na dvou PC pomocí síťové komunikace na principu architektury klient/server
Obrázek 6 – Use case diagram – funkce a vyuţití aplikace. Zdroj vlastní
23
3.5.2. Nefunkční poţadavky na IS Na základě funkčních poţadavků na IS a na základě průzkumu prostředí firmy, její personální struktury a technického vybavení byly stanoveny následující nefunkční poţadavky na IS:
síťová architektura klient/server
snadno ovladatelné a přehledné uţivatelské rozhraní designově odpovídající standardním desktopovým aplikacím
výsledná objednávka po exportu nepřesahuje rozsah jedné strany A4
podpora běhu na operačních systémech MS Windows
24
4. Návrh aplikace Tato kapitola se zabývá návrhem aplikace v rámci IS.
4.1.
Návrh aplikace a procesu vypisování objednávky
Na základě stanovených poţadavků byla vytvořena základní struktura aplikace (Obrázek 7).
Obrázek 7 – Základní struktura aplikace. Zdroj vlastní
Jak je znázorněno na obrázku (Obrázek 7) struktura aplikace je navrţena tak, aby uţivatel mohl zvolit, zda chce přistoupit k zadávacímu formuláři nebo k prohlíţení souhrnných výstupů. Zadávací formulář je pak moţno uloţit do databáze nebo vyexportovat do tisknutelného výstupu (PDF). Podoba zadávacího formuláře bude odpovídat poloţkám, které byly v původním stavu vyplňovány do dokumentu MS Word a které, bude obsahovat vyexportovaný dokument objednávky, k tomu je navíc přiřazena poloţka „marţe“, která na tisknutelné podobě objednávky není, ale ukládá se do databáze za účelem tvorby souhrnných výstupů. Mezi výstupy jsou jednak zahrnuty finanční výstupy a jednak zobrazení poloţek z databáze. Detailně je práce s aplikací ve formě reprezentace pomocí procesů znázorněna v EPC diagramu ( Příloha 3). Při zobrazení poloţek z databáze je umoţněno jednotlivé poloţky editovat v zadávacím formuláři a doplňovat nebo opravovat tak informace o objednávce. Část aplikace, která se zabývá poskytováním souhrnných součtů ceny a marţe je uzpůsobena tak, aby umoţnila vybrat, jaký z těchto dvou ukazatelů má být počítán a dále umoţnila
25
součty a grafické zobrazení vývoje těchto ukazatelů v závislosti na vybraném dopravci (nebo všech dopravcích), měsíci a roce. Jak bylo uvedeno v kapitole 3.5 Poţadavky na IS, aplikace budou paralelně přistupovat ke sdílené databázi. Při tomto pojetí bude jeden z počítačů uchovatelem databáze na svém pevném disku a bude představovat server, ostatní počítače budou na tuto databázi přistupovat po síti jako klient. Do této sítě budou primárně zařazeny PC, na kterých pracují oba spediční pracovníci firmy, popřípadě kdokoli jiný v rámci vnitřní sítě (účetní, vedoucí, atp.), pro přístup k finančním výstupům a dalším funkcionalitám, které bude aplikace poskytovat, tito uţivatelé jsou ve schématu zobrazeni jako „ostatní uţivatelé“. Tuto architekturu zobrazuje schéma (Obrázek 8). Tento obrázek by se dal v podstatě povaţovat i jako základní schéma IS také proto, ţe obsahuje prvky, které patří mezi základní prvky obecného IS, tedy aplikaci (software), uţivatele (lidé), počítače (hardware) a databázi (data). Na základě průzkumu prostředí (kapitola 3.3 Průzkum prostředí) byl jako server zvolen PC spedičního pracovníka p. Vyčítala (v obrázku označen jako „Spediční pracovník 2“) a to především vzhledem k jeho hardwarovému vybavení. Přestoţe provoz serveru a databáze, při předpokládaném rozsahu několika (4-5) tabulek není hardwarově náročnou činností (s ohledem na tamní vybavení), zdá se jako logické pro tyto účely zvolit výkonnější z obou počítačů. Dalším významným faktem, který hovoří pro volbu tohoto počítače, je fakt (ujištění spedičními pracovníky), ţe PC spedičního pracovníka p. Vyčítala běţí prakticky nepřetrţitě celou pracovní dobu a nikdy nenastane situace, kdy by běţel pouze PC jeho kolegyně (v obrázku označena jako „Spediční pracovník 1“), tento fakt prakticky předurčuje pouţití PC p. Vyčítala jako serveru a úloţiště databáze. V neposlední řadě hovoří pro volbu této struktury i fakt, ţe (podle slov spedičních pracovníků) aţ 90% objednávek přepravy je vypisováno právě p. Vyčítalem na jeho PC.
26
Obrázek 8 - Schéma architektury přístupu uţivatelů do databáze. Zdroj vlastní
4.2.
Návrh databáze
Databáze je navrţena tak, aby v sobě uchovávala informace o objednávce přepravy. Jednotlivé tabulky a sloupce tedy odpovídají prvkům zadávacího formuláře, pro který je předobrazem původní dokument MS Word, ve kterém byly objednávky vypisovány. Poloţky této objednávky jsou podrobně popsány v kapitole 3.3 Průzkum prostředí. Oproti poloţkám, které obsahuje objednávka je do databáze přiřazeno několik dalších atributů především pro účely tvorby finančních výstupů. Jsou to atributy:
marže – představuje rozdíl mezi cenou, za kterou je objednána přeprava zákazníkem u ROZLÍVKA TRANSPORT s.r.o. a cenou, za kterou spediční pracovníci objednají přepravní sluţbu u jiného dopravce.
měsíc – objednávky přepravy nejsou vystavovány ke konkrétnímu datu, proto je pro účely tvorby souhrnných výstupů pouţit atribut měsíc, který představuje měsíc, ve kterém byla objednávka vystavena.
cena v Kč – cena, za kterou spediční pracovníci objednávají přepravní sluţby u jiných dopravců je proměnlivá poloţka nejen ve smyslu své hodnoty, ale i ve smyslu souvisejících atributů, cena můţe být vypisována v Eurech nebo v Kč, můţe být vypisována včetně DPH nebo bez DPH atp. Z tohoto důvodu je 27
pro účely tvorby souhrnných výstupů zaveden tento atribut. Představuje poloţku, která byla ručně vypisována na papír (viz kapitola 3.3 Průzkum prostředí).
4.2.1. Konceptuální úroveň Na konceptuální úrovni návrhu databázového modelu byl vytvořen seznam entit. Entita představuje jasně identifikovatelný a odlišitelný objekt reálného světa, který je schopen samostatné existence. [11] Z návrhu vyplynuly čtyři entity (Tabulka 2). Jejich vzájemné vztahy jsou vyjádřeny pomocí ER diagramu (Obrázek 9). Entity představují části dokumentu smlouvy o přepravě a jejich význam je popsán v kapitole 3.3 Průzkum prostředí. Tabulka 2 - Seznam entit. Zdroj vlastní Název Entity
Klíčový atribut
Smlouva o přepravě
Číslo smlouvy, rok
Dopravce
RAAL
Nakládka Vykládka
ID ID
Atributy poznámka, cena, spz, měsíc, marže, cena v Kč název, telefon, fax místo, datum, čas, náklad místo, datum, čas
Obrázek 9 - ERD návrhu databáze. Zdroj vlastní
28
Vztahy mezi entitami, které jsou na obrázku (Obrázek 9) představují:
Zahrnuje – Entita Smlouva zahrnuje Nakládku a Vykládku, Nakládka a Vykládka jsou zahrnuty ve smlouvě, přičemţ Smlouva zahrnuje 1-N nakládek a 1-N vykládek.
Obsahuje – Entita Smlouva obsahuje Dopravce, přičemţ jeden dopravce můţe být obsaţen aţ v N smlouvách.
4.2.2. Logická úroveň Z návrhu vzniklého v konceptuální úrovni pomocí transformačních pravidel transformujeme ERD do relačního modelu databáze (RMD). Počet a struktura vzniklých relací je závislá na vzájemných vztazích entit, jejich kardinalitě a parcialitě, které udávají povinnost a četnost členství ve vztahu. První ze dvou čísel u dané entity vyjadřuje povinnost nebo nepovinnost členství ve vztahu (1 nebo 0) a druhé číslo stupeň četnosti (1 nebo N) (Obrázek 9). [11] Po transformaci se entity rozpadly do čtyř relací (Tabulka 3). Primární klíče jsou vyznačeny tučně, cizí klíče kurzívou. Tabulka 3 - Seznam relací. Zdroj vlastní. Název relace Sml Dop Nakl Vykl
Atributy cis_sml PK, rok PK, poz, cena, mesic, marze, cenakc, spz, raal FK raal PK, nazev, tel, fax ID_nakl PK, misto, datum, cas, naklad, cis_sml FK, rok FK ID_vykl PK, misto, datum, cas, cis_sml FK, rok FK
4.2.3. Normalizace
1NF – říká, ţe ţádný atribut v relaci není vícehodnotový [11]. Pokud vzniklé relace podrobíme normalizaci 1NF. zjistíme, ţe 1NF splňují. Atribut datum by se sice dal dekomponovat na atributy měsíc a den, ale většina implementačních nástrojů relačního modelu databází poskytuje datový typ datum. 29
2NF – je splněna za předpokladu splnění 1NF a dále říká, ţe kaţdý neklíčový atribut včetně kandidátních klíčů musí být plně funkčně závislý na celém primárním klíči [11]. Tato normální forma se tedy týká pouze relací se sloţeným primárním klíčem. V navrhovaném modelu má sloţený primární klíč pouze relace sml. Všechny atributy této relace jsou plně funkčně závislé na celém primárním klíči. Relační model tedy splňuje i 2NF.
3NF - splňuje relace, jestliţe je v 2NF a kaţdý neklíčový atribut je závislý na primárním klíči přímo, tedy není na primárním klíči závislý přes jiný atribut. Všechny relace splňují i tuto normální formu.
Po provedení transformace a normalizace byl navrhnut výsledný relační model dat (Obrázek 10).
Obrázek 10 - RMD databáze. Zdroj vlastní
4.3.
Implementace databáze
Na základě návrhu byl jako implementační nástroj pro vytvoření databáze zvolen nástroj PHP MyAdmin. Jedná se o nástroj umoţňující správu databáze MySQL pomocí webového rozhraní. Výhodou databázového systému MySQL je, ţe se jedná o volně 30
šiřitelný software. Pro rozsah databáze, která byla navrhnuta v předchozích krocích je nástroj PHP MyAdmin bohatě dostačující. Při implementaci databáze v PHP MyAdmin se nastavují vlastnosti jednotlivých tabulek i atributů, nastavují se zde integritní omezení odpovídající implementační úrovni, které nabízí nástroj PHP MyAdmin tj. primární a cizí klíče, datové typy, maximální moţnou délku, výchozí hodnoty a další. Strukturu a vlastnosti databáze v rámci implementační úrovně zobrazuje tabulka (Tabulka 4). Tabulka 4 - Struktura databáze na úrovni implementace. Zdroj vlastní Sloupec Datový typ Tabulka sml cis_sml INT rok INT cena DOUBLE marze INT cenakc INT poz TEXT spz TEXT mesic INT raal VARCHAR Tabulka nakl id_nakl INT misto TEXT naklad TEXT datum TEXT cas TEXT cis_sml INT rok INT Tabulka vykl id_vykl INT misto TEXT datum TEXT cas TEXT cis_sml INT rok INT Tabulka dop raal VARCHAR nazev TEXT tel TEXT fax TEXT
Maximální délka
Index
NE NE ANO NE NE 1000 ANO 12 ANO NE 6 NE
PRIMARY PRIMARY
NE ANO ANO ANO ANO NE NE
PRIMARY
NE 500 ANO 20 ANO 20 ANO NE NE
PRIMARY
6 250 12 12
PRIMARY
500 250 20 20
31
Nulový
NE ANO ANO ANO
Integritní omezení uvedená v tabulce (Tabulka 4) musí být ošetřena i na úrovni práce s databází v rámci vytvořeného programu, aby se docílilo zpětné vazby na konání uţivatele s moţností napravení chyby. Uţivatel musí mít kvalitní informace o chybě, která nastala, aby jí mohl řešit. Například pokud zadá velké mnoţství znaků, které není pro danou poloţku do databáze moţné uloţit, musí o tom být v rámci programu informován, aby tento fakt mohl napravit. Integritní omezení na úrovni aplikace jsou popsány v kapitole 5.2.8 Integritní omezení a ošetření výjimečných událostí. Implementaci databáze pomocí nástroje PHP MyAdmin ilustruje obrázek (Obrázek 11).
Obrázek 11 - Prostředí nástroje PHP MyAdmin. Zdroj vlastní
Popis obrázku (Obrázek 11):
A – Název databáze a vypsané jednotlivé tabulky.
B – Cesta k aktuální tabulce
C – Menu
D – detailní struktura vybrané tabulky, poloţka „Sloupec“ představuje jednotlivé sloupce tabulky, v této tabulce v tuto chvíli není ţádný záznam. Poloţka „typ“ představuje datový typ proměnné (int, text,…). Poloţka „Porovnávání“ představuje pouţitou znakovou sadu. Poloţka „Výchozí“ představuje výchozí hodnotu pro hodnoty daného sloupce. Pod poloţkou „Akce“ je pole tlačítek umoţňující editaci daného sloupce.
E – Menu pro přidávání sloupců do tabulky a další nástroje.
32
Do databáze „fakturace“ byla kromě výše uvedených tabulek začleněna i tabulka „udaje“. Jedná se o tabulku s pouze jedním záznamem, která uchovává statické informace exportované na objednávku jako je adresa firmy, kontaktní údaje atp. Pro uchování těchto informací mohlo být zvoleno i jiné formy, například textového souboru, nebo souboru XML, toto řešení však bylo vyhodnoceno jako nejsnazší, přičemţ funkčnost je u všech řešení srovnatelná.
33
5. Implementace aplikace Na základě průzkumu prostředí zejména pak hardwarových a softwarových prostředků firmy (kapitola 3.3 Průzkum prostředí) a poţadavků na IS (kapitola 3.5 Poţadavky na IS), byl jako implementační nástroj zvolen programovací jazyk Java. Těmto poţadavkům by jako implementační nástroj vyhovovalo více jazyků, jazyk Java byl však z těchto jazyků vybrán i na základě dalších vlastností jazyka popsaných v této kapitole. Jedná se o moderní objektově orientovaný programovací jazyk, který v současnosti patří k nejpouţívanějším programovacím jazykům na světě.
5.1.
Vybrané vlastnosti jazyka Java
V této podkapitole budou uvedena fakta o jazyce Java zejména taková, která jsou nezbytná pro porozumění pouţitých programovacích principů.
5.1.1. Objektová orientovanost Programovací jazyk Java je plně objektově orientovaný (vyjma osmi základních datových typů). To v praxi znamená, ţe program vytvořený v jazyce Java se skládá z jedné nebo více tříd. [12] Třídy obsahují atributy a metody. Třídy, stejně jako u jiných objektově orientovaných programovacích jazyků, slouţí jako forma pro vytvoření objektů. Objekty se někdy označují jako instance dané třídy nebo také referenční proměnné (protoţe je jejich hodnota předávána odkazem do paměti). V Javě jsou všechny třídy (ať uţ implicitně nebo explicitně) děděny ze třídy s názvem Object. [13] Třída Object je tedy přímým nebo nepřímým předkem všech tříd vytvořených v jazyce Java. Pokud vytvořená třída není zděděna z jiné třídy explicitně pomocí klíčového slova extends je implicitně děděna z třídy Object. Jak z předchozího textu vyplývá, Java nabízí nástroje jako je dědění nebo polymorfismus. Podrobnější popis principů těchto nástrojů je však nad rámec této práce.
5.1.2. Základní datové typy V jazyce Java rozeznáváme 8 základních (primitivních) datových typů. Jejich výčet a vlastnosti zobrazuje tabulka (Tabulka 5).
34
Tabulka 5 - Základní datové typy jazyka Java. Zdroj vlastní upraveno na základě [13]
název
klíčové slovo
velikost v paměti
hodnoty
byte
byte
1B
od –128 do +127
short
short
2B
od –32768 do +32 767
integer
int
4B
long
long
8B
od –2147483648 do +2147483647 od –9223372036854775808 do +9223372036854775807
float
float
4B
typ
celočíselný
7-8 platných cifer floating point
8B
15-18 platných cifer
character char
2B
65536 různých znaků
znakový
boolean
1b
2 hodnoty - true a false
logický
double
double
boolean
Datové typy float a double patří mezi datové typy s plovoucí desetinou čárkou (floating point).
5.1.3. Řídící struktury Mezi řídící struktury zařazujeme řídící a iterační příkazy (podmínky a cykly), tedy příkazy, které umoţňují měnit pořadí vykonávaných instrukcí a větvení programu. [12] Nejdůleţitějšími řídícími příkazy v Javě jsou jednoduchá podmínka a přepínač. Jednoduchá podmínka umoţňuje větvení programu do dvou větví na základě vyhodnocení logického výrazu. Příkaz je volán klíčovým slovem if a jeho obecná syntaxe dle [13] je: if(podmínka)příkaz_1 nebo if(podmínka)příkaz_1 else příkaz_2 Přepínač je volán klíčovým slovem switch a umoţňuje vícenásobné větvení programu. V Javě stejně jako v mnoha dalších programovacích jazycích rozeznáváme tři druhy cyklů: cyklus s podmínkou na začátku, cyklus s podmínkou na konci a cyklus s pevným počtem opakování. Pro cyklus s podmínkou na začátku pouţíváme klíčové slovo while, 35
pro cyklus s podmínkou na konci klíčových slov do while, a pro cyklus s pevným počtem opakování klíčové slovo for.
5.1.4. Grafické uţivatelské rozhraní Pro GUI (graphical user interface) existuje v předdefinovaných knihovnách Javy velké mnoţství tříd, představujících komponenty běţně pouţívané v operačních systémech zaloţených na práci s okny, jako je MS Windows. Děděním z před-vytvořených tříd nebo vytvářením jejich instancí lze v Javě snadno docílit přívětivého grafického rozhraní pro uţivatele zvyklého na prostředí MS Windows.
5.1.5. Další klíčové vlastnosti jazyka Java
Java je case-sensitivní, to znamená, ţe rozlišuje malá a velká písmena v názvech proměnných i v klíčových slovech. Proměnná s názvem okno není stejná jako proměnná s názvem Okno.
Pro textové řetězce existuje v Javě datový typ String. Přestoţe se nejedná o základní datový typ, patří třída String do balíčku, který je automaticky importován, proto deklaraci textové proměnné můţeme provádět explicitně.
Java také umoţňuje práci s poli a to vícerozměrnými, statickými i dynamickými (ArrayList).
Java disponuje propracovaným systémem zachycování výjimek. V praxi to znamená, ţe pokud nějaká část kódu můţe vyvolat chybu, je programátor nucen ji předem ošetřit.
5.2.
Vybrané problémy řešené při tvorbě apliakce
V této kapitole jsou podrobněji popsána řešení vybraných problémů nastalých při tvorbě aplikace v programovacím jazyce Java.
5.2.1. Spojení s databází Způsob komunikace s databází, byl v jazyce Java navrhnut tak, aby byla moţná komunikace se všemi často pouţívanými SŘBD (Systém Řízené Báze Dat) jako jsou kupříkladu Oracle, MySQL, MS Access nebo MS SQL Server. Z toho důvodu bylo firmou Sun Microsystems (tvůrce jazyka Java) vytvořeno jednotné rozhraní pro přístup k relačním databázím s názvem JDBC (Java Database Connectivity). [12] 36
Ovladač JDBC je překladač, který převádí zprávy specifické pro kaţdý databázový systém na zprávy, kterým rozumí interpret jazyka Java a naopak. Při vytváření apliakce, jeţ je předmětem této práce, vyvstal také problém propojení programu s databází. Jak bylo uvedeno v kapitole 4.3. Implementace databáze, pro vytvoření databáze byl pouţit nástroj PHP MyAdmin, tedy databázový systém MySQL, postupů propojení databáze s aplikací bylo čerpáno s elektronického zdroje [15]. Pro spojení s databází MySQL se pouţívá JDBC rozhraní určené pro databáze MySQL. Ovladač JDBC pro spojení s databází zpravidla poskytuje výrobce daného databázového systému, v tomto případě je to firma MySQL AB, ovladač je dostupný k volnému staţení na webových stránkách této firmy [14]. V této práci byl pouţit ovladač mysql-connectorjava-5.1.6. Daný ovladač stačí stáhnout, umístit do sloţky se souborem Databaze.java (nebo jiným, který zabezpečuje spojení s databází) a v editoru jej přidat do classpath, tedy zaregistrovat jako pouţívaný. Předtím, neţ mohou být provedeny jakékoli operace nad databází, je nutné ovladač nahrát a registrovat. K tomu slouţí příkaz Class.forName(”jméno_JDBC_ovladače”);. V konkrétním případě připojení k databázi MySQL můţe daný kód vypadat například tak, jak ilustruje vrchní část obrázku (Obrázek 12) řádek 18-25.
Obrázek 12 - Ilustrace zdrojového kódu pro připojení k databázi MySQL. Zdroj vlastní 37
Volání metody forName() třídy Class musí být, jako většina operací nad databází umístěno v bloku try{}, který zachycuje případné nastání výjimky. O řešení výjimky se pak stará kód uvedený v následném bloku catch{}. V tomto případě bude mít výskyt chyby za následek zobrazení chybového okna s hlášením: „Nepodařilo se zaregistrovat ovladač databáze!“ Ve chvíli, kdy je ovladač nahrán a zaregistrován, je moţné navázat spojení s databází. Registrace ovladače JDBC je vázána na třídu, která obsahuje metody pro práci s JDBC, tato třída se jmenuje DriverManager a obsahuje také metodu getConnection(), která zajišťuje připojení k příslušné databázi. Jako parametry metody getConnection() předáme adresu databáze, ke které se chceme připojit. V případě této práce je to databáze pojmenovaná fakturace a je umístěná na serveru, tedy na lokálním disku PC 2. K tomu, abychom po připojení do databáze nad ní mohli provádět datové operace, slouţí metoda createStatement(), která vytvoří instanci třídy Statement. Objekty třídy Statement disponují metodami executeQuery() a executeUpdate(), těm se jako parametr předává příslušný SQL dotaz. Metoda executeQuery() je určena pro dotazování databáze a výsledek dotazu vrací jako objekt rozhraní ResultSet, jak je vidět na obrázku (Obrázek 12). Oproti tomu metoda executeUpdate() slouţí k zapisování do databáze a jako parametr se jí předávají SQL dotazy typu INSERT nebo UPDATE. Z rozdílnosti povahy dotazování databáze a zápisu do databáze vyplývá, ţe bylo nutno vytvořit dvě metody, které by zajišťovaly propojení s databází. Vedle metody spojeni(), jejíţ zdrojový kód je zobrazen výše (Obrázek 12), byla vytvořena metoda zapis(), která se stará o zapsání do databáze. Tato metoda je procedurálního typu (tedy nevrací ţádnou hodnotu), coţ se v jazyce Java provádí klíčovým slovem void v deklaraci metody. Argumentem metody zapis() stejně jako metody spojeni() je SQL dotaz ve formě textového řetězce. Těla obou metod jsou prakticky totoţná, obě obsahují jak registraci ovladače tak připojení k databázi. Rozdíl je aţ v tom, ţe je volána metoda executeUpdate() instance třídy Statement, která se stará o zápis do databáze, tudíţ nic nevrací. Klíčový rozdíl mezi oběma metodami je vidět na obrázku (Obrázek 13), kde je zobrazena část kódu metody zapis().
38
Obrázek 13 - Demonstrace zápisu do databáze. Zdroj vlastní
Takto zapsané argumenty metody getConnection() (Obrázek 12 a Obrázek 13), tedy uvedení slova „localhost“ by umoţňovali pouze připojení k databázi umístěné na lokálním disku, nikoli přístup k databázi umístěné na serveru, tedy na PC 2 v rámci vnitřní sítě LAN. V rámci zvoleného způsobu přístupu k databázi (kapitola 4.1 Návrh aplikace a proces) bylo tedy nutno adresu databáze volit dynamicky s ohledem na to z jakého počítače bude do databáze aplikace přistupovat. Toho bylo dosaţeno vytvořením textového dokumentu, který obsahuje adresu serveru, z tohoto dokumentu je pak pomocí metody getIP() tato adresa načítá a metoda getIP() ji ve formě textového řetězce vrací jako svou návratovou hodnotu. Tento textový dokument je pak na kaţdém PC, ze kterého je aplikace spouštěna, pojmenován stejně, ale jeho obsah můţe být různý. Stejného efektu by bylo moţno dosáhnout nahrazením slova „localhost“ přímo IP adresou serveru v argumentu metody getConnection(), protoţe zadání IP adresy vlastního počítače je ekvivalentní k zadání slova „localhost“. V takovém případě by bylo připojení řešeno staticky. Tento způsob řešení by však s sebou přinášel několik nevýhod z hlediska pruţnosti a bezpečnosti, kupříkladu pokud by byla serveru přidělena jiná IP adresa, server byl přesunut na jiný počítač atp., vyţadovalo by to zásah do kódu programu. Z bezpečnostních důvodů pak kupříkladu PC 2 obsahuje v textovém dokumentu nikoli IP adresu serveru (tedy svou), ale nadále slovo „localhost“, to zaručuje spojení s databází i v případě, ţe by bylo znemoţněno připojení k síti. Poslední úpravou v argumentech metody getConnection() je pak explicitní nastavení znakové sady pomocí příkazu „characterEncoding=Cp1250“ připojeného přes otazník k názvu databáze. Tento postup je nutno provést, aby bylo moţno do databáze zapisovat některé problematické znaky české abecedy. Výslednou podobu metody getConnection() pak ilustruje obrázek (Obrázek 14)
39
Obrázek 14 - Výsledná podoba metody GetConnection(). Zdroj vlastní
Rozhraní ResultSet disponuje mnoha metodami pro zpracování výsledku SQL dotazu. Mezi tyto metody patří kupříkladu metoda next(). Pouţití této metody je spojeno s případem kdy návratem SQL dotazu je větší počet poloţek (řádků, sloupců), příkladem takového dotazu můţe být dotaz: „SELECT * FROM dop“, který vrací celý obsah tabulky dop. Pokud je třeba přistupovat k jednotlivým poloţkám, vyuţijeme metodu next() jako argument cyklu s podmínkou na začátku. Metoda next() přesune kurzor o jeden řádek vpřed z jeho aktuální pozice. Implicitně je kurzor umístěn před první řádek, první volání metody nastaví první řádek jako aktuální, druhé volání nastaví jako aktuální druhý řádek, a tak dále. Metoda next() vrací hodnotu false ve chvíli, kdy je kurzor nastaven za poslední řádek. [16] Pro přístup k meta-datům databáze slouţí metoda getMetaData(), s jejíţ pomocí se dá kupříkladu zjistit počet řádků nebo počet sloupců v tabulce.
5.2.2. Architektura klient/server Jak bylo uvedeno v kapitole 3.5 Poţadavky na IS a popsáno v kapitole 4.1 Návrh aplikace a proces aplikace přistupuje k datům uloţeným v databázi na principu architektury klient/server. Dále tamtéţ bylo uvedeno, ţe vnitřní síť (LAN) firmy je poskytovatelem internetu koncipována tak, ţe v rámci LAN má kaţdý počítač přidělenou pevnou IP adresu. Tento fakt umoţňuje na úrovni aplikace přistupovat do databáze umístěné na serveru ekvivalentním způsobem, jako kdyby byla umístěna na lokálním disku (podrobně v kapitole 5.2.1 Spojení s databází). Jediným rozdílem pak, je, ţe v textovém souboru, který obsahuje adresu serveru není uvedeno klíčové slovo „localhost“, ale IP adresa serveru, v tomto případě tedy PC 2.
5.2.3. Hlavní okno Po spuštění aplikace se otevře okno aplikace pojmenované „Hlavní okno“. Toto okno obsahuje pouze horizontální menu a obrázek s logem firmy ROZLÍVKA TRANSPORT s.r.o. Toto okno funguje pouze jako jakási úvodní stránka, tedy brána k dalším funkcím 40
aplikace. Horizontální menu funguje klasicky jako u většiny desktopových aplikací a obsahuje dvě poloţky: „Soubor“ a „Nastavení“. Poloţka „Nastavení“ obsahuje pouze jedinou poloţku a to „Údaje o výstupu“ skrze ni se nastavují statické údaje tiskového výstupu, jako je adresa firmy, e-mail apod. Poloţka „Soubor“ pak zahrnuje následující poloţky:
„Nový...“ – zvolení této poloţky zobrazí malé okno, ve kterém uţivatel volí, jestli chce otevřít nový zadávací formulář, nové okno pro správu databáze nebo nové okno finančních výstupů
„Uložit jako...“ – tato volba je přístupná aţ ve chvíli kdy je aktivní nějaký zadávací formulář a umoţňuje uţivateli vytvořit z vyplněného formuláře výstup v podobě souboru PDF
„Otevři z databáze“ – volba této poloţky je ekvivalentní k volbě nového okna pro správu databáze
„Uložit do databáze“ – tato volba je opět přístupná aţ pro otevřený zadávací formulář a umoţňuje jeho uloţení do databáze.
Při otevření nového zadávacího formuláře je v hlavním panelu okna otevřen zadávací formulář jako záloţka, přičemţ takto můţe být otevřeno i více panelů, ty jsou pak dynamicky pojmenovávány, jak ilustruje obrázek (Obrázek 15).
Obrázek 15 - Otevírání panelů zadávacího formuláře. Zdroj vlastní
5.2.4. Zadávací formulář pro výpis objednávek Jedním ze dvou stěţejních cílů systému, tak aby byl ţádaným přínosem, byl stanoven poţadavek na usnadnění práce vypisování objednávek přepravy. Jako jeden z prvků aplikace byl proto vytvořen zadávací formulář pro výpis objednávek. Strukturu tohoto formuláře a jeho grafickou podobu určuje především podoba tabulky v dokumentu MS Word, která byla pouţívána spedičními pracovníky pro vypisování objednávek. Vyplněná a vytištěná podoba takto vyplněné objednávky je uvedena v příloze. 41
Formulář obsahuje všechny poloţky tak, jak jiţ byly popsány v kapitole 3.3 Průzkum prostředí. Navíc obsahuje poloţky „Marţe“ a „Cena v Kč“, ty nejsou součástí tisknutelné verze objednávky, ale jsou na formulář zařazeny, protoţe tyto údaje jsou pouţity pro tvorbu souhrnných výstupů. Pro vyplnění jednotlivých poloţek je pouţito základních grafických komponent jazyka Java, které nabízí knihovna Swing. Těmito komponentami jsou:
JTextField – neboli textové pole je klasický formulářový prvek. Jedná se o jednořádkové pole libovolné délky umoţňující uţivateli zadávat text.
JLabel – slouţí jako popisek a jeho text je uţivatelem needitovatelný.
JTextArea – textová oblast je podobná jako textové pole, ale můţe zabírat libovolný počet řádků.
JComboBox- rozevírací seznam. Umoţňuje výběr jedné z předem vyplněných poloţek. Skládá se z textové části a malého tlačítka se šipkou nalevo od textu. Po kliknutí na tuto komponentu se rozevře seznam vybratelných poloţek. Tato komponenta není uţivatelem přímo editovatelná.
JSpinner – jedná se o komponentu, která se skládá z textového pole a dvou tlačítek se šipkami směřujícími nahoru a dolu nalevo od textového pole. Slouţí k záznamu číselných hodnot. Pomocí tlačítek je moţno sniţovat nebo zvyšovat číslo v textové části o předem daný krok, horní a spodní číselná hranice je také předem nastavitelná. Textová část je přímo editovatelná uţivatelem.
JButton – tlačítko. Tato komponenta představuje klasické tlačítko, na které je typicky vázána nějaká událost.
Jaké komponenty byly pouţity pro zobrazení a editaci poloţek formuláře shrnuje tabulka (Tabulka 6). Sloupec „Výchozí hodnota“ představuje výchozí hodnotu pouze prázdného formuláře, formulář otevřený z databáze je vyplněn údaji z databáze.
42
Tabulka 6 - Komponenty zadávacího formuláře. Zdroj vlastní Položka číslo smlouvy rok smlouvy dopravce telefon dopr. fax dopr. RAAL dopr. místo nakládky den nakládky měsíc naklákdy rok nakládky čas nakládky náklad místo vykládky den vykládky měsíc vykládky rok vykládky čas vykládky poznámka cena marže cena v Kč spz
Komponenta JTextField JSpinner JComboBox JTextField JTextField JTextField JTextArea JSpinner JSpinner JSpinner JTextField JTextField JTextField Jspinner JSpinner JSpinner JTextField JTextArea JTextField JTextField JTextField JTextField
Výchozí hodnota dynamicky z databáze aktuální rok první dopravce z databáze dle abecedy dynamicky dle dopravce dynamicky dle dopravce dynamicky dle dopravce prázdné textové pole aktuální den aktuální měsíc aktuální rok prázdné textové pole prázdné textové pole prázdné textové pole aktuální den aktuální měsíc aktuální rok prázdné textové pole prázdné textové pole prázdné textové pole hodnota "0" hodnota "0" prázdné textové pole
U komponent, kde je vyplňován aktuální časový údaj (rok, měsíc, den), je pouţito datového typu třídy Date. Z něho je pak pomocí textových funkcí separován aktuální den, měsíc nebo rok. Seznam dopravců do rozevíracího seznamu je načítán z databáze z tabulky dop a abecedně seřazen. Při výběru konkrétního dopravce, se do textových polí telefon, fax a RAAL automaticky z databáze načtou příslušné hodnoty dle zvoleného dopravce. Při otevření nového formuláře je implicitně nastaven první dopravce dle abecedního řazení. Pro urychlení volby příslušného dopravce (vzhledem k jejich počtu) je poté moţno pouţít počátečního písmene dopravce pro rychlé přesunutí v seznamu. Poloţky „marţe“ a „cena v Kč“ mají přednastavenou hodnotu nula. Důvod, proč zrovna tyto dvě poloţky, mají přednastavenou hodnotu na „0“, kdyţ jiné poloţky jsou prázdné, je takový, ţe v době vypisování objednávky spediční pracovník tyto hodnoty zpravidla nezná a doplňuje je později (coţ umoţňuje editace objednávky z databáze). 43
Zároveň pokud by do databáze byla uloţena u těchto poloţek prázdná hodnota, nebylo by moţno z nich pak počítat automatické součty. Aby spediční pracovník pokaţdé, kdyţ v danou chvíli nezná hodnotu těchto poloţek, nemusel do nich vpisovat nulu, je tato hodnota před-vyplněna. V databázi pak existence této hodnoty nijak neznemoţní tvorbu souhrnných výstupů. Pokud uţivatel nenalezne v rozevíracím seznamu poţadovaného dopravce (ještě nikdy nebyl pouţit), je třeba ho přidat do databáze. K tomuto účelu je pod komponentou rozevíracího seznamu umístěno tlačítko s nápisem „Nový...“. Po kliknutí na toto tlačítko otevře se okno s formulářem pro vyplnění údajů nového dopravce. Toto okno obsahuje poloţky pro vyplnění údajů o dopravci, tedy jeho název, RAAL kód, telefon a fax. Poté, co uţivatel tyto údaje vyplní, klikne na tlačítko s nápisem „Uloţit do Databáze“a údaje o dopravci jsou poté uloţeny do databáze. Při tomto procesu je testováno, zda dopravce se stejným názvem nebo RAAL kódem jiţ neexistuje. V takovém případě by na tento fakt byl uţivatel upozorněn dialogovým oknem, přičemţ dostane na výběr, zda chce údaje o takovém dopravci přepsat, nebo nikoli a pokračovat v editaci. Na podobném principu funguje i proces úpravy údajů o vybraném dopravci. K tomuto účelu slouţí tlačítko s nápisem „Edituj“ umístěné vedle tlačítka „Nový...“. Po kliknutí na toto tlačítko se otevře stejné editační okno, jako v prvním případě, pouze jeho poloţky, tedy údaje o dopravci, jsou předvyplněny na základně vybraného dopravce (aktuálně zvoleného dopravce v rozevíracím seznamu). Při změně údajů o dopravci nebo při přidání nového dopravce se tato změna propíše do všech otevřených panelů zadávacích formulářů. Výslednou podobu formuláře zobrazuje obrázek (Obrázek 16).
44
Obrázek 16 - Výsledná podoba zadávacího formuláře. Zdroj vlastní
Aby si vzhled zadávacího formuláře zachoval přehlednost i při rozdílných rozlišeních monitorů jednotlivých počítačů, jsou komponenty do okna umisťovány relativně s ohledem na rozlišení monitoru v pixelech.
K zjištění rozlišení monitoru slouţí metoda
getScreenSize(). Protoţe (jak bylo uvedeno v kapitole 3.3 Průzkum prostředí) údajů o nakládce a údajů o vykládce můţe být 1-3, je tomuto faktu uzpůsoben i zadávací formulář. Po otevření nového formuláře jsou na něm zobrazeny pouze údaje o jedné nakládce a vykládce. Pokud by uţivatel potřeboval vypisovat údaje o více nakládkách nebo vykládkách, je při pravém okraji formuláře umístěno tlačítko „+“ vţdy pro vykládku i nakládku. Po kliknutí na toto tlačítko se zobrazí další skupina údajů o nakládce (resp. vykládce). Pokud by uţivatel na toto tlačítko klikl omylem, nebo si svou volnu rozmyslel, nic se neděje, do tiskového výstupu se tento fakt neprojeví, dokud uţivatel nevyplní pole „místo nakládky“ (resp. vykládky). Volbu nového místa nakládky (resp. vykládky) zobrazuje obrázek (Obrázek 17).
45
Obrázek 17 - Přidání dalšího místa nakládky a vykládky do formuláře. Zdroj vlastní
5.2.5. Okno správy databáze Aby měl uţivatel moţnost prohlíţet přehledně zobrazené objednávky přepravy a mohl je zpětně editovat zejména pak za účelem doplnění marţe a ceny v Kč, obsahuje aplikace okno správy databáze. Jedná se o okno, v němţ jsou vypisovány objednávky seřazené podle svého čísla v jednotlivých letech a základní údaje, tak aby výsledný soupis nesl potřebné informace a zároveň si zachoval přehlednost. Po pravé straně kaţdé poloţky je pak tlačítko „Editace“. Po stisknutí tohoto tlačítka se otevře panel zadávacího formuláře a jeho poloţky se vyplní odpovídajícími daty z databáze. Zobrazení poloţek ilustruje obrázek (Obrázek 18).
Obrázek 18 - Výpis objednávek z databáze. Zdroj vlastní
5.2.6. Okno správy finančních výstupů Druhým z hlavních cílů systému a jeho přínosnosti byla stanovena tvorba finančních výstupů tak, aby byl usnadněn proces sčítání cen a marţí a tím byla vytvořena podpora pro pruţnější manaţerské rozhodování. K těmto účelům slouţí okno „správy finančních výstupů“. Okno se skládá z poloţek, ve kterých jsou nastaveny atributy pro výpočet ukazatele. V těchto poloţkách uţivatel vybírá, zda chce počítat souhrn ceny nebo marţe, za jaký měsíc v daném roce chce výpočet 46
provést a zda chce výpočet provést pro jednoho konkrétního dopravce nebo souhrnně pro všechny dopravce. Dále okno obsahuje komponentu grafu, která umoţňuje grafické zobrazení průběhu vývoje ukazatele v daném měsíci. Tato komponenta nese název Chart2D a jedná se o komponentu externí knihovny JChart2D, která je volně staţitelná na [17]. Ve chvíli, kdy uţivatel nastaví poloţky, stiskne tlačítko „Vypočítat a zobrazit“, poté se v okně zobrazí výsledek v číselné podobě a dále také v grafické podobě prostřednictvím komponenty Chart2D. Podobu výběru atributů výpočtu a zobrazení výsledků ilustruje obrázek (Obrázek 19).
Obrázek 19 – Okno správy finančních výstupů. Zdroj vlastní
5.2.7. Řešení tiskových výstupů Mezi funkční poţadavky na IS byl zařazen i poţadavek, ţe aplikace musí umoţňovat export formuláře do tisknutelného souboru (kapitola 3.5.1 Poţadavky na funkce IS). API programovacího jazyka Java nástroj pro přímou tvorbu formátovatelného tiskového výstupu neobsahuje. Z tohoto důvodu bylo pro tvorbu tiskových výstupů vyuţito knihovny funkcí s názvem JasperReports, ta je volně dostupná na internetu na [18] a popis základní práce s touto knihovnou je dostupný na [19]. JasperReports je systém, který podle vstupní šablony produkuje výstup. Vytvoření kaţdé sestavy se dle [19] skládá ze čtyř základních kroků: 47
vytvoření vstupní šablony ve formátu .jrxml
zkompilování šablony do souboru .jasper
vloţení vstupních dat do sestavy
volání metod z JasperReports API pro tisk sestavy.
Postup vytvoření tiskové sestavy ilustruje obrázek (Obrázek 20).
Obrázek 20 - Postup vytvoření tiskové sestavy pomocí JasperReports. Zdroj [19]
Soubor .jrxml je v podstatě XML soubor, který popisuje to, jak má tisková sestava vypadat a co má obsahovat. Tento soubor se dá editovat klasicky jako kaţdý XML soubor podle daných pravidel, to však vyţaduje značné odborné znalosti, proto je pro účely snadné editace šablony pro tvorbu tiskového výstupu moţno pouţít editační nástroj iReport, který je volně staţitelný na [18]. Šablona vytvořená pomocí nástroje iReport je poté pouţívána k tvorbě tiskového výstupu do souboru PDF. O tento proces se jiţ stará vytvořená aplikace. Jak je tvorba výstupu do PDF řešena v kódu jazyka Java ilustruje obrázek (Obrázek 21).
Obrázek 21 - Tvorba výstupu do PDF. Zdroj vlastní
Nejprve je nutno vytvořit instanci třídy JasperReport, které předáváme zkompilovanou šablonu. O kompilaci se stará metoda compileReport() třídy JasperCompileManager, která 48
jako svůj argument přebírá cestu a název šablony v tomto případě pojmenované „strep.jrxml“. Dále je třeba vytvořit instanci třídy JaspePrint, o to se postará metoda fillReport() třídy JasperFillManager. Tato metoda přebírá jako argument jednak vytvořenou instanci třídy JasperReport a jednak parametry, pomocí kterých je moţno do tiskových výstupů promítnout dynamické poloţky objednávky. Předání instance třídy JREmptyDataSource jako posledního argumentu metody fillReport() pak představuje fakt, ţe report pouţívá jako dynamických poloţek pouze parametry, ale ţádné proměnné (proměnné slouţí k dodatečným výpočtům v rámci kompilace šablony). O to aby se provedl export do souboru typu PDF se stará třída JasperExportManager konkrétně její metoda exportReportToPdfFile(), která přijímá dva argumenty. Prvním argumentem je vytvořená instance třídy JaspePrint a druhým je cesta k adresáři, do kterého má být výstup uloţen. Tato cesta je volena dynamicky uţivatelem pomocí komponenty JFileChooser, kterou nabízí knihovna Swing. Podoba výsledného PDF souboru, tak jak je vyplněn v zadávacím formuláři a poté exportován, je uvedena v příloze.
5.2.8. Integritní omezení a ošetření výjimečných událostí Integritní omezení na úrovni databáze popisuje Tabulka 4 v kapitole 4.3 Implementace databáze. Aby však byla aplikace bezpečná a nedocházelo k chybám při komunikaci aplikace s databází, je třeba integritní omezení ošetřit i na úrovni aplikace. Díky způsobu ošetření výjimek v jazyce Java, které nutí programátora explicitně v kódu ošetřit místa, která by mohla způsobit pád aplikace, není nebezpečí, ţe by některá chyba způsobila kolaps programu. To zároveň umoţňuje na předpokládané výjimečné události v běhu programu reagovat. Mezi tyto události například patří událost, kdy by uţivatel pokusil do databáze uloţit smlouvu, která jiţ existuje. Při kaţdém uloţení smlouvy je tedy třeba testovat, zda se smlouva s daným číslem a daným rokem jiţ v databázi nenachází. Pokud ano, je uţivateli nabídnuta volba, zda chce danou smlouvu přepsat, nebo dál pokračovat v editaci. Ekvivalentním způsobem je řešena i situace, kdy je do databáze zadáván nový dopravce. Také ve chvíli, kdy by z neočekávaných důvodů selhala komunikace s databází, nenastane pád aplikace nebo jiné její selhání, ale o tomto faktu je uţivatel informován dialogovým oknem. Integritní omezení s hlediska databáze jsou jednak řešeny na úrovni testování výstupů kritických komponent, které by mohly způsobit konflikt při zápisu do databáze a jednak
49
samotným nastavením některých komponent, které neumoţňují jiný výstup neţ, ten který očekává na svém vstupu databáze z hlediska typu proměnné, hodnoty i délky. Výstup je testován u komponent „číslo smlouvy“, „marţe“ a „cena v Kč“. Pokud by do těchto polí formuláře uţivatel zadal jinou neţ číselnou hodnotu v poţadovaném tvaru nebo nezadal ţádnou hodnotu, aplikace uţivateli neumoţní smlouvu uloţit do databáze a na problém jej upozorní pomocí dialogového okna. Toho je dosaţeno pomocí převodu textového výstupu komponent JTextField na celočíselný typ Integer. V případě, ţe by uţivatel zadal do komponenty číslo v neodpovídajícím tvaru nebo zadal text popřípadě nezadal nic (před-vyplněnou hodnotu smazal), vyvolá se při běhu programu výjimka, která je v programu zachycena a ošetřena zobrazením dialogového okna. Co se týče délky textových řetězců jako výstupu z komponent formuláře, je komponentám JTextField nastavena maximální moţná délka textu na číslo odpovídající integritnímu omezení na úrovni databáze.
5.3.
Moţnosti dalšího rozšíření
Pokud by se odstupem času, po dlouhodobějším pouţívání systému (řádově měsíce), zdálo vhodné do aplikace implementovat další části (dne rozhodnutí pracovníků firmy), byla navrţena tato moţná rozšíření aplikace:
rozšíření možností souhrnných výstupů – do okna souhrnných finančních výstupů by mohly být přidány i další souhrnné údaje, jako kupříkladu celkový počet vypsaných objednávek na jednoho konkrétního dopravce atp.
možnost přímého tisku formuláře – tato moţnost nebyla do aplikace řazena z důvodu toho, ţe exportovaný PDF soubor je nejen tisknut, ale i odesílán elektronickou formou a popřípadě v této podobě uchováván. Aby tato funkce (přímý tisk) mohlo být efektivně vyuţívána, musela by aplikace patrně umoţňovat zobrazení náhledu tisku.
možnosti dalšího nastavení – mezi tyto moţnosti by se dalo zařadit kupříkladu nastavení vzhledu aplikace (barvy rámů atp.), moţnost dynamické volby zobrazovaných poloţek databáze (tj. dynamická úprava zobrazované tabulky kupříkladu odebírání a přidávání sloupců) a další. Rozšíření aplikace o tyto moţnosti by však příliš nezvyšovalo její efektivitu a přínos v rámci stanovených cílů. 50
6. Zavedení aplikace v prostředí firmy Pro zavedení systému do provozu firmy bylo pouţito strategie, která se nejvíce přibliţuje strategii postupného zavádění. S pracovníky firmy byly konzultovány a odzkoušeny dílčí části programu, přičemţ bylo navrţeno několik úprav aplikace dle poţadavků pracovníků a tyto úpravy pak byly v aplikaci realizovány. Aby mohl být vytvořený systém provozován, bylo nutno programové vybavení počítačů firmy doplnit o některé softwarové komponenty. Na všechny počítače, kde byla aplikace instalována, muselo být nainstalováno (pokud jiţ nebylo) běhové prostředí jazyka Java pro daný operační systém, v případě všech počítačů tedy prostředí pro běh na systému MS Windows. Běhové prostředí jazyka Java (JRE – Java Runtime Environment) je volně dostupné na adrese „http://java.sun.com“ a jeho velikost je 15,7 MB (verze 1.6.0.24), jeho instalace tedy nepředstavovala pro firmu ţádnou zátěţ. Pro potřeby běhu systému byl na PC 2 nainstalován programový balík WampServer, coţ je jedna z mnoha distribucí, která v sobě integruje nástroje Apache server, PHP, MySQL, phpMyAdmin a další rozšíření. Tento program je dostupný jako freeware. Díky tomuto softwarovému prostředku bylo moţno na PC 2 implementovat databázi. Zástupce spouštěcí ikony programu WampServer byl umístěn do sloţky „Po Spuštění“ lokálního disku PC 2, čímţ bylo docíleno stavu, kdy pracovník firmy nemusí explicitně spouštět po zapnutí počítače server, ale tato činnost se provede automaticky. Přístup na server umístěný na PC 2 byl blokován systémovým firewallem, proto bylo pro zajištění průchodu komunikace povolit komunikaci pro port 3306, na kterém komunikuje aplikace s databází, resp. serverem na kterém je umístěna. Veškeré zdrojové kódy, exportovaná databáze i zkompilovaná aplikace je umístěna na přiloţeném CD. Při zavádění aplikace se nevyskytly ţádné významné problémy, pouze připomínky k podobě zadávacího formuláře, které byly na základě přání pracovníků opraveny. Aplikace začala být ihned po své implementaci pracovníky firmy vyuţívána. Aplikace splňuje všechny vytyčené poţadavky na její funkce i poţadavky nefunkční. Lze tedy objektivně říci, ţe je pro pracovníky firmy přínosem a plní svůj účel.
51
Závěr Úkolem této bakalářské práce bylo poskytnout podklad pro řešení problému nedostatečného vyuţití ICT ve firmě ROZLÍVKA TRANSPORT s.r.o., která se zabývá logistikou. Dále bylo úkolem, na základě informací získaných v dané firmě, navrhnout a vytvořit aplikaci jako součást informačního systému, která by usnadnila spedičním pracovníkům firmy sepisování objednávek a evidenci a management firmy podpořila v jeho rozhodovacích procesech poskytnutím automatických součtů některých finančních ukazatelů. Na základě průzkumu provedeného ve firmě a popsaného v této práci byla navrţena a vytvořena aplikace v rámci IS dané firmy dle stanovených cílů. Tato aplikace pak byla ve firmě implementována a v současné době (24. 4. 2011) je plně funkční a je pracovníky firmy vyuţívána ke všem účelům, ke kterým byla vytvořena. Na základě těchto faktů, lze tedy konstatovat, ţe cíle této práce byly splněny.
52
Pouţitá literatura [1] KŘUPKA, Jiří. Teorie Systémů. Pardubice: Univerzita Pardubice, 2006. 140 s. ISBN 80 – 7194 – 923 – X. [2] psp.cz [online]. 2010 [cit. 2010-12-05]. Zákon č. 256/1992 Sb., o ochraně osobních údajů. Dostupné z WWW: < http://www.psp.cz/eknih/1990fs/tisky/t1465_00.htm > [3] pristupnost.cz [online]. 2010 [cit. 2010-12-05]. Zákon 365/2000 Sb., O informačních systémech veřejné správy. Dostupné z WWW: < http://www.pristupnost.cz/zakon-365-2000-sb-o-informacnich-systemech-verejnespravy> [4] KOMÁRKOVÁ, Jitka. Úvod do informačních systémů: pro kombinovanou formu studia. Pardubice: Univerzita Pardubice, 2006. 85 s. ISBN 80-7194-870-5. [5] muni.cz [online]. 2010 [cit. 2010-12-05]. Ţivotní cyklus informačního systému. Dostupné z WWW: < http://www.fi.muni.cz/~smid/mis-zivcyk.htm > [6] DRAHOTSKÝ, Ivo; ŘEZNÍČEK, Bohumil. Logistika – procesy a jejich řízení. Brono: Computer Press, 2003. 334 s. ISBN 80 - 7226 - 521 - 0. [7] slovnik-cizich-slov.cz [online]. 2011 [cit. 2011-02-07]. Spedice. Dostupné z WWW: < http://slovnik-cizich-slov.abz.cz/web.php/slovo/spedice> [8] LIKŠŮ, Vladimír. Logistika 1. Praha: VŠE v Praze, 2001. 269 s. ISBN 80 - 245 - 0166 - X. [9] raal.cz [online]. 2011 [cit. 2011-02-07]. Spediční databanka RAALTRANS. Dostupné z WWW: < http://www.raal.cz/cs/popis-raal> [10] jr-cz.eu [online]. 2011 [cit. 2011-02-07]. ROZLÍVKA TRANSPORT s.r.o. Dostupné z WWW:
[11] ŠIMONOVÁ, Stanislava; PANUŠ, Jan. Databázové systémy I. Pardubice: Univerzita Pardubice, 2005. 106 s. ISBN 978 - 80 - 7194 - 988 - 6.
53
[12] KEOGH, James. Java bez předchozích znalostí. Brno: CP Books, a.s., 2005. 280 s. ISBN 80-251-0839-2 [13] VIRIUS, Miroslav. Java pro zelenáče. Praha: Neocortex spol. s r.o., 2005. 268 s. ISBN 80-86330-17-6 [14] mysql.com [online]. 2011 [cit. 2011-02-05]. MySQL Connectors. Dostupné z WWW: < http://www.mysql.com/products/connector/> [15] ŠEDA, Jan. interval.cz [online]. 2011 [cit. 2011-02-05]. Úvod do JDBC. Dostupné z WWW: < http://interval.cz/clanky/uvod-do-jdbc> [16] oracle.com [online]. 2011 [cit. 2011-02-07]. Interface ResultSet. Dostupné z WWW: < http://download.oracle.com/javase/1.4.2/docs/api/java/sql/ResultSet.html> [17] sourceforge.net[online]. 2011 [cit. 2011-02-08]. JChart2D. Dostupné z WWW: [18] jasperforge.org [online]. 2011 [cit. 2011-02-08]. JasperForge. Dostupné z WWW: < http://jasperforge.org > [19] JEŢEK, Kamil. java.cz [online]. 2011 [cit. 2011-05-07]. Úvod do problematiky tisku sestav. Dostupné z WWW:
54
Seznam zkratek ICT
Informační a komunikační technologie (Information and Communication Technologies)
IS
Informační systém (Information System)
ŢC
Ţivotní cyklus
MMDIS
Multidimensional Management and Development of Information Systems
HW
Hardware
SW
Software
UML
Unifikovaný modelovací jazyk (Unified Modeling Language)
EPC
diagram procesu řízeného událostmi (Event-driven Process Chain)
PC
Osobní počítač (Personal Computer)
ERD
Entity Relationship Diagram
RMD
Relační model dat
NF
Normání forma
XML
Extensible Markup Language
SŘBD
Systém Řízené Báze Dat
JDBC
„Javovské“ databázové spojení (Java Database Connectivity)
LAN
Lokální síť (Local Area Network)
API
Aplikační programové rozhraní (Application Programming Interface)
JRE
Běhové prostředí Javy (Java Runtime Environment)
55
Příloha 1 – Původní podoba objednávky (část1)
Příloha 1 – Původní podoba objednávky (část2)
Příloha 2 – Tabulka původního způsobu sepisování informací o objednávkách
Příloha 3 – EPC diagram práce s aplikací.
Příloha 4 – Nynější podoba objednávky
