Proiectarea Aplicatiilor de Comert Electronic - Aplicatie de Food-Ordering

UNIVERSITATEA BABE-BOLYAI CLUJ-NAPOCA FACULTATEA DE TIINE ECONOMICE I GESTIUNEA AFACERILOR SECIA INFORMATIC ECONOMIC
PROIECTAREA APLICAIILOR DE COMER ELECTRONIC. APLICAIE DE FOOD-ORDERING
Coordonator tiinific: Prof. univ. dr. TEFAN IOAN NICHI Absolvent:
Cluj-Napoca
Iulie 2006
CUPRINS
UNIVERSITATEA BABE-BOLYAI CLUJ-NAPOCA.............................................1 FACULTATEA DE TIINE ECONOMICE I GESTIUNEA AFACERILOR.........1 SECIA INFORMATIC ECONOMIC........................................................................1 PROIECTAREA APLICAIILOR DE ............................................................................1 COMER ELECTRONIC..................................................................................................1 APLICAIE DE FOOD-ORDERING...............................................................................1 Coordonator tiinific:.........................................................................................................1 Prof. univ. dr. TEFAN IOAN NICHI............................................................................1 Absolvent:...........................................................................................................................1 Cluj-Napoca..........................................................................................................................1 Iulie 2006...............................................................................................................................2 CUPRINS..............................................................................................................................1 INTRODUCERE..................................................................................................................3 CONCEPTE GENERALE DE COMER ELECTRONIC.............................................7 1.1 Noua economie. Revoluia Internet..............................................................................7 1.2 Afaceri electronice. Comer electronic.........................................................................8 1.3 Modele de comer electronic......................................................................................10 1.4 Avantajele i dezavantajele comerului electronic.....................................................11 1.5 Aspecte critice privind dezvoltarea comerului electronic.........................................13 1.6 Comerul electronic n Romnia: evoluie i tendine................................................13 DEZVOLTAREA UNUI SISTEM DE COMER ELECTRONIC..............................16 2.1 Arhitectura unui sistem de comer electronic.............................................................16 2.2 Etapele implementrii unui sistem de comer electronic...........................................16 2.2.1 Etapa I: Dezvoltarea site-ului i promovarea produselor....................................17 2.2.2 Etapa a II-a: Managementul bazelor de date.......................................................19 2.2.3 Etapa a III-a: Plata i procesarea tranzaciilor.....................................................20 2.2.4 Etapa a IV-a: Managementul produselor i al comenzilor..................................20 2.2.5 Etapa a V-a: Centru specializat de servicii.........................................................21 2.3 Sistem Electronic de Pli..........................................................................................21 2.3.1 Arhitectura unui Sistem Electronic de Pli (SEP).............................................21 2.3.2 Dispozitive folosite ntr-un Sistem Electronic de Pli.......................................21 2.3.3 Tipuri de tranzacii ntr-un Sistem Electronic de Pli........................................22 2.3.4 Modaliti de plat...............................................................................................23 TEHNOLOGII I INSTRUMENTE INFORMATICE UTILIZATE N DEZVOLTAREA APLICAIEI......................................................................................28 3.1 Arhitectura Client/Server...........................................................................................28 3.2 Tehnologii i instrumente informatice utilizate n proiectarea aplicaiei...................30 3.2.1 Limbajul de modelare.........................................................................................30 1
3.2.2 Procesul...............................................................................................................32 3.2.3 Instrumentele utilizate (RationalRose, DBDesigner)..........................................33 3.3 Tehnologii i instrumente informatice utilizate n implementarea aplicaiei.............33 3.3.1 Justificarea soluiei Apache + PHP + MySQL....................................................33 3.3.2 PHP.....................................................................................................................34 3.3.3 MySQL................................................................................................................36 3.3.4 Apache.................................................................................................................39 DEZVOLTAREA APLICAIEI......................................................................................41 4.1 Determinarea cerinelor unei aplicaii de food-ordering............................................41 4.1.1 Studiul pieei aplicaiilor care ofer servicii de comenzi on-line a preparatelor culinare.........................................................................................................................41 4.1.2 Cerinele beneficiarilor aplicaiei de food-ordering............................................45 4.1.3 Delimitarea comportamentului aplicaiei (cazurile de utilizare).........................49 4.2 Proiectarea aplicaiei..................................................................................................55 4.2.1 Designul conceptual al aplicaiei........................................................................55 4.2.1.1 Arhitectura aplicaiei.........................................................................................55 4.2.1.2 Designul conceptual al interfeei prototipul de interfa................................57 4.2.1.3 Designul conceptual al bazei de date................................................................60 4.2.2 Designul fizic al aplicaiei ..................................................................................62 4.2.2.1 Componentele aplicaiei....................................................................................62 4.2.2.2 Diagramele de activitate....................................................................................64 4.2.2.3 Designul fizic al bazei de date..........................................................................66 4.3 Implementarea aplicaiei............................................................................................67 SIMULAREA SUCCESULUI UNEI APLICAII WEB...............................................74 5.1 Aspecte generale privind modelarea i simularea proceselor economice..................74 5.2 Metoda Monte Carlo..................................................................................................75 5.3 Estimarea succesului aplicaiei...................................................................................76 5.4 Interpretarea rezultatelor............................................................................................80 CONCLUZII I PROPUNERI.........................................................................................81 BIBLIOGRAFIE................................................................................................................82
Introducere
INTRODUCERE
Progresele realizate recent n domeniile tehnologie-calculatoare, telecomunicaii i software, precum i n alte domenii ale informaiei, au schimbat radical modul de via al populaiei globului ntr-o manier care ar fi fost greu de estimat n urm cu 20 de ani. Pe fundalul acestor transformri s-a realizat trecerea de la era industrial la cea informaional. n noua societate, rezultat n urma acestor transformri, prelucrarea informaiilor, dobndirea de cunotine cu ajutorul calculatorului, comunicarea i dezvoltarea afacerilor cu ajutorul Internetului au devenit posibile pretutindeni i n orice moment, fr depunerea unui efort considerabil. Aceste transformri au avut un impact foarte mare asupra tuturor domeniilor de activitate. Una dintre caracteristicile importante ale Internetului menionat de susintorii ideii c acesta va deveni motorul prosperitii viitoare este aceea c dup ce, la nceput, impactul su s-a manifestat numai n sectorul tehnologiilor nalte (high-tech), treptat se face simit n toate industriile i serviciile. Explozia Internetului, apariia i dezvoltarea economiei Internet i deci a conceptelor de afaceri electronice i n particular comer electronic au produs modificri semnificative n peisajul economic mondial. n aceste condiii proiectarea, implementarea i realizarea unei afaceri electronice este o consecin natural, impus att de mediul economic, prin necesitatea transformrii stilului de a face afaceri, ct i de cel tehnologic. Afacerile electronice transform radical relaiile i procesele de afaceri, fcndu-le mai uor de gestionat i facilitnd, prin intermediul Internetului, o reacie mai rapid la cerinele clienilor i tendinele pieei. Obiectivele principale ale unei aplicaii de comer electronic ar trebui s vizeze creterea eficienei economice a afacerii dezvoltate prin reducerea consumului de timp i resurse, creterea vitezei de comunicare a informaiilor, oferirea unei interfee prietenoase care s faciliteze schimbul de informaii dintre diversele categorii de utilizatori ai aplicaiei (cumprtori i furnizori). Lucrarea de fa i propune prezentarea fundamentrilor economice i a pailor care ar trebui urmai n dezvoltarea unei aplicaii de comer electronic n general, respectiv a unei aplicaii de food-ordering n particular. Prin aplicaie de food-ordering se nelege o aplicaie bazat pe tehnologia client/server, menit s faciliteze efectuarea comenzilor on-line de preparate culinare de la furnizori care asigur livrri la domiciliu. Metoda utilizat n stabilirea cerinelor aplicaiei are la baz un studiu al pieei aplicaiilor care ofer servicii de comenzi on-line de preparate culinare. Rezultatele studiului s-au materializat n enunarea avantajelor i dezavantajelor aplicaiilor studiate pentru o mai bun modelare i nelegere a cerinelor beneficiarilor. Aplicaia de food-ordering are la baz o arhitectur pe trei nivele: nivelul de prezentare, nivelul de logic a aplicaiei (de business) i nivelul de date. Am ales aceast structurare datorit avantajului major pe care l prezint fa de o arhitectur client/server tradiional (pe dou nivele), i anume acela c majoritatea procesrilor se fac pe serverul de aplicaie i pe baza de date, nu pe calculatorul client i pe baza de date, ceea ce permite o scalabilitate mult mai bun a aplicaiei n condiiile unui volum de tranzacii n cretere (este necesar doar adugarea de servere suplimentare pentru creterea capacitii de procesare). 3
Introducere
n dezvoltarea i implementarea aplicaiei am optat pentru avantajele oferite de triada Apache + MySQL + PHP. Aceast soluie se remarc dintre cele tradiionale prin costul redus al dezvoltrii software datorit gratuitii celor trei produse (este posibil o eventual licen pentru serverul de baze de date MySQL), rapiditatea n dezvoltare i uurina n ntreinere a aplicaiilor create. n contextul actual al mediului Web, Apache satisface cerinele unui server HTTP prin securitate sporit, eficien n funcionare, gratuitate i o structur modular care permite extensia funcionalitii acestuia. Aceast ultim caracteristic permite configurarea PHP-ului ca i modul al serverului, crescndu-se astfel rapiditatea triadei. PHP satisface nevoia unui limbaj server-side puternic la implementarea nivelului de logic a aplicaiei datorit combinrii unei sintaxe relaxate cu construcii puternice de limbaj i datorit faptului c beneficiaz de o librrie de extensii considerabil. Este bine cunoscut suportul oferit pentru interaciunea cu un server de baze de date MySQL, aa cum este bine cunoscut i tandemul pe care PHP i MySQL l formeaz ca soluie rapid la cererea crescnd de site-uri ce afieaz coninut dinamic. Uurina n folosire a PHP-ului se datoreaz n principal modelului ales n implementarea paradigmei generrii dinamice de coninut Web. Din funciile puternice oferite de PHP se pot deriva cu uurin scripturi particularizate care s implementeze regulile de funcionare a aplicaiei n ceea privete managementul datelor stocate ntr-o baz de date MySQL. Referitor la soluia aleas pentru implementarea nivelului de date al aplicaiei, trebuie menionat c serverul de baze de date MySQL depete competiia prin rapiditatea n execuie (mai ales pentru sistemul de operare Linux) i securitatea sporit. n ceea ce privete limitele lucrrii de fa, precizez c aplicaia prezentat nu i propune s implementeze un sistem electronic de pli, acest lucru putnd fi luat n considerare la o dezvoltare ulterioar. Totui, n urma studiilor efectuate, avnd n vedere faptul c un asemenea sistem ar presupune eforturi financiare suplimentare att din partea furnizorului (tax de conectare la serviciu + tax lunar de procesare a plilor + comision din ncasri) ct i din partea consumatorului (tax de conectare la serviciu + tax lunar de administrare cont), coroborat cu faptul c acest tip de afacere presupune contactul direct ntre furnizori i consumatori n momentul livrrii produselor (moment n care se poate realiza i ncasarea contravalorii produselor furnizate), consider c implementarea unui astfel de sistem nu ar aduce beneficii suplimentare considerabile pentru aplicaie. De asemenea, lucrarea i propune s insiste asupra aspectelor legate de proiectarea aplicaiei i asupra funcionalitii oferite de aceasta, lsnd ntr-un plan secundar aspectele legate de design, testarea sau promovarea aplicaiei, acestea putnd fi aprofundate n etapele ulterioare de dezvoltare. Urmrind o abordare tehnico-economic, lucrarea este fundamentat tiinific pe arhitectura a cinci capitole. n primul capitol am prezentat aspectele economice fundamentale care stau la baza afacerilor electronice. Dup o analiz succint a noii tendine n economie, am ncercat o definire a conceptelor de afaceri electronice, respectiv comer electronic. Pentru o mai bun nelegere a fenomenului am realizat o prezentare a tuturor modelelor de afaceri electronice, respectiv de comer electronic care funcioneaz la ora actual n lume, am analizat avantajele i dezavantajele comerului electronic, punctnd totodat problemele i piedicile cu care se confrunt astfel de 4
Introducere
modele de afaceri. n final am realizat o analiz a evoluiei i tendinelor comerului electronic pe piaa din Romnia. Cel de-al doilea capitol se dorete a fi un liant ntre fundamentarea teoretic din punct de vedere economic i dezvoltarea efectiv a aplicaiei. n acest capitol am vorbit la modul general despre arhitectura unui sistem de comer electronic, prezentnd paii care ar trebui urmai n implementarea unui astfel de sistem, urmnd ca n capitolele urmtoare s aplic efectiv aceti pai n dezvoltarea propriei aplicaii. De asemenea, la sfritul capitolului am ncercat fundamentarea din punct de vedere teoretic a modului de organizare i funcionare a unu Sistem Electronic de Pli, considernd c acest lucru va constitui o baz riguroas n procesul de dezvoltare ulterioar a aplicaiei. Avnd n vedere c o lucrare trebuie fundamentat nu numai din punct de vedere economic, ci i tehnic, n capitolul al treilea am realizat o prezentare succint a tehnologiilor i instrumentelor informatice utilizate n dezvoltarea aplicaiei. Am nceput prin a descrie arhitectura client/server, arhitectur care st la baza aplicaiei prezentat n lucrarea de fa, continund cu descrierea succint a instrumentelor utilizate i a motivaiei care a stat la baza alegerii lor. De asemenea, n acest capitol am descris procesul pe care s-a bazat dezvoltarea aplicaiei, proces structurat pe dou dimensiuni: dimensiunea temporal (care induce fazele de lansare, elaborare, construcie, tranziie) i componentele procesului (modelarea afacerii, identificare cerinelor, analiza i proiectarea, implementarea i testarea). Dup fundamentarea tehnico-economic a aspectelor teoretice, n capitolul al patrulea am prezentat etapele de dezvoltare a aplicaiei de food-ordering. Astfel, am explicat detaliat modalitile de analiz a cerinelor, de proiectare a aplicaiei i de implementare a acesteia. n faza de analiz, plecnd de la studiul pieei, am modelat necesitile utilizatorilor cu ajutorul cazurilor de utilizare. n faza de proiectare am urmrit etapele procesului de design conceptual (stabilirea arhitecturii aplicaiei, realizarea prototipului de interfa, proiectarea schemei conceptuale a bazei de date) i fizic (prezentarea componentelor aplicaiei, a diagramelor de activitate i a modelului fizic al bazei de date). n faza de implementare am descris modalitatea de realizare efectiv a celor trei nivele ale aplicaiei (nivelul de prezentare, de logic a aplicaiei i nivelul de date) cu ajutorul soluiei Apache + MySQL + PHP. ntruct un ultim pas n dezvoltarea unei afaceri ar trebui s-l constituie determinarea eficienei economice a acesteia, n capitolul al cincilea am ncercat s aplic metode specifice modelrii i simulrii proceselor economice n vederea estimrii succesului aplicaiei. Pentru aceasta, am utilizat metoda Monte Carlo n procesul de simulare a numrului mediu de utilizatori ai aplicaiei pe sptmn, pornind de la datele furnizate de site-ul de monitorizare www.trafic.ro. Am efectuat acest studiu pornind de la premisa c succesul unui site poate fi cel mai bine estimat prin numrul de vizitatori ai si, care pot reprezenta poteniali cumprtori ai produselor oferite. Lucrarea se ncheie cu un capitol de concluzii i perspective n care am subliniat importana temei abordate n cadrul acestei lucrri n procesul de dezvoltare a mediului virtual de afaceri. n cadrul acestui ultim capitol am adus argumente n favoarea dezvoltrii afacerilor electronice, considernd c acest tip de afaceri are un potenial foarte mare datorit avantajelor care le ofer att consumatorilor, ct i vnztorilor. De asemenea, am prezentat i direciile de
Introducere
dezvoltare ulterioar a aplicaiei, tiut fiind faptul c realizarea unei aplicaii const ntr-un proces continuu de analiz i adaptare la nevoile mereu schimbtoare ale utilizatorilor.
Capitolul I Concepte Generale de Comer Electronic
CAPITOLUL I CONCEPTE GENERALE DE COMER ELECTRONIC
1.1 Noua economie. Revoluia Internet. Societatea spre care ne ndreptm este sau va fi Societatea Informaional Societatea Cunoaterii. Acestei societi n continu formare i este proprie o economie mult schimbat fa de cea actual, denumit noua economie. Din diferite motive, noua economie se identific n limbajul curent cu economia bazat pe internet i de aceea mai este denumit digital economy, network economy sau e-economy. Noua economie reprezint o sintez complex ntre economia digital (bazat pe Internet, bunuri i servicii digitale, noi modele de afaceri, noi moduri de munc), globalizare, inovare i dezvoltare durabil. Procesele principale care au loc n noua economie sunt urmtoarele: o dezvoltarea accelerat a comunicaiilor avansate; o explozia Internet; o dezvoltarea comerului electronic; o apariia unor noi modele de realizare a afacerilor i restructurarea / re-ingineria firmelor; o promovarea de noi reguli i forme de organizare, bazate pe inovare; o extinderea formelor de activitate i de munc la distan. Trebuie menionat faptul c noua economie se bazeaz pe trei principii definitorii: o acces (i rspuns) instantaneu; o servicii personalizate; o prezena simultan n mai multe locuri (ubicuitate). Noua economie marcheaz o transformare fundamental n istoria dezvoltrii societii omeneti, i se estimeaz c durata tranziiei de la societatea industrial la societatea global reelizat, bazat pe cunotine, va fi ntre 20 i 30 ani. Informaia este resursa principal n noua economie i de aceea suportul i nucleul acesteia sunt tehnologiile informaionale i comunicaiile avansate, iar motorul ei este Internetul. De aceea se spune c noua economie este o economie a tuturor tipurilor de afaceri construite n jurul Internetului. Internetul are un rol cheie n furnizarea de informaii privind disponibilitatea de produse i servicii i preurile acestora n toat economia. Noile tehnologii Internet contribuie direct la expansiunea comerului electronic, a noilor modele de afaceri i e-business i la dematerializarea produselor i serviciilor. Piaa Internetului rmne o pia de cucerit de ctre ntreprinderi, o posibilitate pentru noi oportuniti, inclusiv prin diversificarea serviciilor oferite i promovarea de servicii noi, personalizate i atractive, pe care tehnologiile informaionale i de comunicaii le fac posibile, ceea ce stimuleaz concurena i competitivitatea prin apariia de noi actori pe pieele tradiionale. 7
Internetul reduce importana distanei i timpului. Moartea distanei i comprimarea timpului, care sunt unele din efectele Internetului, pot fi considerate printre cele mai importante schimbri care modeleaz n prezent societatea omeneasc. Apariia Internet-ului este, probabil, cel mai important eveniment de la sfritul secolului XX din punct de vedere al impactului n economie i societate. Dup unii autori prezena pe Internet a firmelor poate fi realizat n ase stadii: 1. Conectare on-line - n aceast faz, compania are o simpl pagin web, n spatele creia nu exist o structur real. 2. WebSite structurat - website-ul are o structur mai elaborat, se poate folosi un motor de cutare dup cuvinte cheie, se pot vizualiza informaii despre companie i se pot schimba mesaje n mod interactiv cu aceasta. 3. ncercri de e-commerce - compania ncearc s vnd on-line informaii, mrfuri, etc. Sistemul nu este conectat la bazele de date interne de pe Intranet. Este lent, costisitor i nu este sigur. Nu exist posibilitatea trecerii de la sistemul backend al companiei proprii la sistemul back-end al altei firme. 4. Realizarea de e-business - Website-ul are o legtur direct cu sistemul de pe Intranet, permite extragerea de informaii din bazele de date interne i folosete protocoale securizate de transmitere a datelor ntre compania proprie i client sau ctre o alt organizaie. Se pot face economii i poate ncepe obinerea de profit bazat pe utilizarea tehnologiilor on-line. 5. E-business extensiv - Folosind orice dispozitiv care conine un cip (telefon celular, main, etc) personalul companiei, clienii i furnizorii se pot conecta la datele companiei i pot transmite sau primi informaiile dorite pentru e-business. 6. O lume - Un calculator - Toate dispozitivele bazate pe cipuri vor fi interconectate i se va crea o resurs de informaii uria. Dispozitivele sunt capabile s schimbe ntre ele orice tip de informaii.
1.2 Afaceri electronice. Comer electronic. Mediul de afaceri modern este caracterizat prin creterea fr precedent a ofertei furnizorilor, a competiiei globale i a exigenei clienilor. Firmele din toate sectoarele economice au nceput s adopte noua paradigm economic orientarea ctre e-business sau noile modele de afaceri. E-business-ul poate fi definit ca transformarea proceselor (operaiilor, componentelor) constitutive ale unei afaceri cu ajutorul tehnologiilor Web + Internet, ceea ce permite ca afacerile s fie active 24 de ore pe zi. Alegerea modelului de afacere este prima decizie care trebuie luat n momentul n care se pornete o afacere on-line. Noul model de afaceri se realizeaz sub forma unui lan de servicii electronice, compus din: o furnizorul de produse sau servicii cutate; o furnizorul de servicii Internet care poate oferi orice, de la spaiu pe web, la integrarea de e-mall i la diferite tipuri de servicii; 8
o clientul, cu o anumit profesie, interese personale i preferine; acest client poate fi un consumator (B2C), o alt afacere (B2B), o administraie public (B2A) sau un angajat (B2E). Scopul modelelor de e-business este de a reprezenta ntr-un mod ct mai accesibil tipul de afacere i arhitectura sistemului (topologia aplicaiei i topologia de rulare) pentru diferite clase de aplicaii. Aceste modele descriu interaciunea dintre participanii la o soluie de ebusiness. n momentul de fa sunt definite ase modele de e-business: 1. Modelul User-to-Business (U2B): Este cazul general n care un utilizator (intern sau extern) interacioneaz asupra datelor i tranzaciilor unei ntreprinderi. n caz particular se poate aplica la o ntreprindere care ofer servicii sau bunuri care nu pot fi prezentate i vndute prin catalog. Poate fi vzut ca acoperind toate interaciunile de tip User-to-Business care nu sunt acoperite de modelul User-toOnline Buying. 2. Modelul User-to-Online Buying (U2OB): Este folosit pentru a descrie un caz special (un subset al modelului User-to-Business) n care bunurile sunt vndute printr-un catalog folosind un card de cumprri, un portofel, etc. Acest model include ambele cazuri de consumatori: care cumpr bunuri i care se aprovizioneaz de la un singur furnizor. Poate cuprinde legturi cu sisteme de gestiune, de verificare de cri de credit, de livrare etc. 3. Modelul Business-to-Business (B2B): Este folosit pentru a descrie dou tipuri de interaciune ntre dou ntreprinderi: a. tipul (B2Bi) este cazul n care exist un contract de parteneriat ntre ntreprinderi, un exemplu n acest sens fiind o aplicaie pentru un lan de desfacere; b. tipul (B2M2B) este cazul unui e-MarketPlace, deci existena unei piee electronice n care interacioneaz mai muli cumprtori i mai muli furnizori. 4. Modelul User-to-User (U2U): Descrie cazul colaborrii diferiilor utilizatori prin intermediul documentelor partajate, prin e-mail, etc. 5. Modelul User-to-Data (U2D): Descrie cazul n care utilizatorii au nevoie de cantiti nsemnate de date, text, imagini, etc. i folosesc diverse instrumente pentru a extrage informaii. 6. Modelul Application Integration: Este folosit pentru integrarea diverselor aplicaii ntr-o soluie de afacere, i poate fi utilizat att n cadrul unui singur tip de afacere, ct i ntre mai multe tipuri de afacere. Noile modele de afaceri au un rol catalizator pentru modificri organizaionale, noi modele de organizare a produciei i de tranzacionare a afacerilor, i permit firmelor mici i mari s intre pe piaa electronic naional i internaional. Comerul electronic se refer la desfurarea activitilor specifice mediului de afaceri (tranzacii) ntr-un sistem automatizat integrat pentru schimbul de informaii utiliznd mijloace electronice (reele de calculatoare). 9
O definiie posibil a Comerului Electronic ar fi : orice form de tranzacii n afaceri n cadrul creia prile interacioneaz electronic n loc de realizarea de schimburi fizice sau contact fizic direct. n comerul electronic informaia circul ntre agenii implicai n afacere (vnztor, cumprtor, banc, transportator, agent de service), fr a utiliza suportul de hrtie (imprimant sau fax). n cazul comerului electronic, se ntlnesc aceleai componente ca i n cazul comerului clasic, dar cu modificri specifice, i anume: o un produs - material sau digital; o un loc de vnzare - n acest caz un website n reea care s prezinte produsele sau serviciile oferite; o o modalitate de a atrage oamenii s vin la un anumit website; o o modalitate de a primi comenzi - n mod normal un formular on-line; o o modalitate de a ncasa bani - de regul un cont bancar cu pli prin card de credit. Aceasta cere o pagin sigur pentru comenzi i conexiunea la o banc, dar se poate folosi i metoda clasic a facturrii, on-line sau prin pot; o o modalitate de livrare; dac marfa este de tip software sau informaie, livrarea se poate face direct prin reea; o o modalitate de a accepta returnri (formulare on-line); o o modalitate de a accepta eventuale reclamaii (formulare on-line); o o modalitate de a oferi service (prin email, formulare on-line, baze de cunotine on-line etc.); n afacerile tradiionale vnzarea este nc vzut i organizat ca fiind subordonat produciei, sau vindem ce producem. n e-commerce, firmele vnd ce pot livra deoarece ofer consumatorului o gam larg de produse, indiferent cine le produce.
1.3 Modele de comer electronic Analiznd aplicaiile curente dezvoltate pe Internet, identificm urmtoarele modele de afaceri n comerul electronic: o magazin electronic (e-shop): un magazin electronic se implementeaz prin intermediul unui site Web; acesta este gestionat de companie, pentru marketingul i vnzrile propriilor produse i servicii. Minimal, conine catalogul de produse sau servicii cu descrieri tehnice i comerciale pentru fiecare poziie din catalog. Aceste descrieri sunt gestionate n general de un Sistem de Gestiune a Bazelor de Date (SGBD). Sistemul de Gestiune a Bazelor de Date se va ocupa cu stocarea i manipularea datelor i cu oferirea posibilitilor de acces la date. Varianta medie conine faciliti pentru preluarea comenzilor (prin e-mail sau formulare interactive pe care le vor completa clienii), iar varianta extins cuprinde i posibilitatea efecturii on-line a plii (prin cri de credit sau alte variante electronice); 10
o aprovizionarea electronic (eProcurement): pentru procurarea bunurilor i serviciilor, marile companii i autoriti publice organizeaz licitaii. Prin publicarea pe Web a specificaiilor ofertei scade att timpul ct i costul de transmisie, mrindu-se i numrul de firme care iau parte la licitaie. Astfel, crete concurena i scade preul; o magazin electronic universal (eMall): ca i n lumea real, magazinul electronic universal este o colecie de magazine electronice, reunite sub o umbrel comun i care, n general, accept metode de plat comune; o piaa unui ter (3rd party marketplace): se apeleaz la o interfa utilizator pentru catalogul de produse al companiei, interfa ce aparine unui ter (n general, un furnizor de servicii Internet sau o banc). Aceast metod are avantajul c interfaa este unic pentru mai muli productori, utilizatorii fiind familiarizai cu utilizarea ei; o comuniti virtuale (virtual communities): valoarea cea mai important a unei comuniti virtuale este dat de ctre membrii si (clieni sau parteneri), care adaug informaii proprii peste un mediu de baz furnizat de companie. Fiecare membru poate oferi spre vnzare produse sau servicii sau poate adresa cereri de cumprare a unor produse sau servicii. Calitatea de membru al unei comuniti virtuale presupune plata unei taxe; o furnizor de servicii cu valoare adugat pentru canalele de comer electronic (value chain service provider): furnizorii de servicii sunt specializai pe funcii specifice, cum ar fi asigurarea logisticii, plata electronic sau expertiza n managementul produciei i a stocurilor. Plata acestor servicii se face pe baza unor tarife sau a unei cote procentuale; o platforme de colaborare: platformele de colaborare cuprind un set de instrumente i un mediu informaional pentru colaborarea ntre companii. Acestea pot adresa funcii specifice, cum ar fi concepia sau proiectarea n colaborare. Ctigurile provin din managementul platformei (taxa de membru sau taxa de utilizare), i din vnzri de instrumente specializate (pentru design, workflow i gestiunea de documente). Prin workflow se nelege fluxul de documente, care implic dou entiti: o parte pasiv (documentele) i o parte activ (deplasarea acestor documente); o brokeraj de informaii i alte servicii: exemplele cuprind cataloage de clieni clasificai pe profil, vnzarea de oportuniti de afaceri, consultan n domenii specializate. O categorie special o constituie serviciile de ncredere furnizate de autoritile de certificare sau de notariatele electronice.
1.4 Avantajele i dezavantajele comerului electronic Principiile de baz ale unei afaceri electronice sunt aceleai ca la orice afacere tradiional, desfurat n mediul economic real: avem de-a face cu un public int i un produs sau serviciu oferit spre vnzare. n urma ntlnirii dintre cerere i ofert consumatorul 11
va primi produsul, iar productorul va ncasa contravaloarea acestuia, respectiv productorul va factura contravaloarea serviciului prestat ctre consumator, urmnd s ncaseze suma aferent. Diferena major n cazul afacerilor electronice const n faptul c acestea permit automatizarea proceselor de vnzare i cumprare. ntr-un magazin normal exist angajai care s ajute consumatorul s cumpere. n cazul magazinelor virtuale, angajatul este reprezentat de site-ul n sine, care lucreaz 24 de ore din 24, 7 zile pe sptmn, pe parcursul ntregului an, fr nici un fel de ntrerupere, i toate acestea n vederea maximizrii profitului afacerii. Din poziia cumprtorului, avantajele comerului electronic sunt legate de: o timp: cumprtorul poate vizita mai multe magazine virtuale ntr-un timp foarte scurt (mult mai scurt dect timpul pe care l implic prezena fizic a unei persoane ntr-un magazin real); o libertatea de a alege: datorit numrului mare de magazine pe care clientul le poate vizita, acesta va avea posibilitatea de a alege un produs n funcie de un numr mult mai mare de opiuni (pre, data livrrii, etc.). Din punctul de vedere al companiilor ce utilizeaz comerul electronic, se disting urmtoarele avantaje: o creterea semnificativ a vitezei de comunicare, n special pentru comunicaiile internaionale: mai multe companii pot stabili o platform de colaborare, prin intermediul creia s poat concepe i dezvolta diverse produse mpreun; comunicarea prin telefon sau fax ar nsemna o ncetinire drastic a acestor procese de concepie sau dezvoltare; o reducerea unor costuri: de exemplu, utiliznd e-mail (pota electronic) se reduc costurile cu pota sau mesageria, dar i costurile referitoare la deplasarea documentelor (circa 7% din cheltuielile fcute cu comerul tradiional se datoreaz deplasrii documentelor); o ntrirea relaiilor cu furnizorii i clienii: printr-un site Web, clienii companiei vor fi pui la curent cu ultimele produse aprute, li se va oferi suport tehnic pentru produsele cumprate, putnd chiar s ofere sugestii pentru eventuale mbuntiri ale produselor, serviciilor etc.; pe unele site-uri cumprtorii pot construi produsul pe care vor s l cumpere (culori, materiale, nscrisuri etc.); furnizorilor li se poate oferi n cadrul acestui site un domeniu special n care i pot prezenta i ei la rndul lor ultimele nouti; o existena unei ci rapide i comode de furnizare a informaiilor despre companie: prin intermediul unor site-uri Web, a intranet-urilor i a extraneturilor; o canale alternative de vnzare: desfurarea afacerilor prin intermediul unui astfel de site. Dei pare o afacere de vis, exist totui cteva greeli de majore care ar putea-o transforma ntr-un comar: 12
o lipsa unui plan de aciune: antreprenorii se las ghidai doar de entuziasm; o estimarea eronat a investiilor: se pornete de la ideea fals c pentru o afacere electronic, de tipul comer electronic, investiiile trebuie s fie ntotdeauna foarte mici; o neglijarea aspectelor concureniale: ideea c o afacere electronic trebuie s aib ca principal avantaj competitiv preul mic al produselor; o neglijarea aspectelor de promovare a produselor: accentul se pune mai mult pe vnzri, dect pe strategia de marketing.
1.5 Aspecte critice privind dezvoltarea comerului electronic Exist ase piedici majore care frneaz dezvoltarea comerului electronic: o securitatea: Internetul a fost conceput ca un mediu deschis, dar nu neaprat i sigur, protocolului TCP/IP (care st la baza comerului electronic) lipsindui servicii de securitate de baz. Un element de baz pentru securitatea comerului prin Internet l constituie criptarea, care permite att autentificarea, ct mai ales sigurana transmisiei informaiilor; o acceptarea noilor modaliti de plat (bani electronici / digitali): problema major care se pune este cea a caracterului privat n care se cheltuiesc banii n mod normal. Este problema urmririi (trace) tranzaciilor. Un sistem electronic, care realizeaz nregistrarea tuturor tranzaciilor care se fac n ciberspaiu, prezint dezavantajul c tot ceea ce faci este nregistrat; o existena unei infrastructuri de telecomunicaii adecvate: pe msur ce tehnologia avanseaz, apar noi metode de comunicaie celulare; o costurile investiiei: de exemplu, un comerciant care vrea s ofere un magazin pe Internet, va face urmtoarele investiii: servere (calculatoare puternice care s poat evolua odat cu creterea volumului tranzaciilor), tehnologie de comunicaii (care s poat crete odat cu creterea afacerii), software de comer electronic precum i tehnologii care s asigure securitatea, de exemplu firewall-urile; o cadrul legislativ i normativ: se refer la aspectele legate de cadrul fiscal, drepturile asupra proprietii intelectuale, protecia datelor consumatorului; o aspecte lingvistice i culturale: reeaua Web tinde s devin din ce n ce mai mult un turn Babel al naiunilor, pe msura adoptrii pe scar din ce n ce mai larg a tehnologiilor legate de Internet.
1.6 Comerul electronic n Romnia: evoluie i tendine Romnia este singura ar din rsritul Europei n care funcioneaz comerul electronic (on-line) prin intermediul card-ului bancar. Nici Polonia, nici Cehia, Ungaria sau 13
alte ri mai avansate nu au create condiiile pentru funcionarea acestui sistem comod de plat a produselor i serviciilor, reprezentat prin comer electronic . Cei interesai, adic statul, bncile i comercianii, nu fac publicitate sistemului, iar populaia nu este informat. Cu toate acestea, situaia poate evolua extrem de spectaculos n urmtorii trei ani. Volumul tranzaciilor on-line intermediate de sistemul 3D Secure romnesc, unde plata se efectueaz prin card, a crescut continuu dup lansarea sa, n martie 2004, ajungnd la suma de patru milioane de dolari n aprilie 2005. Valoarea pentru comerul electronic ar putea ajunge, la sfritul acestui an, la 80 milioane de euro, ponderea covritoare, de aproximativ 90%, fiind deinut de tranzaciile operate de ctre clienii din afara rii. n Romnia exist mai mult de 500 de site-uri care deruleaz tranzacii n sistem electronic (din care numai 160 active - nregistrate n sistemele de plat on-line). Comerul electronic nregistreaz o rat de cretere lunar foarte mare, de 17-20%. Tendina comerului electronic romnesc este ascendent. Numrul magazinelor virtuale crete vertiginos, ca i numrul clienilor care fac cumprturi on-line. Potrivit RomCard, n primele cinci luni din 2005 s-au efectuat aproximativ 138.000 de tranzacii n sistem 3D Secure, valoarea cumprturilor generate de aceste tranzacii ridicndu-se la 26 milioane USD. n 2004, posesorii de carduri VISA emise n Romnia au efectuat 33.742 de tranzacii n valoare total de 4.565.440 USD. Dintre acestea, valoarea tranzaciilor fcute n Romnia a fost sub 6%. Media tranzaciilor se nvrte n jurul a 45.000 pe lun, ceea ce nseamn c la sfritul anului ne vom apropia de jumtate de milion. ns din valoarea total a tranzaciilor procesate prin RomCard n sistem 3D Secure, cardurile romneti genereaz sub 10%. Nu toate magazinele virtuale sunt nrolate, ns, n sistemul 3D Secure. La 4 milioane de utilizatori Internet i 6 milioane deintori de carduri de debit (majoritatea) i credit, valoarea tranzaciilor cu cardurile emise n Romnia a crescut de la 1,8 milioane de euro, n 2003, la 2,8 milioane n 2004. Toi aceti utilizatori au acces direct la comer electronic. n Martie 2005 erau nregistrai 56.100 de abonai ai instrumentelor de plat cu acces la distan, de patru ori mai muli fa de 2003. n prezent, 160 de comerciani sunt nregistrai i se ateapt ca numrul acestora s creasc la 300 pn la sfritul acestui an. De asemenea, nici numrul clienilor care prefer plata prin card nu este foarte mare, muli optnd nc pentru tipul de plat cash on delivery (sau ramburs, folosind termenul romnesc). S-ar putea spune, deci, c n materie de comer electronic romnul nc nu a prins gustul. Privit sub raportul cifrelor, evoluia fenomenului de comer electronic n ara noastr arat astfel: o n 2004 magazinele virtuale nregistrau cifre de afaceri de 200.000 de euro; n primul trimestru din 2005 acestea s-au dublat; o n 2001 s-au nregistrat 193.413 pagini de comer electronic vizitate, vizualizate de 10.538 de persoane; n luna mai 2005 s-au afiat 4.184.094 de pagini de comer electronic vizitate de 491.817 persoane. n total, n fiecare sptmn, aproape 400.000 de utilizatori romni de Internet viziteaz site-urile de comer electronic din Romnia. 14
Analiznd cifrele de mai sus se poate spune c numrul magazinelor virtuale autohtone de comer electronic este n continu cretere, la fel ca i sumele tranzacionate. De asemenea, standardele de securitate sunt la nivel internaional, modalitile de plat sunt aceleai ca peste tot n lume, produsele la fel. Concluzia pe care o putem trage este urmtoarea: este doar o problem de ncredere i promovare pn cnd romnii i vor ndrepta atenia ctre site-urile romneti de comer electronic.
15
Capitolul II Dezvoltarea Unui Sistem de Comer Electronic
CAPITOLUL II DEZVOLTAREA UNUI SISTEM DE COMER ELECTRONIC
2.1 Arhitectura unui sistem de comer electronic Pentru a construi un sistem de e-commerce, din punct de vedere arhitectural este nevoie de colaborarea a patru componente (subsisteme electronice/informatice) corespunztoare urmtoarelor roluri: a) Client: un echipament clasic, un PC, conectat direct (via un ISP) sau indirect (o reea a unei corporaii) la Internet. Cumprtorul folosete acest echipament pentru a naviga i a face cumprturi. b) Comerciant: sistem informatic (hard & soft), situat de regul la sediul comerciantului, care gzduiete i actualizeaz catalogul electronic de produse disponibile a fi comandate on-line pe Internet. c) Sistemul tranzacional: sistemul informatic (hard & soft) responsabil cu procesarea comenzilor, iniierea plilor, evidena nregistrrilor i a altor aspecte de business implicate n procesul de tranzacionare. d) Dispecer pli (Payment Gateway): sistem informatic responsabil cu rutarea instruciunilor de plat n interiorul reelelor financiar-bancare, cu verificarea crilor de credit i autorizarea plilor; acest sistem joac rolul unei pori care face legtura dintre reeaua global Internet i subreeaua financiar-bancar (supus unor cerine de securitate sporite), poart prin care accesul este controlat de un portar (gatekeeper); pe baza informaiilor specifice crii de credit (tip_card, nr_card) din instruciunile de plat portarul redirecioneaz informaia ctre un centru de carduri (CC - un server certificat n acest scop i agreat de banca emitent); n acest loc este identificat banca emitent a cardului, iar instruciunile de plat sunt trimise mai departe ctre serverul acestei bnci conectat n reeaua interbancar; odat informaiile ajunse n reeaua bncii cu care lucreaz cumprtorul, sunt efectuate (automat) o serie de verificri privind autenticitatea i soldul disponibil n contul cardului implicat n tranzacie; n funcie de rezultatul acestor verificri, banca decide fie efectuarea plii (transfer bancar - ctre contul comerciantului care poate fi deschis la orice alt banc), fie refuz s fac aceast plat; n ambele cazuri, rezultatul deciziei (confirmare plat sau refuz) este trimis n timp real, parcurgnd acest lan de servere n sens invers, ctre client; cu alte cuvinte, n cteva secunde cumprtorul afl dac banca sa a operat plata sau nu.
2.2 Etapele implementrii unui sistem de comer electronic Realizarea unui sistem de comer electronic, indiferent de modelul pe care l implementeaz (business-to-consumer B2C sau business-to-business B2B) implic mai multe etape: 16
2.2.1 Etapa I: Dezvoltarea site-ului i promovarea produselor Aceast etap este la rndul su mprit n patru pai: proiectarea, dezvoltarea, gzduirea, promovarea i optimizarea site-ului. Proiectarea site-ului nainte de a trece la crearea efectiv a unui site de comer electronic, compania care va deine acest site trebuie s poat da un rspuns la urmtoarele ntrebri: o Ce tipuri de produse vinde site-ul? o Ce tipuri de informaii va gzdui? Rspunsurile la aceste ntrebri vor determina domeniile din care va fi alctuit site-ul. De exemplu, respectiva companie poate vinde produse care vor fi livrate clienilor prin pot, produse software care vor fi ncrcate direct de pe site, sau ambele categorii de produse. n cazul n care se dorete vnzarea ambelor tipuri de produse, se vor construi domenii specifice fiecrui tip n parte. Un alt exemplu l-ar constitui construirea unui domeniu dedicat discuiilor on-line: o companie poate decide s ofere clienilor un forum de discuii dedicat unor probleme care prezint un anume interes pentru companie. o Ce persoane din cadrul companiei vor fi responsabile pentru administrarea siteului? Site-ul companiei poate avea un singur administrator (suficient pentru site-uri de dimensiuni mici) sau mai muli, pentru situaiile neprevzute n care unul dintre administratori este indisponibil. De asemenea, trebuie s se aib n vedere stabilirea unei structuri de aprobatori (organizat ierarhic), care s se ocupe de aprobarea coninutului nou care va fi adugat n cadrul diferitelor domenii ale site-ului. Coninutul va fi adugat de ctre utilizatori interni (aparinnd intranetului companiei) sau externi (din Internet, de exemplu). o Care este tipul de interfa pe care dorii s l propunei clienilor? n timp ce rspunsurile la primele dou ntrebri rezolvau n principal probleme legate de structura intern a site-ului, rspunsul la aceast ntrebare va determina aspectul su exterior. Trebuie s se stabileasc ce imagini vor fi prezentate n cadrul paginilor (de exemplu logo-ul companiei), culorile folosite n cadrul paginilor (ar putea fi culorile din logo), stilul de adresare, etc. Dezvoltarea site-ului Dup ce s-au stabilit toate detaliile de la punctul precedent, urmeaz o alt etap la fel de important: determinarea cerinelor necesare pentru dezvoltarea site-ului. Cerinele se refer att la hardware-ul i software-ul necesar pentru implementarea sistemului de comer electronic, ct i la infrastructura de comunicaii: o cerine hard: caracteristicile mainilor folosite ca server (memorie, spaiu pe hard-disk, vitez procesor, etc.) o cerine soft: sistem de operare, server de Web, firewall, pachete de programe opionale (programe de calcul al taxelor, etc.) o comunicaii: se refer la lrgimea bandei de comunicaie, topologii de reea, etc.
17
n urma completrii acestei etape, se va determina mai mult de 80% din costul pe care l implic realizarea unui site de comer electronic. Gzduirea site-ului Site-ul de comer electronic poate fi gzduit pe un sistem care aparine clientului, dar exist de asemenea posibilitatea nchirierii de spaiu pe server-ele furnizorului de servicii Internet. Soluia cea mai ieftin se obine n prima variant. n cel de-al doilea caz, clientul trebuie s se conecteze la Internet fie prin linii nchiriate (acces mai rapid, dar mai scump), fie prin linii telefonice (acces mai lent, dar mai ieftin). Promovarea i optimizarea site-ului Sintagma Construiete-l i vor veni nu este valabil nici pentru site-urile tradiionale, aa cum s-a spus mult vreme, i nici pentru magazinele virtuale. Strategiile de marketing i publicitate sunt absolut necesare pentru a obine succesul dorit pe Internet. Printre modalitile de promovare pe care o organizaie virtual le poate folosi n cadrul strategiei de promovare, se numr: o Promovarea n reea: Anunurile publicitare de pe motoarele de cutare sau de pe site-uri, au ca obiectiv principal atragerea publicului int, astfel nct acesta s viziteze site-ul. Prima etap o constituie crearea de bannere, apoi studierea aspectelor demografice a diverselor site-uri pentru a fi gsite cele mai potrivite, dup care se recurge la negocierea costurilor. o Promovarea n media tradiional: Multe firme i afieaz adresa URL n seciuni speciale ale ziarelor cotidiene, ale publicaiilor de afaceri i ale mediei comerciale. Chiar i reclamele TV conin adrese de Web. Concluzia ar fi c este necesar tiprirea URL-ului pe toate materialele de comunicare i de marketing. o Promovare ncruciat cu site-uri complementare: Dac un site vinde un produs complementar unui produs furnizat de un alt site, acestea pot ajunge la un acord care const n transmiterea unor cupoane cu discount-uri care s atrag clienii ctre site-ul celuilalt. Acest lucru se poate realiza prin acordarea unei reduceri la produsele prezentate pe unul din site-uri la fiecare achiziie de produse complementare prezentate pe cellalt site. o Pltirea de comisioane altor site-uri pentru a oferi referine vizitatorilor i pentru a-i direciona spre site-ul promovat: Dac un site complementar a reuit s atrag un numr mare de cumprtori, acetia pot fi dirijai ctre site-ul respectiv dac se pltete pentru plasarea unei legturi sau a unui anun publicitar pe site-ul complementar. Preurile pentru acest tip de serviciu sunt foarte elastice. o Oferta de produse gratuite: Atragerea vizitatorilor i satisfacerea acestora se transmite informal i ctre alii. Oamenii pot fi atrai ctre site prin simplu fapt c li se ofer mostre sau informaii gratuite. Firmele care se bazeaz pe informaii, cum sunt cele care tipresc rapoarte, pot da un comunicat de pres prin care anun un important produs informaional. Firmele care nu activeaz n sectorul informaional pot de asemenea s transmit informaii care s se adreseze 18
consumatorilor i clienilor poteniali. Cumprtorii i potenialii clieni pot citi aceste articole gratis, iar dac tiu c site-ul este actualizat n mod regulat, ei se vor ntoarce periodic i i vor anuna i cunoscuii despre aceast caracteristic a site-ului. o Informarea utilizatorilor prin e-mail, atunci cnd se actualizeaz coninutul siteului: Se recomand ca site-urile s i ntiineze clienii la fiecare actualizare a coninutului lor pentru ca vizita pe care au repetat-o s capete valoare i s rezulte o ncurajare a revenirii lor pe site. Site-ul poate furniza clienilor si informaii n legtur cu modificrile efectuate prin intermediul adreselor de e-mail pe care le dobndete, de regul, n momentul n care clienii subscriu la site. Utilizarea unei astfel de tactici ajut la crearea unei baze de date cu ajutorul creia se vor determina nevoile i cerinele clienilor, fapt ce va conduce n final la creterea vnzrilor. Dintre metodele consacrate de marketing pe Internet si reclam on-line, promovarea site-urilor Web prin intermediul motoarelor de cutare s-a impus la ora actual ca fiind cea mai profitabil variant de publicitate pe Internet, n primul rnd datorit costurilor zero, n al doilea rnd datorit vizitatorilor de calitate pe care ii garanteaz aceast metod de ridicare a audienei site-urilor Web. Motoarele de cutare sunt programe special proiectate s exploreze Web-ul, deplasndu-se automat de la un site la altul pe calea legturilor existente ntre acestea. Nu avem de-a face cu intervenia operatorului uman, n general ntregul proces de investigare a Web-ului, culegere de informaii i clasificare a acestora realizndu-se prin mijlocirea robotului. Directoarele Web difer de motoarele de cutare prin aceea c se constituie n fapt ca i colecii de site-uri investigate i clasificate de operatori umani. n condiiile n care se opteaz pentru aceste metode de promovare, ar fi bine ca mai nti s se efectueze nscrierea n directoarele Web i dup aceea n motoarele de cutare. Explicaia const n faptul c este total nerecomandat utilizarea oricror tehnici de optimizare mai mult sau mai puin artificiale atunci cnd site-ul urmeaz s fie revizuit de un operator uman.
2.2.2 Etapa a II-a: Managementul bazelor de date Produsele i serviciile pe care site-ul de comer electronic le ofer spre vnzare clienilor, indiferent de modul n care vor fi livrate (prin pot sau direct prin Internet), vor fi stocate n cadrul site-ului n baze de date. Tot n baze de date (dar nu n cadrul acelorai baze de date ca i produsele) vor fi stocate i comenzile pe care clienii le adreseaz ctre site. Aceste comenzi pot fi pstrate chiar i dup onorarea lor, pentru a oferi clienilor un istoric al produselor pe care le-au comandat sau pentru studii de pia efectuate chiar de ctre compania ce deine site-ul. Este foarte important alegerea SGBD-ului (Sistemului de Gestiune a Bazelor de Date), cel puin din urmtoarele motive: 19
o pe msur ce afacerea va crete, crete i numrul de produse oferite spre vnzare, i, implicit, dimensiunea site-ului (a bazelor de date care corespund domeniilor din care este alctuit site-ul); rezult deci necesitatea stringent ca bazele de date s fie scalabile (s poat fi posibil creterea dimensiunii lor); o pentru baze de date de dimensiuni foarte mari, este important problema vitezei de acces la informaiile stocate n aceste baze de date. Dac motorul de cutare n cadrul bazelor de date nu este foarte performant, atunci, chiar i pentru cel mai simplu acces la informaiile din baz, timpul de cutare poate deveni prohibitiv.
2.2.3 Etapa a III-a: Plata i procesarea tranzaciilor Autorizrile sigure de cri de credit i procesarea comenzilor prin Internet sunt elemente de baz. Pentru a realiza n deplin siguran un transfer care implic numere de cri de credit prin Internet, este nevoie s se ia msuri de securitate referitoare la autorizarea plilor. Informaiile referitoare la crile de credit (numrul crii, nume deintor, telefon, etc.), care sunt transmise n momentul efecturii plii trebuie validate de ctre un organism de autorizare. De aceea, companiile care doresc s accepte efectuarea plilor prin Internet prin cri de credit trebuie s ia legtura cu un astfel de organism. Aceasta, la rndul lui, se afl n legtur cu instituia financiar care a eliberat cartea de credit, i, dup un schimb de mesaje criptate cu respectiva instituie, va aviza sau nu transferul de fonduri. Dac primete acceptul din partea organismului, vnztorul va efectua livrarea produselor ctre client i va nregistra comanda ca fiind onorat. Suma pltit de client pentru aceste produse va fi adugat la contul vnztorului.
2.2.4 Etapa a IV-a: Managementul produselor i al comenzilor Transportul produselor: n cazul n care site-ul de comer electronic al companiei ofer spre vnzare clienilor produse care se livreaz prin pot, compania trebuie s ia n considerare necesitatea de a stabili o colaborare cu un serviciu de distribuie prin pot. n funcie de serviciul de pot ales, compania poate s pun la dispoziia clienilor servicii suplimentare, cum ar fi urmrirea on-line a traseului pe care l parcurg produsele din momentul plecrii de la vnztor i pn n momentul sosirii la client. Urmrirea comenzilor i a strii acestora: n cadrul site-ului de comer electronic exist persoane care se ocup cu monitorizarea comenzilor, n cazul n care compania care deine site-ul a hotrt astfel. O comanda se poate gsi n trei stri: o capturat: comanda a fost preluat de ctre sistemul vnztorului, ns metoda de plat aleas de ctre client nu a fost nc validat o reglat: autoritatea care se ocup de autorizarea plilor a dat vnztorului un rspuns pozitiv referitor la certificarea metodei de plat a clientului
20
o respins: comanda este respins, ntruct nu a fost autorizat metoda de plat a clientului.
2.2.5 Etapa a V-a: Centru specializat de servicii Suport post-vnzri prin Internet: Compania poate decide s ofere suport tehnic clienilor pentru produsele pe care acetia le-au cumprat de pe site. n acest scop, pe site poate exista un domeniu separat, dedicat ntrebrilor i rspunsurilor, unde clienilor care ntmpin probleme s li se poat rspunde de ctre personalul tehnic al companiei. Chiar mai mult, n cadrul site-ului, poate exista un forum de discuii on-line, cu moderator sau nu, n cadrul cruia clienii s i poat mprti ntre ei experiena acumulat n folosirea produselor respective. Dac nu se dorete adoptarea nici uneia dintre soluiile propuse, trebuie s ne asigurm c exist mcar o legtur prin care clienii s poat trimite un mesaj prin pota electronic administratorului site-ului.
2.3 Sistem Electronic de Pli 2.3.1 Arhitectura unui Sistem Electronic de Pli (SEP) Un sistem electronic de pli se refer la totalitatea obiectelor care conlucreaz pentru asigurarea plii tranzaciilor ce se efectueaz. Sunt implicate, n general, trei entiti care interacioneaz: o banc B, un cumprtor C i un vnztor V. Sistemul electronic de pli conine i o mulime de protocoale care permit cumprtorului C s fac pli ctre vnztorul V. Un Sistem Electronic de Pli este format din dou nivele: o nivelul utilizator, care constituie nivelul ierarhic superior, i o nivelul sistem, care constituie nivelul ierarhic inferior. n continuare, vor fi descrise foarte pe scurt cele dou nivele: o nivelul utilizator: const din mulimea utilizatorilor i a tranzaciilor care au loc ntre acetia. Utilizatorii sunt grupai dup diverse roluri, dup modul n care interacioneaz n relaiile de afaceri dintre ei: cumprtorul, vnztorul, emitentul de bani electronici (banca), etc.; o nivelul sistem: const din mulimea entitilor fizice i a relaiilor care se stabilesc ntre ele. Entitile pot juca unul dintre urmtoarele roluri: purttor de bani electronici sau registru de cas. 2.3.2 Dispozitive folosite ntr-un Sistem Electronic de Pli Exist mai multe tipuri principale de dispozitive folosite: o portofelul electronic: este folosit de ctre cumprtor pentru a stoca banii electronici. Exist urmtoarele configuraii fundamentale: calculator de mn (hand-held computer): reprezint un calculator de dimensiuni reduse aflat n posesia clientului. Bncile sunt nelinitite 21
de controlul total al utilizatorului asupra resurselor dispozitivului de plat. Conectarea la punctele de acces ale SEP se face de obicei printr-o legtur serial n infrarou; cartela inteligent (smartcard): const dintr-un cip ncorporat ntr-o cartel de plastic. Spre deosebire de o cartel de credit obinuit, un smartcard dispune de un microprocesor. Comunicaia cu punctul de acces se face prin contact direct cu cititorul de cartel. Utilizatorul nu are acces la resursele hard i soft, fapt care avantajeaz bncile. Este imposibil deschiderea smartcard-ului i efectuarea unui reverseengineering (adic o metod de a afla modul n care a fost construit cartela prin dezasamblarea sa i parcurgerea n sens invers a pailor care se presupune c s-au urmat la creare); o portofel electronic cu observator: structur format din dou calculatoare: calculatorul clientului, prin care acesta comunic cu punctul de acces al SEP, i un calculator al bncii, ncorporat n cel al clientului, care previne dubla cheltuire a banilor electronici; o punctul de vnzare (POS): este folosit de ctre vnztor pentru a stoca banii electronici temporar. Din punct de vedere tehnic, are interfee att serial, prin infrarou sau wireless (local sau prin GSM/GPRS sau CDMA) ct i un cititor de smartcard/card magnetic; o distribuitorul de bani electronici: dispozitivul prin care se ncarc bani electronici n portofelul electronic al cumprtorilor. Moduri de implementare: distribuitor cont-bani electronici: soluie care permite incrementarea valorii din portofel pe baza retragerii unei sume de bani reali din contul deschis de cumprtor; distribuitor carte de credit-bani electronici: permite incrementarea valorii din portofel pe baza creditrii cumprtorului de ctre o cas de credit; distribuitor numerar-bani electronici: permite incrementarea valorii portofelului prin colectarea de la cumprtor a unei sume cash.
2.3.3 Tipuri de tranzacii ntr-un Sistem Electronic de Pli Tranzaciile reprezint schimburile de mesaje, sub forma unor protocoale, care se desfoar ntre entitile care joac diverse roluri ntr-un Sistem Electronic de Pli. Exemple de tranzacii: o tranzacia de identificare a utilizatorilor: O entitate verificator V verific dac alt entitate aprobator P este cea care pretinde c este. Pentru aceasta, V creeaz n mod aleator un mesaj de provocare, pe care l cripteaz cu cheia public a lui P i l trimite lui P. Acesta, folosind cheia sa secret, decripteaz mesajul, i l trimite napoi, n clar, lui V. V tie cheia public a lui P ca urmare a tranzaciei; 22
o o o o o o
tranzacia de obinere a unui certificat: toate cheile publice folosite ntr-un SEP sunt certificate de ctre unul sau mai multe centre de certificare. Astfel: informaii specifice utilizatorului (credite) + cheie public a utilizatorului + cheie secret a centrului duc la obinerea unui certificat. n general, certificatele au o perioad de valabilitate redus; tranzacia de control al accesului: furnizeaz protecie mpotriva folosirii neautorizate a unor entiti la nivelul sistem; poate folosi i n operaii de monitorizare (de exemplu, cnd un utilizator dorete s afle suma pe care o deine n cont); tranzacia de ncrcare: se desfoar ntre banc i distribuitor, dup o autentificare mutual prealabil; tranzacia de retragere: se desfoar ntre distribuitor i cumprtor, tot dup autentificarea mutual prealabil; tranzacia de plat: se desfoar ntre vnztor i cumprtor; poate fi offline sau on-line. La cele on-line, este implicat i banca; tranzacia de anulare: se refer la ultima tranzacie de plat ntre cumprtor i vnztor; tranzacia de depunere: implic vnztorul i colectorul; tranzacia de clearing: se desfoar ntre colector i banc sau ntre dou bnci.
2.3.4 Modaliti de plat Sistemele electronice de pli trebuie s ating nivele ridicate de securitate, vitez, caracter privat i confidenial, descentralizare i internaionalizare i s fie unanim acceptate de comerciani i oameni de afaceri. O trstur comun a majoritii acestor soluii o constituie utilizarea tehnicilor criptografice care asigur confidenialitatea, autenticitatea i integritatea mesajelor transferate ntre entitile implicate. n continuare sunt analizate cteva dintre cele mai cunoscute metode de plat electronic: Plata prin carduri bancare Sistemul de carduri a fost creat cu intenia de a-i permite cumprtorului s-i satisfac imediat dorina de cumprare de bunuri i servicii. Prin cartea de credit, riscul este transferat de la vnztor la instituia financiar care a emis cartea de credit. Procesul cuprinde urmtorii pai: o cumprtorul prezint vnztorului cartea de credit; o vnztorul trimite numrul crii de credit i detaliile tranzaciei la un sistem de autorizare; o acesta fie autorizeaz direct tranzacia, fie o direcioneaz la banca emitent a crii de credit, pentru aprobare; o periodic (de exemplu zilnic), vnztorul trimite detaliile tranzaciilor aprobate ctre banca sa; 23
o aceste informaii sunt trimise la asociaia emitorilor de cri de credit dup ce au fost procesate tranzaciile pentru care banca respectiva este i colectoare i emitoare de cri de credit; o la sfritul lunii, consumatorul primete facturile pe care trebuie s le achite, altfel va plti dobnda pentru creditul acordat de banca emitent a crtii de credit. Plata prin SoftNet ePay n Romnia plata direct prin card pe Internet este periculoas datorit nivelului potenial ridicat de fraud. Bncile nu accept n general pli prin card-uri pe Internet dect, eventual, cu asumarea total a riscului de ctre comerciant. Se folosete mai mult plata prin ATM, dar aceasta nu are aceleai beneficii cu plata on-line. ePay este un sistem romnesc realizat de ctre SoftNet, care permite reducerea nivelului de fraud ct mai aproape de zero astfel: o a fost introdus un model de plat cu trei actori: magazinul electronic, posesorul de card (clientul) i banca ce a emis cardul i al crei client este posesorul de card; o posesorul de card semneaz electronic la banc fiecare tranzacie. Doar tranzaciile acceptate de ctre acesta i marcate ca atare de ctre banc sunt autorizate; o plata efectiv se efectueaz doar dup ce datele privind plata transmise de magazinul electronic sunt comparate cu cele nregistrate de client i se constat o coresponden perfect. ePay are urmtoarele caracteristici: o numerele de card nu circul prin Internet i nu se stocheaz nici la client nici n magazinul electronic; o clientul nu poate folosi alte card-uri dect cele deinute oficial la banc. Prin urmare, nu se pot introduce numere de card furate; o clientul nu poate nega efectuarea unei pli. Fiecare acceptare de plat este semnat electronic i nregistrat la banc; o autorizarea plii se face instantaneu, comunicaia ntre cele trei entiti implicate fcndu-se prin Internet (cu criptare i autentificare). Un scenariu tipic de utilizare a sistemul de plat sigur prin Internet ePay este urmtorul: o clientul acceseaz cu un browser, prin Internet, magazinul electronic. Aici alege produsele dorite i le selecteaz pentru a fi introduse n coul virtual de cumprturi; o clientul, dup ce a finalizat alegerea produselor, trece n pagina de plat electronic. Aici selecteaz opiunea Plat prin ePay; o pe staia clientului se deschide o aplicaie de tip portofel electronic. Aceasta se conecteaz la banc i solicit autentificarea clientului (nume/parol i token VASCO). Dup validarea cu succes, portofelul electronic prezint 24
clientului lista cardurilor pe care acesta le deine la banc, invitndu-l s selecteze unul dintre card-uri pentru plata solicitat. Cardul selectat, mpreun cu informaii privind plata (sum, magazin, id_comand) sunt nregistrate n serverul ePay de la banc; o n portofelul electronic clientul aprob plata. Portofelul electronic se nchide, cednd controlul din nou magazinului electronic, transmindu-i identificatorul acceptului clientului n sistemul ePay. Magazinul electronic solicit bncii efectuarea efectiv a plii, transmind mpreun cu solicitarea i informaiile legate de plat (sum, magazin, ID comand); o ePay preia solicitarea i compar informaiile trimise de magazin cu cele transmise de ctre client. Dac acestea corespund ntocmai, se efectueaz plata n sistemul bancar (prin emularea unei tranzacii obinuite POS); o dac tranzacia s-a efectuat cu succes se transmite un mesaj de succes ctre magazinul electronic. Aceasta transmite aceast informaie ctre aplicaiile de procesare de comenzi ale operatorului magazinului. Plata prin CyberCash Pentru a efectua pli prin CyberCash (adresa de Internet: www.cybercash.com), consumatorul are nevoie de un software care simuleaz portofelul, face criptarea mesajelor i memoreaz tranzaciile. Ca i portofelul obinuit, acest portofel-software poate nregistra mai multe cri de credit. La instalarea software-ului, se genereaz o pereche de cheie public cheie privat. Cheia public se transmite la CyberCash care o memoreaz ntr-o baz de date, alturi de toate cheile publice ale vnztorilor i clienilor. Vnztorul are un software similar. Cumprtorul i vnztorul trebuie s fac schimb de chei nainte de a ti cu ce cheie public s cripteze mesajul adresat unui anumit corespondent. Derularea unei tranzacii este compus din urmtorii pai: o utiliznd un navigator Web, consumatorul selecteaz ce vrea s cumpere; o serverul vnztorului trimite portofelului Software o cerere de plat semnat prin care d detalii despre cumprtur i transmite tipul crilor de credit acceptate. Portofelul deschide o fereastr i afieaz suma i lista crilor de credit disponibile pentru selecie; o portofelul trimite un mesaj criptat i semnat cu numrul crii de credit i detalii privind tranzacia i acceptarea plii; o serverul vnztorului trimite acest mesaj mpreun cu un mesaj propriu semnat i criptat ctre Gateway. Gateway-ul este operat de ctre un agent al bncii colectoare al vnztorului. Aici mesajele sunt decriptate i comparate, iar dac se potrivesc, se trimite o cerere de autorizare convenional; o Gateway-ul rentoarce un rspuns ctre vnztor; informaiile privind tranzacia i numrul cartelei de credit sunt criptate cu cheia public a lui CyberCash, astfel nct vnztorul nu poate utiliza ilegal, ulterior, cartea de credit a cumprtorului; o vnztorul trimite un rspuns carte de credit ctre software-ul portofel. 25
Plata prin SmartCard (cartela inteligent) SmartCardul este, n esen, nlocuitorul portofelului obinuit. Tot coninutul unui portofel actual (acte, cri de credit, bani ghea), va fi nlocuit de una sau mai multe SmartCarduri. Din punct de vedere fizic, SmartCard arat ca o carte de credit, cu unul sau mai multe microcircuite de tip microcontroller nglobate. O cartel inteligent poate pstra de 10-100 de ori mai mult informaie dect o cartel magnetic, fiind totodat mult mai sigur. Conectat la un terminal de citire-scriere, SmartCard poate efectua funcii complexe de luare a deciziilor, proceduri sofisticate de autentificare pentru a preveni frauda. Deci beneficiile oferite de SmartCard sunt: sigurana, capabiliti active anti-fraud, flexibilitate n aplicaii, posibilitatea de validare off-line. Pentru a efectua operaii cu SmartCard, aceasta se introduce ntr-un dispozitiv de citire/scriere care poate fi cu sau fr contact. Acest cititor poate fi sub forma unui portofel care poate comunica cu alt portofel similar sau cu banca, pentru efectuarea de transferuri multivalutare. Astfel, SmartCard memoreaz direct echivalentul digital al sumelor de bani n loc s indice un cont la banc sau un credit acordat de banc. Cnd o astfel de cartel este folosit pentru a cumpra ceva, echivalentul sumei respective este efectiv transferat vnztorului i apoi mai departe ctre o instituie financiar. SmartCard poate fi rencrcabil sau nu. n acest ultim caz, cartela va fi aruncat atunci cnd suma nscris pe ea a fost epuizat. Transferul electronic de fonduri Pe Internet, cecul de hrtie poate fi nlocuit de un cec electronic, semnat digital de emitent. Un consoriu de bnci, FSTC Financial Services Technology Consortium (www.fstc.com), a statuat un model de cec electronic foarte asemntor cecurilor clasice pe hrtie. Pltitorul folosete un procesor, de tipul unui SmartCard PC, pentru a genera i semna digital un cec electronic ce va fi transmis prin pot electronic sau Web. El se trimite fie bncii cumprtorului care-l va onora dup verificarea semnturii digitale, trimind banii ctre banca vnztorului, fie direct vnztorului care va verifica semntura, l va semna la rndul su, i l va trimite bncii sale. Sistemul FSTC se bazeaz pe folosirea sistemelor criptografice cu chei publice pentru semntur digital i pleac de la premisa ca toate cheile publice ale participanilor i certificatele lor sunt cunoscute pretutindeni n sistem. Plata prin eCash Este prima soluie totalmente software pentru plile electronice. Tranzaciile se desfoar ntre vnztor i cumprtor, care trebuie s aib conturi la aceeai banc. Cumprtorii trebuie s ntiineze banca asupra faptului c doresc s transfere bani din conturile lor n aa-numitul cont eCash Mint. n orice moment, cumprtorul poate interaciona de la distan, prin calculatorul su i utiliznd un client software, cu contul Mint i poate retrage fonduri de aici pe discul calculatorului su. Formatul acestor fonduri este electronic, suite de zero i unu protejate criptografic. Ca urmare, discul cumprtorului 26
devine un veritabil portofel electronic. Apoi se pot executa pli ntre persoane individuale sau ctre firme, prin intermediul acestor eCash. eCash are un caracter privat: dei banca ine o eviden a fiecrei retrageri eCash i a fiecrui depozit Mint, este imposibil ca banca s stabileasc utilizarea ulterioar a eCash. Aceast proprietate este posibil datorit folosirii unor criptosisteme cu chei publice RSA, cu o lungime a cheii de 768 bii. Banii electronici (digicash): reprezint echivalentul electronic al banilor reali, i pot lua diferite forme, precum cartelele obinuite, a SmartCard-urilor, etc.
27
Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei
CAPITOLUL III TEHNOLOGII I INSTRUMENTE INFORMATICE UTILIZATE N DEZVOLTAREA APLICAIEI
3.1 Arhitectura Client/Server Problema proiectrii aplicaiilor a suferit de-a lungul timpului multe modificri dictate de necesitate i eficien i a dus la apariia unei palete variate de paradigme de programare. Una dintre cele mai rspndite la ora actual este programarea client/server. Arhitectura aplicaiei client/server este o infrastructur versatil, bazat pe mesaje i modular, care are scopul clar de a mbunti flexibilitatea, interoperabilitatea, scalabilitatea i uurina n utilizare de care duc lips tradiionalele arhitecturi mainframe i server de fiiere. n cadrul arhitecturii mainframe toat procesarea necesar obinerii rspunsului la o cerere lansat de o staie se fcea pe calculatorul central (mainframe-ul) care stoca i toate resursele la care avea acces clientul. nc unul din neajunsurile arhitecturii l reprezenta problema dificil a implementrii unei interfee cu utilizatorul. Arhitectura serverului de fiiere se bazeaz pe o arhitectur de fiiere distribuite, care sunt transmise de ctre server, la cerere, clientului, spre modificare sau interogare, i returnate apoi server-ului, spre stocare, la ncheierea operaiei. Limitrile celor dou arhitecturi tradiionale n contextul actual al unei reele de calculatoare i n special al Internetului (vzut ca o reea mare de resurse distribuite) au dus la rspndirea arhitecturii client/server. Arhitectura unei aplicaii client/server este fundamentat pe principiul separrii aplicaiei n module independente care pot fi executate n spaii de memorie diferite. n acest tip de arhitectur, modulul care face interogrile joac rolul de client (cel care cere un anumit serviciu), iar modulul care este interogat devine server (cel care satisface acel serviciu). Dei interaciunea ntre cele dou module se poate desfura n cadrul aceluiai calculator (ceea ce ne duce cu gndul la o asemnare cu programarea structurat), raportat la o reea, arhitectura ofer o modalitate convenabil de interconectare a serviciilor distribuite eficient n reea. Astfel, clientul i server-ul sunt, de regul, dou calculatore diferite n cadrul aceleiai reele. Mai mult, oricare din calculatoarele reelei poate aciona att ca i client, ct i ca server, pe principiul conform cruia orice calculator din reea reprezint un potenial ofertant de resurse (informaii sau servicii).
Fig. 3.1 Arhitectura generic client/server
28
n acest tip de arhitectur a fost nlocuit serverul de fiiere cu serverul de baze de date. Toate datele sunt reinute ntr-o baz de date i se afl sub administrarea unui server de date care proceseaz orice modificare asupra bazei de date. Acest sistem reduce foarte mult traficul n reea, deoarece comunicarea client/server se reduce la comunicarea cerinelor n format ct mai simplu din partea clientului (de ex. o comand SQL) i respectiv comunicarea doar a rezultatelor din partea server-ului. Ca reguli de funcionare a unei relaii client/server trebuie subliniate: o serverul comunic cu clientul dup un protocol dinainte stabilit; o un server trebuie s fie capabil s deserveasc mai muli clieni; o serverul trebuie s fie gsit de ctre client la aceeai adres; o clienii pot lansa cererile de oriunde din reea; o serverul rspunde cererilor pentru resurse fcute de clieni ntr-un mod transparent relativ la locaia, managementul sau distribuia resurselor; o serverul funcioneaz ca o interfa de acces la anumite resurse; Urmtoarea diagram pe 4 nivele detaliaz arhitectura unei aplicaii generice client/sever: Server Server Server de de aplicaie aplicaie Interfaa Interfaa aplicaiei aplicaiei Regulile Regulile de de business business Preluarea Preluarea informaiilor informaiilor Client
Fig. 3.2 Arhitectura unei aplicaii client/server generice
o la nivelul de preluare a informaiilor datele sunt preluate de la utilizator i transformate din format uman n format accesibil calculatorului i invers; este important de subliniat c n aceast etap nu este verificat corectitudinea datelor transmise, ele fiind doar adaptate necesitilor de utilizare; o la nivelul regulilor de business se stabilesc regulile jocului, adic se valideaz datele; la acest nivel nu se proceseaz nici un fel de cerere venit de la client, ci doar se stabilete corectitudinea datelor venite de la client i necesare serverului, sau invers; o interfaa aplicaiei este nivelul care rspunde de transformarea datelor din formatul transmis de client n formatul necesar serverului pentru a putea da un rspuns clientului; ca s lum un exemplu, aceast etap va transpune cererea clientului ntr-o instruciune SQL pe care o va transmite etapei finale; 29
o serverul de aplicaie este nivelul final, acela de procesare a datelor i de obinere a rezultatelor cerute de client; Aplicaiile client/server sunt structurate pe patru nivele. Cum se mparte aplicaia ntre client i server, cu alte cuvinte care nivel va fi situat pe partea de client a aplicaiei i care va fi situat pe partea de server, rmne la latitudinea dezvoltatorului.
3.2 Tehnologii i instrumente informatice utilizate n proiectarea aplicaiei Componentele necesare n activitatea de proiectare a unei aplicaii de succes sunt: notaia (limbajul de modelare), procesul i instrumentul. Aceste trei componente formeaz triunghiul de succes care st (sau ar trebui s stea) la baza proiectrii oricrei aplicaii. Cele trei componente se afl ntr-o relaie de interdependen, omiterea uneia dintre ele putnd cauza eecul procesului de proiectare a aplicaiei. Putem s nvm limbajul de modelare (notaia), dar dac nu tim cum s-l utilizm (dac nu cunoatem procesul de modelare), probabil c vom eua. Putem dispune de un proces foarte bun dar, dac nu suntem capabili s-l comunicm (folosind notaiile), probabil c vom fi sortii eecului. De asemenea, dac nu dispunem de un instrument pentru documentarea pailor parcuri n etapa de proiectare, probabil c munca noastr va fi sortit eecului. Elementele componente ale unei metodologii de analiz i proiectare a unei aplicaii software sunt limbajul de modelare i procesul de modelare. Limbajul de modelare reprezint o notaie grafic folosit pentru descrierea modelului, n timp ce procesul reprezint succesiunea de pai ce trebuie urmai pentru realizarea efectiv a modelului.
3.2.1 Limbajul de modelare Notaia (limbajul de modelare) reprezint unul din punctele cheie ale oricrui model, jucnd rolul de liant ntre prile componente ale procesului. Cele trei roluri de baz ale notaiei n cadrul activitii de proiectare a unei aplicaii sunt: o joac rolul unui limbaj cu ajutorul cruia sunt comunicate deciziile care nu sunt evidente sau care nu pot fi deduse din partea de cod; o ofer o semantic suficient de bogat nct s permit capturarea tuturor deciziilor strategice i tactice importante; o ofer un limbaj suficient de bogat pentru a permite oamenilor s raioneze pe marginea lui i ndeajuns de simplu pentru a permite instrumentelor de modelare s-l poat manipula. La ora actual, limbajul standard utilizat n construirea de schie de soft este reprezentat de UML (Unified Modeling Language Limbaj Unificat de Modelare). Metoda de modelare propus de UML este condus de cazuri de utilizare, centrat n jurul arhitecturii sistemului, iterativ i incremental. UML-ul reprezint un limbaj de vizualizare, specificare, construire i documentare a modelelor, a crui valoare const n: 30
o standardul su deschis; o acoper ntreg ciclul de via al dezvoltrii unui soft; o se bazeaz pe experiena celor care l-au dezvoltat; o este implementat de multe produse de tip CASE. Avnd n vedere c este un limbaj de modelare vizual ce folosete notaii standard, putem spune c UML-ul surprinde i descrie n limbaj grafic sistemul. Modelarea vizual are cinci caracteristici principale: o descoper procesele care au loc n sistem, folosind analiza cazurilor de utilizare (USE CASE); o se constituie ntr-un bun mijloc de comunicare; o simplific/reduce complexitatea sistemului; o definete arhitectura aplicaiei; o permite reutilizarea componentelor. Elementele de baz ale UML-ului sunt reprezentate de: o blocurile constructive: elemente, relaii i diagrame; o regulile ce dicteaz modul n care blocurile pot fi combinate; o mecanismele generale: specificaii, ornamente, diviziuni generale, mecanisme de extensie. Modelarea unei aplicaii necesit specificarea realitii astfel nct s se neleag mai bine sistemul dezvoltat. Mijloacele prin care sunt vizualizate blocurile constructive ale UMLului sunt reprezentate de diagrame. Acestea prezint n mod grafic o mulime de elemente reprezentate sub forma unui graf conex de noduri (elemente) i arce (relaii). Cele nou tipuri de diagrame puse la dispoziie de UML sunt: de cazuri de utilizare, de activiti, de clase, de colaborare, de componente, de exploatare, de obiecte, de secven i de stri. Voi insista asupra diagramelor de cazuri de utilizare i asupra celor de activiti, ntruct acestea au fost folosite n etapa de proiectare a aplicaiei prezentat n lucrarea de fa. Modelarea cazurilor de utilizare constituie o tehnic independent, ortogonal cu modelarea obiect. Ea poate fi inclus la fel de bine ntr-o metodologie orientat-obiect sau structurat. Rolul acestui tip de modelare este de a reprezenta ntr-o form grafic funcionalitile pe care trebuie s le ndeplineasc aplicaia n faza final. Modelul realizat de diagramele cazurilor de utilizare, mpreun cu descrierea succint a fiecrui caz de utilizare determinat, se numete model al cerinelor. Cazurile de utilizare arat comportamentul sistemului sau a unei pri din sistem i reprezint o descriere a unui set de secvene de aciuni pe care un sistem le execut pentru a produce un rezultat observabil pentru un actor. Cazurile de utilizare ale unui sistem trebuie s surprind tot ce-i poate dori un utilizator de la sistemul respectiv. Diagramele cazurilor de utilizare sunt formate din dou categorii de entiti (actori i cazuri de utilizare) i relaiile dintre acestea. Trebuie s se fac o distincie clar ntre actori i utilizatori. Utilizatorul este o entitate care folosete sistemul. n relaia pe care o are cu un caz de utilizare, actorul reprezint un 31
anumit rol jucat de utilizator. n circumstane diferite, acelai utilizator se poate comporta ca mai muli actori. Cazurile de utilizare reprezint o tehnic de analiz util pentru nelegerea i definirea cerinelor funcionale ale unei aplicaii. Aceast tehnic ajut la concentrarea ateniei asupra utilizabilitii aplicaiei, altfel spus asupra a ceea ce utilizatorii ateapt de la aplicaie. Diagramele de activiti reprezint scheme logice cu ajutorul crora sunt prezentate fluxurile de control dintre activitile implicate n executarea unei funcionaliti a aplicaiei. Ele sunt folosite la modelarea aspectelor dinamice ale aplicaiei i presupun modelarea unui proces pas cu pas.
3.2.2 Procesul Un proiect care urmrete dezvoltarea unei aplicaii software poate fi considerat de succes dac ndeplinete urmtoarele condiii: o satisface sau chiar depete nevoile utilizatorilor; o face economie de timp i resurse; o produsul rezultat este adaptabil la diversele modificri care ar putea s apar; o ciclul de via al dezvoltrii produsului promoveaz creativitatea i inovaia, putnd n acelai timp fi controlat, astfel nct s ofere certitudinea c produsul rezultat este complet. n etapa de demarare a unui proiect de dezvoltare de soft este esenial s se stabileasc procesul ce va fi urmat. Acesta descrie efectiv paii care trebuie urmai n vederea dezvoltrii cu succes a unei aplicaii. Procesul de dezvoltare a unei aplicaii este structurat pe dou domenii (dimensiuni), i anume: o dimensiunea temporal: diviziunea ciclului de via n faze i iteraii; o componentele procesului: producerea unei mulimi specifice de elemente (artefacte) cu activiti bine definite. Structurarea unui proces n funcie de dimensiunea temporal induce urmtoarele faze: o lansarea specificarea succint a proiectului; o elaborarea planificarea activitilor i resurselor necesare; specificarea caracteristicilor i proiectarea arhitecturii; o construcia construirea produsului prin iteraii incrementate; o tranziia furnizarea produsului comunitii (distribuire, instruire, etc.). Mulimea componentelor procesului ar trebui s conin: o modelarea afacerii identificarea nevoilor utilizatorilor i a ateptrilor acestora n ceea ce privete funcionalitatea aplicaiei; o identificarea cerinelor descrierea unei viziuni asupra aplicaiei, mpreun cu un set de cerine funcionale i non-funcionale; o analiza i proiectarea descrierea modului de realizare a aplicaiei n faza de implementare; 32
o implementarea generarea efectiv a codului surs; o testarea verificarea ntregii aplicaii. n proiectarea aplicaiei prezentat n lucrarea de fa voi folosi un proces bazat pe cazuri de utilizare. Scenariile i cazurile de utilizare determin fluxul procesului, din momentul stabilirii cerinelor aplicaiei i pn n faza de testare.
3.2.3 Instrumentele utilizate (RationalRose, DBDesigner) Un element important al procesului de proiectare a unei aplicaii l reprezint instrumentele care pun la dispoziia utilizatorului o gam variat de faciliti n ceea ce privete modelarea vizual a procesului. Instrumentele din familia Rational Rose au fost proiectate pentru a oferi dezvoltatorilor de aplicaii un set complet de unelte de modelare vizual n scopul dezvoltrii de soluii robuste i eficiente care s vin n sprijinul nevoilor reale din mediile de afaceri implementate cu ajutorul sistemelor distribuite, client/server. Produsele RationalRose mprtesc un standard comun: acela de a face proiectarea accesibil att programatorilor, care doresc realizarea unei proiectri logice a aplicaiilor, ct i amatorilor care doresc s modeleze procese de business. n lucrarea de fa am utilizat Rational Rose n procesul de modelare vizual a diagramelor de activiti, precum i a celor care prezint cazurile de utilizare ale aplicaiei. Un alt instrument extrem de important pe care l-am utilizat n faza de proiectare este DBDesigner. Acesta este un instrument utilizat la modelarea vizual a bazelor de date, avnd ncorporate funcionaliti care permit design-ul, modelarea, crearea i ntreinerea bazelor de date. A fost dezvoltat i optimizat pentru bazele de date de tip MySQL cu scopul de a pune la dispoziia utilizatorilor acestui tip de baze de date un instrument puternic de proiectare.
3.3 Tehnologii i instrumente informatice utilizate n implementarea aplicaiei 3.3.1 Justificarea soluiei Apache + PHP + MySQL Internet-ul este n al treilea stadiu de dezvoltare, iar dinamic i interactiv sunt atributele eseniale ale oricrui site de succes. Conform lui Graeme, PHP i MySQL reprezint cea mai bun metod actual pentru crearea unor site-uri care folosesc baze de date. Acest fapt este demonstrat de un studiu de cercetare al companiei Netcraft care arat c dac n iunie 1998 existau 7.500 de host-uri care utilizau PHP n martie 1999 numrul acestora a crescut la 410.000. Aceast combinaie a primit i titlul de Database of the Year la Webcon98. MySQL este un server de baze de date mic i compact, ideal att pentru aplicaii mici, ct i pentru dezvoltarea marilor proiecte. n afara faptului c suport standardul SQL (ANSI92), poate rula pe mai multe platforme i permite sisteme multithreading pentru serverele Unix, ceea ce aduce o cretere important a performanei. Sub WindowsNT, 2000 sau XP, MySQL este lansat ca un serviciu, pe cnd sub Windows95/98, ca un proces normal. 33
PHP este un limbaj de programare pentru server. Codul PHP poate fi integrat n interiorul codului HTML. Scriptul PHP va fi apoi procesat de ctre server care va returna un fiier HTML. Acest tip de interaciune permite executarea unor operaii destul de complexe. Aplicaiile WEB reprezint att prezentul ct i viitorul, ele funcionnd pe baza unei arhitecturi client/server. Aplicaiile realizate cu PHP i MySQL utilizeaz un singur client i anume browser-ul WEB. Limbajul de baz al browser-ului WEB este HTML. Acest limbaj dispune de o serie de tag-uri care descriu modul n care va arta o pagin WEB. Majoritatea prelucrrilor efectuate de aplicaiile Web au loc pe sever. O aplicaie specific, numit server Web, va asigura comunicarea cu browser-ul. Un server de baze de date relaionale stocheaz informaiile pe care le va accesa aplicaia. n final mai este nevoie de un limbaj care s intermedieze interogrile ce apar ntre serverul Web i serverul de baze de date. Acest limbaj va fi utilizat i pentru a executa anumite operaii asupra informaiilor care vin spre i dinspre serverul Web.
3.3.2 PHP PHP limbaj scriptural server-side pentru generarea dinamic de coninut Web PHP, acronimul de la PHP: Hypertext Prepocessor, este un limbaj de programare folosit cu precdere ca i limbaj scriptural server-side n generarea dinamic de coninut Web. Modelul PHP implementeaz paradigma generrii dinamice de coninut Web i a aprut ca alternativ necesar la tradiionalele sisteme ASP/VBScript/Jscript al Microsoftului, JSP/Java al Sun Microsystems-ului i CGI/Perl. n modelul PHP, structura unei pagini Web PHP este cea a unei pagini HTML care ncapsuleaz pe alocuri cod PHP. Caracterul dinamic al unei pagini Web PHP este asigurat prin: o posibilitatea manipulrii coninutului paginii prin secvenele ncapsulate de cod PHP n structura de tag-uri a paginii, cod care poate insera text HTML direct n structur; o posibilitatea interpretrii datelor unui formular HTML: PHP permite accesul codului PHP la informaiile primite de pagin de la browser prin structuri de date predefinite i completate automat; o suport pentru ntreinerea unei sesiuni, menit s rein date ntre dou cereri succesive de pagini ctre acelai server; o funcii pentru transmiterea headere-lor HTTP pentru autentificare; o funcii pentru setarea cookie-urilor; o posibilitatea redirecionrii cererilor de pagin; o librrii ce permit generarea, manipularea i trimiterea ctre browser de imagini, animaii, PDF-uri; o interfaa de conectare cu majoritatea SGBD-urilor; o interfaa de conectare la un server de e-mail. Istoric 34
A nceput ca i un pachet de scripturi Perl, prin care Rasmus Lerdorf aduna date despre vizitatorii paginii sale personale Web. Prima versiune a pachetului fcut public a primit denumirea Personal Home Page; i s-a adugat ulterior un scripting engine care mpreun cu o unealt ncorporat permitea analizarea datelor unui formular HTML (Form Interpreter) - devenind astfel PHP/FI, cunoscut i ca PHP2 -, pentru ca s ajung un proiect aflat n minile unui grup de programatori dornici s dezvolte o unealt pentru probleme mai complicate, deschizndu-se astfel drumul lui PHP3. Versiunea 3 a limbajului apare dup o rescriere a scripting engine-ului i prin introducerea unui API care permite programatorilor extinderea capacitilor limbajului prin dezvoltarea de module. ncepnd cu versiunea 4, PHP beneficiaz de scripting engine-ul Zend, rescris dup cel vechi. Odat cu PHP4, limbajul PHP a introdus un motor rapid de parsing care, pe lng funciile PHP-ului de conectare la baze de date, suportul XML sau suportul pentru servlei Java, sistemul de gestiune a sesiunilor i funciile IMAP, reuete s transforme acest limbaj open source ntr-unul de top datorit muncii grele depuse zi i noapte de grupul de dezvoltatori pentru adugarea de funcionaliti i upgrade, bazat doar pe rspunsurile i cererile utilizatorului. Principiul de funcionare ntr-un scenariu tipic de cerere de pagin Web venit din partea unui browser: o server-ul de Web tie, prin configurarea sa i din extensia paginii cerute, c pagina trebuie preprocesat de PHP anterior servirii acesteia ctre browser; o PHP interpreteaz doar secvenele ncapsulate de cod PHP (delimitate de marcajele <?php i ?>) din pagina Web, secvene care pot completa dinamic pagina prin simple inserii de text n structura de tag-uri HTML a paginii (care este ignorat de preprocesor, dar reprodus la ieire); o server-ul trimite browser-ului pagina pe care PHP i-o returneaz n urma interpretrii, pagin n format HTML. Caracteristici Evidenta simplitate n utilizare a acestui model, mbinat cu caracteristici dintre cele mai complexe de care dispune PHP-ul, a propulsat modelul n fruntea tehnologiilor de dezvoltare a aplicaiilor Web cu coninut dinamic. PHP atrage att iniiaii n ale programrii, ct i pe cei experimentai prin: o sintaxa simpl, relaxat, uor de utilizat: ca limbaj de programare slab tipizat, variabilele PHP nu trebuie declarate i pot reine orice tip de obiecte; o similitudinea sintaxei cu cea a limbajelor de programare structurat consacrate precum C i Perl; cu o sintax ce satisface toate ateptrile de la un limbaj de programare att interpretat ct i compilat, structurat sau orientat-obiect, PHP5 permite programatorilor mai experimentai s dezvolte aplicaii complexe cu un efort net mai mic; 35
o independena de platform: a fost portat pe toate sistemele de operare majore, incluznd UNIX, Linux, Windows i MacOs i interacioneaz cu majoritatea serverelor Web; o e open-source: spre deosebire de produsele comerciale similare, care vin cu licen limitat i fr acces la surs, dezvoltatorul Web are libertatea de a modifica i completa limbajul dup propriile nevoi, fr timpii mori dintre patch-uri i fr teama c la un moment dat comerciantul va decide s nu mai susin produsul; o librrie open-source i extensibil de module: beneficiind de o comunitate foarte rspndit de dezvoltatori software, PHP ofer programatorului Web, chiar mpreun cu pachetul standard, un numr impresionant de module reutilizabile i uurina (datorit sintaxei) n crearea de astfel de componente reutilizabile i modulare; astfel, extensiile PHP ofer suport pentru acces la API-ul Windows-ului, managementul proceselor pe sisteme de operare din clasa UNIX-ului, manipularea formatelor de comprimare ZIP/gzip/bzip2, generarea de documente n format PDF, Macromedia Flash, i multe altele; o eficien: scripting engine-ul Zend din spatele limbajului este optimizat pentru timpul scurt de rspuns necesar aplicaiilor Web; poate chiar s fie folosit ca i modul al server-ului de Web, mbuntind i mai mult timpul de reacie; testele pe care Zend Tehnologies le face publice pe propriul site subliniaz msura n care PHP surclaseaz competiia; o interfaa prietenoas de conectare la o gam foarte mare de servere de baze de date: n conformitate cu nevoia aplicaiilor Web de a interaciona n mod dinamic cu utilizatorul n vederea prezentrii informaiilor de interes care, de regul, sunt pstrate ntr-o baz de date, scripturi PHP de 2 sau 3 linii rezolv probleme simple de conectare i executare de instruciuni SQL asupra bazelor de date; o ncepnd cu versiunea 4.0, deine suport minimalist pentru programarea orientat-obiect, suport devenit complet n versiunea 5.0;
3.3.3 MySQL Bazele de date au devenit o parte integrant din via de zi cu zi a fiecrui om. Fr o structurare a datelor n baze de date, nu ar exista o anumit ordine ntre lucruri, gestiunea datelor devenind un lucru foarte greu, poate chiar imposibil. Bncile, universitile i bibliotecile sunt doar trei exemple de organizaii care depind n mare msur de bazele de date i de gestiunea acestora. Pe Internet motoarele de cutare, procesele de cumprturi on-line, i chiar conveniile de denumire a tuturor site-urilor Web sunt activiti care nu s-ar putea desfura fr utilizarea bazelor de date. Dup T.Conolly, o baz de date reprezint o colecie partajat de date, ntre care exist relaii logice (i o descriere a acestor date), proiectat pentru a satisface necesitile informaionale ale unei organizaii.
36
Un Sistem de Gestiune a Bazelor de Date sau SGBD (n limba englez DBMS - Data Base Management System) reprezint un ansamblu de programe pentru gestiunea datelor sau un mediu de programare destinat gestiunii datelor din baza de date, care asigur: o ncrcarea bazei de date, o actualizarea i interogarea acesteia, o interfaa cu sistemul de operare n vederea simplificrii accesului la date. Un sistem de gestiune a bazelor de date care este implementat pe calculator i care gestioneaz interfaa cu aceste date, formeaz ceea ce se numete un server de baze de date. Arhitecturii client-server realizat de perechea de aplicaii browser - server de web (de obicei Internet Explorer - Apache) i se adaug nc o pereche de aplicaii, script asociat formularului - server de baze de date. n acest tandem scriptul asociat formularului (scris n PHP, C, C++, Perl, etc) este client, iar serverul de baze de date (MySQL, Oracle, etc) are rolul de server. Scriptul formuleaz comenzi SQL, iar serverul SQL le execut. MySQL este un sistem de gestiune a bazelor de date relaionale foarte rapid i robust, fiind cel mai popular din clasa sa. MySQL Server a fost creat pentru a lucra cu baze de date mai rapid dect soluiile deja existente la ora actual pe pia. Serverul MySQL controleaz accesul la datele utilizatorului, accesul este permis mai multor utilizatori autorizai. MySQL este un server multi-user i multi-thread i utilizeaz limbajul standard de interogare a bazelor de date (SQL Standard Query Language). MySQL este disponibil n mod public din 1996, dar istoria dezvoltrii sale ncepe nc din 1979 i a ctigat de mai multe ori premiul cititorilor - Linux Journal Readers' Choice Award. MySQL este disponibil sub o licen Open Source, dar exist i sub licene comerciale. Este rapid, iar costul su este nul, fiind distribuit gratuit sau foarte mic, distribuit sub o licen comercial, dac aceasta este necesar aplicaiei utilizatorului i este mult mai uor de configurat dect multe alte produse asemntoare. Popularitatea MySQL se datoreaz n primul rnd multiplelor faciliti oferite de acesta, dintre care vom aminti: o viteza de execuie: programatorii susin c MySQL este cel mai rapid sistem de gestiune a bazelor de date care se gsete la ora actual pe pia; o uurina n utilizare: MySQL este un sistem de gestiune a bazelor de date cu performane ridicate dar relativ simplu de utilizat, a crui configurare i administrare sunt mult mai simple dect n cazul sistemelor mai mari; o accesul concurent la date de ctre un numr nelimitat de utilizatori : la serverul MySQL se pot conecta mai muli clieni simultan; clienii pot folosi mai multe baze de date simultan; se poate obine acces la MySQL n mod interactiv, folosind numeroase interfee care permit introducerea de interogri i vizualizarea rezultatelor: clieni n linie de comand, browsere Web sau clieni Window System; de asemenea este posibil o varietate de interfee de programare pentru limbaje precum PHP, C, Perl, Java; o conectivitatea i securitatea: MySQL poate fi folosit integral n reele, iar bazele de date sunt accesibile de oriunde din internet, oferind astfel posibilitatea partajrii datelor cu oricine, oriunde; MySQL are controlul 37
accesului astfel nct persoanele care nu au dreptul s citeasc datele nu vor avea aceast posibilitate o distribuia liber: MySQL este gratuit, fapt ce a atras extinderea fr precedent a folosirii acestui server de baze de date
Distribuia MySQL include urmtoarele: o un server SQL: acesta ce reprezint motorul care activeaz MySQL i furnizeaz accesul la bazele de date; o programe client pentru accesul la server: acestea sunt reprezentate de programe interactive care permit introducerea de interogri n mod direct i vizualizarea rezultatelor; de asemenea exist numeroase programe administrative i utilitare ce permit rularea site-ului; o o bibliotec client: cu ajutorul acesteia se pot scrie propriile programe client n C; n acelai timp, biblioteca furnizeaz baza de date pentru tere asocieri pentru alte limbaje. MySQL este un sistem client-server alctuit dintr-un server SQL multi-thread care are faciliti pentru mai muli utilizatori, mai multe programe i biblioteci client, instrumente de administrare i un numr mare de interfee de programare. Server-ul de baze de date este un program localizat pe calculatorul responsabil cu stocarea datelor, care ascult cererile clienilor sosite prin reea i obine acces la coninutul bazei de date n funcie de aceste cereri, n scopul de a furniza clienilor informaiile solicitate. Clienii reprezint programe care se conecteaz la server-ul de baze de date i efectueaz interogri pentru a-i indica acestuia informaiile pe care le doresc. Avnd n vedere c MySQL suport o gam variat de produse software, exist posibilitatea ca multe din limbajele de programare deja folosite de anumii utilizatori s suporte deja interfaa cu acest produs. Orice main care dorete s proceseze interogri asupra unei baze de date MySQL trebuie s ruleze MySQL server MySQLd , care este responsabil de tot traficul de tip incoming sau outgoing cu baza de date. Ca orice server, MySQLd primete pe un port particular (3306) eventualele cereri de conexiune ale unui client care trimite cereri ctre o baz de date via MySQLd. Acest client poate fi un script n PHP care, graie modelului DBI, poate trimite o cerere ctre baza de date prin intermediul serverului MySQL, sau chiar clientului command-line MySQL. Clientul MySQL este o interfa interactiv pentru trimiterea de comenzi ctre server. Principalele motive pentru folosirea pe scar larg a MySQL sunt viteza, stabilitatea i facilitatea n utilizare. De asemenea MySQL are o serie de caracteristici care au fost dezvoltate prin colaborarea foarte apropiat cu utilizatorii acestui limbaj. Aceste caracteristici ale limbajului se datoreaz faptului c a fost proiectat nc de la nceput pentru gestionarea unui volum foarte mare de date, iar experiena n folosirea sa acumulat de-a lungul anilor i-a spus cuvntul. MySQL ofer astzi un set complet i util de funcii. Conectivitatea, viteza i securitatea fac ca MySQL s fie unul din cele mai potrivite produse pentru gestiunea bazelor de date pe Internet. 38
3.3.4 Apache Un server Web este un daemon care accept conexiuni conform protocolului HTTP, rspunznd cererilor recepionate de la clieni. Ca i alte protocoale utilizate n Internet, protocolul HTTP (HyperText Transfer Protocol) este un protocol de tip cerere-rspuns, bazat pe TCP/IP, destinat transferurilor de informaii hypermedia. Serverul Web Apache este un proiect al Apache Software Foundation i const ntr-un efort colectiv cu scopul declarat de a dezvolta i ntreine un server Web care ofer servicii HTTP pentru sistemele de operare moderne precum UNIX i Windows, caracterizat de calitile: open-source, securizat, eficient i extensibil. Proiectul Apache este dezvoltat de o comunitate de dezvoltatori i utilizatori cunoscut sub denumirea de Apache Group, care n procesul de dezvoltare se bazeaz pe consens i colaborare. Acestui numr mare de dezvoltatori i se adaug o comunitate substanial de programatori i/sau simpli utilizatori care contribuie cu idei, documentaie, cod i mai ales feedback-ul necesar unei dezvoltri complete. Devenit cel mai popular server Web nc din aprilie 1996, Apache ajungea n noiembrie 2005 ntr-un top al serverelor Web fcut de Netcraft Web Server Survey, serverul fiind folosit de 70% din totalitatea site-urilor de pe Internet, mai mult dect toate celelalte servere la un loc. Ajuns la versiunea 2.2.2, Apache depete servere comerciale ale unor firme de prestigiu, prin: o opiunile de configurare i design-ul modular: este foarte uoar scrierea de module care s satisfac o funcionalitate particular, n cazul n care acestea nu sunt deja implementate n librria proprie. o portabilitate: versiunea original a serverului Apache a fost dezvoltat pentru UNIX, dar exist acum i versiuni care ruleaz sub OS/2, Windows i alte platforme. Dorina creatorilor Apache, dup cum se specific n site-ul Grupului Apache, este ca platforma sa s fie folosit de ct mai mult lume (companii mari sau mici, instituii de cercetare, coli, Intranet-uri ) i s se acopere ct mai multe domenii de activitate. Cteva caracteristici ale serverului Apache sunt: o are foarte multe faciliti: Apache are suport XML, incluziune de fiiere pe parte de server, rescrierea URL-urilor, gzduire virtual, pentru a enumera doar cteva dintre ele; o este modular: dac se dorete folosirea unei faciliti care nu este implementat n nucleul Apache sunt foarte mari anse s existe un modul care poate aduga serverului acea facilitate; o este extensibil: dup cum am menionat codul surs fiind gratis, dac nu se gsete un modul care s ofere funciile de care este nevoie la un moment dat, este posibil crearea unuia nou, care s serveasc nevoilor personale;
39
o este popular: n acest moment, serverele web Apache acoper aproximativ 60% din piaa serverelor web; o este gratuit: nu n ultimul rnd, faptul c este distribuit n mod gratuit este un atu foarte mare pentru Apache.
40
Capitolul IV Dezvoltarea Aplicaiei
CAPITOLUL IV DEZVOLTAREA APLICAIEI
4.1 Determinarea cerinelor unei aplicaii de food-ordering Primul pas n dezvoltarea aplicaiei l reprezint stabilirea potenialilor beneficiari, precum i a ateptrilor acestora n ceea ce privete funcionalitatea aplicaiei. Printr-o analiz atent a cerinelor beneficiarilor se va delimita comportamentul aplicaiei ce urmeaz a fi implementat. Tehnica folosit n stabilirea cerinelor beneficiarilor presupune efectuarea unui studiu al pieei aplicaiilor care ofer servicii similare, n vederea documentrii avantajelor i dezavantajelor acestora. Scopul urmrit este delimitarea comportamentului unei aplicaii ce beneficiaz de cele mai bune practici ntlnite i le nlocuiete pe cele care nu satisfac ntocmai necesitile beneficiarilor. Rezultatele acestei etape le voi documenta n diagrame care prezint cazurile de utilizare ale aplicaiei.
4.1.1 Studiul pieei aplicaiilor care ofer servicii de comenzi on-line a preparatelor culinare n vederea unei mai bune nelegeri a aplicaiilor Web care ofer servicii de comenzi on-line a preparatelor culinare, precum i n vederea proiectrii unei aplicaii care s suplineasc, pe ct posibil, neajunsurile acestora, am efectuat un studiu de pia. Studiul s-a bazat pe analiza a trei dintre aplicaiile Web care ofer posibilitatea de a efectua comenzi online de preparate culinare, i anume: www.culinar.ro, www.chelner.ro, www.mancarebrasov.ro. www.culinar.ro Este site-ul cu traficul cel mai mare dintre cele analizate, situndu-se pe locul 6 la categoria Comer Electronic n cadrul topului efectuat de www.trafic.ro i pe locul 138 n clasamentul general. Situarea sa pe un loc att de nalt n top se poate datora n primul rnd timpului ndelungat de funcionare, aproape 6 ani de la nscrierea pe www.trafic.ro, timp n care site-ul a reuit s-i promoveze imaginea i s-i atrag un numr semnificativ de clieni fideli. Un alt lucru care a contribuit la succesul site-ului ar putea fi acela c ofer dou seciuni de larg interes pentru publicul din Romnia: o seciune n care sunt prezentate reete culinare i o seciune de forum, care permite utilizatorilor s-i mprteasc opiniile n cele mai variate domenii, in special cel gastronomic. Pe lng posibilitatea comandrii de preparate culinare cu livrare la domiciliu, utilizatorii mai pot beneficia de facilitile seciunilor de catering i cumprturi on-line. n ce privete comenzile de preparate culinare, site-ul pune la dispoziia clienilor oferta a 19 furnizori, cu raza de acoperire n zona Municipiului Bucureti. 41
Dintre facilitile oferite utilizatorilor se pot enumera: o posibilitatea nscrierii n ClubCulinar prin crearea unui cont de utilizator; facilitile oferite membrilor sunt variate, de la primirea zilnic prin e-mail a ofertelor speciale, posibilitatea crerii on-line a propriei cri de bucate, accesul la forum, pn la posibilitatea de a participa la concursurile organizate de Culinar.ro; o monitorizarea continu a furnizorilor i oferirea de informaii privind seriozitatea acestora, conexiunea la internet i modalitile de preparare a produselor n conformitate cu respectarea regulilor de igien; o posibilitatea de a introduce n comand preferinele personale ale utilizatorului pentru fiecare produs comandat (preferine legate n general de gradul de condimentare sau de ingredientele coninute) o posibilitatea efecturii de comenzi cu dat de livrare diferit de data comenzii; o posibilitatea de a selecta adresa de livrare dintr-o list care conine adresele la care s-a mai comandat, precum i posibilitatea stabilirii unei adrese diferite pentru efectuarea plii. Printre neajunsurile ntmpinate de utilizatori se numr: o o interfa nu tocmai prietenoas, destul de ncrcat, care ngreuneaz navigarea; site-ul urmrete prezentarea unui numr ct mai mare i mai variat de informaii utile consumatorilor, ns efectul nu este cel scontat: de cele mai multe ori utilizatorii ajung s se piard n multitudinea de informaii, renunnd astfel la intenia de a efectua comenzi; o inexistena unui istoric al comenzilor care s permit utilizatorilor vizualizarea, modificarea sau relansarea unor comenzi anterioare; o lipsa posibilitii de administrare a datelor despre contul personal; o generarea automat a listei adreselor de livrare, fr oferirea de faciliti n vederea modificrii acestor adrese. www.chelner.ro Obiectivul site-ului este acela de a prezenta oferta furnizorilor care asigur livrarea la domiciliu a preparatelor culinare, precum i a firmelor de catering, care asigur mesele de prnz pentru diferite firme sau care se ocup cu organizarea de evenimente. Publicul int este reprezentat de bucureteni ntruct raza de acoperire a furnizorilor se afl n zona Municipiului Bucureti. Printre facilitile oferite se numr: o posibilitatea crerii unui cont de utilizator; din momentul crerii contului, utilizatorul dispune de faciliti care i permit gestionarea adreselor de livrare, vizualizarea istoricului de comenzi (pentru o perioad limitat de timp), precum i gestionarea grupurilor din care face parte; o posibilitatea efecturii de comenzi n grup: mai muli utilizatori pot crea un grup prin intermediul cruia s efectueze comenzi, fiecare utilizator putndu-i aduga n mod individual comanda; 42
o posibilitatea de a solicita eliberarea unei facturi pentru produsele comandate; o posibilitatea de a recomanda un furnizor prin intermediul unui formular; o monitorizarea atent a comenzilor, ceea ce ofer n permanen clientului posibilitatea de a vizualiza stadiul n care se afl comanda iniiat (lansat, anulat, acceptat, refuzat, confirmat sau efectuat). Punctele slabe ale aplicaiei sunt reprezentate de: o deficiene n ceea ce privete structurarea informaiilor despre produse i furnizori; o imposibilitatea de a relansa o comand din istoricul de comenzi; o lipsa unui motor de cutare care s permit clienilor regsirea produselor n funcie de anumite criterii cum ar fi: tipul produsului, preul, furnizorul, etc www.mancare-brasov.ro Este un site care se adreseaz braovenilor, cu intenia de a prezenta oferta furnizorilor de pe piaa Braovului care asigur livrarea la domiciliu i de a facilita procesul de comandare a preparatelor culinare. Aplicaia beneficiaz de o interfa prietenoas i un design unic i unitar, fapt care va contribui decisiv la atragerea clientelei. Fiind abia la nceput, site-ul prezint doar ofertele a cinci furnizori, dintre care doi ofer servicii de livrare la domiciliu. Printre punctele forte, menite s vin n ajutorul utilizatorului, se numr: o posibilitatea de a vizualiza imagini cu produsele aflate n oferta furnizorilor; o posibilitatea de a contacta furnizorul prin intermediul formularului de contact al fiecrui furnizor; o posibilitatea de a vizualiza furnizorii n funcie de regimul de funcionare (restaurante, pizzerii, fast-food-uri, etc); Prile mai puin forte ale aplicaiei se refer la: o lipsa unei structurri pe categorii a produselor oferite, care s conin preparatele puse la dispoziia consumatorului de ctre toi furnizorii; o lipsa facilitilor de administrare a contului i adreselor de livrare; o prezentarea unei oferte limitate de preparate (lucru de neles totui, avnd n vedere faptul c site-ul funcioneaz de 2 luni). nc de la prima vedere, se observ c beneficiarii tipului de aplicaie n discuie sunt, n egal msur, persoanele n cutarea unei metode comode i deloc costisitoare de a comanda ceva de mncare (denumii de acum nainte clieni), precum i productorii de preparate culinare aflai ntr-o continu cutare att de clientel nou pentru preparatele culinare pregtite, precum i de modaliti de promovare n mas larg (denumii de acum nainte furnizori). Sintetiznd rezultatele obinute din analiza pieei de aplicaii Web care ofer servicii de comenzi on-line a preparatelor culinare se pot trage urmtoarele concluzii n ceea ce privete prile pozitive i negative ale unei aplicaii de acest tip. O astfel de aplicaie ar trebui sa ofere urmtoarele faciliti: 43
Pentru client: o interfa plcut, comod i puin costisitoare de comandare: cu o simpl legtur la Internet (de care beneficiaz aproape oricine n ziua de azi), clienii pot comanda preparatul dorit prin 3 modaliti diferite: accesnd lista furnizorilor i selectnd din meniul pus la dispoziie preparatul dorit; accesnd lista categoriilor de preparate culinare i selectnd oferta furnizorului preferat; cutnd preparatul dorit dup anumite criterii, cum ar fi: denumirea, preul, furnizorul, etc.; o libertatea de a alege: clientul are posibilitatea de a consulta meniul fiecrui furnizor i de a alege un produs n funcie de un numr mult mai mare de criterii (furnizor, pre, timpul de livrare, etc.); o posibilitatea de a recomanda un furnizor: ntruct prerea clientului este cea mai important, pe lng tradiionalul formular de contact care s-i permit exprimarea opiniilor pro i contra, aplicaiile de comenzi on-line ofer o posibilitate rapid de recomandare a unui furnizor preferat prin intermediul unui formular. Pentru furnizor: o o modalitate puin costisitoare i efectiv de reclam: informaiile despre noile oferte speciale aprute sau modificrile survenite n meniu pot fi configurate n orice moment de ctre furnizor prin simpla accesare a aplicaiei, fr alte costuri suplimentare (de ex.: editarea de pliante i materiale promoionale); astfel, clientului i sunt oferite n permanen informaii actualizate, prevenindu-se de exemplu situaiile neplcute cnd un furnizor nu mai poate oferi un produs la acelai pre; o accesul la istoricul comenzilor primite i la informaiile publice ale clienilor unui furnizor pentru eventuale statistici, studii de pia sau marketing : prin intermediul coninutului bazei de date a clienilor, la care va avea n permanen acces, furnizorul va putea efectua diferite studii referitoare la impactul produselor sale asupra clienilor; va putea pstra astfel o eviden a celor mai solicitate produse, dar i a celor mai fideli clieni, putndu-i astfel dezvolta diverse strategii de marketing menite s ncurajeze comandarea produselor oferite de el; o o modalitate ieftin de mbuntire a relaiei cu clienii: prin intermediul aplicaiei se poate obine acceptul clientului de a primi mesaje cu oferte i promoii (accept cerut de Legea Comerului Electronic nr. 365/2002 care interzice trimiterea de mesaje nesolicitate); acest accept permite furnizorului aplicarea unei strategii proprii de marketing direct sau a unei strategii propuse de aplicaie; strategia proprie poate consta n trimiterea periodic (dar nu prea 44
des) a unui mesaj care anun o reducere de pre sau o ofert special; strategia propus de aplicaie const n trimiterea zilnic a unui mesaj care s conin ofertele speciale ale tuturor furnizorilor pentru ziua respectiv. n ceea ce privete prile negative, putem vorbi doar despre neajunsurile ntmpinate de clieni n folosirea aplicaiilor studiate. Nu ne putem pronuna i n privina furnizorului deoarece nu avem acces la partea de administrare oferit de aplicaiile analizate. Prin urmare, neajunsurile ntlnite de clieni n timpul utilizrii unor astfel de aplicaii Web ar putea fi sintetizate n urmtoarele: o densitatea mare de informaii: majoritatea aplicaiilor renun la simplitate n favoarea prezentrii unei cantiti excesive de informaii pe fiecare pagin; efectul const n derutarea vizitatorului i punerea acestuia n imposibilitatea de a observa cu uurin elementele de care este interesat; o opiuni limitate n ceea ce privete istoricul comenzilor: aplicaiile care ntrein un istoric al comenzilor l folosesc doar cu rol descriptiv, acesta neputnd fi folosit, de exemplu, pentru relansarea unei comenzi efectuate anterior; o opiuni limitate n ceea ce privete comenzile care s conin preparate de la mai muli furnizori: majoritatea aplicaiilor Web prezint oferta unui singur furnizor, iar cele care prezint oferta mai multor furnizori ofer doar posibilitatea comandrii unei liste de produse aflate n oferta aceluiai furnizor.
4.1.2 Cerinele beneficiarilor aplicaiei de food-ordering ntr-o economie de pia care urmrete echilibrarea raportului dintre cerere i ofert prin satisfacerea ntr-o msur ct mai mare a nevoilor ambelor categorii de participani la procesul de schimb, o aplicaie care ofer faciliti de comandare on-line a preparatelor culinare trebuie s satisfac att nevoile utilizatorilor care caut modaliti imediate, facile i comode de a comanda ceva de mncare, ct i nevoia furnizorilor de a-i vinde preparatele culinare cu costuri sczute. n mod transparent pentru prile implicate, pentru o satisfacere ct mai bun a cerinelor pieei, aplicaia de fa trebuie s vin att n ntmpinarea potenialilor cumprtori de preparate culinare, cu o ofert ct mai variat i o modalitate facil de a comanda on-line, ct i n ntmpinarea furnizorilor, cu o metod nou i puin costisitoare de promovare i vnzare a preparatelor culinare proprii. Se observ c scopul fundamental al aplicaiei este acela de a fi un adevrat intermediar ntre furnizori i client, care trebuie s simuleze ct mai fidel funcionalitatea i scopul unui magazin de prezentare n care furnizori diferii i promoveaz i vnd preparatele culinare. Prin urmare, delimitarea cerinelor acestui tip de aplicaie trebuie s in cont de doleanele ambelor categorii de beneficiari, ca pri direct interesate i participante ntr-o afacere comercial.
45
Din analiza acestui deziderat reies cerinele fundamentale ale aplicaiei, care n esen sunt cele ale unui magazin de prezentare, raportate ns la posibilitile de implementare oferite de mediul Web: o publicarea informaiilor eseniale despre fiecare furnizor i existena unor posibiliti de actualizare a acestor informaii; o prezentarea informaiilor de interes despre preparatele culinare comercializate i existena unor posibiliti de actualizare a acestor informaii; o prezena mecanismelor de promovare a preparatelor ntr-o manier eficient i imparial, dar care s nu afecteze uurina n folosire a aplicaiei; o asistena permanent pentru utilizatorii aplicaiei n ceea ce privete modalitile de folosire a acesteia n procesul comandrii on-line de preparate culinare, precum i oferirea de informaii privitoare la modalitile n care produsele comandate vor ajunge n posesia utilizatorului; o accesul bine organizat i facil al utilizatorului att la informaiile despre furnizori, ct i la cele despre preparatele culinare; o posibilitatea efecturii i prelurii de comenzi de preparate ntr-o manier uoar i cu un flux de informaie ct mai redus de la/nspre utilizator i securizat la nevoie; dezavantajul comunicrii de informaii ntre client i furnizor ntr-un mediu public cum este Internetul, i deci supus interceptrii neautorizate, trebuie corectat prin msuri de securitate atunci cnd informaiile au caracter privat; o funcionaliti care s permit crearea unui punct de comunicare rapid ntre furnizor i clieni, precum i modaliti de ntreinere a acestei relaii cu costuri minime (pentru furnizor). Avnd ca punct de pornire rezultatele studiului efectuat despre implementrile existente, funcionale i de succes ale acestui tip de aplicaie, implementri care se bucur de posibiliti imense oferite de mediul Web, consider c o aplicaie Web care ofer servicii de comenzi on-line a preparatelor culinare trebuie s satisfac urmtoarele necesiti: a. Necesiti ale clientului: o aplicaia trebuie s permit accesul n orice moment, din orice pagin, la serviciul de asisten on-line; aceast aciune nu trebuie s influeneze activitatea precedent a clientului; o aplicaia trebuie s fie orientat client, conform principiului clientul nostru, stpnul nostru; totodat, aplicaia trebuie s limiteze ansele producerii de neplceri la aciunile clienilor neateni sau grbii; aceast limitare de responsabilitate trebuie realizat printr-o verificare permanent a datelor introduse de clieni i prin mesaje de atenionare; o aplicaia trebuie s aib o interfa prietenoas, facil, echilibrat n ceea ce privete raportul de informaie necesar efecturii rapide de comenzi i informaie necesar promovrii preparatelor;
46
o aplicaia trebuie s in cont de eventualele sugestii din partea clientului, legate de logica de funcionare, precum i de eventualele nevoi suplimentare, susinute prin argumente solide; o aplicaia trebuie s ntrein o list a produselor pe care clientul intenioneaz s le comande; aceast list trebuie s se afle n controlul deplin al clientului (de ex. poate renuna la ea n orice moment) i s poat fi consultat ntr-un mod facil din orice pagin a aplicaiei; o lansarea listei de comenzi trebuie s fie o procedur clar, explicit, necondiionat dect de dorina clientului; o posibilitatea lansrii de comenzi cu o dat de livrare ulterioar datei efecturii comenzii; o posibilitatea lansrii unei liste de comenzi cu preparate de la furnizori diferii; o aplicaia trebuie s ofere posibilitatea de anulare a oricrei comenzi lansate, pn n momentul n care aceasta a fost confirmat de ctre furnizor; o plata unei comenzi s se poat efectua la livrare i s existe posibilitatea facturrii serviciului cumprat; o reducerea la minim a informaiilor cerute n momentul lansrii unei comenzi; o aplicaia trebuie s in minte un istoric al comenzilor pentru fiecare client; alturi de scopul su implicit, istoricul trebuie s poat fi folosit pentru relansarea unor comenzi anterioare; o aplicaia trebuie s permit accesul bine organizat i facil att la informaiile despre furnizori, ct i la cele despre preparatele culinare, prin: ierarhii de categorii i subcategorii de preparate; lista furnizorilor; modaliti avansate de cutare a unui preparat; topul celor mai vndute preparate i cel al celor mai vizitate preparate, precum i lista preparatelor noi introduse n aplicaie, diferitele promoii; o acolo unde are sens, clientului trebuie s i se ofere posibilitatea de a-i exprima nivelul de condimentare dorit al preparatului comandat, precum i eventuala lips a vreunui ingredient; o aplicaia trebuie s ntrein un profil al seriozitii pentru fiecare furnizor: clientul s-i poat exprima prerea ntr-un mod liber, accesibil celorlali utilizatori i fr frica unor represalii, asupra calitilor i lipsurilor unui preparat comandat, precum i asupra serviciului de livrare; totodat, clientul s aib la dispoziie modaliti de comunicare direct cu furnizorii; o monitorizarea continu a furnizorilor i accesul clienilor la informaiile privind seriozitatea acestora, conexiunea la internet i modalitile de preparare a produselor n conformitate cu respectarea regulilor de igien; b. Necesiti ale furnizorului: 47
o posibilitatea afirii, prin intermediul aplicaiei, a cel puin urmtoarelor informaii despre un furnizor: denumirea unitii comerciale, sigla, regimul de funcionare, specificul buctriei, adresa complet, orarul de funcionare pe o anumit perioad, valoarea comenzii minime, tichetele de mas acceptate, ofertele promoionale, timpul minim de preparare i livrare, taxa de livrare, oraul i aria de livrare; o interfa prietenoas de administrare a informaiilor pe care un furnizor va avea posibilitatea s le publice prin intermediul aplicaiei; o interfa prietenoas de administrare a comenzilor; o comand se va putea afla ntruna din strile: lansat, anulat, acceptat, refuzat, confirmat sau efectuat; furnizorul i asum n mod exclusiv responsabilitatea modificrii strii unei comenzi dup reguli proprii, dar care nu sfideaz fundamentele relaiei sale comerciale cu cumprtorul; o informaiile cerute de aplicaie n mod obligatoriu la primirea unei comenzi s conin: data i ora la care se dorete livrarea (acestea trebuie s respecte orarul stabilit n avans de furnizor), un numr de telefon la care furnizorul va suna pentru confirmarea comenzii, adresa de livrare (aceasta trebuie s fie n aria de livrare declarat) i, eventual, datele necesare unei facturi fiscale; o prezentarea informaiilor despre furnizori ntr-un format lizibil i plcut vederii; totodat, s se asigure imparialitatea aplicaiei n ceea ce privete ordinea de afiare a furnizorilor ntr-o list a acestora; o aplicaia trebuie s permit accesul bine organizat i facil att la informaiile despre furnizori, ct i la cele despre preparatele culinare, prin: ierarhii de categorii i subcategorii de preparate, lista furnizorilor, modaliti avansate de cutare a unui preparat, topul celor mai vndute preparate i cel al celor mai vizitate preparate, precum i lista preparatelor noi introduse n aplicaie, diferite promoii; o aplicaia trebuie s poat ntreine un profil al seriozitii pentru fiecare client i modaliti de modificare a acestuia de furnizori, n mod argumentat, pe baza trecutului relaiei cu clientul; o funcionaliti care s permit crearea unui punct de comunicare rapid ntre furnizor i clieni, precum i modaliti de ntreinere a acestei relaii cu costuri minime (pentru furnizor). c. Reguli pentru buna funcionare a aplicaiei: o aplicaia trebuie s permit accesul n orice moment, din orice pagin, la condiiile de utilizare a aplicaiei, politica de confidenialitate, descrierea aplicaiei; aceste informaii trebuie s nlture oricrui client, n mod succint i elocvent, orice nelmurire care ar putea aprea cu privire la responsabilitile acestuia n utilizarea aplicaiei; se presupune c clientul este la curent cu responsabilitile care i revin n utilizarea aplicaiei; o aplicaia se oblig s posteze informaiile despre preparatele unui furnizor doar dac acesta i d acceptul n respectarea urmtoarelor condiii:
48
s trateze fiecare comand cu aceeai seriozitate, indiferent de or, client, adres de livrare; s acorde atenie eventualelor reclamaii din partea clienilor.
4.1.3 Delimitarea comportamentului aplicaiei (cazurile de utilizare) Printr-o analiz amnunit a ateptrilor celor doi beneficiari ai aplicaiei vom contura un prim model al aplicaiei, o vedere a acesteia, prin descrierea aplicaiei din punctul de vedere al comportamentului ce rezult n mare parte din necesitile delimitate n capitolul precedent de beneficiari. Scopurile acestei prime faze de analiz i proiectare sunt: o documentarea contextului, a mediului de funcionare i a limitelor aplicaiei, a comportamentului exclusiv exterior (observabil) dorit pentru aplicaie n toate cazurile de interaciune cu utilizatorii; o descrierea cerinelor i nevoilor utilizatorilor n contextul utilizrii aplicaiei; o pregtirea unui punct de plecare n identificarea tuturor activitilor din aplicaie. Pentru aceasta, voi considera aplicaia exclusiv din perspectiva utilizatorilor (care de regul nu tiu i nici nu prezint interes pentru detaliile de implementare a aplicaiei), adic voi privi aplicaia ca i o cutie neagr, un sistem ascuns mie ca form i coninut i cruia doresc s-i delimitez un comportament pentru cazurile de interaciune formulate de utilizator. Odat clarificat scopul acestei faze i a perspectivei mele fa de aplicaie, voi trece la: o identificarea actorilor care interacioneaz cu sistemul; o trecerea n revist a cazurilor n care fiecare actor n parte utilizeaz aplicaia; o transpunerea informaiilor obinute ntr-o vedere a cazurilor de utilizare a aplicaiei, prin intermediul diagramelor de cazuri de utilizare pentru fiecare actor n parte. Cazurile de utilizare reprezint secvene de tranzacii ce au loc n dialog cu sistemul i care sunt nrudite din punct de vedere comportamental. Practic, un caz de utilizare modeleaz un dialog ntre un actor i aplicaie. Mulimea cazurilor de utilizare a unei aplicaii reprezint toate modalitile n care aplicaia poate fi folosit. Cazurile de utilizare : o sunt uniti de sine stttoare, bine delimitate (nceputul i sfritul unui caz de utilizare sunt cuprinse n acesta); o trebuie s fie iniiate de un actor i terminarea lor s fie vzut de un actor; o trebuie s ndeplineasc anumite scopuri de logic a problemei (dac nu se poate gsi un astfel de obiectiv atunci cazul de utilizare trebuie regndit); o trebuie s lase sistemul ntr-o stare stabil (nu pot fi ndeplinite doar pe jumtate). Cazurile de utilizare sunt orientate pe scop: reprezint ceea ce sistemul trebuie s fac i nu cum. Ele sunt neutre din punct de vedere tehnologic, putnd fi utilizate n orice proces sau arhitectur de aplicaie. 49
La prima vedere, rolurile principale de actor sunt distribuite beneficiarilor bine stabilii ai aplicaiei, clienii i furnizorii. Ne referim la un utilizator al aplicaiei cu titulatura de CLIENT dac acesta este nregistrat n evidena aplicaiei ca i beneficiar al serviciilor de comand on-line i n plus s-a conectat la serviciile aplicaiei preciznd perechea valid de nume de utilizator i parol care l identific . FURNIZORUL este i el un utilizator nregistrat al aplicaiei, care se identific la rndul lui printr-o pereche de nume de utilizator i o parol, dar beneficiaz de cu totul alte privilegii (i responsabiliti) fa de cele ale CLIENTULUI. O categorie aparte de actori (cu rol deloc neglijabil) care vor interaciona cu aplicaia o constituie VIZITATORII, reprezentai de orice utilizator care acceseaz aplicaia i care nu este nregistrat n evidena aplicaiei, sau cel puin nu s-a conectat nc la serviciile ei. Deoarece vizitatorul intr primul n contact cu aplicaia, este natural descrierea i documentarea interaciunii dintre acetia (vizitator, aplicaie) pentru delimitarea unui comportament primar al aplicaiei. Cerinele clientului i ale furnizorului de a accesa un mediu controlat de comandare on-line n care se evit, pe ct posibil, comenzile false sau schimbul de informaii eronate, impun limitarea posibilitii de lansare a comenzilor doar la clieni (vizitatorii nregistrai), fiindc informaiile personale furnizate de acetia sunt validate ntr-o oarecare msur de aplicaie i n plus, clienii le garanteaz, cel puin virtual, veridicitatea. Avnd n vedere faptul c unul din scopurile declarate ale aplicaiei de fa este atragerea de noi clieni, lucru care se poate realiza prin determinarea vizitatorilor s-i creeze conturi de utilizator, consider c vizitatorii ar trebui s aib urmtoarele drepturi: o s vizualizeze informaiile despre furnizori i preparatele acestora; o s caute un preparat cel puin dup urmtoarele informaii relevante: furnizor, ora de livrare, aria de livrare, pre, ingrediente; o s contacteze un furnizor pentru eventualele nelmuriri legate de preparatele pe care acesta declar c le poate livra; o s i creeze o idee att despre msura n care preparatele pe care le poate comanda i seriozitatea furnizorilor i satisfac nevoile culinare, ct i despre uurina n utilizare a aplicaiei; o s poat afla termenii i condiiile de utilizare a aplicaiei, politica de confidenialitate, paii pentru crearea unui cont ntr-un cuvnt s beneficieze de asisten on-line; o s se poat nregistra n aplicaie, prin crearea unui cont; o s se poat conecta la aplicaie n cazul n care este nregistrat ca i client/furnizor al aplicaiei. Urmtoarea diagram surprinde toate cazurile n care vizitatorul schimb informaie cu aplicaia:
50
Un VIZITATOR este un utlizator al aplicaiei care nu este nregistrat n evidena aplicaiei s au cel puin nu s-a conectat nc la serviciile ei.
<<extinde>> Navigare categorii de preparate <<extinde>>
Vizualizare info preparat <<extinde>>
Cutare preparat
<<extinde>> Vizualizare info furnizor
Navigare furnizori
<<extinde>>
VIZITATOR
nregistrare ca i client al aplicaiei
Contactare furnizori
Demarare asisten on-line
Conectare la aplicaie ca i client
Conectare la aplicaie ca i furnizor
Fig. 4.1 Cazurile de utilizare pentru vizitator
Eticheta <<extinde>> este folosit pentru a sugera un comportament opional, un comportament care are loc doar n anumite condiii sau fluxuri diferite ce pot fi selectate pe baza seleciei unui actor. De exemplu, pentru a putea vizualiza informaiile despre un anumit preparat, vizitatorul va trebui s efectueze n prealabil cel puin una din aciunile: o cutarea unui preparat prin instrumentele puse la dispoziie de aplicaie; o consultarea meniului unui furnizor; o navigarea categoriilor de preparate. Un real interes pentru comportamentul aplicaiei (datorit ponderii mare n comportamentul final) prezint modalitatea de exercitare de ctre clieni a dreptului de folosire a serviciului de comand on-line. Din analiza cerinelor formulate de clienii aplicaiei am surprins n urmtoarea diagram toate cazurile de utilizare de ctre client a aplicaiei n scopul comandrii on-line de preparate culinare.
51

