Pentaschool Oktatási Központ Számítástechnikai programozó

Z S Í R O S T I B O R ELEKTRON IKU S K ERE SKEDELM I P ORTÁL

F E J L E S ZTÉ S E Kolman Nándor Szaktanár konzulens

1

T A R T A L O M J E G Y Z É K

1. Bevezetés.................................................................................................... 2

2. Internetes kereskedelem ............................................................................. 3

3. Feladatspecifikáció..................................................................................... 4

4. Tervezés...................................................................................................... 6

4.1. Adatbázis megtervezése...................................................................... 6

4.2. Felülettervezés .................................................................................. 18

4.2.1. A tervezésben használt technikák.............................................. 18

4.2.2. Adminisztrációs felület.............................................................. 22

4.2.3. Felhasználói felület.................................................................... 23

5. Megvalósítás............................................................................................. 24

5.1. A megvalósításban felhasznált technológiák .................................... 25

5.2. A rendszer logikai működése............................................................ 33

5.3. Osztályok .......................................................................................... 34

5.4. Adminisztrátori felület megvalósítása .............................................. 37

5.5. Felhasználói felület megvalósítása ................................................... 38

6. Üzembe helyezés...................................................................................... 39

7. Tesztelés ................................................................................................... 40

8. Összefoglalás............................................................................................ 41

9. Felhasznált irodalom ................................................................................ 43

10. Az elektronikus kereskedelmi portál elérhetősége................................... 44

2

1. Bevezetés

Napjaink egyre gyorsuló világa megköveteli a fejlődés ütemének

gyorsulását is. A fejlődő országokban szinte minden háztartás rendelkezik

vagy hamarosan rendelkezni fog internet hozzáféréssel. Hazánkban a tavalyi

évben mintegy másfél millió háztartás rendelkezett számítógéppel és

megközelítőleg 800 000 háztartásban volt internet kapcsolat. Életünkben az

internet használat olyan hétköznapi eszközzé válik, mint az elektromos áram,

vagy a tömegközlekedés. Megkönnyítheti mindennapi életünket, például a

banki tranzakciók otthonról történő ügyintézésével, vagy akár egy jó könyv

kölcsönzésével, hírek böngészésével, elektronikus levelezéssel, egyszóval az

információ gyors és hatékony továbbításával. A nagyvállalatok, és a kisebb

cégek számára is lehetőség nyílik a gyors adatcserére partnereikkel, így

lehetővé vált üzleti tevékenységek kiadása, kiszervezése, másik cég megbízása

bizonyos feladatok elvégzésével, legyen az bárhol a világon. Ezek a

tevékenységek (outsourcing) bevett gyakorlat például az amerikai vállalatok,

és India vagy Japán és Kína között, de hazánkban is egyre nagyobb szerepet

kap a költséghatékonysága miatt. Akár szoftverfejlesztéseket, könyveléseket

és orvosi látleletek véleményezésének folyamatát, munkamenetét is ki lehet

adni, köszönhetően a gyors és biztonságos adattovábbításnak, és az adatok

digitalizálásának. Mindezt figyelembe véve a világ ma már nem lenne képes

működni az internet nélkül, így a hétköznapok tevékenységeink, folyamataink

is áttevődnek az elektronikus birodalomba.

Az egyik interneten keresztüli tipikus tevékenység a vásárlás. A

termékek és azokat kínáló úgynevezett webáruházak széles választéka

megtalálható akár több nyelven is. Az egyik legnépszerűbb böngésző a google

a webáruház szóra kevesebb, mint egy másodperc alatt talál körülbelül

kettőmillió bejegyzést. Ez persze nem konkrétan a webáruházak számosságát

jelenti, de azt mindenképpen, hogy mennyire elterjedt maga a fogalom és a

mögötte található elektronikus kereskedelmi rendszerek. Mindezek miatt

döntöttem úgy, hogy a szakdolgozatom témájául az elektronikus

kereskedelmet választom. A középponti témám a szakdolgozatban egy

3

webáruház megtervezése, felépítése. Egy fejlesztési projekt során mutatom be

egy általános alapokra épülő webáruház alapvető funkcióit és azok működését.

A szakdolgozat végigvezet a fejlesztés szakaszain, bemutatva ezzel egy

fejlesztési projekt lépéseit. Ezen felül bemutatom azokat a mai webes

technológiákat, tervezési koncepciókat és irányokat, amelyek segítségével

életre keltettem a webes áruházat. A dolgozat elolvasása után egyértelművé

válik az olvasó számára egy webes áruház funkcionalitása, működése, és a

mögötte álló technológiák alapja.

2. Internetes kereskedelem

Az internet elterjedésével hazánkban is egyre keresettebbek az

internetes vásárlást biztosító ún. webáruházak. Hazánkban a 2006-os év

legnépszerűbb internetes áruháza a Bookline könyváruház lett, melynek éves

forgalma ugyan ebben az évben 1 418 Millió Ft lett. Ez is azt mutatja, hogy a

felhasználók körében egyre jobban elterjed az elektronikus kereskedelem,

egyre nagyobb bizalmat szentelnek az emberek a karosszékből történő

vásárlásnak. Évekkel ezelőtt még a bizalom hiánya miatt kevésbé használták

az emberek az internet eme funkcióját, viszont napjainkban a vásárlás egyre

inkább elterjed, a bizalmatlanság csak a fizetési szokásokban jelentkezik. A

vásárlók többsége a megbízható utánvételes fizetési módot választja, pedig

rendelkezésre áll a bankok által biztosított portálokon keresztül bankkártyás

fizetések, illetve a nemzetközi webshopok-on keresztüli vásárlás esetén az

online fizetési megoldások, mint a Moneybookers, vagy a Paypal.

A Szonda Ipsos és a Gfk Hungária kutatóintézetek Internet Audience Research

(IAR) kutatásának 2006. októberében publikált eredményei alapján a legalább

havi rendszerességgel internetezők 14%-a használja az internetet vásárlásra, a

vásárlásokat megelőzően pedig 53% keres információt az interneten (akár

online, akár hagyományos).

A GKI által az online áruházakról készített kutatás alapján elmondható, hogy

2005-ben az internetes kiskereskedelmi forgalom 19 milliárd forint volt. Azóta

ez a szám csak emelkedett, a legtöbb feltételezés szerint 2006-os forgalom 25-

4

30 milliárd Ft.-ot is elérheti. A pontos értékről még nincs publikus információ.

Jelenleg is tapasztalható, hogy az internetes áruházak többsége különböző

kedvezményekkel próbálja meg vásárlásra buzdítani a vásárlókat. A boltok

többsége 1-10%, de előfordul, hogy 20-25% kedvezményt is adnak. Nagyon

sok áruház felismerte a vásárlók bizalmatlanságát a fizetési módokat illetően,

ezért aki megteheti, az személyes átvételt is lehetővé tesz. Így a webáruházban

csak kifejezetten a termék kikeresése és megrendelése történik, a konkrét

fizetés és átvétel pedig az áruház által megadott cím(ek)en lehetséges.

3. Feladatspecifikáció

A cél egy olyan általános szabályokon működő webáruház elkészítése

volt számomra, amelynek feladata az ügyfelek elektronikus úton történő

kiszolgálása. Minden olyan alapvető funkció biztosítása, amely egy vásárlás

során megszokott és egyértelmű. Lehetőséget kellett biztosítanom az oldalon

található termékek közötti böngészésre, azok bizonyos kritériumok alapján

való keresésére és a kíván termék árának, egyéb adatainak feltüntetése mellett

annak megvásárlására. Amennyiben vásárlásra kerül a sor, akkor a

webáruházban regisztrálni kell a postázáshoz és a számlázáshoz szükséges

adatokat. Ezt az alkalmazás regisztrációs oldalán található űrlap megfelelő

kitöltésével lehet megtenni. A regisztráció során meghatároztam a kötelezően

megadandó információkat is, ezek megadásának biztosítását mind kliens

oldalon (javascript) mind szerveroldalon (PHP) biztosítani kell. Az oldalra

való belépés után lehet elküldeni a vásárlási igényt. A belépés egy felhasználói

név és egy jelszó megadását jelenti, amelyet a rendszer ellenőriz, majd helyes

adatok esetén beléptet. A webáruház üzemeltetése szempontjából szükség van

egy adminisztrátori felületre. Ez teszi lehetővé a regisztrált felhasználók

adatainak ellenőrzését, azok szükség esetén történő manipulációját. Ugyanitt

lehet a webáruházban található termékek adatait módosítani és új terméket

regisztrálni. Ezen kívül itt lehet majd a leadott vásárlási igényeket kezelni.

A végrehajtás során két felületet hoztam létre. Egyet a webáruháznak és

egy másikat az adminisztrációs felületnek. Ez lehetővé teszi, a felhasználói és

5

az adminisztrációs folyamatok teljes elkülönítését. Biztonsági szempontból is

előnyösebbnek látom, ha ezek a feladatok nem illeszkednek bele a

felhasználói felületbe. Mind a két felületet azonos stíluselemek alkotják így az

adminisztrátor számára az átjárás a két felület között nem okoz semmilyen

nehézséget. A felületek főbb alkotó elemei menüelemek, tartalmi blokkok is

azonos elhelyezkedéssel rendelkeznek. A vásárláshoz a regisztrációt egy

regisztrációs űrlap kitöltésével és annak a felhasználó által történő

továbbküldésével biztosítottam. A vásárláshoz és a számlázáshoz megadandó

kötelező információk biztosítását úgynevezett kötelező mezők kitöltésével

biztosítottam. Ezek megadása nélkül nem lehetséges a regisztráció és a

vásárlás sem.

A munkafolyamatok részfeladatokra bontásával biztosítani tudtam,

