Sunteți pe pagina 1din 70

ACADEMIA DE STUDII ECONOMICE DIN MOLODVA

FACULTATEA Cibernetică, Statistică și Informatică Economică

Catedra Cibernetică şi Informatică Economică

Babuci Livia

TEZĂ DE LICENŢĂ
Tema: “Proiectarea aplicațiilor de comerț electronic”

Executor: studenta gr. INF 281,


Babuci Livia
Conducător ştiinţific: lector superior,
Covalenco Ion
Chișinau 2011
CUPRINS
INTRODUCERE..................................................................................................................2

CAPITOLUL I
CONCEPTE GENERALE PRIVIND COMERȚUL ELECTRONIC........................4
1.1. Noua economie. Revoluția Internet............................................................................4
1.2. Afaceri electronice. Comerț electronic.......................................................................5
1.3 Avantajele și dezavantajele comerțului electronic.......................................................8
1.4. Aspecte nefavorabile privind dezvoltarea comerțului electronic...............................10
1.5. Descrierea social economică a unității.......................................................................11

CAPITOLUL II
DEZVOLTAREA UNUI SISTEM DE COMERȚ ELECTRONIC...............................12
2.1. Arhitectura unui sistem de comerț electronic...........................................................12
2.2. Etapele implementării unui sistem de comerț electronic..........................................12
2.3. Sistem Electronic de Plăți.........................................................................................18
2.4. Arhitectura aplicației(client/server)..........................................................................20
2.5. Tehnologii și instrumente informatice utilizate în proiectarea aplicației.................22
2.5.1. Limbajul de modelare......................................................................................22
2.5.2. Procesul............................................................................................................24
2.5.3. Justificarea soluției Apache+PHP+MySQL.....................................................25

CAPITOLUL III
DEZVOLTAREA APLICAȚIEI.........................................................................................31
3.1. Determinarea cerințelor unei aplicații de food-ordering............................................31
3.1.1. Cerințele beneficiarilor aplicației de food- ordering........................................31
3.1.2. Delimitarea comportamentului aplicației (cazuri de utilizare).........................37
3.2. Proiectarea aplicației....................................................................................................41
3.3. Designul fizic al aplicației...........................................................................................46
3.4. Implementarea aplicației.............................................................................................52

CAPITOLUL IV
DESCRIEREA EFICIENȚEI ECONOMICE UTILIZÎND METODA SIMULĂRII
PROCESELOR....................................................................................................................57
5.1. Aspecte generale privind modelarea și simularea proceselor economice..................57
5.2. Estimarea succesului aplicației...................................................................................59
5.3. Interpretarea rezultatelor.............................................................................................65

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

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

2
INTRODUCERE
Progresele realizate recent în domeniile tehnologie-calculatoare, telecomunicaţii şi
software, precum şi în alte domenii ale informaţiei, au schimbat radical modul de viaţă al
populaţiei globului într-o manieră care ar fi fost greu de estimat în urmă cu 20 de ani. Pe
fundalul acestor transformări s-a realizat trecerea de la era industrială la cea informaţională.
În noua societate, rezultată în urma acestor transformări, prelucrarea informaţiilor,
dobândirea de cunoştinţe cu ajutorul calculatorului, comunicarea şi dezvoltarea afacerilor
cu ajutorul Internetului au devenit posibile pretutindeni şi în orice moment, fără depunerea
unui efort considerabil. Aceste transformări au avut un impact foarte mare asupra tuturor
domeniilor de activitate.
Una dintre caracteristicile importante ale Internetului – menţionată de susţinătorii
ideii că acesta va deveni motorul prosperităţii viitoare – este aceea că după ce, la
început, impactul său s-a manifestat numai în sectorul „tehnologiilor înalte” (high-tech),
treptat se face simţit în toate industriile şi serviciile.
Explozia Internetului, apariţia şi dezvoltarea economiei Internet şi deci a conceptelor
de afaceri electronice şi în particular comerţ electronic au produs modificări semnificative
în peisajul economic mondial. În aceste condiţii proiectarea, implementarea şi realizarea
unei afaceri electronice este o consecinţă naturală, impusă atât de mediul economic, prin
necesitatea transformării stilului de a face afaceri, cât şi de cel tehnologic.
Afacerile electronice transformă radical relaţiile şi procesele de afaceri, făcându-le
mai uşor de gestionat şi facilitând, prin intermediul Internetului, o reacţie mai rapidă la
cerinţele clienţilor şi tendinţele pieţei.
Obiectivele principale ale unei aplicaţii de comerţ electronic ar trebui să vizeze
creşterea eficienţei economice a afacerii dezvoltate prin reducerea consumului de timp şi
resurse, creşterea vitezei de comunicare a informaţiilor, oferirea unei interfeţe prietenoase

3
care să faciliteze schimbul de informaţii dintre diversele categorii de utilizatori ai aplicaţiei
(cumpărători şi furnizori).
Lucrarea de faţă îşi propune prezentarea fundamentărilor economice şi a paşilor care
ar trebui urmaţi în dezvoltarea unei aplicaţii de comerţ electronic în general, respectiv a unei
aplicaţii de food-ordering în particular. Prin aplicaţie de food-ordering se înţelege o
aplicaţie bazată pe tehnologia client/server, menită să faciliteze efectuarea comenzilor on-
line de preparate culinare de la furnizori care asigură livrări la domiciliu.
Aplicaţia de food-ordering are la bază o arhitectură pe trei nivele: nivelul de
prezentare, nivelul de logică a aplicaţiei (de business) şi nivelul de date. Am ales această
structurare datorită avantajului major pe care îl prezintă faţă de o arhitectură
client/server tradiţională (pe două nivele), şi anume acela că majoritatea procesărilor se
fac pe serverul de aplicaţie şi pe baza de date, nu pe calculatorul client şi pe baza de
date, ceea ce permite o scalabilitate mult mai bună a aplicaţiei în condiţiile unui volum
de tranzacţii în creştere (este necesară doar adăugarea de servere suplimentare pentru
creşterea capacităţii de procesare).
În dezvoltarea şi implementarea aplicaţiei am optat pentru avantajele oferite de
triada Apache + MySQL + PHP.
În contextul actual al mediului Web, Apache satisface cerinţele unui server HTTP
prin securitate sporită, eficienţă în funcţionare, gratuitate şi o structură modulară care
permite extensia funcţionalităţii acestuia. Această ultimă caracteristică permite
configurarea PHP-ului ca şi modul al serverului, crescându-se astfel rapiditatea triadei.
În ceea ce priveşte limitele lucrării de faţă, precizez că aplicaţia prezentată nu îşi
propune să implementeze un sistem electronic de plăţi, acest lucru putând fi luat în
considerare la o dezvoltare ulterioară. De asemenea, lucrarea îşi propune să insiste asupra
aspectelor legate de proiectarea aplicaţiei şi asupra funcţionalităţii oferite de aceasta, lăsând
într-un plan secundar aspectele legate de design, testarea sau promovarea aplicaţiei, acestea
putând fi aprofundate în etapele ulterioare de dezvoltare.

4
CAPITOLUL I
CONCEPTE GENERALE PRIVIND COMERŢUL ELECTRONIC
1.1. Noua economie. Revoluţia Internet

Societatea spre care ne îndreptăm este sau va fi Societatea Informaţională –


Societatea Cunoaşterii. Acestei societăţi î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 următoarele:
■ dezvoltarea accelerată a comunicaţiilor avansate;
■ „explozia” Internet;
■ dezvoltarea comerţului electronic;
■ apariţia 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 menţionat faptul că noua economie se bazează pe trei principii definitorii:
■ acces (şi răspuns) instantaneu;
■ servicii personalizate;
■ prezenţa simultană în mai multe locuri (ubicuitate).
Informaţia este resursa principală în noua economie şi de aceea suportul şi nucleul
acesteia sunt tehnologiile informaţionale şi comunicaţiile avansate, iar motorul ei este

5
Internetul. De aceea se spune că noua economie este o economie a tuturor tipurilor de
afaceri construite în jurul Internetului.
Internetul are un rol cheie în furnizarea de informaţii privind disponibilitatea de
produse şi servicii şi preţurile acestora în toată economia. Noile tehnologii Internet
contribuie direct la expansiunea comerţului 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 creşterea fără precedent a ofertei
furnizorilor, a competiţiei globale şi a exigenţei clienţilor. Firmele din toate sectoarele
economice au început să adopte noua paradigmă economică – orientarea către „e-
business” sau noile modele de afaceri.
„E-business-ul” poate fi definit ca transformarea proceselor (operaţiilor,
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 porneşte o afacere on-line. Noul model de afaceri se realizează sub forma unui
lanţ de servicii electronice, compus din:
• furnizorul de produse sau servicii căutate;
• furnizorul de servicii Internet care poate oferi orice, de la spaţiu pe web, la
integrarea de e-mall şi la diferite tipuri de servicii;
• clientul, cu o anumită profesie, interese personale şi preferinţe; acest client
poate fi un consumator (B2C), o altă afacere (B2B), o administraţie 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) interacţionează asupra datelor şi tranzacţiilor unei

6
întreprinderi. În caz particular se poate aplica la o întreprindere care oferă
servicii sau bunuri care nu pot fi prezentate şi vândute prin catalog. Poate fi
văzut ca acoperind toate interacţiunile 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 vândute


printr-un catalog folosind un card de cumpărări, un portofel, etc. Acest model
include ambele cazuri de consumatori: care cumpără bunuri şi care se
aprovizionează de la un singur furnizor. Poate cuprinde legături cu sisteme de
gestiune, de verificare de cărţi de credit, de livrare etc.
3. Modelul Business-to-Business (B2B): Este folosit pentru a descrie două tipuri

de interacţiune între două întreprinderi:


a. tipul (B2Bi) – este cazul în care există un contract de parteneriat între

întreprinderi, un exemplu în acest sens fiind o aplicaţie pentru un lanţ de


desfacere;
b. tipul (B2M2B) – este cazul unui e-MarketPlace, deci existenţa unei pieţe

electronice în care interacţionează mai mulţi cumpărători şi mai mulţi


furnizori.
4. Modelul User-to-User (U2U): Descrie cazul colaborării diferiţilor utilizatori

prin intermediul documentelor partajate, prin e-mail, etc.


5. Modelul User-to-Data (U2D): Descrie cazul în care utilizatorii au nevoie de

cantităţi însemnate de date, text, imagini, etc. şi folosesc diverse instrumente


pentru a extrage informaţii.
6. Modelul Application Integration: Este folosit pentru integrarea diverselor

aplicaţii într-o soluţie de afacere, şi poate fi utilizat atât în cadrul unui singur
tip de afacere, cât şi între mai multe tipuri de afacere.

7
Comerţul electronic se referă la desfăşurarea activităţilor specifice mediului de
afaceri (tranzacţii) într-un sistem automatizat integrat pentru schimbul de informaţii
utilizând mijloace electronice (reţele de calculatoare).
O definiţie posibilă a Comerţului Electronic ar fi : „orice formă de tranzacţii în
afaceri în cadrul căreia părţile interacţionează electronic în loc de realizarea de
schimburi fizice sau contact fizic direct”.
În comerţul electronic informaţia circulă între agenţii implicaţi în afacere
(vânzător, cumpărător, bancă, transportator, agent de service), fără a utiliza suportul de
hârtie (imprimantă sau fax).
În cazul comerţului electronic, se întâlnesc aceleaşi componente ca şi în cazul
comerţului clasic, dar cu modificări specifice, şi anume:
• un produs - material sau digital;
• un loc de vânzare - în acest caz un website în reţea 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 plăţi prin card de
credit. Aceasta cere o pagină sigură pentru comenzi şi conexiunea la o bancă,
dar se poate folosi şi metoda clasică a facturării, on-line sau prin poştă;
• o modalitate de livrare; dacă marfa este de tip software sau informaţie,
livrarea se poate face direct prin reţea;
• o modalitate de a accepta returnări (formulare on-line);
• o modalitate de a accepta eventuale reclamaţii (formulare on-line);
• o modalitate de a oferi service (prin email, formulare on-line, baze de
cunoştinţe on-line etc.);
În afacerile tradiţionale vânzarea este încă văzută şi organizată ca fiind
subordonată producţiei, sau „vindem ce producem”. În e-commerce, firmele vând „ce

8
pot livra” deoarece oferă consumatorului o gamă largă de produse, indiferent cine le
produce.

1.3.Avantajele şi dezavantajele comerţului electronic