Un CLIENT este un utilizator care este nregistrat n evidena aplicaiei ca i beneficiar al serviciilor de comand on-line i n plus S-A CONECTAT LA APLICAIE.
<<exti nde>>
VIZITATOR
Administrare comand n pregtire
Lansare comand n pregtire

<<extinde>>
<<exti nde>>
Vizualizare info preparat
CLIENT Vizualizare comenzi n derulare

<<exti nde>>
Adugare preparat la comanda n pregtire
Vizualizare istoric comenzi
Trimitere prere despre preparat
Administrare cont
Fig. 4.2 Cazurile de utilizare pentru client
Se observ c ntre cei doi actori, CLIENT i VIZITATOR exist o relaie de generalizare, n sensul c un CLIENT poate interaciona cu aplicaia n toate modurile n care interacioneaz vizitatorul, i n plus mai are opiunile prezentate n diagrama de mai sus. Dat fiind multitudinea de informaii pe care clientul dorete ca aplicaia s le rein pentru el, este natural ca rolul contului de client s fie extins de la o modalitate simpl de control al accesului la aplicaie, la un adevrat container de informaie. Am identificat n final 4 tipuri de informaie reinut de un cont client: o informaii personale i de conectare; o lista adreselor de livrare; o lista informaiilor de facturare; o lista grupurilor de clieni la care posesorul contului este administrator. Prin urmare, diagrama detaliat a cazurilor de utilizare care compun cazul de utilizare generic Administrare cont client, dirijat de cele 4 tipuri de informaie, arat astfel:
52

