ACADEMIA DE STUDII ECONOMICE DIN MOLODVA

FACULTATEA Cibernetic, Statistic i Informatic Economic

Catedra Cibernetic i Informatic Economic

Babuci Livia

TEZ DE LICEN
Tema: Proiectarea aplicaiilor de comer electronic

Executor: studenta gr. INF 281,

Babuci Livia
Conductor tiinific: lector superior,
Covalenco Ion

0
 Chiinau 2011
CUPRINS
INTRODUCERE..................................................................................................................2

CAPITOLUL I
CONCEPTE GENERALE PRIVIND COMERUL ELECTRONIC........................4
1.1. Noua economie. Revoluia Internet............................................................................4
1.2. Afaceri electronice. Comer electronic.......................................................................5
1.3 Avantajele i dezavantajele comerului electronic.......................................................8
1.4. Aspecte nefavorabile privind dezvoltarea comerului electronic...............................10
1.5. Descrierea social economic a unitii.......................................................................11

CAPITOLUL II
DEZVOLTAREA UNUI SISTEM DE COMER ELECTRONIC...............................12
2.1. Arhitectura unui sistem de comer electronic...........................................................12
2.2. Etapele implementrii unui sistem de comer electronic..........................................12
2.3. Sistem Electronic de Pli.........................................................................................18
2.4. Arhitectura aplicaiei(client/server)..........................................................................20
2.5. Tehnologii i instrumente informatice utilizate n proiectarea aplicaiei.................22
2.5.1. Limbajul de modelare......................................................................................22
2.5.2. Procesul............................................................................................................24
2.5.3. Justificarea soluiei Apache+PHP+MySQL.....................................................25

CAPITOLUL III
DEZVOLTAREA APLICAIEI.........................................................................................31
3.1. Determinarea cerinelor unei aplicaii de food-ordering............................................31
3.1.1. Cerinele beneficiarilor aplicaiei de food- ordering........................................31
3.1.2. Delimitarea comportamentului aplicaiei (cazuri de utilizare).........................37
3.2. Proiectarea aplicaiei....................................................................................................41
3.3. Designul fizic al aplicaiei...........................................................................................46
3.4. Implementarea aplicaiei.............................................................................................52

CAPITOLUL IV
DESCRIEREA EFICIENEI ECONOMICE UTILIZND METODA SIMULRII
PROCESELOR....................................................................................................................57
5.1. Aspecte generale privind modelarea i simularea proceselor economice..................57
5.2. Estimarea succesului aplicaiei...................................................................................59
5.3. Interpretarea rezultatelor.............................................................................................65

CONCLUZII I PROPUNERI...........................................................................................67

BIBLIOGRAFIE..................................................................................................................68

1
 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).

2
 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.
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).
n dezvoltarea i implementarea aplicaiei am optat pentru avantajele oferite de
triada Apache + MySQL + PHP.
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.
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. 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.

3
 CAPITOLUL I
CONCEPTE GENERALE PRIVIND COMERUL 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:
dezvoltarea accelerat a comunicaiilor avansate;
explozia Internet;
dezvoltarea comerului electronic;
apariia unor noi modele de realizare a afacerilor i restructurarea / re-
ingineria firmelor;
promovarea de noi reguli i forme de organizare, bazate pe inovare;
extinderea formelor de activitate i de munc la distan.
Trebuie menionat faptul c noua economie se bazeaz pe trei principii definitorii:
acces (i rspuns) instantaneu;
servicii personalizate;
prezena simultan n mai multe locuri (ubicuitate).
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.

4
 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.

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:
furnizorul de produse sau servicii cutate;
furnizorul de servicii Internet care poate oferi orice, de la spaiu pe web, la
integrarea de e-mall i la diferite tipuri de servicii;
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).
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

5
 vzut ca acoperind toate interaciunile de tip User-to-Business care nu sunt
acoperite de modelul User-to-Online 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.
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).

6
 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:
