Podnikový informační systém v prostředí cloud

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Podnikový informační systém v prostředí cloud BAKALÁŘSKÁ PRÁCE

Tomáš Stejskal

Brno, podzim 2012

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: RNDr. Pavel Hajn ii

Poděkování Tímto bych chtěl poděkovat své rodině za podporu v průběhu celého studia. Panu RNDr. Pavlovi Hajnovi za odborné vedení mé práce a trefné připomínky. A nakonec také mé přítelkyni za to, že vydržela tak dlouho tolerovat moji často i noční práci.

iii

Shrnutí V rámci bakalářské práce byl analyzován, navržen a implementován informační systém. Ten umožňuje firmě zabývající se prodejem nábytku podrobně evidovat sortiment a to včetně škálovatelných produktů.

iv

Klíčová slova informační systém, evidence zboží, produkt, vzorník, prodej, e-shop

v

Obsah 1 Úvod...............................................................................................................................1 2 Analýza...........................................................................................................................2 2.1 Úvod........................................................................................................................2 2.2 Současné způsoby řízení......................................................................................2 2.2.1 Sklad................................................................................................................2 2.2.2 E-shop.............................................................................................................3 2.3 Požadavky na nový systém.................................................................................3 2.3.1 Shrnutí požadavků na systém.....................................................................4 2.4 Existující software na pokrytí požadavků.........................................................5 3 Návrh systému.............................................................................................................6 3.1 Objektově relační mapování................................................................................6 3.2 Návrh databáze ....................................................................................................6 3.2.1 Důležité pojmy...............................................................................................6 3.3 Součásti datového modelu...................................................................................8 3.3.1 Produktová řada............................................................................................8 3.3.2 Provedení produktu......................................................................................8 3.3.3 Vzorníky ......................................................................................................10 3.3.4 Položky..........................................................................................................10 3.3.5 Položky vzorníku........................................................................................11 3.3.6 Obrázky provedení produktu a vzorníkových položek........................12 3.3.7 Produkt.........................................................................................................13 3.3.8 Kategorie a parametry................................................................................14 3.3.9 Uživatelé systému a registrovaní zákazníci............................................15 3.3.10 Objednávky................................................................................................16 3.3.11 Poznámka k datům...................................................................................17 3.4 Datový model......................................................................................................18 4 Aplikační část..............................................................................................................19 4.1 Technologie..........................................................................................................19 4.1.1 Programovací jazyk.....................................................................................19 4.1.2 Nette Framework........................................................................................19 4.1.3 Další použité technologie...........................................................................20 4.2 Struktura projektu...............................................................................................20 4.2.1 MVC architektura........................................................................................20 vi

4.2.2 Základní struktura......................................................................................21 4.2.3 Aplikační struktura.....................................................................................21 4.3 Konfigurace aplikace..........................................................................................23 4.3.1 Systémové kontejnery.................................................................................23 4.3.2 Použití souboru config.neon......................................................................24 4.4 Repozitáře............................................................................................................25 4.4.1 Hlavní repozitář..........................................................................................25 4.4.2 Třídy modelu...............................................................................................25 4.5 Důležité součásti.................................................................................................27 4.5.1 Provedení produktu....................................................................................27 4.5.2 Finanční přehledy.......................................................................................27 4.5.3 Formuláře.....................................................................................................27 4.6 Zabezpečení systému.........................................................................................28 4.6.1 Nativní zabezpečení....................................................................................28 4.6.2 Uživatelské přístupy...................................................................................28 4.7 Vzhled aplikace...................................................................................................29 4.7.1 Použitý framework......................................................................................29 4.7.2 Responzivní web design ...........................................................................29 5 Závěr.............................................................................................................................31 5.1 Slovo závěrem.....................................................................................................31 5.2 Literatura..............................................................................................................32 Příloha - uživatelský manuál.......................................................................................33 Instalace......................................................................................................................33 Doporučená...........................................................................................................33 Volitelná.................................................................................................................33 Systémové funkce.....................................................................................................33 Administrační část...............................................................................................33 Veřejná část............................................................................................................39 Obsah přílohy............................................................................................................40

vii

Úvod

1 Úvod Každá firma zabývající se prodejem a mající ambice se dále rozrůstat, by měla mít aplikační nástroje, díky kterým může evidovat a spravovat svoje produkty. Způsob jakým to firmy realizují se odvíjí od produktového zaměření sortimentu. Většina menších a zvláště pak zaběhlých firem používá softwarové nástroje instalované lokálně na počítačích, jako jsou evidence skladu, účetní programy apod. S rozmachem internetového prodeje se těmto firmám stále méně daří oslovovat zákazníky. Jedním z řešení je pro ně internetový obchod. Ten ale pokud není propojený s evidencí skladových zásob, tak může přinést víc škody než užitku, protože vznikají problémy s konzistencí dat. Proto je dobré mít evidenci skladu a webou prezentaci v jednom systému. V této práci bude realizován informační systém fungující v cloudu (tj. spouštěný pouze ze serveru) pro firmu obchodující s nábytkem, což oproti obchodníkům například s elektronikou je oblast s mnohem větší škálovatelností produktů. Z tohoto důvodu na evidenci takového sortimentu nestačí e-shopy se základní datovou strukturou, protože kdyby chtěl uživatel zanést do systému všechny kombinace sedací soupravy, mající na výběr deset způsobů provedení, deset látek a deset barev moření dřeva, musela by tato položka být do systému zanesena tisíckrát. V této práci bude navržen a implementován informační systém, díky kterému jeho uživatelé nebudou muset redundantně vkládat data (produkty) a zároveň tak budou mít sortiment více pod kontrolou.

1

Analýza

2 Analýza 2.1 Úvod Firma má v současnosti 24 zaměstnanců a čtyři kamenné prodejny s nábytkem. K tomu na jaře roku 2012 začala provozovat e-shop, na kterém nabízí několik desítek až stovek položek ze svého sortimentu. Z provozního i ekonomického hlediska jsou pro firmu největší překážky v jejím dalším rozvoji nástroje pro řízení.

2.2 Současné způsoby řízení Firma má hlavní sklad, na kterém se nachízí přibližně 30 % naskladněných položek a zbytek je rozptýlen po prodejnách. Problémem je, že zaměstnanci na jedné prodejně mají jen omezené možnosti na to, jak zjistit zda je nějaká konkrétní položka skladem. Příklad: když přijde zákazník na prodejnu a zajímá se o dvojlůžkové postele, tak mu jsou nabídnuta pouze dvojlůžka naskledněná na této prodejně. Jediný způsob, který zaměstnanci využívají ke komunikaci s ostatními prodejnami a hlavním skladem je telefon a e-mailová korespondence. Díky tomu dochází k potížím s integritou dat skladových zásob, protože na jedné prodejně si zaměstnanci myslí, že mohou nabídnot určitý produkt, protože ráno dostali e-amilem seznam zboží dostupného na skladě a ostatních prodejnách, ale odpoledne se zjistí, že zákazník nemůže dostat slíbené zboží, protože již bylo prodáno jinde. Se spuštěním e-shopu se situace s integritou dat naskladněného zboží ještě zhoršila. Na e-shopu jsou umístěny položky, které jsou umístěny jak u dodavatele, tak po prodejnách. Díky tomu se stává, že si zákazník e-shopu objedná zboží, které už bylo prodáno v průběhu dne na prodejně. Proto hlavní a nejdůležitější věcí, kterou firma potřebuje, je systém, který umožní v reálném čase evidovat skladové zásoby napříč prodejnami, sklady i e-shopem.

2.2.1 Sklad Když chce v současnosti zaměstnanec vytvořit položku zboží, tak musí vyplnit 2

