Sjednocení a redesign redak ního a informa ního systému autobazaru. Bc. Jind ich Hulín-Mihalec

eské vysoké u£ení technické v Praze Fakulta informa£ních technologií Katedra softwarového inºenýrství

Diplomová práce

Sjednocení a redesign redak£ního a informa£ního systému autobazaru Bc. Jind°ich Hulín-Mihalec

Vedoucí práce:

Ing. Milan aloudek

Studijní program: Informatika Obor: Webové a softwarové inºenýrství (magisterský) 6. kv¥tna 2013

iv

v

Pod¥kování Na tomto míst¥ bych cht¥l p°edev²ím pod¥kovat vedoucímu a zárove¬ zadavateli své práce Ing. Milanu aloudkovi za pomoc a uºite£né rady a moºnost realizace toho projektu. Také bych cht¥l velmi pod¥kovat v²em £len·m své rodiny a svým p°átel·m za podporu b¥hem psaní této práce.

vi

vii

Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).

Jind°ich Hulín-Mihalec

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

viii

Abstract The objective of this work is to design and imlement new information system of an used car company which will unife existing content management system of their websites and sales system. The work at the rst place describes the company, its needs, internal processes and current state of their system they've been using. Afterwards the funcionality of the systems takes its place as well as their bright and dark sides or functions of the systems which need to be kept or expanded and those which need to be changed or removed. In connection with the current state the problem is described in the next chapter together with the requirements to the new system. According to these requirements the analysis of the new system has been made and the next chapter is dedicated to that. It consists of description of requirements of the new system, description of users' roles and entites of the system and their relationships. At the end of this chapter some complicated precesses are described. The analysis closely follows a next chapter which deals with the design of the system and on the basis of requirements and analysis determines exact solutions for implementation. In the following chapter the implementation of the solution is parsed and described. Mainly it's about structure of the system and how it works in general. It's place in this chapter has also security of the application. The last chapter is about company's websites. A part of the assignment was to make necessary modications of the websites to connect them to the new system and also connect them to the Facebook page of the company. Keywords

Information system, Used car company, Content management system, Web analysis, System analysis, System design, System imlementation, Facebook

ix

x

Abstrakt Cílem této práce je navrhnout a implementovat nový informa£ní systém autobazaru, který bude sjednocovat dosavadní redak£ní systém webových stránek a prodejní systém. Práce na prvním míst¥ popisuje samotný autobazar, jeho pot°eby, interní procesy a sou£asný stav systém·, které pouºívá. Dále je popsána jeho funkcionalita, jeho sv¥tlé i stinné stránky, které funkce systému je pot°eba zachovat nebo roz²í°it a které naopak zm¥nit nebo dokonce zru²it. V návaznosti na popsaný sou£asný stav je v dal²í kapitole popsán samotný problém a poºadavky na nový systém. Na základ¥ t¥chto poºadavk· je pak provedena d·kladná analýza, která je v¥nována dal²í kapitola. Analýza zahrnuje popsání uºivatelských rolí, entit a jejich vztah· a návrh databáze. Na konci se tato kapitola zabývá rozborem n¥kterých sloºit¥j²ích proces·. Na analýzu úzce navazuje dal²í kapitola, která °e²í návrh systému a na základ¥ poºadavk· a analýzy ur£uje konkrétní °e²ení, která budou pouºita p°i implementaci. V následující kapitole je jiº rozebrána a popsána samotná implementace °e²ení. Popsána struktura systému a to, jak celkov¥ funguje. Sv·j prostor v této kapitole má i zabezpe£ení aplikace. Poslední kapitola se v¥nuje webu spole£nosti. Sou£ástí zadání bylo také provedení pot°ebných úprav webových stránek spole£nosti pro propojení s novým systémem a s Facebook stránkou spole£nosti. Klí£ová slova

Informa£ní systém, Autobazar, Redak£ní systém, Webová analýza, Analýza systému, Návrh systému, Implementace systému, Facebook

xi

xii

Obsah 1 Úvod

1

2 Cíl práce

3

3 Stávající systém a jeho historie 3.1 Webové stránky . . . . . . . . . 3.1.1 Z pohledu uºivatele . . . 3.1.2 Z pohledu programátora 3.2 Redak£ní systém . . . . . . . . 3.2.1 Z pohledu uºivatele . . . 3.2.2 Z pohledu programátora 3.3 Account - systém pro prodejce . 3.3.1 Z pohledu uºivatele . . . 3.3.2 Z pohledu programátora

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

5 5 5 6 7 7 9 10 10 11

4 Popis problému 4.1 Pro£ nový systém? . . . . . . . . . . . . . . . . . . . . 4.2 Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . 4.2.1 Jednotný systém pro administrátory i prodejce 4.2.2 Uºivatelské a jejich role . . . . . . . . . . . . . 4.2.3 P°ihla²ování do IS . . . . . . . . . . . . . . . . 4.2.4 Vyhledávání v IS . . . . . . . . . . . . . . . . . 4.2.5 Volba prodejny prodejce . . . . . . . . . . . . . 4.2.6 Editace hlavi£ky a pati£ky webu . . . . . . . . 4.2.7 Správa multimédií . . . . . . . . . . . . . . . . 4.2.8 Mapy . . . . . . . . . . . . . . . . . . . . . . . 4.2.9 Bannery . . . . . . . . . . . . . . . . . . . . . . 4.2.10 Správa voz· . . . . . . . . . . . . . . . . . . . . 4.2.11 Správa objednávek . . . . . . . . . . . . . . . . 4.2.12 Správa dokument· objednávek . . . . . . . . . 4.2.13 Dlouhodobé pronájmy . . . . . . . . . . . . . . 4.2.14 Správa prodejen a prodejc· . . . . . . . . . . . 4.2.15 Zákazníci . . . . . . . . . . . . . . . . . . . . . 4.2.16 Komunikace se zákazníky . . . . . . . . . . . . 4.2.17 Alarmy . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

13 13 13 14 14 14 15 15 15 15 15 16 16 16 17 17 17 17 18 18

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

xiii

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

xiv

OBSAH

4.2.18 lánky . . . . . . . . . . . . . . . . . . . . . 4.2.19 Skrývání poloºek . . . . . . . . . . . . . . . 4.2.20 Propojení stránek s Facebookem spole£nosti 4.3 Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . 4.3.1 UI systému . . . . . . . . . . . . . . . . . . 4.3.2 Zabezpe£ení systému a dat . . . . . . . . . 4.3.3 Roz²i°itelnost systému . . . . . . . . . . . . 4.3.4 Optimalizace pro mobilní za°ízení . . . . . . 4.3.5 Technologie . . . . . . . . . . . . . . . . . . 5 Analýza nového systému 5.1 Entit systému a jejich vztahy . . 5.1.1 V·z . . . . . . . . . . . . 5.1.2 Zna£ka . . . . . . . . . . . 5.1.3 Model . . . . . . . . . . . 5.1.4 Skupina voz· . . . . . . . 5.1.5 Typ historie . . . . . . . . 5.1.6 Historie vozu . . . . . . . 5.1.7 Zm¥na ceny vozu . . . . . 5.1.8 Typ p°íslu²enství . . . . . 5.1.9 P°íslu²enství vozu . . . . 5.1.10 Výbava vozu . . . . . . . 5.1.11 Parametr . . . . . . . . . 5.1.12 Jednotka . . . . . . . . . . 5.1.13 Hodnota parametru . . . 5.1.14 Hodnota parametru vozu 5.1.15 Prodejna . . . . . . . . . 5.1.16 Prodejce . . . . . . . . . . 5.1.17 Administrátor . . . . . . . 5.1.18 Právo administrátora . . . 5.1.19 Komunikace . . . . . . . . 5.1.20 Dotaz vozu . . . . . . . . 5.1.21 Poptávka nancování . . . 5.1.22 Hlídací pes . . . . . . . . 5.1.23 Odeslaný v·z . . . . . . . 5.1.24 Kontakt . . . . . . . . . . 5.1.25 Zákazník . . . . . . . . . . 5.1.26 Poznámka komunikace . . 5.1.27 Typ komunikace . . . . . 5.1.28 Zdroj zákazníka . . . . . . 5.1.29 Objednávka . . . . . . . . 5.1.30 Poloºka objednávky . . . 5.1.31 Úprava vozu . . . . . . . . 5.1.32 Banka . . . . . . . . . . . 5.1.33 Poji²óvna . . . . . . . . . 5.1.34 Faktura . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

18 19 19 19 19 19 20 20 20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21 21 21 22 23 23 23 23 23 23 23 24 24 24 24 25 25 26 26 26 26 27 27 27 28 28 28 28 29 29 29 30 30 31 31 31

xv

OBSAH

5.2

5.3 5.4 5.5

5.1.35 Zp·sob platby . . . . . . . . . . . . . . 5.1.36 Smlouva . . . . . . . . . . . . . . . . . . 5.1.37 Protokol . . . . . . . . . . . . . . . . . . 5.1.38 P°esun vozu . . . . . . . . . . . . . . . . 5.1.39 lánek . . . . . . . . . . . . . . . . . . . 5.1.40 Sloºka £lánk· . . . . . . . . . . . . . . . 5.1.41 Obrázek . . . . . . . . . . . . . . . . . . 5.1.42 Sloºka obrázk· . . . . . . . . . . . . . . 5.1.43 Soubor . . . . . . . . . . . . . . . . . . . 5.1.44 Sloºka soubor· . . . . . . . . . . . . . . 5.1.45 Mapa . . . . . . . . . . . . . . . . . . . 5.1.46 Místo mapy . . . . . . . . . . . . . . . . 5.1.47 Banner . . . . . . . . . . . . . . . . . . 5.1.48 Spole£nost . . . . . . . . . . . . . . . . . 5.1.49 Stát . . . . . . . . . . . . . . . . . . . . 5.1.50 Kraj . . . . . . . . . . . . . . . . . . . . 5.1.51 Okres . . . . . . . . . . . . . . . . . . . 5.1.52 Poloºka menu . . . . . . . . . . . . . . . Uºivatelské role . . . . . . . . . . . . . . . . . . 5.2.1 Superadmin . . . . . . . . . . . . . . . . 5.2.2 Hlavní administrátor . . . . . . . . . . . 5.2.3 Administrátor voz· . . . . . . . . . . . . 5.2.4 Administrátor komunikace se zákazníky 5.2.5 Administrátor £lánk· a multimédií . . . 5.2.6 Prodejce . . . . . . . . . . . . . . . . . . Interní procesy . . . . . . . . . . . . . . . . . . 5.3.1 P°esun vozu . . . . . . . . . . . . . . . . Objednávka vozu . . . . . . . . . . . . . . . . . Komunikace se zákazníkem . . . . . . . . . . . .

6 Návrh °e²ení nového systému 6.1 Prost°edky a technologie . . 6.1.1 PHP . . . . . . . . . 6.1.2 HTML . . . . . . . . 6.1.3 CSS . . . . . . . . . 6.1.4 JavaScript . . . . . . 6.1.5 AJAX . . . . . . . . 6.1.6 SQL . . . . . . . . . 6.1.7 MySQL . . . . . . . 6.2 Moduly . . . . . . . . . . . 6.2.1 jQuery . . . . . . . . 6.2.2 Bootstrap . . . . . . 6.2.3 jQuery File Upload . 6.2.4 prettyPhoto . . . . . 6.2.5 CKEditor . . . . . . 6.2.6 mPDF . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31 32 32 32 32 33 33 33 34 34 34 34 34 34 34 35 35 35 35 35 36 36 36 37 38 38 38 39 41

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

43 43 43 43 44 44 44 44 45 45 45 45 46 46 46 47

xvi

OBSAH

6.2.7 PHPMailer . . . . . . . . 6.3 Webové sluºby . . . . . . . . . . 6.3.1 Google Maps API . . . . 6.3.2 Facebook API . . . . . . . 6.3.3 AddThis . . . . . . . . . . 6.4 Uºivatelské rozhraní a navigace . 6.5 Struktura a architektura systému 6.6 Databáze . . . . . . . . . . . . . 6.6.1 Adminer . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

48 48 48 48 49 49 51 53 53

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

55 55 59 63 65 65 66 66 66 67 67 68 69

8 Úpravy webových stránek 8.1 Úvodní stránka . . . . . . . . . . . . . . 8.2 Katalog voz· . . . . . . . . . . . . . . . 8.3 Detail vozu . . . . . . . . . . . . . . . . 8.4 lánky . . . . . . . . . . . . . . . . . . . 8.5 Formulá°e . . . . . . . . . . . . . . . . . 8.6 Sociální sít¥ a jejich propojení s webem

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

71 71 72 73 75 75 75

7 Implementace nového systému 7.1 Sloºky a soubory systému . . 7.2 T°ídy . . . . . . . . . . . . . 7.3 Generování stránky . . . . . . 7.4 Pouºití modul· a sluºeb . . . 7.4.1 jQuery . . . . . . . . . 7.4.2 Bootstrap . . . . . . . 7.4.3 CKEditor . . . . . . . 7.4.4 prettyPhoto . . . . . . 7.4.5 mPDF . . . . . . . . . 7.4.6 PHPMailer . . . . . . 7.4.7 Google Mapy . . . . . 7.5 Zabezpe£ení . . . . . . . . . .

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

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

9 Záv¥r

77

A Seznam pouºitých zkratek

85

B Obsah p°iloºeného CD

87

Kapitola 1

Úvod Toto téma jsem si vybral pro svou diplomovou práci, protoºe jsem v n¥m vid¥l skv¥lou p°íleºitost spojit znalosti a zku²enosti z r·zných oblastí, které jsem do té doby nabyl a´ uº b¥hem studia a práce, r·zných brigád nebo jen pomocí v rodinné rm¥. B¥hem práce na informa£ním systému jsem p°edev²ím vyuºil n¥kolikaleté zku²enosti s vývojem CMS, internetových obchod· a jiných webových aplikací. Navíc jde o informa£ní systém autobazaru, kdy mohu pro lep²í porozum¥ní pot°eb spole£nosti nebo interních proces· uplatnit zku²enosti z letní brigády v autobazaru. Sou£ástí informa£ního systému je i práce s objednávkami, fakturami a dal²ími dokumenty, ve kterých se bez problému orientuji a vím jaké mají mít náleºitosti nebo jak se ú£tuje DPH, protoºe jiº od gymnázia pomáhám v rodinné rm¥, pro kterou v sou£asnosti spravuji i internetový obchod, kde se paragony a faktury také vyskytují. Podobné projekty jsem tedy jiº °e²il a mám také zku²enosti vhodné pro projekt sjednocení a implementace informa£ního systému autobazaru. Nikdy jsem ale ne°e²il spojení v²ech t¥chto v¥cí dohromady. Výb¥r tohoto projektu byl pro m¥ jak výzva, tak moºnost získání dal²ích zku²eností. Systém se bude vyvíjet pro reálný a fungující autobazar, který si z r·zných d·vod· nep°ál být v práci jmenován, bude tedy p°ípadn¥ ozna£ován jako Autobazar AB. Autobazar jiº funguje p°ibliºn¥ 10 let, b¥hem kterých pro²el mnohými zm¥nami, jako jsou jsou otevírání a ru²ení prodejen, zavedení franchizingu, vykupování voz· nebo roz²í°ení svých sluºeb nap°. o dlouhodobé pronájmy nebo nabízení prodlouºené záruky. M·ºe vypadat divn¥, ºe jsem nezmínil vykupování voz·, coº je u autobazar· b¥ºná v¥c. Autobazar AB ale nakupuje vozy p°edev²ím ze zahrani£í, dováºí je do ech, kde je podrobuje d·kladnému p°edprodejnímu servisu. Ze za£átku své £innosti se spole£nost cht¥la tvá°it více jako autosalon a slovo autobazar rad¥ji nepouºívat. Po nástupu krize a sníºení prodej· voz· ale museli zm¥nit strategii prodeje, nabídku voz· i své sluºby. Na za£átku nap°. byla k vozu poskytována záruka 1 rok, nyní pouze nabízejí moºnost si záruku dokoupit. V sou£asnosti má spole£nost jen jednu prodejnu v Praze, kde má vystavenu v¥t²inu voz·. Sídlo spole£nosti je ale v m¥ste£ku za Prahou, kde má servisní st°edisko, centrální sklad a kancelá°e. Abych se vrátil zpátky k informa£nímu systému, tak autobazar stále pouºívá stejný systém jako na za£átku. Samoz°ejm¥ stejn¥ jako autobazar, tak i tento systém pro²el mnohými zm¥nami. Z p·vodního systému, který umoº¬oval spravovat v podstat¥ jen katalog voz· a obsah webu na úrovni text· a obrázk·, se stal systém nep°eberných nan£ních a komunika£ních p°ehled·, objednávek, dokument· a velkého mnoºství r·zných dat. Protoºe toto 1

2

KAPITOLA 1. ÚVOD

na za£átku nikdo nep°edpokládal a i b¥hem vývoje a roz²i°ování funkcionalit bylo obtíºné p°edpovídat, jakým sm¥rem se bude systém ubírat dál, vznikl za t¥ch 10 let jeho fungování v systému trochu chaos a ob£as to podle slov vedení autobazaru dokonce vypadalo, ºe si systém za£íná ºít vlastním ºivotem. V posledních letech se systém poda°ilo stabilizovat, ale pot°eba jeho upgradu byla £ím dál tím v¥t²í, protoºe n¥které v¥ci v n¥m ne²ly ud¥lat nebo by náklady na n¥ byly p°íli² vysoké. Podrobn¥ji je stávající systém popsán v následující kapitole Stávající systém. Celkov¥ je práce rozd¥lena do ²esti kapitol, úvod a záv¥r nepo£ítaje. První kapitola jiº byla zmín¥na, pojednává o vlastnostech, funkcích a neduzích stávajícího systému. Zmi¬uje ale i n¥která dobrá °e²ení problému, ze kterých se pak vychází p°i vývoji nového systému. V dal²í kapitole je popsán samotný problém, který se °e²í, a p°edev²ím pak poºadavky na nový systém. Na základ¥ t¥chto poºadavk· je v dal²í kapitole nový systém d·kladn¥ zanalyzován, jsou popsány a denovány uºivatelské role, entity a jejich vztahy a jsou rozebrány interní procesy. Následující kapitola pak podle poºadavk· a analýzy sestavuje návrh °e²ení. Kapitola se zabývá navigací, jaké prost°edky budou pouºity, nebo jakou strukturu bude mít databáze. V p°edposlední kapitole je popsána samotná implementace systému, ukázána jeho struktura, uvedeny a popsány pouºité prost°edky, technologie a externí moduly, kterých systém vyuºívá. Poslední kapitola °e²í úpravy webových stránek v návaznosti na nasazení nového systému. Na úplném konci je v záv¥ru mimo jiné popsána reakce uºivatel·, coº jsou p°edev²ím zam¥stnanci autobazaru, na nový systém a zku²enosti z vývoje toho systému. Na záv¥r úvodu bych je²t¥ vysv¥tlil n¥které pojmy a výrazy, které jsou v textu práce pouºívány. asto se pouºívá výraz "správa"n¥jakých poloºek, nap°. vozu, objednávek nebo £lánku. Tento pojem hromadn¥ ozna£uje moºnost p°idávání, editace a mazání poloºek a p°ípadn¥ dal²ích operací, které jsou pro dané poloºky dostupné. Dal²ími výrazy jsou web, webové stránky nebo front-end, které ozna£ují jedno a to samé a to ve°ejnou £ást systému pro nep°ihlá²ené uºivatele. U stávajícího °e²ení v²ak tato £ást obsahuje i neve°ejnou sekci pro p°ihlá²ené zákazníky a prodejce. Opa£ným pojmem je back-end, který ozna£uje neve°ejnou £ást systému, která pro vstup vyºaduje autentizaci uºivatele. U stávájícího systému pojem back-end ozna£uje jak redak£ní systém, tak systém pro prodejce. U nového systému je to pak celý informa£ní systém. Pojem informa£ní systém (IS) si také zaslouºí krátké vysv¥tlení. V p°ípad¥ Autobazaru AB jde o systém, který umoº¬uje správu v²ech poloºek, které jsou pouºívané na webu (vozy, £lánky apod.) a zárove¬ °e²í n¥které interní systémy, jako je vy°izování objednávek, komunikaci se zákazníky nebo p°esuny voz· mezi prodejnami.

Kapitola 2

Cíl práce Cílem této práce je vytvo°it nový informa£ní systém pro autobazar, který nahradí dosavadní zastaralé a ²patn¥ spravovatelné systémy, které autobazar nyní pouºívá. Cílem samoz°ejm¥ není jen samotné vytvo°ení a nasazení systému, ale p°edev²ím zefektivn¥ní práce zam¥stnanc·, zjednodu²ení p°ístupu k dat·m a zavedení po°ádku do jejich evidence. Do stávajícího systému se tedy b¥hem 10 let jeho fungování p°id¥lávalo mnoho v¥cí, které se £asem bu¤ zm¥nily nebo se i p°estaly pouºívat. Od nového systému se tedy o£ekává i to, ºe v n¥m nebudou ºádné p°ebyte£né a zastaralé funkce nebo sekce a tím se celkov¥ zjednodu²í a zp°ehlední. A na konec dva nejd·leºit¥j²í cíle této práce, které jsou zárove¬ i hlavními d·vody autobazaru pro nákup nového systému, jsou sníºení náklad·, reºie a zvý²ení zisk·. Toho by m¥lo být dosaºeno zefektivn¥ním práce, které nový systému umoºní, a získáním nových zákazník· p°edev²ím ze sociálních sítí. Náklady se pak sníºí tím, ºe údrºba systému a p°ípadné roz²í°ení budou v novém systému mnohem jednodu²²í neº v dosavadních dvou, kdy se °ada v¥cí musí d¥lat duplicitn¥.

3

4

KAPITOLA 2. CÍL PRÁCE

Kapitola 3

Stávající systém a jeho historie Tato kapitola popisuje stávající °e²ení systém·, se kterými se v Autobazaru AB pracuje. Jde o t°i systémy, které pracují se stejnou databází a jsou v mnoha £ástech propojené. Konkrétn¥ to je systém front-endu, tedy webové stránky, a dva systémy back-endu - redak£ní systém a systém pro prodejce nazývaný Account. P·vodn¥ byly pouze webové stránky a redak£ní systém. Account vznikl dodate£n¥ a jeho sou£asná verze je dokonce jiº druhá. Jde tedy z t¥chto t°í systému o ten nejnov¥j²í. Byla snaha n¥které v¥ci z redak£ního systému p°esunout pod nov¥j²í a spolehliv¥j²í systém Accounta. To se ale ne vºdy povedlo, protoºe vedení spole£nosti bylo zvyklé na redak£ní systém a jeho propojení s Accoutem nebylo v n¥kterých p°ípadech snadno °e²itelné, a mnoho v¥cí se tak dlouho odkládalo nebo v·bec neud¥lalo. Nyní je situace taková, ºe se °ada v¥cí °e²í jak v redak£ním systému, tak v Accountu, a jsou tedy duplicitn¥, a kdyº se n¥co upravuje, musí se to d¥lat nadvakrát. Tato kapitola neanalyzuje ani ne°e²í problém stávajícího s systému, ale pouze ho popisuje, a to kaºdý systém zvlá²´ a ve dvou £ástech. V první £ásti je systém popsán z pohledu uºivatele a v druhé z pohledu programátora. 3.1

Webové stránky

3.1.1 Z pohledu uºivatele V sou£asné dob¥ má autobazar webové stránky, kde hlavní a zárove¬ výchozí stránkou je katalog voz·. Vozy v katalogu lze ltrovat podle mnoha r·zných parametr·, zna£kou a cenou po£ínaje a pohonem 4x4 nebo typem záruky kon£e. Proklikem p°es poloºku se vstoupí na detail vozu, kde jsou na jednom míst¥ ve²keré informace o voze. Ve°ejn¥ p°ístupné jsou fotograe, název, popis, parametry, výbava, p°íslu²enství, soubory a dal²í. Jsou zde také kontakty na prodejní místo, prodejce a odkazy na °adu formulá°· pro rezervaci, dotaz na prodejce nebo zadání poptávky jiného vozu. Stránky mají také neve°ejnou £ást pro p°ihlá²ené prodejce, kte°í mohou p°es dal²í formulá°e v kart¥ vozu ºádat o p°esun vozu na prodejnu, vytvá°et rezervace a objednávky voz· pro n¥jakého zákazníka, nebo p°idat k vozu dotaz, kdyº zákazník kontaktuje prodejce ne p°es web, ale p°es telefon, email nebo osobn¥. P°ihlá²ený prodejce si v detailu vozu m·ºe 5

6

KAPITOLA 3. STÁVAJÍCÍ SYSTÉM A JEHO HISTORIE

také zobrazit historii vozu, kde vidí historii cen, co se s vozem d¥lo p°ed nasazením do prodeje, jaké na n¥j byly poptávky, kdy a kam byl p°esouván a také d·leºité interní soubory. Dále jsou na webu stránky s formulá°i pro výkup voz· a zadání poptávky na n¥jaký v·z ur£itých parametr·. A je²t¥ na stránce Franchizing je schovaný formulá° pro zájem o spolupráci. Ten se ale jiº nevyuºívá, protoºe spole£nost po n¥kolika ²patných zku²enostech od franchizingu upou²tí. Zbylé stránky jsou vesm¥s oby£ejné £lánky, kde lze najít informace o spole£nosti a jejích sluºbách nebo informace o vozech, nap°. jaký je rozdíl mezi automatickou a manuální p°evodovkou. Trochu speciálním £lánkem je stránka Napsali o nás, kam se dopl¬ovaly informace, kdyº se Autobazar AB objevil n¥kde v médiích. Stránka je uº ale n¥kolik let neaktualizovaná. Odli²nou kapitolou je je²t¥ sekce kontakty, která je trochu d¥laná ve stylu katalogu, kdy na úvodu je seznam prodejen obohacený o bannery infolinky, centrály a servisního st°ediska a v detailu prodejny jsou pak fotograe, její prodejci, mapa a dal²í informace. V sou£asné dob¥, kdy je pouze jedna prodejna, ale seznam trochu postrádá smysl. Podobn¥ jako mají prodejci svou neve°ejnou £ást, existuje neve°ejná £ást i pro registrované zákazníky. V tomto zákaznickém rozhraní m·ºe uºivatel editovat své osobní údaje, které se pak pouºívají pro jeho p°ípadné kontaktování autobazarem nebo p°i vystavování r·zných dokument·. Také má k dispozici svou zákaznickou historii u Autobazaru AB, to znamená p°ehled ve²keré poptávky, které provedl p°es formulá°e na webu, objednávky nebo koup¥ vozu. Bohuºel moºnost se zaregistrovat není náv²t¥vníky webu moc vyuºívána. V sou£asné dob¥ je z celkových cca 3000 zákazník· zaregistrováno pouhých 15.

