Objednávkový systém. Jan Tichý

České vysoké učení technické v Praze Fakulta elektrotechnická

Bakalářská práce

Objednávkový systém Jan Tichý

Vedoucí práce: Ing. Michal Voráček

Studijní program: Elektrotechnika a informatika strukturovaný a bakalářský Obor: Informatika a výpočetní technika leden 2008

ii

Poděkování: Rád bych poděkoval vedoucímu mé bakalářské ing. Michalu Voráčkovi za věcné připomínky, rady a odborné vedení. Dále bych rád poděkoval zaměstnancům společnosti Veolia Voda východní Čechy a.s. za trpělivou spolupráci a vstřícnost.

iii

iv

Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonu (autorský zákon).

V Praze dne 3. ledna 2008

v

Abstract The thesis presents a system for processing and managing orders in middle-sized company. The thesis deals with analysis, design and implementation of the system.

Abstrakt Práce prezentuje systém pro správu objednávek určený k nasazení ve středně velikých firmách. Práce se zabývá analýzou, návrhem a implementaci systému.

vi

vii

Obsah 1. Úvod ................................................................................................................................ 1 1.1 Cíl bakalářské práce ................................................................................................. 1 1.2 Struktura bakalářské práce ....................................................................................... 1 1.3 Účel bakalářské práce .............................................................................................. 2 2. Požadavky na systém ...................................................................................................... 3 2.1 Členění uživatelů ...................................................................................................... 3 2.2 Vytváření a schvalování objednávek ....................................................................... 3 2.2.1 Nová objednávka .............................................................................................. 4 2.2.2 Schvalování objednávek ................................................................................... 4 2.3 Systém práv .............................................................................................................. 5 2.4 Výstup objednávek ze systému ................................................................................ 6 2.4.1 Tisková sestava objednávky ............................................................................. 6 2.5 Zatížení systému ....................................................................................................... 8 2.6 Požadavky na technologie ........................................................................................ 8 3. Analýza a návrh řešení .................................................................................................... 9 3.1 Případ užití systému ................................................................................................. 9 3.2 Scénáře případů použití .......................................................................................... 11 3.2.1 Scénáře zaměstnanec ...................................................................................... 12 3.2.2 Scénáře technika (technický schvalovatel) ..................................................... 13 3.2.3 Scénáře schvalovatele ..................................................................................... 13 3.2.4 Scénáře řešitele ............................................................................................... 13 3.2.5 Scénáře administrátora ................................................................................... 14 3.2.6 Diagram schvalování objednávky .................................................................. 15 3.3 Dynamický model .................................................................................................. 18 3.3.1 Stavové diagramy ........................................................................................... 18 3.4 Konceptuální model ............................................................................................... 25 3.5 Architektura ............................................................................................................ 26 3.5.1 Databázová vrstva........................................................................................... 27 3.5.2 Aplikační vrstva .............................................................................................. 27 3.5.3 Prezentační vrstva ........................................................................................... 28 3.5.4 Architektura systému ...................................................................................... 28 4. Implementace ................................................................................................................ 30 4.1 Popis implementace ............................................................................................... 30 4.2 Logický datový model............................................................................................ 30 4.2.1 Návrh logického datového modelu ................................................................. 30

viii

5.

6. 8.

9.

4.2.2 Datový slovník ................................................................................................ 33 4.3 Vstupní pole ........................................................................................................... 39 4.3.1 Entita zaměstnanec ......................................................................................... 40 4.3.2 Entita objednávka ........................................................................................... 40 4.3.3 Entita kategorie ............................................................................................... 41 4.3.4 Entita dodavatelé ............................................................................................ 42 4.3.5 Entita oddělení ................................................................................................ 43 4.3.6 Entita událostí ................................................................................................. 43 4.4 Struktury souborů ................................................................................................... 44 4.5 Ověření uživatele ................................................................................................... 46 4.6 Instalace systému na server .................................................................................... 47 4.6.1 Požadavky na server ....................................................................................... 47 4.6.2 Instalace .......................................................................................................... 48 Testování ....................................................................................................................... 50 5.1 Funkční testy .......................................................................................................... 50 5.1.1 Black-box testování ........................................................................................ 50 5.2 Testování bezpečnosti ............................................................................................ 51 5.3 Uživatelské rozhraní ............................................................................................... 51 Závěr.............................................................................................................................. 53 Seznam obrázků a tabulek ............................................................................................. 55 8.1 Seznam obrázků ..................................................................................................... 55 8.2 Seznam tabulek ...................................................................................................... 55 Přílohy ........................................................................................................................... 57 9.1 Obsah přiloženého CD ........................................................................................... 57 9.2 Ilustrační obrázky ................................................................................................... 58

ix

1. Úvod

1. Úvod 1.1 Cíl bakalářské práce Cílem této bakalářské práce je navrhnout a implementovat Objednávkový systém pro středně velkou firmu sloužící k vytváření, schvalování a správě objednávek. V systému budou udržovány informace o zaměstnancích, odděleních, dodavatelích a stavech objednávek. Ke každé bude možné připojit soubory a krátký komentář. Většina operací manipulující s objednávkou bude logována. Schválenou objednávku bude možno vyexportovat do PDF dokumentu, vytisknout anebo odeslat dodavateli ve formě e-mailové přílohy.

1.2 Struktura bakalářské práce Bakalářská práce je členěna do devíti kapitol, kterým předchází obsah práce. Kapitola č. 1 Úvod, popisuje cíle, strukturu a problém, který tato bakalářská práce řeší. Kapitola č. 2 Požadavky na systém, definuje požadavky na systém. Podrobně popisuje jednotlivé požadavky a rozvíjí tak zadání práce. Kapitola č. 3 Analýza a návrh řešení, postupně analyzuje zadaný problém a předkládá návrh řešení z analytického pohledu. Kapitola č. 4. Implementace, popisuje naplnění a realizaci systému. Kapitola č. 5 Testování, se zabývá testováním funkčnosti systému. Především popisuje typy a způsoby prováděných testů. Kapitola č. 6 Závěr, je hodnocením výsledku a poznatků z bakalářské práce. Kapitola č. 7 Použitá literatura, obsahuje seznam použité literatury. Kapitola č. 8 Seznam obrázků a tabulek, je tvořena obsahem všech obrázku a kapitol použitých v této práci. Kapitola č. 9 Přílohy, je doplňující kapitola obsahující informace o přiloženém CD a ilustračních obrázcích.

1

1. Úvod

1.3 Účel bakalářské práce Nadnárodní společnost Veolia Voda východní Čechy působí na českém trhu, jako dodavatel a distributor pitné vody. Dále odvádí a čistí odpadní vodu. Společnost projevila zájem o naprogramování zcela nového systému na správu a schvalování objednávek tvořených zaměstnanci. K tomuto kroku byla donucena z důvodu zpřehlednění zadávání objednávek zaměstnanci a jejich schvalování, což nebylo do této doby ve společnosti pevně stanoveno a řešeno. Zaměstnanci, již zadávají objednávky na zboží a služby nezbytné pro chod společnosti jsou děleny do dané hierarchie. Na nejvyšším postu působí generální ředitel, dále ředitelé, vedoucí a na konci žebříčku řadoví zaměstnanci. Podle finanční výše objednávky by mělo probíhat schvalování objednávky na různých postech hierarchie. Za tímto účelem byl vznesen požadavek na systém, který donutí každého zaměstnance ve společnosti dodržovat stanovená pravidla ohledně vytváření a schvalování objednávek, včetně transparentnosti schvalovacího procesu. Od systému bude také očekávána přehledná historie objednávek na každé oddělení v podniku, či zaměstnance a sjednocená grafická forma generovaných objednávek.

2

2. Požadavky na systém

2. Požadavky na systém Tato kapitola obsahuje požadavky na objednávkový systém. V níže uvedených podkapitolách je uveden jejich detailní seznam. Hlavním úkolem systému je umožnit každému zaměstnanci firmy, na základě přidělených práv v rámci systému, vytvářet objednávky. Tzn., že uživatelé budou vytvářet objednávky, které techničtí schvalovatelé, vedoucí a případně ředitelé budou schvalovat. Úspěšně schválenou objednávku dostane na starosti řešitel, jenž zajistí její realizaci u dodavatelské firmy. K tomuto využije možnosti vygenerování objednávky do PDF dokumentu. Po realizaci řešitel objednávku prohlásí za dokončenou a systém ji přesune do sekce dokončených objednávek. V případě neschválení objednávky, je objednávka přesunuta mezi dokončené s atributem neschválená. Procesy vytváření objednávky, schvalování, generování objednávky a další se budou zaznamenávat ke každé objednávce ve formě textových záznamů o události.

