Úprava, dokončení a rozšíření restauračního systému CashBob umožňující jeho distribuci a nasazení do běžného provozu

i

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Úprava, dokončení a rozšíření restauračního systému CashBob umožňující jeho distribuci a nasazení do běžného provozu Štěpán Tesař

Vedoucí práce: Ing. Martin Komárek

Studijní program: Softwarové technologie a management, Bakalářský Obor: Softwarové inženýrství 19. května 2012

iv

v

Poděkování Děkuji svým rodičům za veškerou podporu při studiu, panu Komárkovi za příležitost a dohled nad touto prací, pánům a kolegům Lukáši Tůmovi a Tomáši Apeltauerovi za spolupráci na systému CashBob, všem kantorům za výzvy a všem spolužákům za příjemné chvíle a vzájemnou pomoc při bakalářském studiu.

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).

V Děčíně dne 19. května 2012

.............................................................

viii

Abstract In this bachelor’s work, several structural and functional changes were made in the cashier module of restaurant system CashBob [32], moving it to the state comparable with commercial systems of same kind, and with regards to main use cases. Changes were directed in the manner which should allow an easy use of the program and its deployment to the real workspace, which included changes to the main application and also little to its server part. These changes include all from data-model alternations, changes of logic in processing and passing of information, to unification and optimization of graphical user interface, which also required significant modifications in the source code, making it more meeting with modern principles and conventions.

Abstrakt V rámci této bakalářské práce došlo k přepracování struktury a funkcionality pokladního modulu restauračního systému CashBob [32] do podoby srovnatelné s komerčními systémy stejného druhu, zohledňující hlavní případy užití. Úpravy byli mířeni tak, aby bylo používání programu pohodlné a aplikace mohla být nasazena do skutečného provozu, což zahrnovalo úpravy hlavní aplikace a částečně také serverové části programu. Provedené úpravy zahrnují vše od úprav v datovém modelu aplikace, logice zpracování a předávaní informací až po sjednocení a optimalizaci grafického uživatelského prostředí, přičemž byla také výrazně upravena struktura zdrojového kódu tak, aby vyhovoval moderním zásadám a konvencím.

ix

x

Obsah 1 Úvod

1

2 Popis problému, specifikace cíle 2.1 Úprava GUI a funkcionality . . . . . . . . . . . . 2.2 Úprava zdrojového kódu . . . . . . . . . . . . . . 2.2.1 Předchozí úpravy . . . . . . . . . . . . . . 2.2.2 Správa kódu . . . . . . . . . . . . . . . . . 2.2.3 Práce v kódu . . . . . . . . . . . . . . . . 2.3 Vytvoření možnosti snadného nasazení programu

. . . . . .

3 3 4 4 5 5 5

. . . . . . . . . . . . . .

7 7 8 8 9 10 11 12 13 14 14 14 15 15 15

. . . . . . . .

17 17 17 18 19 19 21 21 22

3 Analýza a návrh řešení 3.1 Analýza GUI . . . . . . . . . . . . . . . . . 3.1.1 Lokalizace . . . . . . . . . . . . . . . 3.1.2 Zobrazení dle autorizace . . . . . . . 3.1.3 Tlačítka . . . . . . . . . . . . . . . . 3.1.4 Virtuální klávesnice . . . . . . . . . 3.1.5 Hlavní okno . . . . . . . . . . . . . . 3.1.6 Pokladní modul - struktura ovládání 3.1.7 Pokladní modul - vizuální podoba . 3.1.8 Drobné problémy v GUI . . . . . . . 3.1.9 GUI serveru . . . . . . . . . . . . . . 3.2 Úprava kódu . . . . . . . . . . . . . . . . . 3.3 Instalační nástroj . . . . . . . . . . . . . . . 3.3.1 Cílový systém . . . . . . . . . . . . . 3.3.2 Požadované akce . . . . . . . . . . . 4 Realizace 4.1 Úpravy GUI a Funkcionality . . 4.1.1 Lokalizace . . . . . . . . 4.1.2 Zobrazení dle autorizace 4.1.3 Tlačíka a ikony . . . . . 4.1.4 Virtuální klávesnice . . 4.1.5 Výběrové seznamy . . . 4.1.6 Okno nahrávání . . . . . 4.1.7 Přihlašovací formulář . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

xi

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

. . . . . .

. . . . . . . . . . . . . .

. . . . . . . .

xii

OBSAH

4.2

4.1.8 Hlavní menu . . . . . 4.1.9 Pokladní modul . . . . 4.1.10 Vyřazené funkce . . . Instalační balík . . . . . . . . 4.2.1 Příprava projektu . . . 4.2.2 Vytvoření instalátoru . 4.2.3 Nainstalovaná aplikace 4.2.4 Problémy . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

5 Testování 5.1 Snížení počtu kroků . . . . . . . . . . 5.1.1 Měření . . . . . . . . . . . . . . 5.1.2 Závěr měření . . . . . . . . . . 5.2 Testování GUI . . . . . . . . . . . . . 5.2.1 Manuální testování úprav . . . 5.2.2 Automatizované testování GUI 5.3 Testování instalátorů . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . .

22 22 27 28 28 29 29 30

. . . . . . .

31 31 31 33 33 33 33 34

6 Závěr

35

A Obrázky

41

B UML diagramy

49

C Instalační a uživatelská příručka C.1 Úvod . . . . . . . . . . . . . . . . . . C.2 Popis software . . . . . . . . . . . . . C.2.1 Technické detaily projektu . . C.2.2 Technické detaily instalátorů C.3 Instalační příručka . . . . . . . . . . C.3.1 Instalace . . . . . . . . . . . . C.4 Uživatelská příručka . . . . . . . . . C.4.1 První spuštění . . . . . . . . C.4.2 Ovládání aplikace . . . . . . C.5 Závěr . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

53 54 54 54 54 55 55 55 55 56 57

D Obsah přiloženého CD 59 D.1 Struktura složek a souborů . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 E Rešerše GUI restauračních systémů

61

F CashBob - Analýza GUI

75

G CashBob - Návrh optimalizace GUI

85

H Návrh úpravy slevového systému

95

Kapitola 1

Úvod Program CashBob [32] byl v základu poměrně jednoduchý program, který původně umožňoval více či méně primitivní zprávu účtenek a objednávek. Na programu již v minulosti pracovalo mnoho týmu i jednotlivců, kteří přidávali funkcionalitu či opravovali chyby předchozích týmů. Postupně se tak z CashBob stala rozsáhlá aplikace s několika moduly, obsahujícími nástroje pro komplexní zprávu celého podniku. K dotykové pokladní části přibily moduly pro organizaci skladu, stolů či menu. V průběhu vývoje programu však málokdo myslel na ty, kteří budou systém vyvíjet po něm. Struktura kódu byla tedy extrémně nepřehledná, nedodržovala téměř žádné zásady, a několik týmů muselo pouze upravovat kód tak, aby bylo vůbec možné systém dále udržovat, včetně týmu jehož jsem byl součástí v pátém semestru bakalářského studia. Z práce v tomto týmu vzešel námět na softwarový projekt, který dále pokračoval v následujícím, šestém, semestru, již přetransformován do bakalářské práce. Program CashBob je vyvíjen v jazyce Java [14] a je založen na rozdělení server-klient, přičemž serverová aplikace byla koncipována jako čistě funkční, bez uživatelského rozhraní, a slouží především k provádění aplikační logiky a komunikace s databází, zatímco klientská aplikace, která se k serveru připojuje skrze síťové rozhraní, prezentuje GUI1 pro uživatele. Část klientské aplikace je pak koncipována jako dotyková, tedy má umožňovat pohodlný provoz na dotykových terminálech. Dotykovými částmi GUI jsou za prvé hlavní okno klienta, které obsahuje formulář pro přihlášení a poté jakýsi rozcestník do zbytku aplikace. Za druhé je to pokladní modul, který umožňuje evidovat objednávky zboží na účtenky, které mohou být asociovány se zákazníkem či stolem. Podrobné schéma entit a jejich vazeb lze prozkoumat v UML diagramu B.1 v příloze B - "UML diagramy". Větší část bakalářské práce se pak zabývá především úpravou klientské části aplikace, a to hlavně právě dotykové části GUI. Spíše než o implementaci nové funkcionality šlo o dokončení a ladění stávajících načatých funkcí a jejich co nejpřehlednější nabídnutí uživateli skrze pohodlné GUI, a to bohužel i za cenu oželení některých stávajících funkcí, jejichž přestavění na přijatelnou úroveň by bylo příliš časově náročné (viz 4.1.10).

1

Graphical User Interface, neboli grafické uživatelské rozhraní

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Popis problému, specifikace cíle Práci lze rozdělit na několik tematicky odlišných částí. Jak již bylo řešeno v úvodu, zásadní část tvoří úprava grafického prostředí, s čímž úzce souvisí úprava funkcionality, která je uživateli skrze GUI1 prezentována. S tím pak volněji souvisí úprava kódu z hlediska jeho čitelnosti, přehlednosti a míře dodržování programátorských zásad. Naopak zcela odlišným problémem je pak otázka zabalení programu jako celku a jeho snadné nasazení k zákazníkovi, u kterého se předpokládá pouze základní znalost práce s výpočetní technikou.

2.1

Úprava GUI a funkcionality

Již v hlavičce této kapitoly je uvedeno, že úprava funkcí úzce souvisí s grafickým prostředím, jelikož uživatel k funkcím jinak nemůže přistupovat. Logika funkcí vyžaduje pouze vstup informací od uživatele, který potom zpracuje a případně upraví GUI do nového stavu. Hlavním problémem systému CashBob, z uživatelského hlediska, byla jeho ne-konzistence a nepřehlednost. Dlouhodobé použití prakticky nebylo možné z důvodu chybějících popisků a nesmyslně strukturovaných nabídek či formulářů. Z obrázku A.2 v příloze A, je příkladně vidět důsledek postupného vývoje skrze několik týmů, při němž se každý jednotlivý tým neodvážil udělat radikálnější úpravy. Ohromná modrá plocha je prakticky nijak nevyužitá, jelikož všechny tlačítka spustí nové okno (například pokladní modul), či drobný dialog (například nastavení). Tato plocha je pouze historickým reliktem, jelikož původně obsahoval program pouze pokladní část, a když pak došlo k přidání dalších funkcí a jejich separaci do modulů, přejalo hlavní okno grafické prostředí původního, tedy pokladního, modulu. Je také nutné podotknout, že původní tlačítka neobsahovali žádné popisky a z obrázků tlačítek nebylo vždy snadné odhadnout jejich funkci. Hlavním cílem bylo tedy v tomto směru zpřehlednění prostředí programu. Tato práce se zaměřila především na pokladní modul, jelikož je jako jediný koncipován pro plně dotykové ovládání, bude využíván přímo "na place"a v nejvíce hektických situacích, a vyžaduje tedy největší přehlednost. Kromě toho obsahují ostatní moduly (tedy manažerský a skladový modul) vesměs pouze formuláře s textovými vstupy, které by se vzhledem k jejich funkci optimalizovali obtížně, pokud by zde vůbec nějaký prostor k optimalizaci byl. Dalším důvodem byl také fakt, že ve skladovém modulu prováděl úpravy kolega Tomáš Apeltauer, a docházelo by ke kolizím práce. 1

Graphical User Interface, neboli grafické uživatelské rozhraní

3

4

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

S opatrností lze říci, že čím je systém přehlednější, tím méně kliknutí počítačové myši (nebo v případě dotykového terminálu, doteků prstem) je nutné k přechodu do kýženého stavu aplikace. Je nutné mít na paměti, že přehlednost samozřejmě záleží na mnoha jiných faktorech, jako je například rozvržení ovládacích prvků, jejich vizuální podoba a případně návodnost, ať již pomocí obrázku či popisku. Tyto faktory se však obtížně měří. Bylo by nutné sestavit testovací skupiny pro staré a nové grafické rozhraní, a nechat je systém využívat a zaznamenávat časy nutné ke stejným operacím v obou verzích GUI. Počet nutných kliknutí počítačovou myší (dále jen "kliknutí"), obecně zkracuje nutnou dobu nejvíce a to z prostého důvodu. Jedno kliknutí totiž vyžaduje zorientovat se v prostředí nového stavu aplikace (řekněme, že GUI se po každém kliknutí výrazně změní), nalezení ovládacího prvku vedoucího k zamýšlenému stavu (například tlačítko pro vytvoření objednávky), přesunutí kurzoru myši na tento ovládací prvek a jeho aktivace. Především orientace a nalezení ovládacího prvku zaberou uživateli, který nemá se systémem dlouhodobé zkušenosti, nejvíce času (řádově vteřiny). Po delším užívaní systému pak druhé dva body, tedy přesunutí a kliknutí, především obtěžují a dávají prostor k chybám. Mějme tedy počet kliknutí jako měrnou jednotku přehlednosti, kterou použijeme při srovnání původního a nového grafického rozhraní. Ideálním cílem pro výsledné GUI byla vytyčena hranice poloviny kliknutí pro každou funkci z neutrálního stavu aplikace, tedy takového, v jakém je zanechán po dokončení předchozí akce.

2.2

Úprava zdrojového kódu

Kromě přehlednosti vstupů v grafickém rozhraní je pak podstatná kvalita implementace. Původní systém obsahoval výrazné duplicity kódu, a nedodržoval základní konvence přehledného a objektového modelování, jako jsou low coupling[19] a high cohesion[18], či dodržení návrhu model-view-controller[21]. Program také chybně prováděl aplikační logiku již v klientské části, což má již z principu zajišťovat server.

2.2.1

Předchozí úpravy

Úpravou dodaného kódu se zabýval, již při předmětu SI2 [13], tým obsahující kromě mé osoby také kolegy Lukáše Tůmu, Tomáše Apeltauera a část semestru také Marcela Soukeníka, který však před dokončením projektu ukončil studium a jeho práci převzali ostatní. Každý člen týmu upravil část aplikace tak, aby co nejvíce odpovídala vyjmenovaným zásadám. Kód bohužel nebylo možné převést zcela, jelikož některé části programu obsahovali zcela odlišné přístupy ke stejným problémům (například validace vstupu z formulářů), což někdy může být výhodné, ale velmi znesnadňuje čitelnost kódu. Vyjma Marcela Soukeníka pak pracovali všichni členové týmu na programu také v rámci předmětu Softwarový projekt [10], po jehož ukončení byla další činnost zaštítěna právě bakalářskými pracemi. Lukáš Tůma měl primárně vytvořit mobilního klienta a měl tak tedy na starost také síťovou komunikaci mezi serverem a klientem. Tomáš Apeltauer se chopil hlavně skladového modulu a napojení periferních zařízení, například tiskárny účtenek. Mé zaměření pak bylo na pokladní modul a hlavní okno. V rámci kolektivních prací pak probíhali pravidelné schůze, a to každý čtvrtek, po většinu semestru.

2.3. VYTVOŘENÍ MOŽNOSTI SNADNÉHO NASAZENÍ PROGRAMU

2.2.2

5

Správa kódu

Jelikož na programu pracovalo více lidí najednou, bylo nutné použití správce týmové práce, kterým se stal git s použitím webové aplikace GitHub [32], který slouží ke kontrole změn v kódu provedenou více lidmi najednou. Web GitHub pak poskytuje také správu úkolů a chyb, pomocí tzv. issues, které lze třídit do milníků. Pomocí milníků a značek bylo možné si issues třídit mezi více lidí, a každý tedy při práci sledoval pouze ty své. Vykonaná práce se zaznamenávala pomocí plnění jednotlivých issues a také zápisem do společného dokumentu na webu Google Drive (dříve Google Docs) [30]

2.2.3

Práce v kódu

V průběhu další práce bylo tedy nutné se stále soustředit na možnosti vylepšení struktury kódu, jeho čitelnosti, odstranění duplicit a korektním užívání návrhových vzorů [25] a principů objektového programování [23]. Cílem bylo tedy zanechat ve výsledné revizi okomentovaný a čitelný kód, který bude přehledný i pro nezasvěceného programátora a bude v něm možné rozeznat logicky oddělené části.

2.3

Vytvoření možnosti snadného nasazení programu

U každé aplikace je nutné vyřešit otázku, jak zprovoznit program na neznámém stroji u zákazníka, u nějž není možné předpokládat hlubší znalosti počítačů, natož pak programovacích jazyků. Jinou otázkou je pak způsob dopravení aplikace k zákazníkovi. Tímto problémem se však práce nezabývá a zůstáváme tedy u předpokladu, že k zákazníkovi se libovolným způsobem dostanou námi zvolené soubory a případná dokumentace. Jelikož je aplikace vyvíjena v jazyce Java [14], vyžaduje na cílovém počítači funkční prostředí JRE2 [9]. Serverová aplikace vedle toho využívá k uchování dat databázový server, který je tedy opět u koncového zákazníka nutné zprovoznit a nakonfigurovat tak, aby s ním aplikace mohla komunikovat. Stále je pak třeba mít na paměti, že uživatel bude na tyto úkony pravděpodobně sám. Podstatné také je, že vytvořením vhodných omezení, jako je například druh a verze operačního systému, můžeme vytvořit vhodné předpoklady, které bude cílový počítač splňovat. S těmito předpoklady pak není příliš náročné vytvořit instalační balík, který všechny nutné operace provede sám automaticky, což je ostatně přesně definovaný cíl této části práce.

2

Java Runtime Environment - prostředí nutné ke spuštění a běhu aplikace psané v Java

6

KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

Kapitola 3

Analýza a návrh řešení Tato část je věnována zanalyzování původního programu, nalezení problémových míst, ve kterých jsou nutné úpravy a návrh jejich možných řešení. Stejně tak se zde vyskytují návrhy na nové vylepšení a celkový přístup k úpravám v systému. Jako výchozí verze programu je považován program dodaný panem ing. Martinem Komárkem již na začátku akademického roku 2011/2012 jako podklad pro práci v předmětu A7B36SI2 [13]. Tato dodaná verze je dohledatelná jako nultá revize v repositáři projektu [32] a vypsané nedostatky je možné v ní ověřit. Tato revize obsahuje rozdělení programu na serverovou a klientskou část, kde klientská část je pak dále rozdělena na pod-části, označované také jako "moduly". V dodané revizi jsou pak dostupné moduly "pokladna", "manažer"a "sklad".

3.1

Analýza GUI

Následující sekce je výstupem analýzy a návrhové části vývoje grafického uživatelského rozhraní pokladního systému CashBob. Analýza i Návrh byly vypracovány již při pracích v rámci předmětu A7B36SI2 [13], prováděné týmem zmíněným v kapitole 2.2(Lukáš Tůma, Tomáš Apeltauer, Marcel Soukeník a Štěpán Tesař), vedle nichž probíhala první část této práce, tehdy zaštítěna předmětem A7B36PRO [10]. Některé části textu této sekce jsou pak přejaty nebo vycházejí z dokumentů shrnujících poznatky pro účely zmíněných předmětů. Jedná se o analytický dokument "CashBob - Analýza GUI"v příloze F a návrhový dokument "CashBob - Návrh optimalizace GUI"v příloze G. Za účelem co nejideálnějšího návrhu řešení nalezených problémů byla vypracována rešerše uživatelských prostředí existujících restauračních systémů, připojená k této práci jako příloha E. Tato rešerše sloužila již jako inspirace pro výše zmíněný návrhový dokument nacházející se v příloze G, a poté po dobu celé práce vždy pro nalezení ideálního východiska na základě zkušeností ze zkoumaných programů. Na základě této rešerše je pak možné doplnit seznam problémů, nalezených prostým spuštěním a vyzkoušením si práce s programem, o hlubší problémy, které lze vidět až při srovnání systému s jinými, podobnými, programy. Vyjmenované problémy jsou přibližně seřazené dle své rozsáhlosti. Nejprve jsou tedy rozebrány chyby zasahující celý program, poté problémy jednotlivých částí až po výraznější konkrétní problémy jednotlivých komponent grafického prostředí. Stojí za zmínku, že mluvíme-li o analýze existujícího grafického prostředí, vždy se pohybujeme v klientské části

7

8

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

programu. Serverová část v dodané verzi neobsahuje žádné grafické prostředí. Návrhu grafického prostředí serveru je pak věnován poslední bod této sekce.

3.1.1

Lokalizace

V systému byl již v dodané verzi implementován systém pro lokalizaci grafických prvků, na základě jazyka nastaveného v konfiguračním souboru. Změnu jazyka lze provést přímo z programu pomocí příslušného dialogu, což bylo možné již dodané verzi. Dialog pro změnu jazyku je pak příkladem jedné z mála komponent, která byla změnou jazykového nastavení ovlivněna. Téměř plně lokalizována1 byla pouze skladová část. Částečně pak lokalizaci podléhalo hlavní okno, na rozdíl od manažerského a pokladního modulu, ve kterých nelze nalézt téměř žádnou snahu o lokalizování. Viz Tento stav je zřejmě důsledkem historie vývoje. Nástroje pro lokalizaci pravděpodobně do systému přivedl stejný člověk, který vytvářel skladový modul, a proto ho ve "svém“ modulu použil. Úlomky lokalizace v jiných částech pak mohou být důsledkem nutnosti stejného člověka zasáhnout při své práci i mimo jeho hlavní pole působnosti. Možnost lokalizovat si uživatelské prostředí do vlastního jazyka je nepochybně užitečná vlastnost jakéhokoliv programu, a v moderních aplikacích je pak téměř nezbytná. Systém pro lokalizaci byl v dodaném programu funkční, a proto by bylo nelogické ho nevyužít pro dokončení lokalizace zbytku systému. V základní verzi jsou pro již lokalizované části dostupné jazyky čeština a angličtina, které je možné rozšířit jednoduchým zásahem do konfiguračního souboru a dopsání nutných slovníků. Šlo by však o čistě rutinní a časově náročnou práci spočívající v překladu všech hesel v původních slovnících, což pro tuto práci není zcela vhodné využití pracovního nasazení. Rozšíření sady jazyků tedy, na rozdíl od lokalizace zbytku systému, nebylo považováno za nezbytné.

3.1.2

Zobrazení dle autorizace