3.1.2 Z pohledu programátora Stránky (stejn¥ jako i redak£ní systém) byly p·vodn¥ jednovrstvé architektury, tedy v jednou souboru se odehrávalo v²e - SQL dotazy na databázi, zpracovávání dat i sestavování HTML kódu. Coº je velice nesystémové a náro£né na orientaci v kódu. Nap°. skript pro administraci voz· má takto cca 4500 °ádk·. N¥které skripty jiº byly p°ed¥lány do t°ívrstvé architektury, ale zrovna administrace voz·, která to uº dlouhou dobu pot°ebuje nejvíce, ji práv¥ kv·li svému rozsahu nemá. U webu byly nap°íklad p°ed¥lány skripty katalogu, detailu vozu a v¥t²iny formulá°· v£etn¥ výkupu a hlídacího psa (poptávka). V²echny ostatní stránky jsou ale stále nep°ed¥lané a a£ jde o stránky, které mají v podstat¥ stejnou strukturu, tak z hlediska databáze, skript· a administrace nemají jedinou v¥c spole£nou. Úpln¥ na za£átku totiº neexistovalo nic jako entita oby£ejný £lánek, který by bylo moºné pouºít na r·zných místech systému, ale ke kaºdé stránce systému se p°istupovalo individuáln¥. Na za£átku byly nap°. jen £lánky o spole£nosti, které byly v DB v tabulce o_spolecnosti. asem se d¥laly £lánky o vozech, které se v databázi nazvaly dulezite_informace a takto se po pokra£ovalo i p°i dal²ích roz²í°eních nejen u £lánk·. Skripty, které byly p°ed¥lány do t°ívrstvé architektury, jsou relativn¥ nové, dob°e a p°ehledn¥ psané a p°edev²ím se v nich jiº pracuje s objekty. Ty byly poprvé nadenovány v samostatném (alespo¬ co se skript· týká) systému pro prodejce zvaném Account, který je zhruba t°i roky starý. Práce s objekty velice usnadnila práci jak v samotném Accountu, tak na stránkách a v redak£ním systému, kam jsou t°ídy includovány, a je tak moºné v nich s nim pracovat. Systém Account je podrobn¥ popsán na konci této kapitoly.

3.2. REDAKNÍ SYSTÉM

3.2

7

Redak£ní systém

V redak£ním systému Autobazaru AB je n¥kolik uºivatelský rolí nap°. pro editaci voz· nebo sledování a správu poptávek a komunikace se zákazníky. Uºivatelské role ale v této kapitole probírány nebudou, protoºe jde vºdy v podstat¥ jen o omezení práv super administrátora.Nedávno do²lo ve spole£nosti k n¥kolika personálním zm¥nám a uºivatelské role v sou£asnosti p°esn¥ neodpovídají práv·m jednotlivých zam¥stnanc· pro p°ístup k dat·m v systému. Redak£ní systém bude tedy popsán komplexn¥ bez ohledu na uºivatelské role.

3.2.1 Z pohledu uºivatele Redak£ní systém je rozd¥len do sedmi hlavních sekcí - Katalog, Objednávky a p°esuny, P°ehledy, Prodejny, Oslovení zákazník·, Kariéra a Obrázky. Sekce Katalog má mnoho podsekcí jako jsou Zna£ky a modely, Dodavatelé, Banky a jiné správy poloºek více £i mén¥ souvisejících s vozy. Hlavními podsekcemi jsou ale katalogy voz·, které se d¥lí na ekonomické, p°edvád¥cí, nové, v komisním prodeji a vozy classic (veteráni). Pro uºivatele takto rozd¥lené katalogy nejsou úpln¥ ideální. asto se totiº stává, ºe n¥jaký v·z je v jiném katalogu, neº si uºivatel myslí, a v kombinaci s mnoha moºnostmi ltrování je pro n¥j problém v·z najít. Dál se v katalogu dají editovat vozy, jejich obrázky, soubory, dotazy zákazník· a prohlíºet historii. P°ímo v editaci vozu je jeden extrémn¥ dlouhý formulá°, kterým se na jednom míst¥ °e²í parametry vozu, jeho nancování, p°edprodejní servis, d·leºitá data o voze, systémové v¥ci, p°íslu²enství a výbavu. Toto si uºivatelé op¥t zrovna nechválí uº jen proto, ºe jediné tla£ítko pro uloºení je aº naspodu formulá°e a také chybí varianta pro uloºení a z·stání ve formulá°i. Vedle toho není ani moºné p°ejít z edita£ního formulá°e nap°íklad k obrázk·m vozu. Je t°eba se vrátit zp¥t do seznamu voz· a tam kliknout na p°íslu²nou ikonku. Obrázky i soubory je pak sice moºné nahrát hromadn¥, ale jen po deseti a kaºdý soubor musí být na disku vybrán samostatn¥, coº je v p°ípad¥ nahrávání t°eba i 70 fotograí dost zdlouhavé. Dotazy na v·z budou popsány pozd¥ji spole£n¥ s dal²ími typy komunikace se zákazníky. Dal²í podsekce sekce Katalog jsou nap°. Dodavatelé, Banky, Poji²óvny, Zna£ky a modely nebo Skupiny voz·. V²echny tyto sekce mají spole£né to, ºe na jejich úvodu je seznam poloºek, ze kterého je pak moºné se dostat k p°idávání poloºek, editaci nebo mazání. Poloºky se pak p°i°azují v edita£ním formulá°i vozu. Dal²í sekcí po Katalogu jsou Prodejny. V této £ásti redak£ního systému se spravují jak prodejny, tak prodejci. Jedna prodejna m·ºe mít více prodejc· a to samé platí i naopak, protoºe nap°. obchodní °editel je jako prodejce u v²ech prodejen uº jen proto, aby byl uveden v kaºdém detailu vozu a prodejny. Administrace prodejen a prodejc· je celkem dob°e ud¥laná aº pár v¥cí, jako je historická moºnost zadávat jazykové mutace nebo n¥kolik zahrani£ních sklad· mezi prodejnami, které se uº dávno nikde nepouºívají. Trochu v¥t²í nedostatek je, ºe nelze p°i°azovat prodejce k prodejnám, lze to pouze naopak. V sekci Objednávky a p°esuny jsou, jak název napovídá, odkazy na p°ehledy objednávek a p°esun· voz· mezi prodejnami a vedle toho také p°ehledy prodej· a dokument·, které s objednávkami a prodeji souvisí, tedy faktury, smlouvy a prodejní protokoly. Tento p°ehled ale vznikl jakýmsi nedorozum¥ním a zákazník ho vlastn¥ v·bec necht¥l a nepouºívá ho. Nicmén¥ se tam uº nechal. Co se týká p°ehled· objednávek a prodej·, tak jde pouze o strohý p°ehled, a pokud chce administrátor s poloºkou n¥co d¥lat, je odkázán do systému pro prodejce.

8


V podsekci p°ehledy má pak ve²keré p°esuny voz·, které se kdy uskute£nily, ale i ty, které se je²t¥ neuskute£nily. Ty také m·ºe schválit nebo zamítnout. Samoz°ejm¥ je v p°ehledu (jako i v jiných) moºnost ltrace podle stavu a data vytvo°ení. Velmi jednoduchá sekce Kariéra pracuje pouze s pár £lánky, i p°esto má ale t°i podsekce. Franchizing, Volná místa a Externí spolupracovník. V kaºdé v t¥chto podsekcích je seznam £lánk·. V posledních dvou je ale £lánek jen jeden. V podsekci Franchizing jich je sice více, ale na stránkách se pak stejn¥ zobrazují v podstat¥ jako jeden na jedné stránce pod sebou. A v této podsekci se ani ne°e²í poptávky na franchizing zadané p°es formulá°. Ty jsou z n¥jakého d·vodu v sekci P°ehledy. Ve v²ech podsekcích pak lze £lánky p°idávat, editovat i mazat. U £lánku lze ale zadat jen název, text a obrázek. Sekce Oslovení zákazník· je pom¥rn¥ r·znorodá. P·lku podsekcí tvo°í r·zné £lánky, o kterých by se dalo °íct, ºe mají oslovit zákazníky a p°im¥t je koupit si v·z v Autobazaru AB. Tro²ku úsm¥vné je, ºe vedle t¥ch n¥kolika podsekcí s r·znými £lánky je zde i samotná podsekce nazvaná lánky. Dále v této sekci je správa typ· komunikace nebo druh· reklamní kampan¥, coº je n¥co jako "kde se o nás zákazník dozv¥d¥l". Dal²í podsekce shromaº¤uje ve²keré emaily zákazník· sesbírané ze v²ech formulá°·, kde se email zákazníka vkládá. Dal²í podsekce pak na tuto navazuje a vytvá°í se tam mail pro hromadnou rozesílku. Zákazník v²ak toto sám nevyuºívá, ale rozeslání mailu vºdy zadá rm¥ DIS Media s.r.o., která mail sestaví, provede testování a pak mail roze²le. Poslední podsekcí je sekce Alarmy, kde jsou poznámky, které si vytvá°ejí v¥t²inou sami prodejci p°es Account, aby nap°. kontaktovali n¥jakého zákazníka kv·li n¥jakému vozu, který poptával, nebo aby nezapomn¥li p°ipravit v·z p°ed domluvenou zku²ební jízdou. Ve zvolený £as pak systém pomocí webcronu po²le prodejci mail. Takovou upomínku m·ºe prodejci zadat i administrátor v této podsekci Alarmy p°es redak£ní systém. P°ehledy související s vozy, jejich prodejem a se zákazníky jsou v p°edposlední sekci P°ehledy. Konkrétn¥ jsou zde p°ehledy nakoupených, neprodaných a prodaných voz·. Podsekce Prodané vozy navíc obsahuje hned n¥kolik p°ehled· podle r·zných souvislostí, nap°. prodané vozy v daném období nebo na dané prodejn¥. Také je zde v podstat¥ duplicitní p°ehled rezervací. Tém¥° totoºný p°ehled je v sekci Objednávky a prodeje. V této sekci jsou p°ehledy komunikace zvlá²´. Kaºdý formulá°, kterým m·ºe zákazník kontaktovat autobazar, má svou stránku s p°ehledem a nechybí ani p°ehled sdruºující v²echny tyto poptávky a dotazy. Ke kaºdé komunikaci se zákazníkem lze p°es redak£ní systém i p°es Account dopl¬ovat poznámky v£etn¥ soubor·. Vedle komunikace se zákazníky je zde i správa zákazník·, kde je moºné je editovat, mazat a prohlíºet jejich historii, £ímº se p°edev²ím myslí objednávky, poptávky apod. K dispozici je také p°ehled upomínek prodejc·m, které se automaticky zasílají, kdyº prodejce del²í dobu nereaguje na poptávku od zákazníka. Posledním p°ehledem jsou nabídky zadané p°es formulá° na webu na stránce Franchizing. V²echny zmín¥né p°ehledy, p°edev²ím pak ty s komunikací a vozy, mají nespo£et r·zných ltr·. Poslední sekcí jsou Obrázky. Zde jsou jen dv¥ podsekce - Obrázky pro web a Obrázky press. Do obrázk· pro web jsou nahrávány obrázky, které se pak p°idávají ke £lánk·, p°i°azují k prodejc·m nebo prodejnám. Obrázky k voz·m jsou, jak jiº bylo zmín¥no, °e²eny samostatn¥. Obrázky pro web jsou t°íd¥ny do sloºek. Jsou zde ale jen jednoduché operace p°idání, editace a mazání sloºky. To samé je u obrázk· jen s tím rozdílem, ºe lze nahrát více obrázku najednou, je to ale stejn¥ ne²ikovn¥ jako u voz·. Podsekce Obrázky press je totoºné struktury jako Obrázky pro web, akorát tyto obrázky se pouºívají pro stránku Napsali o nás.

3.2. REDAKNÍ SYSTÉM

9

Poslední v¥c, kterou je z uºivatelského hlediska pot°eba zmínit, je p°ihla²ování uºivatele a jeho údaje. P°i p°ihlá²ení do systému uºivatel zadává uºivatelské jméno a heslo. Pro p°ihlá²ení má z bezpe£nostních d·vod· t°i pokusy, pokud se ani napot°etí nep°ihlásí, p°ihla²ování se zablokuje a uºivatel musí kontaktovat správce systému. P°ihla²ování má jeden hlavní nedostatek, ºe si nepamatuje poslední zadané uºivatelské jméno a administrátor ho tedy p°i kaºdém p°ihlá²ení musí zadat znovu. Po p°ihlá²ení si uºivatel m·ºe heslo do systému zm¥nit, editace jiných údaj· není k dispozici.

3.2.2 Z pohledu programátora Redak£ní systém bereme jako samostatný systém, ale mnoho £ástí má spole£ných s frontendem. Nap°. inicializa£ní soubor, soubor s funkcemi nebo r·zné moduly. Jde ale jen o £ásti, které by nebyl problém ud¥lat pro oba systém zvlá²´. Není to ale nutné, není to zdroj ºádných problém·. První místo v této podkapitole mají op¥t katalogy voz·. Ale vzhledem k tomu, ºe je na n¥ nahlíºeno o£ima programátora, jde o jeden katalog, protoºe v²echny katalogy zpracovává jeden skript. A to zcela doslova, protoºe celý katalog je °e²en jediným souborem, ve kterém se míchají SQL dotazy na databázi, zpracování dat a výpis HTML kódu. Tento soubor má p°ibliºn¥ 4500 °ádk· kódu. Rozd¥lení jednotlivých £ástí kódu je velmi chabé, slab¥ okomentované a bez jakékoliv °ádu. V kombinaci s pom¥rn¥ ²patn¥ psaným kódem je pro programátora celý skript velmi nep°ehledný. Nijak zabaleno do funkce £i t°ídy není ani hromadné nahrání soubor· nebo obrázk·. V tomto souboru není vid¥t ºádné pouºití objekt· nebo znovupouºití kódu, kdyº se nepo£ítá includování souboru hlavi£ky a pati£ky, které se provádí v kaºdé £ásti, která vypisuje n¥jaký HTML kódu. Tento jednovrstvý p°ístup není v redak£ním systému nijak ojedin¥lý. Katalog je ale jediný, který je jednovrstvé architektury a ve kterém se stále pravideln¥ n¥co upravuje. Podle slov programátora z rmy DIS Media s.r.o. nebyly zatím prost°edky, ani £as a ani odvaha ve stávajícím systému ten skript p°ed¥lat. Ostatní skripty nap°. pro p°ehledy komunikace nebo objednávky a prodeje byly p°ed¥lány na dvouvrstvou nebo nov¥ji t°ívrstvou architekturu, kdy se vyuºívá t°íd denovaných v systému pro prodejce. Dvou i t°ívrstvé °e²ení mají spole£né to, ºe jeden soubor °e²í aplika£ní logiku stránky a ten druhý prezenta£ní. U dvouvrstvé architektury se pro získávání dat z DB nevyuºívá t°íd, ale dotazuje se p°ímo v aplika£ní logice. Soubory s dvouvrstvou architekturou vznikaly t¥sn¥ p°edtím, neº vznikla druhá verze Accounta, která uº je celá °e²ena t°ívrstv¥ a SQL dotazy se nevyskytují jinde neº ve t°ídách. U v¥t²iny výpis· poloºek v systému je n¥jaký ltr. Formulá°e t¥chto ltr· jsou odesílány metodou POST a jejich stavy se ukládají do session. Toto °e²ení je sice elegantní, ale neudrºuje stav ltru p°i p°eposílání adres. P°i programátorských pracích na redak£ním systému se samoz°ejm¥ hodn¥ pracuje i s databází. Jak jiº bylo zmín¥no, databáze je pro v²echny systémy autobazaru jen jedna, protoºe se ve v²ech systémech pracuje v¥t²inou se stejnými data. V databázi je nyní 98 tabulek, které dohromady obsahují p°ibliºn¥ 15 MB dat. N¥kolik tabulek je nepouºívaných, eventueln¥ pouze tak, ºe udrºují n¥jaká historická data. Nap°. sou£asné objednávky jsou v tabulce objednavky_2. V tabulce objednavky jsou objednávky první verze systému pro prodejce. U nov¥ tvo°ených nebo upravených tabulek se ºádné poloºky nemaºou, ale pouze ozna£ují jako smazané, aby se data dala p°ípadn¥ obnovit. Toto je velice uºite£né u tabulky katalog,

10


které obsahuje vozy. Pro zajímavost - tato tabulka má 111 sloupe£k· a 8 dal²ích tabulek s p°idruºenými daty. V tabulce jsou totiº sloupe£ky pro zadávání údaj· o servise, nancích a jiných v¥cech, které by si zaslouºily samostatnou tabulku. 3.3

Account - systém pro prodejce

Systém pro prodejce Account °e²í v²echny pot°eby prodejen a potaºmo jejich prodejc· pro prodej voz· a komunikaci se zákazníky. Toto jsou dv¥ hlavní v¥ci, které prodejci pro svou práci pot°ebují. V systému je také správa a p°ehled p°esun· voz·, p°ehled upomínek ke komunikaci se zákazníky a moºnost si vytvá°et p°ipomínky, které se zasílají mailem. Tento systém je pro uºivatele daleko p°ív¥tiv¥j²í neº webové stránky a redak£ní systém. A z hlediska programátora je rozdíl systém· je²t¥ výrazn¥j²í. Kdyby p°edchozí dva systémy byly °e²ené stejn¥ jako Account, tedy ºe jejich architektura by byla t°ívrstvá a pouºívaly se t°ídy a objekty, pak by bylo moºné vývoj a nasazení nového systému je²t¥ o pár let odloºit.

3.3.1 Z pohledu uºivatele Jelikoº redak£ní systém a Account jsou dva odd¥lené systém, je i p°ihla²ování °e²eno zvlá²´ a p°ihla²ovací údaje jsou pro jednoho zam¥stnance jiné, i kdyº má p°ístup do obou systém·. Tyto údaje jsou mezi sebou propojeny, a pokud se administrátor z redak£ního systému snaºí dostat do Accounta, ale není do n¥j p°ihlá²en, systém ho automaticky p°ihlásí. Samotné p°ihla²ování do systému pro prodejce je jiº o t°ídu vý²e. Pokud se uºivateli poda°í systém zablokovat n¥kolika nesprávnými pokusy o p°ihlá²ení, ale zadal alespo¬ správné uºivatelské jméno a má vypln¥ny email, je mu na n¥j poslán odkaz pro odblokování. P°i p°ihla²ování si prodejce také m·ºe vybrat prodejnu, pod kterou se chce p°ihlásit, pokud je samoz°ejm¥ p°i°azen k více prodejnám. Výb¥r prodejen se okamºit¥ upravuje podle zadaného uºivatelské jména. Po p°ihlá²ení je moºné prodejnu zm¥nit v hlavi£ce systému. Oproti redak£nímu systému má prodejce v Accountu moºnost zm¥ny více osobních údaj·. Mezi jinými i uºivatelské jméno nebo email, na který se mu p°ípadn¥ posílá odkaz pro odblokování p°ihla²ování. V menu jsou £ty°i poloºky - Vozy, Zákazníci, Komunikace se zákazníky a Alarmy. Sekce Vozy a Komunikace se zákazníky mají n¥kolik podsekcí. Sekce Zákazníci a Alarmy odkazují rovnou na správu a p°ehled daných poloºek. V sekci Vozy jsou do samotných podsekcí odd¥leny rezervace, objednávky a prodeje i kdyº jde v podstat¥ o jednu entitu akorát v r·zném stavu. Ve v²ech t°ech podsekcích je na první stránce seznam poloºek se základními informacemi, nejd·leºit¥j²í jsou ty o vozu a zákazníkovi. Dále je u kaºdé poloºky odkaz na vypln¥ní údaj· k objednávce, které zahrnují p°edm¥t prodeje (v·z, p°íslu²enství, prodlouºena záruka apod.), smluvní strany a nancování. Pokud jde o objednávku (potvrzenou rezervaci) nebo prodej, je zárove¬ umoºn¥n p°ístup do manaºeru dokument·, kde se spravují faktury, smlouvy a protokoly. Ve t¥chto dokumentech se pak pracuje s údaji, které byly vypln¥ny u objednávky. Nap°. u faktury se automaticky p°edvyplní údaje o dodavateli a odb¥rateli a poloºky faktury se vybírají z poloºek objednávky, které byly zvoleny v p°edm¥tu prodeje. Dal²í podsekce je v¥nována dlouhodobým pronájm·m, coº je opravdu kapitola sama pro sebe. Na moºnosti vy°izovat dlouhodobé pronájmy p°es Accounta se pracovalo asi dva

3.3. ACCOUNT - SYSTÉM PRO PRODEJCE

11

roky. Toto roz²í°ení sice m¥lo velkou prioritu, ale vºdy se objevilo n¥co, co m¥lo vy²²í. Po dvou letech, kdy se tento úkol dokon£il za£ala spole£nost od dlouhodobých pronájm· upou²t¥t. Co se týká této funkcionality, tak je velice podobná objednávkám. Nejv¥t²í rozdíly jsou, ºe se navíc °e²í ukon£ování pronájm·, p°ejímací protokoly nebo splátkový kalendá°. Poslední podsekcí jsou P°esuny vozu, kde je pouze p°ehled p°esun· vázaných na prodejnu, kterou má prodejce zrovna zvolenou, a moºnost editovat a prohlíºet protokoly. Editovat m·ºe jen p°edávací nebo p°ejímací podle toho, jestli v·z p°edává nebo p°ejímá. Na tomto míst¥ nelze o p°esun ºádat, to je pot°eba ud¥lat v detailu vozu na webu. Sekci Zákazníci není t°eba popisovat, protoºe je úpln¥ stejná jako ta, co je v redak£ním systému. Jde o jedu z n¥kolika v¥cí, která je kv·li nesjednocení Accounta a redak£ního systému °e²ena duplicitn¥. Problém duplicit je i u v²ech podsekcí sekce Komunikace se zákazníky krom¥ jedné a tou jsou upomínky, které prodejci nebo prodejn¥ chodí automatiky, pokud na komunikaci dlouho nereagují. P·vodní vize vedení Autobazaru AB byla ta, ºe pokud bude odeslána t°etí upomínka, budou z toho vyvozovány n¥jaké d·sledky. V praxi to ale zatím moc nefunguje. Tato funkcionalita tedy spí² jen zaji²úje, aby se prodejce nezapomn¥l n¥jakému zákazníkovi ozvat, pokud si sám nevytvo°il p°ipomínku v sekci Alarmy. Jen ve zkratce k ostatním podsekcím Komunikace se zákazníky. K dispozici jsou tedy jednotlivé p°ehledy v²ech typ· komunikací se zákazníky a zárove¬ p°ehled, kde jsou v²echny typy na jednom míst¥. P°ehledy jednotlivých typ· tedy nemají moc smysl, ale celkový p°ehled se d¥lal relativn¥ nedávno a ty ostatní se nechaly být. Stejn¥ jako v redak£ním systému lze i v Accountu ke kaºdému vláknu komunikace p°idávat poznámky i se soubory. Jediný rozdíl oproti redak£nímu systému je, ºe prodejce vidí pouze komunikace, které spadají pod prodejnou, pod kterou je zrovna p°ihlá²en. Poslední sekcí jsou Alarmy, které uº také byly zmín¥ny u redak£ního systému a v podstat¥ jsou také duplicitní. Rozdíl je podobn¥ jako u komunikace, ºe prodejce vidí jen alarmy, které se týkají jeho (sám si je vytvo°il nebo mu je vytvo°il administrátor) nebo celé prodejny, kterou má práv¥ zvolenou. Alarmy mohou být samostatn¥ nebo mohou být p°i°azeny k ur£ité komunikaci.

3.3.2 Z pohledu programátora Jak jiº bylo zmín¥no, sou£asné verze systému pro prodejce je jiº druhá v po°adí. První verze by se dala nazvat samostatným systém jen st¥ºí. Byla to spí²e sou£ást front-endu jako jeho neve°ejná £ást. Ze za£átku Account slouºil jen pro jednoduchou správu objednávek. asem ale p°ibylo vystavování faktur a smluv a za£aly p°ibývat problémy, které se staly sou£ástí kaºdého dne a neda°ilo se je rozumn¥ °e²it, protoºe systém byl od za£átku ²patn¥ navrºen. Za£al se tedy p°ipravovat nový systém. V po£áte£ním návrhu druhé verze se jen po£ítalo s dvouvrstvou architekturou. Pak se ale ve rm¥ DIS Media p°e²lo na OOP. Na²t¥stí to bylo v po£átku vývoje systému, takºe se jen upravily návrhy a systém se za£al vyvíjet uº jako t°ívrstvý. Byly nadenovány t°ídy pro kaºdou entitu, se kterou se po£ítalo v systému pro prodejce. Mezi t¥mito entitami byla samoz°ejm¥ i entita V·z, která je st¥ºejní i pro ostatní dva systémy. Obecn¥ vytvo°ení t°íd neusnadnilo práci jen s Accountem, ale i s webem a redak£ním systémem, protoºe se t°ídy naincludovaly i tam. Postupn¥ se dodenovávaly dal²í t°ídy, se

12


kterými se sice v Accountu nepracuje, ale ze systémového hlediska bylo lep²í je vytvá°et v rámci jednoho systému a v ostatních systémech si je pouze "p·j£ovat". V sou£asné dob¥ existují t°ídy tém¥° pro v²echny entity vyskytující se nap°í£ v²emi systémy Autobazaru AB. Výjimkou jsou r·zné typy £lánk·, kterým se od jejich vzniku nikdo moc nev¥noval, takºe zatím ani nebyla pot°eba je p°ed¥lávat tak, jako tomu bylo nap°. u Hlídacího psa nebo p°edtím výkupu voz·. "P°edtím"proto, ºe p°ed n¥jakou dobou výkupy p°estaly být st°edem zájmu spole£nosti, o £emº uº bylo psáno v Úvodu.

Kapitola 4

Popis problému V této kapitole je popsáno, pro£ se vlastn¥ vyvíjí nový systém, co je d·vodem a co vedlo Autobazar k této investici. Dále jsou v této kapitole uvedeny poºadavky zadavatele a Autobazaru AB na systém, které zjednodu²en¥ popisují jeho základní funkce. 4.1

Pro£ nový systém?

Po p°e£tení p°edchozí kapitoly je d·vod asi z°ejmý. B¥hem t¥ch deseti let, co sou£asný systém funguje, se z n¥j stala zm¥´ nejednotných skript·, tabulek v databázi, sloºek a soubor·. Pokra£ovat dál s tímto systémem je jen cesta k n¥jakému problému, a kdyº ne to, tak minimáln¥ k vysokým náklad·m na údrºbu. Jakákoliv úprava je totiº uº te¤ dosti nákladná a´ uº proto, ºe se d¥lá ve starém jednovrstvém kódu, nebo proto, ºe se d¥lá nadvakrát pro redak£ní systém a pro Accounta. Náklady na po°ízení nového systému jsou sice pom¥rn¥ vysoké, ale kaºdý m¥síc autobazar u²et°í za výdaje na údrºbu. Dal²í d·vod je, ºe UI systému není tak p°átelské, jak by mohlo s pouºitím dne²ních technologií být. To zpomaluje práci jak vedení, kdyº pracuje s redak£ním systémem, tak ale p°edev²ím prodejc·m p°i jejich kaºdodenní práci s Accountem. Sníºená efektivita práce s sebou také samoz°ejm¥ nese ur£ité náklady. Nepo°ádek v databázi a celkové pro£i²t¥ní systému od funkcionalit, které se jiº dávno nevyuºívají, je také jedním z d·vod·, pro£ se autobazar rozhodl od stávájícího systému upustit. V jedné v¥t¥ shrnuto - Autobazar si od nového systému slibuje sníºení náklad·, zvý²ení efektivity práce se systémem a zavedení po°ádku v datech. 4.2

Funk£ní poºadavky

Funk£ní poºadavky popisují operace, které m·ºe uºivatel v systému provád¥t. Funkce, které m·ºe vyuºívat, a vlastnosti systému, které uºivatel p°i práci s ním p°ímo pociúje. 13

14