2.1 Členění uživatelů Uživatelé bude v systému potřeba dělit do podobné hierarchie, jako je nastolená ve společnosti. Každý uživatel bude muset být zařazen v jednom oddělení, ale zároveň mu může být přidělen vedoucí post. Vedoucí posty se vztahují na oddělení a dělí se na nižší – vedoucí a vyšší – ředitel. Uživateli lze přidělit libovolný počet vedoucích a ředitelských pozic. Každé oddělení musí mít svého vedoucího a ředitele, tak jako tomu je ve společnosti. Rozdělení pozic bude mít v systému vliv na schvalovací proces viz. 2.2.2.

2.2 Vytváření a schvalování objednávek Podstatou Objednávkového systému je vytváření viz. 2.2.1 a schvalování viz. 2.2.2 objednávek pro nákup zboží a služeb pro potřebu společnosti. Tzn., že zaměstnanci mající zá-

3


jem o nákup prostředku, musí vytvořit objednávku, která projde schvalovacím řízením uvnitř společnosti, a v případě schválení objednávku realizovat.

2.2.1 Nová objednávka Při vytváření nové objednávky budou muset být vyplněny nebo vybrány následující atributy nutné pro schvalování: Název objednávky, stručně vypovídá a o jejím obsahu. Vybrání typu/kategorie viz 2.3 objednávky na základě jejího obsahu. Podle kategorie se bude rozhodovat schvalovací algoritmus viz. 2.2.2. Nastavit zda chce být zadavatel informován formou upozorňovacích e-mailů o průběhu schvalování objednávky Zadat libovolné množství položek objednávky. Položky musí obsahovat množství a název zboží nebo služby. Volitelně lze doplnit jednotku a předběžnou cenu. Možnost uvést poznámku pro schvalovatele nebo dodavatele. Formulář otestuje veškerá vstupní data zadána uživatelem a v případě chyby zobrazí hlášku, která zabrání v pokračování. Po úspěšném vyplnění formuláře, systém uloží objednávku a předá ji ke schvalovacímu procesu viz. 2.2.2.

2.2.2 Schvalování objednávek S nově vytvořenou objednávkou začne pracovat algoritmus schvalování. Schvalování se dělí do 4 stupňů, přičemž v jakémkoliv z prvních třech může být objednávka prohlášena za neschválenou. V prvním stupni bude objednávku schvalovat zaměstnanec po technické stránce. Jedná se o zvoleného zaměstnanec, který obsahu objednávky nejvíce rozumí v rámci společnosti a bude mít za úkol rozhodnout, zda je položky nutné pořizovat. Umožní se mu zasahovat do položek objednávky – přidávat, editovat a mazat je. Dále má za povinnost vybrat dodavatele objednávky.

4


Další stupeň schvalování bude na vedoucím oddělení, jejímž členem je zadavatel objednávky. Vedoucí pouze rozhoduje, zda objednávku schválí či nikoliv. Nemá již žádné právo zasahovat do obsahu objednávky. Do třetího stupně přejdou pouze objednávky přesahující finanční limit tvořený součtem všech položek. Limit je spjat s kategorií viz 2.3, ve které je objednávka zařazena. Schvalování rozhoduje ředitel autora objednávky a má stejná práva jako vedoucí. Systém nesmí umožnit žádnému jinému uživateli převzít schvalování za technického schvalovatele, vedoucího anebo ředitele. V případě, že bude autorem objednávky technický schvalovatel nebo vedoucí nebo ředitel, proběhne automatické schválení už při zadání objednávky. Poslední stupeň má na starosti řešitel objednávky. Jim je zaměstnanec určený příslušnou kategorií viz 2.3. Řešitel generuje objednávku viz. 2.4 a dohlíží na průběh zpracování dodavatelem. Po vyřízení objednávku prohlásí za dokončenou. Uživatelé musí mít na výběr zasílání informačních e-mailů o každém kroku schválení či neschválení objednávky.

2.3 Systém práv Vytvářet novou objednávku bude povoleno pouze uživatelům s nastaveným právem „zakládat novou objednávku“. Ostatní uživatelé nemají do systému přístup. Práva ohledně schvalovatelů objednávek na vedoucí a ředitelské úrovni budou nastavena v rámci konfigurace oddělení viz. 2.1. Další pravomoci v Objednávkovém systému určí kategorie. Kategorie rozdělí objednávky podle objednávaného obsahu. Pro každou kategorii bude nastaven technický schvalovatel a řešitel nebo skupina řešitelů, čímž se vybere, zda objednávku bude řešit jeden uživatel nebo skupina uživatelů. Dalšími atributy budou finanční limity PPS, investice a ostatní. Volba „rychlé schvalování“ razantně změní schvalovací postup. Objednávka zařazená v kategorii s touto volbou bude vyjmuta ze schvalovacího procesu, až na třetí stupeň schvalování viz. 2.2.2, čili po vytvoření přejde přímo do fáze řešení. Posledním nastavením kategorie se určí, jakým uživatelům bude daná kategorie zobrazena. Bude zde i možnost zobrazit všem zaměstnancům.

5


2.4 Výstup objednávek ze systému Dalším požadavkem na systém je možnost vygenerování schválené objednávky do PDF dokumentu. Řešiteli budou nabídnuty dvě funkce. První funkce vygeneruje objednávku do PDF dokumentu k případnému tisku anebo k uložení objednávky do počítače. Druhá funkce připraví e-mailovou zprávu, kde bude vyplněna elektronická adresa dodavatele a v příloze připravená vygenerovaná objednávka v PDF dokumentu. Řešitel má možnost vyplnit tělo zprávy, připojit další příjemce a přílohy ke zprávě.

2.4.1 Tisková sestava objednávky Tiskovou sestavu musí systém generovat do PDF dokumentu. Sestava je o velikosti A4 a podle množství položek je tisknuta na jednu či více stran. Dokument se rozdělí na hlavičku, tělo tvořené seznamem položek a patičku. Hlavička obsahuje logo firmy, adresu sídla, obchodní informace a informace o dodavateli objednávky. V případě, že objednávka zabírá svým rozsahem položek více stran, je hlavička v dokumentu pouze jednou, a to na první stránce. Patičku objednávky tvoří poznámky/připomínky, razítko s podpisem a datum vystavení dokumentu. U vícestránkové objednávky je patička pouze na poslední stránce dokumentu.

6


Ukázka:

Obrázek 1. Ukázka tiskové sestavy objednávky

7


2.5 Zatížení systému V této kapitole jsou uvedeny přibližné zátěžové hodnoty, které systém musí zvládat: 25 současně pracujících uživatelů 200 zaměstnanců v databázi 2000 objednávek ročně (8 denně) 5 událostí (logů) na objednávku Z kapacitního hlediska se předpokládá 2MB doprovodných dokumentů na objednávku včetně finálně vygenerované objednávky do PDF dokumentu.

2.6 Požadavky na technologie Hardwarové a softwarové prostředky pro systém dodá společnost. Systém bude muset být uzpůsoben, tak aby fungoval na operačním systému MS Windows Server 2003 a využíval Internetovou informační službu (IIS). Databázový server bude také od společnosti Microsoft. Jedná se o volně využitelný produkt MS SQL Server 2005 Express s možností, v případě problému s omezením volné verze, pozdějšího upgradu na produkt MS SQL Server 2005.

8

3. Analýza a návrh řešení

3. Analýza a návrh řešení 3.1 Případ užití systému V této kapitole je popsáno chování systému z hlediska uživatele. Na níže uvedených obrázcích viz. Obrázek 2, Obrázek 3 a Obrázek 4 jsou znázorněny typy uživatelů a jejich role v systému. Systém bude rozpoznávat pět typů uživatelů, kteří mají následující role: Zaměstnanec: je jim každý uživatel systému, kterému jsou dovoleny základní operace. Tvoří základ pro další typy uživatelů. Administrátor: je uživatel, který provádí nastavení systému, zakládá uživatele, kategorie, oddělení a přiděluje práva. Má nejvyšší pravomoc v systému. Technik: je prvním schvalovatelem objednávky. Má navíce možností zasahovat do vytvořené objednávky, tzn. editovat, přidávat a mazat jednotlivé položky. Schvalovatel: typ uživatele, který provádí schvalování objednávek na úrovni vedoucí anebo ředitel. Řešitel: má na starosti poslední fázi objednávky, její realizaci. Generuje objednávku do PDF dokumentu, kterou odesílá dodavateli a dohlíží na realizaci.

Zaměstnanec

Administrátor

Schvalovatel

Technik

Obrázek 2. Hierarchie aktérů 9

Řešitel


Změnit heslo

«extends» Najít objednávku

Vytvořit objednávku

«uses» Dokončit

Zobrazit logy «extends»

Zobrazit objednávku

Řešitel

«uses»

«uses» Generovat objednávku «uses»

Login «uses»

Technik «uses»

Zaměstnanec

Schvalovat objednávku

Logout

Přidat dodavatele

