}w!"#$%&'()+,-./02345<ya 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 203
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 Informační systémy...................... 2. Pojem informačního systému................ 2 2 Systém a analýza jeho požadavků............. 3 2. Princip systému....................... 3 2.2 Specifikace požadavků................... 4 2.2. Funkční požadavky na systém........... 4 2.2.2 Nefunkční požadavky na systém.......... 7 3 Použité nástroje, analýza a návrh systému........ 8 3. UML............................. 8 3.. Co je UML a k čemu se používá.......... 8 3..2 Historie a vznik UML................ 8 3..3 Struktura jazyka.................. 9 Předměty...................... 9 Relace........................ 0 Diagramy...................... 2 3.2 Diagram případů užití................... 4 3.2. Hranice systému.................. 4 3.2.2 Aktéři........................ 4 3.2.3 Případy užití.................... 6 3.3 Diagram tříd........................ 22 3.3. Třídy......................... 22 3.3.2 Vztahy........................ 23 3.3.3 Analytický model.................. 24 3.3.4 Návrhový model.................. 24 Evidence...................... 24 Přesuny zboží................... 27 Prodeje....................... 29 Inventury...................... 29 3.4 Datový model........................ 32 3.4. ERD......................... 32 vi
4 Implementace systému.................... 39 4. Model-View-Controller architektura............ 39 4.2 Webová aplikace...................... 4 4.2. Nette framework.................. 4 4.2.2 Struktura aplikace................. 46 4.2.3 Vzhled........................ 47 4.3 Aplikace pro operační systém Android.......... 48 4.3. Popis aplikace.................... 49 4.3.2 Třídy použité v aplikaci.............. 49 4.3.3 Struktura aplikace................. 5 5 Uživatelská příručka...................... 52 5. Přihlášení, odhlášení a změna hesla............ 52 5.2 Evidence........................... 52 5.3 Sklady a přesuny zboží................... 54 5.4 Prodej zboží......................... 55 5.5 Inventura.......................... 56 6 Závěr............................... 59 A Popis zbývajících případů užití............... 65 B Obsah přiloženého CD.................... 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.
Kapitola Informační systémy Informační systémy [] 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ě.. 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. 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. Funkční požadavky na systém. 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
0. Evidence ceníků 2. Systém a analýza jeho požadavků 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.. 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. 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. UML 3.. 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..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 994 metodika Fusion, která ale nebyla úspěšná, přestože byla velmi propagována. Až v roce 997 se podařilo firmě Rational Software sjednotit metodiky, vytvořit jazyk UML a docílit toho, aby jej sdružení OMG (Object Management Group) přijalo jako historicky první standard objektově orientovaného jazyka. 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..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.: 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 0
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í;
3. Použité nástroje, analýza a návrh systému Obrázek 3.0: Ukázka značení realizace ochranná nádoba (Containment) ukazuje vztah, kdy zdrojový prvek zahrnuje cílový prvek. Obrázek 3.: 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.2. 2
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 chování Diagram tříd Diagram komponent Objektový diagram Diagram případů užití Stavový diagram Diagram složené struktury Diagram balíčku Diagram nasazení Diagram interakce Diagram aktivit Diagram posloupnosti Diagram komunikace Diagram časování Stručný diagram interakce Obrázek 3.2: Hierarchie UML diagramů 3
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.6, 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. 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.3: Symbol aktéra 4
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.4: 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. 5
3.2.3 Případy užití 3. Použité nástroje, analýza a návrh systému 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.5: 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ží. 6
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 Prodejce Otevření a uzavření pokladny <<Extend>> Zadání prodeje Změna hesla <<Extend>> extension points Otevření a uzavření pokladny Zaslání upozornění <<Include>> Smazání prodeje Zaslání upozornění <<Include>> e-mail Příjem zboží od dodavatelů Skladník Provozní <<Extend>> Smazání prodeje <<Include>> Zadání chybějícího zboží Vyhledání zboží <<Include>> Přesun zboží <<Include>> Manažer <<Include>> Evidence ceníků Evidence zboží a výrobních postupů Manažer Evidence dodavatelů Evidence stánků Evidence uživatelů a jejich pozic Evidence slevových kuponů Obrázek 3.6: Diagram případů užití 7
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ář:. Uživatel zadá identifikátor zboží. 2. 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ář:. P.U. začíná, když uživatel klikne na odkaz Pokladna. 2. 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. 3. INCLUDE (Vyhledání zboží). 4. Systém zobrazí celkovou cenu prodeje. 5. Systém uloží prodej do databáze. 6. Systém odečte ze skladu stánku zboží, které bylo prodáno. 7. Systém zobrazí seznam nabízeného zboží. 8
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ář:. P.U. začíná, pokud uživatel klikne na odkaz Sklady. 2. Systém vyhledá a zobrazí seznam stánků ve formuláři. 3. Uživatel vybere zdrojový stánek, odkud bude přesouvat zboží. 4. INCLUDE (Vyhledání zboží), které se nachází na zdrojovém stánku. 5. Uživatel vybere požadované zboží a jeho množství k přesunu. 6. Uživatel zvolí cílový stánek, kam se bude zboží přesouvat a odešle formulář. 7. INCLUDE (Vyhledání zboží), které se nachází na cílovém stánku. 8. 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í. 9
3. Použité nástroje, analýza a návrh systému Hlavní scénář:. P.U. začíná, pokud se množství některého zboží na stánku dostane pod stanovenou mez. 2. 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: UC3 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ář:. P.U. začíná, když Manažer klikne na odkaz Evidence uživatelů. 2. Systém vyhledá seznam všech uživatelů systému. 3. KDYŽ Manažer klikne na vybraného uživatele: (a) Systém vyhledá daného uživatele a zobrazí údaje o něm. 4. Systém zobrazí formulář pro úpravu/vložení údajů. 5. Manažer upraví/vloží údaje o uživateli a odešle formulář. 6. 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: UC4 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ář:. P.U. začíná, když Manažer klikne na odkaz Výroba. 2. Systém vyhledá seznam všeho zboží. 3. KDYŽ Manažer klikne na vybrané zboží: (a) INCLUDE (Vyhledání zboží). (b) Systém zobrazí údaje o výrobě. 4. Systém zobrazí formulář pro úpravu/vložení údajů. 5. Manažer upraví/vloží údaje o zboží a odešle formulář. 6. 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: UC7a 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ář:. P.U. začíná, když Uživatel vybere stánek a klikne na odkaz Otevřít pokladnu. 2. Systém zahájí směnu a otevře pokladnu pro Uživatele na daném stánku. 3. 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. 2
3.3 Diagram tříd 3. Použité nástroje, analýza a návrh systému Diagram tříd (Class diagram) je statický diagram [5], který ukazuje pohled na systém. Můžeme jej rozdělit do tří úrovní:. 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. 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 Nexus 2, 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 IMEI 3 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.7: 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..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.8 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.9 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 vytvoří Prodej -datum : Timestamp obsahuje 0.. Provozni SlevovyKupon -nazev_slevovy_kupon : String -procento : Integer provádí eviduje Skladnik přeskladňuje Zbozi -nazev_zbozi : String -popis : String -jednotka : Jednotka Inventura -datum : Timestamp 0.. obsahuje eviduje obsahuje ChybejiciZbozi -mnozstvi : Float Manazer dodává eviduje eviduje eviduje Stanek -nazev_stanek : String -typ_stanku : TypStanku obsahuje Cenik -platnost_od : Timestamp -platnost_do : Timestamp -cena : Integer..* 0.. Dodavatel -nazevdodavatel : String -ic : Integer -dic : String -telefon : String -email : String má adresu Sklad eviduje má ProdejniStanek Adresa -ulice : String -cislo_popisne : String -cislo_orientacni : String -mesto : String -psc : String -stat : String Obrázek 3.8: 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 +createuzivatel(jmeno : String,... +updateuzivatel(jmeno : String... +createmapozici(pozice : Pozic... +updatemapozici(pozice : Pozi... +setheslo(heslo : String) +newheslo(email : String) má pozici Pozice -nazev_pozice : String SlevovyKupon -nazev_slevovy_kupon :... -procento : Integer +createslevovykupon(n... +updateslevovykupon(... TypStanku -nazev_typ_stanku : String Stanek -nazev_stanek : String -attribute : TypStanku +createstanek(nazev : String,... +updatestanek(nazev : String... je typu Dodavatel -nazevdodavatel : String -ic : Integer -dic : String -telefon : String -email : String -adresa : Adresa +createdodavatel(adresa : A... +updatedodavatel(adresa : A... eviduje eviduje eviduje ProdejniStanek Sklad Zbozi -nazev_zbozi : String -popis : String -jednotka : Jednotka +createzbozi(nazev : St... +updatezbozi(nazev : S... eviduje eviduje Manazer eviduje eviduje má Cenik -platnost_od : Timestamp -platnost_do : Timestamp -cena : Integer +createcenik(stanek : Sta... +updatecenik(stanek : St... má adresu je použito Adresa -ulice : String -cislo_popisne : String -cislo_orientacni : String -mesto : String -psc : String -stat : String +createadresa(ulice : String, cp :... +updateadresa(ulice : String, cp... Vyroba -platnost_od : Timestamp -platnost_do : Timestamp -mnozstvi : Float +createvyroba(prodzbozi :... +updatevyroba(prodzbozi... je součástí..* ProdejniZbozi -nazev_prodejni_zbozi : String je -popis : String vyrobeno +createprodejnizbozi(nazev :... +updateprodejnizbozi(nazev... Obrázek 3.9: 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: dm = pds, hm = 2 pds, (3.) 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 +createuzivatel(jmeno : Strin... +updateuzivatel(jmeno : Stri... +createmapozici(pozice : Poz... +updatemapozici(pozice : Po... +setheslo(heslo : String) +newheslo(email : String) Skladnik má pozici Pozice -nazev_pozice : String Manazer Provozni provádí TypStanku -nazev_typ_stanku : String Stanek -nazev_stanek : String -attribute : TypStanku +createstanek(nazev : String, t... +updatestanek(nazev : String,... 0.. je typu ze stánku na stánek má Dodavatel -nazevdodavatel : String -ic : Integer -dic : String -telefon : String -email : String -adresa : Adresa +createdodavatel(adresa : A... +updatedodavatel(adresa : A... provádí 0.. Presun -datum : Timestamp obsahuje -dodavatel : Dodavatel -z_stanek : Stanek -do_stanek : Stanek +createpresun(dodavatel... SkladovaZasoba -mnozstvi : Float -datum : Timestamp -dolni_mez : Float -horni_mez : Float +createskladovazasoba(zb... +presunzbozi(zbozi : Zboz... +odectiskladovazasoba(zb... má adresu Adresa -ulice : String -cislo_popisne : String -cislo_orientacni : String -mesto : String -psc : String -stat : String +createadresa(ulice : String, cp :... +updateadresa(ulice : String, cp... obsahuje PolozkaPresunu -mnozstvi : Float -zbozi : Zbozi +createpolozkapresunu(zb... je obsaženo je obsaženo Zbozi -nazev_zbozi : String -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.2 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 +createuzivatel(jmeno : Strin... +updateuzivatel(jmeno : Stri... +createmapozici(pozice : Poz... +updatemapozici(pozice : Po... +setheslo(heslo : String) +newheslo(email : String) Manazer Provozni TypStanku -nazev_typ_stanku : String je typu Stanek -nazev_stanek : String -attribute : TypStanku +createstanek(nazev : String, t... +updatestanek(nazev : String,... má pozici Prodejce Pozice -nazev_pozice : String Prodej -datum : Timestamp +createprodej(smena :... +deleteprodej() obsahuje vytvoří zahájí pracuje na Smena -prihlaseni : Timestamp -odhlaseni : Timestamp -trzba : Float +createsmena(uzivatel :... +openpokladna() +closesmena() obsahuje ProdejniStanek má Cenik -platnost_od : Timestamp -platnost_do : Timestamp -cena : Integer +createcenik(stanek : Stanek, pr... +updatecenik(stanek : Stanek, p... PolozkaProdej -kusy : Integer +createpolozkaprodeje(prodej :... +deletepolozkaprodeje() je uplatněn 0.. SlevovyKupon -nazev_slevovy_kupon : String -procento : Integer +createslevovykupon(nazev : String,... +updateslevovykupon(nazev : String... Obrázek 3.2: 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 +createuzivatel(jmeno : String,... +updateuzivatel(jmeno : String... +createmapozici(pozice : Pozic... +updatemapozici(pozice : Pozi... +setheslo(heslo : String) +newheslo(email : String) má pozici Manazer Provozni provádí je kontrolována Smena -prihlaseni : Timestamp -odhlaseni : Timestamp -trzba : Float +createsmena(uzivatel : Uzivatel, s... +openpokladna() +closesmena() pracuje na ProdejniStanek Pozice -nazev_pozice : String Inventura -datum : Timestamp -provadel : Uzivatel -smena : Smena +createinventura(smena : Sme... ChybejiciZbozi -mnozstvi : Float -zbozi : Zbozi +createchybejicizbozi(inventur... Zbozi -nazev_zbozi : String -popis : String -jednotka : Jednotka 0.. +createzbozi(nazev : String... +updatezbozi(nazev : Strin... obsahuje SkladovaZasoba -mnozstvi : Float -datum : Timestamp -dolni_mez : Float -horni_mez : Float +createskladovazasoba(zbozi :... je obsaženo+presunzbozi(zbozi : Zbozi, z... +odectiskladovazasoba(zbozi :... Stanek -nazev_stanek : String -attribute : TypStanku +createstanek(nazev : String, t... +updatestanek(nazev : String,... má je typu TypStanku -nazev_typ_stanku : String Obrázek 3.22: Návrhový diagram tříd inventury 3
3.4 Datový model 3.4. ERD 3. Použité nástroje, analýza a návrh systému 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 id_typ_stanku integer(4) nazev_typ_stanku varchar(6) typ_stanku id_stanek integer(4) id_typ_stanku integer(4) nazev_stanek varchar(64) stanek id_jednotka varchar(8) nazev_jednotka varchar(64) jednotka id_zbozi integer(4) id_jednotka varchar(8) nazev_zbozi varchar(64) popis clob zbozi id_cenik integer(4) id_stanek integer(4) id_prodejni_zbozi integer(4) platnost_od timestamp platnost_do timestamp cena integer(8) cenik id_vyroba integer(8) id_prodejni_zbozi integer(4) id_zbozi integer(4) platnost_od timestamp platnost_do timestamp mnozstvi float vyroba id_adresa integer(8) ulice varchar(64) cislo_popisne varchar(8) cislo_orientacni varchar(8) mesto varchar(64) psc varchar(6) stat varchar(64) adresa id_dodavatel integer(4) id_adresa integer(8) nazev_dodavatel varchar(64) ico integer(6) dic varchar(6) telefon varchar(6) email varchar(64) dodavatel id_presun integer(8) id_uzivatel integer(4) id_dodavatel integer(4) z_id_stanek integer(4) do_id_stanek integer(4) datum timestamp presun id_presun integer(8) id_zbozi integer(4) mnozstvi float polozka_presunu id_uzivatel integer(4) jmeno varchar(32) login varchar(6) heslo varchar(256) email varchar(64) uzivatel id_smena integer(8) id_uzivatel integer(4) id_stanek integer(4) prihlaseni timestamp odhlaseni timestamp trzba float smena id_prodej integer(8) id_smena integer(8) datum timestamp prodej id_pozice integer(4) nazev_pozice varchar(32) pozice id_ma_pozici integer(8) id_uzivatel integer(4) id_pozice integer(4) pozice_od timestamp pozice_do timestamp ma_pozici id_slevovy_kupon integer(4) nazev_slevovy_kupon varchar(32) procento integer(4) slevovy_kupon id_prodej integer(8) id_cenik integer(4) id_slevovy_kupon integer(4) kusy integer(4) polozka_prodeje id_smena integer(8) id_uzivatel integer(4) datum timestamp inventura id_smena integer(8) id_zbozi integer(4) mnozstvi float chybejici_zbozi id_skladova_zasoba integer(8) id_zbozi integer(4) id_stanek integer(4) mnozstvi float datum timestamp dolni_mez float horni_mez float skladova_zasoba id_prodejni_zbozi integer(4) nazev_prodejni_zbozi varchar(64) popis clob prodejni_zbozi Visual Paradigm for UML Community Edition [not for commercial use] Obrázek 3.23: Entitně-relační diagram 33
Popis entitních množin: 3. Použité nástroje, analýza a návrh systému 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 hash 4 ). 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ČO 5, 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