Proiectarea Aplicatiilor de Comert Electronic. Aplicatie de Food Ordering

CUPRINS

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

Metoda utilizată în stabilirea cerințelor aplicației are la bază un studiu al pieței aplicațiilor care oferă servicii de comenzi on-line de preparate culinare. Rezultatele studiului s-au materializat în enunțarea avantajelor și dezavantajelor aplicațiilor studiate pentru o mai bună modelare și înțelegere a cerințelor beneficiarilor.

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. Această soluție se remarcă dintre cele tradiționale prin costul redus al dezvoltării software datorită gratuității celor trei produse (este posibilă o eventuală licență pentru serverul de baze de date MySQL), rapiditatea în dezvoltare și ușurința în întreținere a aplicațiilor create.

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

PHP satisface nevoia unui limbaj server-side puternic la implementarea nivelului de logică a aplicației datorită combinării unei sintaxe relaxate cu construcții puternice de limbaj și datorită faptului că beneficiază de o librărie de extensii considerabilă. Este bine cunoscut suportul oferit pentru interacțiunea cu un server de baze de date MySQL, așa cum este bine cunoscut și tandemul pe care PHP și MySQL îl formează ca soluție rapidă la cererea crescândă de site-uri ce afișează conținut dinamic. Ușurința în folosire a PHP-ului se datorează în principal modelului ales în implementarea paradigmei generării dinamice de conținut Web. Din funcțiile puternice oferite de PHP se pot deriva cu ușurință scripturi particularizate care să implementeze regulile de funcționare a aplicației în ceea privește managementul datelor stocate într-o bază de date MySQL.

Referitor la soluția aleasă pentru implementarea nivelului de date al aplicației, trebuie menționat că serverul de baze de date MySQL depășește competiția prin rapiditatea în execuție (mai ales pentru sistemul de operare Linux) și securitatea sporită.

Î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ă. Totuși, în urma studiilor efectuate, având în vedere faptul că un asemenea sistem ar presupune eforturi financiare suplimentare atât din partea furnizorului (taxă de conectare la serviciu + taxă lunară de procesare a plăților + comision din încasări) cât și din partea consumatorului (taxă de conectare la serviciu + taxă lunară de administrare cont), coroborat cu faptul că acest tip de afacere presupune contactul direct între furnizori și consumatori în momentul livrării produselor (moment în care se poate realiza și încasarea contravalorii produselor furnizate), consider că implementarea unui astfel de sistem nu ar aduce beneficii suplimentare considerabile pentru aplicație. 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.

Urmărind o abordare tehnico-economică, lucrarea este fundamentată științific pe arhitectura a cinci capitole.

În primul capitol am prezentat aspectele economice fundamentale care stau la baza afacerilor electronice. După o analiză succintă a noii tendințe în economie, am încercat o definire a conceptelor de „afaceri electronice”, respectiv „comerț electronic”. Pentru o mai bună înțelegere a fenomenului am realizat o prezentare a tuturor modelelor de afaceri electronice, respectiv de comerț electronic care funcționează la ora actuală în lume, am analizat avantajele și dezavantajele comerțului electronic, punctând totodată problemele și piedicile cu care se confruntă astfel de modele de afaceri. În final am realizat o analiză a evoluției și tendințelor comerțului electronic pe piața din România.

Cel de-al doilea capitol se dorește a fi un liant între fundamentarea teoretică din punct de vedere economic și dezvoltarea efectivă a aplicației. În acest capitol am vorbit la modul general despre arhitectura unui sistem de comerț electronic, prezentând pașii care ar trebui urmați în implementarea unui astfel de sistem, urmând ca în capitolele următoare să aplic efectiv acești pași în dezvoltarea propriei aplicații. De asemenea, la sfârșitul capitolului am încercat fundamentarea din punct de vedere teoretic a modului de organizare și funcționare a unu Sistem Electronic de Plăți, considerând că acest lucru va constitui o bază riguroasă în procesul de dezvoltare ulterioară a aplicației.

Având în vedere că o lucrare trebuie fundamentată nu numai din punct de vedere economic, ci și tehnic, în capitolul al treilea am realizat o prezentare succintă a tehnologiilor și instrumentelor informatice utilizate în dezvoltarea aplicației. Am început prin a descrie arhitectura client/server, arhitectură care stă la baza aplicației prezentată în lucrarea de față, continuând cu descrierea succintă a instrumentelor utilizate și a motivației care a stat la baza alegerii lor. De asemenea, în acest capitol am descris procesul pe care s-a bazat dezvoltarea aplicației, proces structurat pe două dimensiuni: dimensiunea temporală (care induce fazele de lansare, elaborare, construcție, tranziție) și componentele procesului (modelarea afacerii, identificare cerințelor, analiza și proiectarea, implementarea și testarea).

După fundamentarea tehnico-economică a aspectelor teoretice, în capitolul al patrulea am prezentat etapele de dezvoltare a aplicației de food-ordering. Astfel, am explicat detaliat modalitățile de analiză a cerințelor, de proiectare a aplicației și de implementare a acesteia. În faza de analiză, plecând de la studiul pieței, am modelat necesitățile utilizatorilor cu ajutorul cazurilor de utilizare. În faza de proiectare am urmărit etapele procesului de design conceptual (stabilirea arhitecturii aplicației, realizarea prototipului de interfață, proiectarea schemei conceptuale a bazei de date) și fizic (prezentarea componentelor aplicației, a diagramelor de activitate și a modelului fizic al bazei de date). În faza de implementare am descris modalitatea de realizare efectivă a celor trei nivele ale aplicației (nivelul de prezentare, de logică a aplicației și nivelul de date) cu ajutorul soluției Apache + MySQL + PHP.

Întrucât un ultim pas în dezvoltarea unei afaceri ar trebui să-l constituie determinarea eficienței economice a acesteia, în capitolul al cincilea am încercat să aplic metode specifice modelării și simulării proceselor economice în vederea estimării succesului aplicației. Pentru aceasta, am utilizat metoda Monte Carlo în procesul de simulare a numărului mediu de utilizatori ai aplicației pe săptămână, pornind de la datele furnizate de site-ul de monitorizare www.trafic.ro. Am efectuat acest studiu pornind de la premisa că succesul unui site poate fi cel mai bine estimat prin numărul de vizitatori ai săi, care pot reprezenta potențiali cumpărători ai produselor oferite.

Lucrarea se încheie cu un capitol de concluzii și perspective în care am subliniat importanța temei abordate în cadrul acestei lucrări în procesul de dezvoltare a mediului virtual de afaceri. În cadrul acestui ultim capitol am adus argumente în favoarea dezvoltării afacerilor electronice, considerând că acest tip de afaceri are un potențial foarte mare datorită avantajelor care le oferă atât consumatorilor, cât și vânzătorilor. De asemenea, am prezentat și direcțiile de dezvoltare ulterioară a aplicației, știut fiind faptul că realizarea unei aplicații constă într-un proces continuu de analiză și adaptare la nevoile mereu schimbătoare ale utilizatorilor.

CAPITOLUL I

CONCEPTE GENERALE DE COMERȚ 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 realizarea prototipului de interfață, proiectarea schemei conceptuale a bazei de date) și fizic (prezentarea componentelor aplicației, a diagramelor de activitate și a modelului fizic al bazei de date). În faza de implementare am descris modalitatea de realizare efectivă a celor trei nivele ale aplicației (nivelul de prezentare, de logică a aplicației și nivelul de date) cu ajutorul soluției Apache + MySQL + PHP.

Întrucât un ultim pas în dezvoltarea unei afaceri ar trebui să-l constituie determinarea eficienței economice a acesteia, în capitolul al cincilea am încercat să aplic metode specifice modelării și simulării proceselor economice în vederea estimării succesului aplicației. Pentru aceasta, am utilizat metoda Monte Carlo în procesul de simulare a numărului mediu de utilizatori ai aplicației pe săptămână, pornind de la datele furnizate de site-ul de monitorizare www.trafic.ro. Am efectuat acest studiu pornind de la premisa că succesul unui site poate fi cel mai bine estimat prin numărul de vizitatori ai săi, care pot reprezenta potențiali cumpărători ai produselor oferite.

Lucrarea se încheie cu un capitol de concluzii și perspective în care am subliniat importanța temei abordate în cadrul acestei lucrări în procesul de dezvoltare a mediului virtual de afaceri. În cadrul acestui ultim capitol am adus argumente în favoarea dezvoltării afacerilor electronice, considerând că acest tip de afaceri are un potențial foarte mare datorită avantajelor care le oferă atât consumatorilor, cât și vânzătorilor. De asemenea, am prezentat și direcțiile de dezvoltare ulterioară a aplicației, știut fiind faptul că realizarea unei aplicații constă într-un proces continuu de analiză și adaptare la nevoile mereu schimbătoare ale utilizatorilor.

CAPITOLUL I

CONCEPTE GENERALE DE COMERȚ 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).

Noua economie marchează o transformare fundamentală în istoria dezvoltării societății omenești, și se estimează că durata tranziției de la societatea industrială la societatea globală rețelizată,  bazată pe cunoștințe, va fi între 20 și 30 ani.

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

Piața Internetului rămâne o piață de cucerit de către întreprinderi, o posibilitate pentru noi oportunități, inclusiv prin diversificarea serviciilor oferite și promovarea de servicii noi, personalizate și atractive, pe care tehnologiile informaționale și de comunicații le fac posibile, ceea ce stimulează concurența și competitivitatea prin apariția de noi actori pe piețele tradiționale.

Internetul reduce importanța distanței și timpului. „Moartea distanței” și „comprimarea timpului”, care sunt unele din „efectele Internetului”, pot fi considerate printre cele mai importante schimbări care modelează în prezent societatea omenească.

Apariția Internet-ului este, probabil, cel mai important eveniment de la sfârșitul secolului XX din punct de vedere al impactului în economie și societate.

După unii autori prezența pe Internet a firmelor poate fi realizată în șase stadii:

„Conectare on-line” – în această fază, compania are o simplă pagină web, în spatele căreia nu există o structură reală.

„WebSite structurat” – website-ul are o structură mai elaborată, se poate folosi un motor de căutare după cuvinte cheie, se pot vizualiza informații despre companie și se pot schimba mesaje în mod interactiv cu aceasta.

„Încercări de e-commerce” – compania încearcă să vândă on-line informații, mărfuri, etc. Sistemul nu este conectat la bazele de date interne de pe Intranet. Este lent, costisitor și nu este sigur. Nu există posibilitatea trecerii de la sistemul „back-end” al companiei proprii la sistemul „back-end” al altei firme.

„Realizarea de e-business” – Website-ul are o legătură directă cu sistemul de pe Intranet, permite extragerea de informații din bazele de date interne și folosește protocoale securizate de transmitere a datelor între compania proprie și client sau către o altă organizație. Se pot face economii și poate începe obținerea de profit bazat pe utilizarea tehnologiilor on-line.

„E-business extensiv” – Folosind orice dispozitiv care conține un cip (telefon celular, mașină, etc) personalul companiei, clienții și furnizorii se pot conecta la datele companiei și pot transmite sau primi informațiile dorite pentru e-business.

„O lume – Un calculator” – Toate dispozitivele bazate pe cipuri vor fi interconectate și se va crea o resursă de informații uriașă. Dispozitivele sunt capabile să schimbe între ele orice tip de informații.

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

Scopul modelelor de e-business este de a reprezenta într-un mod cât mai accesibil tipul de  afacere și arhitectura sistemului (topologia aplicației și topologia de rulare) pentru diferite clase de aplicații. Aceste modele descriu interacțiunea dintre participanții la o soluție de e-business. 