un produs - material sau digital;
un loc de vnzare - n acest caz un website n reea care s prezinte produsele
sau serviciile oferite;
o modalitate de a atrage oamenii s vin la un anumit website;
o modalitate de a primi comenzi - n mod normal un formular on-line;
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 modalitate de livrare; dac marfa este de tip software sau informaie,
livrarea se poate face direct prin reea;
o modalitate de a accepta returnri (formulare on-line);
o modalitate de a accepta eventuale reclamaii (formulare on-line);
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.

7
 1.3.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. 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:
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);
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:
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;
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);

8
 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;
existena unei ci rapide i comode de furnizare a informaiilor despre
companie: prin intermediul unor site-uri Web, a intranet-urilor i a extranet-
urilor;
canale alternative de vnzare: desfurarea afacerilor prin intermediul unui
astfel de site.
Dei pare o afacere de vis, exist totui cteva greeli majore care ar putea-o
transforma ntr-un comar:
lipsa unui plan de aciune: antreprenorii se las ghidai doar de entuziasm;
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;
neglijarea aspectelor concureniale: ideea c o afacere electronic trebuie s
aib ca principal avantaj competitiv preul mic al produselor;
neglijarea aspectelor de promovare a produselor: accentul se pune mai mult
pe vnzri, dect pe strategia de marketing.

9
1.4.Aspecte nefavorabile privind dezvoltarea comerului electronic

Exist ase piedici majore care frneaz dezvoltarea comerului electronic:

securitatea: Internetul a fost conceput ca un mediu deschis, dar nu neaprat
i sigur, protocolului TCP/IP (care st la baza comerului electronic) lipsindu-
i 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;
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;
existena unei infrastructuri de telecomunicaii adecvate: pe msur ce
tehnologia avanseaz, apar noi metode de comunicaie celulare;
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;
cadrul legislativ i normativ: se refer la aspectele legate de cadrul fiscal,
drepturile asupra proprietii intelectuale, protecia datelor consumatorului;
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.

10
 1.5. Descrierea social economic a unitii
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 (de exemplu: AndyS Pizza, La
Plcinte, Foior) care s suplineasc, pe ct posibil, neajunsurile acestora. Deoarece
aplicaia dat este una de food ordering (ceea ce ine de comandri on-line a
preparatelor culinare), am ncercat s o dezvolt n aa mod, nct cu unele modificri
(uoare) a bazei de date i a unor aspecte ce in de interfa, s fie posibil utilizarea ei i
de ctre alte firme. Datorit flexibilitii triadei Apache+My SQL+ PHP acest lucru este
foarte usor de executat.
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 Republica Moldova i
nu numai.

11
 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).

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:
Etapa I: Dezvoltarea site-ului i promovarea produselor

12
 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:
Ce tipuri de produse vinde site-ul?
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.
Ce persoane din cadrul companiei vor fi responsabile pentru administrarea
site-ului?
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.
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.

13
 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:
cerine hard: caracteristicile mainilor folosite ca server (memorie, spaiu pe
hard-disk, vitez procesor, etc.)
cerine soft: sistem de operare, server de Web, firewall, pachete de programe
opionale (programe de calcul al taxelor, etc.)
comunicaii: se refer la lrgimea bandei de comunicaie, topologia de reea,
etc.
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:

14
 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.
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.
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.
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.
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.

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),

15
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:
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);
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 fi
extrem de redus.

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

16
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.

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:
capturat: comanda a fost preluat de ctre sistemul vnztorului, ns
metoda de plat aleas de ctre client nu a fost nc validat;
reglat: autoritatea care se ocup de autorizarea plilor a dat vnztorului un
rspuns pozitiv referitor la certificarea metodei de plat a clientului;
respins: comanda este respins, ntruct nu a fost autorizat metoda de plat
a clientului.

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

17
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

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 i este format din dou nivele:
nivelul utilizator, care constituie nivelul ierarhic superior, i
nivelul sistem, care constituie nivelul ierarhic inferior.
n continuare, vor fi descrise pe scurt cele dou nivele:
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.;
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.

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:

18
 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;
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 off-
line 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.

19
 2.4. Arhitectura aplicaiei. Arhitectura Client/Server