Analýza název produktové řady, produktu, výrobce, označení produktu, ručně vyspecifikovat katalogové položky jako je barva látky apod. To samé znovu dělá, když chce vytvořit stejnou položku u které se jen změnila vzorníková položka (např. barva látky). Problém je v tom, že má vyplněné teprve dvě položky a už obrazně řečeno „strávil věčnost psaním“. Současná efektivita na příkladu: když by chtěl zaměstnanec v současnosti zanést do skladu (nebo eshopu) všehny kombinace provedení jediné sedací soupravy, která má 10 tvarů (provedení) 50 látek, 8 barev moření područek, tak by musel ručně zanést do systému 10x50x8 položek, tedy 4000! A to ještě nezveřejňoval tyto položky v eshopu, což by obnášelo další dvojnásobek práce.

2.2.2 E-shop Internetový obchod, který firma v současnosti používá jako doplněk podpory prodeje, je nejzákladnější verzí obchodu od firmy Ziskový e-shop1. K redundanci dat v systému zde dochází také díky duplicitnímu popisu zboží. Ten je často u několika produktů naprosto stejný – zkopírovaný. Nachází se v něm především technické údaje (např. délka spacího prostoru), které jsou u všech položek diferencovaných pouze např. látkou stejné. Od tohoto e-shopu bude po kompletním dokončení realizace upuštěno a na webu se bude prodávat jen přes e-shop, který bude součástí informačního sytému a tudíž bude mít okamžitý přístup k evideci skladového zboží.

2.3 Požadavky na nový systém Firma má eminentní zájem se dále rozrůstat a k tomu potřebuje kromě standardních možností, které poskytují základní skladové systémy a e-shopy, také další nástroje, kterými chce podporovat přehlednost a prodej svého sortimentu. Z důvodů zmíněných v odstavci (2.2.1) a (2.2.2) je důležité, aby byla: • Navrhnuta datová struktura, vhodná k jednoduchému vytváření produktů, které se liší pouze provedením a vzorníkovými variacemi. • Dalším požadavkem je automatické nabízení paramatrů společných pro všechny produkty spadající pod společnou nadřazenou kategorii tzv. perzistentní parametry viz. shrnutí požadavků na systém (2.3.1). 1 Ziskový e-shop [online]. Dostupné na World Wide Web: . 3

Analýza •

• • • •

Kategorie a k nim přidružené parametry musí mít rekurzivní strukturu. tzn. že každá produktová kategorie může mít nula až nekonečno podkategorií a produkt umístěný v podkategorii dědí všechny parametry z nadřazených kategoríí. Položky vkládané do vzorníků ke zboží budou vytvářeny nezávisle na zboží, tak aby mohly být přiřazovány opakovaně k různým produktům. V návrhu systému budou i součásti běžné pro e-shop, jako evidence objednávek, zákazníků. Veřejná část webové prezentace musí být graficky na dobré úrovni tak, aby přilákala co největší množství zákazníků. Celý systém musí být umístěn v cloudu a jedinými požadavky na spuštění je počítač, či jiné zařízení s webovým prohlížečem.

2.3.1 Shrnutí požadavků na systém Hlavní předností systému je evidence položek. K tomu se vzhledem k sortimentu – nábytku váže na systém několik specifických požadavků. Aby bylo docíleno vysoké kvality vstupních dat u každé nově zadávané položky, tak je důležité mít dopředu připravené názvy tzv. perzistentích parametrů. To jsou takové parametry, o kterých můžeme říct, že je budou mít všechny produktové položky spadající do skupiny položek. To znamená, že ve chvíli, kdy bude uživatel vyplňovat produkt např. dvojsed, tak mu budou předloženy k vyplnění parametry: výška sedáku, výška opěradla, rozkládací systém apod. Tyto parametry jsou zřětězeny s kategoriemi (menu) v systému. Toto menu má nekonečně mnoho zanoření a každé toto zanoření může mít své parametry. Tím se dají s minimem psaní vytvářet struktury parametrů, které jsou při vytváření zboží vyplňovány. Dalším požadavkem na systém je, aby ke vkládanému zboží mohly být přiřazené tzv. vzorníky. V současném e-shopu, pokud má dostat zákazník na výběr z více např. látek, tak musí být buď vytvořena stejná položka znovu – např. sedací souprava černá, sedací souprava bílá atd. Nebo raději není dáno zákazníkovi na výběr vůbec. Každá z položek může mít takových vzorníku nula až nekonečno a položek ve vzorníku také nula až nekonečno. Navíc musejí být položky do vzorníků vytvářeny samostatně. To proto, že když se k produktu X a vzorníku Y přiřadí nová položka – látka A, tak je zbytečné

4

Analýza znovu vytvářet látku A, až bude potřeba u jiného zboží. Webová prezentace bude vytvořena za pomoci nejmodernějších technologíí tak, aby byla maximálně konkurence schopná.

2.4 Existující software na pokrytí požadavků Současná nabídka hotových řešení informační systému (IS) je velmi pestrá. Nabízejí se v provedeních „šitých“ na míru a to i pro specifická odvětví jako je prodej nábytku. Ovšem základním požadavkem firmy je mít IS v cloudu tak, aby k němu mohli zaměstnanci i zákazníci přistupovat přes webový prohlížeč odkudkoliv. Představou je, že pokud si zákazník nevybere z nabídky zboží na prodejně, tak mu může být nabídnut i sortiment z ostatních prodejen, který bude zveřejněn prostřednictvím IS. Tím, že se firma zajímá jen o cloudové řešení se výběr zúžil. V cloudu se rozdíl mezi IS a e-shopem prakticky stírá. Podle článku Informační systém pro eshop2 se většinou IS myslí zabezpečená část, se kterou pracují zaměstnanci (anglicky tzv. backend). Tato část by se měla přizpůsobit (a v případě potřeby dále přizpůsobovat) firmě na míru. Veřejná část se také přizpůsobuje na míru požadavkům firmy, ale tyto požadavky obvykle nemění zažité ovládací schéma webu. Prodejní model je u většiny firem (např. Easy-shop3, Ziskový e-shop, Vivantis4) takový, že se měsíčně platí za služby obsahující moduly, či různá omezení, např. Ziskový e-shop omezuje své klienty počtem zveřejněných položek a Easy-Shop datovým prostorem. Tyto kapacity lze samozřejmě rozšířit za úplatu. Ale hlavním problémem je, že žádná firma nenabízí „krabicové řešení“, tedy takové, které by si zákazník mohl koupit do osobního vlastnictví a nainstalovat na svém či pronajatém serveru. Důvodem, proč chce firma vytvořit informační systém na míru je, že po převodu kompletního sortimentu skladových zásob do cloudu bude na tomto systému zcela závislá a s ukončením provozu firmy, která jí řešení poskytuje, by mohla přijít o svoje data a tím si způsobit velké problémy. 2 Informační systém pro eshop? [online]. 2009, č. 6 [cit. Červen 2009]. Dostupný na World Wide Web: . 3 Internetový obchod [online]. 2012. Dostupný na World Wide Web: . 4 Internetové obchody [online]. 2012. Dostupný na World Wide Web: .

5

Návrh systému

3 Návrh systému 3.1 Objektově relační mapování Pro projekt, který má být snadno udržovatelný a rozšiřitelný je nezbytné vytvořit unifikovaný postup při vývoji systému. Jak bude podrobněji uvedeno v další kapitole, tento systém je vyvíjen v programovacím prostředí pracujícím z ORM5. Tato programovací technika nahlíží na entity datového modelu a na třídy programovacího jazyka jako na objekty. Výhodou tohoto návrhu je, že je pak prakticky jedno, jaká bude použita relační databáze nebo programovací jazyk (pokud je objektově orientovaný). Nejstabilněším záchytným bodem při vývoji softwaru jsou pak pro programátora data. Uživatelské úlohy a procesy se s časem mění, ale již vytvořená data bývají pouze modifikována, či rozšiřována o další podrobnosti. Při návrhu budou před všemi entitami popisy toho, jak se vzájemně ovlivňují. Každou entitu modelu v programu reprezentuje právě jedna třída, takže orientace v modelu je snadná. Vývoj probíhá přírůstkově v souladu s metodikou UP (Unified Process) [1].

3.2 Návrh databáze 3.2.1 Důležité pojmy •

•

• • •