hogy egy előre megtervezett tematika alapján építsem fel a fejlesztés menetét.

Így láthattam, hogy mi az, ami már elkészült, és mennyi időt kell még

fordítanom a hátralévő fejlesztési munka. Ez a fejlesztési projekt felépítésében

és menedzselésében segített.

A fejlesztési munka során előzetesen a következő alapvető feladatok

tervezését tartottam szükségszerűnek:

� A rendszer általános működése

Egy magas szintű működési folyamat felvázolása eltekintve a ténylegesen

felhasznált szintaktikai elemek bemutatásától. Így láthatom a webáruház,

átfogó általános szinten elvárt működési irányait, folyamatait.

� Adatbázis megtervezése

Egy jól átgondolt és strukturált adatbázis gyors és biztos működést alapoz

meg. Mivel ez a tervezett rendszer egy komoly, több táblás adatbázisra épül,

ezért mondhatjuk, hogy ez a részfeladat egyike a legfontosabbaknak, amit el

kellett végeznem. Megtervezni az adatbázisban használt adatok tulajdonságait,

az azokat magukba foglaló táblák felépítését és a táblák közötti kapcsolatot.

� Felhasználói felületek megtervezése

Figyelembe véve az általános írott és íratlan szabályokat, amiket egy

weblaptervezéskor szem előtt tartunk, létre kell hoznom egy jól strukturált

6

átlátható, az alapkoncepciót megvalósító és kellő felhasználói élményt

biztosító felületet. Ebben a fejezetben ennek a felületnek a megtervezését

fogom elvégezni. Felállítom az oldalak felosztását, megtervezem a használt

betűkészletet, a felületeken uralkodó színvilágot.

� Kódolás

Az előzetes tervek alapján elkezdem a tényleges kódolást, a webáruház

működését biztosító, a felhasználó és az adatbázis közötti kapcsolatot kiépítő

rendszer kialakítását. Ha az előző részfeladatokat és azok céljait sikeresen meg

tudtam határozni, akkor a tényleges kódolás a fejlesztési munka kisebbik

részét fogja jelenteni a számomra, mivel már látható számomra az elvárt

eredmény. Így célirányosan tudom végrehajtani a fejlesztést.

� Üzembe helyezés

Az elkészült termék használni kívánt háttérrendszereken történő

elhelyezésének, üzembe állításának menetét írom le. Bemutatva az eddig ilyen

tevékenységekből szerzett tapasztalataimat.

� Tesztelés

A lefejlesztett felületek teljes körű tesztelésének leírása. A teszt során kapott

eredményeket összevetem a meghatározott működési elvárásokkal. Hiba

esetén elvégzem a szükséges korrekció.

A felsorolt részfeladatok bővebb kifejtését a dolgozat további részében írom

le.

4. Tervezés

4.1. Adatbázis megtervezése

Az adatbázis tervezése az első lépés volt a tényleges webes alkalmazás

megvalósítása során. A folyamatot két részre különítettem el, egy elméleti

tervezésre és egy fizikai leképzésre, megvalósításra. Át kellett gondolnom,

hogy milyen adatokat fogok tárolni az adatbázisban, és ezek az adatok hogyan

fognak kapcsolódni egymáshoz. Meghatároztam az adatokat összefogó

táblázatok felépítését, a bennük található mezők jellemzőit. Nagy hangsúlyt

fektettem az indexelésre is, mivel a relációban tárolt adatok gyors

7

visszakeresésében nagy szerepe van. Ezeken keresztül könnyen kikereshető a

kulcsot tartalmazó fizikai sor helye és így az ott tárolt adatok gyorsan,

hatékonyan kinyerhetők. Első lépésben egy tagolatlan táblát hoztam létre az

alapok meghatározásához. Így fel tudtam vázolni, hogy milyen adatokra,

mezőkre és értékekre lesz szükség az adatbázisban. Itt még nincs szó táblák

közötti kapcsolatokról, minden adatot egyetlen tagolatlan táblába zsúfoltam

bele. Ez a tárolási forma nem hatékony, így ezt a formát a későbbi

modellezésem során, a harmadik normálforma eléréséig próbáltam átalakítani.

Általában ez a normálforma elegendő ahhoz, hogy megszüntesse a

redundanciát és rugalmas, bővíthető, jól strukturált adatbázist hozzak lére.

Redundanciáról akkor beszélünk, ha valamely tényt vagy a többi

adatból levezethető mennyiséget ismételten (többszörösen) tároljuk az

adatbázisban. A redundancia, a szükségtelen tároló terület lefoglalása mellett,

komplikált adatbázis frissítési és karbantartási műveletekhez vezet, melyek

könnyen az adatbázis inkonzisztenciáját okozhatják. Egy adatbázis akkor

inkonzisztens, ha egymásnak ellentmondó tényeket tartalmaz. A reláció

elmélet módszereket tartalmaz a redundancia megszüntetésére az úgynevezett

normál formák segítségével, azaz az adatbázis táblák normalizálásával. Ennek

azért láttam szükség, hogy a későbbiekben az adatok kezelhetősége és az

adattáblák kapcsolatainak átláthatósága hatékonyabb legyen. Az azonos

csoportokba tartozó adatokat egy táblába soroltam, és azon táblák között ahol

szükséges volt ott azonosítók alapján kapcsolatot hoztam létre.

Normalizálás alatt bizonyos szabályok alkalmazását értjük, melyek

nagyban megkönnyítik majd számunkra az adatbázisaink fenntartását. A

normalizálás voltaképpen az adatbázisok szervezésének egy módja, melynek

célja, hogy a táblák mindig a megfelelő kapcsolatba kerüljenek egymással.

� Első normálforma szabályai

- A táblák nem tartalmazhatnak ismétlődő csoportokat

- A különböző fogalmakkal kapcsolatos adatokat külön táblákba kell

elhelyezni

� Második normálforma szabályai

8

- A nem-kulcs attribútumok nem függhetnek egyetlen elsődleges kulcs

valódi részhalmazától sem

� Harmadik normálforma szabályai

- Egyetlen attribútum sem függhet más nem-kulcs attribútumoktól

Ez a tervezésben annyit jelentett, hogy addig bontottam részeire az adatokat,

amíg azok kezelhető, jól bővíthető és stabilan működő rendszert hoztak létre.

Amint elkészült az előzetes adatmodell akkor átnéztem az alkalmazás

leendő felhasználójának a szemszögéből is. Ezen a ponton kellett

meghatározni az üzleti logikát és azt is meg kellett vizsgálni, hogy az

adatmodell eleget tesz-e az üzleti logika által megszabott követelményeknek.

A relációs adatbázisok esetében a logikai tervezés során a relációk már

elnyerhetik végleges alakjukat, melyeket egyszerűen leképezhetünk az

adatbázis kezelőben. A fizikai tervezés során inkább arra koncentráltam, hogy

a logikai szerkezet mennyire felel meg a hatékony végrehajtás feltételeinek,

illetve milyen indexeket rendeljek az egyes relációkhoz. A relációkon

végrehajtott műveletegyüttest tranzakciónak nevezik és általában a

tranzakciók gyors végrehajtását kívánjuk elérni vele.

9

Az adatbázis táblái

Az OnLine Shop adatbázis jelen állapotában 10db táblát tartalmaz.

A FELHASZNÁLÓK tábla tartalma:

azon: A felhasználó azonosítója (auto increment)

vezetekNev: A felhasználó vezetékneve

keresztNev: A felhasználó keresztneve

Email: A felhasználó e-mail címe

cegNev: Céges regisztráció esetén cégnév

jelszo: A felhasználó jelszava

telefonszam: A felhasználó telefonszáma

cimOrszag: A felhasználó postázási címe (Ország)

cimVáros: A felhasználó postázási címe (Város)

cimKozterulet: A felhasználó postázási címe (Közterület)

cimHazszam: A felhasználó postázási címe (Házszám)

cimIranyitoszam A felhasználó postázási címe (Irányítószám)

szamlaCimOrszag A felhasználó számlázási címe (Ország)

szamlaCimVaros A felhasználó számlázási címe (Város)

szamlaCimKozterulet A felhasználó számlázási címe (Közterület)

szamlaCimHazszam A felhasználó számlázási címe (Házszám)

szamlaCimIranyitoszam A felhasználó számlázási címe (Irányítószám)

Datum A regisztráció dátuma

Ez a tábla a webáruházba látogató és ott regisztrációt végrehajtó

felhasználók adatait tárolja. Ezen adatok alapján történik meg az oldalra való

belépés és a vásárlás során a termék postázása a felhasználó felé, illetve a

számlázás. Szintén ezen adatok alapján lehet felvenni a kapcsolatot a

felhasználóval. Fontosnak tartottam a postai és a számlázási adatok külön

tárolását, hiszen ezek eltérhetnek egymástól. Így nagyobb rugalmasságot ad a

felhasználó felé.

10

FELHASZNÁLÓK tábla:

Oszlopnév Oszloptípus Hossz

Azon INTEGER 11

vezetekNev VARCHAR 75

keresztNev VARCHAR 75

Email VARCHAR 155

cegNev VARCHAR 255

Jelszo VARCHAR 55

telefonszam INTEGER 11

cimOrszag VARCHAR 45

cimVaros VARCHAR 55

cimKozterulet VARCHAR 45

cimHazszam INTEGER 3

cimIranyitoszam INTEGER 4

szamlaCimOrszag VARCHAR 45

szamlaCimVaros VARCHAR 55

szamlaCimKozterulet VARCHAR 45

szamlaCimHazszam INTEGER 3

szamlaCimIranyitoszam INTEGER 4

Datum DATETIME 19

ADMINFELHASZNALOK tábla tartalma:

azon: Adminisztrátor azonosító

