Proiectarea Web - Dezvoltarea Sistematica a Aplicatiilor Web

Proiectarea web - dezvoltarea sistematica a aplicaţiilor web

orientarea actuală în domeniul dezvoltării aplicaţiilor web - abordare ad-hoc şi o lipsă a metodelor de dezvoltare > calitate

construirea unui ciclu de viaţă a aplicaţiilor web, prezentarea conceptelor, tehnicilor, metodelor şi utilitarelor pentru dezvoltarea sistematică a aplicaţiilor web > evolutie, infrastructura

Proiectarea web ca disciplină ştiinţifică este influenţată de dezvoltarea aplicaţiilor web. Orientarea actuală în domeniul dezvoltării aplicaţiilor web este deseori caracterizată printr-o abordare ad-hoc şi o lipsă a metodelor de dezvoltare. Datorită complexităţii şi ritmului proliferării aplicaţiilor web, această abordare are un impact negativ asupra calităţii. Aplicaţiile web reprezintă un nou domeniu de aplicaţii cu propriile sale provocări asupra dezvoltării software-ului.

Este necesară construirea unui ciclu de viaţă a aplicaţiilor web, prezentarea conceptelor, tehnicilor, metodelor şi utilitarelor pentru dezvoltarea sistematică a aplicaţiilor web.

Web-ul, aplicaţiile web şi comunitatea web în ansamblu au evoluat de la apariţia Internet-ului la Web 2.0 şi la viziunea web-ului semantic, din acest motiv fiind esenţială renunţarea la abordarea de tip ad-hoc şi adoptarea principiilor proiectării web.

La nivel de infrastructură, web-ul este un spaţiu creat prin intermediul unor limbaje şi protocoale specificate formal. Deşi oamenii sunt implicaţi în crearea paginilor şi utilizarea legăturilor dintre acestea, interacţiunea acestora formează un model web la scară macroscopică. Aceste interacţiuni umane sunt guvernate de convenţii sociale, politici şi legi. Dezvoltarea aplicaţiilor web este rezultatul unei afaceri complexe şi este esenţial ca proiectarea care sprijină această dezvoltare să fie bine realizată. Acest lucru va permite studenţilor şi specialiştilor să proiecteze aplicaţii web de o calitate superioară pe baza principiilor de proiectare software experimentate şi de încredere.

I. Introducere în proiectarea aplicaţiilor web

Proiectarea web - utilizarea unei abordări sistematice şi cuantificabile pentru realizarea specificaţiilor, implementării, operaţiilor şi întreţinerii aplicaţiilor web de calitate superioară > tipuri de aplicaţii web

Aplicaţiile web de astăzi - sisteme software complexe care oferă servicii interactive şi personalizabile accesibile prin intermediul diferitelor dispozitive

Aplicaţie web = sistem software bazat pe tehnologiile şi standardele W3C, care oferă resurse web specifice (conţinut şi servicii) prin intermediul unei interfeţe utilizator numită browser web

Aplicaţiile web moderne sunt sisteme software complexe, iar dezvoltarea acestora necesită o abordare metodologică. Similar cu proiectarea aplicaţiilor software, proiectarea web implică utilizarea unei abordări sistematice şi cuantificabile pentru realizarea specificaţiilor, implementării, operaţiilor şi întreţinerii aplicaţiilor web de calitate superioară. Din punct de vedere al istoricului dezvoltării şi complexităţii distingem anumite tipuri de aplicaţii web: orientate pe documente, interactive, tranzacţionale, cu caracteristici ubicue sau trăsături ale web-ului semantic. Cerinţele particulare ale proiectării aplicaţiilor web rezultă din caracteristicile lor speciale din sfera produselor software, precum şi din dezvoltarea şi utilizarea lor. World Wide Web are o influenţă enormă şi permanentă asupra vieţii noastre. Economia, industria, educaţia, sănătatea, administraţia publică, divertismentul – majoritatea componentelor vieţii noastre au fost pătrunse de World Wide Web. Motivul acestei omniprezenţe constă în special în natura web-ului, caracterizată prin disponibilitatea globală şi permanentă dar şi prin accesul omogen la informaţiile distribuite la nivel global sub forma paginilor web[1].

Deşi iniţial web-ul a fost proiectat ca un mediu pur informaţional, în prezent el evoluează într-un mediu al aplicaţiilor. Aplicaţiile web de astăzi sunt sisteme software complexe care oferă

1

http://www.spc.ca/essentials/may0300.htm

servicii interactive şi personalizabile accesibile prin intermediul diferitelor dispozitive; ele oferă posibilitatea realizării tranzacţiilor între utilizatori şi de obicei stochează datele într-o bază de date. Elementul distinctiv al aplicaţiilor web comparativ cu aplicaţiile software tradiţionale este modul în care este utilizat web-ul: tehnologiile şi standardele sale sunt utilizate ca o platformă de dezvoltare şi ca platformă utilizator în acelaşi timp. O aplicaţie web poate fi definită astfel:

O aplicaţie web este un sistem software bazat pe tehnologiile şi standardele consorţiului World Wide Web (W3C), care oferă resurse web specifice (conţinut şi servicii) prin intermediul unei interfeţe utilizator numită browser web.

Această definiţie include în mod explicit tehnologiile şi interacţiunea cu utilizatorul. De aici putem deduce că tehnologii precum serviciile web nu sunt aplicaţii web, dar pot fi o parte a acestora, iar siturile web lipsite de componente software (cum sunt paginile HTML statice) nu sunt considerate aplicaţii web.

[1] Berners-Lee, T., WWW: Past, Present, and Future, IEEE Computer, 29 (10), 1996, pp. 69–77

Schimbări fundamentale ale web-ului - de la un mediu informaţional la un mediu al aplicaţiilor

Dezvoltarea aplicaţiiilor web - eveniment spontan, de obicei bazat pe cunoaşterea, experienţa şi practicile de dezvoltare ale dezvoltatorilor individuali, greu de reutilizat la modul ”Copy&Paste” şi având o documentare necorespunzătoare a deciziilor de proiectare > probleme de calitate şi dificultăţi de operare şi întreţinere

În ciuda schimbărilor fundamentale ale web-ului de la un mediu informaţional la un mediu al aplicaţiilor, situaţia actuală a dezvoltării ad-hoc a aplicaţiilor web ne aminteşte de practicile de dezvoltare a software-ului din anii 60’, înainte să se realizeze că dezvoltarea aplicaţiilor necesită mai mult decât experienţă în programare[1]. Dezvoltarea aplicaţiilor web este deseori privită ca un eveniment spontan, de obicei bazat pe cunoaşterea, experienţa şi practicile de dezvoltare ale dezvoltatorilor individuali, greu de reutilizat la modul ”Copy&Paste” şi având o documentare necorespunzătoare a deciziilor de proiectare. Deşi acest procedeu poate părea pragmatic, astfel de metode de dezvoltare rapide şi superficiale conduc deseori la probleme serioase privitoare la calitate şi implicit la dificultăţi de exploatare şi întreţinere. Aplicaţiile dezvoltate sunt deseori dependente de tehnologie, predispuse la erori şi sunt caracterizate prin lipsa performanţei, siguranţei, accesibilităţii şi deci a acceptării de către utilizatori[2]. Legătura strânsă dintre aplicaţiile web sporeşte pericolul răspândirii problemelor de la o aplicaţie la alta. Cauza acestei situaţii este complexă şi poate fi abordată din mai multe perspective: [1] 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][2] Fraternali, P., Tools and Approaches for Data-intensive Web Applications: A Survey, ACM Computing Surveys, 31 (3), September, 1999, pp. 227–263

Cauza acestei situaţii abordarea centrată pe document (authoring) presupusa simplitate a dezvoltării aplicaţiilor web (editoare, generatoare) cunoştinţele specifice din discipline relevante nu pot aplicate sau utilizate

Legătura strânsă dintre aplicaţiile web sporeşte pericolul răspândirii problemelor de la o aplicaţie la alta. Cauza acestei situaţii este complexă şi poate fi abordată din mai multe perspective:

- abordarea centrată pe document. Dezvoltarea aplicaţiilor web este încă deseori considerată a fi centrată pe document – o activitate de authoring care include crearea şi realizarea legăturilor din siturile web şi includerea elementelor grafice. Deşi anumite tipuri de aplicaţii web (de exemplu paginile principale, ziarele online) aparţin acestei categorii, o abordare de tip authoring nu este adecvată pentru dezvoltarea de aplicaţii web concentrate pe software;

2

http://www.spc.ca/essentials/may0300.htm

http://friendster.com/

http://bscw.gmd.de/

http://c2.com/cgi/wiki

http://hoohoo.ncsa.uiuc.edu/cgi/interface.html

- presupusa simplitate a dezvoltării aplicaţiilor web. Disponibilitatea largă a diferitelor utilitare, (cum ar fi editoarele HTML sau generatoarele de formulare) permite crearea de aplicaţii web simple, fără a fi necesare cunoştinţe de specialitate. De obicei, accentul se pune pe proiectarea vizuală şi nu pe structurarea internă sau programare. Aceasta duce la inconsistenţe şi redundanţă;

- cunoştinţele specifice din discipline relevante nu pot fi aplicate sau nu sunt utilizate. Există o concepţie greşită conform căreia dezvoltarea aplicaţiilor web este similară cu dezvoltarea aplicaţiilor tradiţionale şi din acest motiv pot fi utilizate metodele din Ingineria Software, în sensul abordării sistematice, cu măsuri adecvate de control a calităţii. Acest lucru este neadecvat în majoritatea cazurilor datorită caracteristicilor speciale ale aplicaţiilor web. În plus, concepte şi tehnici din domenii relevante (cum ar fi hypertext-ul sau interacţiunea om-calculator) nu sunt aplicate într-o manieră consecventă. Standardele de dezvoltare pentru aplicaţiile web de calitate sunt inexistente, acest lucru datorându-se şi relativ scurtei istorii a web-ului.

Proiectarea web - nu este un eveniment imediat Abordare disciplinară

aplicarea unei abordări sistematice şi cuantificabile (concepte, metode, tehnici şi utilitare) în analiza, proiectarea, implementarea, testarea, operarea şi întreţinerea aplicaţiilor web de calitatea superioară;

o disciplină ştiinţifică implicată în studiul acestei abordări Termeni din literatură asociaţi - proiectarea siturilor web, proiectarea hipermedia,

proiectarea documentelor, proiectarea conţinutului şi proiectarea software-lui Internet. >> PROIECTAREA WEB

Proiectarea web nu este un eveniment imediat; este un proces realizat pe tot parcursul ciclului de viaţă al aplicaţiei web, similar celor din ingineria software. În ce mod diferă proiectarea web faţă de proiectarea software-ului şi pot fi ele considerate discipline separate?

O disciplină poate fi definită ca un domeniu de studiu al ştiinţei, mai mult sau mai puţin independent, care include cercetarea, învăţarea şi diseminarea informaţiei ştiinţifice sub forma publicaţiilor. Numărul mare de publicaţii, cursuri, programe analitice, seminarii ştiinţifice şi conferinţe demonstrează că, în acord cu această definiţie, Proiectarea web poate fi considerată o ramură independentă a ingineriei software. Proiectarea reprezintă în general o aplicaţie practică a ştiinţei (în comerţ sau industrie) folosită în scopul dezvoltării aplicaţiilor într-un mod mai bun, mai rapid, mai ieftin şi mai sigur. Ingineria software este definită ca o aplicaţie a ştiinţei şi matematicii prin care capacităţile unui sistem de calcul sunt pot fi utilizate de oameni prin intermediul programelor, procedurilor şi documentaţiei asociate. Pe baza acestei definiţii şi a celei lui Deshpande[1], putem defini Proiectarea web în două moduri:

- Proiectarea web reprezintă aplicarea unor abordări sistematice şi cuantificabile (concepte, metode, tehnici, utilitare) în analiza cerinţelor, proiectarea, implementarea, testarea, exploatarea şi întreţinerea aplicaţiilor web de calitate superioară;

- Proiectarea web reprezintă şi disciplina ştiinţifică implicată în studiul acestor abordări.Termenii din literatură asociaţi sunt Proiectarea siturilor web, Proiectarea hipermedia, Proiectarea documentelor, Proiectarea conţinutului şi Proiectarea software-lui Internet. Prin comparaţie, ”Proiectarea web” este un termen concis, deşi dacă vorbim în mod strict nu este foarte precis: nu web-ul este proiectat, ci aplicaţiile web.

Din punct de vedere al Ingineriei Software, dezvoltarea aplicaţiilor web este un nou domeniu al aplicaţiilor. În ciuda anumitor similitudini cu aplicaţiile tradiţionale, caracteristicile speciale ale aplicaţiilor web necesită o adaptare a multor abordări ale Ingineriei Software sau chiar dezvoltarea unor abordări complet noi.

Principiile de bază ale Proiectării web pot fi descrise totuşi în mod similar celor din Ingineria Software:

- obiective şi cerinţe clar definite;- dezvoltarea sistematică, în faze, a aplicaţiilor web;- planificarea foarte atentă a acestor faze;

3

- auditul continuu al întregului proces de dezvoltare.Proiectarea web face posibilă planificarea şi repetarea proceselor de dezvoltare, facilitând

astfel evoluţia continuă a aplicaţiilor web. Aceasta permite nu doar reducerea costurilor şi minimizarea riscului pe parcursul dezvoltării şi întreţinerii, ci şi creşterea calităţii şi măsurarea calităţii rezultatelor fiecărei faze[2]. [1] 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[2] Mendes, E., Mosley, N., Web Engineering, Springer, 2006

Categorii de aplicaţii web

grade variate de complexitate - pur informaţionale sau aplicaţii de comerţ electronic complexe - 24 / 7

Remarcăm faptul că există o corelaţie între cronologia dezvoltării şi complexitate. De exemplu, aplicaţiile bazate pe fluxuri de lucru sunt bazate pe tranzacţii, adică nivelul superior de dezvoltare necesită o dezvoltare anterioară a unei categorii mai puţin complexe. Există şi excepţii de la această regulă pentru anumite categorii (de exemplu aplicaţiile orientate pe portaluri), care sunt recente din punct de vedere istoric dar au un grad scăzut de complexitate.

Aplicaţiile web ale organizaţiilor care au fost pe web încă de la începuturi au avut deseori un istoric al dezvoltării similar cu cel descris în figura 1.1. Dezvoltarea unei aplicaţii web poate fi începută în oricare din aceste categorii şi ulterior continuată către un nivel sporit de complexitate. Noile categorii sunt în general mult mai complexe, dar aceasta nu înseamnă că ele pot înlocui în totalitate vechea generaţie. Aplicaţiile web complexe pot fi în mod tipic alocate mai multor categorii odată: de exemplu, magazinele online de cumpărături integrează diferiţi furnizori de servicii, dar

4


oferă şi diferite posibilităţi de căutare, monitorizarea stării comenzilor şi în anumite cazuri chiar licitaţii online.

Putem sesiza că diferite categorii de aplicaţii web acoperă mai multe domenii tradiţionale ale aplicaţiilor, cum ar fi băncile online, dar în acelaşi timp creează noi domenii ale aplicaţiilor, cum ar fi serviciile de localizare (location-aware services). În cele ce urmează vom descrie trăsăturile relevante ale acestor categorii.