În momentul de față sunt definite șase modele de e-business:

Modelul User-to-Business (U2B): Este cazul general în care un utilizator (intern sau extern) interacționează asupra datelor și tranzacțiilor unei î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.

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.

Modelul Business-to-Business (B2B): Este folosit pentru a descrie două tipuri de interacțiune între două întreprinderi:

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;

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.

Modelul User-to-User (U2U): Descrie cazul colaborării diferiților utilizatori prin intermediul documentelor partajate, prin e-mail, etc.

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.

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.

Noile modele de afaceri au un rol catalizator pentru modificări organizaționale, noi modele de organizare a producției și de tranzacționare a afacerilor, și permit firmelor mici și mari să intre pe piața electronică națională și internațională.

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 pot livra” deoarece oferă consumatorului o gamă largă de produse, indiferent cine le produce.

1.3 Modele de comerț electronic

Analizând aplicațiile curente dezvoltate pe Internet, identificăm următoarele modele de afaceri în comerțul electronic:

magazin electronic (e-shop): un magazin electronic se implementează prin intermediul unui site Web; acesta este gestionat de companie, pentru marketingul și vânzările propriilor produse și servicii. Minimal, conține catalogul de produse sau servicii cu descrieri tehnice și comerciale pentru fiecare poziție din catalog. Aceste descrieri sunt gestionate în general de un Sistem de Gestiune a Bazelor de Date (SGBD). Sistemul de Gestiune a Bazelor de Date se va ocupa cu stocarea și manipularea datelor și cu oferirea posibilităților de acces la date. Varianta medie conține facilități pentru preluarea comenzilor (prin e-mail sau formulare interactive pe care le vor completa clienții), iar varianta extinsă cuprinde și posibilitatea efectuării on-line a plății (prin cărți de credit sau alte variante electronice); 

aprovizionarea electronică (eProcurement): pentru procurarea bunurilor și serviciilor, marile companii și autorități publice organizează licitații. Prin publicarea pe Web a specificațiilor ofertei scade atât timpul cât și costul de transmisie, mărindu-se și numărul de firme care iau parte la licitație. Astfel, crește concurența și scade prețul;

magazin electronic universal (eMall): ca și în lumea reală, magazinul electronic universal este o colecție de magazine electronice, reunite sub o umbrelă comună și care, în general, acceptă metode de plată comune;

piața unui terț (3rd party marketplace): se apelează la o interfață utilizator pentru catalogul de produse al companiei, interfață ce aparține unui terț (în general, un furnizor de servicii Internet sau o bancă). Această metodă are avantajul că interfața este unică pentru mai mulți producători, utilizatorii fiind familiarizați cu utilizarea ei;

comunități virtuale (virtual communities): valoarea cea mai importantă a unei comunități virtuale este dată de către membrii săi (clienți sau parteneri), care adaugă informații proprii peste un mediu de bază furnizat de companie. Fiecare membru poate oferi spre vânzare produse sau servicii sau poate adresa cereri de cumpărare a unor produse sau servicii. Calitatea de membru al unei comunități virtuale presupune plata unei taxe;

furnizor de servicii cu valoare adăugată pentru canalele de comerț electronic (value chain service provider): furnizorii de servicii sunt specializați pe funcții specifice, cum ar fi asigurarea logisticii, plata electronică sau expertiza în managementul producției și a stocurilor. Plata acestor servicii se face pe baza unor tarife sau a unei cote procentuale;

platforme de colaborare: platformele de colaborare cuprind un set de instrumente și un mediu informațional pentru colaborarea între companii. Acestea pot adresa funcții specifice, cum ar fi concepția sau proiectarea în colaborare. Câștigurile provin din managementul platformei (taxa de membru sau taxa de utilizare), și din vânzări de instrumente specializate (pentru design, workflow și gestiunea de documente). Prin workflow se înțelege fluxul de documente, care implică două entități: o parte pasivă (documentele) și o parte activă (deplasarea acestor documente);

brokeraj de informații și alte servicii: exemplele cuprind cataloage de clienți clasificați pe profil, vânzarea de oportunități de afaceri, consultanță în domenii specializate. O categorie specială o constituie serviciile de încredere furnizate de autoritățile de certificare sau de notariatele electronice.

1.4 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. În urma întâlnirii dintre cerere și ofertă consumatorul va primi produsul, iar producătorul va încasa contravaloarea acestuia, respectiv producătorul va factura contravaloarea serviciului prestat către consumator, urmând să încaseze suma aferentă.

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;

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

1.5 Aspecte critice 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;

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.6 Comerțul electronic în România: evoluție și tendințe

România este singura țară din răsăritul Europei în care funcționează comerțul electronic (on-line) prin intermediul card-ului bancar. Nici Polonia, nici Cehia, Ungaria sau alte țări mai avansate nu au create condițiile pentru funcționarea acestui sistem comod de plată a produselor și serviciilor, reprezentat prin comerț electronic .

Cei interesați, adică statul, băncile și comercianții, nu fac publicitate sistemului, iar populația nu este informată. Cu toate acestea, situația poate evolua extrem de spectaculos în următorii trei ani.

Volumul tranzacțiilor on-line intermediate de sistemul 3D Secure românesc, unde plata se efectuează prin card, a crescut continuu după lansarea sa, în martie 2004, ajungând la suma de patru milioane de dolari în aprilie 2005. Valoarea pentru comerțul electronic ar putea ajunge, la sfârșitul acestui an, la 80 milioane de euro, ponderea covârșitoare, de aproximativ 90%, fiind deținută de tranzacțiile operate de către clienții din afara țării.

În România există mai mult de 500 de site-uri care derulează tranzacții în sistem electronic (din care numai 160 active – înregistrate în sistemele de plată on-line). Comerțul electronic înregistrează o rată de creștere lunară foarte mare, de 17-20%.

Tendința comerțului electronic românesc este ascendentă. Numărul magazinelor virtuale crește vertiginos, ca și numărul clienților care fac cumpărături on-line. Potrivit RomCard, în primele cinci luni din 2005 s-au efectuat aproximativ 138.000 de tranzacții în sistem 3D Secure, valoarea cumpărăturilor generate de aceste tranzacții ridicându-se la 26 milioane USD. În 2004, posesorii de carduri VISA emise în România au efectuat 33.742 de tranzacții în valoare totală de 4.565.440 USD. Dintre acestea, valoarea tranzacțiilor făcute în România a fost sub 6%.

Media tranzacțiilor se învârte în jurul a 45.000 pe lună, ceea ce înseamnă că la sfârșitul anului ne vom apropia de jumătate de milion. Însă din valoarea totală a tranzacțiilor procesate prin RomCard în sistem 3D Secure, cardurile românești generează sub 10%. Nu toate magazinele virtuale sunt înrolate, însă, în sistemul 3D Secure.

La 4 milioane de utilizatori Internet și 6 milioane deținători de carduri de debit (majoritatea) și credit, valoarea tranzacțiilor cu cardurile emise în România a crescut de la 1,8 milioane de euro, în 2003, la 2,8 milioane în 2004. Toți acești utilizatori au acces direct la comerț electronic.

În Martie 2005 erau înregistrați 56.100 de abonați ai instrumentelor de plată cu acces la distanță, de patru ori mai mulți față de 2003. În prezent, 160 de comercianți sunt înregistrați și se așteaptă ca numărul acestora să crească la 300 până la sfârșitul acestui an. De asemenea, nici numărul clienților care preferă plata prin card nu este foarte mare, mulți optând încă pentru tipul de plată „cash on delivery” (sau ramburs, folosind termenul românesc). S-ar putea spune, deci, că în materie de comerț electronic românul încă nu a prins „gustul”.

Privită sub raportul cifrelor, evoluția fenomenului de „comerț electronic” în țara noastră arată astfel:

în 2004 magazinele virtuale înregistrau cifre de afaceri de 200.000 de euro; în primul trimestru din 2005 acestea s-au dublat;

în 2001 s-au înregistrat 193.413 pagini de comerț electronic vizitate, vizualizate de 10.538 de persoane; în luna mai 2005 s-au afișat 4.184.094 de pagini de comerț electronic vizitate de 491.817 persoane.

În total, în fiecare săptămână, aproape 400.000 de utilizatori români de Internet vizitează site-urile de comerț electronic din România.

Analizând cifrele de mai sus se poate spune că numărul magazinelor virtuale autohtone de comerț electronic este în continuă creștere, la fel ca și sumele tranzacționate. De asemenea, standardele de securitate sunt la nivel internațional, modalitățile de plată sunt aceleași ca peste tot în lume, produsele la fel. Concluzia pe care o putem trage este următoarea: este doar o problemă de încredere și promovare până când românii își vor îndrepta atenția către site-urile românești de comerț electronic.

CAPITOLUL II

DEZVOLTAREA UNUI SISTEM DE COMERȚ ELECTRONIC

2.1 Arhitectura unui sistem de comerț electronic

Pentru a construi un sistem de e-commerce, din punct de vedere arhitectural este nevoie de colaborarea a patru componente (subsisteme electronice/informatice) corespunzătoare următoarelor roluri:

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.

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.

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.

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), poartă prin care accesul este controlat de un „portar” (gatekeeper); pe baza informațiilor specifice cărții de credit (tip_card, nr_card) din instrucțiunile de plată „portarul” redirecționează informația către un centru de carduri (CC – un server certificat în acest scop și agreat de banca emitentă); în acest loc este identificată banca emitentă a cardului, iar instrucțiunile de plată sunt trimise mai departe către serverul acestei bănci conectat în rețeaua interbancară; odată informațiile ajunse în rețeaua băncii cu care lucrează cumpărătorul, sunt efectuate (automat) o serie de verificări privind autenticitatea și soldul disponibil în contul cardului implicat în tranzacție; în funcție de rezultatul acestor verificări, banca decide fie efectuarea plății (transfer bancar – către contul comerciantului care poate fi deschis la orice altă bancă), fie refuză să facă această plată; în ambele cazuri, rezultatul deciziei (confirmare plată sau refuz) este trimis în timp real, parcurgând acest lanț de servere în sens invers, către client; cu alte cuvinte, în câteva secunde cumpărătorul află dacă banca sa a operat plata sau nu.

2.2 Etapele implementării unui sistem de comerț electronic

Realizarea unui sistem de comerț electronic, indiferent de modelul pe care îl implementează (business-to-consumer B2C sau business-to-business B2B) implică mai multe etape:

2.2.1 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. De asemenea, trebuie să se aibă în vedere stabilirea unei structuri de aprobatori (organizată ierarhic), care să se ocupe de aprobarea conținutului nou care va fi adăugat în cadrul diferitelor domenii ale site-ului. Conținutul va fi adăugat de către utilizatori interni (aparținând intranetului companiei) sau externi (din Internet, de exemplu).

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 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, topologii 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 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. Firmele care se bazează pe informații, cum sunt cele care tipăresc rapoarte, pot da un comunicat de presă prin care anunță un important produs informațional. Firmele care nu activează în sectorul informațional pot de asemenea să transmită informații care să se adreseze consumatorilor și clienților potențiali. Cumpărătorii și potențialii clienți pot citi aceste articole gratis, iar dacă știu că site-ul este actualizat în mod regulat, ei se vor întoarce periodic și își vor anunța și cunoscuții despre această caracteristică a site-ului.