produktová řada: je sortiment zboží, které výrobce sdružuje pod jedním názvem tak, aby bylo zřejmé, že zakoupením více položek z jedné produktové řady spolu budou funkčně či designově korespondovat . provedení produktu: je zboží, obsahující již všechna data, kromě informace o variantním provedení produktu, jako je barva látky, moření dřeva apod. produkt: dědí všechna data od provedení produktu, ale navíc obsahuje informace o variantním provedení zboží. vzorník: jeho název dává uživateli najevo, jakou vzorníkovou položku si bude vybírat ze seznamu ‚vzorník má položku‘. položka: jedná se o konkrétní předmět, látku, moření dřeva apod. Položky jsou evidovány samostatně, tak aby se daly v případě potřeby

5 Objektově relační mapování [2]

6

Návrh systému • •

přiřazovat ke vzorníkům provedení produktu. vzorníkové položky: jsou položky přiřazené ke konkrétnímu vzorníku perzistentní parametry kategorie: jsou parametry, které jsou stejné pro všechny produkty kategorie

Jednoduchý příklad pro zasazení pojmů do kontextu. Odrážka A představuje analogii z automobilismu a odrážka B je již z nábytkářství. • výrobce A. Škoda B. MobelSoft • produktová řada A. Octavia B. Bologna • provedení produktu A. sedan B. trojsed • vzorník A. barva laku, barva sedadel B. barva kůže, moření dřeva • položka A. černý lak, červený lak, žlutý lak, hnědá kůže B. hnědá kůže, krémová kůže, moření buk, moření olše • vzorníkové položky A. barva laku – červený lak, barva laku – černý lak, barva sedadel – hnědá kůže B. barva kůže – hnědá kůže, barva kůže – béžová kůže, moření dřeva – moření olše • produkt A. Škoda, Octavia, sedan, barva laku – černý lak, barva sedadel – hnědá kůže. B. MobelSoft, Bologna, trojsed, barva kůže – hnědá kůže, moření dřeva – moření olše. • Kategorie a perzistentní parametry A. Osobní automobily – rozvor náprav, počet dveří 7

Návrh systému B. Trojsedy – výška sedáku, výška opěradla

3.3 Součásti datového modelu 3.3.1 Produktová řada Plnění databáze začíná od výrobce (entita: producer), ten je totiž vyžadován při zadávání nové produktové řady (entita: product_line). To proto, že je výhodnější vyplnit výrobce jen jednou a zbytek nechat dědit od produktové řady. Když máme vytvořenou produktovou řadu, tak pod ní můžeme začít vytvářet nová provedení produktu (entita: product_design). Entita: producer – výrobce •

ID – unikátní číselný identifikátor výrobce

• •

name – název výrobce nábytku description – doplňující informace k výrobci (např. vyrábí sedací soupravy a židle) country – země původu výrobce, v budoucnu se dá v systému použít k filtrování zboží, protože někteří zákazníci vyžadují zboží z České republiky web – webová adresa výrobce, slouží pro snadné navázání kontaktu a může být zveřejněna pro zákazníky

•

•

Entita: product_line – produktová řada •

ID – unikátní číselný identifikátor produktové řady

• •

name – název produktové řady, který se zobrazuje zákazníkům internal_name – název produktové řady, který je interní (v rámci konkurenčního boje, se některé produkty jmenují jinak, než je název, který jim dal výrobce) producer_ID – cizí klíč výrobce, v produktové řadě identifikuje, kdo ji vyrábí, zadání je povinné

• •

3.3.2 Provedení produktu Provedení produktu je takovým středobodem databáze. Tato entita ještě není 8

Návrh systému kompletní zboží, ale obsahuje již všechny důležité informace jako název zboží, popis, celkovou váhu, dodací lhůtu pro položky, které nejsou skladem a cenu bez příplatků. Tuto entitu vnímá zákazník jako to, co chce koupit. Cena běžná i akční je uvedena bez daňe. Cena s daní je dopočítána až při zobrazení produktu [4.6.2]. Z toho důvodu musí být evidovaná i výše daně (entita: tax). Entita provedení produktu má svůj identidikátor, ale ten se nedá použít jako jednoznačná identifikace produktu. Je tomu tak z toho důvodu, že na provedení produktu jsou vázány vzorníky (entita: sampler). Entita: product_design – provedení produktu •

ID – unikátní číselný identifikátor provedení produktu

• •

name – název provedení produktu label – označení produktu, označení je identifikátor, který používá výrobce případně dodavatel description_short – důležitá vlastnost, která stojí u produktu za zmínku (např. ergonomická podpěrka atp.) description – popis zboží, který si bude číst zákazník, vytvářen je v textovém editoru uvnitř systému, takže kromě textu obsahuje i html tagy weight – váha, číselný údaj o váze produktu, v budoucnu bude potřebný pro expedici kurýrem warranty – záruční doba v měsících, číselná hodnota, výchozí je 24 delivery_time – dodací lhůta, tento údaj se zákazníkovi zobrazuje v případě že není zboží skladem (např. 6 týdnů) purchase_price_no_tax – nákupní cena bez daně, tento údaj je důležitý pro cenotvorbu, pokud je vyplněn a je vyplněna i cena, tak systém automaticky ukazuje uživateli výši daně, přirážku,marži a v případě že je vyplněna i akční cena, tak i rabat price_no_tax – cena bez daně, cena s daní se vypočítá až při zobrazení a produktu s této hodnoty, zvětšené o daň special_price_no_tax – akční cena bez daně, pokud je tato hodnota vyplněna, tak se se používá jako výchozí pro výpočet konečné ceny, číslo se dvěma desetinnými místy visible – viditelnost produktu, slouží k vyřazení produktu z nabídky, produkty se kvůli archivaci záznamů nemažou, ale pouze skrývají

• • • • • •

• •

•

9

Návrh systému • • • •

for_sale – k prodeji, určuje zda je produkt viditelný pro veřejnost v eshopu tax_ID – cizí klíč daně, používá se k výpočtu konečné ceny s daní product_line_ID – cizí klíč produktové řady, díky tomuto propojení, je možné určit název název produktové řady, ale také třeba výrobce menu_ID – cizí klíč kategorie, určuje pod jakou kategorii bude produkt spadat

Entita: tax – výše daně • •

ID – unikátní číselný identifikátor daně, ten je zároveň hodnotou výše daně, tedy v současnosti 20 u základní a 14 u snížené sazby DPH name – plný název daně

3.3.3 Vzorníky Uživatel systému má možnost (né povinnost) vytvořit u provedení zboží vzorník/y (entita: sampler). Vzorník má povinný řádek k vyplnění pouze jméno (name). To musí co nejlépe vystihovat, jaké položky vzorník obsahuje. Když se uživatel rozhodne vytvořit vzorník, tak by ho měl ještě naplnit položkami. Entita: sampler – vzorník • • •

ID – unikátní číselný identifikátor vzorníku name – název vzorníku product_design_ID – cizí klíč provedení produktu, povinná položka

3.3.4 Položky Většina nábytkářského sortimentu má položky (entita: item), jako je barva látky, dřeva apod. Tyto položky jsou evidovány v systému samostatně a pro větší přehlednost při jejich správě jsou přiřazovány pod skupiny položek (entita: item_group). U každé položky je navíc evidován výrobce. To opět slouží k zpřehlednění seznamů, které mohou obsahovat tisíce položek. Když uživatel bude chtít přiřadit k provedení produktu „trojsed“ a jeho vzorníku „barvy kůže“ novou položku, tak se mu automaticky zobrazí jen položky od výrobce, který vyrábí „trojsed“. K tomu si navíc může vybrat jen položky z určité 10

Návrh systému skupiny položek, např. skupina položek „kůže“. Nakonec už mu nic nebrání v tom, přiřadit položky ke vzorníku. Entita: item - položka • • • • • • •