felhasználóiNev: Az adminisztrátor felhasználói neve

jelszo: Az adminisztrátor jelszava

rogzitesDatuma: A regisztráció dátuma

Ebben a táblában szerepeltetem azokat a felhasználókat, akik az

adminisztrációs felületre beléphetnek. Itt találhatók a belépéshez szükséges

adatok, felhasználói név, jelszó és a regisztráció dátuma.

11

ADMINFELHASZNALOK tábla:

Oszlopnév Oszloptípus Hossz

Azon INTEGER 2

felhasznaloiNev VARCHAR 55

Jelszo VARCHAR 55

rogzitesDatuma DATETIME 19

TERMEKTIPUS tábla tartalma:

azon: A terméktípus azonosítója

nev: A termektípus neve

datum: A terméktípus rögzítésének dátuma

Ebben a táblában találhatók a termékkategóriák. Ezek segítségével

tudom csoportokba rendezni a termékeket (mobiltelefon, headset, akkumlátor

stb.) így azokat könnyebben meg lehet találni a felületen. Ezek segítségével

akár többféle termék is regisztrálható az oldalon, kellő dinamizmust adva

ezzel az alkalmazásnak.

TERMEKTIPUS tábla:

Oszlopnév Oszloptípus Hossz

Azon INTEGER 2

Nev VARCHAR 95

Datum DATE 10

12

TERMEK tábla tartalma:

azon: A termék azonosítója

Gyartó: A termék gyártójának a neve

tipus: A termék típusszáma

termekTipus: A terméktipus táblában található terméktípus azonosító

kep: A termék képét tartalmazó file címe (URL)

ar: A termék ára

datum: A regisztráció dátuma

saleEffectiveDate: A termék eladhatóságának a kezdete

saleExpirationDate: A termék eladhatóságának a vége

Akciós: Egy indikátor ami megjelöli, hogy akciós-e a termék

vagy sem

A táblában a webáruházban található regisztrált termékek vannak

eltárolva. Itt található a gyártójuk, típusuk, áruk és rögzítési dátumuk is. Ezen

kívül még két dátum is szerepel itt, ami az eladhatóságot szabályozza. Ennek

azért láttam szükségét, mert így egy már létező termék megszüntetése esetén is

tovább tárolhatóak annak adatai, és szükség esetén az eladhatóság

manipulálásával ismét aktiválható kikerülve az ismételt regisztrációt.

TERMEK tábla:

Oszlopnév Oszloptípus Hossz

Azon INTEGER 5

Gyarto VARCHAR 55

Tipus VARCHAR 155

termekTipus INTEGER 2

Kep VARCHAR 155

Ar INTEGER 11

Datum DATE 10

saleEffectiveDate DATE 10

13

saleExpirationDate DATE 10

Akcios INTEGER 1

TERMEKTULAJDONSAG tábla tartalma:

termekAzon: A TERMEK táblában található termékek azonosítója

rendszer900: Indikátor, a termék adott szolgáltatását jelzi (900MHz)

rendszer1800: Indikátor, a termék adott szolgáltatását jelzi (1800MHz)

rendszer1900: Indikátor, a termék adott szolgáltatását jelzi (1900MHz)

meret: A termék méretét jelzi (100x48x19.5)

akkumlator: A termék default akkumlátorának mérete (750 mAh Li-Pol)

Kijelzo: A termék kijelzőjének mérete, ha van (262000/176x220)

naptar: Indikátor, a termék adott szolgáltatását jelzi (naptár)

infra: Indikátor, a termék adott szolgáltatását jelzi (Infraport)

bluethooth: Indikátor, a termék adott szolgáltatását jelzi (bluethooth)

wap: Indikátor, a termék adott szolgáltatását jelzi (WAP)

mms: Indikátor, a termék adott szolgáltatását jelzi (MMS küldés)

gprs: Indikátor, a termék adott szolgáltatását jelzi (GPRS)

3g: Indikátor, a termék adott szolgáltatását jelzi (3G)

edge: Indikátor, a termék adott szolgáltatását jelzi (EDGE)

Kamera: A terméken található kamera felbontása, ha van (640x480)

datum: A terméktulajdonságok regisztrálásának dátuma

A táblában találhatók a termékekhez tartozó általános tulajdonságok,

technikai paraméterek. A TERMEK táblában szereplő azon – nevű

termékazonosító alapján hivatkoztam a TERMEK táblára és az ott azonosított

termékekhez rendelt tulajdonságokra. Olyan adatok tárolását terveztem itt,

amelyek segítségével egy körülbelüli képet kaphatunk a kiválasztott termék

szolgáltatásairól, fizikai paramétereikről, mint a méret, vagy a kijelző

felbontása.

14

TERMEKTULAJDONSAG tábla:

Oszlopnév Oszloptípus Hossz

termekAzon INTEGER 5

rendszer900 INTEGER 1

rendszer1800 INTEGER 1

rendszer1900 INTEGER 1

Meret VARCHAR 15

akkumlator VARCHAR 18

Kijelzo VARCHAR 25

Naptar INTEGER 1

Infra INTEGER 1

bluethooth INTEGER 1

Wap INTEGER 1

mms INTEGER 1

Gprs INTEGER 1

3g INTEGER 1

Edge INTEGER 1

Kamera VARCHAR 12

Datum DATETIME 19

HÍRLEVÉL tábla tartalma:

hirlevelAzon: Egy alap érték a hírlevél funkcióhoz

felhasznaloAzon: A regisztrált felhasználók azonosítója

A tábla azon felhasználók azonosítóját tartalmazza, akik feliratkoztak a

webáruház regisztrációs folyamata során a hírlevél szolgáltatásra. Így

egyértelműen látható az alkalmazást üzemeltető számára, hogy kinek kell

elküldeni az aktuális hírlevelet.

15

HIRLEVEL tábla:

Oszlopnév Oszloptípus Hossz

hirlevelAzon INTEGER 3

felhasznaloAzon INTEGER 11

BEVÁSÁRLO_KOCSI tábla tartalma:

Session_id A munkamenet azonosító

Termek_azon A TERMEK táblában található termékazonosító a kiválasztott

termék egyértelmű azonosításához

Termek_ar A TERMEK táblában található termékazonosítóhoz tartozó ár.

A lehetséges árváltozások miatt fontos itt is szerepeltetni a

termék megvásárláskor aktuális árát.

mennyiseg A megadott termékazonosító alatt található termék

megvásárolni kívánt darabszáma

Datum A termék kosárba tételének dátuma

Ebben a táblában találhatók a webáruházban kiválasztott és jövőbeni

megvásárlásra a kosárba helyezett termékek. Az adott termék árát itt is

eltároltam, így az esetleges termékárakban történő változások során is jól

nyomon követhető, hogy az adott termék milyen áron vásárolták meg,

elkerülve így az esetleges reklamációkat.

BEVASARLO_KOCSI tábla:

Oszlopnév Oszloptípus Hossz

Session_id VARCHAR 155

Termek_azon INTEGER 11

Termek_ar INTEGER 11

mennyiseg INTEGER 2

Datum DATETIME 19

16

REDELES_STATUSZ tábla tartalma:

azon: A rendelés státusz azonosítója

nev: A rendelés státusz neve

datum: A státusz regisztrálásának dátuma

Ebben a táblában található a rendelésekhez kapcsolt rendelési státusz.

Ezzel különíthetők el az új és a folyamatban lévő rendelések illetve azok,

amelyek már teljesítve lettek.

RENDELES_STATUSZ tábla:

Oszlopnév Oszloptípus Hossz

Azon INTEGER 1

Nev VARCHAR 15

Datum DATETIME 19

RENDELES tábla tartalma:

azon: A megrendelés azonosítója

felhasznalo_azon: A megrendelést leadó felhasználó azonosítója

Statusz: A megrendelés státusza

datum: A megrendelés dátuma

A tábla a ténylegesen megrendelés után a megrendelő, felhasználó

azonosítóját, a megrendelés státuszát és a megrendelés dátumát tartalmazza.

RENDELES tábla:

Oszlopnév Oszloptípus Hossz

Azon INTEGER 11

felhasznalo_azon INTEGER 11

Statusz INTEGER 1

Datum DATETIME 19

17

RENDELES_TERMEK tábla tartalma:

rendeles_azon: A rendelés azonosítója a RENDELES táblából

Termek_azon: A megrendelt termék azonosítója a TERMEK táblából

Termek_ar: A termek ára amit éppen a megrendelés pillanatában

tartalmazott a TERMEK tábla a megadott termékazonosító

alatt

mennyiseg: Megrendelt mennyiség

A tábla a RENDELES tábla kiegészítése, ahhoz kapcsolódik a rendelés

azonosítóján keresztül. Tartalmazza a megrendelt termékek azonosítóját, azok

árát és a megrendelt mennyiséget. Az termek árat a fent említett indokok miatt

itt is eltároltam. (bevásáró_kosár)

RENDELES_TERMEK tábla:

Oszlopnév Oszloptípus Hossz

rendeles_azon INTEGER 11

Termek_azon INTEGER 5

Termek_ar INTEGER 11

mennyiseg INTEGER 2

A fizikai megvalósításhoz a MySQL adatbázis szerverét használtam fel.

Ez egy többfelhasználós, többszálú, SQL-alapú relációs adatbázis-kezelő

szerver. A szoftver fejlesztője a svéd MySQL AB cég, amely kettős

licenceléssel teszi elérhetővé a MySQL-t; választható módon vagy a GPL,

vagy egy kereskedelmi licenc érvényes a felhasználásra. Az MySQL az egyik

legelterjedtebb adatbázis kezelő, aminek egyik oka lehet, hogy a teljesen nyílt

forráskódú LAMP (Linux–Apache–MySQL–PHP) összeállítás részeként