V programu je implementována kontrola uživatelského přístupu na základě rolí, které jsou uživateli přiděleny. Tato kontrola však v původní verzi funguje tak, že uživatel má přístupné všechny funkce, a zda má právo na jejich provedení, se kontroluje pokaždé, kdy příslušný ovládací prvek uživatel aktivuje. Pokud uživatel nemá požadované právo, je někdy zobrazena chybová hláška, a jindy pak přídavné přihlášení, které umožní skrze danou kontrolu projít pomocí přihlašovacích údajů jiného uživatele. Po pohledu do kódu je však způsob dodatečného přihlašování velmi nepřehledný, a jeho efekt na systém nejasný. Implementační problémy není problém překonat, ale z uživatelského hlediska je různorodost kontroly přístupu k funkcím poněkud nepříjemná. Dalším hlediskem je pak přehlednost. Pracovní plocha zaplněná tlačítky, které po stisknutí ne jen, že neprovedou požadovanou akci, ale navíc vyžadují potvrzení dialogu, aby bylo možné pokračovat v práci (ať již chybového dialogu, nebo dialogu pro sekundární přihlášení). Je také nutné zamyslet se nad vlastním smyslem kontrolovaného přístupu k funkcím programu. Předpokládá se, že uživateli budou odepřeny práva k funkcím, které nejsou pro jeho práci nutné, tedy že například barman nepotřebuje funkce, které vyžaduje skladník. Z hlediska bezpečnosti je 1

tedy všechny zobrazované texty jsou v nastaveném jazyce

3.1. ANALÝZA GUI

9

pak tato kontrola zcela logická, aby si různé role pracovníků nemohli vzájemně narušovat práci, případně různým způsobem funkcí pro ně neurčených nezneužívali. Z výše uvedených důvodů lze dojít k závěru, že není nutné uživateli tyto funkce vůbec skrze uživatelské rozhraní prezentovat. Ne jen, že se tím uživatelské rozhraní pro daného uživatele zpřehlední, ale také odpadne nutnost kontroly práva při každém stisknutí tlačítka, jelikož uživateli nebudou tlačítka (či jiné ovládací prvky), na které nemá právo, vůbec dostupná. Jelikož lze každému uživateli přiřadit více rolí, není pak nutné přidávat celé roli další právo, pokud chceme určitou funkci povolit jen části uživatelů. Není ani nutné vytvářet roli s celou sadou původních práv, ale pouze roli s právy, které jsou oproti původní roli na víc, a poté uživateli přiřadit původní, i tuto novou roli. Tato možnost řeší případné pochybnosti o vhodnosti návrhu nezobrazovat ovládací prvky vedoucí na funkce, ke kterým nemá uživatel právo. Pokud by totiž padl argument, že se tím mění uživatelské prostředí, a ztrácí tak konzistenci, je možné oponovat, že jednotliví uživatelé budou mít "své"prostředí vždy stejné, tedy takové, podle práv které mají přiděleny. Pokud se pak danému uživateli práva změní, změní se tím pouze jeho uživatelské prostředí a vzhledem k tomu, že k takovým změnám nebude pravděpodobně docházet příliš často (možné situace jsou například povýšení, či změna pozice pracovníka), je pak toto řešení lepší, než zobrazovat všem uživatelům všechny ovládací prvky, a polovinu z nich vést na chybový dialog.

3.1.3

Tlačítka

Tento problém se týká především tlačítek určených k ovládání dotykem, tedy tlačítek v základním oknu klienta (přihlášení, nastavení a spouštění modulů) a v pokladním modulu. Jde čistě o vizuální podobu těchto ovládacích prvků, která nijak, nebo jen minimálně, řekne uživateli, jakou funkci dané tlačítko spustí. Již při naprostém počátku práce na tomto programu, byl problém orientovat se v prostředí pouze pomocí těchto tlačítek. Práce byla tak nepříjemná a ne-návodnost tlačítek tak matoucí, že se nakonec muselo sáhnout k úpravě samotných obrázků, do kterých byli dopsáni popisky toho, co jaké tlačítko znamená. Toho bylo dosaženo přímo úpravou samotného rastrového souboru, ze kterého je obrázek načítán, tedy úprava, kterou již na úrovních kódu nelze nijak změnit. Tyto obrázky s provizorními popisky jsou již součástí nulté revize, jelikož na programu probíhala drobná analytická a opravná činnost a ještě před založením aktuálně využívaného repositáře. Tlačítka je tedy nutné doplnit o popisek, nebo vytvořit dostatečně návodné obrázky, se kterými si uživatel bude schopen asociovat dané funkce. Pokud by bylo přikročeno k popiskům, je jasné že musí podléhat kontrole lokalizačního nástroje, tedy že se bude zobrazovat popisek ve zvoleném jazyce. Nejde však o náročný požadavek, jelikož lokalizace popisku tlačítka se implementačně nijak neliší od lokalizace jakékoliv jiné komponenty grafického prostředí. Návrhy podoby tlačítek se pak může lišit v pokladním modulu a v základním okně, jelikož každá z těchto částí programu má silně odlišnou funkci. Dále se tedy návrhem tlačítek zabývají zvlášť pro obě části podkapitoly 3.1.5 pro základní okno a 3.1.7 pro pokladní modul.

10

3.1.4

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

Virtuální klávesnice

Zde se opět jedná pouze o dotykem ovládané části, tedy stejně jako v předchozí podkapitole o pokladní modul a základní okno klienta. Při návrhu úprav klávesnice se lze inspirovat poznatky z rešerše (viz příloha E) zmíněné v úvodu této sekce. Kapitola 3.4 v této rešerši se přímo zabývá problematikou zobrazení klávesnice. Prvním podstatným závěrem je, že přítomnost virtuální klávesnice je zcela nezbytná, jelikož u dotykových terminálů nelze implicitně spoléhat na přítomnost hardwarové klávesnice. Z tabulky k uvedené kapitole v rešerši lze pak srovnat jednotlivé detaily virtuálních klávesnic. Pocit z jednotlivých řešení je pak shrnut v kapitole 4.2 rešerše, a lze z něj vyčíst několik principů, kterých by se měla ideální virtuální klávesnice držet. Virtuální klávesnice je v původní verzi programu řešena zvlášť v každém místě, kde je jí třeba. Zobrazená klávesnice sice na všech místech využívá stejnou třídu, ale téměř nikde není klávesnice zobrazena na stejné pozici. Písmena jsou tedy vždy na jiném místě obrazovky, a je nemožné si tak na psaní pomocí virtuální klávesnice zvyknout. Každý formulář, který klávesnici využívá, si zbytečně uchovává vlastní instanci klávesnice. Jak ukazuje rešerše, odpovídá toto řešení tomu nejhoršímu možnému. Mezi testovanými programy se nacházela podobně vyřešená klávesnice, a celkovou práci s programem tento fakt extrémně znepříjemnil. Klávesnice by naopak měla v ideálním případě vypadat vždy stejně, zobrazovat písmena pořád na stejné pozici a ve stejných rozměrech. Co se pak přítomnosti klávesnice týče, nejhorším možným řešením je zobrazovat klávesnici neustále. Tím pádem klávesnice zabírá drahocenný prostor, který může být využit vhodnějším způsobem (například roztažením ostatních ovládacích prvků, takže je dotykové ovládání pohodlnější). Vhodnější je pak zobrazovat klávesnici pouze pokud je vyžadován vstup, a to ideálně automaticky, tedy tak, že uživatel nemusí klávesnici vyvolat sám. Zde se kromě rešerše možné inspirovat moderními dotykovými telefony či tablety, ve kterých klávesnice s vlastním textovým polem překryje původní obsah, uživatel zadá vstup do onoho vlastního pole klávesnice a až po stisknutí příslušné klávesy (většinou Enter), dojde k nakopírování vstupu do původního textového pole. Tento přístup je jednak osvědčený, a díky tomu, že klávesnice nevyžaduje pohled na původní obsah obrazovky, může být libovolně veliká, a tedy dostatečně velká pro pohodlný dotyk. Dále je z rešerše patrné, že zobrazovat vždy klávesnici vybavenou všemi tlačítky (tak jako je to v původní verzi CashBob) není vhodné, jelikož některé vstupy přijímají pouze čísla, a dovolit pak uživateli vkládat i jiné znaky je zavádějící a neopatrnému či nezkušenému uživateli tím pouze uštědříme chybovou hlášku, nebo v horším případě chybu programu. Komplikovanější otázkou je zda a v jaké míře zobrazovat speciální znaky. Některé testované programy v rešerši byli evidentně dílem českých programátorů, jelikož klávesnice obsahovala plně českou diakritiku. Jelikož rešerše nezkoumala otázku lokalizace programu, není známo, zda je v tomto programu přítomna, a jak by se v tom případě klávesnice chovala. Dle úrovně programu lze ale předpokládat, že lokalizační nástroj zde přítomný není. Klávesnice s českými znaky je tak v případě CashBob neuniverzální, jelikož se počítá s více jazyky. Angličanovi by pak byli české znaky zbytečné, a jiné národní jazyky pak mohou vyžadovat jiné speciální znaky. Pojmout tak všechny možnosti by bylo velmi náročné, a jak také vyplývá s rešerše, dobrým řešením je jednoduše zobrazovat pouze universální speciální znaky jako jsou například pomlčka, čárka nebo tečka, které je možné využít při pojmenovávání

3.1. ANALÝZA GUI

11

(čehokoliv) či psaní desetinných čísel a kalendářních dat. S předchozím bodem více méně souvisí problém, zda poskytnou uživateli možnost psát kapitálky, a případně jakým způsobem. Původní virtuální klávesnice tuto možnost zcela vynechává, a jednoduše je vždy možné psát pouze malá písmena. Bez možností zápisu velkých a malých písmen je však uživatel ochuzen o jakoukoliv možnost zachovat při pojmenovávání určitou estetiku či dodržování základních gramatických pravidel. Přesto, že většina uživatelů tuto možnost pravděpodobně nevyužije, posouvá její přítomnost úroveň virtuální klávesnice do vyšší úrovně, a některé uživatele jistě potěší. Rešerše se také zabývá způsobem zobrazení číselné části klávesnice, jelikož se objevuje řešení zobrazovat řadu tlačítek s čísly nad písmennou částí, tedy tak, jako mají například některé notebooky. Tento způsob také využívá původní verze programu CashBob. Mnohem pohodlnější je však přítomnost numerické části oddělené od písmen do vlastního obdélníku obsahujícím pouze tlačítka s čísly. Je samozřejmě nutné zvážit, zda nebude taková klávesnice mít příliš velký horizontální rozměr, a zda se tedy vejde na monitory s nižším rozlišením. Vezmeme-li ale v úvahu, že původní virtuální klávesnice v CashBob nedosahovala horizontálním rozměrem ani třetiny minimální dovolené velikosti hlavního okna, nemělo by přesunutí tlačítek způsobit velké problémy. Jako drobnost se pak oproti předchozím problémům jeví otázka, zda při vstupu z virtuální klávesnice zachovávat původní text pole. Někdy je jistě vhodné původní obsah vymazat, ale pokud pak uživatel znovu omylem tento vstup aktivuje, o jeho obsah tím přijde. Virtuální klávesnice by také měla pokud možno co nejvěrněji simulovat zadávání z hardwarové klávesnice. Při tomto uvažování je pak patrné, že pouhým označením vstupu nemůže k jeho vymazání dojít. Pokud vezmeme úvahu návrh zobrazovat klávesnici s vlastním textovým polem, stačí vždy původní text nakopírovat do tohoto vlastního pole. Je tím vyřešeno také zachování původního obsahu: Pokud klávesnici upravíme způsobem, že při stisknutí určité klávesy (například Escape) jednoduše nenakopíruje zadaný text do původního pole, nepřijde uživatel o původní text. Z uvedených úvah a závěrů byl v průběhu práce vypracován vizuální návrh podoby nové klávesnice, viz obrázek A.7. Tento návrh je možné porovnat s jednou z podob původní klávesnice, například na obrázku A.4, který zachycuje formulář pro příhlášení tak, jak vypadal v dodané verzi.

3.1.5

Hlavní okno

Hlavním oknem je rozuměno rozhraní viditelné ihned po spuštění klienta. V tu chvíli obsahuje formulář pro přihlášení, který se poté promění na rozcestník celé aplikace. Jak již bylo zmíněno v sekci 2.1, v původní verzi vypadá hlavní okno stejně jako okno pokladního modulu (viz obrázek A.2), což je dáno postupnou separací funkcionality z původně jednoho společného rozhraní. Při extrakci pokladních funkcí do vlastního okna však již nedošlo k úpravě rozvržení hlavního okna, které tak vůbec neodpovídá své funkci. Jak je zmíněno v rešerši, ideální oddělení dotykových a nedotykových částí je skrze základní menu. Hlavní okno prakticky již jako menu slouží, pouze tak nevypadá. Zmiňme také znovu velmi chatrný design tlačítek bez jakýchkoliv popisků, který orientaci dále zhoršuje. Jelikož se z této části uživatel dostane jak do dotykových, tak do nedotykových částí, je nutné uspořádat prostředí tak, aby působilo konzistentně s oběma možnostmi. Tlačítka

12

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

bude v tomto případě vhodné vedle ikony doplnit popiskem, který blíže specifikuje funkci. Na základě těchto požadavků byl opět vytvořen grafický návrh, který je přiložen jako obrázek č. A.5. Součástí hlavního okna je také již zmíněný přihlašovací formulář. V původní verzi je tento natěsnán na pravé straně okna, jelikož zbytek zabírá virtuální klávesnice. Budeme-li se držet návrhu klávesnice ve vlastním okně, bude možné elegantně posunout tento formulář doprostřed.

3.1.6

Pokladní modul - struktura ovládání

Nejprve stručně o principu, na kterém pokladním modul funguje. Uživatel může vytvářet objednávky na položky, které vybere z menu. Objednávky se v pokladním modulu organizují pomocí účtenek, které mají reprezentovat klasické papírové lístky, na které jsme v restauracích zvyklí. Každá účtenka tedy může držet několik objednávek na různé položky (pokrmy, nápoje a podobně). Pokladní modul nabízí akce pro vytvoření nové takové účtenky, přidání objednávek na účtenku, zaplacení či zrušení objednávek na účtence a přesun objednávek mezi účtenkami. Tato část si vyžádala největší pozornost jak při analytických pracích, tak při návrhu řešení nalezených problémů. Z počátku se při práci projevil stejný problém, který provázel všechny týmy i jednotlivce, kteří na systému pracovali dříve, a to konzervativismus a neochota k větším změnám. Po pomyslné první polovině analýzy stávajícího uživatelského rozhraní se však ukázalo, že bez větších úprav nemůže být systém nikdy provozuschopný. Viz tedy následující řádky. Klíčovým problémem pokladního modulu v původní verzi CashBob byla naprostá absence jakékoliv interakce mezi jednotlivými akcemi. Každá zvolená akce zcela překreslila pracovní okno (vyjma lišty s tlačítky), a aplikace si neudržovala naprosto žádnou historii stavů, ani neexistovala určitá posloupnost či provázanost mezi jednotlivými akcemi. Akce, kterou uživatel aktivoval, tedy nemohla dostat žádnou informaci o tom, jaká akce jí předcházela, ani nepřijímala žádný její případný výstup. Při každé akci je tedy nutné znovu zvolit účtenku, pro kterou se má daná akce vykonat. Nastane-li situace, kdy přijde nový host a chce si objednat, musí obsluha nejprve vytvořit novou účtenku, poté manuálně přejít do akce vytvoření objednávky, kde musí nejprve účtenku, kterou v předchozím kroku vytvořila, vyhledat ze seznamu všech účtenek. Poté je teprve možné provést akci objednání. Stejný proces se pak opakuje, pokud chce zákazník účet rovnou zaplatit (například při objednávce drinku na baru). Účtenku je znovu nutné vyhledat ze seznamu, aby bylo možné ji zaplatit. Aplikace nijakým způsobem účtenku, se kterou bylo v předchozím kroku manipulováno, nezvýrazňuje ani nenabízí. V procesu vytvoření-objednání-zaplacení, musí uživatel dvakrát vyhledávat účtenku, kterou v prvním kroku vytvořil. Zde se již přímo dostáváme k problému z kapitoly 2.1, ve kterém se mluví o nepřehlednosti grafického rozhraní, a jako měrná jednotka je zde stanoven počet stisků (tlačítka myši, či dotekové obrazovky prstem) nutných k dokončení jedné akce. Jako cíl v úpravě GUI pokladního modulu, je pak stanoveno snížení nutného počtu stisků na polovinu. Vytyčený cíl není zdaleka tak přehnaný, jak by se mohlo na první pohled zdát. Z předchozích odstavců lze vypozorovat obrovský prostor pro zlepšení, které by spočívalo jednoduše v předávání jedné účtenky mezi akcemi, dokud uživatel nezvolí jinou. Tím odpadne nutnost

3.1. ANALÝZA GUI

13

vybírat účtenku pokaždé, kdy chce uživatel vykonat libovolnou akci. Dále je možné vytvořit určitou provázanost mezi akcemi. Například je velmi nepravděpodobné, že by chtěla obsluha hromadně vytvořit několik účtenek, aniž by na ně cokoliv objednala. Po vytvoření účtenky je tedy logický přechod k formuláři pro vytvoření objednávky s tím, že se bude automaticky objednávat na právě vytvořenou objednávku. Implementací těchto kroků se pak skutečně sníží počet kliknutí minimálně na polovinu. Pokud jsou operace stále prováděny nad jednou účtenkou, je zbytečné, aby každý formulář (každá akce nad účtenkou má vlastní formulář) tuto účtenku zobrazoval sám. Účtenku je možné extrahovat z jednotlivých formulářů do vlastního panelu, který se bude pouze přizpůsobovat požadavkům aktuálně zvolené akce. Panel pak nezabere více místa na obrazovce, než bylo původní místo zabrané ve formulářích. Pro představu podoby pokladního modulu v případě realizace navrhovaných změn posloužil obrázek A.6, který byl vytvořen za tímto účelem. Po prezentaci tohoto grafického návrhu pak proběhla další debata a zamyšlení. Je nutné podotknout, že návrhy na změny pokladního modulu byli zpracováváni jako první ze všech částí aplikace. Obrázek A.6 tak například obsahuje pevně umístěnou klávesnici. Právě díky tomuto obrázku pak došlo k vytvoření vlastního návrhu na klávesnici, která nebude zobrazena neustále (viz 3.1.4). Dalším předmětem debaty se stal seznam účtenek v panelu s aktuálně vybranou účtenkou. Tento seznam měl nahradit původní dlaždicový typ, ze kterého uživatel vybíral účtenky. Veskrze negativní ohlasy na tuto část pak byly zdůvodněny hlavně argumenty o nepřehlednosti, jelikož by uživatel musel při větším počtu účtenek seznamem rolovat. Tento typ seznamu byl tedy posléze z návrhu vyřazen. Stejný problém jako se seznamem účtenek pak vyvstal i v seznamu produktů. Dlaždice jsou zbytečně veliké, a zabírají tak zbytečně mnoho místa. Velmi brzy je pak nutné tímto seznamem rolovat. Tento problém je však jednoduše řešitelný, jednak zmenšením velikosti dlaždic, a také zvětšením dostupného prostoru do části, ve které se původně měla vyskytovat klávesnice.

3.1.7

Pokladní modul - vizuální podoba

Grafické prostředí pokladního modulu kromě zásadních strukturálních úprav, vyžadovalo také kompletní proměnu vizuální stránky. Moderním trendem je tlačit uživatelské rozhraní do minimalistické, přehledné a čisté podoby, jak je možné pozorovat například v rozdílech GUI mezi staršími a novějšími verzemi operačního systému Windows společnosti Microsoft [20], nebo v grafické podobě profesionálních aplikací pro produkty společnosti Apple [1], či zařízení s operačním systémem Google Android [8]. Původní podoba GUI Systému CashBob, a to ne jen v pokladním modulu, obsahuje velmi pestré spektrum barev, zbytečné obrázky které zabírají místo (například růžek účtenky), a skrze formuláře jsou na různých místech umístěna tlačítka se stejnou funkcí. V první řadě bylo nutné sjednocení vzhledu ikon tlačítek, a především pak změna ikon na více návodné. O tomto problému se zmiňuje kapitola 3.1.3. Vzniknou-li dostatečně návodné obrázky pro tlačítka, je v tomto případě možné vynechat textové popisky. Kromě snížení estetiky by totiž textové popisky mohli působit rušivě v případě zadávání textů do formulářů (například při vytváření objednávky), nebo naopak při čtení a vyhledávání v seznamech.

14

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

Obrázky použité v tlačítkách v obrázku A.6, pak ukazují směr, kterým by se sjednocení mělo vydat. Obrázky obsahují podobné tvary, doplněné o ikonu připomínající konkrétní funkci. Dalším pokrokem v tomto návrhu je pak možnost odlišit určité části ikon barevně, což může některým uživatelům pomoci v asociaci těchto ikon s konkrétní funkcí. Sjednocení pozic jednotlivých tlačítek napříč formuláři je pak čistě estetickou záležitostí, která však pozvedne celkovou kvalitu a pocit z prostředí. Stejně tak používání jednotného barevného a rozměrového schématu. Tedy pokud se například ve formuláři pro vytvoření objednávky vyskytuje účtenka dvakrát, měla by se její vizuální podoba shodovat v obou případech. Vizuální podobou je pak v tomto případě myšlena pozice jednotlivých textů, tlačítek, velikost a barva okrajů, umístění ovládacích prvků, jejich rozměry a podobně.

3.1.8

Drobné problémy v GUI

Skrze celý systém se kromě již uvedených zásadních problémů objevuje celá řada drobností, jejichž vyjmenování není podstatné. Pouze pro představu, se jedná například o dialogy v dotykových částech, které nejsou pro dotyk přizpůsobené (mají drobná tlačítka), nebo o zobrazování ID entit v tabulkách, kde je irelevantní, nebo přímo zavádějící, jako je tomu u tabulky s výpisem stolů, které uživatel identifikuje pomocí čísla stolu, nikoliv pomocí ID. Při proběhlé analýze byl vytvořen seznam těchto nedostatků, a jejich odstranění se ve velké většině případů samo nabízelo, tedy nebylo nutné vypracovávat návrh jejich řešení. Mnoho problémů pak bylo nalezeno až při implementaci jiných úprav či oprav.

3.1.9

GUI serveru