Detalierea cazului de utilizare Administrare cont client
<<include>>
Configurarea informaii personale i de conectare

<<incl ude>>
CLIENT
Administrare cont
<<include>> <<incl ude>>
Administrare adrese de livrare
Administrare informaii grupuri de clieni
Administrare informaii de facturare
Fig. 4.3 Cazul de utilizare Administrare cont pentru client
Furnizorul este un utilizator nregistrat n aplicaie ca i prestator de servicii de livrare la domiciliu a preparatelor culinare. Necesitile declarate ale acestuia sunt administrarea listei de comenzi primite, pstrarea de ctre aplicaie a unui istoric al comenzilor onorate de el, precum i posibilitatea modificrii informaiilor despre activitatea sa i a meniului de preparate culinare. Printr-un raionament analog cazului clientului, informaiile despre activitatea furnizorului i a meniului de preparate culinare vor fi reinute ca parte constitutiv a contului de furnizor. De asemenea, datorit interesului accentuat pentru comenzile din ziua n curs, acestea vor fi administrare separat fa de cele cu dat de livrare ulterioar zilei n curs. Prin urmare, n cazul furnizorului vom avea de a face cu dou cazuri generice de utilizare, Administrare cont i Administrare comenzi, care vor include, la rndul lor, alte dou cazuri de utilizare cu efect imediat pentru furnizor. Astfel, diagrama cazurilor de utilizare de ctre furnizor a aplicaiei arat astfel:
53
Un FURNIZOR este un utilizator nregistrat n aplicaie ca i prestator de servicii de preparare i livrare la domiciliu de produse culinare.
<<include>>
Configurare informaii personale i de conectare furnizor Administrare cont