költség hatékony és egyszerűen beállítható megoldást ad dinamikus

webhelyek szolgáltatására. A MySQL adatbázisok adminisztrációjára a

mellékelt parancssori eszközöket (mysql és mysqladmin) használhatjuk. A

18

fejlesztés során én az EMS adatbázis kezelő felületét használtam és a

phpMyAdmin programot, de MySQL honlapjáról grafikus felületű

adminisztráló eszközök is letölthetők: MySQL Administrator és MySQL Query

Browser. A saját gépen történő fejlesztéshez én az EMS felületét találtam a

leghasznosabbnak. Egy jól átlátható és gyorsan működő rendszerről van szó,

amellyel tökéletesen épül a MySQL szervere fölé.

4.2. Felülettervezés

Az alkalmazás fejlesztése során az adatbázisban tárolt adatok

megjelenítése, azok rendezett, jól átlátható felületen való továbbítása a

felhasználó felé újabb tervezési feladatot jelentett. Egy egységes felület

megalkotását tűztem ki célul, szem előtt tartva a webes szabványokat. A

szabványok követése lehetővé teszi, hogy az oldal a böngészők nagy részén

ugyanolyan megjelenéssel, elvárt működéssel fusson. A böngészők jövőbeni

változatain is stabil működő rendszerre számíthatunk.

4.2.1. A tervezésben használt technikák

A HTML (Hyper Text Markup Language) nyelv helyett már az

XHTML (eXtensible Hyper Text Markup Language) nyelvet használtam fel a

tartalom megszerkesztésénél. Ez egy kiterjeszthető HTML nyelv. A

jelölőnyelv az XML (eXtendible Markup Language) egy alkalmazása, vagyis

XML eszközökkel is feldolgozható. A fejlesztés során nagy segítség, ha a

tartalom egyértelműen megmutatkozik, látható hol kezdődik, és hol végződik

az adott tartalmi rész. Ezt használva egy jól áttekinthető tartalmi vázat tudtam

alkotni, nem több ráfordított idővel mintha nem vettem volna figyelembe a

szabványokat. Érdemes megemlíteni az XHTML jelölőnyelv alapvető

szabályait:

XHTML: különleges követelményei

� Minden kezdőcímkének kötelezően kell egy lezáró párjának is lennie

� Különleges DOCTYPE meghatározására van szükség

19

� Minden elemet, jellemzőt és értéket kisbetűvel kell írni

� Minden értéket idézőjelben kell megadni, ami lehet egyes (angolos) vagy

kettes (normál)

� Minden jellemzőnek egyértelműen meg kell adni az értékét

A XHTML tag-jei segítségével leírható a webes tartalom. Az így leírt

tartalmat a böngészők már képesek megjeleníteni. Így kaptam egy vázat, amit

aztán később a megrendelő igényei szerint tudok megjeleníteni, formázni. A

megjelenítés a böngészők sajátossága lesz alapesetben, mivel nem szabtam

meg, hogy mely tag-ek milyen formában és hol jelenhetnek meg az oldalon.

Erre szolgál a CSS (Cascading Style Sheets) azaz stíluslapok, amelyek

meghatározzák a tényleges megjelenést.

A mai böngészők mindegyike támogatja a CSS-t, de kisebb eltérések

azért vannak az egyes böngészők között. Ezért, mivel a szabványokat

szerettem volna követni és egy jól strukturált rendszer fejlesztése a cél a CSS

használatával valósítottam meg a tartalom formába öntését. Általában külön

állományban tároljuk a stíluslapokat css kiterjesztéssel, így én is ezt tettem.

Így, ha a stílusleíró kódot külön helyezem el a tartalomtól leválasztva

gyorsabb betöltési idővel számolhatok. A CSS stílusok segítségével akár eltérő

megjelenítést is biztosíthatok a tartalomnak. Egy HTML tag többféle

stílusleíró szabályt is kaphat, attól függetlenül, hogy hol helyezkedik el a

dokumentum felépítésében. A stílusok a következő sorrendben fognak

érvényesülni prioritási sorrend szerint növekvően:

CSS: stílusok szabályainak rangsora

� A böngésző alapbeállítása

� Külső stíluslap

� Beágyazott stílus

� Szövegközi stílus

20

Az alapszintaktika három elemet különböztet meg: kiválasztó,

tulajdonság, érték. Pl.:( kiválasztó { tulajdonság: érték } ). A megjeleníteni

kívánt elemre többféle módon hivatkozhatunk, használhatunk többféle

kijelölőt. Kiválaszthatjuk a megjelenítendő tag-et, kiválasztót és adhatunk neki

egy stílust.

Ezen kívül választhatjuk még a következőket:

� Felsorolás

Egyszerre akár több kiválasztóra is érvényesíthetjük a formázást. Ekkor

a kiválasztókat egymás után vesszővel elválasztva kell felsorolni.

h1, h2, h3, h4 {color: green;}

� Osztály kiválasztó

Ennek segítségével más-más módon tudjuk megjeleníteni az egyes

osztályokba sorolt elemek tartalmát. Ezt a class kulcsszó használatával

érhetjük el.

p.right {text-align: right}

p.left {text-align: left}

� Azonosító alapú szétválasztás

A HTML elemeknek megadhatunk egy id tulajdonságot. Így az egyedi

id-vel rendelkező elemekhez speciális formázást határozhatunk meg.

CSS-ben a # segítségével tudunk elemet id segítségével kiválasztani.

A következő példa a kiemel elemet fogja azonosítani:

#kiemel {color: red;}

Ezek használatával jól elkülöníthető blokkokra tudtam osztani a

tartalmi részeket, így azok megjelenítése egyértelművé, a kódban is jól

kivehetővé vált. A CSS további mélyebb áttekintésére a dolgozat keretein

belül nincs lehetőség, de rengeteg kiadvány, könyv és internetes portál segít

eligazodni a CSS világában.

21

Az alkalmazást két jól elkülöníthető felületre osztotam, egy

felhasználói felületre és egy adminisztrátori felületre. Mind a két esetben

hasonló felépítésre és stílusra törekedtem, de a tartalmak tekintetében eltérnek

egymástól. Mind a két esetben a fent említett szabványokat és nyelveket

használtam fel a megvalósításhoz. Nagy segítséget jelentett a fejlesztésben a

FIREFOX egy beépülő modulja a Web Developer, amely egy speciális

felületet és rengeteg lehetőséget biztosít a webfejlesztéshez. Ez a tool

ingyenesen letölthető a mozilla – Firefox Add-ons oldaláról és telepítés után

azonnal hozzáférhetők az újonnan szerzett szolgáltatások

