Pokladní modul na platformě SOA

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Pokladní modul na platformě SOA

DIPLOMOVÁ PRÁCE

Bc. Vít Kožín

Brno, 2011

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

Vít Kožín

Vedoucí práce: RNDr. Tomáš Ludík

Poděkování Děkuji vedoucímu diplomové práce, RNDr. Tomáši Ludíkovi, za odborné vedení a pomoc při tvorbě této práce. Taktéž děkuji firmě EtosComp, s.r.o., za možnost navrhnout a implementovat pro ni pokladní systém. Také bych rád poděkoval zaměstnancům a klientům této firmy za trpělivost a snahu důkladně vystihnout jejich představy a specifikovat požadavky na výslednou práci.

Shrnutí Tato diplomová práce se zaměřuje na objektovou analýzu, návrh a implementaci pokladního systému založeného na platformě SOA. V první části je tato architektura představena a jsou zde popsány nejznámější způsoby jejího využití. Obsahem prvních kapitol je i seznámení s pokladními systémy a jejich funkcionalitou, která se mnohdy odlišuje podle toho, jaké hardwarové periferie jsou s nimi používány. Zmíněny jsou i nejznámější v současné době používané pokladní systémy. Druhá část práce je věnována návrhu pokladního modulu na základě získaných informací. Jsou zde zachyceny požadavky na tento systém a také zakreslen diagram tříd, jenž vychází z principů architektury MVC. Je zde také rozebráno rozhraní pro komunikaci se skladovým modulem, ze kterého se získávají potřebná data. Podle tohoto návrhu je systém následně implementován a poté je popsáno, jakým způsobem byl otestován. Závěrečná kapitola shrnuje obsah práce a nastiňuje možnosti, kam se vývoj tohoto softwaru může posunout do budoucna.

Klíčová slova SOA, UML, analýza, Java, pokladna, skladový systém, prodej, produkty

Obsah 1. Úvod .................................................................................................................................. 1 1.1 Motivace ..................................................................................................................... 1 1.2 Cíle práce.................................................................................................................... 1 1.3 Obsah práce ................................................................................................................ 2 2. Platforma SOA .................................................................................................................. 3 2.1 Principy SOA............................................................................................................... 3 2.2 Dělení SOA ................................................................................................................. 4 2.3 Referenční model SOA................................................................................................ 5 2.4 Implementace SOA...................................................................................................... 7 2.4.1 Možnosti implementace služeb ............................................................................ 7 2.4.2 Remote Method Invocation .................................................................................. 8 2.4.3 Web Services ........................................................................................................ 8 3. Pokladní systémy............................................................................................................. 10 3.1 Vlastnosti pokladních systémů .................................................................................. 10 3.2 Hardware ................................................................................................................... 11 3.2.1 Tiskárny.............................................................................................................. 12 3.2.2 Čtečky čárových kódů ........................................................................................ 13 3.2.3 Dotykové obrazovky .......................................................................................... 14 3.2.4 Váhy a jiná měrná zařízení ................................................................................. 14 3.2.5 Čipy pro identifikaci osob nebo zboží................................................................ 15 3.2.6 Pokladní zásuvky................................................................................................ 15 4. Analýza současného stavu ............................................................................................... 16 4.1 Legislativa ................................................................................................................. 16 4.2 Konkurence................................................................................................................ 17 4.2.1 Winshop - APLS Praha s.r.o............................................................................... 17 4.2.2 Awis - A.W.I.S. Správa, systémy s.r.o. .............................................................. 18 4.2.3 Fusion - iTechnologies s.r.o. .............................................................................. 18 4.2.4 Shrnutí ................................................................................................................ 19 5. Analýza a návrh ............................................................................................................... 20 5.1 Specifikace požadavků .............................................................................................. 20 5.1.1 Funkční požadavky............................................................................................. 20 5.1.2 Nefunkční požadavky ......................................................................................... 21 5.2 Diagram případů užití................................................................................................ 21 5.2.1 Účastníci ............................................................................................................. 22 5.2.2 Případy užití........................................................................................................ 22 5.3 Návrh grafického rozhraní......................................................................................... 25 5.4 Diagramy tříd............................................................................................................. 26 5.4.1 Aplikační logika, uživatelské rozhraní a služby................................................. 26 5.4.2 Datový model ..................................................................................................... 29 5.4.3 Diagram nasazení ............................................................................................... 30 6. Implementace................................................................................................................... 31 6.1 Použité nástroje ......................................................................................................... 31 6.2 Postup implementace................................................................................................. 32

7. Testování ........................................................................................................................ 38 7.1 Testování implementace pokladního modulu............................................................ 38 7.2 Testování kompatibility s hardwarem a OS .............................................................. 39 8. Závěr................................................................................................................................ 40 Reference ............................................................................................................................. 42 Přílohy ................................................................................................................................. 44 Diagram tříd..................................................................................................................... 44 Ukázky zdrojových kódů................................................................................................. 45 Grafické rozhraní............................................................................................................. 47 Obsah CD ........................................................................................................................ 48

1. Úvod 1.1 Motivace Počítače a software se v dnešní době již nevyužívají jen pro specializované úkoly, ale jejich rozšíření mezi běžnou populaci umožňuje jejich nasazení v oblastech, které dříve tuto formu zjednodušení práce přímo nevyžadovaly. Jednou z těchto oblastí je i obchodní činnost, kde lze s úspěchem používat skladové a pokladní systémy pro evidenci pohybu zboží, financí, práce zaměstnanců či standardizaci tisknutých dokladů. Také je možné tyto činnosti z co největší části automatizovat a snížit tak míru potřebné lidské práce. Proto i menší obchody a prodejny již začínají využívat nějaký pokladní či skladový systém. Tyto systémy mezi sebou v některých případech musí komunikovat a i systém této komunikace je zapotřebí navrhnout a implementovat. Zárověn je nutné uvažovat i specifický hardware, který se k obsluze může využívat. Celé toto odvětví vývoje softwaru je také ovlivněno současnou legislativou České republiky. Společnost EtosComp, s.r.o (dále jen "EtosComp"), je menší firma zabívající se informačními technologiemi a vývojem softwaru. V nedávné době se rozhodla vytvořit vlastní skladový systém pro evidenci pohybu zboží, objednávek, naskladnění, prodejů a dalších souvisejících činností. K tomuto systému jsem také navrhnul a implementoval pokladní modul za účelem možnosti prodávat zboží ze skladu koncovým zákazníkům. Tématem mé diplomové práce je seznámit se s platformou SOA a současnou verzí skladového systému. Pro jeho potřeby vytvořit pokladní modul, který by s ním byl schopen komunikovat a umožňoval všechny další běžné činnosti, které při své práci musí výkonávat prodavači a prodavačky klientů firmy EtosComp. Stejně tak je součástí práce i popis zákonů a norem, které mohou tento software ovlivňovat. Po analýze současných běžně dostupných pokladních modulů a důkladném seznámení se skladovým systémem Achilles byl k němu navržen a implementován tento modul. Díky dodržení principů architektury SOA je však možné ho případně integrovat i s jinými systémy.

1.2 Cíle práce Cílem první části této práce je seznámit se s architekturou SOA a prozkoumat možnosti jejího využití jakožto principu komunikace mezi softwarovými celky. Následně pochopit základní požadavky na pokladní modul a na základě SOA pak navrhnout komunikaci pokladního modulu se skladovým systémem. Také je nutné zjistit informace o hardwaru, který by se dal využít pro usnadnění práce s výsledným programem a prozkoumat současnou legislativu, jak ovlivňuje chování prodejců při obchodní činnosti.

1

V druhé části této práce ze získaných informací vycházet při návrhu a implementaci pokladního modulu tak, aby umožňoval klientům využívat potřebných služeb skladového systému přes grafické rozhraní pokladny. Na závěr je nutné celé řešení otestovat.

1.3 Obsah práce První kapitola popisuje motivaci a základní cíle této práce, kterých se budu snažit v jejím průběhu dosáhnout. Představuje seznámení s celou prací a je zde popis jednotlivých kapitol a vysvětlení, co v nich lze nalézt. Druhá kapitola se věnuje platformě SOA. Obsahuje krátké seznámení s touto platformou, popis jejích principů a základní dělení podle vlastností. Jsou zde také zmíněny různé možnosti implementace komunikace mezi službami.Velká pozornost je věnována webovým službám, jakožto nejznámějšímu způsobu implementace SOA. Třetí kapitola se věnuje popisu pokladních modulů, současné legislativě a jejím omezením na obchodní činnost. Také je zde popis postupného vývoje pokladen s návazností na specifický hardware, jenž se postupně nasazuje pro usnadnění práce v této oblasti. Ve čtvrté kapitole je rozebráno několik konkurenčních produktů a popsány jejich rozdíly a nedostatky. Navíc pro ilustraci obsahuje obrázky grafického rozhraní těchto programů, aby bylo ukázáno, jak se obvykle u toho druhu softwaru řeší. Pátá kapitola je o analýze a návrhu pokladního modulu. Jsou v ní popsány požadavky na výsledný systém a rozebrány specifika architektury MVC. Také je zde zakresleno několik diagramů za pomoci UML. To slouží pro modelaci případů užití, diagramu nasazení a komponent. Pro osvětlení vnitřní struktury navrhovaného systému jsou zde také diagramy tříd. Šestá kapitola je o implementaci systému a postupech použitých pro jeho tvorbu. Jejich volba je zdůvodněna a je vysvětleno, k čemu přesně byly použity. Část kapitoly je také věnována obecnému rozvržení grafického rozhraní, kde se vycházelo zejména z dosavadního softwaru, na který jsou běžní zákazníci zvyklí. Sedmá kapitola se zaobírá testováním hotového systému a jeho návazností na různá prostředí. Také popisuje testování kompatibility s různými druhy hardwaru. Je zde také několik vybraných problémů, na které se během testování narazilo. Poslední kapitola obsahuje shrnutí práce. Je zde závěrečný popis dosažených výsledků a nastíněny možnosti, kam se vyvíjený program může posunout do budoucna. Také je tu uvedeno, jak na celé řešení pohlíží zadavatel práce a také klienti, u kterých byl již systém nasazen.

2

2. Platforma SOA V průběhu času se postupně mění nástroje pro návrh a implementaci softwaru a vytvářejí se stále nové a odlišné přístupy, jak k tomuto odvětví informatiky přistupovat a jak dosahovat vytyčených cílů. Vyvíjejí se nové jazyky a metodiky, jak je používat. Rovněž styl návrhu programových komponent a jejich interakce se postupně mění. V počátcích vývoje softwaru se k programům přistupovalo zejména jako k celkům, které nepředpokládaly komunikaci se softwarovým okolím. Systém byl navržen jako uzavřená jednotka, což se ukázalo jako nedostačující a s nástupem síťové komunikace jako neefektivní. Pokud jeden systém obsahuje data, která potřebuje ke svému zpracování systém jiný, je nutné je do druhého systému manuálně přenést. Proto je vhodnější, pokud jsou tyto komponenty schopné mezi sebou komunikovat a data si předávat sami. Pro potřeby integrace jednotlivých systémů a komunikace mezi nimi se ukázalo nutností navrhnout a udržovat princip, pomocí kterého si budou předávat informace a budou je sdílet se svým okolím. Nejedná se však pouze o předávání informací. V případě, že jedna softwarová komponenta obsahuje funkcionalitu, která je žádoucí i v jiné komponentě, je zbytečné, aby tato funkcionalita byla implementována v obou dvou. Na první pohled je daleko snadnější předávat pouze data, která jsou pro vykonání této funkce nezbytná a po jejím skončení zaslat zpět výsledek. Jednou z architektur, která řeší tento princip spolupráce mezi softwarovými celky je Service Oriented Architecture (dále jen "SOA"). S tou se v této kapitole seznámíme a popíšeme si její základní principy. Ty se v někdy zdají jako samozřejmé, avšak přesto se jim v některých případech nevěnuje dostatek pozornosti. Mnohé z této architektury je známé již delší dobu, avšak až s tím, že se software stává z logického hlediska síťový, je v poslední době SOA považováno za aktuální.