Problema proiectrii aplicaiilor a suferit de-a lungul timpului multe modificri i

a dus la apariia unor probleme de programare. Una dintre cele mai rspndite la ora
actual este programarea 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. 2.1. Arhitectura generic client/server

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

20
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:
serverul comunic cu clientul dup un protocol dinainte stabilit;
un server trebuie s fie capabil s deserveasc mai muli clieni;
serverul trebuie s fie gsit de ctre client la aceeai adres;
clienii pot lansa cererile de oriunde din reea;
serverul rspunde cererilor pentru resurse fcute de clieni ntr-un mod
transparent relativ la locaia, managementul sau distribuia resurselor;
serverul funcioneaz ca o interfa de acces la anumite resurse;
Urmtoarea diagram pe 4 nivele detaliaz arhitectura unei aplicaii generice
client/sever:
Fig. 2.2. Arhitectura unei aplicaii client/server generice

Server
Server
Server de
de aplicaie
aplicaie

Interfaa
Interfaa aplicaiei
aplicaiei

Regulile
Regulile de
de business
business

Preluarea
Preluarea informaiilor
informaiilor
Client

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;

21
 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;
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;
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.

2.5. 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.

2.5.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:
joac rolul unui limbaj cu ajutorul cruia sunt comunicate deciziile care nu
sunt evidente sau care nu pot fi deduse din partea de cod;

22
 ofer o semantic suficient de bogat nct s permit capturarea tuturor
deciziilor strategice i tactice importante;
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:
standardul su deschis;
acoper ntreg ciclul de via al dezvoltrii unui soft;
se bazeaz pe experiena celor care l-au dezvoltat;
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:
descoper procesele care au loc n sistem, folosind analiza cazurilor de
utilizare (USE CASE);
se constituie ntr-un bun mijloc de comunicare;
simplific/reduce complexitatea sistemului;
definete arhitectura aplicaiei;
permite reutilizarea componentelor.
Elementele de baz ale UML-ului sunt reprezentate de:
blocurile constructive: elemente, relaii i diagrame;
regulile ce dicteaz modul n care blocurile pot fi combinate;

23
 mecanismele generale: specificaii, ornamente, diviziuni generale,
mecanisme de extensie.

2.5.2. Procesul
Un proiect care urmrete dezvoltarea unei aplicaii software poate fi considerat
de succes dac ndeplinete urmtoarele condiii:
satisface sau chiar depete nevoile utilizatorilor;
face economie de timp i resurse;
produsul rezultat este adaptabil la diversele modificri care ar putea s apar;
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:
dimensiunea temporal: diviziunea ciclului de via n faze i iteraii;
componentele procesului: producerea unei mulimi specifice de elemente
(artefacte) cu activiti bine definite.
Structurarea unui proces n funcie de dimensiunea temporal induce urmtoarele
faze:
lansarea specificarea succint a proiectului;
elaborarea planificarea activitilor i resurselor necesare; specificarea
caracteristicilor i proiectarea arhitecturii;
construcia construirea produsului prin iteraii incrementate;
tranziia furnizarea produsului comunitii (distribuire, instruire, etc.).

24
 Mulimea componentelor procesului ar trebui s conin:
modelarea afacerii identificarea nevoilor utilizatorilor i a ateptrilor
acestora n ceea ce privete funcionalitatea aplicaiei;
identificarea cerinelor descrierea unei viziuni asupra aplicaiei, mpreun
cu un set de cerine funcionale i non-funcionale;
analiza i proiectarea descrierea modului de realizare a aplicaiei n faza
de implementare;
implementarea generarea efectiv a codului surs;
testarea verificarea ntregii aplicaii.

2.5.3. 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. PHP i MySQL reprezint cea mai bun
metod actual pentru crearea unor site-uri care folosesc baze de date.
PHP limbaj scriptural server-side pentru generarea dinamic de coninut Web.
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:
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;
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;
suport pentru ntreinerea unei sesiuni, menit s rein date ntre dou cereri
succesive de pagini ctre acelai server;
funcii pentru transmiterea headere-lor HTTP pentru autentificare;