Informarea utilizatorilor prin e-mail, atunci când se actualizează conținutul site-ului: Se recomandă ca site-urile să își înștiințeze clienții la fiecare actualizare a conținutului lor pentru ca vizita pe care au repetat-o să capete valoare și să rezulte o încurajare a revenirii lor pe site. Site-ul poate furniza clienților săi informații în legătură cu modificările efectuate prin intermediul adreselor de e-mail pe care le dobândește, de regulă, în momentul în care clienții subscriu la site. Utilizarea unei astfel de tactici ajută la crearea unei baze de date cu ajutorul căreia se vor determina nevoile și cerințele clienților, fapt ce va conduce în final la creșterea vânzărilor.

Dintre metodele consacrate de marketing pe Internet si reclamă on-line, promovarea site-urilor Web prin intermediul motoarelor de căutare s-a impus la ora actuală ca fiind cea mai profitabilă variantă de publicitate pe Internet, în primul rând datorită costurilor zero, în al doilea rând datorită vizitatorilor de calitate pe care ii garantează această metodă de ridicare a audienței site-urilor Web.

Motoarele de căutare sunt programe special proiectate să exploreze Web-ul, deplasându-se automat de la un site la altul pe calea legăturilor existente între acestea. Nu avem de-a face cu intervenția operatorului uman, în general întregul proces de investigare a Web-ului, culegere de informații și clasificare a acestora realizându-se prin mijlocirea robotului.

Directoarele Web diferă de motoarele de căutare prin aceea că se constituie în fapt ca și colecții de site-uri investigate și clasificate de operatori umani.

În condițiile în care se optează pentru aceste metode de promovare, ar fi bine ca mai întâi să se efectueze înscrierea în directoarele Web și după aceea în motoarele de căutare. Explicația constă în faptul că este total nerecomandată utilizarea oricăror tehnici de optimizare mai mult sau mai puțin artificiale atunci când site-ul urmează să fie revizuit de un operator uman.

2.2.2 Etapa a II-a: Managementul bazelor de date

Produsele și serviciile pe care site-ul de comerț electronic le oferă spre 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 deveni prohibitiv.

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

2.2.4 Etapa a IV-a: Managementul produselor și al comenzilor

Transportul produselor: În cazul în care site-ul de comerț electronic al companiei oferă spre 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.

2.2.5 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

2.3.1 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ă. Sunt implicate, în general, trei entități care interacționează: o bancă B, un cumpărător C și un vânzător V. Sistemul electronic de plăți conține și o mulțime de protocoale care permit cumpărătorului C să facă plăți către vânzătorul V.

Un Sistem Electronic de Plăț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 foarte 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ă.

2.3.2 Dispozitive folosite într-un Sistem Electronic de Plăți

Există mai multe tipuri principale de dispozitive folosite:

portofelul electronic: este folosit de către cumpărător pentru a stoca banii electronici. Există următoarele configurații fundamentale:

calculator „de mână” (hand-held computer): reprezintă un calculator de dimensiuni reduse aflat în posesia clientului. Băncile sunt neliniștite de controlul total al utilizatorului asupra resurselor dispozitivului de plată. Conectarea la punctele de acces ale SEP se face de obicei printr-o legătură serială în infraroșu;

cartela inteligentă (smartcard): constă dintr-un cip încorporat într-o cartelă de plastic. Spre deosebire de o cartelă de credit obișnuită, un smartcard dispune de un microprocesor. Comunicația cu punctul de acces se face prin contact direct cu cititorul de cartelă. Utilizatorul nu are acces la resursele hard și soft, fapt care avantajează băncile. Este imposibilă „deschiderea” smartcard-ului și efectuarea unui „reverse-engineering” (adică o metodă de a afla modul în care a fost construită cartela prin dezasamblarea sa și parcurgerea în sens invers a pașilor care se presupune că s-au urmat la creare);

portofel electronic cu observator: structură formată din două calculatoare: calculatorul clientului, prin care acesta comunică cu punctul de acces al SEP, și un calculator al băncii, încorporat în cel al clientului, care previne dubla cheltuire a banilor electronici;

punctul de vânzare (POS): este folosit de către vânzător pentru a stoca banii electronici temporar. Din punct de vedere tehnic, are interfețe atât serială, prin infraroșu sau wireless (local sau prin GSM/GPRS sau CDMA) cât și un cititor de smartcard/card magnetic;

distribuitorul de bani electronici: dispozitivul prin care se încarcă bani electronici în portofelul electronic al cumpărătorilor. Moduri de implementare: 

distribuitor cont-bani electronici: soluție care permite incrementarea valorii din portofel pe baza retragerii unei sume de bani reali din contul deschis de cumpărător;

distribuitor carte de credit-bani electronici: permite incrementarea valorii din portofel pe baza creditării cumpărătorului de către o casă de credit; 

distribuitor numerar-bani electronici: permite incrementarea valorii portofelului prin colectarea de la cumpărător a unei sume cash.

2.3.3 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;

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.3.4 Modalități de plată

Sistemele electronice de plăți trebuie să atingă nivele ridicate de securitate, viteză, caracter privat și confidențial, descentralizare și internaționalizare și să fie unanim acceptate de comercianți și oameni de afaceri. O trăsătură comună a majorității acestor soluții o constituie utilizarea tehnicilor criptografice care asigură confidențialitatea, autenticitatea și integritatea mesajelor transferate între entitățile implicate. 

În continuare sunt analizate câteva dintre cele mai cunoscute metode de plată electronică: 

Plata prin carduri bancare 

Sistemul de carduri a fost creat cu intenția de a-i permite cumpărătorului să-și satisfacă imediat dorința de cumpărare de bunuri și servicii. Prin cartea de credit, riscul este transferat de la vânzător la instituția financiară care a emis cartea de credit. Procesul cuprinde următorii pași: 

cumpărătorul prezintă vânzătorului cartea de credit;

vânzătorul trimite numărul cărții de credit și detaliile tranzacției la un sistem de autorizare;

acesta fie autorizează direct tranzacția, fie o direcționează la banca emitentă a cărții de credit, pentru aprobare;

periodic (de exemplu zilnic), vânzătorul trimite detaliile tranzacțiilor aprobate către banca sa;

aceste informații sunt trimise la asociația emițătorilor de cărți de credit după ce au fost procesate tranzacțiile pentru care banca respectiva este și colectoare și emițătoare de cărți de credit;

la sfârșitul lunii, consumatorul primește facturile pe care trebuie să le achite, altfel va plăti dobânda pentru creditul acordat de banca emitentă a cărtii de credit.

Plata prin SoftNet ePay 

În România plata directă prin card pe Internet este periculoasă datorită nivelului potențial ridicat de fraudă. Băncile nu acceptă în general plăți prin card-uri pe Internet decât, eventual, cu asumarea totală a riscului de către comerciant. Se folosește mai mult plata prin ATM, dar aceasta nu are aceleași beneficii cu plata on-line. 

ePay este un sistem românesc realizat de către SoftNet, care permite reducerea nivelului de fraudă cât mai aproape de zero astfel:

a fost introdus un model de plată cu trei actori: magazinul electronic, posesorul de card (clientul) și banca ce a emis cardul și al cărei client este posesorul de card;

posesorul de card semnează electronic la bancă fiecare tranzacție. Doar tranzacțiile acceptate de către acesta și marcate ca atare de către bancă sunt autorizate;

plata efectivă se efectuează doar după ce datele privind plata transmise de magazinul electronic sunt comparate cu cele înregistrate de client și se constată o corespondență perfectă. 

ePay are următoarele caracteristici:

numerele de card nu circulă prin Internet și nu se stochează nici la client nici în magazinul electronic;

clientul nu poate folosi alte card-uri decât cele deținute oficial la bancă. Prin urmare, nu se pot introduce numere de card furate;

clientul nu poate nega efectuarea unei plăți. Fiecare acceptare de plată este semnată electronic și înregistrată la bancă;

autorizarea plății se face instantaneu, comunicația între cele trei entități implicate făcându-se prin Internet (cu criptare și autentificare).

Un scenariu tipic de utilizare a sistemul de plată sigur prin Internet ePay este următorul:

clientul accesează cu un browser, prin Internet, magazinul electronic. Aici alege produsele dorite și le selectează pentru a fi introduse în coșul virtual de cumpărături;

clientul, după ce a finalizat alegerea produselor, trece în pagina de plată electronică. Aici selectează opțiunea „Plată prin ePay”;

pe stația clientului se deschide o aplicație de tip portofel electronic. Aceasta se conectează la bancă și solicită autentificarea clientului (nume/parolă și token VASCO). După validarea cu succes, portofelul electronic prezintă clientului lista cardurilor pe care acesta le deține la bancă, invitându-l să selecteze unul dintre card-uri pentru plata solicitată. Cardul selectat, împreună cu informații privind plata (sumă, magazin, id_comandă) sunt înregistrate în serverul ePay de la bancă;

în portofelul electronic clientul aprobă plata. Portofelul electronic se închide, cedând controlul din nou magazinului electronic, transmițându-i identificatorul acceptului clientului în sistemul ePay. Magazinul electronic solicită băncii efectuarea efectivă a plății, transmițând împreună cu solicitarea și informațiile legate de plată (sumă, magazin, ID comandă);

ePay preia solicitarea și compară informațiile trimise de magazin cu cele transmise de către client. Dacă acestea corespund întocmai, se efectuează plata în sistemul bancar (prin emularea unei tranzacții obișnuite POS);

dacă tranzacția s-a efectuat cu succes se transmite un mesaj de succes către magazinul electronic. Aceasta transmite această informație către aplicațiile de procesare de comenzi ale operatorului magazinului. 

Plata prin CyberCash 

Pentru a efectua plăți prin CyberCash (adresa de Internet: www.cybercash.com), consumatorul are nevoie de un software care simulează „portofelul”, face criptarea mesajelor și memorează tranzacțiile. Ca și portofelul obișnuit, acest portofel-software poate înregistra mai multe cărți de credit. La instalarea software-ului, se generează o pereche de cheie publică – cheie privată. Cheia publică se transmite la CyberCash care o memorează într-o bază de date, alături de toate cheile publice ale vânzătorilor și clienților. Vânzătorul are un software similar. Cumpărătorul și vânzătorul trebuie să facă schimb de chei înainte de a ști cu ce cheie publică să cripteze mesajul adresat unui anumit corespondent.

Derularea unei tranzacții este compusă din următorii pași:

utilizând un navigator Web, consumatorul selectează ce vrea să cumpere;

serverul vânzătorului trimite „portofelului Software” o cerere de plată semnată prin care dă detalii despre cumpărătură și transmite tipul cărților de credit acceptate. „Portofelul” deschide o fereastră și afișează suma și lista cărților de credit disponibile pentru selecție;

„portofelul” trimite un mesaj criptat și semnat cu numărul cărții de credit și detalii privind tranzacția și acceptarea plății;

serverul vânzătorului trimite acest mesaj împreună cu un mesaj propriu semnat și criptat către Gateway. Gateway-ul este operat de către un agent al băncii colectoare al vânzătorului. Aici mesajele sunt decriptate și comparate, iar dacă se potrivesc, se trimite o cerere de autorizare convențională;

Gateway-ul reîntoarce un răspuns către vânzător; informațiile privind tranzacția și numărul cartelei de credit sunt criptate cu cheia publică a lui CyberCash, astfel încât vânzătorul nu poate utiliza ilegal, ulterior, cartea de credit a cumpărătorului;

vânzătorul trimite un răspuns „carte de credit” către software-ul „portofel”.

Plata prin SmartCard (cartela „inteligentă”) 