2.1 Principy SOA Servisně orientovaná architektura představuje virtuální peer2peer síť volně vázaných komponent, které spolupracují většinou předáváním zpráv. Je samozřejmě možná i implementace jiných druhů komunikace, nejčastěji se však jedná o asynchronní přístup. Komponenty bývají velké a jejich spolupráce se dá přirovnat ke spolupráci služeb z reálného světa [1]. Žádná přesná definice SOA ovšem neexistuje, jedná se pouze o způsob spolupráce softwarových celků při procesu jejich integrace. Navíc zahrnuje poměrně velkou třídu technologií a přístupů. Často však bývá termín SOA zaměňován s pojmem Web Services (webové služby). Ačkoliv spolu tyto dva termíny souvisí, nejedná se o totéž. Webové služby představují implementační technologii, pomocí níž je možné vystavět software na principech SOA.

3

Základy servisně orientované architektury znázorňuje následující obrázek. V pravé části je zachycen uživatel služby, jenž odesílá požadavek na službu poskytovateli této služby, který následně odesílá odpověď zpět. Spojení s požadavkem a odpovědí jsou předem definovaná a oboum stranám srozumitelná.

Obrázek 2.1: Znázornění komunikace se službou [2]

Propojením více služeb dohromady mohou vznikat i velice rozsáhlé sítě služeb. Tento princip návrhu systémů umožňuje dosáhnout několika cílů: • • • • • •

Snížit náklady jak na vývoj, tak na integraci aplikací. Díky opětovné použitelnosti služeb dále zefektivnit vývoj nebo integraci aplikací. Relativně rychle a snadno otevřít a zhodnotit původní (legacy) aplikace. Zprůhlednit a zjednodušit správu a řízení informačních systémů a nedělat tak věci složitější, než ve skutečnosti jsou. Rychle adoptovat změny, protože změna je atributem architektury SOA, ne nečekanou výjimkou, při níž se typicky mění jen metadata, nikoli zdrojové kódy služeb. Podnikat v reálném čase [3].

Naopak přistoupit k použití SOA není vhodné úplně vždy, protože s sebou přináší i určitá rizika. Jedním z nich je nutnost sledovat a řídit celou architekturu jako celek. Je zapotřebí kontrolovat a sledovat jednotlivé služby, jejich výkon, spolehlivost a hlavně bezpečnost, protože jinak může toto řešení být velice neefektivní. Taktéž pokud nám záleží na opětovné použitelnosti služeb, je nutné jejich návrh dobře promýšlet a zvažovat, kam se požadavky na službu mohou posunout do budoucna, což není vůbec snadné [4].

2.2 Dělení SOA Jak již bylo zmíněno, existuje několik způsobů využití SOA, které se od sebe mohou značně lišit. V této části kapitoly je postupně popsáno, podle jakých kriterií je možné SOA rozlišovat a podle kterých hledisek se dá rozdělit do několika kategorií. Jedním z možných dělení SOA je dělení podle rychlosti odezvy jednotlivých komponent. Používá se termínů jako "Soft real time" a "Hard real time", kde prvních z nich označuje

4

komunikaci, u níž se odpověd na požadavek očekává v krátkém časovém intervalu. Avšak vyjímečné drobné zpoždění nepředstavuje problém, pouze nepříjemnost. Druhý termín naopak označuje spolupráci, kde odpovědi musí být dostupné bez zpoždění. Dalším kritériem dělení může být například míra propojení služeb. Jsou zažité dva pojmy pro označování typu spolupráce služeb. První z nich je termín konfederace, který bývá užíván pro označení volnějšího typu sdružení. Jeho opakem je aliance. Speciálním případem je unie, obvykle označující jádra systémů, jejíž učastníci jsou velké komponenty a vzájemně se znají. Pak lze snadno dohodnout uživatelsky příjemné rozhraní služeb i celého systému [1]. S tímto druhem dělení souvisí i další parametry, jako je předpoklad, zda se služby, které jsou partnery v komunikaci, musí navzájem vyhledávat. To bývá obvyklé u aliancí například v e-komerci nebo u reservačních systémů a je zde nutné využití standardů. Naopak u konfederací se předpokládá, že komponenty o sobě dopředu vědí a mohou proto používat i vlastní nestandardní systém komunikace. Dále je také možné dělení podle toho, zda služby komunikují klasicky pomocí zpráv přímo mezi sebou nebo zda v případě konfederací využívají prostředníka například v podobě datového úložiště.

2.3 Referenční model SOA Pod pojmem referenční model je možné si představit abstraktní rámec zachycující významné vztahy mezi jednotlivými subjekty v daném prostředí. Umožňuje tak vývoj architektury za pomocí standardů a specifikací bez zbytečné návaznosti na technologie, implementaci nebo jiné konkrétní detaily. Úkolem referenčního modelu SOA je tedy definovat podstatu servisně orientované architektury, definovat používané pojmy a popsat běžné chápání SOA. Poskytuje tak normativní obraz, který je relevantní pro SOA jako abstraktní model bez ohledu na rozdílný a nevyhnutelný vývoj technologií, které ovlivňují nasazení SOA [5]. Následující obrázek ilustruje, jakou návaznost má referenční model na další prvky distribuovaných systémů. Koncepty a vztahy definované referenčním modelem by měly být základem pro popis referenčních architektur, které definují specifičtější kategorie návrhu SOA. Konkrétní architektury vyplívají z kombinace referenční architektury, architektonických vzorů a dalších požadavků, včetně technologického prostředí. Architektura musí odpovídat cílům, motivacím a požadavkům na řešení konkrétního problému. Zatímco referenční architektury mohou tvořit několik základních tříd řešení, tak konkrétní architektury definují specifické přístupy k řešení. Architektura je často vyvíjena v rámci předdefinovaného prostředí, kterým jsou relevantní zvolené protokoly, specifikace a standarty. Implementace SOA spojuje všechny tyto prvky od obecnějších principů architektury až na specifika, které definují aktuální potřeby a představují konkrétní implementace, které budou vytvořeny a používány v provozním prostředí.

5

Obrázek 2.2: Návaznost na referenční model [5] Konkrétních referenčních modelů je ovšem celá řada, protože množství analytických a softwarových společností si vytváří vlastní referenční modely SOA. Velká řada vývojářů však vychází z referenčního modelu CBDI. Firma CBDI Forum je nezávislá analytická společnost, která je autorem tohoto referenčního modelu. Referenční modely představované dalšími softwarovými dodavateli se od tohoto modelu většinou příliš neliší. Proto je zde také představen jako vzorový referenční model. Jeho hlavní myšlenka je oddělení od sebe několika vrstev s důrazem na to, že vrstvy služeb, aplikací a technologií představují oddělené fyzické vrstvy, zatímco vrstva obchodních procesů představuje vrstvu konceptuální.

Obrázek 2.3: Referenční model CBDI [3]

6

2.4 Implementace SOA Servisně orientovanou architekturu lze implementovat využitím několika rozdílných technologií. V rámci těchto technologií existují různé varianty řešení v závislosti na konkrétních využitých standardech a protokolech. V této podkapitole bych rád upozornil na některé z nich a popsal jejich základní vlastnosti. Předmětem této práce však není detailní zkoumání implementací služeb, ale cílem je zaměřit se na analýzu a návrh budoucího pokladního modulu tak, aby bylo umožněno využití libovolné z těchto specifikací. Proto zde nebudou dále rozebírány a porovnávány standardy webových služeb, ale během celého procesu tvorby této práce bude brán ohled na servisně orientovanou architekturu a vše bude vytvářeno tak, aby po skončení této práce bylo možné libovolnou z těchto implementací sloučit s pokladním modulem podle toho, jak se rozhodne zadavatel práce.

2.4.1 Možnosti implementace služeb Při řešení otázky, jakým způsobem spolu mohou služby komunikovat, lze tyto přístupy rozdělit do několika různých kategorií, podle toho, na jakých technologiích bude tato komunikace vystavěna. Mezi nejobvyklejší patří tyto tři [6]: • Platformně závislá volání. Například pro platformu Java lze využít Remote Method Invocation (RMI), Sockety, Servlety nebo JMS. • Pomocí middlewaru zaměřeného na distribuovanou komunikaci. Například CORBA nebo DCOM. • Na základě textově orientovaného komunikačního protokolu. Tím je myšleno zasílání požadavků a odpovědí v textové formě, což je princip Web Services. První způsob je velice přímočarý, ale má několik nedostatků. Je úzce svázán s daným jazykem nebo platformou, protože jak poskytovatel tak uživatel služby musí být vystavěny na stejné technologii, jako jsou například Java nebo .NET. Navíc je problém s třídami, které se používají pro přenos dat, protože musí na obou stranách komunikace být jejich totožné verze. Využití middlewaru zaměřeného na distribuovanou komunikaci je považováno za dobré řešení. Konkrétně CORBA se díky své meziplatformnosti do dnešní doby využívala docela často [6]. Poslední možnost v podobě textově orientované komunikace s sebou přináší nutnost na jedné straně data transformovat do textové reprezentace, na druhé straně komunikace opět z textu do objektové podoby. Totéž se děje v obou směrech komunikace, jak při zasílání požadavku, tak při posílání odpovědi. Tento proces serializace a deserializace může na první pohled vypadat jako zbytečná složitost pro návrh principu komunikace. Znamená ale naprostou nezávislost na použitých technologiích obou partnerů komunikace a velice volnou vazbu mezi nimi. Nejpřirozenější cestou,

7

jak data ukládat v textové formě s pomocí XML, tak jak se to děje v případě využití webových služeb. V následující částí teto kapitoly se blíže seznámíme s některými nejznámějšími způsoby implementace SOA a popíšeme si, k čemu slouží a jak se dají využít. Některé z nich jsou navíc kompatibilní mezi sebou a dají se vzájemně propojovat.

2.4.2 Remote Method Invocation Remote Method Invocation je technologie, umožňující programátorům vytvářet distribuované systémy založené na jazyce Java, ve kterých je možné metody a objekty z jednoho virtuálního stroje (Java virtual machine) využívat i vzdáleně na jiném virtuálním stroji. Ten může navíc běžet i na jiném počítači. RMI používá serializaci objektů pro uspořádání parametrů a zachovává typy, takže poskytuje možnost objektové komunikace. Tento komunikační nástroj je součástí Java SE od verze Java SDK 1.1 a pro Javu ME je dostupný jako samostatně stáhnutelný balík. Navíc novější verze jsou kompatibilní i se systémem CORBA [X1].