«uses» Spravovat dodavatele

Najít dodavatele

Schvalovat

Obrázek 3. Use Case diagram – základní

10

Schvalovatel


«extends»

Kopírovat kategorii

Vytvořit kategorii «uses»

«uses»

Najít kategorii

Spravovat kategorii Přidat uživatele «extends»

Spravovat práva uživatele «uses» Najít uživatele «extends»

«uses»

Administrátor Spravovat uživatele

Vytvořit oddělení

«uses» Spravovat oddělení

Najít oddělení

Obrázek 4. Use Case diagram – administrátorská úroveň

3.2 Scénáře případů použití Scénáře obsahují sekvenci událostí, které v rámci scénáře probíhají (včetně případných variant). U každého scénáře je předpokládán proces přihlášení do systému Login a po dokončení operace proces odhlášení ze systému Logout. Dále jsou popsány pouze ty případy užití, které se skládají z více částí.

11


3.2.1 Scénáře zaměstnanec 1. Změnit heslo 1. Zadat staré heslo pro ověření 2. Zadat nové heslo 2. Vytvořit objednávku 1. Zvolit kategorii 2. Popis objednávky 3. Zvolit upozorňování e-mailem (ANO/NE) 4. Nastavit typ objednávky (Ostatní, PPS, Investice) 5. Volitelně připojit soubor 6. Vyplnit položky objednávky 7. Volitelně připojit poznámku 8. Odeslat 9. Poslaní informačního e-mailu 10. Vložit záznam o operaci Další varianta: Vybrat objednávku z dříve vytvořených a jednotlivé položky editovat podle bodů 1 – 7. 3. Přidat dodavatele 1. Vyplnit název firmy a sídlo firmy 2. Volitelně zadat kontaktní údaje 3. Přidat dodavatele 4. Spravovat dodavatele První varianta: editovat položky existujícího dodavatele Druhá varianta: smazat existujícího dodavatele

12


3.2.2 Scénáře technika (technický schvalovatel) 1. Schvalovat objednávku 1. Výběr dodavatele objednávky 2. Editace/mazání položek objednávky 3. Volitelně připojit soubor 4. Vložit záznam o operaci Další varianta: smazat objednávku + vložit záznam o operaci 2. Schvalovat 1. Volitelně připojit poznámku 2. Schválit/neschválit objednávku 3. Poslaní informačního e-mailu 4. Vložit záznam o operaci

3.2.3 Scénáře schvalovatele

1. Schvalovat 1. Volitelně připojit poznámku 2. Schválit/neschválit objednávku 3. Poslaní informačního e-mailu 4. Vložit záznam o operaci V případě schvalování ředitelem lze smazat objednávku

3.2.4 Scénáře řešitele 1. Dokončit 1. Připojit vyfakturovanou částku 2. Dokončit objednávku

13


3. Poslaní informačního e-mailu 4. Přesunutí objednávky mezi dokončené 5. Vložit záznam o operaci 2. Generovat objednávku První varianta: vygenerovat objednávku do PDF dokumentu Druhá varianta: 1. Vygenerovat e-mail dodavateli 2. Volitelně přidat příjemce a tělo zprávy 3. Volitelně připojit soubory ke zprávě 4. Odeslat 5. Vložit záznam o operaci

3.2.5 Scénáře administrátora 1. Vytvořit kategorii 1. Vyplnit položky nové kategorie 2. Uložit kategorii 2. Spravovat kategorie První varianta: editovat položky existující kategorie Druhá varianta: smazat existující kategorii 3. Přidat uživatele 1. Vyplnit položky nového uživatele 2a. Uložit uživatele 2b. Přejít na nastavení práv (Nastavit práva) 4. Spravovat práva uživatele První varianta: 1. Vybrat oddělení a příslušné oprávnění 2. Uložit oprávnění Druhá varianta: smazat existující oprávnění

14


5. Spravovat uživatele První varianta: editovat položky existujícího uživatele Druhá varianta: smazat existujícího uživatele 6. Vytvořit oddělení 1. Vyplnit položky nového oddělení 2. Uložit oddělení 7. Spravovat oddělení První varianta: editovat položky existujícího oddělení Druhá varianta: smazat existující oddělení

3.2.6 Diagram schvalování objednávky Proces schvalování objednávky je znázorněn na diagramu aktivit. Pomocí diagramu aktivit se modeluje dynamický tok řízený nikoliv vnějšími událostmi ale interními podněty. Lze jej používat i pro modelování procesů a pracovních toků (work-flow), kdy se nezřídka využívá možnosti modelovat paralelismus a větvení v rámci konkrétního zpracovávaného procesu. Často se přiřazuje k jednotlivým aktivitám osoby, které jsou za provedení patřičné aktivity zodpovědné. Diagram stavů a aktivit jsou si podobné, oba ukazují sekvenci stavů a podmínky způsobující přechody mezi stavy. Rozdíl mezi diagramy je v tom, že diagram stavů se soustřeďuje na stavy objektů, kdežto diagram aktivit se zaměřuje na stav samotného výpočtu, a kde jsou znázorněny řídící a informační toky mezi prvky diagramu. Diagram schvalování objednávky: znázorňuje postup schvalování objednávky. Jedná se o hlavní logiku, podle které se systém řídí v průběhu schvalování objednávky. Dříve než dojde k uplatnění schématu, je potřeba zadat do systému novou objednávku. Autor objednávky může zastávat více rolí v systému, takže celkem jednoduše může nastat situace, kdy jej systém po vytvoření objednávky vybídne k dokončení. V opačném případě bude objednávka připravena ke schvalování příslušné osobě zastávající post podle diagramu.

15


Uživatel s více schvalovacími posty se k objednávce vyjadřuje pouze jednou a to v prvním případě schvalování. Pro názornost je uveden jednoduchý příklad: Autorem objednávky je uživatel, který zadá objednávku v kategorii, kde je uveden jako technický schvalovatel. Systém vyzve autora, aby v průběhu vytváření objednávky také zadal dodavatele, což je funkce technického schvalovatele. Tedy odesláním nové objednávky se zároveň předpokládá schválení po technické stránce. Dále objednávku obdrží uživatel uveden jako vedoucí a zároveň ředitel oddělení, ve kterém je autor zařazen. Tento uživatel objednávku schválí pouze jednou a to i v případě, přesáhne-li stanovený finanční limit uvedený u kategorie. Jestliže proběhne kladné schválení, přejde do stavu řešení a čeká na řešitele. Existuje i případ rychlého schvalování. Kategorie s tímto nastavením umožní uživatelům okamžitě schválit objednávku a připravit k řešení. Pouze v případě, když přesahuje stanovený finanční limit je potřeba souhlas řiditele.

16


Vytvoření objednávky

NE

Je zakázáno rychlé schvalování?

ANO

Zjisti tech. schvalovatele

Je uživatel technickým schvalovatelem?

NE ANO

Vyber dodavatele

Je uřivatel vedoucím?

Vyber dodavatele

NE ANO

Zjisti limit

Je překročen limit?

NE ANO

Zjisti řiditele

Je uřivatel řiditelem?

NE ANO

Zjisti řešitele

NE

Je uřivatel řešitelem?

ANO

Dokončení objednávky

Obrázek 5. Diagram schvalování objednávky

17


3.3 Dynamický model Dynamický model vyjadřuje dynamické chování systému z vnitřního pohledu. Jeho součástí je stavový diagram a diagram aktivit.

3.3.1 Stavové diagramy Diagram vyjadřuje stav určitého objektu a přechody mezi těmito stavy. Jedná se o graf stavů a přechodů, který popisuje reakce objektu na obdržené události. Stavový diagram - modul zaměstnanec: ukazuje stavy a přechody, které jsou základem pro všechny typy uživatelů pracující se systémem. Tzn., že tento diagram je základem stavů pro každého uživatele a je dále rozšiřován o další stavy podle konkrétního zaměstnance, který se systémem momentálně pracuje. Možná rozšíření jsou uvedena níže. Počátečním stavem je Přihlášení do systému. Z tohoto stavu se bez podmínky přechází do entity Menu. V tomto stavu si uživatel vybírá, jakou operaci bude po systému požadovat a po jejím dokončení se do tohoto místa opět vrátí. Stav Hlavní stránka obsahuje veškeré informace o přihlášeném uživateli a statistiku o objednávkách s nimi souvisejících. Dále lze přejít do stavu Nastavení hesla a měnit přístupové heslo do systému. Nová objednávka je entita sloužící k zadávání nových objednávek ke schvalování a případně k řešení, viz Obrázek 16. Za stavy Moje objednávky a Vyřízené objednávky následují operace pracující nad různými množinami objednávek. Moje objednávky tvoří skupina objednávek, jejímž autorem je přihlášený uživatel. Vyřízené objednávky obsahují objednávky dokončené nebo neschválené, s nimiž měl uživatel nějaké dočinění. Jelikož skupina entit je pro Moje objednávky a Vyřízené objednávky totožná, byla provedena substituce přes stav Operace, viz. Obrázek 7. Ve stavu Dodavatelé se nachází adresář firem, které případně realizují objednávky. S tímto seznamem pracují entity Nový dodavatel, Editace dodavatele a Smazat dodavatele, které zastávají intuitivně stejné operace. Posledním stavem v diagramu je Odhlášení, čímž je realizováno bezpečné opuštění aplikace.