<<incl ude>>
FURNIZOR
Modificare meniu
<<incl ude>>
Administrare comenzi
<<incl ude>>
Administrare comenzi pentru ziua n curs
Administrare comenzi pentru Vizualizare istoric comenzi o zi ulterioar celei n curs
Fig. 4.4 Cazurile de utilizare pentru furnizor
Minimul de interaciune al VIZITATORILOR cu aplicaia ne permite s tragem o concluzie preliminar asupra comportamentului de baz, minimal, al acesteia. Prin urmare aplicaia trebuie s prezinte interfa pentru: o nregistrarea unui client nou; o conectarea la aplicaie a clienilor; o conectarea la aplicaie a furnizorilor; o consultarea listei de furnizori; o consultarea listei de categorii de preparate comandabile prin acest serviciu; o cutarea unui preparat dup criterii relevante; o consultarea informaiilor despre un anumit preparat; o vizualizarea termenilor i condiiilor de utilizare a aplicaiei, a politicii de confidenialitate, a pailor pentru crearea unui cont client.
54
Din cazurile de utilizare delimitate pentru actorul CLIENT, funcionalitatea aplicaiei se extinde, pentru un utilizator conectat la aplicaie ca beneficiar al serviciului de comand on-line, la oferirea unei interfee pentru: o administrarea contului prin posibilitatea configurrii informaiilor personale i de conectare, administrarea adreselor de livrare, administrarea informaiilor de facturare precum i administrarea informaiilor despre grupurile de clieni administrate; o vizualizarea istoricului de comenzilor efectuate de-a lungul folosirii aplicaiei; o adugarea unui preparat la comanda n pregtire; o lansarea comenzii n pregtire; o administrarea comenzii n pregtire; o consultare list cu comenzi n derulare (lansate i neefectuate). Cazurile de utilizare delimitate pentru actorul FURNIZOR completeaz comportamentului aplicaiei. Astfel, aplicaia trebuie s permit unui utilizator conectat la aplicaie ca prestator de servicii de livrare la domiciliu a preparatelor culinare, urmtoarele: o administrarea contului de furnizor prin configurarea informaiilor personale i de conectare, precum i modificarea meniului; o vizualizarea istoricului de comenzi efectuate ctre clieni; o administrarea comenzilor n ateptare pentru o zi ulterioar celei n curs; o administrarea comenzilor n ateptare pentru ziua n curs.
4.2 Proiectarea aplicaiei 4.2.1 Designul conceptual al aplicaiei 4.2.1.1 Arhitectura aplicaiei n general, aplicaiile client/server pot fi privite ca fiind structurate pe trei nivele: nivelul de prezentare, nivelul de logic a aplicaiei (de business) i nivelul de date.
PAR TEA D E SER VER
N ive lu l d e p re ze n tare IN T E R N E T
PAR TEA D E C L IE N T
BRO W SER
N ive lu l d e lo g ic a a p lic a tie i
N ive lu l d e d ate
Buy SmartDraw !- purchased copies print this document without a watermark . Visit www.smartdraw.com or call 1-800-768-3729.
55
Fig. 4.5 Arhitectura three-tier
n figura de mai sus este prezentat modul n care interacioneaz cele trei nivele: o Nivelul de prezentare cunoscut i sub numele de interfa, reprezint nivelul cel mai de sus, care asigur prezentarea rezultatelor ntr-o form inteligibil pentru utilizator; separarea serviciilor de prezentare de cele care in de logica aplicaiei permit modificarea interfeei cu utilizatorul cu eforturi minime; o Nivelul de logic a aplicaiei reprezint cel mai dinamic nivel al unei aplicaii, deoarece regulile de logic a aplicaiei i funcionalitatea se modific mult mai des; izolarea de celelalte nivele face ca impactul implementrii unor modificri s fie redus; pe ct posibil, nivelul de logic trebuie s nu conin elemente legate de interfaa cu utilizatorul sau accesul la baza de date; de asemenea, acest nivel joac rolul de intermediar ntre baza de date i client, fiind responsabil cu transferul datelor; o Nivelul de date este cel mai static nivel al aplicaiei; reprezint nivelul la care sunt stocate datele; de aici datele sunt furnizate nivelului logic pentru prelucrri i eventual nivelului de prezentare, pentru a putea fi accesate de utilizator. Avantajul arhitecturii pe 3 nivele fa de o arhitectur client/server tradiional (pe dou nivele), este c majoritatea procesrilor se fac pe serverul de aplicaie i pe baza de date, nu pe calculatorul client i pe baza de date. Aceasta permite o scalabilitate mult mai bun a aplicaiei n condiiile unui volum de tranzacii n cretere. Este necesar doar adugarea de servere suplimentare pentru creterea capacitii de procesare. Aplicaia de food-ordering, prezentat n lucrarea de fa, este structurat pe trei nivele, astfel:
56
Capitolul IV Dezvoltarea Aplicaiei PAR TEA D E SER VER N ive lu l d e p re ze n tare