Jak bylo řečeno v úvodu této sekce, neobsahuje serverová část v oddané verzi naprosto žádné grafické prostředí. Server se jednoduše spustí, při čemž se zobrazí pouze konzole s výstupem programu. Vypnutí serveru pak proběhne při zavření této konzole. Je tedy možné vytvořit velmi jednoduché uživatelské prostředí, které bude kontrolovat start serveru. Bude tak moci být skryta konzole, jejíž podoba může v uživatelích vzbuzovat nedůvěru. Pokud pak dojde při běhu programu k nějaké chybě, je možné ji uživateli oznámit pomocí dialogu. V původní verzi se jednoduše vypíše klasický Java výpis o chybě, a konzole běží dál. Program již však v tu chvíli nefunguje korektně, což běžný uživatel z konzolového výpisu nemusí pochopit.

3.2

Úprava kódu

Konkrétní místa, kde je nutné kód opravit je těžké najít. Kód je celkově velmi nepřehledný, a je tedy nutné ho upravovat postupně při implementaci jiných požadavků, například při úpravě GUI a přidávání nových funkcí. Příkladem pak může být extrakce účtenky z jednotlivých formulářů do vlastní třídy, jak je navrhnuto v kapitole 3.1.6. Tento zásah do grafického prostředí se výrazně projeví na kvalitě kódu. V původní verzi totiž skutečně každý formulář sám vytvářel panel s účtenkou a měl vlastní metody pro manipulaci s ní. Kromě neuvěřitelného počtu duplicit v kódu pak také s každým formulářem s účtenkou manipulovalo lehce odlišným způsobem, což značně

3.3. INSTALAČNÍ NÁSTROJ

15

ztěžovalo čitelnost kódu a tedy i celou práci. Vytvořením vlastního panelu s účtenkou, se sjednotí rozhraní a všechny formuláře budou s účtenkou komunikovat stejným způsobem. Příští generace programátorů zabývající se GUI pak bude moci k účtence přistupovat jako k black-boxu [17] a zabývat se skutečně pouze konkrétním formulářem. Na první pohled je také patrné, že je možné zcela sjednotit některé třídy z jednotlivých modulů do modulu Library (knihovna), který nemá vlastní uživatelské rozhraní, ale poskytuje všem ostatním modulům třídy, které využívá více modulů společně. Do tohoto balíku je například možné přesunout třídy, které využívá virtuální klávesnice, jelikož ty jsou využité jak v základním okně, tak v pokladním modulu.

3.3

Instalační nástroj

Před samotnou snahou o vytvoření instalačního balíku je nutné upřesnit, jaké úkoly se od něj budou přesně očekávat, a definovat předpoklady cílového systému.

3.3.1

Cílový systém

Pan ing. Martin Komárek poskytl mimo samotného softwaru CashBob také dotykové terminály, které jsou osazeny operačním systémem Microsoft Windows XP [20]. Tyto terminály se pak staly primárním testovacím systémem pro nové verze CashBob, a dá se očekávat, že první ostré nasazení proběhne právě na těchto terminálech. Jako cílový operační systém instalátoru byl tedy určen právě Microsoft Windows, a to minimálně verze XP. V době realizace této práce se jedná již o 11 let starý operační systém, který je však mezi uživateli hojně rozšířen. Zvolení této verze jako minimální tedy není přehnaný požadavek na případné cílové počítače. Je pravdou, že program CashBob je vyvíjen v jazyce Java [14], a je tedy prakticky možné jeho nasazení i na jiné operační systémy, které jsou s jazykem Java kompatibilní. Pro samotné Java aplikace pak existují nástroje pro vytvoření platformě nezávislých instalátorů. Po takových instalátorech však není možné vyžadovat rozšířenou funkcionalitu, jako je právě námi vyžadované spuštění a konfigurace databáze. Tyto úkoly totiž provádí samostatný instalátor, který je poskytován pro jednotlivé operační systémy zvlášť. Existuje možnost přidat do vytvářeného instalačního balíku více verzí instalátorů databáze. Tato úprava by však znásobila velikost výsledného instalačního balíku, a vyžadovala by pak také větší režii. Ve chvíli, kdy je cílová platforma přesně dána, byli by tyto snahy ve výsledku nevyužiti. Pokud v budoucnu dojde k požadavku o možnost nasazení programu CashBob na jiné platformy, jako například MacOS [2] či Linuxové distribuce [27], bude snazší vytvořit pro ně nové, separátní instalátory, opět platformě specifické.

3.3.2

Požadované akce

Jelikož se program CashBob dělí na dvě části, kterými jsou server a klient, je nutné vytvořit požadavky společné a poté specifické pro každou část.

16

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

Obě části vyžadují pro svůj chod přítomnost Java Runtime Environment [9]. Vývoj probíhal ve verzi JRE 7.3. Na dodaných terminálech byla nejprve k dispozici pouze verze 6, a grafické prostředí programu se v některých situacích chovalo odlišně. Verze 7 byla tedy zvolena jako minimální požadovaná, a instalátor by ji měl na cílový systém vždy instalovat. K tomuto prostředí existují jednoduché instalátory, které je možné spustit přímo v konzole v módu, který nevyžaduje žádný další zásah uživatele. Využití tohoto módu tedy instalaci zcela automatizuje. Server na rozdíl od klienta komunikuje s databází, ve které si uchovává data. Již v dodané verzi byla použita databáze MySQL[15]. Tuto databázi je možné na cílovém počítači zprovoznit dvěma způsoby. Existuje opět samostatný instalátor, který lze spustit v tichém módu, podobně jako JRE. Druhým způsobem je nainstalovat nástroj Xampp[28], který kromě databáze obsahuje další nástroje, například grafické rozhraní pro práci s databází. Výhoda samostatného instalátoru je v jeho velikosti, která je oproti Xampp podstatně menší. Instalátor je však nutné spustit a nechat proběhnout a databázi pak dodatečně nakonfigurovat. Xampp sice poskytuje také vlastní instalátor, je však možné jeho soubory přímo extrahovat spolu s požadovanou konfigurací a samotnou MySQL pak spustit pomocí jednoduchého skriptu, který Xampp obsahuje. Použití druhého způsobu by tak značně omezilo prostor pro možné chyby, které mohou při použití samostatného instalátoru MySQL nastat. Kromě samotného nainstalování databázového serveru a spuštění databázové služby, je pak nutné vytvořit požadované schéma a přístupová práva. Při úspěšné instalaci a spuštění MySQL lze tyto úkoly vykonat předáním souboru s příslušným SQL skriptem spuštěnému serveru. Toho lze dosáhnout skrze příkazovou řádku, a tedy opět automatizovat pomocí vlastních skriptů. Klient nevyžaduje oproti serveru instalaci zvláštních součástí. Klient sice v původní verzi obsahoval jako jediný grafické prostředí. To je ale součástí základních knihoven Java, tedy JRE, které je nutné nainstalovat jak pro server, tak pro klienta. Ve výsledné verzi práce pak obsahuje grafické prostřední i server, čímž se veškeré rozdíly v tomto ohledu srovnávají.

Kapitola 4

Realizace V této kapitole jsou popsány změny provedené v dodaném programu. Většina změn má pak základ v návrhové části, které se snaží držet, nebo v případě nalezení nových relevantních poznatků najít více ideální řešení.

4.1

Úpravy GUI a Funkcionality

K nadpisu této části je nutné dodat, že se bude pojednávat především o úpravě GUI. Funkcionální změny jsou pouze sekundární v tom smyslu, že došlo hlavně k dokončení či drobné úpravě již existující funkcionality, nebo naopak dokonce k odstavení některých funkcí. Při realizaci projektu šlo v první řadě o vytvoření stabilního a přehledného prostředí, které bude nasadit do provozu v reálném prostředí, pro které je systém určen, tedy restaurace či baru. Určité funkce nebo schopnosti byli do programu přidány pouze po předchozím zvážení jejich časové náročnosti a debatě, zda budou mít dostatečný přínos v rámci splnění cílů práce.

4.1.1

Lokalizace

Lokalizační manažer implementovaný v dodaném systému fungoval takovým způsobem, že přijímal celé grafické komponenty a sám je lokalizoval. Grafická komponenta jako tlačítka (JButton) či popisky (JLabel) byli předány jako parametr příslušné metodě, která dle jména komponenty, které bylo nutné předat jako druhý parametr, a vybraného bundle1 předaného také jako parametr, vyhledala ve slovníku příslušné klíče, a tyto pak komponentám nastavila. Například tlačítku příslušná metoda nastavila text a tooltip2 . Zde je vhodné podotknout, že ačkoliv je část programu čistě dotyková, a tooltipy není možné zobrazit, byly u většiny tlačítek zachovány pro případ, že se systém spustí na pracovní stanici s počítačovou myší. Vzhledem k velkému počtu parametrů, které tyto lokalizační metody vyžadovali, tedy komponenty, její jméno a vybraný bundle, byly tyto metody využity pouze zřídka ve vhodných situacích. Pro většinu formulářů a jejich komponent byl však zvolen jiný způsob. 1 2

označení pro jazykový balík ze kterého se mají číst lokalizované texty text zobrazený po najetí kurzorem

17

18

KAPITOLA 4. REALIZACE

Většina formulářů implementuje abstraktní třídu AbstractForm. Dialogy pak implementují abstraktní třídy AbstractDialog nebo AbstractFullScreenDialog (pokud mají zabírat celou obrazovku a mít poloprůhledné pozadí). Těmto abstraktním třídám byla tedy přidána staticky přidána instance lokalizačního manažeru (třída LokalizationManager), a vytvořena metoda, která přijímá jediný parametr, a to hodnotu klíče který se má ve slovníku vyhledat. Bundle je pro celý modul stejný a není tedy nutné ho předávat pro každou komponentu v každém formuláři zvlášť. Každý formulář a dialog má pak všechny texty, které obsahuje, definovány jako statické konstanty, které se inicializují pomocí zmíněné metody v abstraktním předkovi přímo na lokalizovaný řetězec. V kódu jsou pak již použité pouze tyto konstanty, což extrahuje lokalizační proceduru na jediné místo, kde díky statické deklaraci proběhne pouze jednou, a to přímo při zavedení programu. Kromě přehlednosti bylo díky tomuto způsobu lokalizace možné odhalit chybějící hesla přímo při startu programu nebo konkrétního modulu. Stále je bohužel nutné program restartovat, aby se projevila změna nastavení jazyku. Možnosti odstranění této nutnosti byli zběžně prozkoumáni, a časová náročnost řešení by byla příliš vysoká, vzhledem k tomu o jak drobné vylepšení by se jednalo. Bylo by totiž nutné, aby všechny okna, formuláře, dialogy a komponenty, znovu načetly všechny lokalizované řetězce. Budeme-li vycházet z toho, že jsou tyto řetězce uloženy ve statických proměnných tříd, bylo by nutné v těchto třídách vytvořit metody, které znovu inicializují všechny tyto proměnné. Nejefektivněji by takového úkolu šlo dosáhnout tak, že by se místo těchto proměnných vytvořila jedna proměnná typu hash-map, ve které by každý klíč měl svůj lokalizovaný řetězec. Tato hash-map by mohla být definována již v abstraktních třídách, které jednotlivé komponenty rozšiřují, a pouze by si ji inicializovali na své klíče. Její aktualizace by pak byla otázkou jednoho průchodu a zavolání lokalizační funkce na každý řetězec. Každý modul by si pak musel udržovat seznam existujících formulářů a dialogů a při přijetí informace o změně lokalizace zavolat aktualizaci mapy pro každou položku tohoto seznamu. Tato implementace by byla efektivní, a logicky není nijak náročný, ale vzhledem k počtu formulářů a dialogů v programu by si vyžádala skutečně masivní objem času. Samotné přepsání řetězců do konstant ve všech formulářích nelokalizovaných modulů zabralo v rámci této práce několik dní. Přepsání těchto konstant do map a vytvoření seznamů formulářů ve všech modulech by pak tedy zabralo minimálně stejně dlouhou dobu.

4.1.2

Zobrazení dle autorizace

Při dokončování autorizace bylo přistoupeno na navržený model, a tedy skrývání ovládacích prvků funkcí, na které nemá uživatel právo. Implementačně byla realizace triviální. Při vykreslování okna bylo použito dostupné rozhraní pro kontrolu práv, které vrací booleovský výsledek, na základě nějž je rozhodnuto o skrytí nebo zobrazení ovládacího prvku. Tato kontrola proběhne při zavedení hlavního okna i všech modulů, pro všechny ovládací prvky, na něž se vztahují existující práva. V návrhu se hovoří o možnosti vynechat poté kontrolu při aktivaci dostupných ovládacích prvků. Po zhodnocení rizik byla kontrola práv zachována i při aktivaci. Pokud by při kontrole při zavádění modulu došlo k náhodné chybě, mohl by v tu chvíli mít uživatel přístup i k neautorizovaným funkcím. Také zůstává faktem, že i přes dlouhodobou práci s kódem je možné, že se v programu vyskytují neošetřené cesty k daným funkcím skrze ovládací prvky,

4.1. ÚPRAVY GUI A FUNKCIONALITY

19

které nepodléhají kontrole při zavádění. Kontrola po aktivaci je pak tedy vhodný ochranný prvek. Skrývání ovládacích prvků se týká jak pokladního modulu, tak hlavního okna. Došlo také k doplnění kontroly práv na spuštění celých modulů, kterou původní verze neobsahovala. Tyto oprávnění slouží ke kontrole přístupu k celým modulům. Stále je nutné uživateli, respektive roli, přiřadit také práva k jednotlivým funkcím modulu, ale vynecháním práva pro celý modul, se uživateli zcela znemožní jeho spuštění. V případě tlačítek, která spouštějí jednotlivé moduly, bylo namísto jejich skrytí přikročeno k jejich zakázání, tedy uvedení do stavu, ve kterém není možné je aktivovat. Tento krok se jevil logicky, jelikož samotnou přítomnost těchto modulů není nutné před uživateli skrývat. Hlavním argumentem pro skrytí tlačítek byla pak větší přehlednost. Jelikož se ale nyní pohybujeme v hlavním okně, které slouží pouze jako rozcestník, neutrpí pouhým zakázáním těchto tlačítek ani přehlednost. Úpravou pak také prošel samotný dialog pro nastavení práv. Původní dialog byl totiž ve stylu pokladního modulu, a do nové podoby hlavního okna by se tedy nehodil. Také bylo na jeho potvrzení (tedy stisknutí tlačítka OK) navěšena akce, která aktualizuje hlavní okno. Tento krok odstraňuje nutnost celý program restartovat, aby se znovu načetlo uživatelské prostředí a znovu se zkontrolovali přidělená práva.

4.1.3

Tlačíka a ikony

Všechny obrázky tlačítek byli předěláni do elegantnější podoby tak, aby lépe odpovídali funkci, kterou reprezentují. Tlačítka mají nyní jednoduché piktogramy. Například pro spuštění pokladního modulu slouží tlačítko s bankovkou, pro sklad zase jednoduchý geometrický obrazec připomínající krabici. V pokladním modulu byli pro tlačítka, která manipulují s účtenkami, vytvořeny obrázky s listem papíru, který účet reprezentuje. Jednotlivé funkce jsou pak zastoupeny barevně odlišenými prvky, které byly zvoleny tak, aby co nejvíce danou funkci připomínali. Pro zapsání objednávky na účet tedy slouží list papíru s tužkou, pro přesun objednávek pak obrázek se dvěma listy, mezi kterými je šipka. Nové ikony byly vytvořeny také pro tlačítka, jako je potvrzení, zrušení či posun. Ikony mají nyní hrubší rysy a výrazněji odlišené barvy. Byly také vytvořeny ikony pro samotný program. Ten odpovídá logu CashBob, a obsahuje piktograficky zobrazenou kravatu a kapsu u košile s připnutou propiskou. Tato ikona slouží jak pro celý program, tak pro manažerský modul. Ostatní dva moduly mají podobné ikony, jako jsou obrázky na tlačítkách, které je spouští. Ikony byly vždy vytvořeny pro velikosti čtverce 64, 32 a 16 pixelů. Ikony je možné kromě spouštěcího exe souboru vidět také v hlavní liště systému Windows, pokud se uživatel manuálně přepne z programu CashBob (klávesová zkratka Alt+Tab nebo Win+D).

4.1.4

Virtuální klávesnice

Realizace virtuální klávesnice se držela velmi detailně zpracovaného návrhu (viz kapitola 3.1.4), který před počátkem implementace zhodnotil možnosti řešení všech aspektů, se kterými je možné se při úpravách virtuální klávesnice setkat.

20

KAPITOLA 4. REALIZACE

Uspořádání kláves odpovídá obrázku A.7 vypracovaném při návrhu. Klávesám Enter a Backspace přibyli ikonky, a byla doplněna klávesa pro zrušení vstupu (Cancel) a spodní řada písmen byla doplněna o klávesy pro znaky tečka a pomlčka. Také zde přibila klávesa pro aktivací psaní velkých písmen (Caps Lock). Klávesa Caps Lock pak reaguje také na stisk hardwarového ekvivalentu této klávesy. Pokud je tedy aktivována hardwarová klávesa Caps Lock, aktivuje se i na virtuální klávesnici, a stejně tak naopak, je-li aktivována virtuálně, je i vstup s hardwarové klávesnice převeden na velká písmena. Klávesnice jako taková pak byla vyjmuta ze všech částí programu, a je nyní inicializována jako singleton [24], a je použita skrze celý program jednotně. Vykresluje se do okna pokrývající celou plochu obrazovky, čímž vždy překryje původní obsah okna. Pozadí klávesnice je poloprůhledné, takže uživatel neztratí kontext a kontakt s původním oknem programu. Tohoto efektu bylo docíleno pomocí implementace abstraktní třídy AbstractFullScreenDialog, kterou třída klávesnice (KeyboardDialog) dědí. Tyto třídy jsou nyní umístěny v modulu Library (knihovna), jelikož jsou využívány jak v hlavním okně klienta, tak v pokladním modulu. Původně měli obě tyto části vlastní třídy s klávesnicí, které byli v podstatě identické. Na stejné místo, tedy do balíku cz.cvut.fel.restauracefel.library.gui byla přesunuta také třída MyKeyListener, která propojuje psaní na virtuální klávesnici s hardwarovou klávesnicí. Virtuální klávesnice má nyní dva nové módy, ve které je možné jí spustit. V kódu jsou označené jako NumericOnly a AsPassword. Oba módy je možné aktivovat pomocí setterů v této třídě a automaticky se resetují při zavření klávesnice, a to při potvrzení i zrušení vstupu. NumericOnly nastaví určité proměnné tak, že není možné stisknout jiná tlačítka, než ty které obsahují čísla. Tento mód kontroluje i přiložený MyKeyListener, takže ani pomocí hardwarové klávesnice není možné psát písmena. Kromě čísel jsou povoleny znaky pomlčka, tečka a lomítko (které není na virtuální klávesnici přítomno, ale je povoleno ho napsat pomocí hardwarové klávesnice). Tyto znaky jsou povoleny, aby bylo umožněno psaní desetinných čísel a kalendářních dat. AsPassword funguje na jiném principu. Textové pole klávesnice je totiž speciálně upravený JPasswrodField3 . Úprava spočívá v tom, že implicitně je jako zástupný znak, tedy znak, kterým se má psaný text nahradit, aby se skryl, nastavena 0. Toto nastavení je pak vyhodnocováno tak, že znaky nejsou nahrazeny vůbec, a je tedy vidět původní text. Při použití metody setAsPassword, se nastaví zástupný znak na hvězdičku, čímž se z textového pole stane standardní vstup pro heslo. Při zavření okna je pak zástupný znak opět nastaven na 0, takže při příštím volání se klávesnice opět chová jako by měla obyčejné textové pole. Chování klávesnice opět odpovídá návrhu. Vždy, když je kurzor přesunut do nějakého textového pole, navěšené posluchače (neboli listenery), aktivují virtuální klávesnici a případně její příslušné módy. Původní text pole se nakopíruje do vlastního pole klávesnice, a jakékoliv úpravy probíhají pouze zde. Pokud chce uživatel úpravy zrušit, stiskne příslušnou klávesu na virtuální klávesnici, nebo klávesu Escape na hardwarové. Stejně tak, pokud chce uživatel úpravy potvrdit, stiskne Enter na libovolné z klávesnic. Chce-li uživatel pole vymazat, musí smazat text v poli klávesnice a poté tuto změnu potvrdit, stejně jako kteroukoliv jinou úpravu. 3

komponenta která automaticky skrývá znaky

4.1. ÚPRAVY GUI A FUNKCIONALITY

4.1.5

21

Výběrové seznamy

Pojmem výběrový seznam rozumějme dialog, který se otevře, pokud je od uživatele požadován vstup, při němž si musí uživatel vybrat z existujících entit. Tyto dialogy se vyskytují například při vytváření nové účtenky, pokud chce uživatel přiřadit zákazníka či stůl. Jak zákazníci, tak stoly jsou entity zanesené v systému, a jejich přiřazení tedy musí proběhnout formou výběru. Tato část není zmíněná v návrhové části, jelikož její úprava byla až důsledkem výsledku implementace virtuální klávesnice. Použití celo-obrazovkového poloprůhledného okna je natolik efektní a uživatelsky příjemné, že byla tato vizuální podoba aplikována právě i na výběrové seznamy. Tato podoba totiž okamžitě zpřehledňuje nově otevřený seznam, jelikož ovládací prvky původního okna jsou skryty za poloprůhledné pozadí, a nenaruší tak přehlednost dialogu. Rozvržení ovládacích prvků dialogu se výrazně nezměnilo. Pouze byly ve všech těchto seznamech stejně vyrovnány ovládací prvky a nápisy. Ve výsledku jsou pak tyto seznamy natolik podobné, že by bylo možné je sloučit do jedné třídy a měnit pouze obsah seznamu a nápisy. Tyto úpravy by ve finální verzi byli zcela triviální, a doposud neproběhli čistě kvůli nedostatku času.

4.1.6

Okno nahrávání