18


Přihlášení Přechod do menu Stisk tl. „Hlavní stránka“ Stisk tl. „Zpět“

Souhrné informace Stisk tl. „Změna hesla“ Návrat po nastavení

Vytvoření objednávky

Nastavení hesla

Stisk tl. „Odhlášení“

Menu

Stisk tl. „Moje objednávky“

Stisk tl. „Nová objednávka“

Odhlášení

Stisk tl. „Vyřízené objednávky“ Stisk tl. „Zpět“

Stisk tl. „Zpět“

Moje objednávky

Stisk tl. „Zpět“

Vyřízené objednávky

Stisk tl. „Dodavatelé“

Návrat po dokončení

Dodavatelé

Nová objednávka Operac

Stisk tl. „Smaž dodavatele“

Stisk tl. „Editace dodavatele“

Operace

Editace dodavatele

Návrat po dokončení Stisk tl. „Nový dodavatel“

Smazat dodavatele Nový dodavatel

Obrázek 6. Stavový diagram - modul zaměstnanec Stavový diagram - modul operace: Ve stavu Detail objednávky jsou zobrazeny kompletní informace o objednávce (zadavatel, datum vytvoření, kategorie objednávky, přiložené soubory, atd.), položky, poznámky a další informace. Logy obsahují kompletní záznamy provedené s objednávkou (datum schvalování, jména schvalovatelů a řešitelů, záznamy o řešení objednávky atd.). Objednávku lze pro urychlení práce ve stavu Hledat objednávku vyhledat zadáním čísla objednávky.

19


Stisk tl. “Detail”

Operace Stisk tl. “Hledat objednávku”

Stisk tl. “Zpět”


Detail objednávky

Stisk tl. “Logy”


Zobrazení výsledku

Hledat objednávku

Logy objednávky

Obrázek 7. Stavový diagram - modul operace Stavový diagram – modul administrátor: je nástavbou diagramu zaměstnance viz. Obrázek 6. Přidává stavy navazující na stav Menu. Kategorie viz. Obrázek 18 obsahuje množinu kategorií, do kterých jsou děleny objednávky. Entity, které následují za Kategoriemi jsou Nová kategorie, Editace kategorie a Smazat kategorii. Z názvu intuitivně vyplívají jejich funkce, přičemž novou kategorii lze založit stavem Kopie kategorie a následně kopii editovat. Administrátorovou další možností vyplívající z diagramu je správa seznamu uživatelů a přidělování oprávnění. K entitám umožňujícím uvedené operace se z Menu přistupuje přes stavy Přidat uživatele a Seznam uživatelů. Z názvů stavů opět vyplívají jednotlivé funkce daných entit. Poslední neuvedená množina stavů, ke kterým se přistupuje přes entitu Oddělení, dovoluje administrátorovi spravovat tabulku oddělení. Entity operují nad tabulkou s klasickými operacemi, nové oddělení, editace oddělení a mazání oddělení.

20


Stisk tl. “Kategorie”

Návrat po dokončení Smazat kategorii


Kategorie

Stisk tl. “Smazat kategorii”

Stisk tl. “Nová kategorie”


Menu

Stisk tl. “Editece kategorie” Návrat po dokončení

Nová kategorie Stisk tl. “Kopie”

Kopie kategorie

Oddělení

Stisk tl. “Oddělení”



Editace kategorie Návrat po dokončení


Stisk tl. “Seznam uživatelů”

Stisk tl. “Nový uživatel”


Přidat uživatele

Nové oddělení

Seznam uživatelů

Stisk tl. “Práva”

Návrat po dokončení Stisk tl. “Editece oddělení”

Editace oddělení

Práva uživatele

Návrat po Stisk tl. dokončení “Editece uživatele” Návrat po dokončení

Návrat po dokončení Návrat po dokončení

Návrat po dokončení Stisk tl. “Smazat uživatele”

Stisk tl. “Práva”

Nastavit oprávnění

Stisk tl. “Nové oddělení”

Smazat oddělení

Stisk tl. “Zpět” Návrat po dokončení

Stisk tl. “Nastav práva”

Stisk tl. “Smazat oddělení”

Smazat uživatele


Editace uživatele

Stisk tl. “Smazat práva”

Smazat oprávnění

Obrázek 8. Stavový diagram - modul administrátor Stavový diagram technika: také navazuje na stav Menu a přidává entitu Schvalované objednávky. Uživatel vybere ze seznamu objednávku ke schválení, čímž přejde na Detail objednávky. V detailu objednávky přibude možnost editovat objednávku, resp. její položky a dodavatele. V dalším se přejde do stavu Schvalování, kde rozhodne, zda objednávku schválí nebo neschválí. Stav Editovat objednávku lze přeskočit přímým přejitím do entity Schvalování. Ostatní stavy byly popsány výše, čili jsou identické s uvedenými a není potřeba je znovu popisovat.

21


Menu

Stisk tl. “Schvalované objednávky”


Schvalované objednávky

Schvalování

Stisk tl. “Hledání”



Schvalování



Hledání objednávky


Schvalování Stisk tl. “Editace objednávky”

Návrat po dokončení Stisk tl. “Smazat objednávku”


Smazat objednávku

Stisk tl. “Smazat objednávku”

Detail objednávky

Editovat objednávku Návrat po dokončení


Logy

Obrázek 9. Stavový diagram technika Stavový diagram - modul schvalovatel (vedoucího a ředitele): tyto dva diagramy jsou si velice podobné. Oba uživatelé pouze schvalují objednávku, přičemž ředitel má možnost ve stavu Smazat objednávku vymazat objednávku ze systému.

22


Menu






Schvalování

Stisk tl. “Zpět” Schvalování

Detail objednávky Stisk tl. “Zpět”

Stisk tl. Stisk tl. “Zpět” “Detail” Stisk tl. “Detail” Stisk tl. “Zpět”


Logy

Obrázek 10. Stavový diagram - modul vedoucí

23

Hledání objednávky


Menu






Schvalování

Stisk tl. “Detail” Stisk tl. “Detail”

Schvalování

Detail objednávky Stisk tl. “Logy”




Stisk tl. “Smazat Hledání objednávky objednávku”

Smazat objednávku

Stisk tl. “Zpět” Stisk tl. “Smazat objednávku”

Stisk tl. “Zpět” Logy

Obrázek 11. Stavový diagram – modul ředitel Stavový diagram - modul řešitel: je posledním uvedeným diagramem. Řešiteli se ve stavu Objednávky k řešení zobrazí objednávky, které zadává dodavateli k realizaci viz. Obrázek 17. Přes entitu Vygenerovat e-mail systém připraví objednávku do elektronické pošty a odešle ji dodavateli. Ve stavu Vygenerovat do PDF vytvoří PDF dokument obsahující zobrazenou objednávku. Po vyřízení objednávky řešitel přejde na entitu Dokončit a objednávku prohlásí za dokončenou. V tuto chvíli je objednávka přesunuta mezi vyřízené objednávky.

24


Menu

Stisk tl. “Objednávky k řešení”


Objednávky k řešení Návrat po dokončení

Dokončit





Hledání objednávky Stisk tl. “Detail”

Dokončení objednávky

Stisk tl. “Zpět” Detail objednávky

Stisk tl. “Vygenerovat PDF”

Vygenerovat do PDF

Návrat po dokončení Návrat po dokončení Stisk tl. “Logy”


Stisk tl. “Vygenerovat e-mail”

Vygenerovat e-mail

Logy

Obrázek 12. Stavový diagram - modul řešitel

3.4 Konceptuální model Konceptuální modely slouží k vytvoření popisu dat v databázi nezávisle na jejich uložení. Model prezentuje vztahy mezi entitami nebo objekty. Na níže uvedeném obrázku viz. Obrázek 13 je uveden konceptuální model, z něhož v další kapitole vychází logický datový model.

25


Obrázek 13. Konceptuální model systému Význam symbolů konceptuálního modelu: Symboly

příjmení titul

Vysvětlivky Kardinalita 1:N Kardinalita 0:N Povinný atribut Nepovinný atribut

Tabulka 1. Symboly Konceptuálního modelu

3.5 Architektura Architektura systému je volena na základě dostupného operačního systému, jeho služeb a v neposlední řadě také na finančních prostředcích. Zvolené prostředí pro Objednávkový

26