Principiile de bază ale unei afaceri electronice sunt aceleaşi ca la orice afacere
tradiţională, desfăşurată în mediul economic real: avem de-a face cu un public ţintă şi un
produs sau serviciu oferit spre vânzare. Diferenţa majoră în cazul afacerilor electronice
constă în faptul că acestea permit automatizarea proceselor de vânzare şi cumpărare.
Într-un magazin normal există angajaţi 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 săptămână, pe parcursul întregului an, fără nici un fel de întrerupere, şi
toate acestea în vederea maximizării profitului afacerii.
Din poziţia cumpărătorului, avantajele comerţului electronic sunt legate de:
■ timp: cumpărătorul poate vizita mai multe magazine virtuale într-un timp
foarte scurt (mult mai scurt decât timpul pe care îl implică prezenţa fizică a
unei persoane într-un magazin real);
■ libertatea de a alege: datorită numărului mare de magazine pe care clientul
le poate vizita, acesta va avea posibilitatea de a alege un produs în funcţie de
un număr mult mai mare de opţiuni (preţ, data livrării, etc.).
Din punctul de vedere al companiilor ce utilizează comerţul electronic, se disting
următoarele avantaje:
■ creşterea semnificativă a vitezei de comunicare, în special pentru
comunicaţiile internaţionale: mai multe companii pot stabili o platformă de
colaborare, prin intermediul căreia să poată concepe şi dezvolta diverse
produse împreună; comunicarea prin telefon sau fax ar însemna o încetinire
drastică a acestor procese de concepţie sau dezvoltare;

9
■ reducerea unor costuri: de exemplu, utilizând e-mail (poşta electronică) se
reduc costurile cu poşta sau mesageria, dar şi costurile referitoare la deplasarea
documentelor (circa 7% din cheltuielile făcute cu comerţul tradiţional se
datorează deplasării documentelor);
■ întărirea relaţiilor cu furnizorii şi clienţii: printr-un site Web, clienţii
companiei vor fi puşi la curent cu ultimele produse apărute, li se va oferi
suport tehnic pentru produsele cumpărate, putând chiar să ofere sugestii pentru
eventuale îmbunătăţiri ale produselor, serviciilor etc.; pe unele site-uri
cumpărătorii 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 rândul lor ultimele
noutăţi;
■ existenţa unei căi rapide şi comode de furnizare a informaţiilor despre
companie: prin intermediul unor site-uri Web, a intranet-urilor şi a extranet-
urilor;
■ canale alternative de vânzare: desfăşurarea afacerilor prin intermediul unui
astfel de site.
Deşi pare o afacere de vis, există totuşi câteva greşeli majore care ar putea-o
transforma într-un coşmar:
■ lipsa unui plan de acţiune: antreprenorii se lasă ghidaţi doar de entuziasm;
■ estimarea eronată a investiţilor: se porneşte de la ideea falsă că pentru o
afacere electronică, de tipul comerţ electronic, investiţiile trebuie să fie
întotdeauna foarte mici;
■ neglijarea aspectelor concurenţiale: ideea că o afacere electronică trebuie să
aibă ca principal avantaj competitiv preţul mic al produselor;
■ neglijarea aspectelor de promovare a produselor: accentul se pune mai mult
pe vânzări, decât pe strategia de marketing.

10
1.4.Aspecte nefavorabile privind dezvoltarea comerţului electronic

Există şase piedici majore care frânează dezvoltarea comerţului electronic:


■ securitatea: Internetul a fost conceput ca un mediu deschis, dar nu neapărat
şi sigur, protocolului TCP/IP (care stă la baza comerţului electronic) lipsindu-
i servicii de securitate de bază. Un element de bază pentru securitatea
comerţului prin Internet îl constituie criptarea, care permite atât autentificarea,
cât mai ales siguranţa transmisiei informaţiilor;
■ acceptarea noilor modalităţi 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 urmăririi (trace) tranzacţiilor. Un sistem
electronic, care realizează înregistrarea tuturor tranzacţiilor care se fac
în ciberspaţiu, prezintă dezavantajul că tot ceea ce faci este înregistrat;
■existenţa unei infrastructuri de telecomunicaţii adecvate: pe măsură ce
tehnologia avansează, apar noi metode de comunicaţie celulare;
■ costurile investiţiei: de exemplu, un comerciant care vrea să ofere un
magazin pe Internet, va face următoarele investiţii: servere (calculatoare
puternice care să poată evolua odată cu creşterea volumului tranzacţiilor),
tehnologie de comunicaţii (care să poată creşte odată cu creşterea 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 proprietăţii intelectuale, protecţia datelor consumatorului;

11
■ aspecte lingvistice şi culturale: reţeaua Web tinde să devină din ce în ce mai
mult un „turn Babel” al naţiunilor, pe măsura adoptării pe scară din ce în ce
mai largă a tehnologiilor legate de Internet.

1.5. Descrierea social economică a unității


Primul pas în dezvoltarea aplicaţiei îl reprezintă stabilirea potenţialilor beneficiari,
precum şi a aşteptărilor acestora în ceea ce priveşte funcţionalitatea aplicaţiei. Printr-o
analiză atentă a cerinţelor beneficiarilor se va delimita comportamentul aplicaţiei ce
urmează a fi implementată.
Tehnica folosită în stabilirea cerinţelor beneficiarilor presupune efectuarea unui
studiu al pieţei aplicaţiilor care oferă servicii similare (de exemplu: Andy’S Pizza, La
Plăcinte, Foișor) care să suplinească, pe cât posibil, neajunsurile acestora. Deoarece
aplicația dată este una de food ordering (ceea ce ține de comandări on-line a
preparatelor culinare), am încercat să o dezvolt în așa mod, încît cu unele modificări
(ușoare) a bazei de date și a unor aspecte ce țin de interfață, să fie posibil utilizarea ei și
de către alte firme. Datorită flexibilității triadei Apache+My SQL+ PHP acest lucru este
foarte usor de executat.
În cadrul lucrării de faţă, plecând 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.

12
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)
corespunzătoare următoarelor roluri:
a) Client: un echipament clasic, un PC, conectat direct (via un ISP) sau indirect (o

reţea a unei corporaţii) la Internet. Cumpărătorul foloseşte acest echipament


pentru a naviga şi a face cumpărături.
b) Comerciant: sistem informatic (hard & soft), situat de regulă la sediul

comerciantului, care găzduieşte şi actualizează catalogul electronic de produse


disponibile a fi comandate on-line pe Internet.
c) Sistemul tranzacţional: sistemul informatic (hard & soft) responsabil cu

procesarea comenzilor, iniţierea plăţilor, evidenţa înregistrărilor şi a altor


aspecte de business implicate în procesul de tranzacţionare.
d) Dispecer plăţi (Payment Gateway): sistem informatic responsabil cu rutarea

instrucţiunilor de plată în interiorul reţelelor financiar-bancare, cu verificarea


cărţilor de credit şi autorizarea plăţilor; acest sistem joacă rolul unei porţi care
face legătura dintre reţeaua globală Internet şi subreţeaua financiar-bancară
(supusă unor cerinţe de securitate sporite).

2.2. Etapele implementării unui sistem de comerţ electronic

13
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
Această etapă este la rândul său împărţită în patru paşi: proiectarea, dezvoltarea,
găzduirea, promovarea şi optimizarea site-ului.
Proiectarea site-ului
Înainte de a trece la crearea efectivă a unui site de comerţ electronic, compania
care va deţine acest site trebuie să poată da un răspuns la următoarele întrebări:
■ Ce tipuri de produse vinde site-ul?
■ Ce tipuri de informaţii va găzdui?
Răspunsurile la aceste întrebări vor determina domeniile din care va fi alcătuit site-ul.
De exemplu, respectiva companie poate vinde produse care vor fi livrate clienţilor prin
poştă, produse software care vor fi încărcate direct de pe site, sau ambele categorii de
produse. În cazul în care se doreşte vânzarea ambelor tipuri de produse, se vor construi
domenii specifice fiecărui tip în parte. Un alt exemplu l-ar constitui construirea unui
domeniu dedicat discuţiilor on-line: o companie poate decide să ofere clienţilor un
forum de discuţii 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 mulţi, pentru situaţiile neprevăzute în care unul dintre
administratori este indisponibil.
■ Care este tipul de interfaţă pe care doriţi să îl propuneţi clienţilor?
În timp ce răspunsurile la primele două întrebări rezolvau în principal probleme legate
de structura internă a site-ului, răspunsul la această întrebare va determina aspectul

14
său exterior. Trebuie să se stabilească ce imagini vor fi prezentate în cadrul paginilor (de
exemplu logo-ul companiei), culorile folosite în cadrul paginilor (ar putea fi culorile din
logo), stilul de adresare, etc.

Dezvoltarea site-ului
După ce s-au stabilit toate detaliile de la punctul precedent, urmează o altă etapă la
fel de importantă: determinarea cerinţelor necesare pentru dezvoltarea site-ului.
Cerinţele se referă atât la hardware-ul şi software-ul necesar pentru implementarea
sistemului de comerţ electronic, cât şi la infrastructura de comunicaţii:
■ cerinţe hard: caracteristicile maşinilor folosite ca server (memorie, spaţiu pe
hard-disk, viteză procesor, etc.)
■ cerinţe soft: sistem de operare, server de Web, firewall, pachete de programe
opţionale (programe de calcul al taxelor, etc.)
■ comunicaţii: se referă la lărgimea bandei de comunicaţie, topologia de reţea,
etc.
În urma completării acestei etape, se va determina mai mult de 80% din costul pe
care îl implică realizarea unui site de comerţ electronic.
Găzduirea site-ului
Site-ul de comerţ electronic poate fi găzduit pe un sistem care aparţine clientului,
dar există de asemenea posibilitatea închirierii de spaţiu pe server-ele furnizorului de
servicii Internet. Soluţia cea mai ieftină se obţine î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 „Construieşte-l şi vor veni” nu este valabilă nici pentru site-urile
tradiţionale, aşa cum s-a spus multă vreme, şi nici pentru magazinele virtuale. Strategiile

15
de marketing şi publicitate sunt absolut necesare pentru a obţine succesul dorit pe
Internet.
Printre modalităţile de promovare pe care o organizaţie virtuală le poate folosi în
cadrul strategiei de promovare, se numără:
■ Promovarea în reţea: Anunţurile publicitare de pe motoarele de căutare sau de
pe site-uri, au ca obiectiv principal atragerea publicului ţintă, astfel încât acesta să
viziteze site-ul. Prima etapă o constituie crearea de bannere, apoi studierea
aspectelor demografice a diverselor site-uri pentru a fi găsite cele mai potrivite,
după care se recurge la negocierea costurilor.
■ Promovarea în media tradiţională: Multe firme îşi afişează adresa URL în
secţiuni speciale ale ziarelor cotidiene, ale publicaţiilor de afaceri şi ale mediei
comerciale. Chiar şi reclamele TV conţin adrese de Web. Concluzia ar fi că este
necesară tipărirea URL-ului pe toate materialele de comunicare şi de marketing.
■ Promovare încrucişată 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ă clienţii
către site-ul celuilalt. Acest lucru se poate realiza prin acordarea unei reduceri la
produsele prezentate pe unul din site-uri la fiecare achiziţie de produse
complementare prezentate pe celălalt site.
■ Plătirea de comisioane altor site-uri pentru a oferi referinţe vizitatorilor şi
pentru a-i direcţiona spre site-ul promovat: Dacă un site complementar a reuşit să
atragă un număr mare de cumpărători, aceştia pot fi dirijaţi către site-ul respectiv
dacă se plăteşte pentru plasarea unei legături sau a unui anunţ publicitar pe site-ul
complementar. Preţurile pentru acest tip de serviciu sunt foarte elastice.
■ Oferta de produse gratuite: Atragerea vizitatorilor şi satisfacerea acestora se
transmite informal şi către alţii. Oamenii pot fi atraşi către site prin simplu fapt că
li se oferă mostre sau informaţii gratuite.

16
Etapa a II-a: Managementul bazelor de date
Produsele şi serviciile pe care site-ul de comerţ electronic le oferă spre vânzare
clienţilor, indiferent de modul în care vor fi livrate (prin poştă sau direct prin Internet),
vor fi stocate în cadrul site-ului în baze de date. Tot în baze de date (dar nu în cadrul
aceloraşi baze de date ca şi produsele) vor fi stocate şi comenzile pe care clienţii le
adresează către site. Aceste comenzi pot fi păstrate chiar şi după onorarea lor, pentru
a oferi clienţilor un istoric al produselor pe care le-au comandat sau pentru studii de
piaţă efectuate chiar de către compania ce deţine site-ul.
Este foarte importantă alegerea SGBD-ului (Sistemului de Gestiune a Bazelor de
Date), cel puţin din următoarele motive:
■ pe măsură ce afacerea va creşte, creşte şi numărul de produse oferite spre
vânzare, şi, implicit, dimensiunea site-ului (a bazelor de date care
corespund domeniilor din care este alcătuit site-ul); rezultă deci necesitatea
stringentă ca bazele de date să fie scalabile (să poată fi posibilă creşterea
dimensiunii lor);
■ pentru baze de date de dimensiuni foarte mari, este importantă problema
vitezei de acces la informaţiile stocate în aceste baze de date. Dacă motorul de
căutare în cadrul bazelor de date nu este foarte performant, atunci, chiar şi
pentru cel mai simplu acces la informaţiile din bază, timpul de căutare poate fi
extrem de redus.