KAPITOLA 4. POPIS PROBLÉMU

4.2.1 Jednotný systém pro administrátory i prodejce Uº nebudou ºádné dva back-end systémy pro prodejce a administrátory webu ani neve°ejná £ást front-endu, které £asto duplikovala to, co bylo dostupné v back-endu. Bude pouze jeden systém, který bude umoº¬ovat spravovat uºivatele a jejich práva pro vstup do ur£itých sekcí a moºnosti provád¥ní operací s daty a poloºkami v systému. Informace a dokumenty k voz·m, které byly dostupné v neve°ejné sekci front-endu, budou v novém IS dostupné ve správ¥ voz·.

4.2.2 Uºivatelské a jejich role Náv²t¥vník webu má moºnost pouze prohlíºet katalog voz·, jejich detaily, £lánky a odesílat formulá°e pro n¥j ur£ené. Moºnost registrace a p°ihla²ování náv²t¥vník· se prozatím v novém systému d¥lat nebude. Dal²ím uºivatelem systému je prodejce, který se m·ºe p°ihla²ovat informa£ního systému, a tam spravovat ve²keré poloºky ur£ené jemu, prodejn¥, pod kterou je p°ihlá²en, nebo prohlíºet poloºky pot°ebné k prodeji, jako jsou t°eba vozy. V ºádném p°ípad¥ je ale nesmí editovat. Stejn¥ tak nesmí prodejce spravovat obsah front-endu, ani jakékoliv jiné údaje o spole£nosti, nebo vid¥t nan£ní detaily voz· nebo prodej·. Finan£ními detaily se myslí p°edev²ím nákupní ceny, výdaje a zisky. Prodejce také nesmí spravovat ºádné dal²í uºivatele systému. Dal²ími uºivateli budou administráto°i pro r·zné sekce. Jedním bude administrátor voz·, který se bude starat od p°idávání a editaci voz· a o údaje a data k nim p°i°azená. Dal²í administrátor se bude starat o obsah webu nepo£ítaje katalog voz·. M¥l by mít tedy moºnost spravovat jednotlivé kapitoly, texty a obrázky na webu. Posledním administrátorem s omezenými právy bude správce komunikace se zákazníky. Na rozdíl od prodejce ale uvidí komunikace v²ech prodejen najednou (samoz°ejm¥ s moºností ltrování). Posledním b¥ºným uºivatelem systému bude hlavní administrátor, který bude mít p°ístup v²ude a bez omezení pro prodejny nebo prodejce. Také bude mít moºnost spravovat v²echny administrátory a prodejce. Pochopiteln¥ od zadavatele, tedy od rmy DIS Media, je poºadavek je²t¥ na jednu roli, a tou je Superadmin, který bude stát je²t¥ nad hlavním administrátorem. U kaºdého uºivatele musí mít nad°ízený administrátor moºnost denovat jeho práva v systému podle individuálních pot°eb. Uºivatelské role tedy nejsou pevn¥ dané.

4.2.3 P°ihla²ování do IS P°ihla²ování do systému jiº nebude moºné z webových stránek. Systém (a tím pádem i jeho p°ihla²ování by) m¥l být umíst¥n na neobvyklé adrese, nic jako /admin, /account, /cms nebo n¥co podobného. Adresa na systém by ani nem¥la být nikde uvád¥na, m¥li by ji znát jen zam¥stnanci spole£nosti. P°ihla²ování musí být dostate£n¥ zabezpe£eno proti napadení hackery. P°ihla²ování si musí pamatovat uºivatelské jméno a prodejnu z posledního p°ihlá²ení. P°i automatickém odhlá²ení, kdy vypr²ela session, si systém musí pamatovat adresu, ze které uºivatele odhlásil, a po p°ihlá²ení ho na ní vrátit.

4.2. FUNKNÍ POADAVKY

15

Neexistuje nic jako trvalé p°ihlá²ení nebo moºnost neodhla²ovat a ani moºnosti zaslání nového hesla v p°ípad¥ jeho zapomenutí. V takovém p°ípad¥ musí uºivatel kontaktovat správce systému.

4.2.4 Vyhledávání v IS Moºnost vyhledávání nejd·leºit¥j²ích poloºek v systému, to jsou - vozy, £lánky, objednávky, komunikace a multimédia.

4.2.5 Volba prodejny prodejce Pokud je uºivatel prodejce a je p°i°azen k více prodejnám, musí mít jiº p°i p°ihla²ování moºnost si vybrat, pod kterou prodejnou se chce p°ihlásit. Po p°ihlá²ení musí mít moºnost toto snadno zm¥nit.

4.2.6 Editace hlavi£ky a pati£ky webu Administrátor musí mít moºnost editovat údaje v hlavi£ce webu a tím se myslí jak údaje, které budou zobrazované náv²t¥vník·, tak ty, které budou v hlavi£ce HTML kódu, p°edev²ím tag title a metatag description. Do hlavi£ky webu se po£ítá i hlavní menu, jehoº editace musí být administrátorovi také umoºn¥na. Poloºky menu mohou mít jednu úrove¬ podpoloºek. Po°adí v²ech poloºek musí jít libovoln¥ ur£ovat a musí být moºné poloºky v menu p°e°azovat pod jiné poloºky nebo do první úrovn¥. Stejnou moºnost editovat údaje musí mít administrátor i pro pati£ku webu, kde budou základní údaje spole£nosti a copyright ve tvaru rok_od - rok_do. Editovat by se m¥l jen po£áte£ní rok_od, rok_do by se m¥l na£ítat automaticky podle aktuálního roku.

4.2.7 Správa multimédií Informa£ní systém musí administrátor·m umoº¬ovat práci s obrázky a soubory. Ty pak musí jít p°i°azovat k poloºkám r·zného typu (£lánek, v·z atd.). Obrázk· a soubor· se p°edpokládá velké mnoºství, takºe musí být moºné vytvá°et nekone£nou stromovou strukturu sloºek, do kterých se budou dát poloºky °adit. S °azením do sloºek ale musí být moºnost hromadných operací jako je p°idávání, mazání, kopírování a p°esouvání poloºek i celých sloºek.

4.2.8 Mapy U £lánk· by m¥la být moºnost vloºit mapu. Vedle Kontakt·, kde by mohla být mapa napevno, m·ºe být vytvo°en £lánek nap°. o výstav¥, které se Autobazar AB ú£astní a chce vloºit mapu s lokací výstavy. U map by m¥la být moºnost do nich vkládat neomezený po£et míst, ke kterým by se m¥ly dát p°idat obrázky, popisky a odkazy.

16


4.2.9 Bannery Na webu spole£nosti se p°ipravuje umisóvání banner· a to nejen r·zných partner·, ale p°edev²ím upoutávek na sluºby, produkty a vozy autobazaru. Správa t¥chto banner· by také m¥la být sou£ástí IS.

4.2.10 Správa voz· K vozu se v základu vedou údaje jako zna£ka, model, VIN, cena a mnoho dal²ích údaj· popisujících v·z a jeho stav a vybavenost. N¥které poloºky, které jsou napevno dané jako zna£ky nebo paliva nebo poloºky, se kterými se pracuje i jinde neº u vozu (jako jsou t°eba banky), by m¥lo být moºné p°ípadn¥ p°idávat, editovat nebo mazat. Dále musí být u vozu moºnost dopl¬ovat jeho historii, zm¥ny cen nebo opravy a to v£etn¥ moºnosti dopln¥ní nan£ních údaj·. Vozy se °adí do skupin a to tak, ºe jeden v·z m·ºe být i v n¥kolika skupinách najednou. K voz· m·ºe být také n¥jaké p°íslu²enství jako zahrádka nebo zimní pneumatiky, které se musí dát do systému zadat. D·leºitou sou£ástí vozu jsou jeho fotograe, které musí být moºné pohodln¥ p°idávat, protoºe jich je kolikrát n¥kolik desítek. Soubor· je u voz· mén¥, ale musí se dát rozli²ovat na ve°ejné a neve°ejné, kdy neve°ejné soubory mohou vid¥t pouze prodejci. V²echny vozy by m¥ly být pohromad¥ v jednom p°ehledu, ale samoz°ejm¥ s moºností ltrování. Nejd·leºit¥j²í je ltrování podle zna£ky a modelu, podle VINu a podle skupiny.

4.2.11 Správa objednávek Objednávky musí být rozd¥lené podle stavu, které jsou t°i. První je rezervace, coº je vlastn¥ nepotvrzená objednávka, kdy je prodej vozu teprve ve fázi jednání. Rezervaci m·ºe provád¥t i zákazník p°es formulá° na webu. Rezervací na jeden v·z m·ºe být i více. Dal²í fáze objednávky je, kdyº je potvrzena n¥jakým prodejce, coº znamená, ºe prodej vozu uº se uskute£¬uje. Objednávce v takovém stavu se °íká práv¥ objednávka. Objednávka v tomto stavu uº m·ºe být pouze jedna. Nicmén¥ rezervace je dále moºné vytvá°et pro p°ípad, ºe by i tak z obchodu se²lo. V této fázi se uº vystavují v²echny dokumenty pot°ebné k prodeji. A posledním stavem je prodej, kdy se po p°edání vozu p°esune objednávka mezi vy°ízené, tedy prodané. I v této fázi musí jít ale editovat v²echny údaje a dokumenty pro p°ípadné opravy nebo dodate£né zm¥ny. Údaje, které se u rezervací a objednávek vypl¬ují, musí z·stat stejné jako ve stávajícím systému. V první °ad¥ o p°edm¥t prodeje, kde jsou ve²keré poloºky, které jsou p°edm¥tem obchodu - v·z, prodlouºená záruka, úpravy vozu, p°íslu²enství a dal²í. Dal²í skupinou údaj· jsou smluvní strany, kde se dopl¬ují údaje o odb¥rateli, tedy zákazníkovi, a dodavateli, kterým je prodejna a konkrétní prodejce. Poslední jsou údaje o nancování koup¥ vozu. U platby hotovostí nebo p°evodem se ºádné údaje nedopl¬ují. Jinak je tomu ale u úv¥ru a leasingu. U rezervací se editují pouze údaje smluvních stran a pár údaj· k samotné rezervaci.

4.2. FUNKNÍ POADAVKY

17

4.2.12 Správa dokument· objednávek U potvrzený objednávek a prodej· se spravují dokumenty pot°ebné k prodeji vozu. T¥mi jsou faktury, smlouvy a protokoly. Texty a forma t¥chto dokument· musí z·stat zachovány, tím pádem musí z·stat stejné i ve²keré údaje, které se u dokument· vypl¬ují. Dokumenty jsou na výstupu tak, jak mají být. Zachovány musejí z·stat také v²echny typy dokument·. Faktura m·ºe být typu zálohové, prodejní nebo dobropisu. Smlouvy mohou být rezerva£ní nebo kupní a ob¥ jsou závislé na faktu°e. Rezerva£ní smlouva je závislá na zálohové faktu°e a kupní smlouva na prodejní faktu°e. Bez ur£ení, ke které faktu°e smlouva pat°í, nesmí být smlouva vystavena. Posledním dokumentem je protokol a ten je pouze jednoho typu a to prodejního. Tento dokument má výjimku v tom, ºe se mohou zm¥nit vypl¬ovaná data a forma dokumentu. Nicmén¥ musí n¥jakým zp·sobem z·stat moºnost ve²keré pot°ebné údaje do protokolu zadat.

4.2.13 Dlouhodobé pronájmy S dlouhodobými pronájmy se zatím v novém systému nepo£ítá, protoºe by se nevyuºily. Systém by m¥l být ale navrºen s ohledem na to, ºe v budoucnu je bude pot°eba dod¥lat.

4.2.14 Správa prodejen a prodejc· U prodejny se musí pro pot°eby webu zadávat údaje jako adresa, otevírací doba a p°i°azovat prodejci. Také se na webu musí prodejna zobrazovat na map¥ a musí u ní být fotky. Pro interní pot°eby je d·leºitý kód prodejny, podle kterého se generují £ísla faktur, a typ, který se zatím bude vyuºívat je pro rozli²ení, jestli jde prodejnu, sklad nebo servis. V budoucnu se budou pro r·zné typy ur£ovat r·zná práva a operace, které mohou v systému provád¥t. Prodejci nesou pouze jméno, kontaktní údaje, funkci a obrázek. Ur£ování vztahu mezi prodejci a prodejnami musí být moºné v obou sm¥rech. Jak u prodejen musí jít p°i°adit prodejci, tak u prodejc· prodejny. A to p°edev²ím proto, ºe kdyº p°ibude nová prodejna nebo nový prodejce, tak aby bylo moºné najednou ur£it vztahy a nemuselo se nap°. u kaºdé prodejny zvlá²´ p°i°azovat nového prodejce.

4.2.15 Zákazníci Údaje o zákaznících se sbírají ze v²ech formulá°·, které mohou uºivatelé na webu odesílat. Systém musí být schopný stejné zákazníky, kte°í autobazar kontaktují vícekrát, sdruºovat. Moºnost registrace zákazníka a jeho p°ihla²ování se na stránkách, kde pak m¥l uºivatelskou sekci se svou historií a kontaktní formulá°e se mu p°edvypl¬ovaly, se zru²í. Jak jiº bylo zmín¥no, v databázi je nyní 3000 zákazník·, ale jen 15 registrovaných a pravd¥podobn¥ jen málo z nich p°ihla²ování v·bec vyuºívá. Zachovávat tuto funkcionalitu tedy nemá smysl. V informa£ním systému musí být kompletní p°ehled v²ech zákazník·, kde bude také moºnost editovat jejich údaje a prohlíºet jejich historii - poptávky, hlídací psi nebo objednávky.

18


4.2.16 Komunikace se zákazníky Komunikace zpravidla vzniká odesláním n¥jakého formulá°e na webu zákazníkem. Komunikaci m·ºe ale také zaloºit prodejce, kdyº zákazník nap°. p°ijde na prodejnu a poptává v·z. Prodejce tedy musí mít moºnost takovéto dotazy sám zadat do systému. Komunikací je tedy n¥kolik typ·: • dotazy na v·z do zákazníka, • dotazy na v·z zadané prodejcem, • rezervace vozu zákazníkem, • rezervace nebo objednávka vozu vytvo°ená prodejcem, • poptávka na nancování vozu, • hlídací pes (poptávka vozu ur£itých parametr·).

V novém systému by oproti stávajícímu uº nem¥ly být p°ehledy jednotlivých typ·, ale celkový p°ehled v²ech komunikací. Ke kaºdé komunikaci musí být moºné psát libovolný po£et poznámek a p°idávat k nim soubory. Po ukon£ení komunikace by m¥l systém umoº¬ovat komunikaci uzav°ít, aby bylo jasné, ºe byla vy°ízena. U komunikací zadávaných prodejci a stejn¥ tak u poznámek je pot°eba ur£ovat typ komunikace se zákazníkem (mailem, osobn¥, telefonicky apod.). Samoz°ejm¥ v p°ehledu komunikací musí být moºnost ltrování a to p°edev²ím podle vozu, zákazníka a prodejny. Ve stávajícím systému se také °e²í upomínání prodejc·, pokud dlouho nereagují na n¥jakou komunikaci tedy, ºe dlouho nedoplnili ºádnou poznámku nebo komunikaci neuzav°eli. Tato funkcionalita zatím v novém systému °e²ena nebude, protoºe se v praxi neosv¥d£ila. Do budoucna by m¥la fungovat pouze na bázi p°ipomínání. O tom více v dal²í podkapitole Alarmy.

4.2.17 Alarmy Alarmy, jak se nazývají p°ipomínky ve stávajícím systému, se v novém zatím d¥lat nebudou. Kaºdý zam¥stnance Autobazaru AB je nyní vybaven by´ i jednoduchým telefonem se systémem Android, aby mohl vyuºívat sluºeb Google odkudkoliv. P°ipomínky se nyní °e²í p°es Google Kalendá° a alarmy ve stávájícím systému se nevyuºívají.

4.2.18 lánky Jednoduché stránky webu by m¥ly být jednotné a snadno editovatelné. M¥ly by do nich jít jednodu²e p°idávat obrázky, ale i soubory nebo mapu. Formátování textu by m¥lo být zaji²t¥no n¥jakým textovým editorem, který bude um¥t pracovat i s obrázky, odkazy a tabulkami.

4.3. NEFUNKNÍ POADAVKY

19

4.2.19 Skrývání poloºek Tém¥° ve²keré poloºky by m¥lo být moºné skrývat p°ed uºivateli, kterým se vypisují. V p°ípad¥ £lánk· nebo voz· to jsou náv²t¥vníci webových stránek. V p°ípad¥ systémových poloºek jsou tito uºivatelé sami prodejci nebo administráto°i. To proto, aby je poloºky, které nejsou nap°. aktuální, nemátly p°i n¥jakém zadávání údaj·.

4.2.20 Propojení stránek s Facebookem spole£nosti Nov¥ zaloºené Facebook stránky Autobazaru AB by se m¥ly propojit s webem spole£nosti. Hlavním propojením by m¥l být velký box, kde bude jak tla£ítko "Líbí se mi", tak p°ísp¥vky p°idané na FB stránky a obli£eje lidí, kterým se stránka líbí. Stránky by s FB m¥ly být propojené i pomocí odkaz· pro sdílení na kaºdé stránce. 4.3

Nefunk£ní poºadavky

Nefunk£ní poºadavky popisují dal²í vlastnosti systému a poºadavky na n¥j, které uºivatel nemusí p°ímo pocióvat nebo si je uv¥domovat.

4.3.1 UI systému Uºivatelské rozhraní systému by m¥lo být jednotné a intuitivní. Ovládací prvky by m¥ly být dob°e a jasn¥ popsané, aby bylo jasné, co se stane p°i jejich pouºití. Systém by m¥l být dob°e provázán, aby se snad dostávalo do jiných £ástí systému, kterou jsou na dané stránce relevantní, a ke v²em akcím, které jsou pro danou poloºku nebo poloºky k dispozici. V systému by se také nem¥ly objevovat obrovské formulá°e nebo "nekone£né"seznamy poloºek. Velké stránky by m¥ly být rozd¥leny na men²í, ale tak aby mezi sebou byly snadno dostupné. A seznamy poloºek by m¥ly být p°i velkém po£tu stránkované. V u seznam· poloºek by také m¥lo být ltrování podle relevantních parametr·, kterým je tém¥° vºdy alespo¬ název. Stejn¥ tak by m¥la být v seznamech moºnost °azení, pokud existuje více sloupe£ku, podle kterých má °azení význam. Práce se systémem by m¥la být jednoduchá, co nejpohodln¥j²í, rychlá a efektivní. V IS v pati£ce stránky by m¥la být doba generování stránky na serveru, aby uºivatel v¥d¥l, ºe p°ípadné dlouhé na£ítání je zp·sobené spojením se serverem a ne n¥jaký problémem v systému.

4.3.2 Zabezpe£ení systému a dat Zabezpe£ení systému a dat, se kterými se v n¥m pracuje je velice d·leºité a m¥la by mu být kladena vysoká priorita. Systém by m¥l být chrán¥n jak proti útok·m z venku (hacke°i, roboti, spamy), tak zevnit°. Ochranou zevnit° se myslí p°edev²ím to, aby se minimalizovalo riziko, ºe n¥jaký uºivatel napáchá v systému nevratné ²kody a´ uº schváln¥ nebo omylem. Uºivatel by hlavn¥ nem¥l mít moºnost se jakkoliv dostat tam, kam nemá oprávn¥ný p°ístup.

20


4.3.3 Roz²i°itelnost systému Autobazar AB je ºivá spole£nost, která p°ichází s novými produkty a sluºbami a r·zn¥ se m¥ní. Je tedy pot°eba, aby se i s tím p°i vývoji systému po£ítalo a byl exibilní, aby nebyl problém s p°ípadnými roz²í°eními £i zm¥nami. Také musí jít znovu pouºívat jiº vytvo°ené komponenty systému.

4.3.4 Optimalizace pro mobilní za°ízení Systém musí pracovat a být pouºitelný i na mobilních za°ízeních a to p°edev²ím na tabletech, protoºe prodejny byly vybaveny tablety, které pouºívají nap°. p°i obcházení voz· se zákazníkem.

4.3.5 Technologie Systém pob¥ºí na serveru rmy DIS Media, kde je nainstalován Apache s PHP 5.3 a s databází MySQL 5. Plánuje se ale v blízké dob¥ upgrade na verzi PHP 5.4. P°i vývoji a implementaci systému se s tím tedy musí po£ítat a v podstat¥ systém vyvíjet pro tuto vy²²í verzi, aby po upgradu systém bez problému fungoval. Systém by m¥l také vyuºívat, pokud je to moºné, jiº hotových modul·, které jsou jiº odzkou²ené a mají dobrou dokumentaci.

Kapitola 5

Analýza nového systému V této kapitole je popsána analýza celého systému, která je provedena na základ¥ poºadavk· popsaných v p°edchozí kapitole a která poslouºí jako podklad pro návrh a implementaci. Metod pro analýzu webových aplikací je sice celá °ada, p°i analýze informa£ního systému Autobazaru AB ale nebylo pln¥ vyuºito ºádné. Nejvíce v²ak bylo vycházeno z metodiky WebML[27]. Ta dnes v podstat¥ jiº neexistuje, protoºe se zm¥nila na IFML[13], coº je nový standard p°ijatý OMG[20] pro modelování UI. První místo v analýze zaujímá popis v²ech entit vyskytujících se v systému, vý£et jejich hlavních atribut· a popis vztah· s jinými entitami. Pro znázorn¥ní vztah· sloºí n¥kolik diagram·. Dal²í podkapitolou analýzy jsou Uºivatelské role, kde jsou popsáni jednotliví uºivatelé systému, jejich hierarchie a práva. Tato podkapitola je dopln¥na Use-Case diagramy, které zobrazují práva a moºnosti uºivatel· v systému. Poté jsou v dal²í £ásti rozebrány interní procesy autobazaru dopln¥né o Activity Diagramy. Ve²keré diagramy, které jsou v této kapitole, byly vytvo°eny online nástrojem Gliy1 , který umí vytvá°et r·zné druhy diagram·. Pro pot°ebu této kapitoly sta£ily diagramy typu UML, BPMN a ERD. 5.1

Entit systému a jejich vztahy

V této £ásti jsou popsány ve²keré entity, se kterými se v systému pracuje, a jejich v vzájemné vztahy. Jelikoº je entit pom¥rn¥ dost (cca 50) a n¥které vztahy jsou relativn¥ komplikované a rozsáhlé, jsou pro lep²í orientaci v t¥chto vztazích a závislostech p°iloºeny Entity Relationship Diagramy. Pro popsání kardinalit v ERD byla pouºita notace Information Engineering[8].

5.1.1 V·z V·z je jedna z nejv¥t²ích entit v systému. Nejv¥t²ích my²leno tak, ºe se u ní vede nejvíce dat a má nejvíce vazeb na dal²í entity. Hlavními atributy jsou VIN, cena, DPH, popis a n¥kolik p°íznak· nap°. jestli je moºný odpo£et DPH, instalace LPG nebo si dokoupit prodlouºenou záruku. 1

http://www.gliy.com

21

22

KAPITOLA 5. ANALÝZA NOVÉHO SYSTÉMU

Entita má také dal²í atributy, které slouºí k propojení s následujícími entitami - Zna£ka, Model, Obrázek, Banka a Prodejna. Obrázek u vozu samoz°ejm¥ není jeden, ale atribut obrazek_id ur£uje hlavní obrázek vozu, který je jednodu²e p°ístupný a pouºitelný kdekoliv je t°eba. Vazba k entita Banka ur£uje, v p°ípad¥ ºe v·z není nancován vlastními prost°edky autobazaru, jaká banka v·z nancuje. Prodejna pak dává informaci, jakému prodejnímu místo v·z náleºí. Dále má entita V·z vazbu na entitu Skupina voz·, kdy jeden v·z m·ºe být ve více skupinách (nap°. ojeté vozy a o-road). Dal²í vazba je s entitou Zm¥na ceny vozu, která hovo°í o cenové historii vozu. Vazba s entitou Historie vozu ur£uje konkrétní událost spojením Typu historie a dopln¥ním dal²ích údaj·. Podobn¥ fungující a £áste£n¥ související je i vazba Vozu na P°íslu²enství. Vazby s ob¥ma t¥mito entitami budou je²t¥ blíºe rozebrány v jejich popisu. Dal²ími vazbami jsou spojení mezi Vozem a Výbavou, Vozem a Obrázky a Vozem a Soubory, kdy v²echny zmín¥né entity mohou mít libovolné mnoºství spojení s prot¥j²í entitou. Je pot°eba dodat, ºe V·z m·ºe mít stejné spojení i se entitami Sloºka obrázk· a Sloºka soubor·, aby nemusely být obrázky a soubory p°i°azovány jen samostatn¥, ale i po sloºkách. Tyto dv¥ vazby nejsou v ER Diagramu uvedeny kv·li jeho uº tak velkému rozsahu. V·z má je²t¥ dal²í vazby s entitami Hodnota parametru vozu, Odeslané vozy hlídacího psa, Komunikace, Objednávka, Faktura, Smlouva a Protokol. Tyto vazby budou ale podrobn¥ popsány dál v této kapitole u p°íslu²ných entit. Skupina

ZměnaCeny

Historie

původni cena nová cena vytvořeno

datum tachometr cena dph

Prodejna

Značka

Příslušenstvi

Vůz

TypPřislušenství

Výbava

Hodnota ParametruVozu

Model

Banka

TypHistorie

Parametr

financuje

Obrázek

Soubor

Obrázek 5.1: Diagram vztah· entit (ERD) pro v·z

5.1.2 Zna£ka Na rozdíl od Vozu je entita Zna£ka jedna z t¥ch nejjednodu²²ích. Obsahuje jediný d·leºitý atribut a tím je název. Vazby na dal²í entity má pak jen dv¥. Jednou je o£ekávan¥ vazba na V·z a druhou vazba na Modely vozu, kdy jich zna£ka m·ºe mít libovolné mnoºství.

5.1. ENTIT SYSTÉMU A JEJICH VZTAHY

23

5.1.3 Model Entita Model je v podstat¥ stejná jako entita Zna£ka, jediný rozdíl je ten, ºe musí mít vazbu na práv¥ jednu Zna£ku.

5.1.4 Skupina voz· Skupina voz· je entita, která umoº¬uje ur£ovat, jestli v·z pat°í mezi osobní vozy, jestli je nový, p°edvád¥cí nebo ojetý nebo t°eba jestli má náhon 4x4. Toto by samoz°ejm¥ ²lo °e²it p°es n¥jaké atributy nebo parametry vozu, ale skupiny poskytují v¥t²í volnost a mají více moºností vyuºití.

5.1.5 Typ historie Typ historie denuje jednotlivé události v "ºivot¥"vozu u Autobazaru AB. Takovou událostí m·ºe být nákup, p°edprodejní servis, nasazení do prodeje nebo prodej vozu. Jedinou vazbou této entity je spojení s entitou Historie vozu, která ur£uje konkrétní událost, která nastala.

5.1.6 Historie vozu Tato entita má vyuºití ve vedení historie vozu, kdy se ur£uje o jakou událost (nákup, oprava, prodej) ²lo, kdy to bylo, kolik to stálo a kolik m¥l v té dob¥ v·z najeto. Z t¥chto informací pak lze sestavovat jak £istou historii vozu, tak nan£ní p°ehledy.