systém lze rozdělit do třech jednotlivých vrstev. První vrstva je databázová, další aplikační a poslední vrstva je prezentační.

3.5.1 Databázová vrstva Úkolem databázové vrstvy je poskytovat spolehlivé a bezpečné úložiště dat pro aplikaci včetně jejich integrace. Dále tato vrstva slouží k rychlému a stabilnímu přístupu k uloženým datům, přičemž je samozřejmostí jejich vyhledávání. Databázová vrstva je realizována na technologii Microsoft SQL 2005. Důvody pro tuto volbu: Vysoká kvalita MS SQL 2005 serveru Pro projekt využitelnost free verze Osobní zkušenost s MS SQL Vysoká rychlost Oproti open-source databázím obsahuje více funkcí Další uvažované varianty: MySQL, Postgre SQL – upřednostňován MS SQL server společností Oracle – velice nákladné řešení pro tento projekt

3.5.2 Aplikační vrstva Aplikační vrstva vytváří kompletní aplikační logiku celého Objednávkového systému. Úkolem této vrstvy je poskytovat všechny potřebné funkce, které jsou základem pro prezenční vrstvu. Pro aplikační vrstvu byla zvolena platforma PHP. Důvody pro tuto volbu: Vysoká kvalita a rozmanitost skriptovacího jazyka PHP Jednoduchá práce s MS SQL 2005 databází PHP je open-source projekt

27


Velké množství open-source modulů a knihoven Využití šablon pro přehledné oddělení aplikační logiky od prezentace dat Za aplikační server byla zvolena Internetová informační služba (IIS) od firmy Microsoft. Byl zvažován i HTTP Apache server, který ovšem nepřesvědčil o bezproblémové stabilitě na MS Windows server 2003, jako služba IIS, i přestože má větší systémové nároky. Další nevýhodou Apache serveru je vysoká náročnost jeho konfigurace.

3.5.3 Prezentační vrstva Tato vrstva má za úkol vytvořit grafické rozhraní mezi uživatelem a systémem. Prezentuje data Objednávkového systému a umožňuje uživateli přístup k jednotlivým funkcím systému. K tomuto byl zvolen standardní HTML prohlížeč, jimž může být například MS Internet Explorer, Mozilla Firefox, Opera, atd. Tento způsob prezentace dat byl zvolen pro možnost využití na jakémkoliv počítači a to nejen v rámci intranetu, ale i z jakéhokoli pracoviště připojeného k síti Internet. Využitím HTML prohlížeče, jenž je součástí většiny operačních systémů, odpadá nutnost jakékoliv instalace před použitím aplikace.

3.5.4 Architektura systému Na obrázku viz. Obrázek 14 je zobrazena architektura systému na Microsoft Windows Serveru.

28


MS Server IIS PHP Klientské PC GUI

Webový prohlížeč Funkční část

Databáze

Obrázek 14. Architektura systému

29

4. Implementace

4. Implementace 4.1 Popis implementace Objednávkový systém byl implementován převážně v programovacím jazyce PHP5. Tato verze PHP už podporuje objektové programování, ale v projektu byla objektová technologie použita částečně. Jelikož se jedná o webovou aplikaci, jsou data zobrazována v HTML kódu a dynamické části za pomoci jazyka JavaScript. Klíčová specifika: HTML kód je formátován čistě CSS styly Je využito objektových šablon PHP – PHP Smarty Jsou použity tři typy uživatelského zobrazení Menu a funkce systému se dynamicky mění podle nastavených práv přihlášeného uživatele Formuláře se pro pohodlnější a rychlejší ovládání kontrolují na straně uživatele pomocí JavaScriptu a zároveň po odeslání dat na straně serveru JavaScripty mají vliv pouze na zjednodušení práce s aplikací, nikoliv na funkčnost systému

4.2 Logický datový model 4.2.1 Návrh logického datového modelu Na modelu viz. Obrázek 15 je uveden logický datový model SLQ databáze. Datový model vychází z konceptuálního modelu viz. 3.4 uvedeném v analytické části práce. Většina entit konceptuálního modelu je převedena na tabulky a doplněna o klíče, cizí klíče a další atributy. Dále byl datový model rozšířen o několik dalších tabulek, příkladem je entita Objednávky rozdělená na tabulky TObjednávky a TObjednávky_his, kvůli rozdělení objedná-

30

4. Implementace

vek na objednávky ke schválení (TObjednávky), se kterými se více pracuje a dokončené objednávky (TObjednávky_his). Databázový model nesplňuje ani 2. normální formu kvůli tabulkám TObjednavky a TObjednavky_his. Je to způsobeno atributem cislo_oddeleni, který vytváří redundanci dat. Cislo_oddeleni nese číslo oddělení, které je součásti čísla objednávky. Správce systému má možnost toto číslo editovat, takže v případě změny čísla oddělení v tabulce TOddeleni by při provázání přes cizí klíč vznikla chyba v číslech objednávek vytvořených před změnou čísla oddělení. V modelu je zřejmé provázání jednotlivých tabulek přes cizí klíče, což je blíže popsáno v kapitole 4.4.

31

4. Implementace

Obrázek 15. Logický datový model

32

4. Implementace

4.2.2 Datový slovník Datový slovník popisuje jednotlivé tabulky datového modelu a jejich sloupce. Označení PK ve sloupci Klíč označuje primární klíč a označení FK označuje cizí klíč. Níže nejsou uvedeny slovníky všech tabulek datového modelu, ale pouze slovníky stěžejních tabulek. Tabulky TObjednavky_his, TObj_polozky_his a Tlogy_his nejsou popsány, jelikož se velice shodují se stejnojmennými tabulkami bez postfixu „_his“. Do těchto tabulek se ukládají dokončené objednávky spolu s jejich položkami a záznamy o událostech. Tabulka TUzivatele: je nejdůležitější tabulkou systému a uchovává stěžejní informace o zaměstnancích. Datový typ Integer

Vstupní pole

Komentář

PK

Název sloupce id

-

Primární kíč

FK

id_oddeleni

Integer

-

Cizí klíč do tab. TOddeleni(id)

nick

String(30)

heslo titul jmeno prijmeni

String(50) String(10) String(20) String(30)

Uživatelské jméno Heslo Titul Jméno Příjmení

Uživatelské jméno pro přihlášení Heslo pro přihlášení Titul zaměstnance Jméno zaměstnance Příjmení zaměstnance

mobil

String(20)

Mobilní fon

linka

String(20)

Linka

kancelar

String(10)

os_cislo

Smallint

mail

String(40)

poznamka

Text

Klíč

tele- Mobilní telefon zaměstnance Tel. číslo na pevnou linku zaměstnance

Číslo kancelá- Číslo dveří kanceláře ře zaměstnance Osobní čísOsobní číslo lo zaměstnance Podnikový E-mail E-mail zaměstnance Poznámka

33

Doplňující poznámka o zaměstnanci

4. Implementace

Klíč

Název sloupce

Datový typ

Vstupní pole

spravce

Smallint

Správce systé- Správce systému mu (ANO/NE)

session

String(50)

-

exist

Smallint

-

razitko

Data

Naskenované razítko Razítko s pods podpisem zaměstpisem nance

design

Smallint

Vzhled

Komentář

Bezpečnostní prvek PHP skriptu Aktivní záznam (ANO/NE)

Vzhled uživatelského rozhranní

Tabulka 2. Datový slovník tabulky TUzivatele

34

4. Implementace

Tabulka TObjednavky: je tabulka nesoucí hlavní informace o zadaných objednávkách.

PK

id

Datový typ Integer

FK

id_zadavatele

Integer

-

cislo_obj

Smallint

-

cislo_oddeleni

Smallint

-

hlavicka

String(80)

Krátký popis objednávky

Popis objednávky

datum_vytvoreni

Integer

-

Datum vytvoření objednávky

FK

id_obj_kategorie

Integer

-

Cizí klíč do tab. TObj_kategorie(id)

FK

id_resitele

Integer

-

Cizí klíč do tab. TUzivatele(id)

stav

Smallint

-

Stav schvalování, ve kterém se objednávka nachází

mail_upozorneni

Smallint

Mám být upozorňován/a na průběh zpracovávání objednávky emailem

Upozornění o průběhu schvalování elektronickou zprávou (ANO/NE)

poznamka

Text

Poznámka

Poznámka k objednávce

id_dodavatele

Integer

Vyberte dodavatele

Cizí klíč do tab. TFirmy(id)

exist

Smallint

-

pdf

Data

-

Klíč Název sloupce

FK

Vstupní pole

Komentář

-

Primární klíč

35

Cizí klíč do tab. TUzivatele(id) Pořadové číslo objednávky v rámci oddělení Číslo oddělení

Aktivní záznam (ANO/NE) Uložena vygenerovaná PDF objednávka

4. Implementace