(https://addons.mozilla.org/firefox/60/). Az első igazán nagy segítséget a CSS

szabályainak, használatának a megértése terén nyújtotta. A CSS menü alatt

lehetőség van az éppen aktuális oldal stíluslapjának a megtekintésére View

CSS. Így látható, hogy az oldal mögött milyen megoldásokat alkalmazott a

fejlesztő. A menüpontban az Edit CSS egy szerkesztőfelület ahol élőben

szerkeszthető és a képernyőn azonnal látható a stíluslapban történt változás.

Ennek köszönhetően sokkal gördülékenyebb volt a felületek tervezése,

fejlesztése. Az alkalmazott CSS szabályokat azonnal át tudtam vinni a

tényleges css file-ba így a tervezett oldal megjelenése már egy jól

megtervezett stíluslap eredménye volt.

Mind a két felület (felhasználói és admin) bővelkedik űrlapokban. Egy

jó és szabványos űrlap készítése nehéz feladat, amiben a fenti tool egy másik

szolgáltatása segített nekem, amely a Forms menüpont alatt található. Itt a

Display Form Details funkcióval azonnal meg tudtam jeleníteni a weblapon

található form-ok tulajdonságait, attribútumait. A View From Information az

oldalon található űrlapok tulajdonságait egy külön felületre szedve táblázatos

formában is meg tudja jeleníteni kiemelve ezeket a grafikus tartalomból, nagy

segítséget biztosítva a fejlesztéshez. Ezek használatával már már otthonosan

mozogtam a tervezett felületen, de az igazi nagy segítség az Outline menü

alatt volt elrejtve. Az itt található kis alkalmazások arra szolgálnak, hogy

segítségükkel behatárolhassuk a különböző blokk és egyéb elemek határait.

22

Bekapcsolva azonnal láthatóvá vált, hogy hol helyezkednek el a blokk-ok

végei, az űrlapok határai és a cella, táblahatárok. Így már jól látható, hogy hol

van esetleg tervezési hiba. Javítani tudtam az egymásba csúszó elemek

értékeit, fel tudtam mérni ténylegesen mi mekkora területet foglal és pontosan

hol található az oldalon.

4.2.2. Adminisztrációs felület

Az első felület, amit megterveztem az adminisztrációs felület volt,

hiszen ez alapján tudom feltölteni az adatbázist, és ez alapján tudom a

későbbiekben manipulálni, figyelemmel kísérni a webáruház termékeit,

megrendeléseit.

A felület a következő alapvető területekre tagolódik:

� Fejléc

� Bal menüsáv

� Tartalom

� Lábléc

Az adminisztrátori felület belépés után a termékek menüpont alatt.

23

A felület megtervezésekor figyeltem a fontosabb menüpontok minél

kontrasztosabb megjelenítésére. Ezért kerültek jól látható kiemelt helyre, a bal

menüsávba. Ugyanitt kapott helyet az oldalra való belépéshez szolgáló belépés

űrlap. A tartalom megjelenítése nagyobb területet kíván, így azt középre a

weboldal kétharmadát kitöltő felületre helyeztem el. Így a legfontosabb

információk kellő teret kapnak a megjelenítés során. A felület egyértelműen

jól elkülönülő blokkokra bontott, így könnyen áttekinthető a rajta található

megjelenített információ. A weboldalon jól megtervezett navigáció segít a

tájékozódásban. Itt figyeltem arra, hogy minden oldalról egyszerűen és

gyorsan vissza lehessen jutni a főoldalra.

4.2.3. Felhasználói felület

Ez maga a webáruház felülete. Az alapstílus ugyanaz, mint az

adminisztrációs oldalon bővítve egy plusz oszloppal és egyéb tartalmi

elemekkel, így az adminisztrátor mindig tudja, hogy éppen hol,melyik

felületen jár. Hasonló stílus leképzése segíti az eligazodást a két felült között.

Itt lehet majd böngészni az áruház kínálatát képező termékek között. Szintén

itt lehet regisztrálni, belépni és vásárolni is. Mivel nagy mennyiségű

információt kell megjeleníteni ezért itt a fenti logikát kiegészítettem egy újabb

oszloppal.

A portál felülete a következő alapvető területekre tagolódik:

� Főmenü

� Fejléc

� Bal menüsáv

� Tartalom

� Jobb menüsáv

� Lábléc

Jól látható helyre került a főmenü, kihasználva a színek adta kontrasztot

a sötét háttér és a világos betűszínek között. A bal menüsávba egy

24

dinamikusan változó menüt helyeztem el, ami a webáruház tartalmának

megfelelően változik. Így a főmenüvel biztosítottam az alapvető funkciók

folyamatos elérhetőségét és a dinamikus bal menüsáv használatával mindig az

aktuális az adatbázisba regisztrált termékek megjelenítését.

A felhasználói felület, a samsung termékeinek listája

A termékkategóriákat a többi tartalomtól jól elkülönülő helyre terveztem A

tartalmat táblázat formájában jelenítettem meg, így egy jól áttekinthető

felületet tudtam kialakítani.

5. Megvalósítás

A megvalósítás során az előre átgondolt és megtervezett rendszer

tényleges kódokba való átültetését végzem. Mivel a leendő alkalmazás

megtervezésekor olyan szoftvereket és technológiákat szerettem volna

felhasználni, amelyek szabadon hozzáférhetőek, nyílt forráskódúak, ezért a

rendszert PHP alapokra helyeztem, támogatva MySQL adatbázissal és Apache

webszerverrel.

25

5.1. A megvalósításban felhasznált technológiák

A tényleges fejlesztés előtt szükséges egy környezet kialakítása, ami

támogatja és futtatja a megírt kódot. Az interneten többféle csomag található,

amely szabadon hozzáférhető és egy teljes keretrendszert biztosít a

fejlesztéshez. Ilyen például az Apache2Triad, ami Windows 2000/XP alá

telepítve tartalmaz Apache-ot, PHP 5-öt MySQL-t és még jó néhány hasznos

programot. A fejlesztés megkezdésekor és a fejlesztés során a XAMPP 1.5-ös

verziót használtam. Ez szintén egy szabadon hozzáférhető telepítő csomag,

amely a telepítés után egy azonnal használható fejlesztői környezetet helyez el

a gépünkön, így szinte azonnal neki kezdhettem a kódolásnak a rendszer

alapvető paramétereinek módosítása nélkül. Persze azért nem árt tisztában

lenni a kódot futtató rendszer tudásával, tulajdonságaival.

Az Apache egy nyílt forráskódú webszerver, ami azt jelenti, hogy

program teljes forráskódja szabadon hozzáférhető. A legújabb verzió

letölthető a http://www.apache.org/ honlapról. A szoftver platform független,

így Windows, Linux és akár OS/2 – es környezeten is futtatható. Mivel

alapvetően a web-re fejlesztünk, elengedhetetlen egy webszerver megléte a

gépen, hiszen ez a lefejlesztett kód működésének ellenőrzésekor

nélkülözhetetlen. Nagy segítséget jelentett, hogy a fejlesztés során

folyamatosan tudtam követni a kód futásának eredményét.

A PHP (Hypertext Preprocessor) egy kiszolgáló oldali parancsnyelv,

amit jellemzően HTML oldalakon használnak. Népszerűsége az új verziók

megjelenésével egyre inkább emelkedik. Egy felmérés szerint 1999-ben több

mint 1 millió kiszolgálón használták, ez a szám 2003-ra majdnem 14 millióra

nőtt. A PHP-t kifejezetten a világhálóra írták, így azokra a problémákra,

amelyekkel a webprogramozók nap, mint nap szembesülnek, magában a

nyelvben megtaláljuk a megoldásokat. Beépített SQL adatbáziskönyvtárat

kínál, így számos adatbázisfajtát önműködően támogat. Egyaránt használják

szerveroldali, parancssori és ablakozós alkalmazások megvalósítására. Ezen

26

érvek és a PHP nyelv emberközeli felépítése miatt döntöttem amellett, hogy a

kódot ezen a nyelven fejlesztem le. Gyorsan és hatékonyan tudtam egy

viszonylag nagy kapacitású keretrendszert építeni vele, ami a mai igényeknek

megfelelő dinamikus webes alkalmazás támogatására szolgál.

A tervezéskor és a megvalósításkor is célom volt a rendszert úgy

kialakítani, hogy az már az Objektum Orientált Programozási szemléletnek

megfeleljen és az objektum orientáció minden jellegzetességét magába zárja.

Erre kiváló lehetőséget adott a PHP 5-ös verziója, ami már hiánytalanul

biztosítja az objektum központú programozáshoz szükséges alapokat,

technikákat, szintaktikai elemeket. A fent említett verzió a következő

újdonságokat tartalmazza, amik egy részét igénybe is vette a fejlesztés során:

� Beépített XML támogatás

� SQLite SQL könyvtár

� Privát, védett tagfüggvények támogatása az osztályokban

� Osztályállandók támogatása

� A függvényeknek és tagfüggvényeknek átadott objektum hivatkozásként

adódik át

� Statikus függvények és tulajdonságok támogatása

� Támogatja az elvont (abstract) osztályokat és felületeket

Az OOP egy programozási, tervezési szemlélet, amelynek nagy előnye,

hogy átláthatóbbá, könnyebben kezelhetővé és mobilabbá teszi a kódot. Ennek

a szemléletnek az alkalmazásával olyan kódot tudtam írni, ami többször is

felhasználható, hordozható így a későbbiekben egyes részei akár

újrahasznosíthatóak, megspórolva ezzel többórányi újabb fejlesztési munkát.

Az alapja az objektum, ami változók és függvények egybezárt

csomagja. Az objektum belső működése nagyrészt elrejtett az objektumot

használók elől, úgy hogy csak hozzáférést biztosítunk, amin keresztül

27

kérelmeket küldhetünk, és információt kaphatunk az objektumtól. Ezzel egy

stabil működésű kódot hozhattam létre, amelyben a fontos és mások számára

hozzá nem férhető értékek, változók jól, biztonságosan kezelhetővé váltak a

külvilágtól elzárva az objektumok belsejében. Ezek az úgynevezett

tagváltozók, amelyekhez a tagfüggvényeken (metódusok) keresztül lehet

hozzáférni. Így ki tudtam zárni, bizonyos nem kívánt működési lehetőségeket.

Az objektumközpontú programok legnagyobb előnye a kód újrahasznosítása.

A létrehozott osztályokat egységbe zárt objektumok létrehozására használjuk,

így azokat egyszerűen át tudom vinni egyik projektből a másikba.

Lehetőség van gyermekosztályokat is létrehozni, (öröklés) amik a szülő

tulajdonságait öröklik és képesek azt kiegészíteni, módosítani. Ez a módszer

több alkalommal is megfordult a kódolásom során, remek alkalmat ad

tagfüggvények, változók tovább adására, megkönnyítve, ezzel a fejlesztést, a

későbbiekben átlátható kódot hozva létre.

Példa az öröklés megvalósítására:

class Felhasznalo extends dbKapcsolat {

}

Az általam tervezett és létrehozott objektumcsaládok, szorosan

egymásra épülnek, és az alaptulajdonságaik folyamatosan bővülnek. Mind

szélesebb körben használható egyre több tulajdonsággal bíró, de átlátható

hierarchiát hozva létre a kódban.

Ahhoz, hogy létre tudjunk hozni egy objektumot először létre kell hozni

a sablont amire épül. Ezt a sablont hívjuk osztálynak (class). Ezt a

következőképpen tudjuk megtenni:

28

class dbKapcsolat

{

public $db;

public function __construct()

{

$this->db = Kapcsolat::getInstance();

}

}

(Részlet a megvalósított webalkalmazás kódjából (ddKapcsolat osztály))

Az osztályok létrehozásakor két különleges függvény meghívására,

megírására is szükség van. Az egyiket úgy nevezik, hogy konstruktor és arra

szolgál, hogy az osztály tulajdonságait beállítsuk vele. A függvény egy új

objektum létrehozásakor fut le automatikusan a new kulcsszó kiadásakor.

Konstruktort kétféleképpen készíthetünk a PHP 5-ös verziójában. A

konstruktor neve megegyező az osztály nevével. Ebben az esetben a program

tudja, hogy ez a függvény a konstruktor. Egy másik lehetőség a __construct()

függvény. Itt az osztály neve helyett ezt a függvényhívást kell végrehajtanunk.

Példa a konstruktor használatára:

public function __construct($azon = null) {

}

A másik függvény a destruktor. Ez arra szolgál, hogy az objektum

elvégezze a hozzá kapcsolódó utófeladatokat. Ez általában akkor következik

be, ha a kód egyetlen futó folyamata sem hivatkozik a már adott objektumra.

Ahogy a konstruktor esetében függvényhívásra van szükség, addig a

destruktort esetében azt a PHP automatikusan megteszi helyettem.

29

Példa a destruktor használatára.

public function __destruct() {

$this->lezar();

}

Fontos volt számomra a tervezés során, hogy a változókat és

tagfüggvényeket csak annyira engedjem láttatni és hozzáférést adni a

felhasználóknak amennyire a programműködéshez szükséges, biztosítva ezzel

az elvárt működést. Így a kódban folyamatosan figyelemmel kísértem a

tagváltozók és tagfüggvények hozzáférésének megfelelő biztosítását. Ezt az

OOP három formában biztosítja, public, protected, és privat kulcsszavak

megjelölésével. Ezek biztosítják, hogy az osztályokból csak annyit fedjünk fel

amennyi feltétlenül szükséges. Ezt a három korlátozást mind az osztályok

mind a tagváltozók és a tagfüggvények elkészítése során alkalmaztam.

Példa a korlátozások használatára változónál:

public $lekerdezOsszAdat;

Példa a korlátozások használatára tagfüggvény esetén:

public function __construct($azon = null) {

parent::__construct();

//azonosító elementése

$this->azon = (int)$azon;

}

}