ID – unikátní číselný identifikátor položky name – název položky label – označení položky, hodnota pod kterou vede položku výrobce description – volitelný popis, prostor pro případné další informace důležité pro zákazníka (např. vysoce odolný povrch) item_group_ID – cizí klíč skupiny položek, slouží k filtrování položek producer_ID – cizí klíč výrobce, určuje jaký výrobce produkuje položku image_ID – cizí klíč obrázku reprezentujícího položku

Entita: item_group – skupina položek • • •

ID – unikátní číselný identifikátor skupiny položek name – název, který má co nejlépe vystihnout skupinu položek description – volitelný popis a další informace, může např. obsahovat popis údržby skupiny položek

3.3.5 Položky vzorníku Jsou takové položky, které jsou přiřazeny ke konrétnímu vzorníku (entitou: sampler_has_item). Tyto položky mají volitelý parametr příplatek (surharge). Ten určuje kolik korun se má připočítat k základní částce uvedené v provedení produktu. Základní hodnota při nevyplnění je nula korun. Entita: sampler_has_item - položky vzorníku • • •

sampler_ID – cizí klíč vzorníku, společně s ID položky jednoznačně identifikuje entitu item_ID – cizí klíč položky surcharge – příplatek za položku, pokud je vybrána na určité zboží, v případě nevyplnění uložené jako 0.00

11

Návrh systému 3.3.6 Obrázky provedení produktu a vzorníkových položek Ke každému provedení produktu lze přiřadit nula až nekonečně mnoho obrázků reprezentujících provedení, bez ohledu na vzorníkové položky na obrázku. Je tedy jedno, zda je na obrázku „trojsed“ v hnědé kůži nebo v béžové kůži. Informace o obrázcích (entita: image) jsou s provedením produktu propojeny přes provedení produktu má obrázek (entita: product_desin_has_image). Tato entita má volitelně vyplnitelný cizí klíč product_ID, k čemu slouží, je řečeno v dalším odstavci. Každá vzorníková položka má vyplněn právě jeden obrázek, reprezentující to, jak vypadá. Entita: image – obrázek • • • • • • •

ID – unikátní číselný identifikátor obrázku description – popis obrázku, zobrazuje se u obrázků pod tagy alt a title, slouží k SEO6 optimalizaci, 200 libovolných znaků file_name – název souboru, slouží k nalezení souboru v adresářové struktuře webu, 500 libovolných znaků size – velikost souboru v bytech, číselná hodnota mime – mime typ souboru, číselná hodnota width – šířka obrázku v pixelech, číselná hodnota height – výška obrázku v pixelech, číselná hodnota

Entita: product_design_has_image – provedení produktu má obrázky • • •

product_design_ID -– cizí klíč provedení produktu, společně s ID obrázku jednoznačně identifikuje entitu, povinná položka image_ID – cizí klíč obrázku, povinná položka product_ID – cizí klíč produktu, pokud uživatel vytvoří produkt, tak v budoucnu bude mít možnost z obrázků provedení produktu vybrat jeden, který reprezentuje přesně kompletní produkt, volitelná položka

6 Search Engine Optimization, optimalizace pro webové vyhledávače vyhledávače

12

Návrh systému 3.3.7 Produkt Když už je vytvořené provedení produktu, vytvořeny a naplněny vzorníky a provedení produktu, tak je možné vytvořit finální produkt (entita: product). Nejdříve je zvoleno provedení produktu a jestliže má vzorník/y, tak musí uživatel vybrat z každého vzorníku právě jednu položku. Proces výběru provedení produktu a přiřazení vzorníkových položek se děje vždy při naskladňování nebo objednávce produktu. Unikátní identifikátor se vytváří automaticky tak, aby jej bylo v případě možnosti (např. na skladě) přičíst. Již existující kombinace provedení produktu a vzorníkových položek se znovu nevytvářejí. V této chvíli také bude možné označit jednu z fotografií náležících provedení produktu , jako obrázek reprezentující produkt. Při této akci systém vloží identifikátor produktu pod obrázek (vyplní product_ID viz. předchozí odstavec). Pokud objednávku provádí zákazník, tak obrázek nevybírá. Všechny vzorníkové položky, které zboží obsahuje, jsou evidovány ve vzorníkových položkách zboží (entita: product_has_sampler_item). Teprve poté co je ke každému vzorníku, který má provedení produkt k dispozici, přiřazena právě jedna vzorníková položka, tak se stává produkt kompletní a vytváří se záznam v entitě produkt. Pokud provedení produktu nemá žádné vzorníky, tak uživatel není nijak obtěžován a záznam se vytvoří okamžitě. Entita: product – produkt • ID – unikátní identifikátor zboží • product_design_ID – cizí klíč provedení produktu, povinná položka • on_store – počet naskladněných položek (poznámka: kdyby začala firma používat čárocé kódy, tak by zde vznikl nový řádek) Entita: product_has_sampler_item – produktu patří vzorníkové položky • • •

item_ID – cizí klíč položky, společně s cizími klíči produktu a vzorníku jednoznačně identifikuje produkt, povinná položka sampler_ID – cizí klíč vzorníku product_ID – cizí klíč produktu

13

Návrh systému 3.3.8 Kategorie a parametry Aby byla práce se systémem přehlednější, musí být provedení produktů třízeno. K tomu slouží kategorie (entita: menu). Kategorie mají hiearchickou strukturu takovou, že každá položka může mít nekonečně mnoho potomků a ty zase nekonečně svých potomků. Každá kategorie navíc může obsahovat tzv. perzistentní parametry (entita: parameter), tedy takové parametry, u kterých je zřejmé, že je budou mít všechny produkty přiřazené pod kategorii. Ve chvíli, kdy uživatel vkládá provedení produktu pod určitou kategorii, tak mu jsou nabídnuty k vyplnění všechny parametry, které kategorie obsahuje, ale také parametry rodičovských kategorií. Pokud uživatel parametry vyplní, tak ty jsou následně uloženy do provedení produktu - má parametr (entita: product_design_has_parameter). Entita: menu – kategorie • • • • • •

ID – unikátní číselný identifikátor kategorie name – název kategorie parrent – ID nadřazené kategorie, v případě, že nemá nadřazenou kategorii tak je to 0 level – hloubka zanoření v kategoriích, pokud není zanořena, tak je to 0 order – číselná hodnota, kterou se dá vynutit pořadí v kategoriích image_ID – cizí klíč obrázku, který vystihuje příslušnou kategorii

Entita: parameter – parametr • • •

ID – unikátní číselný identifikátor parametru name – název parametru menu_ID – cizí klíč kategorie, pod kterou parametr spadá

Entita: product_design_has_parametr – provedení produktu má parametr • • •

product_design_ID – cizí klíč provedení produktu, společně s cizím klíčem parametru jednoznačně identifikuje parametr produktu, povinná položka parameter_ID – cizí klíč parametru, povinná položka value – hodnota, kterou uživatel vyplnil jako platnou pro parametr a provedení produktu, 14

Návrh systému 3.3.9 Uživatelé systému a registrovaní zákazníci Pro pohodlnější a bezpečnější správu přístupů do systému jsou uživatelé systému (zaměstnanci) evidováni společně s registrovanými zákazníky (entita: user). Nemusí se tak vytvářet více uživatelských instancí (seassion), v případě, že se do systému chce přihlásit zaměstnanec jakožto zákazník. Rozdíl je pouze ve způsobu autentizace, kdy zaměstnanec používá pro přihlášení kombinaci uživatelského jména a hesla a zákazník kombinaci e-mailu a hesla (4.7.6). Zákazník i uživatel může mít na svůj účet zřetězeno nekonečně mnoho dodacích adres (entita: address). Adresa je koncipována tak, aby mohla obsahovat jak adresy soukromé, tak firemní. Z toho důvodu je většina položek nepovinná, protože např. při udání firemní adresy není nutné zadávat jméno a příjmení příjemce a naopak. V rámci této práce je v praktické realizaci použita jen jedna adresa pro každého registrovaného zákazníka. Entita: user – uživatel • • • • • •

• • • •