SmartCardul este, în esență, înlocuitorul portofelului obișnuit. Tot conținutul unui portofel actual (acte, cărți de credit, bani gheață), va fi înlocuit de una sau mai multe SmartCarduri. Din punct de vedere fizic, SmartCard arată ca o carte de credit, cu unul sau mai multe microcircuite de tip „microcontroller” înglobate. O cartelă inteligentă poate păstra de 10-100 de ori mai multă informație decât o cartelă magnetică, fiind totodată mult mai sigură. Conectată la un terminal de citire-scriere, SmartCard poate efectua funcții complexe de luare a deciziilor, proceduri sofisticate de autentificare pentru a preveni frauda. Deci beneficiile oferite de SmartCard sunt: siguranța, capabilități active anti-fraudă, flexibilitate în aplicații, posibilitatea de validare off-line.

Pentru a efectua operații cu SmartCard, aceasta se introduce într-un dispozitiv de citire/scriere care poate fi cu sau fără contact. Acest cititor poate fi sub forma unui portofel care poate comunica cu alt portofel similar sau cu banca, pentru efectuarea de transferuri multivalutare. Astfel, SmartCard memorează direct echivalentul digital al sumelor de bani în loc să indice un cont la bancă sau un credit acordat de bancă. Când o astfel de cartelă este folosită pentru a cumpăra ceva, echivalentul sumei respective este efectiv transferat vânzătorului și apoi mai departe către o instituție financiară. SmartCard poate fi reîncărcabilă sau nu. În acest ultim caz, cartela va fi aruncată atunci când suma înscrisă pe ea a fost epuizată. 

Transferul electronic de fonduri 

Pe Internet, cecul de hârtie poate fi înlocuit de un cec electronic, semnat digital de emitent. Un consorțiu de bănci, FSTC – Financial Services Technology Consortium (www.fstc.com), a statuat un model de cec electronic foarte asemănător cecurilor clasice pe hârtie. Plătitorul folosește un procesor, de tipul unui SmartCard PC, pentru a genera și semna digital un cec electronic ce va fi transmis prin poștă electronică sau Web. El se trimite fie băncii cumpărătorului – care-l va onora după verificarea semnăturii digitale, trimițând banii către banca vânzătorului, fie direct vânzătorului – care va verifica semnătura, îl va semna la rândul său, și îl va trimite băncii sale. Sistemul FSTC se bazează pe folosirea sistemelor criptografice cu chei publice pentru semnătură digitală și pleacă de la premisa ca toate cheile publice ale participanților și certificatele lor sunt cunoscute pretutindeni în sistem. 

Plata prin eCash 

Este prima soluție totalmente software pentru plățile electronice. Tranzacțiile se desfășoară între vânzător și cumpărător, care trebuie să aibă conturi la aceeași bancă. Cumpărătorii trebuie să înștiințeze banca asupra faptului că doresc să transfere bani din conturile lor în așa-numitul cont eCash Mint. În orice moment, cumpărătorul poate interacționa de la distanță, prin calculatorul său și utilizând un client software, cu contul Mint și poate retrage fonduri de aici pe discul calculatorului său. Formatul acestor fonduri este electronic, suite de zero și unu protejate criptografic. Ca urmare, discul cumpărătorului devine un veritabil „portofel electronic”. Apoi se pot executa plăți între persoane individuale sau către firme, prin intermediul acestor eCash. 

eCash are un caracter privat: deși banca ține o evidență a fiecărei retrageri eCash și a fiecărui depozit Mint, este imposibil ca banca să stabilească utilizarea ulterioară a eCash. Această proprietate este posibilă datorită folosirii unor criptosisteme cu chei publice RSA, cu o lungime a cheii de 768 biți. 

Banii electronici (digicash): reprezintă echivalentul electronic al banilor reali, și pot lua diferite forme, precum cartelele obișnuite, a SmartCard-urilor, etc.

CAPITOLUL III

TEHNOLOGII ȘI INSTRUMENTE INFORMATICE UTILIZATE ÎN DEZVOLTAREA APLICAȚIEI

3.1 Arhitectura Client/Server

Problema proiectării aplicațiilor a suferit de-a lungul timpului multe modificări dictate de necesitate și eficiență și a dus la apariția unei palete variate de paradigme de programare. Una dintre cele mai răspândite la ora actuală este programarea client/server.

Arhitectura aplicației client/server este o infrastructură versatilă, bazată pe mesaje și modulară, care are scopul clar de a îmbunătăți flexibilitatea, interoperabilitatea, scalabilitatea și ușurința în utilizare de care duc lipsă tradiționalele arhitecturi mainframe și server de fișiere. În cadrul arhitecturii mainframe toată procesarea necesară obținerii răspunsului la o cerere lansată de o stație se făcea pe calculatorul central (mainframe-ul) care stoca și toate resursele la care avea acces clientul. Încă unul din neajunsurile arhitecturii îl reprezenta problema dificilă a implementării unei interfețe cu utilizatorul. Arhitectura serverului de fișiere se bazează pe o arhitectură de fișiere distribuite, care sunt transmise de către server, la cerere, clientului, spre modificare sau interogare, și returnate apoi server-ului, spre stocare, la încheierea operației.

Limitările celor două arhitecturi tradiționale în contextul actual al unei rețele de calculatoare și în special al Internetului (văzut ca o rețea mare de resurse distribuite) au dus la răspândirea arhitecturii 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. 3.1 Arhitectura generică client/server

Î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. 3.2 Arhitectura unei aplicații client/server generice

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.

3.2 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. Putem să învățăm limbajul de modelare (notația), dar dacă nu știm cum să-l utilizăm (dacă nu cunoaștem procesul de modelare), probabil că vom eșua. Putem dispune de un proces foarte bun dar, dacă nu suntem capabili să-l comunicăm (folosind notațiile), probabil că vom fi sortiți eșecului. De asemenea, dacă nu dispunem de un instrument pentru documentarea pașilor parcurși în etapa de proiectare, probabil că munca noastră va fi sortită eșecului.

Elementele componente ale unei metodologii de analiză și proiectare a unei aplicații software sunt limbajul de modelare și procesul de modelare. Limbajul de modelare reprezintă o notație grafică folosită pentru descrierea modelului, în timp ce procesul reprezintă succesiunea de pași ce trebuie urmați pentru realizarea efectivă a modelului.

3.2.1 Limbajul de modelare

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;

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.

Modelarea unei aplicații necesită specificarea realității astfel încât să se înțeleagă mai bine sistemul dezvoltat. Mijloacele prin care sunt vizualizate blocurile constructive ale UML-ului sunt reprezentate de diagrame. Acestea prezintă în mod grafic o mulțime de elemente reprezentate sub forma unui graf conex de noduri (elemente) și arce (relații).

Cele nouă tipuri de diagrame puse la dispoziție de UML sunt: de cazuri de utilizare, de activități, de clase, de colaborare, de componente, de exploatare, de obiecte, de secvență și de stări.

Voi insista asupra diagramelor de cazuri de utilizare și asupra celor de activități, întrucât acestea au fost folosite în etapa de proiectare a aplicației prezentată în lucrarea de față.

Modelarea cazurilor de utilizare constituie o tehnică independentă, ortogonală cu modelarea obiect. Ea poate fi inclusă la fel de bine într-o metodologie orientată-obiect sau structurată. Rolul acestui tip de modelare este de a reprezenta într-o formă grafică funcționalitățile pe care trebuie să le îndeplinească aplicația în faza finală. Modelul realizat de diagramele cazurilor de utilizare, împreună cu descrierea succintă a fiecărui caz de utilizare determinat, se numește model al cerințelor.

Cazurile de utilizare arată comportamentul sistemului sau a unei părți din sistem și reprezintă o descriere a unui set de secvențe de acțiuni pe care un sistem le execută pentru a produce un rezultat observabil pentru un actor. Cazurile de utilizare ale unui sistem trebuie să surprindă tot ce-și poate dori un utilizator de la sistemul respectiv. Diagramele cazurilor de utilizare sunt formate din două categorii de entități (actori și cazuri de utilizare) și relațiile dintre acestea.

Trebuie să se facă o distincție clară între actori și utilizatori. Utilizatorul este o entitate care folosește sistemul. În relația pe care o are cu un caz de utilizare, actorul reprezintă un anumit rol jucat de utilizator. În circumstanțe diferite, același utilizator se poate comporta ca mai mulți actori.

Cazurile de utilizare reprezintă o tehnică de analiză utilă pentru înțelegerea și definirea cerințelor funcționale ale unei aplicații. Această tehnică ajută la concentrarea atenției asupra utilizabilității aplicației, altfel spus asupra a ceea ce utilizatorii așteaptă de la aplicație.

Diagramele de activități reprezintă scheme logice cu ajutorul cărora sunt prezentate fluxurile de control dintre activitățile implicate în executarea unei funcționalități a aplicației. Ele sunt folosite la modelarea aspectelor dinamice ale aplicației și presupun modelarea unui proces pas cu pas.

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

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.

În proiectarea aplicației prezentată în lucrarea de față voi folosi un proces bazat pe cazuri de utilizare. Scenariile și cazurile de utilizare determină fluxul procesului, din momentul stabilirii cerințelor aplicației și până în faza de testare.

3.2.3 Instrumentele utilizate (RationalRose, DBDesigner)

Un element important al procesului de proiectare a unei aplicații îl reprezintă instrumentele care pun la dispoziția utilizatorului o gamă variată de facilități în ceea ce privește modelarea vizuală a procesului.

Instrumentele din familia „Rational Rose” au fost proiectate pentru a oferi dezvoltatorilor de aplicații un set complet de unelte de modelare vizuală în scopul dezvoltării de soluții robuste și eficiente care să vină în sprijinul nevoilor reale din mediile de afaceri implementate cu ajutorul sistemelor distribuite, client/server. Produsele RationalRose împărtășesc un standard comun: acela de a face proiectarea accesibilă atât programatorilor, care doresc realizarea unei proiectări logice a aplicațiilor, cât și amatorilor care doresc să modeleze procese de business. În lucrarea de față am utilizat Rational Rose în procesul de modelare vizuală a diagramelor de activități, precum și a celor care prezintă cazurile de utilizare ale aplicației.

Un alt instrument extrem de important pe care l-am utilizat în faza de proiectare este DBDesigner. Acesta este un instrument utilizat la modelarea vizuală a bazelor de date, având încorporate funcționalități care permit design-ul, modelarea, crearea și întreținerea bazelor de date. A fost dezvoltat și optimizat pentru bazele de date de tip MySQL cu scopul de a pune la dispoziția utilizatorilor acestui tip de baze de date un instrument puternic de proiectare.

3.3 Tehnologii și instrumente informatice utilizate în implementarea aplicației

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

Conform lui Graeme, PHP și MySQL reprezintă cea mai bună metodă actuală pentru crearea unor site-uri care folosesc baze de date. Acest fapt este demonstrat de un studiu de cercetare al companiei Netcraft care arată că dacă în iunie 1998 existau 7.500 de host-uri care utilizau PHP în martie 1999 numărul acestora a crescut la 410.000. Această combinație a primit și titlul de „Database of the Year” la Webcon98.

MySQL este un server de baze de date mic și compact, ideal atât pentru aplicații mici, cât și pentru dezvoltarea marilor proiecte. În afara faptului că suportă standardul SQL (ANSI-92), poate rula pe mai multe platforme și permite sisteme multithreading pentru serverele Unix, ceea ce aduce o creștere importantă a performanței. Sub WindowsNT, 2000 sau XP, MySQL este lansat ca un serviciu, pe când sub Windows95/98, ca un proces normal.