5.1.7 Zm¥na ceny vozu K nan£ním p°ehled·, které jsou ale i pro zákazníka slouºí entita Zm¥na ceny vozu, která pomocí údaj· o p·vodní a nové cen¥ a datum zm¥ny zaznamenává cenovou historii vozu.

5.1.8 Typ p°íslu²enství Typ p°íslu²enství slouºí k denování p°íslu²enství, která mohou k voz·m být. T¥mi mohou být nap°. pneumatiky, zahrádka, zimní °et¥zy nebo kobere£ky pod nohy. Typ p°íslu²enství má samoz°ejm¥ název a je²t¥ stojí za zmínku atribut po°adí, který ur£uje po°adí p°íslu²enství p°i výpise, aby se nap°. p°ední pneumatiky nevypisovali za zadními. Podobn¥ jako Typ historie i tato entita má pouze jednu vazbu a to s konkrétním P°íslu²enstvím vozu.

5.1.9 P°íslu²enství vozu Tato entita jiº pracuje s konkrétním p°íslu²enstvím, které pat°í k ur£itému vozu. Spojuje Typ vozu, V·z samotný a dopl¬uje údaje jako popis, nákupní cena, prodejní cena a DPH. M·ºe se tedy p°idat k Historii vozu jako k entit¥, ze které lze získat n¥jaké informace o nancích.

24


5.1.10 Výbava vozu Entita Výbava vozu stojí samostatn¥ bez nutnosti ur£ování n¥jakého typu a dopl¬ování dal²ích údaj· jako je tomu u P°íslu²enství. Tato entita má pouze jednu vazbu s entitou V·z a to tak, ºe V·z m·ºe mít libovolných po£et vazeb s entitou Výbava. Naopak to samoz°ejm¥ platí také. Atributy jsou zde akorát dva zásadní a to název a po°adí, pomocí n¥hoº se op¥t ur£uje po°adí poloºek na výstupu a tedy jejich priorita a atraktivita u voz·.

5.1.11 Parametr Entita V·z v dosavadním systému má 111 atribut·, kdy pár desítek t¥chto atribut· by mohlo být ozna£eno parametry vozu. Takovými atributy m·ºe být stav tachometru, barva, palivo nebo p°evodovka. Proto je v novém systému navrºena entita Parametr, která takovéto atributy sdruºuje. Jelikoº ale mezi atributy (nap°. tachometr a barva) jsou zásadní rozdíly a to v typu jejich hodnoty a v tom, ºe n¥které mají jednotku a jiné ne, je entita Parametr a její vazby trochu komplikovan¥j²í. Parametr má tedy atributy název a popis, který °íká konkrétn¥ji, o £em daný parametr je. Dále má atributy typ hodnoty a po°adí. Typ hodnoty ur£uje, jakého typu je hodnota parametru, jestli jde o £íslu, interval, text, výb¥r n¥jaké hodnoty, plochu a nebo prostor. Atribut po°adí má stejnou funkci jako u entity Výbava vozu. Entita m·ºe mít vazbu na entitu Jednotka a ur£it tak, ºe nap°. u stavu tachometru má být uvedeno, ºe daná hodnota je v kilometrech. Pokud má Parametr typ hodnoty nastavený na výb¥r, denují se vazby je²t¥ na entitu Hodnota parametru. Hodnota Parametru

Jednotka

Parametr

název zkratka

typ hodnoty

Hodnota ParametruVozu hodnota nebo ID hodnoty

Vůz

Obrázek 5.2: Diagram vztah· entit (ERD) pro parametr vozu

5.1.12 Jednotka Jednotka má pouze atribut název a zkratka. Zkratka je to, co se p°idává za hodnotu parametru, nap°. u kilometru je to tedy km. Vazba na Parametr je jediná vazba, kterou entita má. Jedna jednotka ale m·ºe být p°i°azena více parametr·m, protoºe nap°. kilometry mohou být jak u stavu tachometru, tak u záruky omezené kilometry.

5.1.13 Hodnota parametru Tato entita se pouºívá s entitou Parametr pouze tehdy, kdyº má Parametr atribut typ hodnoty výb¥r, coº znamená, ºe p°i zadávání hodnoty parametru u vozu se hodnota vybírá

25


z n¥jaké nadenované mnoºiny hodnot. Toto lze vyuºít nap°. u parametru barva, kde se nadenují hodnoty bílá, £erná, modrá atd. U hodnot je moºné ur£ovat po°adí, aby bylo moºné nejvíce pouºívanou hodnotu dát na za£átek výb¥ru. Hodnota musí být p°i°azena práv¥ jednomu parametru a m·ºe mít vazbu s entitou Hodnota parametru vozu.

5.1.14 Hodnota parametru vozu Pokud se zvolí n¥jaká hodnota parametru u n¥jakého vozu, má jí tato entita na starost. Má n¥kolik atribut· pro hodnoty v²ech typ· - £íslo, interval (od, do), text, výb¥r (vazba na entitu Hodnota parametru), plocha (²í°ka, vý²ka) a prostor (²í°ka, vý²ka, hloubka). Entita má tedy vazbu jak na Parametr, tak na V·z a v p°ípad¥ typu hodnoty výb¥r je²t¥ na Hodnotu parametru.

5.1.15 Prodejna Entita Prodejna nemusí reprezentovat pouze prodejnu, ale i sklad nebo servis autobazaru, to rozli²uje atribut typ. Primárn¥ je ale entita vyuºívána pro prodejny, u kterých se ur£uje název a kód pro interní pot°eby spole£nosti. Kontaktní údaje prodejny jako jsou adresa, telefon nebo email jsou °e²eny propojením s entitou Kontakt. Podobn¥ je °e²en i obrázek prodejny projením s entitou Obrázek. Rozdíl je ale ten, ºe obrázek prodejna mít nemusí, ale kontaktní údaje ano. Prodejna má také vazbu s Prodejcem, kdy Prodejna m·ºe mít libovoln¥ prodejc·. Dal²í vazby m·ºe mít na entity Objednávka a Komunikace a samoz°ejm¥ na V·z, coº jiº bylo uvedeno.

Vůz

Prodejna

Kontakt

Objednávka

Prodejce

Obrázek

Komunikace

Administrátor Obrázek 5.3: Diagram vztah· entit (ERD) pro prodejnu

26


5.1.16 Prodejce Prodejce reprezentuje zam¥stnance autobazaru, který je na n¥jaké prodejn¥, kde komunikuje se zákazníky a prodává vozy. Od toho se také odvíjejí jeho vazby na dal²í entity. Jakousi hlavní vazbu má na entitu Prodejna, kdy ale jeden prodejce m·ºe být p°i°azen více prodejnám. Dal²í vazbu má prodejce na komunikace, ale ne p°ímo, nýbrº p°es entitu Poznámka komunikace. Dal²í vazby má pak na entity týkající se prodeje voz· a t¥mi jsou Objednávka, Faktura, Smlouva a Protokol. Entita má vcelku podobné atributy jako Prodejna, akorát samoz°ejm¥ nemá název. Jméno a p°íjmení jsou sou£ástí entity Kontakt, se kterou je Prodejce propojen. Také nemá ºádný atribut kód, ale navíc má ur£ení své funkce ve spole£nosti, protoºe podobn¥ jako Prodejna, nemusí ani Prodejce vºdy reprezentovat konkrétn¥ prodejce, ale nap°. servisního technika, to je ale zatím spí² pohled do budoucna. V sou£asnosti název p°esn¥ odpovídá tomu, co v systému reprezentuje. Pozornost si je²t¥ zaslouºí vazba entity na entitu Administrátor. Tato vazba zaji²úje prodejci p°ístup do systému. Prodejce má v systému p°eddenovaná práva, která je moºné upravovat podle jeho reálných oprávn¥ní jako zam¥stnance.

5.1.17 Administrátor Tato entita reprezentuje uºivatele systému a denuje pro n¥j údaje pro p°ihlá²ení, coº je uºivatelské jméno a heslo, a podobn¥ jako u prodejce kontaktní údaje p°es entitu Kontakt. Jak jiº bylo zmín¥no, tato entita m·ºe mít také vazbu na entitu Prodejce. Administrátorovi jsou také denována práva, která mohou být nad°ízenými administrátory m¥n¥na. To jestli je administrátor vý²e neº jiný ur£uje atribut role.

5.1.18 Právo administrátora Právo administrátora denuje jeho oprávn¥ní pro p°ístup do n¥jaké sekce systému nebo oprávn¥ní pro n¥jakou operaci s poloºkami systému. Nap°. lze °íci, ºe má administrátor právo pro p°ístup pouze do seznamu poloºek a tam je jen mazat, nem·ºe je ale uº p°idávat nebo editovat. Nebo lze naopak zadat, ºe má p°ístup v²ude a právo provád¥t v²echny operace. Kaºdopádn¥ je ale t°eba brát v potaz roli administrátora, která stojí nad právy. Pokud tedy existuje n¥jaké omezení pro danou roli, nadenováním práv to nelze zm¥nit.

5.1.19 Komunikace Komunikace sdruºuje entity Dotaz vozu, Poptávka nancování, Hlídací pes a Objednávka. Tyto entity mají mnoho spole£né, coº je p°edev²ím to, ºe se jedná o komunikaci se zákazníky a krom¥ Hlídacího psa je do komunikace také zapojen V·z a Prodejna. Dal²í dv¥ vazby entity ur£ují zákazníka. Jedna je p°ímo na entitu Zákazník a druhá na entitu Kontakt. Zákazník a jeho kontaktní údaje se u Komunikace vedou odd¥len¥, protoºe vazba s entitou Zákazník ur£uje o jakého zákazníka jde a vazba s entitou Kontakt ur£uje kontaktní údaje zákazníka pro danou komunikaci.

27


U komunikace se také vedou informace o datu vytvo°ení, poslední odpov¥di a datu uzav°ení vlákna komunikace. T°eba také zmínit, ºe ke komunikaci si prodejci pí²í poznámky o pr·b¥hu jednání se zákazníkem. Toto je blíºe popsáno u entity Poznámka komunikace.

5.1.20 Dotaz vozu Dotaz vozu je entita p°edstavující zákazník·v dotaz nebo zájem o v·z, který m·ºe zadat p°ímo on p°es formulá° na webu nebo ho za n¥j m·ºe zadat prodejce p°es IS. Atribut je zde v podstat¥ pouze jeden a tím je text dotazu. Entita má v²echny vazby, které byly popsány u entity Komunikace vý²e. Vztah s Prodejnou je dán tím, kam zákazník p°i²el nebo pod kterou dotaz spadl, protoºe na ní je dotazovaný v·z. Entita má je²t¥ jedno propojení a to s Typem komunikace, které se vyuºívá, kdyº dotaz za zákazníka zadává prodejce.

5.1.21 Poptávka nancování Poptávka nancování je oproti Komunikaci roz²í°ena o atributy typ nancování (úv¥r nebo leasing), akontace, doba nancování a poji²t¥ní (ano/ne). Odeslané Vozy

Vůz

DotazVozu

Soubor

Komunikace vytvořeno odpovězeno uzavřeno

HlídacíPes

TypKomunikace Poznámka Komunikace

Objednávka vyřizuje

Poptávka Financování

Zákazník

Prodejna

Prodejce

Obrázek 5.4: Diagram vztah· entit (ERD) pro komunikaci se zákazníky

5.1.22 Hlídací pes Hlídací pes je trochu atypickým druhem komunikace, protoºe se p°i ní nekomunikuje se zákazníkem o jednom voze. Zákazník zadá kritéria vozu, který poºaduje, a systém mu automaticky posílá nabídky. Voz· v jednání tedy m·ºe být hned n¥kolik. Jelikoº nejde jen o jeden

28


v·z, nelze ur£it ani prodejnu, pod kterou komunikace spadá, komunikace je tedy p°ístupná v²em. Entita má n¥kolik atribut· pro ur£ení kritérií poºadovaného vozu - zna£ka, model, palivo, rok výroby, p°evodovka, cena (od - do), tachometr (od - do) a dále uº jen poznámku, kterou m·ºe zákazník zadat. Ur£ení zna£ky a modelu je napojeno na entity Zna£ka a Model. Atributy palivo, rok výroby, p°evodovka a tachometr jsou napojeny na entitu Hodnota parametru vozu. A poslední atribut cena se pojí s atributem cena u entity V·z.

5.1.23 Odeslaný v·z Tato entita je jakýmsi pojítkem mezi entitou Hlídací pes a V·z, která je²t¥ navíc nese informaci o datu a £ase, kdy byl v·z na základ¥ poºadavk· zákazníka systém odeslán. Jeden v·z m·ºe být odeslán stejnému zákazníkovi i vícekrát a to v p°ípad¥, kdy se zm¥nila cena vozu nebo zvý²il stav tachometru.

5.1.24 Kontakt Entita Kontakt jiº byla mnohokrát zmi¬ována. Je to entita reprezentující kontaktní údaje na n¥jakou osobu nebo spole£nost. Uvád¥t ve²keré atributy by asi bylo zbyte£né a dlouhé, ale jsou jimi jak základní kontaktní údaje jako jméno, adresa, telefon a email, tak i nap°. £íslo ú£tu. Entita m·ºe mít vazby na entity Stát, Kraj a Okres, význam není t°eba vysv¥tlovat. Kontakt je trochu zvlá²tní entitou v tom, ºe se nikde v systému nepouºívá samostatn¥, ale vºdy v souvislosti s jinou entitou.

5.1.25 Zákazník Entita Zákazník je ur£ena nejen reálnému zákazníkovi, který provedl u Autobazaru AB n¥jakou koupi vozu, ale i t°eba jen náv²t¥vníkovi webových stránek, který vyplní a ode²le n¥jaký formulá°. Tím se automaticky dostává do databáze zákazník· spole£nosti. Jelikoº email je povinný, lze sledovat, jestli zákazník kontaktoval autobazar poprvé nebo má jiº n¥jakou historii. U zákazníka se také sleduje, odkud se o autobazaru dozv¥d¥l. Pro tento ú£el slouºí entita Zdroj zákazníka. Ve²keré kontaktní údaje zákazníka spadají pod entitu Kontakt, se kterou existuje spojení. Dal²í vazby jsou se v²emi typy komunikace. Jeden typ komunikace ale zatím nebyl popsán a tím je Objednávka. K entit¥ Objednávka se váºí entity Faktura, Smlouva a Protokol, se kterými má zákazník také vazbu. Vazby jsou p°ímé a ne p°es entitu Objednávka, kv·li snaz²í orientaci a p°ístupu dat·m.

5.1.26 Poznámka komunikace Poznámka komunikace reprezentuje text o komunikaci se zákazníkem, který prodejce zadává ke vláknu komunikace. Spolu s textem také zadává, jakým zp·sobem se zákazníkem komunikoval, £ímº vzniká vazba s entitou Typ komunikace. Entita má také vztah k entit¥ Soubor, protoºe k textu musejí jít p°ikládat soubory. Kdyº nap°. prodejce po²le zákazníkovy jiº konkrétní nabídku nancování v DOC nebo PDF, p°iloºí jí k poznámce.


29

5.1.27 Typ komunikace Jak jiº bylo nastín¥no, takto entita °íká jakým zp·sobem komunikace se zákazníkem probíhala, jestli telefonicky, mailem, osobn¥ nebo jinak. Váºe se pouze na entity Poznámka komunikace a Dotaz vozu.

5.1.28 Zdroj zákazníka Tato entita jiº také byla zmín¥na a vyuºívá se u zákazníka, kde ur£uje, jakým zp·sobem se zákazník o Autobazaru AB dozv¥d¥l. Moºnosti mohou být nap°. od známého, z billboardu, z rádia atd.

5.1.29 Objednávka Entita Objednávka reprezentuje jak objednávky, tak rezervace a prodeje, kdy jde pouze o rozdílné stavy téºe v¥ci. Entita má atributy potvrzeno a prodáno. Nepotvrzená objednávka je rezervace a prodaná objednávka je prodej. Z pohledu komunikace se zákazníky je entita normálním typem komunikace, takºe má i stejné vazby a atributy jako ostatní typy komunikace. Navíc má vazbu na Prodejce, která °íká, který prodejce objednávku vy°izuje. Dal²ím atributem je typ poji²t¥ní, které m·ºe být povinné, havarijní, obojí nebo ºádné. Pokud n¥jaké je, vzniká vazba s entitou Poji²óvna, která denuje, p°es kterou poji²óvnu je poji²t¥ní sjednáváno. Podobn¥ je to i s nancováním koup¥ vozu. Pokud je p°es úv¥r nebo leasing, ur£uje se Banka. Také se v takovém p°ípad¥ vyuºívá atribut· £íslo úv¥rové smlouvy a akontace. S p°edm¥tem prodeje souvisí atributy záruka a bonus. Záruka °íká, jestli je sjednávána prodlouºená záruka vozu a bonus je £ást, kterou dostane autobazar od banky za zprost°edkování nancování. Pro rezervaci jsou je²t¥ dva atributy konec rezervace a termín prohlídky. D·leºitou vazbou entity je spojení s entitou Poloºka objednávky. Dále pak s entitami dokument· Faktura, Smlouva a Protokol.

30


ÚpravaVozu

Příslušenství Položka Objednávky

Banka

financuje vůz

Zakazník

pojišťuje vůz

Pojišťovna

Vůz Prodejna

Objednávka

Kontakt Prodejce

Protokol

Faktura Způsob Platby

Smlouva

Obrázek 5.5: Diagram vztah· entit (ERD) pro objednávku vozu

5.1.30 Poloºka objednávky Poloºka objednávky reprezentuje p°edm¥t prodeje. P°i prodeji vozu je p°edm¥t· více a tato entita je sdruºuje. Tím hlavním je samoz°ejm¥ V·z, ale pat°í tam i prodlouºená záruka, poji²t¥ní, Úprava vozu nebo P°íslu²enství. Poloºky jsou poté pouºity p°i vytvá°ení faktury.

5.1.31 Úprava vozu Autobazar nabízí dodate£né úpravy vozu jako je instalace taºného za°ízení nebo xenonových sv¥tlomet·. Atributy této entity jsou název úpravy, referen£ní £íslo, cena, po°izovací cena a DPH. Tyto úpravy v základ¥ stojí samostatn¥, kdy jsou nabízeny na webu ke kaºdému vozu. Nemá ale smysl nabízet úpravu, kdyº uº v·z nap°. taºné za°ízení má. Entita má tedy vazbu na entitu Výbava, která °íká, jaké výbav¥ úprava odpovídá a podle toho se u vozu nabízela nebo ne. Také je moºné díky atributu po°adí ur£ovat posloupnost výpisu úprav na webu.


31

5.1.32 Banka Tato entita reprezentuje bankovní ústav, p°es který autobazar nancuje své vozy a nabízí p°es n¥ nancování zákazník·m. Eviduje se název, p°es entitu Kontakt kontaktní údaje a také, jestli banka nabízí nancování úv¥rem nebo leasing. Vazby této entity jiº byly zmín¥ny - jsou s entitami V·z a Objednávka. V prvním p°ípad¥ vazba °íká, p°es kterou banku nancuje autobazar nákup vozu a v druhém, p°es kterou nancuje nákup zákazník.

5.1.33 Poji²óvna V p°ípad¥, kdy má zákazník zájem rovnou p°i koupi vozu sjednat poji²t¥ní, vybere se i poji²óvna, u které bude poji²t¥ní sjednáno. Toto popisuje jedinou vazbu Poji²óvny na entitu Objednávka. Atributy jsou podobné jako u Banky, akorát odpadají samoz°ejm¥ typy nancování, ale p°ibývá atribut sleva, ur£ující sníºení ceny poji²t¥ní pro Autobazar AB.

5.1.34 Faktura Pro prodej vozu a souvisejících poloºek musí být vystavena faktura se v²emi náleºitostmi danými zákonem. Nejd·leºit¥j²í u faktury jsou tedy samotné poloºky a informace o dodavateli (Autobazar AB) a odb¥rateli (zákazník). V p°ípad¥ leasing je ale odb¥ratelem banka, která koupi nancuje, a zákazník je uveden jako nájemce. Informace o odb¥rateli jsou dány entitou Spole£nost, informace o zákazníkovi pak vazbou na entitu Kontakt. Ne Zákazník, protoºe faktura£ní údaje mohou být úpln¥ jiné neº kontaktní údaje zákazníka. Pokud je odb¥ratelem banka, ur£ují se faktura£ní údaje podle Banky, která má vazbu s danou objednávkou. Spojení s Fakturou je tedy nep°ímé. Faktura m·ºe být n¥kolika typ· - zálohová, prodejní a dobropis. V p°ípad¥ prodejní faktury m·ºe být spojena jak se zálohovými fakturami, tak dobropisy. Podle t¥chto spojení a poloºek faktury se ur£uje £ástka dané faktury, coº je vedle typu dal²í z atribut· entity. D·leºitým atributem je £íslo faktury, které se generuje p°i vystavování faktury podle kódu Prodejny, roku vystavení a po°adí v °ad¥ fakturu pro daný rok. Faktura také m·ºe mít interní popis a pro vystavení musí mít uvedená data vystavení, splatnosti a zdanitelného pln¥ní. K faktu°e také m·ºe být zadána poznámka a zvoleno, jestli se mají vypisovat informace o voze. Také se u faktury vedou údaje o uhrazení a to o datu a £ástce. D·leºité je také zmínit, ºe faktura m·ºe být stornována, k £emuº slouºí atribut stornováno. Vazba s entitou Prodejna jiº byla nastín¥na, je d·leºitá pro ur£ení £ísla faktury a pro interní evidenci prodej· na daných prodejnách. Faktura má také vazbu na Prodejce, který fakturu vystavil.

5.1.35 Zp·sob platby Tato entita reprezentuje zp·sob, jakým bude Faktura uhrazena. Moºnosti mohou být hotovostí, p°evodem, leasingem nebo úv¥rem, coº je i jediný atribut entity - název.

32


5.1.36 Smlouva Entita Smlouva je co do struktury £áste£n¥ podobná Faktu°e. Jsou zde také smluvní strany, akorát u smlouvy není v ºádném p°ípad¥ druhou smluvní stranou banka, ale vºdy zákazník. Rozdíl smlouvy je také v tom, ºe je závislá na Faktu°e a má stejné £íslo jako ona. Smlouva tedy nem·ºe být uzav°ena bez ur£ení, ke které smlouv¥ pat°í. íslo smlouvy je ale i p°es p°ímou vazbu na Fakturu samostatným atributem pro snaz²í p°ístup k tomuto d·leºitému údaji. Smlouva m·ºe být rezerva£ní nebo kupní. Rezerva£ní smlouva m·ºe mít spojení pouze se zálohovou fakturou a kupní pouze s prodejní. Smlouva nemá ºádné poloºky ani £ástku, ale eviduje údaje o konci rezervace a termínu prohlídky pro pot°eby rezerva£ní smlouvy a informace o tom, jestli je k vozu sjednávána prodlouºená záruka pro kupní smlouvu. Stejn¥ jako faktura má i smlouva p°ímou vazbu na objednávku, k níº je vystavována.

5.1.37 Protokol Entita Protokol je rozdílná od Faktury a Smlouvy, protoºe má vyuºití jak u objednávek, tak u p°esunu voz·. Typy protokol· jsou prodejní, p°edávací a p°ejímací. Prodejní a p°edávací mají spole£né to, ºe podrobn¥ popisují p°edávaný v·z a jeho aktuální stav. P°ejímací pak uº jen stav p°edaného vozu potvrzuje, p°íp. uvádí výhrady. V p°ípad¥ prodejního protokolu je p°edávajícím prodejna, kde se obchod uskute£¬uje, spole£n¥ s prodejcem, který prodej vy°izuje, a p°ejímajícím je zákazník. U p°edávacího protokolu je p°ejímajícím prodejna, kam se v·z p°esouvá a prodejce, který v·z p°ejímá. U p°ejímacího protokolu jsou p°edávající a p°ejímající opa£n¥. Protokol má n¥kolik atribut· pro popis vozu - technický stav, karoserie, interier, pneumatiky, výbava, p°íslu²enství, dokumentace, chybí, závady a poznámky. Pro p°ejímajícího je pak jen atribut výhrady. Také se vedou informace o datum, £ase a míst¥ p°edání a stejn¥ tak p°ijetí.

5.1.38 P°esun vozu P°esun vozu m·ºe probíhat jak samostatn¥, tak v závislosti na objednávce/rezervaci, kdy si zákazník chce v·z prohlédnout nebo rovnou koupit a je tedy pot°eba ho p°esunout na danou prodejnu. Entita má dvojí vazbu na Prodejnu a to, ze které prodejny na jakou se v·z p°esouvá. Vazba na V·z je samoz°ejmostí a dále m·ºe mít tedy vazbu na Objednávku. Atributy jsou pak doprava (vlastní nebo za°ízená autobazarem) a data p°edání a p°evzetí vozu. Úpln¥ na za£átku musí být p°esun schválen vedením, k tomu slouºí atributy schváleno a datum schválení. Celý proces p°edávání vozu je podrobn¥ popsán v dal²í podkapitole Interní procesy.

5.1.39 lánek lánek reprezentuje klasickou webovou stránku, která ve v¥t²in¥ p°ípad· obsahuje jen text a obrázky. Entita lánek má ale je²t¥ vazby na entity Soubor a Mapu. Na stránce autobazaru tedy mohou být jak obrázky, soubory, tak i mapa ukazující lokalitu, o které stránka

33


pojednává. Obrázk· a soubor· m·ºe být libovolné mnoºství a je moºné spojit se £lánkem i celé sloºky. lánek má klasicky n¥jaký název, popis, text. Rozdíl mezi popisem a textem je ten, ºe text se zobrazuje na stránce £lánku a popis je na ní jen jako metatag description v HTML kódu. U £lánku se také p°i°azuje náhledový obrázek, který se spolu s název a popisem vyuºívá v seznamu £lánk·.

5.1.40 Sloºka £lánk· lánky lze t°ídit do r·zných sloºek podle témat. Sloºka ale zárove¬ m·ºe být i samostatnou stránkou, která má oproti £lánku navíc seznam podstránek (£lánk·). Entita Sloºka £lánk· má tedy stejn¥ vazby a atributy jako lánek. Soubor

Složka Souborů

Kontakt

SložkaČlánků

Článek

Mapa

Obrázek

Složka Obrázků

MístoMapy

Obrázek 5.6: Diagram vztah· entit (ERD) vztahujících se ke £lánk·m

5.1.41 Obrázek Co p°edstavuje tato entita není t°eba vysv¥tlovat. Jejími jedinými atributy jsou název, název souboru a po°adí, které p°edur£uje po°adí p°i p°ípadném p°i°azení k jiné entit¥. Vazby entity jsou velice rozsáhlé - lánek, V·z, Prodejce atd.

5.1.42 Sloºka obrázk· Význam této entity také není t°eba nijak rozebírat. Entita má pouze název a po°adí, které má stejnou funkci jako u Obrázku, protoºe p°i hromadném p°i°azování obrázk· lze p°i°adit i celé sloºky. Je to z toho d·vodu, ºe kdyº se p°i°adí celá sloºka a dodate£n¥ se do ní p°idá n¥jaký obrázek, projeví se to v²ude, kde je sloºka p°i°azená. Pokud by se p°i°azovaly jen jednotlivé obrázky sloºky, musela by se pak v²echna p°i°azení aktualizovat.

34


5.1.43 Soubor Soubor je v podstat¥ ze systémového hlediska stejný jako Obrázek, akorát má navíc atribut popis, který nahrazuje graku obrázku a popisuje podrobn¥ji neº název, co soubor obsahuje.

