Proiectarea Web Dezvoltarea Sistematica a Aplicatiilor Web

Proiectarea web – dezvoltarea sistematica a aplicațiilor web

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

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

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

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

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

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

I. Introducere în proiectarea aplicațiilor web

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

Aplicațiile web de astăzi – sisteme software complexe care oferă servicii interactive și personalizabile accesibile prin intermediul diferitelor dispozitive

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

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

Deși inițial web-ul a fost proiectat ca un mediu pur informațional, în prezent el evoluează într-un mediu al aplicațiilor. Aplicațiile web de astăzi sunt sisteme software complexe care oferă servicii interactive și personalizabile accesibile prin intermediul diferitelor dispozitive; ele oferă posibilitatea realizării tranzacțiilor între utilizatori și de obicei stochează datele într-o bază de date. Elementul distinctiv al aplicațiilor web comparativ cu aplicațiile software tradiționale este modul în care este utilizat web-ul: tehnologiile și standardele sale sunt utilizate ca o platformă de dezvoltare și ca platformă utilizator în același timp. O aplicație web poate fi definită astfel:

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

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

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

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

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

În ciuda schimbărilor fundamentale ale web-ului de la un mediu informațional la un mediu al aplicațiilor, situația actuală a dezvoltării ad-hoc a aplicațiilor web ne amintește de practicile de dezvoltare a software-ului din anii 60’, înainte să se realizeze că dezvoltarea aplicațiilor necesită mai mult decât experiență în programare[1]. Dezvoltarea aplicațiilor web este deseori privită ca un eveniment spontan, de obicei bazat pe cunoașterea, experiența și practicile de dezvoltare ale dezvoltatorilor individuali, greu de reutilizat la modul ”Copy&Paste” și având o documentare necorespunzătoare a deciziilor de proiectare. Deși acest procedeu poate părea pragmatic, astfel de metode de dezvoltare rapide și superficiale conduc deseori la probleme serioase privitoare la calitate și implicit la dificultăți de exploatare și întreținere. Aplicațiile dezvoltate sunt deseori dependente de tehnologie, predispuse la erori și sunt caracterizate prin lipsa performanței, siguranței, accesibilității și deci a acceptării de către utilizatori[2]. Legătura strânsă dintre aplicațiile web sporește pericolul răspândirii problemelor de la o aplicație la alta. Cauza acestei situații este complexă și poate fi abordată din mai multe perspective:
[1] Pressman, R. S., Can WebApps Be Engineered?, SPC Essentials, Software Productivity Center, May 2000a, la http://www.spc.ca/essentials/may0300.htm , [vizitat la: 2007-10-01]

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

Cauza acestei situații

abordarea centrată pe document (authoring)‏

presupusa simplitate a dezvoltării aplicațiilor web (editoare, generatoare)‏

cunoștințele specifice din discipline relevante nu pot aplicate sau utilizate

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

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

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

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

Proiectarea web – nu este un eveniment imediat

Abordare disciplinară

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

o disciplină științifică implicată în studiul acestei abordări

Termeni din literatură asociați – proiectarea siturilor web, proiectarea hipermedia, proiectarea documentelor, proiectarea conținutului și proiectarea software-lui Internet.

>> PROIECTAREA WEB

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

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

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

– Proiectarea web reprezintă și disciplina științifică implicată în studiul acestor abordări.

Termenii din literatură asociați sunt Proiectarea siturilor web, Proiectarea hipermedia, Proiectarea documentelor, Proiectarea conținutului și Proiectarea software-lui Internet. Prin comparație, ”Proiectarea web” este un termen concis, deși dacă vorbim în mod strict nu este foarte precis: nu web-ul este proiectat, ci aplicațiile web.

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

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

– obiective și cerințe clar definite;

– dezvoltarea sistematică, în faze, a aplicațiilor web;

– planificarea foarte atentă a acestor faze;

– auditul continuu al întregului proces de dezvoltare.

Proiectarea web face posibilă planificarea și repetarea proceselor de dezvoltare, facilitând astfel evoluția continuă a aplicațiilor web. Aceasta permite nu doar reducerea costurilor și minimizarea riscului pe parcursul dezvoltării și întreținerii, ci și creșterea calității și măsurarea calității rezultatelor fiecărei faze[2].
[1] Deshpande, Y., Murugesan, S., Ginige, A., Hansen, S., Schwabe, D., Gaedke, M., White, B., Web Engineering, Journal of Web Engineering, 1 (1), 2002, pp. 3–17

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

Categorii de aplicații web

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

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

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

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

Siturile web axate pe documente sun t precursoare ale aplicațiilor web. Paginile web sunt stocate pe un server web ca documente HTML statice și sunt trimise clientului web ca răspuns la o cerere. Aceste pagini web sunt de obicei actualizate manual folosind utilitare corespunzătoare. Pentru siturile web care impun schimbări frecvente sau pentru cele cu un număr mare de pagini această actualizare crește semnificativ costurile și adesea are drept consecință prezentarea unor informații depășite. În plus există pericolul apariției inconsistențelor atunci când un anumit conținut este prezentat frecvent, redundant pe mai multe pagini web pentru a ușura accesul. Principalele beneficii sunt simplitatea și stabilitatea unui astfel de sit web dar și timpul scurt de răspuns, paginile fiind deja stocate pe serverul web. Paginile principale statice și paginile simple pentru micile afaceri aparțin acestei categorii.