A fentieken kívül az egyik legfontosabb újítás a PHP 5 –ben a statikus

változók és függvények használatának lehetősége. Ez megkönnyítette a

30

munkámat olyan esetekben, amikor egy függvényhívás nem követeli

feltétlenül egy objektum létrehozását. Tehát a függvény és a benne található

eljárások nem kapcsolódnak közvetlenül az objektum tulajdonságaihoz.

Ezeket a függvényeket static kulcsszóval megjelölve statikussá tehetjük azaz

közvetlenül hivatkozhatunk rájuk. Ezek használatával meggyorsítható a kód

lefutása.

Példa a statikus függvényre:

public static function kilepes() {

$_SESSION['felhasznalo_azon'] = null;

unset($_SESSION['felhasznalo_azon']);

}

A fent leírt OOP szemléletnek köszönhetően, figyelve a szintaktikai

elemek megfelelő használatára, olyan kódot sikerült alkotnom, amely

bármikor felhasználható egy újabb fejlesztés során. A tervezésre és a

kivitelezésre nem ment el több idő, mintha egy általános függvényalapú

szemléletet követtem volna. Tapasztalataim szerint az OOP-s rendszer

stabilabb, jobban átlátható működést és kódot eredményezett. Az elvárt

eredmények kiszámíthatóbbak. Előre lehet tervezni a kód alapján a várható

működést. A hibajavítás terén is sokat segített az előre megtervezett

keretrendszer. Hibák során egyértelműen beazonosítható volt számomra a hiba

forrása, így a javításukat is gyorsan el tudtam végezni. Figyelembe véve, hogy

a legtöbb programozási nyelvben és a programfejlesztések során az objektum

központú gondolkodást tartják szem előtt, nagy előnynek érzem, hogy a

fentiek használatával alkottam meg a webes alkalmazásomat, kihasználva és

elsajátítva ezzel az OOP előnyeit, tulajdonságait.

A fejlesztés során próbáltam a már meglévő –fent említett- és használt

technológiák listáját szélesíteni és a ma használatban levő, úgynevezett web 2

31

-es technikák egy kis részét belecsempészni az alkalmazásba. Egyre inkább

elterjedt ilyen technológia az AJAX. Ennek segítségével egy dinamikus

keresőmodult építettem fel, amely igazán esztétikus és hasznos része lett a

webáruháznak, nem is beszélve a mögötte álló „friss” technológia

alkalmazásáról. Az AJAX egy webfejlesztési technika (Asynchronous

JavaScript and XML), amelyet interaktív webalkalmazások létrehozására

használnak. Ennek használata során a weblap viszonylag kevés adatot cserél a

szerverrel, így annak nem kell az egész weblapot újratölteni, csak az éppen

aktuális részt. Mivel ezzel a technikával egy keresőlistát készítettem, így itt is

csak egy minimális adatmennyiség indul a szerver felé és onnan vissza. A

technika kiválasztásával felhasználói élmény fokozása volt a célom.

Az Ajax a következő technikák kombinációja:

� XHTML (vagy HTML) és CSS a tartalom leírására és formázására.

� DOM kliens oldali script nyelvekkel kezelve a dinamikus megjelenítés és a

már megjelenített információ együttműködésének kialakítására.

� XMLHttpRequest objektum az adatok asszinkron kezelésére a kliens és a

webszerver között. Néhány Ajax keretrendszer esetén és bizonyos

helyzetekben IFrame-et használnak XMLHttpRequest objektum helyett.

� XML formátumot használnak legtöbbször az adattovábbításra a kliens és a

szerver között, bár más formátumok is megfelelnek a célnak, mint a

formázott HTML vagy a sima szöveg.

A használat során az Ajax-os oldala viselkedése sokkal felhasználó közelibb,

és dinamikusabb, mint ha egy desktop alkalmazást használnánk. Nem kell

várni a teljes weboldal újratöltésére, éppen csak az aktuális blokk adatait

várjuk a szervertől. Minden más változatlan marad, így csak a feltétlenül

szükséges minimális adat fut keresztül a hálózaton. A technológia tényleges

alkalmazásához letölthetünk úgynevezett Ajax Framework-öket , de akár meg

is írhatjuk a működéséhez szükséges kódot. Saját tapasztalatszerzés céljára

mind a két esetet kipróbáltam, de a mostani fejlesztés során a JQuery

függvénygyűjteményt használtam, ami szintén egy ingyenesen hozzáférhető

32

javascript könyvtár. A könyvtár letölthető a hivatalos oldalról

http://jquery.com/. A javascript könyvtárak elsősorban a böngészők

inkompatibilitása miatt jöttek létre. Saját jscript tapasztalataim során sok

bosszúságot és fejtörést okozott, hogy hogyan is oldjam meg a fenti

problémát. A hosszadalmas kódok és elkerülő technikák helyett én is a fenti

megoldást, egy sokkal tisztább és rugalmasabb rendszert választottam. Így

biztosítva van a jscript kódok működése platformtól függetlenül. Az

XMLHTTPrequest kezelés szintén fontos része az Ajax-nak, amit a fenti kis

alkalmazás remekül elvégez. Segítségével egy perc alatt végrehajthattam

asszinkron adatátvitel. Lehetőség van az adatok GET illetve POST formában

való küldésére és a szervertől a választ XML vagy TEXT formátumba

kaphatjuk vissza.

Példa a JQuery Ajax támogatására (GET):

url: a betöltendő oldal címét

paraméterek: a szerver felé küldendő paramétereket

callback: ez egy függvény, ami végrehajtásra kerül, ha sikeresen

betöltődtek a kért adatok

$.get("test.cgi",

{ name: "John", time: "2pm" },

function(data){

alert("Data Loaded: " + data);

}

);

Gyakorlatilag ilyen egyszerűen tudtam én is beültetni a saját kódomba

az Ajax használatát színesítve ezzel a felhasználói élményt, és gazdagabbá

téve a felsorakoztatott technológiák listáját nem is beszélve a tapasztalatokról.

33

5.2. A rendszer logikai működése

A fejlesztés során ez volt az a rész, ahol igazán nagy mennyiségű

tapasztalatra tettem szert. Itt tudtam igazán belelátni a programozási nyelv

szintaktikai és logikai működésébe. A tervezés során elkészült dokumentáció

felhasználásával már kialakult egy kép a program felépítéséről, működéséről.

A kódolásra fordított idő lerövidülése is ennek volt köszönhető. Látványos

volt a fejlődés a számomra a kezdeti bizonytalanságból, arra a pontra való

eljutásig, amikor már tudatosan, a felépített rendszert ismerve tudtam a

fejlesztést végezni.

A rendszer alapvetően egy úgynevezett keretprogramból áll, ami a

teljes függvényhívást, adatkérést, fogadást vezérli, így biztosítottam, hogy

mindig a megfelelő függvények kerüljenek meghívásra. Ez kiszámítható,

stabil működést biztosít a program számára. A keretprogram felett osztályok

találhatók, amelyek csoportokba gyűjtik az azonos területre specifikált

függvényeket. Ezeket úgynevezett modul osztályok implementálják, és ezeken

keresztül futnak át a kérések a felhasználótól. A felhasználó a template-en

keresztül látja a kért információt, így jól elkülöníthetőek a különböző

funkcionalitást ellátó kódok. Ennek köszönhetően egy jól átlátható rendszert

tudtam alkotni, ahol könnyen nyomon követhető és kiszámítható a futási

eredmény.

34

A működési folyamatot vázlatszerűen ábrázolja a csatolt kép:

A fejlesztés során létrehozott file-ok neveinél szerettem utalni annak

tartalmára, a programban való szerepére. Így megkülönböztettem az

osztályokat név.class.php, a template-ket név.tpl.php és az include file-okat is

név.inc.php névvel. Így ránézésre látható, hogy milyen file-ról és körülbelül

milyen tartalomról, funkcionalitásról lehet szó.

5.3. Osztályok

A programban az objektum orientált szemléletnek megfelelően

osztályokba fogtam össze azokat a tagváltozókat és tagfüggvényeket, amelyek

azonos adatkörön hajtanak végre műveleteket. Így mindig pontosan tudható,

hogy egy bizonyos feladat elvégzéséhez mely osztály implementálására és

mely függvény meghívására van szükség. A tervezés során egy külön osztályt

alkottam az adatbázissal való kapcsolattartásra. Ez a KAPCSOLAT osztály. A

többi osztály ezen keresztül, mint egy kapcsolófelület kapnak elérést az

adatbázis felé. Rajta keresztül küldhetnek kéréseket és fogadhatnak

válaszokat. Ezzel a felülettel biztosítottam, hogy ne legyenek a programban