Tabulka 3. Datový slovník tabulky TObjednavky Tabulka TObj_polozky: tato tabulka je plněna položkami přidružené objednávky. Klíč Název sloupce PK id

Datový typ Integer

Vstupní pole -

Komentář Primární klíč

FK

id_objednavky

Integer

-

Cizí klíč do tab. TObjednavky(id)

c_polozky

Smallint

-

popis

Text

Text

cena

Real

Předběžná cena bez DPH

mnozstvi

Integer

Množství

jednotka

String(8)

Jednotky

Číslo položky v rámci objednávky Název položky Cena položky Počet kusů položky Jednotka množství

Tabulka 4. Datový slovník tabulky TObj_polozky Tabulka TObj_kotagerie: obsahuje nastavení kategorií. Klíč

Název sloupce

PK

id cislo_kategorie

Datový typ Integer Smallint

jmeno

String(50)

FK

id_technik

Integer

skupina_resitelu

Smallint

rychly_resitel

Smallint

pravo_all

Smallint

Vstupní pole

Komentář

Primární klíč Číslo kategorie Číslo kategorie Jméno kategorie

Jméno kategorie

Technický schvalovatel

Technický schvalovatel objednávky, cizí klíč do tabulky TOddeleni(id)

Řešitelé do skupiny Bleskové schvalování

Skupina řešitelů (ANO/NE) Bleskové schvalování objednávek

Má se zobrazit Zobrazení kategokategorie všem rie uživatelů 36

4. Implementace

Klíč

Název sloupce

Datový typ

Vstupní pole

Komentář

uživatelům

(ANO/NE) Aktivovat typ objednávek ostatní (ANO/NE)

Smallint

Typy objednávek ostatní

Smallint

Typy objednávek PPS

Aktivovat typ objednávek PPS (ANO/NE)

obj_invest

Smallint

Typy objednávek investice

Aktivovat typ objednávek investice (ANO/NE)

obj_ost_limit

Integer

obj_pps_limit

Integer

obj_invest_limit

Integer

Finanční limit investiční

exist

Smallint

-

obj_ost

obj_pps

Finanční limit ostatní Finanční limit PPS

Finanční limit pro ostatní objednávky Finanční limit pro PPS objednávky Finanční limit pro investiční objednávky Aktivní záznam (ANO/NE)

Tabulka 5. Datový slovník tabulky TObj_kategorie

37

4. Implementace

Tabulka TOddeleni: obsahuje názvy oddělení společnosti včetně ředitelů a vedoucích pracovníků v každém oddělení. Klíč PK

Název sloup- Datový ce typ id Integer

Vstupní pole

Komentář

-

Primární klíč

jmeno

String(30)

poznamka

Text

Jméno oddělení Poznámka

exist

Smallint

-

Aktivní záznam (ANO/NE) Vedoucí oddělení, cizí klíč do tabulky TOddeleni(id)

FK

id_vedouci

Integer

Vedoucí

FK

id_reditel

Integer

Ředitel

cislo_oddeleni Smallint

Číslo oddělení

Jméno oddělení Poznámka k oddělení

Ředitel oddělení, cizí klíč do tabulky TOddeleni(id) Číslo oddělení

Tabulka 6. Datový slovník tabulky TOddeleni Tabulka TFirmy: je tabulka plněná dodavateli objednávek včetně několika kontaktních informací. Klíč

Název sloupce

PK

id jmeno ulice psc mesto

Datový typ Integer String(70) String(70) String(50) String(50)

kontakt_osoba

String(50)

telefon fax mail ico

String(50) String(50) String(70) String(50)

Vstupní pole

Komentář

Jméno firmy Ulice PSČ Město

Primární klíč Jméno firmy Ulice sídla firmy PSČ sídla firmy Město sídla firmy

Kontaktní osoba Telefon Fax E-mail IČO

Kontaktní osoba ve firmě Kontaktní telefon Fax Firemní e-mail IČO

38

4. Implementace

Klíč

Vstupní pole

Komentář

dic

Datový typ String(50)

DIČ

DIČ

popis

Text

Poznámka

Poznámka

exist

Smallint

-

Aktivní záznam (ANO/NE)

Název sloupce

Tabulka 7. Datový slovník tabulky TFirmy Tabulka TLogy: nese informace o průběhu schvalování objednávky. Ukládá se, který uživatel provedl daný úkon.

PK

id

Datový typ Integer

FK

id_uzivatele

Integer

Klíč Název sloupce

FK

Vstupní Komentář pole Primární klíč -

Autor operace, cizí klíč do tabulky TUzivatele(id)

id_objednavky

Integer

-

datum zaznam

Integer Smallint

-

Související objednávka, cizí klíč do tabulky TObjednavky(id) Čas operace Typ operace

poznamka

String(50)

-

Poznámka k operaci

Tabulka 8. Datový slovník tabulky TLogy

4.3 Vstupní pole Tato kapitola zobrazuje seznamy vstupních polí jednotlivých entit. Jsou jimi například zaměstnanec, objednávka, události atd. U každého pole je uveden datový typ a popis.

39

4. Implementace

4.3.1 Entita zaměstnanec Každému zaměstnanci/uživateli lze při zakládání nastavit tyto hodnoty a později je editovat: Název Uživatelské jméno

Datový typ string(30)

Popis -

Heslo Titul

string(50) string(10)

-

Jméno Příjmení Oddělení

string(20) string(30) výběrové menu

Sestaveno oddělení

Mobil telefon

string(20)

Linka

string(20)

Číslo kanceláře

string(10)

Osobní číslo E-mail Poznamka

smallint string(40) text

Validní e-mail -

Sken podpisu uživatele

Binární data

Soubor .jpg

Řetězec obsahující číslice, mezery, „+“ a/nebo „/“ Řetězec obsahující číslice, mezery, „+“ a/nebo „/“ Řetězec obsahující číslice a/nebo znaky A-Z, a-z

Tabulka 9. Pole entity Zaměstnanec pozn.: Tučné řádky znázorňují povinné údaje

4.3.2 Entita objednávka U každé nové objednávky je nutno zadat následující hodnoty. Vyjma pole „Upozornění emailem“ nelze hodnoty polí dále editovat.

Název Název

Datový typ string(80)

Popis 40

4. Implementace

Název

Datový typ

Popis

Upozornění e-mailem Poznámka Dodavatel

výběrové menu text výběrové menu

ANO/NE Sestaveno dodavatelů

Typ

výběrové menu

Výběr z předdefinované nabídky

Tabulka 10. Pole entity Objednávka pozn.: Tučné řádky znázorňují povinné údaje

4.3.3 Entita kategorie Každé kategorii lze při zakládání nastavit tyto hodnoty a později je editovat: Název Název Technický schvalovatel

Datový typ string(50) výběrové menu

Popis Sestaveno uživatelů

Skupina řešitelů

list

Seznam tvořený uživateli

Rychlé řešení

výběrové menu

ANO/NE

Zobrazit všem

výběrové menu

Komu zobrazit

list

ANO/NE Seznam tvořený uživateli

Typ obj ostatní Typ obj PPS Typ obj investice

výběrové menu výběrové menu výběrové menu

ANO/NE ANO/NE ANO/NE

Schvalovací limit ostatní Schvalovací limit PPS

integer integer

-

41

4. Implementace

Název

Datový typ

Popis

Schvalovací limit investice

integer

-

Tabulka 11. Pole entity Kategorie pozn.: Tučné řádky znázorňují povinné údaje

4.3.4 Entita dodavatelé Dodavatelům je možno při zakládání nastavit níže uvedené hodnoty a později je editovat: Název Jméno Ulice

Datový typ string(70) string(70)

PSČ

string(50)

Město

string(50)

Řetězec obsahující číslice a mezery -

Kontaktní osoba

string(50)

-

Telefon

string(50)

Řetězec obsahující číslice, mezery, „+“ a/nebo „/“

Fax

string(50)

E-mail IČ DIČ

string(70) integer string(50)

Popis -

Řetězec obsahující číslice, mezery, „+“ a/nebo „/“ Validní e-mail Maska: CZ1234567890

42

4. Implementace

Název Popis

Datový typ text

Popis -

Tabulka 12. Pole entity Dodavatel pozn.: Tučné řádky znázorňují povinné údaje

4.3.5 Entita oddělení U modulu oddělení lze při zakládání nastavit tyto hodnoty a později je editovat: Název Jméno Poznámka

Datový typ string(30) text

Vedoucí

výběrové menu

Ředitel

výběrové menu

Číslo oddělení

smallint

Popis Seznam tvořený uživateli Seznam tvořený uživateli -

Tabulka 13. Pole entity Oddělení pozn.: Tučné řádky znázorňují povinné údaje

4.3.6 Entita událostí Události budou automaticky generovány při práci s objednávkou. Většina úkonů, které uživatel s objednávkou provede, se zaznamenají v modulu události. Ke každé události proběhne uložení těchto data: Název Uživatel