2.4.3 Web Services Web Services představují neznámější implementaci architektury SOA. Jedná se o kolekci standardů, pomocí kterých jednotlivé služby komunikují. Základem předávaných zpráv bývá Extensible Markup Language (XML) a jako přenosové médium se používá protokol Hypertext Transfer Protokol (HTTP). XML navíc bylo už od svých počátků konsorciem W3C navrhováno jako formát pro výměnu dat a jeho schopnost tohoto cíle dosáhnout byla již časem prokázána. Jeho základní vlastnosti, které představují značné výhody jsou strukturovatelnost, přenositelnost, rozšiřovatelnost a textový formát. Na to navazuje Web Services Definition Language (WSDL) pro popis rozhraní služeb, protokol Simple Object Access Protocol (SOAP), který je nadstavbou HTTP právě pro předávání dat jednotlivých služeb a Universal Description, Discovery and Integration (UDDI), což je standart pro registrování a vyhledávání služeb. SOAP navíc nabízí množství funkcí, které usnadňují implementaci služeb. Jedná se například o možnost automatizovat některé činnosti, které by jinak zabraly spoustu času. Tím může být třeba generování tříd používaných pro přenos dat nebo tříd na uchovávání dat na straně klienta. Využít se dá také schopnost automaticky vytvořit popis služby za pomoci WSDL. Co se týče samotné komunikace, nabízí i jiné možnosti přenosu než jen protokol HTTP, ale také třeba SMTP. Dokáže také navázat stavovou komunikaci a myslí dokonce i na zabezpečení. Během let však vzniklo několik různých specifikací webových služeb od různých firem a organizací. Jejich názvy obvykle začínají na WS. Je několik málo nízkoúrovňových specifikací pro XML a HTTP, na které navazuje mnohem větší počet specifikací webových služeb jako celku. Jedná se například o specifikace podle W3C, OASIS, Web Services Interoperability Organization

8

(WS-I). Pokrývají rozsáhlou oblast od samotného vzdáleného volání služeb, zabezpečení, správu transakcí, spolehlivost a řešení chyb až po adresování [8].

Obrázek 2.4: Použití webových služeb [9]

9

3. Pokladní systémy Vývoj pokladních systémů sahá hlouběji do minulosti, ačkoliv k jejich velkému rozšíření i mezi menší prodejce dochází spíše až postupně v posledních letech. Během těchto let vývoje se časem ustanovily určité zažité vlastnosti a procesy, které je možné s tímto typem softwaru vykonávat. Naproti tomu jsou ale také určité specifické požadavky, které může mít každý zákazník naprosto odlišné. Toto je popsáno v první části této kapitoly, zatímco její zbytek je věnován návaznosti na hardware a sledování postupného vývoje pokladen podle toho, s kterým hardwarem byly během let propojovány.

3.1 Vlastnosti pokladních systémů Velké množství představ a požadavků závisí na společnosti, která pokladnu chce používat. Zejména se rozchází představy o funkcionalitě v restauračních zařízeních a v klasických obchodech. Zmíněny zde budou představy obou možných nasazení pokladního modulu, přestože další části už budou zaměřeny hlavně na nasazení v restauračních zařízeních. Základní myšlenka pokladního modulu je taková, že má umožňovat zaměstnancům manipulaci se zbožím, které bylo naskladněno a zpracováno nějakým skladovým systémem. O tuto část procesu manipulace se zbožím se pokladní moduly nestarají, přistupují k již nachystanému zboží. Naopak nejčastější činností uživatelů na pokladních modulech je uskutečňování prodejů zboží a vystavování dokladů o koupi. Pokladní modul proto musí mít možnost získávat informace o aktuální nabídce zboží a toto zboží zaznamenávat na právě probíhající prodej. Produkty by mělo být možno zadávat několika způsoby, jak pomocí postupného výběru z kategorií, tak přímo zadáním kódu zboží. Následně vytisknout pokladní účtenku jako doklad pro zákazníka a zboží odečíst ze skladu. Po ukončení pracovní směny prodavačů odpovědní vedoucí chtějí mít možnost rekapitulovat jejich práci za časový interval. K tomu slouží tzv. uzávěrky, tedy celkový přehled všech činností s časem a jménem osoby. Existují však i další úkony, které prodávající v některých specifických případech provádí. Tím je například vracení již prodaného zboží zpět na sklad. To je nutné v případě, že si zákazník z nějakého důvodu koupi rozmyslí a požádá o vrácení peněz. Tento požadavek není častý, ale občas se objeví a za účelem co největší spokojenosti zákazníka je mu obvykle vyhověno. Stejně tak manipulace s penězi není pouze na základě pohybu zboží. Z různých příčin je někdy nutné odvést z pokladny hotovost a tu předat třetí osobě. Zde se jedná například o vyplácení záloh prodavačkám. I toto je zapotřebí zaznamenávat, aby výsledná hotovost odpovídala a neztrácely se finance. Zajímavou možnosti pro počítání hotovosti je nástroj na snadný výpočet celkové částky z různých mincí a bankovek, protože ruční počítání a násobení je nepraktické a dají se při něm lehce udělat chyby. K tomu souží výčetky, na kterých jsou rozepsané všechny druhy mincí a bankovek dané měny a výsledek sloužící k porovnání se skutečným stavem, který je aktuálně v kase.

10

Všechny tyto činnosti je nutné zaznamenávat a tisknout k nim doklady pro fyzické doložení. Stejně tak je mnoho z nich přímo navázáno na skladový systém a vyvstává tak problém vzájemné komunikace mezi oběma moduly aplikace. V neposlední řadě je také vhodné, aby modul měl nějaké řízení uživatelů, aby bylo později dohledatelné, která osoba kdy provedla jaké operace. Pokud je pokladní systém využíván v restauračních zařízeních, je navíc doplňován a nákres restaurace s rozdělením do několika částí. Buď podle místností, nebo přímo jednotlivých stolů na které jsou účty vázány. Důležitým požadavkem je také možnost účty rozdělovat do několika menších, pokud se zákazníci rozhodnou platit po částech každý za své zboží. Naopak je ale zapotřebí mít možnost více účtů slučovat do jednoho, pokud se více zákazníků dohodne platit společně. Na druhou stranu pokladny v restauracích nevyžadují některé ze specifických požadavků, které byly zmíněny výše. Ty se objevují hlavně u softwaru nasazeného v klasických obchodech. Závěrem je také nutné zmínit, že na základě dlouhodobé komunikace s klienty je patrné, že téměř každý má určité naprosto specifické požadavky, které úplně vybočují od výše zmíněných. V těchto případech záleží na konkrétním dodavateli, zda a za jakých podmínek se rozhodne upravovat tento typ softwaru jednotlivým koncovým zákazníkům a potom se i vlastnosti dodávaného pokladního modulu mohou značně odlišovat kus od kusu.

3.2 Hardware Pokladní systémy také prošly jistým vývojem, který se dá dobře monitorovat podle množství a druhu doplňujícího hardwaru. Ten se využívá pro zjednodušení a zrychlení práce obsluhujícího personálu, nebo pro přesnější sledování jeho činnosti ze strany nadřízených a majitelů podniků. Proto se alespoň některé z těchto zařízení používají téměř vždy a jsou považovány za jistý základ hardwarové výbavy pro použití pokladního softwaru. Postupem let však dochází k rozšiřování možností a s příchodem nových technologií se přidávají další a další části vybavení. V některých případech se tak stává, že množství periferií je docela velké. Za základní hardware, který bývá přítomen ve velkém množství případů a navíc je používán již řadu let, patří zajisté tiskárny. Pokladní software potřebuje mít možnost k prodejům vystavovat papírové doklady, takže se téměř vždy využívají alespoň jehličkové tiskárny schopné tyto doklady vytisknout. Díky tomu je tvorba paragonů a dalších dokumentů velice usnadněna a urychlena. Často také bývá využito skutečnosti, že velké množství zboží je již z výroby opatřeno čárovými kódy. Proto mezi jedno z prvních hardwarových zařízení, které se s pokladními systémy používá již delší dobu, patří různé druhy čteček čárových kódů. Tím došlo ke zrychlení identifikace zboží a vytváření seznamu zboží na prodej. Posledním druhem hardwaru, který je velice častý, jsou elektronické kasy. Tedy jakési zásuvky na peníze, které se po skončení prodeje samy otevřou a jiným způsobem by je nemělo být možné otevřít. Existuje však spousta dalších druhů hardwaru, jenž se využívá až v poslední době díky příchodu a rozšíření nejnovějších technologií. Typickým příkladem mohou být dotykové obrazovky. Ty jsou náhradou za jiná ovládací zařízení, jako je klávesnice a myš. Jejich cena postupně klesá a díky tomu je jejich nasazení stále častější. Navíc zjednodušení a zpříjemnění práce

11

s pokladnou je opravdu znatelné. Zajímavou možností je také využití elektronických vah a jiných měrných zařízení pro pohodlnější a rychlejší zjištění množství prodávaného zboží, protože ne vše se prodává pouze po kuse. U různých druhů produktů je důležitým ukazatelem váha nebo objem. V provozech, kde se během jedné pracovní směny střídá větší množství lidí a je vhodné evidovat činnost každého z nich zvlášť není příliš praktické, aby se přihlašovali a odhlašovali pomocí ručního psaní svých přihlašovacích jmen a hesel. Pak přichází na řadu výhody identifikačních čipů v různých podobách. Je samozřejmě možné je využít i pro rozlišování zboží nebo čehokoliv dalšího. Dá se předpokládat, že v určitých specifických prodejnách je vhodné použít i další druhy hardwaru. Stejně tak je velice pravděpodobné, že do budoucnosti se množství hardwaru vhodného pro prodejní činnost ještě rozšíří. V poslední době se například objevují automatické pokladny, které už naprosto zastupují veškerou lidskou činnost, ale jejich rozšíření je zatím minimální. Veškerý výše uvedený hardware bude v následující části kapitoly představen, bude podrobněji vysvětleno jeho využití, výhody a nevýhody, případně zmíněny technické detaily, které mohou mít vliv na tvorbu pokladního modulu.

3.2.1 Tiskárny Pro zjednodušené pokladní doklady se používají tiskárny s úzkým papírem o šířce kolem 60 až 80mm. Technologicky jsou hojně zastoupeny jehličkové a tepelné tiskárny, ale existují i jiné. Přestože se jedná o docela malý kus hardwaru, jejich cena nebývá nejnižší, hlavně u nejmodernějších tiskáren, které mají možnost i barevného tisku. Často se proto zachovávají starší kusy s dnes už zastaralými rozhraními jako je LPT, což může způsobovat komplikace při zapojování do PC, které nejsou tímto portem vybaveny. Existují sice redukce, ale ani jejich využití není bez komplikací. Novější typy bývají připojovány nejčastěji přes USB port. Stejně tak se tiskárny liší podle druhu tisknutelných formátů. U starších tiskáren se obvykle tisk provádí pouze odesláním textového řetězce na port tiskárny. Text tak sám o sobě je neformátovaný, bez možnosti změny velikosti písma nebo jiných úprav fontů. Kvůli tomuto omezení se používají speciální řídící znaky, které se odesílají jako součást tisknutého textu a tiskárna při jejich načtení dokáže změnit písmo použité při tisku odpovídajícím způsobem. Například při tisku za pomoci tiskárny Star SP212 je řídící znak "\u000E" použit pro zvětšení písma [10]. V kódování Unicode je tento znak známý jako "SHIFT-OUT" [11]. Pro tisk běžných daňových dokladů na papír velikosti A4 se používají klasické tiskárny. Ty najdou uplatnění i při tisku vlastních etiket na zboží případně čárových kódů, protože ne vždy je zboží čárovým kódem opatřeno už od dodavatele.

12

Obrázek 3.1: Pokladní tiskárna Epson [12]

