Proiectarea aplicatiilor web

I. Introducere în proiectarea aplicatiilor web

1.1 Categorii de aplicatii web

1.2 Caracteristicile aplicatiilor web

1.2.1 Caracteristici asociate produselor
1.2.2 Caracteristici asociate utilizarii
1.2.3 Caracteristici asociate dezvoltarii
1.2.4 Evolutie
II. Proiectarea cerintelor aplicatiilor web
2.1 Activitati de proiectare a cerintelor
2.2 Cerintele specifice proiectarii web
2.3 Proiectarea cerintelor aplicatiilor web
2.4 Adaptarea metodelor de proiectare a cerintelor la dezvoltarea aplicatiilor
web
2.4.1 Tipuri de cerinte
2.4.2 Notatii
2.4.3 Utilitare
III. Modelarea aplicatiilor web
3.1 Modelarea specifica aplicatiilor web
3.1.1 Nivele
3.1.2 Perspective
3.1.3 Faze
3.1.4 Personalizare
3.2 Modelarea cerintelor
3.3 Modelarea continutului
3.3.1 Obiective
3.3.2 Concepte
3.4 Modelarea hipertextului
3.4.1 Obiective
3.4.2 Concepte de modelare a structurii hipertext
3.4.3 Concepte de modelare a accesului
3.4.4 Modelarea continutului
3.5 Modelarea prezentarii
3.5.1 Obiective
3.5.2 Concepte
3.5.3 Relatia cu modelarea hipertextului
3.6 Modelarea personalizarii
3.6.1 Obiective
3.6.2 Concepte
3.6.3 Relatia cu modelarea continutului, hipertextului si prezentarii
 3.7 Metode si utilitare
3.7.1 Metode de modelare
3.7.2 Dezvoltarea bazata pe modele
3.7.3 Utilitare pentru suport
IV. Arhitecturile aplicatiilor web
4.1 Fundamente
4.1.1 Definitia arhitecturii
4.1.2 Arhitecturi de dezvoltare
4.1.3 Arhitecturi de clasificare
4.2 Arhitecturi specifice aplicatiilor web
4.3 Componentele arhitecturii aplicatiilor web
4.4 Arhitecturile pe straturi
4.4.1 Arhitecturile pe doua straturi
4.4.2 Arhitecturile pe n straturi
4.5 Arhitecturi specifice datelor
4.5.1 Arhitecturi centrate pe baze de date
4.5.2 Arhitecturi pentru managementul documentelor web
4.5.3 Arhitecturi pentru datele multmedia
V. Proiectarea aplicatiilor web din perspectiva tehnologiilor
5.1 Proiectarea web din perspectiva evolutionala
5.1.1 Proiectarea informatiei - activitatea de authoring
5.1.2 Proiectarea software - activitatea de programare
5.1.3 Fuziunea dintre proiectarea informatiei si proiectarea software-
ului
5.1.4 Probleme si restrictii în proiectarea web integrata
5.1.4 Abordarea structurala
5.2 Proiectarea prezentarii
5.2.1 Prezentarea nodurilor si retelelor
5.2.2 Abordarea dezvoltarii independente de dispozitiv
5.3 Proiectarea interactiunii
5.3.1 Interactiunea cu utilizatorul
5.3.2 Organizarea interfetei cu utilizatorul
5.3.3 Proiectarea navigarii
5.3.4 Proiectarea reprezentarii legaturii: ancora
5.3.4 Proiectarea legaturii interne: URL-ul
5.3.5 Navigare si orientare
5.3.6 Dialog structurat pentru activitati complexe
5.3.7 Interactiunea cu tehnologia si arhitectura
5.4 Proiectarea functionala
5.4.1 Integrarea
5.4.2 Paradigme de comunicare si middleware
 5.4.3 Aplicatii web distribuite în cadrul corporatiei
5.5 Perspective
5.5.1 Aplicatii constiente de context
5.5.2 Aplicatii independente de dispozitive
5.5.3 Reutilizare
VI. Tehnologii pentru aplicatiile web
6.1 Elemente fundamentale
6.1.1 Elemente de marcare
6.1.2 Hipertext si hipermedia
6.2 Comunicarea client/server pe web
6.2.1 SMTP - Simple Mail Transfer Protocol
6.2.2 RTSP - Real Time Streaming Protocol
6.2.3 HTTP - HyperText Transfer Protocol
6.2.4 Urmarirea sesiunilor
6.3 Tehnologii client-side
6.3.1 Programe de ajutor si plugin-uri
6.3.2 Applet-uri Java
6.3.3 Controale ActiveX
6.4 Tehnologii orientate pe documente
6.4.1 HTML - Hypertext Markup Language
6.4.2 SVG - Scalable Vector Graphics
6.4.3 SMIL - Synchronized Multimedia Integration Language
6.4.4 XML - eXtensible Markup Language
6.4.5 XSL - eXtensible Stylesheet Language
6.5 Tehnologii pe partea de server
6.5.1 Agenti URI
6.5.2 Servicii web
6.5.3 Tehnologii middleware
VII. Testarea aplicatiilor web
7.1 Elemente fundamentale
7.1.1 Terminologie
7.1.2 Caracteristici de calitate
7.1.3 Obiectivele testarii
7.1.4 Nivelele testarii
7.1.5 Rolul persoanei care testeaza
7.2 Teste specifice proiectarii web
7.3 Abordari privind testarea
7.3.1 Abordarea conventionala
7.3.2 Abordarea activa
7.4 Scheme de testare
7.4.1 Dimensiuni ale testarii
 7.4.2 Aplicarea schemei aplicatiilor web
7.4.3 Exemple de utilizare a schemei de testare
7.5 Metode si tehnici de testare
7.5.1 Testarea legaturilor
7.5.2 Testarea browser-ului
7.5.3 Testari privind usurinta în folosire
7.5.4 Testarea la suprasarcina, presiune si continua
7.5.5 Testarea securitatii
7.5.6 Dezvoltarea bazata pe testare
7.6 Automatizarea testarii
7.6.1 Beneficii si lipsuri ale testarii automate
7.6.2 Utilitare pentru testare
7.6.3 Utilitare selectate pentru testare
VIII. Operarea si întretinerea aplicatiilor web
8.1 Provocarile determinate de lansarea aplicatiilor web
8.2 Promovarea aplicatiilor web
8.2.1 stiri
8.2.2 Marketing prin afiliere
8.2.3 Marketing prin intermediul motoarelor de cautare
8.2.4 Marketing pe baza continutului
8.2.5 Managementul domeniului
8.3 Managementul continutului
8.3.1 Nivelul de actualizare al continutului
8.3.2 Furnizarea continutului
8.4 Analiza gradului de utilizare
8.4.1 Tehnici de analiza a gradului de utilizare
8.4.2 Indicatori statistici
8.4.3 Analiza comportamentului utilizatorului
IX. Managementul proiectelor web
9.1 Managementul proiectelor software vs. managentul proiectelor web
9.1.1 Obiectivele managementului proiectelor software
9.1.2 Sarcinile managementului proiectelor software
9.1.3 Zone de conflict în cadrul proiectelor
9.1.4 Particularitatile managementului proiectelor web
9.2 Provocari ale managementului proiectelor web
9.2.1 Provocari universale ale dezvoltarii software
9.2.2 Provocari caracteristice dezvoltarii proiectelor web
9.2.3 Provocari privitoare la produse în proiectele web
9.3 Managementul echipelor web
9.3.1 Dezvoltarea software-ului: o sarcina focalizata pe individ
 9.3.2 Echipa pentru proiecte web
9.3.3 Manager-ul de proiecte web
9.4 Managementul procesului de dezvoltare al aplicatiilor web
9.4.1 Lansarea utilitarelor
9.4.2 Masurarea progresului
9.4.3 Riscurile proiectului
9.4.4 Managemntul riscului
X. Procesul de dezvoltare al aplicatiilor web
10.1 Fundamente
10.2 Cerinte pentru procesul de dezvoltare a aplicatiilor web
10.2.1 Ciclurile scurte de dezvoltare
10.2.2 Schimbarea cerintelor
10.2.3 Versiuni lansate la data fixa si cu continut flexibil
10.2.4 Dezvoltarea în paralel a diferitelor versiuni
10.2.5 Reutilizare si integrare
10.2.6 Adaptarea la nivelul de complexitate al aplicatiei web
10.3 Analiza procesului unificat rational
10.3.1 Oportunitatea universala pentru dezvoltarea aplicatiilor web
10.3.2 Procesul unificat rational raspunde cerintelor aplicatiilor web?
10.4 Analiza programarii extreme
10.4.1 Programarea extrema raspunde cerintelor dezvoltarii
aplicatiilor web?
XI. Usurinta în folosire a aplicatiilor web
11.1 Definirea usurintei în folosire
11.2 Ce caracterizeaza usurinta în folosire a aplicatiilor web?
11.3 Recomandari de proiectare
11.3.1 Timpii de raspuns
11.3.2 Eficienta interactiunii
11.3.3 Culorile
11.3.4 Expunerea textului
11.3.5 Structura paginii
11.3.6 Structura de navigare
11.3.7 Multiculturalitatea
11.3.8 Masuri care genereaza încredere
11.3.9 Alte criterii de proiectare
11.4 Metode de proiectare a usur 343q169d intei în folosire a aplicatiilor web

11.4.1 Analiza cerintelor

11.4.2 Proiectarea
11.4.3 Implementarea
11.4.4 Operarea
 11.5 Directii de proiectare a usur 343q169d intei în folosire a aplicatiilor web

11.5.1 Modele de usurinta în folosire

11.5.2 Usurinta în folosire pentru dispozitivelor mobile
11.5.3 Accesibilitatea
XII. Performanta aplicatiilor web
12.1 Definirea performantei
12.2 Ce caracterizeaza performanta aplicatiilor web?
12.3 Caracterizarea sistemului si indicatori
12.4 Caracterizarea capacitatii de efort
12.5 Tehnici analitice
12.5.1 Analiza operationala
12.5.2 Modele de simulare
12.5.3 Tehnici de masurare
12.6 Reprezentarea si interpretarea rezultatelor
12.7 Metode de optimizare a performantei
12.7.1 Accelerarea în interiorul aplicatiei web
12.7.2 Reducerea timpului de transmisie
12.7.3 Tuning-ul serverului
XIII. Securitatea aplicatiilor web
13.1 Laturile securitatii
13.2 Criptarea, semnatura digitala si certificatele
13.2.1 Criptarea simetrica
13.2.2 Criptarea asimetrica
13.2.3 Semnatura digitala
13.2.4 Infrastructura certificatelor si cheilor publice
13.3 Securizarea interactiunii client/server
13.3.1 Securitatea punct-la-punct
13.3.2 Securitatea capat la capat
13.3.3 Autentificarea si autorizarea utilizatorului
13.3.4 Sisteme de plati electronice
13.4 Probleme de securitate a clientului
13.4.1 Pastrarea confidentialitatii
13.4.2 Securitatea codului schimbator
13.4.2 Phishing si spoofing web
13.4.2 Securitatea sistemului desktop
13.5 Probleme de securitate a furnizorului de servicii
13.5.1 Scripting cross-site
13.5.2 Injectia SQL
13.5.3 Securitatea programelor CGI
13.5.4 Disponibilitatea serviciilor
 13.5.5 Securitatea sistemului gazda
XIV. Web-ul semantic - reteaua plina de înteles din reteaua documentelor
14.1 Fundamentele web-ului semantic
14.1.1 Rolul agentilor software
14.1.2 Rolul etichetelelor semantice
14.1.3 Rolul ontologiilor
14.2 Concepte tehnologice
14.2.1 Agenti conform standardului FIPA
14.2.2 Ontologii
14.2.3 Etichete semantice pentru web
14.3 Elemente specifice aplicatiilor web semantice
14.3.1 Etichete semantice
14.3.2 Agenti
14.3.3 Ontologii
14.3.4 Servicii web semantice
14.3.5 Integrarea în proiectarea web
14.4 Utilitare
Proiectarea web - disciplina dezvoltarii sistematice a aplicatiilor web
Proiectarea web ca disciplina stiintifica este influentata de dezvoltarea
aplicatiilor web. Orientarea actuala în domeniul dezvoltarii aplicatiilor web este
deseori caracterizata printr-o abordare ad-hoc si o lipsa a metodelor de dezvoltare.
Datorita complexitatii si ritmului proliferarii aplicatiilor web, aceasta abordare are un
impact negativ asupra calitatii. Aplicatiile web reprezinta un nou domeniu de
aplicatii cu propriile sale provocari asupra dezvoltarii software-ului.
Este necesara construirea unui ciclu de viata a aplicatiilor web, prezentarea
conceptelor, tehnicilor, metodelor si utilitarelor pentru dezvoltarea sistematica a
aplicatiilor web.
Web-ul, aplicatiile web si comunitatea web în ansamblu au evoluat de la
aparitia Internet-ului la Web 2.0 si la viziunea web-ului semantic, din acest motiv
fiind esentiala renuntarea la abordarea de tip ad-hoc si adoptarea principiilor
proiectarii web.
La nivel de infrastructura, web-ul este un spatiu creat prin intermediul unor
limbaje si protocoale specificate formal. Desi oamenii sunt implicati în crearea
paginilor si utilizarea legaturilor dintre acestea, interactiunea acestora formeaza un
model web la scara macroscopica. Aceste interactiuni umane sunt guvernate de
conventii sociale, politici si legi. Dezvoltarea aplicatiilor web este rezultatul unei
afaceri complexe si este esential ca proiectarea care sprijina aceasta dezvoltare sa fie
bine realizata. Acest lucru va permite studentilor si specialistilor sa proiecteze
aplicatii web de o calitate superioara pe baza principiilor de proiectare software
experimentate si de încredere.
I. Introducere în proiectarea aplicatiilor web
 Aplicatiile web moderne sunt sisteme software complexe, iar dezvoltarea
acestora necesita o abordare metodologica a proiectarii lor. Similar cu proiectarea
aplicatiilor software, proiectarea web implica utilizarea unei abordari sistematice si
cuantificabile pentru realizarea specificatiilor, implementarii, operatiilor si
întretinerii aplicatiilor web de calitate superioara. Din punct de vedere al istoricului
dezvoltarii si complexitatii distingem anumite tipuri de aplicatii web; aplicatiile web
pot fi orientate pe documente, interactive, tranzactionale, pot dispune de
caracteristici ubicue sau chiar de trasaturi ale web-ului semantic. Cerintele
particulare ale proiectarii aplicatiilor web rezulta din caracteristicile lor speciale din
sfera produselor software, dezvoltarii si utilizarii acestora. Evolutia este o
caracteristica care cuprinde cele trei sfere mentionate.
World Wide Web are o influenta enorma si permanenta asupra vietii noastre.
Economia, industria, educatia, sanatatea, administratia publica si distractia
reprezinta componente ale vietii noastre care nu au fost patrunse de World Wide
Web. Motivul acestei omniprezente consta în special în natura web-ului,
caracterizata prin disponibilitatea globala si permanenta dar si prin accesul omogen
la informatiile distribuite la nivel global produse indivizi sub forma paginilor web1[1].
Initial, web-ul a fost proiectat ca un mediu pur informational, în prezent
evoluând într-un mediu al aplicatiei. Aplicatiile web de astazi sunt rapide si
reprezinta sisteme software complexe care ofera servicii interactive si
personabilizabile accesibile prin intermediul diferitelor dispozitive; ele ofera
posibilitatea realizarii tranzactiilor între utilizatori si de obicei stocheaza datele într-o
baza de date. Elementul distinctiv al aplicatiilor web, comparativ cu aplicatiile
software traditionale, este modul în care este utilizat web-ul: de exemplu
tehnologiile si standardele sale sunt utilizate ca o platforma de dezvoltare si ca
platforma utilizator în acelasi timp. O aplicatie web poate fi definita astfel:
O aplicatie web este un sistem software bazat pe tehnologiile si standardele
consortiului World Wide Web (W3C) care ofera resurse web specifice cum ar fi
continut si servicii prin intermediul unei interfete numita browser web.
Aceasta definitie include în mod explicit tehnologiile dar si interactiunea
utilizatorului. De aici putem deduce ca tehnologiile în sinea lor, la fel ca si serviciile
web, nu sunt aplicatii web, dar pot fi o parte a acestora. În plus, aceasta definitie
implica ca siturile web lipsite de componente software, cum sunt paginile HTML
statice, sa nu fie considerate aplicatii.
În ciuda schimbarilor fundamentale ale web-ului de la un mediu informational
la un mediu al aplicatiilor, situatia actuala a dezvoltarii ad-hoc a aplicatiilor web ne
aminteste de practicile de dezvoltare a software-ului din 1960 înainte sa se realizeze

1[1] Berners-Lee, T., WWW: Past, Present, and Future, IEEE Computer, 29 (10), 1996, pp. 69-77
 ca dezvoltarea aplicatiilor necesita mai mult decât experienta în programare2[2].
Dezvoltarea aplicatiiilor web este vazuta ca un eveniment spontan, de obicei bazat
pe cunoastere, experienta si practici de dezvoltare ale dezvoltatorilor individuali,
limitat la reutilizare la modul "Copy & Paste" si în cele din urma caracterizata de o
documentare necorespunzatoare a deciziilor de proiectare. Desi aceasta procedura
poate pare pragmatica, astfel de metode rapide si neadecvate de dezvoltare conduc
deseori la probleme serioase privitoare la calitate si la dificultati de operare si
întretinere. Aplicatiile dezvoltate sunt deseori dependente de tehnologie,
încorporeaza erori si sunt caracterizate prin lipsuri privind performanta, siguranta,
scalabilitatea, atitudinea prietenoasa si chiar întelesul3[3]. Legatura strânsa dintre
aplicatiile web sporeste gravitatea problemei raspândindu-se de la o aplicatie la alta.
Cauza acestei situatii este complexa si poate fi abordata din mai multe perspective:
- abordarea centrata pe documente. Dezvoltarea aplicatiilor web este deseori
considerata centrata pe documente, cum ar fi de exemplu activitatea de authoring
care include crearea si realizarea legaturilor din siturile web dar si includerea
elementelor grafice4[4]. Desi anumite tipuri de aplicatii web (de exemplu paginile
principale, ziarele online) sunt incluse în aceasta categorie, o abordare prin prisma
authoring-ului nu este adecvata pentru dezvoltarea de aplicatii software concentrate
pe web;
- presupusa simplitate a dezvoltarii aplicatiilor web. Disponibilitatea larga a
diferitelor utilitare, cum ar fi editoarele HTML sau generatoarele de formulare
permite crearea de aplicatii web simple care nu necesita cunostinte specializate. De
obicei, accentul se pune pe proiectarea vizuala si nu pe structurarea interna si pe
programare. Aceasta duce la inconsistente si redundanta;
- cunostintele specifice din discipline relevante nu pot aplicate sau utilizate.
Exista o conceptie gresita conform careia dezvoltarea aplicatiilor web este similara
cu dezvoltarea aplicatiilor web traditionale si din acest motiv metodele din ingineria
software pot fi utilizate în sensul abordarii sistematice, cu masuri adecvate de
control a calitatii. Acest lucru este neadecvat în majoritatea cazurilor datorita
caracteristicilor speciale ale aplicatiilor web. În plus, concepte si tehnici din domenii
relevante cum ar fi hypertext sau interactiunea om-calculator nu sunt aplicate într-o
maniera consecventa. Standardele de dezvoltare pentru aplicatiile web de calitate
sunt neexistente, acest lucru datorându-se si relativei scurte istorii a web-ului.

2[2] Pressman, R. S., Can WebApps Be Engineered?, SPC Essentials, Software Productivity Center, May 2000a, la
http://www.spc.ca/essentials/may0300.htm , [vizitat la: 2007-10-01]

3[3] Fraternali, P., Tools and Approaches for Data-intensive Web Applications: A Survey, ACM Computing Surveys,
31 (3), September, 1999, pp. 227-263

4[4] Ginige, A., Lowe, D., Robertson, J., Hypermedia Authoring, IEEE Multimedia, 2 (4), Winter, 1995, pp. 24-35
 Practicile curente privind dezvoltarea aplicatiilor web, cresterea complexitatii
si relevantei acestora pentru diverse segmente ale societatii si în particular pentru
functionarea eficienta a proceselor critice ale afacerii (de exemplu comertul
electronic), au evoluat datorita preocuparilor privind acest tip de dezvoltare si
calitatii pe termen lung a aplicatiilor web, acestea având deja o contributie
considerabila la software-ul dezvoltat în prezent5[5].
Proiectarea web nu este un eveniment imediat; este un proces realizat pe tot
parcursul ciclului de viata a aplicatiei web, similar cu proiectarea software-ului. Este
necesara o abordare disciplinara diferita pentru proiectarea web fata de proiectarea
software-ului?
O disciplina poate fi definita ca un domeniu de studiu al stiintei, mai mult sau
mai putin independent care include cercetarea, învatarea si cunoasterea stiintifica
sub forma publicatiilor. Numarul mare de publicatii, cursuri, programe analitice,
seminarii stiintifice si conferinte demonstreaza ca, în acord cu aceasta definitie,
proiectarea web poate fi considerata un domeniu independent a proiectarii
software-ului6[6]. Proiectarea reprezinta în general o aplicatie practica a stiintei
folosita în scopul planuirii aplicatiilor într-un mod mai bun, mai rapid, mai ieftin si
mai sigur. Proiectarea software este definita ca o aplicatie a stiintei si matematicii
prin care capacitatile unui sistem de calcul sunt facute utile oamenilor prin
intermediul programelor, procedurilor si documentatiei asociate7[7]. Pe baza acestei
definitii si a celei lui Despande8[8], putem defini proiectarea web în doua moduri:
- proiectarea web reprezinta aplicarea unei abordari sistematice si
cuantificabile (concepte, metode, tehnici si utilitare) în analiza, proiectarea,
implementarea, testarea, operarea si întretinerea aplicatiilor web de calitatea
superioara;
- proiectarea web reprezinta o disciplina stiintifica implicata în studiul acestei
abordari. Termenii din literatura asociati sunt proiectarea siturilor web9[9],

5[5] Deshpande, Y., Hansen, S., Web Engineering: Creating a Discipline among Disciplines, Special Issue on

Web Engineering, IEEE Multimedia, 8 (2), April-June, 2001, pp. 82-87

6[6] Kappel, G., Michlmayr, E., Web Engineering - Old Wine in New Bottles? Proc. of the 5th International
Conference on Web Engineering (ICWE 2005), Springer LNCS 3255, Munich, Germany, 2005

7[7] Boehm, B. W., Software Engineering, IEEE Transactions on Computers, 25 (12), 1976, pp. 1226-1241

8[8] Deshpande, Y., Murugesan, S., Ginige, A., Hansen, S., Schwabe, D., Gaedke, M., White, B., Web Engineering,
Journal of Web Engineering, 1 (1), 2002, pp. 3-17

9[9] Powell, T., Jones, D., Cutts, D., Web Site Engineering: Beyond Web Page Design, Prentice Hall, 1998.

Pressman, R. S., Can Internet-Based Applications Be Engineered?, IEEE Software, 15 (5), September-

October, 1998, pp. 104-110

 proiectarea hipermedia10[10], proiectarea documentelor11[11], proiectarea
continutului12[12] si proiectarea software-lui Internet13[13]. Prin comparatie,
"proiectarea web" este un termen concis, desi daca vorbim în mod strict nu are o
acuratete totala: nu web-ul este proiectat ci aplicatiile web sunt proiectate.
Din punct de vedere al proiectarii software-ului, dezvoltarea aplicatiilor web
este un nou domeniu al aplicatiilor14[14]. În ciuda anumitor similitudini cu aplicatiile
traditionale, caracteristicile speciale ale aplicatiilor web necesita o adaptare a
multiplelor abordari ale proiectarii software-lui sau chiar a dezvoltarii de abordari
complet noi.
Principiile de baza ale proiectarii web pot fi descrise în mod similar cu cele ale
proiectarii software:
- obiective si cerinte clar definite;
- dezvoltarea sistematica, în faze, a aplicatiilor web;
- o planificare foarte atenta a acestor faze;
- auditul continuu a întregului proces de dezvoltare.
Proiectarea web face posibila planificarea si repetarea proceselor de
dezvoltare si în acest mod faciliteaza evolutia continua a aplicatiilor web. Aceasta
permite nu doar reducerea costurilor si minimizarea riscului pe parcursul dezvoltarii
si întretinerii, ci si cresterea calitatii, precum si masurarea calitatii rezultatelor
fiecarei faze15[15].

1.1 Categorii de aplicatii web

Aplicatiile web au grade variate de complexitate. Acestea pot fi pur
informationale sau aplicatii de comert electronic complexe care functioneaza 24 de
ore pe zi / 7 zile pe saptamâna. În functie de cronologia (istoricul) dezvoltarii si
gradul de complexitate au fost identificate diferite categorii de aplicatii web (o

10[10] Lowe, D., Engineering the Web - Web Engineering or Web Gardening? WebNet Journal, 1 (1), January-
March, 1999

11[11] Glushko, R., McGrath, T., Document Engineering for E-business, Proc. of the ACM Symposium on
Document Engineering (DocEng) (held in conjunction with the ACM Int. Conf. on Information and Knowledge
Management, CIKM), Virginia, USA, November 2002

12[12] Reich, S., G¨untner, G., Digital Content Engineering - An Introduction, Proc. of Digital Content Engineering-
Content Plattformen in Theorie und Praxis. Trauner Verlag, 2005

13[13] Balasubramaniam, R., Pries-Heje, J., Baskerville, R., Internet Software Engineering: A Different Class of
Processes, Annals of Software Engineering, 14 (1-4), December, 2002, pp. 169-195

14[14] Glass, R. L., A Mugwump's-Eye View of Web Work, Communications of the ACM, 46 (8), August, 2003,

pp. 21-23

15[15] Mendes, E., Mosley, N., Web Engineering, Springer, 2006

clasificare similara se poate observa si la Pressman16[16]), asa cum putem observa si
în figura 1.1:

Figura 1.1: Categorii de aplicatii web

Trebuie sa remarcam faptul ca exista o corelatie între cronologia dezvoltarii si
complexitate. De exemplu, aplicatiile bazate pe fluxuri sunt bazate pe tranzactii,
adica nivelul înalt de dezvoltare necesita o dezvoltare anterioara a unei categorii mai
putin complexe. Exista si exceptii de la aceasta regula pentru anumite categorii (de
exemplu aplicatiile orientate pe portaluri) care sunt recente din punct de vedere
istoric dar au un grad scazut de complexitate.
Prezenta pe web a organizatiilor care au fost pe web de la începuturi au avut
deseori un istoric al dezvoltarii similar cu cel descris în figura 1.1. Este cert faptul ca
dezvoltarea aplicatiilor web poate fi începuta de la oricare din aceste categorii si
ulterior dezvoltata catre un nivel sporit de complexitate. Noile categorii sunt în
general mult mai complexe, dar aceasta nu înseamna ca ele pot înlocui în totalitate
vechea generatie. Fiecare din aceste categorii dispun de domenii specifice ale
aplicatiilor. În consecinta, aplicatiile web complexe pot fi în mod tipic alocate mai
multor categorii odata. De exemplu, magazinele online de cumparaturi nu integreaza
doar diferiti furnizori de servicii dar ofera si diferite posibilitati de cautare,
monitorizarea starii comenzilor si în anumite cazuri chiar licitatii online.
Putem sesiza ca diferite categorii de aplicatii web acopera mai multe domenii
traditionale ale aplicatiilor, cum ar fi bancile online, dar în acelasi timp creaza noi
domenii ale aplicatiilor, cum ar fi serviciile pentru anumite locatii (location-aware

16[16] Pressman, R. S., Applying Web Engineering. In: Software Engineering: A Practitioner's Approach, 6th
Edition, McGraw-Hill, 2005
 services). În cele ce urmeaza vom descrie trasaturile relevante ale acestor categorii.

Siturile web axate pe documente sunt precursoare ale aplicatiilor web.

Paginile web sunt stocate pe un server web deja configurat, sunt statice, iar
documentele HTML sunt trimise clientului web ca raspuns la o cerere. Aceste pagini
web sunt de obicei actualizate manual utilizând utilitare corespunzatoare. Pentru
siturile web care impun schimbari frecvente sau pentru siturile web cu un numar
mare de pagini aceasta este un factor semnificativ pentru costuri si adesea are drept
consecinta informatii depasite. În plus exista pericolul aparitiei inconsistentelor
atunci când un anumit continut este prezentat frecvent în mod redundant pe mai
multe pagini web pentru a usura accesul. Principalul beneficiu este simplitatea si
stabilitatea unui astfel de sit web dar si timpul scurt de raspuns, paginile fiind deja
stocate pe serverul web. Paginile principale statice si simpla prezenta pe web a
micilor afaceri apartin acestei categorii.
Odata cu aparitia Common Gateway Interface (http://hoohoo.ncsa.uiuc.edu/cgi/
interface.html) si formularelor HTML, au aparut aplicatiile web interactive, oferind o
prima simpla forma de interactivitate prin intermediul formularelor, butoanelor
radio si meniurilor de selectie. Paginile web si legaturile catre alte pagini sunt
generate în mod dinamic în acord cu ceea ce introduce utilizatorul. Exemple de
astfel de categorii sunt prezentarile virtuale, siturile de stiri sau planificarea
calatoriilor.
Aplicatiile web tranzactionale au fost create pentru a oferi mai multa
interactivitate, oferind utilizatorului posibilitatea de a nu interactiona cu aplicatia
doar în modul citire, acesta având posibilitatea de a realiza actualizari ale
continutului de baza. Daca luam în considerare un sistem informational pentru
turism acesta va permite actualizarea continutului într-un mod descentralizat sau
face posibila rezervarea camerelor. Premisa necesara pentru un asfel de sistem
implica existenta unor sisteme de baze de date care permit manevrarea consistenta
a unei cantitati în continua crestere de continut în aplicatiilor web si ofera
posibilitatea structurarii interogarilor. Bancile online, magazinele online si sistemele
de rezervare apartin acestei categorii.
Aplicatiile web bazate pe fluxuri permit manevrarea fluxurilor în interiorul
sau între diferite companii, reprezentanti publici si utilizatori individuali. Este
esentiala pentru aceste aplicatii disponibilitatea serviciilor web adecvate pentru
asigurarea interoperabilitatii17[17]. Complexitatea serviciilor, autonomia
companiilor participante si necesitatea ca aceste fluxuri sa fie robuste si flexibile
sunt principalele provocari. Exemple pentru aceste categorii sunt solutiile B2B

17[17] Weerawarana, S., Curbera, F., Leymann, F., Storey, T., Ferguson, D. F., Web Services Platform Architecture,

Prentice Hall, 2005

 (Business-to-Business) din comertul electronic, aplicatiile e-government din