PHP este un limbaj de programare pentru server. Codul PHP poate fi integrat în interiorul codului HTML. Scriptul PHP va fi apoi procesat de către server care va returna un fișier HTML. Acest tip de interacțiune permite executarea unor operații destul de complexe.

Aplicațiile WEB reprezintă atât prezentul cât și viitorul, ele funcționând pe baza unei arhitecturi client/server. Aplicațiile realizate cu PHP și MySQL utilizează un singur client și anume browser-ul WEB. Limbajul de bază al browser-ului WEB este HTML. Acest limbaj dispune de o serie de tag-uri care descriu modul în care va arăta o pagină WEB. Majoritatea prelucrărilor efectuate de aplicațiile Web au loc pe sever. O aplicație specifică, numită server Web, va asigura comunicarea cu browser-ul. Un server de baze de date relaționale stochează informațiile pe care le va accesa aplicația. În final mai este nevoie de un limbaj care să intermedieze interogările ce apar între serverul Web și serverul de baze de date. Acest limbaj va fi utilizat și pentru a executa anumite operații asupra informațiilor care vin spre și dinspre serverul Web.

3.3.2 PHP

PHP – limbaj scriptural server-side pentru generarea dinamică de conținut Web

PHP, acronimul de la „PHP: Hypertext Prepocessor”, este un limbaj de programare folosit cu precădere ca și limbaj scriptural server-side în generarea dinamică de conținut Web.

Modelul PHP implementează paradigma generării dinamice de conținut Web și a apărut ca alternativă necesară la tradiționalele sisteme ASP/VBScript/Jscript al Microsoft-ului, JSP/Java al Sun Microsystems-ului și CGI/Perl.

În modelul PHP, structura unei pagini Web PHP este cea a unei pagini HTML care încapsulează pe alocuri cod PHP. Caracterul dinamic al unei pagini Web PHP este asigurat prin:

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ă;

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.

Istoric

A început ca și un pachet de scripturi Perl, prin care Rasmus Lerdorf aduna date despre vizitatorii paginii sale personale Web.

Prima versiune a pachetului făcută publică a primit denumirea Personal Home Page; i s-a adăugat ulterior un „scripting engine” care împreună cu o unealtă încorporată permitea analizarea datelor unui formular HTML (Form Interpreter) – devenind astfel PHP/FI, cunoscut și ca PHP2 -, pentru ca să ajungă un proiect aflat în mâinile unui grup de programatori dornici să dezvolte o unealtă pentru probleme mai complicate, deschizându-se astfel drumul lui PHP3.

Versiunea 3 a limbajului apare după o rescriere a „scripting engine-ului” și prin introducerea unui API care permite programatorilor extinderea capacităților limbajului prin dezvoltarea de module.

Începând cu versiunea 4, PHP beneficiază de „scripting engine-ul Zend”, rescris după cel vechi. Odată cu PHP4, limbajul PHP a introdus un motor rapid de „parsing” care, pe lângă funcțiile PHP-ului de conectare la baze de date, suportul XML sau suportul pentru servleți Java, sistemul de gestiune a sesiunilor și funcțiile IMAP, reușește să transforme acest limbaj „open source” într-unul de top datorită muncii grele depuse zi și noapte de grupul de dezvoltatori pentru adăugarea de funcționalități și upgrade, bazată doar pe răspunsurile și cererile utilizatorului.

Principiul de funcționare

Într-un scenariu tipic de cerere de pagină Web venită din partea unui browser:

server-ul de Web „știe”, prin configurarea sa și din extensia paginii cerute, că pagina trebuie „preprocesată” de PHP anterior servirii acesteia către browser;

PHP interpretează doar secvențele încapsulate de cod PHP (delimitate de marcajele „<?php” și „?>”) din pagina Web, secvențe care pot completa dinamic pagina prin simple inserții de text în structura de tag-uri HTML a paginii (care este ignorată de preprocesor, dar reprodusă la ieșire);

server-ul trimite browser-ului pagina pe care PHP i-o returnează în urma interpretării, pagină în format HTML.

Caracteristici

Evidenta simplitate în utilizare a acestui model, îmbinată cu caracteristici dintre cele mai complexe de care dispune PHP-ul, a propulsat modelul în fruntea tehnologiilor de dezvoltare a 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;

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;

începând cu versiunea 4.0, deține suport minimalist pentru programarea orientată-obiect, suport devenit complet în versiunea 5.0;

3.3.3 MySQL

Bazele de date au devenit o parte integrantă din viață de zi cu zi a 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.

După T.Conolly, o bază de date reprezintă o colecție partajată de date, între care există relații logice (și o descriere a acestor date), proiectată pentru a satisface necesitățile informaționale ale unei organizații.

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.

Arhitecturii client-server realizată de perechea de aplicații browser – server de web (de obicei Internet Explorer – Apache) i se adaugă încă o pereche de aplicații, script asociat formularului – server de baze de date. În acest tandem scriptul asociat formularului (scris în PHP, C, C++, Perl, etc) este client, iar serverul de baze de date (MySQL, Oracle, etc) are rolul de server. Scriptul formulează comenzi SQL, iar serverul SQL le execută.

MySQL este un sistem de gestiune a bazelor de date 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).

MySQL este disponibil în mod public din 1996, dar istoria dezvoltării sale începe încă din 1979 și a câștigat de mai multe ori premiul cititorilor – Linux Journal Readers' Choice Award. MySQL este disponibil sub o licență Open Source, dar există și sub licențe comerciale. Este rapid, iar costul său este nul, fiind distribuit gratuit sau foarte mic, distribuit sub o licență comercială, dacă aceasta este necesară aplicației utilizatorului și este mult mai ușor de configurat decât multe alte produse asemănătoare.

Popularitatea MySQL se datorează în primul rând multiplelor facilități oferite de acesta, dintre care vom aminti:

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: clienți în linie de comandă, browsere Web sau clienți Window System; de asemenea este posibilă o varietate de interfețe de programare pentru limbaje precum PHP, C, Perl, Java;

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

Distribuția MySQL include următoarele:

un server SQL: acesta ce reprezintă motorul care activează MySQL și furnizează accesul la bazele de date;

programe client pentru accesul la server: acestea sunt reprezentate de programe interactive care permit introducerea de interogări în mod direct și vizualizarea rezultatelor; de asemenea există numeroase programe administrative și utilitare ce permit rularea site-ului;

o bibliotecă client: cu ajutorul acesteia se pot scrie propriile programe client în C; în același timp, biblioteca furnizează baza de date pentru terțe asocieri pentru alte limbaje.

MySQL este un sistem client-server alcătuit dintr-un server SQL multi-thread care are facilități pentru mai mulți utilizatori, mai multe programe și biblioteci client, instrumente de administrare și un număr mare de interfețe de programare. Server-ul de baze de date este un program localizat pe calculatorul responsabil cu stocarea datelor, care ascultă cererile clienților sosite prin rețea și obține acces la conținutul bazei de date în funcție de aceste cereri, în scopul de a furniza clienților informațiile solicitate. Clienții reprezintă programe care se conectează la server-ul de baze de date și efectuează interogări pentru a-i indica acestuia informațiile pe care le doresc.

Având în vedere că MySQL suportă o gamă variată de produse software, există posibilitatea ca multe din limbajele de programare deja folosite de anumiți utilizatori să suporte deja interfața cu acest produs.

Orice mașină care dorește să proceseze interogări asupra unei baze de date MySQL trebuie să ruleze MySQL server – MySQLd –, care este responsabil de tot traficul de tip „incoming” sau „outgoing” cu baza de date. Ca orice server, MySQLd primește pe un port particular (3306) eventualele cereri de conexiune ale unui client care trimite cereri către o bază de date via MySQLd. Acest client poate fi un script în PHP care, grație modelului DBI, poate trimite o cerere către baza de date prin intermediul serverului MySQL, sau chiar clientului command-line MySQL. Clientul MySQL este o interfață interactivă pentru trimiterea de comenzi către server.

Principalele motive pentru folosirea pe scară largă a MySQL sunt viteza, stabilitatea și facilitatea în utilizare. De asemenea MySQL are o serie de caracteristici care au fost dezvoltate prin colaborarea foarte apropiată cu utilizatorii acestui limbaj. Aceste caracteristici ale limbajului se datorează faptului că a fost proiectat încă de la început pentru gestionarea unui volum foarte mare de date, iar experiența în folosirea sa acumulată de-a lungul anilor și-a spus cuvântul. MySQL oferă astăzi un set complet și util de funcții. Conectivitatea, viteza și securitatea fac ca MySQL să fie unul din cele mai potrivite produse pentru gestiunea bazelor de date pe Internet.

3.3.4 Apache

Un server Web este un daemon care acceptă conexiuni conform protocolului HTTP, răspunzând cererilor recepționate de la clienți. Ca și alte protocoale utilizate în Internet, protocolul HTTP (HyperText Transfer Protocol) este un protocol de tip cerere-răspuns, bazat pe TCP/IP, destinat transferurilor de informații hypermedia.

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. Acestui număr mare de dezvoltatori i se adaugă o comunitate substanțială de programatori și/sau simpli utilizatori care contribuie cu idei, documentație, cod și mai ales feed-back-ul necesar unei dezvoltări complete.

Devenit cel mai popular server Web încă din aprilie 1996, Apache ajungea în noiembrie 2005 într-un top al serverelor Web făcut de Netcraft Web Server Survey, serverul fiind folosit de 70% din totalitatea site-urilor de pe Internet, mai mult decât toate celelalte servere la un loc.

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.

Dorința creatorilor Apache, după cum se specifică în site-ul Grupului Apache, este ca platforma sa să fie folosită de cât mai multă lume (companii mari sau mici, instituții de cercetare, școli, Intranet-uri ) și să se acopere cât mai multe domenii de activitate.

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;

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

CAPITOLUL IV

DEZVOLTAREA APLICAȚIEI

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

4.1.1 Studiul pieței aplicațiilor care oferă servicii de comenzi on-line a preparatelor culinare

În vederea unei mai bune înțelegeri a aplicațiilor Web care oferă servicii de comenzi on-line a preparatelor culinare, precum și în vederea proiectării unei aplicații care să suplinească, pe cât posibil, neajunsurile acestora, am efectuat un studiu de piață. Studiul s-a bazat pe analiza a trei dintre aplicațiile Web care oferă posibilitatea de a efectua comenzi on-line de preparate culinare, și anume: www.culinar.ro, www.chelner.ro, www.mancare-brasov.ro.

www.culinar.ro

Este site-ul cu traficul cel mai mare dintre cele analizate, situându-se pe locul 6 la categoria „Comerț Electronic” în cadrul topului efectuat de www.trafic.ro și pe locul 138 în clasamentul general. Situarea sa pe un loc atât de înalt în top se poate datora în primul rând timpului îndelungat de funcționare, aproape 6 ani de la înscrierea pe www.trafic.ro, timp în care site-ul a reușit să-și promoveze imaginea și să-și atragă un număr semnificativ de clienți fideli. Un alt lucru care a contribuit la succesul site-ului ar putea fi acela că oferă două secțiuni de larg interes pentru publicul din România: o secțiune în care sunt prezentate rețete culinare și o secțiune de forum, care permite utilizatorilor să-și împărtășească opiniile în cele mai variate domenii, in special cel gastronomic.