behatárolhatatlan adatbázis műveletek. A kapcsolat felépítéséhez szükséges,

kötelezően megadandó paramétereket egy külön file-ban helyeztem el, így

biztosítva a kód hordozhatóságát és egyszerű kezelhetőségét (site.inc.php).

define('DB_KISZOLGALO', 'localhost');

define('DB_FELHASZNALO', 'root');

define('DB_JELSZO', '');

define('DB_ADATBAZIS', 'Online_Shop_1_0');

35

Az osztályban két csoportra osztottam az adatbázis műveleteket. Az első

csoport a lekérdezések, amelyek siker esetén egy eredménytömbbel térnek

vissza és a futtatásokra, amelyek eredménye, hogy sikeres volt-e a lefutás

vagy sem. A lekérdez függvény egy másik osztályt használ, ami ténylegesen

segít feldolgozni az eredményhalmazt. A tervezés során már volt

tapasztalatom a sorozatos adatbáziskérelmek és azok eredményeinek

feldolgozásában. Jól tudtam, hogy milyen nehéz ezeket egymás után

hatékonyan kezelni és kinyerni belőlük a szükséges információt. Ennek

kezelésére született meg a lekérdezés osztály. (lekerdezes.class.php) Ebben

egy iterátor segítségével végzem el az eredménytömb feldolgozását. Ez

tulajdonképpen bizonyos műveletek ismétlését teszi lehetővé. A következő

függvényekből áll:

public function next() {

$this->row = $this->getTomb();

$this->counter++;

}

public function valid() {

return $this->row != false;

}

public function current() {

return $this->row;

}

public function key() {

return $this->counter;

}

public function rewind() {

$this->futtat();

}

A függvénynevekből már lehet következtetni azok funkcióira és az egész

működésére is. Az iterátor használatával bármikor kezelni tudtam fennakadás

nélkül az egymás után történt SQL lekérdezések eredményeit. Egységes

36

kezelésüknek köszönhetően sokkal gördülékenyebbé vált számomra a

fejlesztés menete.

Jellemzően két olyan osztály van, ami mind a két felületen a felhasználói és az

adminisztrációs felületen is ugyanaz. Ez pedig a felhasználó és a termék

osztály. Ezek csoportok is egyben. A termékosztályba helyeztem el az összes

terméktáblákban manipulációt végző függvényt, míg a felhasználóosztályba a

felhasználótáblákban műveletet végző függvények kaptak helyet. Mind a két

osztály ugyanazt a felépítési elvet követi. Mivel a műveletek azonosak, csak

céltáblák és a céladatok eltérőek, ezért azonos struktúra alapján építettem fel

őket. Olyan alapvető folyamatokat végrehajtó függvényekből állnak, mint az

adatok listázása (listaz) a termékek illetve felhasználók adatainak módosítása

(modosit), az új adatok felvitele, regisztráció (regisztal) és a feleslegessé vált

adatok törlése (torol). Mind a két osztály számára külső felületeket

biztosítottam a bennük található tagváltozók és tagfüggvények elérésére, így

elrejtettem a belső működéshez fontos adatokat a felhasználók elől. A

tagváltozókat a get és a set függvények segítségével lehet lekérdezni, illetve

azok értékeit beállítani.

A fenti említett osztályokat a modul osztályok implementálják. A

tervezés során ezeket az osztályokat bíztam meg a felhasználótól érkezett

kérések fogadásával. Ide érkeznek az elküldött űrlapok adatai, itt történik a

jogosultságok ellenőrzése. Azért nagyon fontosak a modul osztályok, mert a

működés tényleges logikáját ezekbe az osztályokba építettem bele, ezek az

osztályok végzik azt el. Itt ellenőrzöm, a $_SESSION[’felhasznalo_azon’]

alapján, hogy van e belépett felhasználó a rendszerbe és itt ellenőrzöm, hogy

az elküldött űrlapok minden kötelező adattal rendelkeznek-e, ami elő van írva.

A felhasználó felé a tényleges felület kialakítását és a kért adatok

kiíratását a template-ek végzik. Ezek HTML oldalak, amelyek az adatbázisban

szereplő adatok alapján épülnek fel dinamikusan a modul osztályokkal

közreműködve. Látható, hogy a működés során jól elkülöníthetőek lettek a

PHP kódok a HTML kódoktól. Ennek egyik előnyét abban látom, hogy

mindig pontosan meg tudom határozni, hogy milyen kódok végzik az

37

adathívásokat, és milyen kódokban kereshetem a megjelenítésért felelős tag-

eket.

5.4. Adminisztrátori felület megvalósítása

Az adminisztrátori felület volt az, amelyiket először elkészítettem. Ez a

felület lehetővé teszi az adatbázisban található adatok manipulációját.

Az oldalra való belépéshez, mivel itt meg kellett oldanom, hogy illetéktelenek

ne lépjenek be, egy belépési form-ot készítettem. Ide egy felhasználói név és

egy jelszó megadásával lehet belépni. Az ide tartozó jogosultsági adatokat az

adminfelhasználók táblába tároltam el. A jelszó kódolva van MD5-ös

algoritmussal. Alapvetően a rendszer ezen felületét egy felhasználósra

terveztem, de ha szükséges egy egyszerű űrlappal és jogosultságkezeléssel

lefejleszthető egy modul, amivel akár az adminfelhasználó tábla adatai is

manipulálhatóak. Így nem lesz alap felhasználói név és jelszó megadva, ami a

későbbi biztonság szempontjából egyébként fontos lehet az alkalmazásban.

Külön menüpontok alatt érhetőek el a felhasználók és a termékek

adatai. Ezeket az adatbázison keresztül lekért adatokat, a jobb átláthatóság

miatt oldalszámozott formában jelenítem meg a felületen. Ehhez a MySQL

egy megoldását használtam fel a LIMIT értéket. Az SQL lekérdezésben meg

kellett adnom egy kezdeti értéket, hogy a lekérdezett adatok hányadik sorától

olvasson és pontosan mennyi sort. Ezek után egy ciklussal és a teljes

lekérdezés sorának összegével létrehoztam a linkeket mind számozott, mind

előre, hátra lapozható formában. A felhasználók menüpont alatt az adott

felhasználóhoz tartozó személyes adatokra a következő műveletek

megengedettek: az adatok módosítása, és a feleslegessé vált adatok törlése.

Ezen a felületen nem megengedett az új felhasználó regisztrációja. A

termékoldalon a regisztráció ad lehetőséget az új termékek felvitelére. Ezen

kívül a felvitt adatokat tudom módosítani és törölni. A megjelenítést egy

táblázatos formába beágyazott űrlapon keresztül érem el. A termékoldalon

ahol dátumot kell megadni, ott megkönnyítettem a felvitelt egy felugró naptár

alkalmazásával. Ezt egy ingyenesen letölthető program, a datetimepicker

38

segítségével alakította ki. Ennek segítségével a felület kezelése is

látványosabbá vált.

5.5. Felhasználói felület megvalósítása

A felhasználói felület, azaz a webáruház működése jóval egyszerűbb,

mint az adminisztrációs oldal esetén. Ugyanarra az alapra épül, de jóval

kevesebb funkciót valósít meg. Így ezt a felületet gyorsabban és az előző

felület technikáit és logikáit felhasználva hatékonyabban tudtam felépíteni. A

működés alapja itt is az adatbázisból érkezett adatok táblázatos formában való

megjelenítése, felhasználva az adminisztrációs oldalon használt lapozási

formát. Az oldalon található termék kategóriák dinamikusan változnak annak

függvényében, hogy az adminisztrátori felületen milyen termékmanipulációt

hajt végre a rendszer gazdája. Ezt a dinamizmust vittem át a termékkereső

felületre is. Ez egy Ajax technikát használó dinamikus listákból álló rendszer.

Három listából áll, termék kategóriák, gyártók és típusok. A fejlesztés során

ügyeltem arra, hogy a keresés során, a kiválasztott termék kategória alatt

található gyártók jelenjenek csak meg a gyártók listában. Ezek után konkrét

gyártót is választva már csak az arra a gyártóra jellemző termékek jelennek

meg a típusok listában. Így le tudtam rövidíteni a felhasználó keresésre

fordított időt. Az oldalon lehetőség van az új felhasználók regisztrációjára. Ez

egy regisztrációs űrlap segítségével lehetséges. A vásárlás, postázás és a

számlázáshoz szükséges adatokat itt lehet rögzíteni, ezért fontos ezek pontos

megadása. Ezt nem bízom a felhasználóra, így bizonyos kritériumokat

állítottam fel a kitöltéshez. Ezeket az úgynevezett kötelező mezőket a

kliensoldalon ellenőrzöm első sorban javascript segítségével. Ezt úgy teszem

meg, hogy amikor a felhasználó a regisztrál gombra kattint először egy

javascript függvény hívódok meg, ami ellenőrzi a szükséges adatokat. Ha van

olyan adat, ami nincs kitöltve, akkor arra felhívom a felhasználó figyelmét egy

alert-et használva, illetve a hiányosan kitöltött sorok mellé css segítségével

egy piros csillagot is teszek. Amennyiben az adatok helyesek PHP oldalon is

ellenőrzöm a beérkezett adatokat. Ennek azért láttam szükség szerveroldalon

39

is, mert a felhasználó bármikor kikapcsolhatja böngészőjében a javascript

futtatását, így iktatva ki az elsődleges ellenőrzési rendszert. A

termékvásárlásnál figyelnem kellett, hogy van e belépett felhasználó, ha nincs,

nem engedélyezett a vásárlás. Ezt a $_SESSION[’felhasznalo_azon’]

ellenőrzésével oldottam meg. Amennyiben van felhasználó azonosító megadva

a session-ben, akkor továbblép a felület a pénztár oldalra, ha nincs, átlép a

