Docstoc

bp

Document Sample
bp Powered By Docstoc
					          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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:8/18/2011
language:Slovak
pages:42