ID – unikátní číselný identifikátor uživatele user_name – unikátní uživatelské jméno používané pro přihlášení uživatelů - zaměstanců do systému password – otisk hesla vytvořený z „osoleného“ hesla, povinná položka role – uživatelská role, při zadávání jsou nabídnuty vytvořené role selectboxem email - kontaktní e-mail, zákazníci se pomocí něj autentizují rand_char – náhodný řetězec, je posílán po registraci zákazníka do systému, jako ověření toho, že zákazník disponuje e-mailovým účtem, který zadal checked – ověření zda e-mail patří registrovanému uživateli, logická hodnota bool title – titul name – jméno surname – příjmení

Entita: address – adresa •

ID – unikátní číselný identifikátor adresy 15

Návrh systému • • • • • • • • • • • • •

3.3.10

title – titul/y, nepovinná položka name – jméno příjemce surname – příjmení příjemce company_name – název společnosti company_IDP – IČO společnosti company_IIDP – DIČO společnosti email – kontaktní e-mail, pokud není stejný jako registrační, phone – kontaktní telefoní číslo, povinná položka phone2 – sekundární telefoní číslo city – město street – ulice house_number – číslo domu post_code – PSČ

Objednávky

Detaily zákaznické objednávky musí být vedeny v systému odděleně od informací o produktu. Důvodem je, že musí být vedeny o zboží ty informace, které byly aktuální v době vytvoření objednávky. Z těchto informací lze např. vytvářet faktury, dohledávat záruční lhůty apod. Pro tento účel slouží entita order_has_product. Do ní budou vkládány údaje o objednané položce a o tom, ke které objednávce náleží. Samotná objednávka (entita: order) pak obsahuje informace o dodací adrese, datu objednání atd. Aplikace vhodná pro ostré nasazení by měla i další entity jako způsob dopravy, odběru, komunikace se zákazníkem apod. Pro účel této aplikace ovšem postačí výše zmíněné. Entita: order – objednávka • •

ID – unikátní číselný identifikátor objednávky address_ID – identifikátor doručovací adresy, cizí klíč

Entita: order_has_product – objednávka obsahuje produkty • • •

ID – unikátní číselný identifikátor order_ID – identifikátor objednávky product_ID – identifikátor objednávaného zboží, povinná položka 16

Návrh systému • • • • • • • •

3.3.11

product_name – název produktu, product_design – název provedení product_sampler_item – slovní výčet volitelných vzorníkových položek quantity – množství price – cena s daní price_no_tax – cena bez daně tax – výše daně discount – sleva

Poznámka k datům

V aplikaci nejsou v žádné entitě použity informace o datu vytvoření, datu úprav, interních poznámkách apod. Je tomu z toho důvodu, že pro kvalitní správu historie je třeba evidovat pro každou entitu historii přístupů, úprav a uživatelů samostatně. Vyobrazením by se značně znepřehlednil model.

17

Návrh systému 3.4 Datový model

18

Aplikační část

4 Aplikační část 4.1 Technologie 4.1.1 Programovací jazyk Všechny použité technologie jsou pod veřejnou licencí, což na firmu neklade žádné finanční požadavky. Jako programovací jazyk bylo zvoleno PHP7, konkrétně ve verzi 5.4. Pro tento projekt by byl vhodný také ASP.NET MVC8, nebo RubyOnRails9. Oproti výše zmíněným má PHP nepopíratelnou výhodu v tom, že serverů Apache, na kterém PHP „běží“ je celosvětově majoritní podíl oproti např. Microsoft serverům, na kterých funguje .NET [6]. Pro projekt, který má být rozšiřitelný a znovupoužitelný by bylo nevhodné programovat imperativně. Pokud se programátor rozhodne programovat objektově, tak to ovšem také neznamená, že bude jeho kód čitelný. Každý programátor může mít zafixované jiné postupy a návyky jak řešit problémy. Také z těchto důvodů se objevily tzv. frameworky. Ty se snaží sjednotit programovací postupy a návyky tak, aby byl projekt čitelný i pro větší skupinu vývojářů. Na výběr jich mají vývojáři široké množství, známé zahraniční framework nad PHP jsou např. Symfony, či Zend. Nakonec byl pro projekt vybrán Nette Framework10 (dále jen Nette).

4.1.2 Nette Framework Nette staví na souboru technologií a postupů spojených do jedné knihovny. Plně podporuje poslední verzi PHP 5.4 a jeho licence nijak programátora neomezuje. V jeho dokumentaci lze naleznout všechny v aplikaci použité funkce.

7 PHP: Hypertext Preprocessor [online]. 2012, [cit. Prosinec 2012]. Dostupný na World Wide Web: . 8 MVC : The Official Microsoft ASP.NET Site [online]. 2012, [cit. Prosinec 2012]. Dostupný na World Wide Web: . 9 RubyOnRails.cz [online]. 2012, [cit. Prosinec 2012]. Dostupný na World Wide Web: . 10 Nette Framework [online]. 2012, č. 6 [cit. Prosinec 2012]. Dostupný na World Wide Web: .

19

Aplikační část 4.1.3 Další použité technologie • • • •

datové úložiště: MySQL 5.5, databázový stroj InnoDB značkovací jazyk: HTML5 a šablonovací systém Latte11 kaskádové styly: CSS3 a framework Bootstrap12 skriptovací jazyk: javascript a knihovna jQuery13

4.2 Struktura projektu 4.2.1 MVC architektura Nette Framework je postavený na architektuře MVC (Model-View-Controller). Model Je funkční základ celé aplikace, obsahuje třídy a metody pro práci s databází či soubory. View Česky pohled, jedná se o vykreslitelnou část aplikace, v naší aplikaci se jedná o šablony (složky templates), což jsou soubory s příponou latte. Controller Je prostředník mezi modelem a pohledem. V Nette je reprezentován tzv. pressenterem. Pressenter zavolá potřebnou aplikační logiku a předá ji pohledu. Jednomu pressenteru odpovídá v aplikaci právě jedna složka nacházející se v templates, která je pojmenovaná stejně jako pressenter.

11 Latte [online]. 2001, [cit. 28 Květen 2001]. Dostupný na World Wide Web: . 12 Bootstrap [online]. 2012, [cit. Prosinec 2012]. Dostupný na World Wide Web: . 13 jQuery: The Write Less, Do More, JavaScript Library [online]. 2012, [cit. Prosinec 2012]. Dostupný na World Wide Web: .

20

Aplikační část 4.2.2 Základní struktura ← základní (root) složka webu ← soubory aplikace ← knihovny, které aplikace využívá, obsahuje i Nette ← zde se ukládají chybová hlášení ← dočasné soubory ← veřejně přístupná složka ← soubor obsahující přesměrování do složky www .htacces Soubor .htacces obsahuje přepisovací pravidlo tzv. RewriteEngine, ten má za úkol po zadání kořenové složky webu přesměrovat uživatele do složky www, která obsahuje spustitelný soubor index.php. Tím je na úrovni serveru zajištěno, že uživatelé mimo server mají přístup pouze do veřejné složky a nevidí důležité konfigurační soubory aj. Pokud se například pokusí dostat do složky stejskal/app/config, bude odmítnut s upozorněním „You don't have permission to access /stejskal/app/config/ on this server“.

4.2.3 Aplikační struktura ← zabezpečená část webu ← veřejná část webu ← konfigurační soubory ← třídy modelu ← presentery ← šablony ← soubor zavádějící Nette

21

Aplikační část Soubor bootstrap.php Soubor bootstrap nastavuje základní složky nutné pro běh aplikace. Pokud je třeba změnit cestu ke složkám temp, log, nebo Nette, děje se to zde. Navíc se zde zapíná tzv. „laděnka“, což je nástroj pro vývojáře, který dokáže detekovat a hlásit chyby. Pokud je laďenka vypnuta a dojde na serveru k chybě, tak je zobrazena příslušná šablona dle kódu chyby.