Pe lângă posibilitatea comandării de preparate culinare cu livrare la domiciliu, utilizatorii mai pot beneficia de facilitățile secțiunilor de „catering” și „cumpărături on-line”. În ce privește comenzile de preparate culinare, site-ul pune la dispoziția clienților oferta a 19 furnizori, cu raza de acoperire în zona Municipiului București.

Dintre facilitățile oferite utilizatorilor se pot enumera:

posibilitatea înscrierii în ClubCulinar prin crearea unui cont de utilizator; facilitățile oferite membrilor sunt variate, de la primirea zilnică prin e-mail a ofertelor speciale, posibilitatea creării on-line a propriei cărți de bucate, accesul la forum, până la posibilitatea de a participa la concursurile organizate de Culinar.ro;

monitorizarea continuă a furnizorilor și oferirea de informații privind seriozitatea acestora, conexiunea la internet și modalitățile de preparare a produselor în conformitate cu respectarea regulilor de igienă;

posibilitatea de a introduce în comandă preferințele personale ale utilizatorului pentru fiecare produs comandat (preferințe legate în general de gradul de condimentare sau de ingredientele conținute)

posibilitatea efectuării de comenzi cu dată de livrare diferită de data comenzii;

posibilitatea de a selecta adresa de livrare dintr-o listă care conține adresele la care s-a mai comandat, precum și posibilitatea stabilirii unei adrese diferite pentru efectuarea plății.

Printre neajunsurile întâmpinate de utilizatori se numără:

o interfață nu tocmai prietenoasă, destul de încărcată, care îngreunează navigarea; site-ul urmărește prezentarea unui număr cât mai mare și mai variat de informații utile consumatorilor, însă efectul nu este cel scontat: de cele mai multe ori utilizatorii ajung să se piardă în multitudinea de informații, renunțând astfel la intenția de a efectua comenzi;

inexistența unui istoric al comenzilor care să permită utilizatorilor vizualizarea, modificarea sau relansarea unor comenzi anterioare;

lipsa posibilității de administrare a datelor despre contul personal;

generarea automată a listei adreselor de livrare, fără oferirea de facilități în vederea modificării acestor adrese.

www.chelner.ro

Obiectivul site-ului este acela de a prezenta oferta furnizorilor care asigură livrarea la domiciliu a preparatelor culinare, precum și a firmelor de catering, care asigură mesele de prânz pentru diferite firme sau care se ocupă cu organizarea de evenimente. Publicul țintă este reprezentat de bucureșteni întrucât raza de acoperire a furnizorilor se află în zona Municipiului București.

Printre facilitățile oferite se numără:

posibilitatea creării unui cont de utilizator; din momentul creării contului, utilizatorul dispune de facilități care îi permit gestionarea adreselor de livrare, vizualizarea istoricului de comenzi (pentru o perioadă limitată de timp), precum și gestionarea grupurilor din care face parte;

posibilitatea efectuării de comenzi în grup: mai mulți utilizatori pot crea un grup prin intermediul căruia să efectueze comenzi, fiecare utilizator putându-și adăuga în mod individual comanda;

posibilitatea de a solicita eliberarea unei facturi pentru produsele comandate;

posibilitatea de a recomanda un furnizor prin intermediul unui formular;

monitorizarea atentă a comenzilor, ceea ce oferă în permanență clientului posibilitatea de a vizualiza stadiul în care se află comanda inițiată (lansată, anulată, acceptată, refuzată, confirmată sau efectuată).

Punctele slabe ale aplicației sunt reprezentate de:

deficiențe în ceea ce privește structurarea informațiilor despre produse și furnizori;

imposibilitatea de a relansa o comandă din istoricul de comenzi;

lipsa unui motor de căutare care să permită clienților regăsirea produselor în funcție de anumite criterii cum ar fi: tipul produsului, prețul, furnizorul, etc

www.mancare-brasov.ro

Este un site care se adresează brașovenilor, cu intenția de a prezenta oferta furnizorilor de pe piața Brașovului care asigură livrarea la domiciliu și de a facilita procesul de comandare a preparatelor culinare.

Aplicația beneficiază de o interfață prietenoasă și un design unic și unitar, fapt care va contribui decisiv la atragerea clientelei. Fiind abia la început, site-ul prezintă doar ofertele a cinci furnizori, dintre care doi oferă servicii de livrare la domiciliu.

Printre punctele forte, menite să vină în ajutorul utilizatorului, se numără:

posibilitatea de a vizualiza imagini cu produsele aflate în oferta furnizorilor;

posibilitatea de a contacta furnizorul prin intermediul formularului de contact al fiecărui furnizor;

posibilitatea de a vizualiza furnizorii în funcție de regimul de funcționare (restaurante, pizzerii, fast-food-uri, etc);

Părțile mai puțin forte ale aplicației se referă la:

lipsa unei structurări pe categorii a produselor oferite, care să conțină preparatele puse la dispoziția consumatorului de către toți furnizorii;

lipsa facilităților de administrare a contului și adreselor de livrare;

prezentarea unei oferte limitate de preparate (lucru de înțeles totuși, având în vedere faptul că site-ul funcționează de 2 luni).

Încă de la prima vedere, se observă că beneficiarii tipului de aplicație în discuție sunt, în egală măsură, persoanele în căutarea unei metode comode și deloc costisitoare de a comanda ceva de mâncare (denumiți de acum înainte clienți), precum și producătorii de preparate culinare aflați într-o continuă căutare atât de clientelă nouă pentru preparatele culinare pregătite, precum și de modalități de promovare în masă largă (denumiți de acum înainte furnizori).

Sintetizând rezultatele obținute din analiza pieței de aplicații Web care oferă servicii de comenzi on-line a preparatelor culinare se pot trage următoarele concluzii în ceea ce privește părțile pozitive și negative ale unei aplicații de acest tip.

O astfel de aplicație ar trebui sa ofere următoarele facilități:

Pentru client:

interfață plăcută, comodă și puțin costisitoare de comandare: cu o simplă legătură la Internet (de care beneficiază aproape oricine în ziua de azi), clienții pot comanda preparatul dorit prin 3 modalități diferite:

accesând lista furnizorilor și selectând din meniul pus la dispoziție preparatul dorit;

accesând lista categoriilor de preparate culinare și selectând oferta furnizorului preferat;

căutând preparatul dorit după anumite criterii, cum ar fi: denumirea, prețul, furnizorul, etc.;

libertatea de a alege: clientul are posibilitatea de a consulta meniul fiecărui furnizor și de a alege un produs în funcție de un număr mult mai mare de criterii (furnizor, preț, timpul de livrare, etc.);

posibilitatea de a recomanda un furnizor: întrucât părerea clientului este cea mai importantă, pe lângă tradiționalul formular de contact care să-i permită exprimarea opiniilor pro și contra, aplicațiile de comenzi on-line oferă o posibilitate rapidă de recomandare a unui furnizor preferat prin intermediul unui formular.

Pentru furnizor:

o modalitate puțin costisitoare și efectivă de reclamă: informațiile despre noile oferte speciale apărute sau modificările survenite în meniu pot fi configurate în orice moment de către furnizor prin simpla accesare a aplicației, fără alte costuri suplimentare (de ex.: editarea de pliante și materiale promoționale); astfel, clientului îi sunt oferite în permanență informații actualizate, prevenindu-se de exemplu situațiile neplăcute când un furnizor nu mai poate oferi un produs la același preț;

accesul la istoricul comenzilor primite și la informațiile publice ale clienților unui furnizor pentru eventuale statistici, studii de piață sau marketing: prin intermediul conținutului bazei de date a clienților, la care va avea în permanență acces, furnizorul va putea efectua diferite studii referitoare la impactul produselor sale asupra clienților; va putea păstra astfel o evidență a celor mai solicitate produse, dar și a celor mai fideli clienți, putându-și astfel dezvolta diverse strategii de marketing menite să încurajeze comandarea produselor oferite de el;

o modalitate ieftină de îmbunătățire a relației cu clienții: prin intermediul aplicației se poate obține acceptul clientului de a primi mesaje cu oferte și promoții (accept cerut de Legea Comerțului Electronic nr. 365/2002 care interzice trimiterea de mesaje nesolicitate); acest accept permite furnizorului aplicarea unei strategii proprii de marketing direct sau a unei strategii propuse de aplicație; strategia proprie poate consta în trimiterea periodică (dar nu prea des) a unui mesaj care anunță o reducere de preț sau o ofertă specială; strategia propusă de aplicație constă în trimiterea zilnică a unui mesaj care să conțină ofertele speciale ale tuturor furnizorilor pentru ziua respectivă.

În ceea ce privește părțile negative, putem vorbi doar despre neajunsurile întâmpinate de clienți în folosirea aplicațiilor studiate. Nu ne putem pronunța și în privința furnizorului deoarece nu avem acces la partea de administrare oferită de aplicațiile analizate. Prin urmare, neajunsurile întâlnite de clienți în timpul utilizării unor astfel de aplicații Web ar putea fi sintetizate în următoarele:

densitatea mare de informații: majoritatea aplicațiilor renunță la simplitate în favoarea prezentării unei cantități excesive de informații pe fiecare pagină; efectul constă în derutarea vizitatorului și punerea acestuia în imposibilitatea de a observa cu ușurință elementele de care este interesat;

opțiuni limitate în ceea ce privește istoricul comenzilor: aplicațiile care întrețin un istoric al comenzilor îl folosesc doar cu rol descriptiv, acesta neputând fi folosit, de exemplu, pentru relansarea unei comenzi efectuate anterior;

opțiuni limitate în ceea ce privește comenzile care să conțină preparate de la mai mulți furnizori: majoritatea aplicațiilor Web prezintă oferta unui singur furnizor, iar cele care prezintă oferta mai multor furnizori oferă doar posibilitatea comandării unei liste de produse aflate în oferta aceluiași furnizor.

4.1.2 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 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 ș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;

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;

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ă;

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ă; 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).

Reguli pentru buna funcționare a aplicației:

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; aceste informații trebuie să înlăture oricărui client, în mod succint și elocvent, orice nelămurire care ar putea apărea cu privire la responsabilitățile acestuia în utilizarea aplicației; se presupune că clientul este la curent cu responsabilitățile care îi revin în utilizarea 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.

4.1.3 Delimitarea comportamentului aplicației (cazurile de utilizare)

Printr-o analiză amănunțită a așteptărilor celor doi beneficiari ai aplicației vom contura un prim model al aplicației, o vedere a acesteia, prin descrierea aplicației din punctul de vedere al comportamentului ce rezultă în mare parte din necesitățile delimitate în capitolul precedent de beneficiari.

Scopurile acestei prime faze de analiză și proiectare sunt:

documentarea contextului, a mediului de funcționare și a limitelor aplicației, a comportamentului exclusiv exterior (observabil) dorit pentru aplicație în toate cazurile de interacțiune cu utilizatorii;

descrierea cerințelor și nevoilor utilizatorilor în contextul utilizării aplicației;

pregătirea unui punct de plecare în identificarea tuturor activităților din aplicație.

Pentru aceasta, voi considera aplicația exclusiv din perspectiva utilizatorilor (care de regulă nu știu și nici nu prezintă interes pentru detaliile de implementare a aplicației), adică voi privi aplicația ca și o cutie neagră, un sistem ascuns mie ca formă și conținut și căruia doresc să-i delimitez un comportament pentru cazurile de interacțiune formulate de utilizator.

Odată clarificat scopul acestei faze și a perspectivei mele față de aplicație, voi trece la:

identificarea actorilor care interacționează cu sistemul;

trecerea în revistă a cazurilor în care fiecare actor în parte utilizează aplicația;

