}w !"#$%&'()+,-./012345
Masarykova univerzita Fakulta informatiky
Informační systém pro řízení skladu a návrh mobilní aplikace pro Android Diplomová práce
Bc. Vojtěch Šobáň
Brno, jaro 2013
Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: RNDr. JUDr. Vladimír Šmíd, CSc. ii
Poděkování Děkuji svému vedoucímu práce RNDr. JUDr. Vladimíru Šmídovi, CSc. za vstřícnost, cenné rady a připomínky, které mi pomohly při tvorbě a psaní práce. Děkuji také své rodině, přítelkyni a kamarádům za podporu při studiu a psaní práce.
iii
Shrnutí Cílem práce je analýza požadavků zadavatelské firmy, návrh informačního systému pro řízení skladu a evidenci prodejů pomocí současných modelovacích nástrojů. Implementace webové aplikace s kompletní funkcionalitou a mobilní aplikace pro operační systém Android, která slouží k zadávání prodejů do systému, jsou stěžejní částí práce. Součástí práce je i uživatelská příručka popisující obsluhu obou aplikací.
iv
Klíčová slova Informační systém, UML, diagram případů užití, diagram tříd, PHP, Nette framework, Android
v
Obsah 1 Informační systémy . . . . . . . . . . . . . . 1.1 Pojem informačního systému . . . . . . . . 2 Systém a analýza jeho požadavků . . . . . 2.1 Princip systému . . . . . . . . . . . . . . . 2.2 Specifikace požadavků . . . . . . . . . . . 2.2.1 Funkční požadavky na systém . . . 2.2.2 Nefunkční požadavky na systém . . 3 Použité nástroje, analýza a návrh systému 3.1 UML . . . . . . . . . . . . . . . . . . . . . 3.1.1 Co je UML a k čemu se používá . . 3.1.2 Historie a vznik UML . . . . . . . . 3.1.3 Struktura jazyka . . . . . . . . . . Předměty . . . . . . . . . . . . . . Relace . . . . . . . . . . . . . . . . Diagramy . . . . . . . . . . . . . . 3.2 Diagram případů užití . . . . . . . . . . . 3.2.1 Hranice systému . . . . . . . . . . 3.2.2 Aktéři . . . . . . . . . . . . . . . . 3.2.3 Případy užití . . . . . . . . . . . . 3.3 Diagram tříd . . . . . . . . . . . . . . . . 3.3.1 Třídy . . . . . . . . . . . . . . . . . 3.3.2 Vztahy . . . . . . . . . . . . . . . . 3.3.3 Analytický model . . . . . . . . . . 3.3.4 Návrhový model . . . . . . . . . . Evidence . . . . . . . . . . . . . . Přesuny zboží . . . . . . . . . . . Prodeje . . . . . . . . . . . . . . . Inventury . . . . . . . . . . . . . . 3.4 Datový model . . . . . . . . . . . . . . . . 3.4.1 ERD . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 2 3 3 4 4 7 8 8 8 8 9 9 10 12 14 14 14 16 22 22 23 24 24 24 27 29 29 32 32 vi
4 Implementace systému . . . . . . . . . . 4.1 Model-View-Controller architektura . . 4.2 Webová aplikace . . . . . . . . . . . . 4.2.1 Nette framework . . . . . . . . 4.2.2 Struktura aplikace . . . . . . . 4.2.3 Vzhled . . . . . . . . . . . . . . 4.3 Aplikace pro operační systém Android 4.3.1 Popis aplikace . . . . . . . . . . 4.3.2 Třídy použité v aplikaci . . . . 4.3.3 Struktura aplikace . . . . . . . 5 Uživatelská příručka . . . . . . . . . . . . 5.1 Přihlášení, odhlášení a změna hesla . . 5.2 Evidence . . . . . . . . . . . . . . . . . 5.3 Sklady a přesuny zboží . . . . . . . . . 5.4 Prodej zboží . . . . . . . . . . . . . . . 5.5 Inventura . . . . . . . . . . . . . . . . 6 Závěr . . . . . . . . . . . . . . . . . . . . . A Popis zbývajících případů užití . . . . . B Obsah přiloženého CD . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
39 39 41 41 46 47 48 49 49 51 52 52 52 54 55 56 59 65 72
vii
Úvod Doba, ve které žijeme, by se asi jen těžko obešla bez počítačů, mobilních zařízení a celkově informačních technologií, které nám zásadně pomáhají se vypořádat s časovým tlakem, který si občas sami právě i díky technologiím vytváříme. Lidé brzy přišli na to, že informační technologie jim mohou dobře sloužit jako prostředek k usnadnění práce, například při archivaci dat, a nebo při porovnávání a získávání dat pro statistické účely. Cílem mé diplomové práce je analyzovat a navrhnout informační systém pro správu skladů a evidenci prodejů pro zadavatelskou firmu, která se zabývá stánkovým prodejem občerstvení. Firma do této doby neměla žádný informační systém, prodej zboží a vše kolem probíhalo tzv. „na dobré slovo“. Tím vznikalo množství nesrovnalostí při prodejích a prodejci měli nemalé starosti s kontrolou skladů a přehledem o aktuálním stavu zboží na stánku či skladu. Problematikou informačních systémů se již nějakou dobou zabývám, a protože jsem si chtěl rozšířit obzory v tomto odvětví, a také jsem se chtěl seznámit s tvorbou mobilních aplikací pro operační systém Android, se kterou jsem neměl dosud žádné zkušenosti, vybral jsem si právě toto téma diplomové práce. Ta se skládá z analytické části, návrhové části a z části praktické, která je nejrozsáhlejší a jejíž součástí je webová aplikace pro řízení skladů a evidenci prodejů a aplikace pro mobilní zařízení s operačním systémem Android, která bude sloužit k zadávání prodejů do systému. V první části práce stručně popisuji informační systém, ve druhé části analyzuji požadavky zadavatele na systém a rozebírám, jak bude systém fungovat. Ve třetí části se krátce věnuji použitým modelovacím nástrojům a podrobněji pak objektovému a datovému návrhu systému. Čtvrtá část je zaměřena na implementaci obou vytvořených aplikací a poslední část obsahuje uživatelskou příručku, která popisuje, jak aplikace obsluhovat. 1
Kapitola 1
Informační systémy Informační systémy [1] jsou v dnešní době prakticky nezbytnou součástí každé firmy, která se chce rozvíjet, chce „být vidět“ a chce efektivně fungovat. Jelikož kvalita systému mnohdy koreluje s úspěchem a konkurenceschopností podniku, rozhodně se vyplatí do tvorby informačního systému investovat hned na začátku. Snad největší výhodou informačních systémů je usnadnění práce zaměstnancům firmy, kterým systém pomáhá plnit úkoly lépe a včas, například pomocí synchronizovaných poznámek nebo automatického upozorňování na nedostatek zboží na skladě.
1.1
Pojem informačního systému
Informační systém je spojení dvou pojmů. Informace je často chápána za synonymum pojmu data, což je chyba. Data jsou pouze čísla, hodnoty nebo fakta. Informace jsou data, která jsou zasazena do souvislostí, a pokud máme velké množství dat, neznamená to, že jsme schopni podat velké množství informací. Systém si můžeme představit jako množinu prvků a vztahů mezi nimi. Každý systém je propojen s okolím, na které reaguje. Aby systém pracoval správně, je nutné, aby všechny jeho prvky pracovaly společně. Žádná definice informačního systému [2] není přesná, protože si každý může pod tímto pojmem představit trochu něco jiného. Nejčastěji je však informační systém popisován jako systém vzájemně propojených informací a procesů, které slouží ke zpracování vstupních dat, jejich uchovávání, přenosu, a prezentaci nově získaných informací.
2
Kapitola 2
Systém a analýza jeho požadavků 2.1
Princip systému
Systém, který bude vytvořen v rámci diplomové práce, bude sloužit ke zjednodušení komunikace mezi hlavním skladem a prodejními stánky. Oprávněným uživatelům zpřístupní přehledy prodejů zboží, a přestože systém nebude sloužit jako účetní nebo pokladní systém, umožní uživatelům získat přehled také o tržbách na jednotlivých stáncích. Jeho hlavním úkolem však bude informovat skladníka o aktuálním množství zboží na jednotlivých stáncích a chytře jej upozorňovat na docházející druh zboží na daném stánku, aby jej mohl včas doplnit. Díky tomu bude mít prodejní stánek vždy dostatek zboží, nebudou vznikat prodlevy v dodání z hlavního skladu a omezí se tím riziko zastavení prodeje z důvodu pozdního dodání zboží. Aby mohl systém fungovat, je nutné jej nejprve naplnit počátečními daty. Manažer vloží do systému data o stáncích, uživatelích, dodavatelích, přidá do systému zboží a popíše výrobní postupy. Ke každému stánku vytvoří ceník zboží a vloží slevové kupony. Jakmile jsou počáteční data zadána, systém může začít fungovat v praxi. První přijde na řadu skladník, který přijme od dodavatelů zboží pro prodej nebo pro výrobu vlastních produktů. Pokud nejsou dostupná žádná data o předchozích prodejích, přesune skladník na prodejní stánky množství zboží podle svého odhadu. V případě, že systém již obsahuje databázi prodejů z předchozích dnů, určí systém dolní a horní meze u každého zboží na stánku a skladník tím získá přehled, kolik zboží je potřeba na každý stánek přesunout. Jakmile je zboží na prodejních stáncích, přichází na řadu prodejci, resp. provozní, kteří na nich pracují. Pomocí zařízení s operačním systémem Android a mobilní aplikace zadávají do systému jednotlivé prodeje. Po přihlášení do 3
2. Systém a analýza jeho požadavků systému se automaticky zahájí směna a otevře pokladna. Systém průběžně (po každém zadání prodeje) kontroluje množství zboží na stáncích, a jakmile množství některého ze zboží klesne pod stanovenou dolní mez, systém upozorní skladníka, který dodá požadované zboží na stánek. Jakmile uživatel skončí směnu, pokladnu uzavře a provozní provede inventuru zboží. V případě, že nějaké zboží chybí, zadá tento fakt do systému.
2.2
Specifikace požadavků
Základním stavebním kamenem pro návrh informačního systému je správná a přesná specifikace požadavků, od které se odvíjí celý model systému. Častou příčinou ztroskotání softwarového projektu je nedokonalá a chybná specifikace, a proto nesmí být za žádnou cenu podceněna nebo zanedbána. Specifikace požadavků popisuje, co má systém umět, ale nikoliv způsob, jakým to má dělat. Ovšem v praxi to bývá často spojováno nebo zaměňováno a ve fázi implementace tak vznikají nežádoucí omezení, protože již při specifikaci požadavků určujeme způsob tvorby systému. Požadavky na systém dělíme na funkční a nefunkční. Funkční požadavky reprezentují funkce a chování systému, nefunkční definují vlastnosti, nároky na systém a omezení systému, jako např. požadavky na vzhled, použitou technologii nebo výkon. 2.2.1 Funkční požadavky na systém 1.
Autentizace, autorizace a evidence uživatelů Systém bude evidovat uživatele systému, kteří v něm budou pracovat. Každý uživatel bude mít jednu roli, která jej bude opravňovat k určitým úkonům. Se systémem bude pracovat skladník, prodejce, provozní stánku a manažer. Každý uživatel bude mít své jméno, e-mail, přihlašovací jméno, heslo a roli, která se může v průběhu času měnit. Systém bude provádět autentizaci a autorizaci uživatelů při přihlašování do systému. Evidenci uživatelů bude provádět manažer.
4
2. Systém a analýza jeho požadavků 2.
Příjem zboží od externích dodavatelů Skladník, provozní nebo manažer bude přijímat zboží od externích dodavatelů a zadávat je do systému. Systém bude evidovat pouze příjmy zboží, nikoliv objednávky pro externí dodavatele. Součástí položky příjmu zboží bude datum a čas příjmu, dodavatel, zboží, které se naskladňuje, a jeho množství. Expirační dobu není nutné sledovat, protože prodej na stáncích probíhá pouze v určitý časový úsek a zboží, které se bude přijímat, má vždy delší expirační dobu, než je trvání stánkových prodejů.
3.
Přesun zboží Skladník, provozní a manažer budou mít možnost přeskladňovat zboží ze stánku/skladu na stánek, pokud to bude třeba. U přesunu zboží se bude evidovat datum a čas přesunu zboží, zdrojový stánek, cílový stánek, zboží, které přesouváme, a jeho množství.
4.
Prodej zboží Prodejce, provozní a manažer budou skrz aplikaci na mobilním zařízení zadávat prodeje zboží. Aplikace bude mít velmi jednoduché a přehledné rozhraní. Po přihlášení uživatele se na hlavní obrazovce zobrazí seznam prodejního zboží nabízeného na daném stánku. Uživatel zvolí množství u každého zboží, které právě prodává, příp. uplatní slevu, a jakmile bude seznam položek v objednávce kompletní, pomocí tlačítka Zaplatit se zobrazí celková cena a po potvrzení zaplacení se vrátí zpět na úvodní obrazovku se seznamem prodejního zboží. Systém bude po každém zadaném prodeji kontrolovat aktuální zásobu zboží na stánku a pokud zjistí, že množství některého ze zboží kleslo pod stanovenou mez, upozorní skladníka e-mailem, aby doplnil zboží na stánek.
5.
Inventura, evidence chybějícího zboží Na konci každé směny (obvykle jednou denně) bude provozní stánku provádět inventuru, tedy kontrolovat množství zboží, které má být na skladě stánku podle systému. Pokud provozní zjistí nesrovnalosti (chybějící zboží), zadá je do systému. U inventury bude systém evidovat, která směna je právě kontrolována, datum 5
2. Systém a analýza jeho požadavků a čas provedení inventury, uživatele, který ji prováděl, a samozřejmě chybějící zboží a jeho množství. 6.
Evidence zboží a výrobních postupů Manažer bude zadávat do systému zboží, u kterého bude evidovat název zboží, měrnou jednotku a popis. Pokud bude zboží vyráběno přímo na stáncích (např. v případě míchaných nápojů), bude do systému zadávat suroviny, ze kterých se prodejní zboží vyrábí. Postup výroby bude uveden v popisu vyráběného zboží. Protože se výrobní proces zboží může v čase měnit, je potřeba, aby systém počítal s aktualizací výroby. V jeden časový okamžik však může být u jednoho typu prodejního zboží platný pouze jeden výrobní postup.
7.
Evidence stánků Manažer bude evidovat seznam stánků. Každý stánek bude určen svým názvem a typem. Typy stánku budou zprvu postačovat dva, a to prodejní stánek a sklad, který bude sloužit pouze pro uskladnění většího množství zboží od dodavatelů. Ze skladu bude také skladník rozdělovat zboží mezi jednotlivé stánky.
8.
Evidence slevových kuponů Slevové kupony bude do systému zadávat manažer. Každý kupon bude mít svůj kód, název a procento slevy, kterou bude zákazník uplatňovat.
9.
Evidence dodavatelů Manažer bude do systému zadávat také externí dodavatele, kteří budou mít své jméno, IČO, DIČ, telefonický kontakt, e-mail a adresu, která se bude skládat z ulice, čísla popisného, čísla orientačního, města, poštovního směrovacího čísla a státu. Vzhledem k tomu, že systém není účetní a ani nevytváří objednávky externím dodavatelům, není potřeba, aby evidoval, jaké zboží jednotlivý dodavatel dodává a ani jeho velkoobchodní cenu. Dodavatel bude uveden pouze ve výpisu naskladněného zboží, abychom věděli, odkud zboží pochází.
6
2. Systém a analýza jeho požadavků 10.
Evidence ceníků Každý prodejní stánek bude mít svůj vlastní ceník, který bude vytvářet a upravovat manažer. Každé zboží bude mít nastavenu svou cenu, která se může na různých stáncích lišit. Cena prodejního zboží je proměnlivá, a proto je nutné, aby systém evidoval platnost ceníku.
11.
Přehled prodejů a tržeb Aby měl manažer povědomí o prodaném zboží a tržbách, bude systém generovat přehledy prodejů a tržeb dle zadaných parametrů, jako je např. časový úsek, jednotlivý prodejní stánek nebo druh zboží.
2.2.2 Nefunkční požadavky na systém 1.
Systém bude dostupný skrz webový prohlížeč.
2.
Systém poběží na stávajícím webovém hostingu.
3.
Systém bude implementován pomocí PHP a MySQL.
4.
Systém bude přehledný a jednoduchý na ovládání.
5.
Součástí bude aplikace pro OS Android verze 2.2 a vyšší, která poběží na předem zvoleném mobilním zařízení.
7
Kapitola 3
Použité nástroje, analýza a návrh systému 3.1
UML
3.1.1 Co je UML a k čemu se používá Jazyk, který označujeme zkratkou UML [3] (Unified Modeling Language), je univerzální modelovací jazyk sloužící k usnadnění návrhu a vývoje softwarových aplikací. UML je vizuální jazyk s pevnou grafickou syntaxí, který se stal standardem obzvláště při modelování objektově orientovaných systémů, a proto je pro analytiky a programátory informačních systémů nezbytně nutné, aby se v jazyce orientovali. Je velkým pomocníkem při návrhu rozsáhlých systémů, na kterých pracují týmy programátorů. V týmu je nutná velmi dobrá komunikace, je nutné rychle reagovat na průběžné požadavky a změny od zákazníků, a také odhadnout cenu požadovaného systému. Pomocí UML nástrojů můžeme tyto nástrahy eliminovat. 3.1.2 Historie a vznik UML Na počátku 90. let se hledalo řešení, jak se na informační systém dívat z různých úhlů pohledu. Postupně vznikalo velké množství standardů a specifikací, jak systém členit a graficky jej ztvárnit. Každý měl svou vlastní metodiku, a to bylo potřeba změnit. První snahou o sjednocení byla roku 1994 metodika Fusion, která ale nebyla úspěšná, přestože byla velmi propagována. Až v roce 1997 se podařilo firmě Rational Software sjednotit metodiky, vytvořit jazyk UML a docílit toho, aby jej sdružení OMG1 (Object Management Group) přijalo jako historicky první standard objektově orientovaného jazyka 1. Konsorcium firem poskytující systém pro vývoj aplikací s použitím technik objektového programování.
8
3. Použité nástroje, analýza a návrh systému pro grafické modelování. UML přijala i veřejnost a ostatní metody byly zapomenuty. 3.1.3 Struktura jazyka Struktura jazyka UML je postavena na třech elementech, které jsou reprezentovány v grafické podobě formou značek. Tyto elementy nazýváme: •
Předměty,
•
relace,
•
diagramy.
Předměty Předměty jsou základními prvky UML modelu a dále je dělíme na: •
strukturní abstrakce – tímto pojmem rozumíme všechna podstatná jména v modelu, např. případ užití, třída, uzel, komponenta; jsou zobrazovány uzavřenými útvary (obdélníky, elipsy);
Obrázek 3.1: Ukázka značení třídy a případu užití •
chování – ta představují vzájemnou komunikaci mezi objekty v modelu, značíme je pomocí spojovacích čar, které mohou být zakončeny šipkami;
Obrázek 3.2: Ukázka značení chování 9
3. Použité nástroje, analýza a návrh systému •
seskupení – to jsou tzv. balíčky, které tvoříme seskupováním částí modelu, jež jsou si významově podobné, značíme většinou obdélníkem ve tvaru složky;
Obrázek 3.3: Ukázka značení seskupení – balíčku •
poznámky – blíže určují chování a vlastnosti prvků v UML modelu, značíme obdélníkem s ohnutým rohem.
Obrázek 3.4: Ukázka značení poznámky Relace Samotné předměty by v modelu neměly smysl, pokud by mezi nimi neexistoval vztah, tedy relace. Relaci značíme různými typy čar, které spojují navzájem související předměty. Rozlišujeme následující typy relací: •
asociace (Association) – jedná se o obecný vztah mezi předměty, který je však dopředu přesně definován, speciálními případy jsou kompozice a agregace, které popisuji níže;
Obrázek 3.5: Ukázka značení asociace 10
3. Použité nástroje, analýza a návrh systému •
závislost (Dependency) – definuje vztah mezi předměty, kdy změna v předmětu prvním má vliv na význam předmětu druhého;
Obrázek 3.6: Ukázka značení závislosti •
agregace (Aggregation) – představuje volnou vazbu, cílový předmět je součástí celku;
Obrázek 3.7: Ukázka značení agregace •
kompozice (Composition) – silnější forma agregace, cílový předmět musí být součástí pouze jednoho celku a samostatně nemůže existovat;
Obrázek 3.8: Ukázka značení kompozice •
zobecnění (Generalization) – tento vztah používáme v případě, že je jeden předmět specializací předmětu jiného;
Obrázek 3.9: Ukázka značení zobecnění •
realizace (Realization) – jeden předmět reprezentuje dohodu, jejíž uskutečnění zajišťuje předmět jiný, v objektově orientovaném programování je takový vztah uskutečněn pomocí rozhraní; 11
3. Použité nástroje, analýza a návrh systému
Obrázek 3.10: Ukázka značení realizace •
ochranná nádoba (Containment) – ukazuje vztah, kdy zdrojový prvek zahrnuje cílový prvek.
Obrázek 3.11: Ukázka značení ochranné nádoby Diagramy Každý vytvořený předmět nebo relace se automaticky stává součástí modelu, který popisuje strukturu a chování daného systému. Modelovaný systém se skládá z několika odlišných diagramů, přičemž každý diagram zachycuje různý úhel pohledu na systém. Pozor na záměnu pojmů diagram a model. Pokud odstraníme předměty nebo relace z diagramů, neznamená to, že jsou smazány i z modelu systému. Jsou součástí modelu až do té doby, dokud je explicitně neodstraníme. V UML aktuálně existuje třináct druhů diagramů, které dělíme do dvou základních skupin podle toho, co popisují: •
diagramy struktury (Structure Diagrams) – popisují statickou strukturu systému, tedy předměty a vztahy mezi nimi; patří sem diagram tříd, objektový diagram, diagram komponent, diagram nasazení, diagram balíčků a diagram složené struktury;
•
diagramy chování (Behaviour Diagrams) – popisují dynamickou strukturu systému, nebo-li chování systému, ukazují, jak na sebe jednotlivé předměty působí, abychom dosáhli cíleného chování systému. Patří mezi ně diagram případů užití, stavový diagram, diagram aktivit a diagramy interakce, které se dále člení na diagram posloupnosti, diagram komunikace, stručný diagram interakce a diagram časování. Celou hierarchii diagramů si můžeme prohlédnout na obrázku 3.12. 12
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use] UML diagram
Diagram struktury
Diagram tříd
Diagram složené struktury
Diagram komponent
Diagram balíčku
Diagram posloupnosti
Diagram chování
Objektový diagram
Diagram nasazení
Diagram komunikace
Diagram případů užití
Diagram interakce
Diagram časování
Stavový diagram
Diagram aktivit
Stručný diagram interakce
Obrázek 3.12: Hierarchie UML diagramů 13
3. Použité nástroje, analýza a návrh systému
3.2
Diagram případů užití
Diagram případů užití (Use Case Diagram) [4], který vidíme na obr. 3.16, ukazuje systém, jak jej vidí sám uživatel. Jedná se o základní UML diagram, který vytváříme obvykle jako jeden z prvních na základě předem stanovených funkčních požadavků. Stejně jako funkční požadavky, tak i diagram případů užití nám říká, co má systém umět, nikoliv jakým způsobem to má dělat. Při tvorbě diagramu případů užití se musíme vypořádat s několika úkoly. V první řadě je nutné vymezit hranice systému, poté nalézt aktéry a nakonec specifikovat případy užití. Tento koloběh opakujeme do té doby, než se výčet ustálí. 3.2.1 Hranice systému Při hledání hranic systému si musíme uvědomit, co je součástí systému a co není, resp. co je uvnitř systému a co je vně. Máme-li představu o aktérech a případech užití, usnadní nám to práci při hledání hranic systému, protože případy užití tvoří onu vnitřní část systému a aktéři vnější. Námi hledaná hranice systému je poté patrná. V diagramu ji značíme plným obdélníkem označeným popisem s názvem systému. Případy užití zakreslujeme dovnitř obdélníku, aktéry vně obdélníku. 3.2.2 Aktéři Důležitým úkolem při hledání aktérů je identifikace rolí, které reprezentují určitou skupinu uživatelů systému se stejnými možnostmi práce v něm. Jeden uživatel může mít všeobecně více rolí, a proto je nutné rozlišit pouze role a nikoliv konkrétní uživatele. Aktéry zakreslujeme buď jako obdélník nebo častěji používanou kreslenou figurku.
Obrázek 3.13: Symbol aktéra 14
3. Použité nástroje, analýza a návrh systému Při návrhu je často potřeba zachytit situaci, kdy má nadřazený uživatel stejné možnosti jako jiný uživatel, v praxi se typicky jedná o role nadřízený – podřízený. Abychom nemuseli všechny asociace zdvojovat, použijeme dědičnost, což znamená, že nadřízený dědí všechna práva, které má podřízený. Takový vztah nazýváme generalizací a značíme jej prázdnou šipkou vedenou směrem k předkovi.
Obrázek 3.14: Symbol generalizace mezi aktéry Popis aktérů: Prodejce se přihlašuje do systému, odhlašuje se z něj a ukládá prodeje. Provozní dědí případy užití od Prodejce, navíc má možnost přesunovat zboží z jednoho stánku na druhý, přijímat zboží od externích dodavatelů a na konci směny zadává do systému chybějící zboží – provádí inventuru zboží. Skladník se přihlašuje do systému, odhlašuje se z něj, stará se o příjem zboží od externích dodavatelů a přesunuje zboží mezi stánky. Jakmile systém zaregistruje pokles množství zboží na některém ze stánků, zašle informační e-mail Skladníkovi a ten přesune požadované zboží z hlavního skladu nebo jiného stánku (v případě, že na hlavním skladě není zboží dostupné) na daný stánek. Manažer dědí všechny případy užití od ostatních aktérů, navíc má možnost smazat libovolný prodej, který zadal Prodejce nebo Provozní. Manažer dále upravuje seznam stánků a jejich ceníky, spravuje uživatele systému, externí dodavatele, prodávané zboží a postup výroby vlastních produktů a má možnost zadávat do systému slevové kupony. 15
3. Použité nástroje, analýza a návrh systému 3.2.3 Případy užití Případem užití rozumíme akci nebo posloupnost akcí, kterou systém vykoná na základě vnějšího působení jednoho nebo více aktérů. Případy užití jsou součástí systému a píšeme je z pohledu aktéra, kterým jsou vyvolány. Tvorba případů užití je proces, který se stále rozšiřuje a vyvíjí. Při tvorbě případů užití nejprve volíme název případu užití, poté určujeme vztahy s aktéry, připisujeme poznámky, až se dostaneme k podrobné specifikaci každého z nich. V diagramu jim přísluší značka elipsy s názvem vepsaným typicky dovnitř.
Obrázek 3.15: Symbol případu užití I mezi případy užití existují vazby. Abychom zabránili opakovanému zápisu kódu nebo umožnili rozšířit funkcionalitu případu užití pomocí jiného, existují v diagramu případu užití relace include a extend. Relaci include použijeme v případě, kdy máme např. případ užití Vyhledání zboží, který aplikujeme při změně zboží, prodeji zboží, změně výrobního procesu zboží nebo inventuře zboží. Abychom nemuseli případ užití Vyhledání zboží stále opakovat, zahrneme jej do požadovaných případů právě prostřednictvím relace include. Případy propojíme plnou čarou s popiskem include. Relaci extend použijeme, pokud chceme rozšířit případ užití o novou funkcionalitu. Primární odlišností od relace include je fakt, že původní případ užití, který rozšiřujeme, o rozšiřujícím případu vůbec nic neví a je i bez něj naprosto soběstačný. Naopak případ užití s použitím relace include, který jsem popisoval výše, je funkčně závislý na Vyhledání zboží.
16
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use]
Turbomošt system Přihlášení do systému
Odhlášení ze systému
Změna hesla Prodejce
e-mail
Otevření a uzavření pokladny
Zaslání upozornění
<<Extend>>
Skladník
<<Extend>>
Zadání prodeje extension points Příjem zboží od Otevření a uzavření pokladny dodavatelů Zaslání upozornění <
> < < I n c l u d e > > Smazání prodeje
Vyhledání zboží Provozní
<> <> <<Extend>>
Smazání prodeje
Přesun zboží
Zadání chybějícího zboží
<>
<> Evidence ceníků
Evidence zboží a výrobních postupů
Manažer
Manažer Evidence dodavatelů Evidence stánků
Evidence uživatelů a jejich pozic
Evidence slevových kuponů
Obrázek 3.16: Diagram případů užití 17
3. Použité nástroje, analýza a návrh systému Popis vybraných případů užití: ◇
Vyhledání zboží ID: UC03 Stručný popis: Uživatel vyhledává zboží. Aktéři: Prodejce, Provozní, Skladník, Manažer Vstupní podmínky: Uživatel je přihlášen do systému. Hlavní scénář: 1. 2.
Uživatel zadá identifikátor zboží. Systém vyhledá zboží a údaje o něm.
Výstupní podmínky: Systém nalezl údaje o zboží. ◇
Zadání prodeje ID: UC04 Stručný popis: Uživatel zvolí dané prodejní zboží a přidá prodej do systému. Aktéři: Prodejce, Provozní, Manažer Vstupní podmínky: Uživatel je přihlášen do systému, uživatel má otevřenu pokladnu, je zobrazen seznam nabízeného zboží. Hlavní scénář: 1. 2.
3. 4. 5. 6. 7.
P.U. začíná, když uživatel klikne na odkaz Pokladna. WHILE (Uživatel neklikne na tlačítko „Zaplatit“): (a) Uživatel vybere prodávané zboží tím, že zvolí množství prodávaného zboží. (b) Uživatel zvolí slevový kupon. INCLUDE (Vyhledání zboží). Systém zobrazí celkovou cenu prodeje. Systém uloží prodej do databáze. Systém odečte ze skladu stánku zboží, které bylo prodáno. Systém zobrazí seznam nabízeného zboží. 18
3. Použité nástroje, analýza a návrh systému Výstupní podmínky: Prodej zboží je uložen do databáze, je zobrazen seznam nabízeného zboží. ◇
Přesun zboží ID: UC06 Stručný popis: Uživatel přesouvá zboží ze stánku na stánek. Aktéři: Skladník, Provozní, Manažer Vstupní podmínky: Uživatel je přihlášen do systému. Hlavní scénář: 1. 2. 3. 4. 5. 6. 7. 8.
P.U. začíná, pokud uživatel klikne na odkaz Sklady. Systém vyhledá a zobrazí seznam stánků ve formuláři. Uživatel vybere zdrojový stánek, odkud bude přesouvat zboží. INCLUDE (Vyhledání zboží), které se nachází na zdrojovém stánku. Uživatel vybere požadované zboží a jeho množství k přesunu. Uživatel zvolí cílový stánek, kam se bude zboží přesouvat a odešle formulář. INCLUDE (Vyhledání zboží), které se nachází na cílovém stánku. Systém odebere zvolené množství zboží ze zdrojového stánku a přidá jej na cílový.
Výstupní podmínky: Zvolené množství zboží je přesunuto ze zdrojového stánku na cílový. ◇
Zaslání upozornění ID: UC07 Stručný popis: Systém zašle Skladníkovi upozornění, pokud se množství daného zboží dostane pod stanovenou mez. Aktéři: Skladník Vstupní podmínky: Množství některého zboží je pod stanovenou mezí. 19
3. Použité nástroje, analýza a návrh systému Hlavní scénář: 1. 2.
P.U. začíná, pokud se množství některého zboží na stánku dostane pod stanovenou mez. Systém zašle Skladníkovi e-mail s informací o překročení meze.
Výstupní podmínky: Žádné. ◇
Evidence uživatelů a jejich pozic ID: UC13 Stručný popis: Manažer eviduje seznam uživatelů systému a zadává jejich pozice/role. Aktéři: Manžer Vstupní podmínky: Manažer je přihlášen do systému. Hlavní scénář: 1. 2. 3.
4. 5. 6.
P.U. začíná, když Manažer klikne na odkaz Evidence uživatelů. Systém vyhledá seznam všech uživatelů systému. KDYŽ Manažer klikne na vybraného uživatele: (a) Systém vyhledá daného uživatele a zobrazí údaje o něm. Systém zobrazí formulář pro úpravu/vložení údajů. Manažer upraví/vloží údaje o uživateli a odešle formulář. Systém uloží údaje o uživateli do databáze.
Výstupní podmínky: Údaje o uživateli jsou uloženy v databázi. ◇
Evidence zboží a výrobních postupů ID: UC14 Stručný popis: Manažer zboží a postupy jeho výroby. Aktéři: Manažer Vstupní podmínky: Manažer je přihlášen do systému. 20
3. Použité nástroje, analýza a návrh systému Hlavní scénář: 1. 2. 3.
4. 5. 6.
P.U. začíná, když Manažer klikne na odkaz Výroba. Systém vyhledá seznam všeho zboží. KDYŽ Manažer klikne na vybrané zboží: (a) INCLUDE (Vyhledání zboží). (b) Systém zobrazí údaje o výrobě. Systém zobrazí formulář pro úpravu/vložení údajů. Manažer upraví/vloží údaje o zboží a odešle formulář. Systém uloží údaje o zboží do databáze.
Výstupní podmínky: Údaje o zboží jsou uloženy v databázi. ◇
Otevření pokladny ID: UC17a Stručný popis: Uživatel otevírá pokladnu na stánku. Aktéři: Manažer, Provozní, Prodejce Vstupní podmínky: Uživatel je přihlášen do systému a nemá otevřenou pokladnu. Hlavní scénář: 1. 2. 3.
P.U. začíná, když Uživatel vybere stánek a klikne na odkaz Otevřít pokladnu. Systém zahájí směnu a otevře pokladnu pro Uživatele na daném stánku. Systém vyhledá seznam ceníků a zobrazí je ve formuláři.
Výstupní podmínky: Uživatel má na daném stánku otevřenou pokladnu. Zbývající popisy případů užití jsou uvedeny v příloze A.
21
3. Použité nástroje, analýza a návrh systému
3.3
Diagram tříd
Diagram tříd (Class diagram) je statický diagram [5], který ukazuje pohled na systém. Můžeme jej rozdělit do tří úrovní: 1.
analytický model – základní pohled na systém, modelujeme bez operací, pouze třídy s klíčovými atributy, které zatím blíže nespecifikujeme; analytický model je nezávislý na programovacím jazyku;
2.
návrhový model – odvíjí se od analytického modelu, který postupně zpřesňujeme, doplňujeme atributům viditelnost; model se rozrůstá o nové třídy;
3.
implementační model – specifikujeme kompletní implementační charakteristiky, můžeme z něj vygenerovat kostru aplikace ve zvoleném programovacím jazyce, jedná se o velmi podrobný popis systému, který programátorovi přesně určí, jak má systém naprogramovat.
3.3.1 Třídy Třída (Class) sdružuje objekty se stejnými vlastnostmi a stejným chováním [6]. Jsou to objekty, které mají totožné atributy a metody. Objekt je instancí třídy, což se dá vysvětlit tak, že máme-li třídu „Galaxy Nexus2 “, která definuje všechny vlastnosti daného typu telefonu, objektem této třídy je konkrétní kus, který držíme v ruce, s jedinečným identifikačním číslem. Velmi pěkným příkladem je razítko (třída) s jednotlivými otisky (objekty). Identitu objektu určuje jedinečný identifikátor, ve výše zmíněném příkladu je to IMEI3 telefonu. Objekty jedné třídy mají společné atributy a metody. Atributy uchovávají data objektu (určují stav objektu) a metody jsou uskutečněním operací nad daným objektem (určují chování objektu a většinou mění hodnoty jeho atributů). Třídu v diagramu značíme obdélníkem rozděleným na tři části. V první části je název třídy (podstatná jména nebo slovní spojení začínající velkým písmenem, další jsou malá, bez mezer a diakritiky), ve druhé jsou 2. Nejnovější referenční mobilní zařízení od společností Google a Samsung. 3. International Mobile Equipment Identity. Je to unikátní číslo přidělené výrobcem mobilnímu telefonu.
22
3. Použité nástroje, analýza a návrh systému vyjmenovány všechny atributy třídy (podstatná jména začínající malým písmenem, při slovním spojení začíná každé další slovo velkým písmenem, opět bez mezer a diakritiky) a třetí část obsahuje názvy metod, pro jejichž názvy platí stejná pravidla jako u atributů. Pojmenováváme ovšem slovesným tvarem nebo souslovím, např. zobrazitJmeno nebo zobrazJmeno.
Obrázek 3.17: Ukázka značení třídy Před každým atributem a metodou uvádíme jejich viditelnost: ◇
„+“ – Veřejný (Public) – libovolná metoda má možnost přistupovat k atributu nebo metodě s viditelností Public;
◇
„−“ – Soukromý (Private) – pouze metody uvnitř dané třídy mají přístup k atributu nebo metodě s viditelností Private;
◇
„#“ – Chráněný (Protected) – k atributům a metodám s viditelností Protected mají přístup metody uvnitř dané třídy a potomci této třídy;
◇
„∼“ – Balíček (Package) – k atributům a metodám s viditelností Package povolujeme přístup z celého balíčku, ve kterém je daná třída, a z balíčků vnořených.
3.3.2 Vztahy Aby mohly třídy mezi sebou komunikovat a fungovat, existují mezi nimi vztahy. Mezi třídami používáme vztahy: asociace, agregace, kompozice, zobecnění a realizace, které jsou popsány v části 3.1.3 na straně 9. Posledním vztahem mezi třídami je tzv. asociační třída (Association 23
3. Použité nástroje, analýza a návrh systému class), která slouží např. pro vyjádření vztahu M:N, nebo pokud chceme přiřadit ke vztahu doplňující atributy. Často se udává příklad asociační třídy jako vztah mezi zaměstnancem a zaměstnavatelem, kde ukazuje mzdu zaměstnance. U každého vztahu dále určujeme násobnost (Multiplicity), která říká, kolik objektů dané třídy se podílí v jednom okamžiku na vztahu mezi třídami. 3.3.3 Analytický model Na obrázku 3.18 je analytický model tříd, který znázorňuje pohled na objekty v systému a vztahy mezi nimi. Abychom získali komplexní náhled na celý systém, musíme udržet model přehledný a ne příliš složitý. Úroveň abstrakce u analytického modelu je poměrně vysoká. 3.3.4 Návrhový model Návrhový model je zpřesněním analytického modelu. Doplňujeme nové třídy, vytváříme podrobnější pohled na systém a model se začíná značně rozrůstat. Abychom udrželi jeho přehlednost, je vhodné vytvořit samostatné návrhové diagramy tříd pro stěžejní části systému. Systém rozdělíme na část evidence, přesunů zboží, prodejní část a část inventur. Evidence Na diagramu 3.19 je znázorněna evidence, do níž má přístup uživatel v roli manažera. Třída Uživatel slouží k vytváření uživatelů a editaci jejich údajů. Po vyplnění jména, role a e-mailu uživatele systém vygeneruje osmimístné uživatelské jméno, které se skládá z prvních čtyř písmen jména a příjmení. Systém kontroluje duplikáty, a proto, pokud je nově vygenerované uživatelské jméno již v databázi obsaženo, se odebere potřebný počet písmen z konce uživatelského jména a nahradí číslicí. Po vytvoření uživatelského účtu se vygeneruje desetimístné uživatelské heslo, které je odesláno na e-mailovou adresu uživatele. Heslo je uloženo do databáze v hašované formě, aby bylo chráněno před potenciálním útočníkem. V případě, že uživatel zapomene přihlašovací údaje, může si u manažera vyžádat zaslání nového hesla na e-mail. 24
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use]
Uzivatel -jmeno : String -login : String -heslo : String -email : String
Prodejce
1
Prodej -datum : Timestamp
vytvoří 0..*
obsahuje
0..* 0..1
0..*
SlevovyKupon -nazev_slevovy_kupon : String -procento : Integer
Provozni
0..*
provádí 1 0..* Skladnik
0..* přeskladňuje 0..* 0..*
eviduje
1
eviduje
Manazer
0..1
0..*
ChybejiciZbozi -mnozstvi : Float
obsahuje
1 1
1
1 obsahuje
1
0..*
1
Inventura -datum : Timestamp
Zbozi -nazev_zbozi : String -popis : String -jednotka : Jednotka
1
eviduje
0..*
dodává
eviduje eviduje
1..* obsahuje
0..*
1
Stanek -nazev_stanek : String -typ_stanku : TypStanku
0..1
0..*
Cenik -platnost_od : Timestamp -platnost_do : Timestamp -cena : Integer 0..*
Dodavatel -nazevDodavatel : String -ic : Integer -dic : String -telefon : String -email : String 0..* má adresu
1
má Sklad
1 ProdejniStanek
Adresa -ulice : String -cislo_popisne : String -cislo_orientacni : String -mesto : String -psc : String -stat : String
eviduje
Obrázek 3.18: Diagram tříd – analytický model 25
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use]
Uzivatel -jmeno : String -login : String -heslo : String -email : String -pozice : Pozice
Pozice 0..* 1 má pozici -nazev_pozice : String
TypStanku -nazev_typ_stanku : String 1
+createUzivatel(jmeno : String,... +updateUzivatel(jmeno : String... +createMaPozici(pozice : Pozic... 0..* +updateMaPozici(pozice : Pozi... +setHeslo(heslo : String) +newHeslo(email : String)
SlevovyKupon -nazev_slevovy_kupon :... -procento : Integer
0..*
Stanek -nazev_stanek : String -attribute : TypStanku
+createSlevovyKupon(n... +updateSlevovyKupon(...
+createStanek(nazev : String,... +updateStanek(nazev : String...
0..*
Dodavatel -nazevDodavatel : String -ic : Integer -dic : String -telefon : String -email : String -adresa : Adresa
je typu
0..*
eviduje eviduje
eviduje
Sklad
+createDodavatel(adresa : A... +updateDodavatel(adresa : A...
ProdejniStanek
0..* 0..*
eviduje
1 1
1 1
Manazer
má
1
Zbozi -nazev_zbozi : String -popis : String -jednotka : Jednotka
eviduje 0..*
1
eviduje
1
0..* 0..*
+createZbozi(nazev : St... +updateZbozi(nazev : S... eviduje
1 má adresu
Cenik -platnost_od : Timestamp -platnost_do : Timestamp -cena : Integer +createCenik(stanek : Sta... +updateCenik(stanek : St...
je použito
0..*
1 Adresa -ulice : String -cislo_popisne : String -cislo_orientacni : String -mesto : String -psc : String -stat : String
Vyroba -platnost_od : Timestamp -platnost_do : Timestamp -mnozstvi : Float
+createAdresa(ulice : String, cp :... +updateAdresa(ulice : String, cp ...
+createVyroba(prodZbozi : ... +updateVyroba(prodZbozi ...
je součástí
0..* 0..*
1 1..*
1
ProdejniZbozi -nazev_prodejni_zbozi : String -popis : String
je vyrobeno +createProdejniZbozi(nazev :... +updateProdejniZbozi(nazev ...
Obrázek 3.19: Návrhový diagram tříd – evidence 26
3. Použité nástroje, analýza a návrh systému Třídy Dodavatel a Adresa se starají o evidenci dodavatelů, u kterých registrujeme IČ, DIČ a další kontaktní údaje. Třídy SlevovyKupon, Stanek a Zbozi slouží k vytváření a úpravě jejich instancí. Pomocí tříd ProdejniZbozi a Vyroba manažer eviduje zboží, které se bude prodávat na stáncích, tzn. určuje množství jednotlivých druhů zboží, které se použije pro výrobu prodejního zboží. To následně zařadí do ceníku některého z existujících stánků pomocí třídy Cenik. Protože se může výroba prodejního zboží i cena zboží v ceníku měnit, systém udržuje platnost jednotlivých položek pomocí atributů platnost_od a platnost_do. Tím je zajištěna konzistence dat v systému. Přesuny zboží Diagram 3.20 znázorňuje naskladnění zboží od dodavatelů a přesuny zboží ze stánku na stánek. S touto částí systému pracuje převážně skladník, ale možnost přesunu zboží mají i uživatelé v roli provozního nebo manažera. Aby se zboží dostalo do systému, je nutné jej naskladnit od dodavatelů. Poté oprávněný uživatel přesunuje zboží ze stánku na stánek. O průběh se stará třída Presun. Třída SkladovaZasoba udržuje aktuální stav zboží na jednotlivých stáncích. Atribut dolni_mez určuje hranici minimálního množství zboží na stánku. Pokud množství klesne pod tuto hranici, je nutné zboží doplnit, aby nedošlo k omezení prodeje zboží, které se z něj vyrábí. Atribut horni_mez udává maximální množství zboží na stánku, tedy limit množství, do kterého jej doplňujeme. Obě meze se nastavují vždy po uzavření pokladny na stánku. Výpočet probíhá podle statistiky prodejů za poslední tři dny. Systém spočítá u každého zboží průměrnou spotřebu za jeden den a meze se vypočítají podle následujících rovnic: 𝑝𝑑𝑠 , ℎ𝑚 = 2 · 𝑝𝑑𝑠, (3.1) 2 kde dm je dolní mez, hm horní mez a pds je průměrná denní spotřeba za poslední 3 dny. Při vytvoření přesunu zboží systém nejprve zkontroluje, zda-li je na zdrojovém stánku požadované množství zboží (v případě, že přesunujeme ze stánku na stánek), a pokud ano, odečte jej ze skladové zásoby zdrojového stánku a přičte na sklad cílového stánku. Informace 𝑑𝑚 =
27
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use]
Uzivatel -jmeno : String -login : String -heslo : String -email : String -pozice : Pozice
0..*
1
Pozice -nazev_pozice : String
TypStanku -nazev_typ_stanku : String
má pozici 1
+createUzivatel(jmeno : Strin... +updateUzivatel(jmeno : Stri... +createMaPozici(pozice : Poz... +updateMaPozici(pozice : Po... +setHeslo(heslo : String) +newHeslo(email : String)
Provozni
je typu
1
0..*
Stanek -nazev_stanek : String -attribute : TypStanku +createStanek(nazev : String, t... +updateStanek(nazev : String, ... provádí
Skladnik
0..1
Manazer
1
1
ze stánku
1
má
na stánek provádí 0..* Dodavatel -nazevDodavatel : String -ic : Integer -dic : String -telefon : String -email : String -adresa : Adresa
0..* 0..* 0..1
0..*
obsahuje
+createDodavatel(adresa : A... +updateDodavatel(adresa : A...
SkladovaZasoba -mnozstvi : Float -datum : Timestamp -dolni_mez : Float -horni_mez : Float
0..*
Presun -datum : Timestamp -dodavatel : Dodavatel -z_stanek : Stanek -do_stanek : Stanek
0..*
+createSkladovaZasoba(zb... +presunZbozi(zbozi : Zboz... +odectiSkladovaZasoba(zb...
+createPresun(dodavatel ...
0..*
0..*
1
má adresu
obsahuje
je obsaženo
1 Adresa -ulice : String -cislo_popisne : String -cislo_orientacni : String -mesto : String -psc : String -stat : String +createAdresa(ulice : String, cp :... +updateAdresa(ulice : String, cp ...
0..* PolozkaPresunu -mnozstvi : Float -zbozi : Zbozi +createPolozkaPresunu(zb...
1
je obsaženo
0..*
Zbozi -nazev_zbozi : String 1 -popis : String -jednotka : Jednotka +createZbozi(nazev : String... +updateZbozi(nazev : Strin...
Obrázek 3.20: Návrhový diagram tříd – přesuny 28
3. Použité nástroje, analýza a návrh systému o přesunu se uloží do databáze. Prodeje Diagram 3.21 zachycuje prodejní část systému. Po přihlášení uživatele do systému je nutné prvně zahájit směnu a otevřít pokladnu na stánku, což zajišťuje třída Smena, která nejdříve zkontroluje, zda již má uživatel na požadovaném stánku pokladnu otevřenou. Pokud ano, pokračuje ve směně, pokud ne, zahájí se nová a pokladna se otevře. Po otevření pokladny uživatel zadává prodeje, jejichž evidenci má na starosti třída Prodej. Uživatel vyplní množství prodaného zboží, na které může uplatnit slevový kupon předložený zákazníkem. Třída odečte množství zboží, ze kterého se skládá vyrobené prodejní zboží, z prodejního stánku, spočítá cenu prodeje, ve které je již zahrnuta případná sleva podle slevového kuponu, a po každém prodeji zkontroluje, zda množství některého ze zboží nekleslo pod dolní mez. Jestliže se tak stane, systém upozorní e-mailem skladníka, aby doplnil množství zboží do plného stavu – horní meze. Tím zabrání situaci, kdy by se na stánku spotřeboval některý druh zboží a došlo by tím k omezení prodeje. Třída Prodej dále umožňuje uživatelům v roli provozního a manažera smazat prodej přes webovou aplikaci, pokud to situace vyžaduje. Jakmile je směna u konce, uživatel uzavře pokladnu a odvede hotovost, kterou mu systém spočítá. Inventury Poslední část systému je vyobrazena na diagramu 3.22. Po ukončení směny a uzavření pokladny provede provozní nebo manažer inventuru, jejíž průběh má na starosti třída Inventura. Uživatel vybere ze seznamu požadovanou směnu ke kontrole a systém zobrazí množství všeho zboží, které je podle systému na stánku. Po kontrole uživatel zadá do systému nesrovnalosti – chybějící zboží pomocí třídy ChybejiciZbozi, které se následně odečte ze skladu stánku. Tím je směna definitivně ukončena a stánek je připraven na zahájení nové směny a otevření pokladny s aktuální skladovou zásobou.
29
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use]
Uzivatel -jmeno : String -login : String -heslo : String -email : String -pozice : Pozice
Manazer
TypStanku -nazev_typ_stanku : String 1 je typu
+createUzivatel(jmeno : Strin... +updateUzivatel(jmeno : Stri... +createMaPozici(pozice : Poz... +updateMaPozici(pozice : Po... +setHeslo(heslo : String) +newHeslo(email : String)
0..*
Provozni
Stanek -nazev_stanek : String -attribute : TypStanku +createStanek(nazev : String, t... +updateStanek(nazev : String, ...
0..* Prodejce má pozici 1
1 Pozice -nazev_pozice : String
ProdejniStanek
zahájí
pracuje na 0..*
0..*
1
Smena -prihlaseni : Timestamp -odhlaseni : Timestamp -trzba : Float
Prodej -datum : Timestamp
má
+createSmena(uzivatel : ... +openPokladna() 1 +closeSmena()
0..*
1
0..* Cenik -platnost_od : Timestamp -platnost_do : Timestamp -cena : Integer
vytvoří
+createProdej(smena : ... +deleteProdej() 1
+createCenik(stanek : Stanek, pr... +updateCenik(stanek : Stanek, p...
1 obsahuje obsahuje SlevovyKupon -nazev_slevovy_kupon : String -procento : Integer
0..* PolozkaProdej -kusy : Integer
0..*
+createPolozkaProdeje(prodej :... +deletePolozkaProdeje()
0..*
je uplatněn
0..1
+createSlevovyKupon(nazev : String,... +updateSlevovyKupon(nazev : String...
Obrázek 3.21: Návrhový diagram tříd – prodeje 30
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use]
Uzivatel -jmeno : String -login : String -heslo : String -email : String -pozice : Pozice
Manazer
Smena -prihlaseni : Timestamp -odhlaseni : Timestamp -trzba : Float +createSmena(uzivatel : Uzivatel, s... +openPokladna() +closeSmena()
+createUzivatel(jmeno : String,... +updateUzivatel(jmeno : String... +createMaPozici(pozice : Pozic... +updateMaPozici(pozice : Pozi... +setHeslo(heslo : String) +newHeslo(email : String)
Provozni
1
1
0..*
0..*
pracuje na je kontrolována 1
má pozici
provádí
ProdejniStanek 0..*
1
1
Inventura -datum : Timestamp -provadel : Uzivatel -smena : Smena
Pozice -nazev_pozice : String
+createInventura(smena : Sme...
1
Stanek -nazev_stanek : String -attribute : TypStanku
obsahuje 0..1
+createStanek(nazev : String, t... +updateStanek(nazev : String, ...
ChybejiciZbozi -mnozstvi : Float -zbozi : Zbozi
1
+createChybejiciZbozi(inventur...
0..*
má
0..* 0..*
1 Zbozi -nazev_zbozi : String -popis : String -jednotka : Jednotka
1
0..*
SkladovaZasoba -mnozstvi : Float -datum : Timestamp -dolni_mez : Float -horni_mez : Float
+createSkladovaZasoba(zbozi :... +createZbozi(nazev : String... je obsaženo+presunZbozi(zbozi : Zbozi, z ... +odectiSkladovaZasoba(zbozi :... +updateZbozi(nazev : Strin...
je typu
1 TypStanku -nazev_typ_stanku : String
Obrázek 3.22: Návrhový diagram tříd – inventury 31
3. Použité nástroje, analýza a návrh systému
3.4
Datový model
3.4.1 ERD Informační systémy obsahují velká množství dat, a proto je nutné zajistit jejich správnou strukturu, abychom s nimi mohli pracovat co nejefektivněji. Nejčastěji používaným nástrojem pro modelování databázové struktury je entitně-relační diagram (ERD) [7]. K sestrojení entitně-relačního diagramu používáme, jak již sám název naznačuje, dva základní stavební prvky, a to entity a relace. Entitu představuje reálný objekt, např. zboží, událost, přesun zboží, nebo se může jednat o abstraktní pojem, jako např. jednotka. Entity obsahují atributy, které je určují. Skupinu atributů identifikující záznam jednoznačně nazýváme primární klíč. V diagramu značíme entitu obdélníkem. Abychom mohli znázornit souvislosti mezi entitami, používáme v diagramu vztahy, nebo-li relace, které můžeme popsat slovesy nebo slovesnými tvary a které zakreslujeme pomocí čar, jež tyto entity (obdélníky) spojují. Datový model systému je zachycen na obrázku 3.23.
32
3. Použité nástroje, analýza a návrh systému Visual Paradigm for UML Community Edition [not for commercial use]
id_pozice
pozice integer(4)
nazev_pozice
varchar(32)
ma_pozici id_ma_pozici integer(8)
id_uzivatel
integer(4)
id_pozice
integer(4)
pozice_od
timestamp
pozice_do
timestamp
varchar(32)
login
varchar(16)
heslo
varchar(256)
email
varchar(64)
id_adresa
nazev_slevovy_kupon
varchar(32)
ulice
varchar(64)
procento
integer(4)
cislo_popisne
varchar(8)
cislo_orientacni
varchar(8)
mesto
varchar(64)
psc
varchar(16)
stat
varchar(64)
polozka_prodeje id_prodej integer(8)
id_cenik
integer(4)
id_slevovy_kupon
integer(4)
kusy
integer(4)
id_smena
integer(8)
datum
timestamp
adresa integer(8)
dodavatel id_dodavatel integer(4)
prodej id_prodej integer(8)
uzivatel id_uzivatel integer(4) jmeno
slevovy_kupon id_slevovy_kupon integer(4)
id_adresa
integer(8)
nazev_dodavatel
varchar(64)
ico
integer(16)
dic
varchar(16)
telefon
varchar(16)
email
varchar(64)
typ_stanku id_typ_stanku integer(4) nazev_typ_stanku
varchar(16) id_presun
smena id_smena integer(8)
id_uzivatel
integer(4)
id_stanek
integer(4)
prihlaseni
timestamp
odhlaseni
timestamp
trzba
float
id_uzivatel
integer(4)
stanek id_stanek integer(4)
id_dodavatel
integer(4)
z_id_stanek
integer(4)
id_typ_stanku
integer(4)
do_id_stanek
integer(4)
nazev_stanek
varchar(64)
datum
timestamp
skladova_zasoba id_skladova_zasoba integer(8)
inventura id_smena integer(8)
id_uzivatel datum
integer(4) timestamp
id_zbozi
integer(4)
id_stanek
integer(4)
mnozstvi
float
datum
timestamp
dolni_mez
float
horni_mez
float
id_zbozi chybejici_zbozi id_smena integer(8)
id_zbozi
integer(4)
mnozstvi
float
presun integer(8)
cenik id_cenik
integer(4)
id_stanek
integer(4)
id_prodejni_zbozi
integer(4)
platnost_od
timestamp
platnost_do
timestamp
cena
integer(8)
zbozi integer(4)
id_jednotka
varchar(8)
nazev_zbozi
varchar(64)
polozka_presunu id_presun integer(8)
popis
clob
id_zbozi
integer(4)
mnozstvi
float
vyroba id_vyroba
integer(8)
id_prodejni_zbozi
integer(4)
id_zbozi
integer(4)
jednotka id_jednotka varchar(8)
platnost_od
timestamp
prodejni_zbozi id_prodejni_zbozi integer(4)
platnost_do
timestamp
nazev_prodejni_zbozi
varchar(64)
nazev_jednotka
mnozstvi
float
popis
clob
varchar(64)
Obrázek 3.23: Entitně-relační diagram 33
3. Použité nástroje, analýza a návrh systému Popis entitních množin: ◇
Uživatel Objekty entity jsou všichni uživatelé, kteří jsou evidováni v systému. Primárním klíčem je id_uzivatel, dalším atributem je jmeno uživatele, email, systémem vygenerovaný login a heslo, které je uloženo pomocí kryptovací funkce se solí (Salted hash4 ).
◇
Pozice Zde nalezneme data o pozicích přidělovaných k uživatelům, které jsou fixní a uživatelé je nemohou měnit. id_pozice je primární klíč, atribut nazev_pozice označuje pojmenování dané pozice.
◇
Má pozici Tabulka uchovává data o přidělených pozicích uživatelům, které se mohou v čase měnit, a proto je není možné udržovat přímo v tabulce uzivatel. Primárním klíčem je id_ma_pozici, atributy id_uzivatel a id_pozice jsou cizími klíči odkazující na konkrétní pozici a uživatele, které jsou spojeny v čase díky atributům pozice_od a pozice_do.
◇
Adresa Prvky množiny jsou adresy, které jsou svázány s dodavateli. Primárním klíčem je id_adresa, jednotlivými atributy jsou: ulice, cislo_popisne, cislo_orientacni, mesto, psc a stat.
◇
Dodavatel Objekty jsou externí dodavatelé, od kterých uživatel naskladňuje nové zboží. Entita obsahuje cizí klíč id_adresa odkazující na adresu dodavatele, nazev_dodavatel, kontaktní údaje telefon a email, a také atributy ico, dic, ve kterých je uloženo platné IČO5 , resp. DIČ6 dodavatelské firmy.
4. Technika, při které přidáme k zahašovanému heslu další řetězec, tzv. sůl, pro zvýšení bezpečnosti a zabránění případnému útočníkovi zneužití otisku hesla v jiných informačních systémech v případě, že uživatel používá stejná hesla. 5. Identifikační číslo osoby podnikající v České republice. 6. Daňové identifikační číslo daňového poplatníka.
34
3. Použité nástroje, analýza a návrh systému ◇
Typ stánku Jedná se o číselník určující typ stánku, jejímž primárním klíčem je id_typ_stanku, s jedním atributem nazev_typ_stanku. V systému evidujeme pro naši potřebu dva typy stánků, a to sklad a prodejní stánek.
◇
Stánek Entita udržuje data o stáncích, a to jejich typ pomocí cizího klíče id_typ_stanku a název stánku v atributu nazev_stanku.
◇
Jednotka Opět se jedná o číselník, tentokráte měrných jednotek, které budeme přiřazovat ke zboží. Primární klíč je id_jednotka a tabulka má jeden atribut nazev_jednotka.
◇
Zboží Entita zbozi znázorňuje objekty, které přijímáme od dodavatelů a přeskladňujeme mezi stánky. Jsou to suroviny, ze kterých následně vyrábíme zboží (produkty) určené k přímému prodeji na stáncích. Primárním klíčem je atribut id_zbozi, cizí klíč id_jednotka odkazuje na měrnou jednotku daného zboží a posledními atributy jsou nazev_zbozi a popis.
◇
Prodejní zboží Prvky množiny jsou druhy zboží, které se prodávají na stáncích, kde se také vyrábí. Výroba probíhá podle předem stanovených procesů ze zboží (surovin), které je na skladu stánku. Primárním klíčem je id_prodejni_zbozi, nazev_prodejni_zbozi je atributem.
◇
Výroba Tabulka vyroba obsahuje data o výrobě prodejního zboží, která se může v čase měnit. Časovou platnost výrobního postupu zajišťují atributy platnost_od a platnost_do, id_prodejni_zbozi je cizí klíč uchovávající informaci, ke kterému prodejnímu zboží se výrobní postup vztahuje, cizí klíč id_zbozi ukazuje, z jakého zboží se vyrábí, a atribut mnozstvi je množství zboží, které je 35
3. Použité nástroje, analýza a návrh systému k výrobě potřeba. Na každém řádku tabulky nalezneme množství jedné suroviny pro výrobu prodejního zboží. Primárním klíčem je id_vyroba. ◇
Ceník Každý prodejní stánek (cizí klíč id_prodejni_stanek) má svůj ceník, který se skládá z cizího klíče id_prodejni_zbozi, reprezentující prodejní zboží, jeho ceny (atribut cena) a atributů vymezující platnost položky v ceníku (platnost_od a platnost_do). id_cenik je primární klíč.
◇
Skladová zásoba V tabulce skladova_zasoba jsou uloženy informace o aktuálním stavu množství zboží na daném stánku. Primárním klíčem je id_skladova_zasoba, cizími klíči jsou id_zbozi a id_stanek odkazující na konkrétní objekty. Atribut mnozstvi_zbozi nese hodnotu množství zboží na stánku, datum je časová známka, kdy byl stav zboží naposledy aktualizován. Poslední dva atributy jsou dolni_mez a horni_mez, dolní mez označuje hranici minimálního množství zboží na stánku, horní mez značí množství zboží v plném stavu.
◇
Přesun Entita obsahuje data o provedeném přesunu zboží. id_presun je primárním klíčem, cizí klíče id_dodavatel a z_id_stanek odkazují na zdroj přesunu, tedy odkud zboží přesouváme. Jeden z atributů má vždy hodnotu null a druhý určuje id zdroje. Podle toho poznáme, zda přesun proběhl ze stánku nebo od dodavatele. do_id_stanek je cizí klíč, odkazuje na cílový stánek. Posledním atributem je časová známka přesunu datum.
◇
Položka přesunu Položka přesunu se váže na tabulku presun pomocí cizího klíče id_presun a dále obsahuje cizí klíč id_zbozi, který nese hodnotu id přesunutého zboží. Atribut mnozstvi udává množství a primárním klíčem je id_polozka_presunu.
36
3. Použité nástroje, analýza a návrh systému ◇
Směna Prvky množiny jsou směny, které vzniknou otevřením pokladny uživatelem (cizí klíč id_uzivatel) na stánku (cizí klíč id_stanek). Atribut prihlaseni označuje datum a čas otevření pokladny a počátek směny, odhlaseni datum a čas uzavření pokladny. Atribut trzba nese údaje o celkové částce utržené z prodaného zboží na směně a primárním klíčem je id_smena.
◇
Slevový kupon Entita s primárním klíčem id_slevovy_kupon představuje slevové kupony, které může zákazník uplatnit při nákupu na stáncích. Skládá se z atributu nazev_slevovy_kupon a procento, ve kterém je uložena procentuální výše slevy.
◇
Prodej Tabulka prodej s primárním klíčem id_prodej obsahuje atribut datum, který říká, kdy byl prodej uskutečněn a cizí klíč id_smena odkazující na směnu, která prodej provedla.
◇
Položka prodeje Položka prodeje je svázána s tabulkou prodej prostřednictvím cizího klíče id_prodej. Cizí klíč id_cenik ukazuje na prodávané zboží z příslušného ceníku a cizí klíč id_slevovy_kupon přiřazuje k položce prodeje slevu. Pokud je atribut id_slevovy_kupon roven hodnotě null, zboží bylo prodáno beze slevy. Atribut kusy udává počet prodaného ceníkového zboží a primárním klíčem tabulky je id_polozka_prodeje.
◇
Inventura Entita obsahuje údaje o provedené inventuře s primárním klíčem id_smena, který je zároveň cizím klíčem určující směnu, které byla inventura provedena. Uživatel, který ji provádí, je evidován pomocí cizího klíče id_uzivatel a datum a čas inventury je uložen v atributu datum. Každé položce v tabulce smena náleží jedna položka v tabulce inventura, která je vytvořena po uzavření pokladny a fyzickém provedení inventury. 37
3. Použité nástroje, analýza a návrh systému ◇
Chybějící zboží V tabulce chybejici_zbozi nalezneme zboží (id_zbozi), které uživatel provádějící inventuru na daném stánku (id_stanek) postrádal. Množství chybějícího zboží uložíme pomocí atributu mnozstvi. Primárním klíčem tabulky je id_chybejici_zbozi.
38
Kapitola 4
Implementace systému V této kapitole popisuji nástroje, postupy a principy implementace, které jsem použil při tvorbě webové aplikace a mobilní aplikace pro operační systém Android. Systém je dostupný na adrese http://www.turbosystem.cz a byly v něm vytvořeny čtyři testovací uživatelské účty podle rolí: ◇
Manažer Login: manazer Heslo: manazer
◇
Skladník Login: skladnik Heslo: skladnik
◇
Provozní Login: provozni Heslo: provozni
◇
Prodejce Login: prodejce Heslo: prodejce
4.1
Model-View-Controller architektura
V posledních letech je architektura Model-View-Controller [8] (MVC) velmi populární, obzvláště při tvorbě rozsáhlých informačních systémů. Základní myšlenkou je oddělení kódu aplikačního logiky od uživatelského rozhraní. Pro programátora je mnohdy jednodušší spojit logickou 39
4. Implementace systému část i uživatelské rozhraní do jednoho celku, avšak při vývoji stále roste objemu kódu, zdrojový kód aplikace se stává nepřehledný a případná implementace nové funkcionality je složitější.
Obrázek 4.1: Architektura Model-View-Controller Architektura MVC tento problém řeší rozdělením kódu na tři části takovým způsobem, aby změny v kódu jedné části měly co nejmenší dopad na části zbývající. Tyto tři části se nazývají Model, View a Controller. Model představuje datovou část aplikace a vše, co souvisí s logickou strukturou. Patří sem např. všechny dotazy z databází nebo výpočty. Model funguje sám, nezávisle na zbylých dvou částech, o jejichž existenci neví. Při použití ORM (Objektově relační mapování1 ) odpovídají modely databázovým tabulkám. View, neboli Pohled, má za úkol zobrazovat uživateli data na výstupu. Zpravidla jsou to šablony, které jsou vykresleny pomocí značkovacího jazyka, tedy to, jak aplikaci uživatel vidí. Pohledy neobsahují téměř žádnou aplikační logiku, a pokud ano, jedná se o elementární strukturu, jako např. použití foreach cyklu k výpisu opakujících se položek. Pohled stejně jako Model netuší, odkud přichází data, se kterými pracuje, a stará se pouze o jejich vykreslení na výstupu. 1. Programovací technika, pomocí které je možná konverze dat mezi objektově orientovanými jazyky a relačními databázemi.
40
4. Implementace systému Controller (Řadič) doplňuje předchozí dvě části a obstarává komunikaci a funkcionalitu mezi nimi. Komunikuje s Modelem, od kterého přijímá data nebo je pomocí něj ukládá do databáze, i s Pohledem, kterému data předává k zobrazení uživateli. Slouží tedy jako centrála propojující Model a Pohled, která jim umožňuje mezi sebou spolupracovat. V praxi to ve stručnosti funguje tak, že uživatel klikne na odkaz na webové stránce, která předá Řadiči parametry. Řadič zavolá Model, který vyhledá nebo modifikuje data v databázi. Po provedené akci Řadič předá nová data Pohledu a ten je zobrazí na výstupu. Při použití architektury MVC je kód aplikace mnohem přehlednější a programátor si tím usnadňuje jak orientaci, tak i myšlení při vývoji.
4.2
Webová aplikace
Pro implementaci webové aplikace jsem zvolil programovací jazyk PHP [9] ve spojení s databázovým systémem MySQL [10, 11], značkovacím jazykem pro tvorbu webových aplikací HTML5 [12] a kaskádovými styly CSS3 [13]. Tuto kombinaci jsem zvolil podle zadaných nefunkčních požadavků, jejichž součástí je provoz na stávajícím webovém hostingu, a také proto, že s ní mám zkušenosti z praxe. Osvědčila se mi při nasazování obdobných projektů. Tato kombinace je vhodná také díky vysoké podpoře ze strany poskytovatelů hostingu, protože se v dnešní době jedná o standard při tvorbě internetových aplikací. Další technologií, kterou jsem při tvorbě aplikace použil, je knihovna jQuery [14] sloužící k usnadnění práce s javascriptem. Ten je dnes téměř nepostradatelný při vytváření webových aplikací, a také velmi rozšířený, protože jej podporují všechny moderní internetové prohlížeče. 4.2.1 Nette framework Nette [15] je framework2 , za jehož vznikem stojí český programátor David Grudl. Ten s pomocí komunity okolo frameworku vydal v roce 2004 první verzi a v roce 2008 byl Nette framework uvolněn jako open 2. Framework je softwarová struktura usnadňující práci při programování aplikace, která používá připravené knihovny, podpůrné programy nebo obsahuje doporučené postupy při programování.
41
4. Implementace systému source3 pod licencí BSD4 , která je jednou z nejvolnějších. A díky tomu je framework možno používat zdarma i pro komerční účely. Nette framework sice nepatří k těm největším, ale má obrovskou českou uživatelskou základnu, podporuje mnoho zajímavých doplňků a patří k těm nejvýkonnějším. Proto jsem zvolil právě jej. Framework používá architekturu velmi podobnou již zmiňované MVC, která má i téměř totožný název Model-View-Presenter (MVP).
Obrázek 4.2: Architektura Model-View-Presenter Hned na první pohled lze z obrázku 4.2 rozeznat jeden z rozdílů. Uživatel komunikuje pouze s Pohledem, resp. Pohled zpracovává vstupy i výstupy od uživatele. Odpovídá na akci uživatele tím, že zavolá metodu Presenteru, který se stará o celou aplikační logiku. Přenesení aplikační logiky do Pohledu je v architektuře MVP chybou. Dalším rozdílem je silnější vazba mezi Pohledem a Presenterem. Tato vazba je oboustranná, i když podle některých zdrojů přímá vazba Pohledu na Presenter nutná není. Nette klade důraz především na bezpečnost. Používá metody, které zabraňují potenciálnímu útočníkovi nežádoucí přístup k informacím. Mezi nejčastěji používané způsoby narušení webové aplikace patří CrossSite Scripting5 (XSS), proti kterému se můžeme bránit pouze ošetřením 3. Software, který je veřejně dostupný a umožňuje uživatelům zdrojový kód používat. 4. http://nette.org/cs/license 5. Metoda, která využívá k narušení bezpečnosti internetových stránek neošetřené
42
4. Implementace systému všech textových řetězců. Pokud programátor zapomene ošetřit byť jen jeden řetězec, může nastat problém. To všechno řeší Nette za programátory pomocí technologie Context-Aware Escaping [16], která automaticky převádí textové znaky se zvláštním významem na jiné textové řetězce. Jak technologie funguje, můžete vidět na níže uvedeném příkladě: { $nazev }
Máme proměnnou $nazev, které přiřadíme hodnotu textový řetězec ’Tom&Jerry’. Nette jej automaticky ošetří a na výstup vypíše následující kód: Tom & amp ; Jerry
Další hrozbou je Cross-Site Request Forgery6 (CSRF). Ochrana proti tomuto útoku spočívá v generování autorizačního tokenu – před každou operací vytvoříme náhodný textový řetězec a po provedení jej zkontrolujeme. O to se opět stará Nette. Programátor pouze na formuláři zavolá metodu, která zajistí ošetření: $form - > addProtection (); Framework myslí i na ochranu proti napadení sessions, jako je Session stealing7 nebo session fixation8 . Ochranou je správné nastavení PHP a serveru, což Nette zajistí, pokud to server dovoluje. vstupy. Pokud vstupy nejsou ošetřeny, útočník může vepsat do formulářového prvku javasciptový kód, který může změnit jak vzhled stránky, tak získat citlivá data uložená v databázi aplikace. 6. Útok, který využívá přihlášeného uživatele, jemuž podstrčí script vykonávající např. změny v databázi. 7. Metoda kradení sessions, která umožňuje přístup k sessions oběti. 8. Metoda, kdy útočník podstrčí klientovi nějakou hodnotu session id (např. zasláním odkazu nebo prostřednictvím e-mailu) a jakmile uživatel na odkaz klikne, útočník tuto session id zneužije.
43
4. Implementace systému Velmi užitečným nástrojem pro programátora je knihovna pro debugování a zpracovávání chyb. V komunitě je známá pod názvem Laděnka (od slovesa ladit), pomocí níž jsou chyby odhaleny velmi snadno a rychle. Laděnka pomáhá např. s vypisováním proměnných nebo měřením délky trvání databázových dotazů. Pokud se vyskytne chyba, zaloguje ji, a nebo vypíše na výstup. V nastavení frameworku v souboru config.neon lze debugovací mód zapnout pomocí následujícího kódu: use Nette \ Diagnostics \ Debugger ; Debugger :: enable (); Při ostrém provozu by ovšem vypisování ladících informací nebylo vhodné, proto lze aplikaci přepnout do produkčního režimu, ve kterém probíhá pouze zapisování chyb do souboru a nikoliv výpis na obrazovku. Po vypnutí ladícího módu uživatel při chybě v aplikaci uvidí pro něj srozumitelnou chybovou hlášku. Použité doplňky: ◇
DatePicker+9 Doplněk rozšiřuje formulářové prvky v aplikaci a umožňuje po kliknutí do textového pole výběr data tím, že se zobrazí kalendář. Po zvolení data se v příslušném formátu propíše do textového pole. Používáme jednoduše tak, že formuláři přiřadíme nový prvek pomocí metody addDatePicker(): $form - > addDatePicker ( ’ datum ’ ); Vytvořil jej český vývojář Jan Tvrdík s použitím jQuery UI a HTML 5.
9. http://addons.nette.org/cs/datepicker-plus
44
4. Implementace systému ◇
VisualPaginator10 Rozšíření umožňuje vytvoření komponenty, která se stará o stránkování při výpisu dat z databáze. Příklad použití: // vytvorime novou instanci tridy // VisualPaginator $vp = new VisualPaginator ( $this , ’ vp ’ ); $paginator = $vp - > getPaginator (); // zvolime pocet polozek na jednu stranku $paginator - > itemsPerPage = 20; // do promenne ulozime celkovy pocet zaznamu $paginator - > itemCount = count ( $this -> prodejRepository - > najdiFiltrovane ( $datum , $stanek , $uzivatel )); // vybereme z databaze pozadovane polozky $prodeje = $this - > prodejRepository -> najdiFiltrovane ( $datum , $stanek , $uzivatel ) - > limit ( $vp - > paginator -> itemsPerPage , $vp - > paginator - > offset ); Autorem doplňku je sám „otec“ frameworku David Grudl.
10. http://addons.nette.org/cs/visualpaginator
45
4. Implementace systému 4.2.2 Struktura aplikace Struktura aplikace je zachována podle doporučované struktury frameworku Nette. app
kořenový adresář obsahující celou aplikaci konfigurační soubory třídy modelové vrstvy třídy vrstvy presenterů továrna na webové adresy šablony definující vzhled stránek zaváděcí soubor libs knihovny, které jsou použity v aplikaci Nette knihovny frameworku DatePicker doplněk pro zadávání data ve formulářích VisualPaginator doplněk ke stránkování výpisů z databáze log chybová hlášení aplikace temp složka pro dočasné soubory test místo pro testy aplikace www veřejně dostupná složka na serveru adminer modul pro správu databáze css kaskádové styly aplikace images složka pro obrázky js místo pro javascript .htaccess konfigurační soubor serveru index.php iniciační skript aplikace config model presenters router templates bootstrap.php
46
4. Implementace systému 4.2.3 Vzhled Vzhled informačního systému je velice důležitý, může totiž ovlivnit například to, zda bude mít internetový obchod nebo reklama úspěch. Bohužel v otázce estetiky jde o čistě subjektivní pohled na věc, takže se grafický návrhář informačního systému nemůže nikdy zavděčit všem. Vzhledem k tomu, že aplikace bude sloužit pouze k interním účelům firmy, nebylo mým cílem se tímto problémem nějak zvlášť zabývat. Vzhled jsem zvolil decentní s tématickým záhlavím typickým pro zadavatelskou firmu s horizontálním menu. Aplikace je na první pohled přehledná a ovládání je intuitivní. Ukázku si můžete prohlédnout na obrázku 4.3
Obrázek 4.3: Ukázka vzhledu webové aplikace 47
4. Implementace systému
4.3
Aplikace pro operační systém Android
Android je operační systém [17] (OS) určen především pro mobilní zařízení, jehož počátky sahají do roku 2003 [18], kdy vznikl startup 11 Android Inc. Ten o dva roky později odkoupila společnost Google Inc. a vyvinula open source platformu založenou na Linuxovém jádře. První zařízení s OS Android se dostala na trh na podzim roku 2008. Android je v dnešní době i díky otevřenému kódu nejrozšířenější OS pro mobilní zařízení vůbec, a to byl také hlavní důvod volby této platformy zadavatelem. Aplikace je možné jednoduše distribuovat a pro instalaci není nutné podstupovat zdlouhavé schvalovací procesy, jak tomu je u některých platforem. Pro vývoj aplikací [19], který kompletně probíhá v programovacím jazyce Java [20], je nutné mít nainstalován JDK (Java Development Kit) a SDK (Software Development Kit) pro Android, což je balíček vývojových nástrojů. Doporučovaným vývojovým prostředím pro tvorbu aplikací je Eclipse IDE [21], který je pro vývoj aplikací OS Android rozšířen o doplněk ADT [22] (Android Development Tools). Tím je zajištěna lepší kompatibilita a přizpůsobení prostředí k vývoji aplikací pro Android. SDK obsahuje také emulátor mobilních zařízení s OS Android, díky kterému je možné testovat aplikaci i bez „fyzického“ mobilního zařízení. Po připojení zařízení s OS Android lze testovat aplikaci také přímo na něm. Aplikace je vytvořena pro minimální level API s hodnotou 8, tedy pro OS Android od verze 2.2 (Froyo12 ), a primárně je přizpůsobena pro tablety s úhlopříčkou displeje od sedmi palců. Aplikaci lze použít i na zařízeních s menší úhlopříčkou, ovšem ovládání bude méně přehledné a méně komfortní. Struktura aplikace obsahuje dva základní stavební kameny. Prvním z nich je Aktivita (třída Activity), kterou můžeme přirovnat k Řadiči nebo Presenteru, jež známe z architektury MVC, resp. MVP, popisované v předchozích částech práce. Získává data z nižších vrstev, předává je na výstup a zajišťuje kompletně prezentační logiku a funkcionalitu aplikace. 11. Nově začínající projekt, který je v rané fázi vývoje, mnohdy ve fázi vytváření podnikatelského záměru s dobrým nápadem a potenciálem. 12. Jednotlivé verze systému se jmenují podle zákusků (Cupcake, Donut, Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich, Jelly Bean).
48
4. Implementace systému Druhým základním prvkem je Pohled (View), který můžeme přirovnat k HTML a jehož hlavní funkcí je zobrazení dat, která zpracovává Aktivita. 4.3.1 Popis aplikace Úkolem aplikace je jednoduché přidávání prodejů do systému, které bude probíhat na prodejních stáncích. Po spuštění aplikace se zobrazí přihlašovací obrazovka a po zadání údajů systém uživatele autentizuje. Po ověření oprávnění k zadávání prodejů uživatel zadá počet požadovaného prodaného zboží, zvolí slevový kupon a prodej uloží. Proces uložení prodeje je detailněji popsán v návrhu aplikace a funguje téměř stejně jako ve webové aplikaci. Z menu aplikace se může uživatel odhlásit nebo uzavřít pokladnu. 4.3.2 Třídy použité v aplikaci Ze všech použitých tříd jsem vybral ty, které jsou pro aplikaci nejdůležitější a plní stěžejní funkce aplikace. ◇
NumberPicker13 Doplňkem je třída NumberPicker, která generuje počítadlo obsahující dvě tlačítka (jedno pro snižování počtu, druhé pro zvyšování) a textové pole zobrazující aktuálně nastavený počet. Počítadlo slouží k zadávání počtu prodaného zboží.
Obrázek 4.4: Ukázka komponenty NumberPicker Autorem je Jeffrey F. Cole.
13. http://codejeff.com/?p=42
49
4. Implementace systému ◇
DefaultHttpClient14 Knihovna umožňující volání HTTP15 požadavků odvádí v aplikaci velmi důležitou práci. S její pomocí mobilní aplikace komunikuje se serverem webové aplikace, kde jsou uložena všechna data, a prostřednictvím PHP skriptů uložených na serveru, které volá, modifikuje data v databázi nebo je získává ve formátu JSON16 . Tato třída je používána pro získání seznamu prodejních stánků na přihlašovací obrazovce, k výpisu zboží prodávaného na daném stánku, ukládání prodejů a zavírání pokladny. Tedy při všech akcích aplikace, které komunikují s databází na serveru.
◇
AsyncTask17 Tato třída umožňuje bezproblémový průběh metod na pozadí mimo hlavní vlákno a nijak tím neomezuje plynulost aplikace. V aplikaci je hojně využívána při načítání a ukládání dat v rámci databáze na serveru. Obsahuje čtyři metody, které můžeme implementovat: onPreExecute() Do této metody umísťujeme příkazy, které se vykonají před průběhem samotného úkolu, který poběží na pozadí. Využívá se např. pro zobrazení indikátoru průběhu (Progress bar). doInBackground(Params...) Sem zapisujeme příkazy, které se mají provést na pozadí mimo hlavní vlákno. Provedou se ihned, jakmile se dokončí metoda onPreExecute(). onProgressUpdate(Progress...) Pomocí této metody je zobrazen aktuální stav průběhu příkazů, které běží na pozadí.
14. http://developer.android.com/reference/org/apache/http/impl/ client/DefaultHttpClient.html 15. Hypertext Transfer Protocol je protokol, který slouží k výměně HTML dokumentů. 16. JavaScript Object Notation je datový formát, který slouží k přenosu informací nezávisle na počítačové platformě, výstupem je vždy textový řetězec. 17. http://developer.android.com/reference/android/os/AsyncTask.html
50
4. Implementace systému onPostExecute(Result) Metoda se vykoná, jakmile skončí výpočty běžící na pozadí. Např. pokud jsme zobrazovali indikátor průběhu, zde jej necháme zmizet. 4.3.3 Struktura aplikace src gen
zdrojové soubory aplikace adresář s vygenerovanou třídou R.java, která obsahuje identifikátory surovin – do této třídy bychom neměli zasahovat assets místo pro datové soubory aplikace libs knihovny, které v aplikaci budeme používat res složka pro suroviny aplikace AndroidManifest.xml soubor obsahující seznam komponent aplikace a jejich nastavení
51
Kapitola 5
Uživatelská příručka 5.1
Přihlášení, odhlášení a změna hesla
Oprávnění uživatelé: Manažer, Provozní, Skladník, Prodejce Přihlášení uživatele probíhá na úvodní obrazovce aplikace, kde uživatel vyplní přihlašovací údaje, a pokud je chce na počítači zapamatovat pro budoucí přihlášení, zaškrtne příslušné tlačítko ve formuláři. Změna hesla je možná po kliknutí na odkaz v menu webové aplikace. Zobrazí se formulář se třemi poli, přičemž v prvním uživatel vyplní původní heslo, ve druhém heslo nové a třetí pole je pro ověření shodnosti nového hesla. Pokud formulář projde validací, nové heslo se uloží a zobrazí se hláška o úspěšné změně hesla. Odhlášení ze systému provede uživatel kliknutím na odkaz Odhlásit se v pravém horním rohu aplikace.
5.2
Evidence
Oprávnění uživatelé: Manažer Po kliknutí na tlačítko Evidence se zobrazí podmenu. V podmenu vybere uživatel sekci, ve které bude editovat údaje. Sekce Uživatelé, Stánky, Dodavatelé, Slevové kupony, Zboží a Ceníky jsou způsobem ovládání téměř totožné, a proto popíši na ukázku pouze evidenci Uživatelů. Po kliknutí na odkaz Uživatelé se zobrazí dva sloupce. V levém jsou informace o všech aktivních uživatelích systému s detaily, pravý sloupec obsahuje formulář pro přidání nového uživatele. Po vyplnění 52
5. Uživatelská příručka
Obrázek 5.1: Ukázka editace uživatele všech polí ve formuláři a po kliknutí na tlačítko Uložit se vytvoří uživatel v systému a vygenerují se přihlašovací údaje, které jsou zaslány na e-mailovou adresu zadanou ve formuláři. Na obrázku 5.1 vidíme obrazovku editace uživatele. Dostaneme se na ni kliknutím na položku uživatele v levém sloupci. Ta se podbarví šedou barvou a do formuláře se propíšou data vybraného uživatele. Dále se zpřístupní zaškrtávací tlačítko pro zaslání nového hesla na email uživatele, které využijeme v případě zapomenutí hesla uživatelem, a tlačítko pro smazání uživatele. Po zadání úprav klikneme na tlačítko Uložit a data o uživateli se tak aktualizují. Na obrazovce se poté zobrazí potvrzující zpráva o úspěšném uložení uživatelských dat. Mírně odlišný způsob evidence je u Výroby, kde ve formuláři vybíráme více zboží a jeho množství, které použijeme při výrobě prodejního zboží. Počet zboží, ze kterého vznikne prodejní zboží je omezen na deset, ale takového počtu se v praxi běžně nedosahuje, proto se nejedná o omezující faktor. Editace již existující výroby probíhá stejně jako v předešlém příkladě. Po kliknutí na položku v levém sloupci se propíší data do formuláře a pro uložení dat klikneme na tlačítko Uložit.
53
5. Uživatelská příručka
5.3
Sklady a přesuny zboží
Oprávnění uživatelé: Manažer, Skladník, Provozní Kliknutím na odkaz Sklady se zobrazí opět dva sloupce. V levém se nachází obsah skladu vybraného stánku (implicitně Hlavní sklad). U každé položky vidíme aktuální množství zboží na stánku, dolní a horní mez. Barva pozadí položky je volena dynamicky podle aktuálního množství zboží na daném stánku. V případě, že je plný stav – množství zboží je rovno nebo větší horní mezi, pozadí má zelenou barvu, při poklesu množství zboží pod hranici dolní meze se pozadí zbarví do červena. Pokud je hodnota mezi horní a dolní mezí barva pozadí koresponduje příslušnému odstínu na přechodu mezi červenou a zelenou barvou. Uživatel má díky barevnému pozadí lepší přehled o množství zboží. Ukázka přesunu zboží je na obrázku 5.2.
Obrázek 5.2: Ukázka přesunu zboží Přesun mezi stánky nebo naskladnění zboží od dodavatelů probíhá v pravém sloupci skrz formulář, ve kterém nejprve zvolíme zdroj pře54
5. Uživatelská příručka sunu obecně (od dodavatele nebo ze stánku), a poté vybereme konkrétního dodavatele nebo stánek. Jestliže vybereme dodavatele, vypíše se zboží, které můžeme naskladnit, v případě přesunu ze stánku se zobrazí aktuální skladová zásoba zdrojového stánku. U každého zboží zadáme množství, které chceme přesunout, a tlačítkem Uložit přesun provedeme. Za cílový stánek se považuje ten, který je vybrán v levém sloupci. Pokud chceme zobrazit přehled všech přesunů, klikneme na příslušný odkaz v menu. V levém sloupci se zobrazí přesuny, které můžeme filtrovat podle dodavatele (resp. zdrojového stánku) a cílového stánku. Po kliknutí na konkrétní přesun se v pravém sloupci zobrazí detaily vybraného přesunu.
5.4
Prodej zboží
Oprávnění uživatelé: Manažer, Provozní, Prodejce V systému existují dva způsoby, jak prodeje zboží přidávat. Více používaným bude bezesporu skrz mobilní aplikaci, která byla vytvořena speciálně pro tento typ úkonu. Systém ale umožňuje přidávat prodeje i přes webovou aplikaci. Vždy je nejprve nutné zahájit směnu na vybraném stánku a otevřít pokladnu. V mobilní aplikaci otevření pokladny proběhne automaticky po přihlášení uživatele, na webu klikneme na záložku Pokladna, vybereme stánek a kliknutím na tlačítko otevřeme pokladnu. Poté se zobrazí ceník daného stánku a uživatel zvolí prodávané zboží, u kterého vyplní počet kusů a případně uplatněný slevový kupon. Po stisknutí tlačítka Zaplatit se prodej uloží a částka se připíše do pokladny. Na konci směny uživatel klikne na tlačítko Zavřít pokladnu v levém sloupci, v mobilní aplikaci je možné uzavřít pokladnu z nabídky. Zobrazí se částka k odvodu a směna se ukončí. Ve webové aplikaci je dostupný přehled prodejů po kliknutí na odkaz z menu, kde můžeme záznamy filtrovat podle data, stánku a uživatele, který prodej zadal. Datum lze zadávat ve formátu „den.měsíc.rok“ nebo „rok-měsíc-den“. Pro provedení filtru stačí zmáčknout klávesu Enter nebo myší kliknout kamkoliv na obrazovku. 55
5. Uživatelská příručka
Obrázek 5.3: Ukázka prodeje zboží v mobilní aplikaci Uživatel v roli Manažera nebo Provozního je oprávněn vybraný prodej smazat.
5.5
Inventura
Oprávnění uživatelé: Manažer, Provozní V sekci Inventury vidí uživatel v levém sloupci jím provedené inventury. Pro provedení inventury vybere v pravém sloupci ze seznamu směnu, kterou bude kontrolovat, a tím se zobrazí aktuální skladová zásoba na stánku, kde byla směna zahájena. Po fyzické kontrole skladu a zjištění rozdílů zadá uživatel chybějící zboží do formuláře a uloží pomocí tlačítka Uložit. Inventura se zaeviduje a chybějící zboží se odečte ze skladové zásoby stánku, aby bylo vše připraveno na zahájení nové směny. Ukázku vidíme na obrázku 5.5. 56
5. Uživatelská příručka
Obrázek 5.4: Ukázka přehledu prodejů ve webové aplikaci
Obrázek 5.5: Ukázka obrazovky při provádění inventury 57
5. Uživatelská příručka V sekci Přehled inventur uživatel vidí všechny provedené inventury, které lze opět filtrovat, tentokráte podle data, stánku, kontrolovaného uživatele (směny) a uživatele, jež inventuru prováděl.
58
Kapitola 6
Závěr Cílem mé práce bylo analyzovat a navrhnout informační systém, který se bude starat o správu skladů a evidenci prodeje firmy zabývající se stánkovým prodejem občerstvení. Nejprve jsem provedl analýzu požadavků na systém, zvolil nástroje pro návrh systému a stručně je popsal. Pomocí těchto nástrojů jsem provedl objektový návrh systému. Výsledkem praktické části jsou dvě aplikace, které byly implementovány na základě vytvořeného návrhu. První z nich je webová aplikace, která má kompletní funkcionalitu a je dostupná z jakéhokoliv webového prohlížeče. Druhá je mobilní aplikace pro operační systém Android, která je určena výhradně pro zadávání prodejů do systému. Obě aplikace jsou plně funkční a splňují požadavky zadavatele. Systém prozatím nebylo možné vyzkoušet v praxi, protože provoz stánků, pro které jsou určeny, probíhá v období před Vánoci. Do té doby je naplánováno dlouhodobé testování obou aplikací. Vzhledem k tomu, že zadavatelská firma nemá s podobným informačním systémem žádné zkušenosti, počítá se, že na základě tohoto testování budou zjištěny nové individuální potřeby a budou přidány nové funkce a rozšíření dle potřeb firmy. Aplikace budou bezesporu velkým přínosem pro zadavatelskou firmu, která doposud fungovala bez pomoci informačních technologií, protože usnadní kontrolu skladů na stáncích a umožní bezproblémovou dodávku zboží ve chvíli, kdy to bude potřeba. Navíc bude systém shromažďovat cenná data o prodaném zboží, která firma využije k plánování a tvorbě strategie pro další prodej zboží.
59
Seznam obrázků 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23
Ukázka značení třídy a případu užití 9 Ukázka značení chování 9 Ukázka značení seskupení – balíčku 10 Ukázka značení poznámky 10 Ukázka značení asociace 10 Ukázka značení závislosti 11 Ukázka značení agregace 11 Ukázka značení kompozice 11 Ukázka značení zobecnění 11 Ukázka značení realizace 12 Ukázka značení ochranné nádoby 12 Hierarchie UML diagramů 13 Symbol aktéra 14 Symbol generalizace mezi aktéry 15 Symbol případu užití 16 Diagram případů užití 17 Ukázka značení třídy 23 Diagram tříd – analytický model 25 Návrhový diagram tříd – evidence 26 Návrhový diagram tříd – přesuny 28 Návrhový diagram tříd – prodeje 30 Návrhový diagram tříd – inventury 31 Entitně-relační diagram 33
4.1 4.2 4.3 4.4
Architektura Model-View-Controller 40 Architektura Model-View-Presenter 42 Ukázka vzhledu webové aplikace 47 Ukázka komponenty NumberPicker 49
5.1 5.2 5.3
Ukázka editace uživatele 53 Ukázka přesunu zboží 54 Ukázka prodeje zboží v mobilní aplikaci 56 60
5.4 5.5
Ukázka přehledu prodejů ve webové aplikaci 57 Ukázka obrazovky při provádění inventury 57
61
Literatura [1] Jaroslav Král. Informační systémy: specifikace, realizace, provoz. Science, 1. vydání edition, 1998. [2] CSc. RNDr. JUDr. Vladimír Šmíd. Studijní materiály k předmětu management informačního systému [online]. Dostupné z: http: //www.fi.muni.cz/~smid/managis.html, [cit. 2013-05-02]. [3] Jim Arlow Ila Neustadt. UML 2 a unifikovaný proces vývoje aplikací. Computer Press, 2. upravené vydání edition, 2007. [4] René Stein. Návrh aplikací v jazyce uml - složitější diagram případů užití [online]. Dostupné z: http://interval.cz/clanky/ navrh-aplikaci-v-jazyce-uml-slozitejsi-diagram-pripadu-uziti/, 2013 [cit. 2013-03-16]. [5] devbook.cz. Uml - class diagram [online]. Dostupné z: http:// www.devbook.cz/uml-class-diagram-tridni-model, 2013 [cit. 2013-03-18]. [6] Ph.D. Ing. RNDr. Barbora Bühnová. Pv167 projekt z objektového návrhu is. Studijní materiály předmětu, 2012. [7] Richard Holowczak Thomas Conolly, Carolyn Begg. Mistrovství – Databáze. Computer Press, 2009. [8] Zdroják. Mvc a další prezentační vzory [online]. Dostupné z: http: //www.zdrojak.cz/clanky/uvod-do-architektury-mvc/, 2009 [cit. 2013-05-14]. [9] Jiří Kosek. PHP tvorba interaktivních internetových aplikací. Grada Publishing, 1999. 62
[10] Oracle Corporation. Mysql, the world’s most popular open source database [online]. Dostupné z: http://www.mysql.com, 2013 [cit. 2013-05-16]. [11] W. Jason Gilmore. Velká kniha PHP 5 a MySQL. Zoner Press, 2011. [12] W3C. Html5 [online]. Dostupné z: http://www.w3.org/TR/ html5/, 2013 [cit. 2013-05-16]. [13] Refsnes Data. Css3 tutorial [online]. Dostupné z: http://www. w3schools.com/css3/, 2013 [cit. 2013-05-16]. [14] The jQuery Foundation. jquery [online]. Dostupné z: http:// jquery.com, 2013 [cit. 2013-05-16]. [15] David Grudl. Rychlý a pohodlný vývoj webových aplikací v php | nette framework [online]. Dostupné z: http://nette.org, 2013 [cit. 2013-05-16]. [16] Nette Foundation. Context-aware escaping [online]. Dostupné z: http://doc.nette.org/cs/templating# toc-context-aware-escaping, 2013 [cit. 2013-05-18]. [17] Ujbányai Miroslav. Programujeme pro Android. Grada, 2012. [18] David Mysliveček. Krátké ohlédnutí za historií androidu [online]. Dostupné z: http://www.svetandroida.cz/ kratke-ohlednuti-za-historii-androidu-201305, 2013 [cit. 2013-05-11]. [19] Mark L. Murphy. Android 2, Průvodce programováním mobilních aplikací. Computer Press, 2011. [20] Oracle Corporation. Java [online]. Dostupné z: http://www.java. com/en/, 2013 [cit. 2013-05-18]. [21] The Eclipse Foundation. Eclipse - the eclipse foundation open source community website. [online]. Dostupné z: http://www. eclipse.org, 2013 [cit. 2013-05-18]. 63
[22] Android Developers. Setting up the adt bundle [online]. Dostupné v anglickém jazyce z: http://developer.android.com/ sdk/installing/bundle.html, 2013 [cit. 2013-05-19].
64
Příloha A
Popis zbývajících případů užití ◇
Přihlášení do systému ID: UC01 Stručný popis: Přihlášení uživatele do systému. Aktéři: Prodejce, Provozní, Skladník, Manažer Vstupní podmínky: Uživatel není přihlášený do systému. Hlavní scénář: 1. 2. 3. 4. 5.
6.
P.U. začíná, když se chce uživatel přihlásit do systému. Systém zobrazí přihlašovací formulář. Uživatel vyplní přihlašovací údaje a odešle formulář. Systém ověří přihlašovací údaje. POKUD jsou přihlašovací údaje správné: (a) Systém zaloguje přihlášení. (b) Systém nastaví práva uživatele. (c) Systém nastaví hodnotu přihlášení na TRUE. JINAK: (a) Systém zobrazí hlášku o chybném přihlášení. (b) Systém zobrazí přihlašovací formulář.
Výstupní podmínky: Užvatel je autentizován a přihlášen do systému, hodnota přihlášení je TRUE. ◇
Odhlášení ze systému ID: UC02 Stručný popis: Odhlášení uživatele ze systému. 65
A. Popis zbývajících případů užití Aktéři: Prodejce, Provozní, Skladník, Manažer Vstupní podmínky: Uživatel je přihlášen do systému. Hlavní scénář: 1. 2. 3. 4. 5.
P.U. začíná, když se chce uživatel odhlásit ze systému. Uživatel klikne na tlačítko pro odhlášení ze systému. Systém zaloguje odhlášení uživatele ze systému. Systém nastaví hodnotu přihlášení na FALSE. Systém zobrazí přihlašovací formulář.
Výstupní podmínky: Uživatel je odhlášen ze systému, hodnota přihlášení je FALSE. ◇
Zadání chybějícího zboží ID: UC05 Stručný popis: Uživatel zadává do systému chybějící zboží na konci směny. Aktéři: Provozní, Manažer Vstupní podmínky: Uživatel je přihlášen do systému, pokladna kontrolované směny je uzavřena. Hlavní scénář: 1. 2. 3. 4. 5. 6. 7.
P.U. začíná, když uživatel klikne na odkaz Inventura. Uživatel zvolí požadovanou směnu, kterou bude kontrolovat. INCLUDE (Vyhledání zboží). Systém zobrazí formulář s dostupným zbožím. Uživatel zadá požadované chybějící zboží a množství. Systém uloží chybějící zboží do databáze. Systém odečte ze skladu stánku zboží, které chybí.
Výstupní podmínky: Chybějící zboží je uloženo v databázi. ◇
Příjem zboží od dodavatelů ID: UC08 66
A. Popis zbývajících případů užití Stručný popis: Uživatel přijímá a naskladňuje zboží od dodavatelů. Aktéři: Skladník, Manažer, Provozní Vstupní podmínky: Uživatel je přihlášen do systému. Hlavní scénář: 1. 2. 3. 4. 5. 6. 7. 8. 9.
P.U. začíná, když uživatel klikne na odkaz Sklady. INCLUDE (Vyhledání zboží). Systém zobrazí dostupné zboží na stánku ve formuláři. Uživatel zvolí dodavatele jako zdroj. INCLUDE (Vyhledání zboží). Systém zobrazí dostupné zboží, které je možné naskladnit. Uživatel vybere zboží a jeho množství k naskladnění. Systém uloží naskladněné zboží do databáze. Systém přičte naskladněné množství zboží na sklad cílového stánku.
Výstupní podmínky: Požadované zboží je naskladněno a uloženo v databázi. ◇
Smazání prodeje ID: UC10 Stručný popis: Uživatel smaže prodej, který předtím prodejce zadal do systému. Aktéři: Provozní, Manažer Vstupní podmínky: Uživatel je přihlášen do systému, prodej je uložen v databázi. Hlavní scénář: 1. 2. 3.
P.U. začíná, když uživatel klikne na tlačítko Smazat Systém se zeptá, jestli chceme prodej skutečně smazat. POKUD uživatel akci potvrdí: (a) INCLUDE (Vyhledání zboží). (b) Systém smaže daný prodej z databáze a vrátí se na úvodní obrazovku. 67
A. Popis zbývajících případů užití 4.
JINAK: (a) Systém se vrátí na úvodní obrazovku.
Výstupní podmínky: Prodej bude smazán z databáze a zobrazena úvodní obrazovka nebo jen zobrazena úvodní obrazovka. ◇
Evidence ceníků ID: UC11 Stručný popis: Manažer eviduje ceníky stánků. Aktéři: Manažer Vstupní podmínky: Manažer je přihlášen do systému. Hlavní scénář: 1. 2. 3. 4. 5. 6.
P.U. začíná, když Manažer klikne na odkaz Evidence ceníků. Systém vyhledá seznam všech ceníků. KDYŽ Manažer klikne na vybranou položku ceníku: (a) Systém vyhledá daný ceník a zobrazí údaje o něm. Systém zobrazí formulář pro editaci údajů o ceně zboží. Uživatel vyplní údaje o ceně zboží a odešle formulář. Systém uloží údaje o ceně zboží do databáze.
Výstupní podmínky: Údaje o ceně zboží jsou uloženy v databázi. ◇
Evidence dodavatelů ID: UC12 Stručný popis: Manažer eviduje seznam dodavatelů. Aktéři: Manažer Vstupní podmínky: Manažer je přihlášen do systému. Hlavní scénář: 1. 2.
P.U. začíná, když Manažer klikne na odkaz Evidence dodavatelů. Systém vyhledá seznam všech dodavatelů. 68
A. Popis zbývajících případů užití 3.
4. 5. 6.
KDYŽ Manažer klikne na vybraného dodavatele: (a) Systém vyhledá daného dodavatele a zobrazí údaje o něm. Systém zobrazí formulář pro úpravu/vložení údajů. Manažer upraví/vloží údaje o dodavateli a odešle formulář. Systém uloží údaje o dodavateli do databáze.
Výstupní podmínky: Údaje o dodavateli jsou uloženy v databázi. ◇
Evidence stánků ID: UC15 Stručný popis: Manažer eviduje seznam stánků. Aktéři: Manažer Vstupní podmínky: Manažer je přihlášen do systému. Hlavní scénář: 1. 2. 3. 4. 5. 6.
P.U. začíná, když Manažer klikne na odkaz Evidence stánků. Systém vyhledá seznam všech stánků. KDYŽ Manažer klikne na vybraný stánek: (a) Systém vyhledá daný stánek a zobrazí údaje o něm. Systém zobrazí formulář pro úpravu/vložení údajů. Manažer upraví/vloží údaje o stánků a odešle formulář. Systém uloží údaje o stánku do databáze.
Výstupní podmínky: Údaje o stánku jsou uloženy v databázi. ◇
Evidence slevových kuponů ID: UC16 Stručný popis: Manažer eviduje seznam slevových kuponů. Aktéři: Manažer Vstupní podmínky: Manažer je přihlášen do systému. Hlavní scénář: 69
A. Popis zbývajících případů užití 1. 2. 3.
4. 5. 6.
P.U. začíná, když Manažer klikne na odkaz Evidence slevových kuponů. Systém vyhledá seznam všech slevových kuponů. KDYŽ Manažer klikne na vybraný slevový kupon: (a) Systém vyhledá daný slevový kupon a zobrazí údaje o něm. Systém zobrazí formulář pro úpravu/vložení údajů. Manažer upraví/vloží údaje o slevovém kuponu a odešle formulář. Systém uloží údaje o slevovém kuponu do databáze.
Výstupní podmínky: Údaje o slevovém kuponu jsou uloženy v databázi. ◇
Uzavření pokladny ID: UC17b Stručný popis: Uživatel uzavírá pokladnu na stánku. Aktéři: Manažer, Provozní, Prodejce Vstupní podmínky: Uživatel je přihlášen do systému a má otevřenou pokladnu. Hlavní scénář: 1. 2. 3.
P.U. začíná, když Uživatel klikne na odkaz Uzavřít pokladnu. Systém ukončí směnu a uzavře pokladnu pro Uživatele na daném stánku. Systém spočítá celkovou tržbu Uživatele na stánku a zobrazí ji na výstup.
Výstupní podmínky: Uživatel má na daném stánku uzavřenou pokladnu a výše tržby je zobrazena na výstupu. ◇
Změna hesla ID: UC18 Stručný popis: Uživatel si mění heslo. Aktéři: Manažer, Provozní, Prodejce, Skladník 70
A. Popis zbývajících případů užití Vstupní podmínky: Uživatel je přihlášen do systému. Hlavní scénář: 1. 2. 3. 4.
5.
P.U. začíná, když Uživatel klikne na odkaz Změna hesla. Systém zobrazí formulář pro změnu hesla. Uživatel vyplní původní heslo, nové heslo a potvrzení nového hesla. POKUD původní heslo souhlasí: (a) POKUD nové heslo odpovídá potvrzení nového hesla: i. Systém změní heslo uživatele. (b) JINAK: i. Systém vypíše chybovou hlášku a zobrazí se formulář pro změnu hesla. JINAK: (a) Systém vypíše chybovou hlášku a zobrazí se formulář pro změnu hesla.
Výstupní podmínky: Uživatel má na daném stánku uzavřenou pokladnu a výše tržby je zobrazena na výstupu.
71
Příloha B
Obsah přiloženého CD ◇
Zdrojové kódy webové aplikace (web.zip)
◇
Zdrojové kódy mobilní aplikace pro Android (android.zip)
◇
Instalační soubor mobilní aplikace pro Android (turbosystem.apk)
◇
MySQL databáze potřebná k fungování systému (databaze.sql.zip)
72