domeniul administratiei publice sau suportul web pentru fluxurile de pacienti din
sectorul sanatatii.
În timp ce aplicatiile bazate pe fluxuri necesita o anumita structurare a
proceselor automatizate si a operatiilor, aplicatiile web colaborative sunt folosite
îndeosebi în scopul cooperarii pentru operatiile nestructurate (groupware). Exista o
nevoie sporita pentru comunicatie între utilizatorii care coopereaza. Aplicatiile web
colaborative suporta distribuirea informatiei si spatiile de lucru (de exemplu
WikiWiki - http://c2.com/cgi/wiki - sau BSCW - http://bscw.gmd.de/ -) pentru a
genera, edita si administra informatiile distribuite. Acestea sunt utilizate si pentru a
pastra log-urile anumitor intrari si a le edita (cum sunt log-urile web), pentru a media
întâlnirile sau pentru luarea deciziilor (un exemplu poate fi camerele de discutii -
chat rooms), pentru sistemele de planificare sau ca platforme de e-learning.
Cu toate ca web-ul a fost initial caracterizat prin anonimat, exista o orientare
în crestere spre web-ul social, în care indivizii îsi ofera identitatea unei mici
comunitati cu interese similare. Log-urile web sau sistemele colaborative de filtrare
cum ar fi friendster (http://friendster.com), care ofera posibilitatea de a gasi nu
numai anumite subiecte de interes ci si persoane cu interese similare, apartin acestei
categorii de aplicatii.
Aplicatiile orientate pe portaluri ofera un singur punct de acces la surse de
informatie si servicii distincte / potential eterogene18[18]. Realizatorii de browsere
(Microsoft, Netscape), motoarele de cautare (Yahoo), serviciile online (AOL),
conglomeratele media si alte companii au devenit constiente de cererea existenta si
ofera acum hub-uri centrale sau asa numitele portaluri, ca punct de acces la web. Pe
lânga aceste portaluri generale, exista diverse portaluri specializate cum ar fi
portalurile de afaceri, portalurile de piata sub forma magazinelor de vânzare online
si portalurile comunitatii. Portalurile afacerii ofera angajatilor si/sau partenerilor
afacerii un acces focalizat la diferite surse de informatie si servicii prin intranet sau
extranet. Portalurile de piata sunt împartite în piete orizontale si verticale. Pietele
orizontale functioneaza pe piata B2C oferind bunuri de consum direct publicului, si în
B2B, vânzând produsele sale altor companii din alte sectoare de activitate. Pietele
verticale se reduc la companiile dintr-un singur sector de activitate, cum ar fi
furnizorii pe de o parte si producatorii pe de alta parte. Portalurile comunitatilor
sunt dirijate catre grupuri tinta specifice (de ex. tinerii) si încearca sa creeze o
loialitate a clientilor prin intermediul interactiunilor cu utilizatorii sau sa asigure
oferte individuale printr-un management al utilizatorilor adecvat (marketing unu-la-
unu).
O categorie importanta este reprezentata de aplicatiile web omniprezente
care ofera servicii personalizate oricând si oriunde si pentru orice dispozitiv, astfel

18[18] Wege, Ch., Portal Server Technology, IEEE Internet Computing, 6 (3), May-June, 2002, pp. 73-77
 facilitând accesul de oriunde. Un exemplu poate fi afisarea meniului zilei pe
dispozitivele mobile ale tuturor utilizatorilor care intra în restaurant între 11 am si 2
pm. Pentru acest tip de sistem este important sa luam în calcul limitarile
dispozitivelor mobile (latimea de banda, dimensiunea ecranului, memoria, lipsa de
maturitate a software-ului) si contextul în care aplicatiile web sunt în mod obisnuit
utilizate.
Dezvoltarile prezente si în special convergenta sporita a domeniului TIMES
(telecomunicatii, tehnologia informatiei, multimedia, educatie si amuzament,
securitate), vor conduce, în viitorul apropiat, la o situatie în care aplicatiile
omniprezente vor domina piata. Unul dintre aceste dezvoltari este web-ul semantic.
Obiectivul web-ului semantic este prezentarea informatiei pe web nu numai pentru
indivizi ci si sub forma usor de citit pentru sistemele de calcul19[19]. Acesta va
facilita managementul cunostintelor pe web si în particular conectarea si reutilizarea
cunoasterii (sindicalizarea continutului), dar si localizarea cunostintelor noi
relevante, cu ajutorul sistemelor recomandate. Datorita interactivitatii crescute la
nivel semantic si posibilitatii executiei sarcinilor automate (prin intermiediul
agentilor intelegenti), putem afirma ca web-ul va deveni mai omniprezent si prin
urmare mai relevant în viata de zi cu zi.
1.2 Caracteristicile aplicatiilor web
Aplicatiile web difera de aplicatiile traditionale (non-web), particularitatile
acestora fiind prezentate în cele ce urmeaza. Acestea sunt pe de o parte
caracteristicile de care aplicatiile traditionale nu au nevoie (de exemplu navigarea
non-liniara) si caracteristicile care prezinta o importanta particulara (de exemplu
frecventa actualizarilor), pe de alta parte.
Chiar daca o anumita caracteristica este prezenta si depinde într-o anumita
masura de tipul de aplicatie web, dezvoltarea aplicatiilor web tranzactionale cum ar
fi sistemele de e-commerce necesita o focalizare mai atenta asupra actualizarii si
consistentei continutului comparativ cu sistemele informationale pure - de exemplu
prezentarile virtuale. Aceste caracteristici sunt motivul pentru care numeroase
concepte, metode, tehnici si utilitare ale proiectarii software traditionale trebuie
adaptate la cerintele proiectarii web, desi în unele situatii acestea pot fi în totalitate
neadecvate. Figura 1.2 ne ofera o imagine a acestor caracteristici si le împarte în trei
dimensiuni: "produs", "utilizare" si "dezvoltare", împreuna cu "evolutia" vazuta ca o
dimensiune atotcuprinzatoare.

19[19] Berners-Lee, T., Hendler, J., Lassila, O., The Semantic Web, Scientific American, May, 2001
Figura 1.2 Dimensiunile conform cu standardul ISO/IEC 9126-1 pentru clasificarea
caracteristicilor aplicatiilor web
(http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumb
er=22749)

Aceste dimensiuni se bazeaza pe standardul ISO/IEC 9126-1 pentru evaluarea

caracteristicilor de calitate ale software-ului (http://www.iso.org). Prin atribuirea
diferitelor caracteristici ale aplicatiilor web acestor dimensiuni putem observa
influenta acestora asupra calitatii aplicatiilor si astfel sa consideram caracteristicile
ca un punct de pornire pentru definirea necesarului proiectarii web. Pe lânga
caracteristicile asociate produselor, utilizarii si dezvoltarii exista si evolutia ca o a
patra dimensiune care guverneaza cele trei dimensiuni. Produsele trebuie sa fie
adaptabile, noul context informational trebuie luat în considerare pe durata utilizarii,
iar modalitatile de dezvoltare vor modifica în mod continuu schimbarile care vor
apare. În continuare, vom prezenta caracteristicile individuale conform acestor
dimensiuni.
1.2.1 Caracteristicile produselor
Caracteristicile produselor constituie segmentul principal al aplicatiilor web si
pot consta în continut, structura hipertextuala (structura de navigare) si prezentare
(interfata utilizator). Conform paradigmei orientata obiect, fiecare din aceste parti
nu are doar aspecte structurale sau statice ci si aspecte comportamentale sau
dinamice.
Continut
Generarea continutului, disponibilizarea acestuia, integrarea si actualizarea
sunt în egala masura importante la fel cum sunt dezvoltarea si testarea aplicatiilor
web. Aplicatiile web sunt utilizate în mod expres datorita continutului pe care îl
ofera, fiind valabil motto-ul "Continutul este regele". Dezvoltatorii aplicatiilor web
trebuie prin urmare sa nu se comporte doar ca programatori dar si ca autori.
Aspectele importante vizeaza gradul variat al structurii continutului si calitatea
cererilor pe care utilizatorii le au asupra continutului.
* Caracterul axat pe documente si multi-median. În functie de modul de organizare,
continutul este oferit sub forma tabelelor, textului, elementelor grafice, animatiilor,
elementelor audio sau video. Natura documentului în aplicatiile web se refera la
faptul ca continutul este asigurat, respectiv documentele sunt generate în mod
adecvat pentru anumite grupuri de utilizatori (de exemplu informatii pentru turisti
într-o anumita zi de sarbatoare dintr-o anumita regiune). Aceasta implica si anumite
cerinte speciale privitoare la usurinta în folosire. Continutul este într-o anumita
proportie generat si actualizat dinamic (de exemplu numarul de camere disponibile
dintr-un sistem informational pentru turism). Mai mult, web-ul poate fi folosit ca
infrastructura pentru transmiterea continutului multimedia (de exemplu
videoconferinte sau aplicatiii Real Audio).
* Calitatea cererilor. În functie de domeniul aplicatiei, continutul unei aplicatii
web nu este doar un subiect pentru diferentierea frecventei actualizarilor, dar si
pentru diferentierea masuratorilor de calitate privitoare la actualitate, exactitate,
consistenta si încredere. Aceasta necesita nu numai luarea în considerare a acestor
cereri calitative în definirea necesarului, dar si evaluarea conformitatii cu aceste
principii.
Siturile de stiri, de exemplu, necesita o frecventa sporita a actualizarilor si
trebuie sa faca fata cererilor de ultima ora ale utilizatorilor. Web-ul ca mediu de
distribuire a informatiei, alaturi de televiziune, radio si presa, ofera un potential
enorm pentru adresarea acestor cereri, mult mai bine decât mijloacele de informare
traditionala, prin intermediul personalizarii. Pe de alta parte, exista opinii conform
carora aplicatiile "inteligente", "constiente" de locatie, necesita dezvoltarea unui
nou gen de aplicatii; motivul este ca aceste aplicatii bazate pe continut cum ar fi
podcasting sau continut mobil sunt un mediu diferit decât cele care nu se pot adapta
cu usurinta la continutul existent.
În particular, calitatea superioara este necesara pentru pretul si utilitatea
informatiei în sistemele de cumparare online, acestea formând baza tranzactiilor
unei afaceri. Preturile incorecte pot duce la anularea vânzarii, iar informatia
învechita sau indisponibila poate conduce la nevânzarea produselor din stoc sau la
probleme de livrare deoarece produsele afisate drept disponibile nu exista în stoc.
Indiferent de scopul în care sunt utilizate aplicatiile web, calitatea continutului este
un factor esential. Marea provocare implica capacitatea de a garanta calitatea
datelor în ciuda unui volum mare si frecvent de actualizari.
Hipertext
 Dintre caracteristicile specifice aplicatiilor web relevanta este natura non-
liniara a documentelor hipertextuale. Paradigma hipertext, folosita ca baza pentru
structurarea si prezentarea informatiei a fost prezentata de Vannevar Bush20[20].
Elementele de baza ale modelelor hipertext sunt nodurile, legaturile si ancorele. Un
nod este o unitate de informatie unic identificata, cu continut propriu. Pe web
acesta poate fi un document HTML care poate fi accesat printr-un URL (Uniform
Resource Locator). O legatura este calea de la un nod la altul. Pe web aceste cai sunt
întodeauna unidirectionale, întelesul acestora nefiind clar definit (poate fi urmatorul
nod în acord cu ordinerea de citire recomandata). O ancora este o zona din
continutul unui nod care este sursa sau destinatia unei legaturi (de exemplu o
secventa de cuvinte dintr-un text sau obiect grafic dintr-o figura). Pe web, ancorele
sunt posibile doar în documentele HTML.
Trasatura esentiala a paradigmei hipertext este non-liniaritatea continutului
produs de autori si a continutul receptat de utilizatori, împreuna cu problemele
potentiale de dezorientare si supra-încarcare cognitiva.
* Non-liniaritatea. Hipertextul implica stereotipuri privind citirea sistematica
relativa, si prin aceasta aplicatiile web difera în mod evident de aplicatiile software
traditionale. Acest stil individual de citire, adaptabil la nevoile si comportamentul
utilizatorilor este cel mai indicat pentru dezvoltarea abilitatii de învatare. Utilizatorii
se pot misca liberi în spatiul informational, în functie de interesele si cunostintele
anterioare. Ancorele si legaturile nu sunt doar predefinite în mod static de autori, ele
putând fi generate dinamic (legaturi evaluate) ca o reactie predefinita la
comportamentul utilizatorilor. Crearea hipertextului a fost o provocare permanenta
pentru autori, pe masura cautarii eliminarii dezorientarii si supra-încarcarii cognitive
pentru utilizatori.
* Dezorientarea si supra-încarcarea cognitiva. Este important în dezvoltarea
aplicatiilor web sa întelegem aceste doua probleme fundamentale ale paradigmei
hipertext. Dezorientarea reprezinta tendinta de a pierde pozitia într-un document
non-liniar. Supra-încarcarea cognitiva este determinata de concentrarea
suplimentara solicitata de memorarea simultana a diverselor cai sau sarcini. Hartile
siturilor, cautarea prin intermediul cuvintelor cheie, urmarirea cailor (modul history)
si afisarea timpului de accesare si a timpului petrecut pe sit ajuta utilizatorii sa-si
pastreze orientarea pe aplicatie. Legaturile pline de înteles si denumirea inteligenta
a legaturilor reduce supra-încarcarea cognitiva. În plus, folosirea sabloanelor de
proiectare în modelarea aspectului hipertext poate ajuta la contracararea acestei
probleme.
Prezentarea

20[20] Bush, V., As We May Think, The Atlantic Monthly, 176 (1), 1945, pp. 101-108.
 La nivelul prezentarii, principalele doua caracteristici ale aplicatiilor web sunt
estetica si auto-explicarea.
Estetica. Spre deosebire de aplicatiile traditionale, estetica la nivelul
prezentare a aplicatiilor web, elementul "look and feel" al interfetei utilizator este
factorul central datorita presiunii competitive ridicate de pe web. Prezentarea
vizuala a paginilor web este un subiect la moda si deseori determina succesul sau
esecul, în special pentru aplicatiile de e-commerce21[21].
Auto-explicarea. Dincolo de estetica, este esential ca aplicatiile web sa fie
auto-explicative, respectiv sa fie posibila utilizarea aplicatiei web fara a consulta o
documentatie în prealabil. Sistemul de navigare sau cel care implica interactiunea
trebuie sa fie consistent în întreaga aplicatie, astfel încât utilizatorii sa devina
familiari cu utilizarea aplicatiei web.
1.2.2 Caracteristici asociate utilizarii
Comparativ cu aplicatiile traditionale, utilizarea aplicatiilor web este extrem
de eterogena. Utilizatorii difera prin prisma numarului si culturii generale,
dispozitivele folosite având caracteristici hardware si software diferite, iar ora si
locatia de unde este accesata aplicatia nu poate fi prevazuta. Dezvoltatorii nu au
posibilitatea de a cunoaste apriori potentiala diversitate a acestor factori contextuali
si nu-i pot influenta în nici un mod datorita naturii lor autonome. Este greu chiar si sa
prezicem frecventa de utilizare a unei aplicatii web.
Utilizarea aplicatiilor web este prin urmare caracterizata de necesitatea
adaptarii continue la situatii de utilizare specifice (contexte). Reglarea acestor
contexte poate fi necesara în mod egal pentru toate partile aplicatiilor web
(continut, hipertext si prezentare). Datorita semnificatiei ajustarii contextului,
caracteristicile asociate utilizarii sunt împartite în trei grupuri: context social, context
tehnic si context natural.

Contextul social: utilizatorii

Contextul social se refera la aspecte specifice utilizatorului; spontaneitatea si
multiculturalitatea creaza un grad înalt de eterogenitate.
Spontaneitatea. Utilizatorul poate vizita si parasi o aplicatie web oricând
doreste, chiar daca este situl unui competitor. Utilizatorul web nu trebuie sa fie loial
nici unui furnizor de continut, web-ul fiind un mediu care nu atrage nici o obligatie.
Deoarece este usor sa gasim aplicatii concurente cu ajutorul motoarelor de cautare,
utilizatorii vor utiliza o aplicatie web doar daca le va aduce un avantaj imediat.
Multiculturalitatea. Aplicatiile web sunt dezvoltate pentru diferite grupuri de
utilizatori. Daca grupul luat în discutie este un grup de utilizatori cunoscut (poate fi

21[21] Pressman, R. S., Can WebApps Be Engineered?, SPC Essentials, Software Productivity Center, May 2000a,

http://www.spc.ca/essentials/may0300.htm
cazul intranet-ului sau extranet-ului) aceasta poate fi comparabila cu aplicatiile
traditionale. Când dezvoltam o aplicatie web pentru un grup anonim de utilizatori,
vor exista elemente eterogene evidente în ceea ce priveste abilitatile (sau
incapacitatile), cunoasterea (expertiza aplicatiei) si preferintele (interesele). Pentru a
permite o personalizare adecvata, presupunerile privind contextul utilizatorilor
trebuie facut în faza de dezvoltare a aplicatiilor web. Acest aspect va fi luat în
considerare atunci când adaptam componentele aplicatiei. Clientii obisnuiti pot avea
reduceri speciale (adaptarea contextului), noii clienti pot receptiona un ghid pentru
aplicatia web (adaptarea hipertextului) si utilizatorii cu deficiente vizuale pot fi
sprijiniti prin folosirea unor dimensiuni adecvate ale fontului (adaptarea prezentarii).
Personalizarea necesita deseori specificarea preferintelor utilizatorilor (de exemplu
metoda preferata de plata pe http://www.amazon.com ).
Contextul tehnic: Reteaua si dispozitivele
Contextul tehnic include proprietati legate de conexiunile în retea privitoare
la calitatea serviciului si componentele hardware si software ale dispozitivelor
utilizate pentru a accesa aplicatia web, pentru o distribuire multi-platforma.
Calitatea serviciului. Din punct de vedere tehnic, aplicatiile web sunt bazate
pe principiul client/server. Caracteristicile mediului de transmisie, cum ar fi latimea
de banda, siguranta si stabilitatea conexiunii sunt factori independenti care trebuie
luati în considerare când dezvoltam o aplicatie web pentru a garanta o calitate
adecvata a serviciului. De exemplu, parametrul latimea maxima de banda poate fi
ajustat pentru a optimiza cantitatea de date transferata, astfel încât continutul
multimedia (clipuri video) va fi transferat la o rezolutie scazuta în situatia unei latimi
de banda mici. În timp ce în aplicatiile traditionale specificatiile retelei sunt
cunoscute dinainte, dezvoltatorii aplicatiilor web trebuie sa faca supozitii privitor la
aceste proprietati. Datorita tendintei de orientare catre aplicatiile web mobile, acest
aspect este de o importanta sporita, asa cum retelele convergente necesita o mai
multa adaptare la nivelul aplicatiei.
Distribuirea multi-plaforma. Aplicatiile web ofera de obicei servicii nu doar
unui anumit tip de dispozitiv ci si dispozitivelor mobile cu specificatii diferite
(dimensiunea monitorului, capacitatea memoriei, software-ul instalat). Numarul
mare de versiuni ale browserului reprezinta o provocare datorita diferitelor
functionalitati si restrictii ale acestora (deseori acestea nu implementeaza
specificatiile presupuse). Acest lucru determina dificultati în crearea unei interfete
utilizator consistente si în testarea aplicatiilor web.
În plus, utilizatorii pot configura browserele în mod autonom. Prezentarea
(ascunderea imaginilor), drepturile de acces (applet-urile Java) si o serie de functii
(cookies, caching) pot fi toate configurate individual, acestea având influente asupra
performantei, functionalitatii tranzactiilor si posibilitatii de interactiune.
Pe baza presupunerilor privind clasele tipice de dispozitive, dezvoltatorii
aplicatiilor web pot adapta continutul la PDA-uri (personal digital assistants) prin
netransmiterea imaginilor sau clipurilor video si oferirea în schimb a legaturilor si
textului descriptiv. La nivel hipertext, putem oferi versiunea pentru listare a
documentelor hipertext. Pentru a lua în calcul diferitele versiuni de Javascript din
varietatea de browsere, pot fi utilizate librarii independente de platforma în procesul
de dezvoltare (vezi http://www.domapi.com ).

Contextul natural: locatia si durata

Contextul natural include aspecte privind locatia si durata de accesare.
Globalitatea si disponibilitatea creaza un nivel înalt de eterogenitate.
Globalitatea. Locatia din care o aplicatie web este accesata (pozitia
geografica) este importanta pentru internationalizarea aplicatiilor web relativ la
diferentele regionale, culturale si lingvistice. În plus, locatia fizica poate fi utilizata
împreuna cu modelele locatiei pentru a defini pozitia logica cum ar fi locul de
rezidenta sau locul de munca în scopul de a oferi servicii "constiente" de locatie.
"Constienta" locatiei determina dificultati suplimentare pentru testarea aplicatiilor
web, deseori fiind dificil sa simulam schimbarea locatiei si/sau testa toate locatiile
posibile. Disponibilitatea globala sporeste de asemenea cererile privind securizarea
aplicatiilor web pentru a preveni accesul deliberat sau accidental al utilizatorilor în
zone private sau confidentiale.
Disponibilitatea. "Mecanismul de distribuire instantanee" îsi are originea în
natura web-ului de a face aplicatiile imediat disponibile. Aplicatiile web devin
imediat utilizabile, ceea ce implica ca calitatea produsului dezvoltat sa fie sigur.
Disponibilitatea permanenta (24/7) sporeste de asemenea pretentiile privind
stabilitatea aplicatiilor web. În plus, serviciile dependente de timp sunt posibile prin
luarea în considerare a acestui aspect (timpul) (de exemplu informatiile privind
programul depind de ora din zi si ziua din saptamâna).
1.2.3 Caracteristici asociate dezvoltarii
Dezvoltarea aplicatiilor web este caracterizata de necesarul de resurse, cum
ar fi echipa de dezvoltare si infrastructura tehnica, procesul de dezvoltare în sine si
de integrarea necesarului de solutii deja existente.
Echipa de dezvoltare
Dezvoltarea aplicatiilor web este puternic influentata de faptul ca echipele de
dezvoltare sunt multi-disciplinare si în general formate din tineri. Acesti factori si
metode ale cumunitatii de dezvoltare contribuie la aparitia unui nou mod de
organizare a colaborarii între diferite grupuri de dezvoltatori.
Multi-disciplinaritatea. Aplicatiile web pot fi caracterizate ca o combinatie
între publicistica tiparita si dezvoltarea software, marketing si stiinta calculatoarelor,
arta si tehnologie. Dezvoltarea aplicatiilor web trebuie perceputa ca o abordare
multidisciplinara care solicita cunoastere si expertiza din diferite domenii. Pe lânga
expertii IT responsabili de implementarea tehnica a sistemului, expertii hipertext si
proiectantii trebuie sa fie angajati în proiectarea hipertextului si prezentarii, în timp
ce expertii în domeniu trebuie sa fie responsabili pentru continut.
Se observa o varietate mare a competentelor si cunoasterii în echipa de
dezvoltare fata de dezvoltarea software traditionala. Disciplina dominanta este
dependenta de tipul de aplicatie web. De exemplu, aplicatiile e-commerce sunt
bazate mai mult pe baze de date traditionale si expertiza de programare, în timp ce
dezvoltarea unei prezentari virtuale va pune mai mult accent pe expertiza în
domeniu si în proiectare.
Vârsta medie mica. Dezvoltatorii de aplicatii web sunt în medie mult mai
tineri si mai putin experimentati decât dezvoltatorii de software traditionali. De
obicei sunt apelati cu stereotipuri de tipul "ciudati în domeniul tehnologiei" carora
nu le pasa de vechile conventii si sunt foarte interesati în folosirea noilor utilitare si
tehnologii.
Comunitate de dezvoltare. Dezvoltarea de software open-source disponibila
gratuit pe web si integrarea acesteia în aplicatiile reale este un fenomen recent.
Dezvoltatorii utilizeaza acest software pentru crearea propriilor aplicatii, pe care le
fac disponibile comunitatii open source.
Infrastructura tehnica
Neomogenitatea si imaturitatea utilizarii componentelor sunt caracteristici
importante ale infrastructurii tehnice a aplicatiilor web.
Neomogenitatea. Dezvoltarea aplicatiilor web depinde de doua componente
externe: server si browser. În timp ce serverul web poate fi configurat si folosit asa
cum se doreste de programatorii de aplicatii, nu exista nici o cale de a influenta
browserele web ale utilizatorilor si preferintele lor individuale. Situatia se complica
în cazul diferitelor versiuni de browser si plugin-uri.
Imaturitate. Datorita cresterii presiunii de a ajunge pe piata, componentele
utilizate în aplicatiile web sunt deseori imature, au bug-uri sau lipsuri în privinta
functionalitatii.
Procese. Procesul de dezvoltare este cadrul de lucru pentru toate
caracteristicile de dezvoltare si este influentat de flexibilitate si paralelism.
- Flexibilitate. În dezvoltarea aplicatiilor web este imposibil sa aderam la un
plan de proiect rigid si predefinit. Este important sa fim flexibili la anumite conditii
de schimbare.
- Paralelism. Datorita necesitatii de a dezvolta aplicatiile web într-un timp
scurt si faptului ca ele pot fi deseori împartite în componente autonome (de
exemplu autentificare, functie de cautare, notificarea stirilor), majoritatea
aplicatiilor web sunt dezvoltate în paralel de diferite subgrupuri ale echipei de
dezvoltare. Spre deosebire de dezvoltarea software-ului traditional aceste
subgrupuri sunt structurate conform cu aceste componente si nu în concordanta cu
expertiza membrilor proiectului (de exemplu dezvoltatorii GUI, modelatorii de
date)22[22].
Pe lânga dezvoltarea în paralel a partilor aplicatiei, sarcinile metodice cum ar
fi proiectarea, implementarea si asigurarea calitatii sunt deseori folosite simultan
pentru versiuni diferite. De exemplu, asigurarea calitatii poate fi în curs de
desfasurare pentru o versiune anterioara, în timp ce implementarea începuta deja
pentru versiunea urmatoare si cele care vor urma au fost deja proiectate. Aceasta
rulare în paralel a fazelor determina noi cerinte pentru planificarea modului de
desfasurare a dezvoltarii în proiectele web.

Integrarea
Caracteristica speciala a aplicatiilor web este nevoia de integrarea interna si
externa. În acest context, integrarea se refera nu numai la aspectele tehnice, dar si la
continut si la aspectele organizationale.
Integrarea interna. Frecvent, aplicatiile web trebuie integrate cu sistemele de
mostenire existente când continutul existent (de ex. cataloagele de produse) va fi
facut disponibil aplicatiei web.
Integrarea externa. Integrarea continutului si a servicilor aplicatiilor web
externe reprezinta o caracteristica speciala a aplicatiilor web. Dintre particularitatile
integrarii pe web mentionam:
- existenta unui numar mare de surse care se schimba frecvent si cu un grad
înalt de autonomie;
- se cunosc putine detalii privitoare la proprietatile acestor surse, cum ar fi
continutul si functionalitatile;
- diferite surse sunt adesea foarte eterogene la diverse nivele (nivelul datelor,
schemei sau modelului de date).
Integrarea serviciilor externe în aplicatiile web orientate pe portaluri se
bazeaza pe cresterea formelor de dezvoltare comune a furnizarii si utilizarii
serviciilor web. În acest context, un serviciu web este o componenta reutilizabila cu
o interfata si functionalitate foarte clar definita. Interactiunea diferitelor servicii web
si garantarea calitatii serviciilor sunt câteva dintre problemele relevante ale acestui
context.
1.2.4 Evolutia
Evolutia este o caracteristica care guverneaza toate cele trei dimensiuni ale
produsului, utilizarii si dezvoltarii. Necesitatea evolutiei poate fi argumentata prin

22[22] McDonald, A., Welland, R., A Survey of Web Engineering in Practice, Department of Computing
Science

Technical Report R-2001-79, University of Glasgow, Scotland, 2001.

schimbarea continua a cerintelor si conditiilor, presiunea competitiva si dezvoltarea
rapida.

Schimbarea continua
Aplicatiile web se schimba rapid si sunt în consecinta într-o evolutie
permanenta datorita schimbarii constante a cerintelor sau conditiilor23[23].
Schimbarea rapida si permanenta a tehnologiilor web si a standardelor în particular,
necesita o adaptare continua a aplicatiilor web la acestea. Aceasta schimbare are
doua cauze:
- utilizatorii doresc ultimile aplicatii web;
- instrumentele utilizate sunt conditionate de tehnologie.
Schimbarile constante ale cerintelor si conditiilor reprezinta caracteristica
centrala a aplicatiilor web, acestea afectând toate cele trei dimensiuni ale aplicatiilor
web - produsul însusi, utilizarea acestuia si în particular dezvoltarea lui.
Presiunea competitiva

Presiunea competitiva ridicata de pe web, presiunea de pe piata si

necesitatea prezentei pe web, sporeste nevoia de a scurta ciclul de viata a
produsului si nu lasa loc pentru un proces de dezvoltare sistematica.
Dezvoltarea competitiva
Presiunea timpului în dezvoltarea aplicatiilor web se datoreaza schimbarilor
rapide de pe web si duratei scurte de viata a aplicatiilor web sau frecventei
actualizarilor.
În timp ce în aplicatiile software traditionale evolutia se manifesta sub forma
seriilor planificate de versiuni, în aplicatiile web aceasta este continua. Aplicatiile
web sunt într-o continua întretinere, ciclul schimbarii fiind deseori nu mai lung de
câteva zile sau saptamâni.
Principalele aspecte abordate în continuare sunt prezentate în Figura 3.
Principalele componente luate în discutie pot fi grupe pe trei piloni:
- abordare (metodologie);
- dezvoltarea produsului;
- aspecte privind calitatea.
Elementul de baza este partea introductiva prezentata anterior, web-ul
semantic fiind "acoperisul", perspectiva viitoare.

23[23] Scharl, A., Evolutionary Web Development - Automated Analysis, Adaptive Design, and Interactive
Visualization

of Commercial Web Information Systems, Springer-Verlag, 2000

Figura 3. Abordari ulterioare
Principalele provocari ale proiectarii cerintelor aplicatiilor web includ: spatii de
depozitare indisponibile, schimbarea dinamica a conditiilor, medii de actiune
impredictibile, importanta deosebita a calitatii si frecventa lipsa de experienta în
utilizarea tehnologiilor.
Modelarea se refera la dezvoltarea aplicatiilor web pe baza de modele, cu focalizare
asupra continutului si hipertextului, si implica o dezvoltare de sus în jos. Este
necesara o prezentare a metodelor existente pentru modelarea aplicatiilor web si a
unor instrumente de modelare care ajuta utilizatorul în alegerea metodei adecvate.
Arhitectura este un factor decisiv pentru stabilirea calitatii aplicatiilor web.
Performantele slabe, întretinerea neadecvata si diponibilitatea redusa se datoreaza
deseori unei arhitecturi necorespunzatoare. Folosind arhitecturi multi-straturi si
flexibile, oferirea unui continut multimedia si integrarea aplicatiilor si depozitelor de
date existente influenteaza pozitiv dezvoltarea cu succes a aplicatiilor web.
Proiectarea bazata pe tehnologie descrie alternativa dezvoltarii de jos în sus a
aplicatiilor web. Proiectarea hipertext/hipermedia, a informatiei si a software-ului
orientat obiect nu ofera o solutie satisfacatoare, fiind necesare abordari de
proiectare specifice web-ului, cum ar fi:
- proiectarea vizuala, în care aspectul este determinat si în care sunt abordate
modalitati multiple ale interfetei utilizator.
- proiectarea interactiva, în care sunt proiectate caile de navigare si interactiunea cu
componentele
- proiectarea functionala este esenta aplicatiei web si pe masura ce proiectarea pe
fiecare nivel devine mai concreta, trebuie utilizate mai multe instrumente pentru
hipertext, informatie si proiectarea software.
Tehnologiile au anumite caracteristici care trebuie cunoscute în detaliu pentru a
putea fi utilizate în etapa adecvata. Implementarea aplicatiilor web necesita o
cunoastere aprofundata nu doar a diferitelor tehnologii ci si a interactiunii acestora
cu o anumita arhitectura. Astfel, este necesara o prezentare a diferitelor tehnologii si
o exemplificare a interactiunii si utilizarii împreuna cu anumite arhitecturi.
Recomandarile consortiului web (W3C) necesita o atentie deosebita.
Testarea prin metodele existente se focalizeaza pe cerintele functionale ale
aplicatiilor web. În majoritatea cazurilor nu sunt luate în considerare aspectele de
calitate nonfunctionale importante pentru utilizatori cum ar fi: usurinta în folosire,
siguranta si securitatea.
Operarea si întretinerea sunt esentiale deoarece dezvoltarea aplicatiilor web implica
un proces evolutiv în permanenta dezvoltare. Exista de asemena o tendinta de a
automatiza sarcinile cât timp sistemul este operational. De exemplu, sarcini de
rutina pentru întretinerea continutului sunt în mare masura automatizate,
eliminându-se astfel sursele de erori si garantând o siguranta a operatiilor.
Managementul proiectelor este o activitate proiectata pentru a coordona actiunile
oamenilor, aceasta abordare necesitând competente deosebite din partea
managerilor de proiecte web în rezolvarea conflictelor si o cunoastere
interdisciplinara între echipele web. În consecinta, planul proiectului pentru
dezvoltarea unei aplicatii web trebuie sa fie flexibil si sa permita o dezvoltare
iterativa incrementala si o comunicare permanenta cu clientul.
Posibilitatea utilizarii proceselor de dezvoltare sofware traditionale pentru
dezvoltarea aplicatiilor web implica sase cerinte de baza folosite pentru evaluarea
procesului de dezvoltare a produselor software orientate obiect (Rational Unified
Process - RUP) si a programarii extreme (Extreme Programming - XP). Nici unul
dintre aceste procese nu îndeplineste toate cerintele. Avantajul RUP consta în
adaptarea cu usurinta la gradul de complexitate a aplicatiei în curs de dezvoltare. XP,
pe de alta parte, se poate adapta la timpuri reduse de dezvoltare si la modificari ale
cerintelor aparute pe parcurs.
Usurinta în folosire, perfomanta si securitatea reprezinta 3 dintre aspectele de
calitate ale aplicatiilor web. Usurinta în folosire subliniaza faptul ca aplicatiile web
greu de utilizat nu sunt acceptate de catre utilizatori. Noile dezvoltari, cum ar fi
aplicatiile web mobile si facilitatile speciale pentru utilizatori cu deficiente pun de
asemenea un accent deosebit pe usurinta în folosire, care nu poate fi dobândita
imediat ci pe întregul proces de dezvoltare.
Performanta implica folosirea unor metode, începând cu cele de modelare pentru
verificarea performantei si terminând cu cele de masurare. Dintre metodele de
modelare mentionam modelele operationale si modelele generale de simulare.
Masurarea necesita accesul la un sistem existent si avantajul ca sistemul poate fi
urmarit în timp real. În cazul aparitiei unor probleme de performanta identificate
 prin masurare sau modelare este necesara o îmbunatatire a performantei prin
extinderea hardware-ului, optimizarea software-ului, prin caching sau replicari.
Securitatea implica abordarea unor probleme privind confidentialitatea datelor,
prevenirea interceptarii mesajelor schimbate pe canalele accesibile publicului si
oferirea unor servicii de încredere.
Web-ul semantic reprezinta urmatorul pas logic în evolutia web-ului. Se identifica 3
abordari principale. În primul rând, paginile web trebuie extinse fie manual fie prin
intermediul unor instrumente care ofera etichete semantice cu ajutorul carora
paginile vor avea un continut interpretabil de sistemele de calcul. În al doilea rând
utilizatorii care cauta informatia ar trebui sa foloseasca agenti software inteligenti
capabili sa proceseze paginile web proiectate cu aceasta facilitate. În final,
producatorii de continut si agentii software trebuie sa adopte un vocabular comun al
conceptelor - o ontologie. Web-ul semantic este înca la începuturi, dar opinia
generala este ca acesta implica tehnologii promitatoare care vor influenta profund
mediul de lucru al lucratorilor în domeniul cunoasterii.
II. Proiectarea cerintelor aplicatiilor web
Proiectarea cerintelor acopera activitati care sunt critice pentru proiectarea web.
Cerinte incomplete, ambigue sau incorecte pot conduce la dificultati în dezvoltare
sau chiar cauza anularea proiectului. Proiectarea cerintelor presupune luarea în
discutie a principiilor, metodelor si utilitarelor pentru extragerea, descrierea,
validarea si managementul cerintelor.
Cerintele joaca un rol cheie în dezvoltarea aplicatiilor web, deseori fiind descrise în
mod neadecvat. Consecintele specificarii cerintelor într-o asemenea maniera sunt:
esecul planificarii si arhitecturi software neadecvate.
Exista un acord general privitor la importanta cerintelor pentru dezvoltarea cu
succes a sistemelor, de-a lungul anilor oferindu-se numeroase standarde, abordari,
modele, limbaje de descriere si utilitare.
În continuare vom discuta principiile proiectarii cerintelor pentru dezvoltarea
aplicatiilor web si vom studia modul în care metodele de proiectare a cerintelor pot
fi adaptate la particularitatile proiectelor web.
2.1 Elemente fundamentale
2.1.1 Provenienta cerintelor
Obiectivele individuale si asteptarile împuternicitilor sunt punctul de pornire ale
procesului de descoperire a cerintelor sistemului. Împuternicitii sunt indivizii sau
organizatiile care au o influenta directa sau indirecta asupra cerintelor în dezvoltarea
sistemului24[24]. Principalii împuterniciti sunt clientii, utilizatorii si dezvoltatorii.

24[24] Kotonya, G., Sommerville, I., Requirements Engineering: Processes and Techniques,
John Wiley & Sons,

1998
Împuternicitii reprezentativi pentru aplicatiile web includ autorii de continut, expertii
în domeniu, experti în caracterul utilizabil sau profesionistii în domeniul marketing-
ului. Obiectivele si asteptarile împuternicitilor sunt de obicei diverse, asa cum o
demonstreaza urmatoarele exemple:
- aplicatia web trebuie sa fie disponibila online pâna la 1 septembrie 2007
(constrângerea clientului);
- aplicatia web trebuie sa suporte minim 2500 utilizatori concurenti (obiectiv de
calitate a clientului);
- PHP trebuie folosit ca platforma de dezvoltare (perspectiva tehnologica a
dezvoltatorilor);
- toate datele clientilor trebuie trimise securizat (obiectiv de calitate al utilizatorului);
- interfata utilizator trebuie sa suporte layout-uri pentru grupuri diferite de clienti
(obiectiv de calitate al clientului);
- orice utilizator trebuie sa poata cauta produsul dorit în mai putin de trei minute
(obiectiv privind caracterul utilizabil pentru client);
- utilizatorul trebuie sa aiba posibilitatea sa selecteze o iconita care sa afiseze
articolele incluse în card-ul de cumparaturi în orice moment (obiectiv privind
capacitatea utilizatorului).
Identificarea si implicarea cu succes a împuternicitilor este sarcina principala a
managementului proiectelor. O mare provocare o constituie întelegerea si aplanarea
frecventelor conflicte privind obiectivele, asteptarile si ordinea de zi. De exemplu,
pot exista conflicte între setul dorit de functionalitati si bugetul disponibil; între setul
de functionalitati, planul proiectului si calitatea dorita; sau între tehnologia de
dezvoltare dorita si aptitudinile si experientele dezvoltatorilor. Întelegerea si
rezolvarea din timp a acestor contradictii si conflicte este hotarâtoare si este
importanta pentru managementul riscului. Exista o serie de tehnici de negociere
pentru a suporta aceasta sarcina. În acest proces, dezvoltarea unei viziuni
împartasite între împuterniciti este o conditie pentru succes.
Obiectivele împuternicitilor sunt deseori prezentate neoficial si ofera baza pentru
cerinte derivate mult mai detaliate.
O cerinta descrie proprietatea de a fi cunoscuta sau a unui serviciu de a fi furnizat de
catre un sistem. IEEE 610.12 defineste o cerinta ca:
- o conditie sau aptitudine necesara unui utilizator pentru a rezolva o problema sau a
duce la bun sfârsit un obiectiv;
- o conditie sau aptitudine care trebuie îndeplinita sau posedata de un sistem sau
componenta sistem pentru a satisface un contract, standard, specificatie sau alte
documente solicitate formal;
- o reprezentare documentata a unei conditii sau aptitudini.
 Cerintele sunt clasificate deseori în cerinte functionale, cerinte non-functionale si
constrângeri25[25]. Cerintele functionale definesc capacitatea sistemelor si
serviciilor, în timp ce cerintele non-functionale descriu nivelul de calitate dorit ("Cât
este de securizat?", "Cât este de usor de folosit?"). Constrângerile sunt conditii non-
negociabile care afecteaza proiectul. Exemple de constrângeri sunt nivelul de
pricepere a echipei de dezvoltare, bugetul disponibil, data livrarii sau infrastructura
de calculatoare existenta în echipa de dezvoltare.
Un document cu solicitarile rezuma toate cerintele si constrângerile dintre
contractor si client. Abordarile uzitate în proiectarea cerintelor pun accentul pe
identificarea si implicarea împuternicitilor, negocierea si descoperirea cerintelor pe
baza de scenarii, analiza contextului organizational si social anterior modelarii
detaliate si o definire clara a constrângerilor care afecteaza dezvoltarea26[26].
2.1.2 Activitatile proiectarii cerintelor
Proiectarea cerintelor implica extragerea, documentarea, verificarea si validarea, dar
si managementul cerintelor de pe parcursul procesului de dezvoltare.
Extragerea cerintelor si negocierea
Lowe si Eklund27[27] au demonstrat ca cerintele nu pot fi colectate prin întrebari
adecvate ci sunt rezultatul procesului de învatare si construirii pe baza de consens. În
acest proces, comunicarea dintre împuterniciti este esentiala. Un set larg de metode
si utilitare colaborative sunt disponibile pentru a facilita comunicarea si schimbul
cunoasterii în proiectarea cerintelor. Astfel de exemple sunt tehnici de creativitate,
metode bazate pe scenarii, procese pentru decizii multicriteriu, interviuri sau analiza
documentelor.
Documentarea cerintelor
Daca împuternicitii ajung la un consens, acordul dintre acestia trebuie rafinat si
descris într-un document al cerintelor în functie de gradul detaliilor si formalismelor
adecvate contextului proiectului. Alegerea gradului adecvat de detalii si a
formalismelor depinde de riscurile identificate ale proiectului, de experienta si
aptitudinile presupusilor cititori.

25[25] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley,
1999

26[26] Boehm, B. W., Requirements that Handle IKIWISI, COTS, and Rapid Change, IEEE
Computer, 33 (7),

July, 2000, pp. 99-102

27[27] Lowe, D. B., Eklund, J., Client Needs and the Design Process in Web Projects, Journal
of Web Engineering,

1 (1), October, 2002, pp. 23-36

 Verificarea cerintelor si validarea
Cerintele trebuie validate ("S-au specificat cerintele corecte?") si verificate ("S-au
specificat corect cerintele?). Exista o serie de metode conventionale în acest scop,
cum ar fi revizuirile, verificarile sau prototipizarea. În proiectarea web, deschiderea
pe care o ofera Internetul faciliteaza noi forme de participare directa a utilizatorilor
în validarea cerintelor, cum ar fi colectiile online ale feedback-urilor
utilizatorilor28[28].
Managementul cerintelor
Cerintele sunt supuse schimbarilor frecvente. Principalele caracteristici ale siturilor
web sunt schimbarile permanente ale cerintelor si constrângerile. Metodele si
instrumentele folosite pentru managementul cerintelor suporta atât integrarea
noilor cerinte cât si modificarea celor existente. Datorita dificultatilor care apar în
managementul cerintelor pentru sistemele complexe, este necesara utilizarea
anumitor instrumente pentru a sprijini aceasta sarcina.
2.2 Cerinte specifice proiectarii web
La suprafata diferentele dintre proiectarea cerintelor pentru web si proiectarea
cerintelor pentru sistemele software traditionale par a fi neglijabile. Desi exista
multe diferente între dezvoltarea web si dezvoltarea software, exista si multe
similaritati (de exemplu extragerea cerintelor). În cele ce urmeaza vom insista pe
diferentele dintre acestea, pe baza caracteristicilor aplicatiilor web prezentate în
capitolul anterior.
Multidisciplinaritatea
Dezvoltarea aplicatiilor web necesita participarea expertilor din diferite discipline:
experti multimedia, autorii de continut, arhitecti software, experti în usurinta de
folosire, specialisti în baze de date sau experti într-un anumit domeniu.
Eterogenitatea si multidisciplinaritatea împuternicitilor devine un subiect interesant
în realizarea acordului privind definirea cerintelor.
Indisponibilitatea împuternicitilor
Majoritatea împuternicitilor, cum ar fi potentialii utilizatori web, sunt necunoscuti pe
parcursul activitatilor de proiectare a cerintelor. Managementul proiectelor trebuie
sa gaseasca caracteristici adecvate care sa ofere la rândul lor cerinte cât mai realiste.
De exemplu, deseori exista un spectru larg de posibili utilizatori în proiectele web si
gasirea unor caracteristici adecvate este dificila.

Caracterul schimbator al cerintelor si constrângerilor

28[28] Deshpande, Y., Murugesan, S., Ginige, A., Hansen, S., Schwabe, D., Gaedke, M.,
White, B., Web Engineering,

Journal of Web Engineering, 1 (1), 2002, pp. 3-17

Cerintele si constrângerile (ex. proprietatile platformelor de lucru sau protocoale de
comunicatie) sunt adesea mai usor de definit pentru sistemele software traditionale
comparativ cu aplicatiile web.
Aplicatiile web si mediul în care acestea functioneaza sunt extrem de dinamice, din
acest motiv cerintele si constrângerile fiind greu de stabilit. Cele mai frecvente
exemple de astfel de schimbari sunt inovatiile tehnologice cum ar fi introducerea
noilor platforme si standarde de dezvoltare sau noile dispozitive pentru utilizatorii
finali.

Mediul operational imprevizibil

Mediul operational al aplicatiilor web este de asemenea foarte dinamic si greu de
anticipat. Pentru dezvoltatori este dificil sau chiar imposibil sa controleze factori
importanti, decisivi pentru calitatea aplicatiei web perceputa de utilizator. De
exemplu, modificarea latimii de banda afecteaza timpul de raspuns pentru aplicatiile
mobile dar acest lucru nu depinde de echipa de dezvoltare.
Impactul sistemelor de mostenire
Dezvoltarea aplicatiilor web este caracterizata prin integrarea componentelor
software existente cum ar fi produsele comerciale autonome sau software-ul open
source. În particular, dezvoltatorii web se confrunta frecvent cu integrarea
sistemelor de mostenire, de exemplu atunci când vor sa faca un sistem IT existent al
unei companii accesibil pe web. Dezvoltatorii au posibilitatea sa utilizeze
componentele existente si din motive economice. Componentele care trebuie
integrate influenteaza cerintele si arhitectura viitorului sistem. În aceste situatii o
abordare în cascada care sa mosteneasca arhitectura sistemului din cerinte nu va
avea succes, deoarece componentele, serviciile si infrastructura existenta stabilesc o
serie de posibilitati si limitari pentru dezvoltatori. Prin aceasta întelegem ca atunci
când se identifica si definesc cerintele, dezvoltatorii web trebuie sa fie constienti de
arhitectura sistemului si de constrângerile arhitecturale. O abordare iterativa este
propusa de modelul Twin Peaks si este adecvata într-un asemenea context (vezi
figura).
 Figura: Modelul Twin-Peaks29[29]
Importanta aspectelor calitative
Aspectele calitative sunt decisive pentru succesul aplicatiilor web. Exemple:
performanta unei aplicatii web, securitatea în sistemele de e-commerce,
disponibilitatea sau usurinta în folosire. În ciuda importantei aspectelor calitative,
dezvoltatorii trebuie sa se confrunte cu faptul ca o specificare exacta a cerintelor de
calitate este dificil de stabilit înaintea construirii sistemului. De exemplu timpul de
raspuns al unei aplicatii web depinde de multi factori, care nu pot fi controlati de
echipa de dezvoltare. O abordare realizabila pentru definirea cerintelor de calitate
implica specificarea criteriilor pentru testul de acceptare, specificând daca o cerinta
a fost îndeplinita sau nu. (vezi de asemenea un exemplu al unui criteriu de acceptare
pentru o cerinta a calitatii în tabelul 2-1).
Atribut Comentariu Exemplu
ID Identificator unic 1.2.5
Tip Element din taxonomia Usurinta în învatare
cerintei
Descriere O explicatie scurta în Aplicatia web X trebuie sa
limbaj natural fie utilizabila de un
utilizator web ocazional,
fara a fi necesara o
instruire prealabila
Rationamentul Explica de ce este Managerii de marketing
importanta cerinta sunt utilizatori frecventi ai
sistemului
Criteriul de O conditie masurabila 90% din membrii unui
acceptare care trebuie îndeplinita grup-test (selectat aleator)
pentru acceptare de utilizatori web
ocazionali pot utiliza
Cazurile de Utilizare 2.3,
2.6 si 2.9 fara o instruire
preliminara
Prioritatea Este expresia Foarte important; greu de
importantei si implementat
fezabilitatii cerintei
Cerinte Lista cerintelor care 2.3.4, 2.3.6
dependente depind de aceasta
cerinta

29[29] Nuseibeh, B., Weaving Together Requirements and Architectures, IEEE Computer, 34 (3), March, 2001,

pp. 115-117
 Atribut Comentariu Exemplu
Cerinte care Lista cerintelor care 4.5.6
intra în sunt în conflict cu
conflict aceste cerinte
particulare
Informatii Trimiteri la informatii Recomandari privind
aditionale aditionale usurinta în folosire v1.2
Istoricul Numarul reviziei 1.06
versiunii documentului din
istoricul dezvoltarii
Tabel: Specificatii de formatare
Calitatea interfetei utilizator
Calitatea interfetei utilizator este un alt aspect hotarâtor pentru succesul aplicatiilor
web. Când realizeaza aplicatii web dezvoltatorii trebuie sa fie constienti de
urmatorul fenomen: utilizatorii nu vor fi capabili sa înteleaga si sa aprecieze o
aplicatie web uitându-se la modele si specificatii abstracte; ei trebuie sa
experimenteze. De aceea, este esential sa completam definitia si descrierea
cerintelor prin adaugarea unor prototipuri pentru scenariile importante ale
aplicatiei30[30].
Calitatea continutului
Majoritatea metodelor de proiectare a cerintelor traditionale neglijeaza continutul
web desi este un aspect important al aplicatiilor web. Pe lânga problemele generate
de tehnologia software dezvoltatorii trebuie sa aiba în vedere continutul si în special
crearea si întretinerea acestuia. În contextul proiectarii cerintelor este esential sa
specificam nivelul de calitate cerut. Cele mai importante caracteristici de calitate
includ acuratetea, obiectivitatea, credibilitatea, relevanta, actualitatea, caracterul
complet sau claritatea. Sistemele de management al continutului (CMS) au devenit
importante si permit reprezentarea concisa si consistenta a continutului prin
separarea continutului de layout si oferirea utilitarelor de editare a continutului.
Lipsa de experienta a dezvoltatorilor
Majoritatea tehnologiilor de baza din aplicatiile web sunt relativ noi. Lipsa de
experienta cu instrumentele de dezvoltare care folosesc aceste tehnologii,
standardele si limbajele pot conduce la estimari gresite când se ia în discutie
fezabilitatea sî costul implementarii cerintelor.

Date fixe de livrare

30[30] Constantine, L., Lockwood, L., Software for Use: A Practical Guide to Models and Methods for Usage-

Centered Design, ACM Press, 2001

 Multe proiecte web au o data fixa de livrare, toate activitatile si deciziile trebuind sa
fie finalizate pâna la un termen limita. Negocierea si stabilirea unei ordini de
prioritate a cerintelor este esentiala în aceste conditii.
2.3 Principii pentru proiectarea cerintelor aplicatiilor web
În aceasta sectiune vom descrie principiile de baza ale proiectarii cerintelor
aplicatiilor web. Aceste principii deriva din stabilitatea modelului în spirala în care
câstiga toti partenerii (modelul win-win), un model al ciclului de viata iterativ si
orientat pe risc care pune accentul pe implicarea împuternicitilor si pe extragerea si
rezolvarea cerintelor. Modelul în spirala win-win a influentat multe modele bazate
pe procese, inclusiv Procesul Unificat Rational (RUP) de la IBM. Dezvoltatorii web
trebuie sa aiba în vedere urmatoarele principii pe parcursul activitatilor de
proiectare a cerintelor:
Întelegerea contextului sistemului
Multe aplicatii web sunt înca dezvoltate ca solutii tehnice izolate, fara o întelegere a
rolului si impactului acestora într-un context general. O aplicatie web nu poate fi o
finalitate prin ea însasi; ea trebuie sa tina cont de obiectivele afacerii clientului.
Pentru ca aplicatia web sa aiba succes este important sa clarificam contextul
sistemului(de exemplu prin analizarea si descrierea proceselor de afaceri existente)
si motivul pentru care sistemul va fi dezvoltat. ("Pentru ce facem acest lucru?").
Dezvoltatorii trebuie sa înteleaga modul în care sistemul este implementat în mediul
sau. Analiza afacerii poate stabili valoarea unei aplicatii web în relatie cu resursele
pe care le utilizeaza cerintele. Întelegerea contextului sistemului ajuta la
identificarea împuternicitilor, familiarizarea cu scopul aplicatiei si analizarea
constrângerilor31[31].
Implicarea împuternicitilor
Împuternicitii sau reprezentantii lor reprezinta inima proiectarii cerintelor, iar
cooperarea acestora activa si directa pentru identificarea si negocierea cerintelor
este importanta pentru fiecare faza a proiectului. Managerii de proiect trebuie sa
evite situatiile în care participantii individuali la proiect câstiga pe seama altora. S-a
demonstrat ca asemenea situatii câstig-pierdere conduc adesea la situatii pierdere-
pierdere, determinând în final esecul întregului proiect.
Obiectivele, asteptarile si cerintele împuternicitilor trebuie stabilite si negociate în
mod repetat pentru a se adapta schimbarilor dinamice care apar în proiecte.
Anterior am aratat ca multidisciplinaritatea si indisponibilitatea împuternicitilor sunt
specifice proiectarii cerintelor pentru web. Aceste caracteristici conduc la stabilirea
urmatoarelor cerinte pentru contextul aplicatiilor web:
- identificarea împuternicitilor sau reprezentantilor acestora

31[31] Biffl, S., Aurum, A., Boehm, B. W., Erdogmus, H., Gr¨unbacher, P., Value-based Software Engineering,

Springer-Verlag, September 2005

- întelegerea obiectivelor si asteptarilor împuternicitilor
- negocierea asteptarilor, experientelor si cunostintelor (multidisciplinaritate).
Metodele si utilitarele de proiectare a cerintelor trebuie sa fie în concordanta cu
aceste cerinte sî trebuie sa contribuie la schimbul efectiv de cunostinte dintre
participantii la proiect, sa permita un proces de instruire în echipa, dezvoltarea unei
viziuni comune printre împuterniciti si sa ajute la detectarea din timp a conflictelor.

Definirea iterativa a cerintelor

Abordarea în cascada a cerintelor nu functioneaza într-un mediu dinamic, iar
cerintele trebuie dobândite în mod iterativ în dezvoltarea aplicatiilor web. Cerintele
trebuie sa fie în concordanta cu alte rezultate ale dezvoltarii (arhitectura, interfata
utilizator, continut, testari etc.). La initierea proiectului, cerintele cheie sunt de
obicei definite la un nivel înalt de abstractizare. Aceste cerinte preliminare pot fi
utilizate pentru a dezvolta arhitecturi fezabile, scenarii de utilizare a sistemului si
planurile initiale ale proiectului. Pe masura ce proiectul progreseaza rezultatul
dezvoltarii poate fi rafinat în mod gradat prin specificarea unor termeni mai concreti,
asigurând în continuare consistenta lor. O abordare iterativa este necesara în special
într-un mediu în care cerintele si constrângerile sunt schimbatoare, pentru a putea
reactiona într-un mod flexibil pe masura ce proiectul evolueaza. Daca termenul
limita fixat este trimis echipei de dezvoltare, atunci o abordare de dezvoltare
iterativa permite selectarea cerintelor cheie care trebuie implementate primele.
Focalizarea pe arhitectura sistemului
Tehnologiile existente si solutiile de mostenire au un impact sporit asupra cerintelor
aplicatiilor web. Întelegerea solutiilor tehnice împreuna cu posibilitatile si limitarile
lor sunt esentiale. Extragerea cerintelor nu poate avea loc separat de arhitectura si
trebuie luata în discutie când definim cerintele. Luarea în considerare a arhitecturii
sistemului permite dezvoltatorilor sa înteleaga mai bine impactul solutiilor existente
asupra cerintelor si sa estimeze fezabilitatea acestora. Modelul Twin-Peaks (vezi
figura) propune perfectionarea cerintelor si arhitecturii sistemului în maniera
iterativa prin sporirea continua a nivelului de detaliere.

Riscuri
Problemele nedetectate, cele nerezolvate si conflictele dintre cerinte reprezinta
riscuri majore ale proiectelor. Problemele obisnuite de risc sunt integrarea
componentelor existente în aplicatia web, anticiparea aspectelor de calitate a
sistemului sau lipsa de experienta a dezvoltatorilor. De aceea evaluarea riscului
trebuie adaptata pentru toate cerintele. Odata identificate, riscurile trebuie
administrate pe parcursul proiectului, pentru a ne asigura ca nu sunt urmate
alternative riscante pentru sistem. Diminuarea riscului trebuie realizata cât mai
rapid. Aceasta poate include de exemplu prototipizarea, lansarea rapida a aplicatiei
 web pentru a colecta feedback-ul utilizatorilor sau încorporarea precoce a
componenetelor externe pentru a elimina problemele majore ale integrarii tardive.
2.4 Adaptarea metodelor de proiectare a cerintelor dezvoltarii aplicatiilor web
În prezent sunt disponibile numeroase metode, ghiduri, notatii, cataloage si utilitare
pentru toate activitatile de proiectare a cerintelor. Dezvoltatorii trebuie sa evite o
abordare unitara, metodele de proiectare a cerintelor trebuind adaptate permanent
specificului proiectarii web si situatiilor care apar în anumite proiecte. Principiile
descrise anterior ne conduc la definirea unei abordari de proiectare a cerintelor
specifice proiectelor. Dezvoltatorii trebuie sa clarifice urmatoarele aspecte pe
parcursul procesului de adaptare:
- Ce tipuri de cerinte sunt importante pentru aplicatiile web?
- Cum vor fi descrise si documentate cerintele pentru aplicatiile web?
- Care sunt gradele utile ale detalierii?
- Trebuie avuta în vedere folosirea utilitarelor si care dintre acestea sunt potrivite
pentru nevoile specifice ale proiectului?

2.4.1 Tipuri de cerinte

Organizatiile de standardizare si organizatiile comerciale au dezvoltat un
numar mare de taxonomii pentru definirea si clasificarea diferitelor tipuri de cerinte
(de exemplu Volere32[32] sau IEEE 830-1998). Majoritatea taxonomiilor fac
distinctie între cerintele functionale si cele non-functionale. Cerintele functionale
descriu capacitatile sistemelor si serviciilor (de exemplu utilizatorul poate selecta o
iconita pentru a vizualiza articolele din cosul de cumparaturi în orice moment).
Cerintele non-functionale descriu proprietatile capacitatilor si nivelul dori al
serviciilor (de exemplu aplicatia web ar trebui sa suporte cel putin 2500 de utilizatori
concurenti). Alte cerinte non-functionale se refera la constrângerile proiectului si
interfata sistem.
În continuare vom discuta de scurt tipurile de cerinte de o relevanta
deosebita pentru dezvoltarea proiectelor web:
Cerintele functionale
Cerintele functionale specifica capacitatile si serviciile pe care un sistem ar
trebui sa le ofere (de exemplu transferul de bani într-o aplicatie de online banking).
Cerintele functionale sunt frecvent descrise utilizând scenariile de tip utilizare de caz
(use case) si specificatiile de formatare33[33].
Cerinte privind continutul
Cerintele privind continutul specifica continutul care trebuie sa-l prezinte
aplicatia web. Continutul poate fi descris, de exemplu, sub forma unui glosar.

32[32] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999

33[33] Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2001

 Cerinte privind calitatea
Cerintele privind calitatea descriu nivelul calitatii serviciilor si specifica proprietati
importante ale sistemului cum ar fi securitatea, performanta sau usurinta în
folosire34[34]. Standardul international ISO/IEC 9126 defineste un model
independent de tehnologie pentru calitatea softului care cuprinde 6 caracteristici de
calitate, fiecare fiind împartit într-un set de subcaracteristici.
Cele sase caracteristici sunt:
. Functionalitatea - descrie prezenta functiilor care îndeplinesc proprietatile definite.
Subcaracteristicile sunt oportunitatea, corectitudinea, interoperabilitatea,
conformitatea si securitatea.
. Siguranta - descrie capacitatea unui produs software de a-si mentine nivelul de
performanta în anumite conditii pe o perioada definita de timp. Subcaracteristicile
sunt maturitatea, toleranta la erori si posibilitatea de recuperare.
. Usurinta în folosire - descrie efortul necesar pentru a utiliza un produs software sî
evaluarea sa individuala de catre un grup de utilizatori definit sau presupus.
Subcaracteristicile sunt usurinta în întelegere, în învatare si operare.
. Eficienta - descrie raportul între nivelul de performanta al produsului software si
resursele pe care acesta le utilizeaza în anumite conditii. Subcaracteristicile includ
comportamentul în timp si comportamentul resurselor.
. Întretinerea - descrie efortul necesar pentru a implementa modificari prestabilite
într-un produs software. Subcaracteristicile includ posibilitatea de analiza,
schimbare, stabilitate si testare.
. Portabilitatea - descrie capacitatea unui produs software de a fi mutat dintr-un
mediu în altul. Subcaracteristicile includ capacitatea de adaptare, instalare, potrivire
si înlocuire. Au fost facute diverse încercari de catre cercetatori pentru a extinde
acest model de baza la caracteristicile specifice web-ului. În capitolele ulterioare
vom insista asupra usurintei în folosire, performantei si securitatii, care reprezinta
aspecte de calitate critice în general si pentru aplicatiile web în particular.
Cerintele mediului sistem
Aceste cerinte descriu modul în care o aplicatiile web este inclusa în cadrul tinta si
cum aceasta interactioneaza cu componentele externe, incluzând de exemplu
sistemele de mostenire, componentele comerciale autonome sau hardware-ul
special. De exemplu, daca o aplicatie web se presupune ca este disponibila global,
atunci cerintele de mediu trebuie sa specifice detaliile.

Cerintele interfetei utilizator

34[34] Chung, L., Nixon, B. A., Yu, E., Mylopoulos, J., Non-Functional Requirements in Software Engineering,

Kluwer Academic Publishers, 2000

 Deoarece se presupune ca utilizatorii web folosesc aplicatia web fara o instruire
formala, ghidarea intuitiva si autoexplicativa a utilizatorilor este esentiala pentru
acceptarea aplicatiei. Cerintele privitoare la interfata utilizator definesc modul în
care o aplicatie web interactioneaza cu tipuri diferite de clase de utilizatori.
Principalele aspecte sunt hipertextul (structura de navigare) si prezentarea (interfata
utilizator). Detaliile de navigare si prezentare sunt definite în mod normal în procesul
de modelare, dar deciziile initiale privind proiectarea interfetei utilizator trebuie
luate pe parcursul extragerii cerintelor. Prototipurile sunt cele mai potrivite în
aceasta situatie. Constantine si Lockwood sugereaza ca utilizatorii trebuie sa
coopereze în proiectarea scenariilor pentru anumite sarcini specifice. Proiectarea
centrata pe utilizare se bazeaza pe crearea si rafinarea iterativa de modele pentru
roluri, sarcini si interactiuni35[35].

Cerintele privind evolutia

Produsele software în general si aplicatiile web în particular sunt subiectul unei
evolutii si îmbunatatiri continue. Din acest motiv dezvoltatorii web trebuie sa
anticipeze cerintele care ar putea apare dupa folosirea planificata pe termen scurt a
aplicatiei. De exemplu, o cerinta de calitate prin care se cere suplimentarea cu 5000
de utilizatori concurenti în urmatorii doi ani trebuie avuta în vedere atunci prin
definirea unei arhitecturi a sistemului scalabile. Cerintele privind evolutia sunt
posibile pentru toate tipurile de cerinte discutate (de exemplu capacitatile viitoare,
cerintele de securitate viitoare).
Constrângerile proiectului
Constrângerile proiectului nu sunt negociabile pentru împuternicitii proiectului si
includ de obicei bugetul si planul, limitarile tehnice, standardele, tehnologia de
dezvoltare folosita, regulile de desfasurare, aspectele de întretinere, constrângerile
operationale si aspectele legale sau culturale care afecteaza proiectul.

2.4.2 Notatii
Sunt disponibile diferite notatii pentru specificarea cerintelor la nivele diferite de
detaliere si formalitate. Exemple: relatari, specificatii de formatare, specificatii
formale.
Riscurile identificate ale proiectului ofera repere în alegerea nivelului potrivit al
specificatiilor de calitate (de exemplu stabilirea gradului de specificare a cerintelor
dintr-un anumit proiect). În general abordarile informale si semiformale sunt
adecvate pentru aplicatiile web, iar tabelul urmator (vezi tabelul) prezinta notatii
diferite pentru cerinte.

35[35] Constantine, L., Lockwood, L., Software for Use: A Practical Guide to Models and Methods for Usage-

Centered Design, ACM Press, 2001

 Exactit Usur Efo Folos Scalabili
atea inta rtul irea tatea
valid de
arii catre
non-
expe
rti
Relata ** **** **
ri **
Cerint * ** **** ***
e *
specifi
cate
Specifi ** *** ** *** ***
catii
de
forma
tare
Specifi **** ****
catii
formal
e
Tabel: Compararea concordantei diferitelor notatii
Relatarile
Relatarile - sunt descrieri colocviale ale proprietatilor dorite; ele sunt utilizate pentru
a stabili termenii comuni dintre clienti si dezvoltatori. Exemple: relatarile
utilizatorilor din Extreme Programming36[36]. Relatarea unui utilizator este
formulata de catre un client folosind terminologie si limbaj propriu si descrie
problemele pe care sistemul ar trebui sa le rezolve pentru acel client.
Un exemplu de scenariu din perspectiva clientului poate fi urmatorul: Un utilizator
ale un produs si îl adauga în cosul de cumparaturi online. Datele de intrare sunt
validate atunci când utilizatorul opteaza pentru <Continuare>. Daca nu sunt gasite
erori comanda va fi acceptata si va fi trimisa utilizatorului o confirmare prin email.

Cerintele specificate
Cerintele specificate sunt simple specificatii în limbajul natural. Fiecare cerinta are
un identificator unic. Un bun exemplu este descrierea unui element de tip data
specificat în IEEE/EIA-J-STD- 016.

36[36] Beck, K., Extreme Programming Explained, Addison-Wesley, 2000

Specificatiile de formatare
Specificatiile de formatare utilizeaza o sintaxa bine definita dar permit si descrieri în
limbajul natural. Exemple: descrierile de tip use case din UML (Unified Modeling
Language), RDD-100 Requirements Specification Language, ghidurile MBASE SSRD
sau Volere Shell.
Tabelul în care am prezentat specificatiile de formatare prezinta un exemplu de
specificatie de formatare. Principalele atribute sunt: descriere, prioritate,
rationament sî istoricul versiunii. Fiecare cerinta este identificata individual si poate
fi referita pe parcursul procesului în orice moment utilizând un ID unic.
Interdependentele cu alte cerinte si rezultate ale dezvoltarii (cum ar fi documentele
sau planurile arhitecturii) sunt retinute pentru a sustine identificarea.
Cazurile de utilizare UML sunt utile pentru a descrie cerintele fuctionale. Un caz de
utilizare descrie o functie a sistemului din pespectiva actorilor acestuia si conduce la
un rezultat care poate fi perceput de catre actori. Un actor este o entitate externa
sistemului care interactioneaza cu sistemul. O diagrama de utilizare de caz
reprezinta relatia între cazurile de utilizare a sistemului si actori. Diagramele de
utilizare de caz sunt utile pentru a reprezenta dependentele de nivel înalt dintre
cazurile de utilizare si actori; detaliile cazului de utilizare sunt definite prin
specificatii de formatare. Atributele descriu numarul si numele cazului de utilizare,
actorii implicati, conditiile anterioare si posterioare si progresul, exceptiile si erorile,
variatiile, sursa, rationamentul, si interdependentele cu alte diagrame UML.
Specificatiile formale
Specificatiile formale sunt scrise într-un limbaj care utilizeaza o sintaxa si semantici
definite formal. Cel mai bun exemplu este "Z" (ISO/IEC13,568:2002). Specificatiile
formale sunt greu de utilizat pentru aplicatiile web.
Oportunitatea
Tabelul anterior compara diferite notatii în ceea ce priveste exactitatea atributelor,
usurinta validarii, raportul eficacitate-cost, folosirea de catre non-experti si
scalabilitatea. O exactitate de la scazut la mediu va fi suficienta pentru specificarea
cerintelor aplicatiilor web si o validare formala nu este necesara. Este important sa
pastram scazut efortul de extragere si management a cerintelor, iar aceste cerinte sa
fie întelese si de catre non-experti.
Scalabilitatea este o problema pusa pe seama complexitatii ridicate a aplicatiilor
web. În tabelul anterior putem observa ca descrierile informale si semi-formale
(relatarile, listele de cerinte si specificatiile de formatare) sunt adecvate pentru
aplicatiile web.
2.4.3 Utilitare
Exista numeroase categorii de utilitare care folosesc activitatile de proiectare a
cerintelor descrise. Utilitare de proiectare a cerintelor existente nu sunt limitate la
aplicatiile web si pot fi adaptate la tipicul dezvoltarii aplicatiilor.
Extragerea cerintelor
Metodele si utilitarele de negociere au fost dezvoltate si explorate în multe
discipline. EasyWinWin este o abordare bazata pe groupware care îndruma o echipa
de împuterniciti pentru achizitionarea si negocierea cerintelor. EasyWinWin
defineste un set de activitati pentru procesul de negociere, un moderator
îndrumând împuternicitul pe parcursul întregului proces. Aceasta abordare utilizeaza
tehnici de încurajare a grupurilor de lucru care sunt suportate de utilitarele
colaborative (brainstorming electronic, clasificari, sisteme de votare, etc.). Aceste
activitati sunt: revizuirea si extinderea subiectelor de negociere, interesele
împuternicitilor; convergenta spre conditiile de câstig, extragerea unui vocabular de
termeni comuni, stabilirea nivelului de prioritate pentru conditiile de câstig,
evidentierea problemelor si constrângerilor, identificarea problemelor si optiunilor si
negocierea acordurilor.
Validarea cerintelor
Datorita caracterului deschis al Internetului sistemele de raspuns online (feedback)
pot suplimenta sau chiar înlocui metode costisitoare cum ar fi întâlnirile cu
personalul sau interviurile, când se valideaza cerintele aplicatiei web. De exemplu
utilizatorii Internetului pot fi invitati sa participe la un sondaj pe web pentru a
comunica gradul lor de multumire fata de aplicatia web. Remarcam în acest context
ca datorita spontaneitatii comportamentului interactiv deseori nu putem observa o
aprobare sau o negare ci doar indiferenta. Daca un unui utilizator îi va place
aplicatia web o va utiliza dar va fi reticent la trimiterea unui feedback (de exemplu
informatii privind erorile gasite) pentru a contribui la dezvoltarea si îmbunatatirea
aplicatiei.
Managementul cerintelor
Utilitarele pentru managementul cerintelor permit managementul tuturor
cerintelor colectate dintr-un proiect într-un depozit central. Spre deosebire de
sistemele de procesare a textului utilitarele de management al cerintelor stocheaza
cerintele într-o baza de date. Asemenea specificatiilor de formatare, atributele
relevante sunt administrate pentru fiecare din aceste cerinte (vezi tabelul ).
Sistemele de management al cerintelor sunt importante pentru schimbarea
managementului si identificarii cerintelor. O trecere în revista a utilitarelor existente
poate fi gasita la http://www.paper-review.com/tools/rms/read.php.
2.5 Concluzii
În acest capitol am surprins câteva tendinte în proiectarea cerintelor entru aplicatiile
web:
. Disparitia granitei între dezvoltarea si utilizarea sistemelor: aplicatiile web pot fi
disponibile utilizatorilor pe parcursul dezvoltarii si ele pot evolua în acest timp.
Separarea stricta a dezvoltarii sistemului de utilizarea lui - des întâlnita în sistemele
traditionale va deveni mai putin importanta în viitor.
. O integrare mai buna a cerintelor si arhitecturilor: cercetatorii au dezvoltat
abordari pentru modelarea relatiilor si interdependentelor complexe între cerintele,
componentele si proprietatile arhitecturii sistemului. În viitor vor fi necesare
modalitati mai bune pentru a modela cerintele non-functionale si constrângerile.
. Noi instrumente pentru proiectarea cerintelor distribuite: facilitatile Internetului si
noile forme de cooperare internationala din comert si industrie demonstreaza ca
cerintele vor fi definite de echipe distribuite geografic, conducând la noi schimbari în
procesul de proiectare a cerintelor.
. Proiectarea cerintelor în sistemele deschise: aplicatiile web contin diverse
componente (de exemplu serviciile web) care sunt proiectate, dezvoltate si folosite
de diferite grupuri de împuterniciti. Aceste grupuri pot urmari obiective diferite sau
în schimbare atunci când folosesc aplicatia web, comportamentul în ansamblu al
acestora fiind greu de anticipat.
III. Modelarea aplicatiilor web
În prezent nu este folosit un model general pentru modelarea aplicatiilor web.
Modelele reprezinta un punct de pornire important pentru implementarea
aplicatiilor web, tinând cont de aspectele statice si dinamice ale nivelelor de
continut, hipertext si prezentare ale unei aplicatii web. În timp ce modelarea
continutului unei aplicatii web tinde sa surprinda informatia si logica aplicatiei - fiind
similara celei folosite într-o aplicatie non-web -, modelarea hipertextului este
exclusiv folosita pentru aplicatiile web. Modelul hipertext reprezinta toate
posibilitatile de navigare posibile pe baza continutului. Modelul prezentare mapeaza
structurile hipertext cu paginile si legaturile dintre acestea, în acest mod
reprezentându-se interfata grafica utilizator. Includerea informatiilor contextuale
(precum utilizatorul, ora, locatia si dispozitivul utilizat) si adaptarea aplicatiei web
"derivata" din aceasta informatie necesita o atentie deosebita în procesul de
modelare. Vom prezenta în continuare metodele si utilitarele disponibile pentru
modelarea aplicatiilor web precum si avantajele lor, în vederea sprijinirii procesului
de selectare a metodei adecvate. Aceste metode reprezinta fundamentul pentru
dezvoltarea bazata pe modele si pentru instrumentele de generare a codului si ne
permit o simulare a utilizarii diferitilor clienti web si platforme de lucru.
Pentru dezvoltarea aplicatiilor web complexe este necesara o abordare sistematica
si o specificare a aplicatiei web care trebuie construita sub forma modelelor vizuale.
Disciplinele de proiectare utilizeaza cu succes modelele pentru a reduce
complexitatea si deciziile de proiectare a documentelor si a facilita comunicarea în
cadrul echipelor de proiect. Modelarea are ca obiectiv furnizarea de specificatii
pentru sistemul care va fi construit la un nivel de detaliere suficient de mare pentru
implementarea sistemului. Rezultatul procesului de modelare sunt modelele, care
reprezinta aspectele relevante ale sistemului într-o maniera simplificata si
inteligibila.
stiinta calculatoarelor a utilizat dintotdeauna modelarea pentru dezvoltarea
software-ului. Figura urmatoare (vezi Figura 3.1) demonstreaza ca orizontul
modelarii acopera trei dimensiuni ortogonale. Prima dimensiune cuprinde nivelul
 logic al aplicatiei si nivelul interfetei utilizator în sensul încapsularii a "ce" si "cum" se
va realiza într-o aplicatie. Structura (ex: obiectele si atributele acestora si relatia cu
alte obiecte) si comportamentul (ex: functii si procese) apartin logicii aplicatiei si
interfetei utilizator si formeaza o alta dimensiune. Deoarece o aplicatie nu poate fi
dezvoltata "imediat", fiind necesara o rafinare progresiva si o extindere pe parcursul
procesului de dezvoltare, fazele dezvoltarii formeaza o a treia dimensiune a
modelarii aplicatiei. Prin rafinamente succesive, cerintele identificate în etapa de
analiza a cerintelor sunt transformate la început în modele de analiza si ulterior în
modele de proiectare, pe baza carora se va realiza implementarea.
Figura 3.1
Cerinte pentru
modelarea
aplicatiilor
software
Originile
modelarii le
putem regasi în
proiectarea datelor si în proiectarea software-ului. Proiectarea datelor modeleaza
aspectele structurale (datele) unei aplicatii, identificarea entitatilor, gruparea
acestora si relatiile dintre ele fiind obiectivul major. În acest sens cel mai cunoscut
este modelul entitate-relatie (ER)37[37]. În schimb, modelarea aplicatiilor software
pune accentul pe aspectele comportamentale pentru îndeplinirea cerintelor
limbajelor de programare si se bazeaza în prezent în special pe abordarea orientata-
obiect. Cea mai importanta caracteristica a modelarii orientata-obiect este
abordarea holistica a modelarii sistemului si conceptul de obiect, care cuprinde
structura si comportamentul.
Limbajul de modelare unificat (UML)38[38] este un limbaj de modelare orientat-
obiect si este privit ca o lingua franca în dezvoltarea software-ului orientat obiect.
UML reprezinta fundamentul majoritatii metodelor de modelare pentru aplicatiile
web si permite specificarea aspectelor unui sistem software sub forma modelelor si
a diagramelor pentru reprezentarea grafica a acestora. UML dispune de doua tipuri
de diagrame: diagrame structurale (diagramele de clasa, diagramele de

37[37] Chen, P., The Entity-RelationshipModel - Toward a Unified View of Data, ACM
Transactions on Database

Systems, 1976, pp. 9-36

38[38] OMG (Object Management Group), UML 2.0 Superstructure Specification - Revised
Final Adopted

Specification, 2004, http://www.omg.org

 componente, diagramele de structura complexe, diagramele de desfasurare) si
diagrame de comportament (diagrame de utilizare de caz, diagramele de stari -state
machine-, diagramele de activitate).
3.1 Caracteristicile modelarii în proiectarea web
Abordarile de modelare specifice aplicatiilor web au fost dezvoltate în special în
ultimii ani si permit abordarea aplicatiilor web tinând cont de cele trei dimensiuni
specificate anterior: nivele, aspecte si faze.
Nivele
Pentru a modela aplicatiile web trebuie avut în vedere caracterul orientat pe
document al continutului acestora si navigarea hipertext non-liniara. Din acest motiv
distingem trei nivele ale modelarii aplicatiilor web (vezi Figura 3.2) spre deosebire de
cele doua nivele utilizate în metodele de modelare pentru aplicatiile traditionale.
Cele trei nivele sunt continutul (informatia si logica aplicatiei care stau la baza
aplicatiei web), hipertextul (structurarea continutului în noduri si legaturile dintre
acestea) si prezentarea (interfata utilizator sau layout-ul paginii). Majoritatea
metodelor utilizate în modelarea aplicatiilor web utilizeaza aceasta separare pe trei
nivele39[39].
Figur
a 3.2
Cerin
tele
mode
larii
aplica
tiilor
web
O separare clara între aceste nivele permite reutilizarea si ajuta la reducerea
complexitatii. De exemplu, putem specifica un anumit numar de structuri hipertext
diferite care vor lamuri cerintele specifice diferitelor grupuri de utilizatori si a
dispozitivelor utilizate pentru un anumit continut. Obiectivul modelarii continutului
este definirea explicita a structurii informatiei; similar cu schema bazei de date din
modelarea datelor, aceasta elimina redundanta (structura informatiei va ramâne
neschimbata chiar daca informatia însasi se schimba frecvent).
Pentru a proiecta o navigare eficienta continutul poate fi oferit în mod
redundant pe noduri multiple la nivel hipertext. Continutul este modelat o singura
data (în modelarea continutului) iar modelul structurii hipertext realizeaza doar o

39[39] Fraternali, P., Tools and Approaches for Data-intensive Web Applications: A Survey,
ACM Computing

Surveys, 31 (3), September, 1999, pp. 227-263

referinta la continutul corespunzator. În acest mod utilizatorii pot gasi aceasta
informatie pe diverse cai de acces. Pentru a preveni ratacirea utilizatorilor în timpul
navigarii si pentru a pastra stresul cognitiv asupra acestora cât mai scazut,
modelarea hipertext trebuie sa se bazeze pe sabloane de navigare recurente.
În ceea ce priveste modelarea la nivel de prezentare, focalizarea se va face
asupra structurii de prezentare uniforme a paginilor, pentru obtinerea unui efect de
recunoastere a brandului aplicatiei web printre utilizatorii sai. Desi aspectul vizual al
unei aplicatii web este important, aspectele estetice nu fac parte din obiectivele
majore ale modelarii.
În ciuda separarii intereselor si obiectivelor diferite în cadrul celor trei nivele, putem
stabili o corespondenta între acestea. Pentru realizarea acestui lucru trebuie definite
explicit interdependentele dintre nivele. De exemplu, diferite cai de acces hipertext
personalizate pot fi mapate într-un singur model de continut. Un model
comprehensiv al unei aplicatii web include toate cele trei nivele discutate, dar
accentul variaza în functie de tipul aplicatiei web. Aplicatiile web care furnizeaza o
interfata utilizator pur orientata-hipertext pentru un set mare de date, vor necesita
focalizarea modelarii pe continut si structura hipertextului. În contrast, aplicatiile
web orientate pe prezentare (portalurile corporative sau magazinele de cumparaturi
online) vor avea cereri mai mari în ceea ce priveste modelarea prezentarii.
Aspecte
Conform principiilor orientate obiect, structura si comportamentul sunt
modelate la fiecare din cele trei nivele (continut, hipertext si prezentare). Relevanta
structurii si comportamentului modelelor depinde de tipul de aplicatie web care va fi
implementata. Aplicatiile web care contin în principal informatie statica necesita o
modelare comportamentala mai redusa comparativ cu aplicatiile web interactive (ex.
aplicatiile de comert electronic care ofera motoare de cautare, functii precum
lansarea unei comenzi). Datorita maparii diferitelor nivele este recomandata
utilizarea unui formalism uniform de modelare pentru structura si comportament,
care permite folosirea unui singur instrument CASE.
Faze
În literatura nu exista un consens privitor la o abordare generala a modelarii
pentru dezvoltarea aplicatiilor web. În toate cazurile secventa de pasi pentru
modelarea nivelelor trebuie stabilita de catre modelator. În functie de tipul aplicatiei
web se poate folosi o abordare bazata pe informatie (pornirea de la modelarea
continutului) sau o abordare bazata pe prezentare (pornirea de la modelarea
aspectelor de prezentare a aplicatiei). Dezvoltarea bazata pe modele în proiectarea
web este contradictorie cu practicile folosite în proiectele web (de exemplu cicluri de
dezvoltare cu viata scurta si necesitatea unor "metode rapide"). Abordarea bazata
pe modele ofera în aceasta situatie posibilitatea specificarii comprehensive a unui
model al solutiei si, daca este disponibil un utilitar CASE, posibilitatea generarii
automate a prototipului aplicatiei web.
Personalizarea
Includerea informatiilor de context în dezvoltarea aplicatiilor web are un rol
semnificativ, permitând personalizarea, distribuirea multi-platforma si serviciile
bazate pe locatie. Personalizarea se refera la context (exemplu: preferintele
utilizatorilor, caracteristicile dispozitivelor sau restrictiile privind latimea de banda) si
permite adaptarea aplicatiilor web în functie de aceasta. Aceasta influenteaza toate
cele trei dimensiuni ale modelarii web (continut, hipertext si prezentare) în
conformitate cu structura si comportamentul si trebuie luata în considerare în toate
fazele procesului de dezvoltare. Managementul informatiei de context este tratat ca
o dimensiune de modelare independenta.
Desi nu exista o metoda de modelare globala care sa acopere toate dimensiunile
discutate anterior, vom utiliza în cele ce urmeaza UML si îl vom extinde prin
preluarea unor concepte din metoda de modelare pentru aplicatii web bazata pe
UML - cunoscuta sub numele de UWE (proiectarea web bazata pe UML - UML based
Web Engineering).
3.2 Cerintele modelarii
Se pot utiliza diverse tehnici pentru a identifica, analiza, descrie, evalua si administra
cerintele aplicatiilor web. Cazurile de utilizare reprezinta tehnica de modelare
adecvata cerintelor functionale deoarece ele pot fi reprezentate în mod grafic.
Functionalitatea în ansamblu a aplicatiei web este modelata ca un set de cazuri de
utilizare care descriu cerintele aplicatiei web din perspectiva actorilor (indivizi si alte
sisteme). Mai mult, cazurile de utilizare pot fi suplimentate de diagrame de activitate
UML pentru a descrie cerintele functionale în detaliu.
O caracteristica a cerintelor aplicatiilor web este functionalitatea de navigare, care
permite utilizatorilor sa navigheze prin intermediul hipertextului si sa gaseasca
nodurile. În acest sens, se recomanda separarea functionalitatii de cazurile de
utilizare pentru navigare, ducând astfel la aparitia a doua modele distincte. O alta
abordare (UWE) implica crearea unui singur model de caz de utilizare care foloseste
stereotipul <<navigare>> pentru a indica diferenta între cazurile de utilizare
functionale si cele specifice hipertextului.
Toate aplicatiile web au cel putin un utilizator uman, de cele mai multe ori anonim.
În exemplul urmator al unei conferinte online, pentru sistemul de recenzie al
articolelor pot fi identificati 4 actori: utilizatorii sistemului de recenzie, autorii care
trimit articole pentru conferinta, membrii comitetului de organizare a conferintei
(recenzenti) care revizuiesc articolele trimise si presedintele comitetului de
organizare (presedintele CO). Figura 3.3 reprezinta o diagrama tip caz de utilizare,
parte a unui model de utilizare pentru un sistem de recenzie, care va servi drept
punct de pornire pentru modelarea ulterioara. Cerintele de navigare care
suplimenteaza cerintele functionale sunt definite explicit prin stereotipul
<<navigare>> în diagrama tip caz de utilizare.
Figura 3.3: Diagrama de utilizare de caz pentru un sistem de recenzie
Cazurile de utilizare trebuie descrise în detaliu; putem descrie fiecare caz de utilizare
în mod textual sau prin utilizarea diagramelor de comportament (de exemplu
diagrama de activitate). Diagramele de activitate sunt utilizate în principal când cele
de utilizare de caz se solicita o logica a aplicatiei mai complexa. Un astfel de caz de
utilizare poate fi implementat ca un serviciu web. Figura 3.4 este un exemplu de
proces simplificat pentru trimiterea articolelor.

Figura 3.4: Diagrama de activitate pentru procesul de trimitere a unui articol

3.3 Modelarea continutului
Informatia furnizata de o aplicatie web este unul din cei mai importanti factori
pentru succesul acelei aplicatii, în principal datorita originii web-ului ca un mediu
informational. Modelarea continutului în sensul de modelare pura a datelor este
suficienta în mod normal pentru aplicatiile web statice. Aplicatiile web complexe
solicita în plus modelarea aspectelor comportamentale. De aici rezulta ca modelarea
continutului include crearea modelului domeniului problemei, ce consta în aspectele
statice si dinamice cunoscute din proiectarea software clasica. În plus trebuie luate
în considerare urmatoarele caracteristici ale aplicatiilor web:
- Caracterul axat pe documente si multimedia: este necesar sa luam în considerare
toate tipurile de formate media când modelam continutul, inclusiv structurile pe
care informatia este bazata.
- Integrarea datelor existente si software-ului: multe aplicatii web construite pe
depozite de date existente si componente software nu au fost create initial pentru
aplicatiile web. Modelarea continutului trebuie sa îndeplineasca doua obiective
contradictorii: trebuie sa acopere cerintele de continut ale aplicatiei web pentru o
extindere ulterioara si trebuie sa includa structurile de date existente si
componentele software.
Obiective
Modelarea continutului se focalizeaza pe transferarea informatiei si cerintelor
functionale, stabilite prin proiectarea cerintelor, într-un model. Caracterul hipertext
al aplicatiilor web si cerintele prezentarii acesteia nu vor fi luate în considerare.
Modelarea continutului determina un model care include atât aspectele structurale
ale continutului (sub forma diagramelor de clasa) cât si - în functie de tipul aplicatiei
web - aspectele comportamentale (sub forma diagramelor de stare si interactiune).
Concepte
Asa cum am mentionat anterior, modelarea continutului se bazeaza pe concepte si
metode ale modelarii datelor sau modelarii orientate-obiect si încearca sa ne asigure
ca informatia existenta nu este redundanta si este reutilizabila.
Figura 3.5 ilustreaza o diagrama de clasa UML simplificata pentru exemplul de sistem
de recenzie mentionat anterior. Diagrama modeleaza o conferinta privitoare la un
numar de subiecte si utilizatorii care se pot autentifica pentru conferinta si trimite
articolele proprii. Un articol este subiectul unei recenzii realizate de 3 recenzenti.
Elementul atasat la clasa "Articol" ne asigura ca autorii nu vor putea sa revizuiasca
propriile articole. Aceasta diagrama de clasa va servi ulterior drept baza pentru
modelarea hipertextului si a prezentarii pentru aplicatia discutata.
Figura 3.5 Diagrama de clasa pentru sistemul de recenzie
Figura 3.6 reprezinta o diagrama de stare (state machine diagram) si este utilizata
pentru a modela diverse stari ale articolului în sistemul de recenzie. Un articol trimis
va fi preluat de trei recenzenti pentru revizuire dupa ce termenul limita pentru
trimitere a expirat. Daca valoarea limita prestabilita este atinsa articolul este
acceptat; altfel este respins. În ambele cazuri autorii sunt anuntati prin e-mail despre
rezultatul recenziei. În final articolul acceptat va fi publicat.

Figura 3.6 Diagrama de stare pentru starile articolului

3.4 Modelarea hipertextului
Non-linearitatea hipertextului este una din cele mai importante proprietati de care
trebuie tinut cont când modelam aplicatiile web. Din acest motiv structura hipertext
trebuie proiectata cu atentie. Aceasta poate fi realizata prin utilizarea structurilor de
acces adecvate - optiuni de navigare pentru eliminarea riscului de ratacire a
utilizatorilor si de supunere la un stress cognitiv excesiv.
Obiective
Obiectivul modelarii hipertext (cunoscuta si ca modelarea navigarii) este specificarea
navigabilitatii în continutul aplicatiei web (caile de navigare disponibile utilizatorilor).
Modelarea hipertext genereaza un rezultat dublu: în primul rând produce modelul
structurii hipertext (modelul structurii de navigare) care defineste structura
hipertextului, respectiv ce clase ale modelului de continut pot fi vizitate prin
navigare. În al doilea rând, rafineaza modelul de structura hipertext prin accesarea
elementelor sub forma unui model de acces.
Modelarea hipertext se focalizeaza pe aspectele structurale ale hipertextului si
elementele de acces. Comportamentul de navigare a unei aplicatii web nu este în
mod normal reprezentat explicit, deoarece ofera informatii aditionale
nesemnificative pentru dezvoltatori.
Concepte de modelare a structurii hipertext
Spre deosebire de nivelul continutului, pentru care sunt utilizate diagramele ER sau
diagramele de clasa, pentru modelarea structurii hipertext sunt folosite notatii
specifice. Modelarea structurii hipertext se bazeaza pe conceptele hipertext (noduri
- pagini sau documente si legaturi între aceste noduri).
Punctul de plecare folosit pentru crearea modelului structurii hipertext este de
obicei modelul de continut care contine clasele si obiectele care vor fi disponibile ca
noduri în hipertext. Deseori modelul de structura hipertext este specificat ca o
perspectiva a modelului de continut, fiind uneori numit perspectiva navigationala.
Astfel, un nod este specificat ca o perspectiva a modelului de continut, selectând
unul sau mai multe obiecte din continut. Unele metode modeleaza structura
hipertext indiferent de modelul de continut. De exemplu OOHDM (Object-Oriented
Hypermedia Design Method) ofera o abordare de a modela scenariile, în care
modelul de structura hipertext poate fi construit direct pe baza cerintelor de
navigare identificate de aceste scenarii.
În sistemul de recenzie folosit ca exemplu perspectiva hipertext este necesara
pentru urmatoarele roluri ale utilizatorilor: autor, recenzent si presedintele
comitetului de organizare. Figura 3.7 ilustreaza modelul de structura hipertext din
perspectiva presedintelui comitetului de organizare. Presedintele poate vizualiza
toate articolele trimise, poate accesa lista de articole acceptate sau respinse si
profilurile recenzentilor. Conform metodei de modelare UWE, figura 3.7 ilustreaza
modul în care stereotipul UML <<clasa de navigare>> este utilizat pentru a marca
clasele ce reprezinta nodurile în modelul de structura hipertext pentru a le distinge
de clasele de continut. Legaturile sunt modelate prin asocieri directe cu stereotipul
<<legatura de navigare>>.
 Figura 3.7 Model de structura hipertext a perspectivei presedintelui comitetului de
organizare asupra sistemului de recenzie
În literatura de specialitate distingem tipuri de legaturi folosite pentru rafinarea
ulterioara a semanticii modelului structurii hipertext. De exemplu metoda HDM
(Hypertext Design Model) specifica urmatoarele tipuri de legaturi:
- Legaturile structurale conecteaza elementele aceluiasi nod (de exemplu de la
rezumatul recenziei la detaliile recenziei)
- Legaturile de perspectiva plaseaza diferite perspective ale unui nod în relatie cu
altele (de exemplu versiunile PostScript si PDF ale unui articol).
- Legaturile aplicatiei plaseaza noduri diferite în relatie unul cu altul în functie de
aplicatie (de exemplu o legatura care trimite la "cel mai bun articol").
Alte clasificari se bazeaza pe posibilul transport al informatiei pe parcursul navigarii.
De exemplu metoda WebML40[40] (Web Modeling Language) specifica urmatoarele
tipuri de legaturi:
- legaturi contextuale - transmit informatia contextuala (de exemplu numarul unic al
recenzentului pentru a naviga de la un recenzent la recenzia pe care el a creat-o)
- legaturi noncontextuale - nu au asociate informatii de context (de exemplu legaturi
care duc de la o recenzie singulara la lista tuturor recenziilor)
Datorita distributiei nodurilor la nivel hipertext asupra paginilor de la nivelul
prezentare, WebML specifica în plus urmatoarele tipuri de legaturi:
- legaturi intra-pagina - sunt utilizate când sursa si destinatia legaturii apartin
aceleiasi pagini (de exemplu când o legatura permite utilizatorului sa navigheze
direct la rezumatul articolului, care este afisat în partea de jos a paginii);
- legaturi inter-pagini - sunt utilizate când sursa si destinatia se afla pe pagini diferite
(de exemplu când informatii detaliate despre autori si articolele lor se gasesc pe
pagini diferite).
Pe baza cerintelor functionale ale aplicatiilor web, metoda de modelare UWE
defineste urmatoarele tipuri de legaturi:

40[40] Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., Maristella, M., Designing Data-Intensive

Web Applications, Morgan Kaufmann, 2003

- legaturi de navigare - sunt utilizate pentru a naviga între noduri (de exemplu
legaturi între articole si autorii acestora)
- legaturile procesului - indica nodul de început al unui proces (de exemplu spre
începutul procesului de trimitere a recenziei)
- legaturile externe - indica un nod care nu apartine în mod direct aplicatiei (de
exemplu spre ghidurile de formatare stabilite de editorul lucrarilor conferintei, care
nu sunt stocate direct în sistemul de recenzie).
Metoda de modelare OO-H (Object-Oriented Hypermedia) defineste cinci tipuri de
legaturi dupa cum urmeaza:
- legaturi I (legaturi interne) - indica nodurile din interiorul granitelor unei cerinte de
navigare (de exemplu legaturi interne la detaliile recenziei realizate de unul dintre
recenzenti)
- legaturi T (legaturi transversale) - indica nodurile care satisfac alte cerinte de
navigare (de exemplu de la un autor la articolele acestuia)
- legaturi R (legaturile cerintei) - indica începutul unei cai de navigare (de exemplu
adaugarea unei noi recenzii)
- legaturi X (legaturi externe) - indica noduri externe (de exemplu la ghiduri de
formatare externe)
- legaturi S (legaturile serviciului) - indica (împreuna cu legaturile corespunzatoare de
raspuns) spre servicii (de exemplu spre un motor de cautare extern).
Concepte de modelare a accesului
Modelul structurii hipertext construit pâna în prezent în mod singular nu este
suficient pentru a descrie modul în care nodurile pot fi accesate prin navigare.
Pentru a permite utilizatorilor sa navigheze catre noduri este necesar sprijinul în
navigare si orientare. Acestea se regasesc sub forma structurilor de acces care
rafineaza modelul de structura hipertext. Structurile de acces recurente sunt
descrise ca sabloane de proiectare, deseori fiind numite "sabloane de proiectare
hipermedia" sau "sabloane de navigare". Utilizarea acestor sabloane de navigare
contribuie la o crestere semnificativa a calitatii modelului hipertext.
În sistemul de recenzie, daca cineva doreste sa navigheze de la un recenzent
la un articol asociat acestuia, trebuie sa identifice acest articol pe parcursul navigarii.
De exemplu, acest lucru se poate realiza sub forma unei liste care afiseaza toate
articolele, lista cunoscuta si sub numele de "index". Un index este o structura de
acces care permite utilizatorilor sa selecteze un singur obiect (de exemplu un obiect
din continut) dintr-o lista omogena de obiecte. Spre deosebire de index, un meniu
permite utilizatorilor sa acceseze noduri eterogene sau meniuri suplimentare
(submeniuri). Alte structuri de acces sunt "turul organizat" si interogarea. "Turul
organizat" permite utilizatorilor sa se deplaseze secvential printr-un anumit numar
de noduri. O interogare permite utilizatorilor sa caute noduri. Majoritatea metodelor
de modelare ofera elemente de modelare dedicata pentru cele mai frecvent utilizate
sabloane de navigare. sabloanele de navigare speciale cuprind: home - care trimite
la pagina principala a aplicatiei web si punctul de reper - care trimite catre un nod ce
poate fi accesat de la toate nodurile.
O parte din structurile de acces prezentate pot fi adaugate modelului de
structura hipertext în mod automat. De exemplu indecsii pot fi adaugati automat
oricând dorim sa permitem accesul la un set (mai mare decât unul) de obiecte ale
unui nod.
Figura 3.8 ilustreaza un model de acces simplificat din perspectiva
presedintelui comitetului de organizare specificat în modelul de structura hipertext
al sistemului de recenzie. De notat ca multiplicitatea implicita a legaturilor este 1.
Presedintele comitetului de organizare are acces la toate articolele, recenziile si
utilizatorii. Pentru a accesa un articol anume este utilizat un numar unic.
Presedintele comitetului de organizare poate cauta un articol în functie de titlu.
UWE foloseste stereotipuri UML cum ar fi: <<meniu>> (exemplu "conferinta"),
<<index>> ( exemplu "starea recenziei") , interogare (exemplu "cautare dupa titlul
articolului") si <<turul organizat>> pentru specificarea structurilor de acces meniu,
index, interogare si tur organizat.

Figura 3.8 Model de acces simplificat la al modelului de structura din Figura 3.7
Relatia cu modelarea continutului
În functie de metoda de modelare de baza, modelul hipertext este mai mult sau mai
putin dependent de modelul de continut. Exista atât o dependenta la nivel de model
(de exemplu ce clase din modelul de continut formeaza un anumit nod în modelul
hipertext si la nivel de instanta - ce set de obiecte din modelul de continut populeaza
acel nod din modelul hipertext. Nu toate metodele descriu dependente între
modelul de continut si modelul hipertext. Totusi unele metode specifica o derivare
directa a hipertextului de la continut prin definirea nodurilor pe baza vizualizarilor.
3.5 Modelarea prezentarii
Similar cu modelarea software clasica, modelarea prezentarii trateaza interfata
utilizator si necesita prezentarea aspectului unei aplicatii web. Spre deosebire de
aplicatiile traditionale elementul central al prezentarii din aplicatiile web este pagina
ca unitate de vizualizare.
Obiective
Modelarea prezentarii este realizata în momentul proiectarii structurii si
comportamentului interfetei utilizator pentru a asigura interactiunea cu aplicatia
web într-un mod simplu si auto-explicativ. În plus, se tine cont de aspectele de
comunicare si de reprezentare ale aplicatiei web. Modelarea prezentarii genereaza
un rezultat dublu: în primul rând produce un concept de prezentare uniforma prin
modelarea elementelor recurente din pagini (de exemplu antete si subsoluri de
pagina). Modelarea prezentarii ar trebui în mod ideal sa afiseze structura fiecarei
pagini si proiectarea câmpurilor textelor, imaginilor, formularelor etc., incluse în
aceste pagini. În al doilea rând, pe lânga structura paginilor modelul de prezentare
descrie aspecte comportamentale ale interfetei utilizator (de exemplu pe ce buton
se va executa clic pentru a activa o functie din logica aplicatiei). Datorita diversitatii
mari a optiunilor de navigare si riscului inerent al ratacirii utilizatorilor, trebuie avut
în vedere acordarea unui sistem de ajutor pentru orientarea utilizatorilor la nivelul
prezentarii. Aceasta poate fi realizata, de exemplu, prin afisarea caii de navigare
curente sau a paginilor vizitate pe parcursul sesiunii active.
Nu toate metodele disponibile pentru modelarea aplicatiilor web suporta
concepte de modelare a prezentarii independente de tehnologie; unele utilizeaza
concepte specifice tehnologiei, cum ar fi limbajele pentru stiluri (cum ar fi XSL -
Extensible Stylesheet Language).
Un alt factor important pentru aplicatiile web este proiectarea grafica a
layout-ului pentru interfata utilizator, care deseori este realizata de un grafician pe
baza unor schite de baza sau conceputa prin implementarea paginilor prototip cu
ajutorul utilitarelor.
Concepte
Elementele modelului sunt descrise pe trei nivele ierarhice:
- O pagina de prezentare descrie o pagina prezentata utilizatorului ca o unitate de
vizualizare. Poate fi compusa din diferite unitati de prezentare.
- O unitate de prezentare este utila pentru gruparea elementelor interfetei utilizator
si reprezinta un fragment logic al paginii. Prezinta un nod ce deriva din modelul
hipertext.
- Un element de prezentare este blocul de baza al modelului prezentare. Elementele
de prezentare sunt un set de informatii ale nodului si pot include text, imagini, audio
etc.
Putem vizualiza structura paginilor de prezentare pe baza reprezentarii unei
diagrame de clasa UML imbricate cunoscuta sub numele de "structura", asa cum se
poate observa în figura 3.9. Acest exemplu utilizeaza clasele stereotip <<pagina>> si
<<unitate de prezentare>> pentru a descrie paginile de prezentare si unitatile de
prezentare. Toate tipurile de elemente de prezentare sunt de asemenea proiectate
prin stereotipuri UML adecvate. Figura 3.9 ilustreaza doua pagini de prezentare ale
sistemului de recenzie. Un articol este plasat pe o pagina numita "Pagina Articolului"
împreuna cu câmpurile aferente, o legatura catre versiunea completa a articolului si
o legatura pentru a afisa autorii articolului. În plus, utilizatorii pot apasa un buton
pentru a adauga o noua recenzie. Pagina "Pagina Autorului" are doua unitati de
prezentare - lista tuturor autorilor si informatia detaliata despre fiecare autor.

Figura 3.9 Paginile de prezentare ale sistemului de recenzie

Aspectele comportamentale ale interfetei utilizator precum interactiunea
recenzentilor pentru a naviga catre articolele atribuite acestora pentru recenzie, pot
fi modelate cu ajutorul diagramelor de comportament, asa cum se poate observa în
figurile 3.10, 3.11 si 3.12. În general interactiunea utilizatorului cu aplicatia web nu
implica doar nivelul de prezentare; se face trimitere deseori la nivelul hipertext si
nivelul de continut în functie de tipul de interactiune. În diagramele din figurile 3.11
si 3.12 un recenzent foloseste navigarea catre indexul articolelor atribuite acestuia
prin utilizarea barei de navigare din interiorul paginii principale a conferintei.
Aceasta informatie este compusa din articole relevante de pe nivelul de continut.
Aceasta lista permite utilizatorului sa selecteze un articol din lista atribuita acestuia.
Utilizatorul poate apoi naviga pentru a selecta un articol, care va fi afisat în mod
detaliat.
 Figura 3.10
Diagrama de
interactiune
a sistemului
de recenzie

Figura 3.11 Diagrama secventiala pentru extragerea unei liste de articole atribuite

Figura 3.12 Diagrama secventiala pentru afisarea articolelor selectate

Relatia cu modelarea hipertext
Similar cu maparea modelului de continut la modelul hipertext, trebuie sa specificam
modul în care elementele hipertext trebuie mapate la elemente de prezentare.
Aceasta se realizeaza de obicei pornind de la ipoteza ca toate instantele unui nod vor
fi afisate la nivelul de prezentare.
Interactiunile declansate de un utilizator nu sunt limitate doar la nivelul de
prezentare. Din acest motiv trebuie sa tinem cont de corespondenta acestora cu alte
legaturi. Aceasta corespondenta poate fi sub forma obiectelor si logicii aplicatiei la
nivelul de continut, iar pentru navigare la nivel hipertext.
3.6 Modelarea personalizarii
Deoarece aplicatiile web omniprezente au o importanta deosebita este necesar sa
luam în calcul informatia contextuala si o adaptare adecvata a aplicatiei în faza de
modelare. Propuneri relevante pentru personalizare regasim în domeniul
personalizarii si sistemelor mobile.
Modelarea personalizarii este un domeniu foarte nou, existând doar câteva metode
pentru modelarea aplicatiei web care ofera o astfel de forma a modelarii. Pentru
metodologia UWE a fost propusa recent o abordare orientata pe aspect pentru a
trata problema personalizarii.
Obiective
Modelarea personalizarii este realizata printr-o reprezentare explicita a informatiei
de context si a adaptarilor derivate din aceasta. În functie de metoda de modelare,
rezultatul nu este întotdeauna un model al personalizarii explicit. În majoritatea
cazurilor modelarea personalizarii se confunda cu modelele continutului,
hipertextului si prezentarii. Personalizarea trebuie sa fie distincta de întretinere sau
reproiectare. Modelarea personalizarii ia în considerare informatia care poate fi
anticipata în momentul modelarii si care poate lua valori diferite când aplicatia web
ruleaza. În schimb, adaptarea datorata modificarilor din mediul organizational sau
tehnologic implica activitati de întretinere sau reproiectare.
Concepte
Personalizarea necesita examinarea situatiilor de utilizare a aplicatiilor web - a
raspunde la întrebarile "ce" si "când" trebuie adaptat. Pentru a putea personaliza o
aplicatie web este necesara o modelare si o administrare a preferintelor si
caracteristicilor unui utilizator în asa numitul profil al utilizatorului. De exemplu,
pentru a adapta o aplicatie web din domeniul sistemelor mobile, trebuie sa luam în
considerare profilele dispozitivului, informatii privind locatia si latimea de banda.
Aceasta informatie este apoi reprezentata în cadrul modelului de context sub forma
diagramelor de clasa. În momentul rularii, contextul se poate schimba (de exemplu
îsi schimba preferintele sau aplicatia este folosita din diferite locatii). Din acest motiv
este necesara o adaptare a aplicatiei web.
În ceea ce priveste nivelul de abstractizare al informatiei contextuale, putem
distinge contextul fizic si contextul logic. Contextul fizic rezulta dintr-o situatie de
utilizare specifica (de exemplu numele de utilizator pentru o autentificare sau celula
GSM în care un utilizator este situat). Contextul logic ofera cunostinte de context
suplimentare (de exemplu adresa de la serviciu versus adresa de acasa, ore de lucru
versus timp liber). Aceste informatii de context pot fi oferite aplicatiei web si din
surse externe. Un exemplu de astfel de sursa externa care ofera informatii pentru o
specificare mult mai detaliata a contextului locatiei sunt sistemele informationale
geografic (GIS- Geographic Information Systems). Au fost propuse si alte abordari
(cum ar fi Context Toolkit sau proiectul NEXUS) pentru a sprijini componente
universale capabile sa ofere diferite tipuri de informatii contextuale fizice si logice.
Adaptarea la un context poate fi modelata în unul sau doua moduri. În primul rând
poate fi modelata într-un mod orientat pe rezultat prin crearea unor modele diferite
sau variante de modele tinând cont de diferitele seturi de variante ale informatiei
contextuale. Aceasta abordare se numeste adaptare statica. Exemplul de modelare
hipertext din figura 3.7 descrie o structura hipertext adaptata la contextul rolului
utilizatorului "CO" (comitet de organizare). Neajunsul adaptarii statice este cresterea
exponentiala a variantelor de modele care trebuie luate în considerare. În al doilea
rând poate fi utilizata adaptarea dinamica. Spre deosebire de adaptarea statica,
aceasta adauga reguli de transformare (dependente de context) modelelor continut,
hipertext si prezentare. Aceste reguli de transformare descriu variantele care trebuie
create în momentul rularii. De exemplu, regulile de transformare dinamica formulate
ca reguli ECA (Eveniment/Conditie/Actiune) pot specifica adaugarea sau eliminarea
elementelor modelului, sau filtrarea instantelor pentru a crea o lista personalizata cu
articole despre subiectele de care este interesat un utilizator. Folosirea unei adaptari
statice sau dinamice depinde de cazul de utilizare. Adaptarea dinamica are avantajul
ca evita explozia de combinatii a variantelor de modelare. Dezavantajul ei consta în
faptul ca rezultatul (varianta modelului adaptata contextului) nu este disponibila în
mod direct, dar va fi creata "la rulare", ceea ce face mai dificila întelegerea
modelului.
Figurile 3.13 si 3.14 ilustreaza modul în care nivelele hipertext si prezentare ale
sistemului de recenzie pot fi adaptate dinamic. S-au folosit adnotari (prin stereotipul
<<personalizare>>) pentru a adauga reguli de personalizare claselor adaptate.
Regulile descrise în acest exemplu pot fi specificate mai detaliat utilizând un limbaj
formal (de exemplu OCL - Object Constraint Language). Figura 3.13 ilustreaza modul
în care structura hipertext poate fi personalizata astfel încât articolele pe care un
utilizator le poate citi sa fie limitate la subiectele de interes pentru acel utilizator.
Elementele structurii de acces "Articole Interesante" sunt adaptate dinamic prin
reguli de transformare bazate pe subiectele personale de interes.

Figura 3.13 Adaptarea dinamica a unui index în modelul hipertext

Figura 3.14 ilustreaza modul în care elementele din modelul de prezentare pot fi
adaptate prin utilizarea regulilor de transformare (de exemplu butonul "Introduceti
Recenzia" trebuie sa fie vizibil doar pentru utilizatorii cu rolul "Recenzent").

Figura 3.14 Adaptarea dinamica a unei pagini în modelul de prezentare

Majoritatea tehnologiilor existente în prezent abordeaza modelarea personalizarii
prin definirea regulilor sau unui filtru pentru fiecare punct din aplicatia web în care
personalizarea se aplica ca în exemplul anterior. UWE foloseste o abordare diferita,
utilizând tehnici de modelare orientate pe aspect (AOM). AOM permite pe de o
parte o separare sistematica a functionalitatii sistemului de aspectele personalizarii,
iar pe de alta parte permite reducerea redundantei.
Relatia cu modelarea de continut, hipertext si de prezentare
Personalizarea poate influenta toate nivelele procesului de modelare a aplicatiilor
web. Modificarile pot fi locale (la un singur nivel) sau pot afecta nivele multiple. Este
recomandata separarea modelului personalizarii de modelele continut, hipertext si
prezentare în ceea ce priveste variabilitatea, flexibilitatea si încapsularea, dar
majoritatea metodelor existente nu ofera aceasta separare. În cazul sistemului de
recenzie o astfel de separare este dificila (exemplu: utilizatorul aplicatiei web si
preferintele acestuia reprezinta probleme de modelare a contextului, dar utilizatorul
poate fi o problema si de modelare a continutului).
3.7 Metode si utilitare
Toate metodele de modelare ofera un set de elemente de modelare ajustate la
cerintele aplicatiilor web si majoritatea ofera o notatie specifica pentru elementele
modelate. În plus, multe dintre ele definesc un proces si sunt sustinute de un utilitar
care genereaza (semi) automat o implementare pe baza modelelor create (vezi tabel
3.1)
Metode de modelare
Metodele disponibile pentru modelarea aplicatiilor web se bazeaza pe cele clasice
(cum ar fi ER) sau îmbunatatesc un limbaj de modelare orientat-obiect (UML). Din
punct de vedere istoric metodele de modelare a aplicatiilor web se prezinta ca în
figura 3.17.

Figura 3.17 Dezvoltarea istorica a metodelor de modelare pentru aplicatiile web

Metodele de modelare urmeaza diferite paradigme, în functie de originea si
focalizarea acestora:
HDM
WebML

HDM-Lite

OOHDM

WebSA
 WAE2

OO-H

OOWS

W2000

WSDM

UWE

WAE

UML

OMT
- Metodele orientate pe date - îsi au originea în domeniul sistemelor de baze de
date si se bazeaza în principal pe un model entitate-relatie îmbunatatit prin
concepte specifice pentru modelarea la nivel hipertext. Principalul obiectiv al acestor
metode este modelarea aplicatiilor web care folosesc bazele de date. Exemple de
astfel de metode sunt RMM (Relationship Management Methodology), Hera si
WebML (WebModeling Language41[41]).
- Metodele orientate pe hipertext - se focalizeaza pe caracterul hipertext al
aplicatiilor web; ele deriva în principal din domeniul sistemelor hipertext. Cele mai
reprezentative exemple sunt: HDM (Hypertext Design Model) care a fost extinsa
ulterior în W2000, sau WSDM (Web Site Design Method).
- Metodele orientate pe obiecte - se bazeaza fie pe OMT (primele metode aparute)
sau UML (cele mai recente). UML este notatia preferata atunci când se alege un
limbaj standard pentru modelare. Aceasta categorie include OOHDM (Object-
Oriented Hypermedia Design Method), UWE (UML-based Web Engineering), OOWS
(Object-Oriented Web Solutions42[42]) si OO-H (Object-Oriented Hypermedia).

41[41] Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., Maristella, M., Designing Data-Intensive

Web Applications, Morgan Kaufmann, 2003

42[42] Pastor, O., Pelechano, V., Fons, J., Abrah~ao, S., Conceptual Modelling of Web Applications: the OOWS

Approach. In: Web Engineering - Theory and Practice of Metrics and Measurement for Web Development,

Mendes, E., Mosley, N. (Eds.), Springer-Verlag, 2005.

 - Metodele orientate pe software - abordeaza aplicatiile web în special din
perspectiva dezvoltarii clasice de software, folosind tehnici care urmeaza strict
proiectarea software clasica. Exemple pentru aceasta categorie sunt WAE (Web
Application Extension) sau WAE2 (versiunea sa îmbunatatita)43[43].
Tabelul 3.1 ofera o descriere detaliata a acestor metode, specificând notatiile
folosite, starea de dezvoltare a metodelor si dimensiunile de modelare suportate. În
plus tabelul precizeaza existenta unui utilitar care sa suporte modelarea si/sau
generarea codului, precum si puterea acestor metode.
HDM-lite este succesorul lui HDM si a fost proiectat în vederea automatizarii
procesului de dezvoltare si generarii automate a aplicatiilor web. W2000 deriva tot
din HDM si modeleaza o aplicatie web focalizându-se pe hipertext si pe utilizator.
RMM este o metoda care se bazeaza pe modelul ER si defineste un proces gradat
pentru rafinarea succesiva a modelelor. O alta abordare bazata pe paradigma ER
este Hera, care utilizeaza notatia RMM. WebML este un limbaj de modelare matur si
usor de înteles pentru aplicatii web concentrate pe date care ofera suport pentru
partile esentiale ale modelarii aplicatiilor web. Aceasta metoda foloseste utilitarul
WebRatio pentru a sprijini atât modelarea cât si generarea automata de cod.
Deoarece OOHDM pune accentul pe conceptul de navigare contextuala, aceasta
metoda este recomandata pentru aplicatiile web care utilizeaza diferite optiuni de
navigare. OOHDM a fost extins pentru a suporta personalizarea, modelarea cadrului
de lucru, arhitecturile aplicatiilor web si diagramele pentru a capta scenariile de
interactiune cu utilizatorul. WSDM se focalizeaza pe o abordare metodica orientata
spre cerintele utilizatorului. Pe de alta parte, UWE este o abordare care ofera o
notatie bazata pe UML si o verificare a consistentei modelului bazata pe un meta-
model. OO-H este una dintre metodele mai recente, care îmbina beneficiile WebML,
OOHDM si UWE si foloseste un utilitar numit VisualWADE pentru suportul generarii
codului automat pe baza modelului. OOWS este (asemenea OO-H) o abordare
orientata-obiect bazata partial pe UML dar care utilizeaza propriile notatii. WAE2
este o abordare UML care se focalizeaza pe distribuirea logicii aplicatiei. WebSA este
o abordare pentru modelarea arhitecturilor web.
Dezvoltarea bazata pe modele
Dezvoltarea bazata pe modele (The Model-Driven Development -MDD) nu sprijina
doar utilizarea modelelor pentru dezvoltarea de software ci si necesitatea
transformarilor în toate etapele dezvoltarii (de la specificatiile sistemului pâna la
implementare si testare). Transformarile dintre modele ofera o legatura care
permite implementarea automata a unui sistem în etape succesive pornind de la
diferitele modele definite pentru acesta.
Dezvoltarea aplicatiilor web este un domeniu specific în care MDD poate fi aplicata
cu succes, datorita separarii aspectelor (continut, hipertext, prezentare si

43[43] Conallen, J., Building Web Applications with UML, 2nd edition, Addison-Wesley, 2003
personalizare) specifice web-ului. Metode precum WebML, OO-H si UWE reprezinta
fundamentul abordarii bazate pe modele pentru dezvoltarea aplicatiilor web; ele
includ unele transformari semi-automate bazate pe model.
WebSA (Web Software Architecture) este o alta abordare bazata pe model pentru
domeniul web-ului si foloseste paradigma MDA (Model-DrivenArchitecture).
Asemanator cu MDA, WebSA se focalizeaza pe construirea de modele independente
de platforma si ulterior construirea automata a modelelor specifice platformei.

Utilitare
Datorita ciclurilor de dezvoltare scurte si complexitatii aplicatiilor web este
recomandata utilizarea de instrumente care permit nu doar modelarea ci si
generarea automata a codului si verificarea consistentei modelului. Principalele
utilitare de acest tip sunt: WebRatio Site Development Studio, VisualWADE si
OpenUWE Suite.
WebRatio Site Development Studio
WebRatio Site Development Studio (http://www.webratio.com) este un instrument
de dezvoltare bazat pe modele care construieste folosind Web Modeling Language
(WebML) (http://www.webml.org). Acest utilitar foloseste propriile notatii pentru
modelarea hipertext si suporta notatii ER si UML. Generatorul de cod al
instrumentului utilizeaza XSL pentru a transforma modelele de continut si hipertext
prezentate în XML în bazele de date necesare si conexiuni la baza de date dar si în
componente software si diferite formate de iesire (HTML, WML, PDF, Microsoft
Word). WebRatio foloseste un instrument numit EasyStyle pentru a genera
prezentarea paginilor, care va transforma automat paginile adnotate în foi de stiluri
XSL, fara a solicita alte activitati de programare. Aplicatia web generata cu ajutorul
WebRatio este trimisa apoi în cadrul de lucru bazat pe un set de componente Java
care pot fi configurate prin utilizarea fisierelor XML.
VisualWADE
Instrumentul VisualWADE (http://www.visualwade.com) se bazeaza pe metoda OO-
H. Acest instrument suporta modelarea si generarea automata a aplicatiilor bazate
pe XML, ASP, JSP si PHP. VisualWADE adauga la modelul UML alte doua modele:
"Vizualizarea Navigarii" (utilizata pentru a modela aspectul hipertext al aplicatiei
web) si "Vizualizarea Prezentarii" (reprezinta elementele de interactiune ale
interfetei utilizator cu privire la structura si comportamentul acesteia utilizând
anumite structuri de tip template). Aceasta produce o descriere independenta de
dispozitiv a interfetei utilizator, care poate fi utilizata de generatoare în vederea
obtinerii automate a aplicatiei web pentru medii si dispozitive de rulare distincte.

OpenUWE
Suita de utilitare OpenUWE (http://www.pst.ifi.lmu.de/projekte/uwe) este un mediu
de dezvoltare pentru proiectarea si generarea aplicatiilor web folosind metodologia
 UWE. Principala facilitate a acestei suite este reprezentata de arhitectura deschisa
bazata pe standardele consacrate. Mediul de dezvoltare OpenUWE include
instrumentul CASE ArgoUWE si cadrul de lucru UWEXML care consta într-un motor
de verificare a consistentei modelului, un editor al layout-ului si un generator de cod
pentru cadrul de lucru Cocoon XML Publishing44[44] si JSP.
Instrumentul CASE ArgoUWE se bazeaza pe instrumentul CASE open-source
ArgoUML (http://www. argouml.org), suporta notatia UWE si verifica consistenta
modelelor în functie de constrângerile OCL specificate pentru meta-modelul UWE.
3.8 Concluzii
În ultima decada au fost dezvoltate numeroase metode de modelare a aplicatiilor
web. Este greu de anticipat momentul în care se va ajunge la un limbaj de modelare
web unificat ("Unified Web Modeling Language") similar dezvoltarii UML-ului.
Includerea serviciilor web în dezvoltarea aplicatiilor web bazate pe modele va aduce
noi provocari, cea mai importanta fiind interactiunea dintre modelarea de sus în jos
si de integrarea de jos în sus a serviciilor existente.
IV. Arhitecturile aplicatiilor web
Calitatea aplicatiilor web este influentata semnificativ de arhitectura acestora. Lipsa
aspectelor arhitecturale influenteaza în mod negativ cerintele privind calitatea
aplicatiilor web. Performanta scazuta, întretinerea si extinderea insuficienta si slaba
disponibilitate a unei aplicatii web sunt deseori cauzate de o arhitectura neadecvata.
Pe lânga constrângerile tehnice precum disponibilitatea serverelor web, serverele de
aplicatii utilizate sau integrarea sistemelor de mostenire, arhitecturile aplicatiilor
web trebuie sa ia în considerare si cadrul de lucru organizational în care ele sunt
incluse (de exemplu experienta arhitectilor). Utilizarea unor arhitecturi multi-strat
flexibile, tratarea continutului multimedia si integrarea depozitelor de date existente
sunt stringente pentru dezvoltarea arhitecturii aplicatiilor web. Vom discuta în
continuare proprietatile generale ale arhitecturilor, influenta cunostintelor
arhitecturale existente sub forma sabloanelor si cadrelor de lucru asupra calitatii
aplicatiilor web si arhitecturi reprezentative pentru aplicatii web împreuna cu
componentele necesare construirii acestora.
Când dezvoltam aplicatii web trebuie sa luam în considerare un numar mare de
cerinte si constrângeri, începând cu cerinte functionale (comenzile de produse
online) si cerinte de calitate (performanta si disponibilitatea) si pâna la integrarea
sistemelor software existente (asa numitele sisteme de mostenire sau depozitele de
date existente pe care aplicatiile web ar trebui sa le citeasca). În mod normal,
aplicatiile web nu sunt dezvoltate "din nimic" în ceea ce priveste infrastructura
tehnica; deseori trebuie extinsa sau adaptata o infrastructura existenta. Pe lânga
constrângerile pur tehnice, putem identifica alte aspecte cum ar fi viabilitatea
economica a infrastructurii tehnice.

44[44] Ziegeler, C., Langham, M., Cocoon: Building XML Applications, Sams, July, 2002
 4.1 Generalitati
Definirea arhitecturii
Nu exista o definitie unica a termenului "arhitectura", renumitul institut de
proiectare a software-ului (SEI -Software Engineering Institute) din cadrul
Universitatii Carnegie-Mellon (http://www.sei.cmu.edu) oferind peste 20 de variante
explicative. În loc de a adauga o alta varianta, vom încerca sa descriem principalele
proprietati ale arhitecturilor software:
- arhitectura descrie structura: arhitectura sistemelor software consta în structura
acestora, descompunerea în componente, interfata si relatiile dintre ele45[45].
Arhitectura descrie atât aspectele statice cât si cele dinamice ale sistemului
software, astfel încât este necesara construirea de diagrame de flux pentru un
produs software.
- arhitectura face tranzitia de la analiza la implementare: Când cream arhitectura
încercam sa descompunem cerintele functionale si cele de calitate în componente
software, relatii si interfete într-un mod iterativ. Acest proces este sustinut de mai
multe abordari, cum ar fi Procesul Unificat.
- arhitectura poate fi abordata din diferite puncte de vedere, în functie de care se
pot specifica aspecte arhitecturale distincte. Se remarca urmatoarele puncte de
vedere:
* abordarea conceptuala - identifica identitatile domeniului aplicatiei si relatiile
dintre acestea
* abordarea în functie de momentul rularii - descrie componentele în momentul
rularii sistemului (de exemplu servere sau cai de comunicatie)
* abordarea pe procese - mapeaza procesele în momentul rularii sistemului, avându-
se în vedere aspecte precum sincronizarea si concurenta
* abordarea în functie de implementare - descrie artefactele software-ului si include
subsisteme, componente sau cod sursa.
Aceasta clasificare în functie de diferitele puncte de vedere este de asemenea
sustinuta si de limbajele de modelare (de exemplu UML).
- arhitectura face sistemul mai inteligibil: structurarea sistemelor software si
descompunerea acestora ne permit un management mai bun al complexitatii
sistemelor software, sistemele devenind astfel mai usor de înteles.
- arhitectura reprezinta cadrul de lucru pentru un sistem flexibil: Tom DeMarco se
refera la arhitectura ca la un "cadru al schimbarii" (de exemplu arhitectura software
formeaza cadrul în care un sistem software poate evolua). Daca extinderea unui
sistem nu a fost luata anterior în calcul, atunci aceasta va fi greu de realizat.
Având în vedere proprietatile mentionate, putem afirma ca deciziile arhitecturale au
o importanta majora în dezvoltarea aplicatiilor web.
Dezvoltarea arhitecturilor

45[45] Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison-Wesley, 1998
 Cerintele software-ului si arhitectura acestuia sunt într-o continua schimbare.
Constrângerile tehnice si de organizare se modifica pe parcursul si dupa dezvoltarea
unei aplicatii. Aceasta se poate datora unor cerinte neclare de la începutul
procesului de dezvoltare sau unei schimbari a cerintelor dupa finalizarea sistemului.
Din acest motiv sistemele software sunt deseori numite "tinte în miscare". Figura 4.1
ilustreaza factorii si constrângerile care influenteaza dezvoltarea unei arhitecturi
conform opiniei lui Jacobson46[46].
Figur
a 4.1
Facto
ri
care
influe
nteaz
a
dezvo
ltarea
unei
arhitecturi
Arhitectura unei aplicatii este influentata în principal de cerintele functionale -
serviciile oferite de un sistem- si consideratiile privind calitatea (scalabilitatea sau
performanta). Dincolo de aceste cerinte, arhitecturile sunt influentate de
constrângeri tehnice cum ar fi sistemul software utilizat (de exemplu sistemul de
operare), middleware (de exemplu implementarea CORBA), sistemele de mostenire
care vor fi integrate, standardele utilizate, regulile de dezvoltare (de exemplu ghiduri
de scriere a codului) sau aspectele de distribuire (de exemplu distribuirea în diverse
locatii a unei companii).
Deoarece sistemele software sunt în permanenta schimbare arhitecturile sunt de
obicei dezvoltate într-o maniera iterativa, ceea ce nu garanteaza o arhitectura solida.
O abordare iterativa nu este suficienta pentru rezolvarea problemelor specifice de
proiectare precum integrarea sistemelor de mostenire în dezvoltarea unei
arhitecturi (sabloanele de proiectare sunt foarte eficiente în sprijinirea deciziilor de
proiectare).
sabloane
sabloanele47[47] descriu probleme de proiectare recurente care apar într-un anumit
context si propun solutii la acestea. O solutie descrie componentele participante,

46[46] Jacobson, I., Booch, G., Rumbaugh, J., The Unified Software Development Process, Addison-Wesley, 1999

47[47] Gamma, E., Helm, R., Johnson, R., Design Patterns. Elements of Reusable Object-Oriented Software,

Addison-Wesley, 1997
 responsabilitatile lor, relatia între aceste componente si interactiunea acestor
componente în contextul unei probleme specifice. De aici rezulta ca sabloanele ne
permit reutilizarea cunostintelor de proiectare, sprijinind dezvoltarea sistemelor
software de calitate superioara.
Buschmann48[48] identifica sabloane la trei nivele de abstractizare:
- sabloanele arhitecturale - mapeaza mecanismele de structurare fundamentale
pentru sistemele software. Ele descriu subsistemele arhitecturale, responsabilitatile
acestora, relatiile si interactiunea dintre ele. Un exemplu de astfel de sablon este
sablonul MVC (Model-View-Controller49[49]).
- sabloanele de proiectare -descriu structura, relatiile si interactiunea între
componente pentru a rezolva problemele de proiectare aparute într-un anumit
context si deriva dintr-un limbaj de programare specific.
- dialecte - descriu sabloanele care se refera la o implementare specifica dintr-un
limbaj de programare.
sabloanele sunt disponibile pentru diverse infrastructuri - de exemplu J2EE,
CORBA50[50] si PHP.
Totusi, sabloanele reprezinta doar un ghid pentru o anumita problema. Arhitectii
software trebuie sa adapteze sabloanele la problema si constrângerile respective, sa
integreze si sa îmbunatateasca sabloanele folosite. Pentru a sustine procesul de
integrare, Buschmann recomanda folosirea asa-numitelor limbaje-sablon. Un limbaj-
sablon descrie interconexiunile sabloanelor pe nivele de abstractizare diferite,
sugereaza diferite utilizari pentru sabloane si indica adaptarea necesara pentru a
oferi un sistem solid.
IBM descrie în sabloanele pentru afaceri electronice sabloanele de arhitectura
pentru aplicatiile comerciale si modul în care pot fi mapate pe infrastructura
IBM51[51]. Aceste sabloane de arhitectura sunt perfectionate printr-un lant de
decizii, pornind de la cazurile de utilizare si terminând cu arhitectura tinta.

48[48] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern - Oriented Software
Architecture:

A System of Patterns, John Wiley & Sons, 1996

49[49] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern - Oriented Software
Architecture:

A System of Patterns, John Wiley & Sons, 1996, p.125

50[50] Malveau, R. C., Mowbray, T. J., CORBA Design Patterns, John Wiley & Sons, 1997

51[51] IBM, Patterns for e-business, 2002, http://www-106.ibm.com/developerworks/patterns/, [last visit: 2005-

12-01]
 Cadre de lucru
Cadrele de lucru de lucru reprezinta o alta optiune pentru reutilizarea cunostintelor
arhitecturale existente. Un cadru de lucru este un sistem software reutilizabil cu o
functionalitate generala deja implementata. Cadrul de lucru poate fi întâlnit sub
forma aplicatiilor gata de folosire52[52] si serveste ca o schita pentru arhitectura si
functionalitatile de baza ale unui domeniu specific al aplicatiei. (deci cunostintele
arhitecturale continute în cadrul de lucru pot fi preluate în întregime în aplicatie).
Beneficiile unui cadru de lucru - simpla reutilizare a arhitecturii si functionalitatii-
trebuie puse în balanta alaturi de dezavantajele sale (gradul înalt de instruire
necesara, lipsa standardelor pentru integrarea diferitelor cadre de lucru si
dependenta de producatori).
Clasificarea arhitecturilor
În ultimii ani au fost dezvoltate o serie de arhitecturi pentru rezolvarea cerintelor
specifice din diverse domenii de aplicatii. Anastopoulos si Romberg53[53] descriu
arhitecturile pentru mediul aplicatiilor web în functie de aspectul stratificat al
arhitecturilor sau de aspectul datelor (sustinerea diferitelor date si formate de date):
- aspectul stratificat: se refera la faptul ca sistemele software sunt structurate pe
câteva nivele pentru implementarea principiului "separarea intereselor" în cadrul
unui sistem software. Multe cadre de lucru din domeniul sistemelor distribuite si
aplicatiilor web sunt structurate în principal pe aspectul stratificat (de exemplu
arhitecturile J2EE54[54] utilizate pentru a integra sistemele de mostenire;
portalurile).
- aspectul datelor: datele pot fi structurate sau nestructurate. Datele structurate
urmeaza o schema predefinita asemanator tabelelor din bazele de date relationale
sau structurilor XML dintr-un document. Datele nestructurate sunt elemente
multimedia (imagini, audio, video) care nu respecta o schema explicita, ceea ce face
dificila procesarea lor automata.

52[52] Fayad, M. E., Schmidt, D. C., Johnson, R. E., Building Applications Frameworks: Object Oriented
Foundations

of Framework Design, John Wiley & Sons, 1999

53[53] Anastopoulos, M., Romberg, T., Referenzarchitekturen f¨ur Web-Applikationen, Projekt

Application2Web,

Forschungszentrum Informatik (FZI), December, 2001, http://app2web.fzi.de/, in German, [last visit:

2005-10-15]

54[54] Sun Microsystems (2003), Java2 Platform, Enterprise Edition Specification, v 1.4, November, 2003,

http://java.sun.com/j2ee/j2ee-1 4-fr-spec.pdf, [last visit: 2005-12-07].

Raspândirea din ce în ce mai mare a sistemelor software a condus la dezvoltarea
arhitecturilor si infrastructurilor ce se adreseaza distribuirii datelor si mesajelor:
- DOM (Distributed Object Middleware) - permite accesarea obiectelor de la distanta
în mod transparent si se bazeaza pe mecanismul RPC (Remote Procedure Call)
(exemplu: Microsoft's DCOM (Distributed Component Object Model)
- VSM (Virtual Shared Memory) - permite proceselor distribuite sa acceseze datele
comune (exemplu: Corso http://www.tecco.at)
- MOM (Message Oriented Middleware) - ofera functionalitati pentru transmiterea
asincrona a mesajelor. Comunicarea asincrona difera de cea sincrona prin faptul ca
mesajele sunt trimise destinatarului indiferent de starea acestuia ( de exemplu
destinatarul poate sa nu fie disponibil când mesajul este trimis - este offline).
Exemplu: Microsoft's MSMQ (Microsoft Message Queue).
- P2P (Peer to Peer) - înseamna comunicarea directa între doua dispozitive
(parteneri) într-un sistem fara utilizarea unui server (ei pot comunica printr-o
conexiune de tip punct-la-punct). Exemplu: Xmiddle
(http://xmiddle.sourceforge.net/)
- SOM (Service Oriented Middleware) - îmbunatateste sistemele DOM prin conceptul
de servicii. Un serviciu în acest context reprezinta un numar de obiecte si
comportamentul acestora; aceste obiecte folosesc o interfata predefinita pentru a
face un serviciu disponibil altor sisteme/servicii. Exemplu: sistemul Jini de la Sun
(http://www.sun.com/software/jini/).
Arhitecturile prezentate se pot aplica sistemelor distribuite în general si nu sunt
limitate doar la aplicatiile web.
4.2 Particularitatile arhitecturilor pentru aplicatiile web
Pentru început este necesara realizarea unei distinctii între arhitectura infrastructurii
web (Web Platform Architectures -WPA) si infrastructura aplicatiilor web (Web
Application Architectures - WAA). Deoarece WAA depinde de domeniul problemei
aplicatiei web, vom insista asupra WPA-urilor.
WPA-urile au fost dezvoltate pentru o arie larga de probleme. Serverele de aplicatii
precum implementarea J2EE si platforma .NET încearca sa ofere servicii de baza
pentru controlul sesiunilor si accesul la date. În afara serverelor de aplicatii au fost
dezvoltate solutii arhitecturale specifice pentru rezolvarea problemelor de
securitate, performanta si integrare a datelor (firewall-uri, proxy-uri ptr caching si
EAI).
Paradoxal, utilizarea unui numar mare de sisteme diferite face dificila evaluarea si
pastrarea unor cerinte de calitate distincte. De exemplu, îndeplinirea cerintelor de
performanta devine din ce în ce mai dificila datorita numarului din ce în ce mai mare
de componente si produse utilizate de la terti (comerciale sau gratuite).
Alte probleme în dezvoltarea aplicatiilor web sunt neomogenitatea si imaturitatea
infrastructurilor tehnice. În acest sens mentionam problemele care apar în analiza
performantei pentru serverele de aplicatii în situatia unor update-uri frecvente; un
astfel de studiu releva ca versiunile noi de produse sunt mai lente fata de cele
anterioare si noile funtionalitati determina incompatibilitati în codul aplicatiei
existente. Indiferent de problemele de neomogenitate si imaturitate, aplicatiile web
actuale utilizeaza un numar ridicat de infrastructuri tehnice pentru rezolvarea
anumitor probleme: cadre de lucru open-source (Struts
(http://jakarta.apache.org/struts/ si Cocoon (http://xml.apache.org/cocoon/),
servere de aplicatii (de exemplu implementarea EJB) si JetSpeed
(http://jakarta.apache.org/jetspeed/).
Un alt aspect important pentru arhitectura aplicatiilor web este internationalizarea
aplicatiilor web, care solicita suport pentru limbi diferite, seturi de caractere si
mecanisme de reprezentare (reprezentarea caracterelor arabice de la dreapta la
stânga) la nivelul WPA. Aceste aspecte sunt oferite si de limbajele de programare
sau sistemele de operare (exemplu platforma PHP ofera un mecanism de
internationalizare pentru codificarea seturilor de caractere diferite (exemplu ISO-
8859-2, UTF-8) realizata si cu ajutorul programului Gettext.
4.3 Componentele arhitecturii aplicatiilor web
În Figura 4.2 sunt reprezentate componentele de baza ale arhitecturilor web si
relatiile dintre ele. Comunicarea dintre aceste componente se bazeaza în general pe
principiul cerere-raspuns ( o componenta - un browser web trimite o cerere catre o
alta componenta - serverul web si raspunsul la aceasta cerere este trimis înapoi pe
acelasi canal de comunicare - comunicare sincrona).

Figura 4.2 Componentele de baza ale arhitecturilor unei aplicatii web

Componentele frecvent implicate în comunicare sunt:
- client: în general un browser (agent utilizator) este controlat de catre un utilizator
care foloseste aplicatia web. Functionalitatea clientului poate fi extinsa prin
instalarea plug-in-urilor si applet-urilor.
- firewall: un software care reglementeaza comunicarea între retele nesecurizate
(exemplu Internet) si securizate (exemplu retele locale ale unei companii). Aceasta
comunicare este filtrata prin reguli de acces.
- proxy: un proxy este utilizat pentru a stoca paginile web într-un cache, pentru a
adapta continutul pentru utilizatori (personalizare) sau pentru a urmari utilizatorii.
- server web: un software care suporta diferite protocoale web (exemplu HTTP si
HTTPS) pentru a procesa cererile clientului.
- server de baze de date: prezinta datele organizatiei într-o forma structurata
(exemplu: în tabele)
- server media: este utilizat pentru streamingul continutului pentru datele
nestructurate (exemplu: audio sau video)
- server pentru managementul continutului: pastreaza continutul aferent unei
aplicatii, care este disponibil sub forma datelor semistructurate (exemplu:
documente XML)
- server de aplicatii: pastreaza functionalitatea necesara diverselor aplicatii
(exemplu: fluxul de date sau personalizarea)
- aplicatii mostenite: un sistem mai vechi care trebuie integrat ca o componenta
interna sau externa.
4.4 Arhitecturile stratificate
Arhitecturi pe doua straturi
Arhitectura pe doua straturi, numita si arhitectura client-server, utilizeaza un server
web pentru a oferi servicii unui client (vezi figura 4.3).
Figura 4.3
Arhitectura
pe doua
straturi
pentru
aplicatiile
web
Arhitectura
pe doua
straturi
poate lua forme diferite în mediul aplicatiilor web. O cerere a unui client poate
puncta direct catre o pagina HTML statica, fara o solicita un rationament de
procesare pe stratul server sau poate accesa o baza de date prin intermediul logicii
aplicatiei pe serverul web (de exemplu sub forma scripturilor CGI). Paginile HTML
dinamice includ instructiuni de tip script direct în codul HTML (de exemplu când este
utilizat SSI - Server-Side Include sau PHP) si ele sunt interpretate fie de bazele de
date cu functionalitati HTML fie de un server web. Logica aplicatiei sau paginile
HTML dinamice pot utiliza servicii (exemplu identificarea utilizatorilor sau criptarea
datelor) când este generat un raspuns HTML. Aceasta arhitectura este adecvata
aplicatiilor web simple.
O abordare arhitecturala multi-stratificata este necesara pentru aplicatiile mai
complexe care sunt accesate de un numar mare de clienti concurenti sau care ofera
procese de afaceri complexe ce necesita accesarea sistemele de mostenire.
Arhitecturi pe N straturi
Arhitecturile pe N straturi permit organizarea aplicatiilor web pe un numar arbitrar
de nivele (vezi figura 4.4). Acestea constau de obicei în trei straturi: stratul datelor,
care ofera acces la datele aplicatiei, stratul afacerii - care gazduieste logica de afaceri
a aplicatiei într-un server de aplicatii si stratul prezentare - care returneaza rezultatul
cererii în formatul de iesire dorit. În plus, mecanisme de securitate cum ar fi firewall-
urile sau mecanismele de caching (proxy) pot fi integrate în fluxul cerere-raspuns.

Figura 4.4 O arhitectura pe N straturi pentru aplicatiile web

Arhitecturile pe doua straturi si N straturi difera în principal prin modul în care
încorporeaza serviciile în componenta server a aplicatiei. Servicii precum
personalizarea sau fluxul de date sunt pastrate în serverul aplicatiei, astfel încât sa
fie disponibile pentru toate aplicatiile web.
Serviciile sunt încorporate în serverele de aplicatii cu o interfata definita, care poate
fi utilizata si pentru a administra aceste servicii. Un exemplu pentru aceste
functionalitati este serverul de aplicatii WebSphere, împreuna cu componentele
afacerii WebSphere.
 Conectorii pot fi utilizati pentru a integra sistemele externe (sisteme partener
de afaceri) sau pentru a integra aplicatii de mostenire si sisteme informationale ale
companiilor.
Majoritatea serverelor de aplicatii comerciale au fost optimizate pentru procesarea
continutului bazelor de date, suportul pentru continutul multimedia si structurile
hipertext fiind neglijat. Un exemplu de integrare a datelor video într-un server de
aplicatii este disponibil la
http://www.ibm.com/software/data/informix/blades/video/.
JSP-Model-2
Arhitectura JSP-Model-2 (Java Server Pages) de la Sun Microsystems
(http://java.sun.com/developer/technicalArticles/javaserverpages/servlets jsp/)
implementeaza sablonul MVC pentru aplicatiile web, punând astfel bazele pentru
integrarea aspectelor de navigare, internationalizare si distribuire multi-platforma în
aplicatiile web (vezi figura 4.5)

Figura 4.5 Arhitectura JSP-Model-2

Arhitectura JSP-Model-2 este inclusa într-un server web - view-uri, controller-e si
parti ale functionalitatii modelului acestui sablon sunt disponibile într-o extensie a
serverului web (un container servlet). Controller-ul (logica fluxului si controlului
aplicatiei web) este implementa sub forma servlet-urilor - componente software
care ruleaza într-un container servlet. Controller-ul este responsabil de oferirea
accesului la logica aplicatiei (model) si selectarea prezentarii grafice (view).
JavaBeans - componentele software ce reprezinta datele aplicatiei - sunt folosite
pentru a implementa modelul. Modelul acceseaza sisteme backend precum o baza
de date sau o aplicatie de mostenire. Prezentarea grafica este realizata prin JSP.
Struts
Arhitectura JSP-Model-e este îmbunatatita prin proiectul open-source Struts de la
Apache Software Foundation (http://struts.apache.org/). Struts îmbunatateste
aplicatiile web adaugând facilitati precum tratarea erorilor si internationalizarea. În
plus, Struts utilizeaza un fisier de configurare XML care permite controlul fluxului de
procesare din sablonul MVC pentru a facilita procesarea cererilor clientului.
Figura 4.6 arata modul în care cadrul de lucru Struts proceseaza cererea unui
utilizator: în faza initiala fiecare cerere a utilizatorului (1) este receptionata de un
ActionServlet central. Acest servlet citeste URI-ul cererii pentru a gasi controller-ul
(Action); cererea este trimisa mai de parte catre (2) - logica aplicatiei care trebuie
executata pentru aceasta cerere. Controller-ul este responsabil pentru selectarea
sau crearea modelului sub forma unui JavaBean ce poate fi reprezentat într-un view
(3). Pe baza modelului selectat si a altor informatii (informatii despre utilizator,
agentul utilizator) ActionServlet poate selecta un view pentru a reprezenta
continutul (4). În cele din urma view-ul selectat genereaza rezultatul, care este trimis
utilizatorului (5). Spre deosebire de JSP-Model-2 original, Struts permite
configurarea view-ului si modelului în fisierul struts-config.xml; astfel continutul
poate fi prezentat într-un mod mai flexibil în vederea adaptarii sau distribuirii multi-
platforma.

Figura 4.6 Implementarea arhitecturii JSP-Model-2 în Struts

OOHDM-Java2
Abordarea OOHDM-Java2 descrie modul în care modelul de navigare OOHDM este
mapat pe platforma J2EE. Implementarea acestuia se bazeaza pe sablonul MVC.
Figura 4.7 ilustreaza modul în care componentele OOHDM-Java2 sunt mapate în
sabloane MVC. Spre deosebire de JSP-Model-2 si Struts, aceasta abordare prezinta o
componenta de navigare într-un mod explicit.
Figu
ra
4.7
Com
pon
ente
le
OO
HD
M-
Java
2
 În aceasta figura secventa de executie este indicata de marginile numerotate: (1) o
cerere HTTP este trimisa catre parserul de cerere HTTP, care trimite mai departe un
mesaj Dispatcher-ului.(2) Similar cu Struts, acest parser ruleaza obiectele aplicatiei
alocate (3). Ulterior, obiectul aplicatiei selectate sau o alta informatie (exemplu
agentul utilizator) este utilizat pentru a identifica interfata utilizatorului (4). În
continuare, la interfata utilizator se adauga elementele de navigare (5). În final
rezultatul este plasat într-un layout adecvat si transmis clientului.
Proxy-uri
Initial proxy-urile erau folosite pentru a salva latimea de banda, din acest motiv fiind
numite si proxy-uri de caching55[55]. Proxy-urile sunt capabile sa îndeplineasca si
alte functii:
- proxy-uri de legaturi: sunt de cel putin doua tipuri. În primul rând, sistemele de
tipul URL-urilor persistente (PURLs- Persistent URLs56[56]) utilizeaza componente de
tip proxy. Mai exact, un proxy este utilizat ca un server intermediar pentru a trimite
cererile de URL-uri ale clientului catre serverul real. Daca numele sau locatia resursei
solicitate se schimba, este necesara doar schimbarea adresei URL interne (clientul nu
trebuie sa stie acest lucru). O astfel de schimbare necesita un tabel de mapare între
URL-ul solicitat si cel "real", acesta fiind gestionat de catre proxy. În al doilea rând,
proxy-urile sunt utilizate pentru a adapta si formata legaturile si continutul pentru
utilizatori. O metoda implicata în acest concept este inserarea dinamica a legaturilor
care se potrivesc intereselor unui utilizator, prin aceasta paginile HTML fiind
analizate de proxy si modificate pentru a se potrivi profilului utilizatorului.
Utilizatorul va fi informat în privinta schimbarii resursei transmise la sfârsitul
documentului.
- proxy-uri de istoric: multe aplicatii web încearca sa-si adapteze functionalitatile
cerintelor utilizatorilor. Problema care apare este ca HTTP-ul este un protocol
simplu, care nu ofera informatii despre istoricul navigarii unui utilizator pe mai multe
situri. De exemplu, daca un utilizator planifica o vacanta si rezerva un zbor, un hotel
si închiriaza o masina pe internet, atunci vânzatorul de bilet de avion nu stie ca
utilizatorul a rezervat o camera la un hotel si a închiriat o masina. Daca compania de
zbor ar cunoaste aceste informatii, atunci camera de hotel rezervata si masina
închiriata ar putea fi anulate daca utilizatorul contramandeaza zborul. O problema
similara apare si în domeniul marketingului direct, în care, cu cât se cunosc mai
multe detalii despre interesele utilizatorului, cu atât va fi mai mare efortul pentru

55[55] Bongio, A., Brambilla, M., Ceri, S., Comai, S., Fraternali, P., Matera, M., Designing Data-Intensive Web

Applications, Morgan Kaufmann, 2003

56[56] Weibel, S., Jul, E., Shafer, K., PURLs: Persistent Uniform Resource Locators, Online Computer Library

Center (OCLC), 1999, http://purl.oclc.org/OCLC/PURL/SUMMARY, [last visit: 2005-12-05]

publicitatea orientata pe consumator. Proxy-urile pot fi utilizate pentru a administra
istoricul paginilor vizitate de utilizator, prin atribuirea unui ID unic pentru un
utilizator si stocarea acestui ID utilizând tehnologia cookie. În aceasta situatie, daca
utilizatorul viziteaza situl web al unei alte companii conectate la acelasi proxy, atunci
informatiile despre acest utilizator pot fi extrase, permitând identificarea unui
utilizator unic. Serverul Boomerang de pe DoubleClick (http://www.doubleclick.com)
utilizeaza acest concept pentru marketingul direct.
Arhitecturi integrate
Sistemele interne sau externe - aplicatiile existente, baze de date existente si
interfete catre parteneri de afaceri externi- pot fi integrate în aplicatiile web pe trei
nivele: nivelul prezentare, nivelul logic al aplicatiei si nivelul continutului. Arhitecturi
integrate se refera la aspectul de integrare de pe nivelul continut si de pe cel logic al
aplicatiei si sunt cunoscute sub numele de arhitecturi EAI (Enterprise Application
Integration). În esenta, EAI se focalizeaza pe integrarea sistemelor de mostenire. O
alternativa la EAI sunt serviciile web care ofera integrarea serviciilor (logica aplicatiei
si continutul). La nivel de prezentare, un set de sisteme diferite sunt integrate tipic
prin utilizarea arhitecturilor portal.
Portalurile reprezinta cele mai recente dezvoltari ale aplicatiilor web multi-
stratificate. Cu ajutorul portalurilor continutul, care este distribuit pe mai multe
noduri ale diversilor furnizori de servicii, va fi disponibil dintr-un singur nod, oferind
un aspect consistent. În figura 4.9 este schematizata arhitectura de baza a unui
server portal. Serverele portal se bazeaza pe portlet-uri, care aranjeaza continutul si
logica aplicatiei într-o structura de navigare si un layout adecvate portalului. Un
exemplu de server portal este proiectul open-source JetSpeed
(http://portals.apache.org/).

Figura 4.9 Exemplu de arhitectura a unei aplicatii web orientata pe portal

4.5 Arhitecturi în functie de aspectul datelor
Datele pot fi grupate în una din urmatoarele categorii arhitecturale: (1) date
structurate de tipul celor aflate în bazele de date; (2) documente de tipul celor
utilizate în sistemele de management al documentelor; (3) date multimedia de tipul
celor incluse pe serverele media. Aplicatiile web nu sunt limitate la una din aceste
categorii de date, ele integreaza documente, media si baze de date.
Arhitecturi axate pe baze de date
Sunt disponibile numeroase utilitare si abordari pentru integrarea bazelor de date în
aplicatiile web. Aceste baze de date sunt accesate fie direct prin intermediul
extensiilor serverului web (în cazul arhitecturilor pe doua straturi) fie prin serverele
de aplicatii (în cazul arhitecturilor pe N straturi). Pentru accesul la bazele de date
relationale sunt disponibile interfete (APIs) pentru diferite platforme (Java Database
Connectivity (JDBC) pentru aplicatii bazate pe Java sau Open Database Connectivity
(ODBC) pentru tehnologii Microsoft).
Arhitecturi pentru managementul documentelor web
Pe lânga datele structurate din bazele de date si cele multimedia de pe serverele
media, continutul aplicatiilor web este frecvent procesat sub forma documentelor.
Arhitecturile de management al continutului ofera posibilitatea integrarii
documentelor din surse diferite, reprezentând un mecanism pentru integrarea
acestora în aplicatiile web.
Figura 4.10 reprezinta componentele unei arhitecturi de management a
continutului. Un server web receptioneaza o cerere de la client si o trimite mai
departe serverului de furnizare a continutului. Daca continutul solicitat nu este în
cache atunci cererea este trimisa mai departe serverului de management al
continutului. Continutul poate fi disponibil direct pe server (în forma statica ca un
document sau într-o baza de date) sau poate fi accesat extern. În functie de tipul de
integrare continutul extern poate fi extras fie prin accesarea bazelor de date externe
(direct sau prin utilizarea unui serviciu de agregare) sau dintr-un serviciu sindicat.
Spre deosebire de accesarea unei baze de date, serviciile sindicat pot avea si functii
suplimentare (exemplu facturarea automata a drepturilor de licenta).
Fig
ura
4.1
0
Arh
itec
tur
a
de
ma
nag
em
ent
a
con
tinutului pentru aplicatiile web
Arhitecturi pentru datele multimedia
Capacitatea de a manipula un volum mare de date are un rol important în
proiectarea sistemelor care utilizeaza continut multimedia. Desi volumul de date nu
este important în arhitecturile web axate pe baze de date, acesta influenteaza
considerabil arhitectura si proiectarea aplicatiilor web multimedia.
Datele multimedia - audio si video- pot fi transmise prin intermediul protocoalelor
internet standard (HTTP sau FTP), asemenea celorlalte date utilizate în aplicatiile
web. Aceasta abordare este utilizata de un numar mare de aplicatii web deoarece
prezinta avantajul ca nu necesita componente suplimentare pe server; dezavantajul
este ca descarcarile de fisiere multimedia sunt foarte lente.
Se pot utiliza tehnologii streaming pentru a minimiza perioada de asteptare pentru
redarea continutului multimedia; prin streaming un client reda un fisier audio si/sau
video la câteva secunde dupa ce începe receptionarea acestuia de pe server. Aceasta
tehnica evita descarcarea întregului fisier înainte de a începe redarea lui. Continutul
trebuie transmis în timp real, ceea ce necesita o latime de banda corespunzatoare
(garantarea latimii de banda a transmisiei este numita calitatea serviciului - quality
of service).
În general sunt folosite doua protocoale pentru streaming-ul de continut
multimedia: un protocol preia transmisia datelor multimedia la nivelul retea, iar
celalalt controleaza fluxul prezentarii (exemplu pornirea si oprirea unui clip video) si
transmisia meta-datelor. Un exemplu de protocol de retea este RTP (Real Time
Protocol) care coopereaza cu un protocol de control numit RTSP (Real Time
Streaming Protocol).
Exista doua domenii distincte de aplicatii pentru streaming-ul datelor multimedia:
primul face disponibil la cerere continutul existent (video la cerere) iar al doilea
distribuie live continutul unui numar mare de utilizatori (exemplu web casting).
Fiecare din aceste doua cazuri de utilizare formuleaza cereri diferite la nivelul retelei
si arhitecturilor hardware si software. Desi fiecare utilizator stabileste propria sa
conexiune la server într-un scenariu la cerere (vezi figura 4.12) cauzând probleme
majore ale latimii de banda si încarcarii serverului, broadcasting-ul realizeaza cereri
sporite la nivelul retelei. În mod ideal, un server utilizat pentru broadcasting sa
administreze un singur stream media, care este difuzat simultan catre toti utilizatorii
de catre infrastructura retelei (exemplu de router-e) ca în figura 4.13. Deoarece
multicasting-ul nu este suportat în general în internet, serverul trebuie sa foloseasca
conexiuni punct-la-punct pentru a simula functionalitatea broadcast.
 Figura 4.12
Arhitectura media
de streaming care
utilizeaza conexiuni
punct-la-punct

Figura 4.13
Arhitectura media
de streaming care

utilizeaza o
infrastructura
broadcasting
4.6 Concluzii
The development
of Web
applications is
driven by the
technical
development of
(new) client
devices and emerging server infrastructures. The trend towards ubiquitous and
portal-oriented
applications will undoubtedly continue in view of the emergence of continually more
powerful
client hardware. Portal-oriented Web applications will be supported by
developments toward
service architectures and Web services.
This trend has also led to the emergence of a number of new infrastructure
approaches, e.g.,
peer-to-peer infrastructures, which will have a major influence on the development
of ubiquitous
Web applications. On the other hand, the bandwidth of server infrastructures used
for Web
applications has also been growing continually.
V Proiectarea aplicatiilor web pe baza tehnologiei
Web-ul a aparut ca un sistem hipertext extrem de simplu care sustine conceptul de
legaturi globale. XML a fost prima tehnologie care a facut posibila dezvoltarea
sistemelor hipertext, desi nu este folosita la scara larga. Ulterior, web-ul s-a focalizat
pe conexiuni la baze de date, aceasta implicând proiectarea informatiei, fiind
utilizata partial în proiectarea aplicatiilor web. Integrarea modulelor software
extinse pe partea clientului si serverelor (care au implicat tehnici de proiectare
software orientate obiect) are o importanta deosebita pentru web.
Dezvoltatorii aplicatiilor web ar trebui sa descompuna aplicatiile web pe trei straturi
logice care la rândul lor se împart în doua jumatati pe baza aceluiasi principiu. Este
necesara realizarea unei distinctii între componente (nodurile aplicatiei web: media,
componente software si conexiunile la baza de date) si aranjarea lor într-o retea. Se
identifica urmatoarele trei straturi:
(1) proiectarea prezentarii - în care proiectam aspectul, un rol important având
interfetele utilizator multi-formale
(2) proiectarea interactiunilor - în care se proiecteaza navigarea prin utilizarea
retelelor si casetele de dialog specifice prin utilizarea componentelor
(3) proiectarea functionala - reprezinta inima aplicatiei web. (vezi figura 5.1)
Pe masura ce proiectarea devine mai concreta pe fiecare nivel si pentru ambele parti
(noduri, retea) ne vom concentra asupra utilitarelor pentru proiectarea hipertext-
ului, informatiei si software-ului.
P P P P
r r r r
e e e o
z z z i
e e e e
n n n c
t t t t
a a a a
r r r n
e e e t
a a i

s c m
i o e
t n d
u t i
a i a
t n I
i u n
e t g
i u i
l n
d u e
e i r
 Interactiune

Functie

Figura 5.1 Elemente de baza ale documentelor hipertext

În capitolul de modelare a aplicatiilor web ne-am concentrat asupra celor trei
straturi (prezentare, hipertext si informatie) punând accentul pe aspectul datelor. În
acest capitol vom insista asupra "stratului inferior" al aplicatiilor web, abordându-l
din punct de vedere tehnic (functie din figura 5.1). Desi complexitatea creste,
aceasta are beneficiul ca aspectele modularizarii si proiectarii pot fi aplicate pentru
toate straturile. Astfel, vom scinda aspectul hipertext în doua (retea si componente)
si le vom aranja pe cele trei straturi. Modelarea prezentarii din capitolul de modelare
este si ea împartita în doua:
- partea "pura" de prezentare, care se focalizeaza pe medierea continutului (media,
continut, posibilitati de interactiune) si devine mai complexa daca sunt luate în
considerare aspectele multi-formale
- partea de interactiune, care datorita unei proiectari sistematice ne permite o
modelare mai eficienta. În concluzie, în acest capitol vom extinde tehnicile de
modelare pentru aplicatii web mai complexe, din perspectiva tehnologiilor.
Initial, World Wide Web-ul a fost caracterizat prin pagini HTML axate pe document si
bazate pe text, pentru care termenul de "aplicatie web" parea exagerat. Limbajul de
descriere a unui document HTML îsi are originea în domeniul presei si editorialelor si
promoveaza crearea de documente mari, structurate, care sunt îmbunatatite prin
legaturi. Secretul succesului a constat în integrarea totala a legaturilor globale (URL-
uri). Trecerea catre "adevaratele" aplicatii web, împreuna cu dezvoltarea limbajelor
de scripting (exemplu JavaScript pe partea de browser) si a interfetelor (exemplu CGI
pe partea de server) au permis interactivitatea, accesul la bazele de date si crearea
de documente HTML dinamice. Pentru a reflecta numarul mare de aspecte diferite
ale proiectarii aplicatiilor web, vom utiliza în continuare subsarcini de proiectare ale
aplicatiilor web, dupa cum este schitat în figura 5.1. Vom face diferenta între
componentele aplicatiilor web (nodurile si legaturile dintre acestea, punctule de
pornire si destinatie din interiorul nodurilor - "ancorele") si reteaua alcatuita din
astfel de componente (întreaga aplicatie web).
Pe lânga cele doua parti ale structurii mentionate anterior, figura 5.1 prezinta un al
treilea strat prin care se face o clara diferentiere între prezentare si interactiune,
similara conceptului MVC (Model-View-Controller). Pe de alta parte, prezentarea
afecteaza reteaua, luând în considerare nodul curent vizitat de un utilizator.
Prezentarea componentelor, adica continutul nodului, este o sarcina de proiectare
esentiala, punându-se accentul pe caracteristicile relevante ale aplicatiilor web - în
special cele referitoare la continut si caracteristicile referitoare la prezentare cum ar
fi estetica si autoexplicarea. De aici rezulta importanta implicarii expertilor (numiti
proiectanti media în acest context) si punerea de acord a acestora cu alti
dezvoltatori ai aplicatiei web (numiti ingineri în acest context).
Separarea retelelor de componente se continua pe nivelul de interactiune.
Interactiunea cu reteaua este cunoscuta sub numele de navigare si aceasta poate fi
exploratorie, asa cum o sugereaza si termenul browsing. Utilizatorul urmareste
legaturile care i se par interesante pe parcursul citirii paginilor si se deplaseaza peste
retea într-un mod aparent aleatoriu. Navigarea poate fi controlata prin intermediul
unui software sofisticat care adapteaza optiunile selectiei în fiecare situatie de
navigare (exemplu sub forma schimbarii dinamice a barei de navigare).
Delimitarea pe orizontala (prezentare/interactiune) si pe verticala
(retele/componente) din figura 5.1 este justificata. Retelele nu erau deloc
reprezentate în etapa web-ului bazat pe HTML, fiind oferita doar navigarea în
interiorul retelei (prin clic pe legaturi sau utilizând butoanele forward/back din
browser). Prezentarea componentelor ( documentele HTML interpretate de
browser) a fost luata în serios din momentul în care a fost introdus primul browser
grafic, iar dialogul cu o componenta a fost posibil doar din momentul introducerii
formularelor în HTML.
În figura 5.1 un strat suplimentar cunoscut sub numele de proiectare functionala a
fost referit prin termenul "functie", pentru a include toate stadiile dezvoltarii web.
Stadiul initial axat pe documente a fost caracterizat în principal prin continut static,
respectiv continut sub forma componentelor specificate de autori; astfel acele
functii erau doar apeluri ale prezentarii sau functii de playback pentru media, acest
strat fiind practic gol. Datorita posibilitatii de a accesa bazele de date, aplicatiile web
au fost tot mai mult influentate de principiile sistemelor informationale clasice si
bazelor de date, astfel proiectarea partii functionale reducându-se la proiectarea
informatiei. Împreuna cu tranzitia la categoriile de aplicatii web recente (bazate pe
fluxuri de date, colaborative, portaluri, omniprezente), componentele cu
functionalitati extinse au ajuns în prim plan. Abordarile orientate-obiect au fost cele
mai indicate pentru modelarea integrala a aspectelor functionale si ale datelor.
5.1 Proiectarea web dintr-o perspectiva evolutiva
Caracteristica centrala a aplicatiilor web este axarea pe document insistându-
se pe usurinta în citire a informatie de catre oameni (continutul este regele). Initial
Tim Berners-Lee a dorit sa dezvolte web-ul ca un simplu sistem hipertext global,
focalizându-se în principal pe informatia textuala.
Proiectarea informatiei: o activitate de authoring
Trebuie facuta o separare între epoca dinaintea web-ului, epoca HTML de la aparitia
web-ului pâna în 1997 si epoca XML actuala (W3C 1998). Începutul erei HTML a fost
focalizat exclusiv pe authoring, fiind suportate doar documentele hipertext
(folosindu-se asa-numitul limbaj de programare web HTML care continea instructiuni
sau etichete presarate în documentele text). Pe parcurs HTML a suportat si alte
elemente media cum ar fi imaginile, elementele video si audio reflectate prin
termenul hipermedia, care este utilizat uneori pentru a deosebi HTML-ul de
hipertext si uneori devenind sinonim cu hipertextul.
Conceptul hipertext este mai vechi decât HTML, el fiind definit prima oara de catre
Vannevar Bush la sfârsitul celui de-al doilea razboi mondial si tratat ulterior de Ted
Nelson în 1960. Documentele hipertext sunt alcatuite din:
- noduri, legaturi si ancore si
- retele si alte componente. Retelele desemneaza noduri si legaturi logice, fiind
numite documente hipertext în epoca dinaintea web-ului. Dintre componente
mentionam view-uri (pentru cititorii experti), cai (secvente de citire predeterminate)
si meta-noduri (retele care pot fi incluse în alte retele, asemenea unui nod). Epoca
HTML nu oferea suport pentru acestea, dar semnificatia lor a crescut odata cu
aparitia conceptelor de modularizare (exemplu structuri de navigare cum ar fi
navigarea în forma de stea).
Popularitatea web-ului a fost posibila datorita simplitatii si disponibilitatii globale
gratuite a HTML-ului. Principalele puncte slabe ale HTML-ului care sunt relevante din
perspectiva proiectarii sunt:
- HTML-ul poate fi vazut ca un limbaj de descriere a documentelor care are
grefate etichete hipertext. Acesta determina indivizii sa neglijeze principiul
atomicitatii nodurilor; majoritatea documentelor HTML (de fapt nodurile) se întind
pe multiple pagini iar ideea de baza a hipertextului (citirea non-secventiala) este
prezenta doar rudimentar sau în cazuri exceptionale.
- HTML mixeaza aspectele ortogonale precum structura hipertext (via etichete
pentru legaturi si ancore), structura documentului (titluri, liste) si layout-ul (culoare
de fundal, scris cursiv).
- desi web-ul recunoaste arhitectura software-ului distribuit prin browser si
servere, prezinta lacune în privinta arhitecturilor software "orizontale" ale masinilor
abstracte. Un exemplu include arhitectura clasica Dexter, care separa continutul si
managementul retelei de prezentare.
- HTML-ul este axat pe text. Celelalte formate media sunt incluse doar ca
destinatii ale legaturii, iar multe alte tipuri media nu sunt suportate ca surse ale
legaturii.
- evolutia web-ului a crescut importanta primului neajuns mentionat anterior.
Suportul pentru structurarea si formatarea în interiorul nodurilor a fost îmbunatatit,
în timp ce aspecte hipertext importante (exemplu noduri definite de utilizatori si
tipuri de legaturi) lipsesc.
Pentru o mai buna întelegere a aspectului de authoring din XML ne vom îndrepta
atentia spre originea HTML-ului; acesta îsi are originea în SGML - un limbaj de
marcare generic standardizat pentru lumea tipografiilor si companiilor editoriale.
"Generalizat" semnifica faptul ca SGML defineste etichete si reguli valide care pot fi
utilizate pentru o întreaga clasa de documente. Rezultatele sunt DTD-urile
(document type definitions). Un parser SGML poate citi DTD-uri si verifica
documente pentru a vedea daca ele corespund sau nu cu un DTD. Companiile
editoriale utilizeaza DTD-urile pentru a face distinctie între carti, reviste si formate
de brosuri. Initial HTML nu a fost decât un SGML-DTD pentru formatul ecran, extins
prin etichete pentru legaturi si ancore. Browserele din epoca HTML nu sunt parsere
SGML dar dispun de suport pentru câteva DTD-uri (versiunile HTML suportate) si
includ modul de interpretare a etichetelor si traducerea comenzilor. "Afisarea" este
de asemenea inclusa, introducerea CSS-ului oferind posibilitatea reutilizarii layout-
urilor si o modalitate de separare a layout-ului de structura.
Epoca XML a disparut când PC-urile au putut sa "digere" parserele SGML. Un numar
mare de "limbaje de programare simple" definite ca XML-DTD-uri (recent denumite
scheme XML) au fost create si includ în prezent un limbaj pentru descrierea
apelurilor de proceduri la distanta (SOAP), un limbaj de descriere a tranzactiilor
financiare (XML-EDI), o replica la HTML (XHTML) si altele. Deoarece XML a permis
descrierea formala a sintaxei, browserele moderne pot parsa arbitrar schema si
documentele XML, dar pot executa doar XHTML.
Putem identifica câteva reguli de baza pentru proiectarea aplicatiilor web bazate pe
documente - din perspectiva authoring-ului:
- Retelele trebuie sa formeze centrul proiectarii informatiei.
- Documentele conventionale trebuie descompuse în noduri atomice.
- Aspectele precum layout-ul si continutul nodul si reteaua trebuie delimitate
conceptual, chiar daca o tehnologie nu suporta o astfel de separare.
- Tehnologia selectata trebuie sa suporte concepte avansate (exemplu
managementul central al legaturilor util în proiectare, în sistemul de management al
continutului si în intraneturi).
Proiectarea software-ului: o activitate de programare
În continuare, vom face o distinctie din perpsectiva istorica între dezvoltarea
progresiva a "web-ului programabil" si dezvoltarea programarii distribuite.
Web-ul programabil
Primul pas catre "web-ul dinamic a fost realizat prin intermediul formularelor HTML.
Odata cu introducerea acestora semnificatia limbajelor de script a sporit simtitor, ele
fiind ideale pentru procesarea solicitata de browsere sau servere si usor de folosit.
Scripturile erau în general folosite pentru a crea direct paginile HTML, în functie de
intrarile din formularele HTML. Indiferent de limbajul utilizat pentru crearea noilor
pagini HTML, scriptul sau programul trebuie sa ofere structuri de date predefinite si
operatii capabile sa creeze elementele paginii HTML (antete de diferite nivele,
paragrafe, liste), sa le adauge continut si în final sa le asambleze (sub forma unei
structuri de elemente de tip arbore). Acest lucru se bazeaza pe DOM (Document
Object Model) care a fost vazut de-a lungul timpului ca noi versiuni de HTML si care
este momentan disponibila în limbajele de scripting sau limbajele de programare.
Dezvoltatorii Java au propus introducerea "limbajului pentru web", considerând ca
browserele ar trebui nu doar sa reprezinte HTML, ci sa ruleze Java. Asemenea
documentelor HTML, applet-urile Java au fost proiectate pentru descarcarea de pe
servere, astfel încât în fereastra browser-ului în locul unui document static va apare
o interfata utilizator (un applet). Accentul s-a pus pe aspectul de securitate, pentru a
preveni applet-urile terte sa execute operatii nedorite pe masinile utilizatorilor finali.
În afara de scripturi si applet-uri, browserele pot rula programe specifice pentru
reprezentarea dinamica a prezentarilor multimedia (exemplu cele dezvoltate cu
Macromedia Flash).
Programarea distribuita
Programele distribuite de pe Internet ruleaza direct peste conexiunile TCP,
printr-o comunicare interproces (IPC) care presupune schimbul mesajelor între doua
parti egale. Pentru multimedia, IPC-ul (îmbunatatit de calitatea garantata a
serviciului pentru stream-uri) are o anumita semnificatie, dar a fost înlocuit de RPC
(Remote Procedure Call) împreuna cu arhitecturile client/server din anii 90'.
Urmatorul pas pe scara evolutiei a fost adaptarea RPC-ului al limbajele de
programare orientate-obiect, ceea ce a condus la proliferarea unor tehnologii
precum CORBA si RMI (Remote Method Invocation) de la Java.
Fuziunea dintre proiectarea informatiei si proiectarea software-ului
Proiectarea aplicatiilor web se realizeaza pe baza elementelor (hibrizi obiect-nod) si
legaturi.
Elementele pot fi implementate static sub forma paginilor generate de client
(exemplu JavaScript) sau sub forma paginilor generate de server (ASP, JSP, PHP). În
plus, ele pot fi implementate ca applet-uri, interfete utilizator ale programelor
orientate-obiect distribuite (Java) sau sub forma elementelor media
statice/generate. Utilizatorul distinge în browser doar continut media, formulare sau
interfete utilizator. Elementele pe care utilizatorul le poate selecta, executa clic si
rula sunt legaturile.
Legaturile se numesc URL-uri în HTML sau Xlinks în XML, daca tinta este o informatie
si nu un program, si daca continutul si adresa sunt cunoscute în momentul
implementarii (HTML simplu) sau în momentul prezentarii (HTML dinamic). Din alt
punct de vedere, legaturile reprezinta apeluri la distanta catre scripturi aflate la
distanta (daca informatia trebuie "calculata") sau metode (daca calculele necesare
sunt algoritmice).
Abordarea structurala
Cu riscul de a ne repeta, vom face o distinctie între proiectarea hipertext,
proiectarea informatiei si proiectarea software-ului, necesara pentru metodele si
utilitarele de proiectare, dar si în practica.
Proiectarea prezentarii - are iesiri sub forma sub forma documentelor, media si
datelor (în sensul sistemelor informatice sau în sensul datelor aplicatiei pentru o
componenta software) pe partea de componente. Pe partea sa de retea, proiectarea
trebuie sa se axeze pe vizualizare si pe componentele curent vizitate de un utilizator.
Proiectarea interactiunii - se refera la controlul fluxului unei interactiuni a
utilizatorului cu aplicatia web. Pe partea de retea, termenul navigare este des
folosit, în timp ce termenul dialog este folosit pe partea de componente.
Proiectarea functionala - implica proiectarea componentelor si retelelor, accentul
punându-se pe perspectiva dezvoltatorilor de software. Prin urmare, partea de
componente va fi descrisa ca o proiectare a informatiei, iar pe partea retelei
focalizarea se va face pe amestecul componentelor active în procese ale afacerii si
pe aplicatii web omniprezente.
5.2 Proiectarea prezentarii
În proiectarea prezentarii, proiectantii media definesc aspectul si structura
continutului multimedia prezentat. Pe baza ideii "continutul este regele" HTML-ul
clasic specifica continutul împreuna cu instructiunile de formatare, legaturile si
programele (scripturile). În schimb, proiectarea moderna a prezentarii realizeaza o
separare conceptuala a continutului aplicatiei web de prezentarea acesteia.
Continutul unei aplicatii web rezulta din îmbinarea continutului multimedia
dezvoltat explicit pe partea de componente si continutul definit implicit pe partea de
retea. De aici rezulta ca o buna proiectare a prezentarii ne permite adaptarea
flexibila a prezentarii la diferite cerinte culturale, tehnologice si contextuale.
Multe pagini web, aplicatii web si situri web în întregime sunt restructurate sau
adaptate unui nou design vizual pe parcursul ciclului lor de viata. În dezvoltarea web
clasica sute sî chiar mii de documente HTML trebuiau adaptate manual, iar indivizii
implicati în modificarea documentelor HTML aveau nevoie de cunostinte solide în
acest domeniu. Desi puteau fi folosite anumite utilitare, o parte considerabila a
acestora trebuiau modificate manual (modelarea consistenta a întregului continut
fiind imposibila sau foarte costisitoare).
Instrumentele disponibile pentru crearea aplicatiilor web pot fi grupate în doua
categorii, în functie de modul în care acestea suporta proiectarea prezentarii:
editoare de pagina (conventionale) si sisteme de management a continutului (mai
avansate).
Editoarele de pagina sunt utilizate în general pentru a crea prezente ad-hoc mai mici
pe internet. Principalul lor beneficiu este ca acestea sunt similare cu software-ul
standard si permit utilizatorilor sa lucreze într-un mediu familiar si sa formateze
continutul în mod direct. Dezavantajele principale sunt necesitatea cunoasterii
HTML-ului pentru realizarea anumitor sarcini si lucrul dezvoltatorilor la nivel de
pagina, ceea ce duce la o pierdere a imaginii conceptuale de ansamblu. În plus,
layout-ul, navigarea si interactiunea sunt mixate.
Spre deosebire de editoarele de pagini, sistemele de management al continutului
permit separarea activitatilor editoriale de layout, facilitând întretinerea unei
prezente pe internet. Aceasta înseamna ca structura unei prezentari internet trebuie
mapata. O caracteristica sistemelor de management al continutului este
disponibilitatea instrumentelor speciale pentru diferite roluri de participare (artisti
grafici sau editori), cunostintele HTML nefiind necesare. Un alt beneficiu consta în
faptul ca layout-ul, continutul si navigarea sunt separate, continutul unei singure
unitati de informatie este specificat si fluxul de date poate fi mapat.
Diferentierea realizata mai sus între editoarele de pagina si sistemele de
management al continutului poate crea confuzii, deoarece în versiunile recente
multe editoare de pagina integreaza functii de baza ale sistemului de management al
continutului.
Prezentarea nodurilor si retelelor
Continutul unei pagini web rezulta din combinarea continutului multimedia
dezvoltat explicit de pe partea de componente si continutul definit implicit pe partea
de retea (exemplu optiuni de navigare).
La crearea continutului multimedia dezvoltatorii dispun de un numar mare de
optiuni de proiectare. În ceea ce priveste conceptul dorit de separare a continutului
si prezentarii, optiunile de proiectare sunt deseori concurente. De exemplu,
flexibilitatea de a adapta a continutului la un context al prezentarii se micsoreaza pe
masura ce numarul de optiuni de formatare creste. Astfel, sa presupunem ca
elementele HTML <b> si <strong> au fost specificate pentru formata textul cu aldine.
Formatul <b> se pierde pe dispozitivele care nu suporta prezentari cu aldine
deoarece nu a fost specificat în nici o alternativa. XHTML 2.0 înlocuieste elementul
<b> cu elementul <strong>. Prezentarea acestui element este reglementata în
proiectarea prezentarii, astfel încât poate fi adaptata la capacitatile tehnice ale unui
dispozitiv (exemplu prin utilizarea sublinierii daca aldinele nu sunt suportate).
Desi dezvoltatorul specifica aspectul continutului multimedia pe partea de
componenta, pe partea retelei proiectarea interactiunii si cea functionala determina
un continut neformatat.
Pentru a vedea un exemplu de sarcina implicata în proiectarea navigarii ne vom
îndrepta atentia spre proiectarea prezentarii pentru interfetele de navigare.
Interfetele de navigare ne ajuta sa raspundem la trei întrebari privind navigarea: (1)
"unde sunt?" (2) "unde am fost?" si "(3) unde pot merge?".
La întrebarea "unde sunt?" putem utiliza schema de navigare "farâmitura de pâine"
bazata pe basmul Hansel si Gretel. Într-o interfata utilizator care implica navigarea
prin date sau pagini "farâmitura de pâine" poate fi un mecanism util pentru
reconstituirea pasilor, lasând o urma vizuala a caii urmate. În orice punct utilizatorul
poate reconstitui pasii parcursi catre orice punct vizitat anterior.
Raspunsul la întrebarea "unde am fost?" nu este usor de gasit, deoarece HTTP este
un protocol care nu indica starea si tehnicile folosite pentru legaturi sunt
rudimentare. Butonul "Back" si lista paginilor vizitate anterior sunt cel mai des
folosite în browsere. Urmatorul exemplu demonstreaza necesitatea unei coordonari
între proiectarea prezentarii si a interactiunii. De exemplu, când achizitioneaza
articole de pe web, utilizatorul nu poate folosi butonul "Back" pentru a anula o
comanda, iar confuzia generata printre utilizatori poate fi evitata doar în câteva
aplicatii web bine proiectate. Un alt exemplu este consistenta, a carei prezenta este
ideala pe întregul web. Prezentari diferite ale legaturilor vizitate anterior si ale
legaturilor nevizitate reprezinta un concept des întâlnit în proiectarea prezentarii.
Jakob Nielsen recomanda mentinerea culorilor uzuale pentru legaturi deoarece
consistenta ar trebui sa fie prioritara esteticii.
O abordare des întâlnita pentru a raspunde la întrebarea "unde pot merge?" consta
în afisarea tuturor nivelelor de top dintr-un site web. Folosind schema de navigare
"farâmitura de pâine" si evidentiind destinatia adecvata la care se poate ajunge din
interiorul paginii curente, utilizatorul obtine o informatie suficienta privind pozitia
acestuia în interiorul retelei. Este minim recomandata aceasta marcare care sa
evidentieze legaturile în cadrul textului; în plus, este indicata evidentierea în cadrul
barei de navigare.
Abordarea dezvoltarii independenta de dispozitiv
Îmbunatatirea cerintelor pentru proiectarea prezentarii rezulta din cresterea cererii
pentru folosirea în proiectare a unui numar mare de diferite dispozitive cu suport
web.
Spectrul acestor dispozitive cu suport web include toate clasele de dispozitive
mobile - de la cele mai mici telefoane mobile care dispun de browsere WAP pâna la
telefoane inteligente si tablet PC-uri cu ecrane sensibile la atingere. Prin prisma
facilitatilor tehnice oferite de dispozitivele mobile remarcam o serie de optiuni de
prezentare si interactiune pentru utilizare în aplicatiile web.
5.3 Proiectarea interactiunii
Proiectarea interactiunii implica intersectarea dintre elementele vizuale, dinamice,
functionale si tehnice ale aplicatiilor web. Scopul sau principal este combinarea
acestor elemente si reducerea conflictelor dintre ele pentru a oferi utilizatorilor o
experienta interesanta si atractiva, dar si consistenta si usor de înteles.
Proiectarea interactiunilor implica o abordare sistematica care împarte interactiunea
aplicatiilor web în patru aspecte: interactiunea cu utilizatorul, organizarea interfetei
utilizator, navigarea si activitatile utilizatorului.

Interactiunea cu utilizatorul
 Pe masura ce aplicatiile web au devenit mai sofisticate, au fost asociate
multiple roluri HTML-ului: transportul informatiei, layout-ul, interactiunea cu
utilizatorul, procesele si accesul direct al continutul digital. Odata cu cresterea
responsabilitatilor, HTML-ul a evoluat, încorporând mai multe functionalitati pentru
a se adapta unor scenarii din ce în ce mai complexe. În acest proces interactiunea cu
utilizatorul a devenit o limitare majora: serverele trebuie sa genereze o noua pagina
de fiecare data, aplicatiile ruleaza din ce în ce mai greu, iar din momentul în care
formularele au devenit insuficiente pentru a acoperi tehnicile mai avansate de
interactiune cu utilizatorul, HTML-ul ca interfata a cunoscut un declin comparativ cu
aplicatiile desktop. Pentru a elimina aceste limitari au fost dezvoltate diferite
abordari tehnologice.
În ceea ce priveste interactiunea cu utilizatorul se remarca doua tendinte opuse:
câte functii necesita interfata pentru a afisa datele si a realiza operatiile si, în al
doilea rând, cât de mult este concentrata pe date aplicatia în ansamblu (vezi figura
5.2).
Fig
ura
5.2
Co
mp
arar
ea
prin
cipa
lelo
r
teh
nol
ogii
de dezvoltare a interfetelor
Organizarea interfetei utilizator
Interfata utilizator a unei aplicatii web trebuie sa reprezinte o cantitate mare
de informatie, operatii asupra acestei informatii si relatii dintre acestea. În acest sens
este necesara o mapare corespunzatoare a acestor aspecte. Pentru a rezolva aceasta
problema un prim pas este gruparea elementelor în canale de interactiune. Aceasta
grupare trebuie sa fie clara si consistenta în întreaga interfata. Majoritatea intrarilor
si grupul de interactiune trebuie sa ramâna aceleasi pe parcursul sesiunii, în timp ce
grupul de iesire se modifica.
O problema frecventa apare atunci când un nod contine mai multe informatii decât
permite dimensiunea ecranului. Când punem în balans aspectele de proiectare a
prezentarii cu aspectele de proiectare a interactiunii trebuie avute în vedere
urmatoarele întrebari: Dimensiunea ecranului are prioritate fata de conceptul
potrivit caruia nodurile sunt unitati atomice (si unitati de navigare)? Un nod ar putea
fi împartit în noduri mai mici? Navigarea suplimentara poate fi o alternativa la
scrolling? Cum pot fi echilibrate comportamentul complex al interfetei utilizator si
portabilitatea? Amestecul tehnologic are implicarile lui, de aceasta data în ceea ce
priveste semantica de navigare, portabilitatea si caracterul utilizabil. Se pot
diferentia mai multe abordari (vezi tabelul 5.2):
1. Întregul nod este trimis utilizatorului ca HTML. Pagina HTML include fie scripturi
fie tehnologii plug-in pentru a permite utilizatorului accesul la un subset al
informatiei.
2. Întregul nod este trimis utilizatorului ca o singura pagina HTML fara scripturi.
Utilizatorul selecteaza legaturile relative de pe pagina pentru a naviga în acea
pagina.
3. O vizualizare partiala spere nod este trimisa utilizatorului. Pagina afiseaza un
subset de informatii aranjate în functie de semnificatie. Utilizatorul poate naviga
catre alte pagini pentru a citi în întregime informatia dorita.
Abordarile Semantici de Portabilitate Usurinta în
implementarii navigare folosire
HTML+scripting + - +
HTML+legaturi + + -
relative
Pagini HTML - + -
legate
Tabelul 5.2 Alternativele de implementare pentru noduri. Tabelul afiseaza modul în
care abordari diferite ale implementarii au un impact pozitiv sau negativ asupra
semanticii navigarii, portabilitatii si caracterului utilizabil.
Paginile legate elimina utilizarea excesiva a scrolling-ului dar conduc catre cai de
navigare suplimentare si deci la o latenta mai mare la afisarea în mod repetat a unei
informatii. Studiile efectuate asupra utilizatorilor recomanda folosirea scrolling-ului
în locul unei navigari suplimentare (Nielsen 1997a).
Proiectarea navigarii
Rezultatul obtinut din proiectarea navigarii este dublu: pe de o parte elementele pe
care utilizatorii le pot accesa si pe de alta parte structura de navigare. Elementele
devin noduri în cel mai simplu caz, iar structura defineste relatiile dintre noduri.
Aceste relatii vor deveni ulterior legaturi vizibile în interfata utilizator. În acest
scenariu proiectarea interactiunii defineste aspectele necesare pentru navigarea în
sine (ancora si URL) si elementele necesare pentru orientarea utilizatorilor.
Proiectarea reprezentarii unei legaturi: ancora
Ancorele sunt corespondente vizibile ale URL-urilor si trebuie sa sugereze
utilizatorilor activarea acestora si consecintele posibile. Deoarece implementarea
bazata pe HTML a web-ului amesteca conceptul de ancora cu conceptul de legatura
într-un singur element unidirectional (<a>), semanticile se îmbina la rândul lor, de
aceea utilizatorii nu pot fi siguri de consecintele posibile care apar când acceseaza o
legatura. (vezi tabelul 5.3)
Semantica Incertitudinea privind sensul acesteia
legaturii
Navigare Legatura reprezinta o singura destinatie sau mai multe
destinatii? Destinatia este în interiorul sitului web sau în
afara lui? Noul nod este reprezentat în aceeasi fereastra
sau într-una noua? Textul din pagina actuala se modifica
sau are loc o navigare adevarata?
Descarcare Ce tip de document este descarcat? Sunt necesare utilitare
(exemplu plug-in-uri) pentru reprezenta documentul?
Proces Legatura va declansa o actiune pe server? VA fi posibila
navigarea înapoi sau revenirea la actiunea anterioara?
Tabelul 5.3 Consecintele posibile ale accesarii unei legaturi
Textul unei ancore trebuie sa fie autoexplicativ (W3C 2001c); iar legaturile trebuie
clasificate pe categorii. În plus, iconitele pot fi utilizate în interiorul ancorelor pentru
a vizualiza legaturile. Desi ancorele si iconitele pot fi specificate static, proprietatile
care se modifica dinamic (exemplu daca anumite tipuri media pot fi deschise)
trebuie marcate prin utilizarea scripturilor incluse în aceste pagini.
Proiectarea interna a legaturilor: URL
Navigare si orientare
5.4 Proiectarea functionala
În cadrul proiectarii functionale trebuie luate de asemenea în considerare aspectele
tehnologice care au un impact major asupra aplicatiei web în curs de dezvoltare.
Integrare
Paradigme de comunicare si middleware
Aplicatii web distribuite între corporatii
VI. Tehnologii pentru aplicatiile web
Alegerea unei tehnologii adecvate este un factor de succes important în
dezvoltarea aplicatiilor web. Pentru a putea utiliza tehnologiile, a observa modul de
interactiune dintre ele într-o arhitectura existenta si implementa aplicatii web este
necesara o cunoastere a caracteristicilor acestora. În continuare vom aborda
principalele tehnologii, interactiunea si modul de utilizare al acestora în anumite
arhitecturi, tinând cont de recomandarile W3C (World Wide Web Consortium).

Dezvoltarea sistemelor software traditionale este procesul proiectarii unui

corect "CUM" pentru un bine definit "CE". Padridge (1992)

Din momentul în care am definit cerintele pentru o aplicatie web, am ales o

arhitectura si am dezvoltat un mod de proiectare (pe scurt am clarificat "ce"), putem
demara faza de implementare (pe scurt "cum"). În acest context, reutilizarea are un
rol important în procesul de dezvoltare. Cerintele rezultate pentru implementarea
aplicatiilor web încep cu alegerea tehnologiei adecvate. Separarea continutului si a
prezentarii si cerintele pentru distribuirea si integrarea altor sisteme, în functie de
arhitectura selectata sau existenta, sunt cerinte esentiale pentru o utilizare adecvata
a tehnologiilor.
Caracteristicile implementarii tehnologiilor pentru aplicatiile web versus sisteme
software traditionale provin din utilizarea standardelor web. Aceasta afecteaza
implementarea în trei moduri: cerere (client), raspuns (server) si reguli de
comunicare între cele doua (protocol).
Datorita evolutiei rapide a tehnologiilor bazate pe web este imposibila
descrierea tuturor tehnologiilor. Din acest motiv ne vom limita doar la prezentarea
anumitor tehnologii. În primul rând vom prezenta cele mai folosite protocoale
utilizate pe web, accentul fiind pus pe cel mai important protocol pentru World
Wide Web - HTTP (Hypertext Transfer Protocol).
6.1 Elemente fundamentale

În general, toate paradigmele de programare, aspectele de distribuire, tehnologiile

de authoring, etc., pot fi utilizate drept baza pentru implementarea aplicatiilor web.
Aceasta reprezinta una din problemele care au condus la dezvoltarea haotica a
aplicatiilor web. Aceste dezvoltari rezulta în principal din abordarile ad-hoc sau din
schimbarile rapide ale tehnologiei. Din acest motiv ne vom focaliza pe origini:
marcare (markup) si hipertext (hypertext). Marcarea reprezinta materializarea
încarnarii SGML-ului care a format baza HTML-ului si XML-ului, în timp ce hipertextul
descrie conceptul de baza al WWW.
Marcarea
Conceptul de marcare îsi are originea în domeniul editorialelor si reprezinta
instructiuni tipografice pentru formatarea documentelor. Aceste instructiuni sunt
specificate în interiorul unui document sub forma caracterelor aditionale. De
exemplu, putem scrie *Salut* pentru a obtine iesirea Salut sau /Salut/ pentru a
obtine iesirea Salut. Marcarea semantica ne permite scrierea de comentarii în cadrul
textului fara a le afisa în document. ISO defineste urmatoarele clase de marcare:
1. marcare: acesta este textul introdus în document pentru a adauga
informatii despre modul în care caracterele si continutul trebuie reprezentat în
document;
2. marcare descriptiva: aceasta marcare descrie structura si alte atribute ale
documentului, indiferent de modul de procesare al documentului pentru
reprezentare (ex: comentarii);
3. instructiuni de procesare. Aceasta marcare consta în date specifice
sistemului; controleaza modul în care este procesat un document.
 Dezvoltarea SGML (Standard Generalized Markup Language) a fost
promovata de companiile US. Când se utilizeaza SGML, autorii utilizeaza etichete
(<tag>) pentru a marca anumite parti text, care au fost anterior definite utilizând
SGML (într-un asa numit DTD - Document Type Definition). În consecinta, SGML este
si punctul de pornire pentru anumite marcari specializate, îndeosebi HTML si XML.

Hipertext si hipermedia
Pe baza utilizarii marcarii pentru marcarea elementelor singulare, hipertextul
este vazut ca o organizare a interconexiunilor unitatilor de informatii singulare.
Relatia dintre aceste unitati poate fi exprimata prin legaturi. Conceptul hipertext
este fundamental pentru World Wide Web. În timp ce hipertextul desemneaza doar
legaturile unitatilor de informatie în versiunea lor text, hipermedia este vazuta ca o
modalitate de extindere a principiului hipertext catre obiectele multimedia arbitrare
(ex: imagini sau video).
6.2 Comunicarea client/server pe web

Paradigma client/server care sta la baza aplicatiilor web formeaza coloana

vertebrala dintre un utilizator (client sau agent utilizator) si aplicatia reala (server).
Acest model de comunicare se bazeaza în principal pe arhitectura pe doua straturi.
Oricum, pasii de procesare de pe un server web pot necesita integrarea altor sisteme
(ex: baze de date, servere de aplicatii). Arhitecturile pe N-straturi astfel formate sunt
în principal bazate pe modelul client/server. De exemplu, un browser web trimite o
cerere si aceasta cerere determina un raspuns de la un server web, în timp ce
protocoalele (în special HTTP) au un rol esential. Aceste protocoale controleaza
modul în care un client ar trebui sa faca o cerere, ce raspuns îi poate returna serverul
si cum ar trebui sa realizeze acest lucru.
SMTP - Simple Mail Transfer Protocol
SMTP (Simple Mail Transfer Protocol) (Postel, 1982), combinat cu POP3 (Post
Office Protocol) sau IMAP (Internet Message Access Protocol) (Crispin, 2003)
permite trimiterea si receptionarea e-mail-urilor. În plus, SMTP este din ce în ce mai
mult utilizat ca un protocol de transport pentru schimbul de mesaje asincrone
bazate pe SOAP.
RTSP - Real Time Streaming Protocol
RTSP reprezinta un standard publicat de IETF (Internet Engineering Task
Force) si a fost proiectat pentru a suporta distribuirea de date multimedia în timp
real. Spre deosebire de HTTP, RTSP permite transmiterea resurselor de resurse catre
client într-un mod oportun comparativ cu transmiterea acestuia în întregime
(imediata). Acest mod de transmitere este cunoscut sub denumirea de streaming.
Streaming-ul permite schimbarea manuala a "perioadei de timp" audio-vizuale prin
solicitarea stream-ului la un anumit moment, astfel oferindu-ne posibilitatea de a
controla rularea componentei media într-un mod continuu. De exemplu, putem
implementa functii similare celor de pe dispozitivele hi-fi, cum ar fi "pauza",
"înainte" sau "înapoi" sau repozitiona rularea componentei media într-un punct
viitor sau trecut.
HTTP - HyperText Transfer Protocol
HTTP a devenit un protocol foarte important în ultimii ani. Proliferarea pe
scara larga a standardelor web si posibilitatea de extindere a web-ului a permis
HTTP-ului sa devina cel mai popular protocol de transport pentru continutul Web.
HTTP este un protocol simplu care controleaza modul în care resursele (ex:
documetele HTML sau imaginile) sunt accesate. HTTP este construit pe stiva TCP/IP,
unde serviciul este în mod normal disponibil pe portul 80. Resursele sunt adresate
prin utilizarea conceptului de URI (Uniform Resource Identifier). URI-urile nu sunt
legate de un anumit protocol cum este HTTP; ele reprezinta un mecansim de
adresare uniform, care este utilizat de asemenea în HTTP.
URI-ul aloca identificatori unici resurselor, indiferent de tipul acestora
(documente HTML, imagini). Cel mai reprezentativ URI este URL (Uniform Resource
Locator). URL-urile pot fi utilizate în conexiune cu DNS (Domain Name System)
pentru a identifica sistemele gazda pe care se gasesc aceste resurse. Un URI
(http://www.feaa.uaic.ro/despre_feaa/index.htm), descrie de obicei trei lucruri:
cum este accesata o resursa (ex: http:// daca este utilizat HTTP), calculatorul
destinatie (gazda) pe care este localizata resursa (ex: www.feaa.uaic.ro) si numele
resursei (ex: despre_feaa/index.htm). În plus, URI-rile definesc delimitatorul
interogarii ("?"), care permite HTTP-ului sa transmita parametrii (ex:
http://www.feaa.uaic.ro/catedre/in2.asp?codcat=IE). Sintaxa completa a URI-urilor a
fost standardizata de IETF în RFC 1630.
Delivery = transmiterea; rendered = interpretare
Mecanismul de livrare al HTTP-ului difera de metoda utilizata în sistemele
distribuite orientate obiect. În timp ce valoarea unui apel de functie (de exemplu
prin utilizarea RPC-ului), este transmisa odata ce functia a fost procesata în
întregime, o cerere HTTP conduce la un stream de date, care este evaluat imediat
imediat, chiar daca nu au fost transmise datele în întregime. Aceasta metoda are
beneficiul ca paginile web pot fi interpretate imediat, astfel fiind interpretate si
afisate mai rapid. Transmiterea imediata de catre un server web si procesarea
imediata de catre un client web poate de asemenea poate de asemenea cauza
executia unui program într-o pagina HTML (numita client-side scripting). HTTP a fost
standardizat în RFC 1945 si este disponibil în prezent în versiunea 1.1.

Urmarirea sesiunii
Aplicatiile web interactive trebuie sa fie capabile sa distinga cererile de la
numerosi utilizatori simultani si sa identifice cererile care vin de la acelasi utilizator.
Termenul sesiune este utilizat pentru a defini o astfel de secventa a cererilor
HTTP dintre un anumit utilizator si un server într-o anumita perioada de timp.
Deoarece HTTP este un protocol simplu, serverul web nu poate aloca automat
cererile venite pentru o sesiune. Distingem doua metode principale care permit
serverului web sa aloce automat o cerere venita pentru o sesiune:
- în fiecare din aceste cereri catre server, clientul însusi se identifica într-un
mod unic. Aceasta înseamna ca toate datele trimise catre server sunt alocate ulterior
sesiunii respective;
- toate datele schimbate între un client si un server sunt incluse în fiecare
cerere pe care un client o trimite unui server.
În majoritatea cazurilor, este de dorit sa lasam datele logicii aplicatiei pe
server, astfel încât logica aplicatiei sa nu fie atât de simpla. De obicei, este
implementat un mecanism de urmarire a sesiunilor prin rescrierea URL-ului sau
cookies.

Rescrierea URL-ului
Rescrierea URL-ului este un mecanism care transmite datele relevante ale
sesiunii ca un parametru în URL. Datele transmise pot apoi fi utilizate pentru a
reconstrui sesiunea de pe server. Din nefericire, acest mecanism are anumite lipsuri:
- daca un volum mare de date este necesar într-o sesiune, atunci URL-ul
poate deveni cu usurinta dezordonat si purtator de erori. Din momentul în care
aplicatiile web tind sa devina complexe, cerintele pentru volumul de date care
trebuie stocat într-o sesiune poate de asemenea creste;
- limitarea lungimii unui URL poate determina ca acest mecanism sa devina
instabil pe anumite sisteme;
- obstacolul principal este ca URL-urile codificate în paginile HTML trebuie sa
fie adaptate dinamic pentru fiecare sesiune; de exemplu pentru a codifica o sesiune
într-un ID de sesiune dintr-un URL. Aceasta înseamna ca paginile sau legaturile din
aplicatie trebuie sa fie generate dinamic pentru fiecare cerere. Putem folosi cookies
pentru a rezolva elegant aceasta problema.
Cookies
Cookies sunt fisiere text mici folosite pentru a stoca informatia de pe server
(ex: ID-ul unei sesiuni) pe sistemul clientului. Aceasta informatie este scrisa într-un
fisier text sub forma perechilor nume-valoare. Cookies sunt generate de catre
serverul web si transmise clientului în antetul raspunsului HTTP. Browser-ul web al
clientului stocheaza un cookie pe sistemul clientului si va utiliza întotdeauna acel
cookie pentru a transmite serverului ce a generat cookie la fiecare cerere. Cookies
sunt clasificate în: "sesiune" sau "permanente". În timp ce cookie-urile permanente
ramân stocate pe calculatorul clientului (stocate pe hard disk), cookie-urile sesiune
sunt doar pastrate pâna când situl este parasit sau browser-ul este închis. Aceasta
înseamna ca serverul poate identifica cererile de la anumit client si sa le aloce unei
sesiuni. Cookies pot include si data expirarii; odata ce data expira, browser-ul client
nu va trimite cookie-ul catre server.
 Principalul beneficiu al cookies-urilor este ca informatia care identifica o
sesiune poate fi schimbata în mod transparent între un client si un server. Ele pot fi
utilizate pentru a implementa cu usurinta urmarirea sesiunilor si nu necesita un efort
sporit deoarece doar ID-ul sesiunii generate de server trebuie transmis.
Principalul dezavantaj al cookies-urilor este ca anumiti utilizatori dezactiveaza
functionalitatea cookie în browsere pentru a preveni schimbarea comportamentului
browserului.
Scenarii de utilizare
Care din cele doua mecanisme discutate anterior este cel mai potrivit pentru
aplicatiile web depinde în principal de circumstante. În mod ideal, este de dorit sa
lasam informatiile despre sesiune pe partea de server si sa utilizam un ID de sesiune
cât mai sigur. Aceasta metoda poate fi combinata: utilizând cookies pentru a stoca
ID-ul sesiunii si rescrierea URL-ului pentru browserele care nu accepta cookies. Un
exemplu de codificare pentru ID-ul unei sesiuni într-un URL este:
http://host/application/page.ext?SessionId=XYZ sau
http://host/application/XYZ/page.ext, unde XYZ reprezinta o cheie unica pentru
sesiune, greu de ghicit.
Tehnologiile server actuale (PHP, JSP, ASP.NET) ofera API-uri pentru utilizarea
mecanismului descris anterior. Acest API ascunde complexitatea sesiunii, facilitând
generarea ID-urilor de sesiune si oferind metode dedicate pentru stocarea
informatiilor despre sesiune.
6.3 Tehnologii client-side
Ajutoare si plug-inuri
Programele de ajutor sunt aplicatii care adauga functionalitati browserelor
web. În momentul în care browserul receptioneaza un tip de media inclus în lista de
ajutoare sau plug-inuri, tipul respectiv este trimis unui program extern specificat în
lista pentru o procesare ulterioara. Exemple de aplicatii de ajutor sunt WinZip si
Acrobat Reader. Un program de ajutor trebuie instalat de catre utilizator pe
calculatorul clientului. Programul de ajutor este apoi invocat la tipul corespunzator
de MIME. Orice program poate deveni un ajutor. Dezavantajul ajutoarelor consta în
comunicarea avansata cu browserele. Plug-inurile pot rezolva aceasta problema. Un
plug-in este un program de ajutor instalat permanent în browser pentru optimizarea
comunicarii.
Applet-uri Java
Applet-urile Java sunt programe scrise în Java care sunt încarcate dinamic în
browser. Ele ruleaza într-un "sandbox", astfel împiedicând accesul direct al
resurselor sistem de pe client; uneori permit accesarea resurselor dupa verificarea
politicii de securitate. Applet-urile sunt încarcate de un server web si executate într-
un browser într-un mediu de lucru numit JVM (Java Virtual Machine). Applet-urile nu
sunt stocate în mod persistent pe un sistem. Spre deosebire de controalele ActiveX,
applet-urile sunt compilate într-un sistem independent, ceea ce le permite sa ruleze
pe toate platformele care dispun de JVM.
Controale ActiveX
Prin controalele ActiveX Microsoft a permis utilizarea componentei COM în
browserele web. Controalele ActiveX sunt componente standard COM proiectate
pentru a oferi un anumit set de interfete (interfete COM). Un browser web poate
încarca o astfel de componenta de pe un server web, instantia via COM si apoi utiliza
funtionalitatea acelei componente. Spre deosebire de applet-urile Java, controalele
ActiveX sunt compilate în cod binar, care ofera o performanta deosebita. Controalele
ActiveX sunt stocate într-un director de cache special al browser-ului, prin apelarile
ulterioare functionalitatea respectiva fiind deja disponibila. În plus, controalele
ActiveX au aceleasi posibilitati ca plug-in sau ajutor; ele pot accesa toate zonele
sistem si functiile pe care utilizatorul le detine pe sistemul respectiv (acesta este un
risc de securitate). Microsoft a dezvoltat o metoda care permit distribuitorilor de
controale ActiveX sa utilizeze o metoda criptografica pentru a semna aceste
componente. Când controalele ActiveX sunt încarcate în browser, certificatul
distribuitorului va fi afisat; utilizatorul va decide daca este de acord sa ruleze un
program în functie de încrederea pe care o prezinta compania producatoare. Un alt
beneficiu al controalelor ActiveX este ca componentele pot fi dezvoltate într-un
limbaj arbitrar: Java, Visual Basic si C++, atât timp cât necesitatile compilatorului
pentru limbajul respectiv îndeplineste cerintele specificatiilor COM.
6.4 Tehnologii specifice documentului
HTML - Hypertext Markup Language

HTML este o aplicatiei SGML care descrie elementele care pot fi utilizate
pentru a marca continutul într-un document hipertext si modul în care aceste
elemente sunt în legatura într-un DTD (Document Type Definition). Elementele de
marcare sunt închise între simbolurile "<" si ">". HTML defineste un set mare de
etichete pentru a indica semantici diferite. De exemplu, eticheta <H1> poate fi
folosita pentru a marca titlurile de nivel 1.
Etichetele sunt folosite pentru structurarea logica a documentului. De
exemplu, elementul de marcare <strong> specifica faptul ca partea din document
dintre aceste perechi de etichete trebuie interpretate sub forma unei evidentieri
logice, pe care browserele le afiseaza în mod normal cu aldine. Datorita
posibilitatilor limitate ale proiectarii grafice, au fost introduse elementele
suplimentare pentru a permite proiectantilor sa influenteze în mod direct layout-ul
documentului. De exemplu, elementul de marcare <b> poate fi folosit pentru a
instrui browserul sa reprezinte o parte din document cu aldine. Oricum, semantica
marcarii este pierduta. Datorita multitudinii de posibilitati de a influenta layout-ul,
nu este surprinzator ca majoritatea resurselor HTML neglijeaza utilizarea
elementelor de marcare logice/semantice. Aceasta face mult mai dificila
interpretarea informatiilor pentru masini. Situatia este mult mai critica deoarece
informatia poate fi, într-un anumit mod, usor convertita în alte formate (de exemplu
pentru a o face utilizabila pe dispozitive cum sunt telefoanele mobile). Simplitatea în
crearea si procesarea resurselor HTML (ele sunt simple fisiere text) este o
proprietate foarte importanta pentru caracterul omniprezent al informatiei pe Web,
aceasta fiind împiedicata de aspectul prezentarii. Introducerea noilor elemente de
marcare a fost facilitata îndeosebi de faptul ca browserele resping sau ignora
elementele de marcare pe care nu le cunosc. Aceasta flexibilitate a fost utilizata în
mod repetat de producatorii de browsere pentru a extinde optiunile de layout, care
au condus la noi standarde, dar si la reprezentari "incompatibile".
Aceste probleme au încurajat introducerea unui numar mare de extensii. De
exemplu, CSS (Cascading Style Sheets) reprezinta un mecanism simplu pentru
adaugarea informatiilor de stil (cum sunt fonturile si culorile) la documentele Web.
Împreuna cu introducerea XHTML-ului, un dialect XML, a devenit posibila utilizarea
beneficiilor XML-ului ca un limbaj "curat" pentru descrierea documentelor HTML.

SVG - Scalable Vector Graphics

Formatul imagine SVG (W3C, 2001a) permite descrierea imaginilor

bidimensionale în XML. SVG recunoaste trei tipuri de obiecte grafice: imagini
vectoriale care constau în linii si curbe, imagini si text. Obiectele grafice pot fi
grupate si integrate în alte obiecte.
SVG suporta interactiuni bazate pe evenimente (ex: raspunsuri la miscarea
mouse-ului sau apasarea unui buton). De exemplu, un astfel de raspuns poate fi
marirea unei imagini. În plus, este posibila definirea unui cursor special pentru
interactivitatea cu utilizatorul. SVG suporta toate tipurile de animatii, oferind un
numar mare de functii, inclusiv cele de mutare a unui obiect grafic de-a lungul unei
cai pre-definite. Datorita acestor proprietati, acest format este adecvat pentru toate
toate tipurile de grafice vectoriale interactive si animate. Exemple de astfel de
aplicatii includ reprezentarile CAD, hartile si rutele.
SMIL - Syncronized Multimedia Integration Language
SMIL (W3C, 2001a) este acronimul pentru Syncronized Multimedia
Integration Language si a fost dezvoltat de W3C pentru a reprezenta prezentarile
multimedia sincronizate. SMIL permite coordonarea prezentarii diferitelor media,
cum ar fi audio, video, text si imagini. De exemplu, SMIL ne permite sa definim exact
când o fraza ar trebui rostita si ce imagine sau text ar trebui sa apara în paralel.
Fiecare mediu poate fi adresat direct si putem specifica locatia si perioada
reprezentarii.
Perioadele de start si final pentru fiecare mediu pot fi sincronizate relativ usor
cu cele ale altor medii. Trasaturile de control standard permit utilizatorului sa
interactioneze cu SMIL fiind posibile oprirea, pauza, derularea înainte sau înapoi a
întregii prezentari. Functiile suplimentare includ generatoarele aleatorii, rularea cu
încetinitorul si perioada de timp trecuta. Pe parcursul prezentarii, utilizatorul poate
selecta legaturi pentru a naviga catre alte pagini web.
SMIL include în versiunea sa prezenta functii pentru animatii, controlul
prezentarii continutului, legaturi, integrarea diferitelor tipuri de media, coordonare
si sincronizare, controlul timpului si efecte de tranzitie.
XML - eXtensible Markup Language
XML (eXtensible Markup Language) este un dialect extrem de simplu al SGML-
ului. Obiectivul este de a permite SGML-ului generic sa fie deservit, receptionat si
procesat pe web într-un mod posibil acum cu HTML. Din acest motiv, XML a fost
proiectat pentru a usura implementarea si pentru interoperabilitate cu SGML si
HTML (W3C Working Draft, November 1996).
Pe baza recomandarilor W3C, XML (eXtensible Markup Language, W3C, 1998)
a cunoscut un real progres datorita utilizarii si profilerarii acestuia în cadrul si în
afara Web-ului. Datorita capacitatii de a defini într-un mod extrem de simplu,
formate de date flexibile si de a schimba aceste formate pe Web, XML ofera premisa
pentru pentru a omogeniza mediile eterogene. Aceasta înseamna ca, pe lânga
descrierea uniforma a formatelor de date, vom lua în considerare semanticile
acestor date, indiferent de informatie. Capacitatea de extindere provine din faptul
ca, spre deosebire de HTML, XML nu "dicteaza" o marcare predefinita cu semantici
implicite; ne permite definirea flexibila a sensului semanticilor si a structurii unui
document XML, acesta putând astfel fi adaptat în anumite circumstante. Acesta este
motivul pentru care XML, în loc de a fi o alternativa la HTML, deschide noi moduri de
a descrie datele în diverse scopuri.
Documentele XML sunt caracterizate prin doua proprietati distincte: sunt
bine structurate si sunt valide. Buna structurare este în mod inerent ancorata în
XML, în timp ce validitatea este asigurata de DTD (Document Type Definition) si prin
schema XML. Pentru a ne asigura ca un document XML este bine structurat, exista
reguli generale pentru sintaxa documentelor XML, care (spre deosebire de HTML)
trebuie observate întocmai. În realitate, specificatiile XML abordeaza aceste reguli
sub forma "constrângerilor". Tabelul 6.1 foloseste anumite exemple pentru a
demonstra regulile pentru o buna structurare a XML-ului.
Descriere Gresit Corect
Toate etichetele <A><B></A></B> <A><B></B></A> sau
trebuie sa apara în <A><B/></A>
pereche pe acelasi
nivel de imbricare. În
plus, pot apare
etichete goale (<B/>
Etichetele sunt <A></a> <A></A>
sensibile la majuscule
 si minuscule
Toate atributele <A elem = 5/> <A elem = "5"/>
trebuie închise între
ghilimele
Spre deosebire de <td nowrap> <td style = "white-
HTML, nu exista space:nowrap"
atribute fara valori
Numele de etichete <A B> </A B> <AB></AB>
trebuie sa respecte
regulile pentru
numirea
elementelor. De
exemplu, elementele
goale si < sau > sunt
invalide
Tabelul 6.1 Reguli pentru o buna structurare a XML-ului
Deoarece aceste reguli trebuie strict observate, este posibila o stabilire clara
a structurii documentelor XML. Aceasta a condus la definirea DOM (Document
Object Model), care poate fi utilizata pentru a transforma structura arborescenta a
documentelor XML într-un arbore orientat-obiect. Figura 6.1 ilustreaza o comanda
sub forma unui simplu exemplu de document XML. Vom utiliza acest exemplu drept
baza pentru alte exemple din sectiunile urmatoare:
<?xml version="1.0"?>
<order OrderID="10643">
<item><book isbn="123-321" /></item>
<item><cdrom title="Vivaldi Four Seasons" /></item>
<item><book isbn="3-8265-8059-1" /></item>
<OrderDate ts="2003-06-30T00:00:00" />
<price>167.00 EUR</price>
</order>
Figura 6.1 Exemplu în XML al unei comenzi
Namespace-urile
Namespace-urile57[57] sunt caracteristici esentiale ale manipularii XML-ului.
Namespace-urile pot fi folosite pentru a evita conflictele de nume printr-o numire
uniforma a elementelor dintr-un document XML. Aceasta permite documentelor ce
apartin diferitelor structuri sa fie unite.

57[57] World Wide Web Consortium (W3C), Namespaces in XML, January, 1999a,
http://www.w3.org/TR/1999/REC-xml-names-19990114/Overview.html, [ultima vizita:
2007-12-05]
 Exista doua moduri diferite de marca un element XML prin namespace-uri:
prin specificarea namespace-ului pentru un element sau prin utilizarea unui prefix.
Metoda utilizarii unui prefix este utila atunci când diferite elemente apartin aceluiasi
namespace, deoarece face documentele XML mai scurte si mai usor de citit. Figura
6.2 utilizeaza exemplul anterior pentru a ilustra cele doua variante. URI-ul (uri:order)
adreseaza un namespace ce corespunde unei comenzi.

<order xmlns="uri:order"> <o:order

xmlns:o="uri:order">

<item>
<o:item>
<book xmlns="uri:order" isbn="123-456" /> <o:book / >
</item> </o:item>
</order> </o:order>
Figura 6.2 Utilizarea unui namespace fara si cu un prefix
XML DOM
DOM (Document Object Model) foloseste o abordare orientata-obiect asupra
documentelor XML, permitând o procesare usoara si intuitiva a XML-ului. DOM este
creat de un parser XML care parseaza (analizeaza) structura unui document XML si
instantiaza un arbore obiect (vezi Figura 6.3). Fiecare element XML din acest arbore
corespunde unui nod. Beneficiul acestei metode este accesarea nodurilor într-o
maniera orientata-obiect, odata ce DOM a fost creat. Dezavantajul acestei metode
consta în faptul ca este costisitoare, deoarece este nevoie de un parser XML pentru a
crea arborele. De exemplu, deseori vom dori sa citim parti ale unui document XML în
loc de întregul document; în aceste cazuri, este recomandat sa utilizam parsere care
sunt mai putin consumatoare de resurse (ex: parsere SAX - Simple API for XML).
Parserele SAX utilizeza un model bazat pe evenimente, care suporta interventia
tintei în procesul de parsare. Parserele SAX sunt disponibile pentru majoritatea
platformelor si limbajelor de programare.

<order>
<OrderDate ts="2003-
06-30" />
<price>30.00EUR</pri
ce>
</order>
Figura 6.3 Structura DOM pentru un fragment al exemplului în XML de comanda
Constrângeri privind validitatea XML-ului
În timp ce constrângerea privind buna structurare, definita în specificatiile
XML, asigura o sintaxa clara pentru documentele XML, validitatea ne permite
introducerea unei structuri în mod specific pentru un document XML. Un document
XML este valid atunci când este corect construit si când continutul si structura
acestuia sunt conforme cu regulile predefinite. Aceste reguli sunt formulate fie în
DTD-uri (Document Type Definitions) sau în schemele XML. În termenii orientarii
obiect, aceasta semnifica faptul ca o buna structurare ne permite maparea XML-ului
la DOM, în timp ce validitatea ne permite introducerea tipurilor de date specifice
aplicatiei.
DTD (Document Type Definition)
Un DTD reprezinta un set de reguli care pot fi utilizate pentru a descrie
structura unui document XML. XML a împrumutat DTD-urile din SGML. Figura 6.4
reprezinta un DTD care valideaza exemplul XML al comenzii. Fragmentele !DOCTYPE,
!ELEMENT si !ATTLIST descriu tipul de data. Modul în care elementele sunt legate ne
aminteste de modul de definire a expresiilor regulate. Regula <!ELEMENT order
(item+,OrderDate,price)> specifica ca un element comanda (order) consta în cel
putin un articol ("+"), urmat de o data a comenzii (OrderDate) si un pret (price).
<?xml version="1.0"?>
<!DOCTYPE order [
<!ELEMENT order (item+,OrderDate,price)>
<!ATTLIST order OrderID ID #REQUIRED>
<!ELEMENT item (book,cdrom)+>
<!ELEMENT book EMPTY>
<!ATTLIST book isbn CDATA #REQUIRED>
<!ELEMENT cdrom EMPTY>
<!ATTLIST cdrom title CDATA #REQUIRED>
<!ELEMENT OrderDate EMPTY>
<!ATTLIST OrderDate ts CDATA '2003-06-30T00:00:00'>
<!ELEMENT price (#PCDATA)>
]>
Figura 6.4 DTD-ul pentru exemplul XML al comenzii

Datorita structurii lor simple, DTD-urile sunt relativ usor de înteles de oameni.
Acesta este motivul pentru care ele sunt utile în principal când au fost create sau
întretinute manual. Datorita structurii simple, DTD-urile determina doua probleme
distincte, care sunt solutionate prin schemele XML:
 - faptul ca DTD-urile au împrumutat din SGML este deseori considerata o
problema, deoarece solicita un parser DTD care sa citeasca gramatica. Exemplul
nostru demonstreaza ca un DTD nu reprezinta un XML corect construit;
- desi unele tipuri de date pot fi utilizate pentru a defini elementele sau
atributele din cadrul DTD-urilor, întinderea acestora este foarte limitata. Aceasta
restrictie împiedica reutilizarea DTD-urilor.
Schemele XML
Schemele XML (W3C, 2000) sunt proiectate pentru a raspunde problemelor
introduse prin DTD-uri. Principalele lor beneficii (integrarea tipurilor de date,
reutilizarea si formularea XML) vin cu pretul cresterii complexitatii. Rezultatul este
ca, atunci când dezvoltam schemele, a devenit aproape inevitabila utilizarea
instrumentelor. Datorita complexitatii acestora, în continuare vom discuta schema în
mod concis pentru a sublinia proprietatile si conceptele lor mai importante.
O schema XML poate fi utilizata pentru a descrie tipuri de date pre-definite,
cum ar fi string, byte, decimal sau date. În plus, acestea ne permit definirea fatetelor
care suporta tipuri de date definite de utilizatori similar template-urilor. Sa
presupunem ca toate atributele ISBN valide ale unui element XML numit book, din
exemplul cu comanda, trebuie sa urmeze notatia pentru numerele ISBN. Putem
utiliza o fateta pentru a descrie combinatia de numere si linii (-) din sablonul N\ -
NNNN\ -NNNN\ -N si reutiliza aceste tipuri de date în proiectele de dezvoltare
viitoare.
Exista doua concepte distincte care pot fi folosite pentru a obtine tipurile de
scheme de date pentru tipurile existente: extensia si restrictia. În sensul mostenirii
orientate-obiect, restrictia va corespunde specilizarii unei serii de valori ale unui
supertip, în timp ce extensia va fi similara agregarii altor tipuri. Figura 6.5 (partea din
stânga) demonstreaza cum este creat tipul LTH (mai mic decât 100) prin
restrictionarea tipului pre-definit positiveInteger si setarea limitei superioare pentru
seria de valori. În partea dreapta a figurii, tipul definit de utilizator orderType este
extins la datedOrderType, care adauga un element, orderDate, al tipului pre-definit
date la un orderType.
Figura 6.5 Tipuri definite de utilizator
XSL - eXtensible Stylesheet Language
XSL (W3C, 1999a) consta în trei parti:
- transformarile XSL;
- XPath si
- XSL-FO.
XSL include un standard pentru transformarea si formatarea XML-ului. XSLT
este un limbaj folosit pentru a defini sabloanele si regulile pentru transformarile
acestora si reprezinta inima XSL-ului. În timp ce XSL-FO este folosit pentru a defini în
mod clar un stil de formatare, acesta reprezinta doar una dintre toate posibilele
rezultate pentru transformare XSLT. Din acest motiv, XSL poate fi comparat cu
modelul-View-Controller de proiectare a sabloanelor. Modelul corespunde
documentelor XML, iar controler-ul corespunde XSLT-ului. View-urile create pot fi de
un natura arbitrara (HTML, WML, cHTML, sau din nou XML. Un view predefinit din
cadrul suitei XSL pot fi conceput ca un XSL-FO (Formatting Object).
XSLT - eXtensible Stylesheet Language Transformations
Standardul XSLT descrie cum continutul (datele) marcat în XML poate fi
transformat. Documente care definesc un program XSLT sunt numite foi de stiluri.
Limbajul XSLT definit este un dialect XML. Aceasta înseamna ca XSLT mosteneste
toate proprietatile XML, inclusiv costruirea corecta si validitatea. XSLT este descris în
namespace-ul (http://www.w3.org/1999/XSL/Transform) definit de W3C, care
garanteaza validitatea unei foi de stil XSLT. Rezultatul unei transformari XSL nu este
legat de structuri specifice sau dictate sau de restrictii. Aceasta înseamna ca
rezultatul unei transformari XSL acopera întregul spectru începând cu marcarea
structurata (XML) pâna la interpretarea arbitrara a sirurilor de caractere. Un
procesor XSLT lucreaza dupa principiul IPO (Input, Processing, Output). XML sunt
date de intrare, în timp ce foaia de stil XSLT realizeaza prelucrarea necesara pentru a
genera iesirea. Figura 6.6 demonstreaza modul în care functioneaza un procesor
XSLT.

Figura
6.6
Abord
are
schem
atica a
modului în care functioneaza un procesor XSLT
Functionalitatea unei transformari XSLT se bazeaza pe principiul "potrivirii
sablonului". O foaie de stil reprezinta un set de perechi de sablon-rezultat, similar
regulilor de mapare a unui sistem de rescriere a sirurilor (semi-Thue) (sablon →
rezultat). Un procesor cauta intrarile (sursa documentelor) sabloanelor, care sunt
definite în foaia de stil (sablon), si le înlocuieste cu rezultatul care se potriveste cu
sablonul din datele de iesire (documentele rezultat). Rezultatul poate fi vazut ca un
sablon care reprezinta un amestec de iesiri si alte elemente ale limbajului XSL.
Comparativ cu limbajele de programare conventionale, precum C sau C #,
putem aborda sabloanele ca proceduri, si template-urile drept corpul acestora.
Înlocuirea sablonului rezultat initeaza un proces recursiv asupra DOM-ului din
intrarea XML. Similar cu procedurile, sabloanele pot fi parametrizate si suporta
contextele dintr-o intrare XML. XML Path Language (XPath) este folosit pentru a gasi
sabloane. În timp ce XSLT reprezinta o colectie de modele, XPath controleaza modul
în care sunt conectate la documentul de intrare XML. Elementele limbajului XSLT pot
fi grupate în patru categorii distincte:
- elementele de definire (D): aceste elemente ale limbajului sunt utilizate
pentru a defini o foaie de stil XSL (xsl: stylesheet), un model (xsl: template), variabile,
parametri, etc
- elementele fluxului de control (C): aceste elemente de limbaj sunt utilizate pentru a
manipula control fluxului dintr-un sablon XSLT. De exemplu, putem formula iteratii
(xsl: foreach) sau intructiuni conditionale (xsl: if).
- elementele limbajului orientat pe iesiri (O): aceste elemente sunt folosite pentru a
genera datele de iesire ale unui sablon XSLT. De exemplu, am putea genera
elemente de marcare (xsl: element si xsl: atribut) sau doar text liber.
- elemente privitoare la locatie (L): Aceste elemente sunt utilizate pentru aspecte
privitoare la limbi multiple, cum ar fi definitiile locale si formatele (xsl: zecimal-
format).
Figura 6.7 defineste un stil XSLT, care poate transforma "ordinul de
cumparare" din exemplul XML prezentat în figura 6.1. Browserele cu procesoare XSL
integrate, cum sunt versiunile curente de Internet Explorer si Netscape Navigator,
pot reprezenta un "ordin de cumparare" cu foaia de stil specificata în HTML.
Observam ca avem nevoie sa adaugam un procesor de instructiuni pentru exemplul
XML, pentru a specifica locatia foii de stil (vezi figura 6.8).
<?xml version='1.0'?>
<xsl:stylesheet
xmlns:xsl=http://www.w3.org/1999/XSL/Transform
version="1.0">
<xsl:template match="/">
<HTML><HEAD><TITLE>Ordin de cumparare</TITLE></HEAD>
<BODY>
<xsl:apply-templates select="order"/>
</BODY>
</HTML>
</xsl:template>
<xsl:template match="order">
<table border="1">
<th colspan="2">
Ordin de cumparare (<xsl:value-of select="@OrderID"/>)
</th>
<xsl:for-each select="item">
<xsl:apply-templates select="book" />
</xsl:for-each>
</table>
</xsl:template>
<xsl:template match="book">
<tr><td>Book</td>
<td><xsl:value-of select="@isbn"/></td></tr>
</xsl:template>
</xsl:stylesheet>
Figura 6.7 Utilizarea unui stil XSLT pentru exemplul "ordin de cumparare" example.
<?xml-stylesheet type="text/xsl"
href="http://www.order.com/xsl/order.xslt"?>
Figure 6.8 Integrarea unui stil XSLT într-un document XML
XPath
XML Path Language (XPath) ofera functionalitatea de a parcurge un document
XML. XPath ofera o multitudine de expresii care permit definirea unor cai de cautare
ce pot fi folosite într-un document XML pentru a returna setul de noduri XML.
Expresiile XPath sunt evaluate de un procesor XPath, care functioneaza în acelasi
mod cu directoarele dintr-un sistem de fisiere. De exemplu, copiii elementelor XML
pot fi priviti ca intrari într-un director din sistemul de fisiere. Figura 6.9 arata
legatura dintre un document XML si interpretarea acestuia ca un sistem de
directoare pentru a întelege mai bine conceptul. Pe partea stânga, figura arata cum
este utilizata o expresie XPath, în timp ce partea dreapta arata modul în care o
expresie locala este utilizata. Nodurile dintre acolade reprezinta rezultatele acestor
expresii.
Figura 6-9 Interpretarea unui document XML ca o structura a unui sistem de
directoare
Similar cu caile dintr-un sistem de fisiere, putem defini expresii XPath, descriind
calea dintr-un document XML. Similar cu sistemul de fisiere, distingem o adresare
relativa si una absoluta. XPath ofera o varietate larga de modele de cautare în XML.
De exemplu, am putea folosi pe lânga elementele XML atribute. Mai mult decât atât,
XPath ne permite accesul "axe", cum sunt, descendentii si stramosii. Aceasta
înseamna ca putem sa formulam în mod arbitrar expresii complexe, care pot fi apoi
folosite pentru a parcurge documentele XML pe baza DOM-ului.

XSL-FO - eXtensible Stylesheet Language Formatting Objects

XSL-FO reprezinta o definitie a obiectelor de tip media pentru diferite
reprezentari. XSL-FO nu este legat exclusiv de elementele media vizuale, cum ar fi
ecrane, imprimante, sau documente. De fapt, standardul permite includerea
reprezentarilor audio. Proprietatile importante ale "obiectelor de formatat" se
refera la paginare, proprietatile layout-ului (de exemplu, font), sau structurarea
obiectelor în functie de orientarea lor si de margini.
Acest standard reprezinta o punte de legatura între continutul definit într-un
XML media independent si iesirea dependenta de platforma (de exemplu, un
document în format PDF). Figura 6-10 utilizeaza doi pasi de prelucrare pentru a
demonstra modul de functionare. În primul rând, un procesor XSLT utilizeaza o foaie
de stil XSLT pentru a procesa continutul definit în XML. Rezultatul acestui pas de
procesare reprezinta o instanta a unui obiect formatat definit în specificatia XSL-FO.
Ulterior, printr-un "formatator" sunt utilizate resursele de formatare, cum ar fi
imaginile si fonturile, pentru a fi create iesirile media specifice. Iesirile media
utilizate în acest exemplu sunt un document PDF, o imprimanta, si un ecran.
Figura 6-10 Imagine schematica a interactiunii dintre XML, XSLT si XSL-FO
XSL reprezinta un instrument puternic pentru a transforma XML. Limbajul
XSLT include o multime de transformari, care pot crea iesiri dedicate. Deoarece în
mod inerent XSLT actualizeaza modificarile, pentru ca separa de datele/continutul de
reprezentarea acestora (transformare), circumstantele utilizarii XSLT-ului sunt
similare cu cele care contribuie la selectarea unei arhitecturi.
6.5 Tehnologii server-side
6.5.1 Agenti URI

Agentii URI sunt aplicatii speciale utilizate pentru a procesa cererile HTPP si
transmite o resursa solicitata. Practic, un URI este utilizat pentru a identifica instanta
care proceseaza cererea. Aceasta instanta - manipulatorul URI specializat - preia
cererea si o trimite mai departe pentru executie. Rezultatul executiei este returnat
apoi serverului Web, care, la rândul sau, trimite resursa agentului utilizator.
Server-Side Includes (SSI)
Un SSI reprezinta un mecanism simplu care permite crearea imediata a paginilor
HTML compuse din fragmente de text. Acest mecanism este implementat de un pre-
procesor pentru paginile HTML, care în mod normal este integrat în serverele web
moderne.
O pagina HTML care foloseste SSI este transmisa catre pre-procesor atunci când un
browser Web le solicita. Iesirea pre-procesor-ului este apoi livrat de catre server.
Serverul identifica în general astfel de pagini printr-o extensie speciala de fisier (în
mod normal, shtml).
Comenzile utilizate pentru a controla pre-procesorul sunt incluse în comentariile
SGML si au urmatoare forma:
<!--#atributul comenzii=valoare ... atribut=valoare -->
Valoarea comenzii specifica tipul comenzii, care este parametrizat de catre o lista
atribut-valoare. SSI accepta urmatoarele comenzi:
· include: aceasta comanda este înlocuita de continutul unui fisier, specificata fie
prin calea catre un fisier sau un URL (prin intermediul unui fisier sau atribut virtual).
· exec: acesta este un program la care calea catre fisierul acestuia este
specificata de atributul cmd. Este executat sale de productie si înlocuieste comanda.
Anumite extensii de SSI (de exemplu, XSSI) includ comenzi suplimentare pentru iesiri
text conditionate sau pentru definirea si returnarea variabilelor.
Desi SSI nu mai este folosit pe o scara larga, tehnologia a avut o contributie majora la
progresul noilor abordari si asupra metodelor moderne de manipulare a URI-urilor.
Cele mai moderne metode de a manipula URI-ri au înlocuit SSI-ul, cu mai multe
concepte. Oricum, SSI-ul poate fi folosit îndeosebi pentru pagini care sunt, în
principal, statice, sau pagini care dispun de mijloace auxiliare de navigare.
CGI/FastCGI
CGI este o interfata standardizata între serverele web si programele de aplicatii care
trimit datele dintr-o cerere HTTP un program al aplicatiei. Programul aplicatiei este
specificat prin formarea unui URL sub forma etichetelor de pe pagina HTML apelata.
Acest program citeste parametrii din cerere, le proceseaza si creaza o iesire (de
obicei un document HTML). Orice limbaj de programare disponibil pe o platforma
server poate fi utilizat; de obicei sunt folosite limbaje ca Perl, C, C++ sau Python. O
mare lipsa a texhnologiei CGI este scalabilitatea limitata, deoarece pentru fiecare
cerere venita trebuie pornit un proces independent. Acest lucru poate determina o
depasire considerabila a resurselor, în special atunci când mai multe cereri
concurente trebuie sa fie procesate. Aceasta situatie a condus la introducerea
FastCGI, un standard care permite programelor de aplicatii sa deserveasca mai multe
cereri în paralel.
Scripting Server-Side
În aceasta sectiune vom prezenta PHP (Hypertext Preprocessor), o solutie
open-source care poate fi folosita în locul solutiei ASP (Active Server Pages) oferite
de Microsoft. Alte tehnologii reprezentative sunt Cold Fusion si JavaScript Server-
Side oferit de Netscape ca o parte a programului LiveWire. Toti agentii URI
mentionati definesc un limbaj de scripting. Comenzile acestor limbaje de scripting
sunt incluse în resursele HTML si executate pe server de catre un interpretor de
scripturi, înainte de livrarea resurselor.
PHP reprezinta o tehnologie open-source si server-side, existând versiuni
disponibile pentru majoritatea serverelor web si pentru toate sistemele de operare.
Similar cu SSI, instructiuni speciale pentru un pre-procesor sunt adaugate în paginile
HTML, care sunt prelucrate de catre acel pre-procesor înainte de a fi transmise.
Scripturile sunt stocate în fisiere speciale, cu extensia de fisier .PHP. În consecinta,
este vorba de implementarea unui suport pentru generarea dinamica a resurselor,
pentru care costul sau de prelucrare este oarecum redus în acea resursa, si care,
odata creata pe server este pastrata într-o memorie cache si poate fi adusa din
cache daca este solicitata ulterior.
În timp ce instructiunile SSI permit inserarea în continutul unui fisier, acesta
nu ofera nici o modalitate de a interveni în fluxul de control al pre-procesorului.
Metodele de scripting pe partea de server permit executarea de codului unui
program încorporat în HTML (asa-numitele scripturi), care sunt scrise într-un limbaj
de programare interpretat.
 Conform statisticilor PHP este instalat pe 20 de milioane de situri web si pe 1
milion de servere web, fiind disponibil sub licenta PHP si Free Software Foundation,
fiind astfel un software liber.
Servlet-uri

Servlet-urile reprezinta o îmbunatatire a tehnologiei CGI în mediul Java. Similar cu

programele CGI, servlet-urile sunt invocate de catre URL-uri speciale pentru a
procesa cererile si genera apoi pagini de raspuns HTML în mod direct. Servlet-urile
ruleaza într-un mediu special (asa-numitele containere servlet), care sunt în
întregime integrate în serverul Web.
Un mare avantaj al servlet-urilor fata de CGI este capacitatea lor de multi-
threading. Servlet-urile pot procesa mai multe cereri concomitent pe fire diferite din
cadrul unui mediu de lucru. În plus, ele ofera un API vast pentru programarea
aplicatiilor web si un numar mare de caracteristici integrate, în special, mecanisme
de securitate Java. Mai mult decât atât, servlet-urile ofera o modalitate eleganta de
urmarire a sesiunii prin utilizarea de cookie-uri si obiecte HttpSession pentru a
accesa datele sesiunii.
Java Server Pages
Java Server Pages (JSP) sunt proiectate pentru a simplifica programarea paginilor
HTML sofisticate din punct de vedere grafic.
Java Server Pages extinde paginile HTML conventionale cu tag-uri JSP speciale,
permitând integrarea codului programelor Java pentru a crea continut dinamic. În
momentul invocarii lor, mediul de lucru traduce JSP-urile în servlet-uri, si apoi creaza
paginile de raspuns HTML corespunzatoare.
ASP.NET
ASP.NET reprezinta urmatoarea generatie Microsoft Active Server Pages. Noua
componenta tehnologica, asamblarea, si CLR (Common Language Runtime) formeaza
coloana vertebrala a unei întregi noi game de tehnologii.
De exemplu, ASP.NET permite generarea paginilor de la Server Controls pentru a
separa codul de continut, simplificând proiectarea paginilor dinamice. În plus, .NET
ofera suport dedicat pentru implementarea si utilizarea serviciilor web. ASP.NET
ofera avantaje considerabile pentru dezvoltarea de aplicatii web moderne distribuite
si aplicatii bazate pe servicii Web.
6.5.2 Servicii web

De la aparitia serviciilor web si introducerea SOAP-ului, au fost publicate un numar

mare de îmbunatatiri si protocoale. Aceste produse sunt proiectate sa acopere
lacunele existente sau sa implementeze concepte care aduc îmbunatatiri. În
continuare vom discuta doar tehnologiile de baza ale serviciilor web si nu vom
aborda protocoale suplimentare cum ar fi WS-Security, WS-Transaction sau WSCI.
SOAP - Simple Object Access Protocol

Simple Object Access Protocol (W3C 2003a) reprezinta un modalitate simpla

de a face schimb de mesaje pe baza XML-ului. Astfel de abordari comparabile, sunt,
de exemplu, Internet Inter-ORB Protocol (IIOP) în CORBA, Sun's Remote Method
Invocation (RMI) în Java sau .NET de la Microsoft. Pentru a permite serviciilor web sa
comunice fara probleme, este necesar un protocol uniform pentru mesaje,
independent de platforma utilizata. SOAP este un astfel de protocol pentru mesaje
bazat pe XML. De notat ca SOAP nu poate rezolva toate problemele; nu rezolva
probleme ca transportul mesajelor sau corelarea semantica. Asa cum sugereaza si
numele, SOAP este proiectat pentru a defini un simplu format de comunicare. De
exemplu, Remote Procedure Calls (RPCs) poate fi implementat si permite formularea
de mecanisme simple pentru schimbul de mesaje în sistemele distribuite. În general,
SOAP transmite informatiile ca date XML. Informatiile binare, cum ar fi fisierele
imagini, pot fi adaugate de catre MIME (Multipurpose Internet Mail Extensions) în
mod similar cu Microsoft BizTalk Server.
Deoarece SOAP specifica doar cum ar trebui sa arate mesajele, sunt necesare
protocoale de transport suplimentare pentru a trimite si receptiona aceste mesaje.
Standardul nu defineste un anumit protocol de transport. De fapt, poate fi folosit
orice protocol, cum ar fi HTTP, SMTP (Simple Mail Transfer Protocol) sau protocoale
proprietare bazate pe TCP/IP. Dintre acestea, protocolul HTTP este cel mai frecvent
folosit. De exemplu, SOAP 1.1 defineste modul în care mesajele specificate în SOAP
pot fi schimbate peste HTTP. Specificatiile SOAP constau din trei parti:
- plic SOAP: specifica ce date sunt incluse într-un mesaj (corp SOAP), ce date pot fi
incluse în mod optional (antet SOAP) si modul în care acestea ar trebui sa fie
prelucrate;
- reguli de codificare SOAP: aceste norme specifica, de exemplu, cum datele definite
de utilizator trebuie serializate;
- reprezentarea RPC a SOAP-ului: daca SOAP este utilizat pentru a lucra cu Remote
Procedure Call, atunci reprezentarea RPC este responsabila de unde si cum ar trebui
mesajele sa fie codificate.
SOAP este proiectat pentru a utiliza aceste trei parti, independent una de alta. Cele
mai mari beneficii ale acestei modularitați este ca fiecare parte poate fi înlocuita si
adaptata la situații specifice.
WSDL - Web Service Description Language
Consumatorii si furnizorii unui serviciu trebuie sa ajunga la o întelegere comuna, de
exemplu, o interfata comuna pentru a putea face schimb de mesaje. Web Service
Description Language (WSDL) (W3C 2003b) este un limbaj proiectat pentru a defini
astfel de interfete (Interface Definition Language, IDL) pentru serviciile Web. WSDL
descrie modul în care un utilizator al unui serviciu Web trebuie sa-si planifice
apelurile de functii. Acesta specifica ce fel de mesaje poate accepta un serviciu, ce
informatii (parametri) trebuie sa fie inclusi în mesaj si cum ar trebui sa fie structurat.
În plus, utilizatorul specifica cum va fi construit raspunsul la cererea lui si cum vor fi
interpretate informatiile returnate. WSDL este un alt dialect XML folosit de serviciile
Web (furnizorii de servicii) pentru a descrie modul în care aceste servicii vor utiliza
mesajele pentru a comunica cu utilizatorii lor (consumatorii de servicii). Serviciile
Web pot utiliza unul sau mai multe porturi de comunicare, care vor schimba mesaje
pentru a realiza apelurile de functii si pentru a transmite documentele.
O descriere WSDL este alcatuita din elemente de baza si extensii. Elemente de baza
descriu un serviciu si porturile, tipurile de porturi si mesajele pe care le utilizeaza.
Extensiile permit adaugarea constructorilor XML arbitrari, cum ar fi tipurile de date
definite de utilizatori. În consecinta, documentele WSDL reprezinta un acord de
stabilire a metodelor si a conventiilor de apelare a unui serviciu pe care
consumatorul trebuie sa le examineze atunci când utilizeaza acel serviciu Web.
UDDI - Universal Description, Discovery, and Integration
UDDI (http://www.uddi.org) este un director de servicii Web care ajuta clientii
(solicitanti de servicii) si serverele (furnizori de servicii) sa se gaseasca unul pe altul.
UDDI foloseste SOAP pentru comunicare. UDDI este deseori comparat cu Paginile
Aurii, deoarece UDDI permite companiilor posibilitatea de a oferi produse si servicii
în functie de nume, produs, locatie, si alte criterii.
6.5.3 Tehnologii middleware
Servere de aplicatii
Serverele de aplicatii sunt legate de conceptul de arhitectura pe trei straturi. Ele
denota o platforma software utilizata pentru a procesa tranzactiile online (OLTP).
Arhitectura pe trei straturi muta logica aplicatiei de la client la serverul de aplicatii.
Clientul executa în mod normal un asa-numit thin client, fara nici o logica. Cel de-al
treilea strat este reprezentat de sistemele backend, cum sunt mainframe-urile sau
serverele corporatiei. Figura 6.12 arata modul în care interactioneaza cele trei
straturi.
În acest scenariu, serverul de aplicatii reprezinta un mediu pentru dezvoltarea si
functionarea aplicatiilor distribuite, bazate de componente. În acest scop, acesta
ofera o serie de servicii, cum ar fi tranzactiile, punerea în comun a resurselor,
echilibrarea sracinilor (load balancing), numirea sau directorul de servicii.
Majoritatea serverelor de aplicatii suporta specificatiile Java 2 Enterprise Edition
(J2EE), Java servlets, Java Server Pages, Enterprise Java Beans, CORBA, etc. Vechile
servere de aplicatii, asa-numitele monitoarele "procesoare de tranzactii", pot fi
programate în C, C + + sau COBOL.
Enterprise Java Beans
Enterprise Java Beans (EJBs) reprezinta o arhitectura bazata pe componente pentru
dezvoltarea de aplicatii Java distribuite client/server deschise si independente de
platforma. Arhitectura EJB a fost dezvoltata de Sun Microsystems si publicata în
specificatiile unui furnizor independent. Enterprise Bean implementeaza fie logica
aplicatiei (session bean), fie reprezinta datele (entity bean). Dependent de
functionalitatile acestora, aplicatiile distribuite pot fi compuse dintr-un numar mare
de EJB-uri. Enterprise Beans ruleaza într-un mediu runtime special numit de
container EJB. Containerul EJB este un server de aplicatii care ofera servicii de sistem
integrate, cum sunt: suportul pentru tranzactii, persistenta obiectelor sau Java
Naming si Directory Interface (JNDI). Figura 6-13 prezinta aceste componente de
baza.
Majoritatea proprietatilor lui Enterprise Bean, cum sunt tranzactiile sau controlul
caracteristicilor bazelor de date, sunt definite într-un fisier de configurare (descriptor
de implementare), atunci când este instalat într-un container EJB.
Sistemul de mesaje ofera posibilitatea de comunicare asincrona între sisteme,
într-un mediu distribuit. Sistemele sursa si destinatie dintr-un astfel de mediu
comunica prin schimbul de mesaje. În functie de gradul de încarcare si de
disponibilitate a sistemului destinatie, un sistem sursa poate sa astepte pentru ca un
mesaj sa ajunga. Sistemele de mesaje sunt grupate de doua tipuri distincte de
comunicare: comunicarea cerere/raspuns între exact doua masini (peers) din mediul
de lucru si comunicarea publica/aboneaza. În comunicarea publica/aboneaza,
abonatii înregistrati la un serviciu de mesaje aferent unui anumit subiect, vor primi
ulterior mesaje de la toti editorii.
6.5.4 Concluzii
Tehnologiile care vor avea succes în ingineria web viitoare sunt greu de prezis. XML,
ca tehnologie de baza, a determinat o mutatie majora în ceea ce priveste
omogenizarea mediilor eterogene. XML a determinat aparitia altor standarde bazate
pe XML, care au fost si vor fi din ce în ce mai mult mai folosite. De exemplu, Web
Services, tehnologiile XSL au un mare potential în ceea ce priveste utilizarea
scenariilor, deoarece, datorita XML-ului ele pot construi pe baza unor premise
omogene.
Implementarea cerintelor aplicatiilor web necesita o abordare bine pusa la
punct. Cerintele specifice de implementare a tehnologiilor îsi au originea în alte
etape de dezvoltare, cum ar fi, de exemplu, analiza cerintelor, proiectarea
dependenta de tehnologie sau cerinte arhitecturale si de securitate. Aceasta
înseamna ca implementarea aplicatiilor web va trebui sa urmeze un corect "cum",
dupa un pre-dat "ce".
VII Testarea aplicatiilor web
Aplicatiile web s-au dezvoltat într-o platforma de comunicare de baza pentru multe
companii. Aplicatiile web sunt cruciale pentru comert, schimbul de informatii si
pentru gazduirea activitatilor sociale. Din acest motiv, aplicatiile web trebuie sa
ofere o înalta performanta, fiabilitate si o mare usurinta în folosire. Furnizarea unor
aplicatii web de calitate pentru utilizatorii existenti si cei viitori reprezinta o
provocare majora pentru asigurarea calitatii. Testarea este una dintre cele mai
importante masuri de asigurare a calitatii. Metodele si tehnicile de testare
traditionale se concentreaza în principal pe testarea cerintelor functionale. Din
pacate, acestea nu se concentreaza suficient pe o cerintele de calitate importante
pentru utilizatorii de aplicatii Web, cum ar fi performanta, usurinta în folosire,
fiabilitatea si securitatea. O provocare majora în testarea aplicatiilor web este
dominanta schimbarii. Cerintele utilizatorilor si asteptarile, platformele si
configuratiile, modelele de afaceri, dezvoltarea si testarea bugetelor sunt subiecte
supuse unor modificari frecvente pe tot parcursul ciclului de viata al aplicatiilor web.
Prin urmare, este necesara dezvoltarea unui sistem eficient de testare care sa
acopere o gama larga de caracteristici de calitate ale aplicatiilor web, care sa faca
fata la schimbari si care sa ajute la implementarea si buna întelegere a unei testari
sistematice, complete si lipsita de riscuri. O astfel de schema de test formeaza baza
pentru construirea unei metode model si a instrumentelor aferente. Experienta
practica a demonstrat ca testarea metodica si sistematica fundamentata pe o astfel
de schema este realizabila si utila pe tot parcursul dezvoltarii si evolutiei aplicatiilor
web.
Aplicatiile web sunt expuse unor noi provocari privind asigurarea calitatii si testarea.
Aplicatiile web sunt compuse din diverse componente software oferite în anumite
cazuri de anumiti producatori. Calitatea aplicatiilor web este în principal determinata
de calitatea fiecarei componente software implicate si de calitatea legaturilor dintre
acestea. Testarea este una din cele mai importante instrumente folosite în
dezvoltarea aplicatiilor web pentru realizarea produselor de înalta calitate, care
îndeplinesc asteptarile utilizatorilor.
Testarea aplicatiilor web merge dincolo de testarea software-ului din sistemele
traditionale. Desi se aplica cerinte similare la corectitudinea tehnica a unei aplicatii,
utilizarea unei aplicatii Web de catre grupuri eterogene de utilizatori, pe un numar
mare de platforme, duce la cerinte speciale de testare. Deseori este greu de
anticipat numarul viitor de utilizatori pentru o aplicatie web. Timpul de raspuns este
unul din factorii de succes decisivi pe Internet si trebuie sa fie avut în vedere din
timp, chiar daca platforma hardware finala este, în general, disponibila mult mai
târziu. Alti factori importanti pentru succesul aplicatiilor web sunt usurinta în
folosire, disponibilitatea, compatibilitatea browserelor, securitatea, actualitatea si
eficienta.
7.1 Fundamentele testarii
7.2.1 Terminologie

Testarea este o activitate efectuata pentru a evalua calitatea unui produs si pentru a
îmbunatati-o prin identificarea problemelor si defectelor. Daca vom rula un program
cu intentia de a gasi erori, atunci putem vorbi de testare. Figura 7-1 arata ca testarea
este parte a masurilor de asigurare a calitatii analitice. Prin descoperirea erorilor
existente este determinata calitatea programului testat, în vederea îmbunatatirii
calitatii, acest lucru realizându-se de cele mai multe ori doar prin eliminarea erorilor
gasite.
Putem spune ca o eroare este prezenta în cazul în care rezultatul actual dintr-un test
nu este în conformitate cu rezultat asteptat. Rezultatul asteptat este specificat, de
exemplu, în definirea cerintelor. Aceasta înseamna ca fiecare abatere de la definirea
cerintelor este o eroare; în termeni mai generali, o eroare este "diferenta între
valoarea sau conditia calculata, observata sau masurata si valoarea corecta sau
conditia adevarata, specificata sau teoretic corecta" (standard IEEE 610.12-1990).
Aceasta definitie implica faptul ca definirea cerintelor utilizate ca baza pentru testare
este terminata si disponibila înainte de implementare si testare. Un fenomen comun
în dezvoltarea aplicatiilor web este ca cerintele sunt deseori incomplete, neclare si
reprezinta subiectul unor schimbari frecvente. De obicei, exista o viziune initiala
privind functionalitatea de baza, care este implementata în faza initiala de lansare.
Ca urmare, dezvoltarea ciclului initial de viata este urmata de mici cicluri de
functionalitati adaugate. Abordarile Agile (cum ar fi Extreme Programming) se
concentreaza pe natura evolutiva si repetata a dezvoltarii ciclului de viata fara a
apela la o definire extinsa a cerintelor. În consecinta, obiectivele, preocuparile si
asteptarile partilor interesate (mandatari) trebuie sa constituie baza testarii. Aceasta
înseamna ca, de exemplu, fiecare abatere de la valoarea asteptata în mod firesc de
catre utilizatori este, de asemenea, considerata o eroare.
În acest moment, partile interesate au asteptari diferite, iar unele dintre acestea pot
fi concurente si neclare. Din acest motiv, asteptarile partilor interesate nu vor fi un
reper util pentru a decide daca un rezultat este eronat, cu exceptia cazului în care un
set de asteptari au fost atinse si au fost puse la dispozitie în forma testabila. Pentru a
sprijini testerii în a avea o perspectiva a utilizatorilor si de a întelege mai bine
asteptarile utilizatorilor, acestia ar trebui sa fie implicati cât mai devreme posibil în
identificarea si definirea cerintelor.
Când discutam despre un test ne vom referi la un set de cazuri de testare
pentru un anumit obiect testat (de exemplu, o aplicatie web, componentele unei
aplicatii Web sau un sistem care ruleaza o aplicatie Web). Un singur caz de test
descrie un set de intrari, conditiile de executie, precum si rezultatele asteptate, care
sunt utilizate pentru a testa un anumit aspect al obiectului testat (standard IEEE
610.12-1990).
7.2.2 Caracteristici de calitate
Un utilizator nu asteapta doar ca o aplicatie sa se comporte într-un anumit mod; de
asemenea, se asteapta ca anumite functii sa fie disponibile 24 de ore pe zi si 7 zile pe
saptamâna (24x7). Mai mult, utilizatorii se asteapta ca aplicatia sa fie usor de utilizat,
fiabila, rapida si compatibila cu alte sisteme si versiuni viitoare. Pe lânga
comportament, de o deosebita importanta este testarea aplicatiei prin prisma
cerintelor de calitate (de exemplu, tipurile de caracteristici de calitate asteptate de
catre utilizatori).
 În contextul aplicatiilor web, trebuie avute în vedere diferite caracteristici de
calitate. O taxonomie generala pentru caracteristicile de calitate ale produselor
software este specificata în standardul ISO/IEC 9126-1. Acest standard mentioneaza
sase categorii de caracteristici principale: functionalitate, fiabilitate, usurinta în
folosire, eficienta, mentenanta si portabilitate si le divide în continuare în mai multe
sub-caracteristici.
Cerintele de calitate joaca un rol esential în testarea aplicatiilor web. Chiar
daca acestea sunt în general similare cu cerintele de calitate pentru sistemele
software traditionale, ele ajung deseori dincolo de ele. Datorita importantei
caracteristicilor de calitate si diferentelor privind modul în care pot fi testate,
majoritatea metodelor de testare pentru aplicatiile Web se concentreaza pe una sau
câteva caracteristici de calitate. Cu toate acestea, toate caracteristicile de calitate
sunt importante pentru calitatea generala a unei aplicatii Web. Testarea trebuie sa
se asigure ca acestea sunt implementate cu succes.
7.2.3 Obiectivele testarii
Testarea nu va duce la îmbunatatirea calitatii cu exceptia cazului în care erorile sunt
detectate si eliminate. Principalul obiectiv al testarii este de a gasi erori și nu de a
arata absenta lor. Testele software sunt inadecvate pentru a dovedi absenta unor
erori. Daca un test nu gasește erori, atunci acest lucru nu înseamna ca testat cererea
nu contine nici un fel. Acestea, pur si simplu nu au fost înca detectate.
Numarul mare de caracteristici de calitate, toate valorile de intrare si combinatiile de
intrare potentiale care trebuie luate în considerare, inclusiv toate conditiile si
procesele potentiale, fac imposibila realizarea unei testari complete. Chiar si o paleta
larga de teste este de obicei imposibila, datorita ciclurilor de dezvoltare extrem de
scurte. Consecintele inevitabile sunt erorile în functiile testate si un risc mai mare în
apariția erorilor nedetectate. Acestea sunt motivele pentru care testarea tinde spre
o abordare bazata pe risc. Aceste parti ale unei aplicații în care erorile sunt
nedetectate si în care au consecințe critice, ar trebui sa fie testate primele,
acordânduli-se o atenție sporita. Explorând sursele de risc putem semnala defectele
mult mai direct decât pe fundamentarea testelor pe baza cerintelor. În consecinta,
un obiectiv important al testarii este de a aduce riscul la lumina.
Un test rulat are succes daca sunt detectate erori și daca sunt obținute informatii
suplimentare despre problemele si starea aplicației. Testele nereusite, cum ar fi,
testele în care nu sunt gasite erori, sunt "o pierdere de timp". Acest lucru este valabil
mai ales în dezvoltarea aplicatiilor web, în care testarea este în mod necesar limitata
la un minim, datorita resurselor limitate si presiunii de timp extreme în care se
dezvolta aplicatiile Web. Aceasta situatie necesita, de asemenea, descoperirea
erorilor grave cât mai devreme posibil pentru a evita investitiile inutile cum ar fi
costurile de gasire si eliminare a erorilor care cresc dramatic în fiecare etapa de
dezvoltare. Erorile care au aparut în fazele timpurii de dezvoltare sunt greu de
localizat în etapele ulterioare, si eliminarea lor cauzeaza, în mod normal, modificari
ample si necesitatea de a rezolva erorile ulterioare. Prin urmare, testare trebuie
începuta cât mai devreme posibil, preferabil la începutul unui proiect.
Pe scurt, putem spune ca ciclurile de testare, în general, si pentru proiectele
Web în particular, trebuie sa detecteze cât mai multe erori posibile, în mod ideal cât
mai multe erori grave, la cel mai mic cost posibil, într-o perioada cât mai scurta de
timp si cât mai devreme posibil.
7.2.4 Nivele de Test

În conformitate cu fazele de dezvoltare în care putem obține rezultate ale testarii,

putem identifica anumite nivele de test pentru facilitarea testarii acestor rezultate.
. testarea unitaților: testarea celor mai mici unitati testabile (clase, pagini web, etc),
independent una de alta. Unitatea de testare este obținuta de dezvoltator, pe
parcursul implementarii.
. testele de integritate: evaluarea interactiunii între unitațile testate distinct si
separat dupa ce acestea au fost integrate. Testele de integritate sunt de obicei
efectuate de catre un tester, un dezvoltator sau de ambii.
. testele sistem: testarea completa, integrata a sistemului. Teste sistem sunt, de
obicei, efectuate de catre o echipa de test specializata.
. testele de acceptare: evalueaza sistemul în cooperare cu sau sub patronajul
clientului într-un mediu apropiat mediului de productie. Testele de acceptare
utilizeza condițiii și date reale.
. testele beta: permit utilizatorilor sa lucreze cu versiunile timpurii ale unui
produs cu scopul de a oferi feedback-ul din timp. Testele beta sunt informale (fara
planuri de testare si cazuri de test) și se bazeaza pe numarul și creativitatea
potentialilor utilizatori.
Pe masura ce dezvoltarea progreseaza, cineva va realiza o verificare vizavi de
specificatiile tehnice (daca este cazul) - la fel ca în testarea unitaților, testarea
integritații si testarea sistemului - la o validare a asteptarilor utilizatorilor - la fel ca în
testele de acceptare si testele beta.
Un risc inerent care apare atunci când se efectueaza testele secvential în
acord cu fazele proiectului este ca pot apare erori datorita neîntelegerii asteptarilor
utilizatorilor (care pot fi gasite numai într-un stadiu târziu), ceea ce conduce la
costuri mari de eliminare a acestora. Pentru a minimiza acest risc, testarea trebuie sa
fie parte integranta a construirii produsului si ar trebui sa cuprinda întregul proces
de dezvoltare. Prin urmare, masurile de asigurare a calitatii cum sunt recenziile sau
prototipizarea sunt utilizate deseori înainte de a rula testarea unitatilor. Un proces
de dezvoltare iterativ si evolutiv reduce acest risc deoarece partile mai mici ale
sistemului sunt testate frecvent pe toate nivelurile de test (inclusiv cele cu validare
pentru asteptarile utilizatorilor), astfel încât erorile pot fi depistate înainte de a
putea avea un impact asupra altor parti ale sistemului. Aceasta înseamna ca
secventa nivelurilor de test descrise mai sus nu sunt în permanenta dictate de
succesiune temporala a testarii proiectul web, dar pot fi efectuate de mai multe ori
(de exemplu, o data pentru fiecare dezvoltare a functionalitatii).
7.2.5 Rolul tester-ului

Pentru a gasi cât mai multe erori posibile testerii trebuie sa aiba o atitudine
"distructiva" fata de testare. O astfel de atitudine este dificila pentru un dezvoltator
care lucreaza la un modul software. Aceeasi perspectiva de abordare face deseori ca
dezvoltatorii sa realizeze aceleasi greseli si neîntelegeri pe perioada de testare,
greseli care au condus la erori pe perioada implementarii. Din acest motiv, (Myers
1979) sugereaza ca dezvoltatorii sa nu testeze propriile produse.
În proiectele web, se observa o focalizare sporita pe testarea unitatilor care sunt
scrise de dezvoltatori. Desi acest lucru este o încalcare a sugestiilor lui Myers, testele
suplimentare sunt, de obicei, efectuate de persoane diferite de dezvoltatorul original
(de exemplu, de catre testerii recrutati de departamentul de afaceri al clientului).
Deoarece calitatea este întotdeauna o problema de echipa, o separare stricta a
testarii si dezvoltarii nu este recomandabila si prezinta un risc inerent în
împiedicarea cooperarii între programatori si testeri. În esenta, obiectivul urmarit
este de a detecta erori, erori care vor fi eliminate de catre dezvoltatori. În acest
scop, se recomanda o comunicare si o întelegere reciproca. Acest lucru înseamna
pentru tester: "Cel mai bun tester nu este cel care gaseste cele mai multe bug-uri
sau care stânjeneste majoritatea programatorilor. Cel mai bun tester este cel care
depisteaza cele mai multe bug-uri fixe. ".
Deoarece echipele de proiect web sunt multidisciplinare si cooperarea în echipa
este, de obicei, de scurta durata, este dificil pentru membrii echipei sa stabileasca un
nivel superior de încredere, necesara pentru o colaborare strânsa între dezvoltatori
si testeri.
7.3 Teste specifice ingineriei web
Elementele de baza prezentate anterior se aplica atât la testarea software-ului
traditional cât si în aplicatiile web. Testarea aplicatiilor web este diferita de testarea
produselor software traditionale, lucru datorat caracteristicilor specifice aplicatiilor
web:
. erorile din "continut" pot fi deseori gasite doar prin masuri costisitoare sau
organizationale (de exemplu, prin corectarea greselilor). Formularele simple de
verificare automata (de exemplu, un corector ortografic) sunt foarte valoroase, dar
sunt limitate la o paleta redusa de depistare a potentialelor defecte. Meta-
informatiile despre structurarea si semantica continutului sau despre un sistem de
referinta care furnizeaza valori comparative, sunt deseori o conditie prealabila
pentru a putea efectua testele de profunzime. Daca aceste premise nu sunt
disponibile, trebuie gasite alte abordari. De exemplu, daca apar schimbari frecvente
privind modificarea datelor legate de cantitatea de zapada dintr-un sistem de
informare turistica, acestea nu pot fi testate cu acuratete prin intermediul meta-
informatiilor sau valorilor comparative, si, în consecinta, valabilitate datelor poate fi
restrictionata euristic la doua zile pentru a se asigura actualitatea datelor.
. când testam structura hipertext, trebuie sa ne asiguram ca paginile sunt legate în
mod corect (de exemplu, fiecare pagina trebuie sa fie accesibile printr-o legatura si,
la rândul sau, ar trebui sa aiba o legatura înapoi la structura hipertext). În plus, toate
legaturile trebuie sa duca la pagini existente, adica, nu trebuie sa fie "întrerupte".
Legaturile nefunctionale sunt erori frecvente atunci când legaturile statice
predefinite devin invalide (de exemplu, atunci când se face referire la o pagina web
externa, care a fost eliminata sau s-a schimbat structura acesteia). O alta sursa de
erori este navigarea prin intermediul functiilor browser-ului web (de exemplu,
"Înapoi în Istoric", în asociere cu starile în care o aplicatie web poate fi). Un exemplu
tipic întâlnit este: daca un utilizator adauga un articol în cosul de cumparaturi virtual
în timp ce realizeaza cumparaturi online, atunci acest articol va ramâne în cosul de
cumparaturi, chiar daca utilizatorul se duce cu un pas înapoi în istoricul browser-ului,
afisând pagina anterioara fara acel articol.
. cerintele soft, subiective de pe nivelul prezentare al aplicatiilor web (de exemplu,
"estetica"), sunt dificil de specificat. Cu toate acestea, ele sunt este o conditie
prealabila esentiala pentru tester pentru a putea distinge în mod clar si obiectiv
comportamentul acceptabil (si de dorit) la defectele de comportament. Mai mult,
doar câteva metode si tehnici traditionale pentru testarea software-ul sunt adecvate
pentru testarea prezentarii. Pentru a testa o prezentare, trebuie sa fie utilizate
metode din alte discipline (de exemplu, publicistica tiparita si masurile
organizationale), în aceeasi masura cu asigurarea calitatii continutului.
. numarul mare de dispozitive si caracteristicile lor diferite de performanta
(distribuirea multi-platforma) reprezinta o alta provocare. Chiar daca un tester
dispune de toate dispozitivele posibile, acesta ar trebui sa ruleze cazurile de test
pentru fiecare dispozitiv. Desi simulatoarele pentru dispozitive pot fi de ajutor daca
tester-ul nu dispune de dispozitivul fizic, ele însele prezinta în majoritatea cazurilor
defecte.
. datorita disponibilitatii si utilizarii globale ale aplicatiilor web, exista o serie
de provocari în ceea ce priveste multi-lingvismul si usurinta în folosire în testarea
aplicatiilor web. Provocarea principala este de a recunoaste interdependentele
culturale si le ia în considerare în mod adecvat de test. De exemplu, ordinea de citire
în diferite culturi (de exemplu: araba, chineza) implica folosirea de ajutoare de
navigare laterale în fereastra browser-ului. O alta dificultate provine din lungimea
diferita a mesajelor de tip text în limbi diferite, care poate determina probleme în
afisarea layout-ului.
. "tineretea" si "multi-disciplinaritatea" echipelor sunt adesea legate de slaba
acceptare a metodologiilor si de nepromptitudinea în efectuarea testarii. Deseori,
trebuie acumulate pe parcurs cunostinte despre metodele, tehnologiile si
instrumentele necesare pentru realizarea testarii. De asemenea sunt necesare
puncte de vedere diferite cu privire la testare. Numai o echipa formata din membri
cu experienta vor ajunge la o decizie corecta despre volumul testarii - prea multa
testare poate fi la fel de neproductiva ca cea insuficienta. Testerii sunt deseori
tentati sa testeze tot în întregime, mai ales la început.
. aplicațiile web constau dintr-un numar de diferite componente software (de
exemplu: servere web, baze de date, middleware) si sisteme integrate (de exemplu:
sisteme ERP, sisteme de management al continutului), care sunt oferite de diferiți
furnizori, si implementate cu ajutorul unor tehnologii. Aceste componente formeaza
infrastructura tehnica a aplicatiilor Web. Calitatea unei aplicatii Web este în principal
determinata de calitatea tuturor componentelor software singulare si de calitatea
interfetei dintre ele. Aceasta înseamna ca, pe lânga componentele dezvoltate într-un
proiect, va trebui sa testam componentele software furnizate de parti terte, dar si
integrarea si configurarea acestor componente. Multe erori în aplicatiile web rezulta
din "imaturitatea" unei componente software, "incompatibilitatea" între
componentele software, sau defecte de configurare a componentelor software
corecte.
. "imaturitatea" majoritații metodelor și instrumentelor de testare reprezinta
provocari suplimentare pentru testeri. Daca o aplicatie Web este implementata cu o
tehnologie noua, de cele mai multe ori nu exista înca metode si instrumente de
testare adecvate. Daca instrumentele de testare devin disponibile, multe dintre ele
sunt imature, prezinta defecte si dificil de utilizat.
. "dominanta schimbarii" face ca testarea aplicatiilor web sa fie mai complexa decât
testarea software-ului traditional. Cerintele si asteptarile utilizatorilor, platformele,
sistemele de operare, tehnologiile si configuratiile Internet, modelele de afaceri si de
asteptarile clientilor, dezvoltarea si testarea bugetelor sunt subiectul unor frecvente
modificari pe tot parcursul ciclului de viata al unei aplicatii Web. Adaptarea la
cerintele noi sau modificate este dificila pentru ca functionalitatea existenta trebuie
sa fie reanalizata, ori de câte ori se face o schimbare. Aceasta înseamna ca un singur
fragment de functionalitate trebuie sa fie testat de mai multe ori, în ideea realizarii
unor teste automate si repeatable. Acestea pun accentul în special pe teste de
regresie, care verifica daca ceea ce s-a lucrat functioneza dupa o anumita schimbare.
Upgrade-urile si migrarea aplicatiilor web, determinate de schimbarile permanente
ale platformelor, sistemelor de operare sau hardware-ului, trebuie sa ruleze si sa
dovedeasca ca sunt un succes în mediul de test, pentru a ne asigura ca nu vor fi
probleme neasteptate în mediul de productie.
7.4 Abordari privind testarea
Abordarile Agile (cum ar fi Extreme Programming) sunt din ce în ce mai folosite în
proiectele web. În timp ce abordarile Agile se concentreaza pe colaborare,
abordarile traditionale se focalizeaza pe planificarea si managementul proiectului. În
functie de caracteristicile unui proiect web, poate fi necesara realizarea activitatilor
de testare folosind atât abordarile Agile cât si cele traditionale pe parcursul
proiectului. (Boehm si Turner 2003) descriu pe larg modul de a gasi a un echilibru
corect între agilitate si disciplina în proiecte. În continuarea, vom prezenta
caracteristicile abordarilor de testare traditionale si Agile, si vom evidentia modul în
care acestea difera.
7.4.1 Abordarile traditionale
Din perspectiva unei abordari traditionale, activitatile de testare dintr-un proiect
includ planificarea, pregatirea, executarea si raportarea:
. Planificarea: pasii planificarii definesc obiectivele de calitate, strategia generala de
testare, planurile de test pentru toate nivelurile de test, metodele metrice si de
masurare si testarea mediului.
. Pregatirea: Acest pas implica selectarea tehnicilor si instrumentelor de
testare si specificarea cazurilor de test (inclusiv datele de test).
. Executarea: Acest pas pregateste infrastructura de test, executa cazurile de test si
în final documenteaza si evalueaza rezultatele.
. Raportarea: Acest pas final rezuma rezultatele testelor si genereaza rapoartele
testarii.
Abordarile traditionale definesc rezultatele muncii (de exemplu, planul de calitate,
strategia de testare, planurile de test, cazurile de test, masuratorile testarii, mediul
de testare, rapoartele de testare) si rolurile (de exemplu, managerul testarii,
consultantul testarii, specialistul testarii, specialistul instrumentelor de testare),
precum si pasii detaliati pentru a crea rezultatele (de exemplu, analiza datelor de
test disponibile sau pregatirea/furnizarea datelor de test). Abordarile Agile, definesc
obiectivul de calitate si apoi se bazeaza pe echipa sa se auto-organizeze si sa creeze
un software care îndeplineste (sau depaseste) obiectivul de calitate.
Datorita ciclurilor scurte de a ajunge pe piata în care se dezvolta aplicatiile Web, este
necesar sa selectam doar cele mai importante rezultate ale muncii, rolurile cheie si
sa eliminam pasii de lucru inutili. Activitatile de testare trebuie sa fie începute cât
mai devreme posibil pentru a scurta perioada distribuirii. De exemplu, activitatile de
planificare si de proiectare pot fi finalizate înainte de începerea dezvoltarii, iar
rezultatele muncii pot fi verificate static, de îndata ce acestea devin disponibile.
Figura 7-2 demonstreaza ca acest lucru va scurta perioada de livrare, care respecta
astfel ciclurile scurte de dezvoltare ale aplicatiilor web.
Abordarile Agile presupun ca o echipa va gasi solutii la probleme, în comun si în mod
autonom (se bazeaza pe auto-organizare). Acest lucru se aplica, de asemenea, la
teste. Prin urmare, testarea nu este o chestiune de roluri ci de o mai mai buna
colaborare si utilizare a aptitudinilor disponibile în echipa. Aceasta înseamna ca
testarea este o activitate de dezvoltare integrata. Întreaga echipa este responsabila
pentru calitate si pentru testare.
Abordarile Agile omit activitatile care nu par sa promita un beneficiu imediat.
De exemplu, ele documenteaza anumite aspecte sau scriu planuri de test; în schimb,
ele comunica direct, exprimând în mod clar asteptarile. Membrii echipei trebuie sa
coopereze strâns si sa se "înteleaga" reciproc pentru a se asigura ca erorile sunt
depistate si analizate rapid, eliminate în mod eficient.
Într-o abordare Agile, dezvoltatorii efectueaza testarea unitaților, adica ei își
testeaza propria munca. Prin automatizarea acestor teste ale unitaților, acestea pot
fi folosite ca mici "detectoare ale schimbarii". De fiecare data când o mica porțiune
din aplicație nu mai functioneaza adecvat, schimbarea va fi detectata imediat.
Întârzierea între apariția unei erori si detectarea acesteia este redusa în mod
semnificativ, ceea ce face mai usor pentru dezvoltatori sa corecteze eroarea,
deoarece activitatile sau modificarile recente sunt înca proaspete în mintea lor. Pe
lânga feedback-ul rapid, testele automatizate sunt o cerinta prealabila importanta
pentru ciclurile scurte de dezvoltare si pentru refactoring (reproiectarea unui
program pastrându-se semanticile pentru reducerea redundanței si cresterea
calitații proiectarii).
Într-o echipa poate exista un tester dedicat, acceptat de echipa de
dezvoltatori care îsi asuma calitatea de conducator pentru asigurarea calitații, în
cadrul echipei. De asemenea, un tester poate pregati teste functionale (care sunt pe
un nivel mai mare de abstractizare decât testea unitaților dezvoltatorilor) si face
scripturile de test tolerante la modificari. În plus, tester-ul poate sprijini clientul cu
teste functionale scrise.
Urmatoarele practici de Extreme Programming (XP) au o influenta speciala asupra
asigurarii testarii si calitatii:
. programarea în pereche: accelereaza schimbul de cunostinte între dezvoltatori,
între dezvoltatori si testeri si, în general, în cadrul echipei. Similar cu inspectarea
software-ului, ajuta la detectarea din timp a erorilor.
. un client de pe site: este disponibil pentru întrebari privitoare la cerinte, în orice
moment si ia decizii în acest sens. Împreuna cu tester-ul, clientul de pe site
pregateste pentru testele functionale, care pot fi folosite pentru testele de
acceptare ulterior.
. integrarea continua: ne asigura ca acești mici pasi contribuie la minimizarea riscului
la modificari, si parcurge toate testele pentru o verificare continua a faptului ca
întregul sistem este infailibil.
. testarea înainte de dezvoltare: se refera la faptul ca testele sunt scrise înainte de
cod, asigurându-se ca "dezvoltatorii", se gândesc la "ce" înainte de a implamenta
"cum". Aceste teste sunt automatizate, astfel încât acestea sa poata fi folosite
pentru o integrare continua.
Abordarea Agile se refera în principal la testarea unitaților si la testele de acceptare.
În contrast, abordarile conventionale sunt folosite pentru integrarea și testarea
sistemului ("testarea în ansamblu").
7.5 Schema de testare
Aceasta sectiune descrie o schema generica pentru testarea aplicatiilor Web.
Schema de baza merges de test - test de cazuri, caracteristici de calitate, si de
nivelurile de test - descrise mai sus într-o uniforma si usor de setare. Schema
reprezinta un model pentru aplicatii Web de testare proiectat pentru a întelege mai
bine cum pot fi organizate de testare si de a sprijini sistematic, cuprinzator, si-a
riscului de testare constient de abordare. În formularul de aici si-a prezentat,
sistemul poate fi folosit pentru a vizualiza aspectele implicate în testare, structura
toate testele, si va servi ca un vehicul de comunicare pentru echipa.
This section describes a generic scheme for Web application testing. The scheme
merges the testing basics - test cases, quality characteristics, and test levels -
described above into a uniform and manageable setting. The scheme represents a
model for Web application testing designed to better understand how testing can be
organized and to support a systematic, comprehensive, and risk-aware testing
approach. In the form introduced here, the scheme can be used to visualize the
aspects involved in testing, structure all tests, and serve as a communication vehicle
for the team.