3.2.2 Čtečky čárových kódů V mnoha odvětvích prodeje se pro identifikaci zboží využívá čárových kódů. K jejich snímání existují čtečky schopné zasílat do PC sekvenci čísel ukončenou potvrzením klávesy Enter. Mezi čtečkami jsou značné rozdíly co se funkcionality týče, avšak komunikace se pokladními systémy je na stejném principu. Dají se rozdělit podle způsobu snímání, protože některé pro přečtení kódu vyžadují relativně přesné zaměření snímacího paprsku, jiné naopak dokáží čárový kód rozpoznat pod více úhly. Ruční snímače bývají opatřeny spínačem, bez jehož zmáčknutí a držení snímání neprobíhá. Zabudované čtečky používané například v supermarketech snímají průběžně. Rozhraní pro komunikaci s PC je v dnešní době obvykle USB, existují však i přístroje vybavené jinými porty. Samotné čárové kódy jsou mnoha druhů. Základní rozdělení je na 1D (jednodimenzionální) a 2D (dvoudimenzionální). Následně je ke každému z těchto druhů dostupných několik specifikací, které popisují jednotlivé typy čárových kódů. Nejznámější a nejpoužívanější jsou EAN 13 a EAN 8. Mezi další docela známé patří UCC/EAN128, který je schopen kódovat delší sekvenci čísel, CODE128 navržený pro alfanumerické znaky nebo CODE39 používaný ve zdravotnictví a automobilovém průmyslu. Všechny zmiňované patří mezi jednorozměrné čárové kódy. Mezi ty dvourozměrné řadíme PDF417, což je kód s vysokou informační hodnotou navíc schopný detekce a opravy chyb. Známý a rozšířený je také DATAMATRIX představující maticový kód [13]. Každý z těchto typů čárových kódů je popsán ve své specifikaci, kde například pro nejznámější a nejpoužívanější EAN13 a EAN18 je to ISO/IEC 15420:2009 [14]. Samotná technologie snímání je založena na principu laserového paprsku, který je namířen na čárový kód. Tam kde dopadne na černou čáru je pohlcen, v mezerách se odráží zpět a je snímán. Například u EAN 13 a EAN8 jsou pomocí čar a mezer zakódovány čísla od 0 do 9, přičemž každá číslice je reprezentována dvěma čarami a dvěma mezerami. EAN13 obsahuje 13 číslic a EAN8 jich má v sobě 8. Navíc se dodržují standarty pro význam číslic. První dvě nebo tři čísla označují stát

13

původu zboží, další 4 až 6 číslic je pro identifikaci výrobce, poslední cifra je kontrolní a zbytek mezi tím je číslo výrobku.

Obrázek 3.2: Ukázka čtečky a čárových kódů [13] a [15]

3.2.3 Dotykové obrazovky Jako vstupní zařízení lze využít dotykové obrazovky, které velice urychlují práci se softwarem, pokud je na to připraven. Je nutné na to pamatovat při návrhu grafického rozhraní pokladny, aby se dalo upustit od klasických vstupních zařízení v podobě klávesnice a myši. Jejich cena se postupně snižuje a stávají se stále více dostupnými. Pro komunikaci se také obvykle využívá USB rozhraní.

3.2.4 Váhy a jiná měrná zařízení V případě vah se jedná o specializovaný hardware, využívaný v rozdílných typech prodejní činnosti. Ne vždy se zboží prodává pouze po kusech, ale měrnou jednotkou může být i objem nebo váha. To je obvyklé například v restauračních zařízeních, kde se prodávané tekutiny odměřují pomocí nádob. Je však možné evidovat hustotu jednotlivých druhů nápojů a za pomoci elektronických vah automatizovat prodej nebo inventurizaci zásob. Váhy a další měrná zařízení však najdou své uplatnění i v mnoha jiných odvětvích, kde se prodávaný artikl neurčuje podle kusů. Nasazení tohoto druhu vstupního zařízení však vyžaduje modifikaci pokladního systému, aby byl schopen s příslušným hardwarem spolupracovat.

14

3.2.5 Čipy pro identifikaci osob nebo zboží Různé druhy čipů se dají využít pro zautomatizování identifikace osob, které se systémem pracují. Každá osoba má vlastní čip a před započetím práce se systémem se pomocí něj přihlašuje. Obdobný postup je možný i pro identifikaci prodávaného zboží. Navíc je díky této automatizované identifikaci předmětů a osob možné zaznamenávat množství údajů, které by se jinak získávaly obtížně a na jejich základě vytvářet různé statistiky a získávat z nich dodatečné informace na principech data miningu, tedy analytické metodologie získávání netriviálních, skrytých a potenciálně užitečných informací z dat [16]. Informace bývají často užívány v oblasti marketingu. Jednou z obvyklých úloh, je potřeba modelování odezvy marketingové kampaně nebo také analýza nákupního košíku. Ta má za úkol sledovat vztahy mezi nakupovaným zbožím. Hledají se pravidla o tom, co si zákazníci nejčastěji kupují s jedním vybraným druhem zboží. Na základě výsledků se pak na toto zboží dělají různé akce a očekává se nárůst zájmu i u ostatních produktů s tímto produktem nejčastěji kupovaných. Smyslem je ušetřit za reklamu a vydělat na nákupech [17].

3.2.6 Pokladní zásuvky Finanční hotovost se může uchovávat v elektronické zásuvce, která je otevírána po skončení prodeje přímo pokladním systémem. Kasa bývá vybavena i mechanickým zámkem, aby bylo možné se k hotovosti dostat v případě potřeby i jinak, například při vypnutém systému nebo dokonce výpadku elektrického napájení. Zámek naopak zabraňuje neoprávněným osobám se do zásuvky dostat.

15

4. Analýza současného stavu Navrhovaný pokladní systém bude v mnoha ohledech ovlivněn svým okolím, ať už v podobě konkurenčních programů nebo aktuálních zákonů. V této kapitole budou tyto vlivy rozebrány a nastíněn jejich dopad na návrh systému. Ve složitějších případech budou uvedeny odkazy na další materiály, kde je možné v případě zájmu získat doplňující podrobnosti.

4.1 Legislativa České zákony v mnoha ohledech ovlivňují a omezují možnosti obchodní činnosti a prodeje zboží zákazníkům. Zasahují do velké části tohoto procesu a to od způsobu vytváření prodejních dokladů až po oceňování zboží. Taktéž bývá prodej zatížen daní a její výpočet není triviální. Nejčastější daní, která se na obchodní činnost vztahuje je daň z přidané hodnoty (dále jen "DPH"). Jedná se o nejsložitější nepřímou daň našeho daňového systému, kterou platí obyvatelé této země ve většině nakupovaného zboží, odvádí ji však prodejci. Tomuto tématu se věnuje Zákon č. 235/2004 Sb., o dani z přidané hodnoty. Daň se uplatňuje na zboží, nemovitosti a služby za podmínek stanovených tímto zákonem. Je zde také v §37 až 41 uvedeno, jak se počítá základ daně, tedy placená částka po odečtení DPH. V současné době existují navíc dvě různé sazby DPH a to sazby základní a snížená, které jsou stanoveny na 10% a 20%. Podle aktuálních informací je však možné, že na základě plánů nynější vlády budou tyto sazby sjednoceny. Zákon o dani z přidané hodnoty z tohoto důvodu obsahuje přílohy, ve kterých je výčtem specifikováno, na jaké zboží a služby se uplatňuje snížená daň. První příloha je seznamem zboží, druhá se věnuje službám. Existují také vyjímky, které jsou od DPH úplně osvobozeny. Jejich výčet se nachází v §52 až 62. Jedná se například o poštovní služby, zdravotnické služby a zboží, vzdělávání a další. Důležitou roli hraje také vystavování daňových dokladů. I ty jsou ve dvojím provedení, kdy pro částky nad 10000 Kč je nutné vystavit běžný daňový doklad. V opačném případě je možné použít zjednodušený daňový doklad. Pro oba jsou specifikovány položky, které na nich musí být uvedeny. Zajímavostí související s platbou DPH je elektronický systém pro výměnu informací v oblasti DPH pod názvem VIES. Název je zkratkou z VAT Information Exchange System. Tento evropský systém umožňuje správcům daně států Evropské unie ověřit, zda prodávající měl právo osvobodit se od zdanitelného plnění, a naopak v zemi určení zkontrolovat, zda kupující nabyté zboží řádně přiznal a zdanil [18]. Další podrobnější informace je možné čerpat přímo z tohoto zákona, avšak na tomto místě mu již nebude věnován další prostor. Jeho znění bude bráno na vědomí během celého dalšího procesu tvorby pokladního systému. Zákon je možné získat na Portálu veřejné správy české republiky [19]. Za zmínku určitě také stojí Zákon č. 215/2005 Sb., o registračních pokladnách. Tento zákon ze dne 3. 5. 2005 byl později s platností od 1.1.2008 zrušen.

16

4.2 Konkurence Na trhu je v dnešní době vícero různých druhů softwaru využívaného při obchodní činnosti. Nemusí se jednat vždy jen o pokladní systémy, ale například i o skladové systémy, často propojené s účetním softwarem nebo i webovými stránkami například v podobě elektronického obchodu. Běžné je také rozdělení nabízeného softwaru podle cílového zákazníka do několika druhů balíků. V této podkapitole je zmíněno několik z nich a k čemu se dají využít. Na závěr je uvedeno vysvětlení, proč jejich využití pro tuto práci nebylo vhodné.

4.2.1 Winshop - APLS Praha s.r.o Společnost APLS Praha s.r.o patří mezi největší české dodavatele informačních systémů pro řízení maloobchodních organizací a od roku 1995 se zabývá výhradně dodávkou a vývojem pokladních systémů pro obchody a restaurace [20]. V jejím sortimentu najdeme několik řad systému WinShop lišících se nabízenými funkcemi a přístupem k ukládání dat. Software obsahuje i pokladní modul, který jako jednu z alternativ nabízí zobrazení pro dotykové obrazovky. Umožňuje vytvářet a evidovat prodeje, rozlišuje různé typy plateb a shromažďuje podklady o tržbách a DPH. Veškeré operace jsou monitorovány a je možné je zpětně zdokumentovat. Mimo to je možné využít i rozhraní pro restaurace, které navíc přidává vybírání stolů a další funkce běžné v restauračním provozu.

Obrázek 4.1: Program Winshop [20]

17

Jedná se o dlouho vyvíjený software od firmy, která má za sebou spoustu let zkušeností, čemuž samozřejmě odpovídá i cena. Problém by byl také pokud by pokladní modul měl komunikovat s jiným skladovým systémem, než s tím, který je součástí oficiálního balíku.

4.2.2 Awis - A.W.I.S. Správa, systémy s.r.o. Pokladní systém Awis od firmy A.W.I.S. Správa, systémy s.r.o. je taktéž již řadu let vyvíjeným softwarem. Tato firma se zabývá nejen vývojem a prodejem tohoto programu, ale i dodáváním souvisejícího hardwaru a jeho zprovozněním. Pokladní modul nabízí mimo standardních funkcí jakými jsou prodej a evidence stolů navíc i další funkcionalitu. Tou je například rozvážkový systém, recepce, přehled směn, docházka zaměstnanců nebo statistiky. Jeho nevýhodou je ovšem zásadní orientace na restaurace, hotely a další druhy pohostinských zařízení [21].

Obrázek 4.2: Program Awis [21]

4.2.3 Fusion - iTechnologies s.r.o. Dalším pokladním systémem je program Fusion od společnosti iTechnologies s.r.o., který je opět zaměřený na prodej v restauračních zařízeních. Přesto nabízí mnoho zajímavých funkcí, jakými jsou evidence zboží a receptur, docházky nebo pravidelné slevy. Systém se spouští v internetovém prohlížeči a jsou tedy možné různé problémy s kompatibilitou [22] . Na druhou stranu firma nabízí i verzi pro přenosná dotyková zařízení iPod Touch a iPhone.