chybové stránky dle kódu chyby Rozdělení na moduly Aplikaci bylo potřeba rozdělit na veřejnou část, ke které není potřeba přihlášení - složka FrontModule a soukromou část, která vyžaduje autorizaci - složka AdminModule. Základní struktura složky „app“ tyto složky neobsahovala. Struktura souborů je navržena tak, aby průchod do zabezpečené části probíhal přes tzv. AuthPressenter (autorizaci), který přesměruje nepřihlášeného uživatele na přihlašovací stránku. Více v kapitole zabezpečení (4.6).

22

Aplikační část Veřejná struktura Do této části se umisťuje vše, k čemu má uživatel veřejný přístup.

← kaskádové styly ← obrázky produktů, kategorií aj. ← pomocné obrázky pro uživatelské rozhraní ← javascripty použité v aplikaci ← soubor zabezpečující celou aplikaci ← tento soubor načítá aplikační část programu Soubor .htacces Projekt není momentálně přístupný pro veřejnost, tento soubor zajišťuje zabezpečení celého webu.

4.3 Konfigurace aplikace 4.3.1 Systémové kontejnery Ke konfiguraci je v aplikaci použit soubor config.neon nacházející se ve složce app/config. Tento soubor implementuje především Dependecy Injection (DI) kontejnery. DI kontejner jsou třídy, které automaticky vytváří a ruší své instance tak, aby neplýtvaly zdroji systému a byly uživateli k dispozici kdekoliv v aplikaci. Kontejner může být statický (factories - továrničky) a dynamický (services - služby). Statický kontejner vždy vytváří novou instanci třídy, naopak při volání dynamického kontejneru se při dalších voláních pracuje s téže instancí. Příklad na ukázku: Vytvoření služby class KontejnerProdukt extends Nette\DI\Container { protected function createServicePripojeni() { 23

Aplikační část return new Nette\Database\Connection( $this->parameters['dsn'], $this->parameters['user'], $this->parameters['password'] ); } protected function createServiceProdukt() { return new Produkt($this->connection); } } Volání služby $container = new KontejnerProdukt(array( 'dsn' => 'mysql:', 'user' => 'root', 'password' => '***', )); $produkt = $container->getService('Produkt'); V modelu pak stačí v konstruktory volat předané připojení (toto se děje ve třídě Repository) a můžeme s entitou produkt pracovat.