5.1.44 Sloºka soubor· Mezi touto entitou a entitou Sloºka obrázk· není z hlediska systému ºádný rozdíl, akorát se nepojí s entitou Obrázek, ale Soubor.

5.1.45 Mapa Mapa reprezentuje gracké rozhraní mapy, na kterém jsou vyzna£ená n¥jaká místa, která jsou relevantní pro stránku, kde se mapa vyskytuje. Mapa pot°ebuje relativn¥ hodn¥ údaj·. T¥mi základními jsou název a popis, které mohou být vyuºity uº na stránce, ale p°edev²ím slouºí v p°ípad¥, pokud je mapa zobrazována na samostatné stránce. Pro ur£ení st°edu mapy slouºí bu¤ GPS nebo spojení s entitou Kontakt, kdy se p°es adresu ur£í místo, kde má být st°ed mapy. Nakonec se u mapy ur£uje jaký má mít výchozí zoom a jestli se má její název zobrazovat uº na stránce £lánku, ke kterému je p°i°azená.

5.1.46 Místo mapy Místo mapy má mnoho stejných atribut· jako Mapa - název, popis, GPS a stejn¥ má i vazbu na Kontakt. Navíc je u entity atribut odkaz a vazba na Obrázek. Název, popis, odkaz a obrázek se pak zobrazují v detailu místa na map¥.

5.1.47 Banner Banner reprezentuje reklamní upoutávku na sluºby a produkty spole£nosti nebo i na její partnery. Banner se zobrazuje na stránkách jako obrázek r·zných formát· a na r·zných místech, která jsou p°edem denovaná. Entita má tedy vazbu na Obrázek a atributy název, popis, odkaz a umíst¥ní a po°adí ur£ující, na jakém míst¥ v daném umíst¥ní se banner zobrazuje.

5.1.48 Spole£nost Tato entita reprezentuje ve²keré kontaktní údaje Autobazaru AB, které se pak vyuºívají nap°. p°i vystavování dokument· nebo v hlavi£ce a pati£ce stránek.

5.1.49 Stát Tato entita má vazbu k entit¥ Kontakt, kdy lze u kontaktních údaj· k dokument·m nebo komunikacím se zákazníkem ur£it stát z mnoºiny t¥ch, které jsou v systému. Sou£ástí entity jsou také atributy rozloha, po£et obyvatel a EU, které do budoucna mohou umoºnit vytvá°ení r·zných statistik.

35

5.2. UIVATELSKÉ ROLE

5.1.50 Kraj Kraj je v podstat¥ stejný entita jako Stát, akorát nemá atribut EU a má vztah práv¥ je²t¥ k entit¥ Stát a to takový, ºe Kraj musí pat°it práv¥ k jednomu Státu.

5.1.51 Okres Okres naprosto stejný jako Kraj, akorát samoz°ejm¥ p°ibývá vazba na na tuto entitu.

5.1.52 Poloºka menu Na webu je hlavní menu dvou úrovní a tato entita reprezentuje odkaz v tomto menu. Poloºky první úrovn¥ tedy mohou mít je²t¥ podpoloºky, dál pak uº ne. Atributy jsou pak pouze název a odkaz. 5.2

Uºivatelské role

Do systému m·ºe p°istupovat mnoho r·zných uºivatel·, kaºdý má ale jiná práva, co m·ºe v systému vid¥t, kam se v n¥m dostat a co spravovat. Za ú£elem rozli²ení jednotlivých uºivatel· a stanovení jejich práv jsou denovány uºivatelské role. V novém informa£ním systému Autobazaru AB je celkem 6 rolí a systém funguje tak, ºe nad°azení uºivatelé mohou editovat ty níºe postavené. Hierarchii uºivatel· systému znázor¬uje následující UML diagram.

Superadmin

Administrátor vozů

Administrátor článků a multimédií

Administrátor komunikace se zákazníky

Prodejce

Hlavní administrátor

Obrázek 5.7: UML diagram znázor¬ující hierarchii uºivatel· IS

5.2.1 Superadmin Superadmin je uºivatel, který nemá ºádné omezení práv a m·ºe systém vyuºívat na 100% a spravovat tak ve²keré popsané entity. Tato role je v¥nována pouze správci systému.

36


5.2.2 Hlavní administrátor Tato role pat°í vedení spole£nosti. Jeho práva jsou velice podobná t¥m, která má Superadmin. Hlavní administrátor ale nem·ºe spravovat n¥které systémové v¥ci nebo t°eba p°idávat dal²í hlavní administrátory.

5.2.3 Administrátor voz· Uºivatel mající práva pro správu voz· m·ºe pracovat se v²emi entitami, které souvisejí s vozem, ale nesouvisejí s prodejem a komunikací. U voz· tedy m·ºe spravovat ve²keré jeho údaje, výbavu, p°íslu²enství, parametry atd. V souvislosti s tím m·ºe editovat i entity nesoucí mnoºinu údaj·, které se p°i°azují k vozu, t¥mi jsou nap°. typy p°íslu²enství, zna£ky a modely nebo úpravy vozu. Administrátor voz· nesmí vid¥t ºádné informace o nákupních cenách a ziscích. Toto platí obecn¥ pro v²echny administrátory niº²í role neº má hlavní administrátor, ºe nesmí vid¥t ºádné nan£ní p°ehledy spole£nosti. Spravovat parametry

<<extend>>

Spravovat historii

Spravovat příslušenství

<<extend>> <<extend>>

Spravovat vozy

Spravovat výbavu

<<extend>>

<<extend>>

Administrátor vozů <<extend>>

Spravovat obrázky

Spravovat skupiny

<<extend>>

Spravovat soubory

Obrázek 5.8: Use-Case diagram administrátora voz·

5.2.4 Administrátor komunikace se zákazníky Role Administrátor komunikace existuje, aby mohl spravovat, korigovat a hlídat komunikaci prodejc· a zákazník· a není omezen ºádnou prodejnou. Spravovat m·ºe v²echny typy komunikace a v souvislosti s tím i samotné zákazníky. Stejn¥ jako prodejci m·ºe p°idávat poznámky

37

5.2. UIVATELSKÉ ROLE

k vlákn·m komunikace a v p°ípad¥ pot°eby prodejnu nebo prodejce p°ed zákazníkem zastupovat. UML diagram níºe vykresluje moºnosti a práva tohoto uºivatele, které v IS má.

Spravovat zákazníky Spravovat objednávky

<<extend>> <<extend>>

Spravovat dotazy na vůz <<extend>>

Spravovat komunikace <<extend>> Administrátor komunikace se zákazníky

<<extend>>

<<extend>>

Spravovat poznámky

Spravovat poptávky financování

Spravovat hlídací psi

Obrázek 5.9: Use-Case diagram administrátora komunikace se zákazníky

5.2.5 Administrátor £lánk· a multimédií

Z administrátor· je poslední ten, který se stará o obsah webových stránek spole£nosti. Do jeho kompetence v²ech nespadá katalog voz·, který je v reºii hlavního administrátora a administrátora voz·. Tento administrátor m·ºe spravovat pouze oby£ejné stránky, jejich texty, obrázky a zve°ejn¥né soubory. Spolu s tím má samoz°ejm¥ moºnost pracovat s multimédii a to v£etn¥ banner·.

38


Spravovat bannery

Spravovat obrázky <<extend>>

Spravovat články

Administrátor článků a multimédií

<<extend>> <<extend>> Spravovat mapy

Spravovat soubory

Obrázek 5.10: Use-Case diagram administrátora £lánk· a multimédií

5.2.6 Prodejce Prodejce je specickým druhem administrátora, který má práva uzp·sobená k tomu, aby mohl prodávat vozy a komunikovat se zákazníky. Prodejce má tedy podobná práva jako Administrátor komunikací se zákazníky, navíc je ale omezen svou p°íslu²ností k prodejn¥, takºe nem·ºe zasahovat do záleºitostí jiných neº, které náleºí jeho prodejn¥. Oproti administrátorovi komunikací má ale p°ístup k p°esunu voz·, které se ho týkají a to tak, ºe bu¤ ºádá o p°esun vozu nebo vozidlo p°edává jiné prodejn¥. 5.3

Interní procesy

Jako kaºdá spole£nost tak i Autobazar AB má n¥jaké interní procesy. V¥t²ina interních proces· jsou specické pro kaºdou spole£nost. V této kapitole budou popsány hlavní procesy autobazaru, které se týkají IS, jeho entit a mají vliv na práva uºivatel·. Jelikoº samotné popisy proces· by mohly být nejasné, jsou dopln¥ny o Activity Diagramy.

5.3.1 P°esun vozu P°esun vozu se uskute£¬uje z r·zných d·vod· - vyrovnání stavu voz· na prodejn¥, zájem zákazníka o v·z, který je jinde, nebo i p°esun vozu do servisu kv·li n¥jaké závad¥. V p°ípad¥, kdy n¥jaký prodejce pot°ebuje dostat v·z k sob¥ na prodejnu, zadá si poºadavek a systém informuje hlavního administrátora, který musí poºadavek potvrdit. Pokud ho neschválí, systém pouze informuje prodejce a nic se ned¥je. Pokud ano, systém informuje prodejce i prodejnu, která má v·z p°edat, aby vystavila p°edávací protokol a v·z p°ipravila k p°esunu. Jakmile se v·z dostane na cílovou prodejnu, p°ejímající prodejce vystaví p°ejímací protokol, který

39

5.4. OBJEDNÁVKA VOZU

je v podstat¥ dopln¥ním p°edávacího protokolu, kam se prodejce vyjád°í k tomu, jestli stav vozidla souhlasí s tím, jak byl popsán p°edávající prodejnou, tím proces kon£í. Ob¥ prodejny pak mohou kdykoliv i zp¥tn¥ nahlíºet do obou vystavených protokol·. Proces přesunu vozu na jinou prodejnu Žádající prodejce

Předávající prodejce

Administrátor

upozornění mailem Vytvoření požadavku

Přijetí požadavku

Schválení upozornění mailem upozornění mailem

Přijetí výsledku schválení

Přijetí požadavku

schváleno

Přijetí vozu

zamítnuto Vystavení předávacího protokolu

Vystavení přejímacího protokolu

Předání vozu

Obrázek 5.11: Activity Diagram - p°esun vozu 5.4

Objednávka vozu

Objednávka m·ºe být zapo£ata dv¥ma zp·soby. První je vytvo°ením rezervace, kterou m·ºe ud¥lat jak zákazník p°es web, tak prodejce p°es IS. Aby mohl být prodej uskute£n¥n, je rezervaci t°eba potvrdit a ud¥lat tím z ní objednávku. Druhým zp·sob je, ºe prodejce vytvo°í rovnou potvrzenou rezervaci, tedy objednávku. V tu chvíli je v·z blokovaný a není moºné vytvá°et na n¥j jiné objednávky.

40


P°ed vystavování dokument· je t°eba objednávku vyplnit, coº je rozd¥leno na n¥kolik krok·. V prvním se zadává p°edm¥t prodeje, kde je jiº na za£átku objednaný v·z a je moºnost p°idat nap°. prodlouºenou záruku, poji²t¥ní, p°íslu²enství nebo dodate£né úpravy vozu. Poté se zadají smluvní strany, které jsou jiº p°edvypln¥né tím, co se vyplnilo p°i vytvá°ení rezervace nebo objednávky. A v posledním kroku se vybere zp·sob nancování, kde se u moºnosti hotovost nebo p°evodem nevypl¬uje uº nic jiného, ale u moºností úv¥r a leasing je t°eba zadat akontaci, banku a £íslo úv¥rové smlouvy. Poté, co je objednávka vypln¥na, je moºné za£íst vytvá°et dokumenty pot°ebné k prodeji. To m·ºe za£ít tak, ºe se vystaví rovnou prodejní faktura a kupní smlouva nebo tak, ºe se nejd°íve vystaví zálohová faktura a spolu s ní rezerva£ní faktura a zákazník pak má 14 dní na zaplacení zbytku nebo zaplacení dal²í zálohy. Pokud ani jedno zákazník do 14 dn· neud¥lá, objednávka i zaplacené zálohy propadají. Pokud v²e prob¥hne, jak má, vystaví se prodejní faktura, ve které jsou zálohy ode£teny, poté se uzav°e kupní smlouva. Na konci celého procesu se vystaví prodejní protokol o stavu vozu a s ním p°edávaných v¥cech.

Vytvoření objednávky

Potvrzení rezervace

Vytvoření rezervace

Propadnutí objednávky a zaplacených záloh

zákazník nedoplatí zbylou částku

Přesunutí objednávky mezi prodeje

Vystavení prodejního protokolu

Vyplnění předmětu prodeje

Vystavení zálohové faktury

Vyplnění smluvních stran

Výběr financování

Uzavření rezervační smlouvy

zákazník doplatí zbylou částku

Uzavření kupní smlouvy

Obrázek 5.12: Activity Diagram - objednávka

Vystavení prodejní faktury

41

5.5. KOMUNIKACE SE ZÁKAZNÍKEM

5.5

Komunikace se zákazníkem

Proces komunikace zahajuje v podstat¥ sám zákazník a to tím, ºe n¥jakým zp·sobem kontaktuje Autobazar AB. To m·ºe být bu¤ prost°ednictvím webových stránek, kde vyplní a ode²le n¥jaký formulá°, nebo osobn¥, telefonicky £i emailem kontaktuje p°ímo n¥jakou prodejnu. V takovém p°ípad¥ pak z pohledu IS zahajuje komunikaci prodejce, který za zákazníka zaloºí vlákno komunikace. Poté je moºné ke komunikaci p°idávat dal²í poznámky o tom, jak komunikace se zákazníkem pokra£uje. Kdyº komunikace skon£í a´ uº úsp¥²n¥ prodejem vozu nebo neúsp¥²n¥, vlákno komunikace se uzav°e.

Založení vlákna komunikace prodejcem za zákazníka

Uzavření komunikace po úspěšné obchodu Přidávání poznámek ke komunikace prodejcem

Založení vlákna komunikace zákazníkem odeslání formuláře

Uzavření komunikace bez obchodu

Obrázek 5.13: Activity Diagram - komunikace se zákazníky

42


Kapitola 6

Návrh °e²ení nového systému V návaznosti na uºivatelské role a interní procesy analyzované v p°edchozí kapitole je v této kapitole proveden návrh navigace v systému. P°edposlední podkapitola je pak v¥nována krátkému pohledu na architekturu systému, která je znázorn¥na diagramem nasazení. A kapitolu analýza nakonec uzavírá návrh databáze. 6.1

Prost°edky a technologie

V této sekci jsou popsány prost°edky a technologie pouºité pro implementaci IS. D·vod pouºití práv¥ t¥chto prost°edk· je bu¤ na základ¥ poºadavk· zadavatele, nebo na základ¥ standard· WWW a komunity a podpory t¥chto prost°edk·.

6.1.1 PHP PHP je ²iroce pouºívaný mnohoú£elový skriptovací jazyk, který je obzvlá²t¥ vhodný pro vývoj webových aplikací a lze jej zapouzd°it do HTML.[21] Tento jazyk byl zvolen pro vývoj systému, protoºe ani nebyla jiná moºnost. Zadavatel má sv·j server, kde b¥ºí Apache, a ve²keré webové aplikace, které vyvíjí, jsou psané v PHP. PHP má navíc mnoho výhod, ale samoz°ejm¥ i nevýhod. Jednou z kladných stránek je jednoduchost a volnost p°i psaní kódu a práci s HTML. To ale p°iná²í úskalí v psaní dobrého kódu, je tedy t°eba mít a udrºovat n¥jaký systém. U verze 5 se také výrazn¥ zlep²ila podpora OOP, stále se to ale nedá porovnávat nap°. s jazykem Java. Uº i tak je práce s objekty p°íjemná a velmi usnad¬ující. Nejv¥t²í výhodou PHP je jeho roz²í°enost a ²iroká komunita uºivatel·. To s sebou p°iná²í také celou °adu nejr·zn¥j²ích modul·, roz²í°ení a hotových °e²ení nejr·zn¥j²ích problém·.

6.1.2 HTML HTML je publikující jazyk WWW[12] a v podstat¥ jde o jediný jazyk pro vytvá°ení klasických webových stránek. Jeho pouºití je op¥t relativn¥ jednoduché. Mezi tagy, které jsou denované, nebo do jejich atribut· se umisúje obsah, který na stránce chceme zobrazit. V n¥kterých p°ípadech jako t°eba u obrázk· se do tagu zadává URL a to jako hodnota 43

44

KAPITOLA 6. NÁVRH EENÍ NOVÉHO SYSTÉMU

parametru. Nová verze HTML 5 pak roz²i°uje mnoºinu tag·, které lze pouºít a také roz²i°uje moºnosti práce s multimédii.

6.1.3 CSS Kaskádové styly (CSS) je jednoduchý mechanismus pro p°idání stylu (nap°. fonty, barvy, °ádkování) do webových dokument·.[7] CCS umoº¬uje pozicovat HTML elementy, ur£ovat vzhled textu, tabulek, ur£ovat pozadí nebo ohrani£ení element· a mnoho dal²ího. Verze CSS 3 uº také poskytuje celou ²kálu moºností pro rozhýbání webových stránek. Mnoho funkcí ale stále není n¥kterými prohlíºe£i podporováno nebo je kaºdý prohlíºe£ zobrazuje jinak. Tradi£n¥ nejvíce práce je vyladit styly pro v²echny aktuáln¥ pouºívané verze Internet Exploreru2 , protoºe i nejnov¥j²í verze je vºdy oproti jiným prohlíºe£·m v podpo°e nejnov¥j²ích technologií pozadu a navíc kaºdá verze IE £asto zobrazuje stejné stránky jinak.

6.1.4 JavaScript JavaScript je skriptovací jazyk na webu a je pouºíván v miliardách webových stránek k p°idání funkcí, ov¥°ování formulá°·, komunikování se serverem a mnoho dal²ího.[17] Je moºné pomocí n¥j ud¥lat stránky dynamické a interaktivní a to bez nutnosti znovu na£ítat stránku, protoºe se skript zpracovává na stran¥ klienta v jeho prohlíºe£i. To ov²em stejn¥ jako u CSS p°iná²í problémy se závislostí na prohlíºe£i, jeho verzi a podpo°e r·zných funkcí. JavaScript má také základní vlastnosti objektov¥ orientovaného jazyka. JavaScript se £asto spojuje s jazykem Java, se kterým ale krom¥ £ísti názvu a £áste£n¥ podobné syntaxi nemá nic spole£ného. JavaSkcript je interpretovaný jazyk, kdeºto Java se musí p°ed interpretací zkompilovat.

6.1.5 AJAX AJAX (Asynchronous JavaScript and XML) není nový programovací jazyk, ale nový zp·sob jak pouºívat existující standardy. AJAX je um¥ní vým¥ny dat se serverem a aktualizace £ástí webové stránky bez znovu na£ítání celé stránky.[4] AJAX posílá poºadavek na n¥jaká data na server a poté, co je získá, s nimi m·ºe dál pracovat. V názvu je slovo "asynchronní"proto, ºe skript, který posílá poºadavek na server, b¥ºí asynchronn¥ od zbylého skriptu. Zatímco zbylý skript mohl dávno prob¥hnout, ten ºádající o data na n¥ m·ºe je²t¥ £ekat. XML v názvu je trochu zavád¥jící, jde o jeden z formát·, který umí AJAX zpracovat jako odpov¥¤. Odpov¥dí ale m·ºe být i oby£ejný text nebo JSON.

6.1.6 SQL SQL je standardní jazyk pro p°istupování k databázi[26], který umoº¬uje manipulaci dat v DB a jejich získávání odtud. Jazyk také umí manipulovat i se samotnou databází a její strukturou. SQL je ur£ený pro rela£ní databázové systémy a je ²iroce podporován v£etn¥ spole£ností Oracle3 i Microsoft4 . 2 3 4

Jeden z nejpouºívan¥j²ích prohlíºe£· od spole£nosti Microsoft http://www.oracle.com http://www.microsoft.com

6.2. MODULY

45

6.1.7 MySQL MySQL je sv¥tov¥ nejpopulárn¥j²í open source databáze.[19] Jde o RDBMS, coº je systém °ízení báze dat, který b¥ºí jako server poskytující p°ístup více uºivatel·m najednou k libovolnému po£tu databází. MySQL uº podle názvu pracuje s jazykem SQL a je £asto pouºíván dohromady s PHP, kde má vysokou podporu. 6.2

Moduly

V této £ásti jsou popsány moduly, coº jsou hotová °e²ení r·zných problém·, které by se jinak v systému musely °e²it. Takovými je nap°. nahrávání obrázk· nebo generování PDF. Moduly byly vybrány na základ¥ jejich vlastností, dokumentace, roz²í°ení, podpo°e a zku²enostech jiných uºivatel·. Tyto kritéria zahrnují i poºadavky zadavatele, kterému ²lo o to, aby se neexperimentovalo a do systému se nezavád¥li n¥jaké neodzkou²ené pluginy. Moduly pracují na bázi vý²e popsaných technologii (jedné nebo i více) a n¥které moduly spolupracují i s jinými moduly.

6.2.1 jQuery jQuery je rychlá, malá a na funkce bohatá JavaScript knihovna. D¥lá v¥ci jako pr·chod HTML dokumentem a manipulaci, zpracování událostí, animaci a AJAX mnohem jednodu²í s snadno pouºitelným API, které pracuje nap°í£ mnoha prohlíºe£i. Zkombinování v²estrannosti a roz²i°itelnosti jQuery zm¥nilo psaní JavaScriptu tak, ºe ho nyní pí²í miliony lidí.[14] jQuery je rozd¥leno na n¥kolik balík·, kdy hlavní balík samotné jQuery umoº¬uje práci s JS. Dal²í hojn¥ pouºívaný balík je jQuery UI, který obohacuje jQuery o moºnosti práce s uºivatelským rozhraním. jQuery UI je organizovaný soubor interakcí uºivatelského rozhraní, efekt·, widget· a motiv· postavených na vrcholu knihovny jQuery.[16] Pomocí jQuery UI lze ud¥lat vysoce interaktivní webové aplikace, ale i jen p°idat kalendá° do textového pole pro zadání data. jQuery poskytuje i dal²í balí£ky, kdy z t¥ch nejnov¥j²ích je v sou£asnosti asi nejzajímav¥j²í a nejpropracovan¥j²í jQuery Mobile. Jde o jednotný na HTML 5 zaloºený systém uºivatelského rozhraní pro v²echny platformy populárních mobilních za°ízení postavený na skálopevném jQuery a jQuery UI. Jeho lehký kód je postaven s postupným roz²i°ováním a má exibilní a snadno upravitelný design.[15]

6.2.2 Bootstrap Bootstrap je elegantní, intuitivní a výkonný front-end framework pro rychlej²í a snadn¥j²í vývoj webových aplikací.[5] Tento framework vznikl p·vodn¥ jako sada nástroj· pro Twitter5 . asem se ale Bootstrap roz²í°il a spoluprací mnoha lidí se roz²í°ily i moºnosti jeho vyuºití. Pomocí CSS a HTML denuje jednotnou typograi, jednotný vzhled formulá°·, tabulek, tla£ítek, navigace a dal²ího. Bootstrap také £asem za£al vyuºívat JavaScript, resp. jQuery a °e²it r·zné vysouvací menu, vyskakovací okénka nebo bublinové popisky. 5