18

Obrázek 4.3: Program Fusion na přenosném zařízení [22]

4.2.4 Shrnutí Přestože konkurenční pokladní moduly jsou v některých případech značně propracované a jejich vývojáři mají za sebou roky zkušeností s návrhem tohoto typu softwaru. Jejich využití pro již fungující skladový systém by bylo problematické. Pokladní softwary jsou obvykle součástí většího balíku a jsou přímo napojeny na vlastní sklady nebo databáze. Stejně tak pokud by měly pracovat s nějakým nově vyvinutým a specializovaným hardwarem, jako například vlastní implementací váhového systému, bylo by toto spojení zřejmě problematické.

19

5. Analýza a návrh Před započetím návrhu pokladního modulu bylo nutné specifikovat požadavky, které má práce splňovat. Za tímto účelem bylo dotázáno několik klientů firmy EtosComp ohledně jejich představ a ty byly porovnány s dalšími pokladními systémy, které jsou v dnešní době dostupné. Na základě těchto informací vznikla analýza a návrh budoucího pokladního modulu.

5.1 Specifikace požadavků Firma EtosComp skladový systém vyvíjena jako krabicový software, ale už od počátku vývoje byli někteří klienti, jejichž představy umožňovaly si udělat přehled o tom, jaké jsou pravděpodobné požadavky i budoucích zákazníků. V průběhu návrhu a implementace jim byly představovány průběžné výsledky k nahlédnutí a komentářům. Před začátkem návrhu pokladního modulu je nutné specifikovat funkční a nefunkční požadavky na systém. Jak bude daných požadavků dosaženo zatím není podstatné, to se bude řešit až v dalších částech práce.

5.1.1 Funkční požadavky Většina funkčních požadavků na pokladní modul byla sestavena na základě rozhovorů s koncovými zákazníky, kterým se jednotlivé návrhy předkládaly ke schválení a komentářům. Zároveň na specifikaci požadavků měla vliv i firma EtosComp. Základním požadavkem bylo zaznamenávání pohybu zboží a financí a veškeré manipulace s nimi, které provádí prodávající osoba jakožto zaměstnanec klienta. To začíná od spuštění pokladny, kdy se jednotlivý prodavači autorizují. Následně je modul připraven k použití s libovolnou činností, kterou má tato osoba v popisu práce. Nejčastěji se jedná o evidenci prodejů zboží, které si zákazníci vybírají osobně v prodejně. Prodavač toto zboží musí nalézt v evidenci a vybrat ho do prodeje. Nejběžnější způsob je pomocí čtečky čárových kódů či PLU kódů, což jsou jednoznačná čísla přiřazená každému artiklu. Pokud není tento způsob možný, je nutné procházet kompletní seznam zboží a konkrétní výběr provést ručně. Jednou přidané produkty je také možné z prodeje odstraňovat nebo upravovat jejich množství. Veškeré zboží z různých důvodů také může být zlevněno a i toto by měl systém zaznamenávat. Nakonec mohou také zákazníci využívat různých slevových kupónů a částka za celý prodej tak může být procentuálně upravena. Všechny tyto modifikace prodeje systém bude evidovat a poskytovat uživatelům příslušnou funkcionalitu. Závěrem bude systém automaticky tisknout papírový doklad pro zákazníka ve formě paragonu. Jednotlivé prodeje budou vázané na části prodejny, jako jsou místnosti nebo stoly a bude možné je před ukončením prodeje slučovat nebo rozdělovat podle aktuálních potřeb.

20

Před ukončením pracovní doby zaměstnance bude po zadání požadavku uzavřena veškerá manipulace se zbožím a vytištěn souhrnný výpis obsahující všechny výše zmiňované položky a znemožněno prodávajícímu dále manipulovat s produkty ze skladu. Až po skončení všech předchozích aktivit a po odhlášení ze systému lze pokladní modul vypnout, aby se předešlo nechtěnému ukončení v průběhu práce. Grafické rozhraní bude navrženo s ohledem na možnost využití pouze dotykové obrazovky bez jakýchkoliv dalších periferních ovládacích zařízení. Proto kdekoliv, kde bude možné zadávat textové nebo číselné vstupy musí být zobrazen dialog s obrazovkovou klávesnicí simulující klávesnici skutečnou. Co se týče komunikace mezi pokladnou a skladem, systém bude využívat mechanismu vzdáleného využívání služeb skladové části podle architektury SOA. Tím bude zabezpečena co největší modularita systému jako celku. Pokladna tak bude nezávislá a více modifikovatelná a za předpokladu nezměnění rozhraní ji nebude nutné uvažovat při úpravách skladu. Taktéž data poskytované skladem bude pokladna zpracovávat nezávisle a až po předání službám skladu budou převedena do formy využitelné databází.

5.1.2 Nefunkční požadavky Jako další část byly stanoveny nefunkční požadavky, tedy ty, které nesouvisí přímo s chováním systému, ale specifikují vlastnosti nebo omezující podmínky systému. •

Pokladní modul bude používán na osobních a přenosných počítačích s různými druhy a verzemi operačních systému, jak na systémech firmy Microsoft od verze XP a vyšších, tak na různých distribucích jiných systémů.

•

Pro ukládání dat bude využito skladového systému a jeho napojení na databázi.

•

Pro uživatele bude dostupné co nejjednodušší a nejpřehlednější grafické rozhraní, které bude obvykle využito prostřednictvím dotykových obrazovek, v ostatních případech klávesnicí a myší.

•

Pro rozdílné zaměření zákazníků se dá počítat s tím, že bude nutné grafické rozhraní často přizpůsobovat konkrétním požadavkům.

5.2 Diagram případů užití Prvním použitým diagramem je diagram případů užití (Use Case Diagram, UCD). Jedná se o zobrazení dynamické (funkční) struktury systému z pohledu uživatele. Je primárně určen k

21

definici chování systému, aniž by odhaloval jeho vnitřní strukturu [23]. Zachycuje systém pokladního modulu a jeho vnitřní části tak, jak k nim přistupují jednotlivé uživatelské role a jeho návaznost na skladovou aplikaci. Pomocí případů užití a vazeb mezi nimi jsou znázorněny aktivity a jejich souvislosti.

5.2.1 Účastníci V rámci diagramu užití pokladního modulu vystupují tři účastníci. Jsou jimi Prodavačka, Administrátor a Sklad. Prodavačka a Administrátor představují uživatelské role pro práci se systémem. Naproti tomu účastník Sklad nepředstavuje roli uživatelů, jak je obvyklé, ale systém skladu. Proto je také u něj zakreslen stereotyp <<system>>. Prodavačka a Administrátor. Prodavačka je jedním ze dvou účastníků představujících role pro fyzické osoby. Tento účastník je uživatelem, který se systémem pracuje a využívá jeho funkcionality pro svoji práci. Administrátor má navíc možnost přistupovat k částem systému, které upravují jeho chování pro Prodavačky, je tedy rozšířením této role. Sklad. Tento poslední účastník nepředstavuje uživatelskou roli, ale je v diagramu zakreslen pro úplnost celé komunikace mezi uživatelem, přes pokladní modul až po vazbu na sklad. Většina funkcionality využívá data ze skladu a proto je zde nezbytný.

5.2.2 Případy užití Představují jednotlivé aktivity, které se systémem účastníci provádějí. V tomto případě se jedná o množství činností, které během své práce vykonává Prodavačka nebo Administrátor. Případy užití na sebe v některých případech navazují, což je u každého z nich zmíněno. Vazby na účastníka Sklad představují komunikaci se skladovým systémem, který jako jediný může přímo přistupovat k databázi a zní načítat, nebo do ní naopak ukládat data. Přihlášení a odhlášení. Přihlášení je první aktivita, kterou uživatel systému musí vždy vykonat. Bez úspěšného přihlášení do systému pomocí autorizace uživatelským jménem a heslem není možné pokračovat s žádným z dalších případů užití. Odhlášení se naopak provádí až jako poslední činnost po ukončení veškerých dalších případů užití. Bez úspěšného odhlášení nelze program ani standardním způsobem ukončovat, aby nedošlo k nechtěnému přerušení práce a uživatelé byli donuceni vše řádným způsobem uzavřít. Otevření a uzavření. Pro většinu dalších případů užití v tomto seznamu je nutné pokladní modul nejdříve tzv. otevřít. Jedná se funkci, která od toho okamžiku zaznamenává veškerou činnost uživatelů, která bude následně shrnuta v podobě uzávěrky v případu užití Uzavření.

22

Případem užití Uzavření končí pracovní činnost prodávajícího. Jedinými dalšími aktivitami, které mohou po uzavření následovat jsou Odhlášení nebo opětovné Otevření. Při uzavření pokladny se do skladového systému zaznamenává vše, co uživatel prováděl od Otevření a je vytištěn papírový doklad se souhrnem.

Obrázek 5.1: Diagram užití

23

Prodej. Nejčastější činnost uživatele s pokladním systémem je právě Prodej. Jedná se o sestavení seznamu produktů pomocí výběru z kategorií, nebo zadáním příslušného kódu zboží, následné úpravy počtu nebo stornování položek a na závěr vystavení paragonu a zaznamenání inkasované částky. Na prodej jsou navázány další případy užití, které je nutné využívat pro úspěšné provedení prodeje. Zboží, se kterým je manipulováno je také možné přidávat slevy z běžné ceny. Výše slevy se řídí částečně vnitřními předpisy daného podniku, kde je pokladní systém využíván a částečně také zákony České Republiky. Výběr zboží, Výběr kategorie. Případ užití Výběr zboží je aktivita s účelem sledování aktuálních stavů zboží na skladě a možností z těchto produktů vybírat konkrétní instance, se kterými bude manipulováno. Může se jednat o výběr zboží z katalogu pomocí případu užití Výběr kategorie ale existují i další postupy jednoznačné identifikace, jako je například snímání čárových kódů. Zboží vybrané na prodejní seznam je rovněž možné stornovat, nebo dle potřeby upravovat jeho počet. Úprava stolů a výběr stolu. V restauračním zařízení jsou jednotlivé prodeje vázány na stoly nebo místnosti. K úpravě rozvržení stolů pro restauraci slouží případ užití Úprava stolů, ke kterému má ovšem přístup pouze administrátor. Výběr stolu je zde za účelem zvolení konkrétního stolu, na který se připisuje nově prodávané zboží a tuto funkcionalitu může využít libovolný přihlášený uživatel.

24

5.3 Návrh grafického rozhraní Grafické rozhraní pokladny bylo předem nakresleno a prodiskutováno s vedením firmy a klienty. Návrh bral v potaz skutečnost, že aplikace má být připravena pro použití s dotykovými obrazovkami. Vycházel ze specifikace požadavků a z diagramu případů užití, kde se hlavní okno aplikace vztahuje k případům užití Přihlášení, Odhlášení a ke všem součástem Prodeje. Primární nákres vzhledu zobrazuje přiložený obrázek. Ostatní funkcionalita bude dostupná pomocí dalších doplňkových dialogů a nabídek.

Obrázek 5.2: Návrh grafického rozhraní Na první pohled je uvedené hlavní okno aplikace rozděleno na dvě části. Levá část slouží pro zobrazení seznamu prodávaného zboží, v hlavičce jsou informace o aktuálním času, přihlášeném uživateli a vybraném stolu. Spodní část obsahuje tlačítka pro jednotlivé funkce pokladny, jako je například otevření nebo zavření stolu a množství dalších. Je zde také numerická klávesnice pro zadávání číselných vstupů například kvůli možnosti ručně zadat čárový kód zboží. Navíc je tu i celkový součet ceny. Pravá část obsahuje seznam zboží a jeho kategorií. Úplně vespod pak další tři ovládací tlačítka pro návrat do nadřazené kategorie a dva rychlé odkazy pro pohyb mezi souvisejícími kategoriemi.