Tato úprava je oproti původní verzi novinkou. Jelikož spuštění GUI zabere určitý čas, zobrazuje se ještě před zavedením hlavního okna jednoduchý panel, bez jakýchkoliv ovládacích prvků, který pouze informuje o tom, že se aplikace nahrává. Informace je jednoslovná a využívá lokalizace. Při českém nastavení se tedy zobrazí text "Nahrávání", při anglickém pak "Loading". Kromě toho obsahuje panel také logo programu A.1, jméno školy a fakulty a rok ve kterém byla tato verze programu dokončena, tedy 2012. Tento panel se používá u většiny aplikací, kterým načtení trvá delší dobu. Je to informace pro uživatele, že se skutečně "něco děje"a tedy nemusí být nervózní. Běžně se označuje jako "splash-screen". V případě klientské části aplikace se během zobrazení tohoto splash-screenu snaží klientská aplikace připojit k serveru na IP adresy nastavené v konfiguračním souboru. Při prvním spuštění jsou oba servery (CashBob poskytuje možnost nastavit primární a sekundární server pro připojení) nastaveny na lokální PC, tedy IP adresu 127.0.0.1. V případě, že se na nastavených adresách nelze připojit, je uživateli prezentován dialog, ve kterém je ho na tuto skutečnost upozorněno, a kde může případně nastavit jiné adresy a pokusit se o připojení znovu, nebo program zcela ukončit. Server, který také tento splash-screen obsahuje, se při jeho zobrazení pokusí zcela spustit, tedy tak aby nebylo nutné po zavedení hlavního okna nutné již klikat na tlačítko pro spuštění. Pokud dojde k chybě, zobrazí se tato chyba po zavedení hlavního okna, spolu s možností pokusit se server znovu spustit. Z implementačního hlediska je spuštění a ukončení tohoto okna vyřešeno velmi jednoduše. Při startu programu se inicializuje hlavní kontrolní třída klienta, která má ve statické proměnné uloženou instanci SpashScreen, což je právě naše nahrávací okno. SplashScreen se

22

KAPITOLA 4. REALIZACE

již při konstrukci nastaví na viditelnou, a tedy se skutečně zobrazí ihned po zavedení kontrolní třídy. Instanci SplashScreen poté hlavní kontroler předá třídě ViewController, která se stará o zavedení grafického prostředí. Poté, co proběhnou všechny nutné operace, jako je nastavení vzhledu a inicializace hlavního okna, a GUI je možné spustit, ViewController přijatý SplashScreen ukončí.

4.1.7

Přihlašovací formulář

První formulář, se kterým se uživatel setká při startu programu, a je součástí hlavního okna klienta. Tento formulář byl přesunut do horizontálního středu okna, a drobně vizuálně upraven. Tlačítka jsou nyní větší a jsou pod sebou. Funkčně byl formulář vylepšen tak, aby si vstupní pole pro uživatelské jméno "pamatovalo"naposledy přihlášeného uživatele. Velmi jednoduše byl rozšířen soubor s konfigurací, kam se ukládá například nastavení jazyku, o heslo lastLoggedId. Pokud obsahuje hodnotu -1, zůstane pole prázdné. Pokud obsahuje kladné číslo, pokusí se program najít v databázi uživatel s tímto ID, a jeho uživatelské jméno automaticky doplní. Heslo v konfiguračním souboru se aktualizuje vždy po úspěšném přihlášení uživatele na jeho id. Původně také při chybě v přihlášení došlo ke smazání obou polí. Nově se smaže pouze pole s heslem, ve kterém je větší pravděpodobnost chybování, jelikož si uživatel nemůže zadaný text vizuálně ověřit. Dále bylo pro uživatele, kteří budou mít k dispozici hardwarovou klávesnici, přihlašování zrychleno. Po napsání jména stačí stisknout tabulátor, a automaticky se přejde do pole pro heslo (bez aktivace virtuální klávesnice), a po zadání hesla je možné pro přihlášení stisknout pouze klávesu Enter.

4.1.8

Hlavní menu

Hlavní menu prošlo zřejmě nejradikálnější změnou designu. Původní rozložení komponent, kdy se ani nedalo mluvit o menu, bylo zcela odstraněno. Nové hlavní okno nyní obsahuje pouze tři řady tlačítek. V první řadě se nachází tlačítka pro spuštění modulů, v druhé pro nastavení aplikace, a ve třetí je pouze tlačítko pro odhlášení. Zmizela zbytečná velká modrá plocha, a tlačítko pro nastavení lokalizace se přesunulo do dialogu pro nastavení aplikace. Tlačítka nyní nejsou čtvercová a obsahují lokalizované popisky. Tlačítka pro moduly jsou neaktivní, pokud uživatel nemá právo daný modul spustit. K této kontrole dochází při spuštění klienta a hlavního okna, a poté vždy, když uživatel změní nastavení práv. Dialog pro nastavení práv byl také předělán do nové podoby, a bylo v něm opraveno několik logických chyb. Celé hlavní okno je stejně jako původní roztažené přes celou obrazovku. Byla však odstraněna horní pracovní lišta, a jediný způsob jak aplikaci ukončit skrze GUI je tedy odhlášení, které nově vyžaduje potvrzení skrze dialogové okno, a poté stisknutí tlačítka pro ukončení.

4.1.9

Pokladní modul

Pokud v hlavním menu mluvíme o nejradikálnější změně designu, jedná se o změny týkající se hlavně grafického rozložení komponent a jejich podoby. Celý pokladní modul byl totiž také v podstatě celý proměněn. Nedošlo sice k zásadnímu přesouvání samotných komponent, ale žádná z nich nezůstala vizuálně stejná jako v původní verzi programu.

4.1. ÚPRAVY GUI A FUNKCIONALITY

23

Tlačítka Pro tlačítka byli vytvořeny nové ikony, jak je podrobněji popsáno v kapitole 4.1.3. Jejich pořadí bylo také upraveno tak aby logicky odpovídalo pořadí, v jakém jsou operace obvykle prováděny, tedy vytvoření účtenky, objednání položek, zaplacení a případně přesunutí položek na jiný účet. Vyjmenované funkce mají tlačítka seskupeny na levé straně pracovní lišty. Na pravé straně této lišty je pak skupina tlačítek, jejichž funkce nemanipuluje přímo se zvolenou účtenkou. Jsou to tlačítka pro zobrazení podrobného seznamu účtů, přidání kreditu uživatelům, vytvoření uživatele a vytvoření kategorie účtů. Posledním tlačítkem je odhlášení. Na všechna tlačítka, kromě odhlášení, se vztahují práva. Pokud uživatel práva nemá, je tlačítko zcela skryto. Ke skrývaní zde byl oproti hlavnímu oknu (kde se tímto způsobem skrývají tlačítka pro nastavení, ale tlačítka pro moduly se pouze uvedou do neaktivního stavu) důvod na víc. Pokud totiž není aktuálně vybrán žádný účet, jsou tlačítka pro manipulaci s účtem v neaktivním stavu. Pokud by pak i tlačítka, ke kterým nemá uživatel práva, byla pouze neaktivní, nebyl by uživateli vždy jasný důvod, proč tomu tak je. V tuto chvíli, vidí-li uživatel neaktivní tlačítko, je zcela jasné, že nemá vybranou účtenku. Výběr účtu Po spuštění modulu je automaticky zobrazen formulář se seznamem pro výběr účtu. Formulář obsahuje také tlačítko pro vytvoření nového účtu, které má stejnou funkci jako tlačítko pro vytvoření účtu v horní nástrojové liště. Uživatel tedy musí svolit ze seznamu účtenek, nebo vytvořit účet nový, a to pomocí formuláře pro vytvoření nové účtenky. Seznam obsahuje pouze aktivní, tedy neuzavřené účty. Každý účet v seznamu je reprezentován tlačítkem, po jehož stisknutí dojde k vybrání tohoto účtu jako aktivního, a automatickému přechodu do formuláře pro vytvoření objednávek. Zmíněná tlačítka zobrazují kromě jména také informaci o tom, k jakému uživateli a stolu je účet přiřazen. Levý panel Kromě seznamu účtenek je ihned po spuštění modulu na levé straně zobrazen panel s bílým rámečkem, ve kterém se zobrazuje vybraná účtenka a na ní objednané položky. Pod touto účtenkou se pak vyskytují tlačítka pro výběr jiného účtu a vytvoření rychloúčtenky (viz níže odstavec "Rychlo-účtenka") a podle velikosti zbylého místa se také zobrazí určitý počet předchozích aktivních účtů. Po spuštění pokladního modulu je logicky jak panel pro účtenku, tak seznam předchozích účtů, prázdný. Do seznamu předchozích účtů je zařazen každý vybraný účet ve chvíli, kdy je nahrazen jiným účtem, ale stále zůstává aktivní. Seznam posledních účtů tedy nemůže obsahovat neaktivní účtenky. Seznam funguje stejně jako formulář pro výběr účtu, a po kliknutí na příslušné tlačítko v seznamu se účet nastaví jako aktivní, a ze seznamu se odstraní. Bílý rám, který je použitý ne jen zde, ale i v některých formulářích (vytvoření objednávky, přesun objednávek mezi účty etc.), byl upraven tak, aby podporoval dotykové posunování. Pokud tedy účet obsahuje více položek, než je možné v něm zobrazit, stačí se na libovolném místě seznamu dotknout prstem, a poté jím táhnout směrem nahoru. Inspirace k tomuto ovládání je v aktuálních chytrých telefonech s dotykovými obrazovkami, kde toto rolování funguje ve všech seznamech. Levý panel je pak pro budoucí zpříjemnění práce implementován jako sestava objektů, které rozšiřují existující třídy Java Swing [26]. Nejzajímavější je pak bílý rám, který obsahuje kromě nadpisu a tlačítka pro úpravy atributů účtenky také seznam objednávek, který je pak sestaven z drobných grafických komponent reprezentující jednotlivé položky. Každá

24

KAPITOLA 4. REALIZACE

tato komponenta samostatně vykresluje daný řádek seznamu. Bílý rám pak funguje jako rozhraní pro práci s celým vybraným účtem. Rám má přizpůsobitelná tlačítka, která se zobrazují u každé položky. Pomocí příslušných metod je možné jednoduše tlačítka skrýt či zobrazit a změnit znak, který se v nich zobrazuje. Kliknutí na dané tlačítko pak vyvolá sled akcí, na které může právě aktivní formulář reagovat díky metodě, kterou implementuje z definovaného rozhraní. Stejně tak bílý rám v levém panelu reaguje na stisknutí tlačítka v bílých rámech přítomných v jednotlivých modulech. Nový účet Formulář pro vytvoření nového účtu obsahuje pouze rámec s řadou textových polí, které mohou obsahovat určité informace o nově vytvářeném účtu. Jediný povinný údaj je jméno účtu. První atribut je však osoba, ke které může být účet přiřazen. Tato položka předchází jméno z toho důvodu, že pokud dojde k výběru uživatele, vytvoří se podle jeho uživatelského jména také jméno účtu. Pokud je již jméno použito pro jiný účet, je při potvrzení vytvoření účtu uživateli nabídnuto jméno s číslem na konci. Toto číslo se postupně zvyšuje při snaze vytvořit stejné jméno po několikáté. Dále je možné přiřadit k účtu stůl, kategorii a poznámku. Je také přítomný řádek pro přiřazení slevy, který je však neaktivní, což je vysvětleno v kapitole 4.1.10. Pokud pole vyžaduje textový vstup, tedy u jména a poznámky, dojde po kliknutí na pole samotné, nebo na přiložené tlačítko, k zobrazení klávesnice. Pole pro uživatele, stůl či kategorii otevře výběrový seznam (viz 4.1.5) a po jeho potvrzení se do pole zapíše textová reprezentace zvolené entity (jméno, nebo v případě stolů číslo). Pokud nesou v systému žádné entity daného typu zaneseny, seznam se jednoduše nezobrazí. K této situací může dojít například po čerstvé instalaci programu, jelikož v databázi nejsou žádné stoly či kategorie účtu předdefinovány, a uživatel je musí nejprve vytvořit pomocí manažerského modulu. Pod rámem s textovými vstupy jsou pak tlačítka pro vymazání formuláře a jeho odeslání. Druhé zmíněné tlačítko pak vytvoří nový účet (je-li vyplněno jméno účtu), automaticky ho přiřadí do levého panelu a přejde do formuláře pro vytvoření objednávky. Levý panel s vybranou účtenkou má v horním pravém rohu aktivní tlačítko pro úpravu tohoto účtu, ve kterém je možné informace, zadané při jeho vytváření, upravit. Nová objednávka Dalším formulářem, se kterým se uživatel setká jak po výběru účtu, či jeho vytvoření, je formulář pro vytvoření objednávky. K tomuto formuláři také vede tlačítko s tužkou v horní nástrojové liště (je neaktivní, pokud není účet vybrán). Zde je pak zobrazen stejný bílý rám, který stejně jako v levém panelu umožňuje rolování dotykem. Do tohoto rámu se vpisují položky, které budou objednány po stisknutí příslušného tlačítka pod tímto rámem, kde je opět umístěno i tlačítko pro vymazání seznamu položek k objednání. Položky k objednávce uživatel vybere z buněk napravo od bílého rámu, kde je v horní části zobrazen seznam existujících menu, ve kterém lze rolovat pomocí přiložených kláves (neaktivní, pokud je seznam menu dostatečně krátký a vejde se na obrazovku i bez rolování). Po zvolení menu se pak zobrazí položky tohoto menu do buněk níže. Každá buňka obsahuje název položky a její cenu. Kliknutím na buňku se příslušná položka přidá do rámu se seznamem položek k objednávce. Položky je také možné přiobjednat kliknutím na danou položku v aktivním seznamu. Do rámu s novými objednávkami se pak tato položka přidá stejně, jako by byla vybrána mezi buňkami v menu. Tato funkce umožňuje objednat položky, které již byli na účet objednáni dříve, bez nutnosti je vyhledávat v menu. Dojde-li k situaci, že vybrané menu obsahuje více položek, než je možné v aktuálním

4.1. ÚPRAVY GUI A FUNKCIONALITY

25

seznamu zobrazit, dojde k vertikálnímu zmenšení buněk a přidání dalšího řádku. Buňky jsou dostatečně rozměrné, a jejich zmenšení tedy na pohodlnosti jejich stisku při přidání jednoho či dvou řádků příliš neubere. Při implicitní velikosti seznamu se zobrazuje 30 buněk. Při přidání dvou řádků je pak možné zobrazit až 50 položek najednou. Více řádků již může buňky deformovat natolik, že je nebude možné pohodlně stisknout, avšak dříve uživatel pocítí nepřehlednost daného menu z důvodu vysokého počtu položek, při čemž se tedy nabízí řešení v podobě vytvoření nového menu a přesunutí části položek do něj. Zaplacení účtenky Po objednání položek je možné vybrat jiný účet po práci, nebo položky rovnou zaplatit. Formulář pro zaplacení položek obsahuje známý bílý rám, na který je možné přesouvat z účtu vybraného v levém panelu jednotlivé položky, které chce uživatel zaplatit. Pokud uživatel nevybere žádnou položku, je zaplacen celý účet najednou. Stejné pravidlo platí také pro akci zaplatit kreditem, která je dostupná pouze, je-li k účtence přiřazen uživatel. Vedle tlačítka pro zaplacení kreditem je zobrazena výše uživatelova kreditu, která je po stisknutí tlačítka znovu zkontrolována, a v případě dostatečného zůstatku jsou položky zaplaceny. Při stisku libovolného z tlačítek pro platbu (hotově či kreditem), se ihned začne tisknout účtenka a objeví se potvrzení, zda je vše v pořádku, a zda systém může platbu potvrdit a zaevidovat. Účtenku je možné vytisknout i bez placení vlastním tlačítkem. Vybrané položky je možné zrušit bez placení. Této funkce uživatel využije v případě, že nějaké položky objednal chybně. Pro bezpečnost nelze zrušit všechny položky na účtu najednou. Uživatel tedy musí vždy položky pro zrušení nejprve vybrat. Položky jsou stále uloženy v databázi, s nastaveným příznakem "zrušeno"(isCanceled). Tyto objednávky se pak nikde nezobrazují, ale v budoucnu mohou posloužit při inventuře, statistikách či pro detailní výpis historie účtu. V tomto formuláři je také možné celý účet bez placení uzavřít. Otázka o uzavření účtu se zobrazí také po zaplacení či zrušení všech položek na účtence. Uzavřený účet se nezobrazuje v seznamu pro výběr aktivní účtenky a není možné ho upravovat. Je však možné ho znovu otevřít skrze formulář s detailním seznamem účtů, viz příslušný odstavec níže. Tím, že se účtenka uzavře, se nijak nezmění stav objednávek, které obsahuje. Pokud tedy před uzavřením obsahovala nezaplacené objednávky, zůstanou tyto objednávky nezaplacené i po té, co se účtenka uzavře. Přesun objednávek Kromě zaplacení či zrušení, existuje další způsob, jak s objednávkami manipulovat. Lze je mezi aktivními účty libovolně přesouvat. K tomuto účelu slouží poslední z tlačítek v levé skupině v nástrojové liště. Formulář opět obsahuje bílý rám, na který uživatel pomocí tlačítek v účtence v levém panelu navolí, které objednávky chce přesunout. Vedle bílého rámu je pak další rám, obsahující seznam všech aktivních účtů. Tento seznam má stejné dotykové ovládání pro rolování jako bílé rámy s účtenkami. Pod bílým rámem se seznamem objednávek pro přesun jsou opět tlačítko pro zrušení a tlačítko pro uskutečnění přesunu. Pokud nejsou vybrány žádné objednávky, přesunou se všechny objednávky na zvoleném účtu. Tato funkce je vhodná pro rozdělení jedné účtenky na dva nezávislé účty. Po přesunu se objednávka na svém nově přiřazeném účtu chová zcela standardně, a lze z ní tak také manipulovat, včetně dalšího přesunu na jiný nebo na původní účet.

26

KAPITOLA 4. REALIZACE

Seznam účtů První tlačítko zleva v pravé skupině slouží pro zobrazení komplexního výpisu účtů. Tento formulář si ze všech nejvíce zachoval svou původní podobu a funkcionalitu. Původně formulář obsahoval tlačítka pro rolování tabulkou a pro výběr účtenky, která je v tabulce zvýrazněna (označena). Tyto tlačítka byly doplněny posuvníkem s dostatečnými rozměry, a tlačítko pro výběr přímo kliknutím na příslušný řádek v tabulce. Vedle tabulky je rám s možnostmi filtrování. Po výběru typu filtru pomocí tlačítek napravo od tohoto rámu, se v seznamu rámu objeví jednotlivé možnosti daného filtru. Filtrování bylo implementováno již v dodané verzi, a nebudu ho tedy detailně popisovat. Po kliknutí na účet v tabulce dojde k ověření, zda je vybraný účet uzavřen. Pokud účet je uzavřen, zobrazí se téměř prázdný formulář, pouze s možností vrátit se zpět na formulář s tabulkou, a tlačítkem pro znovu-otevření účtu. Pokud je vybraný účet otevřený, přejde se na formulář pro vytvoření objednávky. V obou případech je vybraný účet označen v levém panelu. Pokud byl však vybrán uzavřený účet, dojde k deaktivaci tlačítek pro manipulaci s účtem, které se znovu aktivují až při výběru jiného účtu, nebo případně po znovu-otevření vybraného účtu.

Vložení kreditu Již v dodané verzi bylo možné platit kreditem. Zásadní chyba v tomto systému byla pouze jedna, a to že při placení byl brán kredit aktuálně přihlášeného uživatele, nikoliv uživatele přiřazeného k účtu. Formulář pro vkládání kreditu byl pouze upraven na nový design, jako je sjednocení velikosti tlačítek a textových polí, způsob vstupu, a podobně. Rám tedy dostal stejný design, jako má například formulář pro vytvoření nového účtu. Pod rámem s tlačítky a textovými poli jsou pak opět tlačítka pro vymazání formuláře či jeho potvrzení. Nově se v rámu vyskytuje informace o aktuální výši kreditu vybraného uživatele. Pro výběr uživatele pak slouží celoobrazovkový výběrový seznam, a pro zadání výše vkládaného kreditu klávesnice nastavená na pouze numerický vstup.

Vytvoření zákazníka Aby bylo možné účtenky přiřazovat konkrétním hostům, nebo přiřazovat těmto hostům kredit, je nutné mít možnost je v systému rychle a pohodlně vytvářet. K tomu slouží prostřední z tlačítek v pravé části nástrojové lišty. Tato funkcionalita byla také přítomna již v dodané verzi, a byly tedy pouze odstraněny drobné chyby a upravena vizuální stránka formuláře. Formulář dostal stejnou podobu, jako například předchozí formulář pro vložení kreditu. Rám obsahuje vstupní pole a k nim příslušná tlačítka. Pro vytvoření nového zákazníka je nutné vyplnit všechny dostupné položky, tedy jméno, příjmení a uživatelské jméno. Poslední vyjmenované je nutné, jelikož entita zaštiťující zákazníky je stejná, jako entita pro zaměstnance, kteří používají program CashBob. Tato zvláštnost byla konzultována a k její úpravě prozatím nedošlo, jelikož tento způsob implementace umožňuje uživatelům vystupovat v systému také jako hosti, a objednávat si tedy zboží. Stejně tak je možné případně upravit zákazníka tak, aby mohl systém využívat, ačkoliv nastání této situace je velmi nepravděpodobné. Drobná úprava fungování této entity v systému je součástí dokumentu vytvořeného jako návrh na upravení systému slev, viz příloha H.

4.1. ÚPRAVY GUI A FUNKCIONALITY

27

Kategorie účtů Jako jedna z možností třídění účtů (ve formuláři se seznamem účtů a jejich filtrování) je také dle kategorie účtů. Pro vytvoření kategorie slouží právě tento formulář, který obsahuje pouze dvě položky, kterými jsou jméno a popis kategorie, přičemž popis je nepovinný. Kategorii lze pak vybrat při vytváření nové účtenky či ji později změnit při jeho úpravě. Tato funckionalita se vyskytoval již v dodané verzi, a formulář byl opět pouze přestavěn na nový design. Rychlo-účtenka Zcela novou funkcí je v systému tzv. "rychlo-účtenka". K aktivaci této funkce slouží tlačítko pod aktivní účtenkou, a její funkce odpovídá pojmenování. Po stisknutí tlačítka je automaticky vytvořen a vybrán účet pojmenovaný dle aktuálního data a počtu v daný den vytvořených rychlo-účtenek. Automaticky je zobrazen formulář pro vytvoření objednávky, který je však ve zvláštním stavu, jež způsobí změnu chování po stisku tlačítka pro objednání. Po navolení položek toto tlačítko totiž položky kromě objednání také rovnou zaplatí. K tomu dojde pomocí skrytého volání formuláře pro placení. Formuláři se nastaví příznak pro potlačení všech zbytečných dialogů (jako je v tuto chvíli například nutnost potvrzení platby všech položek najednou), a je uměle aktivováno akce spouštějící se po stisknutí tlačítka pro placení. Po zaplacení se navíc zvolená účtenka automaticky uzavře, a zobrazí se seznam pro vybrání jiného účtu. Tato funkce je vhodná při rychlém výdeji nápojů na baru, kdy je zbytečné vytvářen účet na konkrétní stůl či osobu, ale je stále nutné proběhlou objednávku a platbu evidovat v systému. Využitím této funkce odpadá nutnost manuálního vyplňování informací a potvrzování dialogů, které by v této situaci byli bezpředmětné.

