České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Bakalářská práce
Skladový a administrativní modul softwaru pro správu restaurace
Jaromír Mlejnek
Vedoucí práce: Ing. Martin Komárek
Studijní program: Softwarové technologie a management, prezenční. Obor: Softwarové inţenýrství Červen 2009
iv
v
Poděkování Chtěl bych poděkovat všem lidem, bez kterých by tato práce nemohla vzniknout. Velké poděkování patří vedoucímu práce Ing. Martinu Komárkovi, a to za jeho rady a nápomocnost během celé tvorby bakalářské práce. V neposlední řadě musím také poděkovat své rodině za nehasnoucí podporu během studia.
vi
vii
Prohlášení Prohlašuji, ţe jsem práci vypracoval samostatně a pouţil jsem pouze podklady uvedené v přiloţeném seznamu. Nemám závaţný důvod proti uţití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). Celé autorské dílo se dá šířit pod licencí BSD, viz [11].
V Praze dne 12. června 2009
…………………………………………………………………..
viii
ix
Abstract The goal of this bachelor thesis is to analyze, propose and implement a storage and administrative module of restaurant management system. The first part of this report provides information of current possibilities of these systems. This part also consists of a background research report of the number of systems available on the market. Great attention is paid to propose and implement the server part of system with emphasis on the use of object-oriented techniques. The result of this work is the administration and storage module and the server application.
Abstrakt Cílem této bakalářské práce je analyzovat, navrhnout a implementovat skladový a administrativní modul systému pro správu restaurace. První část práce informuje o současných moţnostech těchto systémů a obsahuje rešerši několika dostupných systémů na trhu. Velká pozornost je také věnována návrhu a implementaci serverové části systému, přičemţ je kladen důraz na pouţití objektově orientovaných technik. Výsledkem práce je daný modul a serverová aplikace.
x
xi
Obsah 1
ÚVOD ........................................................................................................................................................... 1 1.1 1.2
2
SYSTÉM PRO SPRÁVU RESTAURACE ................................................................................................ 3 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5
3
FUNKČNÍ POŢADAVKY .......................................................................................................................... 9 Administrativní modul ..................................................................................................................... 9 Skladový modul ............................................................................................................................. 10 NEFUNKČNÍ POŢADAVKY .................................................................................................................... 10 MODEL PŘÍPADŮ UŢITÍ ........................................................................................................................ 11 SLOVNÍČEK POJMŮ PROBLÉMOVÉ DOMÉNY......................................................................................... 11
ANALÝZA ................................................................................................................................................. 15 4.1 4.2
5
OBECNÝ POPIS ...................................................................................................................................... 3 MANAŢERSKÁ ČÁST .............................................................................................................................. 4 POKLADNÍ ČÁST .................................................................................................................................... 4 REŠERŠE NĚKOLIKA STÁVAJÍCÍCH SYSTÉMŮ ......................................................................................... 5 Restaurační systém BlueGastro....................................................................................................... 5 Systémy Agnis Restaurace a Agnis Sklad ........................................................................................ 6 Systém AZ Soft - Restaurace............................................................................................................ 7 Systém JAZZ RESTAURANT ........................................................................................................... 7 Závěry plynoucí z provedené rešerše .............................................................................................. 8
SPECIFIKACE POŽADAVKŮ NA VYVÍJENÝ MODUL ..................................................................... 9 3.1 3.1.1 3.1.2 3.2 3.3 3.4
4
CÍLE BAKALÁŘSKÉ PRÁCE ..................................................................................................................... 1 ÚVOD DO PROBLEMATIKY..................................................................................................................... 1
DOMÉNOVÝ MODEL ............................................................................................................................ 15 REALIZACE PŘÍPADŮ UŢITÍ .................................................................................................................. 16
NÁVRH A IMPLEMENTACE ................................................................................................................ 19 5.1 CELKOVÁ ARCHITEKTURA SYSTÉMU................................................................................................... 19 5.1.1 Java RMI ....................................................................................................................................... 21 5.1.2 Hibernate framework .................................................................................................................... 24 5.1.3 JDBC ............................................................................................................................................. 26 5.2 NÁVRH A IMPLEMENTACE SERVEROVÉ ČÁSTI ..................................................................................... 29 5.2.1 Čtečka čárových kódů ................................................................................................................... 31 5.2.2 Tiskové sestavy .............................................................................................................................. 32
6
ZÁVĚR ....................................................................................................................................................... 35
LITERATURA .................................................................................................................................................... 37 PŘÍLOHA A – SEZNAM POUŽITÝCH ZKRATEK ..................................................................................... 39 PŘÍLOHA B – INSTALAČNÍ PŘÍRUČKA ..................................................................................................... 41 PŘÍLOHA C – USE CASE MODEL ................................................................................................................. 43 PŘÍLOHA D – DOMÉNOVÝ MODEL ............................................................................................................ 63
xii
xiii
Seznam obrázků Obrázek 3.1 Rozvrţení modelu případů uţití........................................................................... 11 Obrázek 4.1 Vztah mezi poloţkou menu a surovinou ............................................................. 15 Obrázek 4.2 Evidence role u uţivatele systému ....................................................................... 16 Obrázek 4.3 SSD Zaloţit skladovou kartu ............................................................................... 17 Obrázek 4.4 Aktivity diagram Zaloţit skladovou kartu ........................................................... 18 Obrázek 5.1 Diagram nasazení................................................................................................. 20 Obrázek 5.2 RMI komunikace ................................................................................................. 22 Obrázek 5.3 Komunikace aplikace s Hibernate frameworkem [13] ........................................ 25 Obrázek 5.4 Architektura JDBC [22] ....................................................................................... 27 Obrázek 5.5 Package diagram serverové aplikace ................................................................... 29 Obrázek 5.6 Service Layer ....................................................................................................... 30
xiv
1
1
Úvod
1.1 Cíle bakalářské práce Cílem této bakalářské práce je vytvořit administrativní a skladový modul systému pro správu restaurace. Úkolem je také realizovat způsob komunikace mezi serverem a jednotlivými klienty (moduly), realizovat objektově relační mapování mezi databází a doménovými třídami, a implementovat řadiče (controllery) obsluhující poţadavky z administrativního a skladového modulu, a to vše na serverové straně.
1.2 Úvod do problematiky Informační systémy a počítače stále rozšiřují okruh své působnosti. Najít nějaký obor lidské činnosti, který by nebyl úzce spojen s informačními technologiemi, začíná být velmi obtíţné. Jedním z oborů, ve kterém bychom si před lety nedovedli představit úzkou vazbu na informační technologie a informační systémy, je právě restaurační činnost a pohostinství. Aby si na sebe totiţ restaurace vydělala, tak kromě poskytování dobrého jídla, pití a obsluhy, musí být všechny provozní procesy maximálně efektivní. Právě ke zlepšení provozních procesů přispívají softwarové systémy pro správu restaurací. Definicí a charakteristikou těchto systémů se zabývá první kapitola této práce. Na obecném modelu tohoto typu informačního systému budou popsány jeho hlavní přínosy pro uţivatele, členění tohoto typu systémů do základních modulů apod. Předpokladem pro vytvoření správného a hodnotného systému pro správu restaurací, a to hlavně po funkční stránce, je jeho správné pochopení a správné pochopení poţadavků na něho kladených. Výtečným zdrojem informací tohoto typu se ukázaly popisy a charakteristiky dostupných a uţivateli jiţ ověřených systémů. Rešerše několika málo komerčních produktů dostupných na českém trhu uzavírá první kapitolu. Jelikoţ úkolem této práce je navrhnout a implementovat pouze skladový a administrativní modul, tak se jiţ ostatními částmi systému nebudeme většinou zajímat. Aby bylo moţné jednotlivé moduly po dokončení integrovat v rámci jednoho informačního systému, jsou jednotlivé části vyvíjeny podle předem domluveného rozhraní a předem vytvořeného návrhu. V případě jakéhokoliv zásahu do sjednaného základu jsou tyto změny evidovány a diskutovány s ostatními řešiteli IS, a to v zájmu zachování integrity vyvíjeného softwaru jako celku.
2 Mezi hlavní úkoly skladového a administrativního modulu patří zajištění správného fungování skladového hospodářství a administrativní úkony, pod které spadá například tvorba menu, provádění inventarizace majetku a jiné. Podrobně se o daných procesech tohoto modulu dozvíme v následujících kapitolách. Sběrem poţadavků na tento modul a jejich analýzou se zabývá kapitola třetí a čtvrtá. V páté kapitole přejdeme od analytického pohledu směrem k návrhu. Zde je diskutováno členění systému do jednotlivých modulů a hlavně způsob komunikace mezi jednotlivými moduly a serverovou částí systému. Tato kapitola rovněţ postihuje problematiku tvorby datového úloţiště vyvíjeného systému. Jsou zde zmíněny i implementační detaily některých tříd. Závěrečné zhodnocení dosaţených cílů je obsaţeno v kapitole sedmé.
3
2 Systém pro správu restaurace 2.1 Obecný popis Stejně jako u jakéhokoliv jiného informačního systému, tak i pořízení a nasazení systému pro správu restaurace představuje nemalé finanční náklady. Pokud jsou však náklady vloţeny do odpovídajícího produktu, který postihuje daný druh podniku a procesy v něm probíhající, tak se dá říci, ţe tyto peníze jsou investovány správným směrem, zvláště při rostoucím zájmu o gastronomii a hotelové a pohostinské sluţby na vysoké úrovni. Jiţ po několikáté se zde objevil termín systém pro správu restaurace, ale moţná všichni nevědí, co si pod daným souslovím představit. Systém pro správu restaurace (anglicky restaurant management software nebo POS restaurant software) je druhem informačního systému, který slouţí ke zefektivnění a automatizaci některých provozních a administrativních procesů v restauracích a jiných pohostinských zařízeních. Tyto systémy se dají zařadit do rodiny tzv. POS systémů, ale v mnohém je rozšiřují. POS systémy (Point of Sale nebo Point of Service) [1] měly původně být náhradou za doposud pouţívané pokladny, které měli jen velmi omezené funkční moţnosti. Prvním systémem tohoto druhu byl systém od IBM nazvaný IBM 3650 Store System, který byl představen jiţ v roce 1973. Tento produkt jako první komerční pouţíval technologii klient – server, paralelní zálohování přes lokální síť a mnohé další technologie, které se doposud v komerčních produktech nevyskytovaly. Systémy pro správu restaurací jsou postavené na základu POS systémů, ale rozšiřují je o další funkční moduly. Obecně se dá kaţdý systém tohoto druhu rozdělit na dvě základní části, a to na část manaţerskou a na část pokladní. Manaţerský modul se stará hlavně o vedení skladového hospodářství, evidenci zaměstnanců, dodavatelů a případně zákazníků, a vyhodnocování provozu. Mezi úkony spadající do pokladní části patří hlavně zpracování komunikace mezi personálem a hosty. Pod onou komunikací si můţeme představit zpracování objednávek hostů, delegování objednávek do kuchyně, případně na bar, práci s účty apod. Podrobněji se o výše uvedených částech dozvíte dále v této kapitole. Pracovat s pokladní částí, stejně jako s manaţerskou, mohou pouze zaměstnanci s přiděleným oprávněním, kteří se do systému přihlašují svým uţivatelským jménem a heslem.
4
2.2 Manažerská část Jádrem této části je propracované skladové hospodářství. Kaţdý druh zboţí na skladu má svoji skladovou kartu, na které je uvedeno aktuální mnoţství a pohyb dané poloţky po skladu (popř. po skladech). Při příjmu zboţí na sklad se vyhledá skladová karta a příjem se do ní zaznamená. Po výdeji posledního kusu daného zboţí ze skladu se daná skladová karta označí jako nepotřebná, případně se odstraní. U skladových karet se většinou vyskytuje moţnost nastavení minimálního normativního mnoţství dané suroviny. Při dosaţení tohoto nebo menšího mnoţství je osoba odpovědná za skladové hospodářství informována, ţe mnoţství daného zboţí je pod sledovaným minimem. Většina těchto systémů podporuje neomezený počet skladů. Jiţ název této části systému napovídá, ţe právě zde budou evidovány záznamy nejen skladové, ale i zaměstnanecké. U kaţdého zaměstnance jsou evidovány jeho osobní a personální údaje. Zároveň má kaţdý pracovník vytvořen v systému uţivatelský účet, který spolu se svým heslem pouţívá k přihlášení do systému. Přihlásit se dokáţe zaměstnanec pouze do určité části systému, pro kterou má přidělené oprávnění. Další neméně důleţitou funkcí, kterou zabezpečuje manaţerská část, je tvorba receptur. Receptura je soupis surovin a jejich mnoţství pro kaţdé jídlo, případně pro jakýkoliv jiný produkt. Receptury poskytují informace o finančních nákladech produktu a slouţí pro odepisování surovin ze skladu. Dají se slučovat do různých skupin a dále s nimi pracovat. Není proto těţké zjistit, jak dobře se například prodávají pokrmy obsahující určitou surovinu nebo jaký odbyt mají určité míchané nápoje.
2.3 Pokladní část Jak jiţ bylo uvedeno výše, je hlavním úkolem pokladní části zpracovávat a vyřizovat objednávky zákazníků. Ústřední součástí této části je pokladna, případně i více pokladen. Na pokladně se zákazníkům otevírají účty, zadávají objednávky a uzavírají účty. Uzavřením účtu se nemyslí vţdy pouze jeho zaplacení. V kaţdé restauraci existují objednávky, které se sice uskuteční, ale nejsou okamţitě zaplaceny nebo nejsou zaplaceny vůbec. Mezi takové objednávky patří třeba nápoje a pokrmy pro potřeby personálu. Z důvodu, aby skladové údaje odpovídaly skutečným údajům ve skladě, tak i tyto objednávky musí být zaevidovány přes pokladnu. Tím objednané poloţky, stejně jako u obyčejných objednávek zákazníků, sníţí aktuální stav zásob na skladě. Pro tyto účely slouţí vnitřní účty zaměstnanců. Kaţdý zaměstnanec má svůj vlastní vnitřní účet, na který se mu zapisují jim zkonzumované nápoje a pokrmy. Ty-
5 to vnitřní účty se jiţ vyúčtovávají ve stanovených termínech dle vnitřních pravidel kaţdé restaurace. Jak jiţ bylo řečeno, pokladny tvoří centrální prvek pro práci s objednávkami. Nemusí však být jedinou moţností, jak s nimi pracovat. Druhou moţností je vyuţití přenosných kapesních počítačů, tzv. PDA. Na těchto přenosných počítačích je k dispozici stejná aplikace, případně jen lehce funkčně ochuzená, jako na samotných pokladnách. Hlavní výhodou je to, ţe číšník můţe přijímat a evidovat objednávky od zákazníků přímo u jejich stolu. Tím se zrychlí i jejich vyřízení. Účty nejsou vázaný na přístroj, který je otevřel a tak můţe být účet zaloţený na pokladně uzavřen pomocí PDA a naopak, a to bez jakýchkoliv problémů či nedorozumění. Další funkce, která je pro pohodlné obslouţení zákazníků velmi důleţitá, je přesouvání účtů mezi stoly a dělení účtů. Dělením účtu se rozumí rozdělení účtu na více účtů a jejich jednotlivé vyúčtování. Obecnou charakteristikou a rozborem restauračních systémů se zabývá článek [2].
2.4 Rešerše několika stávajících systémů Obecný model systému pro správu restaurace popsaný v kapitole 2.3 je pouze orientační. Systémy dostupné na trhu, a není jich málo, se od sebe v některých funkcích dosti odlišují. Výše popsaný model však většinou více či méně přesně odpovídá většině produktů. Abychom měli moţnost analyzovat a porovnávat vyvíjený systém s dostupnými produkty na trhu, musíme si určit některé srovnávací body. K nalezení těchto bodů nám poslouţí prostudování a porovnání několika dostupných nástrojů na trhu. Jak jiţ bylo napsáno v úvodu, účelem této práce je vytvořit manaţerskou a skladovou část vyvíjeného softwaru, a tak se jiţ nadále nebudeme zabývat částí pokladní. Kapitolu 2.3 proto prosím berte jako informativní, která podává informace k upřesnění představy o činnostech těchto systémů.
2.4.1 Restaurační systém BlueGastro Určen pro všechny druhy gastronomických provozů (od malých provozů typu kavárna, vinárna, přes restaurace a penziony aţ po hotelová zařízení). Systém lze rozdělit na moduly Manager [3], Dotyková pokladna – CASH a modul PDA pokladna. Skladové hospodářství
Systém umoţňuje členění do více skladových center.
6
Skladové zásoby jsou evidovány v průměrné nákupní ceně (vypočítána metodou váţeného průměru).
Moţnost evidovat suroviny ve spotřebitelských jednotkách.
Automatická změna spotřebitelských balení na zboţí v hlavních měrných jednotkách (kilogramy, litry, kusy) při přesunu skladových zásob z hlavního skladu do odbytových skladů.
Moţnost provádět inventarizace skladu.
Urychlené vkládání skladových karet za pomoci předdefinovaných hodnot.
Moţnost evidence zboţí pomocí čárových kódů EAN.
Tvorba receptur
Dělení receptur do gastronomických skupin.
Zadávání hrubého/čistého mnoţství surovin do receptur.
Evidence technologických postupů tvorby pokrmů.
Tisk receptur.
2.4.2 Systémy Agnis Restaurace a Agnis Sklad Systém Agnis Restaurace [4] se skládá ze dvou modulů (z modulu pokladny a z modulu „Restaurační provoz“). Systém je vhodný pro restaurace, kavárny, vinárny, bary atd. Pro pouţití ve větších provozech by musel být rozšířen o další moduly. My pro úplnost přidáme modul Agnis Sklad [5], protoţe modul Restaurace skladové hospodářství neobsahuje.
Agnis Restaurace
Moţnost pouţití více druhů ceníků.
Vyhodnocování směn číšníků, tj. zjištění prodeje přes pokladnu.
Souhrnné i podrobné vyhodnocení trţby.
Agnis Sklad
Více skladových center.
Jednoduché evidování skladových zásob na hlavním skladě a na všech provozních úsecích.
Převody mezi jednotlivými sklady, automatické odpisy surovin na základě obdrţených dat z modulu Restaurace.
7
Pohyblivé doklady (příjemky, výdejky, převodky).
Více způsobů evidence cen surovin na skladě (průměrné ceny, pevné skladové ceny).
2.4.3 Systém AZ Soft - Restaurace I tento informační systém pro restaurace se člení na manaţerský modul (včetně skladového hospodářství) a na moduly pokladního terminálu a tzv. kapesního číšníka (PDA modul). Manaţerský modul poskytuje nástroje pro sledování, řízení a evidování provozu restauračního zařízení. Bliţší informace o tomto systému jsou dostupné na webových stránkách společnosti AZ Soft, s.r.o. [6]. Manažerský modul
Rozdělení na části pokladní kniha, sklad a adresář.
Moţnost evidence více skladů.
Moţnost evidence zboţí pomocí čárových kódů.
Evidence příjmových a výdajových skladových dokladů.
Tvorba inventur, uzávěrek a přehledových statistik pro libovolné období.
Tvorba a evidence výrobních procesů nápojů a jídel.
Tisk denního menu.
Změny provedené v tomto modulu se ihned projeví na pokladním terminálu a mobilním číšníkovi.
2.4.4 Systém JAZZ RESTAURANT Komplexní systém obsahující jak část pokrývající administrativní činnosti (skladová evidence, tvorba receptur), tak i část pokladní. Stejně jako u předešlých systémů i zde se zaměříme pouze na administrativní část. Podrobnosti o tomto systému se nacházejí na webových stránkách autorské společnosti [7]. Skladové hospodářství
Umoţňuje výdej surovin do mínusu, tj. výdej surovin ze skladu dříve, neţ je zaevidováno jejich naskladnění.
8
Funkce automatických objednávek (dle stanoveného minimálního a maximálního mnoţství surovin na skladě vytvoří systém objednávky na příslušné dodavatele automaticky).
Více skladových center.
Inventarizace stavu zásob na skladě pro libovolný sklad a k určitému datu.
Tiskové sestavy.
Tvorba receptur
Tvorba skladových karet pro výrobky, pro které se následně definují suroviny, ze kterých se dané výrobky skládají (výrobek se můţe skládat i z dalších výrobků).
Automatický odpis surovin dle receptur výrobků.
Tiskové sestavy pro tisk menu.
Evidence spotřeby surovin a výrobků (jídel).
2.4.5 Závěry plynoucí z provedené rešerše Z výše uvedených informací o restauračních systémech vyplývá několik závěrů. Je vidět, ţe většina systémů odděluje provozní část od části pokladní. To logicky plyne z toho, ţe většinou osoba odpovědná za provoz restaurace není zároveň na pozici obsluhujícího personálu. Provozní má také v mnoha případech na starost evidenci skladového hospodářství, a proto obsahuje manaţerský modul většinou i modul skladový. Tvorba receptur a jídelních a nápojových lístků také většinou spadá pod provozního daného zařízení, takţe i tato činnost je zajišťována v rámci manaţerského modulu, coţ je i vidět u výše uvedených systémů. Závěrem této kapitoly můţeme říci, ţe struktura restauračních systémů je obecně velmi podobná. Uţivatelé těchto systémů jsou na zavedené a ustálené členění zvyklí, a proto se ho budeme drţet i při tvorbě našeho systému. Poznatky získané touto rešerší budou pouţity jiţ při analýze vyvíjeného modulu a hlavně potom při jeho návrhu.
9
3 Specifikace požadavků na vyvíjený modul Přesná specifikace poţadavků kladených na vyvíjený software je jednou z nejdůleţitějších aktivit při tvorbě jakéhokoliv programového díla (a nejen toho). Právě pochopení uţivatelských poţadavků finálně rozhoduje o tom, zda bude software plnit očekávanou funkci. Hledání poţadavků je jednou z prvních aktivit při tvorbě softwaru dle metodiky Unified Process1. Poţadavky můţeme rozdělit na funkční (určují, co by měl systém dělat) a na nefunkční (specifikují omezení kladená na software). Funkční a nefunkční poţadavky tvoří model požadavků. Ten můţe být ještě doplněn modelem případů užití. Posledním neméně důleţitým výstupem této aktivity je slovníček pojmů. Ten slouţí k charakteristice a popisu termínů domény řešeného problému. Více informací o sběru a evidenci softwarových poţadavků naleznete v publikaci [8].
3.1 Funkční požadavky Pro větší přehlednost můţeme funkční poţadavky dále rozdělit na funkční poţadavky na administrativní modul a na funkční poţadavky na skladový modul.
3.1.1 Administrativní modul 1. Systém bude evidovat záznamy o zaměstnancích. 2. Provozní bude moci měnit přístupové role u zaměstnanců. 3. Systém bude umoţňovat tvorbu, změnu a mazání receptur. 4. Systém bude umoţňovat tvorbu, změnu a mazání menu. 5. Systém bude umoţňovat tvorbu, změnu a mazání poloţek menu. 6. Systém bude umoţňovat dočasné zneplatnění a následnou aktivaci poloţky menu. 7. Systém bude umoţňovat tvorbu inventur a denních inventur. 8. Systém bude umoţňovat generování provozních a skladových statistik. 9. Systém bude umoţňovat evidenci provozních údajů (počet stolů, jejich značení, počet míst k sezení u jednotlivých stolů).
1
Unified Process je metodika tvorby softwaru, která nabádá k vyuţívání jiţ ověřených postupů a dalších metodik.
10
3.1.2 Skladový modul 1. Systém bude evidovat suroviny na skladě pomocí skladových karet. 2. Systém bude umoţňovat kategorizaci surovin dle uţivatelsky specifikovaných druhů. 3. Systém bude umoţňovat provoznímu kontrolovat aktuální stav surovin na skladě. 4. Systém bude provozního upozorňovat v případě, ţe aktuální mnoţství nějaké suroviny bude menší neţ minimální normativní mnoţství stanovené pro danou surovinu. 5. Při provádění skladových operací bude systém převádět zadané měrné jednotky na měrné jednotky definované u daného skladového záznamu. 6. Systém bude umoţňovat přidávání surovin na sklad pomocí příjmových dokladů. 7. Systém bude umoţňovat odebírání surovin ze skladu pomocí výdejových dokladů a odpisů. 8. Systém bude automaticky při objednání poloţky menu odepisovat suroviny, z nichţ se daná poloţka menu skládá (dle definované receptury).
3.2 Nefunkční požadavky 1. Systém bude platformě nezávislý. 2. Systém bude umoţňovat pouţití čtečky čárových kódů. 3. Při tvorbě systému bude kladen důraz na pouţívání objektově orientovaných technik, metodik a návrhových vzorů. 4. Systém bude vyvíjen v programovacím jazyce Java. Pouţito bude objektově relační mapování (zajištěno pomocí Hibernate), vzdálené volání metod (Java RMI) a jako datové úloţiště bude slouţit MySQL databáze.
11
3.3 Model případů užití
Obrázek 3.1 Rozvržení modelu případů užití
Na obrázku výše je zobrazeno členění modelu případů uţití pro vyvíjený modul systému. Pro větší přehlednost byly případy uţití rozděleny do tří kategorií. V balíčku „Actors“ jsou zobrazeny role, které se přiřazují uţivatelům systému, a vztahy mezi nimi. Tyto role nám říkají, jací uţivatele budou se systémem pracovat. Těmito uţivateli jsou číšníci, kuchaři a provozní, ale do přímého kontaktu s administrativním a skladovým modulem se dostanou převáţně provozní. Ti jediní se budou moci do modulu přihlásit. Jednotlivé diagramy případů uţití, včetně jejich scénářů, jsou zobrazeny v příloze C.
3.4 Slovníček pojmů problémové domény Slovníček pojmů problémové domény vyvíjeného modulu, při jejichţ interpretaci by mohly vyvstat nějaké nesrovnalosti.
12 Denní inventura (tzv. zrcadlo) Denní inventura je úkon, který sečte všechny prodané poloţky během jednoho dne. Pro jednotlivé poloţky zjistí, ze kterých surovin se skládají, a sumarizuje mnoţství pouţitých surovin během celého dne. Systém provozního informuje o předpokládaném mnoţství jednotlivých surovin na skladě na konci dne. Pokud je skutečné mnoţství některých surovin niţší neţ mnoţství předpokládané, tak provozní provede odpis rozdílné hodnoty, přičemţ určí důvod tohoto rozdílu. Hlavní měrné jednotky Mezi hlavní měrné jednotky patří kilogram (kg), litr (l) a kus. Na tyto jednotky se převádějí jednotky specifikované u jednotlivých surovin při provádění inventur.
Inventura Inventura je úkon, který se provádí za účelem zjištění správné skladové evidence vzhledem k pokladním transakcím. Jde tedy o to, ţe se podle pokladních údajů určí předpokládaný stav surovin na skladě a ten se porovná se skutečným stavem. Inventura se na rozdíl od tzv. zrcadla provádí pro delší časové období. Minimální normativní množství suroviny Stanovená hranice, která označuje minimální mnoţství určité suroviny na skladě. Při dosaţení tohoto či menšího mnoţství bude provozní vhodným způsobem systémem o této skutečnosti informován.
Odpis suroviny Je úkon, kterým se sníţí aktuální mnoţství suroviny na skladě, přičemţ se nejedná o výdej suroviny. Odpisy se provádějí například při zničení či poškození suroviny, nebo při ztrátě trvanlivosti. Položka menu Záznam, který reprezentuje buď výrobek něco, co si můţeme objednat z menu. Příjem suroviny Příjem suroviny na sklad je úkon, při kterém se zvýší současné mnoţství suroviny na skladě, a to o dané příjmové mnoţství.
13 Receptura Receptura je soupis surovin, ze kterých se skládá některá poloţka menu. U jednotlivých surovin je určeno její mnoţství, které je obsaţeno v dané receptuře. Toho se vyuţívá při automatickém odpisu surovin při objednání dané poloţky menu. Skladová karta Skladová karta je záznam, který obsahuje informace o dané surovině. Jsou zde vedeny údaje o aktuálním mnoţství suroviny, minimálním normativním mnoţství, o jejím čárovém kódu atd. Výdej suroviny Výdej suroviny ze skladu je úkon, při kterém se sníţí hodnota nesoucí informaci o současném mnoţství, a to o dané výdejové mnoţství.
14
15
4 Analýza Analýza je další aktivitou při procesu tvorby softwaru. Následuje za sběrem poţadavků a jejím úkolem je získané informace analyzovat a vytvořit podle nich analytický model. Analýza se zabývá otázkou, co systém má dělat, nikoliv jiţ tím, jakým způsobem to udělá. Výstupem analýzy jsou analytické třídy (ty tvoří doménový (business) model) a realizace případů užití. Více se o analýze dozvíte například v publikaci [8].
4.1 Doménový model Doménový model pokrývající celý projekt, tj. všechny moduly vyvíjeného softwaru, je zobrazen v příloze D. Při tvorbě doménového modelu se vycházelo hlavně z modelu případů uţití a ze slovníčku pojmů dané problémové domény. Jak je vidět i podle počtu asociací, je jednou z ústředních tříd celé domény třída Surovina (v pravé části obrázku). Tato třída je zároveň ústřední třídou ve skladovém a administrativním modulu. Podíváme-li se na její atributy tak uvidíme, ţe je abstrakcí skladové karty (dle slovníčku pojmů) a plní její úkoly. Má také asociaci na třídu TypSuroviny. Tato asociace nám říká, ţe kaţdá surovina spadá pod nějaký druh (kategorii), coţ nám pokrývá druhý funkční poţadavek skladového modulu. Asociace s třídami Prijem, Vydej a Odpis pokrývají funkční poţadavky ohledně evidence příjmů, výdejů a odpisů surovin ze skladu. Poslední asociace třídy Surovina je se třídou PouzitaSurovina, která má dále vazbu na třídu PolozkaMenu (viz. Obrázek 4.1). To celé nám říká, ţe poloţka menu se skládá ze surovin, u kterých se eviduje jejich pouţité mnoţství. Pomocí toho vztahu systém odepisuje pouţité suroviny u objednané poloţky menu (viz funkční poţadavek 8 ze skladového modulu).
Obrázek 4.1 Vztah mezi položkou menu a surovinou
16 Závěrem této kapitoly se zastavme ještě u uţivatelských rolí. Jak jiţ bylo řečeno v kapitole 3.3 o modelu případu uţití, tak uţivateli systému budou číšníci, kuchaři a provozní restauračních zařízení. Vyvstala otázka, jak u uţivatelů evidovat jejich roli (případně role) v rámci systému. Nakonec bylo rozhodnuto, ţe třída Osoba bude mít asociaci s rozhraním Role. Asociace bude typu M:N, coţ znamená, ţe kaţdý uţivatel můţe mít více rolí a jedna daná role můţe být přiřazena více uţivatelům. Rozhraní Role poté implementují třídy reprezentující konkrétní role. Výhodou tohoto konstruktu je to, ţe jsme schopni přidávat do systému další role tím způsobem, ţe pouze vytvoříme třídu implementující rozhraní Role.
Obrázek 4.2 Evidence role u uživatele systému
4.2 Realizace případů užití Analytické třídy poskytují statický pohled na vyvíjený systém. Pro zachycení dynamiky slouţí realizace případů uţití. V některých publikacích bývají výstupy plynoucí z této aktivity (z dynamického modelování systému) označeny termínem business process model. Více se o této části analytické aktivity dozvíte například v publikaci [8]. Vraťme se zase zpět k vyvíjenému systému. Vzhledem k mnoţství případů uţití, které s vyvíjeným modulem souvisí, zde není moţné popsat a upřesnit všechny případy uţití. Podívejme se tedy alespoň na jeden z nich.
17
Obrázek 4.3 SSD Založit skladovou kartu
Vybraným případem uţití je zaloţení nového skladového záznamu. Kaţdé surovině na skladě odpovídá skladový záznam, ve kterém se evidují informace o surovině (název, druh suroviny, čárový kód, aktuální mnoţství, minimální mnoţství, měrná jednotka, viz Obrázek 4.1). Na obrázku 4.3 vidíme, jak provozní postupuje při zakládání nové skladové karty. Informuje systém, ţe chce vloţit nový skladový záznam. Postupně systému poskytuje poţadované informace o surovině. Jakmile zadá všechny údaje, tak pošle systému zprávu, ve které mu říká, ţe má pro zadané údaje vytvořit nový skladový záznam. Jiný úhel pohled na daný případ uţití poskytuje diagram aktivit. Ten nám specifikuje sled událostí, které předcházejí uloţení skladového záznamu. Oproti diagramu na obrázku 4.3 zde ale můţeme vidět, ţe provozní načítá čárový kód pomocí čtečky čárových kódů (uplatnění nefunkčního poţadavku číslo 2). Nic ovšem nebrání provoznímu v tom, aby načtený čárový kód ručně změnil, případně zadal celý čárový kód ručně.
18
Obrázek 4.4 Aktivity diagram Založit skladovou kartu
19
5 Návrh a implementace Jestliţe jsme se v analýze snaţili vytvořit model, který by popisoval funkce, které má systém plnit, tak při návrhu budeme vytvářet model, který bude specifikovat způsob, jakým budou tyto funkce pracovat. Jde nám tedy o způsob implementace těchto funkcionalit. Účelem návrhu tedy je zkombinování analytického modelu problémové domény se specifickou doménou řešení. Doména řešení je soubor specifikací a omezení, které musí být při implementaci dodrţeny. Doména řešení nám například říká, jakým způsobem bude zajištěna persistence dat, jaké knihovny budou pouţity a podobně. Výstupem této aktivity je návrhový model, podle kterého se dá systém skutečně implementovat. Pro bliţší a podrobnější informace o procesu návrhu softwaru opět doporučuji publikaci [8].
5.1 Celková architektura systému V kapitole 1.1 je uvedeno, ţe částí práce je také návrh a implementace části serverové aplikace. Vyřčeno to bylo na začátku práce a dostáváme se k tomu aţ nyní. Mohla by se naskytnout otázka, zda se touto separací na klientskou a serverovou část neměla zabývat jiţ analýza. Odpověď je, ţe nikoliv. Z analytického hlediska je totoţné, zda bude aplikace nějakým způsobem rozdělena na dvě spolupracující části, nebo bude vše implementováno v jednotné aplikaci. Touto problematikou se zabývá architektonická analýza, která je součástí návrhu. Jak jiţ tedy bylo řečeno, systém bude mít podobu klient-server aplikace. Vlastně jiná moţnost zde ani neexistuje. Jelikoţ je systém diverzifikován do více modulů (skladový a administrativní modul, pokladní modul), tak i v případě, ţe by byla serverová část integrována společně s některým z modulů, tak zbývající moduly by s ní musely komunikovat způsobem klient-server. Z tohoto důvodu bylo rozhodnuto, ţe server bude implementován jako samostatná aplikace. To však nemusí znamenat, ţe serverová část musí být na samostatném počítači a nemůţe být provozována na stejném počítači jako jeden z modulů. To jsou ale jiţ otázky nasazení systému do provozu, kterými se zde nemusíme zabývat. Vraťme se tedy zpět k otázce celkové architektury systému. Nejdůleţitější funkcí serveru je poskytovat data klientským modulům. Na serveru bude tedy koncipováno datové úloţiště. Na vyţádání bude server posílat klientům data, která buď pouze přečte z databáze, nebo je načte, provede nad nimi poţadované operace a teprve poté je pošle na klienta. Datovým úloţištěm bude MySQL databáze [23], která plně vyhovuje současným poţadavkům na vyvíjený systém. Jelikoţ vybraná databáze patří do rodiny relačních databází, a my vyvíjíme sys-
20 tém dle objektově orientovaných metodik, musíme nějakým způsobem zajistit transformaci objektových struktur na struktury relační a naopak. Preferovaným přístupem je pouţití některého jiţ vytvořeného nástroje, který tento problém vyřeší za nás. Jedním z těchto nástrojů je Hibernate framework a právě ten jsme se rozhodli pouţít. Předtím, neţ se dostaneme k návrhu serveru a administrativního a skladového modulu, podívejme se na celkovou architekturu systému (viz. Obrázek 5.1). Pro tento účel bude nejlepší diagram nasazení. Tento diagram nám ukazuje, jakým způsobem budou systémové moduly rozděleny na fyzických uzlech (např. počítačích, serverech). Dále nám tento diagram ukazuje, jakým způsobem budou klientské moduly se serverem komunikovat.
Obrázek 5.1 Diagram nasazení
Z obrázků vyplívá, ţe systém je koncipován do třech modulů a dvou serverů. Fyzická zařízení, na kterých jsou nasazeni jednotlivé klienti, komunikují se serverem, na kterém je spuštěna
21 serverová aplikace. Serverová aplikace zpřístupňuje klientům data uloţená na databázovém serveru. Nic ovšem nebrání tomu, aby byl databázový server integrován v rámci serveru, na kterém běţí serverová aplikace (tj. aplikační server RestauraceFELServer na obrázku 5.1). Jednotlivý klienti (tj. pokladní modul, PDA modul a administrační modul) komunikují se serverovou aplikací prostřednictvím technologie Java RMI (na obrázku výše znázorněno plnou čarou s popiskem RMI). Ať se jiţ databáze nachází na společném serveru se serverovou aplikací RestauraceFEL či nikoliv, pouţívá aplikace pro přístup do databáze technologii JDBC2 (na obrázku výše znázorněno plnou čarou mezi databázovým serverem a aplikačním serverem). Dříve, neţ se dostaneme k samotnému návrhu vyvíjeného modulu a k návrhu komunikační struktury mezi klienty a serverem, měli bychom se blíţe seznámit s technologiemi, jenţ byly v této kapitole jmenovány, tedy Java RMI a Hibernate.
5.1.1 Java RMI Java RMI (Java Remote Method Invocation) je způsob komunikace v rámci distribuovaných systémů implementovaných v jazyce Java. Je zaloţen na tom, ţe jedna aplikace je schopna vyvolat metody z jiné aplikace běţící na jiném javovském virtuálním stroji (JVM3), přičemţ toto zavolání vzdálené metody má stejnou syntaxi jako zavolání lokální metody [10]. Uvaţujme klientskou aplikaci, kterou představuje jeden objekt (lokální objekt). Serverová aplikace obsahuje také jeden objekt, který je však z našeho pohledu vzdálený. Chceme, aby mohl klient vyvolávat metody na vzdáleném objektu, ale ne naopak. Potom obecně můţeme konstatovat, ţe lokální objekt potřebuje:
Lokalizovat vzdálený objekt,
komunikovat se vzdáleným objektem a
přenášet nějakým způsobem jiné objekty ze vzdáleného objektu na objekt lokální a naopak, tzv. marshaling4.
Lokalizace je zajištěna většinou tím, ţe je vzdálený objekt registrován u jmenné sluţby serveru. Při komunikaci se vzdáleným objektem nám jde o to, aby nízkoúrovňová komunikace byla před programátorem skryta. Volání metod na vzdáleném objektu je stejné jako volání metod 2
JDBC je akronymem pro Java Database Connectivity. Tímto tématem se zabývá kapitola 5.1.3. Java Virtual Machine, běhové prostředí Java aplikací; interpret. 4 Marshalingem rozumíme transformaci objektu do proudu dat umoţňující opětovnou rekonstrukci objektu [13]. 3
22 na lokálním objektu. U přenosu objektů jde o to, aby bylo moţné lehce přenášet objekty (ve formě návratových hodnot nebo parametrů) mezi lokálním a vzdáleným objektem, a to i uţivatelsky definované objekty. A právě všechny tyto aspekty a poţadavky za nás řeší Java RMI. Obecný postup implementace Java RMI zahrnuje tyto kroky: 1. Vzdálený objekt implementuje tzv. vzdálený interface. Tento interface musí být deklarován jako veřejný a musí rozšiřovat interface java.rmi.Remote. Vzdálený objekt dědí z třídy java.rmi.server.UnicastRemoteObject nebo java.rmi.activation.Activatable. Pouţijeme-li pro dědění třídu UnicastRemoteObject, poběţí vzdálený objekt ihned v JVM. Pokud bude vzdálený objekt dědit ze třídy Activatable, bude vytvořen aţ při vyvolání některé z jeho metod. 2. Kaţdá metoda mající deklaraci ve vzdáleném interfacu musí zahrnovat výjimku java.rmi.RemoteException (nebo jejího předka). Tato výjimka můţe být vyvolána, dojde-li k chybě při komunikaci se serverem (nedostupnost serveru, přerušení spojení, odmítnutí spojení atd.). 3. Vzdálený objekt se pod nějakým jménem registruje u jmenné sluţby RMI. 4. Lokální objekt musí znát vzdálený interface jiţ při kompilaci aplikace. Po těchto krocích můţe lokální objekt získat referenci na vzdálený objekt a můţe volat metody tohoto objektu. Java RMI pouţívá pro komunikaci tzv. stuby a skeletony. Stub je zástupný objekt serveru na klientské straně a skeleton je naopak zástupný objekt na serverové straně. Klient vyvolává metody na stubu a ten je odpovědný za jejich provedení na serveru. Výše je pod bodem 4 uvedeno, ţe lokální objekt musí znát vzdálený interface, coţ ale není úplně přesné. Vzdálený interface musí implementovat právě stub, protoţe ten zprostředkovaně inicializuje metody na serveru (viz. Obrázek 5.2).
Obrázek 5.2 RMI komunikace
23 Pokud chceme přenášet instance uţivatelsky definovaných tříd, tak musíme zajistit serializaci těchto objektů. Serializace zajišťuje, aby mohl být objekt na jedné straně převeden do proudu dat a na druhé straně naopak rekonstruován. Tento proud je nazýván bajtkódem a proces transformace objektu (nejen uţivatelsky definovaného) z/do bajtkódu je označen anglickým slovem marshaling. Všechny primitivní datové typy a mnoho tříd jádra Javy (např. String, Date) se dají bez sebemenších úprav serializovat. Serializace uţivatelsky definovaného objektu se v programovacím jazyku Java zajišťuje tím, ţe objekt (tedy spíše třída, podle které se vytvářejí dané objekty) implementuje rozhraní Serializable. Pokud se daný objekt odkazuje na některé další uţivatelsky definované objekty, tak i tyto objekty musí implementovat rozhraní Serializable. Problém nastává v případě distribuovaných aplikací. Jde o to, ţe pokud se přenáší objekt z jednoho virtuálního stroje jazyka Java na jiný, musí být i na tomto stroji dostupná definice třídy daného objektu. Zdá se, ţe zajištění tohoto poţadavku není problematické, ale v našem případě to menší problém byl. Podíváme-li se na některou z doménových tříd nacházející se na serveru v balíčku hibernate tak zjistím, ţe dědí z třídy DBEntity, která se stará o komunikace s databází prostřednictvím frameworku Hibernate. Nestatické třídní proměnné jsou sice stejné jako u ekvivalentní třídy v balíčku hibernate na klientu, ale při pokusu o přenos instance této třídy ze serveru na klienta (v opačném případě je to podobné) dojde k vyvolání výjimky vypsané níţe (tato výjimka se týká konkrétní třídy Material). java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.InvalidClassException: hibernate.Material; local class incompatible: stream classdesc serialVersionUID = -7126164302660275981, local class serialVersionUID = -1126164302660275981
Chyba signalizuje, ţe definice třídy na klientu se liší od definice na serveru. Vyvstávají dvě otázky. Zaprvé, jakým způsobem klient zjistil rozdíly v definicích tříd, kdyţ se definice nepřenášejí spolu s objektem, a zadruhé, jak tento problém vyřešit. Řešení naštěstí není sloţité. Předtím, neţ je objekt poslán klientu, tak se spočítá jeho jedinečný identifikátor proudu SUID (serialVersionUID) [10]. SUID je 64bitová hodnota, která se pouţívá k ověření kompatibility přenášené třídy a třídy lokální. Tato hodnota se spočte podle definice třídy, přičemţ se vychází z názvu třídy, jejich modifikátorů, implementovaných metod, třídních proměnných apod. Dá se říci, ţe tato hodnota je vlastně hešový kód dané třídy. Server tedy klientu pošle objekt s jeho SUID a klient spočítá SUID pro svoji definici dané třídy. Pokud se obě hodnoty rovnají, můţe se serializace provést.
24 V našem případě se definice tříd liší, ale mnoţina třídních proměnných je stejná. Stačí tedy, abychom explicitně určili pro danou třídu na klientu stejné SUID jako má serverová třída. V našem konkrétním případě zapíšeme do klientské třídy následující proměnnou: private static final long serialVersionUID = -7126164302660275981L;
Nyní se jiţ SUID hodnoty rovnají a rekonstrukci objektu na klientu nic nebrání. Kdyţ však spustíme server a z klientské aplikace se pokusíme vyvolat nějakou metodu na serveru, tak místo provedení metody a vrácení návratové hodnoty dojde k vyvolání výjimky java.security.AccessControlException. Tato výjimka signalizuje, ţe klientská aplikace nemá povolenou socketovou komunikaci se serverem. Musíme tedy přidělit klientu oprávnění, které mu povolí komunikaci se serverem. Níţe vypsaný příkaz právě toto činí. grant { permission java.net.SocketPermission "*:1099-65535" , "accept,listen,connect,resolve"; };
Jestliţe tento příkaz zapíšeme například do souboru app.policy a klienta spustíme příkazem java -Djava.security.policy=app.policy -jar "Aplikace.jar",
tak by měl být
problém vyřešen.
5.1.2 Hibernate framework Hibernate je nástroj zajišťující objektově relační mapování (ORM) pro javovské prostředí. Pod ORM se skrývá technika mapování objektových javovských tříd na relační struktury reprezentované databázovými tabulkami. Hibernate se nestará pouze o zajištění persistence doménových tříd, ale rovněţ poskytuje vlastní dotazovací jazyk pro získávání dat a práci s nimi (Hibernate Query Language). Programátor pak jiţ nemusí trávit čas manuálním získáváním dat pomocí SQL a JDBC. Hlavním účelem tohoto frameworku je zjednodušovat a urychlovat tvorbu robustních, výkonných databázových Java aplikací. Programátor musí vytvořit třídy, které chce mapovat do databáze. Tyto třídy se označují akronymem POJO, coţ znamená Plain Old Java Object. POJO třídy jsou vţdy tvořeny (mimo jiné) bezparametrickým konstruktorem a „getter/setter“ metodami třídních proměnných. Pro kaţdou třídu se vytvoří mapovací XML soubor, který určuje, jak se budou jednotlivé třídní proměnné mapovat na jednotlivé sloupce databázové tabulky. Programátor musí také specifikovat dialekt, který bude pouţívat HQL pro dotazování nad daty.
25 Dialekt se musí určit z toho důvodu, ţe Hibernate podporuje více jak dvacet relačních databází a kaţdá z nich implementuje standard SQL jiným způsobem.
Obrázek 5.3 Komunikace aplikace s Hibernate frameworkem [13]
Obrázek 5.3 nám poskytuje pohled na strukturu a jednotlivé asociace frameworku Hibernate, a to včetně komunikace s klientskou aplikací. Hlavním konfiguračním souborem je hibernate.cfg.xml. Zde jsou uloţeny konfigurační údaje obsahující například cestu k databázi, uţivatelské jméno a heslo pro přístup do databáze, dialekt databáze, ovladač pro přístup k databázi atd. Tento soubor rovněţ obsahuje záznamy určující cesty k jednotlivým mapovacím souborům (na obrázku výše je uvedena pouze jedna asociace k mapovacímu souboru). Hibernate framework komunikuje s databázi prostřednictvím JDBC, neboli Java Database Connectivity. Charakteristikou a popisem JDBC technologie se zabývá kapitola 5.1.3. Podrobný popis integrace frameworku Hibernate s Java aplikacemi přesahuje rámec této práce. Obecně vzato není tento pracovní postup obtíţný. V plné obecnosti zahrnuje tyto kroky [15]: 1. Stáhnou balíček Hibernate Core, který obsahuje všechny potřebné balíčky, knihovny, dokumentaci a podobně. Tento balíček je moţné stáhnout například na stránkách Hibernatu [19].
26 2. Zahrnout všechny potřebné knihovny a baličky do vyvíjeného projektu. 3. Vytvořit konfigurační soubor hibernate.cfg.xml. 4. Vytvořit mapovací XML sobory pro všechny POJO třídy, které mají být mapovány na databázi. Název těchto souborů je názevPOJOTřídy.hbm.xml. Tento postup popisuje obecné aspekty konfigurace Hibernatu. Pro samotné ukládání a načítání dat je potřeba ještě v kódu aplikace zajistit vytvoření instance třídy SessionFactory. Tato instance je nakonfigurována dle vlastností uvedených v souboru hibernate.cfg.xml. Instance této třídy má na starost vytváření objektů třídy Session. Tyto objekty mají za úkol vytvořit transakci (instance třídy Transaction), v rámci které se provede s databází nějaká operace. Mezi tyto operace patří například provedení databázového dotazu, vloţení, smazání či změna databázového záznamu a podobně. Programátor naštěstí většinou nemusí všechny tyto kroky provádět ručně. Mnoho vývojových nástrojů dokáţe vytvořit konfigurační a mapovací soubory pro danou databázi zcela automaticky a programátor pouze tyto konfigurace doopraví k obrazu svému. Pro bliţší informace o konfiguraci Hibernatu doporučuji dokumentaci HIBERNATE – Relational Persistence for Idiomatic Java [16]. Integrací Hibernatu s aplikacemi vytvářenými v nástroji Netbeans se zabývá článek [17]. Mnoho podstatných informací lze dohledat také v tutoriálu Java Hibernate Tutorial [14].
5.1.3 JDBC Java Database Connectivity poskytuje aplikační rozhranní pro přístup k databázi. Základem je JDBC ovladač, který přijímá databázové příkazy a překládá je do nativních volání dané databáze. Díky tomu nemusí programátor specifikovat svůj kód pro určité rozhraní databáze. JDBC se nepouţívá pouze pro data uloţena v relační databázi, ale dá se pouţít pro jakýkoliv formát ve „sloupcové podobě“, tedy například pro textové soubory nebo soubory tabulkového charakteru [20]. Aplikační rozhraní JDBC je odpovědné za tři hlavní poţadavky, a to: 1. Navázání spojení s datovým zdrojem. 2. Zasílání SQL dotazů do datového zdroje. 3. Zpracování výsledků.
27 Architektura JDBC je vidět na obrázku 5.4. Začněme u Java aplikace (Java Application). Aplikace potřebuje komunikovat se dvěma různými databázemi a jedním ODBC datovým zdrojem (tím můţe být například soubor obsahující data v tabulkovém formátu). Pokud bychom nevyuţívali JDBC, tak bychom museli ke kaţdému datovému zdroji přistupovat individuálně pomocí nativního přístupu. Naše Java aplikace by tedy musela obsahovat tři různé metody (popř. třídy) pro komunikaci s poţadovanými datovými zdroji. Pokud ale pouţijeme JDBC API, tak se situace výrazně zjednoduší. Aplikace bude komunikovat s datovými zdroji skrze JDBC API. Prostřednictvím JDBC Driver Manageru se registrují JDBC ovladače (JDBC Driver). Tyto ovladače jsou v podstatě speciální třídy, které vytvářejí sami tvůrci databází. Pokud tedy aplikace potřebuje přístup do databáze, tak nahraje a zaregistruje daný ovladač, prostřednictvím ovladače otevře spojení s databází a jiţ můţe s databází komunikovat standardním způsobem. Pokud bude poté aplikace potřebovat pracovat s jinou databází, tak pouze nahraje jiný ovladač, pomocí něhoţ se s ní spojí opět stejným způsobem. To nám poskytuje univerzálnost v tom směru, ţe při změně datového zdroje nemusíme přepisovat ani jediný řádek kódu nad vrstvou aplikačního rozhraní JDBC. Pouze v JDBC změníme zaváděný ovladač.
Obrázek 5.4 Architektura JDBC [22]
28
29
5.2 Návrh a implementace serverové části Jak jiţ bylo uvedeno, hlavním úkolem serverové části systému je zpracovávání klientských poţadavků. V diagramu nasazení (Obrázek 5.1) vidíme, ţe jednotlivé moduly se serverem komunikují prostřednictvím Java RMI. Podívejme se, jak vypadá logická struktura serverové aplikace. Na obrázku 5.5 vidíme balíčkovou strukturu serverové aplikace. Pro kaţdou doménovou třídu je vytvořen controller, který slouţí k načítání, mazání, aktualizování a vyhledávání objektů dané doménové třídy. Tyto controllery jsou na obrázku 5.5 obsaţeny v balíčku Controllers. Controllery jsou implementovány dle návrhového vzoru Singleton, coţ znamená, ţe je vţdy vytvořen pouze jeden controller dané doménové třídy. Reference na tento objekt se uloţí do statické proměnné. V případě, ţe některý objekt potřebuje získat referenci na daný controller tak pouze stačí, aby zavolal statickou metodu getInstance() třídy, na jejíţ controller chce získat referenci, a tato metoda mu referenci vrátí.
Obrázek 5.5 Package diagram serverové aplikace
30 Na obrázku 5.6 můţeme vidět servisní vrstvu serverové aplikace. Vidíme, ţe třídy ServiceFacadeManager a ServiceFacadeCash implementují jim ekvivalentní metody. V těchto rozhraních jsou deklarované metody, které mohou klientské moduly vzdáleně vyvolávat. Implementace těchto metod se právě nachází ve třídách ServiceFacadeManager a ServiceFacadeCash. Kromě implementací vzdálených metod tyto třídy také obsahují metody pro inicializaci RMI. Tyto dvě třídy jsou opět navrţeny dle návrhového vzoru Singleton.
Obrázek 5.6 Service Layer
31
5.2.1 Čtečka čárových kódů Jedním z nefunkčních poţadavků kladených na administrativní modul je poţadavek, ţe k tomuto modulu bude moţné připojit čtečku čárových kódů. Pomocí čtečky se budou do systému zadávat čárové kódy zboţí. Nabídka čtecích zařízení na trhu je nepřeberná. Je moţné pořídit specializované bezdrátové čtečky do skladů, čtečky určené pro pokladní provoz apod. Vzhledem k vyvíjenému systému a jednotlivým poţadavků nejsou na čtečku kladeny ţádné speciální nebo konkrétní nároky. Před jejím pořízením si však musíme zodpovědět několik otázek. Asi nejpodstatnější otázkou je, jakým způsobem bude čtečka k počítači připojena. Nejvyuţívanějšími porty pro připojení tohoto druhu periferního zařízení jsou sériové a USB porty. Zastoupení čteček s těmito porty na trhu je přibliţně rovnoměrné. I cenové rozdíly mezi jednotlivými rozhraními u stejného typy jsou zanedbatelné. Musíme totiţ brát v úvahu, ţe pro čtečku se sériovým portem budeme potřebovat externí zdroj napájení, čímţ se cena vyrovnává alternativě s USB portem. Novější počítače jiţ také nejsou standardně osazovány sériovým portem. Vzhledem k těmto důvodům je výhodnější v rámci vyvíjeného systému pouţít čtečku s USB portem. Druhou otázkou je, jaký zdroj světla pro snímání bude v našem případě vhodnější. Zde se naskýtají opět dvě moţnosti. Čtečky pouţívají jako zdroj světla buď LED diody, nebo laserové diody. Čtečky s LED diodami jsou levnější, avšak nejsou určeny k náročnému pouţití a dosahují menších rychlostí snímání oproti laserovým. Laserové čtečky se svými vlastnostmi hodí ke kaţdodennímu pouţívání. Jsou rychlé, mají širší rozlišovací úhly atd. Avšak jak jiţ bylo řečeno, jsou draţší. Vzhledem k tomu, ţe snímač čárových kódů nebude pouţíván permanentně, ale spíše občasně, bude plně vyhovovat našemu pouţití některá z čteček pouţívajících LED diody. Konkrétně byla pro testovací účely vybrána čtečka od společnosti Virtuos s označením CCD-MT9065. Zdrojem světla pro CCD senzor je červená LED dioda (viditelné spektrum 650 nm). Čtečka se připojuje k počítači prostřednictvím USB konektoru, dosahuje rychlosti snímání aţ 45 snímků za sekundu a dokáţe automaticky načíst a rozpoznat všechny standardní typy čárových kódů. Podrobnější informace o tomto snímači lze nalézt na stránkách dodavatele pro Českou republiku, viz [12]. Vybraná čtečka funguje na principu virtuální klávesnice. To znamená, ţe po připojení čtečky k počítači se načtené kódy chovají stejně jako textový vstup z klávesnice. To znamená, ţe aplikace nemusí implementovat ţádné rozhraní pro komunikaci se čtečkou. Ta musí být ale
32 před pouţitím správně nakonfigurována. Konfigurace se provádí načítáním konfiguračních čárových kódů, které se nacházejí v uţivatelské příručce dodávané spolu se čtečkou.
5.2.2 Tiskové sestavy Jedním z funkčních poţadavků uvedených na straně 10 je poţadavek, ţe pomocí tohoto vyvíjeného modulu bude provozní generovat reporty o provozu restauračního zařízení a o stavu skladových zásob. Aktuální stavy a charakteristiky (například u skladových záznamů, skladových příjmů, u poloţek menu, receptur atd.) můţe provozní vidět přímo v tabulkách na odpovídajících formulářích. Pokud však provádí provozní fyzickou kontrolu a inventarizaci skladových zásob, tak pro něho není elektronická forma plně vyhovující. Právě v těchto případech je pro provozního velkým přínosem, pokud pouţívaný systém dokáţe tyto informace tisknout. Z tohoto důvodu bylo rozhodnuto, ţe i tento modul by měl tisk a generování dokumentace podporovat. Způsobů, jak toho docílit, je více. Samotné jádro jazyka Java obsahuje třídy, které zajišťují tisk. Tisknou se ale grafické komponenty, takţe docílit rozumného výstupu je poměrně obtíţné. Lepší moţností je vyuţití některé z dostupných knihoven pro tisk v Javě. Jednou z nich je JasperReports. Tento systém je vyvíjen open-source komunitou, a tak díky velké programátorské základně se rychle vyvíjí. Jediným, avšak podstatným, problémem je nedostatek dokumentace. Přejděme rovnou ke způsobu vyuţití této knihovny. Prvním krokem je staţení samotné knihovny systému JasperReports. Ta se dá stáhnout na stránce http://jasperforge.org/. Doporučuji stáhnout celý .zip soubor, protoţe ten obsahuje kromě samotné knihovny JasperReports také další podpůrné knihovny a několik ukázek včetně zdrojových kódů. Nás bude nejvíce zajímat soubor JasperReports-xy.jar, protoţe právě ten obsahuje samotné API pro tisk. Tento soubor musíme začlenit do CLASSPATH našeho modulu. Tím máme modul připravený pro vyuţívání této knihovny. JasperReports pracuje tím způsobem, ţe načte tiskovou šablonu a aplikuje na ní data, která mu dodal náš modul. Tisková šablona je reprezentována XML souborem. Tento soubor můţeme vytvořit ručně, coţ je ale dosti nepraktické. Proto pouţijeme program iReport, pomocí kterého můţeme tyto šablony tvořit v grafické podobě. Program iReport se dá stáhnout na stejné webové stránce jako knihovna JasperReports. Tvorba kaţdé tiskové sestavy se skládá ze čtyř základních kroků.
Vytvoření tiskové šablony (soubor .jrxml).
Zkompilování šablony do souboru .jasper.
33
Vloţení vstupních dat do sestavy.
Vyvolání metody z JasperReports pro tisk sestavy.
Tiskové šablony pouţívané skladovým a administračním modulem byly vytvořeny pomocí výše zmíněného programu iReport. Aby se urychlil tisk, byly šablony zkompilovány předem, místo toho, aby se při kaţdém tisku kompilovaly znovu. Kompilaci těchto šablon obstarává třída Printer, která rovněţ zajišťuje vkládání dat do tiskové sestavy i samotný tisk. Bliţším popisem metod implementovaných v této třídě se jiţ nebudu zabývat, protoţe jsou řádně okomentovány v dokumentaci ke zdrojovým kódům klientského modulu. Bliţší informace o tvorbě tiskových sestav lze nalézt v tutoriálu JasperReports – tisk v Javě, viz. [24].
34
35
6 Závěr Cílem práce bylo analyzovat, navrhnout a implementovat modul (připomínám, ţe se jedná o skladový a administrativní modul) systému pro správu restaurace. Analýza byla provedena v rámci týmového semestrálního projektu v předmětech Y36SIN2 a Y36SI3. Analytický model byl však dále upřesňován, protoţe se objevovaly stále další funkční poţadavky, které by měl modul zajišťovat. Jako velmi uţitečný zdroj informací se ukázala provedená rešerše stávajících restauračních systémů. Závěry plynoucí z této zprávy poskytovaly cenné informace o poţadavcích zákazníků na tyto systémy a poslouţily pro upřesnění a validaci analytického modelu. Návrh systému byl proveden taktéţ v rámci semestrálního projektu v zimním semestru, ale i ten doznal od té doby několika drobných změn. Zadání bakalářské práce zahrnuje pouze tvorbu skladového a administračního modulu. Jelikoţ ale na projektu pokračovali pouze dva členové původního týmu, já a kolega, který měl na starost implementaci pokladní části systému (včetně aplikace pro PDA), tak bylo nutné si tvorbu serverové části nějakým způsobem rozdělit. Bylo rozhodnuto, ţe dopracování návrhu a implementaci Java RMI a objektově relačního frameworku si vezmu na starost já, přičemţ tvorbu jednotlivých controllerů v servisní vrstvě si rovnoměrně rozdělíme. Kolega ovšem narazil na problémy špatné podpory RMI u aplikací pro PDA, jejímţ řešením strávil velmi dlouho dobu, přičemţ plně optimální řešení nenašel. Z tohoto důvodu jsem se především zaměřil na implementaci controllerů, které vyuţívá mnou vyvíjený modul a na controllery, které jsou vyuţívány oběma moduly společně. Časová náročnost vývoje těchto nezbytných součástí systému (které ovšem nejsou specifikovány v zadání bakalářské práce) zapříčinila, ţe nebylo moţné splnit všechny části ze zadání bakalářské práce. Po domluvě s vedoucím bakalářské práce bylo rozhodnuto, ţe se vypustí poţadavky na tvorbu inventur, tvorbu denních inventur a poţadavek na tvorbu statistik o příjmech a výdajích. Také testování bylo omezeno pouze na testování uţivatelské, protoţe jednotkové testy nebyly plně implementovány. Na druhou stranu musím říci, ţe i v rámci klientského modulu byly implementovány poţadavky, které nejsou v zadání specifikovány, ale jsou velkým přínosem pro vytvořené funkce klientského modulu (např. tiskové sestavy pro tisk menu a skladových záznamů). Budoucnost projektu závisí na tom, jak bude realizována pokladní část systému. Bez této části postrádají některé funkce skladového a administrativního modulu smysl. Těţko si lze představit, ţe by provozní pouţíval systém, kde by mohl vytvářet menu, poloţky menu a jejich receptury, přičemţ by neexistoval pokladní modul, který by toho dokázal vyuţít. Pevně
36 však věřím, ţe se mému kolegovi podaří vytvořit pokladní modul a ţe se celý systém bude moci dále rozvíjet. Sám bych chtěl doplnit do vyvíjeného modulu funkcionality, od kterých se bohuţel muselo nyní upustit.
37
Literatura [1] Point of sale [online]. [cit. 2009-03-20]. Dostupný z WWW:
. [2] Efektivní provoz restaurace. Gastro [online]. 2008, č. 5 [cit. 2009-03-24]. Dostupný z WWW: . [3] Restaurační systém BlueGastro [online]. [cit. 2009-04-01]. Dostupný z WWW: . [4] Agnis - Restaurace [online]. [cit. 2009-04-01]. Dostupný z WWW: . [5] Agnis - Sklad [online]. [cit. 2009-04-01]. Dostupný z WWW: . [6] AZsoft – Moderní hotelový a restaurační software [online]. [cit. 2009-04-01]. Dostupný z WWW: . [7] Restaurant JAZZWARE - systém pro provoz restaurace [online]. [cit. 2009-04-01]. Dostupný z WWW: . [8] ARLOW, Jim, NEUSTADT, Ila. UML2 a unifikovaný proces vývoje aplikací. 2. aktualiz. vyd. [s.l.] : Computer Press, a.s., 2007. 568 s. ISBN 978-80-251-1503-9. [9] PECINOVSKÝ, Rudolf. Návrhové vzory. 1. vyd. [s.l.] : Computer Press, a.s., 2007. 527 s. ISBN 978-80-251-1582-4. [10] SPELL, Brett. Java : Programujeme profesionálně. 1. vyd. [s.l.] : Computer Press, a.s., 2002. 1040 s. ISBN 80-7226-667-5. [11] BSD licence [online]. [cit. 2009-06-04]. Dostupný z WWW: . [12] Virtuos CCD-MT9065 - Čtečka čárového kódu [online]. [cit. 2009-04-02]. Dostupný z WWW: . [13] NOVOTNÝ, Michal. Remote Method Invocation [online]. 2000 [cit. 2009-03-20]. Dostupný z WWW: . [14] Java Hibernate Tutorial Home [online]. [cit. 2009-03-25]. Dostupný z WWW: .
38 [15] Framework Hibernate [online]. [cit. 2009-03-25]. Dostupný z WWW: . [16] HIBERNATE - Relational Persistence for Idiomatic Java [online]. [cit. 2009-03-30]. Dostupný z WWW: . [17] Using Hibernate in a Java Swing Application [online]. [cit. 2009-04-05]. Dostupný z WWW: . [18] Getting Started Using Java RMI [online]. [cit. 2009-04-05]. Dostupný z WWW: . [19] Hibernate.org - Download Overview [online]. [cit. 2009-04-10]. Dostupný z WWW: . [20] Úvod do JDBC [online]. [cit. 2009-05-20]. Dostupný z WWW: . [21] Getting Started JDBC [online]. [cit. 2009-05-20]. Dostupný z WWW: . [22] JDBC Architecture (picture) [online]. [cit. 2009-05-20]. Dostupný z WWW: . [23] MySQL [online]. [cit. 2009-06-05]. Dostupný z WWW: . [24] JEŢEK, Kamil. JasperReports - tisk v Javě [online]. 2009 [cit. 2009-06-08]. Dostupný z WWW: .
39
Příloha A – Seznam použitých zkratek API – Application Programming Interface; aplikační programátorské rozhraní. BSD – Berkeley Software Distribution; softwarová licence, viz. [11]. CCD – Charge-Coupled Device; snímací zařízení s vázanými náboji. EAN – European Article Number; druh čárového kódu. HQL – Hibernate Query Language; dotazovací jazyk pouţívaný Hibernatem. JDBC – Java DataBase Connectivity; Java rozhraní pro unifikovaný přístup do databází. JVM – Java Virtual Machine; virtuální stroj jazyka Java. LED – Light-Emitting Diode; elektroluminiscenční dioda. ODBC – Open DataBase Connectivity; zastaralé rozhraní pro přístup do databází. ORM – Object Relational Mapping; objektově relační mapování. PDA – Personal Digital Assistant; přenosný kapesní počítač. POJO – Plain Old Java Object; objekty s čistě bussines odpovědnostmi. POS – Point Of Sale; pokladní informační systém. RMI – Remote Method Invocation; vzdálené volání metod. SQL – Structured Query Language; dotazovací jazyk pro práci s relačními databázemi. SUID – Stream Unique Identifier; jedinečný identifikátor proudu pouţívaný u serializace. USB – Universal Serial Bus; univerzální sériová sběrnice. XML – Extensible Markup Language; obecný značkovací jazyk.
40
41
Příloha B – Instalační příručka Instalace a spuštění serverové aplikace Instalace (nebo spíše nasazení, protoţe se nic instalovat nemusí) zahrnuje tyto kroky: 1. Předpokladem pro instalaci serverové aplikace je to, ţe na daném počítači je nainstalovaná MySQL databáze a JVM (Java Virtual Machine). 2. Nejprve se musí vytvořit databáze, která bude slouţit jako datové úloţiště. Pro vytvoření MySQL databáze je předpřipraven skript, který databázi vytvoří a naplní ji některými předdefinovanými záznamy. Mezi tyto záznamy patří měrné jednotky a uţivatelské role. Zároveň je vytvořen uţivatelský záznam, který slouţí pro prvotní připojení provozního ke skladovému a administračnímu modulu. „Abstraktní“ uţivatel pro připojení provozního k systému má uţivatelské jméno novak a heslo 1234. Vytvořená databáze má název db_rest_fel. 3. Dále je potřeba nastavit v konfiguračním souboru hibernate.cfg.xml URL adresu databáze a uţivatelské jméno a heslo pro přístup k databázi. Přednastavené uţivatelské jméno je root a přednastavené heslo je rest. 4. Nyní se jiţ můţe serverová aplikace spustit. Pro spuštění slouţí dávkový soubor RestauraceFELServer.bat.
Instalace a spuštění skladového a administračního modulu 1. Zde je pouze nutné nastavit v souboru config.xml IP adresu počítače, na kterém je spuštěna serverová aplikace. Pokud se modulu nepodaří připojit na server na adrese zapsané v tagu primaryServerIP, tak zkusí adresu uloţenou v tagu secondaryServerIP.
2. Poté se modul spustí pomocí dávkového souboru RestauraceFELManager.bat.
42
43
Příloha C – Use Case Model Správa zaměstnanců
Figure: 1
Odstranit zaměstnance z evidence Odstranění záznamu o zaměstnanci z evidence zaměstnanců. Scenarios
Odstranit záznam - ANO - Basic Path Notes
1. Provozní vybere ze seznamu zaměstnanců zaměstnance, jehoţ záznam chce odstranit. 2. Provozní vybere volbu "odstranit záznam o zaměstnanci". 3. Systém vyzve provozního k potvrzení poţadované operace. 4. Provozní potvrdí poţadovanou operaci. 5. Systém smaţe záznam o daném zaměstnanci. Návrat na seznam zaměstnanců.
Odstranit záznam - NE - Alternate Notes
4a. Provozní nepotvrdí smazání záznamu.
44 Scenarios
1. Systém záznam nesmaţe. Návrat k seznamu zaměstnanců.
Přidat zaměstnance do evidence Přidání zaměstnance do evidence zaměstnanců. Scenarios
Přidat zaměstnance - ANO - Basic Path Notes
1. Provozní vybere volbu "přidat nového zaměstnance". 2. Systém vyzve vedoucího, aby zadal informace o zaměstnanci. 3. Provozní zadá poţadované údaje o zaměstnanci. 4. Systém vyzve vedoucího k potvrzení zadaných údajů. 5. Provozní potvrdí vloţené údaje. 6. Systém zvaliduje vloţené údaje. 7. Systém uloţí záznam o zaměstnanci. Návrat na seznam zaměstnanců.
Přidat zaměstnance - NE - Alternate Notes
5a. Provozní nepotvrdí údaje o novém zaměstnanci. 1. Systém nepokračuje ve zpracovávání poţadavku. Návrat na seznam zaměstnanců.
Chybné vstupní údaje - Alternate Notes
6a. Údaje vloţené provozním obsahují neplatné údaje nebo duplikují jiţ existující údaje. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje se krokem 3 scénářem "Přidat zaměstnance - ANO".
Vybrat zaměstnance Vybrání zaměstnance z evidence zaměstnanců. Scenarios
Vybrat zaměstnance - Basic Path Notes
1. Provozní zadá poţadavek na vybrání záznamu o zaměstnanci. 2. Systém zobrazí záznamy zaměstnanců. 3. Provozní vybere záznam hledaného zaměstnance.
45 Scenarios
4. Systém vypíše evidované údaje o vybraném zaměstnanci. Záznam neexistuje - Alternate Notes
2a1. Systém zobrazí zprávu, ţe neexistují ţádné záznamy o zaměstnancích.
Změnit přístupové role u zaměstnance Provozní můţe měnit přístupové role u evidovaných zaměstnanců. Scenarios
Změnit roli v záznamu o zaměstnanci - ANO - Basic Path Notes
1. Provozní vybere záznam o zaměstnanci ze seznamu zaměstnanců. 2. Provozní změní roli (role) u vybraného zaměstnance. 3. Systém vyzve provozního, aby potvrdil změnu. 4. Provozní potvrdí provedené změny. 5. Systém uloţí změny. Návrat na seznam zaměstnanců.
Změnit roli v záznamu o zaměstnanci - NE - Alternate Notes
4a. Provozní nepotvrdí změnu. 1. Systém neuloţí provedené změny u vybraného zaměstnance. Návrat na seznam zaměstnanců.
Změna údajů o zaměstnanci Změna údajů o zaměstnanci v evidenci zaměstnanců. Scenarios
Změnit záznam - ANO - Basic Path Notes
1. Provozní vybere záznam o zaměstnanci ze seznamu zaměstnanců. 2. Provozní změní poţadované údaje o zaměstnanci. 3. Systém vyzve provozního k potvrzení provedených změn. 4. Provozní potvrdí provedené změny. 5. Systém zvaliduje vstupní údaje. 6. Systém uloţí změněný záznam o zaměstnanci. Návrat na seznam zaměstnanců.
46 Scenarios
Změnit záznam - NE - Alternate Notes
4a. Provozní nepotvrdí provedené změny. 1. Systém nepokračuje ve zpracovávání poţadavku. Návrat na seznam zaměstnanců.
Chybné vstupní údaje - Alternate Notes
5a. Údaje vloţené provozním obsahují neplatné údaje nebo duplikují jiţ existující údaje. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje se krokem 2 scénářem "Změnit záznam".
47
Správa menu
Figure: 2
48
Smazat menu Odstranění vybraného záznamu o menu. Scenarios
Smazání menu - Ano - Basic Path Notes
1. Provozní vybere menu v seznamu menu. 2. Provozní zadá volbu smazat menu. 3. Systém se zeptá, zda provozní chce menu smazat. 4. Provozní potvrdí volbu. 5. Systém zkontroluje, zda menu právě není pouţíváno. 6. Systém menu smaţe. Návrat na seznam menu.
Smazání menu - Ne - Alternate Notes
4a. Provozní volbu nepotvrdí. 1. Systém menu nesmaţe. Návrat na seznam menu.
Smazání menu - Chyba - Alternate Notes
5a. systém zjistí, ţe menu je pouţíváno. 1. Systém menu nesmaţe. 2. Systém ohlásí, ţe menu je zrovna pouţíváno a nejde smazat. Návrat na seznam menu.
Smazat položku menu Smaţe záznam o poloţce menu. Scenarios
Smazání poloţky - Ano - Basic Path Notes
1. Provozní vybere poloţku v seznamu poloţek. 2. Provozní zvolí volbu smazat poloţku. 3. Systém oznámí zdaje poloţka v nějakém menu. 4. Systém se zeptá, zda má být poloţka smazána. 5. Provozní volbu potvrdí. 6. Systém poloţku smaţe. Návrat na seznam poloţek menu.
Smazání poloţky - Ne - Alternate Notes
5a. Provozní volbu nepotvrdí. 1. Systém poloţku nesmaţe. Návrat na seznam poloţek menu.
49
Validace položky Validace poloţky menu. Kontroluje, zda jsou všechny poţadované vstupní údaje vyplněny. Scenarios
Validace poloţky - OK - Basic Path Notes
1. Systém zkontroluje povinná pole. 2. Systém zkontroluje duplicitu.
Validace poloţky - Chyba duplicita - Alternate Notes
2a. Pokud bude nalezena duplicita. 1. Systém ohlásí duplicitu. 2. Systém nechá formulář přístupný v nezměněné podobě. Zpět na bod 4 hlavního scénáře UC, který volal validaci.
Validace poloţky - Chyba v poli - Alternate Notes
1a. Pokud bude nějaké pole chybné. 1. Systém vyzve provozního, aby zadal správné údaje. 2. Provozní chybná pole vyplní. Zpět na bod 4 hlavního scénáře UC, který volal validaci.
Založit menu Zaloţení nového záznamu o menu. Scenarios
Zaloţení menu - OK - Basic Path Notes
1. Provozní zvolí volbu zaloţení menu. 2. Systém zobrazí formulář pro menu. 3. Provozní zadá název menu, datum vytvoření menu. 4. Provozní přidá poloţku menu. 5. Systém zkontroluje, zda poloţka v menu jiţ není. Kroky 4 a 5 se opakují, dokud provozní menu nepotvrdí. 6. Systém zkontroluje, zda nekoliduje platnost menu. 7. Systém menu uloţí. Návrat na seznam menu.
Zaloţení menu - Chyba platnost - Alternate Notes
6a. Systém zjistí, ţe koliduje platnost menu. 1. Systém ohlásí, ţe koliduje platnost menu. 2. Provozní zadá novou platnost. Pokračuje se krokem 6 z hlavního scénáře.
50 Scenarios
Zaloţení menu - Chyba poloţka - Alternate Notes
5a. Systém zjistí, ţe v menu jiţ poloţka je. 1. Systém poloţku nepřidá. 2. Systém ohlásí provoznímu chybu. Pokračuje se krokem 4 z hlavního scénáře,
Založit položku menu Vytvoření záznamu o nové poloţce menu. Scenarios
Zaloţeni poloţky - OK - Basic Path Notes
1. Provozní vybere volbu zaloţit poloţku menu. 2. Systém zobrazí formulář. 3. Provozní vyplní údaje. 4. INCLUDE Validace poloţky. 5. Systém poloţku uloţí. Návrat na seznam poloţek menu.
Zaloţeni poloţky - Chyba - Alternate Notes
4a. Pokud je validace vyhodnocena jako chybná. viz scénáře Validace poloţky.
Změnit menu Změna stávajícího záznamu o menu. Scenarios
Změna menu - OK - Basic Path Notes
1. INLCUDE Zobrazit menu. 2. Provozní vybere volbu změna menu, 3. Systém zpřístupní všechny poloţky menu a jiné jeho údaje. 4. Provozní upravuje menu. Přidává, ubírá poloţky, mění údaje, dokud nepotvrdí, ţe je hotov. 5. Systém zkontroluje duplicitu poloţek v menu. 6. Systém zkontroluje, zda nekoliduje platnost menu. 7. Systém menu uloţí.
51 Scenarios
Návrat na seznam menu.
Změna menu - Chyba platnost - Alternate Notes
6a. Systém zjistí, ţe koliduje platnost menu. 1. Systém menu neuloţí. 2. Systém nahlásí chybu provoznímu. Pokračuje se na krok 4 hlavního scénáře.
Změna menu - Chyba poloţka - Alternate Notes
5a. Systém zjistí, ţe v menu poloţka jiţ je. 1. Systém poloţku menu neuloţí. 2. Systém ohlásí chybu. Pokračuje se na krok 4 hlavního scénáře.
Změnit položku menu Změna záznamu o u stávající poloţky menu. Scenarios
Změna poloţky menu - OK - Basic Path Notes
1. Provozní vybere volbu změnit poloţku, 2. Systém zobrazí formulář. 3. Provozní vyplní údaje. 4. INCLUDE Validace poloţky. 5. Systém poloţku uloţí. Návrat na seznam poloţek menu.
Změna poloţky menu - Chyba - Alternate Notes
4a. Pokud bude validace vyhodnocená jako chybná. viz scénáře Validace poloţky.
52
Zneplatnění položky menu Vybraná poloţka menu je označena jako neplatná (nedostupná). Tím se nedostane do aktuálního menu (můţe jich být i více), ve kterém je evidována. Scenarios
Zneplatnění poloţky - Ano - Basic Path Notes
1. Provozní vybere poloţku. 2. Provozní zvolí volbu zneplatnění poloţky. 3. Systém se zeptá, zda má poloţku zneplatnit. 4. Provozní volbu potvrdí. 5. Systém poloţku zneplatní (je neviditelná ve všech menu). Návrat na seznam poloţek menu.
Zneplatnění poloţky - Ne - Alternate Notes
4a. Provozní volbu nepotvrdí. 1. Systém poloţku ponechá beze změny. Návrat na seznam poloţek menu.
Zobrazit menu Zobrazit menu. Scenarios
Zobrazení menu - Basic Path Notes
1. Provozní vybere menu ze seznamu. 2. Provozní zvolí volbu prohlédnout menu. 3. Systém menu zobrazí.
Zpřístupnění položky menu Zpřístupnění nedostupné poloţky menu. Poloţka se tím opět začne zobrazovat v příslušném menu (můţe jich být i více), pro které je evidována. Scenarios
Zpřístupnění poloţky - Ano - Basic Path Notes
1. Provozní vybere poloţku v seznamu poloţek. 2. Provozní zvolí volbu zpřístupnění poloţky. 3. Systém se zeptá, zda má poloţku zpřístupnit.
53 Scenarios
4. Provozní volbu potvrdí. 5. Systém poloţku zpřístupní, čímţ se poloţka menu znovu objeví v relevantních menu. Návrat na seznam poloţek menu.
Zpřístupnění poloţky - Ne - Alternate Notes
4a. Provozní nepotvrdí. 1. Systém poloţku ponechá beze změny. Návrat na seznam poloţek menu.
54
Správa skladu
Figure: 3
Načíst čárový kód Načtení čárového kódu a jeho úprava (pomocí čtečky čárových kódů nebo ručně klávesnicí).
55 Scenarios
Načtení čárového kódu - Basic Path Notes
1. Systém vyzve provozního k načtení čárového kódu. 2. Provozní načte čárový kód. 3. Systém zaeviduje čárový kód. 4. Provozní potvrdí správnost čárového kódu. 5. Systém zvaliduje čárový kód. 6. Systém uloţí pro daný skladový záznam čárový kód.
Nevalidní čárový kód - Alternate Notes
5a. Systém upozorní provozního, ţe zadaný čárový kód není validní. 1. Systém nabídne provoznímu úpravu čárového kódu. Pokračuje krokem číslo 1 scénáře "Úprava čárového kódu".
Úprava čárového kódu - Alternate Notes
3a. Provozní vybere volbu "ručně editovat čárový kód". 1. Systém umoţní provoznímu ruční editaci. 2. Provozní provede změnu čárového kódu. 3. Provozní potvrdí provedenou změnu. Pokračuje krokem číslo 5 scénáře "Načtení čárového kódu".
Odpis suroviny Odpis suroviny v případě jejího zničení, v případě propadnutí trvanlivosti nebo v případě jiného poškození. Scenarios
Odpis suroviny - ANO - Basic Path Notes
1. Provozní vybere volbu "odpis suroviny". 2. Systém vypíše skladové záznamy. 3. Provozní vybere skladový záznam, pro který chce provést odpis. 4. INCLUDE Vybrat skladový záznam. 5. Provozní vyplní poţadované údaje o odpisované surovině. 6. Systém vyzve provozního, aby potvrdil vstupní údaje. 7. Provozní potvrdí vstup. 8. Systém zvaliduje vstupní údaje. 9. Systém uloţí záznam o odpisu. Návrat na seznam odpisů.
Odpis suroviny - NE - Alternate Notes
7a. Provozní nepotvrdí vstupní údaje. 1. Systém dále nepokračuje se zpracováváním poţadavku na zaevidování odpisu. Návrat na seznam odpisů.
56 Scenarios
Změnit údaje o odpisu suroviny - Alternate Notes
1a. Provozní vybere záznam o provedení odpisu suroviny ze skladu. 1. Provozní změní poţadované údaje o odpisu suroviny ze skladu. Pokračuje krokem číslo 6 scénáře "Odpis suroviny - ANO".
Chybné vstupní údaje - Alternate Notes
8a. Údaje vloţené provozním obsahují neplatné údaje nebo duplikují jiţ existující údaje. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje krokem číslo 3 scénáře "Odpis suroviny - ANO".
Odstranit stávající druh suroviny Odstranění stávajícího druhu suroviny. Scenarios
Odstranit druh suroviny - ANO - Basic Path Notes
1. Provozní vybere druh suroviny, který chce odstranit. 2. Systém se provozního dotáţe, zda má doopravdy odstranit vybraný druh suroviny. 3. Provozní potvrdí odstranění vybraného záznamu. 4. Systém odstraní vybraný záznam. Návrat na seznam druhů surovin.
Odstranit druh suroviny - NE - Alternate Notes
3a. Provozní nepotvrdí odstranění vybraného záznamu. 1. Systém dále neprování zpracovávání poţadavku na odstranění. Návrat na seznam druhů surovin.
Odstranit stávající důvod odpisu suroviny Slouţí k odstranění důvodu odpisu. Scenarios
Odstranit důvod odpisu - ANO - Basic Path Notes
1. Provozní vybere důvod odpisu, který chce odstranit.
57 Scenarios
2. Systém se provozního dotáţe, zda má doopravdy odstranit vybraný záznam. 3. Provozní potvrdí odstranění vybraného záznamu. 4. Systém odstraní vybraný záznam. Návrat na seznam důvodů odpisů.
Odstranit důvod odpisu - NE - Alternate Notes
3a. Provozní nepotvrdí odstranění vybraného záznamu. 1. Systém dále neprování zpracovávání poţadavku na odstranění. Návrat na seznam důvodů odpisů.
Přidat nový skladový záznam Přidání nového skladového záznamu o surovině (vytvoření nové skladové karty) zahrnuje načtení čárového kódu dané suroviny a případnou editaci dalších informací. Scenarios
Vytvořit nový skladový záznam o surovině - ANO - Basic Path Notes
1. Provozní vybere volbu "přidat nový skladový záznam". 2. Systém vyzve provozního k vyplnění vstupních údajů. 3. Provozní zadá poţadované skladové údaje. 4. INCLUDE Načíst čárový kód. 5. Systém vyzve provozního k potvrzení zadaných údajů. 6. Provozní potvrdí vloţené údaje. 7. Systém zvaliduje vloţené skladové údaje. 8. Systém vloţí nový skladový záznam. Návrat na seznam skladových záznamů.
Vytvořit nový skladový záznam o surovině - NE - Alternate Notes
6a. Provozní nepotvrdí vloţené údaje. 1. Systém dále nezpracovává poţadavek na vytvoření nového skladového záznamu. Návrat na seznam skladových záznamů.
Chybné vstupní údaje - Alternate Notes
7a. Údaje vloţené provozním obsahují neplatné údaje nebo duplikují jiţ existující údaje. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje se krokem 3 scénáře "Vytvořit nový skladový záznam o surovině - ANO".
58
Příjem suroviny na sklad Příjem suroviny na sklad. Příjem probíhá tak, ţe se na skladovém záznamu dané suroviny aktualizuje její aktuální mnoţství. Pokud pro danou surovinu neexistuje skladový záznam, tak se nejdříve musí vytvořit daný skladový záznam. Scenarios
Příjem suroviny - ANO - Basic Path Notes
1. Provozní vybere volbu "příjem suroviny". 2. Systém vyzve provozního, aby vybral skladový záznam, pro který chce provést příjem. 3. INCLUDE Vybrat skladový záznam. 4. Provozní vyplní poţadované údaje. 5. Systém vyzve provozního, aby potvrdil vstupní údaje. 6. Provozní potvrdí vstupní data. 7. Systém zvaliduje vstupní údaje. 8. Systém uloţí daný záznam. Návrat na seznam skladových příjmů.
Příjem suroviny - NE - Alternate Notes
6a. Provozní nepotvrdí vstupní data. 1. Systém dále nezpracovává poţadavek na vytvoření záznamu o skladovém příjmu. Návrat na seznam skladových příjmů.
Změna údajů o příjmu suroviny na sklad - Alternate Notes
1a. Provozní vybere jiţ evidovaný záznam o příjmu suroviny na sklad. 1. Provozní změní poţadované údaje o příjmu na sklad. Pokračuje krokem číslo 5 scénáře "Příjem suroviny - ANO".
Chybné vstupní údaje - Alternate Notes
7a. Údaje vloţené provozním obsahují neplatné údaje nebo duplikují jiţ existující údaje. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje krokem číslo 3 scénáře "Příjem suroviny - ANO".
59
Smazat skladový záznam Odstranění existujícího skladového záznamu z evidence skladových záznamů. Scenarios
Smazat skladový záznam - ANO - Basic Path Notes
1. Provozní vybere skladový záznam ze seznamu skladových záznamů. 2. Provozní vybere volbu "odstranit skladový záznam". 3. Systém vyzve provozního k potvrzení poţadované operace. 4. Provozní potvrdí poţadovanou operaci. 4. Systém smaţe daný skladový záznam. Návrat na seznam skladových záznamů.
Smazat skladový záznam - NE - Alternate Notes
4a. Provozní nepotvrdí smazání záznamu. 1. Systém dále nepokračuje ve zpracovávání poţadavku. Návrat na seznam skladových záznamů.
Upravit skladový záznam Upravení stávajícího skladového záznamu. Scenarios
Upravit skladový záznam - ANO - Basic Path Notes
1. Provozní vybere skladový záznam ze seznamu skladových záznamů. 2. Systém vyzve provozního k úpravě poţadovaných údajů. 3. Provozní změní poţadované údaje. 4. INCLUDE Načíst čárový kód. 5. Systém vyzve vedoucího k potvrzení zadaných údajů. 6. Provozní potvrdí změněné údaje. 7. Systém zvaliduje změněné skladové údaje. 8. Systém upraví daný skladový záznam. Návrat na seznam skladových záznamů.
Upravit skladový záznam - NE - Alternate Notes
6a. Provozní nepotvrdí provedené úpravy. 1. Systém dále nepokračuje ve zpracovávání poţadavku. Návrat na seznam skladových záznamů.
Chybné vstupní údaje - Alternate Notes
7a. Údaje vloţené provozním obsahují neplatné údaje nebo duplikují jiţ existující úda-
60 Scenarios
je. 1. Systém upozorní provozního na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje krokem číslo 3 scénáře "Upravit skladový záznam - ANO".
Vybrat skladový záznam Vyhledání skladového záznamu za účelem aktualizace aktuálního mnoţství dané suroviny. Scenarios
Vybrat skladový záznam - ANO - Basic Path Notes
1. Systém vypíše skladové záznamy. 2. Provozní vybere hledaný skladový záznam. 3. Provozní potvrdí výběr daného skladového záznamu. 4. Systém vrátí vybraný skladový záznam. Návrat na další krok z volaného use-casu.
Vybrat skladový záznam - NE - Alternate Notes
3a. Provozní nepotvrdí výběr skladového záznamu. 1. Systém provozního upozorní, ţe nebyl vybrán ţádný skladový záznam. Návrat na předchozí krok volaného use-casu. (nový výběr skladového záznamu)
Vybrat skladový záznam podle čárového kódu - Alternate Notes
1a. Systém vyzve provozního, aby pomocí čtečky načetl čárový kód. 1. Provozní načte čárový kód. 2. Systém vyhledá odpovídající záznam. 3. KDYŢ existuje odpovídající záznam, tak: 3.1. Pokračuje se krokem číslo 3 scénáře "Vybrat skladový záznam - ANO". 4. KDYŢ neexistuje odpovídající záznam, tak: 4.1. Systém provozního upozorní, ţe pro daný čárový kód nenašel ţádný skladový záznam.
Vytvořit nový druh suroviny Kaţdá suroviny na skladu spadá do nějaké nadtřídy. Touto nadtřídou je druh suroviny, který slouţí k zjednodušení výběru. Pouţití: - seskupování a sumarizace dle druhu suroviny
61 - selektivní výběr - atd. Scenarios
Nový druh suroviny - ANO - Basic Path Notes
1. Provozní vybere volbu "nový druh suroviny". 2. Systém zobrazí formulář s poţadovanými pro vyplnění poţadovaných údajů. 3. Provozní vyplní poţadované údaje. 4. Provozní potvrdí zadané údaje. 5. Systém zvaliduje vstupní data. 6. Systém uloţí nový druh suroviny. Návrat na seznam druhů surovin.
Nový druh suroviny - NE - Alternate Notes
4a. Provozní nepotvrdí vstupní údaje. 1. Systém dále nepokračuje ve zpracovávání poţadavku na vloţení nového druhu suroviny. Návrat na seznam druhů surovin.
Chybné vstupní údaje - Alternate Notes
5a. Vstupní pole nejsou správně vyplněna údaji nebo nejsou vyplněna vůbec. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje krokem číslo 3 scénáře "Nový druh suroviny - ANO".
Vytvořit nový důvod odpisu suroviny Slouţí pro vytváření nových důvodů, které zapříčinili odpis dané suroviny. Scenarios
Nový důvod odpisu - ANO - Basic Path Notes
1. Provozní vybere volbu "nový důvod odpisu". 2. Systém zobrazí formulář s poţadovanými pro vyplnění poţadovaných údajů. 3. Provozní vyplní poţadované údaje. 4. Provozní potvrdí zadané údaje. 5. Systém zkontroluje vstupní údaje. 6. Systém uloţí nový druh suroviny. Návrat na seznam důvodů odpisů.
Nový důvod odpisu - NE - Alternate Notes
4a. Provozní nepotvrdí vstupní údaje. 1. Systém dále nepokračuje ve zpracovávání poţadavku na vloţení nového důvodu odpisu suroviny.
62 Scenarios
Návrat na seznam důvodů odpisů.
Chybné vstupní údaje - Alternate Notes
5a. Vstupní pole nejsou správně vyplněna údaji nebo nejsou vyplněna vůbec. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje krokem číslo 3 scénáře "Nový důvod odpisu - ANO".
Výdej suroviny Výdej suroviny ze skladu. Scenarios
Výdej suroviny - ANO - Basic Path Notes
1. Provozní vybere volbu "výdej suroviny ze skladu". 2. Systém vyzve provozního, aby vybral skladový záznam, pro který chce provést výdej ze skladu. 3. INCLUDE Vybrat skladový záznam. 4. Provozní vyplní poţadované údaje. 5. Systém vyzve provozního, aby potvrdil vstupní údaje. 6. Provozní potvrdí vstupní data. 7. Systém zvaliduje vstupní údaje. 8. Systém uloţí daný záznam o provedení výdeje. Návrat na seznam výdejů surovin.
Výdej suroviny - NE - Alternate Notes
6a. Provozní nepotvrdí vstupní údaje. 1. Dále se nepokračuje ve zpracovávání poţadavku na uloţení skladového výdeje. Návrat na seznam výdejů surovin.
Změna údajů o provedení výdeje ze skladu - Alternate Notes
1a. Provozní vybere záznam o výdeji suroviny ze skladu. 1. Provozní změní poţadované údaje o výdeji suroviny ze skladu. Pokračuje krokem číslo 5 scénáře "Výdej suroviny - ANO".
Chybné vstupní údaje - Alternate Notes
7a. Vstupní pole nejsou správně vyplněna údaji nebo nejsou vyplněna vůbec. 1. Provozní je upozorněn na neplatný vstup. 2. Systém umoţní provoznímu změnit vstupní údaje. Pokračuje krokem číslo 3 scénáře "Výdej suroviny - ANO".
63
Příloha D – Doménový model
64
65
Příloha E – Obsah přiloženého CD Adresářová struktura
/dokumentace o Text bakalářské práce v PDF o Analýza a návrh provedený Enterprise Architectu (soubor designModel.EAP) o JavaDoc skladového a administrativního modulu
/SQL o Skript pro vytvoření databáze (soubor createDatabase.sql)
/manager o RestauraceFELManager.bat – dávkový soubor pro spuštění klientského modulu o /config
config.xml – konfigurační soubor
Adresář s tiskovými šablonami
o app.policy o RestauraceFELManager.jar
/server o RestauraceFELServer.bat – dávkový soubor pro spuštění serveru o /config
hibernate.cfg.xml – konfigurační soubor pro Hibernate
o app.policy o RestaurantFELServer
RestauraceFELManager – projekt klientského modulu v Netbeans 6.5.1
RestaurantFELServer – projekt serverové aplikace v Netbeans 6.5.1
66