25

5.4 Diagramy tříd Pro zachycení objektového modelu systému byl použit diagram tříd, v němž je znázorněna statická struktura systému. Pokladní modul má díky své návaznosti na skladový systém své specifické potřeby, podle kterých je nutné model tříd vytvářet. Celkový model zde nebude uveden, protože je příliš rozsáhlý. Místo toho budou popsány jednotlivé druhy tříd a bude u nich vysvětleno, k čemu se používají. Velký důraz bude kladen na specifika architektury SOA a návrh komunikace se skladem. Pro složitější a časově náročnější činnosti lze využít knihoven pro podporu více vláken a speciální třídy, které jsou pro tyto účely u objektových jazyků připraveny a i o těch bude řeč.

5.4.1 Aplikační logika, uživatelské rozhraní a služby Hlavní část objektového modelu je vytvořena několika skupinami podobných tříd, uzavřených do společných balíků. Pro každou část aplikace je tak vytvořeno velice podobné schéma tříd, které v některých případech nemusí využívat úplně všech z nich. První obrázek s diagramem tříd je znázorňuje a zároveň zachycuje jejich vazby mezi sebou. Je však nutné podotknout, že stejně jako u dalších částí vývoje tohoto systému, je zachycena a popsána jen jedna z variant, jelikož pro konkrétní zákazníky a jejich rozdílné zaměření podle druhu prodeje, je nutné provádět určité úpravy, z velké části naštěstí pouze na straně GUI. Během návrhu těchto tříd byla brána v úvahu architektura MVC, která se v dnešní době hojně využívá a na jehož principech je vystavěna řada knihoven a frameworků, jako například Spring Framework. MVC je zkratka ze tří anglických slov Model, View a Controller. Architekturu MVC jako první popsal Trygve Reenskaug v roce 1979 a poprvé byla uvedena v jazyce Smalltalk, vyvíjeném v Xerox research labs [24].

Obrázek 5.3: Základní vztahy MVC [25]

26

Smyslem MVC je logické rozdělení tříd aplikace podle jejich určení právě mezi tyto tři skupiny a představují tak prvky, které mezi sebou komunikují a mají vliv na zpracovávaná data. Model je označení pro třídy starající se o data v objektech, které se následně mohou ukládat do libovolného datového úložiště, například do databáze. Vrstva Model zároveň obsahuje i části kódu pro manipulaci s těmito daty. Další částí aplikace jsou View. Už podle názvu je patrné, že představují nejvyšší část aplikace směrem k uživateli a obsahují grafické rozhraní, se kterým uživatelé aplikace interagují. Poslední část aplikace tvoří Controller, což jsou reakce na vstupy od uživatele, které volají Model. Na základě výsledků z Model pak Controller ovlivňuje jakým způsobem se má znovu zavolat View. Velkou výhodou takto rozvrstveného objektového modelu je snadnost úpravy jednotlivých částí a lehčí orientace ve zdrojových kódech během implementace. Architektura MVC bývá někdy nesprávně zaměňována s třívrstvou architekturou a někteří vývojáři je považují za totéž. To ovšem není pravda. Třívrstvá architektura je rozdělena na prezentační, aplikační a datovou vrstvu, kde prezentační se stará o vykreslení rozhraní směrem k uživateli, aplikační obsahuje aplikační logiku a manipulaci s daty a datová odpovídá za získávání a ukládání dat do datového úložiště. Pokud bychom tedy měli MVC rozdělit do těchto tří vrstev, View a Controller by představovali prezentační vrstvu a Model by tvořil vrstvy aplikační a datovou [26].

Obrázek 5.4: Třívrstvá architektura a MVC [26]

U tohoto projektu byla navíc architektura MVC rozdělena do několika dalších podčástí, kvůli oddělení složité logiky do samostatných tříd a také kvůli vymezení rozhraní pro komunikaci se skladovou částí pomocí architektury SOA.

27

Obrázek 5.5: Obecný diagram tříd a rozdělení podle MVC

Základem navrhované aplikace jsou třídy označené jako Controller. Jejich úkolem je starat se o správné reakce na vstup od uživatele a tak zpřístupňovat funkcionalitu celé aplikace. Každá taková třída je přímo propojena s třídami View. Třídy typu Controller dále ke složitějším činnostem využívají třídy typu Task. Smyslem View je práce s uživatelským rozhraním a reakce na akce tohoto rozhraní. K tomu využívá právě výše zmíněného Controlleru a neměla by proto obsahovat už žádné složitější operace s daty. Všechny View také rozšiřují svého rodiče, ve kterém je zapouzdřena společná část zmíněných tříd. V Task se slučují nejsložitější a časově nejnáročnější výpočty a v některých případech se odtud využívá vazba na skladovou část. Pro pochopení tříd Task je možné si každou z nich představit jako činnost spuštěnou v samostatném vlákně, aby se její vykonávání neodráželo na zpomalené reakci grafického rozhraní. Task se může u časově méně náročných akcí vynechat a Controller tak komunikuje přímo se Service. Service jsou třídy určené ke komunikaci se skladovou částí aplikace podle architektury SOA. Každá z nich má své rozhraní a Service je jeho implementací. Komunikace tak probíhá přes rozhraní, bez nutnosti znát podrobnosti, jak je tato komunikace ve skutečnosti implementována. Společně s Task tvoří část Model z architektury MVC.

28

Model tříd je použit několikrát vedle sebe a podle zaznamenaných požadavků a případů užití je tak vystavěna celá aplikace. Navíc je doplněn o několik dalších doprovodných tříd pro speciální funkce, jako je například třída starající se o tisk dokladů. Mezi další samostatné třídy patří hlavní třída spouštějící celou aplikaci nebo objekty pro načítání nastavení z textových souborů. Ukázka části modelu tříd je dostupná v přílohách.

5.4.2 Datový model Datový model pokladny do značné míry kopíruje datový model skladové části aplikace. Je to dáno společnými informacemi, které oba moduly zpracovávají. Oproti Skladu je ale datový model pokladny rozšířen o některé části, které usnadňují manipulaci s nimi ještě před odesláním do skladu nebo jsou z hlediska skladové aplikace bezvýznamné, ale zajímají uživatele jen během jejich zadávání do pokladny. Naopak jsou vynechány ty části, které nejsou důležité z hlediska pokladny.

Obrázek 5.6: Diagram tříd pro datový model Třída Table představuje stůl v restauraci, který má svoje označení, podle kterého ho uživatelé rozpoznávají. Pokud se pokladna nevyužívá v restauračním zařízení, je možné vytvářet prodej bez využití uvedených objektů. Receipt je celý prodej obsahující informace o datu vytvoření

29

a další vhodné atributy, jako například, zda už byl tento prodej zaplacen, nebo zda je stále otevřen pro další úpravy. User je třída pro uchovávání informací o přihlášených uživatelích. Všechny zmíněné třídy jsou využity v nadřazené třídě TableReceipt, která si pamatuje odkazy na příslušné stoly, prodeje a uživatele, se smyslem daný prodej na daný stůl založený daným uživatelem. Položky prodeje jsou zapouzdřeny ve třídě ReceiptItem. Mimo vazby na produkt, je zde obsaženo například i množství, měrná jednotka, výše daně a další. Product a Category jsou nosiče hierarchické struktury produktů a kategorií, ve kterých jsou všechny produkty uloženy. V případě specifických požadavků klientů, je možné datový model dále rozšiřovat a upravovat, nicméně je pravděpodobné, že tento model bude použitelný pro velkou většinu případů nasazení aplikace.

5.4.3 Diagram nasazení Pomocí diagramu nasazení je názorně zobrazeno rozdělení jednotlivých částí aplikací a jejich návaznosti mezi s sebou při interakci s grafickým rozhraním a při komunikaci mezi pokladnou, skladem a databází. Skladová a pokladní část jsou sice zobrazeny jako rozdílné počítače, ale ve skutečnosti to může být i jeden a obě aplikace mohou běžet zároveň vedle sebe. Databáze MySQL může být nahrazena za jinou. Stejně tak nerozhoduje, zda je lokální nebo vzdálená, to se může lišit podle přání konkrétního klienta.

Obrázek 5.7: Diagram nasazení s komponentami

30

6. Implementace V této kapitole je popsáno, jak probíhala implementace pokladního modulu. Nejprve je uveden seznam použitých nástrojů s informacemi o nich. Je zde také vysvětleno, proč byly vybrány právě tyto. Samostatná podkapitola je věnována průběhu implementace a ukázkám kódu s vysvětlením k čemu slouží.

6.1 Použité nástroje Pro úspěšnou implementaci každého softwaru je nejprve zapotřebí vybrat vhodné nástroje. Jejich výběr částečně vyplynul z návaznosti na skladový systém. Důležitou roli také hrály požadavky firmy EtosComp. Vyvinutý software je jejím majetkem a s velkou pravděpodobností nebudu do budoucna jediným pracovníkem, který se na jeho tvorbě podílí. Proto jsou použité technologie zvažovány i z pohledu rozšíření mezi běžné softwarové vývojáře a už zavedené vnitřní postupy firmy. Java Programovací jazyk Java je produktem firmy Sun Microsystems, později koupené firmou Oracle. Jedná se o objektově orientovaný jazyk, který se od svého vzniku v roce 1995 stal velice rozšířeným a poskytuje dostatečné množství nástrojů a knihoven pro tvorbu robustních systémů. V jazyce Java je navíc naprogramována i skladová část systému a proto je jeho volba pro pokladní modul více než vhodná. Důležitou roli také hrály požadavky firmy EtosComp, jejíž zaměstnanci umí v tomto jazyce programovat a je proto možné, aby se v budoucnu na vývoji podíleli i další kolegové. Navíc jsem vycházel z předchozích kladných zkušeností s tímto jazykem, protože jsem ho až do současnosti použil na několika projektech. Netbeans IDE Netbeans IDE představuje OpenSource vývojové prostředí pro jazyk Java. Jedná se o nástroj, pomocí kterého programátoři mohou psát, překládat, ladit a distribuovat aplikace. Samotné vývojové prostředí je budováno v jazyce Java - ovšem podporuje prakticky jakýkoliv programovací jazyk. Existuje rovněž velké množství modulů, které toto vývojové prostředí rozšiřují. Vývojové prostředí NetBeans je bezplatně šířený produkt a jeho užívání není nijak omezeno [27].

31

Swing Application Framework Swing je knihovna uživatelských prvků na platformě Java pro ovládání počítače pomocí grafického rozhraní. Knihovna Swing poskytuje aplikační rozhraní pro tvorbu a obsluhu klasického grafického rozhraní. Navazuje na starší nástroj Abstract Window Toolkit (AWT), u kterého se však objevily chyby v návrhu a proto byl v roce 1997 jeho další vývoj ukončen. V dnešní době je Swing nedílnou součástí Java SE a to už od verze 1.2. Před tím byl dostupný jako samostatná knihovna. Komponenty grafického rozhraní jsou typu "lightweight", tedy každá z nich je zodpovědná za svůj vlastní vzhled a nespoléhají se na vykreslování ze strany systémových knihoven ale operačnímu systému se předávají jen jako hotový obrázek. U starší knihovny AWT tomu bylo naopak. Grafické prvky využívaly vazby na operační systém pro určení svého vzhledu a vytvářely tak jen rozhraní mezi Javou a grafickým API platformy [28]. Další alternativou, která byla zvažována, je využití Spring Frameworku. Od toho však bylo upuštěno, přestože jsem s ním měl již předchozí pozitivní zkušenosti. Důvodem byla nutnost vyvíjet aplikaci tak, aby v její implementaci mohli do budoucna pokračovat i méně zkušení programátoři. Apache SVN Pro správu verzí a ukládání zdrojových souborů bylo využito verzovacího systému Apache SVN. Ten umožňuje mít kontrolu nad postupným vývojem a sledovat změny oproti předešlým verzím programu. Navíc je schopen změny i vracet zpět, pokud se během vývoje dojde k nevhodným výsledkům.