Etapa a III-a: Plata şi procesarea tranzacţiilor


Autorizările sigure de cărţi de credit şi procesarea comenzilor prin Internet sunt
elemente de bază. Pentru a realiza în deplină siguranţă un transfer care implică numere
de cărţi de credit prin Internet, este nevoie să se ia măsuri de securitate referitoare la
autorizarea plăţilor. Informaţiile referitoare la cărţile de credit (numărul cărţii, nume

17
deţinător, telefon, etc.), care sunt transmise în momentul efectuării plăţii trebuie validate
de către un organism de autorizare. De aceea, companiile care doresc să
accepte efectuarea plăţilor prin Internet prin cărţi de credit trebuie să ia legătura cu un
astfel de organism. Aceasta, la rândul lui, se află în legătură cu instituţia financiară care
a eliberat cartea de credit, şi, după un schimb de mesaje criptate cu respectiva instituţie,
va aviza sau nu transferul de fonduri. Dacă primeşte acceptul din partea organismului,
vânzătorul va efectua livrarea produselor către client şi va înregistra comanda ca fiind
onorată. Suma plătită de client pentru aceste produse va fi adăugată la contul
vânzătorului.

Etapa a IV-a: Managementul produselor şi al comenzilor


Transportul produselor: În cazul în care site-ul de comerţ electronic al companiei
oferă spre vânzare clienţilor produse care se livrează prin poştă, compania trebuie să ia
în considerare necesitatea de a stabili o colaborare cu un serviciu de distribuţie prin
poştă. În funcţie de serviciul de poştă ales, compania poate să pună la
dispoziţia clienţilor servicii suplimentare, cum ar fi urmărirea on-line a traseului pe care
îl parcurg produsele din momentul plecării de la vânzător şi până în momentul sosirii la
client.
Urmărirea comenzilor şi a stării acestora: În cadrul site-ului de comerţ electronic
există persoane care se ocupă cu monitorizarea comenzilor, în cazul în care compania
care deţine site-ul a hotărât astfel. O comanda se poate găsi în trei stări:
■ capturat: comanda a fost preluată de către sistemul vânzătorului, însă
metoda de plată aleasă de către client nu a fost încă validată;
■ reglat: autoritatea care se ocupă de autorizarea plăţilor a dat vânzătorului un
răspuns pozitiv referitor la certificarea metodei de plată a clientului;
■ respins: comanda este respinsă, întrucât nu a fost autorizată metoda de plată
a clientului.

18
Etapa a V-a: Centru specializat de servicii
Suport post-vânzări prin Internet: Compania poate decide să ofere suport tehnic
clienţilor pentru produsele pe care aceştia le-au cumpărat de pe site. În acest scop, pe
site poate exista un domeniu separat, dedicat întrebărilor şi răspunsurilor, unde clienţilor
care întâmpină probleme să li se poată răspunde de către personalul tehnic al companiei.
Chiar mai mult, în cadrul site-ului, poate exista un forum de discuţii on-line, cu
moderator sau nu, în cadrul căruia clienţii să îşi poată împărtăşi între ei experienţa
acumulată în folosirea produselor respective. Dacă nu se doreşte adoptarea nici uneia
dintre soluţiile propuse, trebuie să ne asigurăm că există măcar o legătură prin care
clienţii să poată trimite un mesaj prin poşta electronică administratorului site-ului.

2.3. Sistem Electronic de Plăţi

Arhitectura unui Sistem Electronic de Plăţi (SEP)


Un sistem electronic de plăţi se referă la totalitatea obiectelor care conlucrează
pentru asigurarea plăţii tranzacţiilor 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 mulţimea utilizatorilor şi a tranzacţiilor care au
loc între aceştia. Utilizatorii sunt grupaţi după diverse roluri, după modul în
care interacţionează în relaţiile de afaceri dintre ei: cumpărătorul, vânzătorul,
emitentul de bani electronici (banca), etc.;
■ nivelul sistem: constă din mulţimea entităţilor fizice şi a relaţiilor care se
stabilesc între ele. Entităţile pot juca unul dintre următoarele roluri: purtător de
bani electronici sau registru de casă.

19
Tipuri de tranzacţii într-un Sistem Electronic de Plăţi
Tranzacţiile reprezintă schimburile de mesaje, sub forma unor protocoale, care se
desfăşoară între entităţile care joacă diverse roluri într-un Sistem Electronic de Plăţi.
Exemple de tranzacţii:
■ tranzacţia 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 tranzacţiei;
■ tranzacţia de obţinere a unui certificat: toate cheile publice folosite într-un
SEP sunt certificate de către unul sau mai multe centre de certificare. Astfel:
informaţii specifice utilizatorului (credite) + cheie publică a utilizatorului +
cheie secretă a centrului duc la obţinerea unui certificat. În general,
certificatele au o perioadă de valabilitate redusă;
■ tranzacţia de control al accesului: furnizează protecţie împotriva folosirii
neautorizate a unor entităţi la nivelul sistem; poate folosi şi în operaţii
de monitorizare (de exemplu, când un utilizator doreşte să afle suma pe care o
deţine în cont);
■ tranzacţia de încărcare: se desfăşoară între bancă şi distribuitor, după o
autentificare mutuală prealabilă;
■ tranzacţia de retragere: se desfăşoară între distribuitor şi cumpărător, tot după
autentificarea mutuală prealabilă;
■ tranzacţia de plată: se desfăşoară între vânzător şi cumpărător; poate fi off-
line sau on-line. La cele on-line, este implicată şi banca;
■ tranzacţia de anulare: se referă la ultima tranzacţie de plată între cumpărător
şi vânzător;

20
■ tranzacţia de depunere: implică vânzătorul şi colectorul;
■ tranzacţia de clearing: se desfăşoară între colector şi bancă sau între două
bănci.

2.4. Arhitectura aplicației. Arhitectura Client/Server

Problema proiectării aplicaţiilor a suferit de-a lungul timpului multe modificări şi


a dus la apariţia unor probleme de programare. Una dintre cele mai răspândite la ora
actuală este programarea client/server.
Arhitectura unei aplicaţii client/server este fundamentată pe principiul separării
aplicaţiei în module independente care pot fi executate în spaţii de memorie diferite. În
acest tip de arhitectură, modulul care face interogările joacă rolul de „client” (cel care
cere un anumit serviciu), iar modulul care este interogat devine „server” (cel care
satisface acel serviciu).
Deşi interacţiunea între cele două module se poate desfăşura în cadrul aceluiaşi
calculator (ceea ce ne duce cu gândul la o asemănare cu programarea structurată),
raportată la o reţea, arhitectura oferă o modalitate convenabilă de interconectare a
serviciilor distribuite eficient în reţea. Astfel, clientul şi server-ul sunt, de regulă, două
calculatore diferite în cadrul aceleiaşi reţele. Mai mult, oricare din calculatoarele reţelei
poate acţiona atât ca şi client, cât şi ca server, pe principiul conform căruia orice
calculator din reţea reprezintă un potenţial ofertant de resurse (informaţii sau servicii).

Fig. 2.1. Arhitectura generică client/server

21
În acest tip de arhitectură a fost înlocuit serverul de fişiere cu serverul de baze de
date. Toate datele sunt reţinute î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 reţea, deoarece comunicarea client/server se reduce la
comunicarea cerinţelor în format cât mai simplu din partea clientului (de ex. o comandă
SQL) şi respectiv comunicarea doar a rezultatelor din partea server-ului.
Ca reguli de funcţionare a unei relaţii client/server trebuie subliniate:
■ serverul comunică cu clientul după un protocol dinainte stabilit;
■ un server trebuie să fie capabil să deservească mai mulţi clienţi;
■ serverul trebuie să fie găsit de către client la aceeaşi adresă;
■ clienţii pot lansa cererile de oriunde din reţea;
■ serverul răspunde cererilor pentru resurse făcute de clienţi într-un mod
transparent relativ la locaţia, managementul sau distribuţia resurselor;
■ serverul funcţionează ca o interfaţă de acces la anumite resurse;
Următoarea diagramă pe 4 nivele detaliază arhitectura unei aplicaţii generice
client/sever:
Fig. 2.2. Arhitectura unei aplicaţii client/server generice

Server
Server
Server de
de aplicaţie
aplicaţie

Interfaţa
Interfaţa aplicaţiei
aplicaţiei

Regulile
Regulile de
de „business”
„business”

Preluarea
Preluarea informaţiilor
informaţiilor

Client

22
■ la nivelul de preluare a informaţiilor 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 necesităţilor de utilizare;
■ 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 stabileşte corectitudinea datelor venite de la client şi necesare serverului, sau
invers;
■ interfaţa aplicaţiei este nivelul care răspunde de transformarea datelor din formatul
transmis de client în formatul necesar serverului pentru a putea da un răspuns
clientului; ca să luăm un exemplu, această etapă va transpune cererea clientului într-o
instrucţiune SQL pe care o va transmite etapei finale;
■ serverul de aplicaţie este nivelul final, acela de procesare a datelor şi de obţinere a
rezultatelor cerute de client;
Aplicaţiile client/server sunt structurate pe patru nivele. Cum se împarte aplicaţia
între client şi server, cu alte cuvinte care nivel va fi situat pe partea de client a aplicaţiei
şi care va fi situat pe partea de server, rămâne la latitudinea dezvoltatorului.

2.5. Tehnologii şi instrumente informatice utilizate în proiectarea aplicaţiei

Componentele necesare în activitatea de proiectare a unei aplicaţii de succes sunt:


notaţia (limbajul de modelare), procesul şi instrumentul. Aceste trei componente
formează „triunghiul de succes” care stă (sau ar trebui să stea) la baza proiectării oricărei
aplicaţii. Cele trei componente se află într-o relaţie de interdependenţă, omiterea uneia
dintre ele putând cauza eşecul procesului de proiectare a aplicaţiei.

2.5.1.Limbajul de modelare

23
Notaţia (limbajul de modelare) reprezintă unul din punctele cheie ale oricărui
model, jucând rolul de liant între părţile componente ale procesului. Cele trei roluri de
bază ale notaţiei în cadrul activităţii de proiectare a unei aplicaţii sunt:
■ joacă rolul unui limbaj cu ajutorul căruia sunt comunicate deciziile care nu
sunt evidente sau care nu pot fi deduse din partea de cod;
■ oferă o semantică suficient de bogată încât să permită capturarea tuturor
deciziilor strategice şi tactice importante;
■ oferă un limbaj suficient de bogat pentru a permite oamenilor să raţioneze 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 „schiţe 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 cărui valoare constă în:
■ standardul său deschis;
■ acoperă întreg ciclul de viaţă al dezvoltării unui soft;
■ se bazează pe experienţa celor care l-au dezvoltat;
■ este implementat de multe produse de tip CASE.
Având în vedere că este un limbaj de modelare vizuală ce foloseşte notaţii
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;

24
■ defineşte arhitectura aplicaţiei;
■ permite reutilizarea componentelor.
Elementele de bază ale UML-ului sunt reprezentate de:
■ blocurile constructive: elemente, relaţii şi diagrame;
■ regulile ce dictează modul în care blocurile pot fi combinate;
■mecanismele generale: specificaţii, ornamente, diviziuni generale,
mecanisme de extensie.

2.5.2. Procesul
Un proiect care urmăreşte dezvoltarea unei aplicaţii software poate fi considerat
de succes dacă îndeplineşte următoarele condiţii:
■ satisface sau chiar depăşeşte nevoile utilizatorilor;
■ face economie de timp şi resurse;
■ produsul rezultat este adaptabil la diversele modificări care ar putea să apară;
■ ciclul de viaţă al dezvoltării produsului promovează creativitatea şi inovaţia,
putând în acelaşi timp fi controlat, astfel încât să ofere certitudinea că produsul
rezultat este complet.
În etapa de demarare a unui proiect de dezvoltare de soft este esenţial să se
stabilească procesul ce va fi urmat. Acesta descrie efectiv paşii care trebuie urmaţi în
vederea dezvoltării cu succes a unei aplicaţii.
Procesul de dezvoltare a unei aplicaţii este structurat pe două domenii
(dimensiuni), şi anume:
■ dimensiunea temporală: diviziunea ciclului de viaţă în faze şi iteraţii;
■ componentele procesului: producerea unei mulţimi specifice de elemente
(artefacte) cu activităţi bine definite.
Structurarea unui proces în funcţie de dimensiunea temporală induce următoarele
faze:

25
■ lansarea – specificarea succintă a proiectului;
■ elaborarea – planificarea activităţilor şi resurselor necesare; specificarea
caracteristicilor şi proiectarea arhitecturii;
■ construcţia – construirea produsului prin iteraţii incrementate;
■ tranziţia – furnizarea produsului comunităţii (distribuire, instruire, etc.).
Mulţimea componentelor procesului ar trebui să conţină:
■ modelarea afacerii – identificarea nevoilor utilizatorilor şi a aşteptărilor
acestora în ceea ce priveşte funcţionalitatea aplicaţiei;
■ identificarea cerinţelor – descrierea unei viziuni asupra aplicaţiei, împreună
cu un set de cerinţe funcţionale şi non-funcţionale;
■ analiza şi proiectarea – descrierea modului de realizare a aplicaţiei în faza
de implementare;
■ implementarea – generarea efectivă a codului sursă;
■ testarea – verificarea întregii aplicaţii.

2.5.3. Justificarea soluţiei Apache + PHP + MySQL


Internet-ul este în al treilea stadiu de dezvoltare, iar dinamic şi interactiv sunt
atributele esenţiale ale oricărui 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 conţinut 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 manipulării conţinutului paginii prin secvenţele încapsulate de
cod PHP în structura de tag-uri a paginii, cod care poate insera text HTML
direct în structură;

26
■ posibilitatea interpretării datelor unui formular HTML: PHP permite accesul
codului PHP la informaţiile primite de pagină de la browser prin structuri de
date predefinite şi completate automat;
■ suport pentru întreţinerea unei sesiuni, menită să reţină date între două cereri
succesive de pagini către acelaşi server;
■ funcţii pentru transmiterea headere-lor HTTP pentru autentificare;
■ funcţii pentru setarea cookie-urilor;
■ posibilitatea redirecţionării cererilor de pagină;
■ librării ce permit generarea, manipularea şi trimiterea către browser de
imagini, animaţii, PDF-uri;
■ interfaţa de conectare cu majoritatea SGBD-urilor;
■ interfaţa 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 aplicaţiilor Web cu conţinut dinamic. PHP atrage atât iniţiaţii în ale
programării, cât şi pe cei experimentaţi prin:
■ sintaxa simplă, relaxată, uşor de utilizat: ca limbaj de programare slab tipizat,
variabilele PHP nu trebuie declarate şi pot reţine orice tip de obiecte;
■ similitudinea sintaxei cu cea a limbajelor de programare structurată consacrate
precum C şi Perl; cu o sintaxă ce satisface toate aşteptările de la un limbaj de
programare atât interpretat cât şi compilat, structurat sau orientat-obiect, PHP5
permite programatorilor mai experimentaţi să dezvolte aplicaţii complexe cu un
efort net mai mic;