Siturile web axate pe documente sun t precursoare ale aplicaţiilor web. Paginile web sunt stocate pe un server web ca documente HTML statice şi sunt trimise clientului web ca răspuns la o cerere. Aceste pagini web sunt de obicei actualizate manual folosind utilitare corespunzătoare. Pentru siturile web care impun schimbări frecvente sau pentru cele cu un număr mare de pagini această actualizare creşte semnificativ costurile şi adesea are drept consecinţă prezentarea unor informaţii depăşite. În plus există pericolul apariţiei inconsistenţelor atunci când un anumit conţinut este prezentat frecvent, redundant pe mai multe pagini web pentru a uşura accesul. Principalele beneficii sunt simplitatea şi stabilitatea unui astfel de sit web dar şi timpul scurt de răspuns, paginile fiind deja stocate pe serverul web. Paginile principale statice şi paginile simple pentru micile afaceri aparţin acestei categorii. Odată cu apariţia standardului Common Gateway Interface (http://hoohoo.ncsa.uiuc.edu/cgi/interface.html) şi formularelor HTML, s-au dezvoltat şi aplicaţiile web interactive, oferind o primă formă de interactivitate prin intermediul formularelor, butoanelor radio şi meniurilor de selecţie. Paginile web şi legăturile către alte pagini sunt generate în mod dinamic în funcţie de datele introduse de utilizator. Exemple de astfel de categorii sunt expoziţiile virtuale, siturile de ştiri sau de planificare a călătoriilor.

Aplicaţiile web tranzacţionale oferă mai multă interactivitate, utilizatorul având posibilitatea de a interacţiona cu aplicaţia în modul citire dar şi de a realiza actualizări ale conţinutului de bază. De exemplu, un sistem informaţional pentru turism permite actualizarea conţinutului într-un mod descentralizat sau face posibilă rezervarea camerelor. Premisa necesară pentru un astfel de sistem implică existenţa unor sisteme de baze de date care permit manevrarea eficientă a unui conţinut în continuă creştere în cadrul aplicaţiilor web şi oferă posibilitatea unor interogări structurate. Băncile online, magazinele online şi sistemele de rezervare online pentru hoteluri aparţin acestei categorii.

Aplicaţiile web bazate pe fluxuri de lucru permit manevrarea fluxurilor de lucru în interiorul sau între diferite companii, autorităţi publice şi utilizatori privaţi. Pentru aceste aplicaţii este esenţială disponibilitatea unor servicii web adecvate pentru asigurarea interoperabilităţii[1]. Complexitatea acestor servicii, autonomia companiilor participante şi necesitatea ca fluxurile de lucru să fie robuste şi flexibile reprezintă principalele provocări. Aplicaţii ce fac parte din această categorie sunt soluţiile B2B (Business-to-Business) din comerţul electronic, aplicaţiile e-government în domeniul administraţiei publice sau suportul web pentru fluxurile de date ale pacienţilor în sectorul sănătăţii.

În timp ce aplicaţiile bazate pe fluxuri de lucru necesită o anumită structurare a proceselor şi operaţiilor automatizate, aplicaţiile web colaborative sunt folosite îndeosebi în scopul cooperării în operaţiile nestructurate (groupware), unde există o nevoie foarte pentru comunicaţie între utilizatori. Aplicaţiile web în colaborare suportă distribuirea informaţiei şi spaţiile de lucru (ex. WikiWiki - http://c2.com/cgi/wiki - sau BSCW - http://bscw.gmd.de/ -) pentru a genera, edita şi administra informaţiile distribuite. Acestea sunt utilizate şi pentru a păstra log-urile unor mesaje scurte (ca în Weblog-uri), pentru medierea întâlnirilor sau luarea deciziilor (ex. sisteme de argumentare precum QuestMap sau simple camere de discuţii), ca sisteme de planificare sau ca platforme de e-learning.

Deşi web-ul a fost iniţial caracterizat prin anonimitate, el a avut o orientare către web-ul social, în care utilizatorii îşi declină identitatea unei mici comunităţi cu interese similare. Weblog-urile sau sistemele de filtrare colaborative precum friendster (http://friendster.com), care oferă posibilitatea de a găsi atât obiecte de interes similare cât şi persoane cu interese asemănătoare, aparţin acestei categorii de aplicaţii.

Aplicaţiile web orientate pe portaluri oferă un singur punct de acces la surse de informaţie şi servicii separate/potenţial eterogene. Realizatorii de browsere (Microsoft, Netscape),

5

http://friendster.com/

http://bscw.gmd.de/

http://c2.com/cgi/wiki

http://bscw.gmd.de/


motoarele de căutare (Yahoo), serviciile online (AOL), conglomeratele media şi alte companii au sesizat cererea existentă pentru astfel de aplicaţii şi au oferit hub-uri centrale (aşa numitele portaluri) ca punct de acces la web. Pe lângă aceste portaluri generale, există diverse portaluri specializate cum ar fi portalurile pentru afaceri, portalurile pentru comerţ (sub forma mall-urilor online) şi portalurile pentru comunităţi. Portalurile pentru afaceri oferă angajaţilor şi/sau partenerilor afacerii un acces focalizat la diferite surse de informaţie şi servicii prin intranet sau extranet. Portalurile pentru comerţ sunt împărţite în pieţe orizontale şi verticale. Pieţele orizontale funcţionează pe piaţa B2C oferind bunuri de consum direct către public, şi în B2B, prin vânzarea de produse proprii unor companii din alte sectoare de activitate. Pieţele verticale sunt formate de companiile dintr-un singur sector de activitate, cum ar fi furnizorii pe de o parte şi producătorii pe de altă parte. Portalurile pentru comunităţi se adresează unor grupuri ţintă specifice (de ex. tinerii) şi încearcă să creeze o loialitate a clienţilor prin intermediul interacţiunilor cu utilizatorii sau să asigure oferte individuale printr-un management al utilizatorilor adecvat (marketing unu-la-unu).

O categorie importantă este reprezentată de aplicaţiile web omniprezente, care oferă servicii personalizate oricând, oriunde şi pentru orice dispozitiv, facilitând astfel accesul peste tot. Un exemplu poate fi afişarea meniului zilei pe dispozitivele mobile ale tuturor utilizatorilor care intră în restaurant între 11 am şi 2 pm. Pentru acest tip de sistem este important să luăm în calcul limitările dispozitivelor mobile (lăţimea de bandă, dimensiunea ecranului, memoria, lipsa de maturitate a software-ului) şi contextul în care aplicaţia web este utilizată în mod curent.

Dezvoltările prezente şi în special convergenţa sporită a industriei TIMES (telecomunicaţii, tehnologia informaţiei, multimedia, educaţie şi divertisment, securitate), vor conduce, în viitorul apropiat, la o situaţie în care aplicaţiile omniprezente vor domina piaţa. Una dintre aceste dezvoltări este web-ul semantic, al cărui obiectiv este prezentarea informaţiei pe web nu doar pentru oameni ci şi într-o formă care poate fi interpretată de sistemele de calcul[2]. Aceasta va facilita managementul cunoştinţelor pe web şi în particular conectarea şi reutilizarea cunoştinţelor (mediatizarea conţinutului), dar şi localizarea cunoştinţelor noi relevante (de exemplu cu ajutorul sistemelor de recomandare). Datorită interactivităţii crescute la nivel semantic şi posibilităţii de automatizare a sarcinilor (prin intermediul agenţilor inteligenţi), putem afirma că web-ul va deveni mai răspândit şi mai relevant în viaţa de zi cu zi. [1] Weerawarana, S., Curbera, F., Leymann, F., Storey, T., Ferguson, D. F., Web Services Platform Architecture, Prentice Hall, 2005[2] Berners-Lee, T., Hendler, J., Lassila, O., The Semantic Web, Scientific American, May, 2001

Caracteristicile aplicaţiilor web - Generalităţi

Aplicaţiile web # aplicaţiile tradiţionale navigarea non-liniară frecvenţa actualizărilor

Prezenta unei caracteristici- dependenta de tipul aplicatiei web> Aplicaţiile web tranzacţionale - focalizare asupra actualizării şi consistenţei conţinutului

Aplicaţiile web diferă de aplicaţiile tradiţionale (non-web), prin anumite caracteristici: unele lipsesc complet în aplicaţiile tradiţionale (de exemplu navigarea non-liniară), iar altele au o importanţă deosebită în cadrul aplicaţiilor web (de exemplu frecvenţa actualizărilor).

Dacă şi în ce măsură este prezentă o anumită caracteristică depinde parţial de tipul de aplicaţie web: dezvoltarea aplicaţiilor web tranzacţionale (cum ar fi sistemele de comerţ electronic) necesită o focalizare mai atentă asupra actualizării şi consistenţei conţinutului comparativ cu sistemele informaţionale pure (de exemplu expoziţiile virtuale). Aceste caracteristici sunt motivul pentru care numeroase concepte, metode, tehnici şi utilitare ale Ingineriei Software tradiţionale trebuie adaptate la cerinţele proiectării web, deşi în unele situaţii acestea pot fi total neadecvate. Figura 1.2 prezintă o imagine de ansamblu a acestor caracteristici, acestea fiind împărţite pe trei dimensiuni: ”produs”, ”utilizare” şi ”dezvoltare”,”evoluţia” lor fiind o dimensiune comună.

6

Dimensiunile conform cu standardul ISO/IEC 9126-1 pentru clasificarea caracteristicilor aplicaţiilor web (http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=22749)

Aceste dimensiuni se bazează pe standardul ISO/IEC 9126-1 pentru evaluarea caracteristicilor de calitate ale software-ului (http://www.iso.org). Prin atribuirea diferitelor caracteristici ale aplicaţiilor web acestor dimensiuni putem observa influenţa acestora asupra calităţii aplicaţiilor şi astfel să considerăm caracteristicile ca un punct de pornire pentru definirea necesarului proiectării web. Pe lângă caracteristicile asociate produselor, utilizării şi dezvoltării există şi evoluţia ca o a patra dimensiune care guvernează cele trei dimensiuni. Produsele trebuie să fie adaptabile, noul context informaţional trebuie luat în considerare pe durata utilizării, iar modalităţile de dezvoltare vor modifica în mod continuu schimbările care vor apare. În continuare, vom prezenta caracteristicile individuale conform acestor dimensiuni.

Caracteristicile produselor

conţinut, structură hipertextuală şi prezentare > aspecte structurale sau statice ci şi aspecte comportamentale sau dinamice

Caracteristicile legate de produs formează blocurile principale de dezvoltare a unei aplicaţii web şi constau în conţinut, structură hipertextuală (structură de navigare) şi prezentare (interfaţa utilizator). Conform paradigmei orientat-obiect, fiecare din aceste părţi nu are doar aspecte structurale sau statice ci şi aspecte comportamentale sau dinamice.

Conţinut – “Conţinutul este regele” - programatori şi autori- Caracterul „axat pe document” şi multimedia- conţinutul este oferit sub forma tabelelor,

textului, elementelor grafice, animaţiilor, elementelor audio sau videoCaracterul "axat pe document" în aplicaţiile web - documentele sunt generate în mod adecvat pentru anumite grupuri de utilizatori

- generat şi actualizat dinamic - conţinut multimedia

- Cererile de calitate - actualitate, exactitate, consistenţă şi încredere > Siturile de ştiri, personalizare, aplicaţiile ”inteligente”, ”conştiente” de locaţie

7

http://www.iso.org/

- calitatea superioară este necesară pentru preţul şi utilitatea informaţiei în sistemele de cumpărare online

ConţinutulGenerarea conţinutului, disponibilizarea acestuia, integrarea şi actualizarea lui sunt la fel de

importante precum dezvoltarea software-ului pentru o aplicaţie web. Aplicaţiile web sunt utilizate în special datorită conţinutului pe care îl oferă, fiind valabil motto-ul ”Conţinutul este regele”, iar dezvoltatorii lor trebuie să se comporte atât ca programatori cât şi ca autori. Aspectele importante sunt gradul variat al structurii conţinutului şi cererile de calitate făcute de utilizatori asupra conţinutului. * Caracterul „axat pe document” şi multimedia. În funcţie de modul de structurare, conţinutul este oferit sub forma tabelelor, textului, elementelor grafice, animaţiilor, elementelor audio sau video. Caracterul "axat pe document" în aplicaţiile web se referă la faptul că sunt generate documente care prezintă informaţia în mod adecvat pentru anumite grupuri de utilizatori (de exemplu informaţii pentru turiştii aflaţi în vacanţă într-o anumită regiune). Aceasta implică şi anumite cerinţe speciale privitoare la uşurinţa în folosire. Conţinutul este într-o anumită proporţie generat şi actualizat dinamic (de exemplu numărul de camere disponibile într-un sistem informaţional pentru turism). Mai mult, web-ul poate fi folosit ca infrastructură pentru transmiterea conţinutului multimedia (de exemplu videoconferinţe sau aplicaţii Real Audio).

* Cererile de calitate. În funcţie de domeniul aplicaţiei, conţinutul unei aplicaţii web nu este supus doar actualizărilor cu o anumită frecvenţă, ci şi diferitelor măsurători de calitate privitoare la actualitate, exactitate, consistenţă şi încredere. Aceste cereri de calitate trebuie luate în considerare atât la stabilirea cerinţelor, cât şi la evaluarea complianţei cu aceste principii.

Siturile de ştiri, de exemplu, necesită o frecvenţă sporită a actualizărilor şi trebuie să facă faţă cererilor utilizatorilor privind caracterul de ultimă oră al conţinutului. Ca mediu de distribuire a informaţiei, alături de televiziune, radio şi presă, web-ul oferă un potenţial mult mai mare decât mijloacele de informare tradiţională pentru adresarea acestor cereri, datorită personalizării. Pe de altă parte, există opinii conform cărora aplicaţiile personalizate "inteligente" ("conştiente" de locaţie), necesită dezvoltarea unor noi genuri de aplicaţii; motivul este acela că aplicaţiile noi bazate pe conţinut (ex. podcasting sau conţinut mobil) sunt un mediu foarte diferit, greu de adaptat la conţinutul existent.

O calitate superioară este necesară îndeosebi pentru informaţiile privind preţul şi disponibilitatea produselor în sistemele de cumpărare online, acestea formând baza tranzacţiilor unei afaceri. Preţurile incorecte pot duce la anularea vânzării, iar informaţiile vechi privind disponibilitatea pot conduce la incapacitatea de a vinde produsele din stoc sau la probleme de livrare deoarece produsele afişate drept disponibile nu există în stoc. Indiferent de scopul cu care este utilizat o aplicaţie web, calitatea conţinutului este un factor esenţial pentru acceptarea ei. Marea provocare o reprezintă capacitatea de a garanta calitatea datelor în ciuda volumului mare şi frecvenţei crescute a actualizărilor.

Hipertext - natura non-liniară a documentelor hipertextuale Elementele de bază ale modelelor hipertext

nod - unitate de informaţie unic identificată legătură - calea de la un nod la altul ancoră - conţinutul unui nod

Non-liniaritatea - stereotipuri privind citirea sistematică relativă - indicat pentru dezvoltarea abilităţii de învăţare

- Ancorele şi legăturile – statice/dinamiceDezorientarea şi supra-încărcarea cognitivă - pierde poziţia într-un document non-liniar - concentrarea suplimentară solicitată de memorarea simultană a diverselor căi sau sarcini

8

> Hărţile, căutarea prin cuvintele cheie, căile (modul history), afişarea timpului de accesare şi a timpului petrecut pe sit, legăturile pline de înţeles, folosirea şabloanelor de proiectare

HipertextUna dintre caracteristicile specifice aplicaţiilor web este natura non-liniară a documentelor

hipertextuale. Paradigma hipertext, folosită ca bază pentru structurarea şi prezentarea informaţiei, a fost menţionată pentru prima dată de Vannevar Bush. Elementele de bază ale modelelor hipertext sunt nodurile, legăturile şi ancorele. Un nod este o unitate de informaţie unic identificabilă, autonomă. Pe web acesta poate fi un document HTML care poate fi accesat printr-un URL (Uniform Resource Locator). O legătură este calea de la un nod la altul. Pe web aceste căi sunt întotdeauna unidirecţionale, scopul acestora nefiind clar definit (poate fi „următorul nod în acord cu ordinea de citire recomandată”). O ancoră este zona din conţinutul unui nod care este sursa sau destinaţia unei legături (de exemplu o secvenţă de cuvinte dintr-un text sau un obiect grafic dintr-un desen). Pe web, ancorele sunt posibile doar în documentele HTML.

Trăsăturile esenţiale ale paradigmei hipertext sunt non-liniaritatea conţinutului produs de autori şi a conţinutul receptat de utilizatori, alături de problemele potenţiale de dezorientare şi supra-încărcare cognitivă.

* Non-liniaritatea. Hipertextele implică stereotipuri privind citirea relativ sistematică, prin aceasta aplicaţiile web diferenţiindu-se în mod evident de aplicaţiile software tradiţionale. Acest stil de citire individual, adaptabil la nevoile şi comportamentul utilizatorilor, este cel mai potrivit pentru capacitatea de învăţare umană. Utilizatorii se pot mişca liberi în spaţiul informaţional, în funcţie de interesele şi cunoştinţele anterioare. Ancorele şi legăturile nu sunt doar predefinite în mod static de autori, ci pot fi generate dinamic ca o reacţie predefinită la modelele de comportament al utilizatorilor.

* Dezorientarea şi supra-încărcarea cognitivă. Este foarte important, în dezvoltarea aplicaţiilor web, să facem faţă acestor două probleme fundamentale ale paradigmei hipertext. Dezorientarea reprezintă tendinţa de a pierde direcţia într-un document non-liniar. Supra-încărcarea cognitivă este cauzată de concentrarea suplimentară necesară pentru memorarea simultană a diverselor căi sau sarcini. Hărţile siturilor, căutările prin intermediul cuvintelor cheie, urmărirea căilor (modul history) şi afişarea timpului de accesare şi a timpului petrecut pe sit ajută utilizatorii să-şi păstreze orientarea în cadrul aplicaţiei. Crearea unor legături cu înţeles şi denumirea inteligentă a legăturilor reduc supra-încărcarea cognitivă. În plus, folosirea şabloanelor de proiectare în modelarea aspectului hipertext poate ajuta la contracararea acestei probleme.

Prezentarea Estetica - ”look and feel” - succesul sau eşecul (e-comm)Auto-explicarea - utilizare, sistemul de navigare

PrezentareaDouă trăsături speciale ale aplicaţiilor web la nivelul prezentare (interfaţă utilizator) sunt

estetica şi auto-explicarea. Estetica. Spre deosebire de aplicaţiile tradiţionale, estetica nivelului prezentare al unei

aplicaţii web este un factorul important, şi datorită presiunii competitive ridicate de pe web. Prezentarea vizuală a paginilor web este supusă tendinţelor în modă şi deseori determină succesul sau eşecul, în special pentru aplicaţiile de comerţ electronic.

Auto-explicarea. Dincolo de estetică, este esenţial ca aplicaţiile web să fie auto-explicative: să fie posibilă utilizarea aplicaţiei web fără a consulta o documentaţie în prealabil. Sistemul de navigare sau cel de interacţiune trebuie să fie consecvent în întreaga aplicaţie, astfel încât utilizatorii să se poată familiariza rapid cu utilizarea aplicaţiei web.

Caracteristici asociate utilizării

9

- utilizarea aplicaţiilor web este extrem de eterogenă > utilizatorii - diferă prin prisma numărului şi culturii generale > dispozitivele - caracteristici hardware şi software diferite Contextul social: utilizatorii Spontaneitatea - utilizatorul poate vizita şi părăsi o aplicaţie web oricând doreşte, chiar dacă este situl unui competitor. Multiculturalitatea - aplicaţiile web sunt dezvoltate pentru diferite grupuri de utilizatori - abilităţile (sau incapacităţile), cunoaşterea (expertiza aplicaţiei) şi preferinţele (interesele).

- personalizare adecvată- reduceri speciale (adaptarea contextului), ghid pentru aplicaţia web (adaptarea hipertextului) , dimensiuni adecvate ale fontului (adaptarea prezentării)

Comparativ cu aplicaţiile tradiţionale, utilizarea aplicaţiilor web este extrem de eterogenă. Cultura generală şi numărul utilizatorilor variază, dispozitivele folosite au caracteristici hardware şi software diferite, iar ora şi locaţia de unde este accesată aplicaţia nu pot fi prevăzute. În plus, dezvoltatorii nu au posibilitatea de a cunoaşte dinainte potenţiala diversitate a acestor factori contextuali şi nu-i pot influenţa în nici un mod datorită naturii lor autonome. Prin urmare, utilizarea aplicaţiilor web trebuie să se adapteze continuu la situaţii de utilizare specifice (contexte). Adaptarea la aceste contexte poate fi necesară pentru toate părţile aplicaţiei web (conţinut, hipertext şi prezentare). Datorită semnificaţiei adaptării la contexte, caracteristicile asociate utilizării sunt împărţite în trei grupuri: contextul social, contextul tehnic şi contextul natural.

Contextul social: utilizatoriiContextul social se referă la aspecte specifice utilizatorului; spontaneitatea şi

multiculturalitatea în special creează un grad înalt de eterogenitate.Spontaneitatea. Utilizatorii pot vizita o aplicaţie web şi o pot părăsi oricând doresc - posibil

pentru un sit competitor. Utilizatorul web nu trebuie să fie loial nici unui furnizor de conţinut, web-ul fiind un mediu care nu atrage nici o obligaţie. Deoarece găsirea unor aplicaţii concurente este uşor de realizat cu ajutorul motoarelor de căutare, utilizatorii vor utiliza o aplicaţie web doar dacă le va aduce un avantaj imediat.

Multiculturalitatea. Aplicaţiile web sunt dezvoltate pentru diferite grupuri de utilizatori. Dacă grupul luat în discuţie este cunoscut (poate fi cazul intranet-ului sau extranet-ului) situaţia poate fi comparabilă cu aplicaţiile tradiţionale. La dezvoltarea unei aplicaţii web pentru un grup anonim de utilizatori, vor exista numeroase elemente eterogene greu de anticipat în ceea ce priveşte abilităţile (ex. dizabilităţi), cunoştinţele (ex. expertiza aplicaţiei) şi preferinţele (ex. interesele). Pentru a permite o personalizare adecvată, ipotezele privind contextele utilizatorilor trebuie construite în stadiul de dezvoltare al aplicaţiei web. Acest aspect va fi luat în considerare când se adaptează componentele aplicaţiei. Clienţii obişnuiţi pot beneficia de reduceri speciale (adaptarea conţinutului), noii clienţi pot primi un tur ghidat prin aplicaţia web (adaptarea hipertextului), iar utilizatorii cu deficienţe vizuale pot fi ajutaţi prin folosirea unor dimensiuni adecvate ale fontului (adaptarea prezentării). Personalizarea necesită deseori specificarea preferinţelor utilizatorilor (de exemplu metoda preferată de plată pe http://www.amazon.com).

Contextul tehnic: Reţeaua şi dispozitivele Calitatea serviciului .

tehnic - aplicaţiile web - principiul client/server > caracteristicile mediului de transmisie (lăţimea de bandă, siguranţa şi stabilitatea conexiunii)

lăţimea maximă de bandă -ajustat pentru a optimiza cantitatea de date transferată

dezvoltatorii trebuie să facă supoziţii Distribuirea multi-plaformă .

Aplicaţiile web oferă de obicei servicii nu doar unui anumit tip de dispozitiv browserele - nu implementează specificaţiile presupuse

utilizatorii pot configura browserele în mod autonom

10

presupuneri privind clasele tipice de dispozitive

Contextul tehnic: Reţeaua şi dispozitiveleContextul tehnic include proprietăţi legate de conexiunea în reţea (privitoare la calitatea

serviciului) şi componentele hardware şi software ale dispozitivelor utilizate pentru a accesa aplicaţia web, pentru distribuirea multi-platformă.

Calitatea serviciului. Din punct de vedere tehnic, aplicaţiile web sunt bazate pe principiul client/server. Caracteristicile mediului de transmisie, cum ar fi lăţimea de bandă, siguranţa şi stabilitatea conexiunii sunt factori independenţi care trebuie luaţi în considerare când dezvoltăm o aplicaţie web pentru a garanta o calitate adecvată a serviciului. De exemplu, parametrul „lăţime de bandă maximă” poate fi modificat pentru a optimiza cantitatea de date transferată, astfel încât conţinutul multimedia (clipuri video) să poată fi transferat la o rezoluţie scăzută în situaţia unei lăţimi de bandă mici. În timp ce pentru aplicaţiile tradiţionale specificaţiile reţelei sunt cunoscute dinainte, dezvoltatorii aplicaţiilor web trebuie să facă supoziţii privitor la aceste proprietăţi. Datorită tendinţei de orientare către aplicaţiile web mobile, acest aspect are o importanţă sporită, reţelele convergente necesitând şi mai multă adaptare la nivelul aplicaţie.

Distribuirea multi-plaformă. Aplicaţiile web oferă de obicei servicii nu doar unui anumit tip de dispozitiv ci şi dispozitivelor mobile cu specificaţii diferite (dimensiunea monitorului, capacitatea memoriei, software-ul instalat). Numărul mare de versiuni ale browserului reprezintă şi el o provocare datorită diferitelor funcţionalităţi şi restricţii ale acestora (deseori acestea nu implementează specificaţiile presupuse). Acest lucru determină dificultăţi în crearea unei interfeţe utilizator consecvente şi în testarea aplicaţiilor web.

În plus, utilizatorii pot configura browserele în mod autonom. Prezentarea (ex. ascunderea imaginilor), drepturile de acces (ex. pentru applet-urile Java) şi o serie de funcţii ex. (cookies, caching) pot fi toate configurate individual, având astfel influenţe asupra performanţei, funcţionalităţii tranzacţiilor şi posibilităţilor de interacţiune.

Pe baza presupunerilor privind clasele tipice de dispozitive, dezvoltatorii aplicaţiilor web pot adapta conţinutul la PDA-uri (personal digital assistants) prin transmiterea legăturilor şi textului descriptiv în locul imaginilor sau clipurilor video. La nivel hipertext, se poate oferi versiunea pentru listare a documentelor hipertext. Pentru a lua în calcul diferitele versiuni de JavaScript din diferite browsere, pot fi utilizate biblioteci independente de platformă în procesul de dezvoltare (vezi http://www.domapi.com ).

Contextul natural: locaţia si durata Globalitatea

Locaţia - importantă pentru internaţionalizarea aplicaţiilor web relativ la diferenţele regionale, culturale şi lingvistice.

locaţia fizică - utilizată împreună cu modelele locaţiei pentru a defini poziţia logică >> a oferi servicii ”conştiente” de locaţie.

Disponibilitatea . ”Mecanismul de distribuire instantanee” = natura web-ului

Contextul natural: locaţia şi timpulContextul natural include aspecte privind locaţia şi timpul de accesare. Globalitatea şi

disponibilitatea creează un nivel înalt de eterogenitate.Globalitatea. Locaţia din care o aplicaţie web este accesată (poziţia geografică) este

importantă pentru internaţionalizarea aplicaţiilor web referitor la diferenţele regionale, culturale şi lingvistice. În plus, locaţia fizică poate fi utilizată împreună cu modelele locaţiei pentru a defini o poziţie logică (cum ar fi locul de rezidenţă sau locul de muncă) pentru a oferi servicii de localizare. Capacitatea de furnizare a informaţiilor privind locaţia determină dificultăţi suplimentare pentru testarea aplicaţiilor web, deseori fiind dificilă simularea locaţiilor care se schimbă şi/sau testarea tuturor locaţiilor posibile. Disponibilitatea globală sporeşte de asemenea cererile privind securizarea aplicaţiilor web pentru a preveni accesul deliberat sau accidental al utilizatorilor în zone private sau confidenţiale.

11

Disponibilitatea. ”Mecanismul de distribuire instantanee” inerent naturii web-ului face aplicaţiile imediat disponibile. Aplicaţiile web devin imediat utilizabile, de aceea calitatea produsului dezvoltat trebuie să fie garantată. Disponibilitatea permanentă (24/7) sporeşte de asemenea pretenţiile privind stabilitatea aplicaţiilor web. În plus, serviciile dependente de timp sunt posibile prin luarea în considerare a aspectului timp (de exemplu informaţii privind programul ce depind de ora din zi şi ziua din săptămână).

Caracteristici asociate dezvoltării Echipa de dezvoltare

Caracterul multidisciplinar - combinaţie între publicistica tipărită şi dezvoltarea software, marketing şi ştiinţa calculatoarelor, artă şi tehnologie

Disciplina dominantă este dependentă de tipul de aplicaţie web Media de vârstă scăzută - dezvoltatori tineri şi mai puţin experimentaţi Dezvoltarea în comunitate - Dezvoltarea de software open-source disponibil gratuit

pe web şi integrarea acestuia în aplicaţiile „reale” este un fenomen relativ recent. Dezvoltatorii folosesc acest software pentru crearea propriilor aplicaţii, pe care le fac disponibile comunităţii open source.

Dezvoltarea aplicaţiilor web implică existenţa resurselor necesare (echipa de dezvoltare şi infrastructura tehnică), procesul de dezvoltare în sine şi integrarea soluţiilor deja existente.Echipa de dezvoltare

Dezvoltarea aplicaţiilor web este puternic influenţată de faptul că echipele de dezvoltare sunt multidisciplinare şi în general formate din tineri. Aceşti factori şi metodele comunităţii de dezvoltare contribuie la apariţia unui nou mod de organizare a colaborării între diferite grupuri de dezvoltatori.

Caracterul multidisciplinar. Aplicaţiile web pot fi caracterizate ca o combinaţie între publicistică şi dezvoltarea software, marketing şi ştiinţa calculatoarelor, artă şi tehnologie. De aceea, dezvoltarea aplicaţiilor web trebuie percepută ca o abordare multidisciplinară ce necesită cunoştinţe şi expertiză din diferite domenii. Pe lângă experţii IT responsabili de implementarea tehnică a sistemului, trebuie să fie angajaţi experţi în hipertext şi proiectanţi pentru proiectarea hipertextului şi prezentării, în timp ce experţii în domeniu trebuie să fie responsabili pentru conţinut. Se observă deci o varietate mai mare a competenţelor şi cunoştinţelor în echipa de dezvoltare faţă de dezvoltarea software tradiţională.Care disciplină va dominantă depinde de tipul de aplicaţie web. De exemplu, aplicaţiile comerţ electronic sunt bazate mai mult pe baze de date tradiţionale şi expertiză în programare, în timp ce dezvoltarea unei expoziţii virtuale va pune mai mult accent pe expertiza în domeniu şi în proiectare.

Media de vârstă scăzută. Dezvoltatorii de aplicaţii web sunt în medie mult mai tineri şi deci mai puţin experimentaţi decât dezvoltatorii de software tradiţional.

Dezvoltarea în comunitate. Dezvoltarea de software open-source disponibil gratuit pe web şi integrarea acestuia în aplicaţiile „reale” este un fenomen relativ recent. Dezvoltatorii folosesc acest software pentru crearea propriilor aplicaţii, pe care le fac disponibile comunităţii open source.

Infrastructura tehnică Eterogenitatea - două componente externe: server şi browser. Imaturitate - creşterii presiunii de a ajunge pe piaţă

Procese procesul de dezvoltare este influenţat de flexibilitate şi paralelism.

Infrastructura tehnicăEterogenitatea şi imaturitatea componentelor folosite sunt caracteristici importante ale infrastructurii tehnice a aplicaţiilor web.

12

Eterogenitatea. Dezvoltarea aplicaţiilor web depinde de două componente externe: server şi browser. În timp ce serverul web poate fi configurat şi folosit după cum doresc programatorii aplicaţiei, browserele web ale utilizatorilor şi preferinţele lor individuale nu pot fi influenţate. Situaţia este complicată şi de diferitele versiuni de browser şi interacţiunea lor cu plugin-urile.Imaturitatea. Datorită creşterii presiunii de a ajunge pe piaţă cât mai rapid, componentele utilizate în aplicaţiile web sunt deseori imature - au bug-uri sau lipsuri în privinţa funcţionalităţii. ProcesulProcesul de dezvoltare este influenţat de flexibilitate şi paralelism.- Flexibilitatea. În dezvoltarea aplicaţiilor web aderarea la un plan de proiect rigid şi predefinit este imposibilă; o reacţie flexibilă la modificarea condiţiilor este vitală. - Paralelismul. Datorită necesităţii de a dezvolta aplicaţiile web într-un timp scurt şi faptului că ele pot fi deseori împărţite în componente autonome (de exemplu autentificare, funcţie de căutare, notificarea ştirilor), majoritatea aplicaţiilor web sunt dezvoltate în paralel de diferite subgrupuri ale echipei de dezvoltare. Spre deosebire de dezvoltarea software-ului tradiţional, aceste subgrupuri sunt structurate în funcţie de componente şi nu în funcţie de expertiza membrilor proiectului (de exemplu dezvoltatori GUI, modelatori de date etc.).

Integrarea Integrarea internă - aplicaţiile web trebuie integrate cu sistemele de moştenire existente când conţinutul existent (de ex. cataloagele de produse) va fi făcut disponibil aplicaţiei web Integrarea externă - Integrarea conţinutului şi a servicilor aplicaţiilor web externe

Integrarea internă. Aplicaţiile web trebuie integrate frecvent cu sistemele de moştenire existente când conţinutul existent (de ex. cataloagele de produse) va fi făcut disponibil prin intermediul unei aplicaţii web.Integrarea externă. Integrarea conţinutului şi a serviciilor aplicaţiilor web externe reprezintă o caracteristică specială a aplicaţiilor web. Dintre particularităţile integrării pe web menţionăm:- existenţa unui număr mare de surse care se schimbă frecvent şi au un grad înalt de autonomie în ceea ce priveşte disponibilitatea şi evoluţia schemei;- se cunosc puţine detalii privitoare la proprietăţile acestor surse (ex. conţinutul sau funcţionalităţile lor);- sursele diferite sunt adesea foarte eterogene la diverse nivele (nivelul datelor, schemei sau modelului de date).Integrarea serviciilor externe (de ex. în aplicaţiile web orientate pe portaluri) se bazează pe forma de dezvoltare din ce în ce mai comună a furnizării şi utilizării serviciilor web. În acest context, un serviciu web este o componentă reutilizabilă cu o interfaţă şi funcţionalitate foarte clar definite. Interacţiunea diferitelor servicii web, evitând efectele secundare nedorite, şi garantarea calităţii serviciilor sunt câteva dintre problemele relevante ale acestui context.

Evoluţia

Schimbarea continuă = schimbare constantă a cerinţelor sau condiţiilor - utilizatorii doresc ultimile aplicaţii web;

- instrumentele utilizate sunt condiţionate de tehnologie Presiunea competiţiei Ritmul rapid de dezvoltare - presiunea timpului

EvoluţiaEvoluţia este o caracteristică ce guvernează toate cele trei dimensiuni: produsul, utilizarea şi dezvoltarea. Nevoia de progres poate fi argumentată prin schimbarea continuă a cerinţelor şi condiţiilor, presiunea competiţiei şi ritmul rapid de dezvoltare.

Schimbarea continuă

13

Aplicaţiile web se modifică rapid şi sunt în consecinţă într-o evoluţie permanentă datorită schimbării constante a cerinţelor sau condiţiilor Scharl, A., Evolutionary Web Development – Automated Analysis, Adaptive Design, and Interactive Visualization of Commercial Web Information Systems, Springer-Verlag, 2000. Schimbarea rapidă şi permanentă a tehnologiilor web şi a standardelor în particular necesită o adaptare continuă a aplicaţiilor web la acestea. Această schimbare are două cauze:- utilizatorii doresc cele mai noi aplicaţii web;- instrumentele utilizate sunt condiţionate de tehnologie.Schimbările constante ale cerinţelor şi condiţiilor reprezintă o caracteristică esenţială a aplicaţiilor web, acestea putând afecta toate cele trei dimensiuni ale unei aplicaţii web – produsul însuşi, utilizarea acestuia şi, în particular, dezvoltarea lui.Presiunea competiţieiPresiunea competiţiei extrem de ridicate de pe web, presiunea de lansare rapidă pe piaţă şi necesitatea unei prezenţe pe web sporesc nevoia unui ciclu de viaţă scurt al produsului, al unui ciclu de dezvoltare extrem de scurt şi nu lasă loc pentru un proces de dezvoltare sistematic. Prezenţa imediată pe web este considerată mai importantă decât perspectiva pe termen lung.Ritmul rapid de dezvoltarePresiunea timpului în dezvoltarea aplicaţiilor web se datorează schimbărilor rapide de pe web, ce duc scurtarea duratei de viaţă a aplicaţiilor web sau la actualizări frecvente.În timp ce în aplicaţiile software tradiţionale evoluţia are loc sub forma seriilor planificate de versiuni, în aplicaţiile web aceasta este continuă. Aplicaţiile web sunt într-o continuă întreţinere, ciclul schimbării fiind deseori de doar câteva zile sau săptămâni.

Principalele aspecte abordate în continuare sunt prezentate în Figura 3. Principalele componente luate în discuţie sunt grupate pe doi piloni:

- dezvolt area produsului;- aspecte privind calitatea.Elementul de bază este partea introductivă prezentată anterior, web-ul social şi web-ul

semantic fiind "acoperişul", perspectiva de viitor.Principalele provocãri ale proiectãrii cerinþelor aplicaþiilor web includ: parteneri indisponibili, schimbarea dinamicã a condiþiilor, medii de acþiune impredictibile, importanþa deosebitã a calitãþii ºi frecventa lipsã de experienþã în utilizarea tehnologiilor. Modelarea se referã la dezvoltarea aplicaþiilor web pe bazã de modele, cu focalizare asupra conþinutului ºi hipertextului, ºi implicã o dezvoltare de sus în jos. Este necesarã o prezentare a

14

metodelor existente pentru modelarea aplicaþiilor web ºi a unor instrumente de modelare care sã ajute proiectantul în alegerea metodei adecvate. Arhitectura este un factor decisiv pentru o aplicaþie web de calitate. Performanþele slabe, întreþinerea neadecvatã ºi disponibilitatea redusã se datoreazã deseori unei arhitecturi necorespunzãtoare. Folosirea arhitecturilor flexibile, pe mai multe nivele, oferirea unui conþinut multimedia ºi integrarea aplicaþiilor ºi depozitelor de date existente influenþeazã pozitiv dezvoltarea aplicaþiilor web.Proiectarea bazatã pe tehnologie descrie alternativa dezvoltãrii de jos în sus a aplicaþiilor web. Proiectarea hipertext/hipermedia, a informaþiei ºi a software-ului orientat-obiect nu oferã o soluþie satisfãcãtoare, fiind necesare abordãri de proiectare specifice web-ului, cum ar fi: - proiectarea vizualã, în care aspectul este hotãrâtor ºi în care se iau în considerare multiple interfeþe utilizator; - proiectarea interacþiunii - a cãilor de navigare ºi a "dialogului" cu componentele;- proiectarea funcþionalã fixeazã esenþa aplicaþiei web.Pe mãsurã ce proiectarea fiecãrui nivel devine mai concretã, trebuie utilizate instrumente pentru proiectarea hipertext-ului, informaþiei ºi software-ului.Tehnologiile au anumite caracteristici care trebuie cunoscute în detaliu, pentru a putea fi utilizate în etapa adecvatã. Implementarea aplicaþiilor web necesitã o cunoaºtere aprofundatã a diferitelor tehnologii ºi a interacþiunii acestora cu o anumitã arhitecturã. Astfel, este necesarã o prezentare a diferitelor tehnologii ºi o exemplificare a interacþiunii ºi utilizãrii lor împreunã cu anumite arhitecturi. Recomandãrile consorþiului web (W3C) necesitã o atenþie deosebitã.Metodele actuale de testare se focalizeazã pe cerinþele funcþionale ale aplicaþiilor web. Multe dintre cerinþele de calitate non-funcþionale importante pentru utilizatori (uºurinþa în folosire, siguranþa ºi securitatea) nu sunt luate în considerare suficient. Exploatarea ºi întreþinerea: multe sarcini care ar trebui rezolvate în timpul fazei de proiectare ºi dezvoltare sunt deseori amânate spre faza de exploatare ºi întreþinere, ceea ce creºte ºi mai mult importanþã acestei etape. Existã de asemenea o tendinþã de a automatiza sarcinile cât timp sistemul este operaþional. De exemplu, sarcini de rutinã pentru întreþinerea conþinutului sunt în mare mãsurã automatizate, eliminându-se astfel sursele de erori ºi garantând o exploatare stabilã. Uºurinþa în folosire, performanþa ºi securitatea reprezintã trei dintre aspectele de calitate ale aplicaþiilor web. Uºurinþa în folosire subliniazã faptul cã aplicaþiile web greu de utilizat nu sunt acceptate de cãtre utilizatori. Noile dezvoltãri precum aplicaþiile web mobile ºi facilitãþile speciale pentru utilizatorii cu deficienþe pun un accent deosebit pe uºurinþa în folosire; aceasta nu poate fi dobânditã într-o singurã etapã ci trebuie luatã în considerare pe durata întregului proces de dezvoltare.Performanþa implicã folosirea unor metode, începând cu cele de modelare pentru verificarea performanþei ºi terminând cu cele de mãsurare. Dintre metodele de modelare menþionãm modelele operaþionale ºi modelele de simulare generale. Metodele de mãsurare necesitã accesul la un sistem existent ºi au avantajul cã sistemul poate fi urmãrit în timp real. Dacã sunt identificate probleme de performanþã prin mãsurare sau modelare, aceasta va trebui îmbunãtãþitã prin extinderea hardware-ului, optimizarea software-ului, prin caching sau replicãri. Securitatea implicã abordarea unor probleme privind confidenþialitatea datelor, prevenirea interceptãrii mesajelor schimbate pe canalele accesibile public ºi oferirea unor servicii de încredere.Web-ul social indică o formă îmbunătăţită a World Wide Web, susţinătorii lui sugerând faptul că tehnologii precum weblog-urile, wiki-urile, podcast-urile, feed-urile RSS, software-ul social, API-urile web, standardele şi serviciile web online implică o schimbare semnificativă a modului în care Internetul este utilizat. Generaţii diferite de oameni şi-au schimbat dramatic percepţia şi participarea la web, în ultimul timp acesta fiind privit ca un mediu de comunicare, o platformă de socializare, un mecanism de stocare a jurnalelor sau o enciclopedie în continuă expansiune.Web-ul semantic reprezintã urmãtorul pas logic în evoluþia web-ului. Pentru a se realiza acest pas, în primul rând, paginile web trebuie extinse (fie manual fie prin intermediul unor instrumente) cu etichete semantice, cu ajutorul cãrora paginile vor avea un conþinut interpretabil de sistemele de calcul. În al doilea rând, utilizatorii care cautã informaþia ar trebui sã foloseascã agenþi

15

software inteligenþi capabili sã proceseze paginile web care au aceastã facilitate. În cele din urmã, producãtorii de conþinut ºi agenþii software trebuie sã adopte un vocabular comun al conceptelor – o ontologie. Web-ul semantic este încã la începuturi, dar opinia generalã este cã acesta implicã tehnologii promiþãtoare care vor influenþa profund mediul de lucru al "lucrãtorilor în domeniul cunoaºterii".

Proiectarea cerinţelor aplicaţiilor web

activităţi care sunt critice pentru proiectarea web>Cerinţe incomplete, ambigue sau incorecte>Principii, metode şi utilitarele pentru extragerea, descrierea, validarea şi managementul cerinţelor

Proiectarea cerinţelor implică activităţi care sunt esenţiale pentru succesul proiectării web. Cerinţe incomplete, ambigue sau incorecte pot conduce la dificultăţi majore în dezvoltare sau chiar la anularea proiectelor. Proiectarea cerinţelor presupune luarea în discuţie a principiilor, metodelor şi utilitarelor pentru extragerea, stabilirea, descrierea, validarea şi managementul cerinţelor. Deşi cerinţele joacă un rol cheie în dezvoltarea aplicaţiilor web, ele sunt deseori descrise în mod neadecvat, consecinţele tipice fiind acceptarea scăzută din partea utilizatorilor, eşecul planificării sau arhitecturi software neadecvate. Există un acord general privitor la importanţa cerinţelor pentru dezvoltarea cu succes a sistemelor, de-a lungul anilor oferindu-se numeroase standarde, abordări, modele, limbaje de descriere şi utilitare.În continuare vom discuta principiile proiectării cerinţelor pentru dezvoltarea aplicaţiilor web şi vom studia modul în care metodele existente de proiectare a cerinţelor pot fi adaptate la particularităţile proiectelor web.

Obiectivele individuale şi aşteptările părţilor interesatePărţile interesate pentru aplicaţiile web - autorii de conţinut, experţii în domeniu, experţi în caracterul utilizabil sau profesioniştii în domeniul marketing-ului Obiective > constrângerea clientului, obiectiv de calitate a clientului, perspectiva tehnologică a dezvoltatorilor, obiectiv de calitate al utilizatorului, obiectiv de calitate al clientului, obiectiv al clientului privind uşurinţa în folosire, obiectiv al utilizatorului privind capacitatea

Obiectivele individuale şi aşteptările părţilor interesate reprezintă punctul de pornire al procesului de stabilire a cerinţelor. Părţile interesate sunt oameni sau organizaţii care au o influenţă directă sau indirectă asupra cerinţelor în dezvoltarea sistemului[1]. Părţi interesate importante sunt clienţii, utilizatorii şi dezvoltatorii; cele tipice pentru aplicaţiile web includ autorii de conţinut, experţii în anumite domenii, profesioniştii în marketing sau în uşurinţa în folosire. Obiectivele şi aşteptările părţilor interesate sunt de obicei diverse, după cum demonstrează şi următoarele exemple:- aplicaţia web trebuie să fie disponibilă online până la 1 septembrie 2009 (constrângere din partea clientului);- aplicaţia web trebuie să suporte minim 2500 utilizatori concurenţi (obiectiv de calitate al clientului);- PHP trebuie folosit ca platformă de dezvoltare (perspectiva tehnologică a dezvoltatorilor);- toate datele clienţilor trebuie trimise securizat (obiectiv de calitate al utilizatorului);

16

- interfaţa utilizator trebuie să suporte layout-uri pentru diferite grupuri de clienţi (obiectiv de calitate al clientului);- orice utilizator trebuie să poată găsi produsul dorit în mai puţin de trei minute (obiectiv al clientului privind uşurinţa în folosire);- utilizatorul trebuie să aibă posibilitatea să selecteze o iconiţă care să afişeze articolele incluse în coşul de cumpărături în orice moment (obiectiv al utilizatorului privind capacitatea).

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

Cerinţa - descrie o proprietate care trebuie îndeplinită sau un serviciu care trebuie furnizat de către un sistem. IEEE 610.12 defineşte o cerinţă ca:- o condiţie sau aptitudine necesară unui utilizator pentru a rezolva o problemă sau a îndeplini un obiectiv ;- o condiţie sau capacitate care trebuie îndeplinită sau posedată de un sistem sau componentă a sa pentru a satisface un contract, un standard, o specificaţie sau alte documente solicitate formal ;

Identificarea şi implicarea părţilor interesate reprezintă obiectivele principale ale managementului proiectului. O mare provocare o constituie înţelegerea şi aplanarea frecventelor conflicte privind obiectivele, aşteptările şi ordinea de zi. De exemplu, pot exista conflicte între setul dorit de funcţionalităţi şi bugetul disponibil; între setul de funcţionalităţi, programul proiectului şi calitatea dorită; sau între tehnologia de dezvoltare dorită şi aptitudinile şi experienţele dezvoltatorilor. Înţelegerea şi rezolvarea din timp a acestor contradicţii şi conflicte este esenţială şi are o contribuţie importantă la managementul riscului. Au fost propuse diferite tehnici de negociere pentru a susţine acest obiectiv, dezvoltarea unei viziuni comune între părţile interesate fiind o condiţie pentru succes.Obiectivele părţilor interesate sunt deseori reprezentate informal, oferind baza pentru cerinţele derivate mai detaliate. O cerinţă descrie o proprietate care trebuie îndeplinită sau un serviciu care trebuie furnizat de către un sistem. IEEE 610.12 defineşte o cerinţă ca:- o condiţie sau aptitudine necesară unui utilizator pentru a rezolva o problemă sau a îndeplini un obiectiv;- o condiţie sau capacitate care trebuie îndeplinită sau posedată de un sistem sau componentă a sa pentru a satisface un contract, un standard, o specificaţie sau alte documente solicitate formal.Cerinţele sunt clasificate deseori în cerinţe funcţionale, cerinţe non-funcţionale şi constrângeri[1]. Cerinţele funcţionale definesc capacităţile şi serviciile unui sistem, iar cerinţele non-funcţionale descriu nivelele de calitate dorite („Cât este de securizat?”, „Cât este de uşor de folosit?”). Constrângerile sunt condiţii non-negociabile care afectează un proiect. Exemple de constrângeri sunt nivelul de calificare a echipei de dezvoltare, bugetul disponibil, data livrării sau infrastructura de calculatoare existentă în zona de dezvoltare. Toate cerinţele şi constrângerile dintre contractor şi client sunt sintetizate într-un document.Abordările uzitate în proiectarea cerinţelor pun accentul pe identificarea şi implicarea părţilor interesate, negocierea şi descoperirea cerinţelor pe bază de scenarii, analizarea contextului organizaţional şi social anterior modelării detaliate şi definirea clară a constrângerilor care afectează dezvoltarea[2]. [1] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999[2] Boehm, B. W., Requirements that Handle IKIWISI, COTS, and Rapid Change, IEEE Computer, 33 (7), July, 2000, pp. 99–102

Provenienţa cerinţelor

Cerinţe - funcţionale non-funcţionale

17

constrângeri

Cerinţele sunt clasificate deseori în cerinţe funcţionale, cerinţe non-funcţionale şi constrângeri[1]. Cerinţele funcţionale definesc capacităţile şi serviciile unui sistem, iar cerinţele non-funcţionale descriu nivelele de calitate dorite („Cât este de securizat?”, „Cât este de uşor de folosit?”). Constrângerile sunt condiţii non-negociabile care afectează un proiect. Exemple de constrângeri sunt nivelul de calificare a echipei de dezvoltare, bugetul disponibil, data livrării sau infrastructura de calculatoare existentă în zona de dezvoltare. Toate cerinţele şi constrângerile dintre contractor şi client sunt sintetizate într-un document.Abordările uzitate în proiectarea cerinţelor pun accentul pe identificarea şi implicarea părţilor interesate, negocierea şi descoperirea cerinţelor pe bază de scenarii, analizarea contextului organizaţional şi social anterior modelării detaliate şi definirea clară a constrângerilor care afectează dezvoltarea[1].

[1] Boehm, B. W., Requirements that Handle IKIWISI, COTS, and Rapid Change, IEEE Computer, 33 (7), July, 2000, pp. 99–102

[1] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999[1] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999[2] Boehm, B. W., Requirements that Handle IKIWISI, COTS, and Rapid Change, IEEE Computer, 33 (7),July, 2000, pp. 99–102

Activităţile proiectării cerinţelor

- Extragerea cerintelor şi negocierea - rezultatul procesului de învăţare şi construirii pe bază de consens > metode şi utilitare colaborative

- Documentarea cerintelor – detaliere si formalism- Verificarea cerintelor şi validarea –feedback-uri- Managementul cerinţelor

Proiectarea cerinţelor implică extragerea, documentarea, verificarea şi validarea, dar şi managementul cerinţelor pe parcursul procesului de dezvoltare. Extragerea cerinţelor şi negociereaLowe şi Eklund[1] au demonstrat că cerinţele nu pot fi colectate prin întrebări adecvate ci sunt rezultatul unui proces de învăţare şi de creare a unui consens. În acest proces comunicarea între părţile interesate este esenţială, doar punerea în comun a expertizei lor putând duce la soluţii acceptabile mutual. Un set larg de metode şi utilitare de colaborare sunt disponibile pentru a facilita comunicarea şi schimbul de informaţii în proiectarea cerinţelor: tehnici de creativitate, metode bazate pe scenarii, interviuri sau analiza documentelor. Documentarea cerinţelorDacă părţile interesate ajung la un consens, acordurile dintre aceştia trebuie finisate şi descrise într-un document al cerinţelor, având un grad de detaliere şi formalism adecvat contextului proiectului. Alegerea gradului adecvat de detaliere şi formalism depinde de riscurile identificate ale proiectului şi de experienţa şi aptitudinile presupuşilor cititori. Descrierile informale precum relatările utilizatorilor şi cele semi-formale precum cazurile de utilizare sunt relevante pentru proiectarea web.Verificarea cerinţelor şi validareaCerinţele trebuie validate („S-au specificat cerinţele corecte?”) şi verificate („S-au specificat corect cerinţele?). Există o serie de metode convenţionale pentru acest scop (cum ar fi revizuirile, verificările sau prototipizarea). În proiectarea web, deschiderea pe care o oferă Internetul facilitează noi forme de participare directă a utilizatorilor în validarea cerinţelor (de exemplu prin colectarea online a feedback-urilor utilizatorilor)[2]. Managementul cerinţelor

18

Una dintre principalele caracteristici ale proiectelor web este modificarea continuă a cerinţelor şi constrângerilor. Metodele şi instrumentele folosite pentru managementul cerinţelor suportă atât integrarea de noi cerinţe cât şi modificarea celor existente; ele ajută şi la evaluarea impactului acestor schimbări prin administrarea interdependenţelor dintre cerinţe şi alte artefacte de dezvoltare.

[1] 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[2] 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

Cerinţe specifice proiectării web

Caracterul multidisciplinar - experţi multimedia, autorii de conţinut, arhitecţi software, experţi în uşurinţa de folosire, specialişti în baze de date sau experţi într-un anumit domeniu

Indisponibilitatea părţilor interesate- potenţialii utilizatori web, sunt necunoscuţi pe parcursul activităţilor de proiectare a cerinţelor

Caracterul schimbător al cerinţelor şi constrângerilor Mediul operaţional imprevizibil- modificarea lăţimii de bandă

La suprafaţă, diferenţele dintre proiectarea cerinţelor pentru proiectarea web şi proiectarea cerinţelor pentru sistemele software tradiţionale par a fi neglijabile. Deşi există multe diferenţe între dezvoltarea web şi dezvoltarea software, există şi multe similarităţi (de exemplu extragerea cerinţelor). În cele ce urmează vom insista pe diferenţele dintre acestea, pe baza caracteristicilor aplicaţiilor web prezentate în capitolul anterior.Caracterul multidisciplinarDezvoltarea aplicaţiilor web necesită participarea experţilor din diferite discipline: experţi multimedia, autori de conţinut, arhitecţi software, experţi în uzabilitate, specialişti în baze de date sau experţi într-un anumit domeniu. Eterogenitatea şi caracterul multidisciplinar al părţilor interesate fac dificilă obţinerea unui consens la definirea cerinţelor, cu atât mai mult cu cât oamenii din diferite discipline vorbesc limbi şi jargoane diferite.Indisponibilitatea părţilor interesateDe multe ori părţile interesate, (cum ar fi potenţialii utilizatori web), sunt necunoscute pe parcursul activităţilor de proiectare a cerinţelor. Managementul proiectului trebuie să găsească reprezentanţi potriviţi care să ofere cerinţe cât mai realiste. De exemplu, deseori există un spectru larg de posibili utilizatori în proiectele web şi găsirea unui grup de reprezentanţi adecvaţi este dificilă. Caracterul schimbător al cerinţelor şi constrângerilorCerinţele şi constrângerile (ex. proprietăţile platformelor de lucru sau protocoalele de comunicaţie) sunt adesea mai uşor de definit pentru sistemele software tradiţionale comparativ cu aplicaţiile web. Aplicaţiile web şi mediul în care acestea funcţionează sunt extrem de dinamice, din acest motiv cerinţele şi constrângerile fiind greu de stabilizat. Cele mai frecvente exemple de astfel de schimbări sunt inovaţiile tehnologice cum ar fi introducerea de noi platforme şi standarde de dezvoltare sau noi dispozitive pentru utilizatorii finali. Mediul operaţional imprevizibilMediul operaţional al unei aplicaţii web este de asemenea foarte dinamic şi greu de anticipat. Pentru dezvoltatori este dificil sau chiar imposibil să controleze factori importanţi, decisivi pentru calitatea aplicaţiei web percepută de utilizator. De exemplu, modificarea lăţimii de bandă afectează timpul de răspuns pentru aplicaţiile mobile dar acest lucru nu depinde de echipa de dezvoltare.

19

Impactul sistemelor de moştenire - integrarea componentelor software existente cum ar fi produsele comerciale autonome sau software-ul open source

Importanţa aspectelor calitative - performanţa unei aplicaţii web, securitatea în sistemele de e-commerce, disponibilitatea sau uşurinţa în folosire

Impactul sistemelor de moştenireDezvoltarea aplicaţiilor web este caracterizată prin integrarea componentelor software existente cum ar fi produsele comerciale autonome/universale sau software-ul open source. În particular, dezvoltatorii web se confruntă frecvent cu integrarea sistemelor de moştenire, de exemplu atunci când vor să facă accesibile pe web sistemele IT existente într-o companie. Dezvoltatorii sunt deseori îndemnaţi să utilizeze componentele existente şi din motive economice. Componentele care trebuie integrate influenţează cerinţele şi arhitectura viitorului sistem. În aceste situaţii o abordare în cascadă în care arhitectura sistemului derivă din cerinţe nu va avea succes, deoarece componentele, infrastructura şi serviciile existente stabilesc o serie de posibilităţi şi limitări pentru dezvoltatori (atunci când se identifică şi definesc cerinţele, dezvoltatorii web trebuie să fie conştienţi de arhitectura sistemului şi de constrângerile arhitecturale. O abordare iterativă precum cea propusă de modelul Twin Peaks este mai adecvată într-un asemenea context (vezi figura).Importanţa aspectelor calitativeAspectele calitative sunt decisive pentru succesul aplicaţiilor web. Exemple: performanţa unei aplicaţii web, securitatea în sistemele de e-commerce, disponibilitatea, uşurinţa în folosire. În ciuda importanţei aspectelor calitative, dezvoltatorii trebuie să se confrunte cu faptul că specificarea exactă a cerinţelor de calitate este dificilă înaintea construirii sistemului. De exemplu timpul de răspuns al unei aplicaţii web depinde de mulţi factori, care nu pot fi controlaţi de echipa de dezvoltare. O abordare realizabilă pentru definirea cerinţelor de calitate implică specificarea criteriilor pentru testul de acceptare, specificând dacă o cerinţă a fost îndeplinită sau nu. (vezi de asemenea un exemplu al unui criteriu de acceptare pentru o cerinţă a calităţii în tabelul 2-1).

Atribut ExempluID 1.2.5Tip Uşurinţa în învăţareDescriere Aplicaţia web X trebuie să fie utilizabilă de

utilizatori web ocazionali, fără o instruire prealabilă

Raţionament Managerii de marketing sunt utilizatori frecvenţi ai sistemului

Criteriu de acceptare90% din membrii unui grup-test (selectat aleator) de utilizatori web ocazionali pot folosi Cazurile de Utilizare 2.3, 2.6 şi 2.9 fără o instruire preliminară

Prioritate Foarte important; greu de implementat

Cerinţe dependente 2.3.4, 2.3.6

Cerinţe contradictorii 4.5.6

Informaţii adiţionale Recomandări privind uşurinţa în folosire v1.2

Istoricul versiunii 1.06

Specificaţii de formatare

ComentariuIdentificator unicElement din taxonomia cerinţeiO explicaţie scurtă în limbaj natural

20

Explică de ce este importantă cerinţa O condiţie măsurabilă care trebuie îndeplinită pentru acceptareO expresie a importanţei şi fezabilităţii cerinţeiLista cerinţelor care depind de această cerinţăLista cerinţelor care sunt în conflict cu această cerinţăTrimiteri la informaţii adiţionaleUn număr al reviziei pentru a documenta istoricul dezvoltării

Calitatea interfeţei utilizator - adăugarea unor prototipuri pentru scenariile importante ale aplicaţiei

Calitatea conţinutului - acurateţea, obiectivitatea, credibilitatea, relevanţa, actualitatea, caracterul complet sau claritatea – CMS

Lipsa de experienţă a dezvoltatorilor – tehnologii de bază din aplicaţiile web relativ noi Date fixe de livrare - termen limită > negocierea şi stabilirea unei ordini de prioritate a

cerinţelor

Calitatea interfeţei utilizatorCalitatea interfeţei utilizator este un alt aspect hotărâtor pentru succesul aplicaţiilor web. Când realizează aplicaţii web dezvoltatorii trebuie să fie conştienţi de următorul fenomen: utilizatorii nu vor fi capabili să înţeleagă şi să aprecieze o aplicaţie web uitându-se la modele şi specificaţii abstracte; ei trebuie să experimenteze. De aceea, este foarte important să se completeze definirea şi descrierea cerinţelor prin adăugarea unor prototipuri pentru scenariile importante ale aplicaţiei[1]. Calitatea conţinutuluiMajoritatea metodelor tradiţionale de proiectare a cerinţelor neglijează conţinutul web, deşi este un aspect extrem de important al aplicaţiilor web. Pe lângă problemele legate de tehnologia software, dezvoltatorii trebuie să aibă în vedere conţinutul şi în special crearea şi întreţinerea acestuia. În contextul proiectării cerinţelor este esenţială specificarea nivelul dorit de calitate a conţinutului. Cele mai importante caracteristici de calitate includ acurateţea, obiectivitatea, credibilitatea, relevanţa, actualitatea, caracterul complet sau claritatea. Sistemele de management al conţinutului (CMS) au devenit importante şi permit reprezentarea concisă şi consistentă a conţinutului prin separarea conţinutului de layout şi oferirea utilitarelor de editare a conţinutului.Lipsa de experienţă a dezvoltatorilorMajoritatea tehnologiilor de bază din aplicaţiile web sunt relativ noi. Lipsa de experienţă cu instrumentele de dezvoltare, standardele şi limbajele acestor tehnologii pot conduce la estimări greşite când se ia în discuţie fezabilitatea şi costul implementării cerinţelor. Datele fixe de livrareMulte proiecte web au o dată fixă de livrare, toate activităţile şi deciziile trebuind să fie finalizate până la un termen limită. Negocierea şi stabilirea unei ordini de prioritate a cerinţelor sunt esenţiale în aceste condiţii.

[1] Constantine, L., Lockwood, L., Software for Use: A Practical Guide to Models and Methods for Usage-Centered Design, ACM Press, 2001

Principii pentru proiectarea cerinţelor aplicaţiilor web

Principiile derivă din stabilitatea modelului în spirală win-win Înţelegerea contextului sistemului - obiectivele afacerii clientului Implicarea părţilor interesate - cooperarea acestora activă şi directă pentru identificarea

şi negocierea cerinţelor, situaţii câştig-pierdere conduc adesea la situaţii pierdere-pierdere

În această secţiune vom descrie principiile de bază ale proiectării cerinţelor pentru aplicaţiile web. Aceste principii derivă din stabilitatea modelului în spirală în care câştigă toţi partenerii (modelul

21

win-win), un model de ciclu de viaţă iterativ şi orientat pe risc care pune accentul pe implicarea părţilor interesate şi pe extragerea şi punerea de acord asupra cerinţelor. Modelul în spirală win-win a influenţat multe modele bazate pe procese, inclusiv Procesul Unificat Raţional (RUP) de la IBM. Dezvoltatorii web trebuie să aibă în vedere următoarele principii pe parcursul activităţilor de proiectare a cerinţelor: Înţelegerea contextului sistemuluiMulte aplicaţii web sunt încă dezvoltate ca soluţii tehnice izolate, fără o înţelegere a rolului şi impactului acestora într-un context general. O aplicaţie web nu poate fi o finalitate prin ea însăşi; ea trebuie să ţină cont de obiectivele afacerii clientului. Pentru ca aplicaţia web să aibă succes este important să clarificăm contextul sistemului (de exemplu prin analizarea şi descrierea proceselor de afaceri existente) şi motivul pentru care sistemul va fi dezvoltat (“Pentru ce facem acest lucru?”). Dezvoltatorii trebuie să înţeleagă modul în care sistemul este implementat în mediul său. Analiza afacerii poate stabili valoarea unei aplicaţii web în raport cu resursele pe care le utilizează cerinţele. Înţelegerea contextului sistemului ajută şi la identificarea părţilor interesate, familiarizarea cu scopul aplicaţiei şi analizarea constrângerilor[1]. Implicarea părţilor interesatePărţile interesate sau reprezentanţii lor se află în centrul proiectării cerinţelor, iar cooperarea acestora activă şi directă pentru identificarea şi negocierea cerinţelor este importantă pentru fiecare fază a proiectului. Managerii de proiect trebuie să evite situaţiile în care participanţii la proiecte individuale câştigă pe seama altora. S-a demonstrat că asemenea situaţii câştig-pierdere evoluează adesea în situaţii pierdere-pierdere, determinând în final eşecul întregului proiect.Obiectivele, aşteptările şi cerinţele părţilor interesate trebuie stabilite şi negociate în mod repetat pentru a se adapta schimbărilor dinamice care apar în proiecte. Anterior am arătat că indisponibilitatea părţilor interesate şi caracterul multidisciplinar sunt specifice proiectării cerinţelor pentru ingineria web. Aceste caracteristici conduc la stabilirea următoarelor cerinţe pentru contextul aplicaţiilor web: identificarea părţilor interesate sau a reprezentanţilor acestoraînţelegerea obiectivelor şi aşteptărilor părţilor interesatenegocierea perspectivelor, experienţelor şi cunoştinţelor (caracter multidisciplinar).Metodele şi utilitarele de proiectare a cerinţelor trebuie să fie în concordanţă cu aceste cerinţe şi trebuie să contribuie la schimbul efectiv de cunoştinţe dintre participanţii la proiect, să permită un proces de instruire în echipă, dezvoltarea unei viziuni comune a părţilor interesate şi să ajute la detectarea din timp a cerinţelor contradictorii. [1] Biffl, S., Aurum, A., Boehm, B. W., Erdogmus, H., Gr¨unbacher, P., Value-based Software Engineering, Springer-Verlag, September 2005

Definirea iterativă a cerinţelor - în concordanţă cu alte rezultate ale dezvoltării (arhitectură, interfaţă utilizator, conţinut, cazuri de testare etc.); abordare iterativă - necesară în special într-un mediu în care cerinţele şi constrângerile sunt schimbătoare

Focalizarea pe arhitectura sistemului - inţelegerea soluţiilor tehnice împreună cu posibilităţile şi limitările lor sunt esenţiale

Riscuri - problemele nedetectate, cele nerezolvate şi conflictele dintre cerinţe; Diminuarea riscului - prototipizarea, lansarea rapidă a unor versiuni ale aplicaţiei web pentru a colecta feedback-ul utilizatorilor sau încorporarea precoce a componentelor externe pentru a elimina problemele majore ale integrării tardive.

Definirea iterativă a cerinţelorAbordarea în cascadă a definirii cerinţelor nu funcţionează în medii dinamice, iar cerinţele trebuie dobândite în mod iterativ în dezvoltarea aplicaţiilor web. Cerinţele trebuie să fie în concordanţă cu alte rezultate ale dezvoltării (arhitectură, interfaţă utilizator, conţinut, cazuri de testare etc.). La iniţierea proiectului, cerinţele cheie sunt de obicei definite la un nivel înalt de abstractizare. Aceste cerinţe preliminare pot fi utilizate pentru a dezvolta arhitecturi fezabile, scenarii de utilizare a sistemului şi planurile iniţiale ale proiectului. Pe măsură ce proiectul progresează rezultatele

22

dezvoltării pot fi perfecţionate gradat prin specificarea unor termeni mai concreţi, asigurând în continuare consistenţa lor. O abordare iterativă este necesară, în special într-un mediu în care cerinţele şi constrângerile sunt schimbătoare, pentru a putea reacţiona într-un mod flexibil pe măsură ce proiectul evoluează. Dacă echipa de dezvoltare primeşte termeni limită ficşi, atunci o abordare de dezvoltare iterativă permite selectarea cerinţelor cheie care trebuie implementate primele. Focalizarea pe arhitectura sistemuluiTehnologiile existente şi soluţiile de moştenire au un impact sporit asupra cerinţelor aplicaţiilor web. Înţelegerea soluţiilor tehnice împreună cu posibilităţile şi limitările lor este esenţială. Extragerea cerinţelor nu poate avea loc fără a se ţine seama de arhitectură, în special la definirea cerinţelor. Luarea în considerare a arhitecturii sistemului permite dezvoltatorilor să înţeleagă mai bine impactul soluţiilor existente asupra cerinţelor şi să estimeze fezabilitatea acestora. Modelul Twin-Peaks (vezi figura) propune atât perfecţionarea cerinţelor cât şi a arhitecturii sistemului într-o manieră iterativă, sporind continuu nivelul de detaliere. RiscuriProblemele nedetectate, cele nerezolvate şi conflictele dintre cerinţe reprezintă riscuri majore ale proiectului. Problemele obişnuite de risc sunt integrarea componentelor existente în aplicaţia web, anticiparea aspectelor de calitate a sistemului sau lipsa de experienţă a dezvoltatorilor. De aceea evaluarea riscului trebuie realizată pentru toate cerinţele, iar riscurile identificate trebuie controlate pe parcursul proiectului, pentru a ne asigura că nu sunt urmate alternativele riscante pentru sistem. Diminuarea riscului trebuie realizată cât mai devreme posibil, putând include de exemplu prototipizarea, lansarea rapidă a unor versiuni ale aplicaţiei web pentru a colecta feedback-ul utilizatorilor sau încorporarea precoce a componentelor externe pentru a evita problemele majore ale integrării tardive.

Adaptarea metodelor de proiectare a cerinţelor dezvoltării aplicaţiilor web

Ce tipuri de cerinţe sunt importante pentru aplicaţia web?- Cum vor fi descrise şi documentate cerinţele pentru aplicaţia web?- Care sunt gradele utile ale detalierii şi formalismului? - Trebuie avută în vedere folosirea utilitarelor? Care dintre acestea sunt potrivite pentru nevoile specifice ale proiectului?

În prezent sunt disponibile numeroase metode, ghiduri, notaţii, cataloage şi utilitare pentru toate activităţile de proiectare a cerinţelor. Totuşi, dezvoltatorii trebuie să evite o abordare unitară, metodele de proiectare a cerinţelor trebuind adaptate permanent specificului proiectării web şi situaţiilor care apar în anumite proiecte. Principiile descrise anterior ne conduc la definirea unei abordări de proiectare a cerinţelor specifică proiectelor pentru web. Dezvoltatorii trebuie să clarifice următoarele aspecte pe parcursul procesului de adaptare: - Ce tipuri de cerinţe sunt importante pentru aplicaţia web?- Cum vor fi descrise şi documentate cerinţele pentru aplicaţia web? Care sunt gradele utile ale detalierii şi formalismului? - Trebuie avută în vedere folosirea utilitarelor? Care dintre acestea sunt potrivite pentru nevoile specifice ale proiectului?

Tipuri de cerinţe

Cerinţele funcţionale - capacităţile şi serviciile pe care un sistem ar trebui să le ofere - transferul de bani > scenariile de tip utilizare de caz (use case) şi specificaţiile de formatare

Cerinţe privind conţinutul - specifică conţinutul care trebuie să-l prezinte aplicaţia web Cerinţe privind calitatea - nivelul calităţii serviciilor

Funcţionalitatea - prezenţa funcţiilor > concordanţa, precizia, interoperabilitatea, complianţa şi securitatea

23

Siguranţa - menţinere nivel de performanţă > maturitatea, toleranţa la erori şi capacitatea de recuperare

Uşurinţa în folosire - efortul necesar pentru a utiliza un produs software > uşurinţa în înţelegere, învăţare şi operare

Eficienţa - raportul dintre nivelul de performanţă şi resursele utilizate > comportamentul în timp, comportamentul resurselor

Întreţinerea - efortul pentru a implementa modificări prestabilite > posibilitatea de analiză, schimbare, stabilitate şi testare

Portabilitatea - capacitatea produsului software de a fi mutat dintr-un mediu în altul > capacitatea de adaptare, instalare, potrivire şi înlocuire

Organizaţiile de standardizare şi cele comerciale au dezvoltat un număr mare de taxonomii pentru definirea şi clasificarea diferitelor tipuri de cerinţe (de exemplu Volere[1] sau IEEE 830-1998). Majoritatea taxonomiilor fac distincţie între cerinţele funcţionale şi cele non-funcţionale. Cerinţele funcţionale descriu capacităţile şi serviciile unui sistem (de exemplu „Utilizatorul poate selecta o iconiţă pentru a vizualiza articolele din coşul de cumpărături în orice moment.”). Cerinţele non-funcţionale descriu proprietăţile capacităţilor şi nivelul dorit al serviciilor (de exemplu „Aplicaţia web va suporta cel puţin 2500 de utilizatori concurenţi.”). Alte cerinţe non-funcţionale se referă la constrângerile proiectului şi interfeţele sistemului.

În continuare vom discuta pe scurt tipurile de cerinţe relevante pentru proiectele de dezvoltare web:

Cerinţe funcţionaleCerinţele funcţionale specifică capacităţile şi serviciile pe care un sistem ar trebui să le

ofere (de exemplu transferul de bani într-o aplicaţie de online banking). Cerinţele funcţionale sunt frecvent descrise utilizând scenariile de utilizare de caz şi specificaţiile de formatare[2].

Cerinţe privind conţinutul Cerinţele privind conţinutul specifică conţinutul care ar trebui prezentat de aplicaţia web.

Conţinutul poate fi descris, de exemplu, sub forma unui glosar.Cerinţe privind calitatea Cerinţele privind calitatea descriu nivelul de calitate al serviciilor şi capacităţilor şi specifică proprietăţi importante ale sistemului cum ar fi securitatea, performanţa sau uşurinţa în folosire[3]. Standardul internaţional ISO/IEC 9126 defineşte un model independent de tehnologie pentru calitatea softului, care cuprinde 6 caracteristici de calitate, fiecare având propriile trăsături.Cele şase caracteristici sunt:• Funcţionalitatea – descrie prezenţa funcţiilor care îndeplinesc proprietăţile definite. Trăsăturile sunt concordanţa, precizia, interoperabilitatea, complianţa şi securitatea. • Siguranţa – descrie capacitatea unui produs software de a-şi menţine nivelul de performanţă în anumite condiţii pe o perioadă definită de timp. Trăsăturile sunt maturitatea, toleranţa la erori şi capacitatea de recuperare.• Uşurinţa în folosire – descrie efortul necesar pentru a utiliza un produs software şi evaluarea sa individuală de către un grup de utilizatori definit sau presupus. Trăsături: uşurinţa în înţelegere, învăţare şi operare. • Eficienţa - descrie raportul între nivelul de performanţă al unui produs software şi resursele pe care acesta le utilizează în anumite condiţii. Trăsături: comportamentul în timp, comportamentul resurselor.• Întreţinerea – descrie efortul necesar pentru a implementa modificări prestabilite într-un produs software. Trăsături: posibilitatea de analiză, schimbare, stabilitate şi testare. • Portabilitatea – descrie capacitatea unui produs software de a fi mutat dintr-un mediu în altul. Trăsături: capacitatea de adaptare, instalare, potrivire şi înlocuire. Au fost făcute diverse încercări de către cercetători pentru a extinde acest model de bază la caracteristicile specifice web-ului. În capitolele ulterioare vom insista asupra uşurinţei în folosire, performanţei şi securităţii, care reprezintă aspecte de calitate esenţiale pentru succesul aplicaţiilor web. [1] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999

24

[2] Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2001[3] Chung, L., Nixon, B. A., Yu, E., Mylopoulos, J., Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000

Cerinţele mediului sistem - modul în care o aplicaţie web este inclusă în mediul ţintă şi interacţionează cu componentele externe - hardware

Cerinţele interfeţei utilizator - ghidarea intuitivă şi autoexplicativă a utilizatorilor - hipertextul (structura de navigare – proces de modelare) şi prezentarea (interfaţa utilizator) > prototipuri

Cerinţe posibile pe parcursul dezvoltării - anticipare cerinţe care ar putea apare după folosirea pe termen scurt a aplicaţiei (utilizatori concurenti - arhitecturi a sistemului scalabile)

Constrângerile proiectului - bugetul şi planul, limitările tehnice, standardele, tehnologia de dezvoltare folosită

Cerinţele mediului sistemuluiAceste cerinţe descriu modul în care o aplicaţie web este inclusă în mediul ţintă şi interacţionează cu componentele externe, incluzând de exemplu sistemele de moştenire, componentele comerciale autonome sau un hardware special. De exemplu, dacă o aplicaţie web se presupune că va fi disponibilă global, atunci în cerinţele de mediu trebuie să se specifice detaliile. Cerinţele interfeţei utilizatorDeoarece se presupune că utilizatorii web folosesc aplicaţia web fără o instruire formală, ghidarea intuitivă şi auto-explicativă a utilizatorilor este esenţială pentru acceptarea aplicaţiei. Cerinţele privitoare la interfaţa utilizator definesc modul în care o aplicaţie web interacţionează cu diferite tipuri de clase de utilizatori. Principalele aspecte sunt hipertextul (structura de navigare) şi prezentarea (interfaţa utilizator). Detaliile de navigare şi prezentare sunt definite în mod normal în procesul de modelare, dar deciziile iniţiale privind proiectarea interfeţei utilizator trebuie luate pe parcursul extragerii cerinţelor. Prototipurile sunt cele mai potrivite în această situaţie. Constantine şi Lockwood sugerează că utilizatorii trebuie să coopereze în proiectarea scenariilor pentru anumite sarcini. Proiectarea centrată pe utilizare se bazează pe crearea şi reglarea/îmbunătăţirea iterativă a modelelor pentru roluri, sarcini şi interacţiuni[1]. Cerinţe posibile pe parcursul dezvoltăriiProdusele software în general şi aplicaţiile web în particular sunt subiectul unei evoluţii şi îmbunătăţiri continue. Din acest motiv dezvoltatorii web trebuie să anticipeze cerinţele care ar putea apare după folosirea planificată pe termen scurt a aplicaţiei. De exemplu, o cerinţă de calitate care solicită suplimentarea cu 5000 de utilizatori concurenţi în doi ani trebuie avută în vedere, prin definirea unei arhitecturi a sistemului scalabile. Cerinţele ce pot apărea în evoluţie sunt posibile pentru toate tipurile de cerinţe discutate (de exemplu capacităţile viitoare, cerinţele de securitate viitoare).Constrângerile proiectuluiConstrângerile proiectului nu sunt negociabile pentru părţile interesate ale proiectului şi includ de obicei bugetul şi planul, limitările tehnice, standardele, tehnologia de dezvoltare folosită, regulile de desfăşurare, aspectele de întreţinere, constrângerile operaţionale şi aspectele legale sau culturale care afectează proiectul. [1] Constantine, L., Lockwood, L., Software for Use: A Practical Guide to Models and Methods for Usage-Centered Design, ACM Press, 2001

Notaţii

Relatările - descrieri colocviale ale proprietăţilor dorite > exemplu de scenariu Cerinţele specificate - simple specificaţii în limbajul natural

25

Specificaţiile de formatare - sintaxă precis definită, dar permit şi descrieri în limbajul natural. Exemple: descrierile de utilizare de caz din UML

Specificaţiile formale - scrise într-un limbaj care utilizează o sintaxă şi semantică definite formal

Sunt disponibile variate notaţii pentru specificarea cerinţelor la diferite nivele de detaliere şi formalitate. Exemple: relatări, specificaţii de formatare, specificaţii formale.RelatărileRelatările - sunt descrieri colocviale ale proprietăţilor dorite; ele sunt utilizate pentru a stabili o înţelegere între clienţi şi dezvoltatori. Exemple: relatările utilizatorilor din Extreme Programming[1]. Relatarea unui utilizator este formulată de către un client folosind terminologia şi limbajul propriu şi descrie problemele pe care sistemul ar trebui să le rezolve pentru acel client.Un exemplu de scenariu din perspectiva clientului poate fi următorul: Un utilizator verifică produsele adăugate în coşul de cumpărături online. Datele de intrare sunt validate atunci când utilizatorul face clic pe <Continuare>. Dacă nu sunt găsite erori comanda va fi acceptată şi va fi trimisă utilizatorului o confirmare prin e-mail. Cerinţele specificateCerinţele specificate sunt simple specificaţii în limbajul natural. Fiecare cerinţă are un identificator unic. Un bun exemplu este descrierea unui element de tip dată specificat în IEEE/EIA-J-STD- 016.Specificaţiile de formatareSpecificaţiile de formatare utilizează o sintaxă precis definită, dar permit şi descrieri în limbajul natural. Exemple: descrierile de utilizare de caz din UML (Unified Modeling Language), RDD-100 Requirements Specification Language, ghidurile MBASE SSRD sau Volere Shell.Tabelul 2.1 prezintă un exemplu al unei specificaţii de formatare, principalele atribute fiind: descriere, prioritate, raţionament şi istoricul versiunii. Fiecare cerinţă este identificată individual şi poate fi referită pe parcursul procesului în orice moment utilizând un ID unic. Interdependenţele cu alte cerinţe şi rezultate ale dezvoltării (cum ar fi documentele sau planurile arhitecturii) sunt reţinute pentru a susţine trasabilitatea.Cazurile de utilizare UML sunt utile pentru a descrie cerinţele funcţionale. Un caz de utilizare descrie o funcţie a sistemului din perspectiva actorilor acestuia şi conduce la un rezultat perceptibil de către actori. Un actor este o entitate externă sistemului care interacţionează cu sistemul. O diagramă de utilizare de caz prezintă relaţiile dintre cazurile de utilizare şi actori. Diagramele de utilizare de caz sunt utile pentru a ilustra dependenţele strânse dintre cazurile de utilizare şi actori; detaliile cazului de utilizare sunt definite în specificaţiile de formatare. Atributele descriu numărul şi numele cazului de utilizare, actorii implicaţi, condiţiile anterioare şi posterioare, evoluţia, excepţiile şi erorile, variaţiile, sursa, raţionamentul sau interdependenţele cu alte diagrame UML. Specificaţiile formaleSpecificaţiile formale sunt scrise într-un limbaj care utilizează o sintaxă şi semantică definite formal. Cel mai bun exemplu este “Z” (ISO/IEC13,568:2002). Specificaţiile formale sunt rar utilizate pentru aplicaţiile web. Oportunitatea Tabelul anterior compară diferite notaţii în ceea ce priveşte precizia atributelor, uşurinţa validării, raportul eficacitate-cost, folosirea de către non-experţi şi scalabilitatea. O precizie minimă-medie va fi suficientă pentru specificarea cerinţelor aplicaţiei web, iar o validare formală nu este cerută de obicei. Este important să păstrăm scăzut efortul de extragere şi management al cerinţelor, iar aceste cerinţe să fie înţelese şi de către non-experţi. Scalabilitatea este o problemă pusă pe seama complexităţii ridicate a multor aplicaţii web. În tabelul anterior putem observa că formele de descrieri informale şi semi-formale (relatările, listele de cerinţe şi specificaţiile de formatare) sunt adecvate în special pentru aplicaţiile web.

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

Utilitare

26

Extragerea cerinţelor - EasyWinWin Validarea cerinţelor - sistemele de răspuns online (feedback) Managementul cerinţelor - managementul tuturor cerinţelor ce aparţin unui proiect într-un

depozit central - http://www.paper-review.com/tools/rms/read.php

UtilitareExistă numeroase categorii de utilitare care folosesc activităţile de proiectare a cerinţelor descrise. Utilitare existente pentru proiectarea cerinţelor nu sunt limitate la aplicaţiile web, dar pot fi adaptate la specificul dezvoltării aplicaţiilor web.Extragerea cerinţelorMetode şi utilitare de negociere au fost dezvoltate şi explorate în multe discipline. EasyWinWin este o abordare bazată pe groupware care îndrumă o echipă de parteneri în efortul de dobândire şi negociere a cerinţelor. EasyWinWin defineşte un set de activităţi ale unui proces de negociere, un moderator îndrumând partenerii pe parcursul întregului proces. Această abordare utilizează tehnici de încurajare a grupurilor de lucru, care sunt susţinute de utilitare colaborative (brainstorming electronic, clasificări, sisteme de votare, etc.). Aceste activităţi sunt: revizuirea şi extinderea subiectelor de negociere, …..intereselor partenerilor; convergenţa spre condiţiile de câştig, extragerea unui vocabular de termeni comuni, stabilirea nivelului de prioritate pentru condiţiile de câştig, evidenţierea problemelor şi constrângerilor, identificarea problemelor şi opţiunilor şi negocierea acordurilor. Validarea cerinţelorDatorită caracterului deschis al Internetului sistemele de răspuns online (feedback) pot completa sau chiar înlocui metode costisitoare (întâlniri sau interviuri) pentru validarea cerinţelor aplicaţiei web. De exemplu, utilizatorii Internetului pot fi invitaţi să participe la sondaje pe web pentru a comunica gradul lor de mulţumire faţă de o aplicaţie web. Remarcăm în acest context că datorită spontaneităţii comportamentului interactiv deseori nu putem observa o aprobare sau o negare ci doar indiferenţă. Dacă unui utilizator îi place aplicaţia web o va utiliza, dar va fi reticent la trimiterea unui feedback (de exemplu informaţii privind erorile găsite) pentru a contribui la dezvoltarea şi îmbunătăţirea aplicaţiei.Managementul cerinţelorUtilitarele pentru managementul cerinţelor permit managementul tuturor cerinţelor ce aparţin unui proiect într-un depozit central. Spre deosebire de sistemele de procesare a textului, utilitarele de management al cerinţelor stochează cerinţele într-o bază de date. Asemenea specificaţiilor de formatare, atributele relevante sunt administrate pentru fiecare din aceste cerinţe (vezi tabelul ). Sistemele de management al cerinţelor sunt importante pentru managementul modificărilor şi cerinţelor. O trecere în revistă a utilitarelor existente poate fi găsită la http://www.paper-review.com/tools/rms/read.php .

Modelare

Obiecte. Clase

obiect - entitate care are identitate, stare si comportament clasa - descriere a unei multimi de obiecte care au aceleasi caracteristici structurale si

comportamentale

27

http://www.paper-review.com/tools/rms/read.php

Putem privi o clasa, in acelasi timp, ca fiind:- o descriere generala a unui numar de obiecte- o colectie de metode (operatii) ce pot fi efectuate de instantele clasei- un mecanism pentru stabilirea si reutilizarea conceptelor- o abstractizare a unui obiect- un tip de dataUn obiect care apartine unei clase este instanta a acelei clase

Modelare

Folosirea de modele poate inlesni abordarea de probleme complexe. Un model este o simplificare unui anumit sistem, ce permite analizarea unora dintre proprietatile acestuia. Lucrul cu modelele poate facilita o mai buna intelegere a sistemului modelat, datorita dificultatii de intelegere a sistemului in intregul sau. Formalismul limbajului de modelare consta din stabilirea de elemente cu o semantica asupra careia se convine si cu ajutorul carora sa se poata trasmite idei in mod cat mai eficient si neambiguu.

Limbajul de modelare UML- defineasca o modalitate cat mai precisa, generala si extensibila de comunicare a

modelelor- a fost creat in primul rand pentru a facilita proiectarea programelor, insa datorita

expresivitatii sale poate fi folosit si in alte domenii (proiectare hardware, modelarea proceselor de afaceri)

Modelul este o simplificare a realitatii. Aceasta simplificare retine caracteristicile relevante ale unui sistem, in timp ce le ignora pe celelalte.

Limbajul natural- cel mai la indemana limbaj de modelare. - folosirea sa induce adesea neclaritati si inconsistente. Apare astfel necesitatea definirii

unui limbaj neambiguu de specificat modele.

Limbajul de modelare UML isi propune sa defineasca o modalitate cat mai precisa, generala si extensibila de comunicare a modelelor. El a fost creat in primul rand pentru a facilita proiectarea programelor, insa datorita expresivitatii sale poate fi folosit si in alte domenii (proiectare hardware, modelarea proceselor de afaceri etc.) Limbajul natural pare sa fie cel mai la indemana limbaj de modelare. Experienta arata insa ca folosirea sa induce adesea neclaritati si inconsistente. Apare astfel necesitatea definirii unui limbaj neambiguu de specificat modele. Se convine asupra unui set de elemente ale limbajului precum si asupra semanticii acestora. Evident, descrierea elementelor si a semanticii se face in ultima instanta in limbaj natural, deci pot apare ambiguitati. In acest caz insa, limbajul natural este folosit numai intr-o mica parte a sistemului si problemele de semantica pot fi localizate. Eliminarea ambiguitatilor din modele poate fi facuta imbunatatind precizia limbajului de modelare si nu cautand erori de semantica in intreaga descriere a modelului.

UML 1989-1994 - Booch (Grady Booch), OOSE - Object-Oriented Software Engineering (Ivar

Jacobson) si OMT - Object Modeling Technique (James Rumbaugh) creatorii lor puneau accentul pe anumite idei de modelare

1994 – unificare 1996 - consortiu UML

Perioada 1989-1994. Limbajele de modelare de success din aceasta perioada sunt Booch (Grady Booch), OOSE - Object-Oriented Software Engineering (Ivar Jacobson) si OMT - Object Modeling

28

Technique (James Rumbaugh). Aceste limbaje aveau propriile punce tari si slabiciuni, dupa cum creatorii lor puneau accentul pe anumite idei de modelare. Astfel, utilizatorii gaseau tehnicile de modelare ce le erau necesare unui proiect particular numai in anumite limbaje, fapt ce a alimentat ”razboiul metodelor”. La mijlocul anilor 1990, cand este semnalata o noua generatie de limbaje de modelare, a inceput un proces de omogenizare, prin incorporarea in fiecare limbaj a caracteristicilor gasite in celelalte limbaje.Cei trei autori ai limbajelor de modelare principale, Booch, Rumbaugh si Jacobson, au ajuns la concluzia ca ar fi mai bine sa conduca evolutia limbajelor lor pe un acelasi drum, pentru a elimina diferentele gratuite ce nu faceau decat sa incurce utilizatorii. Un al doilea motiv a lost unul pragmatic, reiesit din necesitatea industriei software de a avea o oarecare stabilitate pe piata limbajelor de modelare. Al treilea motiv a lost convingerea ca prin unirea fortelor se pot aduce imbunatatiri tehnicilor existente.Dezvoltarea UML a inceput in mod oficial in octombrie 1994, cand Rumbaugh s-a alaturat lui Booch in cadrul companiei Rational Software, ambii lucrand la unificarea limbajelor Booch si OMT. Pe parcursul anului 1996, ca o consecinta a reactiilor comunitatii proiectantilor de sistem, a devenit clar ca UML este vazut de catre multe companii ca o optiune strategica pentru dezvoltarea produselor lor. A fost creat un consortiu UML format din organizatii doritoare sa aloce resurse pentru a obtine o definitie finala a UML. Dintre aceste companii care au contribuit la crearea UML 1.0 au facut parte DEC, Hewlet-Packard, I-Logix, Intellicorp,and Rumbaugh s-a alaturat lui Booch in cadrul companiei Rational Software, ambii lucrand la unificarea limbajelor Booch si OMT, IBM, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments etc. UML 1.0 a fost propus spre standardizare in cadrul OMG in ianuarie 1997.Pana la sfarsitul anului 1997 echipa care lucra la UML s-a extins, urmand o perioada in care UML a primit o specificare formala mai riguroasa. Versiunea UML 1.1 a fost adoptata ca standard de catre OMG in noiembrie 1997.

UML (Unified Modeling Language) - limbaj de modelare bazat pe notatii grafice folosit pentru a specifica, vizualiza, construi si documenta componentele unui program

Tipuri de diagrame UML Diagrama cazurilor de utilizare (Use Case Diagram) Diagrama de clase (Class Diagram) Diagrame care descriu comportamentul:

Diagrame de interactiuni {Interactions Diagrams) Diagrama de secventa {Sequence Diagram) Diagrama de colaborare {Collaboration Diagram)

Diagrama de stari {Statechart Diagram) Diagrama de activitati {Activity Diagram)

Diagrame de implementare: Diagrama de componente {Component Diagram) Diagrama de plasare {Deployment Diagram)

UML (Unified Modeling Language) este un limbaj de modelare bazat pe notatii grafice folosit pentru a specifica, vizualiza, construi si documenta componentele unui program Tipuri de diagrame existente in UML sunt:Diagrama cazurilor de utilizare (Use Case Diagram)Diagrama de clase (Class Diagram)Diagrame care descriu comportamentul:Diagrame de interactiuni {Interactions Diagrams)Diagrama de secventa {Sequence Diagram)Diagrama de colaborare {Collaboration Diagram)Diagrama de stari {Statechart Diagram)Diagrama de activitati {Activity Diagram)Diagrame de implementare:Diagrama de componente {Component Diagram)

29

Diagrama de plasare {Deployment Diagram)

Diagrama cazurilor de utilizare ( Use Case Diagram)

folosita in UML pentru a modela aspectele dinamice ale unui program alaturi de diagrama de activitati, diagrama de stari, diagrama de secventa si diagrama de colaborare

Elementele componente - use case-uri, actori si relatiile care se stabilesc intre acestea

Diagrama cazurilor de utilizare ( Use Case Diagram) Nici un program nu este izolat, el interactionand cu oameni sau cu alte sisteme pentru indeplinirea unui scop.O diagrama use case este una din cele 4 diagrame folosite in UML pentru a modela aspectele dinamice ale unui program alaturi de diagrama de activitati, diagrama de stari, diagrama de secventa si diagrama de colaborare.Elementele componente ale unei diagrame use case sunt use case-uri, actori si relatiile care se stabilesc intre acestea.

Use case-uri (cazuri de utilizare) - reprezinta cerinte ale utilizatorilor- descriere a unei multimi de secvente de actiuni (incluzand variante) pe care un program le

executa atunci cand interactioneaza cu entitatile din afara lui (actori) si care conduc la obtinerea unui rezultat observabil si de folos actorului

- descrie ce face un program sau subprogram, dar nu precizeaza nimic despre cum este realizata (implementata) o anumita functionalitate

Un use case (caz de utilizare) reprezinta cerinte ale utilizatorilor. El este o descriere a unei multimi de secvente de actiuni (incluzand variante) pe care un program le executa atunci cand interactioneaza cu entitatile din afara lui (actori) si care conduc la obtinerea unui rezultat observabil si de folos actorului. Un use case descrie ce face un program sau subprogram, dar nu precizeaza nimic despre cum este realizata (implementata) o anumita functionalitate.Fiecare use case are un nume prin care se deosebeste de celelalte use case-uri. Acesta poate fi un sir arbitrar de caractere, insa de regula numele sunt scurte fraze verbale care denumesc un comportament ce exista in vocabularul sistemului ce trebuie modelat.Figura 7.3 prezinta notatia grafica pentru use case.Comportamentul unui use case poate fi specificat descriind un flux de eveni-mente intr-un text suficient de clar ca sa poata fi inteles de cineva din exterior (de exemplu utilizatorul). Acest flux de evenimente trebuie sa includa cum in-cepe si se termina use case-ul atunci cand acesta interactioneaza cu actori, ce obiecte sunt interschimbate, precum si ffuxuri alternative ale acestui comportament. Aceste ffuxuri de evenimente reprezinta scenarii posibile de utilizare a sistemului.Identificarea use case-urilor se face pornind de la cerintele utilizatorului si analizand descrierea problemei.

Notatia grafica pentru use case

Comportamentul unui use case - specificat descriind un flux de evenimente intr-un text suficient de clar ca sa poata fi inteles de cineva din exterior (de exemplu utilizatorul)

Acest flux de evenimente trebuie sa includa cum incepe si se termina use case-ul atunci cand acesta interactioneaza cu actori, ce obiecte sunt interschimbate, precum si fluxuri alternative ale acestui comportament.

30

Identificarea use case-urilor se face pornind de la cerintele utilizatorului si analizand descrierea problemei.

Un use case (caz de utilizare) reprezinta cerinte ale utilizatorilor. El este o descriere a unei multimi de secvente de actiuni (incluzand variante) pe care un program le executa atunci cand interactioneaza cu entitatile din afara lui (actori) si care conduc la obtinerea unui rezultat observabil si de folos actorului. Un use case descrie ce face un program sau subprogram, dar nu precizeaza nimic despre cum este realizata (implementata) o anumita functionalitate.Fiecare use case are un nume prin care se deosebeste de celelalte use case-uri. Acesta poate fi un sir arbitrar de caractere, insa de regula numele sunt scurte fraze verbale care denumesc un comportament ce exista in vocabularul sistemului ce trebuie modelat.Figura prezinta notatia grafica pentru use case.Comportamentul unui use case poate fi specificat descriind un flux de evenimente intr-un text suficient de clar ca sa poata fi inteles de cineva din exterior (de exemplu utilizatorul). Acest flux de evenimente trebuie sa includa cum incepe si se termina use case-ul atunci cand acesta interactioneaza cu actori, ce obiecte sunt interschimbate, precum si fluxuri alternative ale acestui comportament. Aceste fluxuri de evenimente reprezinta scenarii posibile de utilizare a sistemului.Identificarea use case-urilor se face pornind de la cerintele utilizatorului si analizand descrierea problemei.

Notatia grafica pentru actor

Actorii - o multime de roluri pe care utilizatorii unor use case-uri le joaca atunci cand interactioneaza cu aceste use case-uri. Actorii sunt entitati exterioare sistemului.

Moduri in care actorii pot interactiona cu un sistem: folosind sistemul, adica initiaza executia unor use case-uri. fiind folositi de catre sistem, adica ofera functionalitate pentru realizarea unor use case-uri.

Fiecare actor trebuie sa comunice cu cel putin un use case

Actorii reprezinta o multime de roluri pe care utilizatorii unor use case-uri le joaca atunci cand interactioneaza cu aceste use case-uri. Actorii sunt entitati exterioare sistemului. Ei pot fi utilizatori (persoane), echipamente hardware sau alte programe. Fiecare actor are un nume care indica rolul pe care acesta il joaca in interactiunea cu programul.Notatie grafica pentru un actor este ilustrata in figura. Exista doua moduri in care actorii pot interactiona cu un sistem:folosind sistemul, adica initiaza executia unor use case-uri.fiind folositi de catre sistem, adica ofera functionalitate pentru realizarea unor use case-uri.Fiecare actor trebuie sa comunice cu cel putin un use case.Pentru identificarea actorii ar trebui sa raspundem la urmatoarele intrebari:Cine foloseste programul?De cine are nevoie programul pentru a-si indeplini sarcinile?Cine este responsabil cu administrarea sistemului?Cu ce ehipamente externe trebuie sa comunice programul?Cu ce sisteme software externe trebuie sa comunice programul?Cine are nevoie de rezultatele (raspunsurile) oferite de program?

31

Notatia grafica pentru relatia de dependenta de tip include

Notatia grafica pentru relatia de dependenta de tip extend

Notatia grafica pentru relatia de generalizare intre use case-uri

Tipuri de roluri jucate de actori in interactiunea cu use case-ul UC

Relatiile - tipuri: asociere, dependenta si generalizareRelatia de asociere - poate exista intre actori si use-case-uri, sau intre use-case-uri. Este folosita pentru a exprima interactiunea (comunicarea) intre elementele pe care le uneste. Relatia de dependenta - se poate stabili numai intre use-case-uri; tipuri: include si extendRelatia de generalizare - se stabilieste intre elemente de acelasi tip (doi actori, sau doua use-case-uri). Este similara relatiiei de generalizare (mostenire) care se stabilieste intre clase. Elementul derivat mosteneste comportamentul si relatiile elementului de baza.

Utilizari ale diagramei use case: pentru a modela contextul unui sistem: determinarea granitelor sistemului si a actorilor cu

care acesta interactioneaza. pentru a modela cerintele unui sistem: ce trebuie sa faca sistemul (dintr-un punct de vedere

exterior sistemului) independent de cum trebuie sa faca. Va rezulta specificarea comportamentului dorit. Sistemul apare ca o cutie neagra. Ceea ce se vede este cum reactioneaza el la actiunile din exterior.

RelatiiRelatiile pot fi de mai multe tipuri: asociere, dependents si generalizare Relatia de asocierePoate exista intre actori si use-case-uri, sau intre use-case-uri. Este folosita pentru a exprima interactiunea (comunicarea) intre elementele pe care le uneste. Relatia de asociere se reprezinta grafic printr-o linie si este evidentiata in figura 7.5.Relatia de dependentaSe poate stabili numai intre use-case-uri. Relatiile de dependenta pot fi de doua tipuri: include si extend.Dependenta de tip includeNotatie grafica este data in figura 7.6.In acest caz comportamentul use case-ului B este inclus in use case-ul A. B este de sine statator, insa este necesar pentru a asigura functionalitatea use case-ului de baza A.Dependenta de tip include se foloseste pentru a scoate in evidenta un comportament comun (B poate fi inclus in mai multe use case-uri de baza).Dependenta de tip extend

32

Notatie grafica se poate vedea in figura 7.7.In acest caz comportamentul use case-ului B poate fi inglobat in use case-ul A. A si B sunt de sine statatoare. A controleaza daca B va fi executat sau nu. Punctele de extensie specifica locul in care use case-ul specializat (B) extinde use case-ul de baza (A). Relatia de generalizareSe stabilieste intre elemente de acelasi tip (doi actori, sau doua use-case-uri). Este similara relatiiei de generalizare (mostenire) care se stabilieste intre clase. Elementul derivat mosteneste comportamentul si relatiile elementului de baza.Figura 7.8 ilustreaza notatia grafica pentru relatia de generalizare intre use case-uri.in figura 7.9actorii A si B joaca acelasi rol R atunci cand comunica cu use case-ul UC (a), si joaca roluri diferite in interactiunea cu use case-ul UC (b).Utilizari ale diagramei use case:pentru a modela contextul unui sistem: determinarea granitelor sistemului si a actorilor cu care acesta interactioneaza.pentru a modela cerintele unui sistem: ce trebuie sa faca sistemul (dintr-un punct de vedere exterior sistemului) independent de cum trebuie sa faca. Va rezulta specificarea comportamentului dorit. Sistemul apare ca o cutie neagra. Ceea ce se vede este cum reactioneaza el la actiunile din exterior.

Diagrama de clase - Clase

33

folosita pentru a modela structura (viziunea statica asupra) unui sistem contine de obicei clase, si relatii care se stabilesc intre acestea

Clasa - reprezinta entitati software, entitati hardware sau concepte

Nume - prin care se distinge de alte claseAtribute - numele unei proprietati a claseiOperatii (metode) – reprezinta implementarea unui serviciu care poate fi cerut oricarui obiect al clasei.O clasa poate avea oricate atribute si operatii sau poate sa nu aiba nici un atribut sau nici o operatie.

Diagrama de claseEste folosita pentru a modela structura (viziunea statica asupra) unui sistem. O astfel de diagrama contine de obicei clase, si relatii care se stabilesc intre acestea.O clasa poate reprezenta entitati software, entitati hardware sau concepte.Modelarea unui sistem presupune identificarea elementelor importante din punctul de vedere al celui care modeleaza. Aceste elemente formeaza vocabularul sistemului. Fiecare dintre aceste elemente are o multime de proprietati.Un exemplu de notatie grafica pentru clasa este dat in figura 7.10.ClaseElementele unei clase sunt: Nume - prin care se distinge de alte clase. O clasa poate fi desenata aratandu-i numai numele.Atribute - un atribut reprezinta numele unei proprietati a clasei.Operatii (metode) - o operatie reprezinta implementarea unui serviciu care poate fi cerut oricarui obiect al clasei.O clasa poate avea oricate atribute si operatii sau poate sa nu aiba nici un atribut sau nici o operatie.

Diagrama de clase – Relatii

modeleaza o conexiune semantica sau o interactiune intre elementele pe care le conecteaza

34

Notatiile grafice pentru diferite tipuri de relatii (a) asociere bidirectionala, (b) asociere unidirectionala, (c) agregare, (d) dependents, (e) generalizare, (f) realizare

O relatie modeleaza o conexiune semantica sau o interactiune intre elementele pe care le conecteaza. Figura 7.11 ilustreaza notatiile grafice pentru diferite tipuri de relatii.

Modelarea aplicaţiilor web

alternativă mai bună faţă de dezvoltarea ad-hoc a aplicaţiilor web Modelele - punct de pornire pentru implementarea aplicaţiilor web, ţinând cont de aspectele

statice şi dinamice ale nivelelor de conţinut, hipertext şi prezentare ale unei aplicaţii web Includerea informaţiilor contextuale (precum utilizatorul, ora, locaţia şi dispozitivul utilizat) şi

adaptarea aplicaţiei web „derivată” din această informaţie

Deşi în prezent nu este folosită frecvent în practică, modelarea aplicaţiilor web reprezintă o alternativă mai bună faţă de dezvoltarea ad-hoc a aplicaţiilor web şi problemele sale inerente. Modelele reprezintă un punct de pornire important pentru implementarea aplicaţiilor web, având în vedere aspectele statice şi dinamice ale nivelelor de conţinut, hipertext şi prezentare ale unei aplicaţii web. În timp ce modelul conţinutului unei aplicaţii web (care tinde să surprindă informaţia şi logica aplicaţiei) este similar modelului corespondent al unei aplicaţii non-web , modelarea hipertextului este o particularitate a aplicaţiilor web. Modelul hipertext descrie toate posibilităţile de navigare pe baza conţinutului. Modelul prezentare mapează structurile hipertext cu paginile şi legăturile dintre acestea, în acest mod reprezentându-se interfaţa grafică utilizator. Includerea informaţiilor contextuale (precum utilizatorul, ora, locaţia şi dispozitivul utilizat) şi adaptarea aplicaţiei web „derivată” din această informaţie necesită o atenţie deosebită în procesul de modelare. Vom prezenta în continuare metodele şi utilitarele disponibile pentru modelarea aplicaţiilor web precum şi avantajele lor, pentru a sprijini selectarea unei metode adecvate. Aceste metode reprezintă fundamentul pentru dezvoltarea bazată pe modele şi pentru instrumentele de generare a codului şi ne permit o simulare a utilizării diferiţilor clienţi web şi platforme de lucru.

dezvoltarea aplicaţiilor web complexe - abordare sistematică şi o specificare a aplicaţiei web care trebuie construită sub forma modelelor vizuale

Modelarea - furnizarea de specificaţii pentru sistemul care va fi construit la un nivel de detaliere suficient de mare pentru implementarea sistemului. Rezultatul procesului de modelare sunt modelele, care reprezintă aspectele relevante ale sistemului într-o manieră simplificată şi inteligibilă.

Pentru dezvoltarea aplicaţiilor web complexe este necesară o abordare sistematică şi o specificare a aplicaţiei web care trebuie construită sub forma modelelor vizuale. Disciplinele de proiectare au utilizat cu succes modelele pentru a reduce complexitatea, sprijini deciziile de proiectare şi facilita comunicarea în cadrul echipelor din proiect. Modelarea are ca obiectiv furnizarea de specificaţii ale sistemului care va fi construit la un nivel de detaliere suficient pentru implementarea sistemului. Rezultatele proceselor de modelare sunt modelele, care reprezintă aspectele relevante ale sistemului într-o manieră simplificată şi inteligibilă.

35

Figura 3.1 Cerinţe pentru modelarea aplicaţiilor software

Modelarea a fost utilizată şi în ştiinţa calculatoarelor pentru dezvoltarea software-ului. În acest domeniu, obiectul modelării este aplicaţia care va fi creată. Figura următoare (vezi Figura 3.1) demonstrează că orizontul modelării acoperă trei dimensiuni ortogonale. Prima dimensiune cuprinde nivelul logic al aplicaţiei şi nivelul interfeţei utilizator în sensul încapsulării a „ce” şi „cum” se va realiza într-o aplicaţie. Structura (obiectele, atributele lor şi relaţiile cu alte obiecte) şi comportamentul (funcţiile şi procesele) aparţin logicii aplicaţiei şi interfeţei utilizator şi formează o altă dimensiune. Deoarece o aplicaţie nu poate fi dezvoltată „imediat”, fiind necesară o rafinare şi o extindere progresivă pe parcursul procesului de dezvoltare, fazele dezvoltării formează o a treia dimensiune a modelării aplicaţiei. Prin rafinamente succesive, cerinţele identificate în etapa de analiză a cerinţelor sunt transformate la început în modele de analiză şi ulterior în modele de proiectare, pe baza cărora se va realiza implementarea.

Originile modelării - regăsi în proiectarea datelor şi în proiectarea software-ului (abordarea orientată-obiect)

modelare orientată-obiect - abordarea holistică a modelării sistemului şi conceptul de obiect, care cuprinde structura şi comportamentul.

UML -limbaj de modelare orientat-obiect şi este privit ca o lingua franca în dezvoltarea software-ului orientat obiect

diagrame structurale (diagramele de clasă, diagramele de componente, diagramele de structură complexe, diagramele de desfăşurare)

diagrame de comportament (diagrame de utilizare de caz, diagramele de stări -state machine-, diagramele de activitate)

Originile modelării le putem regăsi în Proiectarea datelor şi în Proiectarea software-ului. Modelarea din Proiectarea datelor se focalizează pe aspectele structurale (datele) unei aplicaţii, obiectivul major fiind identificarea entităţilor, gruparea acestora şi relaţiile dintre ele. În acest sens cel mai cunoscut este modelul entitate-relaţie (ER)[1]. În schimb, modelarea în Proiectarea software pune accentul pe aspectele comportamentale, pentru îndeplinirea cerinţelor limbajelor de programare şi în prezent se bazează în principal pe abordarea orientată-obiect. Cele mai importante caracteristici ale modelării orientate-obiect sunt abordarea holistică a modelării sistemului şi conceptul central al obiectului, care cuprinde structura şi comportamentul.Limbajul de modelare unificat (UML)[2] este un limbaj de modelare orientat-obiect şi este privit ca o lingua franca în dezvoltarea software-ului orientat obiect. UML stă la baza majorităţii metodelor

Aspecte

Comportament

Structură Analiză Proiectare Implementare

Faze

Interfaţa utilizator

Nivele

Logica aplicaţiei

36

Obiectele, atributele şi relaţiile cu alte obiecte

funcţii şi procese

ce” şi „cum” se va realiza

de modelare pentru aplicaţiile web şi permite specificarea aspectelor unui sistem software sub forma modelelor, folosind diferite diagrame pentru reprezentarea grafică a acestora. UML dispune de două tipuri de diagrame: diagrame structurale (diagramele de clasă, diagramele de componente, diagramele de structură complexe, diagramele de desfăşurare) şi diagrame de comportament (diagramele de utilizare de caz, diagramele de stări, diagramele de activitate).

[1] Chen, P., The Entity-RelationshipModel – Toward a Unified View of Data, ACM Transactions on Database Systems, 1976, pp. 9–36[2] OMG (Object Management Group), UML 2.0 Superstructure Specification – Revised Final Adopted Specification, 2004, http://www.omg.org

Caracteristicile modelării în proiectarea web

- abordarea aplicaţiilor web ţinând cont de cele trei dimensiuni specificate anterior: nivele, aspecte şi faze - accentul variază în funcţie de tipul aplicaţiei web- focalizarea se va face asupra structurii de prezentare uniforme a paginilor- modelarea hipertext trebuie să se bazeze pe şabloane de navigare recurente- Relevanţa structurii şi comportamentului modelelor depinde de tipul de aplicaţie web care va fi implementată

Figura 3.2 Cerinţele modelării aplicaţiilor web

Abordările de modelare specifice aplicaţiilor web au fost dezvoltate în special în ultimii ani şi permit abordarea aplicaţiilor web ţinând cont de cele trei dimensiuni specificate anterior: nivele, aspecte şi faze. NivelePentru a modela aplicaţiile web trebuie luate în considerare caracterul orientat pe document al conţinutului acestora şi navigarea hipertext non-liniară din cadrul lor. Din acest motiv se pot distinge trei nivele ale modelării aplicaţiilor web (vezi Figura 3.2) spre deosebire de cele două nivele utilizate în metodele de modelare pentru aplicaţiile tradiţionale. Cele trei nivele sunt conţinutul (informaţia şi logica aplicaţiei care stau la baza aplicaţiei web), hipertextul (structurarea conţinutului în noduri şi legăturile dintre ele) şi prezentarea (interfaţa utilizator sau layout-ul paginii). Majoritatea metodelor utilizate pentru a modela aplicaţii web folosesc această separare pe trei nivele[1].

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

Aspecte

Comportament

Structură Analiză Proiectare Implementare

Faze

Prezentare

Nivele

Conţinut

Hipertext Personalizare

37

O separare clară între aceste nivele permite reutilizarea şi ajută la reducerea complexităţii. De exemplu, putem specifica un anumit număr de structuri hipertext diferite care vor acorda atenţia cuvenită cerinţelor specifice ale diferitelor grupuri de utilizatori şi dispozitivelor utilizate pentru un anumit conţinut. Obiectivul modelării conţinutului este definirea explicită a structurii informaţiei; similar cu schema unei baze de date din modelarea datelor, aceasta elimină redundanţa (structura informaţiei va rămâne neschimbată, chiar dacă informaţia însăşi se schimbă frecvent).

Pentru a proiecta o navigare eficientă conţinutul poate fi oferit în mod redundant pe diferite noduri la nivel hipertext. Conţinutul este modelat o singură dată (în modelarea conţinutului) iar modelul structurii hipertext realizează doar o referinţă la conţinutul corespunzător. În acest mod utilizatorii pot găsi această informaţie pe diverse căi de acces. Pentru a preveni rătăcirea utilizatorilor în timpul navigării şi pentru a păstra stresul cognitiv asupra acestora cât mai scăzut, modelarea hipertext trebuie să se bazeze pe şabloane de navigare recurente.

În ceea ce priveşte modelarea la nivel de prezentare, focalizarea se va face pe o structură de prezentare uniformă a paginilor, pentru obţinerea unui efect de recunoaştere a brandului aplicaţiei web printre utilizatorii săi. Deşi aspectul vizual al unei aplicaţii web este important, aspectele estetice nu fac parte din obiectivele majore ale modelării. În ciuda separării intereselor şi a obiectivelor diferite în cadrul celor trei nivele, putem stabili o corespondenţă între acestea. Pentru realizarea acestui lucru trebuie definite explicit interdependenţele dintre nivele. De exemplu, diferite căi de acces hipertext personalizate pot fi mapate într-un singur model de conţinut. Un model comprehensiv al unei aplicaţii web include toate cele trei nivele discutate, dar accentul variază în funcţie de tipul aplicaţiei web. Aplicaţiile web care furnizează o interfaţă utilizator pur orientată-hipertext pentru un set mare de date, vor necesita focalizarea modelării pe conţinut şi structura hipertextului. În contrast, aplicaţiile web orientate pe prezentare (ex. portalurile corporative sau magazinele de cumpărături online) vor avea cereri mai mari în ceea ce priveşte modelarea prezentării.

AspecteConform principiilor orientate obiect, structura şi comportamentul sunt modelate la fiecare

din cele trei nivele (conţinut, hipertext şi prezentare). Relevanţa modelelor structurii şi comportamentului depinde de tipul de aplicaţie web care va fi implementată. Aplicaţiile web care conţin în principal informaţie statică necesită o modelare a comportamentului mai redusă comparativ cu aplicaţiile web interactive (ex. aplicaţiile de comerţ electronic care oferă motoare de căutare, funcţii pentru ordine de cumpărare etc.). În ceea ce priveşte maparea diferitelor nivele, este recomandată utilizarea unui formalism de modelare uniform pentru structură şi comportament, care ar permite folosirea unui singur instrument CASE.

FazeÎn literatură nu există un consens privitor la o abordare generală a modelării pentru

dezvoltarea aplicaţiilor web. În toate cazurile secvenţa de paşi pentru modelarea nivelelor trebuie stabilită de către modelator. În funcţie de tipul aplicaţiei web se poate folosi o abordare bazată pe informaţie (pornirea de la modelarea conţinutului) sau o abordare bazată pe prezentare (pornirea de la modelarea aspectelor de prezentare a aplicaţiei). Dezvoltarea bazată pe modele în proiectarea web este contradictorie cu practicile întâlnite în proiectele web (ex. cicluri de dezvoltare cu viaţă scurtă şi necesitatea unor „metode rapide”). Abordarea bazată pe modele oferă în schimb posibilitatea specificării comprehensive a unui model al soluţiei şi, dacă este disponibil un utilitar de caz adecvat, posibilitatea generării automate a prototipului aplicaţiei web. Personalizarea Includerea informaţiilor de context în dezvoltarea aplicaţiilor web are un rol semnificativ, permiţând personalizarea, distribuirea multi-platformă şi serviciile bazate pe locaţie. Personalizarea se referă la context (ex. preferinţele utilizatorilor, caracteristicile dispozitivelor sau restricţiile privind lăţimea de bandă) şi permite adaptarea aplicaţiei web în funcţie de acesta. Personalizarea influenţează toate cele trei dimensiuni ale modelării web (conţinut, hipertext şi prezentare) în ceea ce priveşte structura şi comportamentul şi trebuie luată în considerare în toate fazele procesului de dezvoltare. În consecinţă, managementul informaţiei contextuale este tratat ca o dimensiune de modelare independentă.

38

Deşi nu există o metodă de modelare globală care să acopere toate dimensiunile discutate anterior, vom utiliza în cele ce urmează UML şi îl vom extinde prin preluarea unor concepte dintr-o metodă de modelare pentru aplicaţii web bazată pe UML, cunoscută sub numele de UWE (Proiectare web bazată pe UML – UML based Web Engineering).

Cerinţele modelării

Cazurile de utilizare - tehnica de modelare adecvată cerinţelor funcţionale deoarece ele pot fi reprezentate în mod grafic >> set de cazuri de utilizare care descriu cerinţele aplicaţiei web din perspectiva actorilor (indivizi şi alte sisteme)

suplimentate de diagrame de activitate UML pentru a descrie cerinţele funcţionale în detaliu

Se pot utiliza diverse tehnici pentru a identifica, analiza, descrie, evalua şi administra cerinţele aplicaţiilor web. Cazurile de utilizare reprezintă tehnica de modelare adecvată pentru cerinţele funcţionale, deoarece ele pot fi reprezentate în mod grafic. Funcţionalitatea în ansamblu a unei aplicaţii web este modelată ca un set de cazuri de utilizare care descriu cerinţele aplicaţiei web din perspectiva actorilor (persoane şi alte sisteme). Mai mult, cazurile de utilizare pot fi suplimentate de diagrame de activitate UML pentru a descrie cerinţele funcţionale mai detaliat. O particularitate a cerinţelor aplicaţiilor web este funcţionalitatea navigării, care permite utilizatorului să navigheze prin hipertext şi să găsească nodurile. În acest sens, se recomandă separarea cazurilor de utilizare funcţionale de cele navigaţionale, prin crearea a două modele distincte. O altă abordare (UWE) implică crearea unui singur model de caz de utilizare care foloseşte stereotipul UML <<navigation>> pentru a indica diferenţa între cazurile de utilizare funcţionale şi cele specifice hipertextului.

39

Figura 3.3: Diagramă de utilizare de caz pentru un sistem de recenzie

Toate aplicaţiile web au cel puţin un utilizator uman, de cele mai multe ori anonim. În exemplul următor, al unui sistem de recenzie a articolelelor pentru o conferinţă online, se pot identifica 4 actori: utilizatorii sistemului de recenzie, autorii care trimit articole pentru conferinţă, membrii comitetului care analizează articolele trimise (recenzenţi) şi preşedintele comitetului de organizare (preşedintele CO). Figura 3.3 reprezintă o diagramă tip caz de utilizare, parte a modelului de caz de utilizare pentru sistemul de recenzare, care va servi drept punct de pornire pentru modelarea ulterioară. Cerinţele navigaţionale care suplimentează cerinţele funcţionale sunt evidenţiate prin stereotipul <<navigation>> în diagrama tip caz de utilizare.

Use cases Actors Associations Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case

40

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

poate fi implementat ca un serviciu web

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 solicită o logică a aplicaţiei mai complexă. 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.

Initial node. The filled in circle is the starting point of the diagram. An initial node isn’t required although it does make it significantly easier to read the diagram. Activity final node. The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes. Activity. The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student ScreenCondition. Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in order to traverse the node. Decision. A diamond with one flow entering and several leaving. The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious

Modelarea conţinutului

Informaţia furnizată de o aplicaţie web - unul din cei mai importanţi factori pentru succesul acelei aplicaţii, în principal datorită originii web-ului ca un mediu informaţional

- modelare pură a datelor - suficientă în pentru aplicaţiile web statice- aplicaţiile web complexe - solicită în plus modelarea aspectelor comportamentale

Informaţia oferită de o aplicaţie web este unul din cei mai importanţi factori pentru succesul acelei aplicaţii, datorită originii web-ului ca un mediu informaţional. Modelarea conţinutului în sensul de modelare pură a datelor este suficientă în mod normal pentru aplicaţiile web statice. Aplicaţiile web complexe solicită în plus modelarea aspectelor comportamentale. Astfel, modelarea conţinutului va include crearea modelului domeniului problemei, ce constă în aspectele statice şi dinamice, după cum se cunoaşte din Proiectarea software clasică. În plus trebuie luate în considerare următoarele caracteristici ale aplicaţiilor web:- Caracterul axat pe document şi multimedia: la modelarea conţinutului trebuie luate în considerare toate tipurile de formate media, inclusiv structurile pe care se bazează informaţia.- Integrarea datelor şi software-ului existent: multe aplicaţii web sunt construite folosind depozite de date şi componente software existente, care nu au fost create iniţial pentru aplicaţiile web. Modelarea conţinutului trebuie să satisfacă două obiective potenţial contradictorii: trebuie să

41

îndeplinească cât mai bine posibil cerinţele de conţinut ale aplicaţiei web şi trebuie să includă structurile de date şi componentele software existente.

urmăreşte transferarea informaţiei şi cerinţelor funcţionale, stabilite prin proiectarea cerinţelor, într-un model

Modelarea conţinutului produce un model care include atât aspectele structurale ale conţinutului (sub forma diagramelor de clasă) cât şi – în funcţie de tipul aplicaţiei web - aspectele comportamentale (sub forma diagramelor de stare şi interacţiune).

Modelarea conţinutului urmăreşte transferarea informaţiei şi cerinţelor funcţionale, stabilite prin proiectarea cerinţelor, într-un model. Caracterul hipertext al unei aplicaţii web şi cerinţele prezentării acesteia nu vor fi luate în considerare. Modelarea conţinutului produce un model care include atât aspectele structurale ale conţinutului (ex. sub forma unei diagrame de clasă) cât şi – în funcţie de tipul aplicaţiei web - aspectele comportamentale (ex. sub forma diagramelor de stare şi interacţiune).

Figura 3.5 Diagrama de clasă pentru sistemul de recenzie

Figura 3.5 ilustrează o diagramă de clasă UML simplificată pentru exemplul de sistem de recenzare menţionat anterior. Diagrama modelează o conferinţă care trebuie să abordeze anumite teme şi utilizatorii care se pot autentifica pentru conferinţă şi trimite articolele proprii. Un articol este subiectul unei recenzii realizate de 3 recenzenţi. Invariantul de stare ataşat la clasa „Articol” ne asigură ca autorii nu vor putea să-şi revizuiască propriile articole. Această diagramă de clasă

42

va servi ulterior drept bază pentru modelarea hipertextului şi a prezentării pentru aplicaţia discutată.UML 2 class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods. By including both an attribute and a method box in the class I’m arguably making design decisions in my model, something I shouldn’t be doing if my goal is conceptual modeling. Another approach would be to have two sections, one for the name and one listing responsibilities. This would be closer to a CRC model (so if I wanted to take this sort of approach I’d use CRC cards instead of a UML class diagram). I could also use class boxes that show just the name of the class, enabling me to focus on just the classes and their relationships

Multiplicity Indicators.IndicatorMeaning0..1 Zero or one1 One only0..* Zero or more1..* One or moren Only n (where n > 1)0..n Zero to n (where n > 1)1..n One to n (where n > 1)

Figura 3.6 Diagrama de stare pentru stările articolului

Figura 3.6 reprezintă o diagramă de stare (state machine diagram), utilizată pentru a modela diverse stări ale articolului în sistemul de recenzare. Un articol trimis va fi preluat de trei recenzenţi pentru revizuire după ce termenul limită pentru trimitere a expirat. Dacă este atinsă o valoare-prag prestabilită articolul este acceptat; altfel este respins. În ambele cazuri autorii sunt anunţaţi prin e-mail despre rezultatul recenzării. În final articolul acceptat va fi publicat. Objects have both behavior and state or, in other words, they do things and they know things. Some objects do and know more things, or at least more complicated things, than other objects. Some objects are incredibly complicated, so complex that developers can have difficulty understanding them. To understand complex classes better, particularly those that act in different manners depending on their state, you should develop one or more UML 2 state machine diagrams, formerly called state chart diagrams in UML 1.x, describing how their instances work. UML state machine diagrams depict the various states that an object may be in and the transitions between those states. In fact, in other modeling languages, it is common for this type of a diagram to be called a state-transition diagram or even simply a state diagram. A state represents a stage in the behavior pattern of an object, and like UML activity diagrams it is possible to have initial states and final states. An initial state, also called a creation state, is the one that an object is in when it is first created, whereas a final state is one in which no transitions lead out of. A transition

43

http://www.agilemodeling.com/artifacts/activityDiagram.htm

http://www.agilemodeling.com/essays/umlDiagrams.htm

http://www.agilemodeling.com/artifacts/crcModel.htm

is a progression from one state to another and will be triggered by an event that is either internal or external to the object.

Modelarea hipertextului

poate fi realizată prin utilizarea structurilor de acces adecvate – opţiuni de navigare pentru eliminarea riscului de rătăcire a utilizatorilor şi de supunere la un stress cognitiv excesiv

specificarea navigabilităţii în conţinutul aplicaţiei web (căile de navigare disponibile utilizatorilor).

produce modelul structurii hipertext rafinează modelul de structură hipertext

Non-liniaritatea hipertextului este una din cele mai importante proprietăţi de care trebuie ţinut cont la modelarea aplicaţiilor web. Din acest motiv structura hipertext trebuie proiectată cu atenţie. Aceasta se poate realiza prin utilizarea unor structuri de acces adecvate (opţiuni de navigare) pentru evitarea riscului de rătăcire a utilizatorilor sau de a-i supune la un stres cognitiv excesiv. ObiectiveObiectivul modelării hipertext (cunoscută şi ca modelarea navigării) este specificarea navigabilităţii în conţinutul aplicaţiei web (căile de navigare disponibile utilizatorilor). Modelarea hipertext generează un rezultat dublu: în primul rând produce modelul structurii hipertext (modelul structurii de navigare) care defineşte structura hipertextului, respectiv ce clase ale modelului de conţinut pot fi vizitate prin navigare. În al doilea rând, rafinează modelul de structură hipertext prin accesarea elementelor sub forma unui model de acces. Modelarea hipertext se focalizează pe aspectele structurale ale hipertextului şi elementele de acces. Comportamentul de navigare al unei aplicaţii web nu este în mod normal reprezentat explicit, deoarece oferă foarte puţine informaţii adiţionale pentru dezvoltator.

Figura 3.7 Model de structură hipertext a perspectivei preşedintelui comitetului de organizare asupra sistemului de recenzie

Modelarea structurii hipertext se bazează pe conceptele hipertext (noduri – pagini sau documente şi legături între aceste noduri)

Spre deosebire de nivelul conţinutului, pentru care sunt utilizate diagramele ER sau diagramele de clasă, pentru modelarea structurii hipertext sunt folosite notaţii specifice. Modelarea structurii

1 <<legatura navigare>>

<<legatura navigare>> 1

<<legatura navigare>> 1

articole acceptate *

articole respinse *

<<legatura navigare>> <<legatura navigare>>

1

<<clasa navigare>>Conferinta

*

*

*

<<clasa navigare>>Recenzie

*

<<legatura navigare>>

*

<<legatura navigare>><<clasa navigare>>

Articol

<<legatura navigare>>

1..*<<clasa navigare>>

Utilizator

44

hipertext se bazează pe conceptele hipertext (noduri – pagini sau documente şi legături între aceste noduri). Punctul de plecare folosit pentru crearea modelului structurii hipertext este de obicei modelul de conţinut care conţine clasele şi obiectele care vor fi disponibile ca noduri în hipertext. Deseori modelul de structură hipertext este specificat ca o perspectivă a modelului de conţinut, fiind uneori numit perspectivă navigaţională. Astfel, un nod este specificat ca o perspectivă a modelului de conţinut, selectând unul sau mai multe obiecte din conţinut. Unele metode modelează structura hipertext indiferent de modelul de conţinut. De exemplu OOHDM (Object-Oriented Hypermedia Design Method) oferă o abordare de a modela scenariile, în care modelul de structură hipertext poate fi construit direct pe baza cerinţelor de navigare identificate de aceste scenarii. În sistemul de recenzie folosit ca exemplu perspectiva hipertext este necesară pentru următoarele roluri ale utilizatorilor: autor, recenzent şi preşedintele comitetului de organizare. Figura 3.7 ilustrează modelul de structură hipertext din perspectiva preşedintelui comitetului de organizare. Preşedintele poate vizualiza toate articolele trimise, poate accesa lista de articole acceptate sau respinse şi profilurile recenzenţilor. Conform metodei de modelare UWE, figura 3.7 ilustrează modul în care stereotipul UML <<clasă de navigare>> este utilizat pentru a marca clasele ce reprezintă nodurile în modelul de structură hipertext pentru a le distinge de clasele de conţinut. Legăturile sunt modelate prin asocieri directe cu stereotipul <<legătura de navigare>>.

Modelarea hipertextului - tipuri de legături

metoda HDM (Hypertext Design Model) Legăturile structurale conectează elementele aceluiaşi nod (de la rezumatul

recenziei la detaliile recenziei) Legăturile de perspectivă plasează diferite perspective ale unui nod în relaţie cu

altele (versiunile PostScript şi PDF) Legăturile aplicaţiei plasează noduri diferite în relaţie unul cu altul în funcţie de

aplicaţie (legătură „cel mai bun articol”) metoda WebML (Web Modeling Language)

legături contextuale – transmit informaţia contextuală (numărul unic al recenzentului) legături noncontextuale – nu au asociate informaţii de context (legături care duc de

la o recenzie singulară la lista tuturor recenziilor) legături intra-pagină – sunt utilizate când sursa şi destinaţia legăturii aparţin aceleiaşi

pagini (direct la rezumatul articolului, care este afişat în partea de jos) legături inter-pagini – sunt utilizate când sursa şi destinaţia se află pe pagini diferite

(informaţii detaliate despre autori şi articolele lor)

În literatura de specialitate distingem tipuri de legături folosite pentru rafinarea ulterioară a semanticii modelului structurii hipertext. De exemplu metoda HDM (Hypertext Design Model) specifică următoarele tipuri de legături: - Legăturile structurale conectează elementele aceluiaşi nod (de exemplu de la rezumatul recenziei la detaliile recenziei)- Legăturile de perspectivă plasează diferite perspective ale unui nod în relaţie cu altele (de exemplu versiunile PostScript şi PDF ale unui articol).- Legăturile aplicaţiei plasează noduri diferite în relaţie unul cu altul în funcţie de aplicaţie (de exemplu o legătură care trimite la „cel mai bun articol”).Alte clasificări se bazează pe posibilul transport al informaţiei pe parcursul navigării. De exemplu metoda WebML (Web Modeling Language) specifică următoarele tipuri de legături: - legături contextuale – transmit informaţia contextuală (de exemplu numărul unic al recenzentului pentru a naviga de la un recenzent la recenzia pe care el a creat-o)- legături noncontextuale – nu au asociate informaţii de context (de exemplu legături care duc de la o recenzie singulară la lista tuturor recenziilor)

45

- legături intra-pagină – sunt utilizate când sursa şi destinaţia legăturii aparţin aceleiaşi pagini (de exemplu când o legătură permite utilizatorului să navigheze direct la rezumatul articolului, care este afişat în partea de jos a paginii);- legături inter-pagini – sunt utilizate când sursa şi destinaţia se află pe pagini diferite (de exemplu când informaţii detaliate despre autori şi articolele lor se găsesc pe pagini diferite).

metoda de modelare UWE legături de navigare – sunt utilizate pentru a naviga între noduri (legături între

articole şi autorii acestora) legăturile procesului – indică nodul de început al unui proces (spre începutul

procesului de trimitere a recenziei) legăturile externe – indică un nod care nu aparţine în mod direct aplicaţiei (spre

ghidurile de formatare)

Pe baza cerinţelor funcţionale ale aplicaţiilor web, metoda de modelare UWE defineşte următoarele tipuri de legături: - legături de navigare – sunt utilizate pentru a naviga între noduri (de exemplu legături între articole şi autorii acestora)- legăturile procesului – indică nodul de început al unui proces (de exemplu spre începutul procesului de trimitere a recenziei)- legăturile externe – indică un nod care nu aparţine în mod direct aplicaţiei (de exemplu spre ghidurile de formatare stabilite de editorul lucrărilor conferinţei, care nu sunt stocate direct în sistemul de recenzie).

M odelare a A ccesului

sprijinul în navigare şi orientare - structuri de acces > Structurile de acces recurente sunt descrise ca şabloane de proiectare, deseori fiind numite „şabloane de proiectare hipermedia” sau „şabloane de navigare”

Şabloanele de navigare speciale cuprind: home şi punctul de reper – care trimite către un nod ce poate fi accesat de la toate nodurile

Modelul structurii hipertext construit până în prezent în mod singular nu este suficient pentru a descrie modul în care nodurile pot fi accesate prin navigare. Pentru a permite utilizatorilor să navigheze către noduri este necesar sprijinul în navigare şi orientare. Acestea se regăsesc sub forma structurilor de acces care rafinează modelul de structură hipertext. Structurile de acces recurente sunt descrise ca şabloane de proiectare, deseori fiind numite „şabloane de proiectare hipermedia” sau „şabloane de navigare”. Utilizarea acestor şabloane de navigare contribuie la o creştere semnificativă a calităţii modelului hipertext.

În sistemul de recenzie, dacă cineva doreşte să navigheze de la un recenzent la un articol asociat acestuia, trebuie să identifice acest articol pe parcursul navigării. De exemplu, acest lucru se poate realiza sub forma unei liste care afişează toate articolele, listă cunoscută şi sub numele de „index”. Un index este o structură de acces care permite utilizatorilor să selecteze un singur obiect (de exemplu un obiect din conţinut) dintr-o listă omogenă de obiecte. Spre deosebire de index, un meniu permite utilizatorilor să acceseze noduri eterogene sau meniuri suplimentare (submeniuri). Alte structuri de acces sunt „turul organizat” şi interogarea. „Turul organizat” permite utilizatorilor să se deplaseze secvenţial printr-un anumit număr de noduri. O interogare permite utilizatorilor să caute noduri. Majoritatea metodelor de modelare oferă elemente de modelare dedicată pentru cele mai frecvent utilizate şabloane de navigare. Şabloanele de navigare speciale cuprind: home – care trimite la pagina principală a aplicaţiei web şi punctul de reper – care trimite către un nod ce poate fi accesat de la toate nodurile.

O parte din structurile de acces prezentate pot fi adăugate modelului de structură hipertext în mod automat. De exemplu indecşii pot fi adăugaţi automat oricând dorim să permitem accesul la un set (mai mare decât unul) de obiecte ale unui nod.

46

Figura 3.8 Model de acces simplificat la al modelului de structură din Figura 3.7

Figura 3.8 ilustrează un model de acces simplificat din perspectiva preşedintelui comitetului de organizare specificat în modelul de structură hipertext al sistemului de recenzie. De notat că multiplicitatea implicită a legăturilor este 1. Preşedintele comitetului de organizare are acces la toate articolele, recenziile şi utilizatorii. Pentru a accesa un articol anume este utilizat un număr unic. Preşedintele comitetului de organizare poate căuta un articol în funcţie de titlu. UWE foloseşte stereotipuri UML cum ar fi: <<meniu>> (exemplu „conferinţă”), <<index>> ( exemplu „starea recenziei”) , interogare (exemplu „căutare după titlul articolului”) şi <<turul organizat>> pentru specificarea structurilor de acces meniu, index, interogare şi tur organizat.

Modelarea prezentării

tratează interfaţa utilizator şi necesită prezentarea aspectului unei aplicaţii web. Spre deosebire de aplicaţiile tradiţionale elementul central al prezentării din aplicaţiile web este pagina ca unitate de vizualizare

realizată în momentul proiectării structurii şi comportamentului interfeţei utilizator pentru a asigura interacţiunea cu aplicaţia web într-un mod simplu şi auto-explicativ

generează un rezultat dublu: produce un concept de prezentare uniformă prin modelarea elementelor recurente

din pagini (de exemplu antete şi subsoluri de pagină) descrie aspecte comportamentale ale interfeţei utilizator (de exemplu pe ce buton se

va executa clic pentru a activa o funcţie din logica aplicaţiei) acordarea unui sistem de ajutor pentru orientarea utilizatorilor la nivelul prezentării -

afişarea căii de navigare curente sau a paginilor vizitate pe parcursul sesiunii active

<<clasa navigare>>Conferinta

<<meniu>>Meniu Conferinta

<<interogare>>Cauta articol dupa

titlu

<<index>>Articole in functie de

titlu

<<index>>Autori

<<index>>Recenzii

<<index>>Stare Recenzie

<<index>>Articole trimise

<<index>>Index Utilizator

<<index>>Articole in functie de ID

<<index>>Articole acceptate

<<index>>Articole respinse

articole

cauta articole

<<meniu>>Meniu Articol

*

autori

*

*<<clasa

navigare>>Articol

toate articolele

*

*<<clasa

navigare>>Utilizator

utilizatori

recenzii

<<meniu>>Meniu Articol

*<<clasa

navigare>>Recenzie*

*

*

recenzii

Articole acceptate

Articole respinse

47

proiectarea grafică a layout-ului pentru interfaţa utilizator - grafician

Similar cu modelarea software clasică, modelarea prezentării tratează interfaţa utilizator şi necesită prezentarea aspectului unei aplicaţii web. Spre deosebire de aplicaţiile tradiţionale elementul central al prezentării din aplicaţiile web este pagina ca unitate de vizualizare.

Modelarea prezentării este realizată în momentul proiectării structurii şi comportamentului interfeţei utilizator pentru a asigura interacţiunea cu aplicaţia web într-un mod simplu şi auto-explicativ. În plus, se ţine cont de aspectele de comunicare şi de reprezentare ale aplicaţiei web. Modelarea prezentării generează un rezultat dublu: în primul rând produce un concept de prezentare uniformă prin modelarea elementelor recurente din pagini (de exemplu antete şi subsoluri de pagină). Modelarea prezentării ar trebui în mod ideal să afişeze structura fiecărei pagini şi proiectarea câmpurilor textelor, imaginilor, formularelor etc., incluse în aceste pagini. În al doilea rând, pe lângă structura paginilor modelul de prezentare descrie aspecte comportamentale ale interfeţei utilizator (de exemplu pe ce buton se va executa clic pentru a activa o funcţie din logica aplicaţiei). Datorită diversităţii mari a opţiunilor de navigare şi riscului inerent al rătăcirii utilizatorilor, trebuie avut în vedere acordarea unui sistem de ajutor pentru orientarea utilizatorilor la nivelul prezentării. Aceasta poate fi realizată, de exemplu, prin afişarea căii de navigare curente sau a paginilor vizitate pe parcursul sesiunii active.

Nu toate metodele disponibile pentru modelarea aplicaţiilor web suportă concepte de modelare a prezentării independente de tehnologie; unele utilizează concepte specifice tehnologiei, cum ar fi limbajele pentru stiluri (cum ar fi XSL - Extensible Stylesheet Language).

Un alt factor important pentru aplicaţiile web este proiectarea grafică a layout-ului pentru interfaţa utilizator, care deseori este realizată de un grafician pe baza unor schiţe de bază sau concepută prin implementarea paginilor prototip cu ajutorul utilitarelor.

trei nivele ierarhice O pagină de prezentare - o pagină prezentată utilizatorului O unitate de prezentare – nod - fragment logic al paginii Un element de prezentare - set de informaţii ale nodului

Figura 3.9 Paginile de prezentare ale sistemului de recenzie

Elementele modelului sunt descrise pe trei nivele ierarhice:- O pagină de prezentare descrie o pagină prezentată utilizatorului ca o unitate de vizualizare. Poate fi compusă din diferite unităţi de prezentare.

<<pagina>>Pagina articolului

<<unitatea de prezentare>>Articol

<<text>>ID Articol

<<text>>Data de trimitere

<<text>>Titlu

<<text>>Rezumat

<<ancora>>Versiune PDF

<<buton>>Introdu Recenzie

<<colectie de ancore>>Autori


<<unitatea de prezentare>>Lista Autori

<<unitatea de prezentare>>Autor


<<text>>Nume

<<text>>Afiliere

<<text>>E-mail

<<buton>>Introdu Schimbari

48

- O unitate de prezentare este utilă pentru gruparea elementelor interfeţei utilizator şi reprezintă un fragment logic al paginii. Prezintă un nod ce derivă din modelul hipertext.- Un element de prezentare este blocul de bază al modelului prezentare. Elementele de prezentare sunt un set de informaţii ale nodului şi pot include text, imagini, audio etc.Putem vizualiza structura paginilor de prezentare pe baza reprezentării unei diagrame de clasă UML imbricate cunoscută sub numele de „structură”, aşa cum se poate observa în figura 3.9. Acest exemplu utilizează clasele stereotip <<pagină>> şi <<unitate de prezentare>> pentru a descrie paginile de prezentare şi unităţile de prezentare. Toate tipurile de elemente de prezentare sunt de asemenea proiectate prin stereotipuri UML adecvate. Figura 3.9 ilustrează două pagini de prezentare ale sistemului de recenzie. Un articol este plasat pe o pagină numită „Pagina Articolului” împreună cu câmpurile aferente, o legătură către versiunea completă a articolului şi o legătură pentru a afişa autorii articolului. În plus, utilizatorii pot apăsa un buton pentru a adăuga o nouă recenzie. Pagina „Pagina Autorului” are două unităţi de prezentare - lista tuturor autorilor şi informaţia detaliată despre fiecare autor.

-Aspectele comportamentale ale interfeţei utilizator precum interacţiunea recenzenţilor pentru a naviga către articolele atribuite acestora pentru recenzie, pot fi modelate cu ajutorul diagramelor de comportament

Figura 3.10 Diagrama de interacţiune a sistemului de recenzie

Aspectele comportamentale ale interfeţei utilizator precum interacţiunea recenzenţilor pentru a naviga către articolele atribuite acestora pentru recenzie, pot fi modelate cu ajutorul diagramelor de comportament, aşa cum se poate observa în figurile 3.10, 3.11 şi 3.12. În general interacţiunea utilizatorului cu aplicaţia web nu implică doar nivelul de prezentare; se face trimitere deseori la nivelul hipertext şi nivelul de conţinut în funcţie de tipul de interacţiune. În diagramele din figurile 3.11 şi 3.12 un recenzent foloseşte navigarea către indexul articolelor atribuite acestuia prin utilizarea barei de navigare din interiorul paginii principale a conferinţei. Aceasta informaţie este compusă din articole relevante de pe nivelul de conţinut. Această listă permite utilizatorului să

sd Afişează un articol atribuit

sd Extrage lista de articole atribuite

sd Afişează articolul selectat

49

selecteze un articol din lista atribuită acestuia. Utilizatorul poate apoi naviga pentru a selecta un articol, care va fi afişat în mod detaliat.

Figura 3.11 Diagrama secvenţială pentru extragerea unei liste de articole atribuite

Figura 3.12 Diagrama secvenţială pentru afişarea articolelor selectate

50

Modelarea personalizării

- informaţia contextuală şi o adaptare adecvată a aplicaţiei în faza de modelare- realizată printr-o reprezentare explicită a informaţiei de context şi a adaptărilor derivate din

aceasta - necesită examinarea situaţiilor de utilizare a aplicaţiilor web – a răspunde la întrebările „ce”

şi „când” trebuie adaptat- modelare şi o administrare a preferinţelor şi caracteristicilor unui utilizator în aşa

numitul profil al utilizatorului- dupa nivelul de abstractizare al informaţiei contextuale-distingem contextul fizic şi contextul

logic

Deoarece aplicaţiile web omniprezente au o importanţă deosebită este necesar să luăm în calcul informaţia contextuală şi o adaptare adecvată a aplicaţiei în faza de modelare. Propuneri relevante pentru personalizare regăsim în domeniul personalizării şi sistemelor mobile. Modelarea personalizării este realizată printr-o reprezentare explicită a informaţiei de context şi a adaptărilor derivate din aceasta. În funcţie de metoda de modelare, rezultatul nu este întotdeauna un model al personalizării explicit. În majoritatea cazurilor modelarea personalizării se confundă cu modelele conţinutului, hipertextului şi prezentării. Personalizarea trebuie să fie distinctă de întreţinere sau reproiectare. Modelarea personalizării ia în considerare informaţia care poate fi anticipată în momentul modelării şi care poate lua valori diferite când aplicaţia web rulează. În schimb, adaptarea datorată modificărilor din mediul organizaţional sau tehnologic implică activităţi de întreţinere sau reproiectare.Personalizarea necesită examinarea situaţiilor de utilizare a aplicaţiilor web – a răspunde la întrebările „ce” şi „când” trebuie adaptat. Pentru a putea personaliza o aplicaţie web este necesară o modelare şi o administrare a preferinţelor şi caracteristicilor unui utilizator în aşa numitul profil al utilizatorului. De exemplu, pentru a adapta o aplicaţie web din domeniul sistemelor mobile, trebuie să luăm în considerare profilele dispozitivului, informaţii privind locaţia şi lăţimea de bandă. Această informaţie este apoi reprezentată în cadrul modelului de context sub forma diagramelor de clasă. În momentul rulării, contextul se poate schimba (de exemplu îşi schimbă preferinţele sau aplicaţia este folosită din diferite locaţii). Din acest motiv este necesară o adaptare a aplicaţiei web. În ceea ce priveşte nivelul de abstractizare al informaţiei contextuale, putem distinge contextul fizic şi contextul logic. Contextul fizic rezultă dintr-o situaţie de utilizare specifică (de exemplu numele de utilizator pentru o autentificare sau celula GSM în care un utilizator este situat). Contextul logic oferă cunoştinţe de context suplimentare (de exemplu adresa de la serviciu versus adresa de acasă, ore de lucru versus timp liber). Aceste informaţii de context pot fi oferite aplicaţiei web şi din surse externe. Un exemplu de astfel de sursă externă care oferă informaţii pentru o specificare mult mai detaliată a contextului locaţiei sunt sistemele informaţionale geografic (GIS- Geographic Information Systems). Au fost propuse şi alte abordări (cum ar fi Context Toolkit sau proiectul NEXUS) pentru a sprijini componente universale capabile să ofere diferite tipuri de informaţii contextuale fizice şi logice.

51

Figura 3.14 Adaptarea dinamică a unei pagini în modelul de prezentare

Figurile 3.13 şi 3.14 ilustrează modul în care nivelele hipertext şi prezentare ale sistemului de recenzie pot fi adaptate dinamic. S-au folosit adnotări (prin stereotipul <<personalizare>>) pentru a adăuga 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 ilustrează modul în care structura hipertext poate fi personalizată astfel încât articolele pe care un utilizator le poate citi să 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.14 ilustrează modul în care elementele din modelul de prezentare pot fi adaptate prin utilizarea regulilor de transformare (de exemplu butonul „Introduceţi Recenzia” trebuie să fie vizibil doar pentru utilizatorii cu rolul „Recenzent”).Majoritatea tehnologiilor existente în prezent abordează modelarea personalizării prin definirea regulilor sau unui filtru pentru fiecare punct din aplicaţia web în care personalizarea se aplică ca în exemplul anterior. UWE foloseşte o abordare diferită, utilizând tehnici de modelare orientate pe aspect (AOM). AOM permite pe de o parte o separare sistematică a funcţionalităţii sistemului de aspectele personalizării, iar pe de altă parte permite reducerea redundanţei.


<<unitatea de prezentare>>Articol

<<text>>ID Articol

<<text>>Data de trimitere

<<text>>Titlu

<<text>>Rezumat

<<ancora>>Versiune PDF

<<buton>>Introdu Recenzie


<<personalizare>>

vizibil dacă utilizatorul are rolul “recenzent”

52

Metode şi utilitare

Toate metodele de modelare oferă un set de elemente de modelare ajustate la cerinţele aplicaţiilor web şi majoritatea oferă o notaţie specifică pentru elementele modelate. În plus, multe dintre ele definesc un proces şi sunt susţinute de un utilitar care generează (semi) automat o implementare pe baza modelelor create

Figura 3.17 Dezvoltarea istorică a metodelor de modelare pentru aplicaţiile web

Toate metodele de modelare oferă un set de elemente de modelare ajustate la cerinţele aplicaţiilor web şi majoritatea oferă o notaţie specifică pentru elementele modelate. În plus, multe dintre ele definesc un proces şi sunt susţinute de un utilitar care generează (semi) automat o implementare pe baza modelelor create Metodele disponibile pentru modelarea aplicaţiilor web se bazează pe cele clasice (cum ar fi ER) sau îmbunătăţesc un limbaj de modelare orientat-obiect (UML). Din punct de vedere istoric metodele de modelare a aplicaţiilor web se prezintă ca în figura 3.17. Metodele de modelare urmează diferite paradigme, în funcţie de originea şi focalizarea acestora:- Metodele orientate pe date – îşi au originea în domeniul sistemelor de baze de date şi se bazează în principal pe un model entitate-relaţie îmbunătăţit prin concepte specifice pentru modelarea la nivel hipertext. Principalul obiectiv al acestor metode este modelarea aplicaţiilor web care folosesc bazele de date. Exemple de astfel de metode sunt RMM (Relationship Management Methodology), Hera şi WebML (WebModeling Language).- Metodele orientate pe hipertext – se focalizează pe caracterul hipertext al aplicaţiilor web; ele derivă în principal din domeniul sistemelor hipertext. Cele mai reprezentative exemple sunt: HDM

HDM

OMT UML

WAE

UWE

WSDM

W2000OOWS

OO-H

WAE2

WebSA

OOHDM

HDM-Lite

WebML

ER

RMM

Hera

1993

1994

1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

Limbaje de modelare

Orientate pe date

Orientate pe hypertext

Orientate pe obiecte

Orientate pe software

53

(Hypertext Design Model) care a fost extinsă ulterior în W2000, sau WSDM (Web Site Design Method). - Metodele orientate pe obiecte - se bazează fie pe OMT (primele metode apărute) sau UML (cele mai recente). UML este notaţia preferată atunci când se alege un limbaj standard pentru modelare. Această categorie include OOHDM (Object-Oriented Hypermedia Design Method), UWE (UML-based Web Engineering), OOWS (Object-Oriented Web Solutions) şi OO-H (Object-Oriented Hypermedia).- Metodele orientate pe software - abordează aplicaţiile web în special din perspectiva dezvoltării clasice de software, folosind tehnici care urmează strict proiectarea software clasică. Exemple pentru această categorie sunt WAE (Web Application Extension) sau WAE2 (versiunea sa îmbunătăţită).

HDM-lite este succesorul lui HDM şi a fost proiectat în vederea automatizării procesului de dezvoltare şi generării automate a aplicaţiilor web. W2000 derivă tot din HDM şi modelează o aplicaţie web focalizându-se pe hipertext şi pe utilizator. RMM este o metodă care se bazează pe modelul ER şi defineşte un proces gradat pentru rafinarea succesivă a modelelor. O altă abordare bazată pe paradigma ER este Hera, care utilizează notaţia RMM. WebML este un limbaj de modelare matur şi uşor de înţeles pentru aplicaţii web concentrate pe date care oferă suport pentru părţile esenţiale ale modelării aplicaţiilor web. Această metodă foloseşte utilitarul WebRatio pentru a sprijini atât modelarea cât şi generarea automată de cod. Deoarece OOHDM pune accentul pe conceptul de navigare contextuală, această metodă este recomandată pentru aplicaţiile web care utilizează diferite opţiuni de navigare. OOHDM a fost extins pentru a suporta personalizarea, modelarea cadrului de lucru, arhitecturile aplicaţiilor web şi diagramele pentru a capta scenariile de interacţiune cu utilizatorul. WSDM se focalizează pe o abordare metodică orientată spre cerinţele utilizatorului. Pe de altă parte, UWE este o abordare care oferă o notaţie bazată pe UML şi o verificare a consistenţei modelului bazată pe un meta-model. OO-H este una dintre metodele mai recente, care îmbină beneficiile WebML, OOHDM şi UWE şi foloseşte un utilitar numit VisualWADE pentru suportul generării codului automat pe baza modelului. OOWS este (asemenea OO-H) o abordare orientată-obiect bazată parţial pe UML dar care utilizează propriile notaţii. WAE2 este o abordare UML care se focalizează pe distribuirea logicii aplicaţiei. WebSA este o abordare pentru modelarea arhitecturilor web.

Dezvoltarea bazată pe modele (MDD) - sprijină nu doar utilizarea modelelor pentru dezvoltarea de software ci şi necesitatea transformărilor în toate etapele dezvoltării

Utilitare

WebRatio Site Development Studio – WebML, foloseşte propriile notaţii pentru modelarea hipertext şi suportă notaţii ER şi UML, utilizează XSL pentru a transforma modelele de conţinut şi hipertext prezentate în XML în bazele de date necesare şi conexiuni la baza de date dar şi în componente software şi diferite formate de ieşire (HTML, WML, PDF, Microsoft Word)

VisualWADE - OO-H, suportă modelarea şi generarea automată a aplicaţiilor bazate pe XML, ASP, JSP şi PHP, adaugă la modelul UML alte două modele („Vizualizarea Navigării” şi „Vizualizarea Prezentării”)

OpenUWE Suite - UWE, instrumentul CASE ArgoUWE (se bazează pe instrumentul CASE open-source ArgoUML) şi cadrul de lucru UWEXML

Dezvoltarea bazată pe modele Dezvoltarea bazată pe modele (The Model-Driven Development –MDD) nu sprijină doar utilizarea modelelor pentru dezvoltarea de software ci şi necesitatea transformărilor în toate etapele dezvoltării (de la specificaţiile sistemului până la implementare şi testare). Transformările dintre

54

modele oferă o legătură care permite implementarea automată a unui sistem în etape succesive pornind de la diferitele modele definite pentru acesta.Dezvoltarea aplicaţiilor web este un domeniu specific în care MDD poate fi aplicată cu succes, datorită separării aspectelor (conţinut, hipertext, prezentare şi personalizare) specifice web-ului. Metode precum WebML, OO-H şi UWE reprezintă fundamentul abordării bazate pe modele pentru dezvoltarea aplicaţiilor web; ele includ unele transformări semi-automate bazate pe model. WebSA (Web Software Architecture) este o altă abordare bazată pe model pentru domeniul web-ului şi foloseşte paradigma MDA (Model-DrivenArchitecture). Asemănător cu MDA, WebSA se focalizează pe construirea de modele independente de platformă şi ulterior construirea automată a modelelor specifice platformei.UtilitareDatorită ciclurilor de dezvoltare scurte şi complexităţii aplicaţiilor web este recomandată utilizarea de instrumente care permit nu doar modelarea ci şi generarea automată a codului şi verificarea consistenţei modelului. Principalele utilitare de acest tip sunt: WebRatio Site Development Studio, VisualWADE şi OpenUWE Suite.

WebRatio Site Development StudioWebRatio Site Development Studio (http://www.webratio.com) este un instrument de dezvoltare bazat pe modele care construieşte folosind Web Modeling Language (WebML) (http://www.webml.org). Acest utilitar foloseşte propriile notaţii pentru modelarea hipertext şi suportă notaţii ER şi UML. Generatorul de cod al instrumentului utilizează XSL pentru a transforma modelele de conţinut şi hipertext prezentate în XML în bazele de date necesare şi conexiuni la baza de date dar şi în componente software şi diferite formate de ieşire (HTML, WML, PDF, Microsoft Word). WebRatio foloseşte un instrument numit EasyStyle pentru a genera prezentarea paginilor, care va transforma automat paginile adnotate în foi de stiluri XSL, fără a solicita alte activităţi de programare. Aplicaţia web generată cu ajutorul WebRatio este trimisă apoi în cadrul de lucru bazat pe un set de componente Java care pot fi configurate prin utilizarea fişierelor XML.VisualWADEInstrumentul VisualWADE (http://www.visualwade.com) se bazează pe metoda OO-H. Acest instrument suportă modelarea şi generarea automată a aplicaţiilor bazate pe XML, ASP, JSP şi PHP. VisualWADE adaugă la modelul UML alte două modele: „Vizualizarea Navigării” (utilizată pentru a modela aspectul hipertext al aplicaţiei web) şi „Vizualizarea Prezentării” (reprezintă elementele de interacţiune ale interfeţei utilizator cu privire la structura şi comportamentul acesteia utilizând anumite structuri de tip template). Aceasta produce o descriere independentă de dispozitiv a interfeţei utilizator, care poate fi utilizată de generatoare în vederea obţinerii automate a aplicaţiei web pentru medii şi dispozitive de rulare distincte.OpenUWESuita de utilitare OpenUWE (http://www.pst.ifi.lmu.de/projekte/uwe) este un mediu de dezvoltare pentru proiectarea şi generarea aplicaţiilor web folosind metodologia UWE. Principala facilitate a acestei suite este reprezentată de arhitectura deschisă bazată pe standardele consacrate. Mediul de dezvoltare OpenUWE include instrumentul CASE ArgoUWE şi cadrul de lucru UWEXML care constă într-un motor de verificare a consistenţei modelului, un editor al layout-ului şi un generator de cod pentru cadrul de lucru Cocoon XML Publishing şi JSP.Instrumentul CASE ArgoUWE se bazează pe instrumentul CASE open-source ArgoUML (http://www. argouml.org), suportă notaţia UWE şi verifică consistenţa modelelor în funcţie de constrângerile OCL specificate pentru meta-modelul UWE.

Concluzii

În ultima decadă au fost dezvoltate numeroase metode de modelare a aplicaţiilor web. Este greu de anticipat momentul în care se va ajunge la un limbaj de modelare web unificat (“Unified Web Modeling Language”) similar dezvoltării UML-ului.

55

http://www.pst.ifi.lmu.de/projekte/uwe

http://www.visualwade.com/

http://www.webml.org/

http://www.webratio.com/

Includerea serviciilor web în dezvoltarea aplicaţiilor web bazate pe modele va aduce noi provocări, cea mai importantă fiind interacţiunea dintre modelarea de sus în jos şi de integrarea de jos în sus a serviciilor existente.

Arhitecturile aplicaţiilor web

Calitatea aplicaţiilor web este influenţată semnificativ de arhitectura acestora <Performanţa scăzută, întreţinerea şi extinderea insuficientă şi slaba disponibilitate a

unei aplicaţii web constrângerile tehnice - disponibilitatea serverelor web + serverele de aplicaţii

utilizate sau integrarea sistemelor de moştenire + arhitecturile aplicaţiilor web trebuie să ia în considerare şi cadrul de lucru organizaţional (experienţa arhitecţilor)

Calitatea unei aplicaţii web este influenţată semnificativ de arhitectura sa. Aspectele arhitecturale incomplete sau omise fac dificilă îndeplinirea cerinţelor privind calitatea aplicaţiilor web. Performanţa scăzută, întreţinerea şi extinderea insuficientă şi slaba disponibilitate a unei aplicaţii web sunt deseori cauzate de o arhitectură neadecvată. Pe lângă constrângerile tehnice (precum disponibilitatea serverelor web, serverele de aplicaţii utilizate sau integrarea sistemelor moştenite), trebuie să se ia în considerare şi cadrul de lucru organizaţional în care arhitecturile sunt incluse (de exemplu experienţa arhitecţilor). Utilizarea unor arhitecturi multi-strat flexibile, considerarea conţinutului multimedia şi integrarea depozitelor de date şi aplicaţiilor existente reprezintă provocările pentru dezvoltarea unor arhitecturi de succes pentru aplicaţiile web. Vom discuta în continuare proprietăţile generale ale arhitecturilor, influenţa cunoştinţelor arhitecturale existente sub forma şabloanelor şi cadrelor de lucru asupra calităţii aplicaţiilor web şi arhitecturile reprezentative pentru aplicaţii web împreună cu componentele necesare construirii acestora. Pe parcursul dezvoltării aplicaţiilor web trebuie luate în considerare un număr mare de cerinţe şi constrângeri, începând cu cerinţele funcţionale (ex. comenzile de produse online) şi cele de calitate (ex. performanţa şi disponibilitatea) şi până la integrarea sistemelor software existente (aşa numitele sisteme moştenite) sau a depozitelor de date existente pe care aplicaţia web ar trebui să le citească. În mod normal, aplicaţiile web nu sunt dezvoltate „din nimic” în ceea ce priveşte infrastructura tehnică; deseori trebuie extinsă sau adaptată o infrastructură existentă. Pe lângă constrângerile pur tehnice, putem identifica alte aspecte, precum viabilitatea economică a unei infrastructuri tehnice.

Proprietăţile arhitecturilor software arhitectura descrie structura - structura, descompunerea în componente, interfaţa şi

relaţiile dintre ele arhitectura face tranziţia de la analiză la implementare arhitectura – abordari

conceptuală - identităţile domeniului aplicaţiei şi relaţiile în funcţie de momentul rulării - servere sau căi de comunicaţie pe procese - mapează procesele în momentul rulării sistemului (sincronizarea

şi concurenţa) în funcţie de implementare - artefactele software-ului (subsisteme,

componente sau cod sursă)

Nu există o definiţie unică a termenului „arhitectură”, renumitul Institut de inginerie a software-ului (SEI -Software Engineering Institute) din cadrul Universităţii Carnegie-Mellon (http://www.sei.cmu.edu) oferind peste 20 de variante explicative. În loc de a adăuga o altă variantă, vom încerca să descriem principalele proprietăţi ale arhitecturilor software:- arhitectura descrie structura: arhitectura unui sistem software constă în structurile lui, descompunerea în componente şi interfeţele şi relaţiile dintre ele[1]. Arhitectura descrie atât aspectele statice cât şi cele dinamice ale sistemului software.

56

http://www.sei.cmu.edu/

- arhitectura face tranziţia de la analiză la implementare: când creăm arhitectura încercăm să transformăm cerinţele funcţionale şi cele de calitate în componente software şi relaţiile şi interfeţele dintre ele într-un mod iterativ. Acest proces este susţinut de mai multe abordări, cum ar fi Procesul Unificat.- arhitectura poate fi abordată din diferite perspective, în funcţie de care se pot specifica aspecte arhitecturale distincte. Există patru abordări diferite:* abordarea conceptuală – identifică entităţile domeniului aplicaţiei şi relaţiile dintre acestea;* abordarea în funcţie de momentul rulării – descrie componentele în momentul rulării sistemului (de exemplu servere sau căi de comunicaţie)* abordarea pe procese – mapează procesele în momentul rulării sistemului, avându-se în vedere aspecte precum sincronizarea şi concurenţa;* abordarea în funcţie de implementare – descrie artefactele software-ului (subsisteme, componente sau cod sursă)Această clasificare în funcţie de diferitele perspective este susţinută şi de limbajele de modelare (de exemplu UML). - arhitectura face sistemul mai inteligibil: structurarea sistemelor software şi abordarea lor din diferite perspective ne permite un management mai bun al complexităţii sistemelor software, sistemele devenind astfel mai uşor de înţeles. - arhitectura reprezintă cadrul pentru un sistem flexibil: Tom DeMarco se referă la arhitectură ca la un „cadru al schimbării”: arhitectura software formează cadrul în care un sistem software poate evolua. Dacă extinderile unui sistem nu au fost luate anterior în calcul, atunci aceastea vor fi greu de realizat.Având în vedere proprietăţile menţionate, putem afirma că deciziile arhitecturale sunt de o importanţă majoră pentru dezvoltarea aplicaţiilor web.

[1] Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison-Wesley, 1998

Figura 4.1 Factori care influenţează dezvoltarea unei arhitecturi

Cerinţele software-ului şi deci arhitectura acestuia sunt într-o continuă schimbare. Constrângerile tehnice şi de organizare se modifică pe parcursul şi după dezvoltarea unei aplicaţii. Aceasta se poate datora unor cerinţe neclare la începutul procesului de dezvoltare sau unei schimbări a cerinţelor după finalizarea sistemului. Din acest motiv sistemele software sunt deseori numite „ţinte în mişcare”. Figura 4.1 ilustrează factorii şi constrângerile care influenţează dezvoltarea unei arhitecturi conform opiniei lui Jacobson[1].

`

Arhitectura

Cerinţe funcţionale-clienţi-utilizatori-alţi împuterniciţi

Aspecte tehnice-sistem de operare-middleware-sisteme de moştenire-altele

Experienţa cu-arhitectura existentă-şabloanele-managementul proiectelor-altele

Aspecte privind calitatea-performanţa-scalabilitatea-reutilizabilitatea-altele

57

[1] Jacobson, I., Booch, G., Rumbaugh, J., The Unified Software Development Process, Addison-Wesley, 1999Arhitectura unei aplicaţii este influenţată în principal de cerinţele funcţionale - serviciile oferite de un sistem - şi consideraţiile privind calitatea (scalabilitatea sau performanţa). Dincolo de aceste cerinţe, arhitecturile sunt influenţate de constrângeri tehnice cum ar fi software-ul utilizat de sistem (de exemplu sistemul de operare), middleware-ul (de exemplu o implementare CORBA), sistemele moştenite care trebuiesc integrate, standardele utilizate, regulile de dezvoltare (de exemplu ghidurile de scriere a codului) sau aspectele de distribuire (de exemplu distribuirea în diferite locaţii ale unei companii).Deoarece sistemele software sunt în permanentă schimbare arhitecturile sunt de obicei dezvoltate într-o manieră iterativă, deci riscurile rezultate din cerinţele şi constrângerile neclare ar trebui să fie calculabile şi controlabile. Totuşi, această abordare iterativă nu garantează o arhitectură solidă; ea nu este suficientă pentru rezolvarea unor probleme de proiectare specifice (precum integrarea unui sistem moştenit) apărute în dezvoltarea unei arhitecturi. Şabloanele de proiectare s-au dovedit a fi foarte eficiente în sprijinirea acestor decizii de proiectare.

Şabloane - descriu probleme de proiectare recurente care apar într-un anumit context şi propun soluţii la acestea

şabloanele arhitecturale - mapează mecanismele de structurare fundamentale pentru sistemele software (şablonul MVC)

şabloanele de proiectare - descriu structura, relaţiile şi interacţiunea între componente

dialecte - şabloanele care se referă la o implementare specifică dintr-un limbaj de programare

Şabloanele sunt disponibile pentru diverse infrastructuri – de exemplu J2EE, CORBA şi PHP Cadre - sistem software reutilizabil cu o funcţionalitate generală deja implementată. Cadrul

de lucru poate fi întâlnit sub forma aplicaţiilor gata de folosire şi serveşte ca o schiţă pentru arhitectura şi funcţionalităţile de bază ale unui domeniu specific al aplicaţiei

ŞabloaneŞabloanele[1] descriu probleme de proiectare recurente care apar într-un anumit context şi propun soluţii la acestea. O soluţie descrie componentele participante, responsabilităţile lor, relaţia între aceste componente şi interacţiunea lor în cadrul problemei. De aici rezultă că şabloanele ne permit reutilizarea cunoştinţelor demonstrate şi consolidate de proiectare, sprijinind dezvoltarea unor sisteme software de calitate superioară. Buschmann[2] identifică şabloane pe trei nivele de abstractizare:- şabloanele arhitecturale – mapează mecanismele de structurare fundamentale pentru sistemele software. Ele descriu subsistemele arhitecturale, responsabilităţile acestora, relaţiile şi interacţiunea dintre ele. Un exemplu de astfel de şablon este şablonul MVC (Model-View-Controller[3]).- şabloanele de proiectare –descriu structura, relaţiile şi interacţiunea dintre componente pentru a rezolva o problemă de proiectare apărută într-un anumit context; aceste şabloane derivă dintr-un limbaj de programare specific. - dialecte – descriu şabloanele care apelează o implementare specifică într-un limbaj de programare.Şabloanele sunt disponibile pentru diverse infrastructuri – de exemplu J2EE, CORBA[4] şi PHP.Totuşi, şabloanele reprezintă doar un ghid pentru o anumită problemă. Arhitecţii software trebuie să adapteze şabloanele la problema şi constrângerile respective, să integreze şi să îmbunătăţească şabloanele folosite. Pentru a susţine procesul de integrare, Buschmann recomandă folosirea aşa-numitelor limbaje-şablon. Un limbaj-şablon descrie interconexiunile şabloanelor înrudite la nivele de abstractizare diferite, sugerează diferite utilizări pentru şabloane şi indică adaptarea necesară pentru a asigura un sistem solid.

58

IBM descrie în 2002 şabloanele de arhitectură pentru aplicaţii comerciale şi modul în care pot fi mapate pe infrastructura IBM[5]. Aceste şabloane de arhitectură sunt perfecţionate printr-un lanţ de decizii, pornind de la cazul de utilizare şi terminând cu arhitectura ţintă.CadreCadrele reprezintă o altă opţiune pentru reutilizarea cunoştinţelor arhitecturale existente. Un cadru este un sistem software reutilizabil cu o funcţionalitate generală deja implementată. Cadrul poate fi întâlnit sub forma unei aplicaţii gata de folosire[6]; el serveşte ca o schiţă pentru arhitectura şi funcţionalităţile de bază ale unui domeniu specific al aplicaţiei. (deci informaţiile arhitecturale conţinute într-un cadru pot fi preluate în întregime în aplicaţie).Beneficiile unui cadru – reutilizarea cu uşurinţă a arhitecturii şi funcţionalităţii - trebuie puse în balanţă alături de dezavantajele sale (gradul înalt de instruire necesară, lipsa standardelor pentru integrarea diferitelor cadre şi deci dependenţa de producători).

[1] Gamma, E., Helm, R., Johnson, R., Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, 1997[2] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern – Oriented Software Architecture:A System of Patterns, John Wiley & Sons, 1996[3] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern – Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996, p.125[4] Malveau, R. C., Mowbray, T. J., CORBA Design Patterns, John Wiley & Sons, 1997[5] IBM, Patterns for e-business, 2002, http://www-106.ibm.com/developerworks/patterns/ [6] Fayad, M. E., Schmidt, D. C., Johnson, R. E., Building Applications Frameworks: Object Oriented Foundations of Framework Design, John Wiley & Sons, 1999

Clasificarea arhitecturilor aspectul stratificat: sistemele software sunt structurate pe câteva nivele pentru

implementarea principiului „separarea intereselor” în cadrul unui sistem software (arhitecturile J2EE, portalurile)

aspectul datelor: datele pot fi structurate sau nestructurate

În ultimii ani au fost dezvoltate o serie de arhitecturi pentru rezolvarea cerinţelor specifice din diverse domenii de aplicaţii. Anastopoulos şi Romberg[1] descriu arhitecturile pentru mediile aplicaţiilor web în funcţie de aspectul stratificat al arhitecturilor sau de aspectul datelor (susţinerea diferitelor date şi formate de date):- aspectul stratificat: se referă la faptul că sistemele software sunt structurate pe câteva nivele pentru a implementa principiul „separarea intereselor” în cadrul unui sistem software. Multe cadre din domeniul sistemelor distribuite şi aplicaţiilor web sunt structurate în principal în funcţie de aspectul stratificat (de exemplu arhitecturile J2EE[2] utilizate pentru a integra sistemele moştenite; portalurile).- aspectul datelor: datele pot fi structurate sau nestructurate. Datele structurate urmează o schemă definită asemănător tabelelor din bazele de date relaţionale sau structurilor XML dintr-un document. Datele nestructurate sunt elemente multimedia (imagini, audio, video) care nu respectă o schemă explicită, ceea ce face dificilă procesarea lor automată.

[1] Anastopoulos, M., Romberg, T., Referenzarchitekturen f¨ur Web-Applikationen, Projekt Application2Web, Forschungszentrum Informatik (FZI), December, 2001, http://app2web.fzi.de/ , in German[2] 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

Clasificarea arhitecturilorArhitecturi şi infrastructuri ce se adresează distribuirii datelor şi mesajelor

- DOM (Distributed Object Middleware) - accesarea obiectelor de la distanţă în mod transparent şi se bazează pe mecanismul RPC (Microsoft’s DCOM)

59

http://www-106.ibm.com/developerworks/patterns/

- VSM (Virtual Shared Memory) - permite proceselor distribuite să acceseze datele comune (Corso)

- MOM (Message Oriented Middleware) - oferă funcţionalităţi pentru transmiterea asincronă a mesajelor (Microsoft Message Queue)

- P2P (Peer to Peer) - comunicarea directă între două dispozitive (parteneri) într-un sistem fără utilizarea unui server (Xmiddle)

- SOM (Service Oriented Middleware) - îmbunătăţeşte sistemele DOM prin conceptul de servicii (Jini)

Arhitecturile prezentate se pot aplica sistemelor distribuite în general şi nu sunt limitate doar la aplicaţiile web

Răspândirea din ce în ce mai mare a sistemelor software a condus la dezvoltarea arhitecturilor şi infrastructurilor ce se adresează distribuirii datelor şi mesajelor:- DOM (Distributed Object Middleware): acest tip de infrastructură permite accesarea obiectelor de la distanţă în mod transparent şi se bazează pe mecanismul RPC (Remote Procedure Call) (exemplu: DCOM - Distributed Component Object Model de la Microsoft)- VSM (Virtual Shared Memory): modelul VSM permite proceselor distribuite să acceseze datele comune (exemplu: Corso http://www.tecco.at)- MOM (Message Oriented Middleware): sistemele MOM oferă funcţionalităţi pentru transmiterea asincronă a mesajelor. Comunicarea asincronă diferă de cea sincronă prin faptul că mesajele sunt trimise destinatarului indiferent de starea acestuia (de exemplu destinatarul poate să nu fie disponibil când mesajul este trimis - este offline). Exemplu: MSMQ - Microsoft Message Queue. - P2P (Peer to Peer): înseamnă comunicarea directă între două dispozitive (pereche) într-un sistem fără utilizarea unui server (ele comunică printr-o conexiune de tip punct-la-punct). Exemplu: Xmiddle (http://xmiddle.sourceforge.net/)- SOM (Service Oriented Middleware) - îmbunătăţeşte sistemele DOM prin conceptul de servicii. Un serviciu în acest context reprezintă un număr de obiecte şi comportamentul acestora; aceste obiecte folosesc o interfaţă definită pentru a face un serviciu disponibil pentru alte sisteme/servicii. Exemplu: sistemul Jini de la Sun (http://www.sun.com/software/jini/).Arhitecturile prezentate se pot aplica sistemelor distribuite în general, nefiind limitate doar la aplicaţiile web.

Particularităţile arhitecturilor pentru aplicaţiile web arhitectura infrastructurii web (Web Platform Architectures -WPA) şi infrastructura

aplicaţiilor web (Web Application Architectures - WAA)

WPA Serverele de aplicaţii precum implementarea J2EE şi platforma .NET soluţii arhitecturale specifice pentru rezolvarea problemelor de securitate,

performanţă şi integrare a datelor (firewall-uri, proxy-uri ptr caching şi EAI)Aplicaţiile web actuale utilizează un număr ridicat de infrastructuri tehnice pentru rezolvarea anumitor probleme: cadre de lucru open-source (Struts (http://jakarta.apache.org/struts/ şi Cocoon (http://xml.apache.org/cocoon/), servere de aplicaţii (de exemplu implementarea EJB) şi JetSpeed (http://jakarta.apache.org/jetspeed/). Internaţionalizarea aplicaţiilor web - suport pentru limbi diferite, seturi de caractere şi mecanisme de reprezentare

Particularităţile arhitecturilor pentru aplicaţiile web Pentru început este necesară realizarea unei distincţii între arhitectura infrastructurii web (Web Platform Architectures -WPA) şi arhitectura aplicaţiei web (Web Application Architectures - WAA). Deoarece WAA depinde de domeniul problemei aplicaţiei web, vom insista asupra WPA-urilor. WPA-urile au fost dezvoltate pentru o arie largă de probleme. Serverele de aplicaţii precum implementările J2EE şi platforma .NET încearcă să ofere servicii de bază pentru controlul

60

http://jakarta.apache.org/jetspeed/

http://xml.apache.org/cocoon/

http://jakarta.apache.org/struts/

sesiunilor şi accesul la date. În afara serverelor de aplicaţii au fost dezvoltate soluţii arhitecturale specifice pentru problemele de securitate, performanţă şi integrare a datelor (firewall-uri, proxy-uri pentru caching şi EAI). Paradoxal, utilizarea unui număr mare de sisteme diferite face dificilă evaluarea şi menţinerea unor cerinţe de calitate distincte. De exemplu, îndeplinirea cerinţelor de performanţă a devenit mai dificilă datorită numărului din ce în ce mai mare de componente şi produse (comerciale sau gratuite) utilizate de la vânzători terţi. Alte probleme în dezvoltarea aplicaţiilor web sunt neomogenitatea şi imaturitatea infrastructurilor tehnice. Gorton şi Liu (2002) descriu problemele care apar la analiza performanţei pentru serverele de aplicaţii datorită update-urilor frecvente; studiul relevă că versiunile noi de produse sunt mai lente decât predecesoarele lor şi noile funcţionalităţi determină incompatibilităţi în codul aplicaţiei existente. După adaptări extensive, care au necesitat o cunoaştere extrem de detaliată a produselor în cauză, s-a putut restaura comportamentul de performanţă dorit.Indiferent de problemele de neomogenitate şi imaturitate, aplicaţiile web actuale utilizează un număr ridicat de infrastructuri tehnice diferite pentru rezolvarea anumitor probleme: cadrele open-source (Struts http://jakarta.apache.org/struts/ şi Cocoon http://xml.apache.org/cocoon/), servere de aplicaţii (de exemplu implementările EJB), cadrele portal (JetSpeed http://jakarta.apache.org/jetspeed/). Un alt aspect important în domeniul arhitecturilor aplicaţiilor web este internaţionalizarea aplicaţiilor web, care necesită suport pentru diferite limbi, seturi de caractere şi mecanisme de reprezentare (ex. reprezentarea caracterelor arabice de la dreapta la stânga) la nivelul WPA. Multe dintre aceste aspecte sunt suportate de limbajele de programare sau sistemele de operare (exemplu platforma PHP oferă un mecanism de internaţionalizare pentru codificarea seturilor de caractere diferite -ISO-8859-2, UTF-8- realizată şi cu ajutorul programului Gettext).

Componentele arhitecturii aplicaţiilor web

Figura 4.2 Componentele de bază ale arhitecturilor unei aplicaţii web

În Figura 4.2 sunt reprezentate componentele de bază ale arhitecturilor web şi relaţiile dintre ele. Comunicarea dintre aceste componente se bazează în general pe principiul cerere-răspuns: o componentă (ex. un browser web) trimite o cerere către o altă componentă (ex. un server web) şi răspunsul la această cerere este trimis înapoi pe acelaşi canal de comunicare (comunicare sincronă).

Client

Browser

Plug-in-uriApplet-uri

Aplicaţii externe

Firewall Proxy

Server de baze de date

Server de aplicaţie

Server media Server de management al conţinutului

Aplicaţii moştenite

Server web

Fişiere HTML,XML, XSL

Container CGI Servlet

Componentele arhitecturii web

Componente opţionale ale arhitecturilor web

Ciclu Cerere/Răspuns

61

Componentele frecvent implicate în comunicare sunt:- client: în general un browser (agent utilizator) este controlat de către un utilizator care

foloseşte aplicaţia web. Funcţionalitatea clientului poate fi extinsă prin instalarea plug-in-urilor şi applet-urilor.

- firewall: un software care reglementează comunicarea între reţele nesecurizate (exemplu Internet) şi reţele securizate (exemplu reţele locale ale unei companii). Această comunicare este filtrată prin reguli de acces.

- proxy: un proxy este utilizat pentru a stoca temporar paginile web într-un cache, pentru a adapta conţinutul pentru utilizatori (personalizare) sau pentru a urmări utilizatorii.

- server web: un software care suportă diferite protocoale web (exemplu HTTP şi HTTPS) pentru a procesa cererile clientului.

- server de baze de date: prezintă datele de producţie ale unei organizaţii într-o formă structurată (exemplu: în tabele)

- server media: este utilizat pentru streaming-ul conţinutului pentru datele nestructurate (exemplu: audio sau video)

- server pentru managementul conţinutului: păstrează conţinutul aferent unei aplicaţii, care este disponibil sub forma datelor semistructurate (exemplu: documente XML)

- server de aplicaţii: păstrează funcţionalitatea necesară diverselor aplicaţii (exemplu: fluxul de date sau personalizarea)

- aplicaţii moştenite: un sistem mai vechi care trebuie integrat ca o componentă internă sau externă.

Arhitecturile stratificate Arhitecturi pe două straturi

Figura 4.3 Arhitectură pe două straturi pentru aplicaţiile web

Arhitectura pe două straturi poate lua forme diferite în mediul aplicaţiilor web. O cerere a unui client poate puncta direct către pagini HTML statice, fără a solicita un raţionament de

Client

Client

ServerServerul web şi logica afacerii Servicii

Pagini HTML dinamice

Pagini HTML statice

Baze de date

62

procesare pe stratul server sau poate accesa o bază de date prin intermediul logicii aplicaţiei pe serverul web (de exemplu sub forma scripturilor CGI). Paginile HTML dinamice includ instrucţiuni de tip script direct în codul HTML (de exemplu când este utilizat SSI - Server-Side Include sau PHP) şi ele sunt interpretate fie de bazele de date cu funcţionalităţi HTML fie de un server web. Logica aplicaţiei sau paginile HTML dinamice pot utiliza servicii (exemplu identificarea utilizatorului sau criptarea datelor) când este generat răspunsul HTML. Această arhitectură este adecvată aplicaţiilor web simple.

O abordare arhitecturală multi-stratificată este necesară pentru aplicaţiile mai complexe care sunt accesate de un număr mare de clienţi concurenţi sau care oferă procese de afaceri complexe ce necesită accesarea sistemelor moştenite etc.

Arhitecturi pe N straturi

Figura 4.4 O arhitectură pe N straturi pentru aplicaţiile web

Arhitecturile pe N straturi permit organizarea unei aplicaţii web pe un număr arbitrar de nivele (vezi figura 4.4). Acestea constau de obicei în trei straturi: stratul datelor, care oferă acces la datele aplicaţiei, stratul afacerii – care găzduieşte logica de afaceri a aplicaţiei într-un server de aplicaţii şi stratul prezentare – care returnează rezultatul cererii în formatul de ieşire dorit. În plus, pot fi integrate în fluxul cerere-răspuns mecanisme de securitate cum ar fi firewall-urile sau mecanisme de caching (proxy).

Arhitecturile pe două straturi şi N straturi diferă în principal prin modul în care încorporează serviciile în componenta server a aplicaţiei. Servicii precum personalizarea sau fluxul de date sunt păstrate în serverul aplicaţiei, astfel încât să fie disponibile pentru toate aplicaţiile web.

Client

Firewall

Proxy

Server web

Server de aplicaţii

Acces date Colaborare

Logistica afacerii

Nivelul afacere

Flux de date Personalizare

etc. Conectori

Backend

Aplicaţii de moştenire

Sistem informaţional al

companiei

Nivelul prezentare

Server de baze de date B2B Nivelul datelor

63

Serviciile sunt încorporate în serverul de aplicaţii cu o interfaţă definită, care poate fi utilizată şi pentru a administra aceste servicii. Un exemplu pentru aceste funcţionalităţi este serverul de aplicaţii WebSphere, împreună cu componentele afacerii WebSphere.

Conectorii pot fi utilizaţi pentru a integra sistemele externe (ex. sisteme partener de afaceri) sau pentru a integra aplicaţii moştenite şi sisteme informaţionale ale companiilor.

Majoritatea serverelor de aplicaţii comerciale au fost optimizate pentru procesarea conţinutului bazelor de date, suportul pentru conţinutul multimedia şi structurile hipertext fiind neglijat. Un exemplu de integrare a datelor video într-un server de aplicaţii este disponibil la http://www.ibm.com/software/data/informix/blades/video/.

Proxy-uri

• proxy-uri de legături: sunt de cel puţin două tipuri. -sistemele de tipul URL-urilor persistente (PURLs- Persistent URLs) utilizează

componente de tip proxy - server intermediar pentru a trimite cererile de URL-uri ale clientului către serverul real

- utilizate pentru a adapta şi formata legăturile şi conţinutul pentru utilizatori

• proxy-uri de istoric - pot fi utilizate pentru a administra istoricul paginilor vizitate de utilizator - Serverul Boomerang de pe DoubleClick

Proxy-uriIniţial proxy-urile erau folosite pentru a salva lăţimea de bandă, din acest motiv fiind numite

şi proxy-uri de caching[1]. Proxy-urile sunt capabile să îndeplinească şi alte funcţii:- proxy-uri de legături: sunt de cel puţin două tipuri. În primul rând, sistemele de tipul URL-

urilor persistente (PURLs- Persistent URLs[2]) utilizează componente de tip proxy. Mai exact, un proxy este utilizat ca un server intermediar pentru a trimite cererile de URL-uri ale clientului către serverul real. Dacă numele sau locaţia resursei solicitate se schimbă, atunci adresa sa (URL) trebuie schimbată doar intern (clientul nu trebuie să ştie acest lucru). O astfel de schimbare necesită un tabel de mapare între URL-ul solicitat şi cel „real”, acesta fiind gestionat de către proxy. În al doilea rând, proxy-urile sunt utilizate pentru a adapta şi formata legăturile şi conţinutul pentru utilizatori. O metodă folosită în acest concept este inserarea dinamică a legăturilor care se potrivesc intereselor unui utilizator, prin aceasta paginile HTML fiind analizate de proxy şi modificate pentru a se potrivi profilului utilizatorului. Utilizatorul va fi informat la sfârşitul documentului în privinţa schimbării resursei transmise.

- proxy-uri de istoric: multe aplicaţii web încearcă să-şi adapteze funcţionalităţile cerinţelor utilizatorilor. Problema care apare este că HTTP-ul este un protocol simplu, care nu oferă informaţii despre istoricul navigării unui utilizator pe mai multe situri. De exemplu, dacă un utilizator planifică o vacanţă şi rezervă un zbor, un hotel şi o maşină de închiriat pe internet, atunci vânzătorul de bilet de avion nu ştie că utilizatorul a rezervat o cameră la hotel şi o maşină de închiriat. Dacă compania aeriană ar cunoaşte aceste informaţii, atunci camera de hotel şi maşina rezervate ar putea fi anulate dacă utilizatorul contramandează zborul. O problemă similară apare şi în domeniul marketingului direct, în care, cu cât se cunosc mai multe detalii despre interesele utilizatorului, cu atât publicitatea va fi mai orientată pe consumator. Proxy-urile pot fi utilizate pentru a administra istoricul paginilor vizitate de utilizator, prin atribuirea unui ID unic pentru un utilizator şi stocarea acestui ID utilizând tehnologia cookie. În această situaţie, dacă utilizatorul vizitează situl web al unei alte companii conectate la acelaşi proxy, atunci informaţiile despre acest utilizator pot fi extrase, permiţând identificarea unui utilizator unic. Serverul Boomerang de pe DoubleClick (http://www.doubleclick.com) utilizează acest concept pentru marketingul direct. [1] Bongio, A., Brambilla, M., Ceri, S., Comai, S., Fraternali, P., Matera, M., Designing Data-Intensive Web Applications, Morgan Kaufmann, 2003

[2] Weibel, S., Jul, E., Shafer, K., PURLs: Persistent Uniform Resource Locators, Online Computer Library Center (OCLC), 1999, http://purl.oclc.org/OCLC/PURL/SUMMARY

64

Arhitecturi de integrare

Figura 4.9 Exemplu de arhitectură a unei aplicaţii web orientată pe portal

Sistemele interne sau externe – aplicaţiile şi bazele de date existente, interfeţele către partenerii de afaceri externi - pot fi integrate în aplicaţiile web pe trei nivele: nivelul prezentare, nivelul logic al aplicaţiei şi nivelul conţinutului

Arhitecturile de integrare - se adresează aspectelor de integrare la nivelul conţinut şi nivelul logic al aplicaţiei şi sunt cunoscute sub numele de arhitecturi EAI (Enterprise Application Integration).

Arhitecturi de integrareSistemele interne sau externe – aplicaţiile şi bazele de date existente, interfeţele către partenerii de afaceri externi - pot fi integrate în aplicaţiile web pe trei nivele: nivelul prezentare, nivelul logic al aplicaţiei şi nivelul conţinutului. Arhitecturile de integrare se adresează aspectelor de integrare la nivelul conţinut şi nivelul logic al aplicaţiei şi sunt cunoscute sub numele de arhitecturi EAI (Enterprise Application Integration). În esenţă, EAI se focalizează pe integrarea sistemelor moştenite. O alternativă la EAI sunt serviciile web, care oferă integrarea serviciilor (logica aplicaţiei şi conţinutul). La nivelul prezentare, un set de sisteme diferite este integrat tipic prin utilizarea arhitecturilor portal. Portalurile reprezintă cele mai recente dezvoltări ale aplicaţiilor web multi-stratificate. Cu ajutorul portalurilor conţinutul, care este distribuit pe mai multe noduri ale diverşilor furnizori de servicii, va fi disponibil dintr-un singur nod, oferind un aspect consistent. În figura 4.9 este schematizată arhitectura de bază a unui server portal. Serverele portal se bazează pe portlet-uri, care aranjează conţinutul şi logica aplicaţiei într-o structura de navigare şi un layout adecvate portalului. Un exemplu de server portal este proiectul open-source JetSpeed (http://portals.apache.org/).

Arhitecturi în funcţie de aspectul datelor

(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

Arhitecturi axate pe baze de date- accesate fie direct prin intermediul extensiilor serverului web (în cazul arhitecturilor pe două straturi) fie prin serverele de aplicaţii (în cazul arhitecturilor pe N straturi) Arhitecturi pentru managementul documentelor web

Server web

Client Agregare

Portlet 1 Portlet n

Serviciu web 1

Serviciu web n

Conţinut Conţinut

65

- oferă posibilitatea integrării documentelor din surse diferite, reprezentând un mecanism pentru integrarea acestora în aplicaţiile web

Arhitecturi în funcţie de aspectul datelor Datele pot fi grupate în una din următoarele 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. Aplicaţiile web nu sunt limitate la una din aceste categorii de date, ele integrează documente, media şi baze de date.Arhitecturi axate pe baze de dateSunt disponibile numeroase utilitare şi abordări pentru integrarea bazelor de date în aplicaţiile web. Aceste baze de date sunt accesate fie direct prin intermediul extensiilor serverului web (în cazul arhitecturilor pe două straturi), fie prin serverele de aplicaţii (în cazul arhitecturilor pe N straturi). Pentru accesul la bazele de date relaţionale sunt disponibile interfeţe (APIs) pentru diferite platforme (Java Database Connectivity -JDBC pentru aplicaţii bazate pe Java sau Open Database Connectivity -ODBC pentru tehnologii Microsoft).Arhitecturi pentru managementul documentelor web Pe lângă datele structurate din bazele de date şi cele multimedia de pe serverele media, conţinutul aplicaţiilor web este frecvent procesat sub forma documentelor. Arhitecturile de management al conţinutului oferă posibilitatea integrării documentelor din surse diferite, reprezentând un mecanism pentru integrarea acestor conţinuturi în aplicaţiile web.

Figura 4.10 Arhitectură de management a conţinutului pentru aplicaţiile web

Figura 4.10 reprezintă componentele unei arhitecturi de management al conţinutului. Un server web recepţionează o cerere de la client şi o trimite mai departe unui server de furnizare a conţinutului (responsabil pentru distribuirea şi eventual caching-ul conţinutului). Dacă conţinutul

Client

Sistem de furnizare a conţinutului

Server web

Server de furnizare a conţinutului

Serviciu sindicat

Partener

EditorServiciuDispatch

Documente statice

Baze de date pentru conţinut

Serviciu de agregare

Baze de date externe

Server de management al conţinutului

66

solicitat nu este în cache atunci cererea este trimisă mai departe către serverul de management al conţinutului. Conţinutul poate fi disponibil direct pe acel server (în formă statică ca un document sau într-o bază de date) sau poate fi accesat extern. În funcţie de tipul de integrare conţinutul extern poate fi extras fie prin accesarea bazelor de date externe (direct sau prin utilizarea unui serviciu de agregare) fie dintr-un serviciu de mediatizare. Spre deosebire de accesarea unei baze de date, serviciile de mediatizare pot avea şi funcţionalităţi suplimentare (exemplu facturarea automată a drepturilor de licenţă).

Arhitecturi pentru datele multimedia

Figura 4.12 Arhitectura media de streaming care utilizează conexiuni punct-la-punct

Arhitecturi pentru datele multimediaCapacitatea de a manipula un volum mare de date are un rol decisiv în proiectarea sistemelor care utilizează conţinut multimedia. Deşi volumul de date nu este important în aplicaţiile web axate pe baze de date, acesta influenţează considerabil arhitectura şi proiectarea aplicaţiilor web multimedia. Datele multimedia – audio şi video- pot fi transmise prin intermediul protocoalelor internet standard (HTTP sau FTP), asemenea altor date folosite în aplicaţiile web. Această abordare este utilizată de un număr mare de aplicaţii web, deoarece prezintă avantajul că nu necesită componente suplimentare pe server; dezavantajul este că descărcările de fişiere multimedia sunt foarte lente. Se pot utiliza tehnologii streaming pentru a minimiza perioada de aşteptare pentru redarea conţinutului multimedia; prin streaming în acest context se înţelege că un client poate reda un fişier audio şi/sau video la câteva secunde după ce începe recepţionarea acestuia de pe server. Această tehnică evită descărcarea întregului fişier înainte de a începe redarea lui. Conţinutul trebuie transmis în timp real, ceea ce necesită o lăţime de bandă corespunzătoare (garantarea lăţimii de bandă a transmisiei este numită calitatea serviciului).

Client la locaţia A

Browser

Plug-in streaming

Client la locaţia B

Browser

Streamingclient

Proxy apropiat locaţiei A

Proxy apropiat locaţiei B

Server web Server media

RTP/RTSP

RTP/RTSP

RTP/RTSP

RTP/RTSP

http

http

API

67

În general sunt folosite două protocoale pentru streaming-ul de conţinut multimedia: un protocol preia transmisia datelor multimedia la nivelul reţea, iar celălalt controlează fluxul prezentării (exemplu pornirea şi oprirea unui clip video) şi transmisia meta-datelor. Un exemplu de protocol de reţea este RTP (Real Time Protocol) care cooperează cu un protocol de control numit RTSP (Real Time Streaming Protocol). Există două domenii distincte de aplicaţii pentru streaming-ul datelor multimedia: primul face disponibil la cerere conţinutul existent (ex. video la cerere), iar al doilea distribuie live conţinutul unui număr mare de utilizatori (ex. web casting). Fiecare din aceste două cazuri de utilizare formulează cereri total diferite la nivelul reţelei şi arhitecturilor hardware şi software. Deşi fiecare utilizator stabileşte propria sa conexiune la server într-un scenariu la cerere (vezi figura 4.12) cauzând probleme majore de lăţime de bandă şi încărcare pe server, broadcasting-ul realizează cereri foarte mari la nivelul reţelei. În mod ideal, un server utilizat pentru broadcasting ar trebui să administreze un singur stream media, care este difuzat simultan către toţi utilizatorii de către infrastructura reţelei (de exemplu de router-e), ca în figura 4.13. Deoarece multicasting-ul nu este suportat în general în Internet, serverul trebuie să folosească conexiuni punct-la-punct pentru a „simula” funcţionalitatea broadcast.

Figura 4.13 Arhitectura media de streaming care utilizează o infrastructură broadcasting

Există două domenii distincte de aplicaţii pentru streaming-ul datelor multimedia: primul face disponibil la cerere conţinutul existent (ex. video la cerere), iar al doilea distribuie live conţinutul unui număr mare de utilizatori (ex. web casting). Fiecare din aceste două cazuri de utilizare formulează cereri total diferite la nivelul reţelei şi arhitecturilor hardware şi software. Deşi fiecare utilizator stabileşte propria sa conexiune la server într-un scenariu la cerere (vezi figura 4.12) cauzând probleme majore de lăţime de bandă şi încărcare pe server, broadcasting-ul realizează cereri foarte mari la nivelul reţelei. În mod ideal, un server utilizat pentru broadcasting ar trebui să administreze un singur stream media, care este difuzat simultan către toţi utilizatorii de către infrastructura reţelei (de exemplu de router-e), ca în figura 4.13. Deoarece multicasting-ul nu este suportat în general în Internet, serverul trebuie să folosească conexiuni punct-la-punct pentru a „simula” funcţionalitatea broadcast.

Client Client Client

Client

Client

Client

Servermedia

ClientClient

Router 1

Router m

Router n

68

Documents

Proiectarea Web - Dezvoltarea Sistematica a Aplicatiilor Web