transpunerea informațiilor obținute într-o vedere a cazurilor de utilizare a aplicației, prin intermediul diagramelor de cazuri de utilizare pentru fiecare actor în parte.

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

Cazurile de utilizare sunt orientate pe scop: reprezintă ceea ce sistemul trebuie să facă și nu cum. Ele sunt neutre din punct de vedere tehnologic, putând fi utilizate în orice proces sau arhitectură de aplicație.

La prima vedere, rolurile principale de actor sunt distribuite beneficiarilor bine stabiliți ai aplicației, clienții și furnizorii. Ne referim la un utilizator al aplicației cu titulatura de CLIENT dacă acesta este înregistrat în evidența aplicației ca și beneficiar al serviciilor de comandă on-line și în plus s-a conectat la serviciile aplicației precizând perechea validă de nume de utilizator și parolă care îl identifică. FURNIZORUL este și el un utilizator înregistrat al aplicației, care se identifică la rândul lui printr-o pereche de nume de utilizator și o parolă, dar beneficiază de cu totul alte privilegii (și responsabilități) față de cele ale CLIENTULUI. O categorie aparte de actori (cu rol deloc neglijabil) care vor interacționa cu aplicația o constituie VIZITATORII, reprezentați de orice utilizator care accesează aplicația și care nu este înregistrat în evidența aplicației, sau cel puțin nu s-a conectat încă la serviciile ei.

Deoarece vizitatorul intră primul în contact cu aplicația, este naturală descrierea și documentarea interacțiunii dintre aceștia (vizitator, aplicație) pentru delimitarea unui comportament primar al aplicației.

Cerințele clientului și ale furnizorului de a accesa un mediu controlat de comandare on-line în care se evită, pe cât posibil, comenzile false sau schimbul de informații eronate, impun limitarea posibilității de lansare a comenzilor doar la clienți (vizitatorii înregistrați), fiindcă informațiile personale furnizate de aceștia sunt validate într-o oarecare măsură de aplicație și în plus, clienții le garantează, cel puțin virtual, veridicitatea.

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;

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:

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

Un real interes pentru comportamentul aplicației (datorită ponderii mare în comportamentul final) prezintă modalitatea de exercitare de către clienți a dreptului de folosire a serviciului de comandă on-line.

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.

Fig. 4.2 Cazurile de utilizare pentru client

Se observă că între cei doi actori, 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.

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:

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

Printr-un raționament analog cazului clientului, informațiile despre activitatea furnizorului și a meniului de preparate culinare vor fi reținute ca parte constitutivă a contului de furnizor. De asemenea, datorită interesului accentuat pentru comenzile din ziua în curs, acestea vor fi administrare separat față de cele cu dată de livrare ulterioară zilei în curs. Prin urmare, în cazul furnizorului vom avea de a face cu două cazuri generice de utilizare, „Administrare cont” și „Administrare comenzi”, care vor include, la 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:

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

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

4.2 Proiectarea aplicației

4.2.1 Designul conceptual al aplicației

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

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

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

4.2.1.2 Designul conceptual al interfeței – prototipul de interfață

Rolul etapei de concepere a prototipului de interfață este acela de a prezenta modul în care vor fi structurate informațiile în cadrul site-ului, în funcție de categoriile de utilizatori. În această etapă nu voi vorbi de modul de aranjare fizică a informațiilor în pagină, ci doar de funcționalitățile oferite de site în funcție de categoria de utilizator.

Prototipul trebuie inițial să identifice grupuri majore de ferestre și strategia de interacțiune de ansamblu, lăsând la final aspectele de ordin estetic. În realizarea prototipului se utilizează hărți de structură a ecranului pentru a descrie fluxul aplicației, urmând căile principale ale cazurilor de utilizare.

În Fig. 4.7 este prezentat fluxul aplicației de food-ordering. Se observă faptul că site-ul oferă o interfață diferită pentru fiecare din cele trei categorii de utilizatori ai aplicației, respectiv pentru vizitatori, clienți și furnizori. Interfața diferită este oferită prin intermediul indexului specific, respectiv „Index vizitator”, „Index client” și „Index furnizor”.

În cadrul Fig. 4.7, opțiunile specifice fiecărei categorii de utilizatori, la un moment dat, sunt colorate diferit, astfel: albastru pentru vizitator, roșu pentru client, respectiv verde pentru furnizor. Se mai pot observa o serie aparte de opțiuni, colorate cu galben; acestea reprezintă opțiunile comune tuturor celor trei categorii de utilizatori; oricine va utiliza aplicația va avea acces în orice moment la acele opțiuni generale.

Fig. 4.7 Designul conceptual al interfeței – Fluxul aplicației

4.2.1.3 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 de bazele 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), de tip n:1, dezvoltat de E.F. Codd de la IBM, 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ă, acre permite folosirea bazelor de date relaționale de către o categorie foarte largă de utilizatori.

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.

Pornind de la aceste aspecte teoretice am delimitat în cadrul aplicației de food-ordering 11 tipuri de entități, prezentate în diagrama entitate-relație de mai jos, împreună cu relațiile dintre ele.

Fig. 4.8 Diagrama entitate-relație

4.2.2 Designul fizic al aplicației

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

Fig. 4.9 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 (să nu uităm că acesta este un lucru garantat în termenii de utilizare a aplicației), protejând-o împotriva pericolelor prezente în mediul Web, inclusiv împotriva utilizării necorespunzătoare (voită sau nu) 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 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. Această componentă îndeplinește responsabilitatea nivelului de prezentare din arhitectura 3-tier.

Utilizatorul folosește aplicația prin intermediul unui browser Web, care funcționează ca un user-agent, acționând în locul acestuia în mediul Web (cu comportament guvernat de protocoale) prin transpunerea în acțiuni specifice acestui mediu a nevoilor utilizatorului. Pentru limitarea restricțiilor impuse de varietatea de browsere Web care accesează în mod propriu (deci diferit) Document Object Model-ul unei pagini HTML, consider necesară scrierea unei librării de funcții JavaScript care să suprascrie funcțiile de acces direct la DOM pe care le-ar necesita aplicația. Librăria rezultată va asigura funcționalitatea pachetului Accesul cross-browser la DOM-ul HTML.

Pachetul Prezentare cuprinde șabloanele de pagini precum și a scripturilor de completare a lor; acesta pregătește spre populare cu date paginile site-ului, care rețin doar comportamentul și aspectul lor. Prin delimitarea elementelor definitorii ale aspectului site-ului este posibilă construirea de teme diferite de afișare, iar pachetul Teme de afișare permite interfeței să funcționeze cu orice astfel de temă.

Componenta de Procesare reprezintă backbone-ul aplicației deoarece principala responsabilitate pe care o deține, materializată prin pachetul Logica aplicației, 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. 4.10 Relațiile dintre componentele aplicației

Această diagramă are scopul de a completa prima diagramă de componente prin sublinierea dependențelor dintre ele. Aceasta înseamnă delimitarea relațiilor dintre componente și a interfețelor prin care acestea comunică.

Astfel, se poate 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.

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

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.

Fig. 4.11 Diagrama de activitate care prezintă înregistrarea unui utilizator ca și client al aplicației

Se pot observa cu ușurință cele trei culoare corespunzătoare vizitatorului, browser-ului și scripturilor PHP de pe server, delimitându-se astfel elementele responsabile cu efectuarea activităților la un moment dat.

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

Fig. 4.12 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;

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.

4.2.2.3 Designul fizic al bazei de date

Procesul de design fizic al bazei de date constă în stabilirea atributelor care caracterizează entitățile, precum și a tipului acestor atribute. În diagrama de mai jos sunt prezentate tabelele din baza de date împreună cu atributele și tipul acestora, precum și legăturile dintre tabele.

Fig. 4.13 Schema fizică a bazei de date

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

Pentru satisfacerea acestui deziderat am ales următorul format pentru paginile de index:

Fig. 4.14 Structura paginilor de index ale aplicației

Î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, firma Aldum SRL.

Footer-ul conține toate informațiile necesare despre copyright-ul aplicației prin afișarea mesajului:

© 2006 AlDum România. Toate drepturile rezervate.

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

Fișierului ./lib/mysql.map.php conține o implementare a interfeței pentru baze de date de tip MyISAM. De observat două lucruri: primul, că funcția adb_connect de conectare la un server MySQL permite conectarea la unul implicit dacă nu primește în mod explicit o adresă de server, iar al doilea, că această implementare de interfață se bazează la rândul ei pe funcțiile unei alte librării, ./lib/mysql.lib.php. Este vorba de o nouă aplicare a mecanismului de mai sus, iar mysql.lib.php este o implementare a unei interfețe de acces la baze de date MyISAM.

<?php

if (!defined("MYSQL_MAP_INCLUDED")) {

define("MYSQL_MAP_INCLUDED","1");

require_once($_appCfg['main_dir_rel_path']."lib/mysql.lib.php");

$defaultServer = 'localhost';

$defaultUser = 'alina';

$defaultPassword = 'zevymoqxtni';

$defaultDb = 'myfoodorder';

function adb_connect($server=NULL, $user=NULL, $password=NULL) {

if ($server===NULL) {

global $defaultServer;

global $defaultUser;

global $defaultPassword;

$server = $defaultServer;

$user = $defaultUser;

$password = $defaultPassword;

}

return @mysql_connect($server,$user,$password);

} //~adb_connect

function adb_select_db($db, $connection=NULL) {

if (!$connection) {

$connection = adb_connect();

}

return @mysql_select_db($db,$connection);

} //~adb_select_db

function adb_exec_query($query, &$qResult, $connection=NULL) {

if ($connection===NULL) {

$connection = adb_connect();

}

return wrap_mysql_query($query,&$qResult,$connection);

}

function adb_get_tbl_col_val($tblName,$colName,$qWhere='',$connection=NULL) {

if ($connection===NULL) {

$connection = adb_connect();

}

return get_tbl_col_val($tblName, $colName, $qWhere, $connection);

} //~adb_get_tbl_col_val

…

}

?>

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

<?php

if (!defined("MYSQL_LIB_INCLUDED")) {

define("MYSQL_LIB_INCLUDED","1");

function wrap_mysql_query($qStr, &$qResult, $connection) {

$qResult = array();

if (empty($qStr)) {

return -1;

}

$qResult = @mysql_query($qStr,$connection);

if (mysql_error()) {

$qResult = array();

return 0;

}

return 1;

} //~wrap_mysql_query

function get_tbl_col_val($tbl, $col, $qW, $connection) {

if (!wrap_mysql_query("SELECT `".$col."` FROM `".$tbl."`".

($qW?" WHERE ".$qW:""),$result,$connection) ||

!mysql_num_rows($result)) {

return false;

} else {

$_row = mysql_fetch_array($result,MYSQL_ASSOC);

return $_row[$col];

}

} //~get_tbl_col_val

…

}

?>

Componenta de Securitate

Una din problemele de securitate care trebuie rezolvate pentru această 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.

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.

<?php