27
■ independenţa de platformă: a fost portat pe toate sistemele de operare majore,
incluzând UNIX, Linux, Windows şi MacOs şi interacţionează cu majoritatea
serverelor Web;
■ e open-source: spre deosebire de produsele comerciale similare, care vin cu
licenţă limitată şi fără acces la sursă, dezvoltatorul Web are libertatea de a
modifica şi completa limbajul după propriile nevoi, fără timpii morţi dintre patch-
uri şi fără teama că la un moment dat comerciantul va decide să nu mai susţină
produsul;
■ librărie open-source şi extensibilă de module: beneficiind de o comunitate
foarte răspândită de dezvoltatori software, PHP oferă programatorului Web, chiar
împreună cu pachetul standard, un număr impresionant de module reutilizabile şi
uşurinţa (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 răspuns necesar aplicaţiilor Web; poate chiar să fie folosit ca şi
modul al server-ului de Web, îmbunătăţind şi mai mult timpul de reacţie; testele
pe care Zend Tehnologies le face publice pe propriul site subliniază măsura în
care PHP surclasează competiţia;
■ interfaţa prietenoasă de conectare la o gamă foarte mare de servere de baze de
date: în conformitate cu nevoia aplicaţiilor Web de a interacţiona în mod dinamic
cu utilizatorul în vederea prezentării informaţiilor de interes care, de regulă, sunt
păstrate într-o bază de date, scripturi PHP de 2 sau 3 linii rezolvă probleme simple
de conectare şi executare de instrucţiuni SQL asupra bazelor de date;

28
■ începând cu versiunea 4.0, deţine 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 fiecărui om. Fără 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. Băncile, universităţile şi
bibliotecile sunt doar trei exemple de organizaţii care depind în mare măsură de bazele de
date şi de gestiunea acestora. Pe Internet motoarele de căutare, procesele de cumpărături on-
line, şi chiar convenţiile de denumire a tuturor site-urilor Web sunt activităţi care nu s-ar
putea desfăşura fără 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ă:
■ încărcarea bazei de date,
■ actualizarea şi interogarea acesteia,
■ interfaţa cu sistemul de operare în vederea simplificării accesului la date.
Un sistem de gestiune a bazelor de date care este implementat pe calculator şi care
gestionează interfaţa cu aceste date, formează ceea ce se numeşte un server de baze de date.
MySQL este un sistem de gestiune a bazelor de date relaţionale 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 decât soluţiile deja existente la ora actuală pe piaţă. Serverul
MySQL controlează accesul la datele utilizatorului, accesul este permis mai multor
utilizatori autorizaţi. 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 rând multiplelor facilităţi oferite de
acesta, dintre care vom aminti:

29
■ viteza de execuţie: programatorii susţin că MySQL este cel mai rapid sistem
de gestiune a bazelor de date care se găseşte la ora actuală pe piaţă;
■ uşurinţa în utilizare: MySQL este un sistem de gestiune a bazelor de date cu
performanţe ridicate dar relativ simplu de utilizat, a cărui configurare şi
administrare sunt mult mai simple decât în cazul sistemelor mai mari;
■ accesul concurent la date de către un număr nelimitat de utilizatori: la
server-ul MySQL se pot conecta mai mulţi clienţi simultan; clienţii pot folosi
mai multe baze de date simultan; se poate obţine acces la MySQL în mod
interactiv, folosind numeroase interfeţe care permit introducerea de interogări
şi vizualizarea rezultatelor;
■ conectivitatea şi securitatea: MySQL poate fi folosit integral în reţele, iar
bazele de date sunt accesibile de oriunde din internet, oferind astfel
posibilitatea partajării datelor cu oricine, oriunde; MySQL are controlul
accesului astfel încât persoanele care nu au dreptul să citească datele nu vor
avea această posibilitate
■ distribuţia liberă: MySQL este gratuit, fapt ce a atras extinderea fără
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 experienţa în folosirea sa
acumulată de-a lungul anilor şi-a spus cuvântul. Conectivitatea, viteza şi securitatea fac
ca MySQL să fie unul din cele mai potrivite produse pentru gestiunea bazelor de date pe
Internet.
Apache

30
Serverul Web Apache este un proiect al Apache Software Foundation şi constă
într-un efort colectiv cu scopul declarat de a dezvolta şi întreţine un server Web care
oferă servicii HTTP pentru sistemele de operare moderne precum UNIX şi Windows,
caracterizat de calităţile: 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 depăşeşte servere comerciale ale
unor firme de prestigiu, prin:
■ opţiunile de configurare şi design-ul modular: este foarte uşoară scrierea de
module care să satisfacă o funcţionalitate particulară, în cazul în care acestea nu
sunt deja implementate în librăria 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.
Câteva caracteristici ale serverului Apache sunt:
■ are foarte multe facilităţi: Apache are suport XML, incluziune de fişiere pe
parte de server, rescrierea URL-urilor, găzduire virtuală, pentru a enumera
doar câteva dintre ele;
■ este modular: dacă se doreşte folosirea unei facilităţi care nu este
implementată în nucleul Apache sunt foarte mari şanse să existe un modul care
poate adăuga serverului acea facilitate;
■ este extensibil: după cum am menţionat codul sursă fiind gratis, dacă nu se
găseşte un modul care să ofere funcţiile 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 piaţa serverelor web;

31
■ este gratuit: nu în ultimul rând, faptul că este distribuit în mod gratuit este
un atu foarte mare pentru Apache.

CAPITOLUL III
DEZVOLTAREA APLICAŢIEI

3.1. Determinarea cerinţelor unei aplicaţii de food-ordering

Primul pas în dezvoltarea aplicaţiei îl reprezintă stabilirea potenţialilor beneficiari,


precum şi a aşteptărilor acestora în ceea ce priveşte funcţionalitatea aplicaţiei. Printr-o
analiză atentă a cerinţelor beneficiarilor se va delimita comportamentul aplicaţiei ce
urmează a fi implementată.
Tehnica folosită în stabilirea cerinţelor beneficiarilor presupune efectuarea unui
studiu al pieţei aplicaţiilor care oferă servicii similare, în vederea documentării
avantajelor şi dezavantajelor acestora. Scopul urmărit este delimitarea comportamentului
unei aplicaţii ce beneficiază de cele mai bune practici întâlnite şi le înlocuieşte pe cele
care nu satisfac întocmai necesităţile beneficiarilor.
Rezultatele acestei etape le voi documenta în diagrame care prezintă cazurile de
utilizare ale aplicaţiei.

3.1.1. Cerinţele beneficiarilor aplicaţiei de food-ordering


Într-o economie de piaţă care urmăreşte echilibrarea raportului dintre cerere şi
ofertă prin satisfacerea într-o măsură cât mai mare a nevoilor ambelor categorii de
32
participanţi la procesul de schimb, o aplicaţie care oferă facilităţi de comandare on-line a
preparatelor culinare trebuie să satisfacă atât nevoile utilizatorilor care caută modalităţi
imediate, facile şi comode de a comanda ceva de mâncare, cât şi nevoia furnizorilor de
a-şi vinde preparatele culinare cu costuri scăzute.
În mod transparent pentru părţile implicate, pentru o satisfacere cât mai bună a
cerinţelor pieţei, aplicaţia de faţă trebuie să vină atât în întâmpinarea potenţialilor
cumpărători de preparate culinare, cu o ofertă cât mai variată şi o modalitate facilă de a
comanda on-line, cât şi în întâmpinarea furnizorilor, cu o metodă nouă şi puţin
costisitoare de promovare şi vânzare a preparatelor culinare proprii.
Se observă că scopul fundamental al aplicaţiei este acela de a fi un adevărat
intermediar între furnizori şi client, care trebuie să simuleze cât mai fidel
funcţionalitatea şi scopul unui magazin de prezentare în care furnizori diferiţi îşi
promovează şi vând preparatele culinare.
Prin urmare, delimitarea cerinţelor acestui tip de aplicaţie trebuie să ţină cont de
doleanţele ambelor categorii de beneficiari, ca părţi direct interesate şi participante într-o
afacere comercială.
Din analiza acestui deziderat reies cerinţele fundamentale ale aplicaţiei, care în
esenţă sunt cele ale unui magazin de prezentare, raportate însă la posibilităţile de
implementare oferite de mediul Web:
publicarea informaţiilor esenţiale despre fiecare furnizor şi existenţa unor
posibilităţi de actualizare a acestor informaţii;
■ prezentarea informaţiilor de interes despre preparatele culinare comercializate şi
existenţa unor posibilităţi de actualizare a acestor informaţii;
■ prezenţa mecanismelor de promovare a preparatelor într-o manieră eficientă şi
imparţială, dar care să nu afecteze uşurinţa în folosire a aplicaţiei;
■ asistenţa permanentă pentru utilizatorii aplicaţiei în ceea ce priveşte modalităţile
de folosire a acesteia în procesul comandării on-line de preparate culinare, precum

33
şi oferirea de informaţii privitoare la modalităţile în care produsele comandate vor
ajunge în posesia utilizatorului;
■ accesul bine organizat şi facil al utilizatorului atât la informaţiile despre
furnizori, cât şi la cele despre preparatele culinare;
■ posibilitatea efectuării şi preluării de comenzi de preparate într-o manieră
uşoară şi cu un flux de informaţie cât mai redus de la/înspre utilizator şi securizat
la nevoie; dezavantajul comunicării de informaţii între client şi furnizor într-un
mediu public cum este Internetul, şi deci supus interceptării neautorizate, trebuie
corectat prin măsuri de securitate atunci când informaţiile au caracter privat;
■ funcţionalităţi care să permită crearea unui punct de comunicare rapid între
furnizor şi clienţi, precum şi modalităţi de întreţinere a acestei relaţii cu costuri
minime (pentru furnizor).

Având ca punct de pornire rezultatele studiului efectuat despre implementările


existente, funcţionale şi de succes ale acestui tip de aplicaţie, implementări care se
bucură de posibilităţi imense oferite de mediul Web, consider că o aplicaţie Web care
oferă servicii de comenzi on-line a preparatelor culinare trebuie să satisfacă următoarele
necesităţi:
a. Necesităţi ale clientului:
■ aplicaţia trebuie să permită accesul în orice moment, din orice pagină, la
serviciul de asistenţă on-line; această acţiune nu trebuie să influenţeze activitatea
precedentă a clientului;
■ aplicaţia trebuie să fie orientată client, conform principiului „clientul nostru,
stăpânul nostru”; totodată, aplicaţia trebuie să limiteze şansele producerii de
neplăceri la acţiunile clienţilor neatenţi sau grăbiţi; această limitare de
responsabilitate trebuie realizată printr-o verificare permanentă a datelor introduse
de clienţi şi prin mesaje de atenţionare;

34
■ aplicaţia trebuie să aibă o interfaţă prietenoasă, facilă, echilibrată în ceea ce
priveşte raportul de informaţie necesară efectuării rapide de comenzi şi informaţie
necesară promovării preparatelor;
■ aplicaţia trebuie să ţină cont de eventualele sugestii din partea clientului, legate
de logica de funcţionare, precum şi de eventualele nevoi suplimentare, susţinute
prin argumente solide;
■ aplicaţia trebuie să întreţină o listă a produselor pe care clientul intenţionează să
le comande; această listă trebuie să se afle în controlul deplin al clientului (de ex.
poate renunţa la ea în orice moment) şi să poată fi consultată într-un mod facil din
orice pagină a aplicaţiei;
■ lansarea listei de comenzi trebuie să fie o procedură clară, explicită,
necondiţionată decât de dorinţa clientului;
■ posibilitatea lansării de comenzi cu o dată de livrare ulterioară datei efectuării
comenzii;
■ posibilitatea lansării unei liste de comenzi cu preparate de la furnizori diferiţi;
■ aplicaţia trebuie să ofere posibilitatea de anulare a oricărei comenzi lansate,
până în momentul în care aceasta a fost confirmată de către furnizor;
■ plata unei comenzi să se poată efectua la livrare şi să existe posibilitatea
facturării serviciului cumpărat;
■ reducerea la minim a informaţiilor cerute în momentul lansării unei comenzi;
■ aplicaţia trebuie să ţină minte un istoric al comenzilor pentru fiecare client;
alături de scopul său implicit, istoricul trebuie să poată fi folosit pentru relansarea
unor comenzi anterioare;
■ aplicaţia trebuie să permită accesul bine organizat şi facil atât la informaţiile
despre furnizori, cât şi la cele despre preparatele culinare, prin:
 ierarhii de categorii şi subcategorii de preparate;
 lista furnizorilor;

35
 modalităţi avansate de căutare a unui preparat;
 topul celor mai vândute preparate şi cel al celor mai vizitate
preparate, precum şi lista preparatelor noi introduse în aplicaţie,
diferitele promoţii;
■ 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;
■ aplicaţia trebuie să întreţină un profil al seriozităţii pentru fiecare furnizor:
clientul să-şi poată exprima părerea într-un mod liber, accesibil celorlalţi
utilizatori şi fără frica unor represalii, asupra calităţilor şi lipsurilor unui
preparat comandat, precum şi asupra serviciului de livrare; totodată, clientul să
aibă la dispoziţie modalităţi de comunicare directă cu furnizorii;
■ monitorizarea continuă a furnizorilor şi accesul clienţilor la informaţiile
privind seriozitatea acestora, conexiunea la internet şi modalităţile de preparare
a produselor în conformitate cu respectarea regulilor de igienă;

b. Necesităţi ale furnizorului:


■ posibilitatea afişării, prin intermediul aplicaţiei, a cel puţin următoarelor
informaţii despre un furnizor: denumirea unităţii comerciale, sigla, regimul de
funcţionare, specificul bucătăriei, adresa completă, orarul de funcţionare pe o
anumită perioadă, valoarea comenzii minime, tichetele de masă acceptate, ofertele
promoţionale, timpul minim de preparare şi livrare, taxa de livrare, oraşul şi aria
de livrare;
■ interfaţă prietenoasă de administrare a informaţiilor pe care un furnizor va avea
posibilitatea să le publice prin intermediul aplicaţiei;
■ interfaţă prietenoasă de administrare a comenzilor; o comandă se va putea afla
într-una din stările: lansată, anulată, acceptată, refuzată, confirmată sau efectuată;

36
■ furnizorul îşi asumă în mod exclusiv responsabilitatea modificării stării unei
comenzi după reguli proprii, dar care nu sfidează fundamentele relaţiei sale
comerciale cu cumpărătorul;
■ informaţiile cerute de aplicaţie în mod obligatoriu la primirea unei comenzi să
conţină: data şi ora la care se doreşte livrarea (acestea trebuie să respecte orarul
stabilit în avans de furnizor), un număr de telefon la care furnizorul va suna
pentru confirmarea comenzii, adresa de livrare (aceasta trebuie să fie în aria de
livrare declarată) şi, eventual, datele necesare unei facturi fiscale;
■ prezentarea informaţiilor despre furnizori într-un format lizibil şi plăcut vederii;
totodată, să se asigure imparţialitatea aplicaţiei în ceea ce priveşte ordinea de
afişare a furnizorilor într-o listă a acestora;
■ aplicaţia trebuie să permită accesul bine organizat şi facil atât la informaţiile
despre furnizori, cât şi la cele despre preparatele culinare, prin: ierarhii de
categorii şi subcategorii de preparate, lista furnizorilor, modalităţi avansate de
căutare a unui preparat, topul celor mai vândute preparate şi cel al celor mai
vizitate preparate, precum şi lista preparatelor noi introduse în aplicaţie, diferite
promoţii;
■ aplicaţia trebuie să poată întreţine un profil al seriozităţii pentru fiecare client şi
modalităţi de modificare a acestuia de furnizori, în mod argumentat, pe baza
trecutului relaţiei cu clientul;
■ funcţionalităţi care să permită crearea unui punct de comunicare rapid între
furnizor şi clienţi, precum şi modalităţi de întreţinere a acestei relaţii cu costuri
minime (pentru furnizor).

c. Reguli pentru buna funcţionare a aplicaţiei:

37
■ aplicaţia trebuie să permită accesul în orice moment, din orice pagină, la
condiţiile de utilizare a aplicaţiei, politica de confidenţialitate, descrierea
aplicaţiei;
■ aplicaţia se obligă să posteze informaţiile despre preparatele unui furnizor doar
dacă acesta îşi dă acceptul în respectarea următoarelor condiţii:
 să trateze fiecare comandă cu aceeaşi seriozitate, indiferent de oră,
client, adresă de livrare;
 să acorde atenţie eventualelor reclamaţii din partea clienţilor.
3.1.2. Delimitarea comportamentului aplicaţiei (cazurile de utilizare)
Cazurile de utilizare reprezintă secvenţe de tranzacţii 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 aplicaţie. Mulţimea cazurilor de utilizare a
unei aplicaţii reprezintă toate modalităţile în care aplicaţia poate fi folosită.
Cazurile de utilizare :
■ sunt unităţi de sine stătătoare, bine delimitate (începutul şi sfârşitul unui caz
de utilizare sunt cuprinse în acesta);
■ trebuie să fie iniţiate de un actor şi terminarea lor să fie „văzută” de un actor;
■ trebuie să îndeplinească anumite scopuri de logică a problemei (dacă nu se
poate găsi un astfel de obiectiv atunci cazul de utilizare trebuie regândit);
■ trebuie să lase sistemul într-o stare stabilă (nu pot fi îndeplinite doar pe
jumătate).
Având în vedere faptul că unul din scopurile declarate ale aplicaţiei de faţă este
atragerea de noi clienţi, lucru care se poate realiza prin determinarea vizitatorilor să-şi
creeze conturi de utilizator, consider că vizitatorii ar trebui să aibă următoarele drepturi:
■ să vizualizeze informaţiile despre furnizori şi preparatele acestora;
■ să caute un preparat cel puţin după următoarele informaţii relevante:
furnizor, oraş de livrare, aria de livrare, preţ, ingrediente;

38
■ să contacteze un furnizor pentru eventualele nelămuriri legate de preparatele
pe care acesta declară că le poate livra;
■ să îşi creeze o idee atât despre măsura în care preparatele pe care le poate
comanda şi seriozitatea furnizorilor îi satisfac nevoile culinare, cât şi despre
uşurinţa în utilizare a aplicaţiei;
■ să poată afla termenii şi condiţiile de utilizare a aplicaţiei, politica de
confidenţialitate, paşii pentru crearea unui cont – într-un cuvânt să beneficieze
de asistenţă on-line;
■ să se poată înregistra în aplicaţie, prin crearea unui cont;
■ să se poată conecta la aplicaţie în cazul în care este înregistrat ca şi
client/furnizor al aplicaţiei.
Următoarea diagramă surprinde toate cazurile în care vizitatorul schimbă
informaţie cu aplicaţia:

39
Un VIZITATOReste un utlizator al
aplicaţiei care nu este înregistrat în
evidenţa aplicaţiei sau cel puţin nu
s-a conectat încă la serviciile ei.

<<extinde>>

Navigare categorii <<extinde>>


Vizualizare info preparat
de preparate
<<extinde>>

Căutare preparat <<extinde>>

Vizualizare info furnizor

Navigare furnizori
<<extinde>>

Contactare furnizori
VIZITATOR Înregistrare ca
şi client al aplicaţiei

Demarare asistenţă
on-line

Conectare la
aplicaţie ca şi client

Conectare la
aplicaţie ca şi furnizor

Fig. 3.1. Cazurile de utilizare pentru vizitator

Eticheta <<extinde>> este folosită pentru a sugera un comportament opţional, un


comportament care are loc doar în anumite condiţii sau fluxuri diferite ce pot fi selectate
pe baza selecţiei unui actor. De exemplu, pentru a putea vizualiza informaţiile despre un
anumit preparat, vizitatorul va trebui să efectueze în prealabil cel puţin una din acţiunile:
■ căutarea unui preparat prin instrumentele puse la dispoziţie de aplicaţie;
■ consultarea meniului unui furnizor;
■ navigarea categoriilor de preparate.
Din analiza cerinţelor formulate de clienţii aplicaţiei am surprins în următoarea
diagramă toate cazurile de utilizare de către client a aplicaţiei în scopul comandării on-
line de preparate culinare.
40
Un CLIENT este un utilizator care
este înregistrat în evidenţa aplicaţiei
ca şi beneficiar al serviciilor de
comandă on-line şi în plus S-A
CONECTAT LAAPLICAŢIE.

<<extinde>>

Administrare Lansare comandă


VIZITATOR comandă în pregătire în pregătire

<<extinde>>

<<extinde>>

Vizualizare info preparat

Adăugare preparat la
comanda în pregătire
CLIENT
Vizualizare comenzi
în derulare <<extinde>>

Trimitere părere
Vizualizare despre preparat
istoric comenzi

Administrare cont

Fig. 3.2. Cazurile de utilizare pentru client

Se observă că între CLIENT şi VIZITATOR există o relaţie de generalizare, în


sensul că un CLIENT poate interacţiona cu aplicaţia în toate modurile în care
interacţionează vizitatorul, şi în plus mai are opţiunile prezentate în diagrama de mai
sus.
Dată fiind multitudinea de informaţii pe care clientul doreşte ca aplicaţia să le
reţină pentru el, este natural ca rolul contului de client să fie extins de la o modalitate
simplă de control al accesului la aplicaţie, la un adevărat container de informaţie. Am
identificat în final 4 tipuri de informaţie reţinută de un cont client:
■ informaţii personale şi de conectare;
■ lista adreselor de livrare;
■ lista informaţiilor de facturare;
■ lista grupurilor de clienţi la care posesorul contului este administrator.

41
Prin urmare, diagrama detaliată a cazurilor de utilizare care compun cazul de
utilizare generic „Administrare cont client”, dirijată de cele 4 tipuri de informaţie, arată
astfel:
Detalierea cazului de utilizare
Administrare cont client

<<include>> Configurarea informaţii


personale şi de conectare

<<include>>

Administrare cont
CLIENT

<<include>>
<<include>> Administrare
adrese de livrare

Administrare informaţii Administrare informaţii


grupuri de clienţi de facturare

Fig. 3.3. Cazul de utilizare „Administrare cont” pentru client

Furnizorul este un utilizator înregistrat în aplicaţie ca şi prestator de servicii de


livrare la domiciliu a preparatelor culinare. Necesităţile declarate ale acestuia sunt
administrarea listei de comenzi primite, păstrarea de către aplicaţie a unui istoric al
comenzilor onorate de el, precum şi posibilitatea modificării informaţiilor despre
activitatea sa şi a meniului de preparate culinare.
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 rândul lor,
alte două cazuri de utilizare cu efect imediat pentru furnizor.
Astfel, diagrama cazurilor de utilizare de către furnizor a aplicaţiei arată astfel:

42
Un FURNIZOR este un utilizator
înregistrat în aplicaţie ca şi prestator
de servicii de preparare şi livrare la
domiciliu de produse culinare.

<<include>>

Configurare informaţii personale


şi de conectare furnizor
Administrare cont
<<include>>

FURNIZOR

Modificare meniu

<<include>>

Administrare comenzi

<<include>>

Administrare comenzi
pentru ziua în curs

Administrare comenzi pentru


Vizualizare istoric comenzi o zi ulterioară celei în curs

Fig. 3.4. Cazurile de utilizare pentru furnizor

Minimul de interacţiune al VIZITATORILOR cu aplicaţia ne permite să tragem o


concluzie preliminară asupra comportamentului de bază, minimal, al acesteia. Prin
urmare aplicaţia trebuie să prezinte interfaţă pentru:
înregistrarea unui client nou;
■ conectarea la aplicaţie a clienţilor;
■ conectarea la aplicaţie a furnizorilor;
■ consultarea listei de furnizori;
■ consultarea listei de categorii de preparate comandabile prin acest serviciu;
■ căutarea unui preparat după criterii relevante;
■ consultarea informaţiilor despre un anumit preparat;
■ vizualizarea termenilor şi condiţiilor de utilizare a aplicaţiei, a politicii de
confidenţialitate, a paşilor pentru crearea unui cont client.

43
Din cazurile de utilizare delimitate pentru actorul CLIENT, funcţionalitatea
aplicaţiei se extinde, pentru un utilizator conectat la aplicaţie ca beneficiar al serviciului
de comandă on-line, la oferirea unei interfeţe pentru:
■ administrarea contului prin posibilitatea configurării informaţiilor personale
şi de conectare, administrarea adreselor de livrare, administrarea informaţiilor
de facturare precum şi administrarea informaţiilor despre grupurile de clienţi
administrate;
■ vizualizarea istoricului de comenzi efectuate de-a lungul folosirii aplicaţiei;
■ adăugarea unui preparat la comanda în pregătire;
■ lansarea comenzii în pregătire;
■ administrarea comenzii în pregătire;
■ consultare listă cu comenzi în derulare (lansate şi neefectuate).
Cazurile de utilizare delimitate pentru actorul FURNIZOR completează
comportamentului aplicaţiei. Astfel, aplicaţia trebuie să permită unui utilizator conectat
la aplicaţie ca prestator de servicii de livrare la domiciliu a preparatelor culinare,
următoarele:
■ administrarea contului de furnizor prin configurarea informaţiilor personale
şi de conectare, precum şi modificarea meniului;
■ vizualizarea istoricului de comenzi efectuate către clienţi;
■ administrarea comenzilor în aşteptare pentru o zi ulterioară celei în curs;
■ administrarea comenzilor în aşteptare pentru ziua în curs.
3.2. Proiectarea aplicaţiei

Designul conceptual al aplicaţiei.Arhitectura aplicaţiei


În general, aplicaţiile client/server pot fi privite ca fiind structurate pe trei nivele:
nivelul de prezentare, nivelul de logică a aplicaţiei (de business) şi nivelul de date.

44
P A R DT E A P A R DT E A
S E R V E R C L I E N T

N i v ed le u l
I N T E R N E T B R O W S E R
p r e z e n t a r e

N i v ed le u l
l o g ai a c p ã l i c a t i e i

Buy SmartDraw !- purchased copies print this


document without a watermark .
N i v ed le u dl a t e 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 interacţionează 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 aplicaţiei permit modificarea interfeţei cu utilizatorul cu eforturi
minime;
■ Nivelul de logică a aplicaţiei – reprezintă cel mai dinamic nivel al unei
aplicaţii, deoarece regulile de logică a aplicaţiei şi funcţionalitatea se modifică
mult mai des; izolarea de celelalte nivele face ca impactul implementării unor
modificări să fie redus; pe cât posibil, nivelul de logică trebuie să nu conţină
elemente legate de interfaţa cu utilizatorul sau accesul la baza de date; de
asemenea, acest nivel joacă rolul de intermediar între baza de date şi client,
fiind responsabil cu transferul datelor;
■ Nivelul de date – este cel mai static nivel al aplicaţiei; reprezintă nivelul la
care sunt stocate datele; de aici datele sunt furnizate nivelului logic pentru

45
prelucrări şi eventual nivelului de prezentare, pentru a putea fi accesate de
utilizator.
Avantajul arhitecturii pe 3 nivele faţă de o arhitectură client/server tradiţională (pe
două nivele), este că majoritatea procesărilor se fac pe serverul de aplicaţie şi pe baza de
date, nu pe calculatorul client şi pe baza de date. Aceasta permite o scalabilitate mult
mai bună a aplicaţiei în condiţiile unui volum de tranzacţii în creştere. Este necesară
doar adăugarea de servere suplimentare pentru creşterea capacităţii de procesare.
Aplicaţia de food-ordering, prezentată în lucrarea de faţă, este structurată pe trei
nivele, astfel:
P A R DT EE A P A R DT EE A
S E R V E R C L I E N T

N i v ed le u l
I N T E R N E T B R O W S E R
p r e z e n t a r e

S c r i Pp Ht u P r i d e
g e n e d r i an r a e m i c a
a i n t e r f e t e i

N i v ed le u l S cr i pP t H u rP i c a r e
c o n t r l oo l g e s i a c i z a ã
l o g ai a c p ã l i c a t i e i f l u ax pu l l i c a t i e i

L i b r d a f er u i e n Pc t H i i P
d ae d m i n B i sD t r a r e
M y S Q L

Buy SmartDraw !- purchased copies print this


B a zd a e d a t e document without a watermark .
N i v ed le u dl a t e M y S Q L Visit www .smartdraw .com or call 1-800-768-3729.

Fig. 3.6. Arhitectura aplicaţiei de food-ordering


Nivelul de prezentare este format din paginile HTML prin care utilizatorii
interacţionează cu aplicaţia. Scopul acestui nivel îl reprezintă prezentarea într-un format
prietenos a datelor primite de la nivelul de logică a aplicaţiei. Datele se referă atât la
informaţii ce trebuie aduse la cunoştinţa utilizatorului, cât şi la indicatori care limitează

46
funcţionalitatea paginii rezultate. De asemenea, la acest nivel se realizează o prelucrare a
datelor introduse de utilizator, astfel încât ele să fie trimise mai departe nivelului de
logică a aplicaţiei într-un format recunoscut de acesta.
Nivelul de logică a aplicaţiei face legătura între celelalte două nivele. La acest
nivel, prin scripturi PHP organizate în librării, se stabilesc regulile de funcţionare a
aplicaţiei. Aceste scripturi se ocupă de operaţii precum validarea datelor introduse de
utilizator, construirea interogărilor SQL ce vor fi trimise spre execuţie nivelului de date,
luarea deciziilor în ceea ce priveşte informaţiile care vor fi trimise spre afişare nivelului
de prezentare.
Nivelul de date, reprezentat de baza de date MySQL, constituie partea statică a
aplicaţiei, fiind responsabil de stocarea datelor. De la acest nivel datele sunt trimise
pentru prelucrări către nivelul responsabil de logica aplicaţiei. Pe de altă parte, aici sunt
stocate informaţiile provenite de la utilizatori, după ce în prealabil acestea au fost
validate şi prelucrate la nivelul de logică a aplicaţiei.

Designul conceptual al bazei de date


Utilitatea oricărei colecţii de date constă în obţinerea de informaţii şi depinde în
mare măsură de modul de organizare şi manipulare a acestora. Analiza, proiectarea şi
implementarea structurii bazei de date se realizează utilizând un anumit model de date.
Modelele utilizate a bazelor de date se pot grupa în trei categorii: modele bazate
pe obiect, modele bazate pe înregistrări şi modele fizice. În prezent, cel mai răspândit
dintre modelele de baze de date este cel relaţional (entitate-relaţie), al cărui obiectiv este
acela de simplificare a accesului la bazele de date de către utilizatorii finali.
Răspândirea acestui model se datorează faptului că SGBD-urile relaţionale dispun
de un limbaj de manipulare a datelor foarte puternic şi simplu şi de o interfaţă
prietenoasă, care permite folosirea bazelor de date relaţionale de către o categorie foarte
largă de utilizatori.

47
O bază de date relaţională este definită ca fiind un ansamblu de tabele sa relaţii
între care există anumite legături, fiecare tabelă fiind alcătuită din coloane, denumite
atribute şi linii, denumite şi tuple. Ideea fundamentală a lui Codd a fost că mulţimile de
entităţi se modelează convenabil prin tabele a căror descriere, adică antetul, defineşte
tipul de entitate prin atribute sau proprietăţi, iar liniile reprezintă entităţi din mulţime,
sau instanţe ale tipului de entitate respectiv.
O entitate este o realitate obiectivă care există prin ea însăşi. Orice entitate se
caracterizează prin anumite proprietăţi, care în cadrul modelului de date sunt
reprezentate prin atribute. La rândul lor, entităţile sunt reprezentate prin tipuri de entităţi.
Un tip de entitate este o reprezentare a unei categorii de obiecte din lumea reală sau a
unei mulţimi de entităţi de acelaşi fel, iar atributele sale reprezintă caracteristicile
generale (intensionale) ale acelei categorii.

3.3. Designul fizic al aplicaţiei


Componentele aplicaţiei
Diagramele de componente ne oferă vederi structurale asupra aplicaţiei, prin
aducerea în prim plan a componentelor sale funcţionale care interacţionează în timpul
execuţiei pentru buna comportare a aplicaţiei. Prin urmare, scopul modelului derivat din
aceste vederi este delimitarea modulelor aplicaţiei asupra cărora trebuie să se
concentreze activitatea de implementare, a scopului acestor module, precum şi a
dependenţelor dintre acestea.

48
Fig. 3.7. Diagrama de componente a aplicaţiei

Această primă diagramă are rolul de a sublinia cele patru componente ale
aplicaţiei şi pachetele de librării care susţin funcţionalitatea acestora. Fiecare
componentă este văzută ca şi client al acestor pachete. Am delimitat cele patru
componente din tipul de arhitectură pe trei nivele ales pentru aplicaţie, ţinând totodată
cont de caracterul public al mediului Web.
Astfel, componenta de Securitate completează aplicaţia având rolul bine
determinat şi necesar de asigurare a bunei funcţionări a aplicaţiei, protejând-o împotriva
pericolelor prezente în mediul Web, inclusiv împotriva utilizării necorespunzătoare de
către beneficiarii săi. Pachetul de Autentificare şi autorizare satisface cerinţa aplicaţiei
de a controla accesul la funcţionalitatea acesteia prin intermediul conturilor şi a

49
sesiunilor de lucru. În plus, pachetul de Verificare date trimise de utilizator apără
împotriva pericolului executării de operaţii asupra bazei de date prin injectarea de către
utilizator de comenzi SQL în conţinutul datelor trimise către server, date care prezintă
probabilitate mare să fie folosite de server în construcţii SQL.
Interfaţa reprezintă unicul mediu de exprimare a participanţilor la comunicarea
utilizator – aplicaţie, văzută ca un schimb bidirecţional de informaţie. Prin urmare,
funcţionează atât ca faţă vizibilă a aplicaţiei, cât şi ca modalitate prin care utilizatorul îşi
comunică opţiunile, alegerile, deciziile.
Componenta de Procesare - principala responsabilitate pe care o deţine este
implementarea logicii de funcţionare a aplicaţiei, aşa cum reiese ea din activitatea de
proiectare. Această componentă deţine de asemenea responsabilitatea interfaţării cu
componenta de Date, comportament materializat în pachetul Interfaţa cu serverul
MySQL.
Componenta de Date execută la cererea explicită a componentei Procesare
modificări asupra bazei de date, îndeplinind rolul nivelului de date din arhitectura 3-tier.

Fig. 3.8. Relaţiile dintre componentele aplicaţiei

50
Putem observa că toate componentele fundamentale ale arhitecturii aplicaţiei
<<utilizează>> componenta de Securitate datorită necesităţii de a valida comunicarea
utilizator – aplicaţie conform unor reguli bine stabilite.
Arhitectura 3-tier a aplicaţiei impune existenţa a două interfeţe care, transpuse în
contextul componentelor delimitate, asigură comunicarea între:
■ componenta de Interfaţă şi cea de Procesare (IProcesare): această interfaţă
asigură transformările necesare între formatele de date cu care lucrează cele
două componente;
■ componenta de Date şi cea de Procesare (IDate): funcţionalitatea acestei
interfeţe rezidă în pachetul Interfaţa 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
aplicaţiei, presupunând modelarea proceselor pas cu pas. O diagramă de activitate
prezintă fluxul secvenţelor de activităţi, putând fi folosită pentru a descrie activităţile
realizate în cadrul unei operaţii, folosind, dacă este cazul, decizii şi condiţii. Scopul
acestor diagrame este acela de a captura acţiunile şi rezultatele lor. Ele reprezintă o cale
alternativă de descriere a interacţiunilor, cu posibilitatea de specificare a acţiunilor ce se
vor realiza: „ce fac acestea?”, „când au loc?” şi „unde au loc?”.
Voi folosi diagramele de activităţi în următoarele scopuri:
■ pentru a ilustra acţiunile care vor fi realizate când este executată o operaţie;
■ pentru a arăta cum o instanţă a unui caz de utilizare poate fi realizată în
termenii acţiunilor;
■ pentru a ilustra cum este organizată munca actorilor.

51
Am ales diagramele de acţiune pentru cele mai reprezentative cazuri de
interacţiune dintre utilizator şi aplicaţie, şi anume: înregistrarea unui utilizator ca şi
client, respectiv conectarea unui utilizator ca şi client.
V IZ I TA TO R BRO W SE R S c ri p tu r i P H P s e r v e r -s id e

S u n t v e ri f i c a t e S e p o a t e c re a
C o m p le a ză fo r m u la r cu d a te [ DA ] [ DA ]
re stri c t i i l e d e ti p ? c o n t? C r e a ză c o n t
n e ce s a re p e n tru în r e g is tra r e

[ NU ]
[ NU ]

S e m n a lize a ză
p r o b le m e le a p ă r u te
S e m n a lize a ză
p r o b le m e le a p ă r u te

T rim it e - m a il cu in fo rm a ţiile d e
c o n e c ta r e a le c o n tu lu i c re a t

T r im it c o n firm a re a
c re ă rii c o n tu lu i

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


client al aplicaţiei

Paşii urmaţi în realizarea activităţii de înregistrare ca şi client al aplicaţiei sunt


următorii:
■ vizitatorul completează un formular cu datele necesare pentru înregistrare;
■ browser-ul verifică dacă datele din formular îndeplinesc restricţiile de tip;
dacă aceste restricţii nu sunt îndeplinite, atunci browser-ul semnalează erorile
apărute şi se reia activitatea de completare a formularului;
■ în condiţiile în care restricţiile de tip sunt îndeplinite, atunci responsabilitatea
efectuării de acţiuni revine script-urilor PHP de pe server, care va verifica dacă
este posibilă crearea de cont cu datele introduse; dacă nu este posibilă crearea

52
contului, atunci scripturile semnalează erorile apărute ş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 înştiinţează ca a fost creat contul.

VIZITATOR BROWSER Scripturi PHP serv er-side

Sunt verificate
Completare nume de [ DA ]
restri ctii le de tip? Autorizează conectarea
utilizator şi parolă

[ NU ]

Semnalizează
problemele apărute

Sunt corecte datel e de


Semnalizează conectare?
problemele apărute [ NU ]

[ DA ]

Configurează sesiunea
de conectare

Permit accesul vizitatorului la


opţiunile principale ale clienţilor

Fig. 3.10. Diagrama de activitate care prezintă conectarea unui client la aplicaţie

Paşii urmaţi în realizarea activităţii de conectare a unui client la aplicaţie sunt


următorii:
■ vizitatorul completează numele de utilizator şi parola;
■ browser-ul verifică dacă sunt îndeplinite restricţiile de tip; dacă acestea nu
sunt îndeplinite atunci semnalează erorile apărute şi se reia activitatea de
introducere a numelui de utilizator şi a parolei;
■ dacă restricţiile de tip sunt îndeplinite, atunci scripturilor PHP le revine
responsabilitatea de a autoriza conectarea;

53
■ scripturile PHP verifică dacă sunt corecte datele de conectare; dacă nu sunt
corecte atunci se semnalează erorile apărute ş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 opţiunile principale ale
clientului.

3.4. Implementarea aplicaţiei

Componenta de Interfaţă
Am să încep detalierea implementării alese pentru componenta de Interfaţă prin
descrierea unor aspecte structurale legate de paginile site-ului.
În mod natural, fiecărui tip de utilizator al aplicaţiei îi va corespunde câte o pagină
de început, o pagină de index, care trebuie să combine următoarele cerinţe declarate: să
conţină opţiuni şi informaţii utile pentru utilizator, să aibă aspect plăcut şi să se încarce
rapid.

Fig. 4.13. Structura paginilor de index ale aplicaţiei

54
În cadrul acestui format, header-ul conţine un banner şi trimiteri către termenii de
confidenţialitate, condiţiile de utilizare a aplicaţiei precum şi către formularul de
contactare a administratorului aplicaţiei.
Meniul pus la dispoziţia utilizatorului este poziţionat în partea stângă a paginii,
sub header, şi conţine toate opţiunile majore de care beneficiază acesta în aplicaţie.
Opţiunile din meniu sunt grupate pe categorii, astfel că meniul este format din grupaje
de opţiuni dispuse una sub alta şi încadrate de un chenar. Un grupaj al meniului poate să
fie conţinut într-o fereastră care se încarcă în acel chenar.
Fereastra conţinut este locul de desfăşurare a acţiunii. Toate acţiunile
utilizatorului se vor materializa prin schimbarea conţinutului acestei ferestre.
Schimbarea se realizează centralizat, prin funcţia JavaScript loadInCont(loc) care este
pusă la dispoziţia opţiunilor din meniu de către pagina index. Singurul argument al
funcţiei specifică locaţia paginii care se vrea încărcată în fereastra de conţinut.
Structura dată paginilor de index impune un stil de utilizare al aplicaţiei ce se
caracterizează prin simplitate şi care permite, prin cele trei metode de căutare a unui
preparat, concentrarea utilizatorului asupra preparatelor căutate.

Componenta de Date
În cazul aplicaţiei de faţă este mai elegantă şi mai compactă instalarea pe acelaşi
calculator a serverelor de Apache şi MySQL. Aceasta datorită efortului redus la care
sunt supuse ambele servere în cazul acestei aplicaţii.
Tipul ales pentru baza de date care stochează informaţiile prelucrate de aplicaţie
este MyISAM, un format gratis, neproprietar, simplu, lipsit de facilităţi precum suport
pentru tranzacţii, proceduri stocate sau triggere. Lipsurile acestea îmi sunt indiferente
datorită faptului că cerinţe precum păstrarea integrităţii referenţiale sau păstrarea
consistenţei 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

55
depline asupra bazei de date, iar limitările accesului fiecărui 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 Interfaţa cu serverul de MySQL care conţine librăria de funcţii pe
care le-am considerat necesare pentru administrarea, prin intermediul PHP-ului, a unei
bazei de date.
Această librărie asigură independenţa implementării logicii aplicaţiei de tipul
bazei de date administrată de componenta de Date. Adică scripturile ce implementează
logica aplicaţiei nu trebuie modificate dacă se decide schimbarea tipului bazei de date.
Mecanismul folosit se bazează pe delimitarea unei interfeţe minimale de acces la
o bază de date de orice tip prin operaţii simple şi generale precum: conectare la server,
selectarea unei baze de date, executarea unei comenzi SQL, etc. Denumirile funcţiilor de
acces sunt şi ele în ton cu independenţa interfeţei de tipul bazei de date pe care o
accesează. Astfel, pentru folosirea unui tip anume de bază de date, trebuie pregătit un
fişier care implementează funcţiile acestei interfeţe cu ajutorul funcţiilor specifice de
acces puse la dispoziţie de PHP pentru tipul de bază de date în discuţie.
Scripturile aplicaţiei vor utiliza apeluri către funcţii din interfaţă pentru
modificarea bazei de date care îi stochează informaţiile necesare. Ce se execută efectiv
depinde de implementarea furnizată a interfeţei.

Librăria mysql.lib.php conţine două tipuri de funcţii:


■ care le extind pe cele puse la dispoziţie de PHP ca suport nativ pentru
interacţiunea cu baze de date de tip MyISAM prin modificarea semanticii
valorii returnate de acestea; de exemplu, funcţia wrap_mysql_query() care
suprascrie funcţia PHP mysql_query() de executare a unei comenzi SQL

56
asupra unei bazei de date, returnează în caz de eroare în execuţia comenzii,
valoarea 0 inhibând totodată afişarea în pagină a erorii;
■ pentru care nu există suport nativ, dar care rezolvă probleme mici ce apar
des; de exemplu funcţia get_tbl_col_val() determină valoarea unui câmp
specificat, de pe un rând care verifică o anumită condiţie, dintr-o tabelă
specificată şi folosind o conexiune specificată către o bază de date.

Componenta de Securitate
Una din problemele de securitate care trebuie rezolvate pentru această aplicaţie
este accesul controlat la funcţionalităţile aplicaţiei de comandare on-line. Aceasta se
realizează prin acordarea de conturi de acces (care presupun completarea unor informaţii
personale şi de contact) şi implementarea unui mecanism de conectare la aplicaţie pe
baza acestora.
Atât pentru un client înregistrat, cât şi pentru un furnizor, parola se reţine 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 funcţiile librăriilor ./lib/auth.lib.php şi ./lib/md5.js, precum şi prin fişierul
de includere ./lib/authorize.inc.php. Librăria md5.js conţine 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 întreţinerea unei
sesiuni de lucru menită să reţină date între două cereri succesive de pagini PHP către
acelaşi server. Cel care iniţiază o astfel de sesiune, primeşte un identificator unic de
sesiune pe baza căruia primeşte 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.

57
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
aplicaţie. Această verificare e făcută de funcţia isRegUser() care în caz afirmativ va
întoarce tipul utilizatorului (client/furnizor), precum şi identificatorul utilizatorului,
necesare pentru direcţionarea ulterioară a acestuia spre indexul care-i corespunde.
La o autentificare realizată cu succes, se dispune crearea unei sesiuni de lucru şi,
prin intermediul funcţiei getSessionCodes(), a două coduri obţinute pe baza
identificatorului de sesiune, identificatorului utilizatorului, data, ora, minutul şi secunda
în care s-a reuşit autentificarea şi pe baza parolei criptate a utilizatorului. Între cele două
coduri există o corespondenţă univocă. Unul din coduri urmează să fie păstrat în sesiune,
iar celălalt dat utilizatorului.
Autorizarea unui acces la o pagină se realizează prin intermediul funcţiei
isAuthorizedAccess() şi are rolul de a verifica dacă codul de acces prezentat de utilizator
pentru sesiunea de lucru la care susţine ca e conectat corespunde codului de acces salvat
în sesiunea de lucru.
Fişierul authorize.inc.php trebuie inclus la începutul fiecărei pagini a site-ului şi
are rolul de a autoriza accesul utilizatorilor la aceasta. În caz de nereuşită, va
redirecţiona utilizatorul către pagina de logare:
Mecanismul de acces controlat la pagini asigură faptul că accesul la paginile
destinate celor înregistraţi necesită şi nu funcţionează fără activitatea de conectare. În
acest mod, aplicaţia este protejată, de exemplu, împotriva vizitatorilor fără cont care
încearcă accesarea indexului de client din bara de adresă a browser-ului, sau chiar
împotriva celor conectaţi care încearcă să-şi schimbe pagina de index cu cealaltă. Toţi
vor fi direcţionaţi spre pagina de conectare.

58
CAPITOLUL V
DESCRIEREA EFICIENȚEI ECONOMICE UTILIZÎND METODA SIMULĂRII
PROCESELOR

5.1. Aspecte generale privind modelarea şi simularea proceselor economice

Într-o definiţie succintă modelarea nu este altceva decât un proces de cunoaştere


mijlocită a realităţii cu ajutorul unor modele; iar modelul este o reprezentare simplificată
(materială sau simbolică) a realităţii, fără însă să denatureze caracteristicile esenţiale ale
fenomenului sau procesului studiat. Sintetizând cunoştinţele acumulate până la un
anumit moment, modelul permite reluarea procesului de cunoaştere pe o treaptă
superioară.
Modelarea economico-matematică reprezintă o metodă de cercetare, cunoaştere şi
analiză a fenomenelor şi proceselor complexe din economie, judecate în mod abstract,
apelându-se la formalizarea logică şi matematică.
Modelarea economică oferă managerului latura riguroasă a acţiunilor sale
(„ştiinţa de a conduce”), modalităţi 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 găsi şi a decide „mai bine” şi „mai repede” fără 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 condiţii de eficienţă pentru producător, cu ajutorul unor modele
economico-matematice flexibile şi cu posibilitatea utilizării tehnicii simulării.
Studiul comportării unui sistem în anumite condiţii, care nu pot fi create în mod
real, se realizează numai prin simulare. Situaţiile complexe care apar în studiul
proceselor şi fenomenelor economice nu pot fi uneori soluţionate de instrumentul
matematic. Modalitatea de a ieşi din impas este construirea unui model matematic al
sistemului studiat şi realizarea de experimente pe acesta.

59
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
intrările şi, ţinând seama de stările interne ale sistemului, prin algoritmi adecvaţi, să
determine ieşirile şi să descrie evoluţia în timp a stărilor interne ale sistemului.
Deşi nu oferă soluţii 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 simulării se
obţin mai multe variante de decizie dintre care managerul o va alege pe cea mai bună,
corespunzătoare condiţiilor date la un anumit moment.
În activitatea de simulare sunt implicate trei elemente importante, şi anume:
sistemul real, modelul, calculatorul şi două relaţii: relaţiile de modelare şi relaţiile 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 simţurile omului. „Modelul real”


reprezintă sistemul real înlocuit şi care corespunde, în principiu, cerinţelor sistemului

60
iniţial. „Modelul abstract” realizează trecerea de la „sistemul real” la „modelul real”. El
reproduce sistemul real prin descompunerea sistemului în părţile componente
elementare şi stabileşte legăturile dintre acestea. Validarea rezultatelor se face prin
stabilirea concordanţei dintre datele din sistemul real şi cele oferite de model.
Pentru ca deciziile elaborate pe baza rezultatelor simulării unui proces economic
să fie viabile, este necesar ca şi caracteristicile aleatoare (preţul, cererea de produse,
durata de servire etc.) să fie incluse în modelul de simulare. O mărime aleatoare are mai
multe valori posibile, fiecare valoare având 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 determinării valorilor
unui indicator economic, este necesară o metodă specială care să permită generarea la
întâmplare a valorilor pentru fiecare factor aleator care influenţează indicatorul
respectiv. Aceste valori pot fi reprezentate printr-o distribuţie de probabilitate obţinută
prin metoda de simulare Monte Carlo (sau metoda experimentelor statistice).

5.2. Estimarea succesului aplicaţiei

În cazul comerţului electronic, noutatea şi caracteristicile specifice acestui tip de


afacere nu ne permit luarea în considerare a aceloraşi variabile care afectează succesul
unei afaceri tradiţionale 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 rând datorită
lipsei unor analize amănunţite în acest scop.
În ceea ce priveşte succesul unui site, acesta poate fi cel mai bine estimat prin
numărul de vizitatori ai site-ului, care pot reprezenta potenţiali cumpărători ai produselor
oferite. Trasând o paralelă, am putea spune că numărul de vizitatori ai unui site
reprezintă echivalentul tirajului unui ziar sau al audienţei unei emisiuni de

61
radio/televiziune. În aceste condiţii, un număr mare de vizitatori poate reprezenta o
garanţie a faptului că respectivul site va obţine succesul aşteptat.
Ulterior, în funcţie de volumul efectiv al vânzărilor, cercetarea poate fi extinsă în
vederea estimării profitului viitor al afacerii electronice.
Situaţia de la care am pornit în realizarea simulării este prezentată în tabelul
următor:
Număr Număr
săptămână 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 distribuţiilor de probabilitate. Pentru determinarea


probabilităţii voi folosi definiţia acesteia care spune că: probabilitatea este raportul
dintre numărul cazurilor favorabile realizării unui eveniment şi numărul cazurilor
posibile. În cazul de faţă am calculat probabilitatea relativă astfel: mai întâi am
determinat numărul total de vizitatori din perioada luată în considerare (16 săptămâni),
prezentaţi în tabelul de mai sus şi am obţinut rezultatul 6715. Apoi am folosit

62
următoarea formulă: (număr de vizitatori per săptămână)/ (suma vizitatorilor
magazinului virtual din perioada considerată, adică 6715).
Probabilitatea cumulată se obţine astfel: prima valoare este reprezentată
probabilitatea relativă corespunzătoare, iar valorile următoare se obţin prin însumarea
succesivă a probabilităţilor cumulate anterioare ca poziţie, adică după formula:
k
p k = ∑ pi , i = 1,2,...,16 , unde pi reprezintă probabilităţile relative asociate factorilor
i =1

aleatori.
În tabelul de mai jos sunt prezentate valorile obţinute pentru probabilităţile
relative, respectiv cumulate corespunzătoare valorilor analizate. De asemenea au fost
determinate şi intervalele de numere aleatoare corespunzătoare datelor din exemplul
nostru.
PROBABILITATE
NR A PROBABILITAT INTERVAL
SĂPTĂMÂNĂ RELATIVĂ E 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 probabilităţilor relative, adică ultima valoare a probabilităţii cumulate este 1,
atunci calculele corecte. O proprietate de bază din teoria probabilităţilor spune că suma

63
probabilităţilor unei variabile aleatoare este 1. Întrucât ultima valoare din coloana
corespunzătoare probabilităţii cumulate este 1, înseamnă că, până în prezent, calculele
sunt corecte.
Pasul 2: La acest pas voi prezenta graficul corespunzător probabilităţilor
cumulate calculate la pasul anterior. Pe axa Oy se reprezintă valorile probabilităţilor
cumulate, iar pe axa Ox valorile pentru care au fost calculate aceste probabilităţi, adică
numărul de vizitatori ce intră în magazin în fiecare săptămână, valori pe care le avem în
tabelul de mai sus. Pentru fiecare valoare corespunzătoare numărului de vizitatori din
săptămâna respectivă se reprezintă o bară verticală având înălţimea egală probabilitatea
cumulată corespunzătoare.
Probabilitatea cumulată

1,2
0,989 0,998 1
1 0,873
0,755 0,813
0,8 0,667
0,608
0,522 0,563
0,6 0,44 0,483
0,364
0,4 0,287
0,204
0,2 0,088
0
591 778 555 517 511 290 262 277 300 394 592 390 402 782 62 12
Nr vizitatori / săptăm ână

Pasul 3: La acest pas se generează numerele aleatoare uniform repartizate în


intervalul [0,1), utilizând un generator automat de numere aleatoare. În cazul de faţă
numerele au fost generate folosind funcţia RAND() din Excel. În continuare, fiecare

număr obţinut va fi asociat intervalului [ p k −1 ; p k ) . Într-o altă coloană se va trece


numărul de vizitatori pe săptămână corespunzător intervalului din care face parte
numărul aleator generat.
Nr . Nr. Probabilitatea Probabilitate Interval Nr. Nr. Nr.
săpt. viz/săpt relativă cumulată [Pk-1,Pk) Exp. aleator viz/săpt
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

64
6 290 0,043 0,483 [0,44;0,483) 6 0,685 592
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 poziţie şi ai


variaţiei, adică numărul mediu de vizitatori, deviaţia standard, coeficientul de variaţie al
distribuţiei şi intervalul de încredere pentru nivelul de semnificaţie α/2=0,025.
Numărul mediu de vizitatori se va calculează după formula:
N

∑ nrv i
nrmv = i =1

N
Numărul mediu reprezintă valoarea distribuţiei de probabilitate în jurul căreia
fluctuează valorile date.
Deviaţia standard se calculează conform formulei:
N
∑ (nrmv− nrvi )
2

s= i =1

N −1
Deviaţia standard arată cu cât se abat în medie valorile distribuţiei de probabilitate
faţă de numărul mediu. Majoritatea valorilor distribuţiei sunt cuprinse în intervalul
( nrmv − s, nrmv + s )
Pentru N>=30 intervalul de încredere se construieşte cu relaţia :
 s s 
 nrmv − z α / 2 * , nrmv + z α / 2 * 
 N N

unde: α =0,05 se numeşte nivel de semnificaţie; (1-α)=0,95 este probabilitate (deci


α/2=0,025). Estimaţiile de forma intervalelor de încredere ne permit ca pe baza
65
distribuţiei studiate să indicăm intervalul în care se află cuprinsă media, parametrul pe
care dorim să-l estimăm, cu o probabilitate apropiată de 1.
Valoarea distribuţiei normale zα/2=1,96 se găseşte în tabelul distribuţiei “t”
(Student), pe ultima linie a acestuia.
Coeficientul de variaţie se calculează după formula:
s
Cv % = ⋅ 100
nrmv

După cum se observă din formula de mai sus coeficientul de variaţie al unei
distribuţii este raportul dintre deviaţia standard şi medie. Coeficientul de variaţie ne
arată ce procent din medie reprezintă abaterea standard. Dacă CV%>20% spunem că
distribuţia prezintă o variaţie mare.
Pentru o mai bună înţelegere a rezultatelor, pe lângă 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ă părţi egale. Valoarea modală este acea
valoare a variabilei căreia îi corespunde frecvenţa cea mai mare de apariţie şi se mai
numeşte modul sau valoare dominantă.

Valorile obţinute în cazul exemplului nostru sunt sintetizate în tabelul de mai jos:

Număr de vizitatori
Date valide 16
Date invalide 0
Valoarea medie 431
Valoarea mediană 517
Valoarea modală 390
Deviaţia standard 249,1464
Coeficientul de
variaţie 57,80%
Valoarea minimă 262
Valoarea maximă 778

66
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 funcţionare.
Numărul mediu al vizitatorilor site-ului în decursul unei săptămâni se va situa în
jurul valorii de 431, cu o abatere de ± aprox. 249 vizitatori. Mai exact, numărul mediu
de vizitatori ai site-ului va oscila în intervalul (181,8536 ; 680,1464).
Având în vedere că valoarea coeficientului de variaţie este de 57,80%, putem
spune că un procent de 57,80% din numărul mediu de vizitatori estimaţi pe săptămână se
abate de la valoarea medie estimată de 431 viz./săpt. Acest lucru ne demonstrează faptul
că distribuţia numărului de vizitatori are o variaţie mare.
De asemenea, rezultatele simulării ne duc la concluzia că numărul minim de
vizitatori pe săptămână va fi de 262, în timp ce numărul maxim va atinge valoarea de
778. De asemenea, valoarea cu cea mai mare frecvenţă a numărului de vizitatori este
390, ceea ce înseamnă că în cele mai multe săptămâni site-ul va fi vizitat de un număr de
390 de vizitatori.

CONCLUZII ŞI PROPUNERI

Obiectivul acestei lucrări constă în prezentarea fundamentelor teoretice şi practice


care stau la baza dezvoltării unei afaceri virtuale, în particular a unei aplicaţii de food-
ordering care să faciliteze procesul de comandare on-line de preparate culinare de la
furnizorii care asigură livrarea la domiciliu.
În cadrul lucrării de faţă, plecând 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 menţionat faptul că aplicaţia prezentată reprezintă un prototip, aflându-se
încă în faza de implementare, scopul principal al lucrării de faţă fiind evidenţierea
67
facilităţilor oferite de o astfel de aplicaţie. Odată terminată etapa de implementare, vor
urma fazele de testare, publicare şi promovare a versiunii prototip. Testarea se va face de
către un grup restrâns de persoane, reprezentanţi ai celor trei categorii de utilizatori
cărora li se adresează aplicaţia, şi anume vizitatori, clienţi şi furnizori, urmărindu-se
corectitudinea operaţiilor efectuate de aplicaţie, măsura în care utilizarea ei este
intuitivă, precum şi măsura în care satisface necesităţile 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 identităţi on-line. Din momentul în care aplicaţia va deveni
funcţională în totalitate şi va fi pusă la dispoziţia publicului larg, prin publicarea ei pe
internet, se va trece la faza de promovare, utilizând atât metode ale marketing-ului
clasic, cât şi ale marketing-ului electronic: promovarea prin intermediul motoarelor de
căutare, schimbul de bannere, schimbul de link-uri, promovarea prin e-mail, precum şi
publicarea adresei site-ului pe toate materialele promoţionale ale furnizorilor care vor fi
înscrişi în aplicaţie, precum şi în publicaţiile de specialitate.
În ceea ce priveşte îmbunătăţirile care s-ar putea aduce aplicaţiei de food-ordering
în etapele de dezvoltare ulterioară, printre acestea se numără:
■ implementarea unui sistem de plăţi electronice;
■ implementarea unui forum având ca temă principală reţetele culinare;
■ implementarea unei interfeţe mai atractive, dar care să nu solicite resurse
hardware mari;
■ realizarea unui top al celor mai vândute produse, al celor mai solicitaţi
furnizori sau al celor mai fideli clienţi;
■ implementarea unor instrumente care să ofere furnizorilor statistici privind
numărul de clienţi şi produsele comandate.
G.B. Shaw definea economia ca fiind „arta de a obţine maximum de la viaţă”.
Pentru a fi într-adevăr eficienţi în obţinerea maximizării, trebuie mai întâi să învăţăm să
ne gestionăm timpul într-un mod cât mai eficient. Societatea de azi se caracterizează

68
prin viteză. În această situaţie, timpul devine o resursă limitată, iar gestionarea lui cât
mai eficientă devine una din principalele căi de obţinere a succesului în afaceri. În aceste
condiţii, aplicaţia prezentată oferă o modalitate eficientă de satisfacere a necesităţilor
utilizatorilor săi cu un consum minim din resursa cea mai râvnită, timpul.

BILIOGRAFIE

Publicații și cursuri:
1. S. Buraga, “Tendinţe actuale în proiectarea şi dezvoltarea aplicaţiilor Web”, Iaşi,

26-27 noiembrie 2005

2. V. Cotelea, "Baze de date relaţionale – proiectare logică". – Chişinău, Editura ASEM, 1997;

3. P.BuBois, „MySQL”, Ed. Teora, Bucureşti, 2001

4.C.Raţiu-Suciu, Modelarea şi Simularea proceselor economice”, Editura Economică,Bucureşti, 2003

5. S. Buraga , Aplicaţii Web la cheie, Ed. Polirom, Iaşi, 2003

6. Welling, L. Thomson, Dezvoltarea Aplicaţiilor Web cu PHP şi MySQL, Editura Teora, Bucureşti,

69
2003

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

Legislație:

Legea Nr.284/ 22.07.2004, privind comerțul electronic

Legea Nr.264- XV din 15.07.2004, cu privire la documentul electronic și semnătura 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

70