4.1.10

Vyřazené funkce

V textu již bylo zmíněno, že v zájmu vytvoření kvalitního softwaru, bylo nutné přikročit k odstavení některých funkcí, které se v dodané verzi vyskytovali. Jejich dokončení či předělání na dostatečnou úroveň by vyžadovalo příliš mnoho času a úsilí, které bylo vhodnější věnovat jiným, důležitějším, či méně náročným ale podstatným, funkcím. V podstatě se jedná pouze o jeden výraznější celek, kterým jsou slevy a s nimi spojené formuláře a možnosti. Slevy byly v systému implementovány tak, že umožňovali srážku (konkrétní částku či procentuálně) z ceny určitého výrobku, nebo pro daného uživatele. Důvodů k odstavení slevové funkcionality je několik. Za prvé, nebyl dokončen management slev. Nebylo možné provádět základní úkoly, jako například měnit nastavené hodnoty slevy, nebo zpětně zkontrolovat, k jakému výrobku je jaká sleva přiřazena. Použité slevy se pak nesprávně sčítali a nebylo možné například nastavit pořadí slev (zda nejprve snížit částku, a poté srazit procenta, či na opak). Dále nebylo možné přiřazovat slevy celým skupinám výrobků, ale pouze jednotlivým výrobkům zvlášť. Také neexistovali žádné zákaznické skupiny, kterým by bylo možné slevu přiřadit. V systému totiž existují pouze role, které kromě definice funkce a práv přihlášeného uživatele, rozlišují zákazníka od zaměstnanců. Zákazník je prakticky zaměstnanec bez jakýchkoliv práv. Celá dostupná zpráva slev pak byla nelogicky zařazena do pokladního modulu. Zde by však mělo být možné pouze slevy zobrazit, případně je přiřadit vytvářeným zákazníkům či účtenkám. Samotná zpráva, tedy vytváření a přiřazení položkám, by měla být spíše v manažerském modulu.

28

KAPITOLA 4. REALIZACE