if (!defined('AUTH_LIB_INCLUDED')) {

define('AUTH_LIB_INCLUDED', 1);

require_once($_appCfg['main_dir_rel_path']."lib/db.lib.php");

require_once($_appCfg['main_dir_rel_path']."lib/common.lib.php");

function isRegUser($userName, $cryptPw, $conn) {

$userType = 0;

if ($userId = adb_get_tbl_col_val("clienti","id_client",

"`nume_client`='".$userName."' AND

`parola`='".$cryptPw."'",$conn)) {

$userType = 1;

}

if (!$userType &&

$userId = adb_get_tbl_col_val("furnizori", "id_furnizor",

"`nume_furnizor`='".$userName."'AND

`parola`='".$cryptPw."'",$conn)) {

$userType = 2;

}

return ($userType?$userType."|".$userId:0);

}//~isRegUser

function getSessionCodes($sessId,$userId,$cryptPw) {

$accessCode = md5(date('dsyihm').$userId.$sessId.$cryptPw);

return $accessCode."|".

base64_encode($sessId.str32Compose(md5($accessCode),$cryptPw));

}//~getSessionCodes

function isAuthorizedAccess($sessId,$userId,$accCode,$sessCode,$conn) {

$auth = 0;

if (($passW = adb_get_tbl_col_val("clienti","parola", "`id_client`=

'".$userId."'",$conn)) &&

(base64_encode($sessId.str32Compose(md5($accCode),$passW)) ===

$sessCode)) {

$auth = 1;

}

return $auth;

}//~isAuthorizedAccess

}

?>

Pagina ./bin/authentificate.php este apelată de pagina de conectare și autentifică un utilizator. În caz de reușită redirecționează utilizatorului către pagina de index corespunzătoare categoriei din care face parte.

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:

<?php

require_once($_appCfg['main_dir_rel_path']."lib/auth.lib.php");

if (isset($_REQUEST['ac']) &&

isset($_SESSION['sc']) && isset($_SESSION['iu']) &&

!isAuthorizedAccess(session_id(),$_SESSION['iu'],

$_REQUEST['ac'],$_SESSION['sc'],

$_appCfg['main_connection'])) {

header("Location: ".$_appCfg['main_dir_rel_path']);

exit;

}

?>

Mecanismul de acces controlat la pagini asigură faptul că accesul la paginile destinate celor î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.

CAPITOLUL V

SIMULAREA SUCCESULUI UNEI APLICAȚII WEB

5.1 Aspecte generale privind modelarea și simularea proceselor economice

Într-o definiție lapidară și unanim acceptată, 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.

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 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 Metoda Monte Carlo

Metoda de simulare Monte Carlo poate fi definită ca metoda modelării variabilelor aleatore, în scopul calculării caracteristicilor distribuțiilor lor de probabilitate.

Etapele ce trebuie efectuate pentru a realiza simularea prin metoda Monte Carlo, sunt următoarele:

identificarea factorilor;

formularea unui model;

determinarea distribuțiilor de probabilitate pentru factorii luați în considerare;

realizarea simulării;

analiza și interpretarea rezultatelor simulării.

Ideea de bază a metodei Monte Carlo este următoarea: metoda Monte Carlo generează, la întâmplare, valorile unei variabile aleatoare, prin utilizarea:

unui generator de numere aleatoare uniform distribuite în intervalul [0, 1]

distribuției de probabilitate cumulată asociată variabilei aleatoare respective.

Metoda a fost inventată de către cercetătorii americani de la „Los Alamos National Laboratory” prin anii 1940, când a fost utilizată pentru simularea traiectoriei unui neutron în plutoniu sau uraniu1.

Metoda Monte Carlo poate fi definită ca metodă de modelare a variabilelor aleatoare în vederea determinării caracteristicilor repartiției lor, atunci când aceste caracteristici nu pot fi stabilite prin expresii analitice pe baza funcțiilor teoretice de densitate de probabilitate. Prin metoda Monte Carlo, procesul real este înlocuit cu un proces artificial. Pentru obținerea unor rezultate corecte, se impune ca variabilele aleatoare generate în timpul experimentelor de simulare să reproducă fidel variabila aleatoare reală.

Calitatea eșantionului obținut prin simulare poate fi apreciată prin teste de concordanță (Kolmogorov, Smirnov, Pearson sau χ2) care măsoară apropierea dintre repartiția teoretică specificată pentru o anumită variabilă aleatoare și repartiția simulată.

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

Simularea succesului aplicației se va baza pe datele statistice furnizate de site-ul www.trafic.ro, care se ocupă cu analiza site-urilor din punct de vedere al numărului de vizitatori. Datele luate în considerare vizează numărul de vizitatori ai magazinului virtual www.samancambine.ro în primele 16 de săptămâni de la data înscrierii pe www.trafic.ro. Motivul pentru care am ales www.samancambine.ro ca punct de reper este simplu: ideea care stă la baza site-ului, precum și produsele oferite sunt similare cu cele oferite de aplicația de față, ceea ce ne permite o estimare cât mai aproape de adevăr.

Situația reală de la care am pornit în realizarea simulării este prezentată în tabelul următor:

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 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: , unde pi reprezintă probabilitățile relative asociate factorilor 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.

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

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

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:

Numărul mediu reprezintă valoarea distribuției de probabilitate în jurul căreia fluctuează valorile date.

Deviația standard se calculează conform formulei:

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

Pentru N>=30 intervalul de încredere se construiește cu relația :

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

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:

5.4 Interpretarea rezultatelor

Valorile din tabelul de mai sus ne permit unele concluzii referitoare la succesul pe care site-ul îl va înregistra în primele luni de 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.

Rezultatele obținute plasează aplicația în topul primelor 10 site-uri din categoria comerț electronic – comenzi on-line mâncare. Luând în considerare și faptul că această piață, a comenzilor on-line de mâncare, se află la începuturile dezvoltării sale și coroborat cu faptul că aplicația de față va fi prima de acest gen de pe piața Clujului, putem afirma cu încredere că site-ul se va bucura de succesul scontat.

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 România ș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 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ă 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.

BIBLIOGRAFIE

Publicații și cursuri

1. [Avornicului_2006] C. Avornicului, M. Avornicului, Sisteme – Analiză – Proiectare, Ed. Risoprint, Cluj-Napoca, 2006

2. [Bruegge_2004] B. Bruegge, A. Dutoit, Object Oriented Software Engineering, Prentice Hall, 2004

3. [BuBois_2001] P.BuBois, MySQL, Ed. Teora, București, 2001

4. [Buraga_2003] S. Buraga (coord.), Aplicații Web la cheie, Ed. Polirom, Iași, 2003

5. [Buraga_2005] S. Buraga, Tendințe actuale în proiectarea și dezvoltarea aplicațiilor Web, Iași, 26-27 noiembrie 2005

6. [Conallen_2002] J. Conallen, Building Web Applications with UML Second Edition, Addison Wesley, 2002

7. [Greenspan_2001] J. Greenspan, B. Bulger, MySQL/PHP Database Applications, M&T Books, New York, 2001

8. [McCarty_2002] B. McCarty, PHP 4, Ed. Teora, București, 2002

9. [Quatrani_2002] T. Quatrani, Visual Modeling with Rational Rose 2002 and UML, Addison Wesley, 2002

10. [Rumbaugh_1999] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, Addison Wesley, 1999

11. [Rusu_2003] L. Rusu, Proiectarea și realizarea aplicațiilor Web, Ed. Risoprint, Cluj-Napoca, 2003

12. [Suciu_2003] C. Rațiu-Suciu, Modelarea și Simularea proceselor economice, Editura Economică, București, 2003

13. [Welling_2003] L. Welling, L. Thomson, Dezvoltarea Aplicațiilor Web cu PHP și MySQL, Ed. Teora, București, 2003

Legislație

[1] Legea Nr. 365/7 Iunie 2002, privind Comerțul Electronic

[2] Legea Nr. 455/2001, privind Semnătura Electronică

[3] Regulamentul 4 din 13 iunie 2002, privind tranzacțiile efectuate prin intermediul instrumentelor de plată electronică

[4] Legea Nr. 677/2001, pentru protecția persoanelor cu privire la prelucrarea datelor cu caracter personal și libera circulație a acestor date

[5] Legea Nr. 8/1996, privind dreptul de autor și a drepturile conexe

[6] Legea Nr. 483/5 Iulie 2002, privind comunicările comerciale

Resurse Web

[site1] www.afaceri.net/articole/Webdesign/Promovare/Razboiul_cu_motoarele_de_cautare.htm

[site2] http://inf.ucv.ro/~giurca/courses/CB3105/resources/Modelarea%20Dinamica.pdf

[site3] http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme

[site4] www.MySQL.com

[site5] www.php.net

[site6] www.underclick.ro

[site7] www.hotnews.ro/articol_25442-Afaceri-on-line-tendinte-si-greseli.htm

[site8] www.business-online.ro/VersiuneaRomana/Internet&Afaceri.htmlhttp://www.galaxydesign.ro/ro/programare_web/

BIBLIOGRAFIE

Publicații și cursuri

1. [Avornicului_2006] C. Avornicului, M. Avornicului, Sisteme – Analiză – Proiectare, Ed. Risoprint, Cluj-Napoca, 2006

2. [Bruegge_2004] B. Bruegge, A. Dutoit, Object Oriented Software Engineering, Prentice Hall, 2004

3. [BuBois_2001] P.BuBois, MySQL, Ed. Teora, București, 2001

4. [Buraga_2003] S. Buraga (coord.), Aplicații Web la cheie, Ed. Polirom, Iași, 2003

5. [Buraga_2005] S. Buraga, Tendințe actuale în proiectarea și dezvoltarea aplicațiilor Web, Iași, 26-27 noiembrie 2005

6. [Conallen_2002] J. Conallen, Building Web Applications with UML Second Edition, Addison Wesley, 2002

7. [Greenspan_2001] J. Greenspan, B. Bulger, MySQL/PHP Database Applications, M&T Books, New York, 2001

8. [McCarty_2002] B. McCarty, PHP 4, Ed. Teora, București, 2002

9. [Quatrani_2002] T. Quatrani, Visual Modeling with Rational Rose 2002 and UML, Addison Wesley, 2002

10. [Rumbaugh_1999] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language Reference Manual, Addison Wesley, 1999

11. [Rusu_2003] L. Rusu, Proiectarea și realizarea aplicațiilor Web, Ed. Risoprint, Cluj-Napoca, 2003

12. [Suciu_2003] C. Rațiu-Suciu, Modelarea și Simularea proceselor economice, Editura Economică, București, 2003

13. [Welling_2003] L. Welling, L. Thomson, Dezvoltarea Aplicațiilor Web cu PHP și MySQL, Ed. Teora, București, 2003

Legislație

[1] Legea Nr. 365/7 Iunie 2002, privind Comerțul Electronic

[2] Legea Nr. 455/2001, privind Semnătura Electronică

[3] Regulamentul 4 din 13 iunie 2002, privind tranzacțiile efectuate prin intermediul instrumentelor de plată electronică

[4] Legea Nr. 677/2001, pentru protecția persoanelor cu privire la prelucrarea datelor cu caracter personal și libera circulație a acestor date

[5] Legea Nr. 8/1996, privind dreptul de autor și a drepturile conexe

[6] Legea Nr. 483/5 Iulie 2002, privind comunicările comerciale

Resurse Web

[site1] www.afaceri.net/articole/Webdesign/Promovare/Razboiul_cu_motoarele_de_cautare.htm

[site2] http://inf.ucv.ro/~giurca/courses/CB3105/resources/Modelarea%20Dinamica.pdf

[site3] http://lci.cs.ubbcluj.ro/~tzutzu/Didactic/AnalizaGestSisteme

[site4] www.MySQL.com

[site5] www.php.net

[site6] www.underclick.ro

[site7] www.hotnews.ro/articol_25442-Afaceri-on-line-tendinte-si-greseli.htm

[site8] www.business-online.ro/VersiuneaRomana/Internet&Afaceri.htmlhttp://www.galaxydesign.ro/ro/programare_web/