Get documents about "bp
Document Sample
MASARYKOVA UNIVERZITA
FAKULTA INFORMATIKY
Systém pre evidenciu skladu
a predaj drobného tovaru a služieb
BAKALÁRSKA PRÁCA
Lukáš Pitoňák
Brno, jeseň 2007
Prehlásenie
Prehlasujem, že táto bakalárska práca je mojim pôvodným autorským dielom, ktoré som
vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní
používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na prís-
lušný zdroj.
Vedúci práce: Mgr. Zdeněk Machač
ii
Poďakovanie
R{d by som poďakoval vedúcemu tejto práce, Mgr. Zdeňkovi Machačovi, za jeho rady
a smerovanie v oblasti objektového návrhu a za ochotu pri riešení problémov s platfor-
mou Java Enterprise Edition. Veľk{ vďaka patrí aj mojej rodine a priateľom za podporu,
bez ktorej by bola práca o mnoho ťažšia.
iii
Zhrnutie
Už niekoľko rokov sa v Celouniverzitnej počítačovej študovni Masarykovej univerzity
používa aplikácia podporujúca predaj drobného tovaru a služieb, ktor{ sa len m{lo pri-
spôsobovala meniacemu sa prostrediu. Cieľom tejto bakal{rskej pr{ce je vykonať analýzu
prostredia drobného predaja, pochopiť potreby univerzity a vytvoriť z{klad aplik{cie,
ktor{ umožní drobný predaj na nez{vislých predajných miestach.
iv
Kľúčové slová
Enterprise Java Beans, Java Persistence API, Java Enterprise Edition, trojvrstvová archi-
tektúra, dátový model, vedenie skladu, predaj
v
Obsah
1 Úvod ............................................................................................................................................ 1
1.1 Súčasný stav v CPS ............................................................................................................ 1
1.2 Cieľ pr{ce ............................................................................................................................. 1
2 Použité technológie .................................................................................................................. 3
2.1 Trojvrstvová architektúra .................................................................................................. 3
2.2 Java Enterprise Edition 5 .................................................................................................... 4
2.2.1 Java Persistence API .................................................................................................... 5
2.2.1.1 Manipulácia s entitami ....................................................................................... 5
2.2.1.2 Java Persistence Query Langauge ..................................................................... 8
2.2.2 Enterprise Java Beans ................................................................................................. 8
2.2.2.1 Session beans......................................................................................................... 9
3 Požiadavky na systém ............................................................................................................ 10
3.1 Prostredie nasadenia systému ........................................................................................ 10
3.2 Funkčné požiadavky ........................................................................................................ 10
4 Dátová vrstva ........................................................................................................................... 14
4.1 Konceptuálny model ........................................................................................................ 14
4.2 Logický model .................................................................................................................. 17
4.3 Entitné triedy .................................................................................................................... 19
5 Aplikačná vrstva ...................................................................................................................... 21
5.1 Komponent skladu ........................................................................................................... 22
5.2 Komponent obchodu ....................................................................................................... 23
5.3 Komunikácia medzi komponentmi, ich použitie a limity .......................................... 24
6 Záver .......................................................................................................................................... 25
6.1 Zhodnotenie výsledkov ................................................................................................... 25
6.2 Čo bude nasledovať ......................................................................................................... 26
6.3 Technologická poznámka ................................................................................................ 26
Literatúra ........................................................................................................................................ 28
vi
A Ukážka konfiguračného súboru ........................................................................................... 29
B Logický dátový model ............................................................................................................ 30
C Webový klient .......................................................................................................................... 31
D Obsah priloženého CD .......................................................................................................... 35
vii
1 Úvod
Masarykova univerzita (MU) ponúka svojim študentom od roku 2000 služby Celouni-
verzitnej počítačovej študovne (CPS). Tým podporuje dostupnosť výpočtovej techniky,
sieťových informačných zdrojov a umožňuje študentom vykon{vať administratívu spoje-
nú so štúdiom prostredníctvom študijného informačnému systému IS MU. V študovni sa
osvedčil aj predaj drobného tovaru a služieb, ale z dôvodov, ktoré budú popísané v nas-
ledujúcej kapitole, nie je súčasný stav uspokojivý. T{to pr{ca si kladie za cieľ vytvoriť
základ nového systému na podporu skladu a predaja, ktorý vyrieši súčasné problémy
a umožní univerzite rozšíriť ponuku služieb.
1. 1 Súčasný stav v CPS
Pre podporu predaja je v CPS už niekoľko rokov používaný software kúpený od exter-
ného dod{vateľa, ktorý v poslednej dobe prejavuje nevôľu software prispôsobovať menia-
cemu sa prostrediu a požiadavk{m. Kvôli tomu sa postupom času nakumulovali prob-
lémy rôzneho charakteru:
Nedostatočn{ funkcionalita – systém umožňuje len veľmi chabú podporu predaja
na viacerých a nezávislých miestach.
Systém neposkytuje prehľadové zostavy. Pre získanie prehľadu o okolnostiach
predaja musia pracovníci CPS používať dopyty jazyka SQL.
Systém nepodporuje evidenciu skladu, kontroly z{sob prebiehajú „len“ vizu{lne.
Dôsledkom neevidovania zásob je aj absencia záznamov (v rozsahu predajného
systému) o tovare, ktorý bol použitý pre interné účely študovne.
Grafický klient, používaný pri predaji je nevyhovujúci, pretože obsahuje prvky,
ktoré sa v dnešnej dobe už nevyužívajú.
Pre plnú funkcionalitu bežného chodu obchodu nestačí grafický klient. Niektoré
úkony (napr. správa typov tovaru) sa musia vykon{vať cez webové rozhranie.
Vymenované problémy sú dostatočným dôvodom k vzniku nového systému,
z veľkej časti sú jeho inšpir{ciou. Viac informácií o CPS je možné n{jsť na [CPS1].
1.2 Cieľ práce
Hlavný cieľ bakalárskej práce je vytvoriť aplikačnú a dátovú vrstvu systému, ktorý pod-
porí drobný predaj tovaru a služieb v prostredí počítačových študovní MU. Prev{dzkova-
teľom a správcom systému, vrátane webového a grafického klienta, bude Ústav výpočetní
1
techniky MU, preto je žiaduce, aby bol systém integrovateľný do intranetového infor-
mačného systému Inet MU.
Z funkčného hľadiska m{ systém umožniť existenciu viacerých nez{vislých predaj-
ných miest, čo podmieňuje podporu evidencie nezávislých skladov. Platby za tovar
a poskytnuté služby majú byť realizované pomocou Systému úhrad pohledávek za oso-
bami Masarykovi univerzity (SUPO MU) [SUPO2], ktorý je tiež integrovaný do systému
Inet MU.
Z technologického hľadiska je vhodné, aby bol systém zimplementovaný v jazyku
Java a fungoval na Java Enterprise Edition serveri BEA WebLogic a databázovom stroji
Oracle (podobne ako partnerské systémy).
Pre splnenie hlavného cieľa pr{ce je potrebné učiniť nasledujúce úkony:
1. Vykonať analýzu problematiky a špecifikovať požiadavky na systém.
2. Navrhnúť d{tové štruktúry pre uchov{vanie a poskytovanie informácií o okolnos-
tiach predaja.
3. Navrhnúť a zimplementovať aplikačné rozhranie systému (Application Progra-
mming Interface, API), ktoré umožní uskutočňovať platby prostredníctvom SUPO
účtu nakupujúceho.
4. Otestovať zimplementované rozhranie.
Výstup tejto bakal{rskej pr{ce bude serverov{ časť systému, ktorého spustenie
v CPS je plánované na jar roku 2008.
Nasledujúce kapitoly v skratke predstavia čitateľovi použité technológie, popíšu
jednotlivé etapy vývoja systému a zhodnotia prácu ako celok.
2
2 Použité technológie
2.1 Trojvrstvová architektúra
Trojvrstvová architektúra [MULTI3] je typ klient-server architektúry, ktorého hlavnou
myšlienkou je oddelenie prezent{cie, spracovania a uchovávania dát.
Prezentačn{ vrstva je rozhranie systému určené pre komunik{ciu s koncovým uží-
vateľom. Jeho úlohou je zber a prezentácia dát v užívateľsky príjemnej a prehľadnej for-
me. Komunikuje s vrstvou označovanou ako logick{, aplikačn{, či biznis logika. T{to je
prostredníkom medzi uchovávanými a prezentačnými d{tami – transformuje užívateľské
požiadavky na akcie vykon{vané nad d{tovou vrstvou, ktorá dáta poskytuje a uchováva
typicky v relačnej datab{ze.
Systém pre evidenciu skladu a drobný predaj tovaru a služieb bude trojvrstvová
aplikácia. Zn{zorňuje ho obr{zok 2.1.
Obrázok 2.1
Grafický klient je samostatná Jave Standard Edition aplikácia, ktorá komunikuje s Java
Enterprise Edition serverom po sieti.
Aplikačný server je Java Enterprise Edition server (Bea WebLogic).
Aplikačná vrstva je reprezentovaná Enterprise Java Beans 3.0 komponentmi a ďalšími ob-
jektmi.
DB server je databázový server Oracle 10.x.
3
2.2 Java Enterprise Edition 5
Java Enterprise Edition 5 (Java EE) je platforma pre vývoj prenositeľných, rozšíriteľných,
robustných a šk{lovateľných aplik{cií v jazyku Java. Rozširuje platformu Java Standard
Edition (Java SE) o podporu tvorby webových aplikácií a služieb, distribuovaných viac-
vrstvových aplikácií s cieľom zjednodušenia vývoja.
Veľkým prínosom oproti predch{dzajúcim verzi{m je používanie anot{cií zavede-
ných v Jave SE 5.0. Vďaka tomu je možné prestať používať tzv. deployment descriptors1
vo formáte XML a konfiguračné d{ta vkladať priamo do zdrojového kódu. Java EE server
je schopný tieto informácie rovnocenne interpretovať, čo rieši problém synchroniz{cie
popisu a programového kódu komponentov. Vyhľad{vanie a vytváranie zdrojov (webové
služby, spojenie do databázy, atď.) poskytovaných serverom je pri používaní anot{cií
jednoduchšie, pretože anot{cie zapuzdrujú2 požadovanú funkcionalitu.
Správanie sa jednotlivých komponentov v Java EE systémoch je konfigurovateľné
popismi vo form{te XML alebo anot{ciami. Väčšina popisov m{ svoje predvolené hod-
noty (vhodné pre obvyklé použitie), a preto nemusia byť v zdrojovom kóde či konfigurač-
nom súbore explicitne uvádzané. Tento prístup ku konfigurácii sa nazýva konfigurácia
výnimkami (configuration by exception), pretože je nutné používať popisy len v neštan-
dardných, výnimočných situ{ci{ch. Jednou z výhod je sprehľadnenie zdrojového kódu.
Súčasťou Javy EE je aj technológia Enterprise Java Beans (EJB). Vo verzii 3.0 je opäť
zjednodušen{ a sprehľadnen{. Entitné EJB z predchádzajúcej verzie sú nahradené obyčaj-
nými triedami, ktoré môžu byť popísané anotáciami alebo XML súborom. EJB kompo-
nenty primárne zapuzdrujú biznis logiku distribuovaných viacvrstvových aplikácií. K ich
funkcionalite (metódam) pristupujú vzdialení klienti transparentne3.
Do platformy Java EE pribudlo Java Persistence API (JPA), ktoré je vo verzii 1.0
súčasťou špecifik{cie EJB 3.0. Je to štandard, ktorého implement{cia zaisťuje perzistenciu
(trvalosť) d{t prostredníctvom objektovo relačného mapovania (ORM). Využívať sa d{ aj
v prostredí samostatných (stand alone) aplikácií, pretože jeho fungovanie nie je podmie-
nené prítomnosťou Java EE servera.
Súčasťou platformy Java EE je mnoho ďalších technológií, ktorými sa t{to pr{ca
nezaober{, pretože pri implement{cii systému neboli použité. Jedn{ sa najmä o tech-
nológie používané pri vývoji webových aplikácií. Kompletný prehľad sa d{ získať na
[JAVAEE4].
1 Konfigurujú umiestnenie aplikácie a jej prostredie na Java EE serveri.
2 Zapuzdrovať funkcionalitu znamen{ funkcionalitu poskytovať, ale z{roveň skrývať spôsob, kto-
rým je dosiahnutá.
3 Inštancia EJB vznikne skryto, manipuluje sa s ňou ako s lokálnym zdrojom, ale výpočty prebieha-
jú na aplikačnom serveri.
4
2.2.1 Java Persistence API
Kompletn{ špecifik{cia tohto štandardu je popísan{ v [JSR5]. Najrozšírenejšie imple-
ment{cie sú: OpenJPA, KODO (komerčn{ verzia OpenJPA, je súčasťou serveru BEA
WebLogic), JPOX, Hibernate a TopLink. Nasledujúce kapitoly popíšu z{kladnú funk-
cionalitu a charakteristiky JPA, ale nebudú sa vždy zaoberať konkrétnymi implemen-
tačnými ot{zkami.
2.2.1.1 Manipulácia s entitami
Entitné triedy patria do skupiny objektov označovaných skratkou POJO4, reprezentujú
entity v objektovom prostredí. Chápané sú podobne ako entity v relačných datab{zach:
entitn{ trieda je popisom entity, predstavuje jej predpis, tabuľku v datab{ze. Inštancie
týchto tried reprezentujú riadky tabuliek [EJB9].
Sú to triedy spĺňajúce nasledujúce kritéria:
Anotované sú pomocou javax.persistence.Entity, alebo sú v XML popise označené
ako entita.
Pre prenositeľnosť entít je doporučené, aby triedy neboli finálne. Niektoré imple-
mentácie JPA sprostredkov{vajú funkčnosť entitných tried pomocou ich potom-
kov.
Poskytujú verejný (public), alebo chránený (protected) bezparametrický konštruk-
tor.
Majú špecifikovaný prim{rny kľúč (anot{ciou, z{znamom XML, alebo ho zdedia),
ktorý je buď jednoduchý, alebo zložený z viacero atribútov.
Ak implementujú rozhranie java.io.Serializable, môžu byť používané vzdialene
(serializujú sa do prúdu bytov a prenesú cez HTTP po počítačovej sieti).
Jednoduchosť používania entitných tried spočíva v minimalizácii popisov vo for-
máte XML a v častom používaní predvolených hodnôt anot{cií.
Nasledujúce dva zápisy triedy Osoba sú si navzájom ekvivalentné:
4Skratka termínu Plain Old Java Object, ktorý zaviedli M. Fowler, R. Parsons a J. MacKenzie
v roku 2000, sa používa pre zdôraznenie faktu, že objekt nie je zložitý (nemusí implementovať
komplikované rozhranie, prípadne byť potomkom inej triedy), ale skôr jednoduchý, bežný.
5
Anot{cie sa používajú aj na definovanie rel{cií medzi entitami. Pre väzbu kardinality 1 : 1
je určen{ anot{cia @OneToOne, analogicky sa používajú zvyšné @OneToMany,
@ManyToOne, @ManyToMany. Entity môžu poskytovať metódy vracajúce objekty,
s ktorými sú v relácii. Nasledujúci príklad ilustruje jednoduchý prístup k takýmto dátam.
6
Inštancie entitných tried môžu po svojom vzniku existovať v troch stavoch: spravo-
vaná (managed), oddelená (detached) a odstránená (removed). Povolené prechody medzi
stavmi sú znázornené na obrázku 2.2 [ORA6].
Obrázok 2.2
Kontext perzistencie (persistence context) je množina spravovaných inštancií entít,
v ktorej existuje pr{ve jedna unik{tna inštancia pre jeden výskyt identity perzistentnej
entity [EJB9]. Entity, ktoré patria do kontextu, sú vrátane svojich stavov spravované
objektom javax.persistence.EntityManager.
Informáciu o spôsobe umiestnenia entitných tried na aplikačný server Java EE nesie
súbor persistence.xml, ktorý špecifikuje aj implementáciu JPA a kontext perzistencie.
Uk{žka takého súboru je v prílohe A.
Základné operácie nad entitnými triedami vykonáva objekt EntityManager. Niektoré
z nich sú:
EntityManager.persist(instanciaEntity); Inštancia je pridan{ do kontextu a stane sa
spravovanou.
EntityManager.merge(instanciaEntity); Ak sa inštancia entity už nach{dza v kon-
texte, hodnoty jej atribútov sa zaktualizujú. Inak sa inštancia prid{ do kontextu
a stane sa spravovanou.
EntityManager.remove(instanciaEntity); Inštancia entity sa odstr{ni z kontextu a tým
aj z databázy.
EntityManager.find(entitnaTrieda, primarnyKluc); Ak existuje inštancia zadaného
typu, majúca daný prim{rny kľúč, je vr{ten{ ako n{vratov{ hodnota, inak je vr{-
tená hodnota null.
7
EntityManager.createNamedQuery(nazovDopytu); Vytvorí inštanciu dopytu jazyka
Java Persistence Query Language (JPQL).
JPA je nový, ale silný n{stroj. Tým, že d{ta v relačnej datab{ze transformuje na ob-
jekty a ponúka nad nimi z{kladné oper{cie, môže zjednodušiť a tiež urýchliť implement{-
ciu dátovej vrstvy systému. Odbremení programátora od vytvárania databázy v pros-
trediach rozličných datab{zových strojov od rôznych výrobcov a od mapovania data-
b{zových tabuliek na objekty. Umožňuje rýchly presun d{tovej vrstvy systému medzi
datab{zovými servermi a strojmi (čo je súčasťou asi každého vývoja). Najdôležitejším
prínosom však je, že inštancie entitných tried reprezentujú d{ta uložené v relačnej data-
b{ze ako štandardné objekty jazyka Java, čo je takmer nevyhnutným z{kladom najkomp-
likovanejšej vrstvy rozsiahlych systémov – metód aplikačnej logiky. Podrobný popis
manipulácie s entitami je v [JPA7].
2.2.1.2 Java Persistence Query Language
JPQL je náhrada za EJB Query Language predstaveného v EJB 2.0. Je to dopytovací jazyk
navrhnutý na kombinovanie syntaxe a sémantiky SQL a objektovo orientovaných výrazov
[EJB10]. Je označovaný za prenositeľný, pretože ho JPA dok{že vykonať nad väčšinou
bežných datab{zových serverov. Nie je citlivý na veľkosť písma, okrem n{zvov entít a ich
atribútov.
Existujú štyri typy dopytov:
Výberový (SELECT) slúži na výber perzistentných d{t majúcich nejaké spoločné
vlastnosti.
Agregačný (AGGREGATE) je druh výberového dopytu, ktorý obsahuje použitie
klauzule GROUP BY, alebo agregačnej funkcie (MIN, MAX, AVG, COUNT, SUM).
Aktualizačný (UPDATE) sa používa na úpravu existujúcich inštancií entít.
Mazací (DELETE) odstraňuje existujúce výskyty entít.
JPQL je prirodzenou súčasťou JPA, pretože pristupuje k relačným d{tam objektovo.
Parameter dopytu môže byť objekt, prípadne pole objektu (instanciaObjektu.pole) a návra-
tov{ hodnota je zoznam objektov (napr. entít), prípadne jeden objekt, či hodnota primi-
tívneho dátového typu.
2.2.2 Enterprise Java Beans
EJB je architektúra pre vývoj komponentovo založených a transakčne orientovaných
pokročilých (enterprise) aplik{cií. Podľa špecifik{cie [EJB8] sú EJB určené na implement{-
ciu serverovej časti (back-end), ale pre tvorbu užívateľského rozhrania (front-end) vhodné
nie sú.
Architektúra EJB 3.0 prin{ša tri z{kladné stavebné prvky aplikačnej logiky:
Session beans, ktoré vykonávajú operácie biznis logiky a riadia transakcie.
Message-driven beans (MDBs) reagujú na udalosti, typicky externých systémov.
8
Entity reprezentujú dáta. Viď 2.2.1.1 Manipulácia s entitami.
Nasledujúca kapitola načrtne z{kladné charakteristiky session beans. MDBs nebudú
popísané podrobnejšie, pretože neboli použité pri implement{cii systému.
2.2.2.1 Session beans
Session beans (SBs) sú komponenty, ktoré zapuzdrujú biznis logiku aplikácií – ich rozhra-
nie. Podľa [EJB9] sú najčastejšie používané na modelovanie prípadov užitia, prípadne
reprezentujú funkcionalitu určitého typu. Určené sú na implement{ciu aplikačnej vrstvy
pokročilých viacvrstvových aplikácií, fungujú v prostredí Java EE servera v EJB kontaj-
neri.
Session bean (SB) implementuje5 aspoň jedno z rozhraní:
Lokálne rozhranie, pomocou ktorého sa vyhľad{va a používa inštancia SB v rámci
virtuálneho stroja (Java Virtual Machine), na ktorom funguje aplikačný server
s aplik{ciou, ktorej súčasťou je SB. Typicky sa lok{lne rozhrania používajú na ko-
munikáciu medzi SBs jednej pokročilej aplik{cie, či pri tvorbe webových aplikácií.
Vzdialené rozhranie, pomocou ktorého sa SB používa vzdialene – dáta sa seriali-
zujú do prúdu bytov a prenesú na iný virtuálny stroj, ako je umiestnený aplikačný
server. K SB tak najčastejšie pristupuje vzdialený klient, či iný systém cez počíta-
čovú sieť.
SBs sú dvoch typov:
Stavové (statefull SB) majú definované stavy (napr. vyjadrujúce následky klient-
ských akcií), ktoré ovplyvňujú fungovanie SB.
Bezstavové (stateless SB) sú jednoduchšie, nemajú stavy.
Technológia EJB 3.0 je vhodná na implementáciu systému pre drobný predaj. Plne
sa využije funkcionalita Java Transaction API6, riadenie životného cyklu entít a session
beans EJB kontajnerom, vzdialené používanie zdrojov apod. Pri implementácii systému
stačí použiť bezstavové SB.
5 Implementovať rozhranie znamen{ poskytovať funkcionalitu predpísanú rozhraním.
6 API, ktoré umožňuje riadenie a reťazenie transakcií a úrovni aplikačnej logiky.
9
3 Požiadavky na systém
Jedným z problémov v počiatočných f{zach vývoja rozsiahlejších systémov býva špe-
cifikácia zadania. O systéme pre predaj tovaru a služieb na MU sa síce ned{ tvrdiť, že je to
systém veľmi rozsiahly a komplikovaný, ale rozhodne to nie je jednoduchá aplikácia, kto-
rej vývoj je priamočiary a nevyžaduje si hlbšieho zamyslenia.
Špecifik{cia zadania exaktne popisuje systém, ktorý m{ vzniknúť. Kladie si za cieľ
zmapovať prostredie, do ktorého bude systém nasadený, popísať d{ta, ktorými sa systém
bude zaoberať, a nakoniec pochopiť procesy, ktoré v oblasti záujmu prebiehajú a mani-
pulujú s dátami. Výstupom analýzy problematiky drobného predaja na MU bude špecifi-
kácia systému, ktorý bude predaj zabezpečovať.
V posledných desaťročiach sa pri vývoji softwaru uk{zalo, že najkomplikovanejšie
(a preto aj najdrahšie) je opravovanie chýb vzniknutých pri analýze, preto bude na túto
časť pr{ce kladený patričný dôraz.
3.1 Prostredie nasadenia systému
Systém bude používaný výhradne na pôde MU, v prostredí počítačových študovní, kniž-
níc apod. Vďaka modernému technickému vybaveniu univerzity, vr{tane spoľahlivej
a rýchlej počítačovej siete a veľkej serverovej z{kladni je možné, aby bol systém distri-
buovanou aplikáciou. V praxi to znamen{, že aplikačný server, datab{zový server a klien-
ti systému (napr. pokladňa) budú navz{jom prepojení počítačovou sieťou rozsahu WAN7.
Predaj tovaru, podobne ako spr{va jednotlivých predajných miest, bude môcť prebiehať
paralelne a on-line.
Keďže m{ byť systém predaja integrovaný s informačným systémom Inet MU, je
najvýhodnejšie technologicky sa prispôsobiť – vyvinúť systém v jazyku Java a dáta ukla-
dať do datab{zy Oracle.
Inet MU spad{ medzi pokročilé Java EE aplik{cie, preto je pre jeho fungovanie po-
trebný aplikačný server, konkrétne BEA WebLogic.
3.2 Funkčné požiadavky
Hlavnou úlohou zoznamu funkčných požiadaviek je vymedzenie funkcionality, schop-
ností systému. Vznikol na základe skúmania doteraz používanej aplik{cie, okolností pre-
7Wide Area Network je počítačov{ sieť, ktor{ sp{ja niekoľko menších lok{lnych sietí typicky na
území mesta, či regiónu.
10
daja, predpokladaného vývoja situácie na MU a série rozhovorov vedených s predajcami
a vedúcimi pracovníkmi CPS a týmom SUPO.
Uvedené požiadavky sú rôzneho charakteru a líšia sa aj mierou abstrakcie, preto ne-
budú všetky riešené na úrovni aplikačnej vrstvy (API nebude poskytovať príslušné me-
tódy), ale v prezentačnej vrstve systému. V takom prípade API poskytne dáta, ktoré sa
v prezentačnej vrstve dodatočne spracujú.
Na MU existuje viacero počítačových študovní a knižníc, pričom ich počet sa bude
s najväčšou pravdepodobnosťou zvyšovať. Navštevované sú z podobných dôvodov ako
CPS, preto je možné, že služby drobného predaja by našli svojich z{kazníkov aj tu.
Z tohto dôvodu je potrebné, aby nový systém poskytoval funkcionalitu niekoľkých obcho-
dov s nezávislými skladmi (rôzne ceny a druhy tovaru) a zamestnancami (vrátane opráv-
není).
Funkčné požiadavky, spoločné pre každý obchod, sú:
1. Vytvorenie a editácia typu (druhu) tovaru.
2. Výpis typov tovaru.
3. Založenie a edit{cia predajného miesta (k predajnému miestu prin{leží pr{ve je-
den sklad a niekoľko pokladní).
4. Pridanie tovaru (naskladnenie) známeho typu na predajné miesto.
5. Vyskladnenie tovaru pre interné účely predajného miesta. Súčasťou takého vy-
skladnenia je aj textový popis – odôvodnenie.
6. Poznať aktu{lny stav skladu – zistiť koľko kusov akého tovaru je na sklade.
7. Možnosť zak{zať predaj tovaru určitého typu na danom sklade.
8. Možnosť nastavenia rôznych cien pre tovar rovnakého typu na rôznych skladoch.
9. Identifik{cia klienta prebieha pomocou čítačky študentských a zamestnaneckých
kariet – klienti sú len študenti a zamestnanci MU. Vo výnimočných prípadoch sa
klienti môžu identifikovať univerzitným číslom osoby (UČO).
10. Autorizácia klienta k nakupovaniu: Klient je opr{vnený nakupovať, ak je jeho
SUPO účet aktívny a jeho disponibilný zostatok je nenulový.
11. Pri n{kupe zobrazovať inform{cie o disponibilnom zostatku SUPO účtu klienta:
Ak je zostatok menší ako 100 korún, je povolené zobraziť presnú hodnotu zos-
tatku. Inak vracať inform{ciu o tom, či je zostatok dostatočný na uskutočnenie pre-
daja zvoleného tovaru, alebo nie.
12. Poskytovať funkciu virtu{lneho n{kupného košíka typickú pre internetové ob-
chody.
1. Prid{vanie tovaru do košíka.
2. Odoberanie tovaru z košíka.
3. Pri každej manipul{cii s obsahom košíka overiť a zobraziť inform{ciu o:
i. Dostupnosti tovaru na sklade.
11
ii. Bod 11.
13. Uskutočniť predaj. Pred{vať sa smie len autorizovaným klientom, viď bod 10. Us-
kutočnenie predaja pozost{va z nasledujúcich úkonov (pri prvých dvoch bodoch
sa vyžaduje atomickosť zlyhania8):
1. Vyskladnenie tovaru (podľa obsahu virtu{lneho n{kupného košíku) zo
skladu a predanie klientovi.
2. Vykonať zr{žku zo SUPO účtu v hodnote predaného tovaru.
3. Voliteľn{ tlač účtenky.
14. Správa obsluhy: Vytváranie a rušenie užívateľov systému a prideľovanie ich pr{v.
15. Poskytovať prehľadové zostavy pre tlač (vo form{te PDF):
1. Prehľad typov tovaru radený podľa výskytu na skladoch.
2. História naskladňovania a vyskladňovania tovaru v danom časovom inter-
vale.
3. Prehľad aktu{lneho stavu tovaru daného skladu.
4. Prehľad predaného tovaru (vr{tane klientov) v danom časovom intervale
na danom predajnom mieste.
5. Prehľad vyskladneného tovaru pre interné potreby na danom predajnom
mieste a v danom časovom intervale.
6. Prehľad zamestnancov a ich oprávnení na danom predajnom mieste.
16. Grafický klient, pomocou ktorého sa bude uskutočňovať predaj bude navrhnutý
tak, aby umožnil čo najrýchlejší priebeh predaja. Podrobnosti tohto bodu budú
dohodnuté v konečných f{zach vývoja systému, po dokončení pr{c na aplikačnej
vrstve.
Funkcionalitu systému z{sadne ovplyvňujú dve vlastnosti predaja:
Z určitého hľadiska sa predaj uskutočňuje podobne ako v bežnej samoobsluhe:
Klient si vyberie tovar, ktorý je aktuálne dostupný, zaplatí ho a v zapätí prevezme.
Netreba sa preto zaoberať problémom objednávok, ani skladovaním zaplateného
tovaru.
Všetky platby za tovar budú prebiehať výhradne prostredníctvom systému SUPO.
Preto nie je potrebné systém pre drobný predaj prispôsobovať na spracov{vanie
platieb, či prijímanie hotovosti, ale postačujúca je komunikácia so SUPOm.
Typický priebeh predaja prebehne nasledovne:
1. Obsluha identifikuje klienta pomocou čítačky kariet.
2. Obsluha následne uvidí správu o tom, či je klient autorizovaný k nakupovaniu. Ak
nie, informuje klienta o dôvode a ukončí n{kup.
3. Obsluha na z{kladne klientových požiadaviek naplní virtu{lny n{kupný košík.
8Skupina na seba nadväzujúcich úkonov zlyh{va atomicky pr{ve vtedy, ak sa vykonajú buď
všetky úkony, alebo žiaden.
12
4. Obsluha potvrdí predaj, na z{klade dohovoru vytlačí/nevytlačí účtenku a vydá
klientovi tovar.
13
4 Dátová vrstva
D{tov{ vrstva je spodn{ časť viacvrstvovej architektúry systémov. Jej úlohou je trvalo
uchov{vať a poskytovať d{ta. Na úrovni analýzy je reprezentovaná konceptuálnym a lo-
gickým modelom. Pri použití technológie Java EE, s využitím EJB 3.0, je d{tov{ vrstva prí-
stupná na úrovni abstrakcie JPA.
4.1 Konceptuálny model
Konceptu{lny model popisuje všeobecne predmet z{ujmu, zav{dza pojmy, definuje entity
a zn{zorňuje vzťahy medzi nimi. Vďaka tomu, že v prostredí drobného predaja na MU sú
a budú platby realizované prostredníctvom SUPO účtu, tovar sa bude kupovať výlučne
na predajnom mieste a odoberať ihneď po zaplatení, je do istej miery možné predpokladať
nemennosť funkčných požiadaviek. T{to skutočnosť umožňuje zúžiť pozornosť na entity
a vzťahy skutočne potrebné pre fungovanie systému.
Popis entít:
Názov: TovarTyp
Typ: Kernel
Objektom typu (#TovarTyp) je každý druh tovaru alebo ponúkanej služby, ktorý môže
byť, či bol predávaný.
Názov: Sklad
Typ: Kernel
Objektom typu (Sklad) je každ{ inštancia obchodu, v ktorom sa predáva a skladuje to-
var.
Predajné miesto, obchod a sklad sú synonymá.
Názov: TovarNaSklade
Typ: Associative
Objektom typu (#TovarNaSklade) je každ{ reprezentácia väzby medzi skladom (#Sklad)
a typom tovaru (TovarTyp) so zmyslom: Tovar určitého typu (#TovarTyp) je uskladnený
na sklade (#Sklad). / 0,M : 0,N
TovarNaSklade reprezentuje fyzicky existujúci tovar, ktorý je aktuálne na sklade.
Názov: Osoba
Typ: Kernel
Objektom typu (#Osoba) je každ{ osoba, ktor{ je, alebo môže byť klientom, alebo zamest-
nancom obchodu.
14
Názov: Naskladnenie
Typ: Associative
Objektom typu (#Naskladnenie) je každ{ reprezent{cia väzby medzi skladom (#Sklad)
a typom tovaru (TovarTyp) so zmyslom: Na sklad (#Sklad) bol pridaný tovar určitého
typu (#TovarTyp) v zn{mom množstve a čase. / 0,M : 0,N
Názov: Vyskladnenie
Typ: Associative
Objektom typu (#Vyskladnenie) je každ{ reprezent{cia väzby medzi skladovaným tova-
rom (#TovarNaSklade) a vyskladňovacou d{vkou (#VyskladnovaciaDavka) so zmyslom:
Tovar zn{meho množstva, ktorý bol odobratý z tovaru na sklade (#TovarNaSklade) je
súčasťou vyskladňovacej dávky (#VyskladnovaciaDavka). / 0,M : 0,N
Názov: VyskladnovaciaDavka
Typ: Kernel
Vyskladňovacia d{vka je množina tovaru odobraného zo skladu. Je nedeliteľn{, pretože
ak sa stane predmetom predaja, bude zaplatená ako celok. Ak bola dávka tovaru odobratá
pre iné účely ako predaj, bude k nej prislúchať pr{ve jedno odôvodnenie.
Názov: InternePouzitie
Typ: Kernel
Objektom typu (#InternePouzitie) je každé odôvodnenie odobratia tovaru zo skladu
v podobe d{vky (#VyskladnovaciaDavka) za účelom iným ako predaj tovaru.
Názov: Predaj
Typ: Kernel
Objektom typu (#Predaj) je každý popis predaja d{vky tovaru (#VyskladnovaciaDavka)
klientovi.
Názov: Rola
Typ: Kernel
Objektom typu (Rola) je označenie každej množiny opr{vnení, ktorými môže disponovať
osoba pracujúca na predajnom mieste.
Názov: PracujeNa
Typ: Associative
Objektom typu (#PracujeNa) je každ{ reprezentácia väzby medzi osobou (#Osoba) a pre-
dajným miestom (#Sklad) so zmyslom: Pracovné vzťahy (#PracujeNa) danej osoby (#Oso-
by) viazané na predajné miesto (#Sklad). / 0,M : 0,N
Popis väzieb:
Ref: 01
Osoba (#Osoba), ktor{ uskutočnila naskladnenia tovaru (#Naskladnenie)-s. / 1,1 : 0,M
15
Ref: 02
Osoba (#Osoba), ktorá vyskladnila dávky tovaru (#VyskladnovaciaDavka)-s. / 1,1 : 0,M
Ref: 03
Odôvodnenie (#InternePouzitie) vyskladnenia dávky tovaru (#VyskladnovaciaDavka),
ktor{ nebola vyskladnen{ za účelom predaja. / 1,1 : 1,1
Ref: 04
Predaj (#Predaj), ktorého predmetom bola vyskladňovacia dávka (#VyskladnovaciaDav-
ka). / 1,1 : 1,1
Ref: 05
Osoba (#Osoba), ktorá bola v roli zákazníka (a zaplatila tovar) pri predajoch (#Predaj)-s.
/ 1,1 : 0,M
Ref: 06
Role (#Rola)-s, ktorými disponuje zamestnanec pri vykonávaní prác na základne jeho pra-
covných záväzkov (#PracujeNa)-s. / 0,M : 0,N
Z modelu je vidieť, že naskladňovanie a vyskladňovanie tovaru nebude prebiehať
rovnako. Naskladnený tovar sa pripočíta k tovaru, ktorý sa skladuje a je rovnakého dru-
hu. Spolu s ním je naďalej spravovaný ako celok až do chvíle, kým sa nevyskladní. Vys-
kladnený tovar sa n{sledne pred{va, alebo spotrebúva pre interné účely obchodu. Je
výhodné pracovať s takýmto tovarom ako s dávkou: Dávka tovaru je predaná, prípadne je
k nej naviazané odôvodnenie jej spotreby (je zbytočné a nežiaduce odôvodňovať vysklad-
nenie zošita a ceruzky dvakr{t, podobne ako generovať niekoľko platieb pre obsah náku-
pu). Vyskladňovacia d{vka je v istom zmysle paralelou n{kupného košíka.
Informačn{ schopnosť9 sa javí ako dostatočn{ (s ohľadom na funkčné požiadavky na
systém), a preto bolo opr{vnené zah{jiť ďalšiu f{zu vývoja – tvorbu logického modelu.
9 Informačn{ schopnosť meria množstvo inform{cie, ktoré model môže uchov{vať a poskytovať.
16
Grafické znázornenie konceptuálneho modelu:
4.2 Logický model
Úlohou logického modelu je skonkrétniť konceptu{lny model – vymenovať skutočné d{ta,
ktoré sú predmetom záujmu systému. Vzniknú tak atribúty entít, od ktorých sa bude
odvíjať fyzický model, ktorý je predlohou implement{cie a určuje štruktúru datab{zových
tabuliek.
Atribúty entít:
Typ tovaru (#TovarTyp): názov typu tovaru; slovný popis typu tovaru
Sklad (#Sklad): n{zov skladu; adresa skladu; kód služby, ktorou sa budú uhradzovať plat-
by pomocou systému SUPO
17
Tovar na sklade (#TovarNaSklade): aktu{lne množstvo tovaru na sklade; minimálna hra-
nica (ak je aktu{lne množstvo tovaru menšie ako minimálna hranica, je doporučené objed-
nať nové z{soby tovaru); príznak signalizujúci, či je možné skladovaný tovar pred{vať;
cena, za ktorú sa tovar predáva; typ tovaru; sklad
Osoba (#Osoba): krstné meno; priezvisko, oscis – osobné identifikačné číslo
Naskladnenie (#Naskladnenie): druh tovaru, ktorý bol pridaný na sklad; sklad, na ktorý
sa tovar pridal; počet kusov pridaného tovaru; osoba, ktor{ pridala tovar na sklad; časov{
zn{mka okamihu uskutočnenia naskladnenia
Vyskladnenie (#Vyskladnenie): tovar, ktorý bol vyskladnený; počet kusov vyskladneného
tovaru; vyskladňovacia d{vka
Vyskladňovacia d{vka (#VyskladnovaciaDavka): osoba, ktor{ uskutočnila vyskladnenie;
časov{ zn{mka okamihu uskutočnenia vyskladnenia
Interné použitie (#InternePouzitie): vyskladňovacia d{vka, ktorú spresňuje interné použi-
tie; odôvodnenie vyskladnenia tovaru
Predaj (#Predaj): vyskladňovacia d{vka, ktorá sa predáva; klient, ktorému bola dávka
predaná a ktorý predaj zaplatil; príznak, či sa pri predaji platila daň z pridanej hodnoty
Rola (#Rola): názov role; popis role
Pracuje na (#PracujeNa): obchod, v ktorom pracuje zamestnanec; zamestnanec
Informačn{ schopnosť logického modelu bola opäť konzultovan{ s vedením CPS
a je považovan{ za dostatočnú.
Korektný prevod logického modelu na fyzický neovplyvňuje informačnú schop-
nosť. Je to proces, pri ktorom sa z modelu, ktorý sa orientuje výhradne na dáta a ich
vzťahy, st{va model vhodný na implementáciu a fungovanie na počítači. Dve hlavné sú-
časti tohto procesu sú:
Identifik{cia entít, pri ktorej sa určí prim{rny kľúč10 každej entity.
Normalizácia – technika ktorá minimalizuje duplicitné ukladanie dát a rozhoduje
o usporiadaní dát do databázových tabuliek. Dôsledkom správne vykonanej nor-
malizácie je dobre spravovateľn{ a udržateľn{ datab{za bez logických anom{lií.
Normalizovan{ datab{za je dobrý z{klad pre prehľadnú a modul{rnu aplikačnú
logiku.
10 Prim{rny kľúč je skupina atribútov entity, ktor{ je pre každý výskyt entity (inštanciu) unik{tna.
18
4.3 Entitné triedy
Entitné triedy, ako súčasť JPA, slúžia na implement{ciu fyzického d{tového modelu. Pri
behu aplikácie sú umiestnené na Java EE serveri a pre aplikačnú logiku reprezentujú
datab{zové tabuľky a ich väzby. Skutočné umiestnenie d{t je popísané v konfiguračnom
súbore persistence.xml (spojenie na databázový server, zoznam entít) a v samotných entit-
ných triedach pomocou anotácií (databázová schéma a n{zov tabuľky).
Predlohou pre implementáciu entít bol fyzický model systému znázornený na ob-
rázku 4.1. Keďže sa systém pre predaj nasadzuje do prostredia, kde už existuje fungujúca
evidencia osôb, nie je nutné implementovať ju znovu. ORM umožňuje mapovať potrebné
atribúty z už existujúcej tabuľky a používať ich len na čítanie.
Obrázok 4.1
19
Pri prechode od logického modelu k fyzickému došlo k drobnej zmene, ktor{ však
neovplyvňuje informačnú schopnosť: entita naskladneni sa neviaže na sklad a zbozi_typ, ako
jej to v logickom modeli, ale na zbozi_na_sklade. Z implementačného hľadiska je to výho-
dnejšie, pretože sa jednoduchšie zaručí konzistencia d{t.
Entity na úrovni analýz boli pomenované v slovenskom jazyku. Názvy databázo-
vých tabuliek a atribútov sú, samozrejme, v českom jazyku.
20
5 Aplikačná vrstva
V tejto kapitole bude popísan{ aplikačn{ vrstva – hlavný cieľ tejto pr{ce. Je to t{ časť sys-
tému, ktorá reprezentuje jeho funkcionalitu a riadi operácie nad dátami, ktoré sú predme-
tom z{ujmu. Poskytne rozhranie, ktoré budú používať grafický aj webový klient.
Jej implement{cia vych{dza zo zoznamu funkčných požiadaviek a z podoby dátovej
vrstvy.
Systém bol vyvíjaný iteratívne. To znamen{, že funkcionalita pribúdala po malých
častiach, za ktorými nasledovalo testovanie, ktoré prinieslo radu výhod:
Priebežné testovanie odhalilo program{torské chyby včas, čo v konečnom dôs-
ledku viedlo k urýchleniu vývoja. Chyby boli väčšinou súčasťou nového a ešte
netestovaného zdrojového kódu, teda bolo možné ich pomerne rýchlo lokalizovať.
Vďaka postupnému pribúdaniu funkcionality sa dal dobre kontrolovať priebeh
prác (oproti zoznamu funkčných požiadaviek) a odhadnúť čas potrebný na nasle-
dujúce etapy.
Súčasťou vývoja bolo časté refaktorovanie zdrojového kódu11, ktoré prinieslo nie-
koľko variantov štruktúry programu.
Z glob{lneho hľadiska viedlo refaktorovanie ku dvom odlišným riešeniam:
Štrukturovať aplik{ciu na z{klade funkčnej koherencie – zoskupovať zdrojový kód
na základe podobnej funkcionality. Tým by vznikli komponenty, ktoré by posky-
tovali funkcionalitu určitého druhu (manipul{cia s tovarom, správa tovaru na
sklade, spr{va číselníkov apod.).
Navrhnúť aplik{ciu s dôrazom na logickú koherenciu – vytvoriť komponenty, mode-
lujúce objekty re{lneho sveta, ktoré sú ľahšie pochopiteľné a lepšie sa s nimi ma-
nipuluje. Vzťahy medzi nimi sú analogické k tým, ktoré existujú v reálnom svete.
Myslím, že sa pri n{vrhu systémov v praxi nepoužíva striktne jeden, alebo druhý
prístup. Predpoklad{m, že výsledok by bol zbytočne komplikovaný a obsahoval by príliš
mnoho autonómnych častí. Domnievam sa, že prevl{danie funkčnej koherencie je vý-
hodné pri n{vrhu jednoduchších systémov, či samostatných modulov v relatívne nemen-
nom prostredí. Na druhú stranu je aplikovanie princípu logickej koherencie vhodné, ak je
doménov{ oblasť rozsiahlejšia, komplikovanejšia. V prípade systému pre predaj tovaru na
MU prevládala pri návrhu logická koherencia, preto vznikli dva komponenty – sklad
a obchod.
11Zmeny v programovom kóde, ktoré nemenia funkcionalitu, ale upravujú kód tak, aby sa stal čita-
teľnejší, pochopiteľnejší a lepšie logicky štruktúrovaný. Môžu byť rôzneho rozsahu, od niekoľkých
riadkov až po zmeny ovplyvňujúce celú aplik{ciu.
21
5.1 Komponent skladu
Tento komponent modeluje bežný sklad a poskytuje očak{vanú funkcionalitu. Je repre-
zentovaný jedným SB – StockBean, použitie predpisuje jedno z jeho rozhraní:
Metódy umiestnené pod čiarou sú využívané len zriedka, alebo nie sú ťažiskom z{-
ujmu. Pri striktnom dodržiavaní princípu logickej koherencie by mali byť súčasťou iného
komponentu, bola by to však zbytočn{ komplik{cia.
Najdôležitejšia funkcionalita je reprezentovaná metódami:
addGoods(Stock whereTo, TypeOfGoods typeToAdd, int howMany); Naskladňuje tovar
určitého typu na konkrétny sklad v danom počte. Vytvára aj evidenciu jednotli-
vých naskladnení.
Expenditure expend(GoodsToExpendBatch batch); Odoberie dávku tovaru zo skladu
a vytvorí z{znam identifikujúci zamestnanca, ktorý tovar vyskladnil. Dôležité je,
že na tejto úrovni modul skladu nepozn{ účel vyskladnenia – plní len požiadavky
generované obchodom (predaj, alebo interné použitie).
22
Vyskladňovaciu d{vku reprezentuje serializovateľný objekt GoodsToRemoveBatch.
Obsahuje tovar na sklade a požadované množstvo na vyskladnenie. Poskytuje metódy na
manipuláciu s tovarom v d{vke (pridať, odobrať a prehľad).
Zvyšné metódy umožňujú úpravu vlastností tovaru na sklade (napr. cenu) a pos-
kytujú prehľad o stave skladov. Verím, že ich použitie je zo zdrojového kódu rozhrania
zrejmé.
5.2 Komponent obchodu
Tento komponent modeluje obchod, v ktorom prebiehajú platby bezhotovostne (pomocou
systému SUPO), tovar sa kupuje na mieste a odober{ hneď po predaji (bez objedn{vok,
bez skladovania predaného tovaru). Je implementovaný pomocou jedného SB – StoreBean.
Jeho funkcionalitu vyjadruje nasledujúce rozhranie:
Najvýznamnejšiu funkcionalitu poskytujú metódy:
sellGoods(GoodsToRemoveBatch batch, Person buyer); Predá dávku tovaru klientovi,
uskutoční zr{žku zo SUPO účtu a odoberie predaný tovar zo skladu. Vytvorí záz-
nam o predaji, z ktorého sa môže generovať účtenka.
expendForIU(GoodsToRemoveBatch batch, String reason); Odoberie dávku zo skladu
pre interné účely a zaznamená dôvod vyskladnenia.
Pre zisťovanie hodnoty SUPO účtu vznikol nový objekt – SUPObalance. Ten zaru-
čuje, že presn{ hodnota zostatku na SUPO účte je zn{ma len ak je disponibilný zostatok
menší ako 100 korún, inak poskytne inform{ciu o tom, či je zostatok dostatočne veľký na
zaplatenie dávky tovaru.
23
Zvyšné metódy umožňujú ohodnotiť d{vku tovaru a odpovedajú, či je možné
d{vku predať, alebo vyskladniť pre interné účely.
5.3 Komunikácia medzi komponentmi, ich použitie a limity
Súčasn{ podoba systému, vhodn{ pre použitie pr{ve na pôde MU, má svoje výhody a li-
mity: Z praktického hľadiska je možné komponenty od seba oddeliť a použiť v iných apli-
k{ci{ch. Najmä modul skladu je dostatočne všeobecný na samostatné fungovanie. Dok{že
spravovať typy tovaru, jednotlivé sklady a výskyt tovaru na skladoch. Jeho silným obme-
dzením je absencia evidencie zmien (napr. cien tovaru, uskutočnených zmien typov
tovaru a skladov). Komponent obchodu je viazaný na ľubovoľný sklad umožňujúci vys-
kladnenie tovaru. Vyžaduje prítomnosť externého systému na uskutočňovanie platieb,
nepodporuje objednávky a skladovanie zaplateného tovaru.
Z program{torského hľadiska bolo rozdelenie veľkým prínosom. Som presvedčený,
že zdrojový kód je prehľadný a pochopiteľný. Obrázok 5.1 ilustruje použite komponen-
tov.
Obrázok 5.1
24
6 Záver
6.1 Zhodnotenie výsledkov
Výstupom tejto bakalárskej práce je základ viacvrstvovej distribuovanej aplikácie – dá-
tová a aplikačn{ vrstva. API, ktoré definuje aplikačn{ vrstva, umožňuje predaj drobného
tovaru a služieb v prostredí MU na viacerých a nezávislých predajných miestach z niekoľ-
kých pokladní. Bolo integrované do systému Inet MU a jeho funkčnosť dokazuje webový
klient.
Pri implementácii systému bola použit{ modern{ a perspektívna technológia – Java
EE, najmä EJB 3.0.
Jednotlivé časti pr{ce uvedené v kapitole 1.2 prebiehali nasledovne:
1. Vykonať analýzu problematiky a špecifikovať požiadavky na systém.
o Po uskutočnení analýzy (prehliadka súčasného systému, n{všteva počí-
tačovej študovne, rozhovory s predávajúcim personálom, s vedením CPS
a týmom SUPO) vznikol zoznam funkčných požiadaviek a následne kon-
ceptuálny model systému. Požiadavky, ako aj informačn{ schopnosť mode-
lu, boli opäť konzultované s vedením CPS a s týmom SUPO, na základe
čoho bolo opr{vnené považovať dovtedajšiu analýzu sa spr{vnu a pokra-
čovať ďalšími etapami.
2. Navrhnúť d{tové štruktúry pre uchov{vanie a poskytovanie informácií o okolnos-
tiach predaja.
o Na základe konceptuálneho modelu bol vytvorený fyzický model, ktorý
spĺňa požiadavky štvrtej norm{lnej formy.
3. Navrhnúť a zimplementovať aplikačné rozhranie systému, ktoré umožní uskutoč-
ňovať platby prostredníctvom SUPO účtu nakupujúceho.
o Táto etapa vývoja bola najkomplikovanejšia a zabrala väčšinu času vývoja
systému. Na začiatku bolo potrebné implementovať fyzický model a po-
zornosť presunúť od štrukturaliz{cie d{t k procesom, ktoré d{ta transfor-
mujú, overujú a vytv{rajú. Na z{klade funkčných požiadaviek a fyzického
modelu začalo iteratívne vznikať API. Bolo programované s ohľadom na
princípy defenzívneho programovania a niekoľko kr{t prer{bané s cieľom
dosiahnutia uspokojivej modularity na základe princípu logickej koheren-
cie. V konečnom výsledku pozost{va aplikačn{ logika z dvoch zameniteľ-
ných modulov: zo skladu a obchodu.
o Z časových dôvodov ešte neboli zimplementované metódy, ktoré budú
poskytovať d{ta potrebné pre tvorbu prehľadových zost{v. Som presved-
25
čený, že vzhľadom k informačnej schopnosti d{tového modelu a ku modu-
larite aplikačnej logiky nebude problém metódy do API pridať.
4. Otestovať zimplementované rozhranie.
o Testovanie komponentov systému prebiehalo z{roveň s programovaním
API. Ukázalo sa ako prínosné a zavčas odhalilo program{torské chyby.
o Na z{klade vlastností trojvrstvovej architektúry systému je možné (z funk-
čného hľadiska) považovať grafického a webového klienta za rovnocen-
ných. Pri prev{dzke systému sa bude používať grafický klient (samostatn{
Java SE aplikácia), ale z časových dôvodov prebehli testy na webovom
klientovi, ktorý je súčasťou systému Inet MU. Toto z{roveň ukazuje splne-
nie jedného z hlavných cieľov – integrovať systém predaja so systémom
Inet MU. API ako celok bolo otestované paralelne viacerými užívateľmi cez
webové rozhranie. Neodhalilo žiadne chyby, ale pouk{zalo na technolo-
gické rozdiely implement{cií štandardov, ktorým sa venuje kapitola 6.3.
6.2 Čo bude nasledovať
Výstup tejto bakal{rskej pr{ce samozrejme nestačí na nasadenie do počítačových štu-
dovní. Verím, že bude kvalitným serverovým partnerom pre klientov, pomocou ktorých
sa bude predaj tovaru a spr{va skladu uskutočňovať.
Aplikačný klient tohto systému bude samostatn{ grafick{ Java SE aplik{cia naprog-
ramovan{ s využitím sady n{strojov Java Swing. Jednou z hlavných požiadaviek zad{va-
teľa je, aby bol klient ľahko ovl{dateľný a umožňoval pred{vať (a manipulovať s obsahom
virtu{lneho n{kupného košíka) čo najrýchlejšie. K dosiahnutiu takého cieľa určite pomôže
aj čítačka študentských a zamestnaneckých kariet – zákazníci sa budú voči systému iden-
tifikovať svojou kartou, na z{klade čoho budú realizované aj platby prostredníctvom
systému SUPO.
Pred nasadením do ostrej prev{dzky bude ešte potrebné systém naplniť d{tami
z doteraz používaného systému, vytvoriť účty obsluhy a prideliť im príslušné pr{va.
6.3 Technologická poznámka
V súvislosti s jazykom Java sa často spomína bezproblémov{ prenositeľnosť aplikácií.
Menej významné rozdiely v implement{ci{ch štandardov sa obvykle propagujú v men-
šom rozsahu, preto som sa rozhodol pripomenúť dve, pre mňa prekvapivé, odlišnosti.
Boli odhalené pri prechode z vývojového prostredia (databáza: Apache Derby; imple-
mentácia JPA: TopLink Essentials) do prostredia serverov Inetu (databáza: Oracle 10.x;
implementácia JPA: KODO):
26
Vo vývojovom prostredí bolo možné do datab{zy uložiť pr{zdny reťazec (objekt
typu java.lang.String dĺžky 0) a po vyhľadaní hodnoty pomocou JPA korektne načí-
tať späť. V prostredí serverov Inetu bol po požiadavke na uloženie pr{zdneho re-
ťazca vytvorený z{znam hodnoty null bez upozornenia v podobe záznamu v logu
servera apod. Za takéto správanie je zodpovedná databáza Oracle. Toto zistenie
bolo pre mňa zar{žajúce, pretože pr{zdny reťazec a hodnota null sa diametrálne
odlišujú.
Druhý rozdiel sa týka vyhodnocovania JPQL dopytov: Stav inštancie entity, ktor{
je parametrom dopytu, nehr{ žiadnu rolu vo vývojovom prostredí, ale v prostredí
serverov Inetu {no. Mechanizmus tohto prostredia, ktorý vyhodnocuje rovnosť
dvoch objektov, považuje objekty rovnakého typu so zhodnými hodnotami atri-
bútov za odlišné. Tak{to vlastnosť implement{cie KODO je pre mňa nepochopi-
teľn{. Očak{val by som, že rovnosť objektov v objektovo orientovanom prostredí
(na základe metód equals(Object obj) a hashCode()) a v prostredí relačných datab{z
(rovnak{ hodnota prim{rneho kľúča), je dostatočnou podmienkou rovnosti
objektov pri vyhodnocovaní JPQL dopytov. KODO vyžaduje, aby bola entita,
ktorá je parametrom dopytu, spravovaná (managed).
V praxi sa často stane, že si vývoj{r zvykne na jednu implement{ciu štandardu
a tým štandard spozn{. Tento postup, aj keď nie je úplne spr{vny, je pochopiteľný –
špecifik{cia JPA obsahuje niekoľko stoviek str{n pomerne zložitého textu. Myslím, že
každ{ implement{cia m{ svoje výhody, napr. poskytnutím funkcionality nad rámec po-
žiadaviek štandardu. Problém môže nastať, ak vývoj{r začne pokladať takéto vlastnosti
implement{cie za súčasť štandardu. V takom prípade sa pri prechode z jednej imple-
mentácie na druhú niekedy zmení funkcionalita produktu, alebo sa produkt stane
nefunkčným. Programátorské chyby tohto druhu sa odhaľujú pomerne zložito.
27
Literatúra
*CPS1+ Račanský V., Pištěk P., Celouniverzitní počítačov{ studovna na MU,
Zpravodaj ÚVT MU, ISSN 1212-0901, 2000, roč. X, č. 4, s, 1-2.
[SUPO2] Inet MU: Základní informace o systému SUPO,
https://inet.muni.cz/app/supo/info
[MULTI3] Wikipedia: Multitier architecture,
http://en.wikipedia.org/wiki/Multitier_architecture
[JAVAEE4] Jendrock, E. and Ball, J. and Carson, D. and Evans, I. and Fordin, S.
and Haase, K.: The Java EE 5 Tutorial, Sun Microsystems, Inc., 2007,
http://java.sun.com/javaee/5/docs/tutorial/doc/.
[JSR5] EJB 3.0 expert group, JSR 220: Eterprise Java Beans 3.0, Sun Microsystems,
Inc., 2006, http://jcp.org/en/jsr/detail?id=220.
[ORA6] JPA Annotation Reference,
http://www.oracle.com/technology/products/ias/toplink/jpa/resources/topli
nk-jpa-annotations.html
[JPA7] EJB 3.0 expert group, Java Persistence API, Sun Microsystems, Inc., 2006,
http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html.
[EJB8] EJB 3.0 expert group, EJB Core Contracts and Requirements, Sun
Microsystems, Inc., 2006,
http://jcp.org/aboutJava/communityprocess/final/jsr220/index.html.
[EJB9] Codali, R. R., Weherbee J.: Beginninig EJB 3 Application Development,
Apres, 2006, 1-59059-671-4.
[EJB10] Keith M., Schincariol M.: Pro EJB 3 Java Persistence API, Apres, 2006, 1-
59059-645-5.
[BLOCH11] Bloch, J., Java efektivně, Grada Publishing a.s., 2002, 80-247-0416-1.
[DUZI12] Duží M., Konceptu{lní modelov{ní: d{tový model HIT, Slezsk{
univerzita, 2000, 8072480626.
[STAN13] Staníček Z, Datové modelov{ní metodou HIT,
http://www.fi.muni.cz/~stanicek/P114/hitmet.ps
[BUS14] Wikipedia: Business logic, http://en.wikipedia.org/wiki/Business_Logic
28
Príloha A
Ukážka konfiguračného súboru
Súbor persistence.xml používaný systémom pre drobný predaj vyzer{ nasledovne:
29
Príloha B
Logický dátový model
Sémantika väzieb logického a konceptu{lneho modelu je totožn{.
30
Príloha C
Webový klient
Webový klient dokazuje integráciu Inetu MU a systému pre drobný predaj. Slúži výhrad-
ne na testovanie systému.
Prehľad typov tovaru
31
Prehľad predajných miest
Prehľad tovaru na sklade
32
Naskladnenie tovaru
Vyskladnenie tovaru pre interné účely
33
Predaj tovaru
34
Príloha D
Obsah priloženého CD
Priložené CD obsahuje:
Text práce vo formáte PDF
Text práce vo formáte DOCX
Zdrojové kódy systému a webového klienta, ktoré bolo možné zverejniť
35