belépés oldalra. Abban az esetben, amennyiben volt belépett felhasználó a

rendszer a pénztár oldalra lép. Itt táblázatokba foglaltan jelenítettem meg az

adott felhasználó postázási és számlázási címét, valamit a rendelt_termékek

alapján a vásárolni kívánt termékek listáját. Ide még terveztem egy utólagos

ellenőrzést az adatok helyességét illetően. Amennyiben az adatok helyesek, el

lehet fogadni a vásárlás üzleti feltételeit és magát a vásárlást is. Ebben az

esetben a felhasználónak visszajelzést adok az oldalon a sikeres vásárlásról, és

email útján tájékoztatom a vásárlásról és a további teendőkről.

6. Üzembe helyezés

Az üzembe helyezés során az elkészült alkalmazást magába foglaló

könyvtárakat az alkalmazás számára létrehozott webtárhelyen található

mappákba másoltam. Ezek után ellenőriztem, a hivatkozások megfelelő

beállítását. Amennyiben szükséges, a megfelelő aldomaineket be kell állítani.

Mivel az általam tervezett alkalmazás két felületből áll, ezért egy aldomait is

létre kellett hoznom az adminisztrációs felület számára. Ennek a felületnek a

mappáit az aldomain számára létrehozott mappába helyeztem el. Az

állományokat és könyvtárakat FTP-n keresztül másoltam fel a szolgáltató által

megadott elérési adatok alapján. Erre a feladatra én a Total Commandert

használtam. Mivel az alkalmazás a SESSION-ökre és azok kezelésre épül,

figyelni kell a megfelelő session beállításokra az oldalon. Általában a C:\Temp

file-ba kerülnek a munkamenetek, de a PHP save_session_path()

függvényével megadható az a könyvtár, útvonal, ahová a rendszer elhelyezheti

a munkamenet-állományokat.

40

Amint a file-ok a helyükre kerültek, létre kell hozni az adatbázist.

Mindig üres adatbázist kapunk, amiben fel kell építeni az adatbázis tábláinak

rendszerét, és ezekbe be kell inzertálni a kívánt adatokat. Ezt úgy tudtam a

legkönnyebben megoldani, hogy a már elkészült adatbázisomat kiexportáltam

egy sql kiterjesztésű állományba. Ez a file tartalmazza a teljes adatbázis

felépítéséhez szükséges create és insert parancsokat és az ezekhez szükséges

adatokat. Ezt azután nyugodtan le tudtam futtatni a kapott adatbázis kezelő

felületen. Az esetek többségében a phpMyAdmin-ban. Ezek után az

alkalmazáson belül található adatbázis kapcsolat paramétereit módosítani kell.

Ezt két file-al oldottam meg, amelyek a site könyvtárban találhatóak, és az

adatbázis csatlakozáshoz szükséges adatokat tartalmazza. Az egyik a

localhost-os fejlesztéshez, a másik a szerveren való kommunikációhoz, így

mind a két esetben kényelmesen tudtam fejleszteni és nem kellett a hálózat

függvényében átírnom a kapcsolódáshoz szükséges adatokat. Amint mindezt

beállítottam, a kapott URL-t begépelve a böngészőbe a létrehozott alkalmazás

megtekinthető. Ezek után egy funkcionális teszteléssel győződtem meg arról,

hogy az alkalmazás az üzembe helyezés után az elvárt módon működik-e.

7. Tesztelés

Az élesbe helyezés előtt a tesztelés során bizonyosodtam meg arról,

hogy az alkalmazás megfelelően működik-e. Mivel a fejlesztés során

folyamatosan teszteltem a létrehozott függvényeket és logikákat

tesztadatokkal és azok eredményeinek ellenőrzésével, így ebbe a fázisban

kerülve a fejlesztési projekt során a tényleges működésről már meg volt a

szükséges visszaigazolásom, a korábbi tesztelési eredmények által. A tesztelés

ebben a fázisban az élesre helyezett rendszer funkcionális tesztelését jelenti.

Ez az alkalmazás használhatóságában, a kívánt lépések megfelelő

eredménnyel történő végrehajtódásában merül ki. A funkcionális tesz során

végigfuttatom a megjelent termékek listáját, a felületen található linkek

végződéseit és azok hatásait figyelve. A teszt során olyan eseményeket

generáltam, amik az éles helyzetben szintén előfordulhatnak majd, ilyen a

41

regisztráció, a vásárlás és a termékek közötti navigáció. Első körben

ellenőriztem, hogy minden termék, ami az adatbázisban be van regisztrálva

szerepel a felületen. Ezután egy próbaregisztrációt hajtottam végre, ellenőrizve

a helyes működést. Itt szándékosan hagytam ki kötelező mezőket, hogy

lássam, a rendszer erre adott figyelmeztető válaszát. Ezek után a belépést

vizsgáltam helyes, és helytelen adatokkal. Itt az utóbbi esetben szintén külön

figyelmeztetést kaptam a rendszertől a helytelen adatok miatt. Amint a

próbafelhasználó minden szükséges adataival a rendelkezésemre állt a vásárlás

következett, mint tesztelendő folyamat. Első körben a termékek kosárba

gyűjtésének és onnan való eltávolításának folyamatát követtem figyelemmel.

Ezek után a vásárlás funkciót teszteltem belépett felhasználó nélkül. A

vásárlás linkre való kattintáskor a rendszer a belépés oldalra ugrott és ott kérte

a belépéshez szükséges adatokat a vásárlás elindításához. Így látszott a helyes,

elvárt működés az éles rendszeren is. Ezt követően a tényleges belépés után a

bevásárlókosárban található termékek tényleges megvásárlásán volt a sor. A

rendszer itt is az elvárt eredményt mutatta, azaz a pénztár oldalra ugrott, ahol a

postázási adatok, a számlázási adatok és a megvásárolandó termékek együttes

feltüntetése után befejezhető a vásárlás folyamata amennyiben az adatok

helyesek.

8. Összefoglalás

A szakdolgozat témája egy webes áruház működésének megtervezése

és annak tényleges lefejlesztése volt. Ezt azért választottam, mert a mai

világban egyre inkább támaszkodunk az internetre, a számítógépes

hálózatokra, és a mindennapi tevékenységünk áthelyezésével egyre inkább

előtérbe kerül az elektronikus kereskedelem. Egy webes áruház inkább a kis és

középvállalatok, céges esetén lehet alternatíva, akik saját termékeiket akarják

ilyen formán eladásra kínálni. Illetve azon kisebb cégeknek, akik mások által

gyártott termékek árusításával akarnak foglalkozni, de nem tudnak, vagy nem

akarnak raktárakat, üzlethelységeket bérelni, azok fenntartási procedúráival

foglalkozni. Mivel egyre elterjedtebb ez a kereskedelmi forma ezért döntöttem

42

úgy, hogy ezt választom dolgozatom témájául. Az alkalmazás tényleges

elkészítése előtt fontos meghatározni bizonyos célokat, felvázolni a leendő

alkalmazás főbb működési elvárásait, az alkalmazás üzemeltetésére szánt

technológiákat és azok működését. Így biztosan olyan terméket fogunk

készíteni, ami megállja a helyét és megfelel a kívánt követelményeknek. Így a

feladat specifikálása során felvázoltam a fontosabb pontokat, amivel

foglakoznom kell a projekt megvalósítása során, mint az adatbázis tervezés, a

felülettervezés, a használt technológia kiválasztása és a tényleges fejlesztés.

Amint ezeket elkészítettem és a kódokból összeállt a működő alkalmazás azt

üzembe kellett állítani. Amint az adott tárhely szolgáltató által biztosított

területre felkerült az alkalmazás azt az élesbe állítás előtt is tesztelésnek kellett

alávetni. Ez egy funkcionális teszt volt, amelynek során a lehetséges összes

folyamatot végigjártam, ami egy webes áruház élete során bekövetkezhet.

Amennyiben olyan eredményt kaptam, ami eltért az elvárttól akkor azt a

kódban javítottam és ismét ellenőriztem. A végeredmény egy jól működő, az

alapvető követelményeknek megfelelő webes áruház lett, amely felveszi a

versenyt a jelenleg a weben található hasonló feladatot ellátó alkalmazásokkal.

A teljes fejlesztés során rengeteg tapasztalatot szereztem a tervezés és a

fejlesztés terén is. Megtanultam jól meghatározni a fejlesztés során elérendő

célokat, jól megtervezni a részfeladatokat és így hatékony fejlesztői munkát

végezni.

43

9. Felhasznált irodalom

1. Gál Tibor

Webprogramozás

Műegyetem Kiadó Budapest, 2004

2. Robert W. Sebesta

A Word Wide Web programozása

Panem Kiadó, Budapest, 2005

3. Peter Moulding

PHP Fekete Könyv

Perfact-Pro Kft. Budapest, 2002

4. Julie C. Meloni

A PHP, a MySQL és az Apache használata

Panem Kiadó, Budapest 2004

5. Virginia DeBolt

HTML és CSS Webszerkesztés stílusosan

Kispaku Kft, Budapest, 2005

6. Matt Zandstra

Tanuljuk meg a PHP5 használatát 24 óra alatt.

Kiskapu Kft, Budapest, 2005

7. JQuery http://jquery.com/

Dokumentáció

8. Wikipédia, Szabad felhasználású enciklopédia

44

9. Bookline éves beszámoló

http://bookline.hu/istore/tempimgs/2006_eves_jelentes.pdf

10. Szonda Ipsos - Vásárlás és tájékozódás az interneten

http://www.szondaipsos.hu/hu/ipsos/iarvasarlas

11. GKI Gazdaságkutató Zrt.

www.gki.hu

10. Az elektronikus kereskedelmi portál elérhetősége