Datový typ key

Popis Klíč k uživateli

Objednávka Datum

key datum

Klíč k objednávce -

43

4. Implementace

Název

Datový typ

Událost

smallint

Poznámka

string(50)

Popis Číselné označení události -

Tabulka 14. Pole entity Události pozn.: Tučné řádky znázorňují povinné údaje ke každé události

4.4 Struktury souborů Vyjma databázových tabulek je celý systém uložen v PHP skriptech, jež jsou uloženy v souborech. Ve většině případů představuje jeden soubor s příponou PHP funkční část webové stránky a soubor s příponou TPL grafické rozhraní, ve kterém jsou zobrazována data z funkční části. U objektové části systému představují soubory s příponou PHP třídy. Název souboru

Šablona

Název Use Casu

Popis

autorizace.php

-

-

Autorizační funkce

config.php

-

-

Konfigurace systémových nastavení PHP

fce_send_php.php

-

-

Obsahuje funkce k odesílaní aplikačních skriptů do šablon

finish_objednavka.php

finish_objednavka.tpl

Zobrazit objednávku, Smazat vyřízenou obj

Dokončená objednávku

finish_objednavky.php

Vyřízené objednávky, Smazat vyřízefinish_objednavky.tpl nou obj, Hledat objednávku

Seznam dokončených objednávek

Dodavatelé, Nový dodavatel, Smazat dodavatele, Editace dodavatele

Seznam dodavatelů

firmy.php

firmy.tpl

44

4. Implementace

Název souboru

Šablona

Název Use Casu

Popis

frame1.css

-

-

CSS styl pro GUI 1

frame2.css

-

-

CSS styl pro GUI 2

frame3.css

-

-

CSS styl pro GUI 3

funkce.php

-

-

Obsahuje aplikační funkce systému

funkce_obj.php

-

-

Obsahuje aplikační funkce systému

gen_obj.php

-

Vygenerovat do PDF, Vygenerovat e-mail

Generuje objednávku do PDF dokumentu

header.php

header.tpl

Logout

Generuje dynamické menu v hlavičce aplikace

index.php

index.tpl

Login

Vstupní stránka s přihlašovacím polem

kategorie.php

kategorie.tpl

Kategorie, Nová kategorie, Kopírovat kategorii, Editovat kategorii, Smazat kategorii

Správa kategorií

logy.php

logy.tpl

Logy

Zobrazuje události

main.css

-

-

Hlavní soubor CSS stylů

main.php

main.tpl

Hlavní stránka, Změna hesla

Hlavní stránka systému

moje_objednavky.php

moje_objednavky.tpl

Moje objednávky, Hledat objednávku

Seznam moje objednávky

new_objednavka.php

new_objednavka.tpl

Nová objednávka

Formulář na novou objednávku

new_user.php

new_user.tpl

Přidat uživatele, Editace uživatele

Formulář na nového uživatele

objednavka.php

objednavka.tpl

Zobrazit objednávku, Schvalování, Smazat objednávku, Editovat objednávku, Dokončit

Detail objednávky

objednavky.php

objednavky.tpl

Schvalované objednávky, Smazat objednávku, Hledat

Seznam objednávek

45

4. Implementace

Název souboru

Šablona

Název Use Casu objednávku, Objednávky k řešení

Popis

oddeleni.php

oddeleni.tpl

Oddělení, Nové oddělení, Editovat, oddělení, Smazat oddělení

prava.php

prava.tpl

Práva uživatele, Nastavit oprávnění, Smazat oprávnění

Správa oprávnění

user_list.php

user_list.tpl

Seznam uživatelů, Smazat uživatele

Seznam uživatelů

uzivatelska_prava.php

uzivatelska_prava.tpl

Práva uživatelů

Přehled nastavení uživatelských práv

Správa oddělení

Tabulka 15. Popis souborů a jejich význam Použité knihovny dostupné v rámci GNU: Název knihovny

Popis Šablony pro oddělení aplikační logiky od prezentace dat Knihovna užívaná ke generování PDF objednávek

PHP Smarty FPDF Library

Slouží k rozesílání elektronických zpráv z PHP scriptů

PHPMailer

Tabulka 16. Použité GNU knihovny

4.5 Ověření uživatele Ověřování uživatele probíhá na standardních metodách PHP. Po přihlášení uživatele, zadáním správného uživatelského jména a hesla, vygeneruje PHP session a jeho ID uloží v PC klienta v cookies souboru. Platnost cookies resp. session je nastavena přibližně na 24 minut. V případě, že není uživatel po tuto dobu aktivní, PHP session smaže, čímž následně dojde k jeho odhlášení ze systému. Dalším bezpečnostním prvkem je kontrola IP adresy. Ve chvíli přihlášení systém uloží IP adresu počítače, na kterém se uživatel úspěšně nalogoval.

46

4. Implementace

U přístupů zaměstnanců z Internetu (většina přístupů se realizuje z intranetu) dojde k navázání spojení přes protokol HTTPS. Data nejsou následně přenášena v běžném textu, ale jsou šifrována pomocí SSL. Při každém dotazu uživatele na server jsou volány autorizační funkce, které ověřují zmiňované session a IP adresu uživatele. Jestliže se tyto hodnoty neshodují, dojde k odhlášení a přesměrování na přihlašovací obrazovku.

4.6 Instalace systému na server Objednávkový systém spolu s podpůrnými serverovými aplikacemi je přiložen na CD nosiči viz. 9. Přiložené aplikace je nutné nainstalovat na serveru s operačním systémem od společnosti Microsoft.

4.6.1 Požadavky na server Server by měl po hardwarové stránce splňovat minimálně následující parametry: Procesor Pentium III 600MHz nebo kompatibilní 192MB operační paměti RAM 500MB prostoru na HDD CD-ROM Po softwarové stránce: Jeden z operačních systémů společnosti Microsoft Windows XP s SP2 Microsoft Windows 2000 Professional s SP4 Microsoft Windows 2000 Server s SP4 Windows Server 2003 Standard, Enterprise, nebo Datacenter editions s SP1 Windows Server 2003 Web Edition SP1 Windows Small Business Server 2003 s SP1 Vista Home Basic a vyšší .NET Framework 2.0

47

4. Implementace

4.6.2 Instalace Na serveru s operačním systémem MS Windows je nutná instalace služby IIS, PHP 5 a minimálně MS SQL Serveru 2005 Express edition. PHP nastavení: V souboru PHP.INI je potřeba nastavit následující parametry: register_globals = Off post_max_size = 32M file_uploads = On upload_max_filesize = 32M extension=php_mssql.dll session.use_cookies = 1 Nastavení MS SQL Serveru: Před instalaci objednávkového systému je nutné vytvořit na MS SQL serveru databázi, do které se budou ukládat data. Za pomoci Microsoft SQL Server Management Studiu (Express) musí být v databázi vytvořen uživatel user. Samotná databáze se importuje ze skriptu OS-DB.SQL. Instalace Objednávkového systému: Z CD nosiče se zkopíruje adresář OS do složky nastavené v IIS jako Domovský adresář. V souboru config.php ležícím v adresáři OS je potřeba změnit hodnoty u uvedených proměnných: $_SESSION[url_systemu] nastavení URL adresy odkazující na systém $_SESSION[smtp_server] adresa SMTP serveru $_SESSION[sql_server] adresa SQL serveru $_SESSION[sql_user] uživatelské jméno pro přístup do databáze $_SESSION[sql_pass] heslo pro přístup do databáze Kontaktní a informační údaje o společnosti: $_SESSION[adr][jmeno] jméno firmy $_SESSION[adr][ulice] ulice sídla firmy $_SESSION[adr][mesto] město sídla firmy $_SESSION[adr][ico] ičo firmy 48

4. Implementace

$_SESSION[adr][dic] dič firmy Po nastavení všech údajů je potřeba restartovat IIS službu a SQL server. Tímto je instalace systému dokončena a je možno jej začít používat. Klientské PC: Klientské PC určené k práci se systémem musí být připojené do počítačové sítě obsahující server s funkčním Objednávkovým systémem. V počítači je nutné zřídit připojení do této sítě a nainstalovat internetový prohlížeč, který je ale běžně součástí operačního systému. V prohlížeči je potřeba povolit používání cookies. K zahájení práce se systémem je nejprve nutno přejít v internetovém prohlížeči na URL serveru systému a na úvodní přihlašovací stránce zadat uživatelské jméno a heslo. V případě prvního vstupu je nutné zadat uživatelské jméno admin a heslo xxxxxx, které je doporučeno v rámci bezpečnosti co nejdříve změnit. Dále se nechte řídit pokyny systému.

49

5. Testování

5. Testování Testování slouží k ověření korektního chování naprogramovaných aplikací.