S c r ip t u r i P H P d e g e n e r a r e d i n a m ic a a in t e r f e t e i
PAR TEA D E C L IE N T
IN T E R N E T
BRO W SER
N ive lu l d e lo g ic a a p lic a tie i
S c r ip t u r i P H P c a r e c o n t r o le a z l o g i c a s i f l u x u l a p li c a t i e i
L ib r a r ie d e f u n c t ii P H P d e a d m in is t r a r e B D M ySQ L
N ive lu l d e d ate
B a z a d e d a te M ySQ L
Buy SmartDraw !- purchased copies print this document without a watermark . Visit www.smartdraw .com or call 1-800-768-3729.
Fig. 4.6 Arhitectura aplicaiei de food-ordering
Nivelul de prezentare este format din paginile HTML prin care utilizatorii interacioneaz cu aplicaia. Scopul acestui nivel l reprezint prezentarea ntr-un format prietenos a datelor primite de la nivelul de logic a aplicaiei. Datele se refer att la informaii ce trebuie aduse la cunotina utilizatorului, ct i la indicatori care limiteaz funcionalitatea paginii rezultate. De asemenea, la acest nivel se realizeaz o prelucrare a datelor introduse de utilizator, astfel nct ele s fie trimise mai departe nivelului de logic a aplicaiei ntr-un format recunoscut de acesta. Nivelul de logic a aplicaiei face legtura ntre celelalte dou nivele. La acest nivel, prin scripturi PHP organizate n librrii, se stabilesc regulile de funcionare a aplicaiei. Aceste scripturi se ocup de operaii precum validarea datelor introduse de utilizator, construirea interogrilor SQL ce vor fi trimise spre execuie nivelului de date, luarea deciziilor n ceea ce privete informaiile care vor fi trimise spre afiare nivelului de prezentare. Nivelul de date, reprezentat de baza de date MySQL, constituie partea static a aplicaiei, fiind responsabil de stocarea datelor. De la acest nivel datele sunt trimise pentru prelucrri ctre nivelul responsabil de logica aplicaiei. Pe de alt parte, aici sunt stocate informaiile provenite de la utilizatori, dup ce n prealabil acestea au fost validate i prelucrate la nivelul de logic a aplicaiei.
4.2.1.2 Designul conceptual al interfeei prototipul de interfa 57
Rolul etapei de concepere a prototipului de interfa este acela de a prezenta modul n care vor fi structurate informaiile n cadrul site-ului, n funcie de categoriile de utilizatori. n aceast etap nu voi vorbi de modul de aranjare fizic a informaiilor n pagin, ci doar de funcionalitile oferite de site n funcie de categoria de utilizator. Prototipul trebuie iniial s identifice grupuri majore de ferestre i strategia de interaciune de ansamblu, lsnd la final aspectele de ordin estetic. n realizarea prototipului se utilizeaz hri de structur a ecranului pentru a descrie fluxul aplicaiei, urmnd cile principale ale cazurilor de utilizare. n Fig. 4.7 este prezentat fluxul aplicaiei de food-ordering. Se observ faptul c siteul ofer o interfa diferit pentru fiecare din cele trei categorii de utilizatori ai aplicaiei, respectiv pentru vizitatori, clieni i furnizori. Interfaa diferit este oferit prin intermediul indexului specific, respectiv Index vizitator, Index client i Index furnizor. n cadrul Fig. 4.7, opiunile specifice fiecrei categorii de utilizatori, la un moment dat, sunt colorate diferit, astfel: albastru pentru vizitator, rou pentru client, respectiv verde pentru furnizor. Se mai pot observa o serie aparte de opiuni, colorate cu galben; acestea reprezint opiunile comune tuturor celor trei categorii de utilizatori; oricine va utiliza aplicaia va avea acces n orice moment la acele opiuni generale.
58
Fig. 4.7 Designul conceptual al interfeei Fluxul aplicaiei
59
4.2.1.3 Designul conceptual al bazei de date Utilitatea oricrei colecii de date const n obinerea de informaii i depinde n mare msur de modul de organizare i manipulare a acestora. Analiza, proiectarea i implementarea structurii bazei de date se realizeaz utiliznd un anumit model de date. Modelele utilizate de bazele de date se pot grupa n trei categorii: modele bazate pe obiect, modele bazate pe nregistrri i modele fizice. n prezent, cel mai rspndit dintre modelele de baze de date este cel relaional (entitate-relaie), de tip n:1, dezvoltat de E.F. Codd de la IBM, al crui obiectiv este acela de simplificare a accesului la bazele de date de ctre utilizatorii finali. Rspndirea acestui model se datoreaz faptului c SGBD-urile relaionale dispun de un limbaj de manipulare a datelor foarte puternic i simplu i de o interfa prietenoas, acre permite folosirea bazelor de date relaionale de ctre o categorie foarte larg de utilizatori. O baz de date relaional este definit ca fiind un ansamblu de tabele sa relaii ntre care exist anumite legturi, fiecare tabel fiind alctuit din coloane, denumite atribute i linii, denumite i tuple. Ideea fundamental a lui Codd a fost c mulimile de entiti se modeleaz convenabil prin tabele a cror descriere, adic antetul, definete tipul de entitate prin atribute sau proprieti, iar liniile reprezint entiti din mulime, sau instane ale tipului de entitate respectiv. O entitate este o realitate obiectiv care exist prin ea nsi. Orice entitate se caracterizeaz prin anumite proprieti, care n cadrul modelului de date sunt reprezentate prin atribute. La rndul lor, entitile sunt reprezentate prin tipuri de entiti. Un tip de entitate este o reprezentare a unei categorii de obiecte din lumea real sau a unei mulimi de entiti de acelai fel, iar atributele sale reprezint caracteristicile generale (intensionale) ale acelei categorii. Pornind de la aceste aspecte teoretice am delimitat n cadrul aplicaiei de foodordering 11 tipuri de entiti, prezentate n diagrama entitate-relaie de mai jos, mpreun cu relaiile dintre ele.
60
Fig. 4.8 Diagrama entitate-relaie
61
4.2.2 Designul fizic al aplicaiei 4.2.2.1 Componentele aplicaiei Diagramele de componente ne ofer vederi structurale asupra aplicaiei, prin aducerea n prim plan a componentelor sale funcionale care interacioneaz n timpul execuiei pentru buna comportare a aplicaiei. Prin urmare, scopul modelului derivat din aceste vederi este delimitarea modulelor aplicaiei asupra crora trebuie s se concentreze activitatea de implementare, a scopului acestor module, precum i a dependenelor dintre acestea.
Fig. 4.9 Diagrama de componente a aplicaiei
Aceast prim diagram are rolul de a sublinia cele patru componente ale aplicaiei i pachetele de librrii care susin funcionalitatea acestora. Fiecare component este vzut ca i client al acestor pachete. Am delimitat cele patru componente din tipul de arhitectur pe trei nivele ales pentru aplicaie, innd totodat cont de caracterul public al mediului Web. Astfel, componenta de Securitate completeaz aplicaia avnd rolul bine determinat i necesar de asigurare a bunei funcionri a aplicaiei (s nu uitm c acesta este un lucru garantat n termenii de utilizare a aplicaiei), protejnd-o mpotriva pericolelor prezente n mediul Web, inclusiv mpotriva utilizrii necorespunztoare (voit sau nu) de ctre beneficiarii si. Pachetul de Autentificare i autorizare satisface cerina aplicaiei de a controla accesul la funcionalitatea acesteia prin intermediul conturilor i a sesiunilor de lucru. n plus, pachetul de Verificare date trimise de utilizator apr mpotriva pericolului executrii de operaii asupra bazei de date prin injectarea de ctre utilizator de comenzi SQL n coninutul datelor trimise ctre server, date care prezint probabilitate mare s fie folosite de server n construcii SQL.
62
Interfaa reprezint unicul mediu de exprimare a participanilor la comunicarea utilizator aplicaie, vzut ca un schimb bidirecional de informaie. Prin urmare, funcioneaz att ca fa vizibil a aplicaiei, ct i ca modalitate prin care utilizatorul i comunic opiunile, alegerile, deciziile. Aceast component ndeplinete responsabilitatea nivelului de prezentare din arhitectura 3-tier. Utilizatorul folosete aplicaia prin intermediul unui browser Web, care funcioneaz ca un user-agent, acionnd n locul acestuia n mediul Web (cu comportament guvernat de protocoale) prin transpunerea n aciuni specifice acestui mediu a nevoilor utilizatorului. Pentru limitarea restriciilor impuse de varietatea de browsere Web care acceseaz n mod propriu (deci diferit) Document Object Model-ul unei pagini HTML, consider necesar scrierea unei librrii de funcii JavaScript care s suprascrie funciile de acces direct la DOM pe care le-ar necesita aplicaia. Librria rezultat va asigura funcionalitatea pachetului Accesul cross-browser la DOM-ul HTML. Pachetul Prezentare cuprinde abloanele de pagini precum i a scripturilor de completare a lor; acesta pregtete spre populare cu date paginile site-ului, care rein doar comportamentul i aspectul lor. Prin delimitarea elementelor definitorii ale aspectului site-ului este posibil construirea de teme diferite de afiare, iar pachetul Teme de afiare permite interfeei s funcioneze cu orice astfel de tem. Componenta de Procesare reprezint backbone-ul aplicaiei deoarece principala responsabilitate pe care o deine, materializat prin pachetul Logica aplicaiei, este implementarea logicii de funcionare a aplicaiei, aa cum reiese ea din activitatea de proiectare. Aceast component deine de asemenea responsabilitatea interfarii cu componenta de Date, comportament materializat n pachetul Interfaa cu serverul MySQL. Componenta de Date execut la cererea explicit a componentei Procesare modificri asupra bazei de date, ndeplinind rolul nivelului de date din arhitectura 3-tier.
Fig. 4.10 Relaiile dintre componentele aplicaiei
63
Aceast diagram are scopul de a completa prima diagram de componente prin sublinierea dependenelor dintre ele. Aceasta nseamn delimitarea relaiilor dintre componente i a interfeelor prin care acestea comunic. Astfel, se poate observa c toate componentele fundamentale ale arhitecturii aplicaiei <<utilizeaz>> componenta de Securitate datorit necesitii de a valida comunicarea utilizator aplicaie conform unor reguli bine stabilite. Arhitectura 3-tier a aplicaiei impune existena a dou interfee care, transpuse n contextul componentelor delimitate, asigur comunicarea ntre: o componenta de Interfa i cea de Procesare (IProcesare): aceast interfa asigur transformrile necesare ntre formatele de date cu care lucreaz cele dou componente; o componenta de Date i cea de Procesare (IDate): funcionalitatea acestei interfee rezid n pachetul Interfaa cu serverul MySQL i specific modalitatea prin care componenta de Procesare modific datele din baza de date administrat de componenta de Date.
4.2.2.2 Diagramele de activitate Diagrama de activitate este folosit n modelarea aspectelor dinamice ale aplicaiei, presupunnd modelarea proceselor pas cu pas. O diagram de activitate prezint fluxul secvenelor de activiti, putnd fi folosit pentru a descrie activitile realizate n cadrul unei operaii, folosind, dac este cazul, decizii i condiii. Scopul acestor diagrame este acela de a captura aciunile i rezultatele lor. Ele reprezint o cale alternativ de descriere a interaciunilor, cu posibilitatea de specificare a aciunilor ce se vor realiza: ce fac acestea?, cnd au loc? i unde au loc?. Voi folosi diagramele de activiti n urmtoarele scopuri: o pentru a ilustra aciunile care vor fi realizate cnd este executat o operaie; o pentru a arta cum o instan a unui caz de utilizare poate fi realizat n termenii aciunilor; o pentru a ilustra cum este organizat munca actorilor. Am ales diagramele de aciune pentru cele mai reprezentative cazuri de interaciune dintre utilizator i aplicaie, i anume: nregistrarea unui utilizator ca i client, respectiv conectarea unui utilizator ca i client.
64

