VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra technických studií Obor Aplikovaná informatika
P o č í t a č o v á p o d p o r a p ř í p r a v y v ý ro b y bakalářská práce
Autor: Jan Obajtek Vedoucí práce: doc. Dr. Ing. Jan Voráček, CSc. Jihlava 2016
Abstrakt Cílem této bakalářské práce je navrhnout a implementovat webovou aplikaci postavenou na redakčním systému Joomla!. Tato aplikace umožní firmě Prusa Research s.r.o. operativní doplňování skladovaných dílů tak, aby zajistila plynulou výrobu. Zároveň chceme, aby zajistila přehledný výpis všech potřebných informací z vytvořené databáze a jejích entit. Nedílnou součástí systému bude evidence skladových položek, finálních produktů, objednávek a seznamu dodavatelů. Administrátor se prostřednictvím webového prohlížeče přihlásí do systému, který jej následně přesměruje na dashboard (rozcestník) aplikace. Zde nalezne tlačítka pro ovládání veškerých funkcí systému, dále přehled hodnot stávajících skladových zásob a upozornění v případě nízkého stavu komponent.
Klíčová slova Plánování potřeby materiálu, skladované díly, Joomla!, PHP, LESS, MySQL
Abstract The aim of my bachelor thesis is -to design and -to implement the Website application, which is build on Joomla!. This application enables the below mentioned company Prusa Reseach s.r.o. the operational refilling of the stored parts in order to ensure continuous production. At the same time this application has to ensure the list of all necessary information from created database and its entities. The important part of that is the list of the inventory items, finished products, orders and suppliers. The key user logged in the systém, will be redirected to the dashboard. There are mentioned control buttons of system funcions, overview of stocks value, allert in case of decreasing stocks.
Key words Material requirements planning, stored material, Joomla!, PHP, LESS, MySQL
Prohlašuji, že předložená bakalářská práce je původní a zpracoval jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil autorská práva (ve smyslu 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ů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. V Jihlavě dne
............................................... Podpis
Poděkování V první řadě bych rád poděkoval svému vedoucímu bakalářské práce panu doc. Dr. Ing. Janu Voráčkovi, CSc. za odborné rady, čas a trpělivost. Dále bych rád poděkoval svým nejbližším. Rodině a kamarádům za trpělivost a důležitou zpětnou vazbu ohledně mé práce.
Obsah 1
Úvod.......................................................................................................................... 8
2
Plánování potřeby materiálu ..................................................................................... 9
3
4
5
2.1
Úvod ................................................................................................................... 9
2.2
Historie plánování potřeby materiálu ................................................................. 9
2.3
Základní princip ................................................................................................. 9
2.4
Cíle ................................................................................................................... 10
2.5
Výstupy ............................................................................................................ 10
2.6
Základní struktura ............................................................................................ 10
2.7
Časové fáze výroby produktu........................................................................... 11
2.8
Kanban ............................................................................................................. 11
Systémy pro správu obsahu (CMS) ........................................................................ 13 3.1
Úvod ................................................................................................................. 13
3.2
CMS Joomla! ................................................................................................... 14
3.2.1
Joomla! podrobný přehled rozšíření ......................................................... 15
3.2.2
Databáze.................................................................................................... 20
Analýza stávajícího skladového systému ............................................................... 22 4.1
Úvod ................................................................................................................. 22
4.2
Popis systému ................................................................................................... 22
4.3
Výhody a nevýhody ......................................................................................... 22
Návrh a implementace nového skladového systému .............................................. 24 5.1
Požadavky na skladový systém ........................................................................ 24
5.2
Srovnání s existujícími řešeními ...................................................................... 24
5.3
Grafická stránka skladového systému .............................................................. 25
5.3.1
Node.js ...................................................................................................... 26
5.3.2
Instalace LESS .......................................................................................... 26
5.3.3
Less struktura ............................................................................................ 26
5.3.4
Tvorba Joomla! šablony............................................................................ 27
5.3.5
Design skladového systému ...................................................................... 27
5.4
Návrh a implementace databáze....................................................................... 27
5.4.1
E-R diagram .............................................................................................. 28
5.4.2
Popis tabulek ............................................................................................. 28
5.4.3
Zhotovení databáze a popis dotazů ........................................................... 30
5.5
Implementace komponenty .............................................................................. 32
5.5.1
Složení komponenty ................................................................................. 33
5.5.2
Popis a ukázka controlleru ........................................................................ 34
5.5.3
Popis a ukázka modelu ............................................................................. 36
5.5.4
Popis a ukázka views ................................................................................ 37
5.6 6
Testování komponenty ..................................................................................... 41
Závěr ....................................................................................................................... 42 6.1
Celkové zhodnocení ......................................................................................... 42
6.2
Budoucnost aplikace ........................................................................................ 43
Seznam použité literatury ............................................................................................... 44 Seznam obrázků .............................................................................................................. 46 Seznam použitých zkratek .............................................................................................. 47 Přílohy............................................................................................................................. 48 1
Obsah přiloženého CD ............................................................................................ 48
1 Úvod K vytvoření softwarového systému pro firmu Prusa Research s.r.o. jsem se dostal čistě náhodně. Ke zpracování tohoto tématu mě přivedl bratr zakladatele firmy Prusa Research s.r.o., Bc. Michal Průša, který byl nespokojený se stávajícím skladovým systémem. Úvodem bych rád představil tuto firmu. Vznikla v roce 2012 a jejím zakladatelem je Josef Pruša. Pan Josef Průša se danou problematikou zabývá již od roku 2009 a dodává své 3D tiskárny do celého světa. Má za sebou nespočet školení a přednášek na významných událostech jako jsou TEDx Prague, TEDx Vienna, World MakerFaire New York a další. Firma Prusa Research s.r.o. sídlí v hlavním městě České Republiky, zaměstnává okolo třiceti zaměstnanců a svým zákazníkům dodávají měsíčně okolo 500 3D tiskáren - Prusa i3. Jejich produktem je sestava 3D tiskárny nebo stavebnice 3D tiskárny. Po konzultaci s Michalem Průšou vznikla myšlenka vytvořit jednoduchý a efektivní skladový systém, kvůli nedostatečnosti a nepřehlednosti stávajícího systému. Hlavní nevýhody spatřuje firma Prusa Reserch s.r.o. v jednoduchém narušení funkce bez okamžitě viditelných následků, náročnosti implementace komplexnějších funkcí a jejich provázanosti, absence možnosti modifikace jednotlivých dat se zachováním funkčnosti. Tyto problémy chceme řešit pomocí vytvoření systému na míru, dle daných požadavků. Aplikace bude ukládat jednotlivé záznamy o skladových položkách, produktech, dodavatelích a objednávkách do databáze. Systém doplňování skladových zásob bude ovlivněn zjednodušenou metodikou plánování potřeby materiálu – Kanban. O tom se podrobněji zmíním v teoretické části mé bakalářské práce.
8
2 Plánování potřeby materiálu 2.1 Úvod Z úvodní analýzy a promyšlení dané problematiky jsem usoudil, že se nabízí využití technik a principů MRP (Material Requirement Planning) - plánování potřeby materiálu. Jak z názvu vyplývá, jedná se o techniku řízení zásob ve výrobním procesu. Výhodou zavedení MRP je: efektivnější řešení zákaznických objednávek, zvýšení kapacit strojů a lidských zdrojů, snížený hladiny zásob. Hlavním cílem techniky MRP pro mé zadání je optimalizovat stav zásob na skladě a zajistit tím plynulý chod výroby. [1] V další části kapitoly si popíšeme historii, základní principy, výstupy, cíle a předpoklady techniky MRP.
2.2 Historie plánování potřeby materiálu Za průkopníka se považuje Joseph Orlický (1922 - 1986). Čech, který emigroval do USA po 2. světové válce. Orlický získal titul MBA, pracoval ve firmě J. I. Case Company. Tato firma se zabývala výrobou traktorů a zemědělské techniky. V roce 1961 jako výrobní ředitel vedl tým, který vyvinul a prakticky ověřil systém Plánování potřeby materiálu. V roce 1975 mělo systém zavedeno už 700 společností. O 6 let déle to bylo okolo 8000 společností po celém světě. [1][2]
2.3 Základní princip Základní princip techniky plánování potřeby materiálů je vždy stejný, nicméně implementace techniky se může lišit dle specifických požadavků každé organizace, kde se systém využívá. [2] Pro zavedení techniky je nutná: databáze vyráběných položek, databáze nakupovaných položek, databáze kusovníků pro vyráběné produkty (potřebný materiál pro každý produkt). Dále je třeba vytvořit databázi stávajících skladových zásob a databázi objednávek. Stanovit si počet vyráběných produktů a v neposlední řadě časový horizont pro vyřízení objednávky a sestavení produktu. Při přepočtu MRP si systém prohlédne u každého produktu jeho kusovník a zjistí, z jakého materiálu se produkt skládá. Dále zjistí, zda lze některé požadavky splnit ze skladových zásob. Tímto si systém vytvoří seznam pro pokrytí plánu výroby a předá uživateli výstupy. [3] 9
2.4 Cíle Důvodem implementace této techniky je zajištění plynulého přísunu materiálu do firmy. Materiál musí být k dispozici ve správném množství, na správném místě a ve správný čas. Účelem techniky je snížit celkové náklady díky držení co nejnižších skladových zásob. Technika MRP vypočte celkovou potřebu materiálu a komponent z příslušného produktového kusovníku. Kusovník také zajistí orientaci nad časovým průběhem výroby a sleduje potřeby produktu. Za pomoci těchto vlastností je možné přesně určit, kdy je třeba objednat materiál. [1]
2.5 Výstupy Po přepočtu MRP uživatel dostane soupis doporučení. Obsluze navrhne kolik, a čeho má nakoupit nebo vyrobit. Záleží pouze na člověku, zda tyto doporučení přijme. Tím se dostáváme k tomu, že systém MRP neřídí firmu, ale rozhodovat se musí stále lidé. Po přijetí doporučení systém připraví objednávku nebo výrobní plán. [1]
2.6 Základní struktura
Obrázek 1 - Základní schéma techniky MRP. Zdroj [3]
10
2.7 Časové fáze výroby produktu Systém plánování potřeb materiálu se také zabývá časovými fázemi výroby produktu. Tyto fáze je třeba naplánovat tak, aby byla zajištěna plynulá výroba. [4]
Obrázek 2 - Časové fáze výroby. Zdroj [4]
Nyní si popíšeme obrázek 2. Na obrázku vidíme naplánované časové fáze, které navazují na sebe tak, aby se na žádnou komponentu nečekalo. Například pro produkt B, který se vyrábí 2 týdny, musíme mít vyrobené komponenty D a E. Výroba těchto komponent je časově synchronizována tak, aby D nemusel čekat na skladě. Proto je výroba D posunuta o týden vpřed oproti E.
2.8 Kanban Vychází z metodiky MRP. Jedná se o zjednodušenou verzi, která nevyužívá časové proměnné z objednávek. Je to plánovací systém, který pomocí vizualizace říká uživateli kdy a kolik toho vyrobit. V našem případě objednat. Metoda Kanban má kořeny ve čtyřech základních principech. [5]
Začít na stávajícím projektu.
Zavázat se v uplatňování inkrementální, evoluční změny.
Respektovat současný proces, role, odpovědnosti a tituly.
Vedení na všech úrovních. 11
Obrázek 3 - Ukázka vizualizace Kanbanu. Zdroj [6]
Na obrázku 3 vidíme, jak to celé funguje při řízení zásob nebo výrobě produktu. Zde se vkládají karty od spodní kapsy. Celý sloupec je rozdělen na tři barvy. Zelená – vše v pořádku. Žlutá – pozor něco dochází, čas objednat. Červená – kritická hodnota, nutnost doplnit zásoby. V našem případě nebudeme do tabule přidávat, ale odebírat položky. Barvy budou řazeny sestupně a postupným odebíráním zásob se dostaneme ze zelené až do červené.
12
3 Systémy pro správu obsahu (CMS) 3.1 Úvod Systém pro správu obsahu neboli CMS (Content Management System) se nejčastěji používá pro správu obsahu internetových stránek. Běžně CMS obsahuje dva prvky. CDA (Content Delivery Application) a CMA (Content Management Application). [7] CMA umožňuje autorovi, který nezná značkovací jazyk HTML (HyperText Markup Language), spravovat, vytvářet a upravovat obsah bez pomoci správce webu. Prvek CDA je v podstatě určen k nahrazení funkce správce internetových stránek. Veškeré změny obsahu internetové stránky nyní díky CDA nepotřebují webového vývojáře. Tedy CMA provádí nezbytné práce při vytváření nové webové stránky nebo provádí změny v konečném stavu internetové stránky, která je vidět pro návštěvníky. [7] Funkce systému pro správu obsahu se všeobecně člení na dvě části: administrátorské (backend) a uživatelské (frontend). Hlavní funkcí je vytváření, editace a zveřejňování dokumentů. Tyto dokumenty se nejčastěji vytváří pomocí WYSIWYG (What You See Is What You Get) nástroje. Tento online nástroj se pyšní jedinečnou vlastností, díky které může vytvářet obsah internetové stránky bez znalostí HTML. Obsah, který vytvoří v editoru, se přesně zobrazí na internetové stránce. Bohužel nevýhodou WYSIWYG editoru je, že do výsledného HTML generuje spoustu elementů, které jsou nežádoucí. Mezi nejznámější WYSIWYG editory patří TinyMCE a FCKEditor. Mezi další důležité funkce lze zařadit správu souborů, galerií, obrázků, statistik, kalendářních funkcí a správu komentářů nebo diskuzí. Většinu CMS lze rozšířit přídavnými moduly, které si však musíme naprogramovat nebo koupit. [7][8] Tyto systémy lze rozlišovat pomocí dvou faktorů. Prvním faktorem je cena. Na trhu se vyskytují komerční systémy pro správu obsahu a také systémy, které jsou zdarma (opensource). Open-source systémy získávají finance pro vývoj prodejem rozšiřujících modulů. Druhým faktorem, na kterém závisí použití daného systému, je technologie, kterou byl systém vyvinut. Na trhu se nejčastěji nachází systémy naprogramovány jazykem PHP nebo .NET. Nejpoužívanější open-source systémy jsou: Wordpress, Joomla!, Drupal. Tyto systémy jsou postaveny na technologii PHP. Komerčním
13
systémem je například ExpressionEngine, který stojí od 99,95 do 299,95 amerických dolarů. Open-source systém postavený na technologii .NET je Umbarco. [8]
3.2 CMS Joomla! Jak již bylo zmíněno, tak Joomla! je systém pro správu obsahu na internetových stránkách, který je open-source (zdarma) a postavěný na programovacím jazyku PHP. Od verze 1.5 (22. 01. 2008) využívá techniky objektově orientovaného programování a návrhové vzory. Data ukládá v databázích typu MySQL, MS SQL nebo PostreSQL. [9] Na redakčním systému fungují velké korporace jako CitiBank, eBay, Harvard University, Ikea, Mc Donald´s, Sony a další. [10] Tento CMS systém vznikl 17. 08. 2005, díky rozporům mezi vývojáři v projektu Mambo. O pět dní později, tedy 22. 08. 2005, vyšel první oficiální balíček Joomla! 1.0.0, který byl pouze převlečené Mambo 4.5.2.3. Další verze 1.5 vyšla o tři roky později. V současnosti dochází k aktualizacím systému několikrát do roka. Nejnovější dostupnou a stabilní verzí je verze 3.4.8, tuto verzi lze zdarma stáhnout na oficiálních stránkách projektu Joomla! www.joomla.org. [11] Statistika uvádí 50 milionů stažení balíčku s Joomlou! za rok 2014. V oficiálním obchodě s rozšířeními Joomly! bylo přes 7700 komerčních a nekomerčních rozšíření a mnohem více z ostatních zdrojů. Tohle dělá z Joomly! druhý nejpoužívanější systém pro správu obsahu na internetu. Hned po systému WordPress. [9] Joomlu! je možno rozšířit několika způsoby. Spousta funkcionalit je už naprogramována a dostupná zdarma ke stažení z internetu. Buď z oficiálního obchodu s rozšířeními anebo od soukromých vývojářů. Dále je možné si tyto rozšíření koupit. Oficiální obchod s rozšířeními
nalezneme
na
www.extensions.joomla.org.
Spousta
rozšíření
naimplementována není a tak nám nezbývá nic jiného, než si ho naprogramovat. Rozšíření pro Joomlu! se dělí na obsáhlé komponenty, menší moduly a pluginy, které jednoduše upravují některé vlastnosti. V poslední řadě můžeme také za rozšíření brát šablony. Ty mění celkový vzhled uživatelské části. Existují i šablony pro část administrativní. V následující části si detailněji popíšeme jednotlivé typy rozšíření a ukážeme jejich strukturu. [9]
14
3.2.1 Joomla! podrobný přehled rozšíření 3.2.1.1 Komponenta Komponenta je základním a zároveň největším možným rozšířením pro Joomlu!. Komponentou suplujeme funkčnost, která v základním CMS balíčku chybí. Například rozšířením pro správu e-shopu, obrázkovou galerií nebo podporou přípravy výroby. [9] Pro mou práci je vývoj komponenty zcela zásadní a v této kapitole si podrobněji popíšeme její implementaci.
3.2.1.1.1 MVC Komponenta je založená na návrhovém vzoru MVC (Modul View Controller). Jedná se o softwarovou architekturu, která rozděluje aplikaci na několik dílů. Model, logická část aplikace, která se stará o data, logiku a pravidla. View je výstupem a reprezentací informací, které se zpracovávají v modelu. Také slouží k získávání vstupních příkazů pro další části návrhového vzoru. V komponentě je možno mít vícero views i se stejnými daty. Třetí částí je controller. Ten zpracovává vstupní příkazy od uživatele a předává je dál pro model nebo view. [12][13]
Obrázek 4 - Přehled struktuy MVC. Zdroj [14]
Dle obrázku uživatel provede příkaz. Controller příkaz zachytí a vyhodnotí jej. Podle výsledků rozhodnutí ovlivní buď v konkrétní view, ve kterém je proveden počáteční příkaz nebo se provede změna v modelu. Model může například upravit stavy v databázi.
15
3.2.1.1.2 Ukázková komponenta Na ukázce si ukážeme strukturu jednoduché komponenty a popíšeme si rozdělení a význam jednotlivých souborů. V první řadě si na obrázku ukážeme rozvržení instalačního balíčku pro komponentu, který budeme vyvíjet.
Obrázek 5 - Rozvržení komponenty. Zdroj [9]
Pro lepší orientaci jsem v obrázku označil složky tučným textem a koncové soubory textem klasickým. 16
Na první pohled je jasné, že instalační balíček komponenty je rozdělen na dvě části. První část je ve složce site. Tato složka obsahuje soubory a složky určené pro „frontend“ komponenty. Druhá složka admin je určená pro „backend“ komponenty. V kořenovém adresáři je ještě jeden soubor test.xml. Toto je instalační xml skript, který dodá základní informace o autorovi, licenci, datumu vytvoření, názevu komponenty a jejího popis. Dále je v něm uvedena struktura komponenty, jazykové nastavení a práce s databází. V každém adresáři se nachází soubor index.php. Tento soubor v sobě ukrývá pouze jediný řádek HTML kódu.
V internetovém prohlížeči je možno zadat přímo cestu do různých adresářů. V případě, že uživatel nemá dostatečná přístupová práva, tento řádek kódu zapříčiní výpis bílé stránky. To vše za pomoci následujícího PHP kódu, který je v každém souboru s příponou .php.
3.2.1.1.2.1 Adresář views
Adresář view je pro nás velmi důležitý, konkrétně se nejvíce zajímáme o soubor jmeno_view/tmpl/default.php. V tomto souboru se programuje a kóduje vše, co uvidí uživatel. Jak v „backendové“, tak ve „frontendové“ části. V adresáři view si můžeme vytvořit jednotlivých view kolik chceme. V naší struktuře máme pouze jedno a to test. Další vytvoříme pouze duplikováním view test a přejmenováním jeho názvu a úpravou souboru view.html.php. 3.2.1.1.2.2 Adresář controllers
V adresáři controllers je pro nás stěžejním souborem test.php. Zde se implementují funkce, které mají na starosti ovládání aplikace. Například ve view máme formulář, ze kterého chceme uložit data do databáze. Po stisknutí tlačítka pro potvrzení formuláře se zavolá funkce uložit v controlleru. Controler sám o sobě nepracuje s databází. Zavolá si proto funkci z modelu a pomocí ní záznam uloží do databáze. Funkce z controlleru jsou k dispozici ve všech views.
17
3.2.1.1.2.3 Adresář models
V adresáři models se zajímáme o soubor test_model.php. V tomto souboru se implementují funkce, které především operují s daty. Z předešlého odstavce víme, že model úzce spolupracuje s controllerem. V konkrétním modelu se pracuje s konkrétní databází. K práci s databází se používají vytvořené metody pro skládání dotazů, které si podrobněji vysvětlíme níže. 3.2.1.2 Modul Moduly (nebo zásuvné moduly) se od komponenty liší návrhem. Velká změna je v jejich struktuře, která používá jen zjednodušenou formu návrhového vzoru MVC. Hlavními cíli modulu jsou spíše menší obsahové nebo stylistické změny. Například pro různé role uživatelů zobrazuje stejné tabulky, ale s jinak rozšířeným obsahem. [9]
3.2.1.2.1 Ukázkový modul Nyní si ukážeme strukturu ukázkového modulu a stručně si popíšeme jeho části.
Obrázek 6 - Rozvržení modulu. Zdroj [9]
Stejně jako je tomu v komponentě, tak v každém soboru s příponou .php je na začátku kódu následující příkaz, který znemožňuje zadávání přímých cest v internetovém prohlížeči.
18
Dále je v kořenovém a tmpl adresáři soubor index.html, který po zadání přímé cesty do internetového prohlížeče vypíše pouze čistě bílou stránku. Obsahuje stejný HTML kód jako v komponentě.
Veškeré funkce a metody jsou naimplementovány v souboru helper.php. Tyto funkce se dále musí zavolat v souboru mod_test.php. Tím si připravíme potřebné proměnné, které používáme v tmpl/default.php. Zde se kóduje a programuje vše, co uvidí uživatel. 3.2.1.3 Plugin Pluginy jsou druhem rozšíření, které poskytují funkce spojené se spouštějícími událostmi. Joomla! poskytuje řadu vlastních pluginů, ale každé rozšíření může vyvolat svojí vlastní událost. Pokud se vyvolá vlastní událost, všechny funkce spojené s událostí se provádí v pořadí. Pluginy se rozdělují do několika skupin. Několik z nich si tu popíšeme. Autentizační (authentication), zde řadíme pluginy, které vyžadují přihlášení. Například přihlášení pro Facebook nebo Gmail. Obsahové (content) pluginy umožňující měnit obsah předtím, než se zobrazí na internetové stránce. Mezi editory (editors) patří pluginy, které rozšiřují funkčnosti WYSIWYG editorů jako jsou TinyMCE nebo CodeMirror. Podobnou skupinou jsou editory-XTD (editors-XTD). Tato skupina pluginů přidává do WYSIWYG editorů tlačítka s rozšířenou funkcionalitou. Například pokud chceme přidat tlačítko, které vloží symbol copyrightu, tak musíme naprogramovat plugin pro skupinu editoru-XTD. Skupina rozšíření (extensions) se spouští při událostech, kdy jsou rozšíření (komponenta, modul, plugin) instalovány, aktualizovány, odinstalovány nebo upravovány přes správce pluginů, správce modulů, správce šablon nebo správce jazyka (tyto správci jsou nástroje uvnitř administračního prostředí Joomla!). Uživatelské (user) pluginy povolují dělat věci navíc při specifických událostech. Například je možno si vybrat jaké informace o uživateli chceme uchovávat během registrace (adresa, datum narození, webové stránky atd.). Poslední důležitou skupinou, kterou si zde popíšeme, jsou systémové pluginy. Tyto pluginy běží na pozadí a jsou volány pokaždé během nového cyklu bez ohledu na to, který příkaz byl proveden. [9]
19
Pluginy se běžně skládají ze dvou souborů a to test.php, ve kterém je naprogramována funkčnost pluginu. Dalším souborem je test.xml, kde jsou potřebné informace pro úspěšnou instalaci pluginu. [9]
3.2.2 Databáze 3.2.2.1 Připojení k databázi K databázi se můžeme připojit dvěma způsoby. Prvním je nastavení připojení při instalaci. Druhým způsobem je konfigurace souboru configuration.php, ve kterém jsou pro nás důležité následující řádky. [15] public $dbtype = 'mysqli'; public $host = 'localhost'; public $user = 'jobajtek'; public $password = '*********'; public $db = 'db_pws'; public $dbprefix = 'jos_';
Název proměnných vypovídá o jejich účelu, ale proměnnou dbprefix je dobré si vysvétlit. Díky tomuto prefixu může databázi db_pws využívat více redakčních systémů Joomla!. U druhého systému stačí změnit prefix a vše bude fungovat. [15] 3.2.2.2 Práce s databází V této části se budeme zabývat dotazy. Především si ukážeme jak z databáze získat data a různé již existující metody, které mění charakter načtených dat.
3.2.2.2.1 Tvorba prvního dotazu Při vytváření každého dotazu je nutno mít na paměti roli prefixu. Vždy když v dotazu zmiňujeme název tabulky je třeba tento prefix zakomponovat. To zajistí řetězec „#__“. Řetězec si získá nastavený prefix ze souboru configuration.php, který najdeme v kořenovém adresáři projektu. Například tedy místo celého názvu tabulky s prefixem „jos_produky“ použijeme v dotazu „#__produkty“. Ukážeme si jak napsat jednoduchý dotaz pro výpis všech záznamů z tabulky „jos_produkty“. Zápis je jednoduchý, do proměnné se přiřadí řetězec s SQL (Structured Query Language) dotazem. [15] $query =
'SELECT * '.'FROM #__produkty';
20
Ještě před tím, než vykonáme dotaz, je třeba načíst referenci na globální objekt databáze. Příkaz se vykonává, pouze pokud již není reference vrácena. [15] $db = JFactory::getDBO();
Nyní můžeme vykonat příkaz pro provedení dotazu. $db->setQuery($query);
Získat výsledek provedeného dotazu můžeme několika metodami. V další části kapitoly si popíšeme jednotlivé metody.
3.2.2.2.2 Metody pro získávání dat Veškeré metody voláme sejným způsobem jen se správným názvem metody. Typ metody vybíráme podle potřeb na vrácené výsledky. [15] $result = $db->názevMetody();
3.2.2.2.2.1
loadRowList()
Do proměnné result se přiřadí jako vícerozměrné pole seznam záznamů z tabulky jos_produkty. Toto pole je indexované od 0. Podobná funkce jako myslql_fetch_row. [9] 3.2.2.2.2.2 loadAssocList()
Tato funkce vrací seznam ve vícerozměrném poli, ale jako indexy jsou zde použity názvy sloupců z databáze. [15] 3.2.2.2.2.3 loadObjectList()
Do proměnné result přiřadí seznam záznamů jako objekty. Tyto objekty jsou číslem indexované podle pořadí. [15] Existují ještě další metody, které vrací pouze jeden řádek, sloupec nebo počet záznamů v tabulce (getEnumRows()). My jsme si zde popsali 3 nejužitečnější, které budeme používat. [15]
21
4 Analýza stávajícího skladového systému 4.1 Úvod Tato část popisuje aktuální skladový systém firmy Prusa Research s.r.o. jeho výhody, nevýhody, základní funkce a aktuální stav.
4.2 Popis systému Jedná se o velmi jednoduchý systém plnící základní funkce ERP. Vzhledem k časovým možnostem a předchozím zkušenostem s implemetací složitých ERP systémů bylo rozhodnuto o vývojovém prostředí Google apps, konkrétně o Google Spreadsheet. Toto prostředí velmi zkrátilo dobu vývoje na několik desítek hodin. Systém a jeho funkce:
Obsahuje databáze objektů a násobků, ze kterých se skládá nadřazený celek.
Predikuje včasnost objednávek za předpokladu dané měsíční produkce celků.
Identifikuje zodpovědnou osobu za aktuální stav skladu.
Vyhodnocuje aktuální hodnoty skladu.
Počítá materiálové náklady na produkci celku.
Funkce byly postupně dodělávány a vymýšleny dle aktuálních potřeb. Tento model je ideální pro jednoduché systémy, avšak postupem času se ukázalo, že dodělat náročnější funkce je velmi obtížné a mnohdy nemožné. V případě tvorby nové komplexní funkce je nutné vytvořit vedlejší systém, ve kterém je třeba, díky absenci provázanosti, dodržovat manuálně aktuální stavy, aby byla jeho funkčnost relevantní.
4.3 Výhody a nevýhody Výhody aktuálního systému:
Krátká doba vývoje.
Velmi vysoká dostupnost odkudkoliv.
Jednoduché uživatelské ovládání.
Snadná modifikace jednotlivých objektů.
22
Nevýhody aktuálního systému:
Jednoduché narušení funkce bez okamžitě viditelných následků.
Náročnost implementace komplexnějších funkcí (posílání e-mailů s objednávkami a další).
Absence možnosti modifikace jednotlivých dat se zachováním funkčnosti.
Nemožnost výroby více nadřazených celků skládajících se z podobných komponent.
Pokud si srovnáme výše uvedené výhody a nevýhody je jasné, že aktuální systém za předpokladu expanze firmy Prusa Research s.r.o., přestává být efektivní a je tedy nutné navrhnout a implementovat jiné řešení. Stávající ERP systémy jsou velmi komplikované. Nastavení a úprava aktuálních procesů pro potřeby firmy jsou časově náročné, nehledě na přebytečné funkce, které by byly pro naše účely spíše kontraproduktivní. Proto bylo nutné navrhnout řešení problému postavením systému na míru.
Obrázek 7 - Ukázka stávajícího systému
23
5 Návrh a implementace nového skladového systému Po teoretické části a analýze stávajícího systému máme dostatek informací k vyřešení zadaného úkolu. Zde bych rád připomenul požadavky na nový skladový systém pro firmu Prusa Research s.r.o.. Dále bych se zmínil o grafické úpravě webové aplikace, popsal návrh databáze, specifikoval hlavní prvky implementace a řešení zadaného problému.
5.1 Požadavky na skladový systém Po konzultaci s firmou Prusa Research s.r.o. bude nový skladový systém používán přes webové prostředí a implementován na systém pro správu obsahu Joomla!. Hlavní požadavek na systém je možnost operativního doplňování skladu. To zajistíme zavedením Kanbanu. Díky Kanbanu budeme mít možnost sledovat jednotlivé skladové položky v tabulkách, které budou mít řádky rozdělené dle barev. Podle barvy na první pohled zjistíme, jaké součástky nám docházejí nebo jsou ještě v toleranci se základním nastavením. Po překročení minimálního počtu součástek bude uživateli ihned oznámeno, že překročil limit a je nejvyšší čas objednat nové komponenty. Další požadovanou funkcí firmou Prusa Research s.r.o. je aktualizace stavů skladových zásob dle zadaného počtu vyrobených kusů. Po zadání vyrobeného produktu se musí odečíst správný počet skladových položek dle nadefinovaného kusovníku k danému produktu. V poslední řadě by měl systém obsahovat nástroje pro správu a výpis jednotlivých entit, které hrají v projektu velkou roli. Jde o možnost výpisu, přidávání, editace a mazání dodavatelů, objednávek, skladových položek, produktů, kusovníků a skladových pozic. Jednotlivé entity jsou provázané a více si je popíšeme v části s návrhem a implementací databáze.
5.2 Srovnání s existujícími řešeními V této části kapitoly se budeme zabývat, zda na internetu je dostupné nějaké řešení našeho problému. Hledáme buď stejné, nebo podobné řešení s prvky MRP a řízení skladu. Jako první vyhledávající zdroj jsem použil výše zmíněnou databázi pro Joomla! rozšíření http://extensions.joomla.org/. Jelikož vyvíjím komponentu, tak i zde jsem hledal 24
komponentu, která alespoň trochu odpovídá zadání mé bakalářské práce. Bohužel jsem nalezl pouze vzdáleně příbuznou komponentu Quipu, která obsahuje prvky ERP (Enterprise Resource Planning). ERP je modernější a rozšířenější verze MRP, která vznikla v průběhu devadesátých let. Tato open-source komponenta je určena pro oblast obecného podnikání. Umožňuje spravovat seznamy zákazníků, faktur, bankovních účtů a mnoho dalších. Quipu je dostupné od listopadu roku 2014 pro verzi Joomly! 3.x.x. Jako další vyhledávající zdroj jsem použil nejznámější internetový vyhledávač http://google.com. Ani zde nebyly výsledky uspokojivé. Po několika-hodinovém hledání jsem našel pouze odkaz na Quipu, teorie MRP a MRP software. Pokud z mého hledání vynechám systém pro správu obsahu Joomla!, nalezneme nespočet programů zabývajících se problematikou MRP a ERP. K dispozici jsou jak programy zdarma, tak programy placené. Nejvíce mne zaujal placený systém MRPEasy, který nabízí zkušební verzi zdarma. Tento software funguje přes webovou aplikaci a na první pohled je velice pěkně zpracován. Po registraci se ocitneme v úvodním dashboardu, kde je rozcestník na všechny funkce systému: produktový plán, plánování produkce, skladové položky, dodání, nastavení a přizpůsobení. Na první pohled je vše přehledné, ale při procházení jednotlivých funkcí se dostaví nejistota a zmatek. Výše zmíněné bych shrnul tím, že pokud bychom vynechali systém pro správu obsahu Joomla!, tak naleznu spoustu MRP systémů. MRPEasy by byl plně dostačující pro mé zadání bakalářské práce. Na druhou stranu pro systém Joomla! není nic vyhovujícího naimplementováno a díky tomu považuji moji bakalářskou práci za originální.
5.3 Grafická stránka skladového systému Jedním z požadavků ze strany firmy, který nebyl uveden v zadání je responzivita aplikace. Pomocí responzivního web designu se dosáhnu, že aplikace bude zobrazitelná jak na desktopových počítačích, tak i na mobilních laptopech, tabletech a telefonech. Responzivitu zajistím správným stylováním HTML stránek pomocí kaskádových stylů (CSS). V mém případě to bude preprocesor kaskádových stylů zvaný LESS. LESS rozšiřuje klasické CSS o nové vlastnosti. Například použití proměnných, mixinů a vnořených pravidel. Pro instalaci LESSu musím mít v počítači nainstalovaný balíček Node.js. Celý systém bude postaven na CSS frameworku Bootstrap3. Tento framework
25
nabízí spoustu před stylovaných tříd, které povedou správným směrem k dodržení responzivity.
5.3.1 Node.js Node.js je softwarový systém navržený pro psaní vysoce škálovatelných internetových aplikací,
především webových
serverů.
Programy
pro
Node.js
jsou
psané
v jazyce JavaScript, hojně využívající model událostí a asynchronní I/O operace pro minimalizaci režie procesoru a maximalizaci výkonu. [16] Nicméně mě Node.js stačí pouze pro instalaci LESSového kompilátoru.
5.3.2 Instalace LESS Instalace Lessc probíhá následujícím způsobem (za předpokladu nainstalovaného Node.js). V příkazové řádce se dostaneme do projektu, kde chci LESS nainstalovat a sputím příkaz npm install less. Po instalaci se kompilace souboru s příponou .less vyvolá příkazem lessc „cesta k souboru .less“ „cesta kam se má generovat výsledný soubor .css“. Vždy, když chci, aby se projevily změny v souboru .less, musím zadat tento příkaz v příkazové řádce. Tento způsob je velice neefektivní pro práci, a proto jsem si nastavil v Php Stormu (IDE) File Watcher. Jedná se o automatickou kompilaci .less souboru po každé změně, aniž bych musel cokoliv psát do příkazové řádky (v OSx terminál).
5.3.3 Less struktura Původně se všechny less třídy zapisovaly pouze do jednoho .less souboru a ten se kompiloval. Nyní mám složku less rozdělenou na 4 adresáře a core.less. Do souboru core.less se importují všechny ostatní složky a jejich .less soubory. Příklad importu souboru: @import ui/header.less;. Výhoda je použití přepisů tříd z původního CSS frameworku Bootsrap 3, který mám nahraný ve složce libs. Například, pokud chci použít tabulku z Bootstrapu, ale rádi bych jí dal jinou barvu. Založíme ve složce přepis této třídy za pomocí table.less a přestyluji tabulku podle mých úmyslů. Pořadí importů určuje prioritu. Nejdříve se hledá přepis Bootstrapu, pokud se nenajde, tak se načte originál a pokračuje se dál. Ve složce core stylizuji všeobecné věci, jako jsou obecná nastavení fontů, tagů
a podobně. Ve složce ui upravuji námi vytvořené originální styly bez použití Bootstrapu.
26
Obrázek 8 - Ukázka LESS struktury
5.3.4 Tvorba Joomla! šablony Nyní je třeba vytvořit šablonu. Nejjednodušší způsob jak tuto šablonu vytvořit je duplikovat původní Joomla! šablonu jménem Protostar. Dále přejmenovat všechny důležité soubory dle názvu šablony. Zahrnout LESS strukturu a smazat pro nás nepotřebné soubory, které využívá původní šablona. Tímto jsme zajistily, že po aktualizaci celé Joomly! nepřijdeme o vytvořené struktury a styly.
5.3.5 Design skladového systému Ve skladovém systému bych chtěl zachovat styl firmy Prusa Research, který je minimalistický a jednoduchý. Skladový systém by měl být barevně a designově podobný jako jejich e-shop www.prusaresearch.com a firemní stránky www.prusa3d.cz.
5.4 Návrh a implementace databáze CMS systém Joomla! využívá především databáze typu MySQL. Díky této kompatibilitě jsem nepřemýšlel o jiné možnosti. Mezi hlavní výhody tohoto open-source databázového systému patří podpora na všech platformách a vysoký výkon. Databázi bude tvořit šest entit, které budou provázané cizími klíči. Tyto entity se jmenují: suppliers (dodavatelé), orders (objednávky), stocks (skladové položky), products (produkty), boms (kusovníky) a socksloc (polohy skladových položek). Jejich tvorbu, atributy a klíče podrobně popíši v rozboru E-R diagramu.
27
5.4.1 E-R diagram
Obrázek 9 - E-R diagram
5.4.2 Popis tabulek Všechny tabulky začínají speciálním názvem. Obsahují databázový prefix použitý pro Joomlu!, v mém případě jos_. Následuje název komponenty prusawarehouse a nakonec název tabulky. Tyto názvy byly zvoleny z důvodu zachování konvenčních postupů při vyvíjení komponent pro tento CMS systém. Ze stejného důvodu jsem zvolil názvy psát v anglickém jazyce. 5.4.2.1 jos_prusawarehouse_stocks Tabulka (entita), ve které se uchovávají informace o skladových položkách, se skládá z následujících sloupců (atributů): id (primární klíč), id_supplier (cizí klíč na tabulku s dodavateli), title_stock (název skladové položky), type (typ skladové položky), quantity_stock (aktuální počet na skladě), quantity_min (kritická hodnota, pod kterou by skladová položka neměla klesnout), id_location (cizí klíč na tabulku se skladovými pozicemi), price_stock (cena skladové položky), delivery (přibližný čas dodání), state. Je dobré, trochu více vysvětlit atribut state. Jedná se o stav, který je defaultně nastaven na jedna. Po smazání záznamu se stav nastaví na dvě, ale z databáze se smaže. Z tabulky načítáme pouze záznamy, u kterých je stav roven jedné. Použito z důvodu archivace
28
záznamů v tabulce. Tento atribut se nachází ve všech entitách. Na tabulku se vážou další tabulky. Stocslocs, suppliers ve vztahu 1:1. Boms ve vztahu N:1. 5.4.2.2 jos_prusawarehouse_suppliers Tato tabulka uchovává informace o dodavatelích. Obsahuje tyto sloupce: id (primární klíč), name (jméno dodavatele), email (e-mail na dodavatele) a state. Tato tabulka je provázaná s tabulkami orders (ve vztahu N:1) a stocks (ve vztahu 1:1). 5.4.2.3 jos_prusawarehouse_orders V tabulce orders se ukládají data o objednávkách. Skládá se z následujících atributů. Id (primární klíč), id_supplier (cizí klíč), content (obsah objednávky), assumed_delivery (předpokládané doručení objednávky), state. Tato tabulka je provázaná pouze s tabulkou suppliers ve vztahu 1:N. 5.4.2.4 jos_prusawarehouse_products Zde se uchovávají informace o produktech. Obsahuje sloupce id (primární klíč), title_product (název produktu), quantity_product (počet vyrobených produktů), price_product (cena produktu), state. Tabulka je provázána s tabulkou boms (N:1). 5.4.2.5 jos_prusawarehouse_boms V této tabulce se uchovává složení kusovníků. Název vychází ze zkratky bill of materiál (kusovník). Obsahuje atributy id (primární klíč), id_product (cizí klíč na produkt, ke kterému kusovník patří), id_stock (cizí klíč na skladovou položku, která je přiřazená k produktu), quantity_bom (počet kolik skladových položek je na výrobu potřeba), state. Tabulka boms slouží jako vazební tabulka mezi tabulkami stocks a product. Řeší jejich počáteční vazbu M:N. 5.4.2.6 jos_prusawarehouse_stocksloc Slouží k ukládání dat o skladových pozicích skladových položek. Obsahuje pouze tři atributy. Id (primární klíč), location (název pozice), state.
29
5.4.3 Zhotovení databáze a popis dotazů Tvorba celé databáze probíhala v programu Sequel Pro. Je to správce MySQL databází pro Mac OS X. Veškeré tabulky jsem tvořil klikáním a tím odpadla tvorba SQL dotazů, které generuje program. 5.4.3.1 Tvorba tabulky CREATE TABLE `jos_prusawarehouse_stocks` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `id_supplier` int(11) unsigned NOT NULL, `title_stock` varchar(100) NOT NULL DEFAULT '', `type` varchar(100) NOT NULL DEFAULT '', `quantity_stock` int(11) NOT NULL, `quantity_min` int(11) NOT NULL, `id_location` int(11) unsigned NOT NULL, `price_stock` int(11) NOT NULL, `delivery` varchar(100) NOT NULL DEFAULT '', `state` tinyint(3) NOT NULL DEFAULT '1', PRIMARY KEY (`id`), KEY `StockSupp` (`id_supplier`), KEY `StockLoc` (`id_location`), CONSTRAINT `StockLoc` FOREIGN KEY (`id_location`) REFERENCES `jos_prusawarehouse_stocksloc` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `StockSupp` FOREIGN KEY (`id_supplier`) REFERENCES `jos_prusawarehouse_suppliers` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;
V ukázce vygenerovaného SQL dotazu pro tvorbu tabuky jos_prusawarehouse_stocks vidíme standartní postup při tvorbě tabulek. Definici všech výše zmíněných atributů a primárního klíče. Poslední řádky se věnují tvorbě cizích klíčů, které odkazují na další tabulky jos_prusawarehouse_stocksloc a jos_prusawarehouse_suppliers. 5.4.3.2 Dotazy SELECT, UPDATE Nyní popíši tvorbu dotazů v CMS systému Joomla!. Tyto dotazy pracují s tabulkou jos_prusawarehouse_stocks. Dotazy se často opakují, tudíž předvedu pouze dotazy, které jsou něčím specifické a neopakují se. 30
/* Výběr všech dat z tabulky jos_prusawarehouse_stocks, jména z tabulky jos_prusawarehouse_suppliers, jména pozice z tabulky jos_ prusawarehouse_stocksloc */ $query->select(array('a.*','b.name', 'c.location')) ->from($db->quoteName('#__prusawarehouse_stocks', 'a')) /* Vnitřní spojení tabulky jos_prusawarehouse_stocks s tabulkou jos_prusawarehouse_suppliers */ ->join('INNER', $db->quoteName('#__prusawarehouse_suppliers', 'b') . ' ON (' . $db->quoteName('a.id_supplier') . ' = ' . $db->quoteName('b.id') . ')') /* Vnitřní spojení tabulky jos_prusawarehouse_stocks s tabulkou jos_prusawarehouse_stocksloc */ ->join('INNER', $db->quoteName('#__prusawarehouse_stocksloc', 'c') . ' ON (' . $db->quoteName('a.id_location') . ' = ' . $db->quoteName('c.id') . ')') /* Výběr pouze nezarchivovaných záznamů */ ->where('a.state=1');
Tento dotaz je typickým pro vybírání dat z databáze. Prvně se do pole uloží atributy, které se mají načíst. Dále se určí tabulky, z kterých se data vybírají. Můžeme si všimnout, že se místo prefixu píše #__. Z teoretické části víme proč tomu tak je. Spojení probíhá přes příkaz join. Ten má následující atributy. Jaký typ propojení tabulky se použije. S jakou se váže a specifikace podle jakých id se spojuje. V poslední části je příkaz where. V něm se vybírá podmínka, podle které se provede celý select. /*Vrací odkaz na globální databázi, která je právě využívána.*/ $db = JFactory::getDbo(); /*Tvorba nového objektu pro dotaz*/ $query = $db->getQuery(true); /* Dotaz pro aktualizování záznamu v tabulce. */ $query->update('#__prusawarehouse_stocks') ->set('quantity_stock' . ' = ' . (int)$newQ) ->where('id' . ' = ' . (int)$id); /*Provedení dotazu*/ $db->setQuery($query); /*Do proměnné result se uloží hodnota true/false, podle toho jestli se povedlo dokončit dotaz.*/ $result = $db->execute();
Tvorba dotazu update je obdobná jako u výběru dat z tabulky. Nejprve se načte globální databáze, která je konkrétní Joomlou! používaná. Poté se vytvoří nový objekt query, do 31
kterého se nastaví jméno upravované tabulky. Atribut, který je upravován a jeho nová hodnota. V poslední řade se předá správné id, aby nedošlo k úpravě špatného záznamu. 5.4.3.3 Tvorba vztahů mezi tabulkami
Obrázek 10 - Tvorba relace
Tvorba relace probíhá ve zmíněném nástroji Sequel Pro. Zde se nastaví jméno vzniklého vztahu. Prvně se vybere název sloupce sloužící pro ukládání cizích klíčů, dále tabulka a id kam reference odkazuje. V poslední řadě se vybere akce, co se stane se záznamem při editaci nebo po smazání. Po vytvoření relace se vygeneruje SQL dotaz, který se přidá k dotazu pro tvorbu tabulky.
5.5 Implementace komponenty Nově vytvořená komponenta se v projektovém adresáři se samotnou Joomlou! ukládá do dvou složek. Components
a administrator/components. Implementace se odehrává
především v první možnosti. Tento adresář slouží pro uživatelskou část, ve které řešíme celý zadaný problém. Před začátkem implementace komponenty jsem si musel zvolit její název a přidat k ní standartní prefix zavedený Joomlou! com_. Celá cesta ke komponentě tedy zní projektovýadresář/components/com_prusawarehouse. Tento název byl sjednán se zástupcem firmy Prusa Research s.r.o..
32
5.5.1 Složení komponenty
Obrázek 11 - Složení komponenty
Na obrázku číslo 11 vidíme strukturu komponenty. Ta je velmi podobná struktuře, kterou jsme popsal a vysvětl v teoretické části (obrázek číslo 5). Z obrázku je patrné, že komponenta dokonale splňuje návrhový vzor MVC. Je rozdělena na tři hlavní adresáře controllers, models, views. Dále se tu nachází adresář language a tables. Každá složka obsahuje soubor index.html kvůli neoprávněným přístupům. Ve složce controllers se nachází pro každé view specifický controller, který pracuje s modelem a řídí datový tok aplikace. Tento model je zase přiřazený k určitému view a pracuje s databází. V models je další adresář forms, ve kterém jsou nadefinované xml soubory s atributy dané entity, se kterou model pracuje. Ve složce view jsou naimplementovány jednotlivé obrazovky komponenty, které spouštíme v prohlížeči. Implementace těchto obrazovek probíhá v souboru views/jmenoView/tmpl/default.php. 33
5.5.2 Popis a ukázka controlleru Podrobněji popíši funkci controlleru v naší aplikaci. V kořenovém adresáři komponenty je soubor controller.php, tento soubor obsahuje rodičovskou třídu pro všechny ostatní controllery. V této třídě je naprogramována kontrola, zda je uživatel přihlášený a má oprávnění se do komponenty podívat. Dále zde jsou inicializovány globální proměnné určené k nastavení počtu tiskáren pro barevné statusy ve view supply. define("printerCount", "10"); define("printerSucces", "30"); define("printerWarning", "14"); class PrusaWarehouseController extends JControllerLegacy{ public function display($cachable = false, $urlparams = false){ $user = JFactory::getUser(); if ($user->guest) { $this->setRedirect(JRoute::_(JUri::base(true))); return false; } parent::display($cachable, []); }}
V metodě display se hned provede načtení statusu uživatele do proměnné $user. Následuje podmínka, která ověří, zda je uživatel příhlášený nebo ne. Pokud ne, controller uživatele přesměruje na přihlašovací stránku aplikace. Tuto vlastnost dědí všechny ostatní specifické controllery ve funkci display. 5.5.2.1 Zděděný controller manufacture Pro ukázku zděděného controlleru jsem vybral controller manufacture. Tento controller pracuje s view manufacture a ovládá výrobu nových produktů a odečítá skladové položky dle počtů uvedených v kusovníku pro daný produkt. Popisovat všechny zděděné třídy pro každé view zde nebudu, protože bych razantně překročil rozsah bakalářské práce. Dalším důvodem popisu vybraného controlleru je zajímavá odlišnost od ostatních. Tento controller definujeme následující třídou, která obsahuje všechny metody rodiče a navíc své vlastní. class PrusaWarehouseControllerManufacture extends JControllerAdmin
34
Třída PrusaWarehouseControllerManufacture obsahuje navíc dvě metody. Metodu getModel, tato metoda je použita u všech zděděných controlleru s rozdílem, že každý si volá svůj specifický model. public function getModel($name = 'Manufacture', $prefix = 'PrusaWarehouseModel', $config = array('ignore_request' => true)){ return parent::getModel($name, $prefix, $config); }
Druhá originální metoda je discountQuantities. Tato metoda zajišťuje správné odečítání počtů skladových položek podle nadefinovaných kusovníků. public function discountQuantities(){ $model = $this->getModel(); $this->items = $model->getItems(); $input = new JInput(); $mp_count = $input->get('mp_count', '', 'post'); $product_id = $input->get('selid', '', 'post'); $new_pq = $model->getProductQuantity($product_id) + $mp_count; $state = false; foreach ($this->items as $item) { if($item->id_product == $product_id) { if (!($item->quantity_stock < $item->quantity_bom)) { $new_quantity = $item->quantity_stock - ($item->quantity_bom * $mp_count); if($model->updateNewQuantity($new_quantity, $item->id_stock)) { $state = true; }}}} if($state){ $model->updateNewProduct($new_pq, $product_id); $msg = JText::_('COM_PRUSAWAREHOUSE_WARNINGS_MANUFACTURE_SUCCES'); $this>setRedirect(JRoute::_('index.php?option=com_prusawarehouse&view=manuf acture'),JFactory::getApplication()->enqueueMessage($msg)); } else { $msg = JText::_('COM_PRUSAWAREHOUSE_WARNINGS_MANUFACTURE_FAILTURE'); $this>setRedirect(JRoute::_('index.php?option=com_prusawarehouse&view=manuf acture'),JFactory::getApplication()->enqueueMessage($msg,'warning')); }}}
35
V první části kódu připravím proměnné pro práci. Načtu metody z modelu do proměnné $model. Pro načtení pole objektů z databáze do proměnné $items použiji metodu z modelu getItems. Dále si do proměnných uložím proměnné z inputů ve view. Nyní se už pracuje s proměnnými. Všechny objekty z databáze se pro iterují cyklem foreach, proběhne kontrola, zda se pracuje s produktem se správným id a proběhne do pomocné proměnné $new_quantity výpočet nového počtu skladové položky. V dalším kroku se model pokusí metodou updateNewQuantity změnit v databázi počet kusů u správných záznamů podle id. Pokud vše proběhne správně, nastaví se proměnná $state na hodnotu true a vygeneruje se správná systémová hláška pro danou stránku.
5.5.3 Popis a ukázka modelu Stejně jako controller je pro každé view vytvořen model tak, aby zapadal do MVC struktury. Provedu zde zase ukázku pouze jednoho modelu z důvodů podobnosti kódu u ostatních modelů. Model manufacture, který si zde popíšeme, patří ke view manufacture. A obsluhuje ho výše zmíněný konkrétní controller. Definuje se následující třídou. class PrusaWareHouseModelManufacture extends JModelList
V této třídě jsou implementovány funkce, které pracují s daty a databázemi. První funkce, kterou si popíšeme, se jmenuje getListQuery. Tato metoda je použita ve všech modelech. protected function getListQuery() { $db = JFactory::getDbo(); $query = $this->_db->getQuery(true); $query>select(array('a.*','b.quantity_product','b.title_product','c.quantity _stock')) ->from($db->quoteName('#__prusawarehouse_boms', 'a')) ->join('INNER', $db->quoteName('#__prusawarehouse_products', 'b') . ' ON (' . $db->quoteName('a.id_product') . ' = ' . $db>quoteName('b.id') . ')') ->join('INNER', $db->quoteName('#__prusawarehouse_stocks', 'c') . ' ON (' . $db->quoteName('a.id_stock') . ' = ' . $db>quoteName('c.id') . ')'); return $query; }
36
Metoda slouží k načtení objektů do proměnné $items. Je to standartní metoda implementována Joomlou!, na nás je pouze vytvořit override (přepis) této metody a nastavit správnou tabulku, ze které chceme záznamy uložit. V mém případě spojuji tři tabulky. Pro spojení použiji INNER join, který se používá pro vybírání dat z více jak jedné tabulky. Další metoda, kterou popíšu, se jmenuje updateNewQuantity. Tato metoda podle zadaných parametrů, které se zpracují v controlleru, upraví záznamy v databázi. public function updateNewQuantity($newQ,$id) { $db = JFactory::getDbo(); $query = $db->getQuery(true); $query->update('#__prusawarehouse_stocks') ->set('quantity_stock' . ' = ' . (int)$newQ) ->where('id' . ' = ' . (int)$id); $db->setQuery($query); $result = $db->execute(); if ($result) return true; else return false; }
Prvně se standartně načte odkaz na globální databázi a vytvoří se nový objekt pro dotaz. Dále se tvoří samotný dotaz. Ten se skládá ze tří částí. Update, set, where. Do parametru první části se píše tabulka, která bude upravována. V druhé části se řeší atributy a jejich nové hodnoty. Na závěr v třetí části se určuje, jaký řádek bude upraven podle primárního klíče. Pokud vše proběhne v pořádku, tak celá metoda vrátí hodnotu true.
5.5.4 Popis a ukázka views Views jsou obrazovky, se kterými se dostane do kontaktu uživatel a interaktivně s nimi pracuje. Jedná se o místa, kde se vyhodnocují formuláře a sbírají data pro controllery a modely. Pro každou entitu se tvoří dvě views. Jedno je určeno pro výpis všech záznamů a druhé pro samotné přidávání nového prvku nebo editaci stávajícího. Níže popíšu stěžejní views pro naši aplikaci a zadání bakalářské práce.
37
5.5.4.1 View dashboard
Obrázek 12 - View dashboard
Toto view je první, které uživatel uvidí po úspěšném přihlášení. Jde o rozcestník na všechny operace, které aplikace umožňuje. Tento dashboard vznikal podle grafického návrhu, který jsem si vytvořil v předmětu semestrální projekt. V implementaci všech views jsem myslel na responzivitu aplikace. Díky tomu je umožněno pohodlné zobrazení a práce na mobilním zařízení. V rozcestníku vidíme 8 „dlaždic“. Každá má svůj význam a slouží jako tlačítko. Levá polovina čtyř tlačítek je určena pro správu entit. Jedná se o tlačítka skladové položky, produkty, dodavatelé a objednávky. U každé entity najdeme výpis záznamů z databáze a možnost tvorby nového záznamu. Dále editaci a mazání záznamu. V druhé polovině jsou dvě tlačítka. Tlačítko výroba, kterým se dostaneme do view manufacture. A tlačítko naskladnit. Tímto tlačítkem se dostaneme do view supply. Tyto dvě views popíši níže. Zbývají mi poslední dvě „dlaždice“. V jedné vidíme celkovou hodnotu skladu. Jsou v ní započítány veškeré skladové položky. Toto tlačítko je neaktivní. Poslední tlačítko s ikonou vykřičníku se zobrazí pouze, když některá ze skladových položek dosáhne menší nebo stejné hodnoty, než je nastavený její minimální počet. Po kliknutí na tlačítko se vypíše seznam s kritickými skladovými položkami. 5.5.4.2 View manufacture V této obrazovce probíhá vytváření nových produktů. View obsahuje pouze select box, input a button. V select boxu se vybere produkt, který chceme vyrobit. Do inputu se napíše počet vyráběných produktů. To vše potvrdíme buttonem a předáme tak data pro controller. Ten data zpracuje a podle příslušného kusovníku odečte počty skladových
38
položek.
Následně
upraví
počet
vyráběného
produktu
v tabulce
jos_prusawarehouse_products. 5.5.4.3 View supply
Obrázek 13 - View supply
V tomto view je umožněno doplňovat skladové zásoby tak, aby byl zajištěn plynulý chod výroby. Je zde implementována metoda Kanban, zmíněná v teoretické části bakalářské práce. Ta spočívá v přiřazení barevných statusů záznamům v tabulce, dle kterých přesně víme, kolik tiskáren můžeme vyrobit. Jak lze vidět na obrázku 13, tak máme čtyři barevné statusy. Zelená je aktuálně nastavena pro materiál nad 30 tiskáren. Druhou barvou je modrá, která je určena pro počet mezi šestnácti až třiceti tiskárnami. Dále je barva žlutá označující varovnou hodnotu více než 10, méně než 14. A poslední barvou je červená, která určuje kritický stav - možnost vyrobit pouze 10 a méně tiskáren. Všechny statusy lze jednoduše filtrovat podle barev a rychle zjistit, které skladové položky je třeba objednat. Další funkcí view supply je možnost doplňování zásob. Tyto nové hodnoty se píší do inputů v tabulce a potvrdí ikonou plus. Toto číslo je řádně zvalidováno. Pokud číslo projde validací, vypíše se hláška s úspěchem. Pokud neprojde, vypíše se hláška s důvodem neúspěchu.
39
5.5.4.4 View bom/ boms Poslední obrazovky, které popíši, se starají o výpis a tvorbu kusovníků pro produkty. Implementace je podobná jako u tabulek pracujících s ostatními entitami.
Obrázek 14 - View boms
Je zde skupina tlačítek. První umožňuje přidání nové skladové položky do kusovníku. Po kliknutí se dostaneme z view boms na view bom. Dále tu je select box, jehož pomocí měníme tabulku a vypisujeme vybraný kusovník. V tabulce je možno mazat a upravovat záznamy v kusovníku pomocí ikon ozubeného kolečka a odpadkového koše. Tabulku si můžeme také seřadit vzestupně nebo sestupně podle vybraných atributů.
Obrázek 15 - Tvorba kusovníku
40
Do view bom se dostaneme výše zmíněným tlačítkem. Zde je formulář, který po vyplnění uloží položku do kusovníku a umožní přidat novou. Formulář je ošetřený proti vkládání stejných komponent do kusovníku.
5.6 Testování komponenty Komponenta byla naimplementována necelé dva měsíce před odevzdáním bakalářské práce. Jednotlivé funkce byly testovány, jak v průběhu vývoje, tak i v čase po vývoji. Na testování jsem se podílel já a zástupce z firmy Prusa Research s.r.o. Michal Průša. Hlavním předmětem testování bylo, zda komponenta splňuje nadefinované požadavky ze zadání bakalářské práce. Nejvíce času si vyžádala výroba produktů. Zde bylo nutné, aby se po výrobě produktu správně odečetly veškeré komponenty podle vytvořených kusovníků. Druhou položkou, na kterou byl kladen velký důraz, byla validace formulářů, které pracují s počty skladových položek a produktů. Třetí zmíněnou položkou bude celková hodnota skladu. Ta se skládá ze skladových položek. Po výrobě produktu bylo třeba, řádně otestovat hodnotu odečtenou o skladové položky, které byly použity na výrobu produktu. Na konec se testovala funkčnost naimplementovaného Kanbanu ve view supply. Zde se testovala správná změna barevných statusů podle počtů materiálu na tiskárnu.
41
6 Závěr 6.1 Celkové zhodnocení Cílem této bakalářské práce bylo vyvinout software pro podporu přípravy výroby, který bude umožňovat
efektivně a operativně doplňovat skladové položky. Vedlejším
požadavkem na aplikaci byl přehled a administrace všech entit. V prvních krocích bylo nutné si nastudovat problematiku ohledně MRP a Kanbanu. Oživit si teorii o redakčním systému Joomla! a práci s databází. Díky těmto prvním krokům jsem pronikl do dané problematiky. Začátek samotné implementace bych hodnotil spíše negativně. Neměl jsem tolik zkušeností s vývojem celých aplikací pro tento CMS systém. Musel jsem kontaktovat známého, který se věnuje vývojem aplikací pro Joomlu! již několik let. Ten mě za dvě hodinové konzultace nasměroval správným směrem. Od té doby se můj vývoj stal náhle pozitivním a většina dalších kroků probíhala relativně v pořádku. Nejvíce náročná byla implementace tvorby kusovníku a následné využití kusovníků při výrobě produktů. V této části mi nejvíce času zabralo vymyslet princip, jak bude celkový odpočet skladových položek z kusovníku fungovat. Původně mě napadlo řešit problém databázovými TRIGGERY, ale toto řešení by bylo relativně složité. Problém jsem vyřešil získáním korespondujících dat z databáze, která se po porovnání správných klíčů upraví. Další větší komplikací bylo programování Kanbanu, který má za úkol administrátora informovat o stavu skladových zásob barevnými statusy. Každý ze 4 statusů má své speciální nastavení podle počtu tiskáren, který jsme ze skladových zásob schopni vyrobit. Po zvládnutí všech překážek se mi podařilo zhotovit uživatelsky přívětivý a responzivní systém. Tento systém lze lehce pochopit a pro práci s ním není zapotřebí vzdělání v oboru. Systém upozorňuje administrátora barevným přehledem o skladových zásobách. Dále umožňuje výpis veškerých entit a jejich administraci. Díky těmto krokům si myslím, že cíl mé bakalářské práce, byl splněn.
42
6.2 Budoucnost aplikace Skladový systém bude hojně využíván firmou Prusa Research s.r.o.. Nejedná se o konečnou aplikaci, ale o její první verzi. Vývoj na aplikaci bude nadále pokračovat, ať už ze strany firmy Prusa Research s.r.o. nebo ze strany mé. Nyní jsme s firmou domluveni na několika rozšířeních. V obrazovce s naskladněním by se u záznamů měl objevit uživatel, který jako poslední editoval počet skladových položek. Další požadavek ze strany firmy je výpočet nákladové ceny produktu. Tato cena bude zahrnovat pouze cenu součástek. Z mé strany mne napadá několik návrhů na rozšíření. V každé tabulce by se mohl objevit filtr záznamů, který bude vyhledávat záznamy podle zadaného klíčového slova. Toto rozšíření by mohl hlavně ocenit administrátor skladového systému, který bude vyhledávat v tabulkách o stovkách záznamů. Dalším rozšířením může být exportování tabulek do formátů typu .xlsx nebo .pdf. Tyto formáty lze jednoduše vytisknout do papírové formy a mohlo by to být použito při hodnocení výsledků firmy a sledování cash flow. Třetím rozšířením, které mně během vývoje napadlo je implementace administrátorského rozhraní. V tomto rozhraní si budeme moci nastavit několik parametrů pro upřesnění požadované výroby. Konkrétně minimální počet tiskáren, pro které budeme chtít držet skladové položky. Poslední rozšířením by mohlo být rozšíření view supply o ukazatele počtů skladových jednotek do dalšího vyššího statusu.
43
Seznam použité literatury 1. ORLICKY, Joseph. a George. PLOSSL. Orlicky's material requirements planning. 2nd ed. New York: McGraw-Hill, c1994. ISBN 0070504598. 2. ČUJAN, Zdeněk a Zdeněk Málek. Výrobní a obchodní logistika. Zlín: UTB, 2008. 200 s. ISBN 978-80-7318-730-9. 3. Plánování potřeby materiálu. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2014 [cit. 2016-02-15]. Dostupné z: https://cs.wikipedia.org/wiki/Plánování_potřeby_materiálu 4. Operations Management: Chapter 14 - Material Requirements Planning (MRP) and ERP. In: Slideshare [online prezentace]. Prentice Hall, 2008 [cit. 2016-02-22]. Dostupné z: http://www.slideshare.net/RIZWANKHURRAM/heizer-14-15124711 5. Transitioning to Kanban: From Theory to Practice. In: Slideshare [online prezentace]. Orange Park: Software Quality Engineering, 2013 [cit. 2016-03-10]. Dostupné z: http://www.slideshare.net/SQEPresentations/transitioning-to-kanbanfrom-theory-to-practice 6. Kanban, understanding the control system!. In: Arsparafusos [online]. [cit. 2016-0312]. Dostupné z: http://www.arsparafusos.com.br/en_US/kanban-understanding-thecontrol-system/ 7. Content management system (CMS). Techtarget [online]. 2011 [cit. 2016-03-25]. Dostupné z: http://searchsoa.techtarget.com/definition/content-management-system 8. BOIKO, Bob. Content management bible. 2nd ed. Indianapolis, IN: Wiley Pub., 2005. ISBN 0764573713. 9. DEXTER, Mark a Louis LANDRY. Mistrovství v Joomla!: kompletní průvodce vývojáře. Brno: Computer Press, 2013. ISBN 978-80-251-3740-6. 10. About Joomla!. Joomla! [online]. [cit. 2016-04-11]. Dostupné z: https://www.joomla.org/about-joomla.html 11. Version History. Joomla! documentation [online]. 2015 [cit. 2016-04-11]. Dostupné z: https://docs.joomla.org/Category:Version_History
44
12. Model-View-Controller. Joomla! documentation [online]. 2015 [cit. 2016-04-11]. Dostupné z: https://docs.joomla.org/MVC 13. ROCKWAY, Jonathan. Catalyst: accelerating Perl web application development : design, develop, test and deploy applications with the open-source Catalyst MVC framework. Birmingham: Packt Publishing, c2007. ISBN 978-1-84719-095-6. 14. Model-view-controller. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2014 [cit. 2016-04-14]. Dostupné z: https://cs.wikipedia.org/wiki/Model-view-controller 15. Joomla a práce s databází. Redakční systémy [online]. 2009 [cit. 2016-05-01]. Dostupné z: http://www.redakcni-systemy.com/joomla/navody/147-joomla-a-praces-databazi 16. About Node.js. Nodejs [online]. [cit. 2016-05-05]. Dostupné z: https://nodejs.org/en/about/
45
Seznam obrázků Obrázek 1 - Základní schéma techniky MRP. Zdroj [3]................................................. 10 Obrázek 2 - Časové fáze výroby. Zdroj [4] .................................................................... 11 Obrázek 3 - Ukázka vizualizace Kanbanu. Zdroj [6] ..................................................... 12 Obrázek 4 - Přehled struktury MVC. Zdroj [14] ............................................................ 15 Obrázek 5 - Rozvržení komponenty. Zdroj [9]............................................................... 16 Obrázek 6 - Rozvržení modulu. Zdroj [9] ...................................................................... 18 Obrázek 7 - Ukázka stávajícího systému ........................................................................ 23 Obrázek 8 - Ukázka LESS struktury............................................................................... 27 Obrázek 9 - E-R diagram ................................................................................................ 28 Obrázek 10 - Tvorba relace ............................................................................................ 32 Obrázek 11 - Složení komponenty.................................................................................. 33 Obrázek 12 - View dashboard ........................................................................................ 38 Obrázek 13 - View supply .............................................................................................. 39 Obrázek 14 - View boms ................................................................................................ 40 Obrázek 15 - Tvorba kusovníku ..................................................................................... 40
46
Seznam použitých zkratek 1. MRP - Material Requirement Planning (plánování potřeby materiálu) 2. ERP - Enterprise Resource Planning (plánování podnikových zdrojů) 3. WYSIWYG - What You See Is What You Get (co vidíš, to dostaneš) 4. CMS - Content Management Systém (systém pro správu obsahu) 5. CMA - Content Management Application (aplikace pro správu obsahu) 6. CDA - Content Delivery Application (aplikace pro doručování obsahu) 7. IDE - Integrated Development Environment (vývojové prostředí) 8. MVC - Modul View Controller 9. HTML - HyperText Markup Language 10. PHP - HyperText Preprocessor 11. SQL - Search and Query Language
47
Přílohy 1 Obsah přiloženého CD Na přiloženém CD se v kořenovém adresáři nachází tato bakalářská práce ve formátu bakalarska_prace.pdf s návodem na obsluhu aplikace navod.pdf pro obsluhu programu. V návodu bude upřesněna internetová stránka, na které je webová aplikace zprovozněna. Dále přihlašovací údaje a sestava obrázků z aplikace s popisem funkcí systému. Na CD se dále nachází komponenta a šablona připravena k instalaci pro redakční systém Joomla!. Posledním souborem je předpřipravená databáze s vytvořenými tabulkami a testovacími daty, která komponenta využívá.
48