Sociální sí´ (https://twitter.com/)

46


Bootstrap po£ítá i s vyuºitím na mobilních za°ízení, a proto zohled¬uje i relativn¥ nový trend ve vývoji webových aplikací Responsive Web Design (RWD)[24]. Pokud je n¥jaká stránka °e²ena tzv. responsivn¥, neznamená to, ºe má speciální verzi pro mobilní za°ízení, ale ºe se její obsah p°izp·sobuje velikosti obrazovky, tak aby byl i na nejmen²ích obrazovkách mobilních telefon· pohodln¥ £itelný a pr·chozí. Ve²keré prvky, které Bootstrap navrhuje, se p°i implementování balí£k·, které RWD zohled¬ují, zobrazují responsivn¥.

6.2.3 jQuery File Upload jQuery File Upload je widget pro nahrávání soubor· s podporou výb¥ru více soubor·, drag&drop, grackého znázorn¥ní pr·b¥hu nahrávání, zm¥nou velikostí obrázk· a mnoha platforem v£etn¥ PHP.[10] Jak jiº název napovídá, modul vyuºívá jQuery, ale také Bootstrap, takºe je velice uºivatelsky p°ív¥tivé. Tento modul je velice uºite£ný jak pro programátory, tak pro uºivatele. Z programátorského hlediska je vytvo°ení dobrého nahrávání obrázk· a soubor· velmi t¥ºkým úkolem, coº nasazením File Uploaderu odpadá, a uºivatel m·ºe pohodln¥ nahrávat libovolný po£et soubor· najednou.

Obrázek 6.1: Ukázka nahrávání obrázk· p°es jQuery File Upload

6.2.4 prettyPhoto prettyPhoto je jQuery lightbox6 klon.[23] Nejen, ºe podporuje obrázky, ale také videa, ash, YouTube7 , iframy a AJAX. Je to plnohodnotný média lightbox. Stejn¥ jako lightbox je i prettyPhoto velice snadno pouºitelný, do stránky se vloºí jeden JS, jedno CSS a k danému odkazu se p°idá jeden atribut a je v podstat¥ hotovo. Tento modul pak umoº¬uje, aby se v²e odehrávalo na dané stránce, a není t°eba sm¥rovat odkazy do nových nebo pop-up oken.

6.2.5 CKEditor CKEditor je snadno pouºití HTML textový editor navrºený ke zjednodu²ení vytvá°ení webového obsahu. Je to WYSIWYG editor, který p°iná²í b¥ºné funkce textového procesoru p°ímo na webové stránky.[6] CKEditor pracuje primárn¥ na bázi JS, HTML a CSS. Jde 6 7

JS prohlíºe£ obrázk· (http://lokeshdhakar.com/projects/lightbox/) Server pro sdílení videí (http://www.youtube.com/)

47

6.2. MODULY

o velice rozsáhlou aplikaci, která ²irokou ²kálu p°izp·sobení funk£nosti, kongurace a doinstalování nejr·zn¥j²ích modul·. Z nejd·leºit¥j²ích moºností kongurace je nastavení panelu nástroj· a nadenování styl· jak pro textové pole, ve kterém se obsah spravuje, tak pro výb¥r styl·, které m·ºe uºivatel pouºívat. Nejv¥t²ím konkurentem CKEditoru je TinyMCE. Kaºdý z t¥chto editor· má n¥co a mezi webovými vývojá°i není v podstat¥ jednotný názor na to, který editor je lep²í. Takový názor nebyl ani v dob¥ FCKEditoru, coº je p°edch·dce CKEditoru. Editory jsou si, co se UI týká, velice podobné. CKEditor se ale vyvinul p°edev²ím v oblasti vytvá°ení HTML kódu. Tato verze uº je ale na sv¥te pár let a od té doby se vyvinul i TinyMCE, takºe ani upgradem FCKEditoru na CKEditor se v konkuren£ním boji nic nezm¥nilo. Nicmén¥ v IS Autobazaru AB bude pouºit CKEditor. Jde o p°ání zadavatele, protoºe spole£nost DIS Media pouºívá výhradn¥ práv¥ tento editor.

Obrázek 6.2: Ukázka CKEditoru

6.2.6 mPDF mPDF je PHP t°ída, která vytvá°í PDF soubory z HTML dokument· kódovaných UTF-8. T°ída je zaloºena na FPDF8 a HTML2FPDF9 , ale s °adou vylep²ení.[18] Generování PDF pomocí této t°ídy je velice snadné, protoºe sta£í vytvo°it HTML stránku s vno°enými styly a t°ída podle ní vygeneruje PDF. Toto je velká výhoda, protoºe v p°ípad¥, kdy je pot°eba stejný obsah odeslat nap°. i mailem, nemusí se vytvá°et dva r·zné kódy. T°ída navíc zavádí dal²í tagy a funkce, které zohled¬ují, ºe PDF je oproti HTML stránkované. Jedním z takových tag· je nap°. <pagebreak />, který ukon£uje jednu stránku PDF a za£íná novou. 8 9

http://www.fpdf.org/ http://html2fpdf.sourceforge.net/

48


FPDF a HTML2FPDF, na nichº je mPDF stav¥ná, sice poskytují více mén¥ to samé, ale v dale mén¥ pohodlné form¥. Dal²í moºností, jak v PHP generovat PDF je PHP knihovna PDFlib10 . Psaní kódu pro generování PDF pomocí toho roz²í°ení ale není o nic jednodu²²í neº u FPDF a HTML2FPDF. Jednoduchost generování PDF z HTML asi jen tak nic nep°ed£í. mPDF m¥lo jednu nevýhodu, ºe vygenerované soubory byly velké (1 MB a více), to jiº ale bylo upraveno a nyní dvou nebo t°ístránkové dokumenty mají kolem 50 KB.

6.2.7 PHPMailer PHPMailer je pravd¥podobn¥ sv¥tov¥ nejpouºívan¥j²í kód pro posílání email· pomocí PHP.[22] Tuto t°ídu vyuºívají i velké a roz²í°ené systémy jako Drupal nebo Joomla. V PHP sice existuje funkce mail(), která odesílání mail· °e²í, ale pokud má být mail trochu sostikovan¥j²í, je p°inejmen²ím nelehké v²e °ádn¥ o²et°it. PHPMailer podporuje HTML formát mailu, CSS, p°ílohy, zasílání více adresát·m na jednou nebo má i intergrované SMTP bez nutnosti lokálního SMTP serveru.

6.3

Webové sluºby

Webová sluºba je metoda komunikace mezi dv¥ma elektronickými za°ízeními p°es WWW. Jde o softwarovou funkci poskytovanou na ur£ité adrese p°es web nebo cloud a tato sluºba je vºdy p°ístupná podle konceptu ve°ejných sluºeb.[29] Webová sluºba umoº¬uje jiným systém·m vyuºívat funkcionalit systému, který sluºbu poskytuje a to p°es programátorské rozhraní (API).

6.3.1 Google Maps API Google Mapy mají ²irokou ²kálu API, které umoº¬ují vloºit robustní funk£nost a kaºdodenní uºite£nost Google Map do vlastní webové stránky a aplikace a p°ekrýt je vlastními daty.[11] Google Maps API umoº¬uje ur£ovat ovládací prvky mapy, její chování a vlastnosti a data (resp. místa), která se mají na map¥ zobrazovat.

6.3.2 Facebook API Programátorské rozhraní Facebooku umoº¬uje vkládat na stránku tla£ítka "To se mi líbí", tla£ítka pro odesílání, vkládání p°ísp¥vk· a dal²í pluginy. API také umoº¬uje p°ihla²ování na FB, se který se pak dá v rámci systému pracovat.[9] Pomocí FB API lze propojit web jak s konkrétním prolem na FB, tak i jen dát uºivatel·m moºnost se o stránku na FB pod¥lit. Pomocí p°ihla²ování lze pak uºivatel·m zp°ístupnit neve°ejné sekce, kdy se nemusí registrovat a pamatovat dal²í z mnoha p°ihla²ovacích údaj·, které pouºívají. 10

http://www.php.net/manual/en/intro.pdf.php

6.4. UIVATELSKÉ ROZHRANÍ A NAVIGACE

49

6.3.3 AddThis AddThis je °e²ení pro inzerenty jak pouºít perfektní kombinaci v¥dy dat a lidského poznání, které pomohou získat nové zákazníky, angaºovanost a inteligenci marketingovým plán·m.[2] AddThis poskytuje nejr·zn¥j²í pluginy pro celou ²kálu sociálních sítí a získat nejr·zn¥j²í záznamy, p°ehledy, grafy a diagramy o aktivit¥ náv²t¥vník· na webu, jejich zájmu o n¥j a vyuºívání daných plugin·. 6.4

Uºivatelské rozhraní a navigace

P°i tvorb¥ uºivatelského rozhraní a navigace v nové IS budou pouºity p°edev²ím UI prvky, které poskytuje Bootstrap. Tyto prvky mají jednotný a moderní vzhled, jsou uºivatelsky p°ív¥tivé, snadno pouºitelné a jejich celá °ada nejr·zn¥j²ích typ· a variant. Bootstrap poskytuje typy UI prvk· od nejmen²ích tla£ítek, p°es záloºky, vysouvací menu, formulá°ová poli£ka aº po vyskakovací dialogová okna nebo r·zné bublinové nápov¥dy a popisky. Pro hlavní panel bude pouºita ²ablona, která obsahuje titulek stránky, hlavní menu, vyhledávací pole a podruºné menu, které m·ºe být pouºito nap°. jako menu uºivatele.

Obrázek 6.3: Ukázka Bootstrap hlavního panelu Boostrap nabízí i jednoduchou drobe£kou navigaci, která slouºí k informování, v jaké £ásti systému se uºivatel nachází, a poskytuje rychlý zp·sob, jak se dostat do vy²²ích úrovní.

Obrázek 6.4: Ukázka Bootstrap drobe£kové navigace Pro rozd¥lení stránek nebo velkých formulá°· na logické celky se velice hodí záloºky, které jasn¥ ukazují, jaké podsekce jsou na stránce dostupné a umoº¬uje snadné p°echázení mezi nimi.

Obrázek 6.5: Ukázka Bootstrap ºáloºek Výpis poloºek se standardn¥ °e²í pomocí tabulky, která dob°e a p°ehledn¥ zobrazuje a organizuje i velké mnoºství dat.

50


Obrázek 6.6: Ukázka Bootstrap tabulky Výpis poloºek m·ºe být ale ob£as nep°ijateln¥ dlouhý a zp·sobovat nep°ehlednost a zp·sobovat dlouhé na£ítání stránky. To se °e²í pomocí stránkování. Boostrap nabízí navigaci i pro tento p°ípad.

Obrázek 6.7: Ukázka Bootstrap stránkování Odkazy na akce a operace je standardní °e²it pomocí odkaz· z ikonek a tla£ítek. Boostrap °e²í celou °adu variant tla£ítek, které mohou mít r·zné barvy, mohou obsahovat text, ikonku nebo mohou být skrývat i vysouvací menu.

Obrázek 6.8: Ukázka Bootstrap tla£ítek Tla£ítka v kombinaci s ikonkami a bez text· jsou velice vhodná do výpisu poloºek, kde nebývá místa k plýtvání a kde fungují odkazy na operace, které je moºné s poloºkami d¥lat. Texty vedle ikonek jsou t°ídy, které se pak ur£ují u elementu, kde má ikonka být.

Obrázek 6.9: Ukázka Bootstrap ikonek Bootstrap poskytuje celou °adu formulá°ových prvk· op¥t r·zných variant a velikostí. Na obrázku níºe je oby£ejné textové pole, ale ve stavu, kdy v n¥m po odeslání formulá°e byla nalezena chyba.

Obrázek 6.10: Ukázka Bootstrap informování výskytu chyby ve formulá°ovém polí£ku

6.5. STRUKTURA A ARCHITEKTURA SYSTÉMU

51

Nezbytnou sou£ástí UI je i informování uºivatele o tom, jak daná akce prob¥hla. Následující dva obrázky ukazují dv¥ nejb¥ºn¥j²í varianty - úsp¥²n¥ a neúsp¥²n¥.

Obrázek 6.11: Ukázka Bootstrap informování o výskytu chyby

Obrázek 6.12: Ukázka Bootstrap informování o úsp¥²n¥ provedené akci Ob£as je pot°eba, aby uºivatel n¥co potvrdil, nap°. poºadavek na smazání n¥jaké poloºky, aby nemohlo dojít k n¥jaké nevratné zm¥n¥ kv·li pouhému p°ekliknutí. Také m·ºe být t°eba uºivatele o n¥£em informovat tak, aby bylo jist¥, ºe to nep°ehlédne. Pro oba tyto p°ípady se velmi hodí dialogové okno, které se objeví v úplném pop°edí stránky a zablokuje UI pod ním, dokud uºivatel okno n¥jaký zp·sobem (potvrzení nebo zru²ení) nezav°e.

Obrázek 6.13: Ukázka Bootstrap dialogového okna 6.5

Struktura a architektura systému

Nový informa£ní systém je navrºen na bázi t°ívrstvé architektury, která zavádí do kódu °ád a jasn¥ rozd¥luje funkce jednotlivých £ástí skript·. První vrstva je datová, ta se stará o data, komunikuje s databází a °ídí p°ístup k nim. Druhá je aplika£ní vrstva, která se stará o zpracování akcí, a´ uº je to poºadavek výpis dat nebo odeslání formulá°e. Poslední vrstva je prezenta£ní, ta °e²í výstup dat a jak budou uºivateli zobrazena. Komunikace s databází a získávání dat z ní je °e²eno podle návrhového vzoru Active Record. Jde o architektonický vzor pouºívaný u aplikací, které ukládají data do rela£ních databází. Aby rozhraní objektu vyhovovalo tomuto vzoru, m¥lo by zahrnovat funkce INSERT, UPDATE, DELETE a vlastnosti, které více mén¥ odpovídají sloupc·m tabulky v databázi.[1] P°i pouºití tohoto vzoru jde o to, ºe p°ístup k dat·m je zabalen do t°íd. Instance této t°ídy pak odpovídá °ádku z tabulky v databázi. Komunikace uºivatele, v²ech t°í vrstev a databáze je znázorn¥na na následujícím sekven£ním diagramu.

52


Klient

Prezentační vrstva

Aplikační vrstva

Datová vrstva

Databáze

požadavek vyvolání akce provedení požadavku SQL dotaz na databázi vrácení dat zpracování dat sestavení stránky stažení stránky

Obrázek 6.14: Sekven£ní diagram komunikace vrstev systému Celý systém je umíst¥n na serveru, kde beºí Apache11 s PHP a databází MySQL. S klientem se komunikuje pomocí protokolu HTTP a odesílá se mu stránka sloºena z HTML, CSS a JavaScriptu. Pomocí Javascriptu se na stran¥ klienta pak komunikuje s Facebook API a Google Maps API p°es protokol HTTPS.

Server

Prohlížeč HTML

PHP

MySQL

HTTP

CSS Google Server

Uživatel Javascript

HTTPS Maps API

HTTPS

Obrázek 6.15: Diagram nasazení 11

https://httpd.apache.org/

Facebook Server

API

53

6.6. DATABÁZE

6.6

Databáze

P°i návrhu databáze se v¥t²inou vytvá°í diagram databáze. V p°ípad¥ tohoto IS by byl ale velice rozsáhlý a lze vyjít z popisu entit a jejich vztah·. Diagram databáze pak nahradí jednotlivé ERD. P°i vytvá°ení databáze je t°eba postupovat tak, ºe pokud je kardinalita many-to-many, musí se vytvo°it vztahová tabulka s atributy pro ID z obou tabulek. Pokud se mají dát tyto poloºky °adit, musí p°ibýt i atribut poradi. Pokud je kardinalita jiná, sta£í tabulky provázat p°es atribut nap°. tabulka_id. V¥t²ina dat se z databáze ve skute£nosti nemaºe, ale ozna£uje jako smazaná, a je tedy t°eba p°idat atribut smazano. Pouze pro informaci a p°ípadn¥ i dal²í pouºití se p°idává i atribut vytvoreno, který se p°i vytvá°ení nastaví na aktuální datum a £as. Tyto atributy nejsou u vztahových tabulek a atribut smazano není ani u tabulek obrazky a soubory, protoºe °ádky z t¥chto tabulek se doopravdy vymazávají stejn¥ jako dané soubory, aby nezabíraly místo na serveru. Citlivá data jako jsou hesla se nesmí v databázi objevovat v neza²ifrované podob¥. V²echna hesla jsou tedy ²ifrována pomocí SHA12 . Databázové jádro tabulek databáze je MyISAM13 , které je pro MySQL výchozí. Pro kódování data je pak pouºito nejnov¥j²í utf8mb4_unicode_ci.

6.6.1 Adminer Adminer je pln¥ vybavený nástroj pro správu databáze napsaný v PHP. Na rozdíl od phpMyAdmin, se skládají z jediného souboru p°ipraveného k nasazení na cílový server. Adminer je k dispozici pro MySQL, PostgreSQL, SQLite, MS SQL a Oracle.[3] Pro práci s databází systému se vyuºívá práv¥ tento nástroj, protoºe správa databáze a dat v ní je s ním velmi efektivní. Oproti phpMyAdmin má mnoho r·zných vylep²ení a moºností správy tabulek a dat jako t°eba správa dat p°ímo ve výpise po dvojkliku na polí£ko, moºnosti dodate£ného °azení sloupc· tabulky nebo plná editace pohled·. Velice ²ikovné jsou i odkazy na tabulky a na dokumentaci v SQL kódu.

Obrázek 6.16: Adminer 12 13

http://en.wikipedia.org/wiki/SHA-2 http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html

54


Kapitola 7

Implementace nového systému V této kapitole je popsána implementace nového informa£ního systému spole£nosti Autobazar AB, která probíhala na základ¥ poºadavk· zadavatele, analýzy a návrhu, které byly popsány v p°edchozích kapitolách. V této kapitole je jiº rozebráno samotné °e²ení a výsledná struktura systému. Pro ukázku jsou uvedeny i n¥které zajímavé kódy. První £ást této kapitoly se zabývá funkcí jednotlivých sloºek a soubor· systému. Dal²í kapitola je zam¥°ena na t°ídy, kdy jsou popsány spí²e obecn¥, jak jsou £len¥né a jaké obecn¥ obsahují funkce. T°etí podsekce rozebírá generování stránky, jaké skripty a v jaké posloupnosti se na£ítají. V dal²í £ásti je popsáno jak byly pouºity jednotlivé moduly, které byly popsány v návrhu. A poslední podkapitola pak pojednává o zabezpe£ení systému. 7.1

Sloºky a soubory systému

Ko°enová sloºka je ur£ena výhradn¥ soubor·m aplika£ní a prezenta£ní vrstvy webu a souboru .htaccess. Soubory aplika£ní a prezenta£ní vrstvy informa£ního systému jsou ve sloºce admin123. V této sloºce jsou také podsloºky se soubory, které jsou výhradn¥ pro IS. T¥mi jsou styly a javascript pro prezenta£ní vrstvu IS. Dal²í sloºkou systému je ajax, kde jsou uloºené soubory s PHP skripty, pomocí kterých komunikuje AJAX se serverem. Takovým skriptem m·ºe skript, který vrací JSON s modely konkrétní zna£ky. V dal²í sloºce classes jsou uloºené ve²keré t°ídy reprezentující tabulky v databázi. T°ídy jsou pak blíºe popsané v dal²í podkapitole. Dal²í sloºka css je ur£ena pro styly webu. V této sloºce nejsou CSS soubory ºádných modul·, ty jsou vºdy s daným modulem pohromad¥. Sloºka documents je ur£ena pro ve²keré dokumenty vytvá°ené systémem. Protoºe systém vystavuje více typ· soubor·, má tato sloºka podsloºky orders pro faktury, contracts pro smlouvy a protocols pro protokoly. Následující sloºka les obsahuje soubory nahrané p°es sekci Soubory, který je v IS. Tato sloºka v²ak neobsahuje obrázky, které se spravují v sekci Obrázky, ty mají vlastní sloºku images. V ko°enu této sloºky jsou uloºené obrázky v nejv¥t²ím formátu denovaném v systému. Dále jsou pak ve sloºce podsloºky thumbs1-3 pro t°i men²í formáty obrázk· a podsloºka org, kde jsou obrázky ve velikosti v jaké byly nahrávány. Sloºka js jiº byla zmín¥na u IS, kde jsou v ní javascripty, v ko°enové sloºce má stejný ú£el, akorát javascripty v ní jsou ur£ené pro web. 55

56

KAPITOLA 7. IMPLEMENTACE NOVÉHO SYSTÉMU

Jednou z velmi d·leºitých sloºek je sloºka modules, který obsahuje v²echny moduly popsané v návrhu systému a dal²í pluginy, widgety apod. Dal²í sloºka pics slouºí jako úloºi²t¥ gracký prvk· jako jsou vlaje£ky, ikonky, loga a jiné obrázky, které se pouºívají v IS i na webu. Sloºka temp uzavírající °adu sloºek slouºí pouze jako do£asné úloºi²t¥ pro nahrávání soubor·. Po dokon£ení procesu jsou soubory z této sloºky okamºit¥ smazány. V popisu sloºek byla jedna sloºka vynechána a to sloºka includes. Jde o jednu ze st¥ºejních sloºek systému, resp. obsahující st¥ºejní soubory. T¥mi jsou cong.php, functions.php, db.php a action-report.php. Soubor cong.php obsahuje PHP skript, který je pot°eba vloºit na za£átek kaºdého skriptu, který je v systému spou²t¥n. Jde o inicializa£ní soubor systému. Deklarují se v n¥m konstanty s URL a cestami k systémovým sloºkám, s údaji pro p°ipojení s databází a jinými systémovými údaji jako je t°eba aktuální datum a £as nebo IP adresa klienta. Nastavuje se zde session pomocí funkcí pro zm¥nu php.ini, coº je kongura£ní soubor PHP na serveru. Také se v souboru includují v²echny nezbytné soubory systému v£etn¥ v²ech t°íd se sloºky classes a vytvá°í se objekty pro práci s databází a pro vytvá°ení systémových hlá²ek a upozorn¥ní. Na úplném za£átku se také zji²úje £as za£átku spu²t¥ní skriptu s p°esností na milisekundy, který pak spolu s £asem ukon£ení b¥hu skriptu vypo£ítává dobu generování stránky, která se pak zobrazuje v pati£ce stránky pro informování uºivatele. Tento soubor se také stará o to, jestli je uºivatel do systému p°ihlá²en jako administrátor nebo prodejce. V p°ípad¥ ºe je, na£te ve²keré údaje o administrátorovi. Pro n¥které údaje se vytvo°í konstanty, aby se zabezpe£ily hodnoty v rámci systému. Také inicializuje pole s údaji o tom, kam má uºivatel v systému p°ístup. Pokud ºádný administrátor p°ihlá²en není, nastaví se pot°ebné prom¥nné a konstanty na NULL. Celý PHP kód pro zpracování p°ihlá²ení administrátora je ukázán níºe. Na konci souboru se také na£ítají údaje o spole£nosti. U konstant nehrozí problém p°epsání, ale bohuºel do konstant nelze vloºit pole nebo na£íst objekt. Proto je t°eba ve v²ech dal²ích skriptech pod tímto inicializa£ním dávat pozor, aby systémové prom¥nné nebyly nep°epsány. Soubor functions.php je souborem funkcí, které dost £asto nahrazují nativní PHP funkce, které n¥jakým zp·sobem upravují nebo roz²i°ují. Funkcí v tomto souboru je n¥kolik desítek, je mezi nimi funkce pro vytvo°ení javascriptu Google Mapy, odeslání mailu, p°evedení £ísla na slovo, vytvo°ení stránkování a mnoho dal²ích. Pokud se u funkce pracuje s mnoha parametry nebo se po£ítá s tím, ºe se £asem m·ºe roz²í°it, má funkce denován pouze jeden parametr args, který musí být pole, které obsahuje ve²keré parametry, které by jinak musely být u funkce jednotliv¥ denované.

7.1. SLOKY A SOUBORY SYSTÉMU

57

if (isset($_SESSION['admin_id'])) { $admin = new Administrator($_SESSION['admin_id']); // vytvoreni objektu administratora $_SESSION['admin_id'] = $admin->get_id(); // prepis session // zjisteni, jestli administrator opravdu existuje a~oznacen jako aktivni if ($admin->get_id() && $admin->get_aktivni() && !$admin->get_smazano()) { define('ADMIN_ID', $admin->get_id()); define('ADMIN_ROLE', $admin->get_role()); define('ADMIN_PRODEJNA_ID', $admin->get_prodejna_id()); define('ADMIN_PRODEJCE_ID', $admin->get_prodejce_id()); $admin_kontakt = new Kontakt($admin->get_kontakt_id()); // nacteni kontaktnich udaju // nacteni prav uzivatele $args['where']['aktivni'] = 1; // doplneni $args $admin_prava = $admin->get_prava($args); unset($args); $admin_stranky = array(); // z~prav uzivatele se vytahnou stranky, ke kterym ma pristup a~podle toho se pak probere menu // pokud vnejakem pravu ma uzivatel nastaveno, ze ma pristup ke vsem strankam, je jasno if (check_array($admin_prava)) { foreach ($admin_prava as $row) { if ($row['stranka'] == '*') { $admin_stranky = '*'; break; } else { $admin_stranky[] = $row['stranka']; } } } } else { $no_admin = true; } } else { $no_admin = true; } // nastaveni promennych na~NULL, kdyz administrator prihlaseni neni if ($no_admin) { unset($admin); unset($_SESSION['admin_id']); define('ADMIN_ID', null); define('ADMIN_ROLE', null); define('ADMIN_PRODEJNA_ID', null); define('ADMIN_PRODEJCE_ID', null); $admin_stranky = false; }

Ukázka kódu 1: Zpracování administrátorského p°ístupu do IS v souboru cong.php Soubory db.php a action-report.php mají jedno spole£né. Ob¥ obsahují t°ídy, které jsou typu Singleton, coº je návrhový vzor, který omezuje instance t°ídy na jeden objekt. To je uºite£né, kdyº práv¥ jeden objekt je pot°eba ke koordinaci akcí nap°í£ celým systémem.[25] U obou t°íd se objekt vytvá°í p°es statickou metodu get_instance(). Ukázka této metody ze t°ídy DB je níºe. T°ída DB se pomocí n¥kolika funkcí stará o ve²kerou komunikaci s databází. Po£áte£ní spojení je tedy provedeno jiº ve funkci get_instance(), kde se p°ipojuje k databázi pomocí

58


funkce connect(), která se p°ipojuje za pouºití p°ihla²ovacích údaj· denovaných v souboru cong.php. Hned po p°ipojení se pomocí n¥kolika SQL dotaz· nastavuje kódování pro spojení s databází, které se nastavuje na UTF-8. Dal²ími funkce t°ída °e²í dotazování se na databázi pomocí SQL, napl¬ování dat do polí, získání pouze konkrétního údaje nebo po£tu získaných °ádk·. Tyto funkce v¥t²inou obalují nativní funkce PHP pro MySQL. Sou£ástí souboru db.php je také t°ída DBException, které je roz²í°ením t°ídy Exception a o²et°uje výjimky, které se mohou vyskytnout p°i spojení a dotazování na databázi. public static function get_instance() { if (self::$instance == null) { self::$instance = new DB(); self::$instance->connect(); } self::$instance->query("SET self::$instance->query("SET self::$instance->query("SET self::$instance->query("SET }

character_set_client=utf8mb4"); collation_connection=utf8mb4_unicode_ci"); character_set_connection=utf8mb4"); character_set_results=utf8mb4");

return self::$instance;

Ukázka kódu 2: Funkce pro vytvo°ení objektu t°ídy DB

T°ída ActionReport °e²í upozorn¥ní a hlá²ky systému, které se objevují po provedení n¥jaké akce, nap°. po p°idání nebo smazání poloºky. T°ída pracuje s globální prom¥nnou $_SESSION, coº je pole reprezentující session a do které t°ída ukládá údaje o hlá²ce, aby se p°enesly i p°es p°esm¥rování po úsp¥²ném prob¥hnutí akce. T°ída má t°i funkce a to pro nastavení hlá²ky, které se provádí p°i provád¥ní akce, pro získání hlá²ky p°i následujícím výpise a funkci pro zji²t¥ní, jestli je n¥jaká hlá²ka nastavená nebo ne. U hlá²ek uvádí text hlá²ky, její úsp¥²nost nebo neúsp¥²nost, jestli jde o hlá²ku pro front-end nebo back-end a umíst¥ní hlá²ky na stránce. public function set($report, $success = false, $admin = true, $location = '') { if ($admin) { $prefix = 'admin_'; }

}

$_SESSION[$prefix.'action_report'] = $report; $_SESSION[$prefix.'action_report_success'] = $success; $_SESSION[$prefix.'action_report_location'] = $location;

Ukázka kódu 3: Funkce pro nastavení hlá²ky

7.2. TÍDY

7.2

59

T°ídy

Jak jiº bylo zmín¥no, t°ídy reprezentují entity systému a tím pádem souvisí i s tabulkami databáze, kam se ukládájí data k t¥mto entitám. Atributy t°ídy kopírují sloupce tabulky a funkce t°ídy pak obalují operace, které lze s daty v tabulce provád¥t. Jak bylo popsáno v návrhu, toto °e²ení odpovídá návrhovému vzoru Active Record. P°ítomny jsou funkce pro p°idávání °ádk· do tabulky, pro aktualizaci dat, pro na£ítání a samoz°ejm¥ i pro mazání. Funkce pro mazání u v¥t²iny t°íd neobsahuje SQL dotaz obsahující formuli DELETE FROM, která °ádky z tabulky doopravdy maºe, ale °ádku se pouze nastaví hodnota u sloupce snazano na 1. Data, krom¥ t¥ch, které reprezentují soubory a obrázky a zabírají místo na serveru, se pouze ozna£ují jako smazaná, aby byla p°ípadn¥ snadno obnovitelná. To ale p°iná²í problém p°i na£ítání dat z tabulky, protoºe je pot°eba u SQL dotaz· p°edev²ím typu SELECT, u kterých musí být vºdy p°ítomna podmínka WHERE smazano = 0. T°ídy mají funkcí v¥t²inou daleko víc, které °e²í vazby s dal²ími tabulkami. P°íkladem m·ºe být vazba tabulky clanky a obrazky, která je °e²ena funkcí load_obrazky(), která získává obrázky p°i°azené £lánku. T°ída obecn¥ vypadá tak, ºe na jejím za£átku jsou deklarované její atributy jako privátní prom¥nné s výchozími hodnotami v¥t²inou 0 nebo null. Dal²í v °ad¥ je konstruktor, který má jeden tribut a to ID, které se váºe is ID °ádku v tabulce v DB. Pak nap°. $clanek = new Clanek(1) vytvo°í instanci t°ídy objekt, ve které jsou data ke £lánku, které má v databázi v tabulce clanky ID rovno 1. Po konstruktoru následují ve t°íd¥ denice tzv. getter· a setter·, coº jsou funkce, slouºící pro získávání a nastavování hodnota atribut· t°ídy, které jsou denované jako privátní a p°ímo s nimi m·ºe pracovat pouze sama t°ída. Tyto funkce pak umoº¬ují korigovat, co práci s hodnotami atribut· t°ídy. K t¥mto funkcím jsou i denované funkce, které umoº¬ují hromadné získávání a nastavování hodnot pomocí pole. Funkce get_vars_array() pro hromadné získání hodnota je velice jednoduchá, protoºe vyuºívá nativní PHP funkce get_object_vars(), která d¥lá p°esn¥ to, ºe atributy a hodnoty objektu p°evede na pole a to tak, ºe názvy atribut· jsou pak klí£e pole. Druhá funkce pro nastavování hodnot set_vars_array() je trochu komplikovan¥j²í, protoºe se musí kaºdá hodnota nastavit zvlá²´ a vyuºít k tomu p°íslu²ného setteru, aby byla daná hodnota nastavena °ádným zp·sobem. public function set_vars_array($vars) { if (isset($vars['id'])) { $this->set_id($vars['id']); } if (isset($vars['nazev'])) { $this->set_nazev($vars['nazev']); } if (isset($vars['obrazek_id'])) { $this->set_obrazek_id($vars['obrazek_id']); } if (isset($vars['poradi'])) { $this->set_poradi($vars['poradi']); } if (isset($vars['zobrazovat'])) { $this->set_zobrazovat($vars['zobrazovat']); } if (isset($vars['vytvoreno'])) { $this->set_vytvoreno($vars['vytvoreno']); } if (isset($vars['smazano'])) { $this->set_smazano($vars['smazano']); } } public function get_vars_array() { return get_object_vars($this); }

Ukázka kódu 4: Funkce pro hormadné nastavování a získání hodnot atribut· t°ídy pomocí pole

60


Funkce pro na£tení dat z ur£itého °ádku v tabulce v DB a nastavení instance má ve t°ídách název load(). Tato funkce se vyuºívá v konstruktoru p°i vytvo°ení instance t°ídy. Funkce má pouze jediný parametr a to $args, který se napl¬uje vícerozm¥rným polem. Toto °e²ení jiº bylo zmín¥no a u funkcí t°íd je hojn¥ pouºíváno, protoºe mnoºství parametr· je bývá velké. Ve funkci load() bývá pouze jedno podpole a to where, které denuje omezení pro výb¥r dat z DB a sestavuje tak SQL formuli WHERE. Pro nastavení hodnot se pak vyuºívá vý²e popsaná funkce set_vars_array().

public function load($args = null) { global $db; $types = ""; $params = array(); if (check_array($args['where'])) { foreach ($args['where'] as $key => $value) { switch ($key) { case 'id' : $where .= " AND clanky.id = ?"; $types .= 'i'; $params[] = $value; break; case 'nazev' : $where .= " AND clanky.nazev "; if (empty($value)) { $where .= "IS NULL"; } else { $where .= "= ?"; $types .= 's'; $params[] = $value; } break; case 'obrazek_id' : $where .= " AND clanky.obrazek_id "; if (empty($value)) { $where .= "IS NULL"; } else { $where .= "= ?"; $types .= 'i'; $params[] = $value; } break; case 'poradi' : $where .= " AND clanky.poradi = ?"; $types .= 'i'; $params[] = $value; break; case 'slozka_id' : $where .= " AND clanky.slozka_id = ?"; $types .= 'i'; $params[] = $value; break; case 'zobrazovat' : $where .= " AND clanky.zobrazovat = ?"; $types .= 'i'; $params[] = $value; break; case 'smazano' : $where .= " AND clanky.smazano = ?"; $types .= 'i'; $params[] = $value; break; } } } if (empty($where)) { $where = "id = ?"; $types = "i"; $params = $this->id; } else { $where = substr($where, 5); } $db->execute_query("SELECT * FROM clanky WHERE ".$where, $types, $params);

}

if ($db->num_rows()) { $row = $db->fetch_assoc(); $this->set_vars_array($row); return true; } else { return false; }

Ukázka kódu 5: Funkce pro získání dat instance t°ídy z DB a nastavení hodnot atribut·

61

7.2. TÍDY

Funkce pro ukládání dat instance t°ídy se provádí pomocí funkce save(), která podle atribut· a jejich hodnot a typ· t¥chto hodnot sestavuje SQL dotaz pro vloºení dat do DB. Vloºení m·ºe být pomocí SQL p°íkazu INSERT INTO nebo UPDATE podle toho, jestli °ádek dané instance v DB jiº existuje nebo ne, coº se zji²úje podle toho, jestli je nastavena hodnota atribudu id. Pokud se instance ukládá poprve a t°ída má atribut poradi, ur£íse po£áte£ní hodnota pomocí funkce get_max_poradi(). Pokud se entita reprezentovaná t°ídou °adí do sloºek, kontroluje se, jestli se neukládá kam nemá a p°íp. se ur£uje nové po°adí. public function save() { global $db; // objekt pro~praci s DB if (!$this->id) { // urceni poradi, pokud insert $this->poradi = self::get_max_poradi($this->slozka_id)+1; } else { // kontrola, jestli se clanek neuklada do jine slozky a~prip. urceni noveho poradi $query = "SELECT slozka_id FROM clanky WHERE id = ?"; $type = "i"; $param = $this->id; $db->execute_query($query, $type, $param);

}

if ($db->result() != $this->slozka_id) { $this->poradi = self::get_max_poradi($this->slozka_id)+1; }

$query = ""; $types = ""; $params = array(); $query .= "id = ?, "; $types .= "i"; $params[] = $this->id; if (!empty($this->nazev)) { $query .= "nazev = ?, "; $types .= "s"; $params[] = $this->nazev; } else { $query .= "nazev = NULL, "; } if (!empty($this->obrazek_id)) { $query .= "obrazek_id = ?, "; $types .= "i"; $params[] = $this->obrazek_id; } else { $query .= "obrazek_id = NULL, "; } $query .= "poradi = ?, "; $types .= "i"; $params[] = $this->poradi; $query .= "slozka_id = ?, "; $types .= "i"; $params[] = $this->slozka_id; $query .= "zobrazovat = ?, "; $types .= "i"; $params[] = $this->zobrazovat; if (!empty($this->vytvoreno)) { $query .= "vytvoreno = ?, "; $types .= "s"; $params[] = $this->vytvoreno; } else { $query .= "vytvoreno = NOW(), "; } $query .= "smazano = ?, "; $types .= "i"; $params[] = $this->smazano; $query = substr($query, 0, -2); if ($this->id) { $types .= "i"; $params[] = $this->id; $db->execute_query("UPDATE clanky SET ".$query." WHERE id = ?", $types, $params); } else { $db->execute_query("INSERT INTO clanky SET ".$query."", $types, $params); $this->id = $db->insert_id(); } }

return true;

Ukázka kódu 6: Funkce pro uloºení instance t°ídy do DB

62


Dal²í standardní funkcí t°ídy je funkce delete(), která °e²í mazání poloºky a ve které se v¥t²inou pomocí SQL p°íkazu UPDATE nastavuje hodnota ve sloupci smazano na 1. Pokud tento sloupec neexistuje, maºe se °ádek v tabulce úpln¥ pomocí DELETE FROM. V takové p°ípad¥ je pak pot°eba °e²it je²t¥ ru²ení existujících spojení na dal²í tabulky. Funkce check() slouºí ke kontrole dat p°i p°idávání nebo editace. Kontrolují se stanovené povinné údaje a p°íp. správnost a smysluplnost t¥chto údaj·. Klasickým p°íkladem je kontrola emailové adresy, jestli obsahuje znak @ a te£ku p°ed posledními n¥kolika písmeny. astá je také kontrola, jestli se název poloºky uº neexistuje nap°. ve sloºce, kam se poloºka ukládá. Funkce check() v p°ípad¥ nalezení n¥jaké chyby vrací pole s chybovými hlá²kami. Indexy tohoto pole jsou názvy atribut·, u nichº byla chyba nalezena. Funkce se pouºívá v aplika£ní logice p°ed volání funkce save(). Hlá²ky v poli se pak vypisují u jednotlivých poloºek edita£ního formulá°e. public function check() { $form_errors = array(); if (empty($this->nazev)) { $form_errors['nazev'] = '<span class="form_error">Udaj musi byt zadan.'; } else if (!$this->check_nazev()) { $form_errors['nazev'] = '<span class="form_error">Tento nazev jiz ve slozce existuje.'; } if (empty($this->email)) { $form_errors['email'] = '<span class="form_error">Udaj musi byt zadan.'; } else if (!is_email($this->email)) { $form_errors['email'] = '<span class="form_error">Email musi mit spravny format.'; } }

return $form_errors;

Ukázka kódu 7: Funkce pro zji²t¥ni chyb v zadaných údajích instance Ve t°íd¥ je dal²í b¥ºnou funkcí statická funkce pro hromadné na£ítání poloºek, která vrací více rozm¥rné pole. Funkce se nazývá load_polozky(), kdy "polozky"ve v¥t²in¥ p°ípad· nahrazuje název tabulky DB. Tato funkce je £áste£n¥ podobná funkci load() a to p°edev²ím kv·li °e²ení parametr· a sestavování podmínek pro výb¥r poloºek. Protoºe ale jde seznam poloºek, °e²í se zde i °azení pomocí formule ORDER BY nebo omezení po£tu poloºek p°es formuli LIMIT. Podobn¥ jako je funkce pro hromadné na£ítání, existuje ve t°íd¥ i funkce pro hromadné mazání, která vyuºívá funkce delete(). Pokud se poloºky dají °adit i do sloºek, existují i funkce pro hromadné kopírování a p°esouvání. Funkce pro p°esouvání je jednoduchá, u kaºdé poloºky se pouze zkontroluje, jestli se nep°esouvá kam nemá a pak je uº jen zm¥ní reference na sloºku. U kopírování jde o trochu sloºit¥j²í proces, protoºe se musí °e²it i kopírování vazeb a pokud se na poloºku váºe i soubor na serveru, musí se °e²it i zkopírování tohoto souboru. Je-li umoºn¥no °azení, existuje v t°íd¥ atribut poradi a p°idávání, kopírování nebo p°esouvání se musí °e²it po°adí vzhledem k ostatním poloºkám. Pokud se mezi poloºky n¥jakým

63

7.3. GENEROVÁNÍ STRÁNKY

zp·sobem p°idává nová, umisúje se automaticky na konec a k tomu slouºí statická funkce get_max_poradi(), která vrací maximální po°adí n¥jakého celku (nap°. sloºky). Dal²í standardní funkcí ve t°íd¥ j¥ get_page_url(), která ur£uje stránku seznamu poloºek, na které se poloºka vyskytuje, aby nap°. po editaci, kdy systém sm¥ruje na seznam, nebyl uºivatel p°esm¥rován na za£átek, ale tam odkud do editace p°e²el. Ve t°íd¥ je také b¥ºná funkce get_url(), která vrací nap°. URL £lánku nebo vozu. asté jsou také funkce na formátování údaj· jako jsou cena nebo datum. Cena se nap°. rozd¥luje po t°ech £íslech a p°idá se m¥na, datum se pak zformátuje pomocí funkce format_date(), ze souboru functions.php, ze systémového formátu rrrr-mm-dd do £eského d.m.rrrr. 7.3

Generování stránky

Generování b¥ºné stránky v systému je primárn¥ °ízeno souborem index.php, kterému se v URL parametru zadá poºadovaná stránka pro zobrazení. Na prvním míst¥ se v souboru index.php na£te soubor cong.php, ve kterém jsou deklarované ve²keré pot°ebné prom¥nné a konstanty a na£teny soubory pot°ebné pro b¥h skriptu IS. Poté se zji²úje, jestli je zadán poºadavek na stránku, jinak se p°esm¥rovává na úvodní stránku. Poºadavek je zadán, kontroluje se, jestli existují soubory s aplika£ní a prezenta£ní logikou pro poºadovanou stránku. Pokud ne, prob¥hne p°esm¥rování na stránku o²et°ující stavové HTTP kódy 4xx, v tomto p°ípad¥ 404 (Stránka nenalezena). Pokud soubory prezenta£ní a aplika£ní logiky existují naincludují se soubory hlavi£ky, dané stránky a pati£ky, které obsahují aplika£ní logiku a poté ve stejném po°adí soubory s prezenta£ní logikou, £ímº je sestavování skriptu pro generování stránky hotové. INDEX.PHP

CONFIG.PHP HEADER.PHP

HEADER.HTML.PHP

- PAGE - .PHP

- PAGE - .HTML.PHP

FOOTER.PHP

FOOTER.HTML.PHP

DB.PHP

FUNCTIONS.PHP

ACTION-REPORT.PHP

- CLASSES - .PHP

Obrázek 7.1: Znázorn¥ní posloupnosti na£ítání soubor· systému (shora dol·, zleva doprava)

64


Soubor index.php o²et°uje a zpracovává i jiné systémové záleºitosti a události. Kontroluje, jestli je v·bec n¥jaký uºivatel p°ihlá²ený a má tedy p°ístup k n¥jaké stránce. Pokud ne, p°esm¥ruje ho na p°ihlá²ení. Stejn¥ tak °e²í, jestli k poºadované stránce má uºivatel v·bec práva pro p°ístup. V tomto souboru se také o²et°uje zm¥na prodejny prodejce. Také se °e²í otevírání stránek v pop-up okn¥ nebo v modulu prettyPhoto, ve kterých by se nem¥la objevovat hlavi£ka stránky. Soubor s aplika£ní logikou stránky je rozd¥len na dv¥ £ásti. Jedna se stará o zpracování akcí jako je odeslání formulá°· pro p°idání nebo editaci poloºky, poºadavek na smazání nebo hromadné operace a jiné dal²í operace, které jsou s poloºkami moºné. Druhá £ást °e²í na£ítání a zpracování dat výpis do stránek, p°ipravuje tedy data pro prezenta£ní vrstvu. V prezenta£ní vrstv¥ se uº jen podle parametr· v URL ur£uje, jaký HTML kód se má vypsat. Soubory hlavi£ky a pati£ky jsou podobné, akorát aplika£ní soubor není nijak rozd¥len na dv¥ £ásti, protoºe se v n¥m ºádné akce nezpracovávají. Uºivatelská práva jsou °e²ena tak, ºe kaºdý administrátor má denované jaké stránky a jaké akce m·ºe na stránce provád¥t. Toto se kontroluje jak v aplika£ní vrstv¥, kde se poºadováná stránka a akce porovnávají s právy uºivatele, tak v prezenta£ní, kde se bu¤ pomocí PHP skrývají poloºky menu a dal²í ovládací prvky odkazující na dané stránky nebo se akce zakazují pomocí jQuery. To je °e²eno tím zp·sobem, ºe je odkaz bu¤ odebrán nebo deaktivován s oznámením, ºe uºivatel nemá pro daný odkaz oprávn¥ní. jQuery porovnává práva uºivatele pomocí AJAX.

public static function check_prava_administratora($stranka, $akce) { // situace, kdy ma uzivatel pristup vzdy if (ADMIN_ROLE == 1 || $stranka == 'uvod' || $stranka == 'http-chyby' || empty($stranka)) { return true; } // nacteni platnych prav administratora pro~danou stranku a~akci $args['where']['stranka_or_all'] = $stranka; $args['where']['akce_or_all'] = ($akce ? $akce : '#'); // # znamena uvod stranky (napr. vypis polozek) $args['where']['administrator_id'] = ADMIN_ID; $args['where']['aktivni'] = 1; $args['where']['smazano'] = 0; $prava = PravoAdministratora::load_prava($args); unset($args);

}

// pokud se neco nacetlo, administrator prava ma, jinak ne if (check_array($prava)) { return true; } else { return false; }

Ukázka kódu 8: Funkce t°ídy Administrátor pro zji²t¥ní práv uºivatele pro konkrétní stránku a akci

7.4. POUITÍ MODUL A SLUEB

7.4

65

Pouºití modul· a sluºeb

7.4.1 jQuery V systému je za pouºití jQuery a Javascriptu °e²eno mnoho v¥cí jako je skrývání poloºek, úprava vlastností HTML element·, potvrzování zdánliv¥ nevratných operací a mnoho dal²ích v¥cí, které by jinak ani °e²it ne²ly nebo by °e²ení bylo komplikované. P°íkladem m·ºe být upozorn¥ní uºivatele, kdyº chce opustit stránku s formulá°em, do kterého jiº doplnil nebo v n¥m pozm¥nil data. Kód toho °e²ení je ukázán níºe. Zajímavostí je °e²ení pro CKEditor, do kterého se musel nainstalovat modul, aby se dala zm¥na dat v n¥m zjistit. window.formChangesMade = false; $(window).load(function(e) { if (window.top.length < 2) { jQuery("form.check-changes input, form.check-changes textarea").on('keyup', function(e) { window.formChangesMade = true; }); jQuery("form.check-changes input, form.check-changes textarea").on('mouseup', function(e) { window.formChangesMade = true; }); jQuery("form.check-changes select").on('change', function(e) { window.formChangesMade = true; }); for (var i~in CKEDITOR.instances) { CKEDITOR.instances[i].on('change', function(e) { window.formChangesMade = true; }); }

} });

// pokud se klika na tlaticko ulozit, hlaska se neukazuje ani kdyz byly provedeny zmeny jQuery("form.check-changes input[type=submit]").on('click', function(e) { window.formChangesMade = false; });

jQuery(window).bind('beforeunload', function (e) { if (window.formChangesMade) { e.preventDefault(); var message = 'Vami zadana data mohou byt ztracena.'; return message;

} });

e.cancelBubble = true; e.returnValue = message; //e.stopPropagation works in Firefox. if (e.stopPropagation) { e.stopPropagation(); }

Ukázka kódu 9: Funkce pro zji²t¥ni chyb v zadaných údajích instance

66


7.4.2 Bootstrap Pomocí modulu Bootstrap je °e²ené celé uºivatelské rozhraní systému. Modul spolupracuje také s jQuery a stejn¥ jednodu²e je i nasaditelný pouze p°idáním odkaz· na p°íslu²né soubory do HTML hlavi£ky stránky. Vzhled nadenovaných prvk· není problém upravit a p°izp·sobit vlastními styly.

Obrázek 7.2: Ukázka uºivatelského rozhraní systému °e²eného pomocí Bootstrapu

7.4.3 CKEditor CKEditor je v systému pouºit pro formátování text· £lánk·. Pomocí kongura£ního souboru byl nadenován panel nástroj·, který pokrývá ve²keré pot°eby uºivatel·. Také bylo provedeno propojení s databází obrázk· a soubor·, aby bylo moºné vkládat obrázky a odkazy na soubory, které jiº v systému existují a nebo je pohodln¥ nahrát zp·sobem, na který jsou uºivatelé zvyklí. U odkaz· byly také p°idány moºnosti odkazovat do modulu prettyPhoto.

7.4.4 prettyPhoto Modul prettyPhoto je nejen vyuºit pro prohlíºení obrázk·, ale také pro otevírání r·zných stránek. Vyuºívá se nap°. p°i p°i°azování obrázk·, kdy se v tomto modulu otev°e stránka obrázky v reºimu, kdy je moºné vybrat libovolné obrázky a hromadn¥ je p°i°adit t°eba vozu nebo £lánku. Jindy se prettyPhoto vyuºívá pro prohlíºení nebo editaci poloºek, které jsou v seznamu jiných poloºek (nap°. prodejna v seznamu objednávek, viz obrázek níºe) a normální odkaz by byl nesystémový kv·li vracení se na daný výpis poloºek. Takto se otev°e edita£ní formulá° nad seznamem, poloºka se upraví a po zav°ení prettyPhoto se seznam poloºek obnoví, aby se projevily p°ípadné zm¥ny, které editace zp·sobila.

7.4. POUITÍ MODUL A SLUEB

67

Obrázek 7.3: Ukázka edita£ního formulá°e na£teného vprettyPhoto

7.4.5 mPDF T°ída mPDF slouºí v systému k vytvá°ení PDF faktur, smluv a protokol·, kdy se tyto PDF ukládají na server. Generování PDF zaji²úje v t°ídách reprezentujících dané dokumenty funkce create_pdf(). V této funkci se na£ítají a zpracovávají údaje pot°ebné pro dokument se sestavuje se HTML kód, ze kterého je pak PDF vytvo°eno. require_once(MODULES_PATH.'mpdf/mpdf.php'); // nacteni souboru se tridou mPDF $mpdf = new mPDF('utf-8'); $mpdf->SetFooter('Cislo faktury: '.$this->cislo.' || Stranka: {PAGENO}/{nb}'); // nastaveni paticky PDF $mpdf->WriteHTML($html); // vlozeni HTML kodu, ze ktereho je vygenerovan obsah PDF $mpdf->Output(DOCUMENTS_PATH.'invoices/faktura-'.$this->cislo.'.pdf', 'F'); // ulozeni souboru

Ukázka kódu 10: Kód pro vytvo°ení PDF z HTML pomocí t°ídy mPDF

7.4.6 PHPMailer V souboru functions.php je denována funkce send_mail() ur£ená k odesílání mail· za jakýmkoliv u£elem. Ve funkci se pracuje s mnoha parametry a v budoucnu mohou p°ibýt dal²í, takºe má op¥t jediný parametr $args, který ve²keré parametry sdruºuje v poli. Hlavní parametry jsou email odesílatele a p°íjmence, p°edm¥t a text mailu. Ukázka toho, jak se ve funkci send_mail() pracuje a vyuºívá t°ídy PHPMailer je níºe.

68


require_once(MODULES_PATH.'phpmailer/class.phpmailer.php'); // nacteni souboru se tridou PHPMailer $mail = new PHPMailer(); $mail->SetLanguage("cz", MODULES_PATH.'phpmailer/language/'); // nastaveni jazyka mailu $mail->CharSet = "utf-8"; // kodovani mailu $mail->From = $from; // adresa odesilatele $mail->FromName = $from_name; // jmeno odesilatele $mail->AddAddress($to, $to_name); // definovani prijemce $mail->AddReplyTo($from, $from_name); // definovani adresy pro odpoved $mail->WordWrap = 50; // nastaveni zalamovani $mail->IsHTML(true); // mail se odesila ve~formatu HTML $mail->Subject = $subject; // predmet mailu $mail->Body = $text; // HTML kod, ktery je obsahem mailu $mail->Send(); // odeslani

Ukázka kódu 11: Kód pro odeslání mailu pomocí PHPMaileru

7.4.7 Google Mapy O zobrazování Google map v systému se stará funkce get_map_js(), která má stejn¥ jako t°eba funkce send_mail() jen jeden parametr, kterým je pole, protoºe moºností nastavování mapy je mnoho a pole je jednodu²e roz²i°itelné. Funkce get_map_js() vrací, jak jiº název napovídá, Javascript kód pro zobrazení mapy, který je sestavován na základ¥ Google Maps API v3. Jde o nejnov¥j²í verzi toho programátorského rozhraní. Podle zadaných parametr· se vyuºívá nebo nevyuºívá r·zných funkcí API. P°íkladem je moºnost p°ibliºování pomocí kole£ka my²i nebo moºnost p°esouvání ²pendlíku, coº je p°i editaci mapy vyuºíváno jako jedna zmoºností ur£ení pozice na map¥. Moºnosti zadávání umíst¥ní na map¥ jsou celkem t°i. Jedne je tedy zmín¥né p°esouvání ²pendlíku, druhá je zadáním konkrétních GPS a t°etí moºnost je zadat adresu nebo její £ást a podle ní se pokusit vyhled umíst¥ní. Toto se provádí pomocí funkce search_address() denované v souboru functions.js ve sloºce js. Dal²ím parametrem vedle GPS, který se u mapy ukládá je úrov¥¬ p°iblíºení. Tyto hodnoty jsou ukládány do skrytých formulá°ových polí a editovány pomocí jQuery podle toho, jak se m¥ní na map¥. function search_address(address) { geocoder.geocode({ address: address}, function(responses) { if (responses && responses.length > 0) { // adresa byla nalezena // nastaveni spendliku na mape podle vracenych GPS set_marker_position(responses[0].geometry.location.lat(), responses[0].geometry.location.lng()); // vlozeni GPS mista do~formulare set_marker_position_inputs(responses[0].geometry.location.lat(), responses[0].geo..loc..lng()); // nastaveni stredu mapy podle GPS set_map_center(responses[0].geometry.location.lat(), responses[0].geometry.location.lng()); } else { // adresa nebyla nalezena unset_marker_position_inputs(); // vynulovani GPS ve formulari alert('Adresa bohuzel nebyla nalezena'); // zobrazeni dialogoveho okna } }); }

Ukázka kódu 12: Funkce pro ur£ování umíst¥ní na Google map¥ podle adresy

7.5. ZABEZPEENÍ

7.5

69

Zabezpe£ení

Zabezpe£ení systému a p°edev²ím dat, se kterými pracuje, bylo jedním z prioritních aspekt· p°i implimentaci. N¥které v¥ci ohledn¥ zabezpe£ení ani nebylo t°eba °e²it, protoºe jsou °e²eny na úrovni serveru. To je nap°. zálohování, které se provádí inkrementáln¥ a zálohy jsou dostupné minimáln¥ dva týdny na zp¥t. Provádí se zálohy soubor· i DB. Zárove¬ jsou data uloºená sou£asn¥ na dvou zrcadlících se discích, coº je chrání p°i po²kození jednoho z disk·. V·£i vn¥j²ím vliv·m i proti krád¥ºi je server v bezpe£í v chrán¥ných prostorách správce serveru. Bezpe£nostní problémy, které bylo t°eba °e²it na úrovni samotného systému, byly SQL Injection14 , XSS (Cross Site Scripting)15 , práva uºivatel· a maximální zabrán¥ní provedení nevratných zm¥n. Zabezpe£ení SQL dotaz· proti SQL Injection je v systému °e²eni pomocí parametrizovaných dotaz·, které ve t°íde DB zpracovává funkce execute_query(), které se p°edávají t°í parametry - SQL dotaz, °et¥zec typ· hodnot parametr· v SQL dotazu a pole hodnot parametr·. public function execute_query($query, $types = null, $params = null) { if (!is_array($params)) { $params = array($params); } // pokud nejsou zadany parametry, neni treba parametrizovaneho dotazu, staci normalni if (!$types || !$params) { return $this->query($query); } $stmt = mysqli_stmt_init($this->db_link); if ($stmt->prepare($query)) { // priprava SQL dotazu // prevedeni typu hodnota a~pole hodnota na parametry funkce bind_param, ktera je spoji s dotazem call_user_func_array( array($stmt, 'bind_param'), array_merge(array($types), $this->make_values_referenced($params)));

}

$executed = $stmt->execute(); // provedeno dotazu $this->result = $stmt->get_result(); // zaznameni vysledku

// osetreni vyjimek if (!$executed) { throw new DBException(mysqli_error($this->db_link), $query); } }

return $this->result; // vraceni vysledku dotazu

Ukázka kódu 13: Funkce t°ídy DB pro zpracování parametrizovaného dotazu XSS je °e²ené výhradním pouºíváním absolutních cest jak u odkaz·, tak p°i includování soubor·. Na£ítání stránky navíc funguje na základ¥ URL parametru, kdy se pak o²et°uje, jestli soubory pro stránku na serveru existují. Pokus o nastr£ení n¥jakého skriptu by akorát 14 15

http://en.wikipedia.org/wiki/SQL_injection https://en.wikipedia.org/wiki/Cross-site_scripting

70


skon£il hlá²kou, ºe stránka nebyla nalezena, ale nic by se nestalo. O²et°ované jsou i jiné URL parametry a zárove¬ jsou v php.ini vypnuty moºnosti allow_url_fopen a allow_url_include, coº znemoº¬uje includování soubor· pomocí URL, ale je pot°eba pouºívat cestu (path). Cesty, ze kterých je moºné na£ítat, jsou v PHP nastaveny jen na danou doménu. Zabezpe£ení proti úmyslnému i neumýslnému po²kození samotnými uºivateli systému je na prvním míst¥ moºnost denice jejich práv a jejich kontrola p°edev²ím v aplika£ní £ásti systému. Tento bezpe£nostní problém je také °e²en nemazáním v¥t²iny poloºek, ale pouhým ozna£ováním jako smazané. A ta data, která se doopravy maºou, jsou p°edev²ím obrázky a soubory, které si spole£nost uchovává. Ur£it¥ by se p°i kaºdodenní práci se systémem brzy zjistilo, ºe chybí a obnovily by se ze záloh. Rizikovým místem systému je beze sporu formulá° pro p°ihlá²ení do systému, který je chrán¥n uº jen svým umíst¥ním na adrese /admin123, coº není ºádná z klasických adres pro p°ístup k IS a £áste£n¥ to zabra¬uje úto£ník·m, aby se k formulá°i v·bec dostali. Pokud by se i p°esto stalo, je po£et pokus· pro p°ihlá²ení omezen na t°i, poté se p°ihla²ování zablokuje a je t°eba ho odblokovat speciálním odkazem. A na posledním míst¥ jsou p°ihla²ovací údaje porovnávany dv¥ma r·znými zp·soby, aby bylo maximáln¥ ov¥°eno, ºe uºivatel je tím, za koho se vydává. K ²ifrování hesel je pouºito SHA-2, konkrétn¥ SHA-512, coº je v sou£asnosti jedeno z nejsiln¥j²ích ²ifrování.

Kapitola 8

Úpravy webových stránek Tato kapitola pojednává o úprav¥ front-endu vzhledem k novému IS. Zde nastala celkem zásadní zm¥na, protoºe se Autobazar AB ustoupil od p·vodního zám¥ru, kdy se stávájící front-end m¥l pouze upravit, tak aby fungoval s novým systém, a rozhodl se pro kompletní p°ed¥lání. Nem¥lo smysl starý web sloºit¥ upravovat, kdyº se paraleln¥ s novým IS vývíjí i nový front-end. Jediné, co se na p·vodním front-endu ud¥lalo, bylo vimplementování kód· pro základní propojení s Facebookem. V této kapitole je p°edev²ím popsán návrh nového front-endu, který je znázorn¥n wireframy[28], coº je hrubý ná£rt rozvrºení stránky a jejích prvk·. Wireframy byly vytvo°ené pomocí online nástroje Mockup Builder16 . V kapitole je také popsáno propojení s Facebookem u nových stránek a vyuºití sluºek AddThis.com. U wirefram· byl brán ohled na poºadavek autobazaru, aby spole£nost z·stava v anonymit¥. Z tohoto d·vodu jsou rozmazány n¥které údaje, které by mohly vést ke zji²t¥ní jména spole£nosti. D·leºitými aspekty p°i návrhu nového front-endu byl snadný p°ístup k informacím, jejich p°ehlednost, provázanost webu, informování o vozech a sluºbách na kaºdé stránce, propojení s FB stránkou spole£nosti a snadná moºnost kontaktování spole£nosti. 8.1

Úvodní stránka

Nejv¥t²í rozdíl na front-endu nastal na úvodní stránce, kde je v sou£asné dob¥ katalog v²ech nabízených voz·. Nov¥ by úvodní stránka m¥la slouºit více jako rozcestník s informacemi o spole£nosti a o produktech a sluºbách, které nabízí. Zárove¬ by m¥la zákazníka upozornit na nové nebo n¥£ím zajímavé vozy nebo nové £i výhodné sluºby. Aby se vykompenzovalo to, ºe zákazník p°ímo nevidí celý katalog voz·, je na za£átku stránky navrºen ltr pro výb¥r voz· podle n¥kolik nejd·leºit¥j²ích parametr· vozu. Vedle by pak m¥ly být dva boxy s vozy, které jsou bu¤ vybírané automaticky (nap°. 10 nejnov¥j²ích) nebo jsou ur£eny, ºe je autobazar pot°ebuje zpropagovat. Pod ltrem jsou pak bannery na vybrané skupiny voz·, které jsou aktuální nebo je pot°eba na n¥ zákazníka více upozornit. Dále jsou na úvodní stránce informace o sluºbách, odkazy na £lánky o vozech, které Autobazar na svých stránkách publikuje, a nedílnou sou£ástí úvodní stránky je také Facebook box. 16

http://mockupbuilder.com/

71

72

KAPITOLA 8. ÚPRAVY WEBOVÝCH STRÁNEK

Na kaºdé stránce na spodu se nov¥ budou uvád¥t i bannery partner· a zp°ízn¥ných spole£ností. Pati£ka je také obohacena o kontaktní formulá° a navigaci, který dupluje hlavní menu.

Obrázek 8.1: Vý°ez wireframu úvodní stránky 8.2

Katalog voz·

Dal²í velké a d·leºité zm¥ny zaznamenal katalog voz·, kde vozy a základní informace o nich nebudou nov¥ v úzkých °ádcích ale ve vet²ích boxech, coº poskytuje prostor pro v¥t²í náhledovou fotograi, odkazy na poptávku a d·leºité informace nap°. o výbav¥ vozu. Jelikoº ale toto °e²ení zabírá na vý²ku daleko více místa neº dosavadní °adek, kdy i tak stránka se v²emi vozy byla velmi dlouhá, budou se vozy stránkovat.

73

8.3. DETAIL VOZU

Podobn¥ jako i ostatní stránky je katalog navrºen dvousloupcov¥. V pravém ²ír²ím sloupci jsou vypsané vozy a v pravidelných intervalech mezi n¥ mohou být vloºeny upoutávkové bannery. Levý sloupec je pak o n¥co r·znorod¥j²í, za£íná ltrem voz·, který je v podstat¥ roz²í°ením toho, co je na úvodní stránce. Poté následují odkazy na skupiny vozu, coº je také jakýsi druh ltru. Tímto kon£í ovládací prvky vztahující se ke katalogu a ve sloupci následují odkazy na £lánky, sluºby nebo Facebook box. U katalogu jsou také navrºeny záloºky, kdy se je²t¥ po£ítalo se zachováním dlouhodobých pronájm·. Jedna záloºka ale pat°í oblíbeným, coº je funk£nost, která je i na stávajícím webu, ºe si náv²t¥vník p°i pr·chodu katalog m·ºe vozy zaklikávat jako oblíbené a pod touto záloºkou je pak má v²echny pohromad¥.

Obrázek 8.2: Vý°ez wireframu katalogu voz· 8.3

Detail vozu

Stránka s detialem vozu byla také úpln¥ od základu nov¥ navrºena. Návrh je inspirován detaily produkt· z r·zných internetových obchod·. Nebylo to z d·vodu nedostatku fantazie nebo snahy ukrást n¥£í nápad, ale spí²e zjistit, na co jsou uºivatelé internetu zvyklí a nabídnout jim stránku, na které snadno najdou ve²keré pot°ebné informace. Trend v detailech produkt· je takový, ºe na za£átku je relativn¥ velká náhledová fotka, vedle které jsou základní informace jako název, krátky popis, cena a dal²í. Roz²í°ený popis, fotograe, p°íslu²enství a jiné poloºky související s produktem jsou rozd¥leny do záloºek. Detail je v základu °e²en tak jak bylo popsáno a je roz²í°en a upraven pro pot°eby voz· a Autobazaru AB. Pod velkou náhledovou fotkou jsou malé, mezi kterými se lze posouvat

74


²ipkami nebo kliknutím na odkaz níºe p°ejít do záloºky Fotograe, kde jsou v²echny náhledy vid¥t najednou. Vpravo od fotograe jsou pak po základními informacemi r·zné moºnosti kontaktování p°es zelenou linku, dotazem na prodejce nebo zadáním poptávky na jiný v·z (hlídací pes). Na záloºkami jsou je²t¥ umíst¥ny upoutávky na sluºby autobazaru, které mohou zákazníkovi moct v rozhodování nap°. co se nancování týká nebo mu mohou vnuknout t°eba my²lenku na p°estav¥ní vozu na LPG. Záloºky jsou v základu t°i - Informace o voze, Fotograe a Dopl¬kové úpravy a p°íslu²enství. Na wireframu je je²t¥ Historie vozu, která m¥la být p°ístupná pouze pro prodejce, ale nakonec se d¥lat nebude, protoºe ve²kerou historii vozu má prodejce v IS. Na první záloºce Informace o voze jsou ve²keré parametry a údaje o vozidle, popis a výbava. Záloºka Fotograe komentá° nepot°ebuje a poslední Dopl¬kové úpravy a p°íslu²enství je nábídka úprav, které je moºné u vozu ud¥lat, a p°íslu²enství, které je moºné s vozem koupit.

Obrázek 8.3: Vý°ez wireframu detailu vozu

8.4. LÁNKY

8.4

75

lánky

Stránka £lánku jako takového tolik zm¥n¥na nebyla, pouze p°íbyly fotograe, soubory a mapa. Nov¥ je u £lánk· navrºen jejich výpis, který dosud chyb¥l a bylo moºné se dostat jen p°ímo na konkrétní £lánek p°es vysouvací menu nebo postranní menu vedle £lánku. V novém návrhu seznamu £lánk· se vypisuje název a popis £lánku a náhledový obrázek. Seznam je trochu atypický v tom, ºe druhý uº²í sloupec s informacemi a odkazy na jiné sekce webu a Facebook jsou vpravo a ne vlevo jako na v¥t²in¥ stránek. Ve £lánku uº je toto °e²eno klasicky jako na ostatních stránkách a na za£átku sloupce je menu s odkazy na ostatní £lánky sekce. 8.5

Formulá°e

Byly navrºeny t°í základní formulá°e pro dotaz na v·z, poptávku nancování a hlídacího psa. V²echny formulá°e mají spole£né to, ºe obsahují kontakty na autobazar a prodejce, jsou uvedeny základní informace, £eho se formulá° týká. Jedná-li se o konkrétní v·z, jsou uvedeny základní informace o tomto voze v£etn¥ malé fotograe. Podle velikosti a po£tu poloºek ve formulá°i je formulá° jedno nebo dvousloupcový a ostatní informace jsou bu¤ naho°e nebo vlevo. Formulá°e byly navrºeny tak, ºe se budou otevírat v prettyPhoto. Poznámka: wireframy v²ech typových stránek front-endu jsou na p°iloºeném CD. 8.6

Sociální sít¥ a jejich propojení s webem

Primární sociální sítí, kterou Autobazar AB vyuºívá, je Facebook. Stránku má také na Twitteru, který se automaticky synchronizuje s Facebookem a není pot°eba se o n¥j starat v p°ípad¥, ºe se tomu spole£nost nechce více v¥novat. Facebook poskytuje °adu plugin·, které je moºné na web vloºit. Jeden z nejuºite£n¥j²ích a nejpouºívan¥j²ích je Like Box17 , který zahrnuje jak tla£ítko "To se mi líbí", tak aktuální p°ísp¥vky na dané stránce,po£et "lajk·"18 a prolové fotky uºivatel·, kterým se stránka líbí. Zobrazování toho v²eho je navrºeno na úvodní stránce. Na ostatních stránkách se pak po£ítá uº jen se zmen²enou verzí, kde je pouze název stránky, tla£ítko "To se mi líbí"a po£et "lajk·". Pro integrování toho pluginu je jednoduché. Pouze se na místo, kde má box být, vloºí kód vygenerovaný na stránce Like Boxu. Facebook je sice nejpouºívan¥j²í sociální sítí, ale jinak je pouze jednou z mnoha, p°es kterou uºivatelé internetu sdílejí informace. Proto, aby uºivatelé jiných sociální sítí mohli sdílet stránky autobazaru, je vyuºito sluºby AddThis.com, která poskytuje pluginy pro sdílení na stovkách sociálních sítí a p°es email. Zárove¬ tato sluºba jednou týdn¥ posílá statistiky mailem o tom, jaké stránky a kolika uºivateli byly sdíleny. Integrace pluginu je op¥t velice jednoduchá a provádí se podobn¥ jako u FB. Na stránkách addthis.com je pot°eba se zaregistrovat, vygenerovat kód pluginu, vloºit na stránky a pak uº jen sledovat, jak ho náv²t¥vníci vyuºívají. 17 18

https://developers.facebook.com/docs/reference/plugins/like-box/ Po£et uºivatel·, kterým se stránka líbí

76


Obrázek 8.4: Nástoroj pro generování kódu Like Boxu na stránce pluginu

Obrázek 8.5: Ukázka pluginu AddThis pro sdílení stránky na sociálních sítích

Kapitola 9

Záv¥r Podle zadání a popisu problému byla provedena analýza a návrh nového informa£ního systému, který nahradí stávající nejednotné °e²ení dvou r·zných systém· - redak£ného a systému pro prodejce. Podle analýzy a návrhu byla provedena implementace nového systému. Systém je pro ú£ely této práce dostupný na http://www.hulin-mihalec.cz/dp/admin123/ (p°ihla²ovací údaje jsou "test"a "test"). Systém sice v dob¥ psaní t¥chto °ádk· není nasazen v ostrém provozu, ale je zcela p°ipraven ke spu²t¥ní. V sou£asné dob¥ probíhá pouze nální kontrola dat na stran¥ autobazaru a £eká se na pokyn od vedení. Reakce vedení i samotných zam¥stnanc· na nový systém jsou pozitivní. V²ichni uºivatelé se podíleli na vývoji a p°edev²ím na testování systému, coº bylo b¥hem vývoje velmi uºite£né. Testování probíhalo jak podle stru£ných scéná°· pro hlavní procesy systému (k dispozici na p°iloºeném CD), tak volným pohybování a zkou²ením uºivatel·. Zam¥stnanci v¥t²inou v¥d¥li a p°edev²ím chápali své role v systému a byli tak schopni pomáhat v nacházení nejen systémových chyb, ale také logických. Ty pak v¥t²inou musely být je²t¥ prodiskutovány s vedením spole£nosti, jestli to tak opravdu má být. Spolupráce s vedením spole£nosti byla trochu komplikovan¥j²í, protoºe b¥hem vývoje stále m¥nili poºadavky nebo °e²ili do detailu v¥ci, které v dané fázi vývoje nebyly relevatní. P°íkladem mohou být wireframy, kde sice ne²lo o velký problém, ale naprosto to vystihuje, jak se s vedením na vývoji systému spolupracovalo. Problém u wirefram· byl trochu o£ekáván, takºe bylo p°i p°edávání vedení zd·razn¥no, ºe jde pouze o návrh rozvrºením stránky a prvk·, nikoliv o nální podobu stránek. Vedení pak ale stejn¥ °e²ilo vedle graky i to, ºe ve wireframech jsou ²patn¥ poloºky menu nebo nevhodné texty. I p°es ob£asné nesnáze v komunikaci s vedením se vºdy na²la spole£ná °e£ a konstruktivní °e²ení. Jeden problém v²ak z·stal nedo°e²en a tím jsou p°esuny voz·. Vedení v dob¥, kdy uº za£ala implementace systému, za£alo pochybovat o nezbytnosti °e²ení tohoto procesu p°es systém, i kdyº b¥hem analýzy bylo jejich stanovisko jasné. Nakonec si rozmysleli, ºe p°i sou£asné situaci, kdy jsou místa s vozy pouze dv¥ a ve v¥t²in¥ p°ípad· p°esun koordinuje nebo p°ímo provádí n¥kdo z vedení, je schvalování a vystavování protokol· v systému zbyte£né. Rozpracované °e²ení p°esunu voz· v systému bylo odzálohováno a prozatím se v systému ne°e²í. P°esun vozu jako událost se zaznamenává nezávisle do historie vozu. A dohoda s vedením je taková, ºe dojde-li k n¥jakým zm¥nám, do°e²í se to dodate£n¥. Systém je stav¥n tak, ºe dodate£né dod¥lávání nebo zm¥na stávajích funkcionalit není problém. Toto bylo pro systém velmi zásadní, coº se potvrdilo uº b¥hem implementace, kdy 77

78

KAPITOLA 9. ZÁVR

bylo t°eba £asto n¥co upravovat podle poºadavk· vedení autobazaru. Autobazar AB je dynamická a rozvíjející se spole£nost, u které se nedají úpln¥ odhadnout pot°eby do budoucna. Díky exibilit¥ a roz²i°itelnosti systému by v²ak s ºádnými úpravami v budoucnu nem¥l být problém. Doufám a v¥°ím, ºe nový informa£ní systém splnil a p°ípadn¥ je²t¥ splní vyty£ené cíle, kterými jsou p°edev²ím zefektivn¥ní práce, sníºení reºijních náklad· a potaºmo zvý²ení zisk· spole£nosti. Tomu by také m¥lo pomoci integrování Facebookových plugin· a pluginu pro sdílení na sociálních sítích, coº jsou mocné nástroje pro propagaci a získávání nových zákazník·. Také v¥°ím, ºe nové webové stránky, které se v sou£asné dob¥ vyvíjí a jejiº návrh je sou£ásti této práce, pomohou spole£nosti v konkuren£ním boji a v lep²ím umíst¥ní ve vyhledáva£ích, coº spolu úzce souvisí. Za sebe tuto práci hodnotím jako velký osobní p°ínost, co se poznatk· a zku²eností pro praxi týká. Nejen samotná práce na projektu, ale také jednání se zákazníkem a spolupráce s rmou DIS Media byla pro m¥ velmi obohacující.

Literatura [1] Patterns of enterprise application architecture. Boston, U.S.: Pearson Education, Inc., 2004. ISBN 978-0-321-12742-6. http://books.google.cz/books?id=FyWZt5DdvFkC&printsec=frontcover#v=onepage&q&f=false. [2] AddThis [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.addthis.com/. [3] Adminer [online]. 2007, 2013 [cit. 2013-05-02]. Dostupné z: http://www.adminer.org/. [4] AJAX Tutorial. W3Schools Online Web Tutorials [online]. 1999, 2013 [cit. 2013-05-02]. Dostupné z: http://www.w3schools.com/ajax/. [5] Bootstrap [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://twitter.github.io/bootstrap/. [6] CKEditor [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://ckeditor.com/. [7] Cascading Style Sheets. World Wide Web Consortium (W3C) [online]. 2013 [cit. 201305-02]. Dostupné z: http://www.w3.org/Style/CSS/. [8] Cardinality Notations. Software Design Tutorials [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.smartdraw.com/resources/tutorials/cardinality-notations/. [9] Facebook API [online]. 2013 [cit. 2013-05-02]. Dostupné z: https://developers.facebook.com/. [10] jQuery File Upload [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://blueimp.github.io/jQuery-File-Upload/. [11] Google Maps API [online]. 2013 [cit. 2013-05-02]. Dostupné z: https://developers.google.com/maps/. [12] HTML. World Wide Web Consortium (W3C) [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.w3.org/html/. [13] IFML (Interaction Flow Modeling Language) [online]. 1997, 2013 [cit. 2013-05-02]. |Dostupné z: http://www.ifml.org/. 79

80

LITERATURA

[14] jQuery [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://jquery.com/. [15] jQuery Mobile [online]. 2013 [cit. 2013-05-02]., . Dostupné z: http://jquerymobile.com/. [16] jQuery UI [online]. 2013 [cit. 2013-05-02]., . Dostupné z: http://jqueryui.com/. [17] JavaScript Tutorial. W3Schools Online Web Tutorials [online]. 1999, 2013 [cit. 2013-0502]. Dostupné z: http://www.w3schools.com/js/. [18] mPDF [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.mpdf1.com/mpdf/. [19] MySQL [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.mysql.com/. [20] Object Management Group [online]. 1997, 2013 [cit. 2013-05-02]. Dostupné z: http://www.omg.org/. [21] PHP : Hypertext Preprocessor [online]. 2001, 2013 [cit. 2013-05-02]., . Dostupné z: http://www.php.net. [22] PHPMailer. GitHub [online]. 2013 [cit. 2013-05-02]., . Dostupné z: https://github.com/Synchro/PHPMailer. [23] prettyPhoto. No Margin For Errors [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.no-margin-for-errors.com/projects/prettyphoto-jquerylightbox-clone/. [24] Responsive Web Design. A List Apart: For People Who Make Websites [online]. 1998, 2013 [cit. 2013-05-02]. Dostupné z: http://alistapart.com/article/responsive-web-design. [25] Singleton design pattern in java. How to do in JAVA [online]. 2012 [cit. 2013-05-02]. Dostupné z: http://howtodoinjava.com/2012/10/22/singleton-design-pattern-in-java/. [26] SQL Tutorial. W3Schools Online Web Tutorials [online]. 1999, 2013 [cit. 2013-05-02]. Dostupné z: http://www.w3schools.com/sql/. [27] The Web Modeling Language [online]. 2003 [cit. 2013-05-02]. Dostupné z: http://www.webml.org. [28] BROWN, Dan M. Communicating design developing web site documentation for design and planning. 2nd ed. Berkeley, Calif: New Riders. ISBN 978-013-1385-399. [29] Web Service. World Wide Web Consortium (W3C) [online]. 2013 [cit. 2013-05-02]. Dostupné z: http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice.

Seznam obrázk· 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13

Diagram vztah· entit (ERD) pro v·z . . . . . . . . . . . . . Diagram vztah· entit (ERD) pro parametr vozu . . . . . . . Diagram vztah· entit (ERD) pro prodejnu . . . . . . . . . . Diagram vztah· entit (ERD) pro komunikaci se zákazníky . Diagram vztah· entit (ERD) pro objednávku vozu . . . . . Diagram vztah· entit (ERD) vztahujících se ke £lánk·m . . UML diagram znázor¬ující hierarchii uºivatel· IS . . . . . . Use-Case diagram administrátora voz· . . . . . . . . . . . . Use-Case diagram administrátora komunikace se zákazníky . Use-Case diagram administrátora £lánk· a multimédií . . . Activity Diagram - p°esun vozu . . . . . . . . . . . . . . . . Activity Diagram - objednávka . . . . . . . . . . . . . . . . Activity Diagram - komunikace se zákazníky . . . . . . . . .

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

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

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

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

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

22 24 25 27 30 33 35 36 37 38 39 40 41

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16

Ukázka nahrávání obrázk· p°es jQuery File Upload . . . . . . . . . . . Ukázka CKEditoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka Bootstrap hlavního panelu . . . . . . . . . . . . . . . . . . . . Ukázka Bootstrap drobe£kové navigace . . . . . . . . . . . . . . . . . . Ukázka Bootstrap ºáloºek . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka Bootstrap tabulky . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka Bootstrap stránkování . . . . . . . . . . . . . . . . . . . . . . . Ukázka Bootstrap tla£ítek . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka Bootstrap ikonek . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka Bootstrap informování výskytu chyby ve formulá°ovém polí£ku Ukázka Bootstrap informování o výskytu chyby . . . . . . . . . . . . . Ukázka Bootstrap informování o úsp¥²n¥ provedené akci . . . . . . . . Ukázka Bootstrap dialogového okna . . . . . . . . . . . . . . . . . . . . Sekven£ní diagram komunikace vrstev systému . . . . . . . . . . . . . Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adminer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

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

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

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

46 47 49 49 49 50 50 50 50 50 51 51 51 52 52 53

81

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

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

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

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

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

82

SEZNAM OBRÁZK

7.1 Znázorn¥ní posloupnosti na£ítání soubor· systému (shora dol·, zleva doprava) 63 7.2 Ukázka uºivatelského rozhraní systému °e²eného pomocí Bootstrapu . . . . . 66 7.3 Ukázka edita£ního formulá°e na£teného vprettyPhoto . . . . . . . . . . . . . . 67 8.1 8.2 8.3 8.4 8.5

Vý°ez wireframu úvodní stránky . . . . . . . . . . . . . . . . . Vý°ez wireframu katalogu voz· . . . . . . . . . . . . . . . . . . Vý°ez wireframu detailu vozu . . . . . . . . . . . . . . . . . . . Nástoroj pro generování kódu Like Boxu na stránce pluginu . . Ukázka pluginu AddThis pro sdílení stránky na sociálních sítích

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

72 73 74 76 76

Seznam ukázek kód· 1 2 3 4 5 6 7 8 9 10 11 12 13

Zpracování administrátorského p°ístupu do IS v souboru cong.php . . . . . Funkce pro vytvo°ení objektu t°ídy DB . . . . . . . . . . . . . . . . . . . . . Funkce pro nastavení hlá²ky . . . . . . . . . . . . . . . . . . . . . . . . . . . Funkce pro hormadné nastavování a získání hodnot atribut· t°ídy pomocí pole Funkce pro získání dat instance t°ídy z DB a nastavení hodnot atribut· . . . Funkce pro uloºení instance t°ídy do DB . . . . . . . . . . . . . . . . . . . . Funkce pro zji²t¥ni chyb v zadaných údajích instance . . . . . . . . . . . . . Funkce t°ídy Administrátor pro zji²t¥ní práv uºivatele pro konkrétní stránku a akci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funkce pro zji²t¥ni chyb v zadaných údajích instance . . . . . . . . . . . . . Kód pro vytvo°ení PDF z HTML pomocí t°ídy mPDF . . . . . . . . . . . . . Kód pro odeslání mailu pomocí PHPMaileru . . . . . . . . . . . . . . . . . . Funkce pro ur£ování umíst¥ní na Google map¥ podle adresy . . . . . . . . . . Funkce t°ídy DB pro zpracování parametrizovaného dotazu . . . . . . . . . .

83

57 58 58 59 60 61 62 64 65 67 68 68 69

84

SEZNAM UKÁZEK KÓD

P°íloha A

Seznam pouºitých zkratek AJAX Asynchronous JavaScript and XML API Application Programming Interface BPMN Business Process Model and Notation CMS Content Management System CSS Cascading Style Sheets DB DataBáze DPH Da¬ z P°idané Hodnoty DOC DOCument (p°ípona soubor· programu Microsoft Word) ERD Entity Relationship Diagram EU Evropská Unie FB FaceBook GPS Global Positioning System HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IE Internet Explorer (prohlíºe£ od spole£nosti Microsoft) IFML Interaction Flow Modeling Language IS Informa£ní systém JS JavaScript JSON JavaScript Object Notation

85

86

PÍLOHA A. SEZNAM POUITÝCH ZKRATEK

KB KiloByte MB MegaByte OMG the Object Management Group OOP Object-Oriented Programming PDF Portable Document Format (p°ípona soubor· programu Adobe Acrobat) PHP PHP: Hypertext Preprocessor RDBMS Relational DataBase Management System RWD Responsive Web Design SHA Secure Hash Algorithm SQL Structured Query Language UI User Interface UML Unied Modeling Language VIN Vehicle Identication Number WebML the Web Modeling Language WWW World Wide Web WYSIWYG What You See Is What You Got (editor HTML kódu) XML eXtensible Markup Language XSS Cross Site Scripting

.. .

P°íloha B

Obsah p°iloºeného CD • Diagramy

Entity Relationship Diagramy Use-Case Diagramy Activity Diagramy Diagram nasazení Sekven£ní diagram komunikace vrstev Diagram includování souboru p°i generování stránky

• Dokumentace • Wireframy nového front-endu

Wireframe úvodní stránky Wireframy katalogu a detailu vozu Wireframy £lánku a jejich seznamu Wireframy poptávkových formulá°·

• Zdrojové kódy IS • Dump databáze IS • Diplomová práce • Testovací scéná°e

87

Sjednocení a redesign redak ního a informa ního systému autobazaru. Bc. Jind ich Hulín-Mihalec

Recommend Documents