VIZITATOR BROWSER Scripturi PHP serv er-side
Compleaz formular cu date necesare pentru nregistrare
Sunt verificate restrictii le de tip?
[ DA ]
Se poate crea cont?
[ DA ]
Creaz cont
[ NU ] [ NU ]
Semnalizeaz problemele aprute Semnalizeaz problemele aprute Trimit e-mail cu informaiile de conectare ale contului creat
Trimit confirmarea crerii contului
Fig. 4.11 Diagrama de activitate care prezint nregistrarea unui utilizator ca i client al aplicaiei
Se pot observa cu uurin cele trei culoare corespunztoare vizitatorului, browser-ului i scripturilor PHP de pe server, delimitndu-se astfel elementele responsabile cu efectuarea activitilor la un moment dat. Paii urmai n realizarea activitii de nregistrare ca i client al aplicaiei sunt urmtorii: o vizitatorul completeaz un formular cu datele necesare pentru nregistrare; o browser-ul verific dac datele din formular ndeplinesc restriciile de tip; dac aceste restricii nu sunt ndeplinite, atunci browser-ul semnaleaz erorile aprute i se reia activitatea de completare a formularului; o n condiiile n care restriciile de tip sunt ndeplinite, atunci responsabilitatea efecturii de aciuni revine script-urilor PHP de pe server, care va verifica dac este posibil crearea de cont cu datele introduse; dac nu este posibil crearea contului, atunci scripturile semnaleaz erorile aprute i se reia activitatea de completare a formularului; o scripturile PHP creeaz contul de utilizator; o scripturile PHP trimit un e-mail cu datele noului cont creat; o vizitatorul vizualizeaz un mesaj care l ntiineaz ca a fost creat contul.
65

