Proiectarea web - dezvoltarea sistematica a aplicaiilor web

orientarea actual n domeniul dezvoltrii aplicaiilor web - abordare ad-hoc i o lips a metodelor de dezvoltare > calitate construirea unui ciclu de via a aplicaiilor web, prezentarea conceptelor, tehnicilor, metodelor i utilitarelor pentru dezvoltarea sistematic a aplicaiilor web > evolutie, infrastructura Proiectarea web ca disciplin tiinific este influenat de dezvoltarea aplicaiilor web. Orientarea actual n domeniul dezvoltrii aplicaiilor web este deseori caracterizat printr-o abordare ad-hoc i o lips a metodelor de dezvoltare. Datorit complexitii i ritmului proliferrii aplicaiilor web, aceast abordare are un impact negativ asupra calitii. Aplicaiile web reprezint un nou domeniu de aplicaii cu propriile sale provocri asupra dezvoltrii software-ului. Este necesar construirea unui ciclu de via a aplicaiilor web, prezentarea conceptelor, tehnicilor, metodelor i utilitarelor pentru dezvoltarea sistematic a aplicaiilor web. Web-ul, aplicaiile web i comunitatea web n ansamblu au evoluat de la apariia Internet-ului la Web 2.0 i la viziunea web-ului semantic, din acest motiv fiind esenial renunarea la abordarea de tip ad-hoc i adoptarea principiilor proiectrii web. La nivel de infrastructur, web-ul este un spaiu creat prin intermediul unor limbaje i protocoale specificate formal. Dei oamenii sunt implicai n crearea paginilor i utilizarea legturilor dintre acestea, interaciunea acestora formeaz un model web la scar macroscopic. Aceste interaciuni umane sunt guvernate de convenii sociale, politici i legi. Dezvoltarea aplicaiilor web este rezultatul unei afaceri complexe i este esenial ca proiectarea care sprijin aceast dezvoltare s fie bine realizat. Acest lucru va permite studenilor i specialitilor s proiecteze aplicaii web de o calitate superioar pe baza principiilor de proiectare software experimentate i de ncredere. I. Introducere n proiectarea aplicaiilor web Proiectarea web - utilizarea unei abordri sistematice i cuantificabile pentru realizarea specificaiilor, implementrii, operaiilor i ntreinerii aplicaiilor web de calitate superioar > tipuri de aplicaii web Aplicaiile web de astzi - sisteme software complexe care ofer servicii interactive i personalizabile accesibile prin intermediul diferitelor dispozitive Aplicaie web = sistem software bazat pe tehnologiile i standardele W3C, care ofer resurse web specifice (coninut i servicii) prin intermediul unei interfee utilizator numit browser web Aplicaiile web moderne sunt sisteme software complexe, iar dezvoltarea acestora necesit o abordare metodologic. Similar cu proiectarea aplicaiilor software, proiectarea web implic utilizarea unei abordri sistematice i cuantificabile pentru realizarea specificaiilor, implementrii, operaiilor i ntreinerii aplicaiilor web de calitate superioar. Din punct de vedere al istoricului dezvoltrii i complexitii distingem anumite tipuri de aplicaii web: orientate pe documente, interactive, tranzacionale, cu caracteristici ubicue sau trsturi ale web-ului semantic. Cerinele particulare ale proiectrii aplicaiilor 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 vieii noastre. Economia, industria, educaia, sntatea, administraia public, divertismentul majoritatea componentelor vieii noastre au fost ptrunse de World Wide Web. Motivul acestei omniprezene const n special n natura web-ului, caracterizat prin disponibilitatea global i permanent dar i prin accesul omogen la informaiile distribuite la nivel global sub forma paginilor web[1]. Dei iniial web-ul a fost proiectat ca un mediu pur informaional, n prezent el evolueaz ntr-un mediu al aplicaiilor. Aplicaiile web de astzi sunt sisteme software complexe care ofer servicii interactive i personalizabile accesibile prin intermediul diferitelor dispozitive; ele ofer posibilitatea realizrii tranzaciilor ntre utilizatori i de obicei stocheaz datele ntr-o baz de date. Elementul distinctiv al aplicaiilor web comparativ cu aplicaiile software tradiionale este modul n care este utilizat web-ul: tehnologiile i standardele sale sunt utilizate ca o platform de dezvoltare i ca platform utilizator n acelai timp. O aplicaie web poate fi definit astfel: 1

O aplicaie web este un sistem software bazat pe tehnologiile i standardele consoriului World Wide Web (W3C), care ofer resurse web specifice (coninut i servicii) prin intermediul unei interfee utilizator numit browser web. Aceast definiie include n mod explicit tehnologiile i interaciunea cu utilizatorul. De aici putem deduce c tehnologii precum serviciile web nu sunt aplicaii web, dar pot fi o parte a acestora, iar siturile web lipsite de componente software (cum sunt paginile HTML statice) nu sunt considerate aplicaii web. [1] Berners-Lee, T., WWW: Past, Present, and Future, IEEE Computer, 29 (10), 1996, pp. 6977 Schimbri fundamentale ale web-ului - de la un mediu informaional la un mediu al aplicaiilor Dezvoltarea aplicaiiilor web - eveniment spontan, de obicei bazat pe cunoaterea, experiena i practicile de dezvoltare ale dezvoltatorilor individuali, greu de reutilizat la modul Copy&Paste i avnd o documentare necorespunztoare a deciziilor de proiectare > probleme de calitate i dificulti de operare i ntreinere n ciuda schimbrilor fundamentale ale web-ului de la un mediu informaional la un mediu al aplicaiilor, situaia actual a dezvoltrii ad-hoc a aplicaiilor web ne amintete de practicile de dezvoltare a software-ului din anii 60, nainte s se realizeze c dezvoltarea aplicaiilor necesit mai mult dect experien n programare[1]. Dezvoltarea aplicaiilor web este deseori privit ca un eveniment spontan, de obicei bazat pe cunoaterea, experiena i practicile de dezvoltare ale dezvoltatorilor individuali, greu de reutilizat la modul Copy&Paste i avnd o documentare necorespunztoare a deciziilor de proiectare. Dei acest procedeu poate prea pragmatic, astfel de metode de dezvoltare rapide i superficiale conduc deseori la probleme serioase privitoare la calitate i implicit la dificulti de exploatare i ntreinere. Aplicaiile dezvoltate sunt deseori dependente de tehnologie, predispuse la erori i sunt caracterizate prin lipsa performanei, siguranei, accesibilitii i deci a acceptrii de ctre utilizatori[2]. Legtura strns dintre aplicaiile web sporete pericolul rspndirii problemelor de la o aplicaie la alta. Cauza acestei situaii 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. 227263 Cauza acestei situaii abordarea centrat pe document (authoring) ) presupusa simplitate a dezvoltrii aplicaiilor web (editoare, generatoare) cunotinele specifice din discipline relevante nu pot aplicate sau utilizate Legtura strns dintre aplicaiile web sporete pericolul rspndirii problemelor de la o aplicaie la alta. Cauza acestei situaii este complex i poate fi abordat din mai multe perspective: - abordarea centrat pe document. Dezvoltarea aplicaiilor web este nc deseori considerat a fi centrat pe document o activitate de authoring care include crearea i realizarea legturilor din siturile web i includerea elementelor grafice. Dei anumite tipuri de aplicaii web (de exemplu paginile principale, ziarele online) aparin acestei categorii, o abordare de tip authoring nu este adecvat pentru dezvoltarea de aplicaii web concentrate pe software; - presupusa simplitate a dezvoltrii aplicaiilor web. Disponibilitatea larg a diferitelor utilitare, (cum ar fi editoarele HTML sau generatoarele de formulare) permite crearea de aplicaii web simple, fr a fi necesare cunotine de specialitate. De obicei, accentul se pune pe proiectarea vizual i nu pe structurarea intern sau programare. Aceasta duce la inconsistene i redundan; - cunotinele specifice din discipline relevante nu pot fi aplicate sau nu sunt utilizate. Exist o concepie greit conform creia dezvoltarea aplicaiilor web este similar cu dezvoltarea aplicaiilor tradiionale i din acest motiv pot fi utilizate metodele din Ingineria Software, n sensul abordrii sistematice, cu msuri adecvate de control a calitii. Acest lucru este neadecvat n majoritatea cazurilor datorit caracteristicilor speciale ale aplicaiilor web. n plus, concepte i tehnici din domenii relevante (cum ar fi 2

hypertext-ul sau interaciunea om-calculator) nu sunt aplicate ntr-o manier consecvent. Standardele de dezvoltare pentru aplicaiile web de calitate sunt inexistente, acest lucru datorndu-se i relativ scurtei istorii a web-ului. Proiectarea web - nu este un eveniment imediat Abordare disciplinar aplicarea unei abordri sistematice i cuantificabile (concepte, metode, tehnici i utilitare) n analiza, proiectarea, implementarea, testarea, operarea i ntreinerea aplicaiilor web de calitatea superioar; o disciplin tiinific implicat n studiul acestei abordri Termeni din literatur asociai - proiectarea siturilor web, proiectarea hipermedia, proiectarea documentelor, proiectarea coninutului 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 aplicaiei 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 tiinei, mai mult sau mai puin independent, care include cercetarea, nvarea i diseminarea informaiei tiinifice sub forma publicaiilor. Numrul mare de publicaii, cursuri, programe analitice, seminarii tiinifice i conferine demonstreaz c, n acord cu aceast definiie, Proiectarea web poate fi considerat o ramur independent a ingineriei software. Proiectarea reprezint n general o aplicaie practic a tiinei (n comer sau industrie) folosit n scopul dezvoltrii aplicaiilor ntr-un mod mai bun, mai rapid, mai ieftin i mai sigur. Ingineria software este definit ca o aplicaie a tiinei i matematicii prin care capacitile unui sistem de calcul sunt pot fi utilizate de oameni prin intermediul programelor, procedurilor i documentaiei asociate. Pe baza acestei definiii i a celei lui Deshpande[1], putem defini Proiectarea web n dou moduri: - Proiectarea web reprezint aplicarea unor abordri sistematice i cuantificabile (concepte, metode, tehnici, utilitare) n analiza cerinelor, proiectarea, implementarea, testarea, exploatarea i ntreinerea aplicaiilor web de calitate superioar; - Proiectarea web reprezint i disciplina tiinific implicat n studiul acestor abordri. Termenii din literatur asociai sunt Proiectarea siturilor web, Proiectarea hipermedia, Proiectarea documentelor, Proiectarea coninutului i Proiectarea software-lui Internet. Prin comparaie, Proiectarea web este un termen concis, dei dac vorbim n mod strict nu este foarte precis: nu web-ul este proiectat, ci aplicaiile web. Din punct de vedere al Ingineriei Software, dezvoltarea aplicaiilor web este un nou domeniu al aplicaiilor. n ciuda anumitor similitudini cu aplicaiile tradiionale, caracteristicile speciale ale aplicaiilor web necesit o adaptare a multor abordri ale Ingineriei Software sau chiar dezvoltarea unor abordri complet noi. Principiile de baz ale Proiectrii web pot fi descrise totui n mod similar celor din Ingineria Software: - obiective i cerine clar definite; - dezvoltarea sistematic, n faze, a aplicaiilor web; - planificarea foarte atent a acestor faze; - auditul continuu al ntregului proces de dezvoltare. Proiectarea web face posibil planificarea i repetarea proceselor de dezvoltare, facilitnd astfel evoluia continu a aplicaiilor web. Aceasta permite nu doar reducerea costurilor i minimizarea riscului pe parcursul dezvoltrii i ntreinerii, ci i creterea calitii i msurarea calitii rezultatelor fiecrei 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. 317 [2] Mendes, E., Mosley, N., Web Engineering, Springer, 2006 Categorii de aplicaii web grade variate de complexitate - pur informaionale sau aplicaii de comer electronic complexe - 24 / 7 3

Remarcm faptul c exist o corelaie ntre cronologia dezvoltrii i complexitate. De exemplu, aplicaiile bazate pe fluxuri de lucru sunt bazate pe tranzacii, adic nivelul superior de dezvoltare necesit o dezvoltare anterioar a unei categorii mai puin complexe. Exist i excepii de la aceast regul pentru anumite categorii (de exemplu aplicaiile orientate pe portaluri), care sunt recente din punct de vedere istoric dar au un grad sczut de complexitate. Aplicaiile web ale organizaiilor care au fost pe web nc de la nceputuri au avut deseori un istoric al dezvoltrii similar cu cel descris n figura 1.1. Dezvoltarea unei aplicaii web poate fi nceput n oricare din aceste categorii i ulterior continuat ctre un nivel sporit de complexitate. Noile categorii sunt n general mult mai complexe, dar aceasta nu nseamn c ele pot nlocui n totalitate vechea generaie. Aplicaiile web complexe pot fi n mod tipic alocate mai multor categorii odat: de exemplu, magazinele online de cumprturi integreaz diferii furnizori de servicii, dar ofer i diferite posibiliti de cutare, monitorizarea strii comenzilor i n anumite cazuri chiar licitaii online. Putem sesiza c diferite categorii de aplicaii web acoper mai multe domenii tradiionale ale aplicaiilor, cum ar fi bncile online, dar n acelai timp creeaz noi domenii ale aplicaiilor, cum ar fi serviciile de localizare (location-aware services). n cele ce urmeaz vom descrie trsturile relevante ale acestor categorii. Siturile web axate pe documente sun t precursoare ale aplicaiilor web. Paginile web sunt stocate pe un server web ca documente HTML statice i sunt trimise clientului web ca rspuns la o cerere. Aceste pagini web sunt de obicei actualizate manual folosind utilitare corespunztoare. Pentru siturile web care impun schimbri frecvente sau pentru cele cu un numr mare de pagini aceast actualizare crete semnificativ costurile i adesea are drept consecin prezentarea unor informaii depite. n plus exist pericolul apariiei inconsistenelor atunci cnd un anumit coninut este prezentat frecvent, redundant pe mai multe pagini web pentru a uura accesul. Principalele beneficii sunt simplitatea i stabilitatea unui astfel de sit web dar i timpul scurt de rspuns, paginile fiind deja stocate pe serverul web. Paginile principale statice i paginile simple pentru micile afaceri aparin acestei categorii. 4

