ˇ ˇ ´ ODBORNA ´ CINNOST ˇ STREDO SKOLSK A
Autonomn´ı sklad elektronick´ ych souˇ c´ astek
Jan Priessnitz
Brno 2015
ˇ ˇ ´ ODBORNA ´ CINNOST ˇ STREDO SKOLSK A ˇ 18. Informatika Obor SOC:
Autonomn´ı sklad elektronick´ ych souˇ c´ astek
Autor:
Jan Priessnitz
ˇ Skola:
Gymn´ azium, Brno, tˇ r´ıda Kapit´ ana Jaroˇ se 14, 658 70 Brno
Brno 2015
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem svou pr´aci vypracoval samostatnˇe, pouˇzil jsem pouze podklady (literaturu, SW atd.) citovan´e v pr´aci a uveden´e v pˇriloˇzen´em seznamu a postup pˇri zpracov´an´ı pr´ace je v souladu se z´akonem ˇc. 121/2000 Sb., o pr´avu autorsk´am, o pr´avech souvisej´ıc´ıch s pr´avem autorsk´ ym a o zmˇenˇe nˇekter´ ych z´akon˚ u (autorsk´ y z´akon) v platn´em znˇen´ı.
V Brnˇe dne: 19. u ´nora 2015
podpis:
Podˇ ekov´ an´ı Dˇekuji Jaroslavu P´aralovi, m´emu ˇskoliteli, za obrovskou pomoc a mnoho uˇziteˇcn´ ych rad ˇ a pˇripom´ınek pˇri pr´aci na SOC. D´ale dˇekuji Domu dˇet´ı a ml´adeˇze Junior za poskytnut´ı z´azem´ı, pˇredevˇs´ım Jakubovi Streitovi a Ing. Jiˇr´ımu V´achovi za rady a pˇripom´ınky. Tato pr´ace byla vypracov´ana za finanˇcn´ı podpory JMK a JCMM.
Anotace Kl´ıˇ cov´ a slova:
Obsah 1 O zaˇ r´ızen´ı
2
2 Struktura a technologie 2.1 Funkce a ˇsk´ala aplikace . . . . . . . . . . 2.2 Struktura aplikace . . . . . . . . . . . . 2.2.1 Architektura MVC . . . . . . . . 2.2.2 Webov´ y frontend (View) . . . . . 2.2.3 Datov´ y model (Model) . . . . . . 2.2.4 Backend (Controller) . . . . . . . 2.2.5 Komunikace mezi ˇca´stmi aplikace 2.3 Pouˇzit´e technologie . . . . . . . . . . . . 2.3.1 Syst´em . . . . . . . . . . . . . . . 2.3.2 Datov´ y model . . . . . . . . . . . 2.3.3 Webov´ y frontend . . . . . . . . . 2.3.4 Automatick´e funkce a komunikace 2.4 Pouˇzit´ y n´avrh . . . . . . . . . . . . . . . 3 Popis datab´ aze 3.1 Seznam tabulek . . 3.1.1 users . . . . 3.1.2 parts . . . . 3.1.3 partitions . 3.1.4 queue . . . 3.1.5 history . . . 3.1.6 stores . . . 3.1.7 parts stores 3.2 Relace . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
4 Popis webov´ eho prostˇ red´ı 4.1 Funkce . . . . . . . . . . . . . 4.1.1 Zmˇena stav˚ u souˇca´stek 4.1.2 Spr´ava pˇrihr´adek . . . 4.1.3 Datab´aze souˇc´astek . . 4.1.4 Datab´aze obchod˚ u . . 4.1.5 Spr´ava uˇzivatel˚ u . . . 4.1.6 Fronta pˇr´ıkaz˚ u. . . . . 4.1.7 Historie pˇr´ıkaz˚ u . . . . 4.2 Uˇzivatelsk´e prostˇred´ı . . . . . 5 Popis daemonu
. . . . . . . . .
. v . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . se zaˇr´ızen´ım . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . pˇrihr´adk´ach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . . . (Doplˇ nov´an´ı souˇc´astek) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . . . . .
2 2 3 3 4 4 4 4 4 4 4 5 5 5
. . . . . . . . .
5 6 6 7 7 7 7 7 7 8
. . . . . . . . .
8 8 9 9 9 9 9 9 9 10 10
´ Uvod C´ıle C´ılem t´eto pr´ace je vytvoˇrit zaˇr´ızen´ı, ve kter´em bude moˇzn´e jednoduˇse skladovat SMD (Solid mounted devices) souˇca´stky. Jeho hlavn´ı funkc´ı by mˇelo b´ yt pˇredevˇs´ım automatick´e vyd´av´an´ı uskladnˇen´ ych souˇca´stek na dan´e povely
Vyuˇ zit´ı
1
O zaˇ r´ızen´ı
2
Struktura a technologie
2.1
Funkce a ˇ sk´ ala aplikace
Abych mohl urˇcit nejlepˇs´ı n´avrh struktury aplikace a technologi´ı, potˇrebuji urˇcit, jak´e funkce bude aplikace m´ıt a s jak´ ymi parametry bude pracovat. Funkce aplikace: • Komunikace s uˇzivatelem pˇres uˇzivatelsky pˇr´ıvˇetiv´e rozhran´ı • Datab´aze souˇca´stek a obchod˚ u • Spr´ava rozloˇzen´ı souˇca´stek • Vyb´ır´an´ı souˇca´stek • Statistiky a historie • Diagnostika zaˇr´ızen´ı • Automatick´e upozornˇen´ı pˇres email Parametry aplikace: • Frekvence pˇr´ıstup˚ u na webov´e rozhran´ı: S velkou rezervou poˇc´ıt´am s t´ım, ˇze to budou maxim´alnˇe des´ıtky pˇr´ıstup˚ u za sekundu. • Frekvence vyb´ır´an´ı souˇca´stek: Ta by mˇela b´ yt do des´ıtek v´ ybˇer˚ u za minutu, protoˇze z´avis´ı na mechanice zaˇr´ızen´ı, kter´a na v´ıc nen´ı konstruov´ana. • Poˇcet souˇca´stek: Poˇcet souˇc´astek v datab´azi by se mˇel pohybovat do tis´ıc˚ u. • Poˇcet pˇrihr´adek: V zaˇr´ızen´ı by mˇelo b´ yt zhruba do sta pˇrihr´adek. To znamen´a, ˇze tam tak´e bude moci b´ yt souˇcasnˇe maxim´alnˇe tolik sdruh˚ u souˇc´astek.
2.2
2.2.1
Struktura aplikace
Architektura MVC
Architektura MVC (Model-View-Controller) je n´avrh aplikace, kter´ y se ji snaˇz´ı rozdˇelit na v´ıce ˇca´st´ı, kter´e spolu co nejm´enˇe souvis´ı. V ide´aln´ım pˇr´ıpadˇe to znamen´a, ˇze budu moci jednu z ˇca´st´ı nahradit, aniˇz bych musel upravovat ostatn´ı ˇca´sti. MVC konkr´etnˇe rozdˇeluje aplikaci na 3 ˇca´sti: • Model - To je ˇc´ast aplikace, kter´a se star´a o ukl´ad´an´ı dat. Ostatn´ı ˇca´sti aplikace pˇres ni pˇristupuj´ı k informac´ım. Dobr´ y model by mˇel poskytovat hlavnˇe jednoduch´ y pˇr´ıstup k dat˚ um, ale tak´e by je mˇel ukl´adat rychle a efektivnˇe a mˇel by b´ yt jednoduˇse rozˇsiˇriteln´ y. • View - View se star´a o prezentov´an´ı dat z´ıskan´ ych od modelu uˇzivateli a zprostˇredkov´an´ı komunikace mezi uˇzivatelem a Controllerem. • Controller - V controlleru se vykon´avaj´ı vˇsechny logick´e operace a pˇr´ıkazy aplikace, kter´e jsou vyvol´any pˇres view a upravuj´ı data pˇres model. Aplikaci jsem se snaˇzil udˇelat tak, aby co nejv´ıce odpov´ıdala t´eto architektuˇre. Proto jsem ji rozdˇelil na 3 ˇc´asti: • Webov´ y frontend (View) • Datov´ y model (Model) • Backend (Controller)
2.2.2
Webov´ y frontend (View)
Jako uˇzivatelskou platformu jsem zvolil web, protoˇze je to snad jedin´e uˇzivatelsky pˇr´ıvˇetiv´e rozhran´ı, kter´e lze spustit vzd´alenˇe. Alternativnˇe by se dala navrhnout specializovan´a klientsk´a aplikace, kter´a by pˇres nˇejak´ y protokol komunikovala se serverovou aplikac´ı, ale to je prakticky stejn´e, jako webov´e rozhran´ı. 2.2.3
Datov´ y model (Model)
Pro ukl´ad´ani dat jsem zvolil datab´azi. Vzhledem k tomu, ˇze data budou pˇrev´aˇznˇe tabulkov´eho charakteru, mysl´ım, ˇze je tato moˇznost nejlepˇs´ı. 2.2.4
Backend (Controller)
Backend bude bˇeˇzet st´ale a jeho hlavn´ım u ´kolem bude zprostˇredkov´avat komunikaci se zaˇr´ızen´ım. Kromˇe toho bude vykon´avat automatick´e funkce programu (napˇr. odes´ıl´an´ı emailov´ ych upozornˇen´ı). 2.2.5
Komunikace mezi ˇ c´ astmi aplikace
Jednotliv´e ˇca´sti aplikace si mezi sebou mus´ı umˇet pˇred´avat data. K tomu slouˇz´ı r˚ uzn´e komunikaˇcn´ı kan´aly. Zde bych chtˇel zm´ınit, ˇze trochu odboˇc´ım od architektury MVC. Zaprv´e budu z webov´eho frontendu pˇr´ımo upravovat data v datab´azi a obejdu t´ım backend. Nav´ıc datab´azi pouˇziji jako komunikaˇcn´ı kan´al mezi webov´ ym frontendem a backendem. Webov´ y frontend takto bude pos´ılat pˇr´ıkazy backendu. Konkr´etnˇe tak, ˇze pˇrid´a ˇra´dek do tabulky pˇr´ıkaz˚ u. Backend se pot´e do tabulky pod´ıv´a a nov´e pˇr´ıkazy obdrˇz´ı. Pro backend je ale n´aroˇcn´e opakovanˇe se d´ıvat do datab´aze pro pˇr´ıkazy. Proto zde bude jeˇstˇe datov´ y stream, do kter´eho bude frontend zapisovat a backend z nˇej ˇc´ıst. Ten bude slouˇzit pro upozornˇen´ı backendu o tom, ˇze je v datab´azi nov´ y pˇr´ıkaz. Samozˇrejmˇe backend bude do datab´aze zapisovat urˇcitˇe stavov´e informace o zaˇr´ızen´ı, kter´e se prom´ıtnou do webov´eho frontendu,.
2.3 2.3.1
Pouˇ zit´ e technologie Syst´ em
Jako hardwarov´e ˇreˇsen´ı pro tuto aplikaci jsem vybral nˇejak´e microPC. Konkr´etnˇe jsem vybral Raspberry Pi, protoˇze je levn´e, mal´e a nem´a velk´e energetick´e n´aroky (okolo 5 W ve ˇspiˇcce). Dalˇs´ı v´ yhodou je, ˇze na Raspberry Pi bˇeˇz´ı Linux, na kter´em je moˇzn´e skoro jak´ ykoli software a pro servery je ide´aln´ı. 2.3.2
Datov´ y model
Aplikace bude muset umˇet dlouhodobˇe ukl´adat nˇekter´a stavov´a data jako napˇr´ıklad aktu´aln´ı rozloˇzen´ı pˇrihr´adek nebo mnoˇzstv´ı souˇca´stek v pˇrihr´adk´ach a dlouhodob´a data jako datab´aze souˇca´stek, obchod˚ u, nebo seznam uˇzivatel˚ u. Asi nejlepˇs´ım ˇreˇsen´ım zde je datab´azov´ y server MySQL, kter´ y je rychl´ y, bezpeˇcn´ y, a jednoduˇse pˇr´ıstupn´ y. Alternativnˇe by se datab´aze dala uloˇzit do souboru (SQLite). To by mohlo b´ yt jednoduˇsˇs´ı na
instalaci, ale vzhledem k tomu, ˇze budu k datab´azi pˇristupovat z r˚ uzn´ ych proces˚ u (PHP skript, daemon), rozhodl jsem se pro datab´azov´ y server. Dalˇs´ı moˇznost´ı je ukl´ad´an´ı dat do soubor˚ u, kdy se d´a k soubor˚ um pˇristupovat pˇr´ımo, nebo pˇres nˇejak´ y klient, avˇsak toto ˇreˇsen´ı zdaleka nen´ı tak bezpeˇcn´e a rychl´e a je tˇeˇzko rozˇsiˇriteln´e nebo upravovateln´e. 2.3.3
Webov´ y frontend
Pro psan´ı webov´eho frontendu jsem pouˇzil dvojici jazyka PHP a frameworku Nette. Toto ˇreˇsen´ı je velice rozˇs´ıˇren´e, bezpeˇcn´e a vcelku rychl´e. Nav´ıc jiˇz s PHP a Nette m´am zkuˇsenosti. Jako webserver jsem vybral Apache, jelikoˇz je tak´e velmi rozˇs´ıˇren´ y a bezpeˇcn´ y. Existuj´ı i rychlejˇs´ı alternativy jako Nginx nebo Lighttpd, kter´e jsou m´enˇe n´aroˇcn´e. Kdyby to bylo potˇreba, nen´ı probl´em Apache vymˇenit za tyto webservery. M´ısto PHP by bylo pˇr´ıpadnˇe moˇzn´e pouˇz´ıt jazyk Java, Python, nebo C++ s jin´ ymi webservery. 2.3.4
Automatick´ e funkce a komunikace se zaˇ r´ızen´ım
Automatick´ ymi funkcemi rozum´ıme takov´e funkce, kter´e se spouˇst´ı nez´avisle na pˇr´ıstupu uˇzivatele na webov´e rozhran´ı. To znamen´a napˇr. pokud zaˇr´ızen´ı ohl´as´ı chybu a aplikace poˇsle spr´avci email o t´eto chybˇe. Toto jsem ˇreˇsil programem, kter´ y se spust´ı po startu Raspberry Pi a po celou dobu kontroluje, zda m´a nˇeco vykonat. Kromˇe toho tak´e program zprostˇredkov´av´a pˇr´ıkazy pro zaˇr´ızen´ı a po celou dobu ˇcek´a na pˇr´ıkazy od zaˇr´ızen´ı. Jako programovac´ı jazyk jsem vybral Python, protoˇze pro nˇej existuj´ı knihovny jednoduˇse zpˇr´ıstupˇ nuj´ıc´ı rozhran´ı GPIO a UART a knihovny pro pˇr´ıstup do MySQL datab´aze. Alternativnˇe jsem pˇrem´ yˇslel o C++, kter´e je rychlejˇs´ı, ale h˚ uˇre se s n´ım pˇristupuje k rozhran´ım GPIO a UART. Pro Python jsem se nakonec rozhodl proto, ˇze program nebude vykon´avat ˇza´dnˇe v´ ypoˇcetnˇe n´aroˇcn´e operace ani velk´e mnoˇzstv´ı poˇzadavk˚ u (viz parametry aplikace), tud´ıˇz rychlost zde nehraje tak velkou roli.
2.4
Pouˇ zit´ y n´ avrh
Koneˇcn´a struktura aplikace se tedy skl´ad´a z tˇechto ˇca´st´ı • MySQL datab´aze • Daemon, kter´ y pos´ıl´a pˇr´ıkazy zaˇr´ızen´ı a s webov´ ym rozhran´ım komunikuje pˇres datab´azi a rouru • Webov´e rozhran´ı
3
Popis datab´ aze
Pro ukl´ad´an´ı dat jsem pouˇzil datab´azov´ y server MySQL.
3.1
Seznam tabulek
Datab´aze bude m´ıt celkem 7 tabulek. • users • parts • partitions • queue • history • stores • parts stores V kaˇzd´e tabulce bude sloupec id s funkc´ı AUTO INCREMENT a prim´arn´ım kl´ıˇcem. V tomto sloupci tedy bude pro kaˇzd´ y ˇra´dek v tabulce unik´atn´ı identifik´ator. D´ıky funkci AUTO INCREMENT se pole id automaticky vypln´ı ˇc´ıslem o 1 vˇetˇs´ım, neˇz id posledn´ıho ˇra´dku. 3.1.1
users
Tato tabulka uchov´av´a informace o uˇzivatel´ıch. Kromˇe sloupce id zde bude sloupec username a password. Ve sloupci username bude uloˇzeno pˇrihlaˇsovac´ı jm´eno uˇzivatele. Ve sloupci password je m´ısto hesla uˇzivatele MD5 suma hesla. Suma je zde kv˚ uli bezpeˇcnosti. Kdyby byla datab´aze napadnuta, u ´toˇcn´ık by sice zjistil MD5 sumu hesla a mohl by se pˇrihl´asit do syst´emu, ale nem˚ uˇze zpˇetnˇe zjistit heslo uˇzivatele a zneuˇz´ıt jej pro pˇr´ıstup na jin´e weby.
3.1.2
parts
Zde je uloˇzena datab´aze souˇca´stek. Kromˇe id je zde dalˇs´ıch 5 sloupc˚ u. Ve sloupci name je uloˇzeno jm´eno souˇca´stky. D´ale jsou ve sloupc´ıch width a length uloˇzeny rozmˇery souˇc´astky. Konkr´etnˇe ˇs´ıˇrka souˇc´astky, jelikoˇz zaˇr´ızen´ı bude m´ıt do budoucna r˚ uznˇe ˇsirok´e pˇrihr´adky a bude podporovat r˚ uznˇe ˇsirok´e souˇca´stky, a d´elka souˇc´astky, coˇz bude parametr potˇrebn´ y pro vyd´an´ı pˇr´ıkazu stˇr´ıhac´ı hlavˇe (kolik pap´ırov´eho p´asku m´a vysunout). 3.1.3
partitions
Tato tabulka slouˇz´ı k uchov´av´an´ı aktu´aln´ıho rozloˇzen´ı pˇrihr´adek. M´a celkem 5 sloupc˚ u (id, position, part, amount, width). Ve sloupci position je uloˇzena neceloˇc´ıseln´a promˇenn´a pozice pˇrihr´adky. Promˇenn´a bude nab´ yvat hodnot mezi 0 (zaˇc´atek kolejnice) a 1 (konec kolejnice). D´ale ve sloupci part je promˇenn´a ukazuj´ıc´ı na id souˇca´stky, kter´a je v pˇrihr´adce. Ve sloupci amount je aktu´aln´ı poˇcet souˇca´stek v pˇrihr´adce. Ve sloupci width je ˇs´ıˇrka ˇıˇrka pˇrihr´adky by se mˇela pˇrihr´adky (do budoucna budou m´ıt pˇrihr´adky r˚ uznou ˇs´ıˇrku). S´ shodovat s ˇs´ıˇrkou souˇc´astky, jinak syst´em pˇri pˇriˇrazov´an´ı souˇca´stky do pˇrihr´adky upozorn´ı uˇzivatele. 3.1.4
queue
Tato tabulka bude slouˇzit ke komunikaci mezi webov´ ym frontendem a daemonem. Bude zde uloˇzena fronta pˇr´ıkaz˚ u vyb´ır´an´ı souˇca´stek. Tabulka m´a celkem 8 sloupc˚ u (id, state, time, user, part, partition, amount a priority). Ve sloupci state bude uloˇzen stav pˇr´ıkazu (hodnota 0 pro ’ˇcek´a’, kladn´e hodnoty pro chybu), ve sloupci time ˇcas a datum zad´an´ı pˇr´ıkazu, ve sloupci user id uˇzivatele, kter´ y pˇr´ıkaz zadal, ve sloupci part id vybran´e souˇc´astky, ve sloupci partition id pˇrihr´adky, ze kter´e se m´a souˇca´stka vybrat a ve sloupci amount mnoˇzstv´ı vyb´ıran´ ych souˇca´stek. Sloupec priority slouˇz´ı k pˇresouv´an´ı pˇr´ıkaz˚ u na zaˇc´atek nebo na konec fronty (zaˇr´ızen´ı bude nejdˇr´ıve zpracov´avat pˇr´ıkazy s vyˇsˇs´ı prioritou). 3.1.5
history
Zde bude uloˇzena historie pˇr´ıkaz˚ u. Tabulka m´a stejnou strukturu, jako tabulka queue, ale budou zde uloˇzeny jen jiˇz vykonan´e pˇr´ıkazy a probˇehl´e chyby. Pot´e, co zaˇr´ızen´ı vykon´a pˇr´ıkaz, daemon zkop´ıruje ˇr´adek z tabulky queue do tabulky history, zmˇen´ı promˇennou state (na -1, pokud pˇr´ıkaz probˇehl v poˇra´dku, nebo kladn´e ˇc´ıslo, pokud nastala chyba) a smaˇze ˇra´dek z tabulky queue. 3.1.6
stores
V t´eto tabulce bude uloˇzena datab´aze obchod˚ u. Bude zde uloˇzeno jm´eno obchodu a webov´a adresa. 3.1.7
parts stores
Jelikoˇz kaˇzd´a souˇca´stka m˚ uˇze b´ yt dostupn´a ve v´ıce obchodech a v jednom obchodˇe m˚ uˇze b´ yt v´ıce souˇc´astek, je potˇreba vytvoˇrit jeˇstˇe jednu tabulku relac´ı mezi tabulkami parts
a stores (Many to Many relation). Tabulka m´a celkem 4 sloupce (id, part, store, url). V part a store jsou id souˇc´astky a obchodu. D´ale je zde sloupec url, kde je uloˇzena webov´a adresa souˇca´stky v dan´em obchodˇe.
3.2
Relace
V tabulk´ach se ˇcasto objevuj´ı odkazy na z´aznamy v jin´ ych tabulk´ach pomoc´ı id. Do datab´aze m˚ uˇzeme informaci o relac´ıch mezi tabulkami zadat. Tyto informace vyuˇz´ıv´a datab´aze pro vylepˇsen´ı efektivity a rovnˇeˇz Nette framework, kter´ y um´ı automaticky pomoc´ı relace odk´azat na c´ılov´ y z´aznam v jin´e tabulce. V datab´azi jsem vytvoˇril tyto relace: • partitions.part → parts.id • queue.user → users.id • queue.part → parts.id • queue.partition → partitions.id • history.user → users.id • history.part → parts.id • history.partition → partitions.id
4 4.1
Popis webov´ eho prostˇ red´ı Funkce
Pˇredn´ı funkc´ı webu bude navolen´ı a souˇca´stek a zaˇrazen´ı jich do fronty na vybr´an´ı. Web bude m´ıt ale kromˇe vyd´av´an´ı souˇca´stek jeˇstˇe nˇekolik dalˇs´ıch praktick´ ych funkc´ı, kter´e bude moci vykon´avat nez´avisle na zaˇr´ızen´ı.
4.1.1
Zmˇ ena stav˚ u souˇ c´ astek v pˇ rihr´ adk´ ach (Doplˇ nov´ an´ı souˇ c´ astek)
Web bude umˇet zobrazit mnoˇzstv´ı souˇca´stek v jednotliv´ ych pˇrihr´adk´ach v pˇrehledn´e tabulce. Tuto tabulku bude moci uˇzivatel mˇenit (a s n´ı i hodnoty v datab´azi), kdyˇz napˇr´ıklad doplˇ nuje souˇca´stky. 4.1.2
Spr´ ava pˇ rihr´ adek
Uˇzivatel bude moci jednoduˇse zmˇenit typy souˇc´astek v jednotliv´ ych pˇrihr´adk´ach a mˇenit jejich polohu. 4.1.3
Datab´ aze souˇ c´ astek
Jakmile uˇzivatel pˇrid´a nˇejakou souˇca´stku, uloˇz´ı se do datab´aze jej´ı jm´eno, obr´azek a popis. Kromˇe toho se uloˇz´ı tak´e ˇs´ıˇrka a d´elka, coˇz jsou hodnoty potˇrebn´e pro zaˇr´ızen´ı. V´ yhledovˇe budou v datab´azi uloˇzeny i vlastnosti souˇca´stky a uˇzivatel si bude moci vybrat souˇc´astku jednoduˇse podle vlastnost´ı. 4.1.4
Datab´ aze obchod˚ u
Pro vˇsechny souˇca´stky v datab´azi bude moˇznost uloˇzit i odkazy na webov´e str´anky souˇc´astek v obchodech s elektronikou, takˇze uˇzivatel si uˇzivatel bude moci rychle vybrat, kde souˇc´astku nakoup´ı, bez zbyteˇcn´eho hled´an´ı. Do budoucna poˇc´ıt´am i s implementac´ı API nˇekter´ ych obchod˚ u do aplikace. Aplikace tak bude moci napˇr. automaticky upozornit uˇzivatele, ˇze nˇejak´a souˇc´astka doch´az´ı a odk´aˇze ho na obchod s nejniˇzˇs´ı cenou. 4.1.5
Spr´ ava uˇ zivatel˚ u
Uˇzivatel´e budou m´ıt r˚ uzn´a pˇr´ıstupov´a pr´ava a ti s vyˇsˇs´ımi pˇr´ıstupov´ ymi pr´avy budou moci vytvoˇrit nov´ y uˇzivatelsk´ y uˇcet, nebo zmˇenit nebo smazat jiˇz existuj´ıc´ı s niˇzˇs´ımi pr´avy. 4.1.6
Fronta pˇ r´ıkaz˚ u
Web bude umˇet zobrazit frontu vˇsech pˇr´ıkaz˚ u v tabulce. Uˇzivatel bude pot´e moci pˇr´ıkaz smazat, nebo jej posunout ve frontˇe. Pokud nastane chyba, uˇzivatel se z tabulky dozv´ı, jak´ y pˇrikaz chybu zp˚ usobil a bude moci zkusit pˇr´ıkaz prov´est znovu, nebo jej pˇreskoˇcit. 4.1.7
Historie pˇ r´ıkaz˚ u
Po proveden´ı pˇr´ıkazu se ˇra´dek v datab´azi v tabulce fronty pˇr´ıkaz˚ u pˇresune do tabulky historie. Uˇzivatel si na webu bude moci prohl´ednout historii pˇr´ıkaz˚ u ve zvolen´em ˇcasov´em u ´seku.
4.2
5
Uˇ zivatelsk´ e prostˇ red´ı
Popis daemonu
Z´ avˇ er