25
 funcii pentru setarea cookie-urilor;
posibilitatea redirecionrii cererilor de pagin;
librrii ce permit generarea, manipularea i trimiterea ctre browser de
imagini, animaii, PDF-uri;
interfaa de conectare cu majoritatea SGBD-urilor;
interfaa de conectare la un server de e-mail.

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:
sintaxa simpl, relaxat, uor de utilizat: ca limbaj de programare slab tipizat,
variabilele PHP nu trebuie declarate i pot reine orice tip de obiecte;
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;
independena de platform: a fost portat pe toate sistemele de operare majore,
incluznd UNIX, Linux, Windows i MacOs i interacioneaz cu majoritatea
serverelor Web;
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;

26
 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;
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;
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;
ncepnd cu versiunea 4.0, deine suport minimalist pentru programarea
orientat-obiect, suport devenit complet n versiunea 5.0;
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-

27
line, i chiar conveniile de denumire a tuturor site-urilor Web sunt activiti care nu s-ar
putea desfura fr utilizarea bazelor de date.
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:
ncrcarea bazei de date,
actualizarea i interogarea acesteia,
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.
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).
Popularitatea MySQL se datoreaz n primul rnd multiplelor faciliti oferite de
acesta, dintre care vom aminti:
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;
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;
accesul concurent la date de ctre un numr nelimitat de utilizatori: la
server-ul 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

28
 interactiv, folosind numeroase interfee care permit introducerea de interogri
i vizualizarea rezultatelor;
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
accesului astfel nct persoanele care nu au dreptul s citeasc datele nu vor
avea aceast posibilitate
distribuia liber: MySQL este gratuit, fapt ce a atras extinderea fr
precedent a folosirii acestui server de baze de date.
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. Conectivitatea, viteza i securitatea fac
ca MySQL s fie unul din cele mai potrivite produse pentru gestiunea bazelor de date pe
Internet.
Apache
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. Ajuns la versiunea 2.2.2, Apache depete servere comerciale ale
unor firme de prestigiu, prin:

29
 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.
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.
Cteva caracteristici ale serverului Apache sunt:
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;
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;
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;
este popular: n acest moment, serverele web Apache acoper aproximativ
60% din piaa serverelor web;
este gratuit: nu n ultimul rnd, faptul c este distribuit n mod gratuit este
un atu foarte mare pentru Apache.

30
 CAPITOLUL III
DEZVOLTAREA APLICAIEI

3.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.

3.1.1. 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.

31
 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.
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:
publicarea informaiilor eseniale despre fiecare furnizor i existena unor
posibiliti de actualizare a acestor informaii;
prezentarea informaiilor de interes despre preparatele culinare comercializate i
existena unor posibiliti de actualizare a acestor informaii;
prezena mecanismelor de promovare a preparatelor ntr-o manier eficient i
imparial, dar care s nu afecteze uurina n folosire a aplicaiei;
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;
accesul bine organizat i facil al utilizatorului att la informaiile despre
furnizori, ct i la cele despre preparatele culinare;
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;

32
 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:
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;
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;
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;
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;
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.

33
poate renuna la ea n orice moment) i s poat fi consultat ntr-un mod facil din
orice pagin a aplicaiei;
lansarea listei de comenzi trebuie s fie o procedur clar, explicit,
necondiionat dect de dorina clientului;
posibilitatea lansrii de comenzi cu o dat de livrare ulterioar datei efecturii
comenzii;
posibilitatea lansrii unei liste de comenzi cu preparate de la furnizori diferii;
aplicaia trebuie s ofere posibilitatea de anulare a oricrei comenzi lansate,
pn n momentul n care aceasta a fost confirmat de ctre furnizor;
plata unei comenzi s se poat efectua la livrare i s existe posibilitatea
facturrii serviciului cumprat;
reducerea la minim a informaiilor cerute n momentul lansrii unei comenzi;
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;
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;
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;

34
 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;
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:

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;
interfa prietenoas de administrare a informaiilor pe care un furnizor va avea
posibilitatea s le publice prin intermediul aplicaiei;
interfa prietenoas de administrare a comenzilor; o comand se va putea afla
ntr-una 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;
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