6.2 Postup implementace Během implementace byla uplatněna skutečnost, že skladová část již byla předpřipravena s většinou potřebných funkcí. Jediné, co bylo potřeba vytvořit, jsou třídy se službami, aby bylo možné je volat a získávat potřebná data a mít zároveň rozhraní i pro zpětné ukládání do databáze. Po jejich implementaci jako obyčejných tříd, byl celý projekt skladu importován do projektu pokladny a během vývoje grafického rozhraní a aplikační logiky pokladny se tak dalo využít přímého volání služeb skladu a simulovat tak vzdálenou komunikaci bez nutnosti její okamžité implementace. Pozornost tak byla upřena na pokladnu samotnou a na tvorbu jejích tříd. Hlavní okno aplikace bylo během implementace rozděleno na dvě části a z každé z nich vytvořeny třídy typu View. Jejich obsahem jsou všechny ovládací prvky, tedy tabulka, tlačítka a nápisy. Tyto třídy neobsahují žádnou aplikační logiku, starají se pouze o zobrazení vzhledu. To se na první pohled může zdát jako velice jednoduché ale není tomu tak. Například u tlačítek vpravo, které se vykreslují podle obsahu právě vybrané kategorie je nutné brát v potaz například rozlišení obrazovky, aby se dalo určit, kolik řádků a sloupců se má použít. Výpočty pro tuto část

32

samozřejmě neprobíhají na straně View, ale i samotné dynamické zobrazování proměnného počtu tlačítek není triviální. Jak vypadá již spuštěná aplikace ukazuje poslední obrázek v této kapitole. Dalším pohledem, který bylo pro restaurační pokladnu nutno vytvořit, je rozhraní pro grafický výběr a úpravu rozmístění stolů v restauraci. Toho bylo dosaženo využitím knihoven pro kreslení grafiky z platformy Java. Celá obrazovka pro design restaurace se zobrazuje po stisknutí tlačítka s nápisem "Restaurace" z předchozí části. Podobně jsou vytvořeny i další pohledy pro přihlašování a odhlašování uživatelů nebo pro potvrzování vypnutí aplikace. Jejich ukázky jsou součástí příloh. Některé ovládací prvky také mohou být v určité chvíli nedostupné, například tlačítko pro otevření stolu, pokud je stůl už otevřený. Této funkcionality bylo dosaženo pomocí anotací a jejich parametrů. Metody pro akce grafického rozhraní proto využívají právě anotace org.jdesktop.application.Action, kterou je možné opatřit parametrem enabledProperty. Ten se používá pro specifikace pravdivostní proměnné, na jejíž hodnotě závisí, zda ovládací prvek, který tuto akci vykonává, je nebo není v danou chvíli dostupný. Použití pravdivostní hodnoty a metody pro její zjišťování a nastavování jsou na dalším obrázku. Další následující ukazuje použití této anotace přímo v kódu.

Obrázek 6.1: Použití pravdivostní hodnoty a metody pro její zjišťování a nastavování.

33

Obrázek 6.2: Použití anotace pro automatické nastavení dostupnosti ovládacích prvků.

Pro reakce na všechny uživatelské vstupy z těchto pohledů jsou vytvořeny třídy typu Controller. Proto po aktivaci libovolného ovládacího prvku je z odpovídající třídy zavolána příslušná metoda. Jako celek pak fungují pouze pro reakce na tyto vstupy, které mají za následek úpravu dat nebo i přepínání mezi pohledy. Na ně jsou navázány třídy, které rozšiřují abstraktní třídu org.jdesktop.application.Task. Ta je součástí aplikačního frameworku Swing a představuje akce spouštěné v samostatných vláknech. Jejich obsahem je hlavní část aplikační logiky a pro návaznost na sklad využívají rozhraní služeb. Podle potřeb aplikační logiky a požadavků byl také dle návrhu vytvořen datový model pro uchovávání dat. Přímo tyto třídy nejsou sice ukládány do databáze, ale jsou vytvářeny během spuštěné aplikace a při ukládání do databáze přes služby skladu jsou z nich získávána nebo do nich naopak ukládána potřebná data. Součástí aplikace jsou také třídy pro tisk dokladů. Tento tisk je vysoce parametrizovatelný, protože množství tiskáren, které se v současné době používají pro pokladní systémy je velké a pro každou z nich vytvářet speciální třídu by bylo pracné. Proto je možné spoustu parametrů tisku ovlivňovat z v vnější pomocí textových souborů s nastavením. Jedním z hlavních rozdílů mezi tiskárnami je počet znaků, které je možné vytisknout na jeden řádek. To je důležitý údaj například pro zarovnání. Stejně tak je nastavitelné, o kolik znaků mají být odsazené jednotlivé části textu, nebo jaký text se má vytisknout do zápatí každého dokladu. Soubor s nastavením je typu .properties a je načítán pomocí standardních tříd z jazyka Java. Na následujícím obrázku je jeho část, která má vliv právě na tisk paragonů.

34

Obrázek 6.3: Část souboru s nastavením tisku Po získání těchto údajů je pak možné nastavit šablonu tisku. S pomocí dalších údajů, jako jsou položky prodeje nebo přihlášený uživatel, jenž se získávají z datových tříd, případně z informací přímo z operačního systému, což je třeba aktuální čas a datum, se vytváří celý dokument, který bude vytištěn. Ukázka hotového výstupu, jak se vytiskne na pokladní doklad, je na dalším obrázku.

Obrázek 6.4: Ukázka vytištěného paragonu

Poslední částí, kterou bylo nutné vytvořit, jsou samotné služby. Celá aplikace je vystavěna na základě komunikace se skladovým modulem a právě pomocí nich tato komunikace probíhá. Před začátkem implementace služeb bylo pro každou z nich vytvořeno rozhraní a kdekoliv v jiné

35

části aplikace, kde se využívá volání služeb pro manipulaci s daty ve skladovém modulu, je tato komunikace vystavěna pomocí těchto rozhraní. Vzniká tak naprostá nezávislost na konkrétní implementaci služeb. Následující ukázka obsahuje jedno z těchto rozhraní.

Obrázek 6.5: Rozhraní služby pro komunikaci se skladem

Konkrétní implementace je pak určena až třídou implementující toto rozhraní a z hlediska funkcionality pokladního modulu není vůbec důležitá. Proto bylo možné v průběhu vývoje služby volat stejně jako u hotové aplikace, přestože způsob komunikace může být naprosto odlišný. Navíc i skladová část je neustále dále vyvíjena a pokud se změní tato komunikace, na vnitřní funkcionalitu pokladny to nebude mít vůbec vliv. Stačí upravit implementace rozhraní služeb jak na skladu, tak odpovídajícím způsobem na pokladně. Navíc za předpokladu, že se nezmění technologie komunikace a zůstanou stejná i rozhraní, je možné na skladové části provádět naprosto jakékoliv změny beze strachu, že to ovlivní pokladnu. Zde je zařazena ukázka části implementace služby, jak byla nastavena v průběhu vývoje.

36

Obrázek 6.6: Jeden z možných způsobů implementace rozhraní služby

Obrázek 6.7: Implementace grafického rozhraní

37

7. Testování Během implementace a po jejím dokončení je vhodné vyvíjený systém podrobit co nejdůkladnějšímu testování. U aplikace, která manipuluje se zbožím a s peněžní hotovostí, je správnost implementace a vyloučení chyb ještě daleko důležitější než jinde. První část této kapitoly se věnuje testování samotného softwaru. V závěru je pak vysvětleno, jak byla testována kompatibilita s různým požadovaným hardwarem a s jinými operačními systémy.

7.1 Testování implementace pokladního modulu Již během vývoje byl pokladní modul testován a to hned několika způsoby. Jednou z prvních věcí, která se zkoušela oproti odchylkám od specifikace požadavků, byla komunikace se skladovým systémem. Tím se hledaly a odstraňovaly chyby jak na straně služeb pokladny, tak na straně služeb skladu. Velkou výhodou byla již z velké části kompletní implementace a dokončené otestování skladu, protože se tak vyloučila možnost nesprávné persistence dat a aplikační logiky v této aplikaci. Jedinou nevýhodou byly další drobné úpravy, které se prováděly na skladovém modulu i během vývoje pokladny. Ty se objevily z důvodu zapomenutých posledních drobností a některých menších dodatečných požadavků klientů na skladovou část. Zmíněné testování probíhalo jak během implementace služeb, tak po jejich dokončení, většinou přímo prostředky jazyka Java a vývojového prostředí Netbeans IDE. Jednalo se zejména o zvýšenou úroveň logování a sledování průběhu jednotlivých metod nebo také různých metrik, k čemuž posloužil nástroj Netbeans Profiler. Ten je standardní součástí vývojového prostředí Netbeans IDE a umožňuje sledovat rozličné množství ukazatelů, podle nichž se dá usuzovat kvalita a rychlost aplikace. Stejně tak může pomoci odhalit slabé části kódu, například příliš časté volání časově náročných metod nebo i nezamýšlené volaní různých objektů v průběhu implementace. Netbeans Profiler dokáže zobrazovat četnost volání všech metod a tříd, sledovat využití paměti nebo vytížení CPU. Výstup z tohoto nástroje je znázorněn na následujícím obrázku.

Obrázek 7.1: Ukázka použití nástroje Netbeans Profiler

38

Dalším důležitým prvkem pro testování bylo chování grafického rozhraní. Velká část aplikace běží v jediném okně a střídá se v něm množství různých pohledů v reakci na mnoho vstupů. I toto bylo nutné pořádně ozkoušet. Některé komponenty nejsou pevně vytvořeny, ale vykreslují se dynamicky podle vnějších vlivů, například podle rozlišení obrazovky. Součástí pokladního modulu jsou i upravené komponenty lišící se vzhledem nebo funkcionalitou od těch klasických používaných v běžných aplikacích. Po dokončení hlavní části aplikace byl výsledek porovnáván s požadavky klientů a s případy užití, zda odpovídá zadání. Toho bylo docíleno spuštěním aplikace na testovacích datech, která simulovala nasazení v ostrém provozu. Vyzkoušeny byly i různé neobvyklé vstupy a nečekané chování uživatelů.