Odată cu apariția standardului Common Gateway Interface (http://hoohoo.ncsa.uiuc.edu/cgi/interface.html) și formularelor HTML, s-au dezvoltat și aplicațiile web interactive, oferind o primă formă de interactivitate prin intermediul formularelor, butoanelor radio și meniurilor de selecție. Paginile web și legăturile către alte pagini sunt generate în mod dinamic în funcție de datele introduse de utilizator. Exemple de astfel de categorii sunt expozițiile virtuale, siturile de știri sau de planificare a călătoriilor.

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

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

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

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

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

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

Dezvoltările prezente și în special convergența sporită a industriei TIMES (telecomunicații, tehnologia informației, multimedia, educație și divertisment, securitate), vor conduce, în viitorul apropiat, la o situație în care aplicațiile omniprezente vor domina piața. Una dintre aceste dezvoltări este web-ul semantic, al cărui obiectiv este prezentarea informației pe web nu doar pentru oameni ci și într-o formă care poate fi interpretată de sistemele de calcul[2]. Aceasta va facilita managementul cunoștințelor pe web și în particular conectarea și reutilizarea cunoștințelor (mediatizarea conținutului), dar și localizarea cunoștințelor noi relevante (de exemplu cu ajutorul sistemelor de recomandare). Datorită interactivității crescute la nivel semantic și posibilității de automatizare a sarcinilor (prin intermediul agenților inteligenți), putem afirma că web-ul va deveni mai răspândit și mai relevant în viața de zi cu zi.

[1] Weerawarana, S., Curbera, F., Leymann, F., Storey, T., Ferguson, D. F., Web Services Platform Architecture, Prentice Hall, 2005

[2] Berners-Lee, T., Hendler, J., Lassila, O., The Semantic Web, Scientific American, May, 2001

Caracteristicile aplicațiilor web – Generalități

Aplicațiile web # aplicațiile tradiționale

navigarea non-liniară

frecvența actualizărilor

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

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

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

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

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

Caracteristicile produselor

conținut, structură hipertextuală și prezentare

> aspecte structurale sau statice ci și aspecte comportamentale sau dinamice

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

Conținut – “Conținutul este regele” – programatori și autori

– Caracterul „axat pe document” și multimedia- conținutul este oferit sub forma tabelelor, textului, elementelor grafice, animațiilor, elementelor audio sau video

Caracterul "axat pe document" în aplicațiile web – documentele sunt generate în mod adecvat pentru anumite grupuri de utilizatori

– generat și actualizat dinamic

– conținut multimedia

– Cererile de calitate – actualitate, exactitate, consistență și încredere > Siturile de știri, personalizare, aplicațiile ”inteligente”, ”conștiente” de locație

– calitatea superioară este necesară pentru prețul și utilitatea informației în sistemele de cumpărare online

Conținutul

Generarea conținutului, disponibilizarea acestuia, integrarea și actualizarea lui sunt la fel de importante precum dezvoltarea software-ului pentru o aplicație web. Aplicațiile web sunt utilizate în special datorită conținutului pe care îl oferă, fiind valabil motto-ul ”Conținutul este regele”, iar dezvoltatorii lor trebuie să se comporte atât ca programatori cât și ca autori. Aspectele importante sunt gradul variat al structurii conținutului și cererile de calitate făcute de utilizatori asupra conținutului.

* Caracterul „axat pe document” și multimedia. În funcție de modul de structurare, conținutul este oferit sub forma tabelelor, textului, elementelor grafice, animațiilor, elementelor audio sau video. Caracterul "axat pe document" în aplicațiile web se referă la faptul că sunt generate documente care prezintă informația în mod adecvat pentru anumite grupuri de utilizatori (de exemplu informații pentru turiștii aflați în vacanță într-o anumită regiune). Aceasta implică și anumite cerințe speciale privitoare la ușurința în folosire. Conținutul este într-o anumită proporție generat și actualizat dinamic (de exemplu numărul de camere disponibile într-un sistem informațional pentru turism). Mai mult, web-ul poate fi folosit ca infrastructură pentru transmiterea conținutului multimedia (de exemplu videoconferințe sau aplicații Real Audio).

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

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

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

Hipertext – natura non-liniară a documentelor hipertextuale

Elementele de bază ale modelelor hipertext

nod – unitate de informație unic identificată

legătură – calea de la un nod la altul

ancoră – conținutul unui nod

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

Ancorele și legăturile – statice/dinamice

Dezorientarea și supra-încărcarea cognitivă

– pierde poziția într-un document non-liniar

– concentrarea suplimentară solicitată de memorarea simultană a diverselor căi sau sarcini

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

Hipertext

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

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

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

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

Prezentarea

Estetica – ”look and feel” – succesul sau eșecul (e-comm)‏

Auto-explicarea – utilizare, sistemul de navigare

Prezentarea

Două trăsături speciale ale aplicațiilor web la nivelul prezentare (interfață utilizator) sunt estetica și auto-explicarea.

Estetica. Spre deosebire de aplicațiile tradiționale, estetica nivelului prezentare al unei aplicații web este un factorul important, și datorită presiunii competitive ridicate de pe web. Prezentarea vizuală a paginilor web este supusă tendințelor în modă și deseori determină succesul sau eșecul, în special pentru aplicațiile de comerț electronic.

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

Caracteristici asociate utilizării

– utilizarea aplicațiilor web este extrem de eterogenă

> utilizatorii – diferă prin prisma numărului și culturii generale

> dispozitivele – caracteristici hardware și software diferite

Contextul social: utilizatorii

Spontaneitatea – utilizatorul poate vizita și părăsi o aplicație web oricând dorește, chiar dacă este situl unui competitor.

Multiculturalitatea – aplicațiile web sunt dezvoltate pentru diferite grupuri de utilizatori – abilitățile (sau incapacitățile), cunoașterea (expertiza aplicației) și preferințele (interesele).

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

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

Contextul social: 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 aplicație web și o pot părăsi oricând doresc – posibil pentru un sit competitor. Utilizatorul web nu trebuie să fie loial nici unui furnizor de conținut, web-ul fiind un mediu care nu atrage nici o obligație. Deoarece găsirea unor aplicații concurente este ușor de realizat cu ajutorul motoarelor de căutare, utilizatorii vor utiliza o aplicație web doar dacă le va aduce un avantaj imediat.

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

Contextul tehnic: Rețeaua și dispozitivele

Calitatea serviciului.

tehnic – aplicațiile web – principiul client/server > caracteristicile mediului de transmisie (lățimea de bandă, siguranța și stabilitatea conexiunii)‏

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

dezvoltatorii trebuie să facă supoziții

Distribuirea multi-plaformă.

Aplicațiile web oferă de obicei servicii nu doar unui anumit tip de dispozitiv

browserele – nu implementează specificațiile presupuse

utilizatorii pot configura browserele în mod autonom

presupuneri privind clasele tipice de dispozitive

Contextul tehnic: Rețeaua și dispozitivele

Contextul tehnic include proprietăți legate de conexiunea în rețea (privitoare la calitatea serviciului) și componentele hardware și software ale dispozitivelor utilizate pentru a accesa aplicația web, pentru distribuirea multi-platformă.

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

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

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

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

Contextul natural: locația si durata

Globalitatea

Locația – importantă pentru internaționalizarea aplicațiilor web relativ la diferențele regionale, culturale și lingvistice.

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

Disponibilitatea.

”Mecanismul de distribuire instantanee” = natura web-ului

Contextul natural: locația și timpul

Contextul natural include aspecte privind locația și timpul de accesare. Globalitatea și disponibilitatea creează un nivel înalt de eterogenitate.

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

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

Caracteristici asociate dezvoltării

Echipa de dezvoltare

Caracterul multidisciplinar – combinație între publicistica tipărită și dezvoltarea software, marketing și știința calculatoarelor, artă și tehnologie

Disciplina dominantă este dependentă de tipul de aplicație web

Media de vârstă scăzută – dezvoltatori tineri și mai puțin experimentați

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

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

Echipa de dezvoltare

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

Caracterul multidisciplinar. Aplicațiile web pot fi caracterizate ca o combinație între publicistică și dezvoltarea software, marketing și știința calculatoarelor, artă și tehnologie. De aceea, dezvoltarea aplicațiilor web trebuie percepută ca o abordare multidisciplinară ce necesită cunoștințe și expertiză din diferite domenii. Pe lângă experții IT responsabili de implementarea tehnică a sistemului, trebuie să fie angajați experți în hipertext și proiectanți pentru proiectarea hipertextului și prezentării, în timp ce experții în domeniu trebuie să fie responsabili pentru conținut. Se observă deci o varietate mai mare a competențelor și cunoștințelor în echipa de dezvoltare față de dezvoltarea software tradițională.

Care disciplină va dominantă depinde de tipul de aplicație web. De exemplu, aplicațiile comerț electronic sunt bazate mai mult pe baze de date tradiționale și expertiză în programare, în timp ce dezvoltarea unei expoziții virtuale va pune mai mult accent pe expertiza în domeniu și în proiectare.

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

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

Infrastructura tehnică

Eterogenitatea – două componente externe: server și browser.

Imaturitate – creșterii presiunii de a ajunge pe piață

Procese

procesul de dezvoltare este influențat de flexibilitate și paralelism.

Infrastructura tehnică

Eterogenitatea și imaturitatea componentelor folosite sunt caracteristici importante ale infrastructurii tehnice a aplicațiilor web.

Eterogenitatea. Dezvoltarea aplicațiilor web depinde de două componente externe: server și browser. În timp ce serverul web poate fi configurat și folosit după cum doresc programatorii aplicației, browserele web ale utilizatorilor și preferințele lor individuale nu pot fi influențate. Situația este complicată și de diferitele versiuni de browser și interacțiunea lor cu plugin-urile.

Imaturitatea. Datorită creșterii presiunii de a ajunge pe piață cât mai rapid, componentele utilizate în aplicațiile web sunt deseori imature – au bug-uri sau lipsuri în privința funcționalității.

Procesul

Procesul de dezvoltare este influențat de flexibilitate și paralelism.

– Flexibilitatea. În dezvoltarea aplicațiilor web aderarea la un plan de proiect rigid și predefinit este imposibilă; o reacție flexibilă la modificarea condițiilor este vitală.

– Paralelismul. Datorită necesității de a dezvolta aplicațiile web într-un timp scurt și faptului că ele pot fi deseori împărțite în componente autonome (de exemplu autentificare, funcție de căutare, notificarea știrilor), majoritatea aplicațiilor web sunt dezvoltate în paralel de diferite subgrupuri ale echipei de dezvoltare. Spre deosebire de dezvoltarea software-ului tradițional, aceste subgrupuri sunt structurate în funcție de componente și nu în funcție de expertiza membrilor proiectului (de exemplu dezvoltatori GUI, modelatori de date etc.).

Integrarea

Integrarea internă – aplicațiile web trebuie integrate cu sistemele de moștenire existente când conținutul existent (de ex. cataloagele de produse) va fi făcut disponibil aplicației web

Integrarea externă – Integrarea conținutului și a servicilor aplicațiilor web externe

Integrarea internă. Aplicațiile web trebuie integrate frecvent cu sistemele de moștenire existente când conținutul existent (de ex. cataloagele de produse) va fi făcut disponibil prin intermediul unei aplicații web.

Integrarea externă. Integrarea conținutului și a serviciilor aplicațiilor web externe reprezintă o caracteristică specială a aplicațiilor web. Dintre particularitățile integrării pe web menționăm:

– existența unui număr mare de surse care se schimbă frecvent și au un grad înalt de autonomie în ceea ce privește disponibilitatea și evoluția schemei;

– se cunosc puține detalii privitoare la proprietățile acestor surse (ex. conținutul sau funcționalitățile lor);

– sursele diferite sunt adesea foarte eterogene la diverse nivele (nivelul datelor, schemei sau modelului de date).

Integrarea serviciilor externe (de ex. în aplicațiile web orientate pe portaluri) se bazează pe forma de dezvoltare din ce în ce mai comună a furnizării și utilizării serviciilor web. În acest context, un serviciu web este o componentă reutilizabilă cu o interfață și funcționalitate foarte clar definite. Interacțiunea diferitelor servicii web, evitând efectele secundare nedorite, și garantarea calității serviciilor sunt câteva dintre problemele relevante ale acestui context.

Evoluția

Schimbarea continuă = schimbare constantă a cerințelor sau condițiilor

– utilizatorii doresc ultimile aplicații web;

– instrumentele utilizate sunt condiționate de tehnologie

Presiunea competiției

Ritmul rapid de dezvoltare – presiunea timpului

Evoluția

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

Schimbarea continuă

Aplicațiile web se modifică rapid și sunt în consecință într-o evoluție permanentă datorită schimbării constante a cerințelor sau condițiilor Scharl, A., Evolutionary Web Development – Automated Analysis, Adaptive Design, and Interactive Visualization of Commercial Web Information Systems, Springer-Verlag, 2000

. Schimbarea rapidă și permanentă a tehnologiilor web și a standardelor în particular necesită o adaptare continuă a aplicațiilor web la acestea. Această schimbare are două cauze:

– utilizatorii doresc cele mai noi aplicații web;

– instrumentele utilizate sunt condiționate de tehnologie.

Schimbările constante ale cerințelor și condițiilor reprezintă o caracteristică esențială a aplicațiilor web, acestea putând afecta toate cele trei dimensiuni ale unei aplicații web – produsul însuși, utilizarea acestuia și, în particular, dezvoltarea lui.

Presiunea competiției

Presiunea competiției extrem de ridicate de pe web, presiunea de lansare rapidă pe piață și necesitatea unei prezențe pe web sporesc nevoia unui ciclu de viață scurt al produsului, al unui ciclu de dezvoltare extrem de scurt și nu lasă loc pentru un proces de dezvoltare sistematic. Prezența imediată pe web este considerată mai importantă decât perspectiva pe termen lung.

Ritmul rapid de dezvoltare

Presiunea timpului în dezvoltarea aplicațiilor web se datorează schimbărilor rapide de pe web, ce duc scurtarea duratei de viață a aplicațiilor web sau la actualizări frecvente.

În timp ce în aplicațiile software tradiționale evoluția are loc sub forma seriilor planificate de versiuni, în aplicațiile web aceasta este continuă. Aplicațiile web sunt într-o continuă întreținere, ciclul schimbării fiind deseori de doar câteva zile sau săptămâni.

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

– dezvolt area produsului;

– aspecte privind calitatea.

Elementul de bază este partea introductivă prezentată anterior, web-ul social și web-ul semantic fiind "acoperișul", perspectiva de viitor.

Principalele provocãri ale proiectãrii cerinþelor aplicaþiilor web includ: parteneri indisponibili, schimbarea dinamicã a condiþiilor, medii de acþiune impredictibile, importanþa deosebitã a calitãþii ºi frecventa lipsã de experienþã în utilizarea tehnologiilor.

Modelarea se referã la dezvoltarea aplicaþiilor web pe bazã de modele, cu focalizare asupra conþinutului ºi hipertextului, ºi implicã o dezvoltare de sus în jos. Este necesarã o prezentare a metodelor existente pentru modelarea aplicaþiilor web ºi a unor instrumente de modelare care sã ajute proiectantul în alegerea metodei adecvate.

Arhitectura este un factor decisiv pentru o aplicaþie web de calitate. Performanþele slabe, întreþinerea neadecvatã ºi disponibilitatea redusã se datoreazã deseori unei arhitecturi necorespunzãtoare. Folosirea arhitecturilor flexibile, pe mai multe nivele, oferirea unui conþinut multimedia ºi integrarea aplicaþiilor ºi depozitelor de date existente influenþeazã pozitiv dezvoltarea aplicaþiilor web.

Proiectarea bazatã pe tehnologie descrie alternativa dezvoltãrii de jos în sus a aplicaþiilor web. Proiectarea hipertext/hipermedia, a informaþiei ºi a software-ului orientat-obiect nu oferã o soluþie satisfãcãtoare, fiind necesare abordãri de proiectare specifice web-ului, cum ar fi:

– proiectarea vizualã, în care aspectul este hotãrâtor ºi în care se iau în considerare multiple interfeþe utilizator;

– proiectarea interacþiunii – a cãilor de navigare ºi a "dialogului" cu componentele;

– proiectarea funcþionalã fixeazã esenþa aplicaþiei web.

Pe mãsurã ce proiectarea fiecãrui nivel devine mai concretã, trebuie utilizate instrumente pentru proiectarea hipertext-ului, informaþiei ºi software-ului.

Tehnologiile au anumite caracteristici care trebuie cunoscute în detaliu, pentru a putea fi utilizate în etapa adecvatã. Implementarea aplicaþiilor web necesitã o cunoaºtere aprofundatã a diferitelor tehnologii ºi a interacþiunii acestora cu o anumitã arhitecturã. Astfel, este necesarã o prezentare a diferitelor tehnologii ºi o exemplificare a interacþiunii ºi utilizãrii lor împreunã cu anumite arhitecturi. Recomandãrile consorþiului web (W3C) necesitã o atenþie deosebitã.

Metodele actuale de testare se focalizeazã pe cerinþele funcþionale ale aplicaþiilor web. Multe dintre cerinþele de calitate non-funcþionale importante pentru utilizatori (uºurinþa în folosire, siguranþa ºi securitatea) nu sunt luate în considerare suficient.

Exploatarea ºi întreþinerea: multe sarcini care ar trebui rezolvate în timpul fazei de proiectare ºi dezvoltare sunt deseori amânate spre faza de exploatare ºi întreþinere, ceea ce creºte ºi mai mult importanþã acestei etape. Existã de asemenea o tendinþã de a automatiza sarcinile cât timp sistemul este operaþional. De exemplu, sarcini de rutinã pentru întreþinerea conþinutului sunt în mare mãsurã automatizate, eliminându-se astfel sursele de erori ºi garantând o exploatare stabilã.

Uºurinþa în folosire, performanþa ºi securitatea reprezintã trei dintre aspectele de calitate ale aplicaþiilor web. Uºurinþa în folosire subliniazã faptul cã aplicaþiile web greu de utilizat nu sunt acceptate de cãtre utilizatori. Noile dezvoltãri precum aplicaþiile web mobile ºi facilitãþile speciale pentru utilizatorii cu deficienþe pun un accent deosebit pe uºurinþa în folosire; aceasta nu poate fi dobânditã într-o singurã etapã ci trebuie luatã în considerare pe durata întregului proces de dezvoltare.

Performanþa implicã folosirea unor metode, începând cu cele de modelare pentru verificarea performanþei ºi terminând cu cele de mãsurare. Dintre metodele de modelare menþionãm modelele operaþionale ºi modelele de simulare generale. Metodele de mãsurare necesitã accesul la un sistem existent ºi au avantajul cã sistemul poate fi urmãrit în timp real. Dacã sunt identificate probleme de performanþã prin mãsurare sau modelare, aceasta va trebui îmbunãtãþitã prin extinderea hardware-ului, optimizarea software-ului, prin caching sau replicãri.

Securitatea implicã abordarea unor probleme privind confidenþialitatea datelor, prevenirea interceptãrii mesajelor schimbate pe canalele accesibile public ºi oferirea unor servicii de încredere.

Web-ul social indică o formă îmbunătățită a World Wide Web, susținătorii lui sugerând faptul că tehnologii precum weblog-urile, wiki-urile, podcast-urile, feed-urile RSS, software-ul social, API-urile web, standardele și serviciile web online implică o schimbare semnificativă a modului în care Internetul este utilizat. Generații diferite de oameni și-au schimbat dramatic percepția și participarea la web, în ultimul timp acesta fiind privit ca un mediu de comunicare, o platformă de socializare, un mecanism de stocare a jurnalelor sau o enciclopedie în continuă expansiune.

Web-ul semantic reprezintã urmãtorul pas logic în evoluþia web-ului. Pentru a se realiza acest pas, în primul rând, paginile web trebuie extinse (fie manual fie prin intermediul unor instrumente) cu etichete semantice, cu ajutorul cãrora paginile vor avea un conþinut interpretabil de sistemele de calcul. În al doilea rând, utilizatorii care cautã informaþia ar trebui sã foloseascã agenþi software inteligenþi capabili sã proceseze paginile web care au aceastã facilitate. În cele din urmã, producãtorii de conþinut ºi agenþii software trebuie sã adopte un vocabular comun al conceptelor – o ontologie. Web-ul semantic este încã la începuturi, dar opinia generalã este cã acesta implicã tehnologii promiþãtoare care vor influenþa profund mediul de lucru al "lucrãtorilor în domeniul cunoaºterii".

Proiectarea cerințelor aplicațiilor web

activități care sunt critice pentru proiectarea web

>Cerințe incomplete, ambigue sau incorecte

>Principii, metode și utilitarele pentru extragerea, descrierea, validarea și managementul cerințelor

Proiectarea cerințelor implică activități care sunt esențiale pentru succesul proiectării web. Cerințe incomplete, ambigue sau incorecte pot conduce la dificultăți majore în dezvoltare sau chiar la anularea proiectelor. Proiectarea cerințelor presupune luarea în discuție a principiilor, metodelor și utilitarelor pentru extragerea, stabilirea, descrierea, validarea și managementul cerințelor.

Deși cerințele joacă un rol cheie în dezvoltarea aplicațiilor web, ele sunt deseori descrise în mod neadecvat, consecințele tipice fiind acceptarea scăzută din partea utilizatorilor, eșecul planificării sau arhitecturi software neadecvate.

Există un acord general privitor la importanța cerințelor pentru dezvoltarea cu succes a sistemelor, de-a lungul anilor oferindu-se numeroase standarde, abordări, modele, limbaje de descriere și utilitare.

În continuare vom discuta principiile proiectării cerințelor pentru dezvoltarea aplicațiilor web și vom studia modul în care metodele existente de proiectare a cerințelor pot fi adaptate la particularitățile proiectelor web.

Obiectivele individuale și așteptările părților interesate

Părțile interesate pentru aplicațiile web – autorii de conținut, experții în domeniu, experți în caracterul utilizabil sau profesioniștii în domeniul marketing-ului

Obiective > constrângerea clientului, obiectiv de calitate a clientului, perspectiva tehnologică a dezvoltatorilor, obiectiv de calitate al utilizatorului, obiectiv de calitate al clientului, obiectiv al clientului privind ușurința în folosire, obiectiv al utilizatorului privind capacitatea

Obiectivele individuale și așteptările părților interesate reprezintă punctul de pornire al procesului de stabilire a cerințelor. Părțile interesate sunt oameni sau organizații care au o influență directă sau indirectă asupra cerințelor în dezvoltarea sistemului[1]. Părți interesate importante sunt clienții, utilizatorii și dezvoltatorii; cele tipice pentru aplicațiile web includ autorii de conținut, experții în anumite domenii, profesioniștii în marketing sau în ușurința în folosire. Obiectivele și așteptările părților interesate sunt de obicei diverse, după cum demonstrează și următoarele exemple:

– aplicația web trebuie să fie disponibilă online până la 1 septembrie 2009 (constrângere din partea clientului);

– aplicația web trebuie să suporte minim 2500 utilizatori concurenți (obiectiv de calitate al clientului);

– PHP trebuie folosit ca platformă de dezvoltare (perspectiva tehnologică a dezvoltatorilor);

– toate datele clienților trebuie trimise securizat (obiectiv de calitate al utilizatorului);

– interfața utilizator trebuie să suporte layout-uri pentru diferite grupuri de clienți (obiectiv de calitate al clientului);

– orice utilizator trebuie să poată găsi produsul dorit în mai puțin de trei minute (obiectiv al clientului privind ușurința în folosire);

– utilizatorul trebuie să aibă posibilitatea să selecteze o iconiță care să afișeze articolele incluse în coșul de cumpărături în orice moment (obiectiv al utilizatorului privind capacitatea).

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

Cerința – descrie o proprietate care trebuie îndeplinită sau un serviciu care trebuie furnizat de către un sistem. IEEE 610.12 definește o cerință ca:

– o condiție sau aptitudine necesară unui utilizator pentru a rezolva o problemă sau a îndeplini un obiectiv ;

– o condiție sau capacitate care trebuie îndeplinită sau posedată de un sistem sau componentă a sa pentru a satisface un contract, un standard, o specificație sau alte documente solicitate formal ;

Identificarea și implicarea părților interesate reprezintă obiectivele principale ale managementului proiectului. O mare provocare o constituie înțelegerea și aplanarea frecventelor conflicte privind obiectivele, așteptările și ordinea de zi. De exemplu, pot exista conflicte între setul dorit de funcționalități și bugetul disponibil; între setul de funcționalități, programul proiectului și calitatea dorită; sau între tehnologia de dezvoltare dorită și aptitudinile și experiențele dezvoltatorilor. Înțelegerea și rezolvarea din timp a acestor contradicții și conflicte este esențială și are o contribuție importantă la managementul riscului. Au fost propuse diferite tehnici de negociere pentru a susține acest obiectiv, dezvoltarea unei viziuni comune între părțile interesate fiind o condiție pentru succes.

Obiectivele părților interesate sunt deseori reprezentate informal, oferind baza pentru cerințele derivate mai detaliate.

O cerință descrie o proprietate care trebuie îndeplinită sau un serviciu care trebuie furnizat de către un sistem. IEEE 610.12 definește o cerință ca:

– o condiție sau aptitudine necesară unui utilizator pentru a rezolva o problemă sau a îndeplini un obiectiv;

– o condiție sau capacitate care trebuie îndeplinită sau posedată de un sistem sau componentă a sa pentru a satisface un contract, un standard, o specificație sau alte documente solicitate formal.

Cerințele sunt clasificate deseori în cerințe funcționale, cerințe non-funcționale și constrângeri[1]. Cerințele funcționale definesc capacitățile și serviciile unui sistem, iar cerințele non-funcționale descriu nivelele de calitate dorite („Cât este de securizat?”, „Cât este de ușor de folosit?”). Constrângerile sunt condiții non-negociabile care afectează un proiect. Exemple de constrângeri sunt nivelul de calificare a echipei de dezvoltare, bugetul disponibil, data livrării sau infrastructura de calculatoare existentă în zona de dezvoltare. Toate cerințele și constrângerile dintre contractor și client sunt sintetizate într-un document.

Abordările uzitate în proiectarea cerințelor pun accentul pe identificarea și implicarea părților interesate, negocierea și descoperirea cerințelor pe bază de scenarii, analizarea contextului organizațional și social anterior modelării detaliate și definirea clară a constrângerilor care afectează dezvoltarea[2].
[1] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999

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

Proveniența cerințelor

Cerințe – funcționale

non-funcționale

constrângeri

Cerințele sunt clasificate deseori în cerințe funcționale, cerințe non-funcționale și constrângeri[1]. Cerințele funcționale definesc capacitățile și serviciile unui sistem, iar cerințele non-funcționale descriu nivelele de calitate dorite („Cât este de securizat?”, „Cât este de ușor de folosit?”). Constrângerile sunt condiții non-negociabile care afectează un proiect. Exemple de constrângeri sunt nivelul de calificare a echipei de dezvoltare, bugetul disponibil, data livrării sau infrastructura de calculatoare existentă în zona de dezvoltare. Toate cerințele și constrângerile dintre contractor și client sunt sintetizate într-un document.

Abordările uzitate în proiectarea cerințelor pun accentul pe identificarea și implicarea părților interesate, negocierea și descoperirea cerințelor pe bază de scenarii, analizarea contextului organizațional și social anterior modelării detaliate și definirea clară a constrângerilor care afectează dezvoltarea[1].

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

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

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

July, 2000, pp. 99–102

Activitățile proiectării cerințelor

Extragerea cerintelor și negocierea – rezultatul procesului de învățare și construirii pe bază de consens > metode și utilitare colaborative

Documentarea cerintelor – detaliere si formalism

Verificarea cerintelor și validarea –feedback-uri

Managementul cerințelor

Proiectarea cerințelor implică extragerea, documentarea, verificarea și validarea, dar și managementul cerințelor pe parcursul procesului de dezvoltare.

Extragerea cerințelor și negocierea

Lowe și Eklund[1] au demonstrat că cerințele nu pot fi colectate prin întrebări adecvate ci sunt rezultatul unui proces de învățare și de creare a unui consens. În acest proces comunicarea între părțile interesate este esențială, doar punerea în comun a expertizei lor putând duce la soluții acceptabile mutual. Un set larg de metode și utilitare de colaborare sunt disponibile pentru a facilita comunicarea și schimbul de informații în proiectarea cerințelor: tehnici de creativitate, metode bazate pe scenarii, interviuri sau analiza documentelor.

Documentarea cerințelor

Dacă părțile interesate ajung la un consens, acordurile dintre aceștia trebuie finisate și descrise într-un document al cerințelor, având un grad de detaliere și formalism adecvat contextului proiectului. Alegerea gradului adecvat de detaliere și formalism depinde de riscurile identificate ale proiectului și de experiența și aptitudinile presupușilor cititori. Descrierile informale precum relatările utilizatorilor și cele semi-formale precum cazurile de utilizare sunt relevante pentru proiectarea web.

Verificarea cerințelor și validarea

Cerințele trebuie validate („S-au specificat cerințele corecte?”) și verificate („S-au specificat corect cerințele?). Există o serie de metode convenționale pentru acest scop (cum ar fi revizuirile, verificările sau prototipizarea). În proiectarea web, deschiderea pe care o oferă Internetul facilitează noi forme de participare directă a utilizatorilor în validarea cerințelor (de exemplu prin colectarea online a feedback-urilor utilizatorilor)[2].

Managementul cerințelor

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

[1] Lowe, D. B., Eklund, J., Client Needs and the Design Process in Web Projects, Journal of Web Engineering, 1 (1), October, 2002, pp. 23–36

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

Cerințe specifice proiectării web

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

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

Caracterul schimbător al cerințelor și constrângerilor

Mediul operațional imprevizibil- modificarea lățimii de bandă

La suprafață, diferențele dintre proiectarea cerințelor pentru proiectarea web și proiectarea cerințelor pentru sistemele software tradiționale par a fi neglijabile. Deși există multe diferențe între dezvoltarea web și dezvoltarea software, există și multe similarități (de exemplu extragerea cerințelor). În cele ce urmează vom insista pe diferențele dintre acestea, pe baza caracteristicilor aplicațiilor web prezentate în capitolul anterior.

Caracterul multidisciplinar

Dezvoltarea aplicațiilor web necesită participarea experților din diferite discipline: experți multimedia, autori de conținut, arhitecți software, experți în uzabilitate, specialiști în baze de date sau experți într-un anumit domeniu. Eterogenitatea și caracterul multidisciplinar al părților interesate fac dificilă obținerea unui consens la definirea cerințelor, cu atât mai mult cu cât oamenii din diferite discipline vorbesc limbi și jargoane diferite.

Indisponibilitatea părților interesate

De multe ori părțile interesate, (cum ar fi potențialii utilizatori web), sunt necunoscute pe parcursul activităților de proiectare a cerințelor. Managementul proiectului trebuie să găsească reprezentanți potriviți care să ofere cerințe cât mai realiste. De exemplu, deseori există un spectru larg de posibili utilizatori în proiectele web și găsirea unui grup de reprezentanți adecvați este dificilă.

Caracterul schimbător al cerințelor și constrângerilor

Cerințele și constrângerile (ex. proprietățile platformelor de lucru sau protocoalele de comunicație) sunt adesea mai ușor de definit pentru sistemele software tradiționale comparativ cu aplicațiile web.

Aplicațiile web și mediul în care acestea funcționează sunt extrem de dinamice, din acest motiv cerințele și constrângerile fiind greu de stabilizat. Cele mai frecvente exemple de astfel de schimbări sunt inovațiile tehnologice cum ar fi introducerea de noi platforme și standarde de dezvoltare sau noi dispozitive pentru utilizatorii finali.

Mediul operațional imprevizibil

Mediul operațional al unei aplicații web este de asemenea foarte dinamic și greu de anticipat. Pentru dezvoltatori este dificil sau chiar imposibil să controleze factori importanți, decisivi pentru calitatea aplicației web percepută de utilizator. De exemplu, modificarea lățimii de bandă afectează timpul de răspuns pentru aplicațiile mobile dar acest lucru nu depinde de echipa de dezvoltare.

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

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

Impactul sistemelor de moștenire

Dezvoltarea aplicațiilor web este caracterizată prin integrarea componentelor software existente cum ar fi produsele comerciale autonome/universale sau software-ul open source. În particular, dezvoltatorii web se confruntă frecvent cu integrarea sistemelor de moștenire, de exemplu atunci când vor să facă accesibile pe web sistemele IT existente într-o companie. Dezvoltatorii sunt deseori îndemnați să utilizeze componentele existente și din motive economice. Componentele care trebuie integrate influențează cerințele și arhitectura viitorului sistem. În aceste situații o abordare în cascadă în care arhitectura sistemului derivă din cerințe nu va avea succes, deoarece componentele, infrastructura și serviciile existente stabilesc o serie de posibilități și limitări pentru dezvoltatori (atunci când se identifică și definesc cerințele, dezvoltatorii web trebuie să fie conștienți de arhitectura sistemului și de constrângerile arhitecturale. O abordare iterativă precum cea propusă de modelul Twin Peaks este mai adecvată într-un asemenea context (vezi figura).

Importanța aspectelor calitative

Aspectele calitative sunt decisive pentru succesul aplicațiilor web. Exemple: performanța unei aplicații web, securitatea în sistemele de e-commerce, disponibilitatea, ușurința în folosire. În ciuda importanței aspectelor calitative, dezvoltatorii trebuie să se confrunte cu faptul că specificarea exactă a cerințelor de calitate este dificilă înaintea construirii sistemului. De exemplu timpul de răspuns al unei aplicații web depinde de mulți factori, care nu pot fi controlați de echipa de dezvoltare. O abordare realizabilă pentru definirea cerințelor de calitate implică specificarea criteriilor pentru testul de acceptare, specificând dacă o cerință a fost îndeplinită sau nu. (vezi de asemenea un exemplu al unui criteriu de acceptare pentru o cerință a calității în tabelul 2-1).

Specificații de formatare

Comentariu

Identificator unic

Element din taxonomia cerinței

O explicație scurtă în limbaj natural

Explică de ce este importantă cerința

O condiție măsurabilă care trebuie îndeplinită pentru acceptare

O expresie a importanței și fezabilității cerinței

Lista cerințelor care depind de această cerință

Lista cerințelor care sunt în conflict cu această cerință

Trimiteri la informații adiționale

Un număr al reviziei pentru a documenta istoricul dezvoltării

Calitatea interfeței utilizator – adăugarea unor prototipuri pentru scenariile importante ale aplicației

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

Lipsa de experiență a dezvoltatorilor – tehnologii de bază din aplicațiile web relativ noi

Date fixe de livrare – termen limită > negocierea și stabilirea unei ordini de prioritate a cerințelor

Calitatea interfeței utilizator

Calitatea interfeței utilizator este un alt aspect hotărâtor pentru succesul aplicațiilor web. Când realizează aplicații web dezvoltatorii trebuie să fie conștienți de următorul fenomen: utilizatorii nu vor fi capabili să înțeleagă și să aprecieze o aplicație web uitându-se la modele și specificații abstracte; ei trebuie să experimenteze. De aceea, este foarte important să se completeze definirea și descrierea cerințelor prin adăugarea unor prototipuri pentru scenariile importante ale aplicației[1].

Calitatea conținutului

Majoritatea metodelor tradiționale de proiectare a cerințelor neglijează conținutul web, deși este un aspect extrem de important al aplicațiilor web. Pe lângă problemele legate de tehnologia software, dezvoltatorii trebuie să aibă în vedere conținutul și în special crearea și întreținerea acestuia. În contextul proiectării cerințelor este esențială specificarea nivelul dorit de calitate a conținutului. Cele mai importante caracteristici de calitate includ acuratețea, obiectivitatea, credibilitatea, relevanța, actualitatea, caracterul complet sau claritatea. Sistemele de management al conținutului (CMS) au devenit importante și permit reprezentarea concisă și consistentă a conținutului prin separarea conținutului de layout și oferirea utilitarelor de editare a conținutului.

Lipsa de experiență a dezvoltatorilor

Majoritatea tehnologiilor de bază din aplicațiile web sunt relativ noi. Lipsa de experiență cu instrumentele de dezvoltare, standardele și limbajele acestor tehnologii pot conduce la estimări greșite când se ia în discuție fezabilitatea și costul implementării cerințelor.

Datele fixe de livrare

Multe proiecte web au o dată fixă de livrare, toate activitățile și deciziile trebuind să fie finalizate până la un termen limită. Negocierea și stabilirea unei ordini de prioritate a cerințelor sunt esențiale în aceste condiții.

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

Principii pentru proiectarea cerințelor aplicațiilor web

Principiile derivă din stabilitatea modelului în spirală win-win

Înțelegerea contextului sistemului – obiectivele afacerii clientului

Implicarea părților interesate – cooperarea acestora activă și directă pentru identificarea și negocierea cerințelor, situații câștig-pierdere conduc adesea la situații pierdere-pierdere

În această secțiune vom descrie principiile de bază ale proiectării cerințelor pentru aplicațiile web. Aceste principii derivă din stabilitatea modelului în spirală în care câștigă toți partenerii (modelul win-win), un model de ciclu de viață iterativ și orientat pe risc care pune accentul pe implicarea părților interesate și pe extragerea și punerea de acord asupra cerințelor. Modelul în spirală win-win a influențat multe modele bazate pe procese, inclusiv Procesul Unificat Rațional (RUP) de la IBM.

Dezvoltatorii web trebuie să aibă în vedere următoarele principii pe parcursul activităților de proiectare a cerințelor:

Înțelegerea contextului sistemului

Multe aplicații web sunt încă dezvoltate ca soluții tehnice izolate, fără o înțelegere a rolului și impactului acestora într-un context general. O aplicație web nu poate fi o finalitate prin ea însăși; ea trebuie să țină cont de obiectivele afacerii clientului. Pentru ca aplicația web să aibă succes este important să clarificăm contextul sistemului (de exemplu prin analizarea și descrierea proceselor de afaceri existente) și motivul pentru care sistemul va fi dezvoltat (“Pentru ce facem acest lucru?”). Dezvoltatorii trebuie să înțeleagă modul în care sistemul este implementat în mediul său. Analiza afacerii poate stabili valoarea unei aplicații web în raport cu resursele pe care le utilizează cerințele. Înțelegerea contextului sistemului ajută și la identificarea părților interesate, familiarizarea cu scopul aplicației și analizarea constrângerilor[1].

Implicarea părților interesate

Părțile interesate sau reprezentanții lor se află în centrul proiectării cerințelor, iar cooperarea acestora activă și directă pentru identificarea și negocierea cerințelor este importantă pentru fiecare fază a proiectului. Managerii de proiect trebuie să evite situațiile în care participanții la proiecte individuale câștigă pe seama altora. S-a demonstrat că asemenea situații câștig-pierdere evoluează adesea în situații pierdere-pierdere, determinând în final eșecul întregului proiect.

Obiectivele, așteptările și cerințele părților interesate trebuie stabilite și negociate în mod repetat pentru a se adapta schimbărilor dinamice care apar în proiecte. Anterior am arătat că indisponibilitatea părților interesate și caracterul multidisciplinar sunt specifice proiectării cerințelor pentru ingineria web. Aceste caracteristici conduc la stabilirea următoarelor cerințe pentru contextul aplicațiilor web:

identificarea părților interesate sau a reprezentanților acestora

înțelegerea obiectivelor și așteptărilor părților interesate

negocierea perspectivelor, experiențelor și cunoștințelor (caracter multidisciplinar).

Metodele și utilitarele de proiectare a cerințelor trebuie să fie în concordanță cu aceste cerințe și trebuie să contribuie la schimbul efectiv de cunoștințe dintre participanții la proiect, să permită un proces de instruire în echipă, dezvoltarea unei viziuni comune a părților interesate și să ajute la detectarea din timp a cerințelor contradictorii.
[1] Biffl, S., Aurum, A., Boehm, B. W., Erdogmus, H., Gr¨unbacher, P., Value-based Software Engineering, Springer-Verlag, September 2005

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

Focalizarea pe arhitectura sistemului – ințelegerea soluțiilor tehnice împreună cu posibilitățile și limitările lor sunt esențiale

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

Definirea iterativă a cerințelor

Abordarea în cascadă a definirii cerințelor nu funcționează în medii dinamice, iar cerințele trebuie dobândite în mod iterativ în dezvoltarea aplicațiilor web. Cerințele trebuie să fie în concordanță cu alte rezultate ale dezvoltării (arhitectură, interfață utilizator, conținut, cazuri de testare etc.). La inițierea proiectului, cerințele cheie sunt de obicei definite la un nivel înalt de abstractizare. Aceste cerințe preliminare pot fi utilizate pentru a dezvolta arhitecturi fezabile, scenarii de utilizare a sistemului și planurile inițiale ale proiectului. Pe măsură ce proiectul progresează rezultatele dezvoltării pot fi perfecționate gradat prin specificarea unor termeni mai concreți, asigurând în continuare consistența lor. O abordare iterativă este necesară, în special într-un mediu în care cerințele și constrângerile sunt schimbătoare, pentru a putea reacționa într-un mod flexibil pe măsură ce proiectul evoluează. Dacă echipa de dezvoltare primește termeni limită ficși, atunci o abordare de dezvoltare iterativă permite selectarea cerințelor cheie care trebuie implementate primele.

Focalizarea pe arhitectura sistemului

Tehnologiile existente și soluțiile de moștenire au un impact sporit asupra cerințelor aplicațiilor web. Înțelegerea soluțiilor tehnice împreună cu posibilitățile și limitările lor este esențială. Extragerea cerințelor nu poate avea loc fără a se ține seama de arhitectură, în special la definirea cerințelor. Luarea în considerare a arhitecturii sistemului permite dezvoltatorilor să înțeleagă mai bine impactul soluțiilor existente asupra cerințelor și să estimeze fezabilitatea acestora. Modelul Twin-Peaks (vezi figura) propune atât perfecționarea cerințelor cât și a arhitecturii sistemului într-o manieră iterativă, sporind continuu nivelul de detaliere.

Riscuri

Problemele nedetectate, cele nerezolvate și conflictele dintre cerințe reprezintă riscuri majore ale proiectului. Problemele obișnuite de risc sunt integrarea componentelor existente în aplicația web, anticiparea aspectelor de calitate a sistemului sau lipsa de experiență a dezvoltatorilor. De aceea evaluarea riscului trebuie realizată pentru toate cerințele, iar riscurile identificate trebuie controlate pe parcursul proiectului, pentru a ne asigura că nu sunt urmate alternativele riscante pentru sistem. Diminuarea riscului trebuie realizată cât mai devreme posibil, putând include de exemplu prototipizarea, lansarea rapidă a unor versiuni ale aplicației web pentru a colecta feedback-ul utilizatorilor sau încorporarea precoce a componentelor externe pentru a evita problemele majore ale integrării tardive.

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

Ce tipuri de cerințe sunt importante pentru aplicația web?

– Cum vor fi descrise și documentate cerințele pentru aplicația web?

– Care sunt gradele utile ale detalierii și formalismului?

– Trebuie avută în vedere folosirea utilitarelor? Care dintre acestea sunt potrivite pentru nevoile specifice ale proiectului?

În prezent sunt disponibile numeroase metode, ghiduri, notații, cataloage și utilitare pentru toate activitățile de proiectare a cerințelor. Totuși, dezvoltatorii trebuie să evite o abordare unitară, metodele de proiectare a cerințelor trebuind adaptate permanent specificului proiectării web și situațiilor care apar în anumite proiecte. Principiile descrise anterior ne conduc la definirea unei abordări de proiectare a cerințelor specifică proiectelor pentru web. Dezvoltatorii trebuie să clarifice următoarele aspecte pe parcursul procesului de adaptare:

– Ce tipuri de cerințe sunt importante pentru aplicația web?

– Cum vor fi descrise și documentate cerințele pentru aplicația web? Care sunt gradele utile ale detalierii și formalismului?

– Trebuie avută în vedere folosirea utilitarelor? Care dintre acestea sunt potrivite pentru nevoile specifice ale proiectului?

Tipuri de cerințe

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

Cerințe privind conținutul – specifică conținutul care trebuie să-l prezinte aplicația web

Cerințe privind calitatea – nivelul calității serviciilor

Funcționalitatea – prezența funcțiilor > concordanța, precizia, interoperabilitatea, complianța și securitatea

Siguranța – menținere nivel de performanță > maturitatea, toleranța la erori și capacitatea de recuperare

Ușurința în folosire – efortul necesar pentru a utiliza un produs software > ușurința în înțelegere, învățare și operare

Eficiența – raportul dintre nivelul de performanță și resursele utilizate > comportamentul în timp, comportamentul resurselor

Întreținerea – efortul pentru a implementa modificări prestabilite > posibilitatea de analiză, schimbare, stabilitate și testare

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

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

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

Cerințe funcționale

Cerințele funcționale specifică capacitățile și serviciile pe care un sistem ar trebui să le ofere (de exemplu transferul de bani într-o aplicație de online banking). Cerințele funcționale sunt frecvent descrise utilizând scenariile de utilizare de caz și specificațiile de formatare[2].

Cerințe privind conținutul

Cerințele privind conținutul specifică conținutul care ar trebui prezentat de aplicația web. Conținutul poate fi descris, de exemplu, sub forma unui glosar.

Cerințe privind calitatea

Cerințele privind calitatea descriu nivelul de calitate al serviciilor și capacităților și specifică proprietăți importante ale sistemului cum ar fi securitatea, performanța sau ușurința în folosire[3]. Standardul internațional ISO/IEC 9126 definește un model independent de tehnologie pentru calitatea softului, care cuprinde 6 caracteristici de calitate, fiecare având propriile trăsături.

Cele șase caracteristici sunt:

• Funcționalitatea – descrie prezența funcțiilor care îndeplinesc proprietățile definite. Trăsături le sunt concordanța, precizia, interoperabilitatea, complianța și securitatea.

• Siguranța – descrie capacitatea unui produs software de a-și menține nivelul de performanță în anumite condiții pe o perioadă definită de timp. Trăsăturile sunt maturitatea, toleranța la erori și capacitatea de recuperare.

• Ușurința în folosire – descrie efortul necesar pentru a utiliza un produs software și evaluarea sa individuală de către un grup de utilizatori definit sau presupus. Trăsături: ușurința în înțelegere, învățare și operare.

• Eficiența – descrie raportul între nivelul de performanță al unui produs software și resursele pe care acesta le utilizează în anumite condiții. Trăsături: comportamentul în timp, comportamentul resurselor.

• Întreținerea – descrie efortul necesar pentru a implementa modificări prestabilite într-un produs software. Trăsături: posibilitatea de analiză, schimbare, stabilitate și testare.

• Portabilitatea – descrie capacitatea unui produs software de a fi mutat dintr-un mediu în altul. Trăsături: capacitatea de adaptare, instalare, potrivire și înlocuire.

Au fost făcute diverse încercări de către cercetători pentru a extinde acest model de bază la caracteristicile specifice web-ului. În capitolele ulterioare vom insista asupra ușurinței în folosire, performanței și securității, care reprezintă aspecte de calitate esențiale pentru succesul aplicațiilor web.
[1] Robertson, S., Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999

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

[3] Chung, L., Nixon, B. A., Yu, E., Mylopoulos, J., Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000

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

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

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

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

Cerințele mediului sistemului

Aceste cerințe descriu modul în care o aplicație web este inclusă în mediul țintă și interacționează cu componentele externe, incluzând de exemplu sistemele de moștenire, componentele comerciale autonome sau un hardware special. De exemplu, dacă o aplicație web se presupune că va fi disponibilă global, atunci în cerințele de mediu trebuie să se specifice detaliile.

Cerințele interfeței utilizator

Deoarece se presupune că utilizatorii web folosesc aplicația web fără o instruire formală, ghidarea intuitivă și auto-explicativă a utilizatorilor este esențială pentru acceptarea aplicației. Cerințele privitoare la interfața utilizator definesc modul în care o aplicație web interacționează cu diferite tipuri de clase de utilizatori. Principalele aspecte sunt hipertextul (structura de navigare) și prezentarea (interfața utilizator). Detaliile de navigare și prezentare sunt definite în mod normal în procesul de modelare, dar deciziile inițiale privind proiectarea interfeței utilizator trebuie luate pe parcursul extragerii cerințelor. Prototipurile sunt cele mai potrivite în această situație. Constantine și Lockwood sugerează că utilizatorii trebuie să coopereze în proiectarea scenariilor pentru anumite sarcini. Proiectarea centrată pe utilizare se bazează pe crearea și reglarea/îmbunătățirea iterativă a modelelor pentru roluri, sarcini și interacțiuni[1].

Cerințe posibile pe parcursul dezvoltării

Produsele software în general și aplicațiile web în particular sunt subiectul unei evoluții și îmbunătățiri continue. Din acest motiv dezvoltatorii web trebuie să anticipeze cerințele care ar putea apare după folosirea planificată pe termen scurt a aplicației. De exemplu, o cerință de calitate care solicită suplimentarea cu 5000 de utilizatori concurenți în doi ani trebuie avută în vedere, prin definirea unei arhitecturi a sistemului scalabile. Cerințele ce pot apărea în evoluție sunt posibile pentru toate tipurile de cerințe discutate (de exemplu capacitățile viitoare, cerințele de securitate viitoare).

Constrângerile proiectului

Constrângerile proiectului nu sunt negociabile pentru părțile interesate ale proiectului și includ de obicei bugetul și planul, limitările tehnice, standardele, tehnologia de dezvoltare folosită, regulile de desfășurare, aspectele de întreținere, constrângerile operaționale și aspectele legale sau culturale care afectează proiectul.
[1] Constantine, L., Lockwood, L., Software for Use: A Practical Guide to Models and Methods for Usage-Centered Design, ACM Press, 2001

Notații

Relatările – descrieri colocviale ale proprietăților dorite > exemplu de scenariu

Cerințele specificate – simple specificații în limbajul natural

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

Specificațiile formale – scrise într-un limbaj care utilizează o sintaxă și semantică definite formal

Sunt disponibile variate notații pentru specificarea cerințelor la diferite nivele de detaliere și formalitate. Exemple: relatări, specificații de formatare, specificații formale.

Relatările

Relatările – sunt descrieri colocviale ale proprietăților dorite; ele sunt utilizate pentru a stabili o înțelegere între clienți și dezvoltatori. Exemple: relatările utilizatorilor din Extreme Programming[1]. Relatarea unui utilizator este formulată de către un client folosind terminologia și limbajul propriu și descrie problemele pe care sistemul ar trebui să le rezolve pentru acel client.

Un exemplu de scenariu din perspectiva clientului poate fi următorul: Un utilizator verifică produsele adăugate în coșul de cumpărături online. Datele de intrare sunt validate atunci când utilizatorul face clic pe <Continuare>. Dacă nu sunt găsite erori comanda va fi acceptată și va fi trimisă utilizatorului o confirmare prin e-mail.

Cerințele specificate

Cerințele specificate sunt simple specificații în limbajul natural. Fiecare cerință are un identificator unic. Un bun exemplu este descrierea unui element de tip dată specificat în IEEE/EIA-J-STD- 016.

Specificațiile de formatare

Specificațiile de formatare utilizează o sintaxă precis definită, dar permit și descrieri în limbajul natural. Exemple: descrierile de utilizare de caz din UML (Unified Modeling Language), RDD-100 Requirements Specification Language, ghidurile MBASE SSRD sau Volere Shell.

Tabelul 2.1 prezintă un exemplu al unei specificații de formatare, principalele atribute fiind: descriere, prioritate, raționament și istoricul versiunii. Fiecare cerință este identificată individual și poate fi referită pe parcursul procesului în orice moment utilizând un ID unic. Interdependențele cu alte cerințe și rezultate ale dezvoltării (cum ar fi documentele sau planurile arhitecturii) sunt reținute pentru a susține trasabilitatea.

Cazurile de utilizare UML sunt utile pentru a descrie cerințele funcționale. Un caz de utilizare descrie o funcție a sistemului din perspectiva actorilor acestuia și conduce la un rezultat perceptibil de către actori. Un actor este o entitate externă sistemului care interacționează cu sistemul. O diagramă de utilizare de caz prezintă relațiile dintre cazurile de utilizare și actori. Diagramele de utilizare de caz sunt utile pentru a ilustra dependențele strânse dintre cazurile de utilizare și actori; detaliile cazului de utilizare sunt definite în specificațiile de formatare. Atributele descriu numărul și numele cazului de utilizare, actorii implicați, condițiile anterioare și posterioare, evoluția, excepțiile și erorile, variațiile, sursa, raționamentul sau interdependențele cu alte diagrame UML.

Specificațiile formale

Specificațiile formale sunt scrise într-un limbaj care utilizează o sintaxă și semantică definite formal. Cel mai bun exemplu este “Z” (ISO/IEC13,568:2002). Specificațiile formale sunt rar utilizate pentru aplicațiile web.

Oportunitatea

Tabelul anterior compară diferite notații în ceea ce privește precizia atributelor, ușurința validării, raportul eficacitate-cost, folosirea de către non-experți și scalabilitatea. O precizie minimă-medie va fi suficientă pentru specificarea cerințelor aplicației web, iar o validare formală nu este cerută de obicei. Este important să păstrăm scăzut efortul de extragere și management al cerințelor, iar aceste cerințe să fie înțelese și de către non-experți. Scalabilitatea este o problemă pusă pe seama complexității ridicate a multor aplicații web. În tabelul anterior putem observa că formele de descrieri informale și semi-formale (relatările, listele de cerințe și specificațiile de formatare) sunt adecvate în special pentru aplicațiile web.

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

Utilitare

Extragerea cerințelor – EasyWinWin

Validarea cerințelor – sistemele de răspuns online (feedback)

Managementul cerințelor – managementul tuturor cerințelor ce aparțin unui proiect într-un depozit central – http://www.paper-review.com/tools/rms/read.php

Utilitare

Există numeroase categorii de utilitare care folosesc activitățile de proiectare a cerințelor descrise. Utilitare existente pentru proiectarea cerințelor nu sunt limitate la aplicațiile web, dar pot fi adaptate la specificul dezvoltării aplicațiilor web.

Extragerea cerințelor

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 dobândire și negociere a cerințelor. EasyWinWin definește un set de activități ale unui proces de negociere, un moderator îndrumând partenerii pe parcursul întregului proces. Această abordare utilizează tehnici de încurajare a grupurilor de lucru, care sunt susținute de utilitare colaborative (brainstorming electronic, clasificări, sisteme de votare, etc.). Aceste activități sunt: revizuirea și extinderea subiectelor de negociere, …..intereselor partenerilor; convergența spre condițiile de câștig, extragerea unui vocabular de termeni comuni, stabilirea nivelului de prioritate pentru condițiile de câștig, evidențierea problemelor și constrângerilor, identificarea problemelor și opțiunilor și negocierea acordurilor.

Validarea cerințelor

Datorită caracterului deschis al Internetului sistemele de răspuns online (feedback) pot completa sau chiar înlocui metode costisitoare (întâlniri sau interviuri) pentru validarea cerințelor aplicației web. De exemplu, utilizatorii Internetului pot fi invitați să participe la sondaje pe web pentru a comunica gradul lor de mulțumire față de o aplicație web. Remarcăm în acest context că datorită spontaneității comportamentului interactiv deseori nu putem observa o aprobare sau o negare ci doar indiferență. Dacă unui utilizator îi place aplicația web o va utiliza, dar va fi reticent la trimiterea unui feedback (de exemplu informații privind erorile găsite) pentru a contribui la dezvoltarea și îmbunătățirea aplicației.

Managementul cerințelor

Utilitarele pentru managementul cerințelor permit managementul tuturor cerințelor ce aparțin unui proiect într-un depozit central. Spre deosebire de sistemele de procesare a textului, utilitarele de management al cerințelor stochează cerințele într-o bază de date. Asemenea specificațiilor de formatare, atributele relevante sunt administrate pentru fiecare din aceste cerințe (vezi tabelul ). Sistemele de management al cerințelor sunt importante pentru managementul modificărilor și cerințelor. O trecere în revistă a utilitarelor existente poate fi găsită la http://www.paper-review.com/tools/rms/read.php .

Modelare

Obiecte. Clase

obiect – entitate care are identitate, stare si comportament

clasa – descriere a unei multimi de obiecte care au aceleasi caracteristici structurale si comportamentale

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

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.

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

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.

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

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 aplicațiilor web

alternativă mai bună față de dezvoltarea ad-hoc a aplicațiilor web

Modelele – punct de pornire pentru implementarea aplicațiilor web, ținând cont de aspectele statice și dinamice ale nivelelor de conținut, hipertext și prezentare ale unei aplicații web

Includerea informațiilor contextuale (precum utilizatorul, ora, locația și dispozitivul utilizat) și adaptarea aplicației web „derivată” din această informație

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

dezvoltarea aplicațiilor web complexe – abordare sistematică și o specificare a aplicației web care trebuie construită sub forma modelelor vizuale

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

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

Figura 3.1 Cerințe pentru modelarea aplicațiilor software

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

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

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

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

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

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

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

Limbajul de modelare unificat (UML)[2] este un limbaj de modelare orientat-obiect și este privit ca o lingua franca în dezvoltarea software-ului orientat obiect. UML stă la baza majorității metodelor de modelare pentru aplicațiile web și permite specificarea aspectelor unui sistem software sub forma modelelor, folosind diferite diagrame pentru reprezentarea grafică a acestora. UML dispune de două tipuri de diagrame: diagrame structurale (diagramele de clasă, diagramele de componente, diagramele de structură complexe, diagramele de desfășurare) și diagrame de comportament (diagramele de utilizare de caz, diagramele de stări, diagramele de activitate).

[1] Chen, P., The Entity-RelationshipModel – Toward a Unified View of Data, ACM Transactions on Database Systems, 1976, pp. 9–36

[2] OMG (Object Management Group), UML 2.0 Superstructure Specification – Revised Final Adopted Specification, 2004, http://www.omg.org

Caracteristicile modelării în proiectarea web

– abordarea aplicațiilor web ținând cont de cele trei dimensiuni specificate anterior: nivele, aspecte și faze

– accentul variază în funcție de tipul aplicației web

– focalizarea se va face asupra structurii de prezentare uniforme a paginilor

– modelarea hipertext trebuie să se bazeze pe șabloane de navigare recurente

– Relevanța structurii și comportamentului modelelor depinde de tipul de aplicație web care va fi implementată

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

Abordările de modelare specifice aplicațiilor web au fost dezvoltate în special în ultimii ani și permit abordarea aplicațiilor web ținând cont de cele trei dimensiuni specificate anterior: nivele, aspecte și faze.

Nivele

Pentru a modela aplicațiile web trebuie luate în considerare caracterul orientat pe document al conținutului acestora și navigarea hipertext non-liniară din cadrul lor. Din acest motiv se pot distinge trei nivele ale modelării aplicațiilor web (vezi Figura 3.2) spre deosebire de cele două nivele utilizate în metodele de modelare pentru aplicațiile tradiționale. Cele trei nivele sunt conținutul (informația și logica aplicației care stau la baza aplicației web), hipertextul (structurarea conținutului în noduri și legăturile dintre ele) și prezentarea (interfața utilizator sau layout-ul paginii). Majoritatea metodelor utilizate pentru a modela aplicații web folosesc această separare pe trei nivele[1].

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

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

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

În ceea ce privește modelarea la nivel de prezentare, focalizarea se va face pe o structură de prezentare uniformă a paginilor, pentru obținerea unui efect de recunoaștere a brandului aplicației web printre utilizatorii săi. Deși aspectul vizual al unei aplicații web este important, aspectele estetice nu fac parte din obiectivele majore ale modelării.

În ciuda separării intereselor și a obiectivelor diferite în cadrul celor trei nivele, putem stabili o corespondență între acestea. Pentru realizarea acestui lucru trebuie definite explicit interdependențele dintre nivele. De exemplu, diferite căi de acces hipertext personalizate pot fi mapate într-un singur model de conținut. Un model comprehensiv al unei aplicații web include toate cele trei nivele discutate, dar accentul variază în funcție de tipul aplicației web. Aplicațiile web care furnizează o interfață utilizator pur orientată-hipertext pentru un set mare de date, vor necesita focalizarea modelării pe conținut și structura hipertextului. În contrast, aplicațiile web orientate pe prezentare (ex. portalurile corporative sau magazinele de cumpărături online) vor avea cereri mai mari în ceea ce privește modelarea prezentării.

Aspecte

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

Faze

În literatură nu există un consens privitor la o abordare generală a modelării pentru dezvoltarea aplicațiilor web. În toate cazurile secvența de pași pentru modelarea nivelelor trebuie stabilită de către modelator. În funcție de tipul aplicației web se poate folosi o abordare bazată pe informație (pornirea de la modelarea conținutului) sau o abordare bazată pe prezentare (pornirea de la modelarea aspectelor de prezentare a aplicației). Dezvoltarea bazată pe modele în proiectarea web este contradictorie cu practicile întâlnite în proiectele web (ex. cicluri de dezvoltare cu viață scurtă și necesitatea unor „metode rapide”). Abordarea bazată pe modele oferă în schimb posibilitatea specificării comprehensive a unui model al soluției și, dacă este disponibil un utilitar de caz adecvat, posibilitatea generării automate a prototipului aplicației web.

Personalizarea

Includerea informațiilor de context în dezvoltarea aplicațiilor web are un rol semnificativ, permițând personalizarea, distribuirea multi-platformă și serviciile bazate pe locație. Personalizarea se referă la context (ex. preferințele utilizatorilor, caracteristicile dispozitivelor sau restricțiile privind lățimea de bandă) și permite adaptarea aplicației web în funcție de acesta. Personalizarea influențează toate cele trei dimensiuni ale modelării web (conținut, hipertext și prezentare) în ceea ce privește structura și comportamentul și trebuie luată în considerare în toate fazele procesului de dezvoltare. În consecință, managementul informației contextuale este tratat ca o dimensiune de modelare independentă.

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

Cerințele modelării

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

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

Se pot utiliza diverse tehnici pentru a identifica, analiza, descrie, evalua și administra cerințele aplicațiilor web. Cazurile de utilizare reprezintă tehnica de modelare adecvată pentru cerințele funcționale, deoarece ele pot fi reprezentate în mod grafic. Funcționalitatea în ansamblu a unei aplicații web este modelată ca un set de cazuri de utilizare care descriu cerințele aplicației web din perspectiva actorilor (persoane și alte sisteme). Mai mult, cazurile de utilizare pot fi suplimentate de diagrame de activitate UML pentru a descrie cerințele funcționale mai detaliat.

O particularitate a cerințelor aplicațiilor web este funcționalitatea navigării, care permite utilizatorului să navigheze prin hipertext și să găsească nodurile. În acest sens, se recomandă separarea cazurilor de utilizare funcționale de cele navigaționale, prin crearea a două modele distincte. O altă abordare (UWE) implică crearea unui singur model de caz de utilizare care folosește stereotipul UML <<navigation>> pentru a indica diferența între cazurile de utilizare funcționale și cele specifice hipertextului.

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

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

Use cases Actors Associations

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

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

poate fi implementat ca un serviciu web

Cazurile de utilizare trebuie descrise în detaliu; putem descrie fiecare caz de utilizare în mod textual sau prin utilizarea diagramelor de comportament (de exemplu diagrama de activitate). Diagramele de activitate sunt utilizate în principal când cele de utilizare de caz se solicită o logică a aplicației mai complexă. Un astfel de caz de utilizare poate fi implementat ca un serviciu web. Figura 3.4 este un exemplu de proces simplificat pentru trimiterea articolelor.

Initial node. The filled in circle is the starting point of the diagram.  An initial node isn’t required although it does make it significantly easier to read the diagram.

Activity final node. The filled circle with a border is the ending point.  An activity diagram can have zero or more activity final nodes.

Activity.   The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create [anonimizat].  Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in order to traverse the node.

Decision. A diamond with one flow entering and several leaving.  The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious

Modelarea conținutului

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

– modelare pură a datelor – suficientă în pentru aplicațiile web statice

– aplicațiile web complexe – solicită în plus modelarea aspectelor comportamentale

Informația oferită de o aplicație web este unul din cei mai importanți factori pentru succesul acelei aplicații, datorită originii web-ului ca un mediu informațional. Modelarea conținutului în sensul de modelare pură a datelor este suficientă în mod normal pentru aplicațiile web statice. Aplicațiile web complexe solicită în plus modelarea aspectelor comportamentale. Astfel, modelarea conținutului va include crearea modelului domeniului problemei, ce constă în aspectele statice și dinamice, după cum se cunoaște din Proiectarea software clasică. În plus trebuie luate în considerare următoarele caracteristici ale aplicațiilor web:

– Caracterul axat pe document și multimedia: la modelarea conținutului trebuie luate în considerare toate tipurile de formate media, inclusiv structurile pe care se bazează informația.

– Integrarea datelor și software-ului existent: multe aplicații web sunt construite folosind depozite de date și componente software existente, care nu au fost create inițial pentru aplicațiile web. Modelarea conținutului trebuie să satisfacă două obiective potențial contradictorii: trebuie să îndeplinească cât mai bine posibil cerințele de conținut ale aplicației web și trebuie să includă structurile de date și componentele software existente.

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

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

Modelarea conținutului urmărește transferarea informației și cerințelor funcționale, stabilite prin proiectarea cerințelor, într-un model. Caracterul hipertext al unei aplicații web și cerințele prezentării acesteia nu vor fi luate în considerare.

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

Figura 3.5 Diagrama de clasă pentru sistemul de recenzie

Figura 3.5 ilustrează o diagramă de clasă UML simplificată pentru exemplul de sistem de recenzare menționat anterior. Diagrama modelează o conferință care trebuie să abordeze anumite teme și utilizatorii care se pot autentifica pentru conferință și trimite articolele proprii. Un articol este subiectul unei recenzii realizate de 3 recenzenți. Invariantul de stare atașat la clasa „Articol” ne asigură ca autorii nu vor putea să-și revizuiască propriile articole. Această diagramă de clasă va servi ulterior drept bază pentru modelarea hipertextului și a prezentării pentru aplicația discutată.

UML 2 class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes

Classes are depicted as boxes with three sections, the top one indicates the name of the class, the middle one lists the attributes of the class, and the third one lists the methods.  By including both an attribute and a method box in the class I’m arguably making design decisions in my model, something I shouldn’t be doing if my goal is conceptual modeling.  Another approach would be to have two sections, one for the name and one listing responsibilities.  This would be closer to a CRC model (so if I wanted to take this sort of approach I’d use CRC cards instead of a UML class diagram).  I could also use class boxes that show just the name of the class, enabling me to focus on just the classes and their relationships

Multiplicity Indicators.

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 stările articolului

Figura 3.6 reprezintă o diagramă de stare (state machine diagram), utilizată pentru a modela diverse stări ale articolului în sistemul de recenzare. Un articol trimis va fi preluat de trei recenzenți pentru revizuire după ce termenul limită pentru trimitere a expirat. Dacă este atinsă o valoare-prag prestabilită articolul este acceptat; altfel este respins. În ambele cazuri autorii sunt anunțați prin e-mail despre rezultatul recenzării. În final articolul acceptat va fi publicat.

Objects have both behavior and state or, in other words, they do things and they know things. Some objects do and know more things, or at least more complicated things, than other objects. Some objects are incredibly complicated, so complex that developers can have difficulty understanding them. To understand complex classes better, particularly those that act in different manners depending on their state, you should develop one or more UML 2 state machine diagrams, formerly called state chart diagrams in UML 1.x, describing how their instances work.

UML state machine diagrams depict the various states that an object may be in and the transitions between those states. In fact, in other modeling languages, it is common for this type of a diagram to be called a state-transition diagram or even simply a state diagram. A state represents a stage in the behavior pattern of an object, and like UML activity diagrams it is possible to have initial states and final states. An initial state, also called a creation state, is the one that an object is in when it is first created, whereas a final state is one in which no transitions lead out of. A transition is a progression from one state to another and will be triggered by an event that is either internal or external to the object.

Modelarea hipertextului

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

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

produce modelul structurii hipertext

rafinează modelul de structură hipertext

Non-liniaritatea hipertextului este una din cele mai importante proprietăți de care trebuie ținut cont la modelarea aplicațiilor web. Din acest motiv structura hipertext trebuie proiectată cu atenție. Aceasta se poate realiza prin utilizarea unor structuri de acces adecvate (opțiuni de navigare) pentru evitarea riscului de rătăcire a utilizatorilor sau de a-i supune la un stres cognitiv excesiv.

Obiective

Obiectivul modelării hipertext (cunoscută și ca modelarea navigării) este specificarea navigabilității în conținutul aplicației web (căile de navigare disponibile utilizatorilor). Modelarea hipertext generează un rezultat dublu: în primul rând produce modelul structurii hipertext (modelul structurii de navigare) care definește structura hipertextului, respectiv ce clase ale modelului de conținut pot fi vizitate prin navigare. În al doilea rând, rafinează modelul de structură hipertext prin accesarea elementelor sub forma unui model de acces.

Modelarea hipertext se focalizează pe aspectele structurale ale hipertextului și elementele de acces. Comportamentul de navigare al unei aplicații web nu este în mod normal reprezentat explicit, deoarece oferă foarte puține informații adiționale pentru dezvoltator.

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

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

Spre deosebire de nivelul conținutului, pentru care sunt utilizate diagramele ER sau diagramele de clasă, pentru modelarea structurii hipertext sunt folosite notații specifice. Modelarea structurii hipertext se bazează pe conceptele hipertext (noduri – pagini sau documente și legături între aceste noduri).

Punctul de plecare folosit pentru crearea modelului structurii hipertext este de obicei modelul de conținut care conține clasele și obiectele care vor fi disponibile ca noduri în hipertext. Deseori modelul de structură hipertext este specificat ca o perspectivă a modelului de conținut, fiind uneori numit perspectivă navigațională. Astfel, un nod este specificat ca o perspectivă a modelului de conținut, selectând unul sau mai multe obiecte din conținut. Unele metode modelează structura hipertext indiferent de modelul de conținut. De exemplu OOHDM (Object-Oriented Hypermedia Design Method) oferă o abordare de a modela scenariile, în care modelul de structură hipertext poate fi construit direct pe baza cerințelor de navigare identificate de aceste scenarii.

În sistemul de recenzie folosit ca exemplu perspectiva hipertext este necesară pentru următoarele roluri ale utilizatorilor: autor, recenzent și președintele comitetului de organizare. Figura 3.7 ilustrează modelul de structură hipertext din perspectiva președintelui comitetului de organizare. Președintele poate vizualiza toate articolele trimise, poate accesa lista de articole acceptate sau respinse și profilurile recenzenților. Conform metodei de modelare UWE, figura 3.7 ilustrează modul în care stereotipul UML <<clasă de navigare>> este utilizat pentru a marca clasele ce reprezintă nodurile în modelul de structură hipertext pentru a le distinge de clasele de conținut. Legăturile sunt modelate prin asocieri directe cu stereotipul <<legătura de navigare>>.

Modelarea hipertextului – tipuri de legături

metoda HDM (Hypertext Design Model)

Legăturile structurale conectează elementele aceluiași nod (de la rezumatul recenziei la detaliile recenziei)

Legăturile de perspectivă plasează diferite perspective ale unui nod în relație cu altele (versiunile PostScript și PDF)

Legăturile aplicației plasează noduri diferite în relație unul cu altul în funcție de aplicație (legătură „cel mai bun articol”)

metoda WebML (Web Modeling Language)

legături contextuale – transmit informația contextuală (numărul unic al recenzentului)

legături noncontextuale – nu au asociate informații de context (legături care duc de la o recenzie singulară la lista tuturor recenziilor)

legături intra-pagină – sunt utilizate când sursa și destinația legăturii aparțin aceleiași pagini (direct la rezumatul articolului, care este afișat în partea de jos)

legături inter-pagini – sunt utilizate când sursa și destinația se află pe pagini diferite (informații detaliate despre autori și articolele lor)

În literatura de specialitate distingem tipuri de legături folosite pentru rafinarea ulterioară a semanticii modelului structurii hipertext. De exemplu metoda HDM (Hypertext Design Model) specifică următoarele tipuri de legături:

– Legăturile structurale conectează elementele aceluiași nod (de exemplu de la rezumatul recenziei la detaliile recenziei)

– Legăturile de perspectivă plasează diferite perspective ale unui nod în relație cu altele (de exemplu versiunile PostScript și PDF ale unui articol).

– Legăturile aplicației plasează noduri diferite în relație unul cu altul în funcție de aplicație (de exemplu o legătură care trimite la „cel mai bun articol”).

Alte clasificări se bazează pe posibilul transport al informației pe parcursul navigării. De exemplu metoda WebML (Web Modeling Language) specifică următoarele tipuri de legături:

– legături contextuale – transmit informația contextuală (de exemplu numărul unic al recenzentului pentru a naviga de la un recenzent la recenzia pe care el a creat-o)

– legături noncontextuale – nu au asociate informații de context (de exemplu legături care duc de la o recenzie singulară la lista tuturor recenziilor)

– legături intra-pagină – sunt utilizate când sursa și destinația legăturii aparțin aceleiași pagini (de exemplu când o legătură permite utilizatorului să navigheze direct la rezumatul articolului, care este afișat în partea de jos a paginii);

– legături inter-pagini – sunt utilizate când sursa și destinația se află pe pagini diferite (de exemplu când informații detaliate despre autori și articolele lor se găsesc pe pagini diferite).

metoda de modelare UWE

legături de navigare – sunt utilizate pentru a naviga între noduri (legături între articole și autorii acestora)

legăturile procesului – indică nodul de început al unui proces (spre începutul procesului de trimitere a recenziei)

legăturile externe – indică un nod care nu aparține în mod direct aplicației (spre ghidurile de formatare)

Pe baza cerințelor funcționale ale aplicațiilor web, metoda de modelare UWE definește următoarele tipuri de legături:

– legături de navigare – sunt utilizate pentru a naviga între noduri (de exemplu legături între articole și autorii acestora)

– legăturile procesului – indică nodul de început al unui proces (de exemplu spre începutul procesului de trimitere a recenziei)

– legăturile externe – indică un nod care nu aparține în mod direct aplicației (de exemplu spre ghidurile de formatare stabilite de editorul lucrărilor conferinței, care nu sunt stocate direct în sistemul de recenzie).

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 către un nod ce poate fi accesat de la toate nodurile

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

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

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

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

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

Modelarea prezentării

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

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

generează un rezultat dublu:

produce un concept de prezentare uniformă prin modelarea elementelor recurente din pagini (de exemplu antete și subsoluri de pagină)

descrie aspecte comportamentale ale interfeței utilizator (de exemplu pe ce buton se va executa clic pentru a activa o funcție din logica aplicației)

acordarea unui sistem de ajutor pentru orientarea utilizatorilor la nivelul prezentării – afișarea căii de navigare curente sau a paginilor vizitate pe parcursul sesiunii active

proiectarea grafică a layout-ului pentru interfața utilizator – grafician

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

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

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

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

trei nivele ierarhice

O pagină de prezentare – o pagină prezentată utilizatorului

O unitate de prezentare – nod – fragment logic al paginii

Un element de prezentare – set de informații ale nodului

Figura 3.9 Paginile de prezentare ale sistemului de recenzie

Elementele modelului sunt descrise pe trei nivele ierarhice:

– O pagină de prezentare descrie o pagină prezentată utilizatorului ca o unitate de vizualizare. Poate fi compusă din diferite unități de prezentare.

– O unitate de prezentare este utilă pentru gruparea elementelor interfeței utilizator și reprezintă un fragment logic al paginii. Prezintă un nod ce derivă din modelul hipertext.

– Un element de prezentare este blocul de bază al modelului prezentare. Elementele de prezentare sunt un set de informații ale nodului și pot include text, imagini, audio etc.

Putem vizualiza structura paginilor de prezentare pe baza reprezentării unei diagrame de clasă UML imbricate cunoscută sub numele de „structură”, așa cum se poate observa în figura 3.9. Acest exemplu utilizează clasele stereotip <<pagină>> și <<unitate de prezentare>> pentru a descrie paginile de prezentare și unitățile de prezentare. Toate tipurile de elemente de prezentare sunt de asemenea proiectate prin stereotipuri UML adecvate. Figura 3.9 ilustrează două pagini de prezentare ale sistemului de recenzie. Un articol este plasat pe o pagină numită „Pagina Articolului” împreună cu câmpurile aferente, o legătură către versiunea completă a articolului și o legătură pentru a afișa autorii articolului. În plus, utilizatorii pot apăsa un buton pentru a adăuga o nouă recenzie. Pagina „Pagina Autorului” are două unități de prezentare – lista tuturor autorilor și informația detaliată despre fiecare autor.

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

Figura 3.10 Diagrama de interacțiune a sistemului de recenzie

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

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

Figura 3.12 Diagrama secvențială pentru afișarea articolelor selectate

Modelarea personalizării

informația contextuală și o adaptare adecvată a aplicației în faza de modelare

realizată printr-o reprezentare explicită a informației de context și a adaptărilor derivate din aceasta

necesită examinarea situațiilor de utilizare a aplicațiilor web – a răspunde la întrebările „ce” și „când” trebuie adaptat

modelare și o administrare a preferințelor și caracteristicilor unui utilizator în așa numitul profil al utilizatorului

dupa nivelul de abstractizare al informației contextuale-distingem contextul fizic și contextul logic

Deoarece aplicațiile web omniprezente au o importanță deosebită este necesar să luăm în calcul informația contextuală și o adaptare adecvată a aplicației în faza de modelare. Propuneri relevante pentru personalizare regăsim în domeniul personalizării și sistemelor mobile.

Modelarea personalizării este realizată printr-o reprezentare explicită a informației de context și a adaptărilor derivate din aceasta. În funcție de metoda de modelare, rezultatul nu este întotdeauna un model al personalizării explicit. În majoritatea cazurilor modelarea personalizării se confundă cu modelele conținutului, hipertextului și prezentării. Personalizarea trebuie să fie distinctă de întreținere sau reproiectare. Modelarea personalizării ia în considerare informația care poate fi anticipată în momentul modelării și care poate lua valori diferite când aplicația web rulează. În schimb, adaptarea datorată modificărilor din mediul organizațional sau tehnologic implică activități de întreținere sau reproiectare.

Personalizarea necesită examinarea situațiilor de utilizare a aplicațiilor web – a răspunde la întrebările „ce” și „când” trebuie adaptat. Pentru a putea personaliza o aplicație web este necesară o modelare și o administrare a preferințelor și caracteristicilor unui utilizator în așa numitul profil al utilizatorului. De exemplu, pentru a adapta o aplicație web din domeniul sistemelor mobile, trebuie să luăm în considerare profilele dispozitivului, informații privind locația și lățimea de bandă. Această informație este apoi reprezentată în cadrul modelului de context sub forma diagramelor de clasă. În momentul rulării, contextul se poate schimba (de exemplu își schimbă preferințele sau aplicația este folosită din diferite locații). Din acest motiv este necesară o adaptare a aplicației web.

În ceea ce privește nivelul de abstractizare al informației contextuale, putem distinge contextul fizic și contextul logic. Contextul fizic rezultă dintr-o situație de utilizare specifică (de exemplu numele de utilizator pentru o autentificare sau celula GSM în care un utilizator este situat). Contextul logic oferă cunoștințe de context suplimentare (de exemplu adresa de la serviciu versus adresa de acasă, ore de lucru versus timp liber). Aceste informații de context pot fi oferite aplicației web și din surse externe. Un exemplu de astfel de sursă externă care oferă informații pentru o specificare mult mai detaliată a contextului locației sunt sistemele informaționale geografic (GIS- Geographic Information Systems). Au fost propuse și alte abordări (cum ar fi Context Toolkit sau proiectul NEXUS) pentru a sprijini componente universale capabile să ofere diferite tipuri de informații contextuale fizice și logice.

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

Figurile 3.13 și 3.14 ilustrează modul în care nivelele hipertext și prezentare ale sistemului de recenzie pot fi adaptate dinamic. S-au folosit adnotări (prin stereotipul <<personalizare>>) pentru a adăuga reguli de personalizare claselor adaptate. Regulile descrise în acest exemplu pot fi specificate mai detaliat utilizând un limbaj formal (de exemplu OCL – Object Constraint Language). Figura 3.13 ilustrează modul în care structura hipertext poate fi personalizată astfel încât articolele pe care un utilizator le poate citi să fie limitate la subiectele de interes pentru acel utilizator. Elementele structurii de acces „Articole Interesante” sunt adaptate dinamic prin reguli de transformare bazate pe subiectele personale de interes.

Figura 3.14 ilustrează modul în care elementele din modelul de prezentare pot fi adaptate prin utilizarea regulilor de transformare (de exemplu butonul „Introduceți Recenzia” trebuie să fie vizibil doar pentru utilizatorii cu rolul „Recenzent”).

Majoritatea tehnologiilor existente în prezent abordează modelarea personalizării prin definirea regulilor sau unui filtru pentru fiecare punct din aplicația web în care personalizarea se aplică ca în exemplul anterior. UWE folosește o abordare diferită, utilizând tehnici de modelare orientate pe aspect (AOM). AOM permite pe de o parte o separare sistematică a funcționalității sistemului de aspectele personalizării, iar pe de altă parte permite reducerea redundanței.

Metode și utilitare

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

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

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

Metodele disponibile pentru modelarea aplicațiilor web se bazează pe cele clasice (cum ar fi ER) sau îmbunătățesc un limbaj de modelare orientat-obiect (UML). Din punct de vedere istoric metodele de modelare a aplicațiilor web se prezintă ca în figura 3.17.

Metodele de modelare urmează diferite paradigme, în funcție de originea și focalizarea acestora:

– Metodele orientate pe date – își au originea în domeniul sistemelor de baze de date și se bazează în principal pe un model entitate-relație îmbunătățit prin concepte specifice pentru modelarea la nivel hipertext. Principalul obiectiv al acestor metode este modelarea aplicațiilor web care folosesc bazele de date. Exemple de astfel de metode sunt RMM (Relationship Management Methodology), Hera și WebML (WebModeling Language).

– Metodele orientate pe hipertext – se focalizează pe caracterul hipertext al aplicațiilor web; ele derivă în principal din domeniul sistemelor hipertext. Cele mai reprezentative exemple sunt: HDM (Hypertext Design Model) care a fost extinsă ulterior în W2000, sau WSDM (Web Site Design Method).

– Metodele orientate pe obiecte – se bazează fie pe OMT (primele metode apărute) sau UML (cele mai recente). UML este notația preferată atunci când se alege un limbaj standard pentru modelare. Această categorie include OOHDM (Object-Oriented Hypermedia Design Method), UWE (UML-based Web Engineering), OOWS (Object-Oriented Web Solutions) și OO-H (Object-Oriented Hypermedia).

– Metodele orientate pe software – abordează aplicațiile web în special din perspectiva dezvoltării clasice de software, folosind tehnici care urmează strict proiectarea software clasică. Exemple pentru această categorie sunt WAE (Web Application Extension) sau WAE2 (versiunea sa îmbunătățită).

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

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

Utilitare

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

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

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

Dezvoltarea bazată pe modele

Dezvoltarea bazată pe modele (The Model-Driven Development –MDD) nu sprijină doar utilizarea modelelor pentru dezvoltarea de software ci și necesitatea transformărilor în toate etapele dezvoltării (de la specificațiile sistemului până la implementare și testare). Transformările dintre modele oferă o legătură care permite implementarea automată a unui sistem în etape succesive pornind de la diferitele modele definite pentru acesta.

Dezvoltarea aplicațiilor web este un domeniu specific în care MDD poate fi aplicată cu succes, datorită separării aspectelor (conținut, hipertext, prezentare și personalizare) specifice web-ului. Metode precum WebML, OO-H și UWE reprezintă fundamentul abordării bazate pe modele pentru dezvoltarea aplicațiilor web; ele includ unele transformări semi-automate bazate pe model.

WebSA (Web Software Architecture) este o altă abordare bazată pe model pentru domeniul web-ului și folosește paradigma MDA (Model-DrivenArchitecture). Asemănător cu MDA, WebSA se focalizează pe construirea de modele independente de platformă și ulterior construirea automată a modelelor specifice platformei.

Utilitare

Datorită ciclurilor de dezvoltare scurte și complexității aplicațiilor web este recomandată utilizarea de instrumente care permit nu doar modelarea ci și generarea automată a codului și verificarea consistenței modelului. Principalele utilitare de acest tip sunt: WebRatio Site Development Studio, VisualWADE și OpenUWE Suite.

WebRatio Site Development Studio

WebRatio Site Development Studio (http://www.webratio.com) este un instrument de dezvoltare bazat pe modele care construiește folosind Web Modeling Language (WebML) (http://www.webml.org). Acest utilitar folosește propriile notații pentru modelarea hipertext și suportă notații ER și UML. Generatorul de cod al instrumentului utilizează XSL pentru a transforma modelele de conținut și hipertext prezentate în XML în bazele de date necesare și conexiuni la baza de date dar și în componente software și diferite formate de ieșire (HTML, WML, PDF, Microsoft Word). WebRatio folosește un instrument numit EasyStyle pentru a genera prezentarea paginilor, care va transforma automat paginile adnotate în foi de stiluri XSL, fără a solicita alte activități de programare. Aplicația web generată cu ajutorul WebRatio este trimisă apoi în cadrul de lucru bazat pe un set de componente Java care pot fi configurate prin utilizarea fișierelor XML.

VisualWADE

Instrumentul VisualWADE (http://www.visualwade.com) se bazează pe metoda OO-H. Acest instrument suportă modelarea și generarea automată a aplicațiilor bazate pe XML, ASP, JSP și PHP. VisualWADE adaugă la modelul UML alte două modele: „Vizualizarea Navigării” (utilizată pentru a modela aspectul hipertext al aplicației web) și „Vizualizarea Prezentării” (reprezintă elementele de interacțiune ale interfeței utilizator cu privire la structura și comportamentul acesteia utilizând anumite structuri de tip template). Aceasta produce o descriere independentă de dispozitiv a interfeței utilizator, care poate fi utilizată de generatoare în vederea obținerii automate a aplicației web pentru medii și dispozitive de rulare distincte.

OpenUWE

Suita de utilitare OpenUWE (http://www.pst.ifi.lmu.de/projekte/uwe) este un mediu de dezvoltare pentru proiectarea și generarea aplicațiilor web folosind metodologia UWE. Principala facilitate a acestei suite este reprezentată de arhitectura deschisă bazată pe standardele consacrate. Mediul de dezvoltare OpenUWE include instrumentul CASE ArgoUWE și cadrul de lucru UWEXML care constă într-un motor de verificare a consistenței modelului, un editor al layout-ului și un generator de cod pentru cadrul de lucru Cocoon XML Publishing și JSP.

Instrumentul CASE ArgoUWE se bazează pe instrumentul CASE open-source ArgoUML (http://www. argouml.org), suportă notația UWE și verifică consistența modelelor în funcție de constrângerile OCL specificate pentru meta-modelul UWE.

Concluzii

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

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

Arhitecturile aplicațiilor web

Calitatea aplicațiilor web este influențată semnificativ de arhitectura acestora

<Performanța scăzută, întreținerea și extinderea insuficientă și slaba disponibilitate a unei aplicații web

constrângerile tehnice – disponibilitatea serverelor web + serverele de aplicații utilizate sau integrarea sistemelor de moștenire + arhitecturile aplicațiilor web trebuie să ia în considerare și cadrul de lucru organizațional (experiența arhitecților)

Calitatea unei aplicații web este influențată semnificativ de arhitectura sa. Aspectele arhitecturale incomplete sau omise fac dificilă îndeplinirea cerințelor privind calitatea aplicațiilor web. Performanța scăzută, întreținerea și extinderea insuficientă și slaba disponibilitate a unei aplicații web sunt deseori cauzate de o arhitectură neadecvată. Pe lângă constrângerile tehnice (precum disponibilitatea serverelor web, serverele de aplicații utilizate sau integrarea sistemelor moștenite), trebuie să se ia în considerare și cadrul de lucru organizațional în care arhitecturile sunt incluse (de exemplu experiența arhitecților). Utilizarea unor arhitecturi multi-strat flexibile, considerarea conținutului multimedia și integrarea depozitelor de date și aplicațiilor existente reprezintă provocările pentru dezvoltarea unor arhitecturi de succes pentru aplicațiile web. Vom discuta în continuare proprietățile generale ale arhitecturilor, influența cunoștințelor arhitecturale existente sub forma șabloanelor și cadrelor de lucru asupra calității aplicațiilor web și arhitecturile reprezentative pentru aplicații web împreună cu componentele necesare construirii acestora.

Pe parcursul dezvoltării aplicațiilor web trebuie luate în considerare un număr mare de cerințe și constrângeri, începând cu cerințele funcționale (ex. comenzile de produse online) și cele de calitate (ex. performanța și disponibilitatea) și până la integrarea sistemelor software existente (așa numitele sisteme moștenite) sau a depozitelor de date existente pe care aplicația web ar trebui să le citească. În mod normal, aplicațiile web nu sunt dezvoltate „din nimic” în ceea ce privește infrastructura tehnică; deseori trebuie extinsă sau adaptată o infrastructură existentă. Pe lângă constrângerile pur tehnice, putem identifica alte aspecte, precum viabilitatea economică a unei infrastructuri tehnice.

Proprietățile arhitecturilor software

arhitectura descrie structura – structura, descompunerea în componente, interfața și relațiile dintre ele

arhitectura face tranziția de la analiză la implementare

arhitectura – abordari

conceptuală – identitățile domeniului aplicației și relațiile

în funcție de momentul rulării – servere sau căi de comunicație

pe procese – mapează procesele în momentul rulării sistemului (sincronizarea și concurența)

în funcție de implementare – artefactele software-ului (subsisteme, componente sau cod sursă)

Nu există o definiție unică a termenului „arhitectură”, renumitul Institut de inginerie a software-ului (SEI -Software Engineering Institute) din cadrul Universității Carnegie-Mellon (http://www.sei.cmu.edu) oferind peste 20 de variante explicative. În loc de a adăuga o altă variantă, vom încerca să descriem principalele proprietăți ale arhitecturilor software:

– arhitectura descrie structura: arhitectura unui sistem software constă în structurile lui, descompunerea în componente și interfețele și relațiile dintre ele[1]. Arhitectura descrie atât aspectele statice cât și cele dinamice ale sistemului software.

– arhitectura face tranziția de la analiză la implementare: când creăm arhitectura încercăm să transformăm cerințele funcționale și cele de calitate în componente software și relațiile și interfețele dintre ele într-un mod iterativ. Acest proces este susținut de mai multe abordări, cum ar fi Procesul Unificat.

– arhitectura poate fi abordată din diferite perspective, în funcție de care se pot specifica aspecte arhitecturale distincte. Există patru abordări diferite:

* abordarea conceptuală – identifică entitățile domeniului aplicației și relațiile dintre acestea;

* abordarea în funcție de momentul rulării – descrie componentele în momentul rulării sistemului (de exemplu servere sau căi de comunicație)

* abordarea pe procese – mapează procesele în momentul rulării sistemului, avându-se în vedere aspecte precum sincronizarea și concurența;

* abordarea în funcție de implementare – descrie artefactele software-ului (subsisteme, componente sau cod sursă)

Această clasificare în funcție de diferitele perspective este susținută și de limbajele de modelare (de exemplu UML).

– arhitectura face sistemul mai inteligibil: structurarea sistemelor software și abordarea lor din diferite perspective ne permite un management mai bun al complexității sistemelor software, sistemele devenind astfel mai ușor de înțeles.

– arhitectura reprezintă cadrul pentru un sistem flexibil: Tom DeMarco se referă la arhitectură ca la un „cadru al schimbării”: arhitectura software formează cadrul în care un sistem software poate evolua. Dacă extinderile unui sistem nu au fost luate anterior în calcul, atunci aceastea vor fi greu de realizat.

Având în vedere proprietățile menționate, putem afirma că deciziile arhitecturale sunt de o importanță majoră pentru dezvoltarea aplicațiilor web.

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

Figura 4.1 Factori care influențează dezvoltarea unei arhitecturi

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

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

Arhitectura unei aplicații este influențată în principal de cerințele funcționale – serviciile oferite de un sistem – și considerațiile privind calitatea (scalabilitatea sau performanța). Dincolo de aceste cerințe, arhitecturile sunt influențate de constrângeri tehnice cum ar fi software-ul utilizat de sistem (de exemplu sistemul de operare), middleware-ul (de exemplu o implementare CORBA), sistemele moștenite care trebuiesc integrate, standardele utilizate, regulile de dezvoltare (de exemplu ghidurile de scriere a codului) sau aspectele de distribuire (de exemplu distribuirea în diferite locații ale unei companii).

Deoarece sistemele software sunt în permanentă schimbare arhitecturile sunt de obicei dezvoltate într-o manieră iterativă, deci riscurile rezultate din cerințele și constrângerile neclare ar trebui să fie calculabile și controlabile. Totuși, această abordare iterativă nu garantează o arhitectură solidă; ea nu este suficientă pentru rezolvarea unor probleme de proiectare specifice (precum integrarea unui sistem moștenit) apărute în dezvoltarea unei arhitecturi. Șabloanele de proiectare s-au dovedit a fi foarte eficiente în sprijinirea acestor decizii de proiectare.

Șabloane – descriu probleme de proiectare recurente care apar într-un anumit context și propun soluții la acestea

șabloanele arhitecturale – mapează mecanismele de structurare fundamentale pentru sistemele software (șablonul MVC)

șabloanele de proiectare – descriu structura, relațiile și interacțiunea între componente

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

Șabloanele sunt disponibile pentru diverse infrastructuri – de exemplu J2EE, CORBA și PHP

Cadre – sistem software reutilizabil cu o funcționalitate generală deja implementată. Cadrul de lucru poate fi întâlnit sub forma aplicațiilor gata de folosire și servește ca o schiță pentru arhitectura și funcționalitățile de bază ale unui domeniu specific al aplicației

Șabloane

Șabloanele[1] descriu probleme de proiectare recurente care apar într-un anumit context și propun soluții la acestea. O soluție descrie componentele participante, responsabilitățile lor, relația între aceste componente și interacțiunea lor în cadrul problemei. De aici rezultă că șabloanele ne permit reutilizarea cunoștințelor demonstrate și consolidate de proiectare, sprijinind dezvoltarea unor sisteme software de calitate superioară.

Buschmann[2] identifică șabloane pe trei nivele de abstractizare:

– șabloanele arhitecturale – mapează mecanismele de structurare fundamentale pentru sistemele software. Ele descriu subsistemele arhitecturale, responsabilitățile acestora, relațiile și interacțiunea dintre ele. Un exemplu de astfel de șablon este șablonul MVC (Model-View-Controller[3]).

– șabloanele de proiectare –descriu structura, relațiile și interacțiunea dintre componente pentru a rezolva o problemă de proiectare apărută într-un anumit context; aceste șabloane derivă dintr-un limbaj de programare specific.

– dialecte – descriu șabloanele care apelează o implementare specifică într-un limbaj de programare.

Șabloanele sunt disponibile pentru diverse infrastructuri – de exemplu J2EE, CORBA[4] și PHP.

Totuși, șabloanele reprezintă doar un ghid pentru o anumită problemă. Arhitecții software trebuie să adapteze șabloanele la problema și constrângerile respective, să integreze și să îmbunătățească șabloanele folosite. Pentru a susține procesul de integrare, Buschmann recomandă folosirea așa-numitelor limbaje-șablon. Un limbaj-șablon descrie interconexiunile șabloanelor înrudite la nivele de abstractizare diferite, sugerează diferite utilizări pentru șabloane și indică adaptarea necesară pentru a asigura un sistem solid.

IBM descrie în 2002 șabloanele de arhitectură pentru aplicații comerciale și modul în care pot fi mapate pe infrastructura IBM[5]. Aceste șabloane de arhitectură sunt perfecționate printr-un lanț de decizii, pornind de la cazul de utilizare și terminând cu arhitectura țintă.

Cadre

Cadrele reprezintă o altă opțiune pentru reutilizarea cunoștințelor arhitecturale existente. Un cadru este un sistem software reutilizabil cu o funcționalitate generală deja implementată. Cadrul poate fi întâlnit sub forma unei aplicații gata de folosire[6]; el servește ca o schiță pentru arhitectura și funcționalitățile de bază ale unui domeniu specific al aplicației. (deci informațiile arhitecturale conținute într-un cadru pot fi preluate în întregime în aplicație).

Beneficiile unui cadru – reutilizarea cu ușurință a arhitecturii și funcționalității – trebuie puse în balanță alături de dezavantajele sale (gradul înalt de instruire necesară, lipsa standardelor pentru integrarea diferitelor cadre și deci dependența de producători).

[1] Gamma, E., Helm, R., Johnson, R., Design Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, 1997

[2] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern – Oriented Software Architecture:A System of Patterns, John Wiley & Sons, 1996

[3] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Pattern – Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996, p.125

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

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

[6] Fayad, M. E., Schmidt, D. C., Johnson, R. E., Building Applications Frameworks: Object Oriented Foundations of Framework Design, John Wiley & Sons, 1999

Clasificarea arhitecturilor

aspectul stratificat: sistemele software sunt structurate pe câteva nivele pentru implementarea principiului „separarea intereselor” în cadrul unui sistem software (arhitecturile J2EE, portalurile)

aspectul datelor: datele pot fi structurate sau nestructurate

În ultimii ani au fost dezvoltate o serie de arhitecturi pentru rezolvarea cerințelor specifice din diverse domenii de aplicații. Anastopoulos și Romberg[1] descriu arhitecturile pentru mediile aplicațiilor web în funcție de aspectul stratificat al arhitecturilor sau de aspectul datelor (susținerea diferitelor date și formate de date):

– aspectul stratificat: se referă la faptul că sistemele software sunt structurate pe câteva nivele pentru a implementa principiul „separarea intereselor” în cadrul unui sistem software. Multe cadre din domeniul sistemelor distribuite și aplicațiilor web sunt structurate în principal în funcție de aspectul stratificat (de exemplu arhitecturile J2EE[2] utilizate pentru a integra sistemele moștenite; portalurile).

– aspectul datelor: datele pot fi structurate sau nestructurate. Datele structurate urmează o schemă definită asemănător tabelelor din bazele de date relaționale sau structurilor XML dintr-un document. Datele nestructurate sunt elemente multimedia (imagini, audio, video) care nu respectă o schemă explicită, ceea ce face dificilă procesarea lor automată.

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

[2] Sun Microsystems (2003), Java 2 Platform, Enterprise Edition Specification, v 1.4, November, 2003, http://java.sun.com/j2ee/j2ee-1 4-fr-spec.pdf

Clasificarea 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 (Microsoft’s DCOM)

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

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

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

SOM (Service Oriented Middleware) – îmbunătățește sistemele DOM prin conceptul de servicii (Jini)

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

Răspândirea din ce în ce mai mare a sistemelor software a condus la dezvoltarea arhitecturilor și infrastructurilor ce se adresează distribuirii datelor și mesajelor:

– DOM (Distributed Object Middleware): acest tip de infrastructură permite accesarea obiectelor de la distanță în mod transparent și se bazează pe mecanismul RPC (Remote Procedure Call) (exemplu: DCOM – Distributed Component Object Model de la Microsoft)

– VSM (Virtual Shared Memory): modelul VSM permite proceselor distribuite să acceseze datele comune (exemplu: Corso http://www.tecco.at)

– MOM (Message Oriented Middleware): sistemele MOM oferă funcționalități pentru transmiterea asincronă a mesajelor. Comunicarea asincronă diferă de cea sincronă prin faptul că mesajele sunt trimise destinatarului indiferent de starea acestuia (de exemplu destinatarul poate să nu fie disponibil când mesajul este trimis – este offline). Exemplu: MSMQ – Microsoft Message Queue.

– P2P (Peer to Peer): înseamnă comunicarea directă între două dispozitive (pereche) într-un sistem fără utilizarea unui server (ele comunică printr-o conexiune de tip punct-la-punct). Exemplu: Xmiddle (http://xmiddle.sourceforge.net/)

– SOM (Service Oriented Middleware) – îmbunătățește sistemele DOM prin conceptul de servicii. Un serviciu în acest context reprezintă un număr de obiecte și comportamentul acestora; aceste obiecte folosesc o interfață definită pentru a face un serviciu disponibil pentru alte sisteme/servicii. Exemplu: sistemul Jini de la Sun (http://www.sun.com/software/jini/).

Arhitecturile prezentate se pot aplica sistemelor distribuite în general, nefiind limitate doar la aplicațiile web.

Particularitățile arhitecturilor pentru aplicațiile web

arhitectura infrastructurii web (Web Platform Architectures -WPA) și infrastructura aplicațiilor web (Web Application Architectures – WAA)

WPA

Serverele de aplicații precum implementarea J2EE și platforma .NET

soluții arhitecturale specifice pentru rezolvarea problemelor de securitate, performanță și integrare a datelor (firewall-uri, proxy-uri ptr caching și EAI)

Aplicațiile web actuale utilizează un număr ridicat de infrastructuri tehnice pentru rezolvarea anumitor probleme: cadre de lucru open-source (Struts (http://jakarta.apache.org/struts/ și Cocoon (http://xml.apache.org/cocoon/), servere de aplicații (de exemplu implementarea EJB) și JetSpeed (http://jakarta.apache.org/jetspeed/).

Internaționalizarea aplicațiilor web – suport pentru limbi diferite, seturi de caractere și mecanisme de reprezentare

Particularitățile arhitecturilor pentru aplicațiile web

Pentru început este necesară realizarea unei distincții între arhitectura infrastructurii web (Web Platform Architectures -WPA) și arhitectura aplicației web (Web Application Architectures – WAA). Deoarece WAA depinde de domeniul problemei aplicației web, vom insista asupra WPA-urilor.

WPA-urile au fost dezvoltate pentru o arie largă de probleme. Serverele de aplicații precum implementările J2EE și platforma .NET încearcă să ofere servicii de bază pentru controlul sesiunilor și accesul la date. În afara serverelor de aplicații au fost dezvoltate soluții arhitecturale specifice pentru problemele de securitate, performanță și integrare a datelor (firewall-uri, proxy-uri pentru caching și EAI).

Paradoxal, utilizarea unui număr mare de sisteme diferite face dificilă evaluarea și menținerea unor cerințe de calitate distincte. De exemplu, îndeplinirea cerințelor de performanță a devenit mai dificilă datorită numărului din ce în ce mai mare de componente și produse (comerciale sau gratuite) utilizate de la vânzători terți.

Alte probleme în dezvoltarea aplicațiilor web sunt neomogenitatea și imaturitatea infrastructurilor tehnice. Gorton și Liu (2002) descriu problemele care apar la analiza performanței pentru serverele de aplicații datorită update-urilor frecvente; studiul relevă că versiunile noi de produse sunt mai lente decât predecesoarele lor și noile funcționalități determină incompatibilități în codul aplicației existente. După adaptări extensive, care au necesitat o cunoaștere extrem de detaliată a produselor în cauză, s-a putut restaura comportamentul de performanță dorit.

Indiferent de problemele de neomogenitate și imaturitate, aplicațiile web actuale utilizează un număr ridicat de infrastructuri tehnice diferite pentru rezolvarea anumitor probleme: cadrele open-source (Struts http://jakarta.apache.org/struts/ și Cocoon http://xml.apache.org/cocoon/), servere de aplicații (de exemplu implementările EJB), cadrele portal (JetSpeed http://jakarta.apache.org/jetspeed/).

Un alt aspect important în domeniul arhitecturilor aplicațiilor web este internaționalizarea aplicațiilor web, care necesită suport pentru diferite limbi, seturi de caractere și mecanisme de reprezentare (ex. reprezentarea caracterelor arabice de la dreapta la stânga) la nivelul WPA. Multe dintre aceste aspecte sunt suportate de limbajele de programare sau sistemele de operare (exemplu platforma PHP oferă un mecanism de internaționalizare pentru codificarea seturilor de caractere diferite -ISO-8859-2, UTF-8- realizată și cu ajutorul programului Gettext).

Componentele arhitecturii aplicațiilor web

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

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

Componentele frecvent implicate în comunicare sunt:

– client: în general un browser (agent utilizator) este controlat de către un utilizator care folosește aplicația web. Funcționalitatea clientului poate fi extinsă prin instalarea plug-in-urilor și applet-urilor.

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

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

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

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

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

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

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

– aplicații moștenite: un sistem mai vechi care trebuie integrat ca o componentă internă sau externă.

Arhitecturile stratificate

Arhitecturi pe două straturi

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

Arhitectura pe două straturi poate lua forme diferite în mediul aplicațiilor web. O cerere a unui client poate puncta direct către pagini HTML statice, fără a solicita un raționament de procesare pe stratul server sau poate accesa o bază de date prin intermediul logicii aplicației pe serverul web (de exemplu sub forma scripturilor CGI). Paginile HTML dinamice includ instrucțiuni de tip script direct în codul HTML (de exemplu când este utilizat SSI – Server-Side Include sau PHP) și ele sunt interpretate fie de bazele de date cu funcționalități HTML fie de un server web. Logica aplicației sau paginile HTML dinamice pot utiliza servicii (exemplu identificarea utilizatorului sau criptarea datelor) când este generat răspunsul HTML. Această arhitectură este adecvată aplicațiilor web simple.

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

Arhitecturi pe N straturi

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

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

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

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

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

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

Proxy-uri

proxy-uri de legături: sunt de cel puțin două tipuri.

-sistemele de tipul URL-urilor persistente (PURLs- Persistent URLs) utilizează componente de tip proxy – server intermediar pentru a trimite cererile de URL-uri ale clientului către serverul real

– utilizate pentru a adapta și formata legăturile și conținutul pentru utilizatori

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

Proxy-uri

Inițial proxy-urile erau folosite pentru a salva lățimea de bandă, din acest motiv fiind numite și proxy-uri de caching[1]. Proxy-urile sunt capabile să îndeplinească și alte funcții:

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

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

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

Arhitecturi de integrare

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

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

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

Arhitecturi de integrare

Sistemele interne sau externe – aplicațiile și bazele de date existente, interfețele către partenerii de afaceri externi – pot fi integrate în aplicațiile web pe trei nivele: nivelul prezentare, nivelul logic al aplicației și nivelul conținutului. Arhitecturile de integrare se adresează aspectelor de integrare la nivelul conținut și nivelul logic al aplicației și sunt cunoscute sub numele de arhitecturi EAI (Enterprise Application Integration). În esență, EAI se focalizează pe integrarea sistemelor moștenite. O alternativă la EAI sunt serviciile web, care oferă integrarea serviciilor (logica aplicației și conținutul). La nivelul prezentare, un set de sisteme diferite este integrat tipic prin utilizarea arhitecturilor portal.

Portalurile reprezintă cele mai recente dezvoltări ale aplicațiilor web multi-stratificate. Cu ajutorul portalurilor conținutul, care este distribuit pe mai multe noduri ale diverșilor furnizori de servicii, va fi disponibil dintr-un singur nod, oferind un aspect consistent. În figura 4.9 este schematizată arhitectura de bază a unui server portal. Serverele portal se bazează pe portlet-uri, care aranjează conținutul și logica aplicației într-o structura de navigare și un layout adecvate portalului. Un exemplu de server portal este proiectul open-source JetSpeed (http://portals.apache.org/).

Arhitecturi în funcție de aspectul datelor

date structurate de tipul celor aflate în bazele de date;

documente de tipul celor utilizate în sistemele de management al documentelor;

date multimedia de tipul celor incluse pe serverele media

Arhitecturi axate pe baze de date

– accesate fie direct prin intermediul extensiilor serverului web (în cazul arhitecturilor pe două straturi) fie prin serverele de aplicații (în cazul arhitecturilor pe N straturi)

Arhitecturi pentru managementul documentelor web

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

Arhitecturi în funcție de aspectul datelor

Datele pot fi grupate în una din următoarele categorii arhitecturale: (1) date structurate, de tipul celor aflate în bazele de date; (2) documente de tipul celor utilizate în sistemele de management al documentelor; (3) date multimedia de tipul celor incluse pe serverele media. Aplicațiile web nu sunt limitate la una din aceste categorii de date, ele integrează documente, media și baze de date.

Arhitecturi axate pe baze de date

Sunt disponibile numeroase utilitare și abordări pentru integrarea bazelor de date în aplicațiile web. Aceste baze de date sunt accesate fie direct prin intermediul extensiilor serverului web (în cazul arhitecturilor pe două straturi), fie prin serverele de aplicații (în cazul arhitecturilor pe N straturi). Pentru accesul la bazele de date relaționale sunt disponibile interfețe (APIs) pentru diferite platforme (Java Database Connectivity -JDBC pentru aplicații bazate pe Java sau Open Database Connectivity -ODBC pentru tehnologii Microsoft).

Arhitecturi pentru managementul documentelor web

Pe lângă datele structurate din bazele de date și cele multimedia de pe serverele media, conținutul aplicațiilor web este frecvent procesat sub forma documentelor. Arhitecturile de management al conținutului oferă posibilitatea integrării documentelor din surse diferite, reprezentând un mecanism pentru integrarea acestor conținuturi în aplicațiile web.

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

Figura 4.10 reprezintă componentele unei arhitecturi de management al conținutului. Un server web recepționează o cerere de la client și o trimite mai departe unui server de furnizare a conținutului (responsabil pentru distribuirea și eventual caching-ul conținutului). Dacă conținutul solicitat nu este în cache atunci cererea este trimisă mai departe către serverul de management al conținutului. Conținutul poate fi disponibil direct pe acel server (în formă statică ca un document sau într-o bază de date) sau poate fi accesat extern. În funcție de tipul de integrare conținutul extern poate fi extras fie prin accesarea bazelor de date externe (direct sau prin utilizarea unui serviciu de agregare) fie dintr-un serviciu de mediatizare. Spre deosebire de accesarea unei baze de date, serviciile de mediatizare pot avea și funcționalități suplimentare (exemplu facturarea automată a drepturilor de licență).

Arhitecturi pentru datele multimedia

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

Arhitecturi pentru datele multimedia

Capacitatea de a manipula un volum mare de date are un rol decisiv în proiectarea sistemelor care utilizează conținut multimedia. Deși volumul de date nu este important în aplicațiile web axate pe baze de date, acesta influențează considerabil arhitectura și proiectarea aplicațiilor web multimedia.

Datele multimedia – audio și video- pot fi transmise prin intermediul protocoalelor internet standard (HTTP sau FTP), asemenea altor date folosite în aplicațiile web. Această abordare este utilizată de un număr mare de aplicații web, deoarece prezintă avantajul că nu necesită componente suplimentare pe server; dezavantajul este că descărcările de fișiere multimedia sunt foarte lente.

Se pot utiliza tehnologii streaming pentru a minimiza perioada de așteptare pentru redarea conținutului multimedia; prin streaming în acest context se înțelege că un client poate reda un fișier audio și/sau video la câteva secunde după ce începe recepționarea acestuia de pe server. Această tehnică evită descărcarea întregului fișier înainte de a începe redarea lui. Conținutul trebuie transmis în timp real, ceea ce necesită o lățime de bandă corespunzătoare (garantarea lățimii de bandă a transmisiei este numită calitatea serviciului).

În general sunt folosite două protocoale pentru streaming-ul de conținut multimedia: un protocol preia transmisia datelor multimedia la nivelul rețea, iar celălalt controlează fluxul prezentării (exemplu pornirea și oprirea unui clip video) și transmisia meta-datelor. Un exemplu de protocol de rețea este RTP (Real Time Protocol) care cooperează cu un protocol de control numit RTSP (Real Time Streaming Protocol).

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

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

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