35
pentru confirmarea comenzii, adresa de livrare (aceasta trebuie s fie n aria de
livrare declarat) i, eventual, datele necesare unei facturi fiscale;
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;
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;
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;
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:

aplicaia trebuie s permit accesul n orice moment, din orice pagin, la
condiiile de utilizare a aplicaiei, politica de confidenialitate, descrierea
aplicaiei;
aplicaia se oblig s posteze informaiile despre preparatele unui furnizor doar
dac acesta i d acceptul n respectarea urmtoarelor condiii:
s trateze fiecare comand cu aceeai seriozitate, indiferent de or,
client, adres de livrare;
s acorde atenie eventualelor reclamaii din partea clienilor.

36
 3.1.2. Delimitarea comportamentului aplicaiei (cazurile de utilizare)
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 :
sunt uniti de sine stttoare, bine delimitate (nceputul i sfritul unui caz
de utilizare sunt cuprinse n acesta);
trebuie s fie iniiate de un actor i terminarea lor s fie vzut de un actor;
trebuie s ndeplineasc anumite scopuri de logic a problemei (dac nu se
poate gsi un astfel de obiectiv atunci cazul de utilizare trebuie regndit);
trebuie s lase sistemul ntr-o stare stabil (nu pot fi ndeplinite doar pe
jumtate).
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:
s vizualizeze informaiile despre furnizori i preparatele acestora;
s caute un preparat cel puin dup urmtoarele informaii relevante:
furnizor, ora de livrare, aria de livrare, pre, ingrediente;
s contacteze un furnizor pentru eventualele nelmuriri legate de preparatele
pe care acesta declar c le poate livra;
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;
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;

37
 s se poat nregistra n aplicaie, prin crearea unui cont;
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:

Un VIZITATOR es te 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 <<extinde>>

Vizualizare info preparat
de preparate
<<extinde>>

Cutare preparat <<extinde>>

Vizualizare info furnizor

Navigare furnizori
<<extinde>>

Contactare furnizori
VIZITATOR nregistrare ca
i client al aplicaiei

Demarare asisten
on-line

Conectare la
aplicaie ca i client

Conectare la
aplicaie ca i furnizor

Fig. 3.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:
cutarea unui preparat prin instrumentele puse la dispoziie de aplicaie;
38
 consultarea meniului unui furnizor;
navigarea categoriilor de preparate.
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.
Un CLIENT este un utilizator care
es te nregistrat n evidena aplicaiei
ca i beneficiar al serviciilor de
comand on-line i n plus S-A
CONECTAT LA APLICAIE.

<<exti nde>>

Administrare Lans are comand

VIZITATOR comand n pregtire n pregtire

<<exti nde>>

<<exti nde>>

Vizualizare info preparat

Adugare preparat la
comanda n pregtire
CLIENT
Vizualizare comenzi
n derulare <<exti nde>>

Trimitere prere
Vizualizare des pre preparat
istoric com enzi

Administrare cont

Fig. 3.2. Cazurile de utilizare pentru client

Se observ c ntre 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

39
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:
informaii personale i de conectare;
lista adreselor de livrare;
lista informaiilor de facturare;
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:
Detalierea cazului de utilizare
Administrare cont client

<<incl ude>> Configurarea informaii

personale i de conectare

<<incl ude>>

Administrare cont
CLIENT

<<incl ude>>
<<incl ude>> Administrare
adrese de livrare

Administrare inform aii Administrare inform aii

grupuri de clieni de facturare

Fig. 3.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.

40
 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:

Un FURNIZOR este un utilizator

nregis trat n aplicaie ca i pres tator
de servicii de preparare i livrare la
domiciliu de produs e culinare.

<<include>>

Configurare informaii personale

i de conectare furnizor
Administrare cont
<<incl ude>>

FURNIZOR

Modificare meniu

<<include>>

Administrare comenzi

<<incl ude>>

Adminis trare com enzi

pentru ziua n curs

Adminis trare comenzi pentru

Vizualizare istoric comenzi o zi ulterioar celei n curs