7.2 Testování kompatibility s hardwarem a OS Protože pokladní modul bude používán nejen na operačních systémech od firmy Microsoft, bylo nutné jeho testování provádět i na různých distribucích Linuxu. Stejně tak pro pokladny specifický hardware může občas způsobovat problémy a proto i ten bylo nutné v součinnosti s pokladnou otestovat. Přestože software napsaný v jazyce Java je ze své podstaty multiplatformní, ukázalo se, že i tak se u něj mohou vyskytnout problémy. V první řade velké množství uživatelů operačních systémů Windows má ve zvyku všechny činnosti vykonávat pod účtem s oprávněním administrátora. Modul byl ale testován i na distribuci Fedora bez maximálních oprávnění a díky tomu se objevily některé menší nedostatky. Za běhu aplikace některé její externí knihovny vyžadovaly přístup k určitým souborům na disku a pokud tyto neměly správně nastavené oprávnění přístupu, aplikace nebyla schopna pracovat. Daleko větším problémem se ale ukázala spolupráce platformy Java s tiskem. Ve Windows fungovala naprosto bez problémů, ale při práci v prostředí systému Fedora, kde se využívá externích aplikací, jako je například Ghostscript pro konverzi mezi formáty nebo tiskový manažer CUPS pro řízení samotného tisku, se objevily chyby v kompatibilitě mezi verzemi těchto programů. Vše však bylo nakonec úspěšně vyřešeno. Poslední drobný problém se vyskytl u čtečky čárových kódů. Ta totiž čárový kód ze vstupu převádí na písmena české abecedy s diakritikou, pokud je v systému zvoleno české rozvržení klávesnice. Proto byla mezi vstup čísel ze čtečky a zbytek aplikace přidána třída pro kontrolu těchto nechtěných konverzí na špatné znaky a jejich převod zpět na numerické hodnoty. V rámci testování byly objeveny i další drobné nedostatky, které byly zaznamenány a v nejbližším možném termínu opravovány.

39

8. Závěr Dobře zvolený skladový a pokladní systém je jednou z možností, jak zvýšit efektivitu práce při evidenci a prodeji zboží. V dnešní době už i menší společnosti využívají této možnosti kvůli vyšší produktivitě a možnosti lépe sledovat vnitřní procesy firmy a získat tak náskok před konkurencí. Také možnost propojit tento software se specifickým hardwarem, jako jsou například pokladní tiskárny, čtečky čárových kódů nebo dotykové obrazovky, dále umocňuje jeho využitelnost a urychluje a zjednodušuje práci zaměstnanců. Nehledě na to, že pokladní systémy mají čím dál tím širší pole působnosti a nasazují se nejen v běžných obchodech, ale i v restauračních zařízeních. Analýza, návrh a implementace pokladního softwaru s sebou přináší řadu obtíží. Kvůli propojení se skladovou částí a rozdílnosti požadavků různých klientů bylo nutné navrhnout systém takovým způsobem, aby umožňoval co nejjednodušší modifikovatelnost a rozšiřitelnost do budoucna. Toho bylo dosaženo využitím moderních principů jako je platforma SOA nebo architektura MVC. Konkrétním cílem této diplomové práce bylo seznámit se s platformou SOA a analyzovat její použitelnost pro tvorbu pokladního systému. Zároveň bylo nutné se zorientovat ve specifickém hardwaru a v omezujících podmínkách ze strany legislativy. Na základě těchto informací pak byl navržen a vytvořen pokladní systém v jazyce Java, který reflektuje současné trendy ve vývoji informačních systémů a zároveň splňuje požadavky klientů na tento software. Při své činnosti komunikuje pomocí služeb se skladovým systémem, který byl již předem připraven. Starší verze pokladny, která je taktéž mým dílem a z velké části se shoduje s principy popsanými v této práci a která je uzpůsobená pro nasazení v klasických obchodech, je již úspěšně nasazena u několika klientů. Nová verze, u které byly provedeny změny v návrhu tříd a použity některé novější technologie a postupy, popsané v analytické a návrhové část této práce a která je upravena pro použití v restauračních zařízeních, je v době dokončování této práce ve fázi těsně před nasazením. Firmy, které již tento pokladní a skladový systém využívají jsou s ním spokojeny, protože jim umožňuje automatickou kontrolu pohybu produktů a financí a zjednodušuje jim administrativní činnost. Jejich další představy a připomínky jsou zaznamenávány a zvažovány jako součást budoucích verzí tohoto softwaru. Tato práce se skládá ze dvou hlavních částí. První z nich obsahuje seznámení s cílem práce a potřebnými znalostmi. Je zde popsána platforma SOA a její principy a nejznámější způsoby implementace. Dále následuje obecný popis pokladních systémů, tak jak se v dnešní době běžně používají a k čemu slouží. Rovněž jsou zde zmíněny vazby na zákony, které specifikují manipulaci s některými údaji a doklady. Popsáno je také několik druhů hardwaru a vysvětleno, k čemu se tyto periferie v součinnosti s pokladním softwarem dají využít. V souvislosti s tím jsou zmíněny i vybrané pokladní programy konkurenčních firem, se kterými se každý z nás setkává v každodenním životě, aniž by si to třeba uvědomoval. Druhá část práce se zaměřuje na tvorbu pokladního systému, tak jak požadoval zadavatel této práce, firma EtosComp, s.r.o. Rozhovorem se zaměstnanci firmy a na základě informací od jejich klientů byl sestaven seznam funkčních a nefunkčních požadavků na výsledný systém.

40

Pomocí několika diagramů v jazyce UML byla znázorněna očekávaná funkcionalita jak z vnějšího, tak z vnitřního pohledu na tento software. K tomu posloužil diagram užití s vysvětlením a popisem jednotlivých případů užití. Na něj pak navazovaly další grafická znázornění, jako například diagram tříd a pojednání o vnitřním návrhu systému s využitím architektury MVC. Až po důkladné analýze a dokončení návrhu bylo přikročeno k implementaci celého systému, která probíhala v několika částech. Jako první byl vyřešen mechanismus komunikace mezi pokladnou a skladem na principech SOA. Následně bylo implementováno grafické rozhraní a aplikační logika. Poslední část práce byla věnována postupnému testování aplikace a to nejen z hlediska správné implementace softwaru, ale i z pohledu kompatibility s různými druhy hardwaru a softwarového prostředí. Do budoucna se dá očekávat, že se objeví další zákazníci, kteří budou mít nové specifické požadavky a že bude nutné tento systém dále rozšiřovat a upravovat. Z dosavadních zkušeností jasně plyne, že potřebná funkcionalita je velkou měrou závislá na oblasti podnikání zákazníka a hlavně na druhu prodávaného zboží. Přestože je systém už nasazen u několika klientů s dosti odlišným zaměřením, nelze předpokládat, že je naprosto univerzální a použitelný úplně všude. Navíc častým požadavkem je také změna rozložení ovládacích prvků u grafického rozhraní a v tomto ohledu nelze vždy vyhovět všem. Naštěstí tyto úpravy jsou v mé aplikaci snadné díky velice volné vazbě grafického rozhraní na aplikační logiku a ostatní části aplikace. Společnost EtosComp, s.r.o., pro kterou byl tento systém vyvinut, je s ním spokojena a do budoucna plánuje jeho další vývoj a nasazení pro nové klienty.

41

Reference [1] KRÁL, J. Přednáška o SOA. Brno: Fakulta informatiky, 2009. [2] BARRY, D. Service-oriented architecture (SOA) definition. Dostupný na URL http://www.service-architecture.com/web-services/articles/serviceoriented_architecture_soa_definition.html (květen 2011). [3] ŠTUMPF, J. Proč SOA nemá alternativu. 2006. Dostupný na URL http://www.systemonline.cz/sprava-it/proc-soa-nema-alternativu.htm (květen 2011). [4] Studijní materiál. Service-oriented architecture. Brno: Fakulta informatiky. Dostupný na URL http://kore.fi.muni.cz:5080/wiki/index.php/SOA (květen 2011). [5] MACKENZIE, M. aj. Reference Model for Service Oriented Architecture 1.0. 2006. Dostupný na URL http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf (květen 2011). [6] BARAI, M., CASELLI, V., BINILDAS, C. Service Oriented Architecture with Java. Birmingham: Pack Publishing, 2008. [7] Oracle. Remote Method Invocation. Dostupný na URL http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html (květen 2011). [8] JOSUTTIS, N. SOA in Practice. Sebastopol: O'Reilly Media, Inc., 2007. [9] KOSEK, J. Využití webových služeb a protokolu SOAP při komunikaci. Dostupný na URL http://www.kosek.cz/diplomka/html/websluzby.html (květen 2011). [10] STAR MICRONICS. Impact printers. Dostupný na URL http://www.starmicronics.com/Printer/allprinters.aspx?PageId=3 (květen 2011). [11] THE UNICODE CONSORTIUM. Unicode 6.0 Character Code Charts. 2010. Dostupný na URL http://www.unicode.org/charts/PDF/U0000.pdf (květen 2011). [12] ELTRADE. POS printers. Dostupný na URL http://www.eltrade.com/en/products/hardware/POS-printers (květen 2011). [13] KODYS. Čárový kód. Dostupný na URL http://www.kodys.cz/carovy-kod.html (květen 2011). [14] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 15420:2009. Dostupný na URL http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=46143 (květen 2011).

42

[15] MOTOROLA SOLUTIONS. Symbol LS2208 General Purpose Bar Code Scanner. Dostupný na URL http://www.motorola.com/business/v/index.jsp?vgnextoid=e37575489c075110VgnVCM10000084 06b00aRCRD (květen 2011). [16] BERKA, P. Dobývání znalostí z databází. Praha: Academia, 2003. ISBN-80-200-1062-9. [17] FRAND, J. Data Mining: What is Data Mining? Dostupný na URL http://www.anderson.ucla.edu/faculty/jason.frand/teacher/technologies/palace/datamining.htm (květen 2011). [18] FINANCE.CZ. Systém VIES. Dostupný na URL http://www.finance.cz/dane-amzda/informace/dph/vies/ [19] PORTAL.GOV.CZ. Portál veřejné správy ČR. Dostupný na URL http://portal.gov.cz/ (květen 2011). [20] APLS, S.R.O. Obchodní a pokladní systém Winshop Standard. Dostupný na URL http://www.pokladny.com/winshop_std.html [21] http://awiscz.com/ishop/ (květen 2011). [22] HORECA. Pokladní systémy FUSION. Dostupný na URL http://www.horeca-fusion.cz/ (květen 2011). [23] KUČEROVÁ, H. Use Case model. Dostupný na URL http://web.sks.cz/users/ku/pri/usecase.htm (květen 2011). [24] Wikipedie otevřená encyklopedie. Model-view-controller. Dostupný na URL http://cs.wikipedia.org/wiki/Model-view-controller (květen 2011). [25] BERNARD, B. Úvod do architektury MVC. 2009. Dostupný na URL http://zdrojak.root.cz/clanky/uvod-do-architektury-mvc/ (květen 2011). [26] MANCUSO, S. MVC and Multi-tier architecture. 2010. Dostupný na URL http://craftedsw.blogspot.com/2010/05/mvc-and-multi-tier-architecture.html (květen 2011). [27] NETBEANS TEAM. Co je NetBeans? Dostupný na URL http://netbeans.org/index_cs.html (květen 2011). [28] ELLIOTT, J. aj. Java Swing. Sebastopol: O'Reilly Media, Inc., 2007.

43

Přílohy Diagram tříd

Obrázek příloha 1: Diagram tříd pro načítání produktů a kategií

44

Ukázky zdrojových kódů

Obrázek příloha 2: Ukázka zdrojového kódu CategoriesView.java

45

Obrázek příloha 3: Ukázka zdrojového kódu CategoriesController.java

46

Grafické rozhraní

Obrázek příloha 4: Pohled pro přihlašování uživatelů

Obrázek příloha 5: Pohled pro editaci restaurace

47

Obsah CD Součástí práce je i přiložené CD, které obsahuje: •

bc.pdf - text práce ve formátu pdf.

•

sources/ - ukázky zdrojových kódů v jazyce Java.

•

images/ - obrázky použité v textu práce.

48