VIZITATOR BROWSER Scripturi PHP serv er-side
Completare nume de utilizator i parol
Sunt verificate restrictiile de tip?
[ DA ]
Autorizeaz conectarea
[ NU ]
Semnalizeaz problemele aprute
Semnalizeaz problemele aprute
Sunt corecte datele de conectare?
[ NU ]
[ DA ]
Configureaz sesiunea de conectare
Permit accesul vizitatorului la opiunile principale ale clienilor
Fig. 4.12 Diagrama de activitate care prezint conectarea unui client la aplicaie:
Paii urmai n realizarea activitii de conectare a unui client la aplicaie sunt urmtorii: o vizitatorul completeaz numele de utilizator i parola; o browser-ul verific dac sunt ndeplinite restriciile de tip; dac acestea nu sunt ndeplinite atunci semnaleaz erorile aprute i se reia activitatea de introducere a numelui de utilizator i a parolei; o dac restriciile de tip sunt ndeplinite, atunci scripturilor PHP le revine responsabilitatea de a autoriza conectarea; o scripturile PHP verific dac sunt corecte datele de conectare; dac nu sunt corecte atunci se semnaleaz erorile aprute i activitatea se reia din momentul introducerii numelui de utilizator i a parolei; o dac datele de conectare sunt corecte, atunci scripturile configureaz sesiunea de conectare; o scripturile PHP permit accesul vizitatorului la opiunile principale ale clientului.
4.2.2.3 Designul fizic al bazei de date Procesul de design fizic al bazei de date const n stabilirea atributelor care caracterizeaz entitile, precum i a tipului acestor atribute. n diagrama de mai jos sunt prezentate tabelele din baza de date mpreun cu atributele i tipul acestora, precum i legturile dintre tabele.
66
Fig. 4.13 Schema fizic a bazei de date
4.3 Implementarea aplicaiei Componenta de Interfa Am s ncep detalierea implementrii alese pentru componenta de Interfa prin descrierea unor aspecte structurale legate de paginile site-ului. n mod natural, fiecrui tip de utilizator al aplicaiei i va corespunde cte o pagin de nceput, o pagin de index, care trebuie s combine urmtoarele cerine declarate: s conin opiuni i informaii utile pentru utilizator, s aib aspect plcut i s se ncarce rapid.
67
Pentru satisfacerea acestui deziderat am ales urmtorul format pentru paginile de index:
Fig. 4.14 Structura paginilor de index ale aplicaiei
n cadrul acestui format, header-ul conine un banner i trimiteri ctre termenii de confidenialitate, condiiile de utilizare a aplicaiei precum i ctre formularul de contactare a administratorului aplicaiei, firma Aldum SRL. Footer-ul conine toate informaiile necesare despre copyright-ul aplicaiei prin afiarea mesajului: 2006 AlDum Romnia. Toate drepturile rezervate. Meniul pus la dispoziia utilizatorului este poziionat n partea stng a paginii, sub header, i conine toate opiunile majore de care beneficiaz acesta n aplicaie. Opiunile din meniu sunt grupate pe categorii, astfel c meniul este format din grupaje de opiuni dispuse una sub alta i ncadrate de un chenar. Un grupaj al meniului poate s fie coninut ntr-o fereastr care se ncarc n acel chenar. Fereastra coninut este locul de desfurare a aciunii. Toate aciunile utilizatorului se vor materializa prin schimbarea coninutului acestei ferestre. Schimbarea se realizeaz centralizat, prin funcia JavaScript loadInCont(loc) care este pus la dispoziia opiunilor din meniu de ctre pagina index. Singurul argument al funciei specific locaia paginii care se vrea ncrcat n fereastra de coninut. Structura dat paginilor de index impune un stil de utilizare al aplicaiei ce se caracterizeaz prin simplitate i care permite, prin cele trei metode de cutare a unui preparat, concentrarea utilizatorului asupra preparatelor cutate. Componenta de Date n cazul aplicaiei de fa este mai elegant i mai compact instalarea pe acelai calculator a serverelor de Apache i MySQL. Aceasta datorit efortului redus la care sunt supuse ambele servere n cazul acestei aplicaii. Tipul ales pentru baza de date care stocheaz informaiile prelucrate de aplicaie este MyISAM, un format gratis, neproprietar, simplu, lipsit de faciliti precum suport pentru 68
tranzacii, proceduri stocate sau triggere. Lipsurile acestea mi sunt indiferente datorit faptului c cerine precum pstrarea integritii refereniale sau pstrarea consistenei datelor stocate sunt duse la ndeplinire exclusiv prin intermediul script-urilor PHP. Astfel, conectarea la baza de date se face cu un utilizator unic, cu drepturi depline asupra bazei de date, iar limitrile accesului fiecrui tip de utilizator la date vor fi impuse prin intermediul scripturilor PHP. Componenta de Procesare Am s ncep referirea la detaliile de implementare a componentei Procesare prin prezentarea pachetului Interfaa cu serverul de MySQL care conine librria de funcii pe care le-am considerat necesare pentru administrarea, prin intermediul PHP-ului, a unei bazei de date. Aceast librrie asigur independena implementrii logicii aplicaiei de tipul bazei de date administrat de componenta de Date. Adic scripturile ce implementeaz logica aplicaiei nu trebuie modificate dac se decide schimbarea tipului bazei de date. Mecanismul folosit se bazeaz pe delimitarea unei interfee minimale de acces la o baz de date de orice tip prin operaii simple i generale precum: conectare la server, selectarea unei baze de date, executarea unei comenzi SQL, etc. Denumirile funciilor de acces sunt i ele n ton cu independena interfeei de tipul bazei de date pe care o acceseaz. Astfel, pentru folosirea unui tip anume de baz de date, trebuie pregtit un fiier care implementeaz funciile acestei interfee cu ajutorul funciilor specifice de acces puse la dispoziie de PHP pentru tipul de baz de date n discuie. Scripturile aplicaiei vor utiliza apeluri ctre funcii din interfa pentru modificarea bazei de date care i stocheaz informaiile necesare. Ce se execut efectiv depinde de implementarea furnizat a interfeei. Fiierului ./lib/mysql.map.php conine o implementare a interfeei pentru baze de date de tip MyISAM. De observat dou lucruri: primul, c funcia adb_connect de conectare la un server MySQL permite conectarea la unul implicit dac nu primete n mod explicit o adres de server, iar al doilea, c aceast implementare de interfa se bazeaz la rndul ei pe funciile unei alte librrii, ./lib/mysql.lib.php. Este vorba de o nou aplicare a mecanismului de mai sus, iar mysql.lib.php este o implementare a unei interfee de acces la baze de date MyISAM.
<?php if (!defined("MYSQL_MAP_INCLUDED")) { define("MYSQL_MAP_INCLUDED","1"); require_once($_appCfg['main_dir_rel_path']."lib/mysql.lib.php"); $defaultServer $defaultUser $defaultPassword $defaultDb = = = = 'localhost'; 'alina'; 'zevymoqxtni'; 'myfoodorder';
function adb_connect($server=NULL, $user=NULL, $password=NULL) { if ($server===NULL) { global $defaultServer; global $defaultUser;
69

global $defaultPassword; $server = $defaultServer; $user = $defaultUser; $password = $defaultPassword; } return @mysql_connect($server,$user,$password); } //~adb_connect function adb_select_db($db, $connection=NULL) { if (!$connection) { $connection = adb_connect(); } return @mysql_select_db($db,$connection); } //~adb_select_db function adb_exec_query($query, &$qResult, $connection=NULL) { if ($connection===NULL) { $connection = adb_connect(); } return wrap_mysql_query($query,&$qResult,$connection); } function adb_get_tbl_col_val($tblName,$colName,$qWhere='',$connection=NULL) { if ($connection===NULL) { $connection = adb_connect(); } return get_tbl_col_val($tblName, $colName, $qWhere, $connection); } //~adb_get_tbl_col_val ... } ?>
Librria mysql.lib.php conine dou tipuri de funcii: o care le extind pe cele puse la dispoziie de PHP ca suport nativ pentru interaciunea cu baze de date de tip MyISAM prin modificarea semanticii valorii returnate de acestea; de exemplu, funcia wrap_mysql_query() care suprascrie funcia PHP mysql_query() de executare a unei comenzi SQL asupra unei bazei de date, returneaz n caz de eroare n execuia comenzii, valoarea 0 inhibnd totodat afiarea n pagin a erorii; o pentru care nu exist suport nativ, dar care rezolv probleme mici ce apar des; de exemplu funcia get_tbl_col_val() determin valoarea unui cmp specificat, de pe un rnd care verific o anumit condiie, dintr-o tabel specificat i folosind o conexiune specificat ctre o baz de date.
<?php if (!defined("MYSQL_LIB_INCLUDED")) { define("MYSQL_LIB_INCLUDED","1"); function wrap_mysql_query($qStr, &$qResult, $connection) { $qResult = array(); if (empty($qStr)) { return -1; } $qResult = @mysql_query($qStr,$connection); if (mysql_error()) {
70

$qResult = array(); return 0; } return 1; } //~wrap_mysql_query function get_tbl_col_val($tbl, $col, $qW, $connection) { if (!wrap_mysql_query("SELECT `".$col."` FROM `".$tbl."`". ($qW?" WHERE ".$qW:""),$result,$connection) || !mysql_num_rows($result)) { return false; } else { $_row = mysql_fetch_array($result,MYSQL_ASSOC); return $_row[$col]; } } //~get_tbl_col_val ... } ?>
Componenta de Securitate Una din problemele de securitate care trebuie rezolvate pentru aceast aplicaie este accesul controlat la funcionalitile aplicaiei de comandare on-line. Aceasta se realizeaz prin acordarea de conturi de acces (care presupun completarea unor informaii personale i de contact) i implementarea unui mecanism de conectare la aplicaie pe baza acestora. Att pentru un client nregistrat, ct i pentru un furnizor, parola se reine criptat ireversibil cu algoritmul MD5. Asta presupune c la o eventual cerere de conectare, pagina de conectare ./bin/login.php trebuie s trimit pe server criptarea cu algoritmul MD5 a parolei completat de utilizator. Pachetul Autentificare i autorizare, implementeaz accesul controlat la paginile siteului prin funciile librriilor ./lib/auth.lib.php i ./lib/md5.js, precum i prin fiierul de includere ./lib/authorize.inc.php. Librria md5.js conine o implementare a algoritmului MD5 n JavaScript i este folosit de pagina de conectare la trimiterea criptat a parolei spre autentificare. Mecanismul de conectare se bazeaz pe suportul oferit de PHP n ntreinerea unei sesiuni de lucru menit s rein date ntre dou cereri succesive de pagini PHP ctre acelai server. Cel care iniiaz o astfel de sesiune, primete un identificator unic de sesiune pe baza cruia primete acces la datele salvate n sesiune la orice cerere ulterioar de pagin care restaureaz sesiunea. Sesiunea se pierde n momentul n care o pagin PHP omite s o restaureze sau cere distrugerea sa. Mecanismul de conectare se bazeaz pe autentificarea vizitatorilor i autorizarea accesului la pagini. Autentificarea unui vizitator al site-ului presupune verificarea dac perechea de nume de utilizator i parol prezentate de el identific un utilizator nregistrat n aplicaie. Aceast verificare e fcut de funcia isRegUser() care n caz afirmativ va ntoarce tipul utilizatorului (client/furnizor), precum i identificatorul utilizatorului, necesare pentru direcionarea ulterioar a acestuia spre indexul care-i corespunde.
71
La o autentificare realizat cu succes, se dispune crearea unei sesiuni de lucru i, prin intermediul funciei getSessionCodes(), a dou coduri obinute pe baza identificatorului de sesiune, identificatorului utilizatorului, data, ora, minutul i secunda n care s-a reuit autentificarea i pe baza parolei criptate a utilizatorului. ntre cele dou coduri exist o coresponden univoc. Unul din coduri urmeaz s fie pstrat n sesiune, iar cellalt dat utilizatorului. Autorizarea unui acces la o pagin se realizeaz prin intermediul funciei isAuthorizedAccess() i are rolul de a verifica dac codul de acces prezentat de utilizator pentru sesiunea de lucru la care susine ca e conectat corespunde codului de acces salvat n sesiunea de lucru.
<?php if (!defined('AUTH_LIB_INCLUDED')) { define('AUTH_LIB_INCLUDED', 1); require_once($_appCfg['main_dir_rel_path']."lib/db.lib.php"); require_once($_appCfg['main_dir_rel_path']."lib/common.lib.php"); function isRegUser($userName, $cryptPw, $conn) { $userType = 0; if ($userId = adb_get_tbl_col_val("clienti","id_client", "`nume_client`='".$userName."' AND `parola`='".$cryptPw."'",$conn)) { $userType = 1; } if (!$userType && $userId = adb_get_tbl_col_val("furnizori", "id_furnizor", "`nume_furnizor`='".$userName."'AND `parola`='".$cryptPw."'",$conn)) { $userType = 2; } return ($userType?$userType."|".$userId:0); }//~isRegUser function getSessionCodes($sessId,$userId,$cryptPw) { $accessCode = md5(date('dsyihm').$userId.$sessId.$cryptPw); return $accessCode."|". base64_encode($sessId.str32Compose(md5($accessCode),$cryptPw)); }//~getSessionCodes function isAuthorizedAccess($sessId,$userId,$accCode,$sessCode,$conn) { $auth = 0; if (($passW = adb_get_tbl_col_val("clienti","parola", "`id_client`= '".$userId."'",$conn)) && (base64_encode($sessId.str32Compose(md5($accCode),$passW)) === $sessCode)) { $auth = 1; } return $auth; }//~isAuthorizedAccess } ?>
72
Pagina ./bin/authentificate.php este apelat de pagina de conectare i autentific un utilizator. n caz de reuit redirecioneaz utilizatorului ctre pagina de index corespunztoare categoriei din care face parte. Fiierul authorize.inc.php trebuie inclus la nceputul fiecrei pagini a site-ului i are rolul de a autoriza accesul utilizatorilor la aceasta. n caz de nereuit, va redireciona utilizatorul ctre pagina de logare:
<?php require_once($_appCfg['main_dir_rel_path']."lib/auth.lib.php"); if (isset($_REQUEST['ac']) && isset($_SESSION['sc']) && isset($_SESSION['iu']) && !isAuthorizedAccess(session_id(),$_SESSION['iu'], $_REQUEST['ac'],$_SESSION['sc'], $_appCfg['main_connection'])) { header("Location: ".$_appCfg['main_dir_rel_path']); exit; } ?>
Mecanismul de acces controlat la pagini asigur faptul c accesul la paginile destinate celor nregistrai necesit i nu funcioneaz fr activitatea de conectare. n acest mod, aplicaia este protejat, de exemplu, mpotriva vizitatorilor fr cont care ncearc accesarea indexului de client din bara de adres a browser-ului, sau chiar mpotriva celor conectai care ncearc s-i schimbe pagina de index cu cealalt. Toi vor fi direcionai spre pagina de conectare.
73
Capitolul V Simularea Succesului Unei Aplicaii Web
CAPITOLUL V SIMULAREA SUCCESULUI UNEI APLICAII WEB
5.1 Aspecte generale privind modelarea i simularea proceselor economice ntr-o definiie lapidar i unanim acceptat, modelarea nu este altceva dect un proces de cunoatere mijlocit a realitii cu ajutorul unor modele; iar modelul este o reprezentare simplificat (material sau simbolic) a realitii, fr ns s denatureze caracteristicile eseniale ale fenomenului sau procesului studiat. Sintetiznd cunotinele acumulate pn la un anumit moment, modelul permite reluarea procesului de cunoatere pe o treapt superioar. Modelarea economico-matematic reprezint o metod de cercetare, cunoatere i analiz a fenomenelor i proceselor complexe din economie, judecate n mod abstract, apelndu-se la formalizarea logic i matematic. Modelarea economic ofer managerului latura riguroas a aciunilor sale (tiina de a conduce), modaliti multiple de punere de acord a resurselor (materiale, umane, financiare) existente cu obiectivele formulate pentru o anumit perioad de timp, oferindu-i posibilitatea de a gsi i a decide mai bine i mai repede fr s denatureze realitatea. Modelarea i simularea proceselor economice este o disciplin economic de grani cu matematica i tehnica de calcul i se ocup de fundamentarea deciziei manageriale, n condiii de eficien pentru productor, cu ajutorul unor modele economico-matematice flexibile i cu posibilitatea utilizrii tehnicii simulrii. Studiul comportrii unui sistem n anumite condiii, care nu pot fi create n mod real, se realizeaz numai prin simulare. Situaiile complexe care apar n studiul proceselor i fenomenelor economice nu pot fi uneori soluionate de instrumentul matematic. Modalitatea de a iei din impas este construirea unui model matematic al sistemului studiat i realizarea de experimente pe acesta. Simularea este o tehnic de realizare a experimentelor cu calculatorul electronic, care implic utilizarea unor modele matematice i logice care descriu comportarea unui sistem real de-a lungul unei perioade mari de timp. Simularea trebuie s genereze intrrile i, innd seama de strile interne ale sistemului, prin algoritmi adecvai, s determine ieirile i s descrie evoluia n timp a strilor interne ale sistemului. Dei nu ofer soluii exacte (ci suboptimale), simularea este o tehnic de cercetare eficient pentru problemele economice complexe la nivel de firm, imposibil de studiat analitic (cu metodele economico-matematice de optimizare). Cu ajutorul simulrii se obin mai multe variante de decizie dintre care managerul o va alege pe cea mai bun, corespunztoare condiiilor date la un anumit moment. n activitatea de simulare sunt implicate trei elemente importante, i anume: sistemul real, modelul, calculatorul i dou relaii: relaiile de modelare i relaiile de simulare. n figura 5.1 se prezint sintetic procesul de trecere de la sistemul real la modelul de simulare / modelul real. 74
Fig. 5.1 Trecerea de la sistemul real la modelul real
Sistemul real reprezint sistemul perceput cu simurile omului. Modelul real reprezint sistemul real nlocuit i care corespunde, n principiu, cerinelor sistemului iniial. Modelul abstract realizeaz trecerea de la sistemul real la modelul real. El reproduce sistemul real prin descompunerea sistemului n prile componente elementare i stabilete legturile dintre acestea. Validarea rezultatelor se face prin stabilirea concordanei dintre datele din sistemul real i cele oferite de model. Pentru ca deciziile elaborate pe baza rezultatelor simulrii unui proces economic s fie viabile, este necesar ca i caracteristicile aleatoare (preul, cererea de produse, durata de servire etc.) s fie incluse n modelul de simulare. O mrime aleatoare are mai multe valori posibile, fiecare valoare avnd asociat o anumit probabilitate. Rezult c nu poate fi cunoscut cu certitudine care va fi, la un moment dat, valoarea variabilei aleatoare. Pentru realizarea experimentelor de simulare n vederea determinrii valorilor unui indicator economic, este necesar o metod special care s permit generarea la ntmplare a valorilor pentru fiecare factor aleator care influeneaz indicatorul respectiv. Aceste valori pot fi reprezentate printr-o distribuie de probabilitate obinut prin metoda de simulare Monte Carlo (sau metoda experimentelor statistice).
5.2 Metoda Monte Carlo Metoda de simulare Monte Carlo poate fi definit ca metoda modelrii variabilelor aleatore, n scopul calculrii caracteristicilor distribuiilor lor de probabilitate. Etapele ce trebuie efectuate pentru a realiza simularea prin metoda Monte Carlo, sunt urmtoarele: 1. identificarea factorilor; 2. formularea unui model; 3. determinarea distribuiilor de probabilitate pentru factorii luai n considerare; 4. realizarea simulrii; 5. analiza i interpretarea rezultatelor simulrii. Ideea de baz a metodei Monte Carlo este urmtoarea: metoda Monte Carlo genereaz, la ntmplare, valorile unei variabile aleatoare, prin utilizarea: o unui generator de numere aleatoare uniform distribuite n intervalul [0, 1] 75
o distribuiei de probabilitate cumulat asociat variabilei aleatoare respective. Metoda a fost inventat de ctre cercettorii americani de la Los Alamos National Laboratory prin anii 1940, cnd a fost utilizat pentru simularea traiectoriei unui neutron n plutoniu sau uraniu1. Metoda Monte Carlo poate fi definit ca metod de modelare a variabilelor aleatoare n vederea determinrii caracteristicilor repartiiei lor, atunci cnd aceste caracteristici nu pot fi stabilite prin expresii analitice pe baza funciilor teoretice de densitate de probabilitate. Prin metoda Monte Carlo, procesul real este nlocuit cu un proces artificial. Pentru obinerea unor rezultate corecte, se impune ca variabilele aleatoare generate n timpul experimentelor de simulare s reproduc fidel variabila aleatoare real. Calitatea eantionului obinut prin simulare poate fi apreciat prin teste de concordan (Kolmogorov, Smirnov, Pearson sau 2) care msoar apropierea dintre repartiia teoretic specificat pentru o anumit variabil aleatoare i repartiia simulat.
5.3 Estimarea succesului aplicaiei n cazul comerului electronic, noutatea i caracteristicile specifice acestui tip de afacere nu ne permit luarea n considerare a acelorai variabile care afecteaz succesul unei afaceri tradiionale de comer. Estimarea profitului pe care site-ul l poate realiza ntr-o anumit perioad de la lansarea sa este destul de dificil, n primul rnd datorit lipsei unor analize amnunite n acest scop. n ceea ce privete succesul unui site, acesta poate fi cel mai bine estimat prin numrul de vizitatori ai site-ului, care pot reprezenta poteniali cumprtori ai produselor oferite. Trasnd o paralel, am putea spune c numrul de vizitatori ai unui site reprezint echivalentul tirajului unui ziar sau al audienei unei emisiuni de radio/televiziune. n aceste condiii, un numr mare de vizitatori poate reprezenta o garanie a faptului c respectivul site va obine succesul ateptat. Ulterior, n funcie de volumul efectiv al vnzrilor, cercetarea poate fi extins n vederea estimrii profitului viitor al afacerii electronice. Simularea succesului aplicaiei se va baza pe datele statistice furnizate de site-ul www.trafic.ro, care se ocup cu analiza site-urilor din punct de vedere al numrului de vizitatori. Datele luate n considerare vizeaz numrul de vizitatori ai magazinului virtual www.samancambine.ro n primele 16 de sptmni de la data nscrierii pe www.trafic.ro. Motivul pentru care am ales www.samancambine.ro ca punct de reper este simplu: ideea care st la baza site-ului, precum i produsele oferite sunt similare cu cele oferite de aplicaia de fa, ceea ce ne permite o estimare ct mai aproape de adevr. Situaia real de la care am pornit n realizarea simulrii este prezentat n tabelul urmtor:
76
Capitolul V Simularea Succesului Unei Aplicaii Web Numr sptmn 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Numr vizitatori 591 778 555 517 511 290 262 277 300 394 592 390 402 782 62 12
Pasul 1: Determinarea distribuiilor de probabilitate. Pentru determinarea probabilitii voi folosi definiia acesteia care spune c: probabilitatea este raportul dintre numrul cazurilor favorabile realizrii unui eveniment i numrul cazurilor posibile. n cazul de fa am calculat probabilitatea relativ astfel: mai nti am determinat numrul total de vizitatori din perioada luat n considerare (16 sptmni), prezentai n tabelul de mai sus i am obinut rezultatul 6715. Apoi am folosit urmtoarea formul: (numr de vizitatori per sptmn)/ (suma vizitatorilor magazinului virtual din perioada considerat, adic 6715). Probabilitatea cumulat se obine astfel: prima valoare este reprezentat probabilitatea relativ corespunztoare, iar valorile urmtoare se obin prin nsumarea succesiv a probabilitilor cumulate anterioare ca poziie, adic dup formula: p k = pi , i = 1,2,...,16
i =1 k
, unde pi reprezint probabilitile relative asociate factorilor aleatori. n tabelul de mai jos sunt prezentate valorile obinute pentru probabilitile relative, respectiv cumulate corespunztoare valorilor analizate. De asemenea au fost determinate i intervalele de numere aleatoare corespunztoare datelor din exemplul nostru.
NR SPTMN 1 2 3 4 5 6 7 8 9 10 11 12 13 14 PROBABILITATEA RELATIV 0,088 0,116 0,083 0,077 0,076 0,043 0,039 0,041 0,045 0,059 0,088 0,058 0,06 0,116 PROBABILITATE CUMULAT 0,088 0,204 0,287 0,364 0,44 0,483 0,522 0,563 0,608 0,667 0,755 0,813 0,873 0,989 INTERVAL [PK-1,PK) [0;0,088) [0,088;0,204) [0,204;0,287) [0,287;0,364) [0,364;0,44) [0,44;0,483) [0,483;0,522) [0,522;0,563) [0,563;0,608) [0,608;0,667) [0,667;0,755) [0,755;0,813) [0,813;0,873) [0,873;0,989)
77
Capitolul V Simularea Succesului Unei Aplicaii Web 15 16 0,009 0,002 0,998 1 [0,989;0,998) [0,998;1)
Dac suma probabilitilor relative, adic ultima valoare a probabilitii cumulate este 1, atunci calculele corecte. O proprietate de baz din teoria probabilitilor spune c suma probabilitilor unei variabile aleatoare este 1. ntruct ultima valoare din coloana corespunztoare probabilitii cumulate este 1, nseamn c, pn n prezent, calculele sunt corecte. Pasul 2: La acest pas voi prezenta graficul corespunztor probabilitilor cumulate calculate la pasul anterior. Pe axa Oy se reprezint valorile probabilitilor cumulate, iar pe axa Ox valorile pentru care au fost calculate aceste probabiliti, adic numrul de vizitatori ce intr n magazin n fiecare sptmn, valori pe care le avem n tabelul de mai sus. Pentru fiecare valoare corespunztoare numrului de vizitatori din sptmna respectiv se reprezint o bar vertical avnd nlimea egal probabilitatea cumulat corespunztoare.
Probabilitatea cumulat 1,2 1 0,8 0,6 0,4 0,2 0,088 0 591 778 555 517 511 290 262 277 300 394 592 390 402 782 62 12 Nr vizitatori / sptmn 0,204 0,287 0,364 0,608 0,522 0,563 0,44 0,483 0,667 0,873 0,755 0,813 0,989 0,998 1
Pasul 3: La acest pas se genereaz numerele aleatoare uniform repartizate n intervalul [0,1), utiliznd un generator automat de numere aleatoare. n cazul de fa numerele au fost generate folosind funcia RAND() din Excel. n continuare, fiecare numr obinut va fi asociat
1 ; p k ) . ntr-o alt coloan se va trece numrul de vizitatori pe sptmn intervalului [ p k corespunztor intervalului din care face parte numrul aleator generat.
Nr . spt. 1 2 3 4 5 6 7 8 9 10 11 12 13
Nr. viz/spt 591 778 555 517 511 290 262 277 300 394 592 390 402
Probabilitatea relativ 0,088 0,116 0,083 0,077 0,076 0,043 0,039 0,041 0,045 0,059 0,088 0,058 0,06
Probabilitate cumulat 0,088 0,204 0,287 0,364 0,44 0,483 0,522 0,563 0,608 0,667 0,755 0,813 0,873
Interval [Pk-1,Pk) [0;0,088) [0,088;0,204) [0,204;0,287) [0,287;0,364) [0,364;0,44) [0,44;0,483) [0,483;0,522) [0,522;0,563) [0,563;0,608) [0,608;0,667) [0,667;0,755) [0,755;0,813) [0,813;0,873)
Nr. Exp. 1 2 3 4 5 6 7 8 9 10 11 12 13
Nr. aleator 0,503 0,751 0,332 0,613 0,766 0,685 0,516 0,3 0,457 0,761 0,183 0,809 0,774
Nr. viz/spt 262 592 517 394 390 592 262 517 290 390 778 390 390
78
Capitolul V Simularea Succesului Unei Aplicaii Web 14 15 16 782 62 12 0,116 0,009 0,002 0,989 0,998 1 [0,873;0,989) [0,989;0,998) [0,998;1) 14 15 16 0,579 0,534 0,284 300 277 555
Pasul 4: Analiza statistic a datelor. Voi determina indicatorii de poziie i ai variaiei, adic numrul mediu de vizitatori, deviaia standard, coeficientul de variaie al distribuiei i intervalul de ncredere pentru nivelul de semnificaie /2=0,025. Numrul mediu de vizitatori se va calculeaz dup formula:
N Numrul mediu reprezint valoarea distribuiei de probabilitate n jurul creia fluctueaz valorile date. Deviaia standard se calculeaz conform formulei:
nrmv =
nrv
i =1
s=
i =1
(nrmv nrvi ) N 1
Deviaia standard arat cu ct se abat n medie valorile distribuiei de probabilitate fa de numrul mediu. Majoritatea valorilor distribuiei sunt cuprinse n intervalul
( nrmv s, nrmv + s )
Pentru N>=30 intervalul de ncredere se construiete cu relaia :

s s , nrmv + z / 2 * nrmv z / 2 * N N
unde: =0,05 se numete nivel de semnificaie; (1-)=0,95 este probabilitate (deci /2=0,025). Estimaiile de forma intervalelor de ncredere ne permit ca pe baza distribuiei studiate s indicm intervalul n care se afl cuprins media, parametrul pe care dorim s-l estimm, cu o probabilitate apropiat de 1. Valoarea distribuiei normale z/2=1,96 se gsete n tabelul distribuiei t (Student), pe ultima linie a acestuia. Coeficientul de variaie se calculeaz dup formula:
Cv % = s 100 nrmv
Dup cum se observ din formula de mai sus coeficientul de variaie al unei distribuii este raportul dintre deviaia standard i medie. Coeficientul de variaie ne arat ce procent din medie reprezint abaterea standard. Dac CV%>20% spunem c distribuia prezint o variaie mare. Pentru o mai bun nelegere a rezultatelor, pe lng variabilele prezentate mai sus vom calcula n plus valoarea median i valoarea modal. Valoarea median este acea valoare a variabilei care mparte seria n dou pri egale. Valoarea modal este acea valoare a variabilei creia i corespunde frecvena cea mai mare de apariie i se mai numete modul sau valoare dominant. Valorile obinute n cazul exemplului nostru sunt sintetizate n tabelul de mai jos: 79
Capitolul V Simularea Succesului Unei Aplicaii Web Numr de vizitatori Date valide Date invalide Valoarea medie Valoarea median Valoarea modal Deviaia standard Coeficientul de variaie Valoarea minim Valoarea maxim
16 0 431 517 390 249,1464 57,80% 262 778
5.4 Interpretarea rezultatelor Valorile din tabelul de mai sus ne permit unele concluzii referitoare la succesul pe care site-ul l va nregistra n primele luni de funcionare. Numrul mediu al vizitatorilor site-ului n decursul unei sptmni se va situa n jurul valorii de 431, cu o abatere de aprox. 249 vizitatori. Mai exact, numrul mediu de vizitatori ai site-ului va oscila n intervalul (181,8536 ; 680,1464). Avnd n vedere c valoarea coeficientului de variaie este de 57,80%, putem spune c un procent de 57,80% din numrul mediu de vizitatori estimai pe sptmn se abate de la valoarea medie estimat de 431 viz./spt. Acest lucru ne demonstreaz faptul c distribuia numrului de vizitatori are o variaie mare. De asemenea, rezultatele simulrii ne duc la concluzia c numrul minim de vizitatori pe sptmn va fi de 262, n timp ce numrul maxim va atinge valoarea de 778. De asemenea, valoarea cu cea mai mare frecven a numrului de vizitatori este 390, ceea ce nseamn c n cele mai multe sptmni site-ul va fi vizitat de un numr de 390 de vizitatori. Rezultatele obinute plaseaz aplicaia n topul primelor 10 site-uri din categoria comer electronic comenzi on-line mncare. Lund n considerare i faptul c aceast pia, a comenzilor on-line de mncare, se afl la nceputurile dezvoltrii sale i coroborat cu faptul c aplicaia de fa va fi prima de acest gen de pe piaa Clujului, putem afirma cu ncredere c site-ul se va bucura de succesul scontat.
80
Concluzii i Propuneri
CONCLUZII I PROPUNERI
Obiectivul acestei lucrri const n prezentarea fundamentelor teoretice i practice care stau la baza dezvoltrii unei afaceri virtuale, n particular a unei aplicaii de food-ordering care s faciliteze procesul de comandare on-line de preparate culinare de la furnizorii care asigur livrarea la domiciliu. n cadrul lucrrii de fa, plecnd de la prezentarea elementelor teoretice de baz din domeniul economic i informatic am ajuns la elaborarea unui model economic i informatic de afacere virtual adaptabil mediului de afaceri din Romnia i nu numai. Trebuie menionat faptul c aplicaia prezentat reprezint un prototip, aflndu-se nc n faza de implementare, scopul principal al lucrrii de fa fiind evidenierea facilitilor oferite de o astfel de aplicaie. Odat terminat etapa de implementare, vor urma fazele de testare, publicare i promovare a versiunii prototip. Testarea se va face de ctre un grup restrns de persoane, reprezentani ai celor trei categorii de utilizatori crora li se adreseaz aplicaia, i anume vizitatori, clieni i furnizori, urmrindu-se corectitudinea operaiilor efectuate de aplicaie, msura n care utilizarea ei este intuitiv, precum i msura n care satisface necesitile publicului int. n etapa de publicare cel mai mare accent se va pune pe alegerea unui nume de domeniu intuitiv, care s permit crearea unei identiti on-line. Din momentul n care aplicaia va deveni funcional n totalitate i va fi pus la dispoziia publicului larg, prin publicarea ei pe internet, se va trece la faza de promovare, utiliznd att metode ale marketing-ului clasic, ct i ale marketing-ului electronic: promovarea prin intermediul motoarelor de cutare, schimbul de bannere, schimbul de link-uri, promovarea prin e-mail, precum i publicarea adresei site-ului pe toate materialele promoionale ale furnizorilor care vor fi nscrii n aplicaie, precum i n publicaiile de specialitate. n ceea ce privete mbuntirile care s-ar putea aduce aplicaiei de food-ordering n etapele de dezvoltare ulterioar, printre acestea se numr: o implementarea unui sistem de pli electronice; o implementarea unui forum avnd ca tem principal reetele culinare; o implementarea unei interfee mai atractive, dar care s nu solicite resurse hardware mari; o realizarea unui top al celor mai vndute produse, al celor mai solicitai furnizori sau al celor mai fideli clieni; o implementarea unor instrumente care s ofere furnizorilor statistici privind numrul de clieni i produsele comandate. G.B. Shaw definea economia ca fiind arta de a obine maximum de la via. Pentru a fi ntr-adevr eficieni n obinerea maximizrii, trebuie mai nti s nvm s ne gestionm timpul ntr-un mod ct mai eficient. Societatea de azi se caracterizeaz prin vitez. n aceast situaie, timpul devine o resurs limitat, iar gestionarea lui ct mai eficient devine una din principalele ci de obinere a succesului n afaceri. n aceste condiii, aplicaia prezentat ofer o modalitate eficient de satisfacere a necesitilor utilizatorilor si cu un consum minim din resursa cea mai rvnit, timpul.
81
BIBLIOGRAFIE
Publicaii i cursuri 1. [Avornicului_2006] C. Avornicului, M. Avornicului, Sisteme Analiz - Proiectare, Ed. Risoprint, Cluj-Napoca, 2006 2. [Bruegge_2004] B. Bruegge, A. Dutoit, Object Oriented Software Engineering, Prentice Hall, 2004 3. [BuBois_2001] P.BuBois, MySQL, Ed. Teora, Bucureti, 2001 4. [Buraga_2003] S. Buraga (coord.), Aplicaii Web la cheie, Ed. Polirom, Iai, 2003 5. [Buraga_2005] S. Buraga, Tendine actuale n proiectarea i dezvoltarea aplicaiilor Web, Iai, 26-27 noiembrie 2005 6. [Conallen_2002] J. Conallen, Building Web Applications with UML Second Edition, Addison Wesley, 2002 7. [Greenspan_2001] J. Greenspan, B. Bulger, MySQL/PHP Database Applications, M&T Books, New York, 2001 8. [McCarty_2002] B. McCarty, PHP 4, Ed. Teora, Bucureti, 2002 9. [Quatrani_2002] T. Quatrani, Visual Modeling with Rational Rose 2002 and UML, Addison Wesley, 2002 10. [Rumbaugh_1999] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, Addison Wesley, 1999 11. [Rusu_2003] L. Rusu, Proiectarea i realizarea aplicaiilor Web, Ed. Risoprint, ClujNapoca, 2003 12. [Suciu_2003] C. Raiu-Suciu, Modelarea i Simularea proceselor economice, Editura Economic, Bucureti, 2003 13. [Welling_2003] L. Welling, L. Thomson, Dezvoltarea Aplicaiilor Web cu PHP i MySQL, Ed. Teora, Bucureti, 2003
Legislaie [1] Legea Nr. 365/7 Iunie 2002, privind Comerul Electronic [2] Legea Nr. 455/2001, privind Semntura Electronic
82
[3] Regulamentul 4 din 13 iunie 2002, privind tranzaciile efectuate prin intermediul instrumentelor de plat electronic [4] Legea Nr. 677/2001, pentru protecia persoanelor cu privire la prelucrarea datelor cu caracter personal i libera circulaie a acestor date [5] Legea Nr. 8/1996, privind dreptul de autor i a drepturile conexe [6] Legea Nr. 483/5 Iulie 2002, privind comunicrile comerciale
Resurse Web [site1] www.afaceri.net/articole/Webdesign/Promovare/Razboiul_cu_motoarele_de_cautare.htm [site2] http://inf.ucv.ro/~giurca/courses/CB3105/resources/Modelarea%20Dinamica.pdf [site3] http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme [site4] www.MySQL.com [site5] www.php.net [site6] www.underclick.ro [site7] www.hotnews.ro/articol_25442-Afaceri-on-line-tendinte-si-greseli.htm [site8] www.business-online.ro/VersiuneaRomana/Internet&Afaceri.html
83

Proiectarea Aplicatiilor de Comert Electronic - Aplicatie de Food-Ordering

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proiectarea Aplicatiilor de Comert Electronic - Aplicatie de Food-Ordering

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA BABE-BOLYAI CLUJ-NAPOCA FACULTATEA DE TIINE ECONOMICE I GESTIUNEA AFACERILOR SECIA INFORMATIC ECONOMIC

PROIECTAREA APLICAIILOR DE COMER ELECTRONIC. APLICAIE DE FOOD-ORDERING

Coordonator tiinific: Prof. univ. dr. TEFAN IOAN NICHI Absolvent:

Capitolul I Concepte Generale de Comer Electronic

CAPITOLUL I CONCEPTE GENERALE DE COMER ELECTRONIC

Capitolul I Concepte Generale de Comer Electronic

Capitolul I Concepte Generale de Comer Electronic

Capitolul I Concepte Generale de Comer Electronic

Capitolul I Concepte Generale de Comer Electronic

Capitolul I Concepte Generale de Comer Electronic

Capitolul I Concepte Generale de Comer Electronic

Capitolul I Concepte Generale de Comer Electronic

Capitolul I Concepte Generale de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

CAPITOLUL II DEZVOLTAREA UNUI SISTEM DE COMER ELECTRONIC

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul II Dezvoltarea Unui Sistem de Comer Electronic

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

CAPITOLUL III TEHNOLOGII I INSTRUMENTE INFORMATICE UTILIZATE N DEZVOLTAREA APLICAIEI

Fig. 3.1 Arhitectura generic client/server

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul III Tehnologii i Instrumente Informatice Utilizate n Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

CAPITOLUL IV DEZVOLTAREA APLICAIEI

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

Capitolul IV Dezvoltarea Aplicaiei

<<extinde>> Navigare categorii de preparate <<extinde>>

Vizualizare info preparat <<extinde>>

<<extinde>> Vizualizare info furnizor

nregistrare ca i client al aplicaiei

Demarare asisten on-line

Conectare la aplicaie ca i client

Conectare la aplicaie ca i furnizor

Fig. 4.1 Cazurile de utilizare pentru vizitator

Capitolul IV Dezvoltarea Aplicaiei

Administrare comand n pregtire

Lansare comand n pregtire