Fig. 3.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:
nregistrarea unui client nou;
conectarea la aplicaie a clienilor;
conectarea la aplicaie a furnizorilor;

41
 consultarea listei de furnizori;
consultarea listei de categorii de preparate comandabile prin acest serviciu;
cutarea unui preparat dup criterii relevante;
consultarea informaiilor despre un anumit preparat;
vizualizarea termenilor i condiiilor de utilizare a aplicaiei, a politicii de
confidenialitate, a pailor pentru crearea unui cont client.
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:
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;
vizualizarea istoricului de comenzi efectuate de-a lungul folosirii aplicaiei;
adugarea unui preparat la comanda n pregtire;
lansarea comenzii n pregtire;
administrarea comenzii n pregtire;
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:
administrarea contului de furnizor prin configurarea informaiilor personale
i de conectare, precum i modificarea meniului;
vizualizarea istoricului de comenzi efectuate ctre clieni;
administrarea comenzilor n ateptare pentru o zi ulterioar celei n curs;
administrarea comenzilor n ateptare pentru ziua n curs.

42
 3.2. Proiectarea aplicaiei

Designul conceptual al aplicaiei.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 PAR TEA D E
SER VER C L IE N T

N ive lu l d e
IN T E R N E T BRO W SER
p re ze n tare

N ive lu l d e
lo g ic a a p lic atie i

Buy SmartDraw !- purchased copies print this

document without a watermark .
N ive lu l d e d ate Visit www .smartdraw.com or call 1-800-768-3729.

Fig. 3.5. Arhitectura three-tier

n figura de mai sus este prezentat modul n care interacioneaz cele trei nivele:
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;
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

43
 asemenea, acest nivel joac rolul de intermediar ntre baza de date i client,
fiind responsabil cu transferul datelor;
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:
PAR TEA D E PAR TEA D E
SER VER C L IE N T

N ive lu l d e
IN T E R N E T BRO W SER
p re z e n tare

S c r ip t u r i P H P d e
g e n e r a r e d in a m ic a
a in t e r f e t e i

N ive lu l d e S c r ip t u r i P H P c a r e
c o n t r o le a z lo g ic a s i
lo g ic a ap lic atie i f lu x u l a p lic a t ie i

L ib r a r i e d e f u n c t i i P H P
d e a d m in is t r a r e B D
M ySQ L

Buy SmartDraw !- purchased copies print this

B a z a d e d a te document without a watermark .
N ive lu l d e d a te M ySQ L Visit www .smartdraw .com or call 1-800-768-3729.

Fig. 3.6. Arhitectura aplicaiei de food-ordering

44
 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.

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 a bazelor 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), al crui obiectiv este
acela de simplificare a accesului la bazele de date de ctre utilizatorii finali.

45
 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, care 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.

3.3. Designul fizic al aplicaiei

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.

46
 Fig. 3.7. 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, protejnd-o mpotriva
pericolelor prezente n mediul Web, inclusiv mpotriva utilizrii necorespunztoare de
ctre beneficiarii si. Pachetul de Autentificare i autorizare satisface cerina aplicaiei
de a controla accesul la funcionalitatea acesteia prin intermediul conturilor i a

47
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.
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.
Componenta de Procesare - principala responsabilitate pe care o deine 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. 3.8. Relaiile dintre componentele aplicaiei

48
 Putem 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:
componenta de Interfa i cea de Procesare (IProcesare): aceast interfa
asigur transformrile necesare ntre formatele de date cu care lucreaz cele
dou componente;
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.

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:
pentru a ilustra aciunile care vor fi realizate cnd este executat o operaie;
pentru a arta cum o instan a unui caz de utilizare poate fi realizat n
termenii aciunilor;
pentru a ilustra cum este organizat munca actorilor.

49
 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.
VIZITATOR BROWSER Scripturi PHP serv er-side

Sunt verificate Se poate crea

Compleaz formular cu date [ DA ] [ DA ]
restrictiile de tip? cont? Creaz cont
necesare pentru nregistrare

[ NU ]
[ NU ]