4.3.2 Použití souboru config.neon V souboru config.neon, který se nachází ve složce app/config se nachází tato deklarace: nette: database: dsn: 'mysql:host=localhost;dbname=czstejskal' user: 'czstejskal' password: '**********' Ta zastupuje výše zmíněnou službu createServicePripojeni. Níže v souboru(pod komentářem #SLUŽBY) jsou deklarovány (registrovány) další služby, těm je předáván jako parametr připojení14. Jako služby jsou volány třídy, které se nachází v modelu, jsou to tzv. repozitáře.

14 Ve službách není vidět že by se nějaký parametr předával. Nette toto řeší automaticky.

24

Aplikační část 4.4 Repozitáře 4.4.1 Hlavní repozitář Všechny služby registrované v souboru config.neon volají třídu umístěnou ve složce model. Třídy se vždy jmenují podle databázové entity, se kterou pracují (a za ní je uvedeno „Repository“, aby bylo zřejmé, co je jejich předkem). Tyto třídy dědí od hlavního repozitáře (třída: Repository). Hlavní repozitář poskytuje svým potomkům připojení k databázi. V konstruktoru využije poslané údaje k připojení a v metodě getTable() se připojí k entitě reprezentující třídu, která je jeho potomkem. Díky regulárním výrazům umí getTable() vytvořit z názvu třídy (odvodit) název tabulky tak, že uživatel nemusí psát její název. To funguje pokud je dodržena jmenná konvence CamelCase15 pro třídy a underscores16 pro entity. Od tříd je navíc regulárním výrazem odstraněn výraz „Repository“. Celá metoda vypadá takto: Metoda getTable() protected function getTable() { Odstranění „Repository“ z názvu třídy preg_match('#(\w+)Repository$#', get_class($this), $m); Převod názvu třídy z CamelToe na underscore $camelToeName = lcfirst($m[1]); $underscoreName = strtolower(preg_replace('/(?<=[a-z])([A-Z])/', '_$1', $camelToeName)); Databázové připojení k entitě, s tou již jde dále pracovat return $this->connection->table($underscoreName); }

4.4.2 Třídy modelu Jak už bylo řečeno, repozitáře představují entity. Díky tomu, že k modelu mají přes hlavní repozítář přístup, tak nad ním mohou v metodách provádět různé akce. Metody mají vypovídající názvy, které jasně dávají tušit co provádějí, takže je zde není potřeba podrobně rozebírat. Pro názornost jedna „počeštělá“ metoda, která by sloužila k uložení dat entitě „obrázek“. 15 Tzv. VelbloudíNotaceSeZapisujeTakto 16 tato_notace_se_zapisuje_takto_a_pouziva_se_v_databazich

25

Aplikační část public function uloz($nazev_obrazku,$cesta,$velikost,$pripona,$sirka,$vyska) { return $this->getTable()->insert(array( 'nazev_popisek' => $nazev_obrazku, 'cesta' => $cesta, 'velikost' => $velikost, 'typ' => $pripona, 'sirka' => $sirka, 'vyska' => $vyska )); } Pro přístup k databázi je využita PHP knihovna NotORM17 .

Třídy modelu, hlavní repozitář je označen vykřičníkem 17 NotORM [online]. 2010. Dostupný na World Wide Web: .

26

Aplikační část 4.5 Důležité součásti 4.5.1 Provedení produktu Jak bylo řečeno již v návrhu datového modelu (3.3.2), vše se odvíjí od provedení produktu. Zde (v systému odkaz zboží) uživatel určuje všechny klíčové parametry – umístění v kategoriích, obrázky produktu, parametry, cenu, popis, atd. Cena se dopočítává z ceny bez daně a daně. Ovšem pro to, aby měl uživatel přehled o finančních statistikách položky toto nestačí.

4.5.2 Finanční přehledy Finanční přehledy jsou v systému řešeny pomocí javascriptových funkcí (umístěných v souboru www/js/my/taxhelper.js). Tyto funkce reagují na uvolnění tlačítka a z polí Pořizovací cena, Cena s DPH, Cena bez DPH, Akční cena s DPH a Akční cena bez DPH dopočítávájí ostatní dostupné informace viz. obrázek:

Jak se informace vypočítávají je uvedeno v odkazu označeným symbolem „i v kroužku“ vedle zobrazovaných hodnot.

4.5.3 Formuláře Veškeré formuláře použité v aplikaci jsou ošetřeny tak, aby přijímaly pouze validní požadovaná data. Například PSČ může být pouze pětimístné číslo, email musí být v platném formátu atd.

27

Aplikační část 4.6 Zabezpečení systému 4.6.1 Nativní zabezpečení Nette nativně zabezpečuje aplikaci před celou řadou útoků. Komunita kolem frameworku se aktivně zabývá bezpečností a v případě výskytu nových bezpečnostních hrozeb se je snaží co nejrychleji eliminovat. Značnou část bezpečnostních rizik eliminují v Nette formuláře, což je jedna ze součástí frameworku. Základní výčet útoků proti kterým je Nette chráněno je ochrana proti: • Cross-Site Scripting (XSS) – podstrčení škodlivého kódu stránce • Cross-Site Request Forgery (CSRF) – podstrčení cizí stránky uživateli • URL attack, control codes, invalid UTF-8 – útoky přes neošetřené vstupy • Session hijacking, session stealing, session fixation – útoky přes seassion

4.6.2 Uživatelské přístupy Ověření přihlašovacích údajů Řízení uživatelských přístupů do aplikace (anglicky user access managment) je realizováno tak, že není třeba vepisovat žádný kód do nově přibývajících presenterů (stránek). Řešení spočívá v tom, že všechny presentery v administrační části dědí od BasePresenteru (umístěného ve složce app/AdminModule/presenters), kterému je jako služba předáno ověření (třída Authenticator) umístěná ve složce libs.

← soubor obsahující definici zdrojů a rolí ← ověřovací třída Pro ověření je nejdůležitější metoda ověřit (authenticate), této metodě jsou předávány ověřovací údaje z přihlašovacího formuláře (credentials). K heslu je přiřazen řetězec (umístěný v config.neon) a z hesla je vytvořen otisk (hash). Přiřazení řetězce k heslu se nazývá „solení“ a provádí se, protože neosolené heslo lze snadněji prolomit útokem hrubou silou (Brute Force) [3], na které se používají předgenerované tabulky. Pro ověření registrovaných uživatelů slouží 28

Aplikační část třída CustomerAuthenticator. Ta pro identifikaci užvatele používá e-mailovou adresu na rozdíl od uživatelů systému, kteří používají uživatelské jméno. Uživatelská oprávnění Přidělení uživatelských oprávnění se provádí ve třídě Acl. Zde se pomocí funkcí (implementovaných v Nette\Security\User) nejdříve vytvoří uživatelské role addRole(), poté zdroje(stránky odpovídající presenteru) addResource() a nakonec nastaví oprávnění pomocí allow(). Díky tomu lze vytvořit libovolně složitá

struktura uživatelských rolí a oprávnění. Pro účel této aplikace postačí role administrátor, mající veškerá oprávnění s manipulací nad administrační částí. Dále role retail_customer - maloobchodní zákazník, který může nakupovat v eshopu. Jako poslední je pak quest - host, ten může nahlížet veškeré informace v zákaznické části, ale nemůže nakupovat.

4.7 Vzhled aplikace 4.7.1 Použitý framework Pro úspěch firemního webu je jeho vzhled téměř stejně důležitý jako funkčnost. Vytvořit kompletní stylopis moderního webu není nic jednoduchého. S novými kaskádovými styly (CSS3) lze vytvářet hezkou grafiku se zaoblenými rohy a barevnými přechody tam, kde to dříve šlo jenom s obrázkem. S tím ale souvisí značné „naboptnání“ kódu ve stylopisu. Naštěstí existují freameworky, které dávají programátorovi předpřipravenou sadu moderních stylů a ten je může začít okamžitě používat a v případě potřeby si je přizpůsobit.

4.7.2 Responzivní web design Dlouhou dobu se aplikace designovaly pro určité rozlišení monitoru tak, aby se stránka vešla na obrazovku. Do roku 2008 se nejčastěji šířka webu navrhovala pro šířku 800px, poté začali být moderní layoty s rozlišením do 1024px [4]. S masovým rozmachem přenosných počítačů, jako jsou tablety a chytré telefony, se situace mírně zkomplikovala. Weby, které chtějí být uživatelsky přístupné, by neměly zapomínat ani na ně. Veřejná prezentace tohoto webu je dostupná ve čtyřech rozlišeních a to 1200, 980, 780 a 480 pixelů šířky. Je tomu tak díky 29

Aplikační část rozdělení stránky na dlaždice. Jejich šířka včetně odsazení a rámečku je 226 pixelů. Výška je pak pro dlaždice robrazující menu poloviční oproti výšce dlaždic produktů.

Podoba webu ve všech čtyřech velikost Ve stylopise se o různé zobrazení kontejneru fixujícího dlaždice starají tzv. Media Queries (např. pro maximální šířku vypadá zápis takto: @media (maxwidth: 780px)). Poznámka: Prvky vyhledávání a banner produktu, jsou pouze dekorativní, resp. složí jako rezervace pro budoucí funkční prvky.

30

Závěr

5 Závěr 5.1 Slovo závěrem V rámci bakalářské práce byl implementován informační systém pro správu variantních produktů a funkce spojené s další obsluhou systému. Podařilo se vytvořit čistý, ale informačně bohatý design a realizovat výrazné usnadnění vkládání položek majících možnost volby ze vzorníků. V případě dodatečné implementace dalších dílčích položek, jako je podrobná správa objednávek apod. Bude tento robustní korpus infomačního systému reálným přínosem. A to zejména pro firmu, prodávající variantní výrobky, která se snaží prorazit na internetovém trhu.

31

Závěr 5.2 Literatura [1] UML 2 a unifikovaný proces vývoje aplikací :objektově orientovaná analýza a návrh prakticky. Edited by Jim Arlow - Ila Neustadt. Brno: Computer Press, 2007. 567 s. ISBN 978-80-251-1503. strana. 51 [2] FOWLER, Martin. Patterns of Enterprise Application Architecture. [s.l.] : Addison Wesley, 2002. ISBN 0-321-12742-0. strana. 560. [3] KOFLER, Michael a Bernd ÖGGL. PHP 5 a MySQL 5 :průvodce webového programátora. Translated by David Čepička. Vyd. 1. Brno: Computer Press, 2007. 607 s. ISBN 978-80-251-1813. strana. 165 [4] CEDERHOLM, Dan. Webdesign s webovými standardy. Vyd. 1. Brno: Zoner press, 2004. 256 s. ISBN 80-86815-15-3. strana. 52

32

Příloha - uživatelský manuál

Příloha - uživatelský manuál Instalace Doporučená Je doporučeno aplikaci přímo spustit na webové adrese http://stejskal.php5.cz/ . K přihlášení použijte údaje vytištěné na žlutém papírku a vlepené na deskách této práce.

Volitelná Aplikaci je možné naistalovat na vlastní server podporující Apache v. 2.2.16 Debian18 a databázový klient libmysql v. 5.1.63. Po úspěsné instalaci je třeba na tento server nakopírovat složku stejskal, umístěnou ve složce aplikace, která je součástí přílohy a také u ní přiložený soubor .htacces. V tom je na druhém a posledním řádku potřeba upravit cesty na server podle potřeby. Odstraněním souboru .htacces umístěného ve složce stejskal/www se zruší zaheslování webu. Poté je potřeba v souboru config.neon, umístěného ve složce stejskal/app/config změnit přihlašovací údaje k databázevému serveru pomocí třídy database. Nakonec je třeba vytvořit databázi pomocí dotazu přiloženého v souboru sql.txt. Přihlašovací údaje pro administrátora obsahu soubor user.txt. Upozornění: součástí složky a sql nejsou kromě přihlašovacích údajů pro administrátora žádná data a fotky – i toho důvodu je doporučeno spustit aplikaci přímo.

Systémové funkce Výčet je seřazen tak, jak jsou zobrazeny odkazy v menu (zleva → doprava).

Administrační část Autentizace V administrační části je možné pracovat až po přihlášení. K tomu je uživatel 18 Apache průvodce instalací [online]. 2012, [cit. Prosinec 2012]. Dostupný na World Wide Web: .

33

Příloha - uživatelský manuál vyzván automaticky, vždy když se pokusí navštívit jakokoliv administrační část bez autentizace. Nahlížení registrovaných zákazníků Nachází se v Zákazníci. Zobrazuje dostupné informace o zákazníkovy, který se registroval. Nahlížení uživatelů systému Nachází se v Uživatelé. Zobrazuje dostupné informace o zákazníkovy, který se registroval. Vytváření uživatelů systému Nachází se v Uživatelé→Nový uživatel. Zaregistruje uživatele systému a přiřadí mu adresu. Editace uživatelů systému Nachází se v Uživatelé→Editovat. Umožňuje změnit základní informace o uživateli systému. Nahlížení produktových řad Nachází se v Zboží. Zobrazuje dostupné produktové řady. Vytvoření produktové řady Nachází se ve Zboží→Nová produktová řada. Touto funkcí se vytvoří produktová řada určitého výrobce, ke které lze posléze přiřazovat nová provedení produktů. Editace produktové řady Nachází se v Zboží→Editovat produktovou řadu. Umožňuje změnit informace o produktové řadě. Nahlížení provedení produktu Nachází se v Zboží→Zobrazit produkty. Zobrazí provedení produktu náležících 34

Příloha - uživatelský manuál produktové řadě. Vytvoření nového provedení produktu Nachází se v Zboží→Zobrazit produkty→Nové provedení produktu. Tato funkce spustí průvodce, který provede uživatelé kompletním vytvořením produktu. V prvním kroku jsou vyplněny informace o produktu. Ve druhém kroku je zboží přiřazeno do kategorie a volitelně jsou vyplně nabízené perzistentní parametry. Ve třetím kroku se ke zboží přiřazují obrázky, které ho reprezentují. Po třetím kroku je již produkt uložen do systému, ale uživateli je ještě nabídnuta funkce Vytvoření vzorníků a přiřazení vzorníkových položek. Editace provedení produktu Nachází se v Zboží→Zobrazit produkty→Editovat produkt. Spuštěním této funkce se spustí obrazovka nabízející editaci základních údajů o produktu a v pravém sloupci pak editaci obrázků produktu, vzorníků produktu (odkaz je reprezentován tužkou) a editaci umístění v menu společně s perzistentními parametry. Vytvoření vzorníků a přiřazení vzorníkových položek Nachází se v Zboží→Zobrazit produkty→Editovat produkt→Editovat vzorníky. Umožňuje v první řadě vytvořit vzorník, přes funkci Nový vzorník. Ten je pak možno z formuláře umístěného pod ním vybrat. Když je vzorník vybrán, zpřístupní se funkce Vložit do vzorníku zboží reprezentovaná „ležatým stromečkem“. Po kliktutí na ni se zobrazí formulář, ve kterém je možno určit výši příplatku na dannou položku a produkt. Poté se položka vloží do vzorníku produktu. Funkce Odebrat ze vzorníku je její negací. Vytváření a editace obrázků reprezentujících produkt Nachází se v Zboží→Zobrazit produkty→Editovat produkt→Editovat obrázky. Výhodnou při přidávání je, že uživatel může libovolně nahrávat a odstraňovat obrázky, ale dokud nezmáčkne tlačítko Uložit změny a zpět , tak jsou v paměti i „smazané obrázky“.

35

Příloha - uživatelský manuál Naskladnění produktu Nachází se v Zboží→Zobrazit produkty→Naskladnit. Ukáže obrazovku na které se vyplní množství naskladňovaného produktu a pokud tento produkt obsahuje vzorníky, tak uživatel musí zvolit z každého vzorníku jednu vzorníkovou položku. Zobrazení naskladněných položek Nachází se v Sklad. Vypíše názvy a označení produktů, které jsou skladem. Vzorníkové položky, které mohou být případně součástí naskladněného produktu, jsou zobrazeny pod funkcí Sklad→Vzorníkové položky. Odebrání položky ze skladu Nachází se v Sklad→Odebrat jeden kus. Odepíše ze skladu jednu vybranou položku. Zobrazení objednaných položek Nachází se v Objednávky. Vypíše objednávky uskutečněné přes e-shop. Jedná se pouze o stručé náhledy. Vyřízení objednávky Nachází se v Objednávky→Vyřízeno. Tato funkce symbolizuje vyřízení objednávky, tím se odstraní ze seznamu. Nahlížení výrobců Nachází se v Výrobci. Zobrazuje všechny výrobce. Vytvoření výrobce Nachází se v Výrobci→Nový výrobce. Vytvoří výrobce. Editace výrobce Nachází se v Výrobci→Editovat výrobce. Umožňuje změnit informace o výrobci. 36

Příloha - uživatelský manuál Nahlížení kategorií Nachází se v Menu. Umožňuje nahlížet na kategorie a to ve dvou strukturách. První (výše zobrazená) ukazuje jak jsou položky kategorií vzájemně seřazené a zanořené. Druhá (níže zobrazená) je pak grafické zobrazení kategorií sloužící pro kontrolu vzhledu při vytváření. Vytvoření kategorie Nachází se v Menu→Přidat další kategorii. Otevře obrazovku na které se vložením obrázku a popisku vytvoří nová kategorie. Ta náleží pod položku pod kterou byla vytvořena a pořadí má na konci. Editace kategorie Nachází se v Menu→Přidat další kategorii. Umožňuje změnit obrázek a popisek kategorie. Změna pořadí kategorie Nachází se v Menu→Posunout níže a Menu→Posunout výše. Umožňuje vynutit pořadí položky v menu. Díky tomu nemusí být položky třízeny jen podle názvu. Změna zanoření kategorie Nachází se v Menu→Zanořit pod položku a Menu→Zvýšit úroveň zanoření. Funkce Zanořit pod položku udělá z kategorie potomka kategorie nacházející se přímo nad ním. Funkce Zvýšit úroveň zanoření neguje tento stav. Nahlížení perzistentních parametrů kategorie Nachází se v Menu→Odkaz na kategorii. V pravé části obrazovky zobrazí parametry náležící pod danou kategorii. Vytvoření perzistentního parametru kategorie Nachází se v Menu→Odkaz na kategorii→Přidat. Vytvoří parametr náležící kategorii. 37

Příloha - uživatelský manuál Editace perzistentního parametru kategorie Nachází se v Menu→Odkaz na kategorii→Editovat parametr. Umožňuje upravit parametr náležící kategorii. Nahlížení vzorníkových položek Nachází se v Vzorníky. Zobrazuje položky, které je možné přiřadit k vzorníkům zboží. Vytvoření vzorníkové položky Nachází se v Vzorníky→Nová vzorníková položka. Poté co je vybrán výrobce a skupina položek ke kterým položka náleží, je možné ji zde vytvořit. Vytvoření skupiny položek Nachází se v Vzorníky→Editovat skupiny položek→Vytvořit. Ve spodní části obrazovky je možné vytvořit novou skupinu položek. Editace skupiny položek Nachází se v Vzorníky→Editovat skupiny položek→Editovat. Umožňuje úpravu informací o skupině položek. Změna hesla Nachází se v Změna hesla. Po rutině zadání původního hesla je možné zadat nové. Odhlášení Nachází se v Odhlásit. Mazání napříč systémem není možné z důvodu zachování dostatečného množství dat pro prezentaci bakalářské práce.

38

Příloha - uživatelský manuál Veřejná část Registrace nového uživatele Nachází se v Sortiment a Hlavní strana→Přihlášení→Nová registrace. Po vyplnění užavatelských údajů je uživateli poslán e-mail sloužící k potvrzení vlastnictví emailové adresy. Autentizace Nachází se v Hlavní strana→Přihlášení. Pouze přihlášený uživatel může provést objednávku. Nahlížení kategorií Nachází se v Sortiment a Hlavní strana. Kategorie jsou zobrazeny v části sortiment, jako podle jména setřízený zanořený seznam a na hlavní straně jako grafický seznam položek bez zanoření takový, že po rozkliknutí se zanoří. Zobrazení seznamy produktů Nachází se v Hlavní strana. Zobrazuje produktová provedení. K orientaci slouží kategorie. Náhled produktu Nachází se v Hlavní strana→Náhled produktu. Zobrazuje konkrétní položku včetně parametrů, vzorníků, obrázků, ceny, popisků atp. Pokud nemá produkt vzorníky, ihned se zobrazuje informace o dostupnost, pokud je má, tak je tato informace zobrazena až poté co je z každého vzorníku vybrána alespoň jedna položka. Vložení do košíku Nachází se v Hlavní strana→Náhled produktu→Vložit do košíku. Tato funkce před samotným vložením zkontroluje, zda má kupovaná kombinace již vytvořený identifikátor a pokud ne tak ho vytvoří – funguje tedy podobně jako naskladnění. 39

Příloha - uživatelský manuál Objednání zboží z košíku Nachází se v Hlavní strana→Nákupní košík→Objednat. Vytvoří záznamy v objednávce. Žádné údaje jako na ěžném e-shopu nejsou vyžadovány, použijí se údaje z adresy zadané při registraci. Pouze přihlášený uživatel může provést objednávku. Odhlášení Nachází se v Hlavní strana→Uživatel→Odhlásit.

Obsah přílohy • • •

Adresář aplikace obsahující zdrojové kódy Soubor sql.txt obsahující databázi Bakalářskou práci ve formátech PDF, RTF, DOC, ODT a HTML

Soubor s přílohou se nachází v archivu práce v IS v souboru s názvem priloha.

40