Nutné úpravy by tedy vyžadovali kromě úpravy velkého množství formulářů na novou grafickou podobu (nebo jejich přesun do manažerského modulu, což by vyžadovalo jejich naprosté předělání) a jejich otestování, také úpravy v samotné logice, a v ideálním případě také rozšíření modelu o nový způsob kategorizace zákazníků (například na studenty, seniory a podobně). K této části byl vypracován návrh na úpravy (viz příloha H, na základě kterého bylo později rozhodnuto o nevyužití slev ve výsledné verzi programu z důvodu rozsahu nutných prací. Kromě slev není ve výsledné verzi programu přítomný celý směnový modul. Tento modul byl vyvíjen paralelně s pracemi v předmětu SI2 [13], kdy docházelo k výrazným úpravám v rozhraních, přesouvaní celých tříd a změn ve struktuře kódu. Práce na směnovém modulu pak prováděl kolega Martin Kosek v rámci své bakalářské práce [11] v odděleném repositáři, jelikož nebyl součástí týmu v předmětu SI2, a docházelo by ke kolizím práce, či problémům při koordinaci prací. Směnový modul je tedy pravděpodobně hotový, ale není napojený na upravená rozhraní. Modul byl navíc pravděpodobně také vytvořen s podporou pro dotykové ovládání. Bylo by tedy nutné jeho grafický vzhled a ovládací prvky přizpůsobit tak, aby vyhovoval novému návrhu pokladního modulu. Vzhledem k tomu, jak náročné byli tyto úpravy v pokladním modulu, v jehož kódu bylo navíc po předchozím semestru snadné se orientovat, by tato práce zabrala minimálně stejně času, tedy čtvrtinu času stráveného na celé bakalářské práci. Rozsahem tedy odpovídá napojení směnového modulu semestrálnímu projektu, nebo minimálně části prací v týmových pracích v předmětu SI2. Na směnový modul je vytvořené tlačítko v hlavním menu, ale je aktuálně zcela skryté. Výsledná verze obsahuje pravděpodobně jednu ze zcela prvotních revizí směnového modulu, který je sice spustitelný, ale obsahuje čistě grafické rozhraní bez jakékoliv logiky zpracování vstupů.

4.2

Instalační balík

Před započetím prací na samotném instalačním balíku, bylo nutné udělat několik úprav ve způsobu, jakým se aplikace kompiluje a vytváří cílové soubory. Poté bylo teprve možné tyto soubory zpracovat a vytvořit s nich jednotný instalátor, který je dle nastavení rozbalí v cílovém počítači a provede pak další nutné úkoly.

4.2.1

Příprava projektu

Projekt CashBob byl vyvíjen v prostředí NetBeans [16] za pomocí distribučního nástroje Maven [4]. Maven umožňuje rozsáhlé natavení a rozšíření pomocí velkého množství dostupných doplňků (plug-ins). Vše probíhá úpravami příslušného xml souboru projektu. Původní nastavení nástroje Maven využívalo doplněk Assembly [5], který automaticky zkopíruje zdrojové soubory do nastavené cílové složky. Již mezi zdrojovými soubory byly vytvořeny dávkové soubory. Pomocí těchto souborů pak bylo možné v cílovém adresáři spustit hlavní třídu zkompilovaného programu, a tedy program spustit. Od dávkových souborů bylo upuštěno, a byly nahrazeny automaticky generovanými spustitelnými soubory s příponou exe. Tyto soubory jsou vytvářeny vždy při vystavění cílových

4.2. INSTALAČNÍ BALÍK

29

souborů pomocí Maven doplňku shahed [6] a Launch4j [12]. Shaded plugin nejprve vytvoří tak zvaný "super-jar", který obsahuje všechny Java soubory, včetně hlavní spustitelné třídy. Tento soubor pak použije 4j pro vytvoření spustitelných exe souborů. Spustitelné soubory jsou pak vytvořeny ve dvou verzích jak pro klienta, tak pro server. Jedna verze vždy spustí kromě základního uživatelského prostředí také konzoly, což je vhodné hlavně při ladění a odstraňování chyb. Druhá verze spustitelného souboru pak spustí pouze hlavní uživatelské rozhraní. Právě tato verze je pak určena pro koncového zákazníka.

4.2.2

Vytvoření instalátoru

Pro vytvoření instalátoru existuje několik nástrojů. Pro tuto práci bylo nutné zvolit takový, jenž poskytne možnosti pro vytvoření takového instalátoru, který kromě samotného rozbalení souborů programu do cílového systému vykoná také další nutné operace, jako je instalace JRE a databáze. Po zběžném prozkoumání trhu s nástroji na vytvoření instalátoru se jako nejvhodnější jevil skriptovací NSIS (Nullsoft Scriptable Install System) [29]. Tento nástroj poskytuje naprostou volnost, jelikož vytvoření instalátoru probíhá dle skriptu, který si uživatel sám napíše. Pro editaci a kompilaci skriptů byl použit doplněk do vývojového prostředí Eclipse [7]. NSIS má také doplněk pro Maven [4], který jeho spuštění automatizuje při kompilaci projektu, avšak tento doplněk byl v průběhu práce na této části nedostupný, a spuštění skriptů je tedy nutné manuálně pro každou revizi. Díky tomu bylo možné do instalátoru přidat spuštění vlastních dávkových souborů, které spustí instalaci JRE [9] a případně MySQL [15]. Instalátor byl nastaven tak, že vždy cílové soubory přepíše. Tedy je-li již na cílovém počítači program CashBob nainstalován, bude prakticky pouze aktualizován a jeho nastavení resetováno na výchozí. Pokud je takto přeinstalován pouze klient, nedojde ani ke ztrátě dat, které jsou uloženy v databázi. Databáze se instaluje logicky pouze se serverovou částí, a probíhá spuštěním dávkového souboru, který konzolovými příkazy spustí instalační balík MySQL v tichém režimu. Poté dojde ke spuštění služby mysqld.exe, a opět stále v konzole k předání souboru s sql příkazy, který vytvoří potřebnou databázi a její schéma. Instalátor také obsahuje skript, díky kterému je nastaveno spuštění databáze vždy po startu systému. JRE se instaluje s klientem i serverem. Pokud již cílový počítač JRE obsahuje, dojde k jeho aktualizaci či opravě (v případě, že je přítomné JRE nižší nebo stejné verze). Pokud bude instalován na jeden počítač server i klient, nemělo by dojít k žádným problémům. Jak vyplývá z předchozího textu, byl vytvořen instalátor zvlášť pro klientskou a serverovou část programu. To umožňuje obě části distribuovat zvlášť na cílové počítače dle potřeby. V budoucnu je možné vytvořit další instalátor, který nainstaluje obě části dohromady, a odpadne tak tedy jedno spuštění instalace JRE.

4.2.3

Nainstalovaná aplikace

Po nainstalování neobsahuje databáze téměř řádná data. Je vytvořen základní uživatel "Admin"s heslem "1234"a přidělenými všemi právy. Skrze tohoto uživatel tak zákazník provede konfiguraci aplikace a vytvoří další uživatele, kterým přidělí vhodná práva. Pokladní

30

KAPITOLA 4. REALIZACE

modul obsahuje jednu vzorovou účtenku, aby bylo jasné, k čemu výchozí formulář slouží (výběr účtenky). Nejsou vytvořeny žádné stoly či kategorie, které by se dali nově vytvářenému účtu přidělit. Stejně tak je prázdný seznam menu a položek k objednání.

4.2.4

Problémy

Jediné, ale zato velmi závažné problémy, způsobuje připojená instalace databázového serveru. MySQL nelze s jistotou nakonfigurovat pomocí připojeného oficiálního konfiguračního nástroje, který v náhodných případech selhává při snaze spustit systémovou službu pro databázi. Manuální konfigurace a nastavení pak fungují spolehlivěji, ale v závislosti na konkrétním systémovém prostředí může také docházet k problémům. Dále o tomto problému v sekci 5.3. S databázovým serverem MySQL se pojí také legální problém, jelikož přímé připojení k distribuci komerčního software je v rozporu s licenčním ujednáním pro standardní užívání. JE tedy nutné před distribucí software kontaktovat příslušné právní oddělení společnosti R a požádat o povolení. ORACLE

Kapitola 5

Testování 5.1

Snížení počtu kroků

V části 2.1 "zadání"byl jako měřitelný cíl vytyčeno snížení počtu kroků dělících uživatele od kýžené funkce na minimum, a minimálně tedy na polovinu. Při měření uvažujme vždy nejmenší možný počet kroků. V původním systému by sice z důvodu nepřehlednosti jistě docházelo k nárůstu tohoto počtu (z důvodu stisknutí nesprávného tlačítka a podobných omylů v navigaci systémem), ale tyto náhodné faktory nebudeme pro přesnost uvažovat. Měření vybraných postupů probíhalo po samotném spuštění programu, přihlášení uživatele a spuštění pokladního modulu. Měřené postupy jsou následující: • Výběr účtu • Objednání položky na účet • Zaplacení účtu • Dohromady - vytvoření učtu, objednání položek a zaplacení. Poslední bod je pouze seskupení předchozích akcí za sebe (s tím rozdílem, že na začátku vytváříme nový účet), ale v zařízeních s barem k tomuto postupu bude docházet velmi často, a je tedy vhodné ukázat také rozdíl mezi původní a novou verzí právě při tomto souhrnném úkonu. Akce objednání a zaplacení také mohou obsahovat více kliknutí, za účelem specifikace objednávaného či placeného zboží. Tento počet kliknutí se však ve staré a nové verzi neliší, a navíc je závislý na konkrétním případě, takže bude z měření vynechán.

5.1.1

Měření

Výběr účtu Původně bylo nutné po spuštění pokladního modulu před jakoukoliv akcí účet vybrat. Seznam s účty se zobrazil až po aktivaci daného tlačítka. Dále pak bylo nutné účet vyhledat a kliknout na něj, tedy 2 kroky. Nově se seznam s účty zobrazí ihned po spuštění pokladního modulu, a je tedy pouze nutné účet vyhledat a zvolit, což je pouze 1 krok. Tento účet zůstane zvolený skrze všechny další funkce, což odbourá další nutnost účet znovu vybírat. Pokud chce pak uživatel vybrat jiný účet, vede k seznamu neustále zobrazené tlačítko v levém panelu.

31

32

KAPITOLA 5. TESTOVÁNÍ

Objednání položky na účet Původně bylo nutné před touto akcí vždy zvolit účet, tedy 2 kroky. Poté teprve bylo možné navolit položky k objednání (proměnný počet kroků) a objednávku potvrdit pomocí jednoho kliknutí. Celkem tedy 3 kroky. V nové verzi se na dialog pro objednání přejde automaticky po výběru účtu a po navolení položek je opět nutné objednávku potvrdit. Byl-li tedy před akcí již vybrán účet, vyžaduje akce pouze 1 kliknutí. Zaplacení účtu V původní verzi je opět nutné vždy vybrat při této akci účtenku, tedy 2 kroky. Nejmenší možný počet kliknutí při placení účtu je 1, a to pro kliknutí na tlačítko pro přidání všech položek na seznam k zaplacení. Poté se dalším tlačítkem zaplatí, tedy 4 kroky. V upravené podobě stačí k funkci přejít, uvažujeme, že účet je vybrán z předchozích akcí, tedy pouze 1 klik. Pro zaplacení všech položek nemusí uživatel nic dělat, jelikož pokud není označena žádná položka k zaplacení, automaticky se zaplatí všechny po kliknutí na tlačítko pro zaplacení. Celkem jsou to pak tedy pouze 2 kroky. Vše za sebou Nejprve opět postup v původní verzi programu: Stisk tlačítka pro vytvoření nového účtu. V původní verzi je nutné uvést jméno (1 klik pro aktivaci klávesnice), stůl nebo uživatele (1 klik pro aktivaci výběrového seznamu, 1 pro výběr entity, 1 pro potvrzení výběru), tedy minimálně 4 kliknutí. Kliknutí na tlačítko pro potvrzení vytvoření účtu. Nový účet byl vytvořen, přejdeme manuálně do formuláře pro vytvoření objednávky a účet musíme vybrat ze seznamu, tedy 2 kliknutí. Navolíme položky a objednávku potvrdíme stiskem tlačítka (uvažujeme tedy 1 kliknutí). Nyní musíme přejít na akci pro placení, a znovu účet vybrat, tedy opět 2 kliknutí. Stiskneme tlačítko pro přesun všech položek a platbu potvrdíme, což dává další 2 kliknutí. Celkem tedy původní verze vyžadovala pro tuto proceduru 13 kliknutí nebo doteků prstem. Tento postup zahrnuje také nutnost minimálně dvakrát účet vyhledat v seznamu všech aktivních účtů, ačkoliv chceme stále manipulovat s tím samým účtem, který byl na začátku vytvořen. Pro novou verzi existují dva postupy. Nejprve klasický, odpovídající více původnímu postupu: Kliknutí na tlačítko pro vytvoření účtu. Je vyžadováno pouze jméno, které se také automaticky vyplní v případě zvolení osoby, takže minimálně pouze 1 kliknutí pro klávesnici, nebo 2 kliknutí pro aktivaci výběrového seznamu a jeho automatickému zavření po výběru uživatele. Potvrdíme kliknutím na příslušné tlačítko a aplikace automaticky přejde do formuláře pro objednávku. Navolíme položky a objednávku 1 kliknutím potvrdíme. Nyní musíme manuálně přejít k placení, tedy 1 klik. Položky se platí automaticky všechny, tedy pouze 1 klik pro zaplacení všech položek najednou. Celkem můžeme tedy mít pouze 6 kliknutí. Druhá možnost jak tuto proceduru vykonat je v nové verzi takzvaná rychlo-účtenka, která je popsána v posledním odstavci kapitoly 4.1.9. Pro využití této funkce stačí stisknout neustále zobrazené tlačítko pod aktivním účtem. Automaticky je vytvořen účet, a zobrazen formulář pro objednávku. Po navolení položek stačí objednávku potvrdit, a účet je automaticky zaplacen a uzavřen. Nepočítáme-li výběr položek pro objednání (což nebylo bráno v úvahu ani v předchozích postupech), máme pak pouze 2 kliknutí pro stejnou proceduru, která si v původním systému vyžádala kliknutí 13.

5.2. TESTOVÁNÍ GUI

5.1.2

33

Závěr měření

Při pohledu na rozdíly v jednotlivých akcích dojdeme k výsledkům 2:1, 3:1 a 4:2, kde číslo před dvojtečkou je počet kroků v původním systému, za dvojtečkou pak v nové verzi programu. Je také zřejmé, že nejvíce kroků spotřebuje v původním systému právě nutnost vždy účet znovu vybírat, což byl také ostatně hlavní důvod k některým úpravám. Z tohoto důvodu je pak tak rozdílný výsledek provedení více akcí po sobě, kdy je výsledek 13:6. Ze skóre starý systém versus nový systém lze odečíst snížení nutného počtu kroků přibližně na polovinu. K tomuto výsledku vedou jak měření jednotlivých samostatných funkcí, tak měření delší procedury reprezentující komplexnější práci se systémem. Můžeme tedy říci, že vytyčené cíle byly splněny.

5.2

Testování GUI

Testování probíhalo jak při vlastí implementaci tak zpětně pro každou pomyslnou část.

5.2.1

Manuální testování úprav

Nejrychlejším způsobem otestování změn v kódu je spuštění programu a ověření funkčnosti. Při případné chybě lze použít vestavěnou konzoli NetBeans [16] pro vyhledání příčiny chyby díky odkazům z výstupu na konkrétní místo v kódu. Postupně byla tímto způsobem odstraněna většina zásadních chyb.

5.2.2

Automatizované testování GUI

Vizuální úpravy grafického prostředí bylo kromě manuálního testování (bezprostředně po úpravě) otestováno také pomocí dodatečně vytvořených automatizovaných testů. K těmto testům byl využit framework Abbot [31], který má metody pro simulaci akcí kurzoru a vyhledávání aktuálně zobrazených komponent. Pomocí této knihovny byly vytvořeny automatické testy spuštění klientského programu, přihlášení pomocí implicitního účtu (admin/1234) a spuštění pokladního modulu. Testování je automatizované z hlediska pohybů kurzorem. Je však nutné testy manuálně spouštět, aby k jejich provedení došlo. Pro úspěšnost testů je nutné nejprve spustit serverovou část aplikace. Pro zahájení testování stačí na projektu cashBob (tedy projektu obsahujícím základního klienta) spustit úkol "test". Testovací třída automaticky spustí klientskou část aplikace. Je bezpodmínečně nutné, aby uživatel naprosto nijak neovlivňoval vstupy počítače, zatímco testy běží. Jakýkoliv pohyb myší, či stisknutí tlačítka klávesnice, může způsobit chybu. Při testování se může program na několik sekund zdát nečinný, ale stále běží. Náhodně dochází k selhání testu při vyplňování přihlašovacích informací. Tato chyba pramení z příliš rychlého sledu zadání znaků hesla, a není tedy chybou GUI. K této chybě z pravidla dojde několikrát po sobě, a vyřeší se jednoduše opakovaným spuštěním testu. Spuštěný pokladní modul je testován metodou dumb-monkey [22]. Testovací metoda vybírá náhodné body na obrazovce a pokouší se na ně klikat. Jelikož má být GUI pokladního modulu plně dotykové, neměl by být nutný vstup z klávesnice, a při spuštění testu na

34

KAPITOLA 5. TESTOVÁNÍ

libovolný počet kliknutí by měl být úspěšný. Dostatečný počet kliknutí (řádově alespoň tisíce) také relativně důkladně ověří korektní funkčnost všech formulářů a komponent. Náhodné klikání na obrazovce pokladního modulu je omezeno na lehce menší obdélník, než jaké je rozlišení obrazovky. Je tomu tak z důvodu zamezení aktivace ovládacích prvků, které by mohli okno přesunout nebo deaktivovat. Ze stejného důvodu je pak také vyloučena plocha kolem tlačítka pro vypnutí pokladního modulu. Počet náhodných klepnutí kurzorem je dán statickou proměnnou CASHIER CLICKS v testovací třídě cz.cvut.fel.restauracefel.restauracefel.gui tests.MainFrameTests.java. Implicitně je nastavena na hodnotu 1000. Při testování byla tato hodnota zvýšena až na 100 000, což si již vyžádalo poměrně dlouhou prováděcí dobu.

5.3

Testování instalátorů

Pro bezprostřední otestování při úpravě skriptů vytvářejících instalátory posloužilo PC, na kterém probíhal vývoj, a na němž již tedy bylo JRE [9] i MySQL databáze [15] nainstalována. Nedošlo tak k čerstvé instalaci JRE, ale bylo naopak otestováno, že instalace funguje, i v tomto případě. Instalace databázového serveru pak probíhá do jiné složky, než ve které byla umístěna vývojářská instance MySQL (pro kterou byl použit nástroj Xampp [28]). Korektní instalace a spuštění databáze tak bylo možné testovat bez použití jiného počítače. Příležitostně byla pak funkčnost instalátorů ověřována na dotykových terminálech dodaných panem ing. Komárkem, pro které je systém primárně určen. Ladění instalátorů a konečné úpravy pak probíhaly při testování na těchto terminálech, při čemž bylo vždy nasimulováno "čerstvé"prostředí. Tím je myšleno odinstalování JRE, databázového serveru a samozřejmě také klientské i serverové části aplikace CashBob. Při prvním testu na terminálech pak bylo objeveno několik dalších problémů v instalaci MySQL, způsobené jinou verzí a konfigurací systému. Po několika dalších úpravách a otestování na více konfiguracích lze zaručit funkčnost instalace hlavně na dotykových terminálech s Windows XP [20] bez předchozí instalace MySQL databáze. Nelze však bohužel nemožné vyloučit, že na různých konfiguracích se budou instalátory chovat nepředvídatelně. Pro případ selhání instalace databáze, což je nejčastější případ selhání při instalaci, je návod na manuální instalaci v příloze C. Jedním z poznatků instalací na různé počítače je hlášení antivirového programu Avast [3], který instalátory označuje jako podezřelé a snaží se je pustit v ochranném prostředí, které může způsobit nečekané chování instalátoru. V tomto případě je doporučeno hlášení antivirového programu ignorovat.

Kapitola 6

Závěr Změnami a úpravami, které jsem provedl v grafickém rozhraní, či fungování programu, a vytvořením automatizovaného instalátoru, jsem pomohl především budoucím uživatelům aplikace CashBob. Úpravami ve struktuře kódu a dodržením základních zásad při programování, které uvádím v kapitole 2.2, jsem pak zjednodušil práci budoucím týmům, které budou program dále vyvíjet. V programu po mne stále zůstal prostor pro zlepšení, jako je například zprovoznění neaktivních funkcí, jejichž výčet a popis jsem uvedl v kapitole 4.1.10, ale věřím, že jsem splnil vytyčené cíle a zadání, tedy upravení GUI do přívětivé podoby, revize a vylepšení existujících funkcí na úroveň srovnatelnou s komerčními aplikacemi a rozšíření programu o funkce vhodné pro reálné využití, což popisuji kapitole 4.1. Dále jsem také dle zadání vytvořil jednoduchý instalační balík, viz kapitola 4.2. Dle mého názoru je po mé práci program mnohem více použitelný a hlavně příjemnější pro běžné použití. Práce samotná byla pro mne náročná hlavně z časového hlediska, a přinesla mi tak výzvy v organizaci a rozložení práce. Celkem jsem prací strávil přibližně 370 hodin, které jsem průběžně zaznamenával do dokumentu na Google Docs [30]. Logické problémy, jako například zjednodušení práce s pokladním modulem, a hledání ideálního řešení, je pak pro mne přínosem a zkušenostmi do budoucnosti, stejně jako práce s týmovými nástroji (viz 2.2.2) a koordinací práce na jednom projektu ve více lidech.

35

36

KAPITOLA 6. ZÁVĚR

Literatura R Apple. [1] Apple . http://www.apple.com/, 15. 5 2012. R Apple - os x lion. [2] Apple . http://www.apple.com/macosx/, 15. 5 2012.

[3] AVAST Software a.s. avast! http://www.avast.com, 15. 5 2012. [4] The Apache Software Foundation. Maven — welcome to apache maven. http://maven.apache.org/, 15. 5 2012. [5] The Apache Software Foundation. Maven assembly plugin. http://maven.apache.org/plugins/maven-assembly-plugin/, 15. 5 2012. [6] The Apache Software Foundation. Maven shaded plugin. http://maven.apache.org/plugins/maven-shade-plugin/, 15. 5 2012. [7] The Eclipse Foundation. Eclipse — the eclipse foundation. http://www.eclipse.org/, 12. 2 2011. R Android. [8] Google . http://www.android.com/, 15. 5 2012.

[9] Chet Haase. Consumer jre: Leaner, meaner java technology. http://www.oracle.com/technetwork/articles/javase/consumerjre-135093.html, Květen 2007. [10] J. Novák I. Halaška. Popis předmětu — a7b36pro. http://www.fel.cvut.cz/education/bk/predmety/14/02/p1402506.html, 14. 5 2012. [11] Martin Kosek. Bakalářská práce — modul pro plánování směn systému CashBob. https://dip.felk.cvut.cz/browse/pdfcache/kosekma1_2012bach.pdf, 5. 1. 2012. [12] Grzegorz Kowal. Launch4j — cross-platform java executable wrapper. http://launch4j.sourceforge.net/, 15. 5 2012. [13] Ondřej Macek. A7b36si2 - Řízení sw projektů. https://edux.feld.cvut.cz/courses/A7B36SI2/start, 22. 9 2011.

37

38

LITERATURA

R java.com: Java + you. [14] ORACLE . http://www.java.com/en/, 15. 5. 2012. R Mysql — the world’s most popular open source databas. [15] ORACLE . http://www.mysql.com/, 27. 1 2011. R Welcome to netbeans. [16] ORACLE . http://netbeans.org/, 15. 5 2012.

[17] Přispěvatelé Wikipedie. Black box. http://en.wikipedia.org/wiki/Black_box, 15. 5 2012. [18] Přispěvatelé Wikipedie. Cohesion (computer science). http://en.wikipedia.org/wiki/Cohesion_(computer_science), 15. 5. 2012. [19] Přispěvatelé Wikipedie. Coupling (computer programming). http://en.wikipedia.org/wiki/Coupling_(computer_programming), 15. 5. 2012. [20] Přispěvatelé Wikipedie. Microsoft windows. http://en.wikipedia.org/wiki/Microsoft_Windows, 15. 5 2012. [21] Přispěvatelé Wikipedie. Model-view-controller. http://cs.wikipedia.org/wiki/Model-view-controller, 15. 5. 2012. [22] Přispěvatelé Wikipedie. Monkey test. http://en.wikipedia.org/wiki/Monkey_test#Dumb_Monkey_Testing, 15. 5 2012. [23] Přispěvatelé Wikipedie. Objektově orientované programování. http://cs.wikipedia.org/wiki/Objektově_orientované_programování, 15. 5. 2012. [24] Přispěvatelé Wikipedie. Singleton pattern. http://en.wikipedia.org/wiki/Singleton_pattern, 15. 5 2012. [25] Přispěvatelé Wikipedie. Software design pattern. http://en.wikipedia.org/wiki/Software_design_pattern, 15. 5. 2012. [26] Přispěvatelé Wikipedie. Swing (java). http://cs.wikipedia.org/wiki/Swing_(Java), 15. 5 2012. [27] Adam Přibyll pod záštitou CZLUG. Linux.cz - České stránky systému gnu/linux. http://www.linux.cz/, 15. 5 2012. [28] Kai ’Oswald’ Seidler. Apache friends — xampp. http://www.apachefriends.org/en/xampp.html, 27. 1 2011. [29] NSIS team. Nullsoft scriptable install system. http://nsis.sourceforge.net/, 12. 2 2011. [30] Štěpán Tesař, Lukáš Tůma, Tomáš Apeltauer. Cashbob bc — tabulka práce. http://goo.gl/rjwvJ, 15. 5 2012.

LITERATURA

39

[31] Timothy Wall. Abbot framework for automated testing of java gui components and programs. http://abbot.sourceforge.net/doc/overview.shtml, 12. 2 2011. [32] Github — stránky projektu CashBob. https://dip.felk.cvut.cz/browse/pdfcache/kosekma1_2012bach.pdf, 15. 5. 2012.

40

LITERATURA

Příloha A

Obrázky

41

42

PŘÍLOHA A. OBRÁZKY

Obrázek A.1: Logo cashBob.

Obrázek A.2: Původní podoba hlavního okna.

43

Obrázek A.3: Původní podoba pokladního podulu, právě po spuštění.

44

PŘÍLOHA A. OBRÁZKY

Obrázek A.4: Původní podoba přihlašovacího formuláře.

45

Obrázek A.5: Návrh podoby hlavního okna ve formě menu.

46

PŘÍLOHA A. OBRÁZKY

Obrázek A.6: Návrh podoby pokladního modulu. Návrh zobrazuje možnou podobu formuláře pro vytvoření objednávky.

47

Obrázek A.7: Navrhnutá podoba klávesnice.

48

PŘÍLOHA A. OBRÁZKY

Příloha B

UML diagramy

49

50

PŘÍLOHA B. UML DIAGRAMY

Obrázek B.1: Doménový diagram modelu aplikace.

51

Obrázek B.2: Doménový diagram s navrhovanými změnami týkajícími se slevové funkcionality. Červená spojení indikují navrhované nové vazby. Fialové pouze vazby upravené nebo jinak pro tento problém podstatné.

52

PŘÍLOHA B. UML DIAGRAMY

Příloha C

Instalační a uživatelská příručka

53

54

C.1

PŘÍLOHA C. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Úvod

Tento dokument obsahuje základní uživatelské a technické informace o softwaru CashBob a možnostech jeho zprovoznění a ovládání z uživatelského hlediska. Vytvoření tohoto dokumentu došlo výhradně pro účely mé bakalářské práce, zbývající se úpravami softwaru CashBob, hlavně pak jeho GUI a pokladní části. Text obsahuje některé pojmy, jména a odkazy, se kterými se uživatel seznámil při čtení zmíněné bakalářské práce, a nejsou zde tedy vysvětleny. Jsou zde pouze uvedeny obecnější reference na webové aplikace či nástroje. Témata z kapitoly C.2 - Popis Software jsou popsány také již v samotné bakalářské práci a v tomto dokumentu jde tedy spíše o shrnutí a připomenutí k navedení vhodného kontextu pro následující kapitoly. Také slouží jako shrnutí použitých implementačních nástrojů a postupů.

C.2 C.2.1

Popis software Technické detaily projektu

Program CashBob byl vyvíjen v jazyce Java v grafickém vývojovém prostředí NetBeans[16]. Kód je rozvržen do několika vlastních projektů, jeden pro každý modul (pokladní, skladový atd.), serverovou a klientskou část, a vlastní projekt je pak vytvořen také pro tzv. knihovnu (Library), která obsahuje balíky a třídy využívané skrze celý program. Projekty jsou propojené pomocí závislostí, a spojení a vytvoření samostatných distribucí pro klienta a pro server je zajištěno speciálními Maven[4] projekty, které neobsahují vlastní kód. Sestavování projektu probíhá pomocí doplňků pro Maven, konkrétně assembly plugin [5] pro zkopírování zdrojových kódů a souborů připojených projektů, a shade [6] a Launch4j [12] plugin pro vytvořeného souboru exe. Správa úprav kódu probíhala pomocí nástroje Git ve spojení s webovou aplikací GitHub [32], kde byly nutné změny a opravy zaneseny pomocí rozhraní GitHubu takzvanými issues.

C.2.2

Technické detaily instalátorů

Instalační balíky byly vytvořeny pomocí nástroje NSIS [29], který umožňuje otevřené možnosti nastavení instalace a připojení libovolných pod-procesů. Instalační skript nejdříve rozbalí všechny zdrojové soubory do nastavené složky (implicitně program files/CashBob T), kde T je Server nebo Klient, podle toho který z instalátorů probíhá. Mezi rozbalenými soubory se nachází složka /install, která obsahuje další samostatné instalátory a dávkové soubory pro spuštění oněch instalátorů. Tyto dávkové soubory (instal myslq.bat a install jre.bat) jsou volány z instalačního skriptu, a automaticky spustí instalaci JRE a MySQL serveru. Spuštění databáze je pak rozděleno do dvou kroků, kdy v prvním proběhne spuštění samotné služby (run mysql.bat) a zavření zbytečných konzolových oken (kill cmd.bat), a v druhém dojde k nastavení serveru pomocí skriptu setupdb.bat který na spuštěné databázi předá příkazy uložené v souboru db.sql, který se předtím nakopíruje do složky C:/MySQL/bin/.

C.3. INSTALAČNÍ PŘÍRUČKA

55

Instalátor umístí odkazy na aplikaci do nabídky start a na plochu. Do nabídky start je umístěn také odkaz na od-instalační program. Odkaz na dávkový soubor pro spuštění databáze je umístěn do speciální složky Windows, jejíž obsah je spuštěn vždy po startu operačního systému. Tím je docíleno automatického spuštění databáze při zapnutí daného počítače.

C.3

Instalační příručka

Jelikož bylo zadáním bakalářské práce, jíž je tento dokument součástí, vytvoření snadné a co nejvíce automatizované instalace programu CashBob, slouží tato příručka spíše jako popi těchto instalátorů a výsledného stavu cílového počítače.

C.3.1

Instalace

Instalátor je samostatný soubor, pojmenovaný CashBobServer setup.exe či CashBobClient setup.exe. Spuštění instalátoru vyžaduje administrátorská práva, která je nutné na novějších verzích operačního systému Windows potvrdit. Okno instalačního programu je pak velmi standardní záležitost. Je nutné projít několik informativních kroků, přečíst a potvrdit licenci pro používání a zvolit instalační složku. Lze také nastavit, zda vytvářet zástupce v nabídce start. Samotný proces instalace by pak měl proběhnout zcela automaticky, a bez nutnosti zásahu uživatele. Při instalaci se spustí několik dalších oken, která by se měla také sama ukončit. Po úspěšné instalaci při ponechání výchozího nastavení je server nainstalován ve složce Program Files/CashBob server/ nebo /CashBob client/ a jsou spuštěny všechny potřebné služby, které se také automaticky zavedou při startu systému

C.4

Uživatelská příručka

Uživatelská příručka se týká hlavně zprovoznění aplikace po nainstalování serveru a klientů. Je zde také vysvětleno základní ovládání hlavního okna aplikace a pokladního modulu.

C.4.1

První spuštění

Spuštění serveru Po instalaci je možné spustit oba části programu pomocí přiložených zástupců v nabídce start nebo na ploše. Nejprve je nutné spustit CashBob Server. Pokud instalace proběhla v pořádku, server se zcela automaticky spustí. Pokud dojde při spouštění serveru k chybě, došlo s největší pravděpodobností k problému při instalaci databázového serveru. V tomto případě je nutné kontakt s vývojáři (autor práce - Štěpán Tesař), jelikož problém může být způsoben různými důvody, které je nutné manuálně opravit. Spuštění klienta na stejném PC jako server Po spuštění serveru je možné spustit také klientskou části aplikace. Spouštíte-li CashBob Client na stejném počítači, na kterém je spuštěn CashBob Server, spustí se nahrávací obrazovka a po několika sekundách se objeví přihlašovací okno.

56

PŘÍLOHA C. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Spuštění klienta z jiného PC, než na kterém běží server Spouštíme-li klientskou aplikaci z jiného PC, je nezbytné, aby byl počítač na stejné lokální síti, jako je PC se spuštěným serverem. Po spuštění se objeví nahrávací obrazovka a aplikace se nejprve pokusí najít server na PC, na kterém je spuštěna. Po neúspěchu této akce bude zobrazen dialog, ve kterém nastavíte lokální IP adresu počítače, na kterém je spuštěný server. Tuto IP adresu vám sdělí správce sítě, nebo odborný IT pracovník.

Přihlašovací obrazovka Po spuštění klienta se zobrazí přihlašovací okno. V poli pro zadání uživatelského jména (login) by mělo být předvyplněný text “admin”. Pokud je pole prázdné, doplňte tento text manuálně. Dalším polem je heslo, které je nastavené implicitně na “1234”. Po jeho vyplnění a kliknutí na tlačítko přihlášení se objeví hlavní menu aplikace.

Nastavení aplikace Při prvním spuštění je vhodné věnovat se jako první nastavení aplikace, které je dostupné z hlavního menu pod levým tlačítkem v prostředním řádku. Je zde možné změnit IP adresy serveru, což se projeví při dalším spuštění aplikace. Dále můžete změnit adresář s tiskovými šablonami a komunikační port pro periferní zařízení. Měnit toto nastavení se však neodporučuje. Zajímavým nastavením, které se projeví okamžitě, je slovní reprezentace měny. Napsané znaky se budou zobrazovat skrze program, hlavně pak pokladní modul, u hodnot znázorňující cenu. Pro uložení těchto nastavení je nutné stisknout tlačítko uložit. V dialogu s nastavením je také přítomné velké tlačítko s dvěma znaky, které otevře dialog pro jazykové nastavení. Zde je možné změnit jazyk, ve kterém se bude celá aplikace zobrazovat. Pro změnu tohoto nastavení je také nutné restart klientské aplikace. Druhým tlačítkem v prostředním řádku hlavního menu je pak možné měnit uživatelské role a přiřazovat jim práva pro práci v systému. Práva jsou návodně pojmenována, a uživatelské rozhraní by mělo být dostatečně návodné. Pro začátek se doporučuje vytvořit role pro jednotlivá povolání, a dle jejich zaměření nastavit práva. Každý uživatel může mít více rolí, což lze nastavit v manažerském modulu. Funkce manažerského modulu bohužel není součástí práce, k níž byl tento dokument vypracován, a jeho fungováni zde tak není popsáno.

C.4.2

Ovládání aplikace

Hlavní menu V prvním řádku hlavního menu se vyskytují tlačítka pro spuštění jednotlivých modulů. Tyto tlačítka jsou neaktivní, pokud ke spuštění modulu nemáte potřebná práva. Funkce tlačítek v prostředním řádku menu je popsána v kapitole “nastavení aplikace”. Ve spodním řádku je pak jediné tlačítko, které po potvrzení odhlásí aktuálního uživatele, a zobrazí přihlašovací formulář.

C.5. ZÁVĚR

57

Pokladní modul Funkce pokladního modulu je velmi komplexní a rozsáhlá. Popíšeme zde tedy pouze základní operace s účtenkami, tedy vytvoření, objednání a zaplacení. Vytvoření účtu probíhá prvním tlačítkem zleva v horní nástrojové liště. Je nutné vyplnit pouze jméno účtu (červená šipka), a poté je možné účet vytvořit. Ostatní položky jsou nepovinné, a jejich jména jsou poměrně návodná. Stoly a uživatele je možné spravovat v manažerském modulu. Kategorie pak pod druhým tlačítkem zprava v horní liště. Automaticky po vybrání účtu, nebo po jeho vytvoření, se účet zobrazí v levém panelu. Pod tímto panele je tlačítko pro výběr jiného účtu, či pro vytvoření rychlo-objednávky, která po objednání účet rovnou zaplatí a uzavře. Objednávku lze provést pouze se zvoleným účtem, a slouží pro ni druhé tlačítko zleva v horní nástrojové liště. Jednoduše vyberete menu, ze kterého chcete položky objednat, a poté konkrétní položky. Pokud je seznam menu a položek prázdný, je nutné je vytvořit pomocí manažerského modulu. Zaplacení lze také provést pouze s aktivním vybraným účtem, a slouží k němu třetí tlačítko v liště. Vyberete položky, které chcete zaplatit, a příslušným tlačítkem proceduru potvrdíte. Pokud byla k účtence přiřaděna osoba, je možné platit kreditem, k čemuž slouží tlačítko v pravém horním rohu. Zde jsou také tlačítka pro tisk účtenky (která se ale vytiskne automaticky také při placení), zrušení vybraných objednávek, nebo uzavření celého účtu. Kredit lze uživateli doplnit pomocí tlačítka s ikonou člověka a bankovky v horní liště.

C.5

Závěr

Tento dokument měl hlavně shrnout záležitosti týkající se instalace a prvotní orientace v aplikaci, jelikož v hlavním dokumentu bakalářské práce jsou tyto témata popsána velmi detailně hlavně z pohledu provedených prací a úprav. Jejich nalezení v hlavním dokumentu by tedy mohlo být zdlouhavé, a tento dokument by měl první kroky s programem usnadnit.

58

PŘÍLOHA C. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Příloha D

Obsah přiloženého CD Přiložené CD obsahuje jak zdrojové soubory pro vývoj programu, tak vytvořené instalační balíky, vhodné pro nasazení aplikace. Dále je na CD tento dokument v elektronické podobě ve formátu pdf, spolu s přílohami, které byli připojeny jako externí pdf soubory. K tomuto dokumentu je zde také původní text napsaný v jazyce LATEX, spolu se všemi sub-dokumenty, obrázky a dokumenty příloh.

D.1

Struktura složek a souborů

1. Distribuce — Tato složka obsahuje instalátory pro distribuci serverové i klientské části, tedy soubory: (a) CashBobClient.exe — instalátor pro klientskou část. (b) CashBobServer.exe — instalátor pro serverovou část. 2. Dokumenty — Zde se nachází elektornická forma tohoto dokumentu. 3. Dokumenty/Tex — zdrojové soubory dokumentu v LATEX, ze kterých je konečný pdf dokument vytvořen. 4. Zdroj — Zdrojové kódy upravovaného softwaru CashBob. Většina složek v tomto adresáři obsahuje jednotlivé projekty, nebo případně soubory s projekty nějakým způsobem související.

59

60

PŘÍLOHA D. OBSAH PŘILOŽENÉHO CD

Příloha E

Rešerše GUI restauračních systémů

61

Rešerše GUI restauračních systémů Štěpán Tesař

1

Obsah Rešerše GUI restauračních systémů Obsah Úvod Kapitola 1 - Specifikace 1.1 - Zadání 1.2 - Výběr softwaru Kapitola 2 - Zkoumaný software 2.1 - ValuePOS 2.2 - HotSale 2.3 - Retail Man 1.90 2.4 - Jazz Restaurant Lite 2.5 - AZSOFT Kapitola 3 - Porovnání 3.1 - Obecné vlastností GUI 3.2 - Rozdělení programu 3.3 - Pokladní část 3.4 - klávesnice 3.5 - Nabídky a okna Kapitola 4 - Zpracování výsledků 4.1 - Hlavní zásady 4.1.1 - Oddělení nedotykových částí 4.1.2 - Dostatečně velká tlačítka 4.1.3 - Ucelený grafický háv 4.2 - Srovnání principů GUI Závěr

2

Úvod Podnětem k vypracování této rešerše, bylo zadání mé bakalářské práce, jejíž součástí je optimalizace grafického prostředí v systému CashBob, vyvíjeného pod záštitou katedry počítačů, Fakulty Elektrotechnické, univerzity České Vysoké Učení Technické. Výraz GUI pochází z anglického “Graphical User Interface”, neboli v překladu “grafické uživatelské prostředí”. V tomto dokumentu si dovolím uvedenou aberaci používat. Je také třeba upozornit na fakt, že v textu se mohou vyskytovat další výrazy, pro jejichž plné porozumění textu je potřeba určitá technická či počítačová gramotnost.

3

Kapitola 1 - Specifikace 1.1 - Zadání Hlavním cílem je získat ucelený přehled o prvcích grafického prostředí používaného v existujících restauračních systémech. Pro konkrétnější představu o obsahu rešerše je však nutné upřesnit zadání. Nadpis dokumentu v rámci stručnosti nezmiňuje, že provedený výzkum se týká výhradně systémů určených pro dotykové terminály, tedy také, u kterých nelze předpokládat připojení fyzické klávesnice a počítačové myši, nebo jiných periferních zařízení, a hlavní komunikace se softwarem bude probíhat skrze dotykový displej. Na trhu se pro označení tohoto druhu softwaru používá označení POS (Point Of Sale), který je však obecnější, a zahrnuje také systémy využívaných v pokladnách supermarketů, hotelech, nebo obecně umožnující monitorování prodeje nějakého zboží či služeb. Zkoumaný software byl omezen pouze na restaurační systémy. Tedy systémy určené pro správu prodeje nápojů a pokrmů v restauracích, případně hospodách a barech. Tyto systémy se například od těch používaných na pokladnách supermarketu diametrálně odlišují případy užití, a konkretizace tedy má v rámci této rešerše smysl.

1.2 - Výběr softwaru V první řadě proběhl výběr zkoumaného softwaru selekcí vhodných výsledků na dotaz internetovému vyhledávači společnosti Google (dále jen Google). Vyhledávaná fráze specifikovala určení softwaru a nutnost jeho použití na dotykových displejích. Z nalezených aplikací pak byly vybrány ty, ke kterým byla na webu dostatečná dokumentace, včetně vizuálních ukázek, nebo stažitelná demoverze poskytující plnou funkcionalitu aplikace (omezení demoverze tedy spočívá v době používání, nebo omezení počtu položek menu či jiných entit). Dále byl vyhledán software, o kterém se zmiňuje pan Jakub Jambor ve své bakalářské práci1 (při níž pracoval na předchozí verzi stejného softwaru, který byl podnětem této rešerše) v kapitole 2.3, kde se odkazuje na rešerši Jaromíra Mlejnka, kterou jsem však nebyl schopný dohledat, ale jmenovitý seznam softwaru pro jejich nalezení postačil. Z tohoto seznamu byly opět selektovány pouze vyhovující systémy, jelikož pan Jakub Jambor měl odlišné zadání, a tedy mu i v testovaném softwaru hleděl na jiné věci.

1

https://dip.felk.cvut.cz/browse/details.php?f=F3&d=K13136&y=2010&a=jambojak&t=bach 4

Kapitola 2 - Zkoumaný software V této kapitole se vyskytuje seznam softwaru ve zkoumaném vzorku, vybraného postupy uvedenými v kapitole 1.2.

2.1 - ValuePOS Program společnosti Computerbanc Inc., ke kterému je dostupná na domovských stránkách2 spustitelná demoverze, jejíž omezení není přesně specifikováno, a zdá se, že dokonce možná žádné nejsou. Program je dle výrobce nabitý funkcionalitou, což je zřejmě i pravdou, jelikož aplikace je v podstatě změť tlačítek a vyskakujících oken, které se překrývají a obsahují další tlačítka vedoucí do dalších oken. Aplikace se spouští skrze přihlašovací formulář, který hraje všemi barvami (dokonce tu a tam něco bliká), a obsahuje několik ne zcela jasných funkcí (kalkulačka). Po přihlášení se nabídne okno odkazující do dalších částí systému. Jednotlivé části jsou extrémně přeplněné tlačítky, a bez přečtení uživatelského manuálu je téměř nemožné se v programu rychle zorientovat, což je pravděpodobně daň za snahu nabízet přístup k co nejvíce funkcím najednou. Jednotlivé části jsou také dost nekonzistentní. Různá barevnost, velikosti písem či styl obrázků jsou pouze nejvíce do očí bijící prohřešky. O to děsivější je zjištění, že software byl pravděpodobně vydaný v roce 2008, kdy měl již být grafický návrh nedílnou součástí vývoje. Kromě čistě designových záležitostí je systém také zcela nevyhovující pro použití čistě s dotykovým terminálem, i přesto, že je tak koncipován, jak dokazuje například logovací okno, kde je přítomna numerická klávesnice s velkými tlačítky, a obecně všemi prvky tak, aby bylo použití dotykové obrazovky možné. Jinde však nalezneme obyčejná malá textová okénka ve stylu Windows, a stejně tak zaškrtávací pole nebo seznamy.

2.2 - HotSale Výrobcem aplikace je HotSaleApp, a na oficiálním webu3 je k dispozici plná verze aplikace omezená třiceti dny použití. Tento program je pravděpodobně nejaktuálnějším, a minimálně vizuálně nejkvalitnějším z testovaných. Domovská stránka je stále aktualizována, a software pravděpodobně není starší než jeden rok. Design je velmi ucelený, poněkud temný, ale přehledný. Ačkoliv je hlavní okno evidentně určeno k použití na dotykovém displeji, o jiných nabídkách a dialozích se to již zcela říci nedá, jelikož obsahují malé textové pole, tlačítka a tabulky. Kombinace celkově tmavého prostředí s naprostou absencí obrázků pak může působit poněkud pochmurně.

2.3 - Retail Man 1.90 Program společnosti EziSolutions4, u kterého se mi nepodařilo spolehlivě určit datum produkce, ale protože výrobce uvádí plnou kompatibilitu se systémem Windows 7, dá se maximální stáří odhadnout přibližně na 2 roky s tím, že absolutní jádro programu bude pravděpodobně starší. Na webu je dostupná 30 denní zkušební verze s plnou funkcionalitou. 2 3 4

www.valuepos.com www.hotsaleapp.com www.ezisolution.co.uk/retail.htm 5

Aplikace je laděná do příjemných barev, a tlačítka obsahují piktogramy, které při delším užívaní pravděpodobně začnou dávat smysl. Aplikace má jedno hlavní okno, v rámci kterého se spouštějí další vnořená okna poskytující kýžené funkce. V aplikaci se však objevuje stejný problém jako u ostatních, a to obsah klasických nabídek a tlačítek, které jsou pro dotykové displeje nevyhovující. V programu se sice vyskytují části, které evidentně mají být ovládány ze stolního PC, ale samotné okno pro vytváření účtu s velkými tlačítky pro výběr položek, obsahuje zmíněné nevyhovující prvky také. Program je však přehledný, a vizuálně příjemný.

2.4 - Jazz Restaurant Lite Restaurační software od české firmy jazzware5 která poskytuje ke stažení plnohodnotnou verzi omezenou počtem pokrmů a účtenek. Testovaná verze je dle webu k dispozici od 8.9.2011, a je tedy velmi aktuální. Systém je laděný do světle modré barvy, a poskytuje možnost změny velikosti jednotlivých ovládacích prvků. Základní okno po spuštění je přímo určeno k vytváření účtů a objednávek, a je velmi jednoduché se v něm zorientovat, také díky poměrně návodných ikonám a popiskům tlačítek. Do dalších částí se pak dá přejít pomocí menu v záhlaví, které již samo pravděpodobně není určeno k dotykovému ovládání, ale je přesto zobrazeno neustále. Další sekce již evidentně vyžadují periferní zařízení, jelikož graficky nejsou pro dotykové ovládání vůbec přizpůsobena.

2.5 - AZSOFT Systém pochází od společnosti AZ systémy s r.o. a pravděpodobně pochází z roku 2009. K dispozici jsou na webových stránkách pouze dva obrázky, které však podávají dostatečnou představu o podstatných částech systému, ale stále ji nelze testovat tak detailně, což vede při porovnávání k nedostupnosti řady informací. Okno pro objednávky se zdá být přeplněné tlačítky, z nichž na některých místech dokonce přetéká text. Nevábně působí čistě funkční design s různobarevným písmem, který bohužel obsahuje také drobné tabulky a titěrné posuvníky převzaté z prostředí Windows, které vskutku dotykovému ovládání nevyhovují. Aplikace je evidentně rozdělená na několik modulů, z nichž jsou kromě pokladního ostatní určeny spíše k ovládání na stolním počítači.

Kapitola 3 - Porovnání Samotné porovnání jednotlivých aplikací seskupené do jednotlivých sekcí, dle testovaných vlastností. Pokud jsou v tabulce uvedena pouze čísla, jedná se o bodové hodnocení na stupnici čísel 0 až 5, kde 0 je nejhorší/nejméně, a 5 je nejlepší/nejvíce.

3.1 - Obecné vlastností GUI Nejprve proběhlo porovnání programů v rámci celkového dojmu a nejzásadnějších možností, které grafické prostředí poskytuje.

5

www.jazzware.cz 6

● ● ● ●

Rozměr - zda má okno nastavený rozměr, či zda ho lze měnit dle potřeby. Konzistence - souvislost designového návrhu skrze jednotlivé části aplikace. Grafický návrh - ohodnocení grafického hávu celé aplikace. Informace - počet informací dostupných v hlavním nebo průměrně v aktivním dotykovém okně. Nižší hodnota znamená, že se uživatel k potřebným informacím musí “proklikat”. ● Přehlednost - objektivní zhodnocení přehlednosti programu jako celku. ● Velikost prvků - platí, že čím větší jsou ovládací prvky, tím lépe se se systémem na dotykovém displeji pracuje. V žádném ze systémů nedošlo k situaci, že by ovládací prvky byli příliš velké, tedy platí, že čím větší číslo, tím lepší. Pokud jsou uvedená dvě čísla, pak je část prvků svou velikostí výrazně odlišná. ValuePOS

HotSale

RetailMan

Jazz Lite

AZSOFT

statický

nastavitelný

nastavitelný

nastavitelný

neznámo

Konzistence

0

4

3

2

1

Grafický návrh

0

4

4

2

0

Informace

3

2

2

4

4

Přehlednost

0

2

3

5

3

Velikost Prvků

2/5

3

1/4

2/4

3

Rozměr

7

3.2 - Rozdělení programu Další ze zkoumaných kategorií GUI bylo logické rozdělení funkčně odlišných částí programu, hlavně pak způsob oddělení částí uzpůsobených pro dotyková zařízení a částí vyžadujících použití klávesnice a myši. V částech určených pro dotyková zařízení je pak zásadní výskyt prvků, které nejsou pro dotyk uzpůsobené, jejich počet a závažnost komplikací, které může prvek způsobit. ● ● ● ●

Optimalizace pro dotyk - zda, a jaké části programu, jsou určeny pro dotykové ovládání. Oddělení - zda, a jak, jsou odděleny dotykové části od nedotykových. Přístup - způsob přístupu k nedotykovým částem. Nedotykové prvky - v jaké míře se vyskytují nedotykové prvky v částech určených pro dotyk. Zde platí, že více prvků je horší. (Číslo neudává konkrétní počet prvků, ale relativní míru výskytu, přičemž 5 je velmi mnoho a 1 je velmi málo).

ValuePOS

HotSale

RetailMan

Jazz Lite

AZSOFT

Celá aplikace

Hlavní okno

Pokladní část

Pokladní okno

Pokladní modul

Oddělení

Není

Více oken

Pod-okna

Změna obsahu

Moduly

Přístup

Není

Dotyková tlačítka

Dotyková tlačítka

Záhlavní menu

není známo

5

2

1

2

1

Optimalizace pro dotyk

nedotykové prvky

8

3.3 - Pokladní část Porovnání vlastností části sloužící k vytváření a placení objednávek. Všechny testované systémy mají společné minimálně to, že tato část je určitým způsobem oddělena, a má být určena pro dotykové ovládání. ● ● ● ●

Typ seznamu - druh seznamu, ve kterém jsou prezentovány položky pro objednávku. Rolování - způsob posouvání seznamu, který se nevejde do okna. Popisky - způsob označení ovládacích prvků. Dynamické seznamy - existence možnosti přiřadit do buněk vlastní položky, tedy nezávislost na tom, jakým způsobem jsou data vytvořeny, nebo existence vlastní sady buněk s “oblíbenými” položkami. ● Vyhledávání - způsob, kterým je umožněno prohledávat a tedy filtrovat seznam položek. ● Umístění seznamu - umístění seznamu položek ve vztahu k základnímu oknu pro objednávky. ValuePOS

HotSale

RetailMan

Jazz Lite

AZSOFT

Typ seznamu

buňky

tabulka

buňky

buňky/tabulka

buňky

Rolování

tlačítka

posuvníky

počet omezen

posuvníky

počet omezen

Popisky

text a obrázky

pouze text

text a/nebo obrázky

text a obrázky

text, obrázky minimálně

Dynamické seznamy

ne

ne

ano, manuální pořadí

ne

ano

Vyhledávání

není

dle volitelné vlastnosti

ne

možnost manuálního zápisu ID

ne

nové okno

nové okno

dolní polovina

dole/nové okno

pravá polovina

Umístění seznamu

9

3.4 - klávesnice Sekce věnovaná čistě testování virtuálních klávesnic daných systémů. Z tohoto testu byly vyřazeny programy HotSale a AzSoft u kterých nebyla virtuální klávesnice nalezena, jelikož pravděpodobně spoléhají na systémové virtuální klávesnice, nebo jsou určeny pro systémy, ke kterým je kromě dotykového displeje k dispozici i jednoduchá klávesnice. ● Druh - druhy virtuálních klávesnic dostupných v systému. “Qwerty” značí plnou textovou klávesnici, “num” vlastní panel s čísly a “calc” je numerická klávesnice rozšířená o matematické funkce. ● Vyvolání - kdy se klávesnice zobrazuje. ● Způsob zobrazení - jak je zobrazená klávesnice zakomponována do prostředí okna. ● Způsob zadávání - způsob jakým je provedeno zadávání textu z klávesnice. ● Speciální znaky - zda jsou na qwerty klávesnici přítomny i jiné než alfa-numerické znaky. ● Shift/CapsLock - zda klávesnice umožňuje psaní kapitálek. ● Numerická část - umístění číselné části v oknu qwerty klávesnice. ● Původní text - zda klávesnice zachovává původní text ve vstupním poli. ValuePOS

RetailMan

Jazz Lite

qwerty+num,num,calc

qwerty, num

qwerty+num

tlačítko v některých oknech

tlačítko u textového pole, numerická pořád

po aktivaci akce vyžadující klávesnici

Způsob zobrazení

statické okno

plovoucí okno

plovoucí okno

Způsob zadávání

vlastní textové pole

vlastní textové pole

vlastní textové pole

Speciální znaky

pouze \ - .

ano, mnoho

Česká diakritika

Shift/CapsLock

CapsLock

Shift

CapsLock

Numerická část

oddělená napravo

řádek nad písmeny

oddělená napravo

ne

ano

ne

Druh Vyvolání

Původní text

3.5 - Nabídky a okna Zobrazení nabídek, seznamů nebo tabulek bylo téměř bezvýhradně ve všech případech ponecháno na systémových prostředcích, tedy žádný z prvků nebyl optimalizován pro dotykové displeje, a to ani v případě že se vyskytoval v části pro dotykové ovládání určené. Toto byl také jediný problém, který se vyskytoval bez ohledu na jiné kvality ve všech systémech. Smutným faktem tedy je, že ani jeden ze systému neměl dotykové ovládání dotažené do absolutního konce. Pochopitelná by tato praktika mohla být pouze v případech systémů nasazených na displeje s malým rozlišením, což je z testovaných pouze ValuePOS.

Kapitola 4 - Zpracování výsledků Díky výsledkům testování je možné vytvořit si představu o množině grafických prvků či principů s pozitivním přínosem pro přehlednost a uživatelskou přívětivost GUI, a stejně tak lze

10

vytvořit výčet věcí, které by se v aplikaci rozhodně vyskytovat neměli.

4.1 - Hlavní zásady Z testování lze odvodit několik hlavních zásad, které je nutné dodržet, pokud je našim cílem vytvořit dobré GUI použitelné na dotykových displejích.

4.1.1 - Oddělení nedotykových částí Nemá cenu snažit se vytvořit dotykově dostupné části aplikace, které je nesmyslné na dotykových terminálech používat. Je nutné si uvědomit, že dotyk budou pro práci používat hlavně servírky či barmani, nebo jednoduše lidé “na place”, kteří potřebují interakcí se systémem trávit co nejméně času, a tedy nemohou bloudit aplikací mezi nekonečným výčtem funkcí. Naopak manažeři podniku, nebo skladníci, se mohou posadit ke svému desktopu nebo notebooku, a relativně v klidu si projít nabídky a funkci, kterou potřebují vyhledat. Oddělení dotykové části také umožní absolutní eliminaci neoptimalizovaných vstupů, jelikož v dotykové části je nutné se vyvarovat zobrazení drobných tabulek, textových polí, posuvníků, tlačítek a podobně.

4.1.2 - Dostatečně velká tlačítka Prsty při dotyku zabírají určitou plochu, a někteří lidé mají větší prsty než jiní. Navíc ve spěchu se člověk nesoustředí na to, aby se dotkl přesně. Je tedy nutné poskytnou co největší plochu, a vizuálně ji zvýraznit tak, aby ji bylo snadné vymezit i rychlým pohledem.

4.1.3 - Ucelený grafický háv Pokud každá část aplikace vypadá jinak, působí pak nekonzistentním dojmem. Uživatel si připadá zcela oddělen od původní části aplikace, a může ztrácet kontext. Je tedy nutné aplikaci navrhovat tak, aby byla barevně a celkově graficky stejnorodá. Tedy pokud se někde vyskytují bledé barvy, hrany a nenápadné obrázky, není možné v další sekci prezentovat zářivé barvy, oblé okraje se stíny a křiklavé obrázky.

11

4.2 - Srovnání principů GUI Výčet všech testovaných prvků a principů uživatelského prostředí, vždy s nejlepším a nejhorším řešením. Nejhorší a nejlepší řešení je vybráno podle tabulky v kapitole 3.1, ze které lze vyčíst, které programy si stojí v celkovém hodnocení dobře a které hůře, a také podle osobní zkušenosti z práce s programy. Nejlepší řešení

Nejhorší řešení

Pokladní část

Celá aplikace

Změna obsahu okna

Více zároveň spuštěných oken

Hlavní menu

Tlačítka v dotykové části

Typ seznamu

buňky

tabulka

Rolování

tlačítka

posuvníky

Popisky

text a obrázky

pouze obrázky

Dynamické seznamy

s manuálním pořadím

ne

Vyhledávání

dle volitelné vlastnosti, implicitně dle názvu

manuální vepsání id

nové okno

část aktuálního okna

Qwerty nebo numerická, dle potřeby

vždy qwerty

automaticky po označení vstupu

tlačítko kdesi v okně, stálé zobrazení

Způsob zobrazení

statické okno, vždy na jednom místě se stejným rozměrem

plovoucí okno, poloha dle pozice vstupu

Způsob zadávání

vlastní textové pole

přímo do označeného vstupu

Speciální znaky

Vybrané

česká diakritika (neuniverzální)

Shift/CapsLock

CapsLock, shift

Pouze shift

Numerická část

Oddělená napravo

řádek nad písmeny

nakopírován do vlastního pole

ztracen

Optimalizace pro dotyk Oddělení nedotykových částí Přístup k nedotykovým částem

Umístění seznamu

Druh klávesnice Vyvolání

Původní text

12

Závěr Při práci na tomto dokumentu jsem došel k několika zajímavým poznatkům. Například je zřejmé, že u většiny testovaných programů byl při vývoji design až na posledním místě, a tedy celá aplikace působí přinejmenším nevábně. Bohužel u programů tohoto typu, tedy často používané ve spěchu a stresu, nejde pouze o kosmetickou vadu, ale o zásadní problém, který znepříjemňuje práci s celým systémem, způsobuje nepřehlednost a tudíž i lidské chyby. Je tedy s podivem, že si někteří autoři účtují několika-set dolarové, nebo několika-tisíci korunové částky za systém který jednoduše špatně vypadá. Lze samozřejmě argumentovat mamutí funkcionalitou, ale je nesmysl tvrdit, že rozsáhlé aplikace nemohou být přehledné a uživatelsky přívětivé, pouze to vyžaduje více námahy, kterou se programátorům nechce vynakládat, jelikož jim mnohokrát nedochází, že běžným konzumním uživatelům jde většinou především o vizuální stránku, a až po té o tu funkční. Doby funkčních aplikací, ke kterým bylo nutné přečíst obrovský manuál, by měli být pryč, což bohužel evidentně stále zcela neplatí. V kapitole 4 sekci 2 je možné najít seznam, ve kterém srovnávám dobrá a špatná řešení nejzásadnějších grafických prvků a principů. Z tohoto seznamu si lze odnést základní směr, kterým by se vývoj a grafické prostředí nové, podobně zaměřené aplikace, měl ubírat.

13

Příloha F

CashBob - Analýza GUI

75

CashBob - Analýza GUI Štěpán Tesař

1

Obsah CashBob - Analýza GUI Obsah Úvod Obecné problémy Tlačítka Lokalizace Virtuální klávesnice Zobrazení dle autorizace MainFrame Zbytečná chyba při spouštění Přihlašovací okno Rozvržení hlavního okna Nefunkční tlačítka Zobrazování id Pokladní modul Vytváření účtu Seznam účtů (druhé tlačítko z leva) Transfer mezi účty Zbytečná upozornění Manažerský modul Skladový modul Uzávěrky Zálohování

2

Úvod Tento dokument je výstupem analýzy grafického uživatelského rozhraní (dále jen GUI z anglického Graphical User Interface), pokladního systému CashBob, na kterém již v minulosti pracovalo několik týmů studentů, a aktuálně na něm také probíhají práce v rámci předmětu A7B36SI2, prováděné týmem pod mým vedením. Paralelně s těmito pracemi, upravujících především strukturu kódu a interní komunikaci (datové toky) v systému, pak já sám pracuji na části zadání mé bakalářské práce. Tato část práce je v mém pátém semestru zaštítěna předmětem A7B36PRO, a v šestém semestru bude tato práce pokračovat, tentokrát vedená již jako bakalářská. Analýza se zabývala jak nalezením částí GUI které jsou nepřehledné, nelogické, nebo pro uživatele zavádějící, tak částí které je již možné označit jako uživatelsky přívětivé, ale existuje stále místo pro zlepšení. Dokument je strukturovaný podle logicky oddělených částí systému (modulů), které mezi sebou nejsou propojené, a lze je tedy analyzovat zvlášť s ohledem na jejich funkcionalitu. Výjimkou je první část, kde je výčet obecných nedostatků týkajících se celého systému. Analýza se zabývá pouze klientskou částí programu, jelikož původní serverová část neobsahuje žádné uživatelské rozhraní, vyjma konzolového výstupu, který ale nelze pro zpětnou komunikaci se serverem nijak použít.

3

Obecné problémy Tlačítka Skrze většinu modulů je problém s vizuální identifikací účelu jednotlivých grafických tlačítek. Primárně je systém určen pro použití na dotekových zařízeních, a není proto možné použít kontextovou nápovědu (“tooltipy” po najetí kurzorem myši). Obrázky tlačítek nejsou z velké části příliš návodné, a podpora pro popisky chybí. Pro práci se systémem byl tento problém dočasně vyřešen přímým zásahem do obrázků tlačítek, kam byly dopsány funkce. Tento způsob je ale pro další vývoj nevhodný, jelikož s popisky takto není možné jakkoliv manipulovat jinak, než změnou samotného obrázku.

Lokalizace V systému je momentálně částečně implementována závislost GUI na jazykové lokalizaci. Již při mělkém pohledu na kód je však jasné, že lokalizace není kompletní. Plně lokalizovaný je pouze skladový modul a hlavní okno. Ostatní moduly nejsou lokalizované vůbec, nebo pouze minimálně.

Virtuální klávesnice Pozice virtuální klávesnice je nyní závislá na dané nabídce. Tento faktor může být nepříjemný pro většinu uživatelů, a ve výsledku může podstatně zpomalovat práci se systémem.

Zobrazení dle autorizace V systému se nyní zobrazují všechny funkce, a to i uživateli, který nemá k těmto funkcím přístup. Po kliknutí na takovou položku je pak nabídnuto dodatečné přihlášení. Toto řešení však není příliš vhodné, jelikož neautorizovaný uživatel by neměl mít vůbec informaci o tom, že je taková funkce k dispozici.

4

MainFrame Pojmem MainFrame je v tomto systému rozuměno hlavní okno, které je automaticky zobrazeno po spuštění klienta. Toto okno nejprve zajišťuje přihlášení uživatele a po úspěšném přihlášení, je překresleno na rozhraní pro přistup k ostatním modulům a nastavení programu.

Zbytečná chyba při spouštění Při spuštění klienta v momentě, kdy není na síti registrovaný server, se objeví oznámení o chybě. Tato hláška je víceméně zbytečná, jelikož klientský program se bez problému spustí, a po dodatečném spuštění serveru se lze i bez problémů přihlásit. Naopak, pokud se server nespustí, program toto při přihlašování oznámí již srozumitelnou chybovou hláškou.

Přihlašovací okno v hlavním okně je nyní zobrazený rám s černým okrajem, který okno rozděluje. Jde pravděpodobně pouze o nedodělek, jelikož jsem nenalezl důvod, proč by tento okraj měl být viditelný.

Rozvržení hlavního okna Hlavní okno je rozvržené stejně, jako pokladní modul. Tedy v horní části je horizontální panel s tlačítky, pod kterým je velký nevyplněný prostor. Toto rozvržení je pravděpodobně pozůstatek po zcela původním systému, který obsahoval pouze pokladní část, která byla s hlavní oknem pevně propojená. Nyní je však toto rozvržení nevhodné, jelikož prázdný prostor není nikdy využit.

Nefunkční tlačítka Tlačítka pro změny uživatelských práv a prvních “settings” z leva nevyvolají žádnou viditelnou akci.

5

Zobrazování id Ve většině tabulek v systému se vyskytuje sloupec ID, který je u velké části seznamů zbytečný a někdy i zavádějící, jako například v evidenci stolů v manažerském modulu, kde se stoly vybírají dle svého čísla. Zobrazení ID vedle čísla stolu pak tabulku činí nepřehlednou.

6

Pokladní modul V tomto modulu se nejvíce projevuje nepřehlednost tlačítek, pokud k nim nejsou uvedené popisky. Nelogicky také obsahuje rozhraní pro přidání kreditu uživateli, nebo nabídky pro slevy.

Vytváření účtu Pro vytvoření nového účtu je nyní nutné přiřadit osobu, nebo alespoň zadat jméno, a stůl, ke kterému je účet přiřazen. Vyžadování těchto informací je však absurdní například při využití systému v barech, kde je zboží často placeno rovnou, a je pouze nutné jeho vydání zaregistrovat do systému.

Seznam účtů (druhé tlačítko z leva) Data v tabulce všech účtů jsou velmi natěsnaná, i přes velký prostor, který je zde k dispozici. Tlačítko “zobrazit účet” v pravé dolní části je přebytečné, jelikož je mnohem intuitivnější nechat účet zobrazit po kliknutí na daný účet přímo v tabulce. Tlačítko pro zrušení filtru je pouze umístěno daleko od ostatních ovládacích prvků pro filtrování, které jsou zcela vnalevo, zatímco toto tlačítko je v pravé části.

7

Transfer mezi účty Nejprve je nutné vybrat první účet, ze kterého převádět, a teprve poté je uživatel odkázán na rozhraní pro samotný převod. Cílový účet je pak vybírán až v tomto rozhraní. Z uživatelského hlediska by tedy bylo příjemnější, kdyby vše probíhalo na jednom místě.

Zbytečná upozornění V částech, ve kterých se pouze zobrazuje seznam otevřených účtů, se objevuje hláška informující o prázdném seznamu, pokud žádné účty otevřené nejsou. Tato informace je zcela zbytečná, jelikož uživatel tento fakt mlže pozorovat na vlastní oči. Hláška navíc blokuje zbytek programu a je tedy nutné hlášku potvrdit stisknutím tlačítka “OK” a teprve pak je možné dále pokračovat v práci.

Manažerský modul Tento modul evidentně není postavený pro práci na dotykovém zařízení. Počítá se s tím, že manažer, který bude tento systém využívat, bude mít k dispozici stolní počítač. Při spuštění modulu je před uživatelem zcela prázdné okno a je nutné si zvolit funkcionalitu z menu. Jistě je však možné zobrazit první z funkcionalit již při samotném spuštění modulu. Modul je víceméně funkční, pouze některé popisky je možné nahradit vhodnějšími či návodnějšími texty.

8

Skladový modul Pravděpodobně nejméně funkční modul z celé aplikace. Ačkoli jsou některé části velmi podobné těm v manažerském modulu, nejsou dotažené do konce, a uživatel se mlže dostat do bezvýchodných situací. Například při úpravě materiálu, po stisknutí tlačítka pro vymazání formuláře, nedojde k resetovaní označeného materiálu, takže jediná možnost jak zabránit ztrátě údajů o označené položce je celý modul vypnout. Stejný problém se pak vyskytuje i v ostatních částech kde se nachází tlačítka s touto funkcí.

Uzávěrky Zcela nefunkční. Tímto problémem se však bude hlouběji zabývat kolega Tomáš Apeltauer v rámci své bakalářské práce.

Zálohování Po vybrání této položky dojde bez jakéhokoliv komentáře k zobrazení okna pro výběr souboru. Ani po zběžném prozkoumání zdrojového kódu jsem přesně nepochopil, co přesně tato nabídka vlastně zálohuje, ale domnívám se, že skladové záznamy v databázi. Každopádně, i pokud by byla záloha úspěšná, chybí zde nabídka pro obnovení dat ze zálohy.

9

Příloha G

CashBob - Návrh optimalizace GUI

85

CashBob - Návrh optimalizace GUI Štěpán Tesař

Obsah CashBob - Návrh optimalizace GUI Obsah Úvod Návrh řešení obecných problémů GUI Návodnější tlačítka Lokalizace Virtuální klávesnice Přizpůsobení prostředí uživatelské roli Chyby v modulech Rozvržení hlavního okna Rozvržení pokladního modulu Závěr

Úvod Na následujících stranách se nachází výčet návrhů na optimalizaci grafického prostředí systému CashBob. Některé návrhy jsou pouze způsobem odstranění chyb nalezených a vyčtených v dokumentu k analýze této části práce na systému CashBob, a některé vyloženě obměňují systém tak, aby byl v souladu s moderními trendy a umožňoval co nejpohodlnější práci skrze dotykový displej.

Návrh řešení obecných problémů GUI V analytické části bylo poukázáno na několik problému, které se vyskytují v grafickém prostředí skrze celý systém. V této části se tedy budu věnovat řešením těchto problémů.

Návodnější tlačítka Problém spojený se špatnou návodností tlačítek v systému byl částečně vyřešen vytvořením zcela nového grafického hávu aplikace, který obsahuje také nové obrázky pro použitá tlačítka. Stále by však bylo lepší, kdyby tlačítka obsahovala také jednoslovný popis své funkce. Tento popis by měl být plně lokalizovaný, a tedy generovaný při běhu aplikace, nikoliv vložený jako obrázek, jelikož by potom přidání nové jazykové mutace vyžadovalo také vytvoření nových obrázků pro jednotlivá tlačítka.

obrázek 1 - aktuální podoba tlačítka “nový účet”

obrázek 2 - navrhovaná podoba tlačítka s lokalizovaným popiskem

Zde vyvstává problém s různou délkou popisku v jednotlivých jazycích. Jelikož dynamická velikost tlačítka v závislosti na délce textu by mohla způsobit poruchy v rozložení grafických prvků, a ořezávání textu by naopak mohlo vyvolat ještě větší nepřehlednost tlačítek, než bez popisků, bude pravděpodobně nutné dynamicky počítat velikost textu, a zvolit takovou, která umožní do tlačítka napasovat celý řetězec znaků.

Lokalizace Lokalizační systém je přítomen a funkční, stačí ho pouze aplikovat na doposud nelokalizované řetězce v kódu, což bude pravděpodobně náročné pouze časově, nikoliv logicky.

Virtuální klávesnice Po prezentaci původního grafického návrhu (obrázek 6), který počítal se staticky zobrazenou klávesnicí v jedné části okna, se vyskytla připomínka, že klávesnice zabírá cenný prostor, a nutí tak zmenšovat ostatní ovládací prvky. Navíc by klávesnice byla zobrazena i v situacích, kdy zcela není potřeba, což je podstatně více procent času práce se systémem, než kdy potřeba je. Nově byl tedy zpracován návrh, že se klávesnice zobrazuje, pouze pokud je zaměřeno (z anglického focused, tedy kurzor je přesunut do... ) textové pole vyžadující vstup z klávesnice. Klávesnice se v tu chvíli zobrazí ve vlastním okně, které zastíní původní aplikaci. Toto okno má vlastní textové pole, do kterého je možné psát jak z virtuální, tak fyzické klávesnice, a do původního pole je text nakopírován po stisknutí klávesy ENTER, opět na libovolné s klávesnic.

Obrázek viz A.7 v příloze A - Obrázky.

Přizpůsobení prostředí uživatelské roli V přijatém softwaru probíhá kontrola práv tak, že po aktivování libovolného tlačítka je nejprve ověřeno, zda má uživatel akci právo provést a teprve poté je případně akce vykonána, nebo je naopak zobrazeno chybové hlášení, informující o nepřístupnosti dané operace. Navrhovaným elegantním vylepšením je tedy kontrola uživatelských práv již při vykreslování prostředí, a případně blokování zobrazení tlačítek, sloužících k akcím, na které uživatel nemá právo. Pozdější kontrola práv po stisku tlačítka by pravděpodobně měla být ponechána, čistě z bezpečnostního hlediska, ačkoliv by teoreticky nemělo dojít k tomu, že by uživatel aktivoval funkci, ke které nemá právo.

Chyby v modulech S největší pravděpodobností nemá smysl se zabývat všemi problémy nalezenými v jednotlivých částích GUI, jelikož se většinou jedná o triviální problémy se stejně triviálním řešením, nebo vyloženě o systémové chyby, které je nutné vyřešit prostým nalezením chybného fragmentu kódu, a jeho opravou. V následující části se tedy budu zabývat pouze těmi problémy z analytické části, které vyžadují hlubší zamyšlení a komplexnější způsob řešení.

Rozvržení hlavního okna Hlavní okno je nyní graficky identické s pokladním modulem, což však zcela odporuje jeho hlavní funkci, kterou je zpráva aplikace a spouštění ostatních modulů. Tomuto účelu by více vyhovovalo zobrazení ve stylu “menu” s jednotlivými sekcemi dle funkce, viz obrázek 4:

Obrázek viz A.5 v příloze A - Obrázky.

Rozvržení pokladního modulu Pokladní modul bude pravděpodobně nejfrekventovaněji využívaný modul ze všech, a tedy vyžaduje také největší nároky na přehlednost, rychlost a návodnost ovládání. Nyní je nutné pro jakoukoliv akci s účtenkou, nejprve účtenku vybrat z nabídky, i přesto, že většinou akce za sebou probíhají nad jednou účtenkou. Například při vytvoření účtenky bude nejspíše následovat ihned objednání položek, a možná i rovnou zaplacení. Ideálním řešením je tedy staticky vybraná účtenka s tím, že se pouze mění zbylý obsah okna podle aktuálně zvolené akce. Následující obrázek ukazuje přibližnou představu, jak by takový systém mohl vypadat. Jde však o návrh staršího data, který ještě počítal se staticky zobrazenou klávesnicí, od které bylo nakonec upuštěno. Díky tomu se výrazně rozšíří volná plocha pro zobrazení ovládacích prvků různých akcí.

Obrázek viz A.6 v příloze A - Obrázky.

Problémem však zůstává, jak přehledně umožnit listování účtenkami. Nabízí se možnost účtenky řadit do prioritní fronty, podle jejich poslední aktivace. Tedy vybraná účtenka by byla vždy vrcholem seznamu, a předchozí účtenky pak seřazené sestupně pod ní (na rozdíl od vizualizace v obrázku 6, která ukazuje dynamickou polohu aktivní účtenky podle umístění v seznamu). Další možností je zobrazovat pouze tlačítko pro výběr účtenky, a účtenky vybírat z menu fungujícího stejně jako navrhovaná klávesnice, tedy zobrazeného přes celou aplikaci, což poskytuje největší možný operační prostor, a tedy také pojme největší počet účtenek. I v tomto případě by však při určitém množství bylo nutné vytvoření “scrollbaru” pro obsáhnutí všech

účtenek při zachování určité přehlednosti a velikosti písma. Je také možné vytvoření textového pole, které by aktivně filtrovalo seznam účtenek dle zadávaného textu, pravděpodobně podle jména. Nejideálněji se jeví kombinace filtrovacího textového pole, a rozklikávacího okna s rolovací lištou, jelikož v tu chvíli je možné zobrazovat maximální počet účtenek, a umožnit i snadné filtrování. Stejným způsobem by pak mohl být řešen výběr položek pro objednávku, tedy v hlavním okně by se zobrazovali pouze jednotlivé sekce menu (polévky, hlavní jídla, nápoje ...), a až po zvolení dané sekce se zobrazí překrývací okno s jednotlivými položkami. Toto řešení poskytne stejné výhody jako při použití s účtenkami, jelikož po rozdělení do jednotlivých sekcí nebude běžné, aby obsahovali více položek, než se vejde na jeden rozměr obrazovky. Stejně tak by se jednotlivé sekce měli do hlavního okna pohodlně vejít, jelikož zde nebude virtuální klávesnice.

Závěr K realizaci předchozích návrhů bude z velké části pouze zásah do grafické vrstvy aplikace, jelikož v rámci předmětu A7B36SI2 byl dokončen převod kódu do architektury modeview-controller, a veškerá logika již v systému je zanesena. Logické oddělení jednotlivých prvků GUI na dialogy a formuláře bude také umožňovat systematický převod po částech (jednotlivých funkcí), tedy po úpravě každé z nich by aplikace měla být zcela funkční, pokud přejdeme fakt, že grafické prostředí v tu chvíli bude velmi nekonzistentní.

94

PŘÍLOHA G. CASHBOB - NÁVRH OPTIMALIZACE GUI

Příloha H

Návrh úpravy slevového systému

95

Návrh na úpravu slevového systému v programu CashBob Štěpán Tesař

Obsah Návrh na úpravu slevového systému v programu CashBob Obsah Úvod Nové požadavky Dělení uživatelů nezávisle na systémových rolích Časově závislé slevy Prodejné slevové karty (poukázky svázané s uživatelským účtem) Možnost asociace s více slevami najednou Časově limitované Limitované počtem použití každé asociované slevy. Rozšíření modelu Aktuální model Rozšířený Model Nové a upravené třídy UserClass DiscountType Discount DiscountCard iMenuItem Count Úprava logiky slev v GUI

Úvod Tento dokument je shrnutím navrhovaných úprav stávajícího systému slev v programu CashBob, na kterém již v minulosti pracovalo několik týmů studentů, a aktuálně na něm také probíhají práce v rámci předmětu A7B36SI2, prováděné týmem jehož jsem součástí. Paralelně s těmito pracemi, upravujícími především strukturu kódu a interní komunikaci v systému, pracuji na zadání mé bakalářské práce. Tato práce je v mém pátém semestru zaštítěna předmětem A7B36PRO. Analýza se zabývá stávajícím systémem slev a možnostmi na jeho rozšíření.

Nové požadavky Uvedené požadavky jsou v podstatě výčtem funkcionality, která aktuálnímu systému chybí. Nejsou uvedeny základní požadavky na dokončení stávajících funkcí, jako je například správa existujících slev. ● Dělení uživatelů nezávisle na systémových rolích V tuto chvíli není možné uživatelé rozlišit do skupin jinak, než vytvořením rolí. Tyto role však v původním návrhu reprezentují hlavně odlišení přístupových práv do některých částí systému, a bylo by proto vhodné vytvoření funkčně odděleného členění. ● Časově závislé slevy Aktuálně je možné slevu pouze vytvořit a poté smazat. Časové slevy by umožnily vytváření limitovaných akcí. Při inventuře nebo reklamacích je navíc vhodné mít k dispozici údaj o tom, jaké slevy se v danou chvíli na položky vztahovaly. ● Prodejné slevové karty (poukázky svázané s uživatelským účtem) Karty nemusí nutně reprezentovat fyzickou kartičku. Jelikož tato třída musí být asociována s uživatelem, a tedy je možná identifikace osobním průkazem (řidičský, občanský atp.), kterým uživatel prokáže použití slevy v systému. ○ Možnost asociace s více slevami najednou Mělo by být umožněno uplatnit na jeden poukaz více druhů slev. ○ Časově limitované Průkaz by měl určitě být časově omezený, tedy platný od-do. ○ Limitované počtem použití každé asociované slevy. Každou slevu na průkazu by mělo být možné uplatnit pouze několikrát, ale měl by být stejně tak omezen i celkový počet využití karty.

Rozšíření modelu Aktuální model Tento model je sestavený reverzním inženýrstvím z modelu využívaného frameworkem hybernate. Model překvapivě poměrně dobře odpovídá původní analýze předchozího týmu, se kterým byl porovnán, a byly dle něj doplněny násobnosti vazeb.

Obrázek viz diagram B.1 v příloze B - UML Diagramy.

Rozšířený Model Navrhované rozšíření modelu tak, aby podporoval rozšířený systém slev. Principy tohoto systému a popis rozšíření je níže pod diagramem. Na diagramu se nenachází všechny třídy původního modelu, ale pouze část důležitá pro další práci.

Obrázek viz diagram B.2 v příloze B - UML Diagramy.

Červené čáry označují nově navrhované spojení. Nově navržené třídy jsou UserClass, DiscountAction, DiscountCard, rozhraní iMenuItem a asociační třída Count. Fialové čáry pak označují existující spojení a barevné odlišení pouze zvýrazňuje, že dané spojení je pro tento projekt určitým způsobem podstatné a bude s nimi manipulováno.

Nové a upravené třídy UserClass Tato třída umožňuje nově dělení uživatelů kromě rolí do systémově nezávislých skupin. Na rozdíl od uživatelských rolí (kuchař, manažer atp.), které mají v systému především autorizační funkci, je nyní umožněno dělení uživatelů nezávisle na jejich postavení v daném podniku (student, senior), nebo uživatelsky přívětivou klasifikaci zákazníků. Díky této třídě bude možné vytvářet slevy jak na konkrétní role (zaměstnanci se budou moci stravovat se slevou) tak na dle zařazení uživatelů mimo rozsah podniku, tedy například akce pro studenty.

DiscountType V této třídě pouze dojde k doplnění její platnosti od a do určitého data, což umožní lepší manipulaci se slevami v systému. Nově bude možné vytvořit slevové “akce” platící pouze po určitý čas, na určité zboží pro určitou skupinu zákazníků. Mělo by být možné vytvořit časově neomezenou slevu, případně zvětšovat dobu platnosti karty (nikoliv však snižovat, kvůli zpětným inventurám). Nové je také propojení s třídou UserClass.

Discount Zde by mělo být možné uplatnit slevu ne pouze na konkrétní položku ale na celý typ položek. V aktuálním systému tohoto kroku lze dosáhnout pouze vybráním všech položek ze sekce, což je časově náročné a neprojeví se u nově vytvořených položek sekce.

DiscountCard Jde o reprezentaci slevové karty. Tuto kartu může mít zakoupenou konkrétní uživatel, a dle nastavených parametrů mu umožňuje určitý počet využití asociované slevy, v omezený čas. Jelikož i třída DiscountType má atributy omezující její platnost, bude nutné při vytváření instancí DiscountCard ošetřit její horní hranici dle asociovaného typu slevy.

iMenuItem Třída DiscountCard také dědí nově navržený interface, který bude umožňovat prodej slevových karet provázaných se systémem stejným způsobem jako ostatní sortiment.

Count Tato asociační třída udává počet možných aplikací karty na asociovaný typ slevy. Tento údaj není možné ukládat do atributu, jelikož se slevovou kartou je možné provázat více typů slev, a tedy je nutné si jejich počet držet pro každou asociaci zvlášť.

Úprava logiky slev v GUI Bude nutné přepracovat způsob, jakým systém slevy používá. Bude nutné slevu svázat s konkrétním uživatelem, rolí a nově také s třídou uživatele. V případě, že si ale například student chce zakoupit zboží, u nějž by měl nárok na slevu, bylo by nyní nutné mu vytvořit uživatelský účet, přiřadit mu příslušnou studentskou třídu, a poté by teprve bylo možné ji na účtence uplatnit. Ideální by tedy bylo, kdyby při placení bylo možné vybrat aplikované slevy. Uživatel by mohl mít na výběr ze slev aplikovatelných na aktuální položky na účtence (tedy když by na účtence byla permanentka na vstup, nebylo by možné vybrat slevu na pivo, jelikož by se ve výpočtu ceny stejně nijak neprojevila).

— FIN —

103