Semnalizeaz
problemele aprute
Semnalizeaz
problemele aprute

Trimit e-mail cu informaiile de

conectare ale contului creat

Trimit confirmarea
crerii contului

Fig. 3.9. Diagrama de activitate care prezint nregistrarea unui utilizator ca i

client al aplicaiei

Paii urmai n realizarea activitii de nregistrare ca i client al aplicaiei sunt

urmtorii:
vizitatorul completeaz un formular cu datele necesare pentru nregistrare;
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;
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

50
 contului, atunci scripturile semnaleaz erorile aprute i se reia activitatea de
completare a formularului;
scripturile PHP creeaz contul de utilizator;
scripturile PHP trimit un e-mail cu datele noului cont creat;
vizitatorul vizualizeaz un mesaj care l ntiineaz ca a fost creat contul.

VIZITATOR BROWSER Scripturi PHP serv er-side

Sunt verificate
Completare nume de [ DA ]
restrictiile de ti p? Autorizeaz conectarea
utilizator i parol

[ NU ]

Semnalizeaz
problemele aprute

Sunt corecte datel e de

Semnalizeaz conectare?
problemele aprute [ NU ]

[ DA ]

Configureaz sesiunea
de conectare

Permit accesul vizitatorului la

opiunile principale ale clienilor

Fig. 3.10. Diagrama de activitate care prezint conectarea unui client la aplicaie

Paii urmai n realizarea activitii de conectare a unui client la aplicaie sunt

urmtorii:
vizitatorul completeaz numele de utilizator i parola;
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;
dac restriciile de tip sunt ndeplinite, atunci scripturilor PHP le revine
responsabilitatea de a autoriza conectarea;

51
 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;
dac datele de conectare sunt corecte, atunci scripturile configureaz sesiunea
de conectare;
scripturile PHP permit accesul vizitatorului la opiunile principale ale
clientului.

3.4. 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.

Fig. 4.13. Structura paginilor de index ale aplicaiei

52
 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.
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 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

53
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.

Librria mysql.lib.php conine dou tipuri de funcii:

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

54
 unei bazei de date, returneaz n caz de eroare n execuia comenzii, valoarea 0
inhibnd totodat afiarea n pagin a erorii;
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.

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
site-ului 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.

55
 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.
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.
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:
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.

56
 CAPITOLUL V
DESCRIEREA EFICIENEI ECONOMICE UTILIZND METODA SIMULRII
PROCESELOR

5.1. Aspecte generale privind modelarea i simularea proceselor economice

ntr-o definiie succint 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.

57
 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.

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

58
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. 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

59
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.
Situaia de la care am pornit n realizarea simulrii este prezentat n tabelul
urmtor:
Numr Numr
sptmn vizitatori
1 591
2 778
3 555
4 517
5 511
6 290
7 262
8 277
9 300
10 394
11 592
12 390
13 402
14 782
15 62
16 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