5.1 Funkční testy Funkční testy porovnávají software s požadavky kladenými na funkce. Tzn., zda naprogramovaná aplikace splňuje zadání v celém rozsahu. Tyto testy systému byly provedeny manuálně zaměstnanci společnosti. Nebyly vytvářeny žádné testovací scénáře. Vyjádření zadavatele: „Po doladění funkcí plynoucích z požívání systému v testovacím období lze prohlásit, že systém splňuje zadané požadavky a jeví se plně funkční. Dále se ve společnosti díky systému zefektivnilo následující: plně se zpřehlednilo zadávání a schvalování objednávek vznikl kompletní přehled o zadaných objednávkách a osobách podílejících se na jejich realizaci urychlil se proces vytvoření samotné objednávky sjednocení formátu objednávek pro celou společnost vzniká jednotný adresář dodavatelů“

5.1.1 Black-box testování Dříve než byla aplikace předána k manuálnímu testování zaměstnanci, proběhlo několik testů formou pohledu na systém, jako na černou skříňku se snahou zjistit za jakých okolností se systém chová jinak, než jak je uvedeno v požadavcích. Simulovaly se reálné situace provozu systému a pozorovalo se jeho chování a reakce na události, jako např.: chybné zadávání hodnot do textových polí ve formuláři

50

5. Testování

nevyplnění povinných formulářových polí správný průběh schvalování podle nakonfigurování systému rozesílání/nerozesílání upozorňovacích e-mailů o průběhu schvalování správné záznamy v logu o provedené operaci bezchybné ukládání vstupních dat a jejich následné zobrazení V průběhu tohoto testování byly odladěny veškeré nalezené chyby a po ukončení testování se systém choval v průběhu schvalování zcela podle očekávání.

5.2 Testování bezpečnosti Bylo testováno bezpečné a oprávněné přihlášení do systému na základě zadání správného uživatelského jména a hesla. Po úspěšném přihlášení probíhalo v průběhu práce se systémem pozorování, zda se zobrazují správná data přihlášeného uživatele a zda systém nabízí pouze funkce plynoucí z nastavení práv aktuálního uživatele. Předmětem dalšího testování byla simulace nekorektního odhlášení uživatele formou ukončení webového prohlížeče bez předchozího stisknutí odkazu Odhlásit. V tomto případě nelze technicky zaručit, že při znovuotevření jakékoliv stránky systému dojde k výzvě opětovného přihlášení. S malou pravděpodobností lze prohlásit, že v systému bude přihlášen poslední přihlášený uživatel. V případě korektního odhlášení ze systému, byla testována historie prohlížených stránek v prohlížeči. Vybráním jakékoliv stránky, jež je součástí Objednávkového systému dojde k přesměrování na úvodní přihlašovací stránku.

5.3 Uživatelské rozhraní Testování uživatelského rozhraní bylo rozděleno do dvou částí. V první části se testovala použitelnost rozhraní. Tato část testování probíhala v testovacím období se zaměstnanci společnosti. Zkoumalo se grafické sestavení formulářů a ovládacích prvků na různých typech monitorů a displejů o různých rozlišeních. Toto testování bylo velice náročné na čas množství uživatelů.

51

5. Testování

Druhá část se zabývala testováním na standardy a zásady pro webové stránky. Spočívala v ověření, zda aplikace splňuje veškeré požadavky, které jsou pro webové aplikace klíčové. Prvně se testovala validita stránek, která se ověřovala na stránkách konsorcia W3C, kde je k dispozici validátor jak HTML tak CSS. Celá webová část systému byla zkontrolována a všechny její části byly validátorem uznány, že vyhovují standardu HTML 4.01 Transitional. Jediná část, která nevyhovovala standardu se týká cookies. Systém mezi serverem a klientem rozeznává komunikaci pouze pomocí session uložené v cookies klienta. Čili v případě vypnuté funkce cookies na klientském PC, způsobí nesprávnou funkčnost systému. Stejným způsobem byly ověřeny i kaskádové styly, které byly CSS validátorem označeny jako validní.

52

6. Závěr

6. Závěr Ze zadání bakalářské práce vyplívají dva hlavní úkoly, navrhnout a implementovat objednávkový systém. Závěrem této práce lze tedy konstatovat, že byly oba úkoly v plné míře splněny. Tzn., že systém umožňuje zaměstnancům vytvářet objednávky a vedoucí a ředitelé tyto objednávky následně schvalují. Princip schvalování je nastaven v kategoriích, do kterých se objednávky přiřazují na základě objednávaných položek. Objednávkový systém lze využít v malých a středně velikých společnostech. Díky požadavkům vznášených od společnosti, která systém plně používá, dochází k jeho rozšiřování a programování dalších komponent. Tato bakalářská práce byla pro mě velikým přínosem v oblasti softwarového vývoje. Nejnáročnější, ale zároveň nejzajímavější částí z celého projektu byla pro mě samotná realizace systému. Zdokonalil jsem se ve spoustě technologiích a metodách v programátorském odvětví.

53

7. Použitá literatura

7. Použitá literatura [1] SQL Server 2005 Books Online - http://technet.microsoft.com/cscz/sqlserver/bb428874(en-us).aspx [2] Dokumentace PHP - http://www.cz.php.net/ [3] Prof. RNDr. Jaroslav Pokorný, CSc., Ing. Ivan Halaška, Databázové systémy, Vydavatelství ČVUT 2004 [4] Jim Arlow, Ila Neustadt, UML2 a unifikovaný proces vývoje aplikací, Computer Press, a.s., Brno 2007

54

8. Seznam obrázků a tabulek

8. Seznam obrázků a tabulek 8.1 Seznam obrázků Obrázek 1. Obrázek 2. Obrázek 3. Obrázek 4. Obrázek 5. Obrázek 6. Obrázek 7. Obrázek 8. Obrázek 9. Obrázek 10. Obrázek 11. Obrázek 12. Obrázek 13. Obrázek 14. Obrázek 15. Obrázek 16. Obrázek 17. Obrázek 18.

Ukázka tiskové sestavy objednávky ............................................................. 7 Hierarchie aktérů........................................................................................... 9 Use Case diagram – základní ...................................................................... 10 Use Case diagram – administrátorská úroveň ............................................ 11 Diagram schvalování objednávky............................................................... 17 Stavový diagram - modul zaměstnanec ...................................................... 19 Stavový diagram - modul operace .............................................................. 20 Stavový diagram - modul administrátor ..................................................... 21 Stavový diagram technika........................................................................... 22 Stavový diagram - modul vedoucí .............................................................. 23 Stavový diagram – modul ředitel ................................................................ 24 Stavový diagram - modul řešitel ................................................................. 25 Konceptuální model systému ...................................................................... 26 Architektura systému .................................................................................. 29 Logický datový model ................................................................................ 32 Nová objednávka ........................................................................................ 58 Objednávky k řešení ................................................................................... 59 Kategorie ..................................................................................................... 60

8.2 Seznam tabulek Tabulka 1. Tabulka 2. Tabulka 3. Tabulka 4. Tabulka 5. Tabulka 6. Tabulka 7.

Symboly Konceptuálního modelu .............................................................. 26 Datový slovník tabulky TUzivatele ............................................................ 34 Datový slovník tabulky TObjednavky ........................................................ 36 Datový slovník tabulky TObj_polozky ...................................................... 36 Datový slovník tabulky TObj_kategorie .................................................... 37 Datový slovník tabulky TOddeleni ............................................................. 38 Datový slovník tabulky TFirmy.................................................................. 39 55

8. Seznam obrázků a tabulek

Tabulka 8. Tabulka 11. Tabulka 12. Tabulka 13. Tabulka 14. Tabulka 15. Tabulka 16.

Datový slovník tabulky TLogy ................................................................... 39 Pole entity Kategorie .................................................................................. 42 Pole entity Dodavatel .................................................................................. 43 Pole entity Oddělení ................................................................................... 43 Pole entity Události ..................................................................................... 44 Popis souborů a jejich význam ................................................................... 46 Použité GNU knihovny............................................................................... 46

56

9. Přílohy

9. Přílohy Příloha k této práci je v rozsahu jednoho CD a několika ilustračních obrázků systému.

9.1 Obsah přiloženého CD CD disk obsahuje Objednávkový systém (OS), tuto práci ve formátech MS Word a PDF. Dále instalační balíčky MSSQL 2005 Express a PHP 5. Adresáře s instalacemi: MSSQL_2005_Express OS (Objednávkový systém) PHP Soubory: bp.doc bp.pdf

57

9. Přílohy

9.2 Ilustrační obrázky

Obrázek 16. Nová objednávka

58

9. Přílohy

Obrázek 17. Objednávky k řešení

59

9. Přílohy

Obrázek 18. Kategorie

60

Objednávkový systém. Jan Tichý

Recommend Documents