Odat cu apariia standardului Common Gateway Interface (http://hoohoo.ncsa.uiuc.edu/cgi/interface.html) i formularelor HTML, s-au dezvoltat i aplicaiile web interactive, oferind o prim form de interactivitate prin intermediul formularelor, butoanelor radio i meniurilor de selecie. Paginile web i legturile ctre alte pagini sunt generate n mod dinamic n funcie de datele introduse de utilizator. Exemple de astfel de categorii sunt expoziiile virtuale, siturile de tiri sau de planificare a cltoriilor. Aplicaiile web tranzacionale ofer mai mult interactivitate, utilizatorul avnd posibilitatea de a interaciona cu aplicaia n modul citire dar i de a realiza actualizri ale coninutului de baz. De exemplu, un sistem informaional pentru turism permite actualizarea coninutului ntr-un mod descentralizat sau face posibil rezervarea camerelor. Premisa necesar pentru un astfel de sistem implic existena unor sisteme de baze de date care permit manevrarea eficient a unui coninut n continu cretere n cadrul aplicaiilor web i ofer posibilitatea unor interogri structurate. Bncile online, magazinele online i sistemele de rezervare online pentru hoteluri aparin acestei categorii. Aplicaiile web bazate pe fluxuri de lucru permit manevrarea fluxurilor de lucru n interiorul sau ntre diferite companii, autoriti publice i utilizatori privai. Pentru aceste aplicaii este esenial disponibilitatea unor servicii web adecvate pentru asigurarea interoperabilitii[1]. Complexitatea acestor servicii, autonomia companiilor participante i necesitatea ca fluxurile de lucru s fie robuste i flexibile reprezint principalele provocri. Aplicaii ce fac parte din aceast categorie sunt soluiile B2B (Business-toBusiness) din comerul electronic, aplicaiile e-government n domeniul administraiei publice sau suportul web pentru fluxurile de date ale pacienilor n sectorul sntii. n timp ce aplicaiile bazate pe fluxuri de lucru necesit o anumit structurare a proceselor i operaiilor automatizate, aplicaiile web colaborative sunt folosite ndeosebi n scopul cooperrii n operaiile nestructurate (groupware), unde exist o nevoie foarte pentru comunicaie ntre utilizatori. Aplicaiile web n colaborare suport distribuirea informaiei i spaiile de lucru (ex. WikiWiki - http://c2.com/cgi/wiki - sau BSCW - http://bscw.gmd.de/ -) pentru a genera, edita i administra informaiile distribuite. Acestea sunt utilizate i pentru a pstra log-urile unor mesaje scurte (ca n Weblog-uri), pentru medierea ntlnirilor sau luarea deciziilor (ex. sisteme de argumentare precum QuestMap sau simple camere de discuii), ca sisteme de planificare sau ca platforme de e-learning. Dei web-ul a fost iniial caracterizat prin anonimitate, el a avut o orientare ctre web-ul social, n care utilizatorii i declin identitatea unei mici comuniti cu interese similare. Weblog-urile sau sistemele de filtrare colaborative precum friendster (http://friendster.com), care ofer posibilitatea de a gsi att obiecte de interes similare ct i persoane cu interese asemntoare, aparin acestei categorii de aplicaii. Aplicaiile web orientate pe portaluri ofer un singur punct de acces la surse de informaie i servicii separate/potenial eterogene. Realizatorii de browsere (Microsoft, Netscape), motoarele de cutare (Yahoo), serviciile online (AOL), conglomeratele media i alte companii au sesizat cererea existent pentru astfel de aplicaii i au oferit hub-uri centrale (aa numitele portaluri) ca punct de acces la web. Pe lng aceste portaluri generale, exist diverse portaluri specializate cum ar fi portalurile pentru afaceri, portalurile pentru comer (sub forma mall-urilor online) i portalurile pentru comuniti. Portalurile pentru afaceri ofer angajailor i/sau partenerilor afacerii un acces focalizat la diferite surse de informaie i servicii prin intranet sau extranet. Portalurile pentru comer sunt mprite n piee orizontale i verticale. Pieele orizontale funcioneaz pe piaa B2C oferind bunuri de consum direct ctre public, i n B2B, prin vnzarea de produse proprii unor companii din alte sectoare de activitate. Pieele verticale sunt formate de companiile dintr-un singur sector de activitate, cum ar fi furnizorii pe de o parte i productorii pe de alt parte. Portalurile pentru comuniti se adreseaz unor grupuri int specifice (de ex. tinerii) i ncearc s creeze o loialitate a clienilor prin intermediul interaciunilor cu utilizatorii sau s asigure oferte individuale printr-un management al utilizatorilor adecvat (marketing unu-la-unu). O categorie important este reprezentat de aplicaiile web omniprezente, care ofer servicii personalizate oricnd, oriunde i pentru orice dispozitiv, facilitnd astfel accesul peste tot. Un exemplu poate fi afiarea 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 lum n calcul limitrile dispozitivelor mobile (limea de band, dimensiunea ecranului, memoria, lipsa de maturitate a software-ului) i contextul n care aplicaia web este utilizat n mod curent. Dezvoltrile prezente i n special convergena sporit a industriei TIMES (telecomunicaii, tehnologia informaiei, multimedia, educaie i divertisment, securitate), vor conduce, n viitorul apropiat, la o situaie n care aplicaiile omniprezente vor domina piaa. Una dintre aceste dezvoltri este web-ul semantic, al crui 5

obiectiv este prezentarea informaiei pe web nu doar pentru oameni ci i ntr-o form care poate fi interpretat de sistemele de calcul[2]. Aceasta va facilita managementul cunotinelor pe web i n particular conectarea i reutilizarea cunotinelor (mediatizarea coninutului), dar i localizarea cunotinelor noi relevante (de exemplu cu ajutorul sistemelor de recomandare). Datorit interactivitii crescute la nivel semantic i posibilitii de automatizare a sarcinilor (prin intermediul agenilor inteligeni), putem afirma c web-ul va deveni mai rspndit i mai relevant n viaa 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 aplicaiilor web - Generaliti Aplicaiile web # aplicaiile tradiionale navigarea non-liniar frecvena actualizrilor Prezenta unei caracteristici- dependenta de tipul aplicatiei web> Aplicaiile web tranzacionale focalizare asupra actualizrii i consistenei coninutului Aplicaiile web difer de aplicaiile tradiionale (non-web), prin anumite caracteristici: unele lipsesc complet n aplicaiile tradiionale (de exemplu navigarea non-liniar), iar altele au o importan deosebit n cadrul aplicaiilor web (de exemplu frecvena actualizrilor). Dac i n ce msur este prezent o anumit caracteristic depinde parial de tipul de aplicaie web: dezvoltarea aplicaiilor web tranzacionale (cum ar fi sistemele de comer electronic) necesit o focalizare mai atent asupra actualizrii i consistenei coninutului comparativ cu sistemele informaionale pure (de exemplu expoziiile virtuale). Aceste caracteristici sunt motivul pentru care numeroase concepte, metode, tehnici i utilitare ale Ingineriei Software tradiionale trebuie adaptate la cerinele proiectrii web, dei n unele situaii acestea pot fi total neadecvate. Figura 1.2 prezint o imagine de ansamblu a acestor caracteristici, acestea fiind mprite pe trei dimensiuni: produs, utilizare i dezvoltare,evoluia lor fiind o dimensiune comun.

Dimensiunile conform cu standardul ISO/IEC 9126-1 pentru clasificarea caracteristicilor aplicaiilor 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 aplicaiilor web acestor dimensiuni putem observa influena acestora asupra calitii aplicaiilor i astfel s considerm caracteristicile ca un punct de pornire pentru definirea necesarului proiectrii web. Pe lng caracteristicile asociate produselor, utilizrii i dezvoltrii exist i evoluia ca o a patra dimensiune care guverneaz cele trei dimensiuni. Produsele trebuie s fie adaptabile, noul context informaional trebuie luat n considerare pe durata utilizrii, iar modalitile de dezvoltare vor modifica n mod continuu schimbrile care vor apare. n continuare, vom prezenta caracteristicile individuale conform acestor dimensiuni. Caracteristicile produselor coninut, 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 aplicaii web i constau n coninut, structur hipertextual (structur de navigare) i prezentare (interfaa utilizator). Conform paradigmei orientat-obiect, fiecare din aceste pri nu are doar aspecte structurale sau statice ci i aspecte comportamentale sau dinamice. Coninut Coninutul este regele - programatori i autori - Caracterul axat pe document i multimedia- coninutul este oferit sub forma tabelelor, textului, elementelor grafice, animaiilor, elementelor audio sau video Caracterul "axat pe document" n aplicaiile web - documentele sunt generate n mod adecvat pentru anumite grupuri de utilizatori - generat i actualizat dinamic - coninut multimedia - Cererile de calitate - actualitate, exactitate, consisten i ncredere > Siturile de tiri, personalizare, aplicaiile inteligente, contiente de locaie - calitatea superioar este necesar pentru preul i utilitatea informaiei n sistemele de cumprare online Coninutul Generarea coninutului, disponibilizarea acestuia, integrarea i actualizarea lui sunt la fel de importante precum dezvoltarea software-ului pentru o aplicaie web. Aplicaiile web sunt utilizate n special datorit coninutului pe care l ofer, fiind valabil motto-ul Coninutul este regele, iar dezvoltatorii lor trebuie s se comporte att ca programatori ct i ca autori. Aspectele importante sunt gradul variat al structurii coninutului i cererile de calitate fcute de utilizatori asupra coninutului. * Caracterul axat pe document i multimedia. n funcie de modul de structurare, coninutul este oferit sub forma tabelelor, textului, elementelor grafice, animaiilor, elementelor audio sau video. Caracterul "axat pe document" n aplicaiile web se refer la faptul c sunt generate documente care prezint informaia n mod adecvat pentru anumite grupuri de utilizatori (de exemplu informaii pentru turitii aflai n vacan ntr-o anumit regiune). Aceasta implic i anumite cerine speciale privitoare la uurina n folosire. Coninutul este ntr-o anumit proporie generat i actualizat dinamic (de exemplu numrul de camere disponibile ntr-un sistem informaional pentru turism). Mai mult, web-ul poate fi folosit ca infrastructur pentru transmiterea coninutului multimedia (de exemplu videoconferine sau aplicaii Real Audio). * Cererile de calitate. n funcie de domeniul aplicaiei, coninutul unei aplicaii web nu este supus doar actualizrilor cu o anumit frecven, ci i diferitelor msurtori de calitate privitoare la actualitate, exactitate, consisten i ncredere. Aceste cereri de calitate trebuie luate n considerare att la stabilirea cerinelor, ct i la evaluarea complianei cu aceste principii. Siturile de tiri, de exemplu, necesit o frecven sporit a actualizrilor i trebuie s fac fa cererilor utilizatorilor privind caracterul de ultim or al coninutului. Ca mediu de distribuire a informaiei, alturi de televiziune, radio i pres, web-ul ofer un potenial mult mai mare dect mijloacele de informare tradiional pentru adresarea acestor cereri, datorit personalizrii. Pe de alt parte, exist opinii conform crora aplicaiile 7

personalizate "inteligente" ("contiente" de locaie), necesit dezvoltarea unor noi genuri de aplicaii; motivul este acela c aplicaiile noi bazate pe coninut (ex. podcasting sau coninut mobil) sunt un mediu foarte diferit, greu de adaptat la coninutul existent. O calitate superioar este necesar ndeosebi pentru informaiile privind preul i disponibilitatea produselor n sistemele de cumprare online, acestea formnd baza tranzaciilor unei afaceri. Preurile incorecte pot duce la anularea vnzrii, iar informaiile vechi privind disponibilitatea pot conduce la incapacitatea de a vinde produsele din stoc sau la probleme de livrare deoarece produsele afiate drept disponibile nu exist n stoc. Indiferent de scopul cu care este utilizat o aplicaie web, calitatea coninutului este un factor esenial pentru acceptarea ei. Marea provocare o reprezint capacitatea de a garanta calitatea datelor n ciuda volumului mare i frecvenei crescute a actualizrilor. Hipertext - natura non-liniar a documentelor hipertextuale Elementele de baz ale modelelor hipertext nod - unitate de informaie unic identificat legtur - calea de la un nod la altul ancor - coninutul unui nod Non-liniaritatea - stereotipuri privind citirea sistematic relativ - indicat pentru dezvoltarea abilitii de nvare - Ancorele i legturile statice/dinamice Dezorientarea i supra-ncrcarea cognitiv - pierde poziia ntr-un document non-liniar - concentrarea suplimentar solicitat de memorarea simultan a diverselor ci sau sarcini > Hrile, cutarea prin cuvintele cheie, cile (modul history), afiarea timpului de accesare i a timpului petrecut pe sit, legturile pline de neles, folosirea abloanelor de proiectare Hipertext Una dintre caracteristicile specifice aplicaiilor web este natura non-liniar a documentelor hipertextuale. Paradigma hipertext, folosit ca baz pentru structurarea i prezentarea informaiei, a fost menionat pentru prima dat de Vannevar Bush. Elementele de baz ale modelelor hipertext sunt nodurile, legturile i ancorele. Un nod este o unitate de informaie unic identificabil, autonom. Pe web acesta poate fi un document HTML care poate fi accesat printr-un URL (Uniform Resource Locator). O legtur este calea de la un nod la altul. Pe web aceste ci sunt ntotdeauna unidirecionale, scopul acestora nefiind clar definit (poate fi urmtorul nod n acord cu ordinea de citire recomandat). O ancor este zona din coninutul unui nod care este sursa sau destinaia unei legturi (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. Trsturile eseniale ale paradigmei hipertext sunt non-liniaritatea coninutului produs de autori i a coninutul receptat de utilizatori, alturi de problemele poteniale de dezorientare i supra-ncrcare cognitiv. * Non-liniaritatea. Hipertextele implic stereotipuri privind citirea relativ sistematic, prin aceasta aplicaiile web difereniindu-se n mod evident de aplicaiile software tradiionale. Acest stil de citire individual, adaptabil la nevoile i comportamentul utilizatorilor, este cel mai potrivit pentru capacitatea de nvare uman. Utilizatorii se pot mica liberi n spaiul informaional, n funcie de interesele i cunotinele anterioare. Ancorele i legturile nu sunt doar predefinite n mod static de autori, ci pot fi generate dinamic ca o reacie predefinit la modelele de comportament al utilizatorilor. * Dezorientarea i supra-ncrcarea cognitiv. Este foarte important, n dezvoltarea aplicaiilor web, s facem fa acestor dou probleme fundamentale ale paradigmei hipertext. Dezorientarea reprezint tendina de a pierde direcia ntr-un document non-liniar. Supra-ncrcarea cognitiv este cauzat de concentrarea suplimentar necesar pentru memorarea simultan a diverselor ci sau sarcini. Hrile siturilor, cutrile prin intermediul cuvintelor cheie, urmrirea cilor (modul history) i afiarea timpului de accesare i a timpului petrecut pe sit ajut utilizatorii s-i pstreze orientarea n cadrul aplicaiei. Crearea unor legturi cu neles i denumirea inteligent a legturilor reduc supra-ncrcarea cognitiv. n plus, folosirea abloanelor de proiectare n modelarea aspectului hipertext poate ajuta la contracararea acestei probleme. 8

Prezentarea Estetica - look and feel - succesul sau eecul (e-comm) Auto-explicarea - utilizare, sistemul de navigare Prezentarea Dou trsturi speciale ale aplicaiilor web la nivelul prezentare (interfa utilizator) sunt estetica i auto-explicarea. Estetica. Spre deosebire de aplicaiile tradiionale, estetica nivelului prezentare al unei aplicaii web este un factorul important, i datorit presiunii competitive ridicate de pe web. Prezentarea vizual a paginilor web este supus tendinelor n mod i deseori determin succesul sau eecul, n special pentru aplicaiile de comer electronic. Auto-explicarea. Dincolo de estetic, este esenial ca aplicaiile web s fie auto-explicative: s fie posibil utilizarea aplicaiei web fr a consulta o documentaie n prealabil. Sistemul de navigare sau cel de interaciune trebuie s fie consecvent n ntreaga aplicaie, astfel nct utilizatorii s se poat familiariza rapid cu utilizarea aplicaiei web. Caracteristici asociate utilizrii - utilizarea aplicaiilor web este extrem de eterogen > utilizatorii - difer prin prisma numrului i culturii generale > dispozitivele - caracteristici hardware i software diferite Contextul social: utilizatorii Spontaneitatea - utilizatorul poate vizita i prsi o aplicaie web oricnd dorete, chiar dac este situl unui competitor. Multiculturalitatea - aplicaiile web sunt dezvoltate pentru diferite grupuri de utilizatori - abilitile (sau incapacitile), cunoaterea (expertiza aplicaiei) i preferinele (interesele). - personalizare adecvat- reduceri speciale (adaptarea contextului), ghid pentru aplicaia web (adaptarea hipertextului) , dimensiuni adecvate ale fontului (adaptarea prezentrii) ) Comparativ cu aplicaiile tradiionale, utilizarea aplicaiilor web este extrem de eterogen. Cultura general i numrul utilizatorilor variaz, dispozitivele folosite au caracteristici hardware i software diferite, iar ora i locaia de unde este accesat aplicaia nu pot fi prevzute. n plus, dezvoltatorii nu au posibilitatea de a cunoate dinainte poteniala diversitate a acestor factori contextuali i nu-i pot influena n nici un mod datorit naturii lor autonome. Prin urmare, utilizarea aplicaiilor web trebuie s se adapteze continuu la situaii de utilizare specifice (contexte). Adaptarea la aceste contexte poate fi necesar pentru toate prile aplicaiei web (coninut, hipertext i prezentare). Datorit semnificaiei adaptrii la contexte, caracteristicile asociate utilizrii sunt mprite n trei grupuri: contextul social, contextul tehnic i contextul natural. Contextul social: utilizatorii Contextul social se refer la aspecte specifice utilizatorului; spontaneitatea i multiculturalitatea n special creeaz un grad nalt de eterogenitate. Spontaneitatea. Utilizatorii pot vizita o aplicaie web i o pot prsi oricnd doresc - posibil pentru un sit competitor. Utilizatorul web nu trebuie s fie loial nici unui furnizor de coninut, web-ul fiind un mediu care nu atrage nici o obligaie. Deoarece gsirea unor aplicaii concurente este uor de realizat cu ajutorul motoarelor de cutare, utilizatorii vor utiliza o aplicaie web doar dac le va aduce un avantaj imediat. Multiculturalitatea. Aplicaiile web sunt dezvoltate pentru diferite grupuri de utilizatori. Dac grupul luat n discuie este cunoscut (poate fi cazul intranet-ului sau extranet-ului) situaia poate fi comparabil cu aplicaiile tradiionale. La dezvoltarea unei aplicaii web pentru un grup anonim de utilizatori, vor exista numeroase elemente eterogene greu de anticipat n ceea ce privete abilitile (ex. dizabiliti), cunotinele (ex. expertiza aplicaiei) i preferinele (ex. interesele). Pentru a permite o personalizare adecvat, ipotezele privind contextele utilizatorilor trebuie construite n stadiul de dezvoltare al aplicaiei web. Acest aspect va fi luat n considerare cnd se adapteaz componentele aplicaiei. Clienii obinuii pot beneficia de reduceri speciale (adaptarea coninutului), noii clieni pot primi un tur ghidat prin aplicaia web (adaptarea 9

hipertextului), iar utilizatorii cu deficiene vizuale pot fi ajutai prin folosirea unor dimensiuni adecvate ale fontului (adaptarea prezentrii). Personalizarea necesit deseori specificarea preferinelor utilizatorilor (de exemplu metoda preferat de plat pe http://www.amazon.com). Contextul tehnic: Reeaua i dispozitivele Calitatea serviciului. tehnic - aplicaiile web - principiul client/server > caracteristicile mediului de transmisie (limea de band, sigurana i stabilitatea conexiunii) limea maxim de band -ajustat pentru a optimiza cantitatea de date transferat dezvoltatorii trebuie s fac supoziii Distribuirea multi-plaform. Aplicaiile web ofer de obicei servicii nu doar unui anumit tip de dispozitiv browserele - nu implementeaz specificaiile presupuse utilizatorii pot configura browserele n mod autonom presupuneri privind clasele tipice de dispozitive Contextul tehnic: Reeaua i dispozitivele Contextul tehnic include proprieti legate de conexiunea n reea (privitoare la calitatea serviciului) i componentele hardware i software ale dispozitivelor utilizate pentru a accesa aplicaia web, pentru distribuirea multi-platform. Calitatea serviciului. Din punct de vedere tehnic, aplicaiile web sunt bazate pe principiul client/server. Caracteristicile mediului de transmisie, cum ar fi limea de band, sigurana i stabilitatea conexiunii sunt factori independeni care trebuie luai n considerare cnd dezvoltm o aplicaie web pentru a garanta o calitate adecvat a serviciului. De exemplu, parametrul lime de band maxim poate fi modificat pentru a optimiza cantitatea de date transferat, astfel nct coninutul multimedia (clipuri video) s poat fi transferat la o rezoluie sczut n situaia unei limi de band mici. n timp ce pentru aplicaiile tradiionale specificaiile reelei sunt cunoscute dinainte, dezvoltatorii aplicaiilor web trebuie s fac supoziii privitor la aceste proprieti. Datorit tendinei de orientare ctre aplicaiile web mobile, acest aspect are o importan sporit, reelele convergente necesitnd i mai mult adaptare la nivelul aplicaie. Distribuirea multi-plaform. Aplicaiile web ofer de obicei servicii nu doar unui anumit tip de dispozitiv ci i dispozitivelor mobile cu specificaii diferite (dimensiunea monitorului, capacitatea memoriei, software-ul instalat). Numrul mare de versiuni ale browserului reprezint i el o provocare datorit diferitelor funcionaliti i restricii ale acestora (deseori acestea nu implementeaz specificaiile presupuse). Acest lucru determin dificulti n crearea unei interfee utilizator consecvente i n testarea aplicaiilor 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 funcii ex. (cookies, caching) pot fi toate configurate individual, avnd astfel influene asupra performanei, funcionalitii tranzaciilor i posibilitilor de interaciune. Pe baza presupunerilor privind clasele tipice de dispozitive, dezvoltatorii aplicaiilor web pot adapta coninutul la PDA-uri (personal digital assistants) prin transmiterea legturilor 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: locaia si durata Globalitatea Locaia - important pentru internaionalizarea aplicaiilor web relativ la diferenele regionale, culturale i lingvistice. locaia fizic - utilizat mpreun cu modelele locaiei pentru a defini poziia logic >> a oferi servicii contiente de locaie. Disponibilitatea. Mecanismul de distribuire instantanee = natura web-ului 10

Contextul natural: locaia i timpul Contextul natural include aspecte privind locaia i timpul de accesare. Globalitatea i disponibilitatea creeaz un nivel nalt de eterogenitate. Globalitatea. Locaia din care o aplicaie web este accesat (poziia geografic) este important pentru internaionalizarea aplicaiilor web referitor la diferenele regionale, culturale i lingvistice. n plus, locaia fizic poate fi utilizat mpreun cu modelele locaiei pentru a defini o poziie logic (cum ar fi locul de reziden sau locul de munc) pentru a oferi servicii de localizare. Capacitatea de furnizare a informaiilor privind locaia determin dificulti suplimentare pentru testarea aplicaiilor web, deseori fiind dificil simularea locaiilor care se schimb i/sau testarea tuturor locaiilor posibile. Disponibilitatea global sporete de asemenea cererile privind securizarea aplicaiilor web pentru a preveni accesul deliberat sau accidental al utilizatorilor n zone private sau confideniale. Disponibilitatea. Mecanismul de distribuire instantanee inerent naturii web-ului face aplicaiile imediat disponibile. Aplicaiile web devin imediat utilizabile, de aceea calitatea produsului dezvoltat trebuie s fie garantat. Disponibilitatea permanent (24/7) sporete de asemenea preteniile privind stabilitatea aplicaiilor web. n plus, serviciile dependente de timp sunt posibile prin luarea n considerare a aspectului timp (de exemplu informaii privind programul ce depind de ora din zi i ziua din sptmn). Caracteristici asociate dezvoltrii Echipa de dezvoltare Caracterul multidisciplinar - combinaie ntre publicistica tiprit i dezvoltarea software, marketing i tiina calculatoarelor, art i tehnologie Disciplina dominant este dependent de tipul de aplicaie web Media de vrst sczut - dezvoltatori tineri i mai puin experimentai Dezvoltarea n comunitate - Dezvoltarea de software open-source disponibil gratuit pe web i integrarea acestuia n aplicaiile reale este un fenomen relativ recent. Dezvoltatorii folosesc acest software pentru crearea propriilor aplicaii, pe care le fac disponibile comunitii open source. Dezvoltarea aplicaiilor web implic existena resurselor necesare (echipa de dezvoltare i infrastructura tehnic), procesul de dezvoltare n sine i integrarea soluiilor deja existente. Echipa de dezvoltare Dezvoltarea aplicaiilor web este puternic influenat de faptul c echipele de dezvoltare sunt multidisciplinare i n general formate din tineri. Aceti factori i metodele comunitii de dezvoltare contribuie la apariia unui nou mod de organizare a colaborrii ntre diferite grupuri de dezvoltatori. Caracterul multidisciplinar. Aplicaiile web pot fi caracterizate ca o combinaie ntre publicistic i dezvoltarea software, marketing i tiina calculatoarelor, art i tehnologie. De aceea, dezvoltarea aplicaiilor web trebuie perceput ca o abordare multidisciplinar ce necesit cunotine i expertiz din diferite domenii. Pe lng experii IT responsabili de implementarea tehnic a sistemului, trebuie s fie angajai experi n hipertext i proiectani pentru proiectarea hipertextului i prezentrii, n timp ce experii n domeniu trebuie s fie responsabili pentru coninut. Se observ deci o varietate mai mare a competenelor i cunotinelor n echipa de dezvoltare fa de dezvoltarea software tradiional. Care disciplin va dominant depinde de tipul de aplicaie web. De exemplu, aplicaiile comer electronic sunt bazate mai mult pe baze de date tradiionale i expertiz n programare, n timp ce dezvoltarea unei expoziii virtuale va pune mai mult accent pe expertiza n domeniu i n proiectare. Media de vrst sczut. Dezvoltatorii de aplicaii web sunt n medie mult mai tineri i deci mai puin experimentai dect dezvoltatorii de software tradiional. Dezvoltarea n comunitate. Dezvoltarea de software open-source disponibil gratuit pe web i integrarea acestuia n aplicaiile reale este un fenomen relativ recent. Dezvoltatorii folosesc acest software pentru crearea propriilor aplicaii, pe care le fac disponibile comunitii open source. Infrastructura tehnic Eterogenitatea - dou componente externe: server i browser. Imaturitate - creterii presiunii de a ajunge pe pia Procese 11

 procesul de dezvoltare este influenat de flexibilitate i paralelism. Infrastructura tehnic Eterogenitatea i imaturitatea componentelor folosite sunt caracteristici importante ale infrastructurii tehnice a aplicaiilor web. Eterogenitatea. Dezvoltarea aplicaiilor web depinde de dou componente externe: server i browser. n timp ce serverul web poate fi configurat i folosit dup cum doresc programatorii aplicaiei, browserele web ale utilizatorilor i preferinele lor individuale nu pot fi influenate. Situaia este complicat i de diferitele versiuni de browser i interaciunea lor cu plugin-urile. Imaturitatea. Datorit creterii presiunii de a ajunge pe pia ct mai rapid, componentele utilizate n aplicaiile web sunt deseori imature - au bug-uri sau lipsuri n privina funcionalitii. Procesul Procesul de dezvoltare este influenat de flexibilitate i paralelism. - Flexibilitatea. n dezvoltarea aplicaiilor web aderarea la un plan de proiect rigid i predefinit este imposibil; o reacie flexibil la modificarea condiiilor este vital. - Paralelismul. Datorit necesitii de a dezvolta aplicaiile web ntr-un timp scurt i faptului c ele pot fi deseori mprite n componente autonome (de exemplu autentificare, funcie de cutare, notificarea tirilor), majoritatea aplicaiilor web sunt dezvoltate n paralel de diferite subgrupuri ale echipei de dezvoltare. Spre deosebire de dezvoltarea software-ului tradiional, aceste subgrupuri sunt structurate n funcie de componente i nu n funcie de expertiza membrilor proiectului (de exemplu dezvoltatori GUI, modelatori de date etc.). Integrarea Integrarea intern - aplicaiile web trebuie integrate cu sistemele de motenire existente cnd coninutul existent (de ex. cataloagele de produse) va fi fcut disponibil aplicaiei web Integrarea extern - Integrarea coninutului i a servicilor aplicaiilor web externe Integrarea intern. Aplicaiile web trebuie integrate frecvent cu sistemele de motenire existente cnd coninutul existent (de ex. cataloagele de produse) va fi fcut disponibil prin intermediul unei aplicaii web. Integrarea extern. Integrarea coninutului i a serviciilor aplicaiilor web externe reprezint o caracteristic special a aplicaiilor web. Dintre particularitile integrrii pe web menionm: - existena unui numr mare de surse care se schimb frecvent i au un grad nalt de autonomie n ceea ce privete disponibilitatea i evoluia schemei; - se cunosc puine detalii privitoare la proprietile acestor surse (ex. coninutul sau funcionalitile lor); - sursele diferite sunt adesea foarte eterogene la diverse nivele (nivelul datelor, schemei sau modelului de date). Integrarea serviciilor externe (de ex. n aplicaiile web orientate pe portaluri) se bazeaz pe forma de dezvoltare din ce n ce mai comun a furnizrii i utilizrii serviciilor web. n acest context, un serviciu web este o component reutilizabil cu o interfa i funcionalitate foarte clar definite. Interaciunea diferitelor servicii web, evitnd efectele secundare nedorite, i garantarea calitii serviciilor sunt cteva dintre problemele relevante ale acestui context. Evoluia Schimbarea continu = schimbare constant a cerinelor sau condiiilor - utilizatorii doresc ultimile aplicaii web; - instrumentele utilizate sunt condiionate de tehnologie Presiunea competiiei Ritmul rapid de dezvoltare - presiunea timpului Evoluia Evoluia este o caracteristic ce guverneaz toate cele trei dimensiuni: produsul, utilizarea i dezvoltarea. Nevoia de progres poate fi argumentat prin schimbarea continu a cerinelor i condiiilor, presiunea competiiei i ritmul rapid de dezvoltare. 12

Schimbarea continu Aplicaiile web se modific rapid i sunt n consecin ntr-o evoluie permanent datorit schimbrii constante a cerinelor sau condiiilor 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 aplicaiilor web la acestea. Aceast schimbare are dou cauze: - utilizatorii doresc cele mai noi aplicaii web; - instrumentele utilizate sunt condiionate de tehnologie. Schimbrile constante ale cerinelor i condiiilor reprezint o caracteristic esenial a aplicaiilor web, acestea putnd afecta toate cele trei dimensiuni ale unei aplicaii web produsul nsui, utilizarea acestuia i, n particular, dezvoltarea lui. Presiunea competiiei Presiunea competiiei extrem de ridicate de pe web, presiunea de lansare rapid pe pia i necesitatea unei prezene 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. Prezena imediat pe web este considerat mai important dect perspectiva pe termen lung. Ritmul rapid de dezvoltare Presiunea timpului n dezvoltarea aplicaiilor web se datoreaz schimbrilor rapide de pe web, ce duc scurtarea duratei de via a aplicaiilor web sau la actualizri frecvente. n timp ce n aplicaiile software tradiionale evoluia are loc sub forma seriilor planificate de versiuni, n aplicaiile web aceasta este continu. Aplicaiile web sunt ntr-o continu ntreinere, ciclul schimbrii fiind deseori de doar cteva zile sau sptmni.

Principalele aspecte abordate n continuare sunt prezentate n Figura 3. Principalele componente luate n discuie 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 "acoperiul", perspectiva de viitor. Principalele provocri ale proiectrii cerinelor aplicaiilor web includ: parteneri indisponibili, schimbarea dinamic a condiiilor, medii de aciune impredictibile, importana deosebit a calitii i frecventa lips de experien n utilizarea tehnologiilor. 13

Modelarea se refer la dezvoltarea aplicaiilor web pe baz de modele, cu focalizare asupra coninutului i hipertextului, i implic o dezvoltare de sus n jos. Este necesar o prezentare a metodelor existente pentru modelarea aplicaiilor web i a unor instrumente de modelare care s ajute proiectantul n alegerea metodei adecvate. Arhitectura este un factor decisiv pentru o aplicaie web de calitate. Performanele slabe, ntreinerea neadecvat i disponibilitatea redus se datoreaz deseori unei arhitecturi necorespunztoare. Folosirea arhitecturilor flexibile, pe mai multe nivele, oferirea unui coninut multimedia i integrarea aplicaiilor i depozitelor de date existente influeneaz pozitiv dezvoltarea aplicaiilor web. Proiectarea bazat pe tehnologie descrie alternativa dezvoltrii de jos n sus a aplicaiilor web. Proiectarea hipertext/hipermedia, a informaiei i a software-ului orientat-obiect nu ofer o soluie satisfctoare, fiind necesare abordri de proiectare specifice web-ului, cum ar fi: - proiectarea vizual, n care aspectul este hotrtor i n care se iau n considerare multiple interfee utilizator; - proiectarea interaciunii - a cilor de navigare i a "dialogului" cu componentele; - proiectarea funcional fixeaz esena aplicaiei web. Pe msur ce proiectarea fiecrui nivel devine mai concret, trebuie utilizate instrumente pentru proiectarea hipertext-ului, informaiei i software-ului. Tehnologiile au anumite caracteristici care trebuie cunoscute n detaliu, pentru a putea fi utilizate n etapa adecvat. Implementarea aplicaiilor web necesit o cunoatere aprofundat a diferitelor tehnologii i a interaciunii acestora cu o anumit arhitectur. Astfel, este necesar o prezentare a diferitelor tehnologii i o exemplificare a interaciunii i utilizrii lor mpreun cu anumite arhitecturi. Recomandrile consoriului web (W3C) necesit o atenie deosebit. Metodele actuale de testare se focalizeaz pe cerinele funcionale ale aplicaiilor web. Multe dintre cerinele de calitate non-funcionale importante pentru utilizatori (uurina n folosire, sigurana i securitatea) nu sunt luate n considerare suficient. Exploatarea i ntreinerea: multe sarcini care ar trebui rezolvate n timpul fazei de proiectare i dezvoltare sunt deseori amnate spre faza de exploatare i ntreinere, ceea ce crete i mai mult importan acestei etape. Exist de asemenea o tendin de a automatiza sarcinile ct timp sistemul este operaional. De exemplu, sarcini de rutin pentru ntreinerea coninutului sunt n mare msur automatizate, eliminndu-se astfel sursele de erori i garantnd o exploatare stabil. Uurina n folosire, performana i securitatea reprezint trei dintre aspectele de calitate ale aplicaiilor web. Uurina n folosire subliniaz faptul c aplicaiile web greu de utilizat nu sunt acceptate de ctre utilizatori. Noile dezvoltri precum aplicaiile web mobile i facilitile speciale pentru utilizatorii cu deficiene pun un accent deosebit pe uurina n folosire; aceasta nu poate fi dobndit ntr-o singur etap ci trebuie luat n considerare pe durata ntregului proces de dezvoltare. Performana implic folosirea unor metode, ncepnd cu cele de modelare pentru verificarea performanei i terminnd cu cele de msurare. Dintre metodele de modelare menionm modelele operaionale i modelele de simulare generale. Metodele de msurare necesit accesul la un sistem existent i au avantajul c sistemul poate fi urmrit n timp real. Dac sunt identificate probleme de performan prin msurare sau modelare, aceasta va trebui mbuntit prin extinderea hardware-ului, optimizarea software-ului, prin caching sau replicri. Securitatea implic abordarea unor probleme privind confidenialitatea datelor, prevenirea interceptrii mesajelor schimbate pe canalele accesibile public i oferirea unor servicii de ncredere. Web-ul social indic o form mbuntit a World Wide Web, susintorii lui sugernd 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. Generaii diferite de oameni i-au schimbat dramatic percepia 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 urmtorul pas logic n evoluia web-ului. Pentru a se realiza acest pas, n primul rnd, paginile web trebuie extinse (fie manual fie prin intermediul unor instrumente) cu etichete semantice, cu ajutorul crora paginile vor avea un coninut interpretabil de sistemele de calcul. n al doilea rnd, utilizatorii care caut informaia ar trebui s foloseasc ageni software inteligeni capabili s proceseze paginile web care au aceast facilitate. n cele din urm, productorii de coninut i agenii software trebuie s adopte un vocabular comun al conceptelor o ontologie. Web-ul semantic este nc la nceputuri, dar opinia general 14

este c acesta implic tehnologii promitoare care vor influena profund mediul de lucru al "lucrtorilor n domeniul cunoaterii".

Proiectarea cerinelor aplicaiilor web activiti care sunt critice pentru proiectarea web >Cerine incomplete, ambigue sau incorecte >Principii, metode i utilitarele pentru extragerea, descrierea, validarea i managementul cerinelor
Proiectarea cerinelor implic activiti care sunt eseniale pentru succesul proiectrii web. Cerine incomplete, ambigue sau incorecte pot conduce la dificulti majore n dezvoltare sau chiar la anularea proiectelor. Proiectarea cerinelor presupune luarea n discuie a principiilor, metodelor i utilitarelor pentru extragerea, stabilirea, descrierea, validarea i managementul cerinelor. Dei cerinele joac un rol cheie n dezvoltarea aplicaiilor web, ele sunt deseori descrise n mod neadecvat, consecinele tipice fiind acceptarea sczut din partea utilizatorilor, eecul planificrii sau arhitecturi software neadecvate. Exist un acord general privitor la importana cerinelor pentru dezvoltarea cu succes a sistemelor, de-a lungul anilor oferindu-se numeroase standarde, abordri, modele, limbaje de descriere i utilitare. n continuare vom discuta principiile proiectrii cerinelor pentru dezvoltarea aplicaiilor web i vom studia modul n care metodele existente de proiectare a cerinelor pot fi adaptate la particularitile proiectelor web. Obiectivele individuale i ateptrile prilor interesate Prile interesate pentru aplicaiile web - autorii de coninut, experii n domeniu, experi n caracterul utilizabil sau profesionitii n domeniul marketing-ului Obiective > constrngerea clientului, obiectiv de calitate a clientului, perspectiva tehnologic a dezvoltatorilor, obiectiv de calitate al utilizatorului, obiectiv de calitate al clientului, obiectiv al clientului privind uurina n folosire, obiectiv al utilizatorului privind capacitatea Obiectivele individuale i ateptrile prilor interesate reprezint punctul de pornire al procesului de stabilire a cerinelor. Prile interesate sunt oameni sau organizaii care au o influen direct sau indirect asupra cerinelor n dezvoltarea sistemului[1]. Pri interesate importante sunt clienii, utilizatorii i dezvoltatorii; cele tipice pentru aplicaiile web includ autorii de coninut, experii n anumite domenii, profesionitii n marketing sau n uurina n folosire. Obiectivele i ateptrile prilor interesate sunt de obicei diverse, dup cum demonstreaz i urmtoarele exemple: - aplicaia web trebuie s fie disponibil online pn la 1 septembrie 2009 (constrngere din partea clientului); - aplicaia web trebuie s suporte minim 2500 utilizatori concureni (obiectiv de calitate al clientului); - PHP trebuie folosit ca platform de dezvoltare (perspectiva tehnologic a dezvoltatorilor); - toate datele clienilor trebuie trimise securizat (obiectiv de calitate al utilizatorului); - interfaa utilizator trebuie s suporte layout-uri pentru diferite grupuri de clieni (obiectiv de calitate al clientului); - orice utilizator trebuie s poat gsi produsul dorit n mai puin de trei minute (obiectiv al clientului privind uurina n folosire); 15

- utilizatorul trebuie s aib posibilitatea s selecteze o iconi care s afieze articolele incluse n coul de cumprturi n orice moment (obiectiv al utilizatorului privind capacitatea). [1] Kotonya, G., Sommerville, I., Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998 Cerina - descrie o proprietate care trebuie ndeplinit sau un serviciu care trebuie furnizat de ctre un sistem. IEEE 610.12 definete o cerin ca: - o condiie sau aptitudine necesar unui utilizator pentru a rezolva o problem sau a ndeplini un obiectiv ; - o condiie sau capacitate care trebuie ndeplinit sau posedat de un sistem sau component a sa pentru a satisface un contract, un standard, o specificaie sau alte documente solicitate formal ; Identificarea i implicarea prilor interesate reprezint obiectivele principale ale managementului proiectului. O mare provocare o constituie nelegerea i aplanarea frecventelor conflicte privind obiectivele, ateptrile i ordinea de zi. De exemplu, pot exista conflicte ntre setul dorit de funcionaliti i bugetul disponibil; ntre setul de funcionaliti, programul proiectului i calitatea dorit; sau ntre tehnologia de dezvoltare dorit i aptitudinile i experienele dezvoltatorilor. nelegerea i rezolvarea din timp a acestor contradicii i conflicte este esenial i are o contribuie important la managementul riscului. Au fost propuse diferite tehnici de negociere pentru a susine acest obiectiv, dezvoltarea unei viziuni comune ntre prile interesate fiind o condiie pentru succes. Obiectivele prilor interesate sunt deseori reprezentate informal, oferind baza pentru cerinele derivate mai detaliate. O cerin descrie o proprietate care trebuie ndeplinit sau un serviciu care trebuie furnizat de ctre un sistem. IEEE 610.12 definete o cerin ca: - o condiie sau aptitudine necesar unui utilizator pentru a rezolva o problem sau a ndeplini un obiectiv; - o condiie sau capacitate care trebuie ndeplinit sau posedat de un sistem sau component a sa pentru a satisface un contract, un standard, o specificaie sau alte documente solicitate formal. Cerinele sunt clasificate deseori n cerine funcionale, cerine non-funcionale i constrngeri[1]. Cerinele funcionale definesc capacitile i serviciile unui sistem, iar cerinele non-funcionale descriu nivelele de calitate dorite (Ct este de securizat?, Ct este de uor de folosit?). Constrngerile sunt condiii nonnegociabile care afecteaz un proiect. Exemple de constrngeri sunt nivelul de calificare a echipei de dezvoltare, bugetul disponibil, data livrrii sau infrastructura de calculatoare existent n zona de dezvoltare. Toate cerinele i constrngerile dintre contractor i client sunt sintetizate ntr-un document. Abordrile uzitate n proiectarea cerinelor pun accentul pe identificarea i implicarea prilor interesate, negocierea i descoperirea cerinelor pe baz de scenarii, analizarea contextului organizaional i social anterior modelrii detaliate i definirea clar a constrngerilor 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. 99102 Proveniena cerinelor Cerine - funcionale non-funcionale constrngeri Cerinele sunt clasificate deseori n cerine funcionale, cerine non-funcionale i constrngeri[1]. Cerinele funcionale definesc capacitile i serviciile unui sistem, iar cerinele non-funcionale descriu nivelele de calitate dorite (Ct este de securizat?, Ct este de uor de folosit?). Constrngerile sunt condiii nonnegociabile care afecteaz un proiect. Exemple de constrngeri sunt nivelul de calificare a echipei de dezvoltare, bugetul disponibil, data livrrii sau infrastructura de calculatoare existent n zona de dezvoltare. Toate cerinele i constrngerile dintre contractor i client sunt sintetizate ntr-un document. 16

Abordrile uzitate n proiectarea cerinelor pun accentul pe identificarea i implicarea prilor interesate, negocierea i descoperirea cerinelor pe baz de scenarii, analizarea contextului organizaional i social anterior modelrii detaliate i definirea clar a constrngerilor care afecteaz dezvoltarea[1]. [1] Boehm, B. W., Requirements that Handle IKIWISI, COTS, and Rapid Change, IEEE Computer, 33 (7), July, 2000, pp. 99102 [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. 99102 Activitile proiectrii cerinelor Extragerea cerintelor i negocierea - rezultatul procesului de nvare i construirii pe baz de consens > metode i utilitare colaborative Documentarea cerintelor detaliere si formalism Verificarea cerintelor i validarea feedback-uri Managementul cerinelor

Proiectarea cerinelor implic extragerea, documentarea, verificarea i validarea, dar i managementul cerinelor pe parcursul procesului de dezvoltare. Extragerea cerinelor i negocierea Lowe i Eklund[1] au demonstrat c cerinele nu pot fi colectate prin ntrebri adecvate ci sunt rezultatul unui proces de nvare i de creare a unui consens. n acest proces comunicarea ntre prile interesate este esenial, doar punerea n comun a expertizei lor putnd duce la soluii acceptabile mutual. Un set larg de metode i utilitare de colaborare sunt disponibile pentru a facilita comunicarea i schimbul de informaii n proiectarea cerinelor: tehnici de creativitate, metode bazate pe scenarii, interviuri sau analiza documentelor. Documentarea cerinelor Dac prile interesate ajung la un consens, acordurile dintre acetia trebuie finisate i descrise ntr-un document al cerinelor, avnd un grad de detaliere i formalism adecvat contextului proiectului. Alegerea gradului adecvat de detaliere i formalism depinde de riscurile identificate ale proiectului i de experiena i aptitudinile presupuilor cititori. Descrierile informale precum relatrile utilizatorilor i cele semi-formale precum cazurile de utilizare sunt relevante pentru proiectarea web. Verificarea cerinelor i validarea Cerinele trebuie validate (S-au specificat cerinele corecte?) i verificate (S-au specificat corect cerinele?). Exist o serie de metode convenionale pentru acest scop (cum ar fi revizuirile, verificrile sau prototipizarea). n proiectarea web, deschiderea pe care o ofer Internetul faciliteaz noi forme de participare direct a utilizatorilor n validarea cerinelor (de exemplu prin colectarea online a feedback-urilor utilizatorilor)[2]. Managementul cerinelor Una dintre principalele caracteristici ale proiectelor web este modificarea continu a cerinelor i constrngerilor. Metodele i instrumentele folosite pentru managementul cerinelor suport att integrarea de noi cerine ct i modificarea celor existente; ele ajut i la evaluarea impactului acestor schimbri prin administrarea interdependenelor dintre cerine 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. 2336 [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. 317 Cerine specifice proiectrii web Caracterul multidisciplinar - experi multimedia, autorii de coninut, arhiteci software, experi n uurina de folosire, specialiti n baze de date sau experi ntr-un anumit domeniu 17

 Indisponibilitatea prilor interesate- potenialii utilizatori web, sunt necunoscui pe parcursul activitilor de proiectare a cerinelor Caracterul schimbtor al cerinelor i constrngerilor Mediul operaional imprevizibil- modificarea limii de band La suprafa, diferenele dintre proiectarea cerinelor pentru proiectarea web i proiectarea cerinelor pentru sistemele software tradiionale par a fi neglijabile. Dei exist multe diferene ntre dezvoltarea web i dezvoltarea software, exist i multe similariti (de exemplu extragerea cerinelor). n cele ce urmeaz vom insista pe diferenele dintre acestea, pe baza caracteristicilor aplicaiilor web prezentate n capitolul anterior. Caracterul multidisciplinar Dezvoltarea aplicaiilor web necesit participarea experilor din diferite discipline: experi multimedia, autori de coninut, arhiteci software, experi n uzabilitate, specialiti n baze de date sau experi ntr-un anumit domeniu. Eterogenitatea i caracterul multidisciplinar al prilor interesate fac dificil obinerea unui consens la definirea cerinelor, cu att mai mult cu ct oamenii din diferite discipline vorbesc limbi i jargoane diferite. Indisponibilitatea prilor interesate De multe ori prile interesate, (cum ar fi potenialii utilizatori web), sunt necunoscute pe parcursul activitilor de proiectare a cerinelor. Managementul proiectului trebuie s gseasc reprezentani potrivii care s ofere cerine ct mai realiste. De exemplu, deseori exist un spectru larg de posibili utilizatori n proiectele web i gsirea unui grup de reprezentani adecvai este dificil. Caracterul schimbtor al cerinelor i constrngerilor Cerinele i constrngerile (ex. proprietile platformelor de lucru sau protocoalele de comunicaie) sunt adesea mai uor de definit pentru sistemele software tradiionale comparativ cu aplicaiile web. Aplicaiile web i mediul n care acestea funcioneaz sunt extrem de dinamice, din acest motiv cerinele i constrngerile fiind greu de stabilizat. Cele mai frecvente exemple de astfel de schimbri sunt inovaiile tehnologice cum ar fi introducerea de noi platforme i standarde de dezvoltare sau noi dispozitive pentru utilizatorii finali. Mediul operaional imprevizibil Mediul operaional al unei aplicaii web este de asemenea foarte dinamic i greu de anticipat. Pentru dezvoltatori este dificil sau chiar imposibil s controleze factori importani, decisivi pentru calitatea aplicaiei web perceput de utilizator. De exemplu, modificarea limii de band afecteaz timpul de rspuns pentru aplicaiile mobile dar acest lucru nu depinde de echipa de dezvoltare. Impactul sistemelor de motenire - integrarea componentelor software existente cum ar fi produsele comerciale autonome sau software-ul open source Importana aspectelor calitative - performana unei aplicaii web, securitatea n sistemele de ecommerce, disponibilitatea sau uurina n folosire Impactul sistemelor de motenire Dezvoltarea aplicaiilor 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 motenire, de exemplu atunci cnd vor s fac accesibile pe web sistemele IT existente ntr-o companie. Dezvoltatorii sunt deseori ndemnai s utilizeze componentele existente i din motive economice. Componentele care trebuie integrate influeneaz cerinele i arhitectura viitorului sistem. n aceste situaii o abordare n cascad n care arhitectura sistemului deriv din cerine nu va avea succes, deoarece componentele, infrastructura i serviciile existente stabilesc o serie de posibiliti i limitri pentru dezvoltatori (atunci cnd se identific i definesc cerinele, dezvoltatorii web trebuie s fie contieni de arhitectura sistemului i de constrngerile arhitecturale. O abordare iterativ precum cea propus de modelul Twin Peaks este mai adecvat ntr-un asemenea context (vezi figura). Importana aspectelor calitative Aspectele calitative sunt decisive pentru succesul aplicaiilor web. Exemple: performana unei aplicaii web, securitatea n sistemele de e-commerce, disponibilitatea, uurina n folosire. n ciuda importanei aspectelor calitative, dezvoltatorii trebuie s se confrunte cu faptul c specificarea exact a cerinelor de calitate este 18

dificil naintea construirii sistemului. De exemplu timpul de rspuns al unei aplicaii web depinde de muli factori, care nu pot fi controlai de echipa de dezvoltare. O abordare realizabil pentru definirea cerinelor de calitate implic specificarea criteriilor pentru testul de acceptare, specificnd dac o cerin a fost ndeplinit sau nu. (vezi de asemenea un exemplu al unui criteriu de acceptare pentru o cerin a calitii n tabelul 2-1). Atribut ID Tip Descriere Raionament Criteriu de acceptare Exemplu 1.2.5 Uurina n nvare Aplicaia web X trebuie s fie utilizabil de utilizatori web ocazionali, fr o instruire prealabil Managerii de marketing sunt utilizatori frecveni ai sistemului 90% din membrii unui grup-test (selectat aleator) de utilizatori web ocazionali pot folosi Cazurile de Utilizare 2.3, 2.6 i 2.9 fr o instruire preliminar Foarte important; greu de implementat 2.3.4, 2.3.6

Prioritate Cerine dependente

Cerine contradictorii 4.5.6 Informaii adiionale Istoricul versiunii Recomandri privind uurina n folosire v1.2 1.06

Specificaii de formatare Comentariu Identificator unic Element din taxonomia cerinei O explicaie scurt n limbaj natural Explic de ce este important cerina O condiie msurabil care trebuie ndeplinit pentru acceptare O expresie a importanei i fezabilitii cerinei Lista cerinelor care depind de aceast cerin Lista cerinelor care sunt n conflict cu aceast cerin Trimiteri la informaii adiionale Un numr al reviziei pentru a documenta istoricul dezvoltrii Calitatea interfeei utilizator - adugarea unor prototipuri pentru scenariile importante ale aplicaiei Calitatea coninutului - acurateea, obiectivitatea, credibilitatea, relevana, actualitatea, caracterul complet sau claritatea CMS Lipsa de experien a dezvoltatorilor tehnologii de baz din aplicaiile web relativ noi Date fixe de livrare - termen limit > negocierea i stabilirea unei ordini de prioritate a cerinelor Calitatea interfeei utilizator Calitatea interfeei utilizator este un alt aspect hotrtor pentru succesul aplicaiilor web. Cnd realizeaz aplicaii web dezvoltatorii trebuie s fie contieni de urmtorul fenomen: utilizatorii nu vor fi capabili s neleag i s aprecieze o aplicaie web uitndu-se la modele i specificaii abstracte; ei trebuie s experimenteze. De aceea, este foarte important s se completeze definirea i descrierea cerinelor prin adugarea unor prototipuri pentru scenariile importante ale aplicaiei[1]. Calitatea coninutului Majoritatea metodelor tradiionale de proiectare a cerinelor neglijeaz coninutul web, dei este un aspect extrem de important al aplicaiilor web. Pe lng problemele legate de tehnologia software, dezvoltatorii 19

trebuie s aib n vedere coninutul i n special crearea i ntreinerea acestuia. n contextul proiectrii cerinelor este esenial specificarea nivelul dorit de calitate a coninutului. Cele mai importante caracteristici de calitate includ acurateea, obiectivitatea, credibilitatea, relevana, actualitatea, caracterul complet sau claritatea. Sistemele de management al coninutului (CMS) au devenit importante i permit reprezentarea concis i consistent a coninutului prin separarea coninutului de layout i oferirea utilitarelor de editare a coninutului. Lipsa de experien a dezvoltatorilor Majoritatea tehnologiilor de baz din aplicaiile web sunt relativ noi. Lipsa de experien cu instrumentele de dezvoltare, standardele i limbajele acestor tehnologii pot conduce la estimri greite cnd se ia n discuie fezabilitatea i costul implementrii cerinelor. Datele fixe de livrare Multe proiecte web au o dat fix de livrare, toate activitile i deciziile trebuind s fie finalizate pn la un termen limit. Negocierea i stabilirea unei ordini de prioritate a cerinelor sunt eseniale n aceste condiii. [1] Constantine, L., Lockwood, L., Software for Use: A Practical Guide to Models and Methods for UsageCentered Design, ACM Press, 2001 Principii pentru proiectarea cerinelor aplicaiilor web Principiile deriv din stabilitatea modelului n spiral win-win nelegerea contextului sistemului - obiectivele afacerii clientului Implicarea prilor interesate - cooperarea acestora activ i direct pentru identificarea i negocierea cerinelor, situaii ctig-pierdere conduc adesea la situaii pierdere-pierdere n aceast seciune vom descrie principiile de baz ale proiectrii cerinelor pentru aplicaiile web. Aceste principii deriv din stabilitatea modelului n spiral n care ctig toi partenerii (modelul win-win), un model de ciclu de via iterativ i orientat pe risc care pune accentul pe implicarea prilor interesate i pe extragerea i punerea de acord asupra cerinelor. Modelul n spiral win-win a influenat multe modele bazate pe procese, inclusiv Procesul Unificat Raional (RUP) de la IBM. Dezvoltatorii web trebuie s aib n vedere urmtoarele principii pe parcursul activitilor de proiectare a cerinelor: nelegerea contextului sistemului Multe aplicaii web sunt nc dezvoltate ca soluii tehnice izolate, fr o nelegere a rolului i impactului acestora ntr-un context general. O aplicaie web nu poate fi o finalitate prin ea nsi; ea trebuie s in cont de obiectivele afacerii clientului. Pentru ca aplicaia web s aib succes este important s clarificm 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 neleag modul n care sistemul este implementat n mediul su. Analiza afacerii poate stabili valoarea unei aplicaii web n raport cu resursele pe care le utilizeaz cerinele. nelegerea contextului sistemului ajut i la identificarea prilor interesate, familiarizarea cu scopul aplicaiei i analizarea constrngerilor[1]. Implicarea prilor interesate Prile interesate sau reprezentanii lor se afl n centrul proiectrii cerinelor, iar cooperarea acestora activ i direct pentru identificarea i negocierea cerinelor este important pentru fiecare faz a proiectului. Managerii de proiect trebuie s evite situaiile n care participanii la proiecte individuale ctig pe seama altora. S-a demonstrat c asemenea situaii ctig-pierdere evolueaz adesea n situaii pierdere-pierdere, determinnd n final eecul ntregului proiect. Obiectivele, ateptrile i cerinele prilor interesate trebuie stabilite i negociate n mod repetat pentru a se adapta schimbrilor dinamice care apar n proiecte. Anterior am artat c indisponibilitatea prilor interesate i caracterul multidisciplinar sunt specifice proiectrii cerinelor pentru ingineria web. Aceste caracteristici conduc la stabilirea urmtoarelor cerine pentru contextul aplicaiilor web: identificarea prilor interesate sau a reprezentanilor acestora nelegerea obiectivelor i ateptrilor prilor interesate negocierea perspectivelor, experienelor i cunotinelor (caracter multidisciplinar). 20

Metodele i utilitarele de proiectare a cerinelor trebuie s fie n concordan cu aceste cerine i trebuie s contribuie la schimbul efectiv de cunotine dintre participanii la proiect, s permit un proces de instruire n echip, dezvoltarea unei viziuni comune a prilor interesate i s ajute la detectarea din timp a cerinelor contradictorii. [1] Biffl, S., Aurum, A., Boehm, B. W., Erdogmus, H., Grunbacher, P., Value-based Software Engineering, Springer-Verlag, September 2005 Definirea iterativ a cerinelor - n concordan cu alte rezultate ale dezvoltrii (arhitectur, interfa utilizator, coninut, cazuri de testare etc.); abordare iterativ - necesar n special ntr-un mediu n care cerinele i constrngerile sunt schimbtoare Focalizarea pe arhitectura sistemului - inelegerea soluiilor tehnice mpreun cu posibilitile i limitrile lor sunt eseniale Riscuri - problemele nedetectate, cele nerezolvate i conflictele dintre cerine; Diminuarea riscului prototipizarea, lansarea rapid a unor versiuni ale aplicaiei web pentru a colecta feedback-ul utilizatorilor sau ncorporarea precoce a componentelor externe pentru a elimina problemele majore ale integrrii tardive. Definirea iterativ a cerinelor Abordarea n cascad a definirii cerinelor nu funcioneaz n medii dinamice, iar cerinele trebuie dobndite n mod iterativ n dezvoltarea aplicaiilor web. Cerinele trebuie s fie n concordan cu alte rezultate ale dezvoltrii (arhitectur, interfa utilizator, coninut, cazuri de testare etc.). La iniierea proiectului, cerinele cheie sunt de obicei definite la un nivel nalt de abstractizare. Aceste cerine preliminare pot fi utilizate pentru a dezvolta arhitecturi fezabile, scenarii de utilizare a sistemului i planurile iniiale ale proiectului. Pe msur ce proiectul progreseaz rezultatele dezvoltrii pot fi perfecionate gradat prin specificarea unor termeni mai concrei, asigurnd n continuare consistena lor. O abordare iterativ este necesar, n special ntr-un mediu n care cerinele i constrngerile sunt schimbtoare, pentru a putea reaciona ntr-un mod flexibil pe msur ce proiectul evolueaz. Dac echipa de dezvoltare primete termeni limit fici, atunci o abordare de dezvoltare iterativ permite selectarea cerinelor cheie care trebuie implementate primele. Focalizarea pe arhitectura sistemului Tehnologiile existente i soluiile de motenire au un impact sporit asupra cerinelor aplicaiilor web. nelegerea soluiilor tehnice mpreun cu posibilitile i limitrile lor este esenial. Extragerea cerinelor nu poate avea loc fr a se ine seama de arhitectur, n special la definirea cerinelor. Luarea n considerare a arhitecturii sistemului permite dezvoltatorilor s neleag mai bine impactul soluiilor existente asupra cerinelor i s estimeze fezabilitatea acestora. Modelul Twin-Peaks (vezi figura) propune att perfecionarea cerinelor ct i a arhitecturii sistemului ntr-o manier iterativ, sporind continuu nivelul de detaliere. Riscuri Problemele nedetectate, cele nerezolvate i conflictele dintre cerine reprezint riscuri majore ale proiectului. Problemele obinuite de risc sunt integrarea componentelor existente n aplicaia web, anticiparea aspectelor de calitate a sistemului sau lipsa de experien a dezvoltatorilor. De aceea evaluarea riscului trebuie realizat pentru toate cerinele, iar riscurile identificate trebuie controlate pe parcursul proiectului, pentru a ne asigura c nu sunt urmate alternativele riscante pentru sistem. Diminuarea riscului trebuie realizat ct mai devreme posibil, putnd include de exemplu prototipizarea, lansarea rapid a unor versiuni ale aplicaiei web pentru a colecta feedback-ul utilizatorilor sau ncorporarea precoce a componentelor externe pentru a evita problemele majore ale integrrii tardive. Adaptarea metodelor de proiectare a cerinelor dezvoltrii aplicaiilor web Ce tipuri de cerine sunt importante pentru aplicaia web? - Cum vor fi descrise i documentate cerinele pentru aplicaia 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? 21

n prezent sunt disponibile numeroase metode, ghiduri, notaii, cataloage i utilitare pentru toate activitile de proiectare a cerinelor. Totui, dezvoltatorii trebuie s evite o abordare unitar, metodele de proiectare a cerinelor trebuind adaptate permanent specificului proiectrii web i situaiilor care apar n anumite proiecte. Principiile descrise anterior ne conduc la definirea unei abordri de proiectare a cerinelor specific proiectelor pentru web. Dezvoltatorii trebuie s clarifice urmtoarele aspecte pe parcursul procesului de adaptare: - Ce tipuri de cerine sunt importante pentru aplicaia web? - Cum vor fi descrise i documentate cerinele pentru aplicaia 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 cerine Cerinele funcionale - capacitile i serviciile pe care un sistem ar trebui s le ofere - transferul de bani > scenariile de tip utilizare de caz (use case) i specificaiile de formatare Cerine privind coninutul - specific coninutul care trebuie s-l prezinte aplicaia web Cerine privind calitatea - nivelul calitii serviciilor Funcionalitatea - prezena funciilor > concordana, precizia, interoperabilitatea, compliana i securitatea Sigurana - meninere nivel de performan > maturitatea, tolerana la erori i capacitatea de recuperare Uurina n folosire - efortul necesar pentru a utiliza un produs software > uurina n nelegere, nvare i operare Eficiena - raportul dintre nivelul de performan i resursele utilizate > comportamentul n timp, comportamentul resurselor ntreinerea - efortul pentru a implementa modificri 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 Organizaiile de standardizare i cele comerciale au dezvoltat un numr mare de taxonomii pentru definirea i clasificarea diferitelor tipuri de cerine (de exemplu Volere[1] sau IEEE 830-1998). Majoritatea taxonomiilor fac distincie ntre cerinele funcionale i cele non-funcionale. Cerinele funcionale descriu capacitile i serviciile unui sistem (de exemplu Utilizatorul poate selecta o iconi pentru a vizualiza articolele din coul de cumprturi n orice moment.). Cerinele non-funcionale descriu proprietile capacitilor i nivelul dorit al serviciilor (de exemplu Aplicaia web va suporta cel puin 2500 de utilizatori concureni.). Alte cerine non-funcionale se refer la constrngerile proiectului i interfeele sistemului. n continuare vom discuta pe scurt tipurile de cerine relevante pentru proiectele de dezvoltare web: Cerine funcionale Cerinele funcionale specific capacitile i serviciile pe care un sistem ar trebui s le ofere (de exemplu transferul de bani ntr-o aplicaie de online banking). Cerinele funcionale sunt frecvent descrise utiliznd scenariile de utilizare de caz i specificaiile de formatare[2]. Cerine privind coninutul Cerinele privind coninutul specific coninutul care ar trebui prezentat de aplicaia web. Coninutul poate fi descris, de exemplu, sub forma unui glosar. Cerine privind calitatea Cerinele privind calitatea descriu nivelul de calitate al serviciilor i capacitilor i specific proprieti importante ale sistemului cum ar fi securitatea, performana sau uurina n folosire[3]. Standardul internaional ISO/IEC 9126 definete un model independent de tehnologie pentru calitatea softului, care cuprinde 6 caracteristici de calitate, fiecare avnd propriile trsturi. Cele ase caracteristici sunt: Funcionalitatea descrie prezena funciilor care ndeplinesc proprietile definite. Trsturi le sunt concordana, precizia, interoperabilitatea, compliana i securitatea. 22

 Sigurana descrie capacitatea unui produs software de a-i menine nivelul de performan n anumite condiii pe o perioad definit de timp. Trsturile sunt maturitatea, tolerana la erori i capacitatea de recuperare. Uurina n folosire descrie efortul necesar pentru a utiliza un produs software i evaluarea sa individual de ctre un grup de utilizatori definit sau presupus. Trsturi: uurina n nelegere, nvare i operare. Eficiena - descrie raportul ntre nivelul de performan al unui produs software i resursele pe care acesta le utilizeaz n anumite condiii. Trsturi: comportamentul n timp, comportamentul resurselor. ntreinerea descrie efortul necesar pentru a implementa modificri prestabilite ntr-un produs software. Trsturi: posibilitatea de analiz, schimbare, stabilitate i testare. Portabilitatea descrie capacitatea unui produs software de a fi mutat dintr-un mediu n altul. Trsturi: capacitatea de adaptare, instalare, potrivire i nlocuire. Au fost fcute diverse ncercri de ctre cercettori pentru a extinde acest model de baz la caracteristicile specifice web-ului. n capitolele ulterioare vom insista asupra uurinei n folosire, performanei i securitii, care reprezint aspecte de calitate eseniale pentru succesul aplicaiilor web. [1] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999 [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 Cerinele mediului sistem - modul n care o aplicaie web este inclus n mediul int i interacioneaz cu componentele externe - hardware Cerinele interfeei utilizator - ghidarea intuitiv i autoexplicativ a utilizatorilor - hipertextul (structura de navigare proces de modelare) i prezentarea (interfaa utilizator) > prototipuri Cerine posibile pe parcursul dezvoltrii - anticipare cerine care ar putea apare dup folosirea pe termen scurt a aplicaiei (utilizatori concurenti - arhitecturi a sistemului scalabile) Constrngerile proiectului - bugetul i planul, limitrile tehnice, standardele, tehnologia de dezvoltare folosit Cerinele mediului sistemului Aceste cerine descriu modul n care o aplicaie web este inclus n mediul int i interacioneaz cu componentele externe, incluznd de exemplu sistemele de motenire, componentele comerciale autonome sau un hardware special. De exemplu, dac o aplicaie web se presupune c va fi disponibil global, atunci n cerinele de mediu trebuie s se specifice detaliile. Cerinele interfeei utilizator Deoarece se presupune c utilizatorii web folosesc aplicaia web fr o instruire formal, ghidarea intuitiv i auto-explicativ a utilizatorilor este esenial pentru acceptarea aplicaiei. Cerinele privitoare la interfaa utilizator definesc modul n care o aplicaie web interacioneaz cu diferite tipuri de clase de utilizatori. Principalele aspecte sunt hipertextul (structura de navigare) i prezentarea (interfaa utilizator). Detaliile de navigare i prezentare sunt definite n mod normal n procesul de modelare, dar deciziile iniiale privind proiectarea interfeei utilizator trebuie luate pe parcursul extragerii cerinelor. Prototipurile sunt cele mai potrivite n aceast situaie. 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/mbuntirea iterativ a modelelor pentru roluri, sarcini i interaciuni[1]. Cerine posibile pe parcursul dezvoltrii Produsele software n general i aplicaiile web n particular sunt subiectul unei evoluii i mbuntiri continue. Din acest motiv dezvoltatorii web trebuie s anticipeze cerinele care ar putea apare dup folosirea planificat pe termen scurt a aplicaiei. De exemplu, o cerin de calitate care solicit suplimentarea cu 5000 de utilizatori concureni n doi ani trebuie avut n vedere, prin definirea unei arhitecturi a sistemului scalabile. Cerinele ce pot aprea n evoluie sunt posibile pentru toate tipurile de cerine discutate (de exemplu capacitile viitoare, cerinele de securitate viitoare). Constrngerile proiectului 23

Constrngerile proiectului nu sunt negociabile pentru prile interesate ale proiectului i includ de obicei bugetul i planul, limitrile tehnice, standardele, tehnologia de dezvoltare folosit, regulile de desfurare, aspectele de ntreinere, constrngerile operaionale i aspectele legale sau culturale care afecteaz proiectul. [1] Constantine, L., Lockwood, L., Software for Use: A Practical Guide to Models and Methods for UsageCentered Design, ACM Press, 2001 Notaii Relatrile - descrieri colocviale ale proprietilor dorite > exemplu de scenariu Cerinele specificate - simple specificaii n limbajul natural Specificaiile de formatare - sintax precis definit, dar permit i descrieri n limbajul natural. Exemple: descrierile de utilizare de caz din UML Specificaiile formale - scrise ntr-un limbaj care utilizeaz o sintax i semantic definite formal Sunt disponibile variate notaii pentru specificarea cerinelor la diferite nivele de detaliere i formalitate. Exemple: relatri, specificaii de formatare, specificaii formale. Relatrile Relatrile - sunt descrieri colocviale ale proprietilor dorite; ele sunt utilizate pentru a stabili o nelegere ntre clieni i dezvoltatori. Exemple: relatrile utilizatorilor din Extreme Programming[1]. Relatarea unui utilizator este formulat de ctre 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 urmtorul: Un utilizator verific produsele adugate n coul de cumprturi online. Datele de intrare sunt validate atunci cnd utilizatorul face clic pe <Continuare>. Dac nu sunt gsite erori comanda va fi acceptat i va fi trimis utilizatorului o confirmare prin e-mail. Cerinele specificate Cerinele specificate sunt simple specificaii 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. Specificaiile de formatare Specificaiile de formatare utilizeaz o sintax precis definit, dar permit i descrieri n limbajul natural. Exemple: descrierile de utilizare de caz din UML (Unied Modeling Language), RDD-100 Requirements Specication Language, ghidurile MBASE SSRD sau Volere Shell. Tabelul 2.1 prezint un exemplu al unei specificaii de formatare, principalele atribute fiind: descriere, prioritate, raionament i istoricul versiunii. Fiecare cerin este identificat individual i poate fi referit pe parcursul procesului n orice moment utiliznd un ID unic. Interdependenele cu alte cerine i rezultate ale dezvoltrii (cum ar fi documentele sau planurile arhitecturii) sunt reinute pentru a susine trasabilitatea. Cazurile de utilizare UML sunt utile pentru a descrie cerinele funcionale. Un caz de utilizare descrie o funcie a sistemului din perspectiva actorilor acestuia i conduce la un rezultat perceptibil de ctre actori. Un actor este o entitate extern sistemului care interacioneaz cu sistemul. O diagram de utilizare de caz prezint relaiile dintre cazurile de utilizare i actori. Diagramele de utilizare de caz sunt utile pentru a ilustra dependenele strnse dintre cazurile de utilizare i actori; detaliile cazului de utilizare sunt definite n specificaiile de formatare. Atributele descriu numrul i numele cazului de utilizare, actorii implicai, condiiile anterioare i posterioare, evoluia, excepiile i erorile, variaiile, sursa, raionamentul sau interdependenele cu alte diagrame UML. Specificaiile formale Specificaiile formale sunt scrise ntr-un limbaj care utilizeaz o sintax i semantic definite formal. Cel mai bun exemplu este Z (ISO/IEC13,568:2002). Specificaiile formale sunt rar utilizate pentru aplicaiile web. Oportunitatea Tabelul anterior compar diferite notaii n ceea ce privete precizia atributelor, uurina validrii, raportul eficacitate-cost, folosirea de ctre non-experi i scalabilitatea. O precizie minim-medie va fi suficient pentru specificarea cerinelor aplicaiei web, iar o validare formal nu este cerut de obicei. Este important s pstrm sczut efortul de extragere i management al cerinelor, iar aceste cerine s fie nelese i de ctre non-experi. 24

Scalabilitatea este o problem pus pe seama complexitii ridicate a multor aplicaii web. n tabelul anterior putem observa c formele de descrieri informale i semi-formale (relatrile, listele de cerine i specificaiile de formatare) sunt adecvate n special pentru aplicaiile web. [1] Beck, K., Extreme Programming Explained, Addison-Wesley, 2000 Utilitare Extragerea cerinelor - EasyWinWin Validarea cerinelor - sistemele de rspuns online (feedback) Managementul cerinelor - managementul tuturor cerinelor ce aparin unui proiect ntr-un depozit central - http://www.paper-review.com/tools/rms/read.php Utilitare Exist numeroase categorii de utilitare care folosesc activitile de proiectare a cerinelor descrise. Utilitare existente pentru proiectarea cerinelor nu sunt limitate la aplicaiile web, dar pot fi adaptate la specificul dezvoltrii aplicaiilor web. Extragerea cerinelor Metode 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 dobndire i negociere a cerinelor. EasyWinWin denete un set de activiti ale unui proces de negociere, un moderator ndrumnd partenerii pe parcursul ntregului proces. Aceast abordare utilizeaz tehnici de ncurajare a grupurilor de lucru, care sunt susinute de utilitare colaborative (brainstorming electronic, clasificri, sisteme de votare, etc.). Aceste activiti sunt: revizuirea i extinderea subiectelor de negociere, ..intereselor partenerilor; convergena spre condiiile de ctig, extragerea unui vocabular de termeni comuni, stabilirea nivelului de prioritate pentru condiiile de ctig, evidenierea problemelor i constrngerilor, identificarea problemelor i opiunilor i negocierea acordurilor. Validarea cerinelor Datorit caracterului deschis al Internetului sistemele de rspuns online (feedback) pot completa sau chiar nlocui metode costisitoare (ntlniri sau interviuri) pentru validarea cerinelor aplicaiei web. De exemplu, utilizatorii Internetului pot fi invitai s participe la sondaje pe web pentru a comunica gradul lor de mulumire fa de o aplicaie web. Remarcm n acest context c datorit spontaneitii comportamentului interactiv deseori nu putem observa o aprobare sau o negare ci doar indiferen. Dac unui utilizator i place aplicaia web o va utiliza, dar va fi reticent la trimiterea unui feedback (de exemplu informaii privind erorile gsite) pentru a contribui la dezvoltarea i mbuntirea aplicaiei. Managementul cerinelor Utilitarele pentru managementul cerinelor permit managementul tuturor cerinelor ce aparin unui proiect ntr-un depozit central. Spre deosebire de sistemele de procesare a textului, utilitarele de management al cerinelor stocheaz cerinele ntr-o baz de date. Asemenea specificaiilor de formatare, atributele relevante sunt administrate pentru fiecare din aceste cerine (vezi tabelul ). Sistemele de management al cerinelor sunt importante pentru managementul modificrilor i cerinelor. O trecere n revist a utilitarelor existente poate fi gsit la http://www.paper-review.com/tools/rms/read.php .

Modelare
Obiecte. Clase 25

 obiect - entitate care are identitate, stare si comportament clasa - descriere a unei multimi de obiecte care au aceleasi caracteristici structurale si comportamentale 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 data Un 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 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 26

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) Diagrama de plasare {Deployment Diagram) Diagrama cazurilor de utilizare ( Use Case Diagram)

27

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

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?

Notatia grafica pentru relatia de dependenta de tip include

Notatia grafica pentru relatia de dependenta de tip extend

29

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 generalizare Relatia 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 extend Relatia 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.

Relatii Relatiile pot fi de mai multe tipuri: asociere, dependents si generalizare Relatia 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 asociere se reprezinta grafic printr-o linie si este evidentiata in figura 7.5. Relatia de dependenta Se poate stabili numai intre use-case-uri. Relatiile de dependenta pot fi de doua tipuri: include si extend. Dependenta de tip include Notatie 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 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 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. Figura 7.8 ilustreaza notatia grafica pentru relatia de generalizare intre use case-uri. 30

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

31

Nume - prin care se distinge de alte clase Atribute - numele unei proprietati a clasei Operatii (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 clase Este 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. Clase Elementele 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

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 aplicaiilor web

alternativ mai bun fa de dezvoltarea ad-hoc a aplicaiilor web 32

 Modelele - punct de pornire pentru implementarea aplicaiilor web, innd cont de aspectele statice i dinamice ale nivelelor de coninut, hipertext i prezentare ale unei aplicaii web Includerea informaiilor contextuale (precum utilizatorul, ora, locaia i dispozitivul utilizat) i adaptarea aplicaiei web derivat din aceast informaie Dei n prezent nu este folosit frecvent n practic, modelarea aplicaiilor web reprezint o alternativ mai bun fa de dezvoltarea ad-hoc a aplicaiilor web i problemele sale inerente. Modelele reprezint un punct de pornire important pentru implementarea aplicaiilor web, avnd n vedere aspectele statice i dinamice ale nivelelor de coninut, hipertext i prezentare ale unei aplicaii web. n timp ce modelul coninutului unei aplicaii web (care tinde s surprind informaia i logica aplicaiei) este similar modelului corespondent al unei aplicaii non-web , modelarea hipertextului este o particularitate a aplicaiilor web. Modelul hipertext descrie toate posibilitile de navigare pe baza coninutului. Modelul prezentare mapeaz structurile hipertext cu paginile i legturile dintre acestea, n acest mod reprezentndu-se interfaa grafic utilizator. Includerea informaiilor contextuale (precum utilizatorul, ora, locaia i dispozitivul utilizat) i adaptarea aplicaiei web derivat din aceast informaie necesit o atenie deosebit n procesul de modelare. Vom prezenta n continuare metodele i utilitarele disponibile pentru modelarea aplicaiilor 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 utilizrii diferiilor clieni web i platforme de lucru. dezvoltarea aplicaiilor web complexe - abordare sistematic i o specificare a aplicaiei web care trebuie construit sub forma modelelor vizuale Modelarea - furnizarea de specificaii 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 aplicaiilor web complexe este necesar o abordare sistematic i o specificare a aplicaiei 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 specificaii 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.

Nivele Obiectele, atributele i relaiile cu alte obiecte Interfaa utilizator ce i cum se va realiza Logica aplicaiei Faze Structur Comportament funcii i procese Aspecte
Figura 3.1 Cerine pentru modelarea aplicaiilor software

Analiz Proiectare Implementare

33

Modelarea a fost utilizat i n tiina calculatoarelor pentru dezvoltarea software-ului. n acest domeniu, obiectul modelrii este aplicaia care va fi creat. Figura urmtoare (vezi Figura 3.1) demonstreaz c orizontul modelrii acoper trei dimensiuni ortogonale. Prima dimensiune cuprinde nivelul logic al aplicaiei i nivelul interfeei utilizator n sensul ncapsulrii a ce i cum se va realiza ntr-o aplicaie. Structura (obiectele, atributele lor i relaiile cu alte obiecte) i comportamentul (funciile i procesele) aparin logicii aplicaiei i interfeei utilizator i formeaz o alt dimensiune. Deoarece o aplicaie nu poate fi dezvoltat imediat, fiind necesar o rafinare i o extindere progresiv pe parcursul procesului de dezvoltare, fazele dezvoltrii formeaz o a treia dimensiune a modelrii aplicaiei. Prin rafinamente succesive, cerinele identificate n etapa de analiz a cerinelor sunt transformate la nceput n modele de analiz i ulterior n modele de proiectare, pe baza crora se va realiza implementarea. Originile modelrii - regsi n proiectarea datelor i n proiectarea software-ului (abordarea orientatobiect) modelare orientat-obiect - abordarea holistic a modelrii 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 desfurare) diagrame de comportament (diagrame de utilizare de caz, diagramele de stri -state machine-, diagramele de activitate) Originile modelrii le putem regsi n Proiectarea datelor i n Proiectarea software-ului. Modelarea din Proiectarea datelor se focalizeaz pe aspectele structurale (datele) unei aplicaii, obiectivul major fiind identificarea entitilor, gruparea acestora i relaiile dintre ele. n acest sens cel mai cunoscut este modelul entitate-relaie (ER)[1]. n schimb, modelarea n Proiectarea software pune accentul pe aspectele comportamentale, pentru ndeplinirea cerinelor limbajelor de programare i n prezent se bazeaz n principal pe abordarea orientat-obiect. Cele mai importante caracteristici ale modelrii orientate-obiect sunt abordarea holistic a modelrii 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 majoritii metodelor de modelare pentru aplicaiile 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 desfurare) i diagrame de comportament (diagramele de utilizare de caz, diagramele de stri, diagramele de activitate). [1] Chen, P., The Entity-RelationshipModel Toward a Unified View of Data, ACM Transactions on Database Systems, 1976, pp. 936 [2] OMG (Object Management Group), UML 2.0 Superstructure Specification Revised Final Adopted Specification, 2004, http://www.omg.org Caracteristicile modelrii n proiectarea web - abordarea aplicaiilor web innd cont de cele trei dimensiuni specificate anterior: nivele, aspecte i faze - accentul variaz n funcie de tipul aplicaiei web - focalizarea se va face asupra structurii de prezentare uniforme a paginilor - modelarea hipertext trebuie s se bazeze pe abloane de navigare recurente - Relevana structurii i comportamentului modelelor depinde de tipul de aplicaie web care va fi implementat

34

Nivele Prezentare Hipertext Coninut Faze Structur Analiz Proiectare Implementare Personalizare

Comportament Aspecte
Figura 3.2 Cerinele modelrii aplicaiilor web Abordrile de modelare specifice aplicaiilor web au fost dezvoltate n special n ultimii ani i permit abordarea aplicaiilor web innd cont de cele trei dimensiuni specificate anterior: nivele, aspecte i faze. Nivele Pentru a modela aplicaiile web trebuie luate n considerare caracterul orientat pe document al coninutului acestora i navigarea hipertext non-liniar din cadrul lor. Din acest motiv se pot distinge trei nivele ale modelrii aplicaiilor web (vezi Figura 3.2) spre deosebire de cele dou nivele utilizate n metodele de modelare pentru aplicaiile tradiionale. Cele trei nivele sunt coninutul (informaia i logica aplicaiei care stau la baza aplicaiei web), hipertextul (structurarea coninutului n noduri i legturile dintre ele) i prezentarea (interfaa utilizator sau layout-ul paginii). Majoritatea metodelor utilizate pentru a modela aplicaii 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. 227263 O separare clar ntre aceste nivele permite reutilizarea i ajut la reducerea complexitii. De exemplu, putem specifica un anumit numr de structuri hipertext diferite care vor acorda atenia cuvenit cerinelor specifice ale diferitelor grupuri de utilizatori i dispozitivelor utilizate pentru un anumit coninut. Obiectivul modelrii coninutului este definirea explicit a structurii informaiei; similar cu schema unei baze de date din modelarea datelor, aceasta elimin redundana (structura informaiei va rmne neschimbat, chiar dac informaia nsi se schimb frecvent). Pentru a proiecta o navigare eficient coninutul poate fi oferit n mod redundant pe diferite noduri la nivel hipertext. Coninutul este modelat o singur dat (n modelarea coninutului) iar modelul structurii hipertext realizeaz doar o referin la coninutul corespunztor. n acest mod utilizatorii pot gsi aceast informaie pe diverse ci de acces. Pentru a preveni rtcirea utilizatorilor n timpul navigrii i pentru a pstra stresul cognitiv asupra acestora ct mai sczut, modelarea hipertext trebuie s se bazeze pe abloane de navigare recurente. n ceea ce privete modelarea la nivel de prezentare, focalizarea se va face pe o structur de prezentare uniform a paginilor, pentru obinerea unui efect de recunoatere a brandului aplicaiei web printre utilizatorii si. Dei aspectul vizual al unei aplicaii web este important, aspectele estetice nu fac parte din obiectivele majore ale modelrii. n ciuda separrii intereselor i a obiectivelor diferite n cadrul celor trei nivele, putem stabili o coresponden ntre acestea. Pentru realizarea acestui lucru trebuie definite explicit interdependenele dintre nivele. De exemplu, diferite ci de acces hipertext personalizate pot fi mapate ntr-un singur model de coninut. Un model comprehensiv al unei aplicaii web include toate cele trei nivele discutate, dar accentul variaz n funcie de tipul aplicaiei web. Aplicaiile web care furnizeaz o interfa utilizator pur orientat-hipertext pentru un set mare de date, vor necesita focalizarea modelrii pe coninut i structura hipertextului. n contrast, aplicaiile 35

web orientate pe prezentare (ex. portalurile corporative sau magazinele de cumprturi online) vor avea cereri mai mari n ceea ce privete modelarea prezentrii. Aspecte Conform principiilor orientate obiect, structura i comportamentul sunt modelate la fiecare din cele trei nivele (coninut, hipertext i prezentare). Relevana modelelor structurii i comportamentului depinde de tipul de aplicaie web care va fi implementat. Aplicaiile web care conin n principal informaie static necesit o modelare a comportamentului mai redus comparativ cu aplicaiile web interactive (ex. aplicaiile de comer electronic care ofer motoare de cutare, funcii pentru ordine de cumprare etc.). n ceea ce privete 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 modelrii pentru dezvoltarea aplicaiilor web. n toate cazurile secvena de pai pentru modelarea nivelelor trebuie stabilit de ctre modelator. n funcie de tipul aplicaiei web se poate folosi o abordare bazat pe informaie (pornirea de la modelarea coninutului) sau o abordare bazat pe prezentare (pornirea de la modelarea aspectelor de prezentare a aplicaiei). Dezvoltarea bazat pe modele n proiectarea web este contradictorie cu practicile ntlnite n proiectele web (ex. cicluri de dezvoltare cu via scurt i necesitatea unor metode rapide). Abordarea bazat pe modele ofer n schimb posibilitatea specificrii comprehensive a unui model al soluiei i, dac este disponibil un utilitar de caz adecvat, posibilitatea generrii automate a prototipului aplicaiei web. Personalizarea Includerea informaiilor de context n dezvoltarea aplicaiilor web are un rol semnificativ, permind personalizarea, distribuirea multi-platform i serviciile bazate pe locaie. Personalizarea se refer la context (ex. preferinele utilizatorilor, caracteristicile dispozitivelor sau restriciile privind limea de band) i permite adaptarea aplicaiei web n funcie de acesta. Personalizarea influeneaz toate cele trei dimensiuni ale modelrii web (coninut, hipertext i prezentare) n ceea ce privete structura i comportamentul i trebuie luat n considerare n toate fazele procesului de dezvoltare. n consecin, managementul informaiei contextuale este tratat ca o dimensiune de modelare independent. Dei 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 aplicaii web bazat pe UML, cunoscut sub numele de UWE (Proiectare web bazat pe UML UML based Web Engineering). Cerinele modelrii Cazurile de utilizare - tehnica de modelare adecvat cerinelor funcionale deoarece ele pot fi reprezentate n mod grafic >> set de cazuri de utilizare care descriu cerinele aplicaiei web din perspectiva actorilor (indivizi i alte sisteme) suplimentate de diagrame de activitate UML pentru a descrie cerinele funcionale n detaliu Se pot utiliza diverse tehnici pentru a identifica, analiza, descrie, evalua i administra cerinele aplicaiilor web. Cazurile de utilizare reprezint tehnica de modelare adecvat pentru cerinele funcionale, deoarece ele pot fi reprezentate n mod grafic. Funcionalitatea n ansamblu a unei aplicaii web este modelat ca un set de cazuri de utilizare care descriu cerinele aplicaiei web din perspectiva actorilor (persoane i alte sisteme). Mai mult, cazurile de utilizare pot fi suplimentate de diagrame de activitate UML pentru a descrie cerinele funcionale mai detaliat. O particularitate a cerinelor aplicaiilor web este funcionalitatea navigrii, care permite utilizatorului s navigheze prin hipertext i s gseasc nodurile. n acest sens, se recomand separarea cazurilor de utilizare funcionale de cele navigaionale, prin crearea a dou modele distincte. O alt abordare (UWE) implic crearea unui singur model de caz de utilizare care folosete stereotipul UML <<navigation>> pentru a indica diferena ntre cazurile de utilizare funcionale i cele specifice hipertextului.

36

Figura 3.3: Diagram de utilizare de caz pentru un sistem de recenzie Toate aplicaiile web au cel puin un utilizator uman, de cele mai multe ori anonim. n exemplul urmtor, 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 (recenzeni) i preedintele comitetului de organizare (preedintele 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. Cerinele navigaionale care suplimenteaz cerinele funcionale sunt evideniate 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

37

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 cnd cele de utilizare de caz se solicit o logic a aplicaiei 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 isnt 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 Screen Condition. 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 coninutului Informaia furnizat de o aplicaie web - unul din cei mai importani factori pentru succesul acelei aplicaii, n principal datorit originii web-ului ca un mediu informaional - modelare pur a datelor - suficient n pentru aplicaiile web statice - aplicaiile web complexe - solicit n plus modelarea aspectelor comportamentale Informaia oferit de o aplicaie web este unul din cei mai importani factori pentru succesul acelei aplicaii, datorit originii web-ului ca un mediu informaional. Modelarea coninutului n sensul de modelare pur a datelor este suficient n mod normal pentru aplicaiile web statice. Aplicaiile web complexe solicit n plus modelarea aspectelor comportamentale. Astfel, modelarea coninutului va include crearea modelului domeniului problemei, ce const n aspectele statice i dinamice, dup cum se cunoate din Proiectarea software clasic. n plus trebuie luate n considerare urmtoarele caracteristici ale aplicaiilor web: - Caracterul axat pe document i multimedia: la modelarea coninutului trebuie luate n considerare toate tipurile de formate media, inclusiv structurile pe care se bazeaz informaia. - Integrarea datelor i software-ului existent: multe aplicaii web sunt construite folosind depozite de date i componente software existente, care nu au fost create iniial pentru aplicaiile web. Modelarea coninutului trebuie s satisfac dou obiective potenial contradictorii: trebuie s ndeplineasc ct mai bine posibil cerinele de coninut ale aplicaiei web i trebuie s includ structurile de date i componentele software existente. 38

 urmrete transferarea informaiei i cerinelor funcionale, stabilite prin proiectarea cerinelor, ntrun model Modelarea coninutului produce un model care include att aspectele structurale ale coninutului (sub forma diagramelor de clas) ct i n funcie de tipul aplicaiei web - aspectele comportamentale (sub forma diagramelor de stare i interaciune). Modelarea coninutului urmrete transferarea informaiei i cerinelor funcionale, stabilite prin proiectarea cerinelor, ntr-un model. Caracterul hipertext al unei aplicaii web i cerinele prezentrii acesteia nu vor fi luate n considerare. Modelarea coninutului produce un model care include att aspectele structurale ale coninutului (ex. sub forma unei diagrame de clas) ct i n funcie de tipul aplicaiei web - aspectele comportamentale (ex. sub forma diagramelor de stare i interaciune).

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 menionat 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 recenzeni. Invariantul de stare ataat la clasa Articol ne asigur ca autorii nu vor putea s-i revizuiasc propriile articole. Aceast diagram de clas va servi ulterior drept baz pentru modelarea hipertextului i a prezentrii pentru aplicaia 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 39

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 Im arguably making design decisions in my model, something I shouldnt 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 Id 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. IndicatorMeaning 0..1 Zero or one 1 One only 0..* Zero or more 1..* One or more n 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 strile articolului Figura 3.6 reprezint o diagram de stare (state machine diagram), utilizat pentru a modela diverse stri ale articolului n sistemul de recenzare. Un articol trimis va fi preluat de trei recenzeni 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 anunai prin e-mail despre rezultatul recenzrii. 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 statetransition 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 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

40

 poate fi realizat prin utilizarea structurilor de acces adecvate opiuni de navigare pentru eliminarea riscului de rtcire a utilizatorilor i de supunere la un stress cognitiv excesiv specificarea navigabilitii n coninutul aplicaiei web (cile de navigare disponibile utilizatorilor). produce modelul structurii hipertext rafineaz modelul de structur hipertext Non-liniaritatea hipertextului este una din cele mai importante proprieti de care trebuie inut cont la modelarea aplicaiilor web. Din acest motiv structura hipertext trebuie proiectat cu atenie. Aceasta se poate realiza prin utilizarea unor structuri de acces adecvate (opiuni de navigare) pentru evitarea riscului de rtcire a utilizatorilor sau de a-i supune la un stres cognitiv excesiv. Obiective Obiectivul modelrii hipertext (cunoscut i ca modelarea navigrii) este specificarea navigabilitii n coninutul aplicaiei web (cile de navigare disponibile utilizatorilor). Modelarea hipertext genereaz un rezultat dublu: n primul rnd produce modelul structurii hipertext (modelul structurii de navigare) care definete structura hipertextului, respectiv ce clase ale modelului de coninut pot fi vizitate prin navigare. n al doilea rnd, 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 aplicaii web nu este n mod normal reprezentat explicit, deoarece ofer foarte puine informaii adiionale pentru dezvoltator.
<<legatura navigare>> 1 <<legatura navigare>> 1 1 <<legatura navigare>> * articole acceptate * <<clasa navigare>> Articol articole respinse * * <<legatura navigare>> * <<clasa navigare>> Recenzie <<legatura navigare>> * <<legatura navigare>> * 1..* <<clasa navigare>> Utilizator <<clasa navigare>> Conferinta 1 <<legatura navigare>>

<<legatura navigare>>

Figura 3.7 Model de structur hipertext a perspectivei preedintelui comitetului de organizare asupra sistemului de recenzie Modelarea structurii hipertext se bazeaz pe conceptele hipertext (noduri pagini sau documente i legturi ntre aceste noduri) Spre deosebire de nivelul coninutului, pentru care sunt utilizate diagramele ER sau diagramele de clas, pentru modelarea structurii hipertext sunt folosite notaii specifice. Modelarea structurii hipertext se bazeaz pe conceptele hipertext (noduri pagini sau documente i legturi ntre aceste noduri). Punctul de plecare folosit pentru crearea modelului structurii hipertext este de obicei modelul de coninut care conine clasele i obiectele care vor fi disponibile ca noduri n hipertext. Deseori modelul de structur hipertext este specificat ca o perspectiv a modelului de coninut, fiind uneori numit perspectiv navigaional. Astfel, un nod este specificat ca o perspectiv a modelului de coninut, selectnd unul sau mai multe obiecte din 41

coninut. Unele metode modeleaz structura hipertext indiferent de modelul de coninut. 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 cerinelor de navigare identificate de aceste scenarii. n sistemul de recenzie folosit ca exemplu perspectiva hipertext este necesar pentru urmtoarele roluri ale utilizatorilor: autor, recenzent i preedintele comitetului de organizare. Figura 3.7 ilustreaz modelul de structur hipertext din perspectiva preedintelui comitetului de organizare. Preedintele poate vizualiza toate articolele trimise, poate accesa lista de articole acceptate sau respinse i profilurile recenzenilor. 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 coninut. Legturile sunt modelate prin asocieri directe cu stereotipul <<legtura de navigare>>. Modelarea hipertextului - tipuri de legturi metoda HDM (Hypertext Design Model) Legturile structurale conecteaz elementele aceluiai nod (de la rezumatul recenziei la detaliile recenziei) Legturile de perspectiv plaseaz diferite perspective ale unui nod n relaie cu altele (versiunile PostScript i PDF) Legturile aplicaiei plaseaz noduri diferite n relaie unul cu altul n funcie de aplicaie (legtur cel mai bun articol) metoda WebML (Web Modeling Language) legturi contextuale transmit informaia contextual (numrul unic al recenzentului) legturi noncontextuale nu au asociate informaii de context (legturi care duc de la o recenzie singular la lista tuturor recenziilor) legturi intra-pagin sunt utilizate cnd sursa i destinaia legturii aparin aceleiai pagini (direct la rezumatul articolului, care este afiat n partea de jos) legturi inter-pagini sunt utilizate cnd sursa i destinaia se afl pe pagini diferite (informaii detaliate despre autori i articolele lor) n literatura de specialitate distingem tipuri de legturi folosite pentru rafinarea ulterioar a semanticii modelului structurii hipertext. De exemplu metoda HDM (Hypertext Design Model) specific urmtoarele tipuri de legturi: - Legturile structurale conecteaz elementele aceluiai nod (de exemplu de la rezumatul recenziei la detaliile recenziei) - Legturile de perspectiv plaseaz diferite perspective ale unui nod n relaie cu altele (de exemplu versiunile PostScript i PDF ale unui articol). - Legturile aplicaiei plaseaz noduri diferite n relaie unul cu altul n funcie de aplicaie (de exemplu o legtur care trimite la cel mai bun articol). Alte clasificri se bazeaz pe posibilul transport al informaiei pe parcursul navigrii. De exemplu metoda WebML (Web Modeling Language) specific urmtoarele tipuri de legturi: - legturi contextuale transmit informaia contextual (de exemplu numrul unic al recenzentului pentru a naviga de la un recenzent la recenzia pe care el a creat-o) - legturi noncontextuale nu au asociate informaii de context (de exemplu legturi care duc de la o recenzie singular la lista tuturor recenziilor) - legturi intra-pagin sunt utilizate cnd sursa i destinaia legturii aparin aceleiai pagini (de exemplu cnd o legtur permite utilizatorului s navigheze direct la rezumatul articolului, care este afiat n partea de jos a paginii); - legturi inter-pagini sunt utilizate cnd sursa i destinaia se afl pe pagini diferite (de exemplu cnd informaii detaliate despre autori i articolele lor se gsesc pe pagini diferite). metoda de modelare UWE legturi de navigare sunt utilizate pentru a naviga ntre noduri (legturi ntre articole i autorii acestora) 42

 legturile procesului indic nodul de nceput al unui proces (spre nceputul procesului de trimitere a recenziei) legturile externe indic un nod care nu aparine n mod direct aplicaiei (spre ghidurile de formatare) Pe baza cerinelor funcionale ale aplicaiilor web, metoda de modelare UWE definete urmtoarele tipuri de legturi: - legturi de navigare sunt utilizate pentru a naviga ntre noduri (de exemplu legturi ntre articole i autorii acestora) - legturile procesului indic nodul de nceput al unui proces (de exemplu spre nceputul procesului de trimitere a recenziei) - legturile externe indic un nod care nu aparine n mod direct aplicaiei (de exemplu spre ghidurile de formatare stabilite de editorul lucrrilor conferinei, care nu sunt stocate direct n sistemul de recenzie). Modelarea Accesului 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 ctre un nod ce poate fi accesat de la toate nodurile Modelul structurii hipertext construit pn 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 ctre noduri este necesar sprijinul n navigare i orientare. Acestea se regsesc 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 cretere semnificativ a calitii modelului hipertext. n sistemul de recenzie, dac cineva dorete s navigheze de la un recenzent la un articol asociat acestuia, trebuie s identifice acest articol pe parcursul navigrii. De exemplu, acest lucru se poate realiza sub forma unei liste care afieaz 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 coninut) 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 secvenial printr-un anumit numr 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 aplicaiei web i punctul de reper care trimite ctre un nod ce poate fi accesat de la toate nodurile. O parte din structurile de acces prezentate pot fi adugate modelului de structur hipertext n mod automat. De exemplu indecii pot fi adugai automat oricnd dorim s permitem accesul la un set (mai mare dect unul) de obiecte ale unui nod.

43

<<clasa navigare>> Conferinta recenzii <<index>> Articole acceptate <<index>> Articole respinse Articole acceptate Articole respinse <<meniu>> Meniu Conferinta articol e <<meniu>> Meniu Articol cauta articole <<interogare>> Cauta articol dupa titlu <<index>> Articole in functie de titlu * * <<index>> Stare Recenzie <<index>> Recenzii * <<clasa navigare>> Recenzie * * <<clasa navigare>> Articol <<meniu>> Meniu Articol * utilizatori <<index>> Index Utilizator toate articolele * <<clasa navigare>> Utilizator * <<index>> Articole in functie de ID

<<index>> Articole trimise

recenz ii

autori

<<index>> Autori

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 preedintelui comitetului de organizare specificat n modelul de structur hipertext al sistemului de recenzie. De notat c multiplicitatea implicit a legturilor este 1. Preedintele comitetului de organizare are acces la toate articolele, recenziile i utilizatorii. Pentru a accesa un articol anume este utilizat un numr unic. Preedintele comitetului de organizare poate cuta un articol n funcie de titlu. UWE folosete stereotipuri UML cum ar fi: <<meniu>> (exemplu conferin), <<index>> ( exemplu starea recenziei) , interogare (exemplu cutare dup titlul articolului) i <<turul organizat>> pentru specificarea structurilor de acces meniu, index, interogare i tur organizat. Modelarea prezentrii trateaz interfaa utilizator i necesit prezentarea aspectului unei aplicaii web. Spre deosebire de aplicaiile tradiionale elementul central al prezentrii din aplicaiile web este pagina ca unitate de vizualizare realizat n momentul proiectrii structurii i comportamentului interfeei utilizator pentru a asigura interaciunea cu aplicaia 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 interfeei utilizator (de exemplu pe ce buton se va executa clic pentru a activa o funcie din logica aplicaiei) acordarea unui sistem de ajutor pentru orientarea utilizatorilor la nivelul prezentrii - afiarea cii de navigare curente sau a paginilor vizitate pe parcursul sesiunii active proiectarea grafic a layout-ului pentru interfaa utilizator - grafician 44

Similar cu modelarea software clasic, modelarea prezentrii trateaz interfaa utilizator i necesit prezentarea aspectului unei aplicaii web. Spre deosebire de aplicaiile tradiionale elementul central al prezentrii din aplicaiile web este pagina ca unitate de vizualizare. Modelarea prezentrii este realizat n momentul proiectrii structurii i comportamentului interfeei utilizator pentru a asigura interaciunea cu aplicaia web ntr-un mod simplu i auto-explicativ. n plus, se ine cont de aspectele de comunicare i de reprezentare ale aplicaiei web. Modelarea prezentrii genereaz un rezultat dublu: n primul rnd produce un concept de prezentare uniform prin modelarea elementelor recurente din pagini (de exemplu antete i subsoluri de pagin). Modelarea prezentrii ar trebui n mod ideal s afieze structura fiecrei pagini i proiectarea cmpurilor textelor, imaginilor, formularelor etc., incluse n aceste pagini. n al doilea rnd, pe lng structura paginilor modelul de prezentare descrie aspecte comportamentale ale interfeei utilizator (de exemplu pe ce buton se va executa clic pentru a activa o funcie din logica aplicaiei). Datorit diversitii mari a opiunilor de navigare i riscului inerent al rtcirii utilizatorilor, trebuie avut n vedere acordarea unui sistem de ajutor pentru orientarea utilizatorilor la nivelul prezentrii. Aceasta poate fi realizat, de exemplu, prin afiarea cii de navigare curente sau a paginilor vizitate pe parcursul sesiunii active. Nu toate metodele disponibile pentru modelarea aplicaiilor web suport concepte de modelare a prezentrii 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 aplicaiile web este proiectarea grafic a layout-ului pentru interfaa utilizator, care deseori este realizat de un grafician pe baza unor schie 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 informaii ale nodului

<<text>> ID Articol

<<text>> Data de trimitere

<<colectie de ancore>> Autori

<<text>> Nume

<<text>> <<pagina>> Titlu Pagina articolului <<unitatea de prezentare>> Articol <<text>> Rezumat <<ancora>> Versiune PDF <<buton>> Introdu Recenzie

<<text>> <<pagina>> <<unitatea de prezentare>> Afiliere Pagina articolului Autor <<unitatea de prezentare>> Lista Autori <<text>> E-mail <<buton>> Introdu Schimbari

<<colectie de ancore>> Autori

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 uniti de prezentare. - O unitate de prezentare este util pentru gruparea elementelor interfeei utilizator i reprezint un fragment logic al paginii. Prezint un nod ce deriv din modelul hipertext. 45

- Un element de prezentare este blocul de baz al modelului prezentare. Elementele de prezentare sunt un set de informaii ale nodului i pot include text, imagini, audio etc. Putem vizualiza structura paginilor de prezentare pe baza reprezentrii unei diagrame de clas UML imbricate cunoscut sub numele de structur, aa 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 unitile 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 cmpurile aferente, o legtur ctre versiunea complet a articolului i o legtur pentru a afia autorii articolului. n plus, utilizatorii pot apsa un buton pentru a aduga o nou recenzie. Pagina Pagina Autorului are dou uniti de prezentare - lista tuturor autorilor i informaia detaliat despre fiecare autor. -Aspectele comportamentale ale interfeei utilizator precum interaciunea recenzenilor pentru a naviga ctre articolele atribuite acestora pentru recenzie, pot fi modelate cu ajutorul diagramelor de comportament sd Afieaz un articol atribuit

sd Extrage lista de articole atribuite

sd Afieaz articolul selectat

Figura 3.10 Diagrama de interaciune a sistemului de recenzie Aspectele comportamentale ale interfeei utilizator precum interaciunea recenzenilor pentru a naviga ctre articolele atribuite acestora pentru recenzie, pot fi modelate cu ajutorul diagramelor de comportament, aa cum se poate observa n figurile 3.10, 3.11 i 3.12. n general interaciunea utilizatorului cu aplicaia web nu implic doar nivelul de prezentare; se face trimitere deseori la nivelul hipertext i nivelul de coninut n funcie de tipul de interaciune. n diagramele din figurile 3.11 i 3.12 un recenzent folosete navigarea ctre indexul articolelor atribuite acestuia prin utilizarea barei de navigare din interiorul paginii principale a conferinei. Aceasta informaie este compus din articole relevante de pe nivelul de coninut. Aceast list permite utilizatorului s selecteze un articol din lista atribuit acestuia. Utilizatorul poate apoi naviga pentru a selecta un articol, care va fi afiat n mod detaliat.

46

Figura 3.11 Diagrama secvenial pentru extragerea unei liste de articole atribuite

Figura 3.12 Diagrama secvenial pentru afiarea articolelor selectate

Modelarea personalizrii informaia contextual i o adaptare adecvat a aplicaiei n faza de modelare 47

realizat printr-o reprezentare explicit a informaiei de context i a adaptrilor derivate din aceasta necesit examinarea situaiilor de utilizare a aplicaiilor web a rspunde la ntrebrile ce i cnd trebuie adaptat - modelare i o administrare a preferinelor i caracteristicilor unui utilizator n aa numitul profil al utilizatorului dupa nivelul de abstractizare al informaiei contextuale-distingem contextul fizic i contextul logic

Deoarece aplicaiile web omniprezente au o importan deosebit este necesar s lum n calcul informaia contextual i o adaptare adecvat a aplicaiei n faza de modelare. Propuneri relevante pentru personalizare regsim n domeniul personalizrii i sistemelor mobile. Modelarea personalizrii este realizat printr-o reprezentare explicit a informaiei de context i a adaptrilor derivate din aceasta. n funcie de metoda de modelare, rezultatul nu este ntotdeauna un model al personalizrii explicit. n majoritatea cazurilor modelarea personalizrii se confund cu modelele coninutului, hipertextului i prezentrii. Personalizarea trebuie s fie distinct de ntreinere sau reproiectare. Modelarea personalizrii ia n considerare informaia care poate fi anticipat n momentul modelrii i care poate lua valori diferite cnd aplicaia web ruleaz. n schimb, adaptarea datorat modificrilor din mediul organizaional sau tehnologic implic activiti de ntreinere sau reproiectare. Personalizarea necesit examinarea situaiilor de utilizare a aplicaiilor web a rspunde la ntrebrile ce i cnd trebuie adaptat. Pentru a putea personaliza o aplicaie web este necesar o modelare i o administrare a preferinelor i caracteristicilor unui utilizator n aa numitul profil al utilizatorului. De exemplu, pentru a adapta o aplicaie web din domeniul sistemelor mobile, trebuie s lum n considerare profilele dispozitivului, informaii privind locaia i limea de band. Aceast informaie este apoi reprezentat n cadrul modelului de context sub forma diagramelor de clas. n momentul rulrii, contextul se poate schimba (de exemplu i schimb preferinele sau aplicaia este folosit din diferite locaii). Din acest motiv este necesar o adaptare a aplicaiei web. n ceea ce privete nivelul de abstractizare al informaiei contextuale, putem distinge contextul fizic i contextul logic. Contextul fizic rezult dintr-o situaie de utilizare specific (de exemplu numele de utilizator pentru o autentificare sau celula GSM n care un utilizator este situat). Contextul logic ofer cunotine de context suplimentare (de exemplu adresa de la serviciu versus adresa de acas, ore de lucru versus timp liber). Aceste informaii de context pot fi oferite aplicaiei web i din surse externe. Un exemplu de astfel de surs extern care ofer informaii pentru o specificare mult mai detaliat a contextului locaiei sunt sistemele informaionale geografic (GIS- Geographic Information Systems). Au fost propuse i alte abordri (cum ar fi Context Toolkit sau proiectul NEXUS) pentru a sprijini componente universale capabile s ofere diferite tipuri de informaii contextuale fizice i logice.

48

<<text>> ID Articol <<text>> Titlu

<<text>> Data de trimitere <<personalizare>>

<<pagina>> <<unitatea de prezentare>> Pagina articolului <<text>> Articol

Rezumat <<ancora>> Versiune PDF <<buton>> Introdu Recenzie

vizibil dac utilizatorul are rolul recenzent

<<colectie de ancore>> Autori

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 adnotri (prin stereotipul <<personalizare>>) pentru a aduga reguli de personalizare claselor adaptate. Regulile descrise n acest exemplu pot fi specificate mai detaliat utiliznd un limbaj formal (de exemplu OCL - Object Constraint Language). Figura 3.13 ilustreaz modul n care structura hipertext poate fi personalizat astfel nct 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 Introducei Recenzia trebuie s fie vizibil doar pentru utilizatorii cu rolul Recenzent). Majoritatea tehnologiilor existente n prezent abordeaz modelarea personalizrii prin definirea regulilor sau unui filtru pentru fiecare punct din aplicaia web n care personalizarea se aplic ca n exemplul anterior. UWE folosete o abordare diferit, utiliznd tehnici de modelare orientate pe aspect (AOM). AOM permite pe de o parte o separare sistematic a funcionalitii sistemului de aspectele personalizrii, iar pe de alt parte permite reducerea redundanei. Metode i utilitare Toate metodele de modelare ofer un set de elemente de modelare ajustate la cerinele aplicaiilor web i majoritatea ofer o notaie specific pentru elementele modelate. n plus, multe dintre ele definesc un proces i sunt susinute de un utilitar care genereaz (semi) automat o implementare pe baza modelelor create

49

Limbaje de modelare ER HDM

OMT

UML

1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 Orientate pe date Orientate pe hypertext Orientate pe obiecte Hera WebML RMM HDM-Lite

WSDM

OOHDM WAE

W2000

UWE OOWS WAE2 OO-H WebSA

Orientate pe software Figura 3.17 Dezvoltarea istoric a metodelor de modelare pentru aplicaiile web Toate metodele de modelare ofer un set de elemente de modelare ajustate la cerinele aplicaiilor web i majoritatea ofer o notaie specific pentru elementele modelate. n plus, multe dintre ele definesc un proces i sunt susinute de un utilitar care genereaz (semi) automat o implementare pe baza modelelor create Metodele disponibile pentru modelarea aplicaiilor web se bazeaz pe cele clasice (cum ar fi ER) sau mbuntesc un limbaj de modelare orientat-obiect (UML). Din punct de vedere istoric metodele de modelare a aplicaiilor web se prezint ca n figura 3.17. Metodele de modelare urmeaz diferite paradigme, n funcie 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-relaie mbuntit prin concepte specifice pentru modelarea la nivel hipertext. Principalul obiectiv al acestor metode este modelarea aplicaiilor 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 aplicaiilor web; ele deriv n principal din domeniul sistemelor hipertext. Cele mai reprezentative exemple sunt: HDM (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 aprute) sau UML (cele mai recente). UML este notaia preferat atunci cnd 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 aplicaiile web n special din perspectiva dezvoltrii clasice de software, folosind tehnici care urmeaz strict proiectarea software clasic. Exemple pentru aceast categorie sunt WAE (Web Application Extension) sau WAE2 (versiunea sa mbuntit).

50

HDM-lite este succesorul lui HDM i a fost proiectat n vederea automatizrii procesului de dezvoltare i generrii automate a aplicaiilor web. W2000 deriv tot din HDM i modeleaz o aplicaie web focalizndu-se pe hipertext i pe utilizator. RMM este o metod care se bazeaz pe modelul ER i definete un proces gradat pentru rafinarea succesiv a modelelor. O alt abordare bazat pe paradigma ER este Hera, care utilizeaz notaia RMM. WebML este un limbaj de modelare matur i uor de neles pentru aplicaii web concentrate pe date care ofer suport pentru prile eseniale ale modelrii aplicaiilor web. Aceast metod folosete utilitarul WebRatio pentru a sprijini att modelarea ct i generarea automat de cod. Deoarece OOHDM pune accentul pe conceptul de navigare contextual, aceast metod este recomandat pentru aplicaiile web care utilizeaz diferite opiuni de navigare. OOHDM a fost extins pentru a suporta personalizarea, modelarea cadrului de lucru, arhitecturile aplicaiilor web i diagramele pentru a capta scenariile de interaciune cu utilizatorul. WSDM se focalizeaz pe o abordare metodic orientat spre cerinele utilizatorului. Pe de alt parte, UWE este o abordare care ofer o notaie bazat pe UML i o verificare a consistenei modelului bazat pe un metamodel. OO-H este una dintre metodele mai recente, care mbin beneficiile WebML, OOHDM i UWE i folosete un utilitar numit VisualWADE pentru suportul generrii codului automat pe baza modelului. OOWS este (asemenea OO-H) o abordare orientat-obiect bazat parial pe UML dar care utilizeaz propriile notaii. WAE2 este o abordare UML care se focalizeaz pe distribuirea logicii aplicaiei. 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 transformrilor n toate etapele dezvoltrii Utilitare WebRatio Site Development Studio WebML, folosete propriile notaii pentru modelarea hipertext i suport notaii ER i UML, utilizeaz XSL pentru a transforma modelele de coninut 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 ieire (HTML, WML, PDF, Microsoft Word) VisualWADE - OO-H, suport modelarea i generarea automat a aplicaiilor bazate pe XML, ASP, JSP i PHP, adaug la modelul UML alte dou modele (Vizualizarea Navigrii i Vizualizarea Prezentrii) 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 transformrilor n toate etapele dezvoltrii (de la specificaiile sistemului pn la implementare i testare). Transformrile dintre modele ofer o legtur care permite implementarea automat a unui sistem n etape succesive pornind de la diferitele modele definite pentru acesta. Dezvoltarea aplicaiilor web este un domeniu specific n care MDD poate fi aplicat cu succes, datorit separrii aspectelor (coninut, hipertext, prezentare i personalizare) specifice web-ului. Metode precum WebML, OO-H i UWE reprezint fundamentul abordrii bazate pe modele pentru dezvoltarea aplicaiilor web; ele includ unele transformri semi-automate bazate pe model. WebSA (Web Software Architecture) este o alt abordare bazat pe model pentru domeniul web-ului i folosete paradigma MDA (Model-DrivenArchitecture). Asemntor cu MDA, WebSA se focalizeaz pe construirea de modele independente de platform i ulterior construirea automat a modelelor specifice platformei. Utilitare Datorit ciclurilor de dezvoltare scurte i complexitii aplicaiilor web este recomandat utilizarea de instrumente care permit nu doar modelarea ci i generarea automat a codului i verificarea consistenei modelului. Principalele utilitare de acest tip sunt: WebRatio Site Development Studio, VisualWADE i OpenUWE Suite. 51

WebRatio Site Development Studio WebRatio Site Development Studio (http://www.webratio.com) este un instrument de dezvoltare bazat pe modele care construiete folosind Web Modeling Language (WebML) (http://www.webml.org). Acest utilitar folosete propriile notaii pentru modelarea hipertext i suport notaii ER i UML. Generatorul de cod al instrumentului utilizeaz XSL pentru a transforma modelele de coninut 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 ieire (HTML, WML, PDF, Microsoft Word). WebRatio folosete un instrument numit EasyStyle pentru a genera prezentarea paginilor, care va transforma automat paginile adnotate n foi de stiluri XSL, fr a solicita alte activiti de programare. Aplicaia 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 fiierelor XML. VisualWADE Instrumentul VisualWADE (http://www.visualwade.com) se bazeaz pe metoda OO-H. Acest instrument suport modelarea i generarea automat a aplicaiilor bazate pe XML, ASP, JSP i PHP. VisualWADE adaug la modelul UML alte dou modele: Vizualizarea Navigrii (utilizat pentru a modela aspectul hipertext al aplicaiei web) i Vizualizarea Prezentrii (reprezint elementele de interaciune ale interfeei utilizator cu privire la structura i comportamentul acesteia utiliznd anumite structuri de tip template). Aceasta produce o descriere independent de dispozitiv a interfeei utilizator, care poate fi utilizat de generatoare n vederea obinerii automate a aplicaiei web pentru medii i dispozitive de rulare distincte. OpenUWE Suita de utilitare OpenUWE (http://www.pst.ifi.lmu.de/projekte/uwe) este un mediu de dezvoltare pentru proiectarea i generarea aplicaiilor 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 consistenei 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 notaia UWE i verific consistena modelelor n funcie de constrngerile OCL specificate pentru meta-modelul UWE. Concluzii n ultima decad au fost dezvoltate numeroase metode de modelare a aplicaiilor web. Este greu de anticipat momentul n care se va ajunge la un limbaj de modelare web unificat (Unied Web Modeling Language) similar dezvoltrii UML-ului. Includerea serviciilor web n dezvoltarea aplicaiilor web bazate pe modele va aduce noi provocri, cea mai important fiind interaciunea dintre modelarea de sus n jos i de integrarea de jos n sus a serviciilor existente.

Arhitecturile aplicaiilor web

Calitatea aplicaiilor web este influenat semnificativ de arhitectura acestora <Performana sczut, ntreinerea i extinderea insuficient i slaba disponibilitate a unei aplicaii web constrngerile tehnice - disponibilitatea serverelor web + serverele de aplicaii utilizate sau integrarea sistemelor de motenire + arhitecturile aplicaiilor web trebuie s ia n considerare i cadrul de lucru organizaional (experiena arhitecilor) Calitatea unei aplicaii web este influenat semnificativ de arhitectura sa. Aspectele arhitecturale incomplete sau omise fac dificil ndeplinirea cerinelor privind calitatea aplicaiilor web. Performana sczut, ntreinerea i extinderea insuficient i slaba disponibilitate a unei aplicaii web sunt deseori cauzate de o arhitectur neadecvat. Pe lng constrngerile tehnice (precum disponibilitatea serverelor web, serverele de aplicaii utilizate sau integrarea sistemelor motenite), trebuie s se ia n considerare i cadrul de lucru 52

organizaional n care arhitecturile sunt incluse (de exemplu experiena arhitecilor). Utilizarea unor arhitecturi multi-strat flexibile, considerarea coninutului multimedia i integrarea depozitelor de date i aplicaiilor existente reprezint provocrile pentru dezvoltarea unor arhitecturi de succes pentru aplicaiile web. Vom discuta n continuare proprietile generale ale arhitecturilor, influena cunotinelor arhitecturale existente sub forma abloanelor i cadrelor de lucru asupra calitii aplicaiilor web i arhitecturile reprezentative pentru aplicaii web mpreun cu componentele necesare construirii acestora. Pe parcursul dezvoltrii aplicaiilor web trebuie luate n considerare un numr mare de cerine i constrngeri, ncepnd cu cerinele funcionale (ex. comenzile de produse online) i cele de calitate (ex. performana i disponibilitatea) i pn la integrarea sistemelor software existente (aa numitele sisteme motenite) sau a depozitelor de date existente pe care aplicaia web ar trebui s le citeasc. n mod normal, aplicaiile web nu sunt dezvoltate din nimic n ceea ce privete infrastructura tehnic; deseori trebuie extins sau adaptat o infrastructur existent. Pe lng constrngerile pur tehnice, putem identifica alte aspecte, precum viabilitatea economic a unei infrastructuri tehnice. Proprietile arhitecturilor software arhitectura descrie structura - structura, descompunerea n componente, interfaa i relaiile dintre ele arhitectura face tranziia de la analiz la implementare arhitectura abordari conceptual - identitile domeniului aplicaiei i relaiile n funcie de momentul rulrii - servere sau ci de comunicaie pe procese - mapeaz procesele n momentul rulrii sistemului (sincronizarea i concurena) n funcie de implementare - artefactele software-ului (subsisteme, componente sau cod surs) Nu exist o definiie unic a termenului arhitectur, renumitul Institut de inginerie a software-ului (SEI -Software Engineering Institute) din cadrul Universitii Carnegie-Mellon (http://www.sei.cmu.edu) oferind peste 20 de variante explicative. n loc de a aduga o alt variant, vom ncerca s descriem principalele proprieti ale arhitecturilor software: - arhitectura descrie structura: arhitectura unui sistem software const n structurile lui, descompunerea n componente i interfeele i relaiile dintre ele[1]. Arhitectura descrie att aspectele statice ct i cele dinamice ale sistemului software. - arhitectura face tranziia de la analiz la implementare: cnd crem arhitectura ncercm s transformm cerinele funcionale i cele de calitate n componente software i relaiile i interfeele dintre ele ntr-un mod iterativ. Acest proces este susinut de mai multe abordri, cum ar fi Procesul Unificat. - arhitectura poate fi abordat din diferite perspective, n funcie de care se pot specifica aspecte arhitecturale distincte. Exist patru abordri diferite: * abordarea conceptual identific entitile domeniului aplicaiei i relaiile dintre acestea; * abordarea n funcie de momentul rulrii descrie componentele n momentul rulrii sistemului (de exemplu servere sau ci de comunicaie) * abordarea pe procese mapeaz procesele n momentul rulrii sistemului, avndu-se n vedere aspecte precum sincronizarea i concurena; * abordarea n funcie de implementare descrie artefactele software-ului (subsisteme, componente sau cod surs) Aceast clasificare n funcie de diferitele perspective este susinut 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 complexitii sistemelor software, sistemele devenind astfel mai uor de neles. - arhitectura reprezint cadrul pentru un sistem flexibil: Tom DeMarco se refer la arhitectur ca la un cadru al schimbrii: 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. 53

Avnd n vedere proprietile menionate, putem afirma c deciziile arhitecturale sunt de o importan major pentru dezvoltarea aplicaiilor web. [1] Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison-Wesley, 1998
Cerine funcionale -clieni -utilizatori -ali mputernicii Aspecte privind calitatea -performana -scalabilitatea -reutilizabilitatea -altele

` Arhitectura

Experiena cu -arhitectura existent -abloanele -managementul proiectelor -altele

Aspecte tehnice -sistem de operare -middleware -sisteme de motenire -altele

Figura 4.1 Factori care influeneaz dezvoltarea unei arhitecturi Cerinele software-ului i deci arhitectura acestuia sunt ntr-o continu schimbare. Constrngerile tehnice i de organizare se modific pe parcursul i dup dezvoltarea unei aplicaii. Aceasta se poate datora unor cerine neclare la nceputul procesului de dezvoltare sau unei schimbri a cerinelor dup finalizarea sistemului. Din acest motiv sistemele software sunt deseori numite inte n micare. Figura 4.1 ilustreaz factorii i constrngerile care influeneaz dezvoltarea unei arhitecturi conform opiniei lui Jacobson[1]. [1] Jacobson, I., Booch, G., Rumbaugh, J., The Unified Software Development Process, Addison-Wesley, 1999 Arhitectura unei aplicaii este influenat n principal de cerinele funcionale - serviciile oferite de un sistem i consideraiile privind calitatea (scalabilitatea sau performana). Dincolo de aceste cerine, arhitecturile sunt influenate de constrngeri tehnice cum ar fi software-ul utilizat de sistem (de exemplu sistemul de operare), middleware-ul (de exemplu o implementare CORBA), sistemele motenite care trebuiesc integrate, standardele utilizate, regulile de dezvoltare (de exemplu ghidurile de scriere a codului) sau aspectele de distribuire (de exemplu distribuirea n diferite locaii ale unei companii). Deoarece sistemele software sunt n permanent schimbare arhitecturile sunt de obicei dezvoltate ntr-o manier iterativ, deci riscurile rezultate din cerinele i constrngerile neclare ar trebui s fie calculabile i controlabile. Totui, aceast abordare iterativ nu garanteaz o arhitectur solid; ea nu este suficient pentru rezolvarea unor probleme de proiectare specifice (precum integrarea unui sistem motenit) aprute 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 soluii la acestea abloanele arhitecturale - mapeaz mecanismele de structurare fundamentale pentru sistemele software (ablonul MVC) abloanele de proiectare - descriu structura, relaiile i interaciunea 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 54

 Cadre - sistem software reutilizabil cu o funcionalitate general deja implementat. Cadrul de lucru poate fi ntlnit sub forma aplicaiilor gata de folosire i servete ca o schi pentru arhitectura i funcionalitile de baz ale unui domeniu specific al aplicaiei abloane abloanele[1] descriu probleme de proiectare recurente care apar ntr-un anumit context i propun soluii la acestea. O soluie descrie componentele participante, responsabilitile lor, relaia ntre aceste componente i interaciunea lor n cadrul problemei. De aici rezult c abloanele ne permit reutilizarea cunotinelor 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, responsabilitile acestora, relaiile i interaciunea dintre ele. Un exemplu de astfel de ablon este ablonul MVC (Model-View-Controller[3]). - abloanele de proiectare descriu structura, relaiile i interaciunea dintre componente pentru a rezolva o problem de proiectare aprut 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. Totui, abloanele reprezint doar un ghid pentru o anumit problem. Arhitecii software trebuie s adapteze abloanele la problema i constrngerile respective, s integreze i s mbunteasc abloanele folosite. Pentru a susine procesul de integrare, Buschmann recomand folosirea aa-numitelor limbaje-ablon. Un limbaj-ablon descrie interconexiunile abloanelor nrudite la nivele de abstractizare diferite, sugereaz diferite utilizri pentru abloane i indic adaptarea necesar pentru a asigura un sistem solid. IBM descrie n 2002 abloanele de arhitectur pentru aplicaii comerciale i modul n care pot fi mapate pe infrastructura IBM[5]. Aceste abloane de arhitectur sunt perfecionate printr-un lan de decizii, pornind de la cazul de utilizare i terminnd cu arhitectura int. Cadre Cadrele reprezint o alt opiune pentru reutilizarea cunotinelor arhitecturale existente. Un cadru este un sistem software reutilizabil cu o funcionalitate general deja implementat. Cadrul poate fi ntlnit sub forma unei aplicaii gata de folosire[6]; el servete ca o schi pentru arhitectura i funcionalitile de baz ale unui domeniu specific al aplicaiei. (deci informaiile arhitecturale coninute ntr-un cadru pot fi preluate n ntregime n aplicaie). Beneficiile unui cadru reutilizarea cu uurin a arhitecturii i funcionalitii - trebuie puse n balan alturi de dezavantajele sale (gradul nalt de instruire necesar, lipsa standardelor pentru integrarea diferitelor cadre i deci dependena de productori). [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 cteva nivele pentru implementarea principiului separarea intereselor n cadrul unui sistem software (arhitecturile J2EE, portalurile) aspectul datelor: datele pot fi structurate sau nestructurate

55

n ultimii ani au fost dezvoltate o serie de arhitecturi pentru rezolvarea cerinelor specifice din diverse domenii de aplicaii. Anastopoulos i Romberg[1] descriu arhitecturile pentru mediile aplicaiilor web n funcie de aspectul stratificat al arhitecturilor sau de aspectul datelor (susinerea diferitelor date i formate de date): - aspectul stratificat: se refer la faptul c sistemele software sunt structurate pe cteva nivele pentru a implementa principiul separarea intereselor n cadrul unui sistem software. Multe cadre din domeniul sistemelor distribuite i aplicaiilor web sunt structurate n principal n funcie de aspectul stratificat (de exemplu arhitecturile J2EE[2] utilizate pentru a integra sistemele motenite; portalurile). - aspectul datelor: datele pot fi structurate sau nestructurate. Datele structurate urmeaz o schem definit asemntor tabelelor din bazele de date relaionale 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 fur 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 arhitecturilor Arhitecturi 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 (Microsofts DCOM) - VSM (Virtual Shared Memory) - permite proceselor distribuite s acceseze datele comune (Corso) - MOM (Message Oriented Middleware) - ofer funcionaliti pentru transmiterea asincron a mesajelor (Microsoft Message Queue) - P2P (Peer to Peer) - comunicarea direct ntre dou dispozitive (parteneri) ntr-un sistem fr utilizarea unui server (Xmiddle) - SOM (Service Oriented Middleware) - mbuntete sistemele DOM prin conceptul de servicii (Jini) Arhitecturile prezentate se pot aplica sistemelor distribuite n general i nu sunt limitate doar la aplicaiile web Rspndirea 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 funcionaliti 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 cnd mesajul este trimis - este offline). Exemplu: MSMQ - Microsoft Message Queue. - P2P (Peer to Peer): nseamn comunicarea direct ntre dou dispozitive (pereche) ntr-un sistem fr utilizarea unui server (ele comunic printr-o conexiune de tip punct-la-punct). Exemplu: Xmiddle (http://xmiddle.sourceforge.net/) - SOM (Service Oriented Middleware) - mbuntete sistemele DOM prin conceptul de servicii. Un serviciu n acest context reprezint un numr 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 aplicaiile web. Particularitile arhitecturilor pentru aplicaiile web 56

 arhitectura infrastructurii web (Web Platform Architectures -WPA) i infrastructura aplicaiilor web (Web Application Architectures - WAA) WPA Serverele de aplicaii precum implementarea J2EE i platforma .NET soluii arhitecturale specifice pentru rezolvarea problemelor de securitate, performan i integrare a datelor (firewall-uri, proxy-uri ptr caching i EAI) Aplicaiile web actuale utilizeaz un numr 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 aplicaii (de exemplu implementarea EJB) i JetSpeed (http://jakarta.apache.org/jetspeed/). Internaionalizarea aplicaiilor web - suport pentru limbi diferite, seturi de caractere i mecanisme de reprezentare Particularitile arhitecturilor pentru aplicaiile web Pentru nceput este necesar realizarea unei distincii ntre arhitectura infrastructurii web (Web Platform Architectures -WPA) i arhitectura aplicaiei web (Web Application Architectures - WAA). Deoarece WAA depinde de domeniul problemei aplicaiei web, vom insista asupra WPA-urilor. WPA-urile au fost dezvoltate pentru o arie larg de probleme. Serverele de aplicaii precum implementrile J2EE i platforma .NET ncearc s ofere servicii de baz pentru controlul sesiunilor i accesul la date. n afara serverelor de aplicaii au fost dezvoltate soluii arhitecturale specifice pentru problemele de securitate, performan i integrare a datelor (firewall-uri, proxy-uri pentru caching i EAI). Paradoxal, utilizarea unui numr mare de sisteme diferite face dificil evaluarea i meninerea unor cerine de calitate distincte. De exemplu, ndeplinirea cerinelor de performan a devenit mai dificil datorit numrului din ce n ce mai mare de componente i produse (comerciale sau gratuite) utilizate de la vnztori teri. Alte probleme n dezvoltarea aplicaiilor web sunt neomogenitatea i imaturitatea infrastructurilor tehnice. Gorton i Liu (2002) descriu problemele care apar la analiza performanei pentru serverele de aplicaii datorit update-urilor frecvente; studiul relev c versiunile noi de produse sunt mai lente dect predecesoarele lor i noile funcionaliti determin incompatibiliti n codul aplicaiei existente. Dup adaptri extensive, care au necesitat o cunoatere extrem de detaliat a produselor n cauz, s-a putut restaura comportamentul de performan dorit. Indiferent de problemele de neomogenitate i imaturitate, aplicaiile web actuale utilizeaz un numr 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 aplicaii (de exemplu implementrile EJB), cadrele portal (JetSpeed http://jakarta.apache.org/jetspeed/). Un alt aspect important n domeniul arhitecturilor aplicaiilor web este internaionalizarea aplicaiilor web, care necesit suport pentru diferite limbi, seturi de caractere i mecanisme de reprezentare (ex. reprezentarea caracterelor arabice de la dreapta la stnga) la nivelul WPA. Multe dintre aceste aspecte sunt suportate de limbajele de programare sau sistemele de operare (exemplu platforma PHP ofer un mecanism de internaionalizare pentru codificarea seturilor de caractere diferite -ISO-8859-2, UTF-8- realizat i cu ajutorul programului Gettext). Componentele arhitecturii aplicaiilor web

57

Proxy Container CGI Servlet Server web Fiiere HTML, XML, XSL

Plug-in-uri Applet-uri Browser Client Firewall Server de baze de date

Server de aplicaie

Aplicaii externe Server media Server de management al coninutului Aplicaii motenite

Componentele arhitecturii web

Componente opionale ale arhitecturilor web

Ciclu Cerere/Rspuns

Figura 4.2 Componentele de baz ale arhitecturilor unei aplicaii web n Figura 4.2 sunt reprezentate componentele de baz ale arhitecturilor web i relaiile dintre ele. Comunicarea dintre aceste componente se bazeaz n general pe principiul cerere-rspuns: o component (ex. un browser web) trimite o cerere ctre o alt component (ex. un server web) i rspunsul la aceast cerere este trimis napoi pe acelai canal de comunicare (comunicare sincron). Componentele frecvent implicate n comunicare sunt: - client: n general un browser (agent utilizator) este controlat de ctre un utilizator care folosete aplicaia web. Funcionalitatea clientului poate fi extins prin instalarea plug-in-urilor i applet-urilor. - firewall: un software care reglementeaz comunicarea ntre reele nesecurizate (exemplu Internet) i reele securizate (exemplu reele 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 coninutul pentru utilizatori (personalizare) sau pentru a urmri 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 producie ale unei organizaii ntr-o form structurat (exemplu: n tabele) - server media: este utilizat pentru streaming-ul coninutului pentru datele nestructurate (exemplu: audio sau video) - server pentru managementul coninutului: pstreaz coninutul aferent unei aplicaii, care este disponibil sub forma datelor semistructurate (exemplu: documente XML) - server de aplicaii: pstreaz funcionalitatea necesar diverselor aplicaii (exemplu: fluxul de date sau personalizarea) - aplicaii motenite: un sistem mai vechi care trebuie integrat ca o component intern sau extern. Arhitecturile stratificate Arhitecturi pe dou straturi

58

Client

Client

Serverul web i logica afacerii

Servicii

Server Pagini HTML statice

Baze de date

Pagini HTML dinamice

Figura 4.3 Arhitectur pe dou straturi pentru aplicaiile web Arhitectura pe dou straturi poate lua forme diferite n mediul aplicaiilor web. O cerere a unui client poate puncta direct ctre pagini HTML statice, fr a solicita un raionament de procesare pe stratul server sau poate accesa o baz de date prin intermediul logicii aplicaiei pe serverul web (de exemplu sub forma scripturilor CGI). Paginile HTML dinamice includ instruciuni de tip script direct n codul HTML (de exemplu cnd este utilizat SSI - Server-Side Include sau PHP) i ele sunt interpretate fie de bazele de date cu funcionaliti HTML fie de un server web. Logica aplicaiei sau paginile HTML dinamice pot utiliza servicii (exemplu identificarea utilizatorului sau criptarea datelor) cnd este generat rspunsul HTML. Aceast arhitectur este adecvat aplicaiilor web simple. O abordare arhitectural multi-stratificat este necesar pentru aplicaiile mai complexe care sunt accesate de un numr mare de clieni concureni sau care ofer procese de afaceri complexe ce necesit accesarea sistemelor motenite etc. Arhitecturi pe N straturi

59

Client

Firewall

Proxy Nivelul prezentare Nivelul afacere Acces date Colaborare

Server web

Logistica afacerii Server de aplicaii Flux de date etc. Personalizare Conectori

Aplicaii de motenire Backend Sistem informaional al companiei

Server de baze de date

B2B

Nivelul datelor

Figura 4.4 O arhitectur pe N straturi pentru aplicaiile web Arhitecturile pe N straturi permit organizarea unei aplicaii web pe un numr arbitrar de nivele (vezi figura 4.4). Acestea constau de obicei n trei straturi: stratul datelor, care ofer acces la datele aplicaiei, stratul afacerii care gzduiete logica de afaceri a aplicaiei ntr-un server de aplicaii i stratul prezentare care returneaz rezultatul cererii n formatul de ieire dorit. n plus, pot fi integrate n fluxul cerere-rspuns 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 aplicaiei. Servicii precum personalizarea sau fluxul de date sunt pstrate n serverul aplicaiei, astfel nct s fie disponibile pentru toate aplicaiile web. Serviciile sunt ncorporate n serverul de aplicaii cu o interfa definit, care poate fi utilizat i pentru a administra aceste servicii. Un exemplu pentru aceste funcionaliti este serverul de aplicaii WebSphere, mpreun cu componentele afacerii WebSphere. Conectorii pot fi utilizai pentru a integra sistemele externe (ex. sisteme partener de afaceri) sau pentru a integra aplicaii motenite i sisteme informaionale ale companiilor. Majoritatea serverelor de aplicaii comerciale au fost optimizate pentru procesarea coninutului bazelor de date, suportul pentru coninutul multimedia i structurile hipertext fiind neglijat. Un exemplu de integrare a datelor video ntr-un server de aplicaii este disponibil la http://www.ibm.com/software/data/informix/blades/video/. Proxy-uri proxy-uri de legturi: sunt de cel puin dou tipuri. 60

-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 ctre serverul real - utilizate pentru a adapta i formata legturile i coninutul pentru utilizatori proxy-uri de istoric - pot fi utilizate pentru a administra istoricul paginilor vizitate de utilizator Serverul Boomerang de pe DoubleClick

Proxy-uri Iniial proxy-urile erau folosite pentru a salva limea de band, din acest motiv fiind numite i proxyuri de caching[1]. Proxy-urile sunt capabile s ndeplineasc i alte funcii: - proxy-uri de legturi: sunt de cel puin dou tipuri. n primul rnd, 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 ctre serverul real. Dac numele sau locaia 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 ctre proxy. n al doilea rnd, proxy-urile sunt utilizate pentru a adapta i formata legturile i coninutul pentru utilizatori. O metod folosit n acest concept este inserarea dinamic a legturilor 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 sfritul documentului n privina schimbrii resursei transmise. - proxy-uri de istoric: multe aplicaii web ncearc s-i adapteze funcionalitile cerinelor utilizatorilor. Problema care apare este c HTTP-ul este un protocol simplu, care nu ofer informaii despre istoricul navigrii unui utilizator pe mai multe situri. De exemplu, dac un utilizator planific o vacan i rezerv un zbor, un hotel i o main de nchiriat pe internet, atunci vnztorul de bilet de avion nu tie c utilizatorul a rezervat o camer la hotel i o main de nchiriat. Dac compania aerian ar cunoate aceste informaii, atunci camera de hotel i maina rezervate ar putea fi anulate dac utilizatorul contramandeaz zborul. O problem similar apare i n domeniul marketingului direct, n care, cu ct se cunosc mai multe detalii despre interesele utilizatorului, cu att 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 utiliznd tehnologia cookie. n aceast situaie, dac utilizatorul viziteaz situl web al unei alte companii conectate la acelai proxy, atunci informaiile despre acest utilizator pot fi extrase, permind 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 Arhitecturi de integrare

61

Client

Agregare Server web Portlet 1 Portlet n

Serviciu web 1

Serviciu web n

Coninut

Coninut

Figura 4.9 Exemplu de arhitectur a unei aplicaii web orientat pe portal Sistemele interne sau externe aplicaiile i bazele de date existente, interfeele ctre partenerii de afaceri externi - pot fi integrate n aplicaiile web pe trei nivele: nivelul prezentare, nivelul logic al aplicaiei i nivelul coninutului Arhitecturile de integrare - se adreseaz aspectelor de integrare la nivelul coninut i nivelul logic al aplicaiei i sunt cunoscute sub numele de arhitecturi EAI (Enterprise Application Integration). Arhitecturi de integrare Sistemele interne sau externe aplicaiile i bazele de date existente, interfeele ctre partenerii de afaceri externi - pot fi integrate n aplicaiile web pe trei nivele: nivelul prezentare, nivelul logic al aplicaiei i nivelul coninutului. Arhitecturile de integrare se adreseaz aspectelor de integrare la nivelul coninut i nivelul logic al aplicaiei i sunt cunoscute sub numele de arhitecturi EAI (Enterprise Application Integration). n esen, EAI se focalizeaz pe integrarea sistemelor motenite. O alternativ la EAI sunt serviciile web, care ofer integrarea serviciilor (logica aplicaiei i coninutul). La nivelul prezentare, un set de sisteme diferite este integrat tipic prin utilizarea arhitecturilor portal. Portalurile reprezint cele mai recente dezvoltri ale aplicaiilor web multi-stratificate. Cu ajutorul portalurilor coninutul, care este distribuit pe mai multe noduri ale diverilor 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 coninutul i logica aplicaiei 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 funcie 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 aplicaii (n cazul arhitecturilor pe N straturi) Arhitecturi pentru managementul documentelor web - ofer posibilitatea integrrii documentelor din surse diferite, reprezentnd un mecanism pentru integrarea acestora n aplicaiile web 62

Arhitecturi n funcie de aspectul datelor Datele pot fi grupate n una din urmtoarele 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. Aplicaiile web nu sunt limitate la una din aceste categorii de date, ele integreaz documente, media i baze de date. Arhitecturi axate pe baze de date Sunt disponibile numeroase utilitare i abordri pentru integrarea bazelor de date n aplicaiile web. Aceste baze de date sunt accesate fie direct prin intermediul extensiilor serverului web (n cazul arhitecturilor pe dou straturi), fie prin serverele de aplicaii (n cazul arhitecturilor pe N straturi). Pentru accesul la bazele de date relaionale sunt disponibile interfee (APIs) pentru diferite platforme (Java Database Connectivity -JDBC pentru aplicaii bazate pe Java sau Open Database Connectivity -ODBC pentru tehnologii Microsoft). Arhitecturi pentru managementul documentelor web Pe lng datele structurate din bazele de date i cele multimedia de pe serverele media, coninutul aplicaiilor web este frecvent procesat sub forma documentelor. Arhitecturile de management al coninutului ofer posibilitatea integrrii documentelor din surse diferite, reprezentnd un mecanism pentru integrarea acestor coninuturi n aplicaiile web. Client

Server de management al coninutului Server web Sistem de furnizare a coninutului Serviciu Dispatch Editor

Server de furnizare a coninutului Baze de date pentru coninut Serviciu sindicat Documente statice

Partener

Serviciu de agregare

Baze de date externe

Figura 4.10 Arhitectur de management a coninutului pentru aplicaiile web Figura 4.10 reprezint componentele unei arhitecturi de management al coninutului. Un server web recepioneaz o cerere de la client i o trimite mai departe unui server de furnizare a coninutului (responsabil pentru distribuirea i eventual caching-ul coninutului). Dac coninutul solicitat nu este n cache atunci cererea este trimis mai departe ctre serverul de management al coninutului. Coninutul 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 funcie de tipul de integrare coninutul 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 63

unei baze de date, serviciile de mediatizare pot avea i funcionaliti suplimentare (exemplu facturarea automat a drepturilor de licen). Arhitecturi pentru datele multimedia

Proxy apropiat locaiei A Client la locaia A Browser Plug-in streaming http Server web API Server media RTP/ RTSP

RTP/ RTSP

http Browser Client la locaia B RTP/ RTSP RTP/ RTSP Proxy apropiat locaiei B

Streaming client

Figura 4.12 Arhitectura media de streaming care utilizeaz conexiuni punct-la-punct Arhitecturi pentru datele multimedia Capacitatea de a manipula un volum mare de date are un rol decisiv n proiectarea sistemelor care utilizeaz coninut multimedia. Dei volumul de date nu este important n aplicaiile web axate pe baze de date, acesta influeneaz considerabil arhitectura i proiectarea aplicaiilor web multimedia. Datele multimedia audio i video- pot fi transmise prin intermediul protocoalelor internet standard (HTTP sau FTP), asemenea altor date folosite n aplicaiile web. Aceast abordare este utilizat de un numr mare de aplicaii web, deoarece prezint avantajul c nu necesit componente suplimentare pe server; dezavantajul este c descrcrile de fiiere multimedia sunt foarte lente. Se pot utiliza tehnologii streaming pentru a minimiza perioada de ateptare pentru redarea coninutului multimedia; prin streaming n acest context se nelege c un client poate reda un fiier audio i/sau video la cteva secunde dup ce ncepe recepionarea acestuia de pe server. Aceast tehnic evit descrcarea ntregului fiier nainte de a ncepe redarea lui. Coninutul trebuie transmis n timp real, ceea ce necesit o lime de band corespunztoare (garantarea limii de band a transmisiei este numit calitatea serviciului). n general sunt folosite dou protocoale pentru streaming-ul de coninut multimedia: un protocol preia transmisia datelor multimedia la nivelul reea, iar cellalt controleaz fluxul prezentrii (exemplu pornirea i oprirea unui clip video) i transmisia meta-datelor. Un exemplu de protocol de reea este RTP (Real Time Protocol) care coopereaz cu un protocol de control numit RTSP (Real Time Streaming Protocol). Exist dou domenii distincte de aplicaii pentru streaming-ul datelor multimedia: primul face disponibil la cerere coninutul existent (ex. video la cerere), iar al doilea distribuie live coninutul unui numr mare de utilizatori (ex. web casting). Fiecare din aceste dou cazuri de utilizare formuleaz cereri total diferite la nivelul reelei i arhitecturilor hardware i software. Dei fiecare utilizator stabilete propria sa conexiune la 64

server ntr-un scenariu la cerere (vezi figura 4.12) cauznd probleme majore de lime de band i ncrcare pe server, broadcasting-ul realizeaz cereri foarte mari la nivelul reelei. n mod ideal, un server utilizat pentru broadcasting ar trebui s administreze un singur stream media, care este difuzat simultan ctre toi utilizatorii de ctre infrastructura reelei (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 funcionalitatea broadcast. Client Client Client

Client Router m Server media

Router 1 Client Router n

Client

Client

Client

Figura 4.13 Arhitectura media de streaming care utilizeaz o infrastructur broadcasting Exist dou domenii distincte de aplicaii pentru streaming-ul datelor multimedia: primul face disponibil la cerere coninutul existent (ex. video la cerere), iar al doilea distribuie live coninutul unui numr mare de utilizatori (ex. web casting). Fiecare din aceste dou cazuri de utilizare formuleaz cereri total diferite la nivelul reelei i arhitecturilor hardware i software. Dei fiecare utilizator stabilete propria sa conexiune la server ntr-un scenariu la cerere (vezi figura 4.12) cauznd probleme majore de lime de band i ncrcare pe server, broadcasting-ul realizeaz cereri foarte mari la nivelul reelei. n mod ideal, un server utilizat pentru broadcasting ar trebui s administreze un singur stream media, care este difuzat simultan ctre toi utilizatorii de ctre infrastructura reelei (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 funcionalitatea broadcast.

65