60
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:
k
p k pi , i 1,2,...,16 , unde pi reprezint probabilitile relative asociate factorilor
i 1

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 PROBABILITATEA PROBABILITATE INTERVAL
SPTMN RELATIV CUMULAT [PK-1,PK)
1 0,088 0,088 [0;0,088)
2 0,116 0,204 [0,088;0,204)
3 0,083 0,287 [0,204;0,287)
4 0,077 0,364 [0,287;0,364)
5 0,076 0,44 [0,364;0,44)
6 0,043 0,483 [0,44;0,483)
7 0,039 0,522 [0,483;0,522)
8 0,041 0,563 [0,522;0,563)
9 0,045 0,608 [0,563;0,608)
10 0,059 0,667 [0,608;0,667)
11 0,088 0,755 [0,667;0,755)
12 0,058 0,813 [0,755;0,813)
13 0,06 0,873 [0,813;0,873)
14 0,116 0,989 [0,873;0,989)
15 0,009 0,998 [0,989;0,998)
16 0,002 1 [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

61
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.

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 intervalului pk 1 ; pk . ntr-o alt coloan se va trece

numrul de vizitatori pe sptmn corespunztor intervalului din care face parte
numrul aleator generat.
Nr . Nr. Probabilitatea Probabilitate Interval Nr. Nr. Nr.
spt. viz/spt relativ cumulat [Pk-1,Pk) Exp. aleator viz/spt
1 591 0,088 0,088 [0;0,088) 1 0,503 262
2 778 0,116 0,204 [0,088;0,204) 2 0,751 592
3 555 0,083 0,287 [0,204;0,287) 3 0,332 517
4 517 0,077 0,364 [0,287;0,364) 4 0,613 394
5 511 0,076 0,44 [0,364;0,44) 5 0,766 390
6 290 0,043 0,483 [0,44;0,483) 6 0,685 592

62
 7 262 0,039 0,522 [0,483;0,522) 7 0,516 262
8 277 0,041 0,563 [0,522;0,563) 8 0,3 517
9 300 0,045 0,608 [0,563;0,608) 9 0,457 290
10 394 0,059 0,667 [0,608;0,667) 10 0,761 390
11 592 0,088 0,755 [0,667;0,755) 11 0,183 778
12 390 0,058 0,813 [0,755;0,813) 12 0,809 390
13 402 0,06 0,873 [0,813;0,873) 13 0,774 390
14 782 0,116 0,989 [0,873;0,989) 14 0,579 300
15 62 0,009 0,998 [0,989;0,998) 15 0,534 277
16 12 0,002 1 [0,998;1) 16 0,284 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

nrv i
nrmv i 1

N
Numrul mediu reprezint valoarea distribuiei de probabilitate n jurul creia
fluctueaz valorile date.
Deviaia standard se calculeaz conform formulei:
N
(nrmv nrvi )
2

s i 1

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

63
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:
s
Cv % 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:

Numr de vizitatori
Date valide 16
Date invalide 0
Valoarea medie 431
Valoarea median 517
Valoarea modal 390
Deviaia standard 249,1464
Coeficientul de
variaie 57,80%
Valoarea minim 262
Valoarea maxim 778

64
 5.3. 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.

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 Moldova 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

65
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:
implementarea unui sistem de pli electronice;
implementarea unui forum avnd ca tem principal reetele culinare;
implementarea unei interfee mai atractive, dar care s nu solicite resurse
hardware mari;
realizarea unui top al celor mai vndute produse, al celor mai solicitai
furnizori sau al celor mai fideli clieni;
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

66
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.

BILIOGRAFIE

Publicaii i cursuri:
1. S. Buraga, Tendine actuale n proiectarea i dezvoltarea aplicaiilor Web, Iai,

26-27 noiembrie 2005

2. V. Cotelea, "Baze de date relaionale proiectare logic". Chiinu, Editura ASEM, 1997;

3. P.BuBois, MySQL, Ed. Teora, Bucureti, 2001

4.C.Raiu-Suciu, Modelarea i Simularea proceselor economice, Editura Economic,Bucureti, 2003

5. S. Buraga , Aplicaii Web la cheie, Ed. Polirom, Iai, 2003

6. Welling, L. Thomson, Dezvoltarea Aplicaiilor Web cu PHP i MySQL, Editura Teora, Bucureti,

67
 2003

7. V. Cotelea: "Modele i algoritmi de proiectare logic a bazelor de date", 2009

Legislaie:

Legea Nr.284/ 22.07.2004, privind comerul electronic

Legea Nr.264- XV din 15.07.2004, cu privire la documentul electronic i semntura digital

Legea Nr. 139 din 02.07.2010, privind dreptul de autor i drepturile conexe

Resurse Web:
www.afaceri.net/articole/Webdesign/Promovare/Razboiul_cu_motoarele_de_cautare.htm
http://inf.ucv.ro/~giurca/courses/CB3105/resources/Modelarea%20Dinamica.pdf
www.MySQL.com
www.php.net
www.underclick.ro
www.hotnews.ro/articol_25442-Afaceri-on-line-tendinte-si-greseli.htm
www.business-online.ro/VersiuneaRomana/Internet&Afaceri.html
http://www.iafaceri.md/index.php?l=ro

68