Cuprins

Cuprins
Cuprins ................................................................................................................................ 4 Capitolul 1. Introducere Contextul proiectului .............................................................. 7 1.1 Internet i Web 1.0................................................................................................. 7 1.2 Web 2.0, Web 3.0 i HTML5 ................................................................................ 8 1.3 Social Media i Social Dashboards ....................................................................... 9 1.4 Motoare de cautare i Web .................................................................................... 9 1.5 Contextul Problemei .............................................................................................. 9 Capitolul 2. Obiectivele proiectului ................................................................................ 10 2.1 Generator Web 3.0 ............................................................................................... 10 2.2 Site Web 3.0 ........................................................................................................ 11 2.2.1 Personalizare site .......................................................................................... 11 2.2.2 Platforme Web 2.0 ........................................................................................ 12 2.2.3Memorare / Manipulare informaii ................................................................ 12 2.3 Editor ................................................................................................................... 13 Capitolul 3. Studiu bibliografic ...................................................................................... 14 3.1 Conceptul Web X.0 ............................................................................................. 14 3.1.1 Web X.0 Pro/Contra ..................................................................................... 14 3.1.2 Web 1.0......................................................................................................... 15 3.1.3 Web 2.0......................................................................................................... 16 3.1.3.1 Web 1.0 Web 2.0 ................................................................................ 17 3.1.4 Web 3.0......................................................................................................... 19 3.1.4.1 Elementele Web 3.0............................................................................... 20 3.1.4.2 Semantic Web - Teorie .......................................................................... 20 3.1.5 Web 4.0......................................................................................................... 23 3.2 Generatoare de Site-uri ........................................................................................ 23 3.3 Web Service......................................................................................................... 24 3.4 Social Dashboards ............................................................................................... 25 3.5 Data mining ......................................................................................................... 26 Capitolul 4. Analiz i fundamentare teoretica ............................................................... 28 4.1 Analiza general .................................................................................................. 28 4.2. Analiza componente ........................................................................................... 29 4.2.1 Site-ul web .................................................................................................... 30 4.2.1.1 Cerine funcionale ................................................................................ 30 4.2.1.2 Cerine ne-funcionale: .......................................................................... 31 4.2.1.3 Cerine specifice domeniului problemei:............................................... 32 4.2.2 Generatorul Web........................................................................................... 32 4.2.2.1 Cerine funcionale ................................................................................ 32 4.2.2.2 Cerine ne-funcionale ........................................................................... 32 4.2.3 Editorul de Site-uri ....................................................................................... 33 4.2.3.1 Cerine funcionale ................................................................................ 33 4.2.3.2 Cerine ne-funcionale ........................................................................... 34 4.2.3.3 Cerine specifice domeniului problemei ................................................ 35 4.3 Arhitectura Sistemului ......................................................................................... 35 4.3.1 Arhitectura bazat pe componente ............................................................... 35 4.3.2 Descrierea Arhitecturii Proiectului ............................................................... 36

Cuprins Capitolul 5. Proiectare de detaliu si implementare ......................................................... 38 5.1 Arhitectura proiectului implementat.................................................................... 38 5.2 Editor Site ............................................................................................................ 38 5.2.1 Aplicaia Flash .............................................................................................. 39 5.2.1.1 Platforma Aplicaiei............................................................................... 39 5.2.1.2 ablon de proiectare .............................................................................. 40 5.2.1.3 Elemente generale ale implementrii .................................................... 41 5.2.1.4 View ...................................................................................................... 44 5.2.1.4.1 Elementele Vizuale ......................................................................... 44 5.2.1.4.2 Tipuri de componente ..................................................................... 46 5.2.1.5 Controlorul (Controller) ........................................................................ 49 5.2.1.6 Modelul.................................................................................................. 53 5.2.1.6.1 Operaii legate de pagini ................................................................. 53 5.2.1.6.2 Operaii legate de componente ....................................................... 54 5.2.2 Standardul XML ........................................................................................... 57 5.2.3 Aplicaia JSP ................................................................................................ 59 5.2.3.1 Platforma Aplicaiei............................................................................... 59 5.2.3.2 Implementarea operaiilor ..................................................................... 59 5.3 Site Web 3.0 ........................................................................................................ 61 5.3.1 Pagini specifice fiecrui site ......................................................................... 61 5.3.2 Paginile generate de utilizator ...................................................................... 62 5.3.3 Pagina Social Dahsboard .............................................................................. 64 5.4 Generatorul Web.................................................................................................. 65 5.4.1 Tehnologia Web Service ............................................................................ 66 5.4.2 Operaiile Generatorului web ....................................................................... 67 Capitolul 6. Testare i validare ....................................................................................... 69 6.1. Ansamblul proiectului ........................................................................................ 69 6.2.Editor ................................................................................................................... 70 6.3. Generator ............................................................................................................ 71 6.4. Site ...................................................................................................................... 71 Capitolul 7. Manual de instalare si utilizare ................................................................... 72 7.1 Instructiuni de instalare ....................................................................................... 72 7.1.1 Editorul ......................................................................................................... 72 7.1.2 Generatorul ................................................................................................... 73 7.1.3 Site ................................................................................................................ 73 7.2 Manual de utilizare .............................................................................................. 74 7.2.1 Editorul ......................................................................................................... 74 7.2.2 Generatorul ................................................................................................... 78 7.2.3 Site ................................................................................................................ 79 Capitolul 8. Concluzii ..................................................................................................... 81 Calitatea obiectivelor realizate .................................................................................. 81 Posibile dezvoltri/nbuntiri .................................................................................. 83 8.2.1 Dezvoltri/nbuntiri generale ................................................................... 83 8.2.2 Editor ............................................................................................................ 83 8.2.3 Generator ...................................................................................................... 84 8.2.4 Site ................................................................................................................ 84 Bibliografie ........................................................................................................................ 85 Anex ................................................................................................................................. 87 A1 Editor ................................................................................................................... 87

Cuprins A1.1 Elementele vizuale ale aplicaiei .................................................................. 87 A1.2 Controlerul .................................................................................................... 88 A1.3 Modelul ......................................................................................................... 89 A2. Generator ............................................................................................................ 91 A3. Site ...................................................................................................................... 93

Capitolul 1

Capitolul 1.

Introducere Contextul proiectului

Pentru o introducere corespunzatoare n contextul problemei este indispensabil o prezentare a evoluiei Internetului, a modificrii structurii sale. Necesitatea unei astfel de prezentri este motivat de evoluia legturii ntre Internet i om, de satisfacerea nevoilor utilizatorului i modul prin care Internetul a rspuns acestor cereri. Fenomen complex care, mai mult ca niciodata, are un rol important n viaa omului, Internetul a parcurs o serie de etape pentru a deveni ceea ce este astzi. Aceast capitol va prezenta succint etapele de dezvoltare, att tehnologic ct i privit din punct de vedere al raportului author user, apoi va continua cu o ramura a Internetului i anume socializarea on-line ct i o prezentare a viitorului. Descrierea fiecrei etape va fi limitativ, dar va conine suficient informaie pentru inelegerea unui concept sau fenomen, mpreun cu surse bibliografice care prezint conceptul n profunzime.

1.1 Internet i Web 1.0

Internetul este o reea global de caluclatoare, o reea de reele[1], care ofer o varietate larg de informaii, resurse i servicii [1] miliardelor de utilizatori care l folosesc. Acest schimb de informaii se realizeaz printr-un standard denumit Internet protocol suite[2] IP (cunoscut n special sub denumirea generic de TCP/IP, dei nu toate protocolurile folosesc TCP) prin care utilizatorii comunic unii cu alii diferite tipuri de informaii cum ar fi text, imagini, hypertext, email, etc. Interesul pentru schimbul de pachete ntre calculatoare a nceput n prima parte a anilor 1950, dar un model operaional de schimb pe o scal larg a aprut abia n 1968 cand ARPANet a pus n aplicare primul proiect de reea de calculatoare, denumit generic astzi bunicul internetului. Dei modelul pentru o scala mare a aprut aa trziu, reele de calculatoare existau i la nceputul anilor 1960 dar acestea conineau un numr limitat de calculatoare i resurse. Prima teoretizare a ceea ce urma sa devin Internetul a fost fcut n 1962 de J.C.R. Licklider, cercettor MIT, care propunea conceptul de Galactic Network. Acest concept prezenta o reea global de calculatoare interconectate prin care oricine putea s acceseze informaii i programe din orice locaie.[3] Dei conceptualizat, Internetul s-a nscut odat cu standardizarea Internet Protocol Suite [2] n 1982. Pn atunci reelele de calculatoare erau facute doar la nivel local i doar acei utilizatori care aveau un nivel mediu de cunotiin a calculatoarelor puteau sa opereze cu aceasta. Introducerea acestui protocol a fcut conectarea i transmiterea de date mai uor de neles i practicat. Odat cu trecerea timpului, un serviciu al internetului denumit World Wide Web ncepe s devin din ce n ce mai popular, aducnd noi utilizatori datorit mas-mediei, circulatiei rapide printre adolesceni cat i uurinei cu care se putea face schimbul de informaii. Transferul de informaii se realiza printr-o aplicaie denumit web browser prin care un utilizator cu un nivel minim de cunotiin a calculatoarelor putea sa vizualizeze pagini hypertext. Pn la sfritul anilor 1990, WWW era format din o serie de pagini statice pe care utilizatorul putea doar s le vizualizeze (Web 1.0), fr a putea modifica sau adauga ceva. n fapt, autorii paginilor expuneau informaii ntr-un mod asemntor afielor. Acest lucru se dovedea a fi prea puin pentru un mediu cu asemenea potenial, un mediu care putea atat sa trimit ct i s primeasc informaii. Astfel se nate un internet de tipul read/write[4], un Internet n care fiecare utilizator poate s dein propriul spaiu n care s scrie Web 2.0. 7

Capitolul 1

1.2 Web 2.0, Web 3.0 i HTML5

Conceptul Web 2.0 reprezint o serie de caracteristici specifice unei aplicaii web prin care se faciliteaz partajarea de informaii, interoperabilitatea, design bazat pe utilizator n WWW[5]. Acum utilizatorii nu mai sunt doar consumatori ci i productori, colabornd ntr-o societate virtual n care ne putem ntlnii cu toii unde s citim i s scriem[4] Dei termenul pare a sugera un update la WWW, o alt specificaie, el defapt arata o schimbare in modul n care software developeri si utilizatorii finali folosesc i creeaz pe Internet. Vorbim despre o arhitectur de participaie[6], un produs open source n care, spre deosebire de un software open source, utilizatorul nu scrie cod ci un simplu document[6]. n urma acestor schimbri ncep s apar diverse noi tehologii ct i noi moduri de a comunica on-line. Printre acestea se enumer: wikis, blog-uri, audio/video provider, podcasting, social software i lista continu. Toate au n comun 3 lucruri: social web - un web care tinde s interacioneze cu utilizatorul i s l integreze n sine, arhitecturi web oriented aplicaiile Web 2.0 i expun funcionalitiile pentru ca alte aplicaii s se poat folosi de ele, aplicaii rich internet[5] aplicaii usor accesibile ct i bogate din punct de vedere vizual. n clipa de fa exist suficiente astfel de posibilitti de dezvoltare. Ele devin din ce in ce mai performante i i ofer tot mai multe dar viitorul nu const n mai multe reele de socializare sau mai multe metode de comunicare. Viitorul const ntr-un Web n care calculatorul cunoaste ceea ce face i ajut utilizatorul n experiena sa on-line. n prezent aplicaiile web nu se deosebesc de un calculator de mn care primete informaii i apoi le afieaz pe un ecran. O aplicaie web afiseaz, dar nu ntelege defapt ceea ce este scris. Este nevoie de aplicaii care proceseaz informaiile primite de la utilizator n aa fel nct contentul primit s fie generat de calculator n funcie de preferine. Un Web n care aplicaiile s caute, pentru utilizator, on-line Web 3.0. Aplicaia va ntelege att ceea ce doreti ct i preferinele tale. O aplicaie Web 3.0 va cauta n istoricul utilizatorului preferinele sale i le va raporta cu ceea ce dorete. Spre exemplu, dac se introduce: Vreau sa m duc la un restaurant cu specific chinezesc. Unde propui s m duc? , aplicaia mi va propune o list n ordinea probabilelor mele preferine. n Web 2.0 trebuie sa caui n mai multe pagini o alternativ, s citeti user review-uri i n cele din urm te hotreti. Web 3.0 face asta pentru tine la prima cutare. Dac Web 2.0 folosete internetul s conecteze oamenii, Web 3.0 conecteaz cu informaii.[7] Aceast direcie de dezvoltare pare a fi acceptat i de ctre cei de la World Wide Web Consortium prin propunerea unui nou mod de interaciune ntre aplicaii denumit Semantic Web. Acesta cuprinde un framework comun care permite informaiei s fie mprit i reutilizat n mai multe aplicaii enterprise[8]. W3C recomand spre folostire dou standarde Resource Description Framework[9] i Web Ontology Language[10]. n prezent, dezvoltarea limbajului XHTML 1.0, iar apoi HTML5, au pus bazele RDFa Resource Description Framework Attributes, un framework care permite descrierea informaiei din pagina web, relaiile dintre acele informaii i o anumit tipologie. Astfel un agent Web 3.0 nu va mai cuta doar cuvinte cheie n coninutul documentelor ci i modul cum relaioneaz cu restul paginii.

Capitolul 1

1.3 Social Media i Social Dashboards

Andreas Kaplan i Michael Haenlein definesc Social Media n lucrarea lor Users of the world, unite! ca un grup de aplicaii on-line care se fundamenteaz pe ideologia Web 2.0 i care permit creaia i schimbul de documente generate de utilizatori[11]. Aparent corect, definiia nu pare a fi suficient datorit lipsei scopului principal, interacinea social. Aplicaiile Social Media se fundamenteaaz pe accesibilitate i scalabilitate a unei pseudo-comunicri on-line, fundament care a schimbat modul n care comunitile, organizaiile i indivizii comunic. Formele principale de comunicare cuprind: internet forums, webblogs, blog social, microblogging, wikis, podcast, social bookmarking, etc. Internetul prezint un numr mare de tehnologii i aplicaii care ofer aceste servicii. Aparenta problem pare a fi o relativ unificare a acestora. Datorit cantitii mari de aplicaii i a utilizatoriilor care le folosesc, se dovedea dificil o comunicare optim. Pentru fiecare aplicaie trebuie efectuat comunicarea separat. Astfel un utilizator trebuia s se conecteze la toate aplicaiile folosite i sa le urmreasc individual. Aceast nevoie urma s fie satisfcut rapid, iar ncepnd cu anul 2008 apar aplicaiile denumite Social Dashboard care uneasc toate aceste aplicaii sub o singur platform.

1.4 Motoare de cautare i Web

Influena Web 2.0 a ptruns i n domeniul motoarelor de cutare. Pn la nceputul anului 2010, autorii de Web Search Engine Optimization ca Brian Solis vorbeau despre importana aplicaiilor Web 2.0 n mediul cutarii on-line[13], dei giganii motoarelor de cutare nu pareau a respecta aceast regul. Abia n decembrie 2010, Google, pe Vlogul su de Webmasters, a confirmat importana aplicaiilor web[14]. Ele au devenit semnale pentru cutare, n special n domeniul blog, singura problema pare a fi accesibilitatea acestor informaii.

1.5 Contextul Problemei

n prezent se pune problema trecerii de la Web 2.0 la Web 3.0 n cadrul aplicaiilor sociale existente. Exist platforme de unificare dar ele nu fac altceva dect s publice informaiile nu s le i interpreteze. Urmtorul pas este oferit de o aplicaie care preia activitatea utlizatorului, observ interesele sale, activitatea de socializare i pstreaza informaiile importante. Aceast aplicaie trebuie s fie conectat la tot ceea ce face utilizatorul astfel trebuie s unifice toate aplicaiile folosite de utilizator, pe scurt un amestec ntre Web 3.0 i Social Dashboard. Rspunsul este oferit de o aplicaie specific fiecruia, o aplicaie care dedubleaz personalitatea utilizatorului. Avnd un istoric de socializare, ea poate prezuma interesul utilizatorului i s l ajute n experiena on-line. Acest aplicaie trebuie generat la nivelul fiecrui utilizator i s se manifeste independent de platforma generatoare dar dependet de activitatea utilizatorului. Aceast lucrare va prezenta o propunere spre rezolvarea acestei probleme prin o aplicaie care genereaz site-uri Web 3.0, site specific fiecrui utilizator. Trebuie s unifice toate aplicaiile Web 2.0, s proceseze aceste informaii, apoi s ajute utilizatorul la o cutare on-line.

Capitolul 2

Capitolul 2.

Obiectivele proiectului

Problema procesrii tuturor informaiilor Web 2.0 sub o singur platform se poate realiza printr-o aplicaie independent . Aceast aplicaie trebuie s neleag ceea ce doreste utilizatorul, s poat fi utilizat de oriunde, s pstreze personalitatea utilizatorului, s pstreze legtura cu aplicaiile Web 2.0 i s ajute utlizatorul n experiena on-line. Soluia propus const ntr-un site care ndeplinete toate condiiile de mai sus. Proiectul ofer un generator de site-uri web, unul specific fiecrui utilizator, care nu se va rezuma doar la generarea codului de manipulare (pagin personalizat i pagini de unificare a platformelor Web 2.0), ci i la generarea codului de interpretare a informaiilor primite - Web 3.0. Realizarea obiectivului propus se efectueaz printr-un proiect ce const n trei pri principale: un serviciu on-line care genereaz site-uri Generator Web 3.0, un consumator de servicii care citete preferinele utilizatorului apoi le trimite serviciului de generare Editor; i site-ul Web 3.0 generat. Luat fiecare individual, se observ un aparent raport de dependen a clientului fa de serviciu, independena produsului final i a serviciului, posibilitatea de reutilizare a serviciului ct i alte particulariti care vor fi prezentate n subcapitolele urmtoare. Astfel descrierea obiectivelor proiectului ncepe prin descrierea obiectivelor componentelor sale principale.

2.1 Generator Web 3.0

Partea principal a proiectului este Generatorul Web 3.0, un serviciu web[15] de interpretare a standardelor de intrare. El prezint dou funcionaliti care satisfac necesarul unei dezvoltri de site-uri. Prima funcionalitate este una de informare a clientului n ceea ce privete operaiile oferite de serviciu. Se vor afia: totalitatea funciilor publice intrrile i ieirile funciilor descriere a acestor funcii. A doua funcionalitate const ntr-un set de operaii de interpretare a unor intrri, oferind rspuns fie produsul final Web 3.0, fie diferite structuri ale acestuia, n funcie de cerinele clientului. Impreun cu aceste funcionaliti principale, este util a se specifica i cteva obiective suplimentare, ntr-o list care cuprinde toate obiectivele serviciului: independena de client, specific serviciilor web[15] creeare/modificare site-uri web afiseaz standarde de intrare/ieire set relativ redus de operaii, limitate la generare totala/parial

10

Capitolul 2

2.2 Site Web 3.0

Produsul final al generatorului Web este Site-ul Web 3.0: respecta conceptul Web 3.0 - va fi scris ntr-o manier care va permite o parcurgere optim de ctre alte aplicaii Web 3.0. n ceea ce privete parcurgerea altor aplicaii Web 3.0 de ctre site, se va propune un model rudimentar de cutare. Propunerea oferit are un rol exemplificativ, prezint un nivel minim a ceea ce poate s fac site-ul cu ceea ce a nvat. O alt caracteristic a site-ului este reutilizarea codului prin care a fost creeat. Odat generat, site-ul va conine o copie a sa n formatul dat serviciului de interpretare. Aceast caracteristic are dou consecine importante. n primul rnd utilizatorul poate s ncarce formatul n aplicaia de client serviciu spre modificare, apoi spre generarea produsului actualizat. a doua consecin se bazeaz pe existena unei copii de siguran a produsului actual. n ceea ce privete celelalte obiective, pentru o prezentare corespunztoare a fiecrei funcionaliti, obiectivele au fost mprite n trei tipuri, n funcie de apartenena lor la un topic specific: obiective de Personalizare site, obiective legate de platforme Web 2.0 i obiective legate de memorarea/manipularea informaiilor.

2.2.1 Personalizare site

Site-ul are la baz identitatea utilizatorului, astfel aproape tot ce va conine va fi creat dup preferinele sale. utilizatorul va decide asupra aspectelor vizuale, site-ul va conine tipuri de formate generale, specificate n informaiile oferite de serviciu. Aplicaia de generare va citi preferinele utilizatorului, genernd site-ul, dar activitatea de personalizare este fcut n aplicaia Editor. Cu toate acestea, produsul final va fi modificat, el va reflecta efortul creator al utilizatorului, astfel, capacitatea de a fi personalizat aparine site-ului, nu clientului. Utilizatorul va specifica: numrul de pagini, cum sunt legate paginile ntre ele coninutul paginilor nivelul de acces al utilizatorilor externi la produs. Este indicat ca orice modificare asupra coninutului site-ului, dup generare, s fie fcut folosind serviciul de generare, pe baza copiei de siguran oferit. Dei modificrile ulterioare se pot realiza manual, modificarea pe baza copiei este mult mai sigur. Astfel, pe scurt, obiectivele principale const n: creeare/modificare vizual editare elemente functionale

11

Capitolul 2

2.2.2 Platforme Web 2.0

Un al doilea obiectiv este unificarea aplicaiilor Web 2.0. Produsul final va trebui: s permit conectarea la aplicaiile Web 2.0 folosite de ctre utilizator, s pstreze o legtur cu acestea de tip sincron (la fiecare conectare se face update). Motivul conexiunii sincrone are la baz necesitatea unui control al utilizatorului asupra a ce este postat, el va decide cnd i ce va aprea n coninutul site-ului. Odat accesate, informaiile provenite de la aplicaiile exterioare vor: intra n baza de date, fi accesibile utilizatorului spre vizualizare/adaugare/stergere i n urma unor prelucri, utilizatorul public pe coninutul site-ului informaia care o consider important. Conexiunea nu se rezum doar la operaia de citire, ci i la operaia de scriere. utilizatorul va avea posibilitatea de a crea direct din cadrul site-ului. aplicaia posed un numr minim de funcii de creeare/modificare/tergere a coninutului din aplicaiile exterioare. Controlul este foarte sczut datorit nivelului strict al accesului oferit de ctre aplicaiile Web 2.0. De asemenea site-ul trebuie s conin opiuni de conectare, permind modificri ulterioare. Acest caz este valabil pentru toate aplicaiile introduse n site. Dac se urmrete o adugare de aplicaie, este necesar o nou generare a site-ului pe baza copiei de siguran. Spre deosebire de caracterul de personalizare, platformele pot fi modificate fr o generare a coninutului ntregului site. Att site-ul ct i aplicaiile Web 2.0 i pstreaz caracterul de independen. Obiectivele care decurg din caracterul de unificare a aplicaiilor web sunt: independena site aplicaii Web 2.0 unificarea tuturor aplicaiilor Web 2.0 sub o singur platform posibilitatea de editare (creeare/modificare/stergere) n cadrul aplicaiilor Web 2.0 din site

2.2.3Memorare / Manipulare informaii

Operaia de memorare se realizeaz prin procesarea informaiilor primite de la aplicaiile Web 2.0. Se vor prelua informaiile principale i vor fi memorate ntr-o baz de date. Procesul de selectare se va face printr-un algoritm de selecie. Operaia de manipulare a informaiilor este mai complex. Ea presupune dou seturi de funcii: primul set este cel de citire a informaiei, preluare a ceea ce pare a fi relevant pentru utilizator, apoi ordonarea informaiilor n funcie de trecutul utilizatorului. Se va propune un mod de ierarhizare a importanei. al doilea set de funcii sunt cele care se preocup cu prelucrarea informaiei. Acum site-ul va trebui s proceseze ceea ce primete iar, luand n calcul rezultatul primului set, s produc coninut relevant utilizatorului. Aplicaia va consta n un ajutor de cutare on-line.

12

Capitolul 2 O caracteristic esenial a acestei funcionaliti const n caracterul permanent al acestei baze de date. n momentul schimbrii /actualizrii site-ului, coninutul bazei de date nu se va schimba. Operaiile eseniale oferite de acest funcionalitate se rezum la: prelucrare Web 2.0, memorare informaii relevante manipulare informaiei spre generarea unui coninut relevant utilizatorului persistena bazei de date odat generate

2.3 Editor
Aplicaia Editor are dou funcionaliti principale. prima funcionalitate este de manipulare. Aplicaia primete intrrile de la utilizator, le transform ntr-un format pe care aplicaia Generator le recunoate i apoi afieaz rspunsul acesteia. a doua funcionalitate este una de testare. Prin aplicaia Editor se poate verifica disponibilitatea serviciului, se limiteaz intrrile la Generator la cele pe care acesta le poate procesa i testeaz coninutul decurs din procesul de creeare. Datorit celor dou funcionaliti, Editorul poate fi ncadrat n tipul de aplicaie Front End[17], un mediu CAD (Computer Aided Design)[16] care s permit o creeare/modificare a unui site. Utilizatorii necesit un nivel minim de cunotiine despre web, mediul de dezvoltare trebuie s respecte conceptul usability aplicaia s fie folosit ntr-un mod uor i de plcut[18]. Mediul trebuie s permit importul de fiiere multimedia, dar nu prezint un editor al acestora. Fiierele sunt ataate paginilor web prin poziionarea acestora n cadrul pagini. Obiectivele principale se rezum la: ajutor creeare/editare/modificare pagini apelare serviciu web/ verificare disponibilitate serviciu publicarea unui rezultat parial respect conceptele Web 3.0 / Semantic web

13

Capitolul 3

Capitolul 3.

Studiu bibliografic

Parcurgerea obiectivelor din capitolul anterior, a relevat o serie de concepte i principii care au la baz studii bibliografice. Documentarea corespunztoare asupra acestor principii i tot ceea ce reprezint, este esenial n dezvoltarea corespunztoare a proiectului. Spre deosebire de capitolele anterioare, criteriul de clasificare dup care se va face partajul materialelor bibliografice n subcapitole, nu mai este elementul comun, ci importana studiului bibliografic pentru proiect. Fiecare subcapitol va prezenta o serie de concepte, prerile unor experi n domeniu, exemple practice ale conceptelor, apoi legtura dintre proiect i aceste concepte .

3.1 Conceptul Web X.0

Internetul a parcurs diverse stadii pentru ca s ajung unde este acum. Acest proces evolutiv s-a desfurat pe o perioad ndelungat de timp, interval n care att destinaia sa ct i tipicul utilizatorilor si s-a schimbat. Unii experi au ncercat s fac unele descrieri vizuale ale evoluiei Internetului, ca Tim Burners-Lee inventator WWW, el aseamn evoluia Internetului unui om aflat n continu cretere[4]. Ali autori, i nu puini, aseamn Internetul ca o evoluie de la stadiul de primate la stadiul de om[21]. Create n principal n scop de divertisment, aceste descrieri prezint etapele de dezvoltare i apoi le compar cu diferitele lor exemple. n activitatea doctrinar s-au propus diverse teorii legate de evoluia Internetului, dar nici una nu a fost la fel de bine acceptat ca teoria Web X.0. Deii propus de ctre Darcy DiNucci n articolul [19], ea a luat amploare dup ce a fost promovat de ctre Tim OReilly n diversele sale publicaii de la OReilly Media, exemplu articolul [6]. Seciunile urmtoare vor prezenta cteva aspecte importante legate de Web X.0 mpreun cu toate cele 4 concepte care formeaz Web X.0: Web 1.0, Web 2.0, Web 3.0 i Web 4.0.

3.1.1 Web X.0 Pro/Contra

Asemntor oricrui concept/teorie, nu toi specialitii sunt partizani ai acestei noiuni, dar pentru a putea expune prerile, trebuie nti prezentat o definiie. Conceptul Web X.0 cuprinde totalitatatea de stadii existente (Web 1.0, Web 2.0) i propuse (Web 3.0, Web 4.0) de ctre experii susintori ai acestui concept. El privete evoluia Internetului din punct de vedere al modului de folosin, nu din punct de vedere istoric. Tim OReilly definea n articolul su [20] Web 2.0 este un set de tendine economice, sociale i tehnologice care formeaz baza generaiei urmtoare a Internetului un mediu caracterizat prin participaia utilizatorului i deschidere. Pe parcursul promovrii conceptului, au existat preri care excludeau existena fenomenului Web 2.0. Majoritatea acestor preri au o baz tehnologic. n clipa n care se pronuna ideea de Web 2.0, tehnologia pe care se aplica era existent nc din perioada Web 1.0. Tim Berner-Lee n interviul [4] explic [Web] este un mediu colaborativ, un loc unde fiecare [...] poat s scrie i s citeasc. Internetul fusese gndit de la bun nceput s fie un mediu colaborativ, astfel Web 2.0 pare a fi acelai lucru cu Web 1.0. Mai mult, Directorul de la W3C califica n anul 2006, ntr-un interviu ctre DeveloperWorks IBM [22], Web 2.0 ca o bucat de jargon, nimeni nici nu tie ce nseamn exact. Aceast prere parea a fi mprit i de W3C. 14

Capitolul 3 O alt prere contra conceptului 2.0 se fundamenteaz pe exemplul Amazon.com. mpreun cu alte site-uri din perioada anului 1995, Amazon.com permitea review-uri din partea utilizatorilor si. Alte preri opuse Web 2.0, exemplu articolul [23], motiveaz inexistena conceptului datorit spectrului mult prea larg de aplicabilitate. Susintorul Web 2.0, Tim OReilly a rspuns n articolul [24] prin prezentarea conceptului n 7 capitole. El a cuprins ideile principale corespunztoare noului concept prin comparaie cu predecesorul su; articolul descrie diferenele dintre elementele Web 1.0 i Web 2.0, reliefnd ideile specifice conceptului Web 2.0. Un argument suplimentar i decisiv legat de existena i aplicabilitatea conceptului Web X.0, este dat de nsui cei care scriu internetul, utilizatorii. Datorit folosirii lui pe o scal larg, practica general asociat i perioadei ndelungat n care s-a invocat conceptul, a devenit larg acceptat de toi practicienii ct i de toi teoreticienii. nsui Tim Berners-Lee, cel care a denumit Web 2.0 o bucat de jargon, a recunoscut la Conferina Web 2.0 din anul 2009[25]: este un termen minunat pentru a oferi o linie de dezvoltare [a internetului] n ultimii ani.

3.1.2 Web 1.0

Naterea conceptului Web 1.0 este legat de Web 2.0. nainte de teoritizarea fcut de Nancy DiNucci n articolul [19] a conceptului Web 2.0, nu se poate spune de existena lui Web 1.0. ntr-adevr, aplicaiile Web 1.0 existau de mult timp, dar nimeni nu le-a calificat corespunztor. Principiul Web 1.0 descrie aplicaii de tipul top-down. Administratorii site-urilor publicau coninutul, utilizatorii doar vizualizau coninutul, nu puteau contribui n nici un fel. n articolul [26] Cormode G. descrie acest raport n urmtorul fel: creatorii de coninut web erau puini n Web 1.0, majoritatea utilizatoriilor jucau rolul unor simpli consumatori ai coninutului. O alt caracteristic este subliniat de Tim OReilly. El descria n articolul [24] aplicaiile Web 1.0 dependente de Software Release Cycle. Aplicaiile se modificau doar mpreun cu un nou release, softul nu se va ridica la aceeai performan dac nu este ntreinut n fiecare zi [24]. n cadrul aceluiai articol [24], Tim OReilly descrie targetul de site-uri folosite de tipul head: doar site-urile mari, sau cu trafic mare, primeau importana. Acest efect s-a simit n cadrul economic al WWW, exemplu paralela DoubleClick - Google AdSense. O ultim caracteristic esenial const n pagini srace din punct de vedere vizual. Siteurile se rezumau la un set de imagini i, foarte rar, unele sunete de acompaniere. De asemenea,Web 1.0 prezenta un nivel interactiv redus. Web 1.0 reprezint era afielor web pe suportul PC. n general coninutul Web 1.0 era destinat calculatoarelor. Cateva elemente Web 1.0:
Scopul principal: expunerea informaiei Arhitectur de tipul top-down Software release cycle Experiena utilizatorilor redus la cte click-uri i mail

Cateva elemente constatate din practica Web 1.0:

Pagini statice, lipsa de coninut dinamic Practic de codificare specifica HTML prin: frameset-uri, butoane imagini GIF, elemente ca <blink>,<marque> Poziionarea elementelor n pagin folosind tabele HTML

15

Capitolul 3

3.1.3 Web 2.0

n opoziie cu Web 1.0 vine Web 2.0. Coninutul expus on-line nu mai este in mna ofertanilor ci n mna consumatorului. Tim OReilly n articolul [6] descrie aceast trecere prin arhitectura n participaie utilizatori particip la dezvoltarea mediului on-line. Aceast arhitectur este unul din fundamentele Web 2.0. Acum site-urile sunt dezvoltate n modul bottom-up. ntr-un alt articol [24], Tim OReilly prezint o lucrare de tipul magna carta a aplicaiilor Web 2.0. El descrie n 7 capitole conceptul Web 2.0 prin exemplificare, oferind un studiu comparativ prezent/trecut. Primul capitol corespunde ideii de Web ca un Serviciu. Acum aplicaiile web nu mai trebuie s fie platforme bazate pe release cycle, ci aplicaii serviciu care se modific odat cu contentul oferit de utilizatori. Aceast prere este susinut n prezent de W3C. ntr-unul dintre tutorialele sale, W3C susine serviciile web duc aplicaiile web-based la urmtorul nivel[27]. Aceast tez va fi prezentat n detaliu ntr-un alt subcapitol. Valorificarea informaiei colective reprezint al doilea tiltlu(capitol). Prin Web 2.0, utilizatorii creeaz o cantitate mai mare de informaie, comparativ cu cea publicat de developeri. [..]Contribuiile utilizatorului [..]sunt cheia spre succes in era Web 2.0[24]. Tim Berners-Lee pare a susine aceeai idee n interviul [22]. El susine un internet n care toat lumea contribuie, internetul aa cum a fost gndit de la nceput. Dei nu numete a fi cheia de succes, fondatorul WWW susine colaborarea utilizatorilor n produsul web. A treia parte denumit generic: Informaia este urmtorul Intel Inside se poate rezuma la citatul SQL este noul HTML[24]. Importana unei baze de date care s conin ct mai multe informaii, fie ele adugate de creatori, fie de utilizatori, este crucial n Web 2.0. Cu ct baza de date este mai complet, mai greu de reconstruit sau conine informaii greu de gsit, cu att este mai valoroas. Cei de la W3C merg i mai departe n descrierea Semantic Web. Ei prezint un viitor n care bazele de date create pn acum, reprezint punctul de plecare. Acestea vor fi modificate primind semnificaie, aplicaiile vor nelege coninutul ,nu vor vedea doar un set de date . Titlul al patrulea vorbete despre finalul erei software release cycle. Acum aplicaiile trebuie s priveasc utilizatori [asemenea unor] co-developeri [24], numrul lor fiind mult mai mare ca developerii, cantitatea de coninut generat va crete proportional. Pentru a realiza acest scop este nevoie de aplicaii care sunt ntr-o continu schimbare, fr ca utilizatori s realizeze aceasta. Operaiile in de nucleul aplicaiei. Acesta se modific att de developeri ct i de coninutul publicat de utilizatori. Exemplu Google Page Rank. Urmtoarea parte vorbete despre modele de programare lightweight. Aceste modele consist din componente vag legate ntre ele. Scopul acestei legturi slabe este simplitatea ct i interoperabilitatea. Un exemplu oferit este REST n comparaie cu SOAP. Web 1.0 era gndit doar pentru calculatoare, titlul ase propune un software aplicabil mai multor dispozitive. Exemplu citat este iTunes. Aceast aplicaie este specific dispozitivelor Apple, care au n spate o aplicaie masiv web. Titlul final vorbete despre experiene bogate ale utilizatorilor. Aceast concept se bazeaz pe un design mai atractiv, limbaje care permit o interactivitate mrit. Spre deosebire de predecesorul su, mediul vizual primete o imortan deosebit. Web 2.0 Design Patterns:

16

Capitolul 3 The Long Tail[24] site-urile mici reprezint cea mai mare parte a internetului, astfel orice aplicaie s se concentreze la site-urile mari i la cele mici Aplicaiile sunt data-driven este important deinerea unei baze de date unice, o baz de date greu de recreat Utilizatorii adaug valoare utilizatori trebuie s se implice n adugarea coninutului Drepturi rezervate soft reutilizabil care aparine oricui The perpetual Beta aplicaii n continu modificare Cooperare, nu control s nu existe un monopol al unui serviciu Software specific mai multor dispozitive Cateva elemente constatate n practica Web 2.0: Limbaje orientate spre o grafic nbuntit: JavaScript, Ajax, Flash Socializarea internetului prin interoperabilitatea aplicaiilor Web 2.0, Servicii Web Necesitatea de generare cod reutilizabil oferit utilizatorului, exemple YouTube; Flickr;
sau chiar opiuni de manipulare: Facebook, Twitter, etc

Limbaje predominante: HTML, XHTML, PHP, ASP, JSP n seciunea urmtoare se vor prezenta cteva tabele comparative Web 1.0 Web 2.0. 3.1.3.1 Web 1.0 Web 2.0 Jeffrey Henning, n prezentarea [28], ofer o scurt i simpl comparaie ntre Web 1.0 i Web 2.0 - Tabelul 3.1. Aceast prezentare simplist prezint esenialul diferenelor Web 1.0 2.0. Tabelul 3.1 Web 1.0 Web 2.0 Oneway Twoway Autoritar Democratic Pasiv Activ Static Dinamic nchis Colaborativ Toate comparaiile se bazeaz pe diferena din perspectiva utilizatorului. Prima prezint cele dou concepte asemntor comunicarii dintre dou persoane. One way - sunt aplicaiile n care utilizatorul nu poate aduga coninut, doar s vizualizeze asemntor unui monolog. Twoway este dialogul Web, utilizatorul poate citi i aduga coninut. Celelalte comparaii sunt legate de prima. Web 1.0 este autoritar i static datorit rigiditii sale, pe cnd Web 2.0 este democratic i dinamic, permite i utilizatorului s participe la creearea coninutului. Choise Media Group,Vovici, ntr-un webcast[29], a prezentat clasificarea dup Tabelul 3.2. Aceast comparaie repet i completeaz cea fcut de Jeffrey Henning. Tabelul 3.2. Web 1.0 Web 2.0 Coninut Read-Only Coninut generat de utilizator Ochi Maini Stickiness Syndication Editor Buzz Pagini Personale Blog Centralizat Croudsourcing

17

Capitolul 3 Prima comparaie, mpreun cu doua, repet prezentarea diferenelor dintre concepte din prisma utilizatorului, singura diferen const n modul de exprimare. A doua comparaie prezint ntr-o manier artistic ceea ce a fost expus n prima comparaie. Raportul Stickiness/Syndication reprezint caracterul Rigid/Flexibil corespunztor celor dou concepte. Stickiness reprezint inflexibilitatea aplicaiilor Web 1.0 n opoziie cu flexibilitatea aplicaiilor Web 2.0. Aici Syndication nu se refer la RSS feed. Diferena Editor/Buzz se rezum la modul de publicare a coninutului a dou aplicaii specifice conceptelor din care faceau parte. Editor publica informaiile oferite de autor, dar nu permitea adugarea de coninut din o surs exiterioar. Buzz(Google) era o reea de socializare n carea utilizatorii puteau face schimb de informaii. Ambele servicii nu mai sunt disponibile astzi. Diferena pagini personale/blog este una de coninut. Ambele permit unui utilizator s publice informaii, diferena este din perspecitva cititorului. Asemntor cu deosebirea principal intre Buzz/Editor, utilizatorii pot aduga preri legate de articolele publicate doar pe Blog, nu i n cadrul Paginilor personalizate. Este important urmtoarea meniune: paginile personalizate, din comparaia pagini personalizate/blog, sunt pagini specifice Web 1.0. n cazul n care ele ofer posibilitatea de feedback, ele sunt produse Web 2.0. Ultima comparaie este la nivelul dezvoltatorilor. n Web 1.0 dezvoltatorii coninutului aplicaiilor Web erau doar programatorii care publicau aplicaia. Spre deosebire de predecesorul su, acum consumatorii produsului Web 2.0 devin i ei dezvoltatori ai coninutului (codeveloperi)[24]. Croudsourcing nseamn externalizarea unui serviciu ctre un grup de specialiti sau comunitate sub forma unei competiii de dezvoltare. Diferena croudsourcing/outsourcing const n publicul la care este predat. Croudsourcing se aplic unui public nedefinit. Tim OReilly, n lucrarea sa [24], a formulat cteva exemple Web 1.0 Web 2.0. Aceste exemple stau la baza celor apte principii enunate. Tabelul 3.3 corespunde lucrrii [24] i conine exemple de aplicaii sau principii care reliefeaz Web 1.0 i Web 2.0. Tabelul 3.3 Web 1.0 Web 2.0 Doubleclick GoogleAdSense Ofoto Flickr Akamai BitTorrent Mp3.com Napster Britannica Online Wikipedia Personal websites Bloging evite Upcoming.org i EVDB Domain name speculation Search engine optimization Page views Cost per click Screen scraping Web services Publishing Participation Content management systems Wikis Directories (taxonomy) Tagging (folksonomy) Principala diferen DoubleClick/AdSense a fost targetul de site-uri folosite. AdSense a demonstrat c serviciile pentru consumatori i managementul informaiei algoritmice trebuie s se ntind peste tot web-ul, pn la margini, nu doar la centru, la coada sa lung, nu doar la cap[24]. DoubleClick era un model care susinea: cei care fceau promovarea fceau regulile, iar publicitatea era dedicat doar celor mari. Vizitatorii se orientau n general spre aceste pagini. 18

Capitolul 3 Succesul Adsense a constat n posibilitatea de a publica pe orice pagin advertisements i spre deosebire de predecesorul su, nu necesita un contract de vnzri. Acum publicitatea nu apare doar pe site-uri mari, ci poate aprea pe orice site. Diferena Akamai/BitTorrent este una crucial. Ambele servicii se ocup de transferul de fiiere ctre utilizatori. Diferena ntre cele dou era modul de transmisie. Akamai oferea fiierele de pe serverele lor, pe cnd BitTorrent se folosea de arhitecturi n participaie [6]. BitTorrent se folosea de ideea lui Tim Berners-Lee, o aplicaie devine mai bun cu ct mai muli utilizatori particip la ea. n cazul n care serverele devin suprasolicitate, cei de la Akamai trebuiau s adauge alte servere, pe cnd la BitTorrent o suprancrcare pare greu posibil datorit participaiei utilizatorilor att la download ct i la upload. Acelai argument este revelator n comparaia Mp3.com/Napster. Comparaia ntre cele dou enciclopedii Online Britannica Online/Wikipedia este asemntoare cu cea Akamai/BitTorrent. Dei Britannica produce articole mai relevante/preioase dect Wikipedia, Britannica nu va putea niciodat produce o cantitate mai mare de articole ca Wikipedia, datorit numrului de editori/utilizatori. Comparaia dintre cele dou e asemntoare cu One-Way/Two Way a lui Jeffrey Henning. n aceast comparaie Web 2.0 pare a fi n dezavantaj datorit raportului cantitate/calitate. La o prim vedere aa este, dar cu un numr tot mai mare de contribuitori la mediul Wikipedia, calitatea ncepe s creasc odat cu cantitatea. Nivelul de utilizatori/creatori de coninut Wikipedia este n continu cretere. Site-ul [40] conine informaii suplimentare pe acest subiect. Diferenele ntre publishing/participation; personal websites/blogs; Ofoto/Flickr; Screen Scraping/WebServices, sunt parcurse n mare n paragrafele anterioare. Diferenele dintre acestea reprezint aplicarea unui principiu specific Web 1.0/Web 2.0 n diferite contexte de dezvoltare.

3.1.4 Web 3.0

Dup sedimentarea Web 2.0, muli experi au propus diverse opinii n ceea ce privete viitorul internetului. Aceste idei prezint diferite laturi ale internetului, stadiile lor de dezvoltare, iar toate se intituleaz Web 3.0. Interesant este faptul c, majoritatea conceptelor par s atribuie Web 3.0 la o singur idee de dezvoltare. Aceast abordare este greit. Primele dou stadii nu se rezum doar la un singur concept sau idee de dezvoltare. Web 3.0 trebuie s fie asemntor predecesorilor lui, asimilnd o serie de concepte sub o singur sigl. Dintre toate aceste teorii, cele mai des ntlnite concepte Web 3.0 sunt cele prezentate n lista de mai jos. Ele sunt denumite mpreun cu articolul n care au fost expuse: a) Scalable Vector Graphics [30], b) Inteligen artificial [31], c) First generation Metaverse [32], d) Informaia i modul de folosin [33], e) Semantic Web, larg acceptat ca sinonim cu Web 3.0,[34]. Aceste cinci concepte par a fi cel mai des legate de Web 3.0. Pe lng aceste opinii, exist i alte speculri, cum ar fi [35] n care Web este vzut n rolul unui nou TV. Sti International, n proiectele sale aflate sub sigla The Future of the Internet [36], vorbete despre un internet n care toate dispozitivele sunt interconectate ntre ele (PC,TV, aparate electrocasnice, etc.), un internet al lucrurilor. Exist i alte concepte susinute de alte nterprinderi sau ali academicieni, dar cele enumerate mai sus sunt cele mai citate.

19

Capitolul 3 Directorul W3C Tim Berners-Lee a descris Web 3.0: un amestec ntre o grafic format din vectori scalari, cu un acces la un Web semantic integrat pe un spaiu imens de informaii, n care vei avea acces la o cantitate incredibil de resurse. Aceast prere este mprtit i de ali experi, n prezent, majoritatea practicienilor ct i teoreticienilor susin aceeai idee. Web 3.0 pare a avea la baz cele cinci concepte enumerate mai sus. 3.1.4.1 Elementele Web 3.0 Primele patru direcii de dezvoltare cuprinse n acest subcapitol sunt tangente cu proiectul dezvoltat, astfel ele vor fi descrise pe scurt. Scalable Vector Graphics, considerat ntre Web 2.0 i Web 3.0, este deja folosit n dezvoltarea aplicaiilor web. SVG este o familie de specificaii, bazate pe XML, pentru descrierea imaginilor, statice sau dinamice, ntr-un spaiu vectorial bi-dimensional. SVG a cunoscut o serie de versiuni, n prezent 1.1 fiind recomandat de W3C. Acest standard este folosit de o perioad ndelungat, el este un proiect open standard din anul 1999. n prezent, majoritatea browserelor web cunosc i au o implementare pentru SVG. Apartenena lui la Web 3.0 se explic prin abundena n practic a acestui format, spre deosebire de predecesorii si Web. Inteligena artificial va avea o importan major n experiena online. Aplicaiile Web 3.0 trebuie s fie capabile s efectueze seturi de sarcini specifice utilizatorului. Fie aplicaia va citi profilul utilizatorului [7], fie va face operaii pentru utilizator, fie aplicaia va genera content[31], domeniul de aplicabilitate va fi foarte mare. Un lucru este sigur, web 3.0 va introduce Inteligena Artificial n domeniul Web[41]. First Generation Metaverse, definit n articolul [32] i amintit n articolul [7]. Web 3.0 va unii Internetul cu lumea 3D. Vor exista aplicaii care localizeaz i genereaz modele 3D. Unele preri merg mai departe, Internetul va fi n 3D. Aceast prere pare plauzibil datorit efortului interprins de dezvoltare a unei alternative OpenGL, denumit WebGL[36]. Aceast platform scris n AJAX permite aplicaiilor care folosesc OpenGL s ruleze n interiorul browserului. Informaia i modul su de foloisin. Reid Hoffman, cofondator LinkedIn, a prezentat ntr-o conferin [37] importana informaiei i modul cum va circula on-line. Web 3.0 va conine toat informaia produs de 2.0, mpreun cu informaii analitice[37]. Aceast informaie trebuie clasificat dup importana sa, procesat, iar din ea se va genera noul coninut. Acum aplicaiile vor contribui la coninutul paginilor, mpreun cu utilizatorii (Web 2.0) i autorii (Web 1.0). 3.1.4.2 Semantic Web - Teorie Deseori folosit ca sinonim cu Web 3.0, Semantic Web arat un internet n care aplicaiile web nu doar afieaz informaii ci i interpreteaz. Tim Berners-Lee descrie Semantic web n cartea sa [38] un web de informaii care poate fi procesat direct sau indirect de ctre maini. James Hendler n articolul [39] descrie Semantic Web: scopul acestei noi tehnologii este dezvoltarea comunicrii ntre oameni, folosind diferite terminologii care extind interoperabilitatea bazelor de date, care s furnizeze instrumente pentru interactivitatea cu coleciile multimedia i s asigure noi mecanisme pentru suport al tiinei. Tot n acest articol el scrie: Pentru a ajunge la acest potenial, oamenii de tiin i inginerii tehnologiei informaiei 20

Capitolul 3 trebuie s creeze noi modele de cooperare[] pentru noua generaie de instrumente tiinifice pe Web. Semantic Web propune un internet care se bazeaz pe cunotine collection of knowledge[38]. El va permite utilizatorilor s adauge ceea ce cunosc, aplicaiile s neleag i s rspund la diferite ntrebri. W3C definete, pe site-ul oficial [42], Semantic Web ca o extensie a World Wide Web, care permite utilizatorilor s mpart informaii dincolo de limitele aplicaiilor i website-urilor. El este descris ori ca un web of data, fie un salt spre o paradigm natural n folosina de zi cu zi a Web-ului, sau ca un internet mai aproape de om. Aceast extensie nu va nsemna un nou Internet. Datele oferite de ctre Web 2.0 vor fi utile n dezvoltarea noului Internet. Pe baza unor legturi semantice, se va genera coninut nou din cel vechi. Informaia generat trebuie s fie ntr-o form structurat de date, va fi editat n aa fel nct s poat fi citit att de utilizatori ct i de aplicaii. Tot n site-ul [42], Semantic Web primete dou caracteristici : [...] formate comune pentru integrare i combinare a datelor provenite din diverse surse, spre deosebire de Web-ul anterior care se ocupa doar de intreschimbul de resurse; de asemenea: Semantic Web definete [...] cum datele Web sunt legate de obiecte reale Odat cu promovarea i acceptarea conceptului de Semantic Web ca un pas firesc n dezvoltarea Web, au nceput s apar diverse preri despre cum s-ar putea implementa. Tim Berners-Lee, n prezentarea sa [43], a descris Arhitectura Semantic Web ntr-o form denumit generic : Semantic Web Cake , Figura 3.1.

Figura 3.1 Semantic Web aa cum a fost prezentat de Tim Berners-Lee n 2000 Structura prezentat de Arhitectura Semantic Web trebuie analizat bottom-up. Prima parte conine unicode i URI mpreun cu XML i xmlschema. Descrierea elementelor specifice acestui nivel se bazeaz pe definiiile oferite de W3C[44]. Unicode reprezint un standard de codificare, reprezentare i manipulare a caracterelor text, din majoritatea sistemelor de scriere din lume. URI Uniform Resource Identifier este format dintr-un ir de caractere care descrie o resurs dintr-o reea. Aceste dou componente se ocup de identificarea elementelor pe Web printr-o codificare adecvat. XML este un limbaj de descriere a datelor, uor inteligibil att aplicaiilor ct i oamenilor. Xmlschema este o particularizare a modului de reprezentare XML prin definirea unor seturi de reguli pentru reprezentarea datelor. NS provine de la namespace i propune un set de denumiri unice pentru elementele i atributele dintr-un document. XML ofer un suport corespunztor 21

Capitolul 3 pentru codificarea semanticii, datorit practicii asociate ct i uurinei de manipulare a formatului. RDF Resource Description Framework se bazeaz pe o tripl de informaie, format din: un subiect, un obiect i verbul/predicatul care leag cele dou. Subiectul i Obiectul reprezint resurse care dein propria identitate. Aceast identitate este descris individual n resurse descriptive, printr-un URI. Legtura dintre resurse este realizat printr-o descriere. Aceasta este un container care conine cteva afirmaii despre resurs. Exemplu 3.1,Tripla: Ana are mere, grafic: are Subiect Ana Descriere mere Obiect

Exemplu 3.1, Tripla: Ana are mere, XML: <rdf:Description about=[Ana] xmlns:are=[NS]> <predicatulMeu rdf:resource=[mere] /> </rdf:description> Codul anterior prezint Ana ca o resurs; se definete un namespace pentru relaia are; se specific legtura cu resursa mere. Subiectul i descrierea (predicatul) sunt de regul reprezentate prin URI. Obiectul este fie un alt URI, fie un string sau un numr. Exemplu 3.2 din perspectiva URI: Subiect Descriere/Predicat Obiect <http://exemplu.com/persoana/Ana> - <http://ontologiefamilie.com/1.0#areTata> <http://exemplu.com/persoana/Ion > RDF definete clase, obiecte i predicate mpreun cu anumite reguli specifice fiecruia. RDF + rdfschema reprezint setul de reguli care trebuie respectate, oferind o structur de siguran pentru dezvoltarea semanticii. Ontologia este un model folosit pentru repezentarea informaiei, un set de concepte dintrun domeniu, i modul cum relaioneaz reprezentrile. Ontologia se bazeaz pe RDF i prezint resursele sub denumirea de clase. ntr-o ontologie se adaug semantica la resursele specificate(una sau mai multe RDF), singura condiie este unicitatea termenilor descrii n clase. Scopul ontologiei este de a crea relaii din schemele descrise de RDF, mpreun cu crearea altor relaii (subiecte/predicate/obiecte). Ontologia prezint urmtoarele caracteristici: formate din triple, asemntor cu RDF uor de extins definirea unei triple noi formeaz o relaie nou prin modificarea semnificaiei subiectelor/predicatelor/obiectelor nu se modific ontologia alternative excelente la cod surs ontologia este mai uor de modificat adaptabilitate Logica se formeaz din ontologie i conine toate relaiile formate. Proof reprezint totalitatea de legturi formate la cerere sub forma unei query. 22

Capitolul 3 Trust reprezint nivelul de ncredere n resursa respectiv. Acesta se pot prelua din diverse servicii on-line. Nivelul de ncredere favorizeaz o legtur semantic fa de alta. Scopul Semanticii Web este de a oferi un neles, din perspectiva dispozitivelor/aplicaiilor, a datelor publicate. n urma realizrii acestui concept, aplicaiile vor fi capabile s rspund la ntrebrile formulate n limbaj natural. n prezent, W3C susine un efort de promovare i recomandare Semantic Web.

3.1.5 Web 4.0

Dei o discuie pe tema Web 4.0 pare prematur, Web 4.0 poate s fie mai apropape de prezent decat s-ar putea crede. Dup cum am specificat mai sus, Web 3.0 este legat, n principal, de cinci concepte, restul fie nu sunt legate de Web 3.0, fie vor urma s fie adugate. Web 4.0 poate fi doar un subiect de speculaie. Din acest motiv orice direcie de dezvoltare propus este fie una progresist, n care se prezint aplicaii web n curs de dezvoltare, ca fiind parte din o nou generaie, fie una tenedential, o direcie n care se va dezvolta Web. Un exemplu pentru un Web 4.0 progresist este Web Operating System. Acest tip de sistem de operare presupune un PC cu o plac de reea, o plac video care s proceseze semnalul trimis mpreun cu un porcesor care s efectueze un set minim de operaii. Un astfel de sitem de operare va nltura necesitatea schimbrii PC-ului datorit creterii criteriului de performan. Aceast prere este susinut de Ray Kurzweil[45] i Nova Spivack[46]. Web 4.0, pe criteriu tendenial, arat dezvoltarea internetului ntr-o anumit direcie. O astfel de prere este un Web inteligent, capabil de reasoning. Stadiul Web 3.0 face aplicaiile web capabile s gndeasc. Web 2.0 se manifest pe mai multe platforme. n prezent vedem din ce n ce mai multe dispozitive capabile s se conecteze i s primeasc comenzi prin internet. Poate viitorul va conine un web al lucrurilor n care toate operaiile vor fi fcute cu comenzi vocale n limbajul natural uman, prin intermediul Internetului. Legtura Concept Web X.0 Proiect este una evident. Aplicaia descris de proiectul prezent se fundamentez pe conceptele Web X.0.

3.2 Generatoare de Site-uri

Programarea automatic este acea ramur a developementului de soft n care dezvoltatorii scriu cod la un nivel nalt de abstractizare. Aceste aplicaii conin mecanisme care genereaz cod pentru utilizator [47]. n general, astfel de practici sunt asociate unor aplicaii care au la baz segmente de cod reutilizabil. James Wilcox, n articolul [48], descrie - generative programming ca un stil de programare care folosete cod surs automat, generic, bazat pe frame-uri, clase, prototip, template-uri care s nbunteasc productivitatea programatorului. Generatoarele de site-uri sunt undeva la mijloc ntre aceste dou tipuri de dezvoltare. Aplicaiile generatoare de cod trebuie s dezvolte, prin programare automatic, site-uri, folosindu-se de codul surs generat prin generative programming. Tipicul de utilizator care folosete aplicaii scrise dup cele dou modele de programare sunt dezvoltatorii. Aplicaia generatoare de site-uri, dei ofer suport i pentru cunosctori, este dedicat unui mediu mai larg, unor profani n domeniul programrii. Numrul de lucrri teoretice legate de generatoare de site-uri este minimal comparativ cu practica asociat. Exist diferite tipuri de medii de generare a site-urilor. Ele difer dup limbajele folosite, complexitatea desingului folosit, operaiile oferite, etc. 23

Capitolul 3 Din 1996, cei de la W3C lucreaz spre a propune un generator/editor de site-uri. Acest efort a luat denumirea de Amaya. Scopul acestei aplicaii a fost, de la bun nceput, unirea ctor mai multe standarde W3C sub un singur editor. Legtura studiului bibliografic Generatoare de Site-uri Proiect este una de gen specie. Totalitatea principiilor descrise n acest studiu vor fi aplicate nemijlocit n Proiect.

3.3 Web Service

Serviciile Web sunt aplicaii independete, create cu scopul de a rezolva taskuri specifice, oferite ctre alte aplicaii la cerere. Aceste servicii reprezint o modalitate standard de integrare a diferitelor aplicaii Web. Bazate pe o comunicare n limbajul XML, Serviciile Web sunt independente de platform, de limbaje de programare i de siteme de operare. Una dintre ideile propuse de conceptul Web 2.0 este dezvoltarea aplicaiilor web folosind web service. Aceast metod permite conversia aplicaiilor statice n aplicaii Web-based folosite prin intermediul Internetului, LAN sau WAN. Tim OReilly descrie, n articolul [24], Aplicaiile web service ca fiind parte dintr-un nou Internet. Spre deosebire de Web 1.0, aplicaiile 2.0 se vor folosii de operaii oferite de servicii web pentru a prezenta compusul final. Modul de folosire a Serviciilor Web este descris prin Service Oriented Arhitecture (SOA). Aceast arhitectur conine principiile i metodologiile pentru proiectarea i dezvoltarea softului n forma unor aplicaii interoperabile. Arhitectura SOA nu se reduce doar la dezvoltarea serviciilor Web, ci conine principii privind integrarea lor n diferite aplicaii. W3C descrie dou tipuri de Web Service: se pot indentifica dou tipuri de clase de Web Service. Primul este Web Service REST n care scopul principal este manipularea reprezentrii resurselor Web bazate pe XML, folosind un set uniform de operaii stateless. A doua variant este denumit Arbitrary Web Service n care serviciul expune un set de operaii arbitrare [49]. Arhitectura de funcionare a unui Web Service Arbitrar: Service Broker WSDL WSDL

Service Requester

SOAP

Service Provier

Serviciile Web arbitrare prezint trei actori: Service Brooker, Service Provider i Service Requestor. Fiecare dintre actori comunic unul cu cellalt prin mesaje. Aceste mesaje difer dup tipul de actori, dar toate sunt scrise n limbaj XML. Ian J. Taylor, n lucrearea sa [50], prezint modul de funcionare a arhitecturii Serviciilor Web: Service Broker are un singur scop, publicarea existenei serviciilor. Service Provider descrie funcionalitiile sale Brokerului n formatul WSDL. Service Broker va publica informaiile specifice serviciului n format UDDI, Universal Description, Discovery and Integration, dar interogarea Service Requestor-lui este realizat prin WSDL. 24

Capitolul 3 Service provider este Serviciul Web. El ofer informaii ctre Broker despre funcionalitile sale. Dup tipul de descriere UDDI, aceste informaii conin trei componente[50]: White Pages ofer informaii despre partea de bussines care furnizeaz serviciul Yellow Pages ofer o clasificare a serviciului pe baza taxonomiilor de baz Green Pages sunt folosite la descrierea modului cum se acceseaz serviciul Web Dup ce un Service Requestor s-a hotrt s utilizeze serviciul oferit de Provider, Requestorul va face schimb de mesaje de tip SOAP cu Providerul. Aceste mesaje vor conine informaiile specifice intrrilor/ieirilor serviciului. Mesajul SOAP Simple Object Access Protocol reprezint o modalitate de codificare a obiectelor/variabilelor/intrrilor/ieirilor n formatul XML. Structura sa prezint un Envelope care conine doi copii: Header i Body. SOAP header, opional, este folosit pentru descrierea unor informaii legate de aplicaie, exemplu: informaii legate de calea de transmitere. SOAP body, obligatoriu, conine informaii pentru destinatarul mesajului. SOAP fault, aparine de body, este partea din mesaj destinat erorilor. SOAP este o recomandare W3C din anul 2003. Cealalalt variant a arhitecturii Serviciilor Web este REST. Succesul Representational state transfer (REST), fa de modelele care folosesc SOAP sau WSDL, este datorat simplitii modelului arhitectural. Arhitecturile REST comunic prin resurse stateless. Ele folosesc protocolul HTTP, interfaa mesajelor este constrns n formatul operaiilor standard HTTP (GET,PUT,DELETE, etc.). Spre deosebire de arhitecturile care folosesc SOAP sau WSDL, arhitectura REST nu folosete neaparat formatul WSDL. Aplicaiile care dezvolt servicii web implementate folosind HTTP i principiile REST sunt denumite generic RESTful. Celi de la W3C pe site-ul oficial [51] prezint o list cu caracteristicile unui Web Service: - componente ale unei aplicaii - comunic folosind protocoluri deschise - self-contained, self-describing, independente - se descoper folosind UDDI - pot fi folosite de ctre alte aplicaii - XML este baza Serviciilor Web Serviciile web, arhitectura SOA i variantele de arhitecturi de implementare a serviciilor web sunt recomandri W3C din anul 2003. Necesitatea fundamentrii Web Service Proiect este bazat pe o component descris n capitolul anterior Serviciul Generator Web 3.0.

3.4 Social Dashboards

Unificarea tuturor aplicaiilor Web 2.0 de socializare, sub o singur platform, este realizat de aplicaii denumite Social Dashboards. Utilitatea acestor platforme const n uurina de manipulare a informaiilor primite de la diferitele aplicaii Web 2.0, elmininnd factorul de conectare i verificare individual. Pentru construcia unui dashboard este nevoie de parcurgerea anumitor informaii oferite de ctre produsele Web 2.0. Justin Cutroni, membru Google Analytics a expus, n prezentarea sa [52], cteva dimensiuni i metrici specifice aplicaiilor dashboard:

25

Capitolul 3 Data Hub Activities totalitatea activitiilor din reelele sociale reprezint o platform deschis de informaii; conine totalitatea activitiilor pentru un site Social Network totalitatea reelelor de socializare care permit transmiterea traficului ctre un site Social Source Referral verificarea informaiilor primite dac provin de la o surs de trafic social Social Source & Action aciunile specifice reelei de socializare Social Entity URL-ul mprit pe social media Social Type tipul de site social Aceste informaii trebuie luate n vedere n momentul integrrii unei aplicaii de socializare n Dashboard. n ceea ce privete activitatea oferit de un dashboard, prezentat tot n articolul [52], exist o clasificare n trei tipuri de activiti: activitate off-site, activitate on-site i conversaii/rezultate. Activitatea off-site reprezint setul de funcionaliti disponibile utilizatorului n clipa lipsei de conexiuni cu servicul Web 2.0, mpreun cu funcionalitiile exterioare manipulrii acestor aplicaii. Scopul principal al aplicaiei dashboard este activitatea on-site. Operaiile de creeare/modificare/tergere a coninutului aplicaiilor web 2.0 reprezint funcionalitile on-site. Conversaii/rezultate reprezint acea parte a aplicaiei n care se leag diversele platforme mpreun. Coninutul din o aplicaie 2.0 trebuie s poat fi publicat n interiorul altei aplicaiii 2.0. Necesitatea prezentrii unor elemente teoretice despre social dashboard este folositoare n analiza necesar alegerii aplicaiilor incluse n aplicaia dashboard.

3.5 Data mining

Cunoscut sub denumirea de Knowledge Discovery in Databases, Data Mining este o disciplin a tiinei calculatoarelor care proceseaz informaii din seturi de date. ACM Special Interest Group on Knowledge Discovery and Data Mining, n curiculum su[53], descrie aceast disciplin: se afl la intersecia inteligenei artificiale, machine learning, statistici i a bazelor de date . Scopul acestei tiine este extragera informaiei dintr-un set de date. n articolul [54] Procesul de Knlowledge Discovery n baze de date este definit a avea 5 etape: Selecie Preprocesare Transformare Data Mining Interpretare/Evaluare n etapa de selecie se alege aplicaia i informaia din cadrul aplicaiei. Pre-pocesarea este succesiv seleciei, n care se alege o cantitate de informaie care urmeaz s fie supus procesului de Mining. n aceast etap se elimin informaiile care conin zgomore sau prezint informaii incomplete. Transformarea este etapa n care datele specific unui limbaj sunt transpuse n mediul limbajului de data mining. Data Mining conine ase seturi de clase[54]: Detectarea de anomali date care pot fi considera neobinuite sau prezint erori 26

Capitolul 3 nvarea bazat pe reguli caut legturi ntre variabile Clustering se caut grupuri i structuri de informaii. Clasificare metod prin care se aplic structura nvat n seturi noi de date Regresie etapa n care se caut o funcie specific setului de date Sumarizare generarea reprezentrii setului de date n diferite formate cerute de utilizator Ultima etap, de interpretare/evaluare este una de testare final. n funcie de ce s-a generat prin procesul de Data Mining, se vor testa rezultatele pe seturi mari de date. Necesitatea prezentrii unor elemente fundamentale legate de data mining este una de informare. Aplicaia va propune un algoritm de cutare fundamentat n prezentul sub-capitol.

27

Capitolul 4

Capitolul 4.

Analiz i fundamentare teoretica

Capitolele anterioare prezint obiectivele urmarite de proiect, apoi cateva studii care stau la baza dezvoltrii prezentei aplicaii. Prezentul capitol va oferi o analiz a cerinelor funcionale i non-funcionale mpreun cu o descriere a arhitecturii proiectului. Cerinele funcionale i non-funcionale vor fi prezentate la nivelul fiecrei componente a proiectului. Dac este cazul, se vor face meniuni referitoare la conceptul Web care fundamenteaz o cerin. Cerinele vor fi clasificate dup modelul propus de Ian Sommerville n prezentarea [55]. Arhitectura aplicaiei va fi prezentat pe baza celor trei componente descrise anterior, mpreun cu motivul separaiei proiectului n trei aplicaii individuale.

4.1 Analiza general

Proiectul ofer un generator de site-uri Web 3.0, mpreun cu toate componentele necesare pentru creeare, editare i testare. Elementele specifice proiectului au fost descrise n cadrul capitolului 2, mpreun cu o list de cerine impuse. Capitolul 3 a prezentat conceptele care sunt invocate n analiza i dezvoltarea proiectului, urmnd ca acum s fie prezentat tema proiectului n detaliu mpreun cu analiza proiectului. Tema proiectului cuprinde patru cerine principale, descrise n forma unei cerine utilizator[55] n limbaj natural : proiectul este o aplicaie Web care ofer mijloace de creeare/editare a unui site aplicaia trebuie s prezinte un minim de instrumente prin care se permite conectarea la reelele de socializare. site-ul generat permite adugare de coninut n cadrul paginilor prin reelele de socializare aplicaia trebuie s respecte standardele Semantic Web cu posibilitate de stocare de date Pe lng aceste cerine utilizator, se mai adaog cteva cerine sistem legate de aplicaia Web descris de proiect: trebuie s aib la baza conceptele Web 2.0 i 3.0 trebuie s suporte fiiere standard HTML trebuie definit un standard de codificare mpreun cu aceste cerine, este util specificarea unor cerine non-funcionale suplimentare, specifice proiectului n ansamblu: robustee aplicaia trebuie s se fac fa probabilelor erori generate, tehnici care asigur folosirea intrrilor corespunztoare accesibilitate aplicaia s fie accesibil unui numr mare de utilizatori disponibilitate aplicaia s fie disponibil oricnd utilizatorul dorete s o foloseasc backup aplicaia prezint metode care ajut la restabilirea ntr-un stadiu precedent, n caz de nefolosire extensibilitate principiu de design, implementarea este creat n aa fel nct s fie pregtit pentru o probabil modificare viitoare mentenabilitatea uurin n determinarea unor defecte, ndeplinirea unor noi sarcini compatibilitate cu un numr mare de platforme 28

Capitolul 4 portabilitate posibilitatea de a utiliza aplicaia n mai multe medii posibilitatea de executare n cazul unor resurse limitate Aceste cerine se aplic pe ansablul proiectului, urmnd a fi enunate la nivelul fiecrei componente.

4.2. Analiza componente

Pe baza cerinelor funcionale afiate, mpreun cu alte motive prezentate n prezentul subcapitol, se observ trei categorii de cerine: a) cerine legate de site-ul generat b) cerine de procesare a intrrilor n cod c) cerine legate de editarea site-ului Urmrind fiecare set de cerine, se poate observa independena fiecrui set, astfel, exist posibilitatea dezvoltrii aplicaiei n trei componente independente. Prima component reprezint produsul generat Site-ul Web 3.0. A doua component este o aplicaie care prelucreaz intrrile oferite de ctre utilizator i produce prima componenta - Generator. A treia component joac rolul unui editor care manipuleaz intrrile utilizatorului i trimite informaia spre generare/creearea/modificare a site-ului - Editor. Separaia proiectului n componente se dovedete a fi util din mai multe motive: 1. Componentele sunt creeate n aa fel nct s respecte conceptele Web X.0. Exemplu: Web 2.0: arhitectura n participaie Site; software oriented arhitecture Generator, Editor; aplicaii data-driven: Site, Generator; perpetual beta: Site,Generator,Editor; limbaje orientate spre o grafic nbuntit: Site,Generator,Editor; cod reutilizabil:Site,Editor; caracter democratic al coninutului amestecat cu caracter autoritar:Site; croudsourcing:Site,Generator; Web 3.0: Semantic Web: Site, Generator; Scalable Vector Graphics: Site, Generator; Data Mining/Inteligen artificial: Site; 2. Cerinele non-funcionale ale componentelor: Certificare acreditarea aplicaiei de ctre o surs exterioar Site Conformitate definirea unor standarde de intrare specifice doar n procesul de editare Editor Independena fiecare component este independent de cealalalt Mentenabilitatea fiecare component este mai uor de verificat/modificat Extensibilitate componentele se pot modifica fr ca utilizatorul s cunoasc, principiu legat de perpetual beta Web 2.0; Documentare doar o component are intrri stabilite pe baza unei documentaii, celelalte dou pot fi schimbate: Generator Inter-operabilitate abilitatea celor trei componente de a lucra mpreun; interoperabilitatea nu se limiteaz doar la cele 3 Scalabilitate componentele pot fi mrite fr ca celelalte s fie modificate 3. Cerinele funcionale: 29

Capitolul 4 Fiecare component prezint un set specific de cerine funcionale Componentele sunt dezvoltate/verificare independent Independena componentelor; ele pot fi folosite i de ctre alte aplicaii n cadrul setului de cerine specificate Fiecare din aceste cerine funcionale/non-funcionale vor fi prezentate la nivelul fiecrei componente. Urmtoarea etap n dezvoltarea proiectului este analiza, n detaliu, a componentelor prin prezentarea tuturor cerinelor specifice.

4.2.1 Site-ul web

Produsul final a Generatorului i Editorului este Site-ul Web 3.0. El trebuie s realizeze un numr sarcini limitate la operaii de scriere/afiare a coninutului i ar trebui s prezinte operaii de manipulare a informaiilor. Sarcinile sunt definite la nivelul fiecrei pagini Web, n cadrul operaiei de editare de ctre utilizator. Autorul va creea un numr de pagini particulare, apoi va adauga posibiliti de editare a coninutului din surse exterioare. Site-ul va conine i o zon rezervat autorului n care va putea edita numarul de pagini. Operaia de tergere este limitat la nivelul paginii sau a coninutului din pagina; operaia de adaugare este limitat la clonarea unei pagini, urmat de o modificare a acesteia; operaia de modificare este limitat la modificarea coninutului text/poze/video din pagina. Acestea sunt aspectele principale ale componentei Site-ului descrise sub forma unor cerine generale. Cerinele specifice care decurg din analiza cerinei generale vor fi prezentate n subcapitole individuale. 4.2.1.1 Cerine funcionale Izvoarele cerinelor funcionale pot fi grupate dup mai multe criterii: cerine utilizator cerine propuse de potenialul utilizator, cerine conceptuale cerine care pornesc din conceptele Web X.0 i cerine sistem reguli/constrngeri legate de modul de execuie a aplicaiei , Cerine utilizator : trebuie s afieze informaiile pe care utilizatorul le ofer trebuie s ofere un suport de fiiere minimal ar trebui s permit verificarea/editarea coninutului de pe alte pagini/servicii Web 2.0 trebuie s conin o copie de baz n formatul folosit pentru generator trebuie s permit o clasificare a publicitii informaiilor Cerine conceptuale: trebuie s permit adugare de coninut de ctre utilizatorii externi - pagina n participaie Web 2.0 caracter opional la nivelul fiecrei pagini trebuie s respecte conceptul Semantic Web grafic superioar formatului Web 1.0 Web 2.0 trebuie s rein informaii primite de la aplicaiile exterioare, apoi s genereze anumite informaii suplimentare data-driven Web 2.0/3.0 o obiectiv memorare/manipulare informaii o obiectiv platforme Web 2.0 perpetual beta: site-ul este n continu modificare prin adaugare/editare de pagini de ctre utilizator Cerine sistem: 30

Capitolul 4 permite logare prin surse exterioare; doar deintorul site-ului are posibilitatea de logare editarea coninutului este limitat; coninutul adaugat de ctre proprietarul site-ului se poate modifica doar de ctre proprietar, restul de orice persoan cerine generale legate de paginare n cadrul site-ului:

4.2.1.2 Cerine ne-funcionale: n categoria acestor cerine se vor prezenta cerinele ne-funcionale mpreun cu exemplificarea rolului fiecrui concept. Cerinele vor fi prezentate dup caracterul global sau particular n relaie cu proiectul. Cerine ne-funcionale globale: robustee intrrile se rezum la coninutul adaugat de ctre utilizatorii externi mpreun cu coninutul adugat de ctre proprietar. Erorile sunt verificate la nivelul utilizatorului extern prin filtrarea coninutului; erorile de intrare a proprietarului sunt limitate de ctre operaia de generare accesibilitate aplicaia este accesibil unui numr mare de utilizatori datorit postrii sale pe Internet disponibilitate aplicaia este disponibil att timp ct hostul este disponibil; relativ 99,8%, standard de hosting backup site-ul va conine o copie a sa n formatul trimis ctre generator, accesibil doar proprietarului extensibilitate aplicaia este n continu modificare datorit adugrii de coninut de ctre utilizatori mentenabilitatea uurin n ndeplinirea unor noi sarcini, determinarea unor defecte; se realizeaz datorit partajrii informaiei n pagini Web compatibilitate cu un numr mare de platforme orice browser care implementeaz standardele cerute de cerinele funcionale portabilitate aplicaia se poate folosi de pe orice mediu care suport un browser de internet posibilitatea de executare n cazul unor resurse limitate aplicaia folosete un numr limitat de resurse Cerine ne-funcionale particulare: Certificare acreditarea este realizat de ctre standardul W3C Independena odat generat, site-ul nu va mai folosi celelate componente n buna sa funcionare Mentenabilitatea site-ul este uor de modificat de ctre proprietar fie prin o nou generare, fie prin editare a fiierelor particulare Inter-operabilitate aplicaia nu este legat de celelalte componente dar este interoperabil cu aplicaiile Web 2.0 folosite Scalabilitate parial adevrat n cadrul site-ului, adevrat n cadrul coninutului aduga de ctre exterior, fals legat de coninutul adugat de proprietar; se prezum un nivel redus de cunotiine n programare pagini web a proprietarului, este recomandabil o nou generare n cazul de adugare pagini

31

Capitolul 4 4.2.1.3 Cerine specifice domeniului problemei: Acest tip de cerine sunt legate de caracterul on-line al aplicaiei. Spre deosebire de cerinele prezentate anterior, acestea au la baz factorul uman de eroare sau intenie de modificare a coninutului ntr-un mod abuziv aplicaia ar trebui s prezinte o posibilitate de eliminare a activitii de tip spam site-ul ar trebui s ofere o posibilitate de tergere a coninutului de ctre utilizatorii externi alte cerine care pot face aplicaia s fie folosit n scopuri abuzive

4.2.2 Generatorul Web

Scopul aceste aplicaii este transformarea intrarilor oferite de utilizator n site-ul Web. Intrrile vor fi verificate, pe baza standardului cerut n documentaie, apoi transpuse n tipurile de fiiere cerute. Ieirea va fi format dinr-un set de pagini Web 3.0 mpreun cu resursele cerute. Aceast component este ncadrat n tipul de aplicaie Generatoare de Site-uri descris n capitolul anterior. Apartenena n aceast categorie prezint o serie de cerine suplimentare. Acestea sunt prezentate mpreun cu cerinele generale n urmtoarele subcapitole. 4.2.2.1 Cerine funcionale Asemntor cu capitolul anterior, cerinele funcionale vor fi clasificate dup izvorul lor: cerine utilizator, cerine conceptuale, cerine sistem. Cerine utilizator: transform dintr-un format prestabilit n fiierele corespondete ale site-ului trebuie s ofere opiuni de dezvoltare aplicaia prezint un set de operaii de afiare i unul de generare trebuie s poat s fie folosit din mai multe medii Cerine conceptuale: arhitectura orientat pe servicii Web 2.0 component refolosit de ctre diversele aplicaii exterioare Web 2.0 arhitectur n participaie posibilitate de participare la dezvoltarea aplicaiei prin notificarea de ctre utilizatorii exteriori de eventuale soluii la diverse erori aprute Web 2.0 Cerine sistem: sistemul permite oricui apelarea funciei de generare sistemul permite opiuni de feedback prin un set de funcii specifice doar administatorul are drepturi de vizualizare feedback trebuie s existe o posibilitate de notificare a schimbrilor ctre utilizatorul care o cere 4.2.2.2 Cerine ne-funcionale Cerine ne-funcionale generale: robustee standardul de intrare asigur lipsa posibilitii unei erori exterioare; erorile interioare sunt tratate nainte de publicare a serviciului accesibilitate asemntor cu cumponenta anterioar, generatorul este postat online, fiind accesibil prin intermediul Internetului disponibilitate aplicaia s fie disponibil oricnd utilizatorul dorete s o foloseasc 32

Capitolul 4 backup aplicaia generez site-ul i creeaz o copie de siguran n interiorul acestuia extensibilitate orice modificare efectuat asupra modului de genererare/produsului generat este transparent fat de utilizator mentenabilitatea independena fa de orice alte componente ceeaz posibilitatea unei corectri permanente compatibilitate cu un numr mare de platforme portabilitate componenta trebuie s foloseasc un protocol care s permit un spectru larg de aplicaii care o pot apela posibilitatea de executare n cazul unor resurse limitate Cerine ne-funcionale particulare: Independena fiecare component este independent de cealalalt Documentare aceast component ofer o documentaie asupra intrrilor i ieirilor; standardul de intrare Inter-operabilitate aplicaia trebuie s fie interoperabil cu orice component care o apleaz Scalabilitate aplicaia este gndit pentru un numr mare de utilizatori

4.2.3 Editorul de Site-uri

Aceast component preia informaiile oferite de ctre utilizator i le transpune n formatul cerut de ctre generator. Asemntor unei aplicaii de tipul editor, ea trebuie s permit adugarea/editarea de componente suportate de ctre generator. La sfritul operaiei de creeare a utilizatorului, aplicaia va oferi fiierul de tipul standard al componentei generatoare. A doua funcionalitate a Editorului const n afiarea rezultatului oferit de ctre generator. Aceast set de funcii este unul cu caracter opional; rezultatul Generatorului este oferit utilizatorului. El nu este obligat s verifice coninutul fiierelor prin intermediul Editorului, dei un astfel de comportament este recomandat. O ipotez suplimentar legat de caracterul aplicaiei Editor este format n urma analizei obiectivelor proiectului, efectuat n capitolul anterior, Editorul poate fi calificat asemenea unei aplicaii de tipul CAD, un mediu front end n dezvoltarea site-ului. Cele dou funcionaliti alturi de caracterizarea oferit, prezint o serie de cerine specifice acestei componente. Ele sunt descrise folosind modelul de clasificare folosit asupra componentei anterioare. 4.2.3.1 Cerine funcionale Acest categorie de cerine se nasc din mai multe surse: cele dou funcionaliti prezentate, caracterizarea oferit n capitolul anterior, cerine nscute din aplicarea conceptelor prezentate n capitolul anterior mpreun cerinele care se nasc din consecinele tuturor cerinelor puse la un loc. Cerine utilizator: trebuie s conin operaii de editare trebuie s ofere operaii de generare format trebuie s permit adugarea de coninut HTML/cod embeded trebuie s verifice corectitudinea informaiilor adugate trebuie s ofere un set de instruciuni care afieaz produsul generat Cerine conceptuale: 33

Capitolul 4 trebuie s permit introducerea de componente Web 2.0 trebuie s asigure respectarea formatului Semantic Web 3.0 trebuie s respecte conceptul SVG Web 3.0 trebuie s permit adugarea de componente data-driven Cerine sistem: trebuie s ofere opiuni de publicitate a site-urilor trebuie s constrng intrrile la cele acceptate de ctre editor trebuie s permit adugare de componente particularizate trebuie s verifice posibilitatea de conexiune cu Generatorul ar trebui s ofere un mod de vizualizare a coninutului generat de utilizator 4.2.3.2 Cerine ne-funcionale Cadrul cerinelor nefuncionale este analizat pe baza cerinelor specifice ntregului proiect cerine generale, mpreun cu cele specifice componentei Editor cerine particulare. Cerine ne-funcionale generale: robustee componenta joac rolul unui parser al intrrilor oferite de utilizator, eliminnd posibile erori la generare; aplicaia trebuie s fie pregtit de orice greeal de input a utlizatorului accesibilitate aplicaia este accesibil celor care doresc s o foloseasc prin intermediul Internetului; ea nu este obligatorie pentru generare, ci o recomandare disponibilitate editorul este disponibil att on-line ct i offline, generarea standardului Generatorului este realizat i fr ajutorul internetului backup aplicaia poate fi salvat oricnd prin generarea de standard; n caz de eroare se poate readuce n ultima stare salvat extensibilitate fiind separat de Generator, ea poate fi modificat odat cu acesta sau separat prin diverse opiuni de editare suplimentare mentenabilitatea defectele se pot detecta n cadrul aplicaiei la nivelul fiecrei operaii oferite pe baza standardului generat compatibilitate cu un numr mare de platforme portabilitate posibilitatea de a fi folosit pe orice mediu ce suport un browser posibilitatea de executare n cazul unor resurse limitate aplicaia prezint un nivel minim de operaii de creeare/editare Cerine ne-funcionale particulare: Independena scopul componente este generarea de standard specific Generatorului aplicaia funcioneaz fr necesitatea unei alte componente; datorit calitii generatorului de perpetual beta, pstrarea aceluiai standard n cadrul editorului nu va creea probleme n procesul generator. Mentenabilitatea site-ul este uor de modificat de ctre proprietar fie prin o nou generare, fie prin editare a fiierelor particulare Inter-operabilitate aplicaia nu este legat de celelalte componente dar este interoperabil cu aplicaiile Web 2.0 folosite Conformitate aplicaia trebuie s fie conform stadiului existent sau unui stadiu anterior de standard a componentei Generator Extensibilitate componentele se pot modifica fr ca utilizatorul s cunoasc, principiu legat de perpetual beta Web 2.0 34

Capitolul 4 4.2.3.3 Cerine specifice domeniului problemei Acest tip de cerine sunt legate de domeniul editoarelor web. n general, ele sunt legate de intrrile utilizatorului, n special cele de codificare: aplicaia trebuie s ofere un set de funcii care permite adugarea de coninut exterior; acesta ar trebui verificat nainte de trimitere ctre Generator editorul ar trebui s ofere o verificare suplimentar a fiierelor externe introduse n cadrul aplicaiei, este recomandat salvarea fiierelor externe n cadrul aplicaiei, n loc de ncrcarea lor prin link Cerinele prezentate la nivelul fiecrei componente se nasc din asumarea obiectivelor prezentate n cadrul Capitolului 2 a prezentei lucrri. Scopul acestor cerine este de a califica funciile sistemului fr a repeta ceea ce s-a menionat anterior.

4.3 Arhitectura Sistemului

Partajarea proiectului n componente, caracterizeaz arhitectura n una de tipul Component-Based Software Engineering. Aceast arhitectur se bazeaz pe componente vag legate ntre ele care ndeplinesc seturi de funcii, urmnd ca produsul final s apeleze aceste componente n executarea unor sarcini specifice. Motivul seleciei acestei arhitecturi este parial motivat n analiza componentelor efectuat n subcapitolul anterior. Aceste argumente prezint avantajele arhitecturii ComponentBased la nivel local, fr a prezenta avantajele la nivel global.

4.3.1 Arhitectura bazat pe componente

Arhitectura bazat pe componente, este o ramur a igineriei software care separ operaiile n forma unor componente distincte, formate din seturi de preocupri funcionale independente. Din aceast definiie, se poate observa rolul central ocupat de componenta software. Ea este o entitate independenta, format dintr-un set de operaii, care realizeaz o serie de funcionaliti de interes comun. Stabilirea interesului comun al funcionalitiilor se realizeaz n analiza aplicaiei. n urma parcurgerii cerinelor, se stabilesc grupuri de funcionaliti care fie sunt dependente una de alta, fie realizeaz o operaie complex. Motivul acestei grupri reprezint interesul comun al funcionalitiilor i st la baza separrii n componente. Aceast arhitectura, ca oricare alt arhitectur, prezint o serie de avantaje/dezavantaje. Acestea vor fi prezentate la nivel general, specifice oricrui proiect, mpreun cu o serie de avantaje particulare, specifice prezentului proiect. Avantajele generale ale arhitecturii: managementul complexitii separarea funcionalitiilor n grupuri cu interes comun; aceste grupuri se bazeaz pe legtura dintre funcionaliti separarea sarcinilor n componente individuale uurin n dezvoltare datorit preocuprii cu un anumit set de funcionaliti care prezint un interes comun uurina n detectarea erorilor la nivelul aplicaiei uurin n modificarea/extinderea componentelor 35

Capitolul 4 componente refolosiblie componentele pot fi folosite i de alte aplicaii componentele pot fi reutilizate prin folosirea unei sau mai multor funcionaliti creearea/modificarea aplicaiilor prin utilizarea componentelor cere mai puin timp pentru dezvoltare datorit funcionalitiilor cuprinse n interiorul componentei i a interesului lor comun, noua funcionalitate este catalogat n apartenena unei componente; n dezvoltarea noii funcionaliti, aceasta poate apela funcii care prezint un interes comun din intermediul componentei efectul imediat este creterea productivitii timpul de dezvoltare este redus spre deosebire de dezvultarea iterativ, Avantajele specifice proiectului: aplicarea unor concepte cerute n cadrul obeictivelor/cerinelor proiectului exemplu: lightweight programming format folosind arhitectura bazat pe componente este recomnadarea oferit pentru arhitectura aplicaiilor Web 2.0 separarea n componente poate fi exins la separare n aplicaii Dezavantaje generale ale arhitecturii: sensibilitatea la schimbri componentele trebuie gndite n aa fel nct s fie pregtite pentru schimbri control redus asupra strii sistemului dei nu este valabil n cazul proiectului, n cazul n care sistemul, n ansamblul su, pstreaz diferite stri, este foarte greu de creeat o logic de pstrare/ncrcare a strii

4.3.2 Descrierea Arhitecturii Proiectului

Partea general a descrierii arhitecturii proiectului a fost deja efectuat prin prezentarea tipului de arhitectur folosit i prin analiza componentelor, astfel repetarea acestora ar fi redundant. Fiecare funcionalitate a componentelor a fost descris, dar se poate observa lipsa unei descrieri a modului de interacionare ntre componente. Urmtoarea etap n descrierea arhitecturii proiectului este prezentarea modului de relaionare a componentelor pe baza funcionalitiilor sale. Scenariul general al proiectului privit abstract: Intrare utilizator Editor Trimite format standard Publicat pentru testare Site Web 3.0 Serviciu Web

Genereaz Site

Figura 4.1 Scenariul general al proiectului -abstract 36

Capitolul 4 Pe lang scenariul general propus, fiecare aplicaie prezint un scenariu particular format din intrri/ieiri specifice fiecrei funcionaliti. Ele trebuie prezentate i calificate n implementarea arhitecturii. Figura 4.2 prezint funcionalitiile aplicaiiei privite la nivel global.

Editor
creeare pagina/pagini desenare pagina/pagini desenare componente: o text o imagini o exterioare definire elemente semantice generare XML afiare pagini generate salvare arhiva zip pe maina local

Intrare Utilizator - mouse - tastatura - fiier XML

Trimite XML ctre Serviciu

Serviciu web
afiez informaii serviciu genereaz site web: o HTML text imagine CSS Semantic Web o PHP Pagini speciale facebook twitter

Intrare Utilizator - getInfo() - genereaza()

Genereaz

Site Web 3.0

-

Intrare Utilizator - mouse - tastatura

pagini HTML o text/imagini o Semantic Web pagini PHP o facebook/twitter o pagini speciale imagini standard XML

Trimis ctre Editor Figura 4.2 Arhitectura Proiectului - aspect general 37

Capitolul 5

Capitolul 5.

Proiectare de detaliu si implementare

Fiecare implementare prezentat conine soluia unei funcionaliti, motivarea soluiei mpreun cu descrierea tehnologiei folosite. Suplimentar, se precizeaz, dac este cazul, modul n care implementarea afecteaz arhitectura proiectului. Prezentarea implementrii ncepe cu nivelul global, adic maparea arhitecturii cu tehnologiile invocate, urmat de prezentarea implementrii fiecrei componente.

5.1 Arhitectura proiectului implementat

Scopul acestui subcapitol este de a prezenta modul de funcionare a aplicaiei, oferind o introducere n implementarea proiectului i a componentelor sale. Prezentarea n detaliu a fiecrei componente, mpreun cu motivarea implementrii propuse, se va face separat. ntre modelul arhitectural propus i schema general a aplicaiei implementate nu exist diferene. Fiecare component respect conceptele propuse n capitolul anterior. Schema general a aplicaiei nu face altceva dect s prezinte, n mod practic, ceea ce a fost descris teoretic. Intrare utilizator Editor JSP/Flash Publicat pentru testare ZIP Serviciu WebService Java Genereaz Site Format: HTML/php

Trimite XML

Site Web HTML/php Figura 5.1 Schema general a aplicaiei; procesul tipic de generare Intrarea de la utilizator const n editarea unor elemente HTML n cadrul aplicaiei editor. Utilizatorul adaug coninut elementelor stabilite de editor, urmnd ca aplicaia s verifice coninutul generat. La sfritul procesului creator, editorul proceseaz intrrile utilizatorului i formeaz fiierul de tipul XML specific intrrii Serviciului de generare. Componenta Editor apeleaz, prin aritectura de tipul Web Service, Generatorul. Acesta primete fiierul i transform intrarea n Site-ul Web 3.0. Produsul final este arhivat i ntors ctre utilizator spre vizualizare. Utilizatorul are de ales ntre vizualizarea coninutului generat n interiorul Editorului sau preluarea coninutului spre testare particular. Schema prezentat n figura 5.1 prezint modulul general de funcionare.

5.2 Editor Site

Funcionalitiile oferite de ctre aceast aplicaie acoper totalitatea cerinelor de lucru direct cu utilizatorul. Componenta Editor permite creearea/modificarea modelului de site, apoi afieaz rezultatul final. Operaia de generare de cod este transparent pentru utilizator, doar Editorul cunoate existena generatorului. Aceast abordare este motivat datorit targetului de utilizatori ai aplicaiei. Ei nu doresc s cunoasc aceste detalii, scopul aplicaiei este doar generarea de cod, 38

Capitolul 5 astfel operaiile efectuate nu conteaz. Totui, pentru a respecta conceptul Web X.0, informaiile legate de procesul de generare sunt oferite la cerere. Astfel, componenta Editor i pstreaz calitatea de aplicaie de tipul Front End, operaiile Back End sunt predate spre componenta Generator. O alt observaie leagt de Editor, identific trei tipuri de funcionaliti: operaii folosite n modelarea Site-ului; operaii de vizualizare; operaii de comunicare Generator/Editor Aceast observaie se dovedete a fi util n implementarea aplicaei. Fiecre set de operaii se dezvolt individual, economisind timp de dezvoltare. Editorul urmeaz s fie partajat n dou aplicaii interdependente, n funcie de setul de operaii realizat. Aplicaia Flash se ocup de ntaia parte a procesului creator, modelarea Site-ului. Ea ofer un set de operaii de adugare/editare coninut Web, asemntor unui mediu CAD. A doua aplicaie, JSP, se ocup de ultima parte a procesului creator verificarea produsului generat. Tot a doua aplicaie va conine logica de comunicare datorit legturii intime cu procesul de verificare.

5.2.1 Aplicaia Flash

Scopul i cerinele acestei componente au fost descrise anterior (subcapitolele 4.2.3 i 2.3) i nu necesit detalii suplimentare. Din aceste descrieri rezult dou moduri generale de folosin a Componenta Aplicaie Flash: modelarea Site-ului care urmeaz generat generarea standardului de intrare a Generatorului. Modelarea site-ului presupune o serie de funcionaliti creeate cu scopul de adaugare/editare/stergere elemente. Site-ul va fi scris n limbajul HTML, astfel elementele generale supuse editrii vor fi standarde ale acestui limbaj. Pe lang aceste elemente, exist o serie de componente care sunt specifice unei aplicaii web, n special aplicaiile Web 2.0. Aplicaia Flash trebuie s descrie operaii pentru adugare/editare/stergere de elemente pentru aceste componente. Analiza componentelor care vor fi supuse adugrii va fi realizat n subcapitolul dedicat implementrii Site-ului Web. Aplicaiile Web 2.0 care vor fi adugate n componena site-ului vor fi site-urile: facebook.com i twitter.com Formarea standardului de intrare a Generatorului se va realiza folosind schema interioar a paginilor create. Aceasta va fi transpus n formatul XML, cerut de ctre Generator, apoi oferit utilizatorului. Spre rezolvarea implementrii componentei se va folosi paternul Model View Controler descris pe platforma Adobe Flash CS5. 5.2.1.1 Platforma Aplicaiei Cunoscut i sub denumirea de Macromedia Flash, Adobe Flash este o platform multimedia, oferit de ctre Adobe Systems, folosit n creearea unor pagini bogate vizual, prin utilizarea animailor, formatelor video i a interactivitii. Flash creeaz animaii folosind grafic vectorial mpreun cu elemente de tipul RASTER. El suport streaming bidirecional al formatelor video i audio; poate citi intrri primite de la mouse, tastatura, microfon sau camer web. Flash conine un limbaj orientat obiect, denumit ActionScript, care ofer un mod de manipulare animaiilor/elementelor adugate. 39

Capitolul 5 Structura mediului de dezvoltare conine trei entiti principale. Prima entitate se numete scen i permite creearea unor elemente vizuale. Aici se pot adauga/defini elemente text, video, imagini prin operaii de tipul drag and drop sau desenare. Aceast parte nu necesit cunoaterea vreunui limbaj de programare, Flash joac rolul unei aplicaii de editare de imagini. A doua component se numete Timeline i permite animarea scenei create n entitatea anterioar. Bazat pe frame-uri, Flash se aseamn unui editor video care red un numr de imagini pe secunda (fps). Ultima component se intituleaz aciuni. n aceast entitate se definesc elementele desenate n scene, mpreun cu comportamentul acestora, folosind limbajul de programare ActionScript. Cele trei entiti sunt legate ntre ele, existnd posibilitatea creeri unor operaii complexe, prin manipularea evenimentelor/componentelor n diferite frame-uri/scene. Selecia platformei Flash pentru dezvoltarea aplicaiei Editor se motiveaz pe avantajele oferite n dezvoltrea unei aplicaii de tipul CAD, mpreun cu cteva avantaje generale ale platformei. Aceste motive vor fi prezentate mpreun cu conceptul/cerina care o respect: dezvoltarea unei aplicaii bogate web conceptul Web 2.0 o procesarea elementelor vizuale (butoane, imagini, text, etc) o definirea unor funcii bazate pe interactivitate o ncrcare/salvare fiiere aplicaii SVG Web 3.0; aplicaia Flash Player, folosit n redarea coninutului Flash, este gratuit i se gsete oricnd, pentru instalare, pe site-ul oficial accesibilitate; formatul flash poate fi accesat att prin intermediul unui browser, cat i stand alone disponibilitate; compatibilitate cu un numr mare de platforme; portabilitate, aplicaiile flash ruleaz pe mai multe medii concept Web 2.0; posibilitatea de executare n cazul unor resurse limitate Flash Lite Player ofer posibilitatea creearii unor operaii complexe n funcie de evenimente diferite; permite adugare de diferite standarde specifice formatului HTML; exemplu: imagini, video, sunet, etc; ofer posibilitatea dezvoltrii unui mediu mai usor de folosit useability; 5.2.1.2 ablon de proiectare Problema implementrii componentei Flash este realizat folosind design-pattern-ul Model-View-Controler. Aceast descriere permite separarea operaiilor specifice elementelor vizuale de operaiile de procesare. Patternul MVC conine trei componente: Model descrie operaiile efectuate prin interactionarea cu elementul visual, reine starea aplicaiei; View descrie elementele vizuale, poziia lor, contextul, etc; Controlor interpreteaz intrrile oferite n componenta View i notific Modelul ce operaii s execute; Controlorul trimite intrrile ctre Model spre procesare. Acest design patern prezint o serie de avantaje: claritate n design: separarea operaiilor dup scopul lor; eficien prin modularizare: permite modificarea/adaugarea/stergerea componentelor cu uurint; multitudine de componente vizuale; uurina de manipulare a componentelor vizuale; 40

Capitolul 5 uurina n adugarea de funcionaliti noi; O abordare simplist a modului de funcionare a Patternului MVC este oferit n figura 5.2. Modelul este nucleul aplicaiei. Cand exist schimbri n Model, se notific View. Controlerul reprezint modalitatea de interaciune cu Modelul a utilizatorului. View afieaz informaiile oferite de Model. User vede utilizeaz

View

Controler

update Model

manipuleaz

Figura 5.2 Prezentarea paternului MVC Acest pattern a fost ales datorit avantajelor care le prezint la dezvoltarea implementrii ct i datorit tipicitii aplicaiei (de tipul CAD). 5.2.1.3 Elemente generale ale implementrii nainte de prezentarea implementrii componentelor paternului, se va prezenta modul de organizare a codului n interiorul aplicaiei. Scena este mprit pe nivele denumite layer. Acestea sunt poziionate asemntor paginilor ntr-o carte, una deasupra celeilalte. Nivelele pot fi grupate n directoare (folders). Codul fiecrei componente este separat n mai multe nivele, dar toate sunt adugate n cadrul aceluiai folder. Astfel Folderul View conine mai multe layere, specifice fiecrui caz de vizualizare, modelul va conine mai multe layere specifice anumitor operaii, etc. Denumirea acestor layere va cuprinde tipul de component a paternului urmat de o denumire generic a operaiilor/intei. Exemplu: ModelImage layer care aparine de model i inta operaiilor sunt cele de prelucrare imagine. Aplicaia ruleaz ntr-un singur cadru (frame), astfel fiecare layer va conine pe respectivul frame o seciune de cod ActionScript. Un alt element general al implementrii reprezint modul de reprezentare a coninutului Site-ului generat n interiorul Modelului. Se vor folosi clasele ActionScript descrise n tabelul 5.1. Toate pre-condiiile i post-condiiile sunt menionate n prezentul capitol, impreuna cu operaia pe care o valideaz, dar sunt prezentate n capitolul dedicat testrii/validrii. Implem Nume clas Extinde Atribute Metode eteaz
-id* : int -titlu* : String -scop : String -componente : Array +w : int +h : int +constructor +setter/getter +addComponenta +deleteCompone nta

Pagina

MovieClip

41

Capitolul 5 Nume clas

ComponentaExteriora

Extinde
Pagina

Implem eteaz
-

Atribute
-x : int -y : int -relatiePagina : String -nume* : String -h : int -w : int -continut:TextField -relevanta : String -text : String -font : String -marime : String -align : String -hyperlinks : Array -relevanta : String -alt : String -lnk : String -src : String -loader : Loader -imageData : ByteArray -continut : TextField -continut : TextField -linkTo : String -continut : TextField -continut : TextField -continut : TextField -beginInt :int -endInt : int -link : String -descriere : String

Metode
+constructor +constructor +setter/getter +clone +consturctor +setter/getter +addHyperLink +removeHyperLi nk +clone

ComponentaPagina

Clonable

ComponentaText

Componenta Pagina

Clonable

ComponentaImage

Componenta Pagina

Clonable

+constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +consturctor +setter/getter

ComponentaExternaFB

Componenta Pagina

Clonable Clonable Clonable Clonable Clonable

ComponentaExternaOth Componenta er Pagina ComponentaFBHistoryI nput ComponentaFBInput ComponentaFBPicture Componenta Pagina Componenta Pagina Componenta Pagina -

HyperLinkPage

Tabelul 5.1: Clasele utilizate n dezvoltarea aplicaiei Dup cum se observ din citirea tabelului, fiecare clas deine un constructor, settere/gettere (mutatori) i operaia de clonare. Constructorul fiecrei clase primete parametrii atributele definite de clas. Metoda de clonare nu are pre-condiie; post-condiia este fcut prin verificarea egalitii ntre obiecte. ActionScript3.0 nu cunoate interfaa de clonare, astfel aceasta trebuie definit, apoi fiecare clas trebuie s prezinte o implementare a acestuia. 42

Capitolul 5 Mutatori sunt folosii n setarea/ntoarcerea valorii unei variabile private. Pre-condiiile i post-condiiile sunt tipice unor mutatori. Clasa principal a aplicaiei este cea de tipul Pagina. Ea corespunde unei pagini generate. Atributele acestei clase se rezum la un numr de identificare id; denumirea paginii titlu; relevana fa de coninutul site-ului, semantic Web scop; elementele html/facebook/twitter componente; nalime h; lungime w; atribute primite de la superclasa: x,y : pozitia fa de colul stnga al aplicaiei Operaiile de adaugare/deleteComponenta adaug sau terg o component din atributul de tipul Array, primesc un singur paramentru de tipul ComponentaPagina. Pre-condiia adaugrii este validitatea elementului adugat: prin existena acestuia (diferit de null), s nu existe n componente i s fie de tipul corespunztor. Post-condiia adugrii se rezum la o verificare dac elementul a fost adaugat corect. Pre-condiia tergerii: existena elementului n list, s nu fie null, post-condiia tergerii const n verificarea array-ului dup tergere. Aceeai condiii se aplic i n cadrul operaiilor de add/removeHyperLink ale clasei ComponentaText. Clasa ComponentaExterioara definete o componenta de tipul facebook sau twitter. Ea este tratat n mod asemntor unei pagini datorit condiiilor speciale de editre ale acestei componente. Ele se comporta ca pagini la nivel vizual, dar rezultatul lor este refolosit sub forma de ComponentPagina. Motivarea acestui fapt este fcut dup prezentarea elementelor vizuale. Clasa ComponentaPagina reprezint elementul HTML/facebook/twitter. Atributele acestei clase sunt generale oricrui tip de componente. Metodele sunt creeate n mod asemntor cu cele prezentate mai sus. Clasele ComponentaText, ComponentaImage, CoponentaExternaFB, ComponentaExternaOther extind clasa ComponentaPagina i reprezint particularizarea clasei ComponentaPagina. Fiecare din aceste sub-clase conin parametrii specifici elementului care l reprezint, iar toate sunt vazute de ctre Pagina ca fiind ComponentePagina - polimorfism. Ultimul set de clase reprezint clasele care pot fi adugate doar n contextul unei ComponenteExterioara. Clasele ComponentaFBHistoryInput, ComponentaFBInput, ComponentaFBPicture, definesc elemente ale unei componente FB. Ele vor fi adaogate dac utilizatorul dorete acest lucru.

43

Capitolul 5
Pagina Componenta Exterioara

ComponentaPagina

Componenta Image

Componenta Text

Componenta ExternaFB

ComponentaExterna Other

HyperLinkPage

ComponentaFB Input

ComponentaFB HistoryInput

ComponentaFB Input

Figura 5.3 Diagrama de clase Clasa HyperLinkPage conine informaii referitoare la un hyperlink in interiorul unei componente text. El pstreaz informaii legate de poziia de nceput i sfrit a linkului impreun cu pagina ctre care se face linkul. n cazul n care se face link ctre o pagin n interiorul siteului, linkul va conine un prefix : SITE: mpreun cu denumirea paginii. O informaie suplimentar oferit de tabelul 5.1 este unicitatea anumitor parametrii n diferite colecii n care poate s apar. Fiecare atribut care trebuie s fie unic i este ataat simbolul *. 5.2.1.4 View Componenta View reprezint elementul vizual al aplicaiei. Aici sunt definite totalitatea elementelor care urmeaz a fi afiate. Aceste elemente primesc, dac este cazul, o referin spre operaiile, din Controler, apelate n cazul anumitor evenimente. Un eveniment const ntr-o aciune efectuat asupra unui element vizual, de ctre utilizator. Aciunile se rezum la operaii provenite fie de la tastatur fie de la mouse. Exemplu 5.1: componentaView.addEventListener(event,funcieControler) n exemplul 5.1, se arat modul de atribuire a unei funcii Controler: funcieControler la elementul view: componentaView, n cazul evenimentului event. Acest exemplu este scris n limbajul ActionScript3.0. 5.2.1.4.1 Elementele Vizuale Tipurile de elementele vizuale ale Aplicaiei Flash: a. forme geometrice b. desen fundal 44

Capitolul 5 c. text label/input d. butoane e. liste f. comboBox g. Loader Toate elementele prezentate sunt adugate n scena aplicaiei. Flash descrie scena sub forma unei implementri a clasei MovieClip, denumit stage. n interiorul acestuia se pot aduga variante ale clasei DisplayObject. Toate elementele enumerate mai sus extind clasa DiplayObject, dar nu direct. Flash conine o ierarhie de clase specializate pentru fiecare form vizual care se poate defini n spaiul tridimensional. Adugarea unui element se realizeaz folosind operaia addChild(DisplayObject). n cazul n care se dorete adugarea unui elemend la o anumit adncime, se utilizeaz operaia addChildAt(DisplayObject, depth). Eliminarea unui element de pe scen se realizeaz folosind operaia removeChild(DisplayObject). Exist o alt metod de ascundere a elementelor aflate pe scen. Fiecare obiect de tipul DisplayObject conine atributul visible. n cazul n care nu se dorete eliminarea obiectului de pe scen, dar se dorete ascunderea lui, se seteaz parametrul visible de tipul false. n cazul n care visible estre true, se afieaz elementul. Descrierea elementelor viuzale folosite de Aplicaia Flash: a. Formele geometrice conin majoritatea figurilor geometrice elementare. Ele sunt definite n pachetul flash.display, oferind o serie de operaii de desenare i adaugare n scen. Ele sunt folosite la desenarea de coninut dinamic prin intermediul ActionScript3.0. n cadrul implementrii, ele sunt folosite n operaiile de generare de coninut. Forma geometric desenat joac rolul unei umbre temporare a viitoarei componente. Exemplu: n clipa n care se cere adugarea uni element text, sistemul ateapt poziionarea i desenarea respectivului element. Pn n momentul finalizrii desenului, se va afia o form dreptunghiular, apoi se va afia elementul Text. Metodele apelate pentru generarea formelor geometrice n limbajul ActionScript sunt n formatul drawX(), unde x este denumirea formei n limba englez. Parametrii difer de la figur la figur. Obiectele generate sunt adugate ntr-un container de tipul Shape. Acest container permite poziionarea, redimensionarea ct i definirea unui comportament n cazul evenimentelor. b. Elementul Desen Fundal reprezint fundalul static al aplicaiei. Acesta nu se modific pe parcursul rulrii aplicaiei. Fie c el face parte din scena principal, fie din butoane, acest component are un scop pur vizual i nu funcional. c. Text label reprezint un element text care nu poate fi modificat. Acestea sunt adugate n scen pentru a oferi informaie ctre utilizator. Elementele label, n limbajul ActionScript 3.0, sunt de tipul TextField. Operaiile asupra acestor elemente sunt cele generale ale unui TextField. Text input reprezint un element text a crui coninut se poate modifica. Scopul acestor elemente este de a prelua informaii de utilizator in format text. n limbajul ActionScript 3.0, aceste elemente sunt de tipul TextField. Operaiile principale, oferite de ctre limbajul ActionScript3.0, asupra unui TextField sunt: 45

Capitolul 5 poziionare TextField, prin setarea atributelor publice: +x, +y, +width, +height; valori ntregi modificare text prin setarea atributului public +text; setare de format text: se folosete o clas TextFormat care primete atribute legate de mrime, font, align, etc. Operaia de atribuire TextFormat implic mai multe etape Pe lang cazurile expuse mai sus, elementul Text input/label se mai folosete i n cazul definirii unui element al site-ului. Aceste operaii sunt acoperite n domeniul Modelului. d. Butoanele reprezint o particularizare a clasei MovieClip. Clasa SimpleButton definete trei frame-uri, fiecare avnd un scop specific n raport cu evenimentele realizate cu mouse-ul. Frame-ul Up reprezint comportamentul aplicaiei n cazul n care nu exist contact cu mouse-ul. Over reprezint frame-ul care este activat n momentul n care mouse-ul este deasupra butonului. Down reprezint frame-ul activat n momentul n care se face click. Din punct de vedere al evenimentelor pe care le poate interpreta un buton, cele mai importatne sunt MouseDown eveniment definit de momentul de apsare a butonului stanga a mouse-ului, MouseMove eveniment definit de micarea mouse-ului in scena deasupra butonului, MuseUp eveniment definit de momentul n care se las butonul stanga al mouse-ului, MouseClick eveniment definit de momentul n care s-a efectuat o operaie de click. Fiecare buton deine o serie de parametrii de poziionare : +x:int, +y:int ct i parametrii care ofer lungimea/limea butonului, +width/+height. Implementarea comportamentului de buton este realizat n Controler n mai multe operaii. e. Listele sunt elemente predefinite care afieaz o serie de opiuni, urmnd ca utilizatorul s selecteze una. Lista este o extensie a clasei DislayObject, astfel nct poate fi adugat n scen, conine atribute folosite n poziionare i permite adugarea de comportament n cazul evenimentelor. Citirea elementului unei liste se realizeaz folosind operaia getSelectedLabel(). Aceasta ntoarce indexul elementului selectat, urmnd ca denumirea elementului selectat din list s fie returnat de operaia getLabelAt(index). f. ComboBox sunt asemntoare listelor, singura diferen const n modul de afiare a coninutului. n cadrul elementelor ComboBox, se afieaz doar elementul selectat. Dac se dorete modificarea elementului, se va face click pe sgeata din partea stng. Elementul ComboBox va afia opiunile posibile, apoi utilizatorul alege opiunea dorit. Implementarea acestui element se face n mod asemntor cu elementul List. g. Loader element grafic care poate conine orice imagine sub form de bitmap. Este folosit n diverse cazuri care cer afiarea de figuri geometrice sau imagini. Elementul loader prezint o serie de metode de adugare de coninut, exemplu adugare de imagine: loadByteArray(), load() , etc. 5.2.1.4.2 Tipuri de componente Aplicaia Flash conine dou tipuri de componente View. Clasificarea este realizat dup criteriul importanei elementelor n dezvoltarea site-urilor. Cele dou tipuri sunt: componente care sunt pstrate vizibile fie permanent, fie o perioad ndelungat; denumite generic : elemente vizuale permanente 46

Capitolul 5 componente care sunt folosite doar n cazul unui anumit eveniment; elemente vizuale temporare

I. Elementele vizuale permanente sunt desenate la nceputul dezvoltrii aplicaiei. Ele sunt vizibile pe parcursul dezvoltrii aplicaiei, astfel, legtura dintre componenta view i model, n cazul acestor elemente, este una minim. Acestea nu sunt generate n limbajul ActionScript. Singura caracteristic descris n limbajul ActionScript a acestor elemente const n operaia de atribuire a unui comportament n cazul unui eveniment. Elementele vizuale permanente ale Componenta Editor prezint dou stri: adugare componenta text/imaginie i adugare componenta FB. Figura 5.4 prezint elementele vizuale permanente specifice strii de adugare elemente imagine/text. Comportamentul acestor elemente este descris n Tabelul 5.2 Figura 5.5 descrie elementele vizuale n cazul adugrii unei componente FB, iar Tabelul 5.3 este o continuare a Tabelului 5.2.

Meniu Hyperlink

Adaugare Componenta Meniu XML Pagini Meniu TextField

Meniu Componenta Facebook

Figura 5.4 Componenta Editor n cazul de utilizare adugare text Lista elementelor vizuale permanente i comportamentul lor:
Denumire Element Elemente Text Image Pagina Generate Load Text Options Font FontComboBox Size Tip Label Buton Buton Buton Buton Buton Label Label ComboBox Label Comportament Adaug un TextField in site Adaug o imagine in Site Creeaz o pagin nou Genereaz XML unde dorete utilizatorul ncarc XML exterior Permite alegerea unui tip de font -

47

Capitolul 5
SizeText Align AlignLeft AlignRight AlignCenter AlignJustified Color Bold Italic Underline Hyperlink Tab Pagina 1..6 - X Site Map Index* Descriere Legatura Descriere Legatura Hyperlink Hyperlink Create Create Custom FB Component Create Other Component Add Fb Component Input Label Buton Buton Buton Buton ColorPicker Buton Buton Buton Buton Label Buton Buton Buton Label Input Label Input Buton Buton Buton Buton Valoarea introdus reprezint mrimea fontului textului Seteaz align la text Seteaz align la text Seteaz align la text Seteaz align la text Seteaz culoarea Selecia din text devine boldata Selecia din text devine inclinat Selecia din text devine subliniat Seteaz selecia ca fiind hyperlink Afieaz paginile nr x*7-(x+1)*7 Afieaz meniu Site Map Afieaz pagina Index pe scen Descrie legtura ntr-un mod semantic Conine site-ul ctre care se face link Adauga un hyperlink n zona selectat ctre Hyperlink Input Creeaz o nou component FB Creeaz o nou component Other Adaug o component fb definit

Tabel 5.2 Comportamentul elementelor vizuale permanente

Elemente Componenta FB

Scena Componenta FB

Figura 5.5 Componenta Editor n cazul de utilizare adugare text

Denumire Element Tip Comportament

FBPicture Buton Adugare componenta imagine utilizator FB FB Input Text Buton Adugare componenta input utilizator FB FB History Input Buton Adugare componenta istoric utilizatori FB Tabel 5.3 Comportamentul elementelor vizuale permanente 48

Capitolul 5 Implementarea componentelor vizuale premanente se rezum la desenarea fiecrei componente n parte, apoi atribuirea unui comportament fiecrui element vizual . II. Elementele vizuale temporare sunt creeate folosind metode de generare a componentelor vizuale. Ele au un caracter temporar, dar nu sunt eliminate din scen. Acest abordare este motivat de caracterul repetitiv al operaiilor asociate cu elementele temporare. Iniializarea elementelor vizuale temporare este realizat n componenta View. Ele sunt generate de ctre Model folosind metodele GenerezaX, unde X este tipul de component care urmeaz s fie generat. Logica de generare este cuprins n Model. Modelul general de creeare a unei componente: Var componenta: TipComponenta = GenerateTipComponenta(parametrii). Lisa de elemente vizuale temporare este pstrat n Anex. 5.2.1.5 Controlorul (Controller) Controlorul verific informaiile trimise de ctre utilizator, iar dac acestea sunt corecte, apeleaz modelul spre modificarea strii de view i efectuarea operaiilor. n cazul unei intrri formate greit, controlerul trimite spre afiarea erorii ntampinate. Fiecare operaie de verificare conine o descriere a tuturor verificrilor care se cer nainte de apelarea Modelului mpreun cu funciile apelate, sursa din View care apeleaz la acest comportament mpreun cu, dac este cazul, particulariti ale implementrii. OpC1: Afiarea erorilor. Pe parcursul prezentrii tuturor operaiilor se vor descrie cazurile n care se trimite ctre model o execuie i cazurile n care se trimite ctre Model afiarea unei erori. La notificarea modelului, el va dispune afiarea dialogului specific erorii, mpreun cu un buton OK pentru ntoarcere la pagina anterioar. Dialogul specific errori va afia Erroare: TextEroare, unde TextEroare este un Label care notific utilizatorul ceea ce a completat greit. Acest text este generat de ctre Model n funcie de tipul erorii notificate de ctre controler prin apelarea metodei doErrorNo. Aceasta funcie specific i comportamentul butonului OK. Aceast comportament mpreun cu detalii suplimentare legate de operaiile Modelului sunt parcurse n operaia OpM17. OpC2:Verificarea operaiei de adugare pagin. La efectuarea unui click pe butonul Pagin, controlorul trimite ctre model operaia de curare scena: clearStage(); apoi se iniializeaz procedura de creeare a unei noi pagini showNewPageDialog(). Se va deschide un dialog care va cere introducerea unor informaii legate de noua pagin care urmeaz creat. La efectuarea unui click pe butonul OK se va verifica dac informaiile sunt introduse corect, apoi se vor trimite ctre model parametrii folosii n creearea unei noi pagini, mpreun cu operaia de setFocusOnNewPage(), care afieaz elementele ultimei pagini create. Observaie: mai exist o metod care afieaz o pagin specific, ea se numete setFocusOnPage(pagina), care afieaz o pagin specific. n cazul n care exist intrri care nu sunt completate corect se va apela modelul prin doErrorNo(1,MesajEroare), unde 1 reprezint codul erorii i Mesaj Eroare reprezint ytextul care urmeaz s fie afiat. Dac se efectueaz click pe butonul Cancel, se va trimite ctre model operaia de redesenare a scenei: redrawStage(). Implementarea acestei componente se realizeaz prin verificarea urmtoarelor cerine: Campul Denumire s fie completat cu o valoare unica; nu pot exista dou pagini cu aceeai denumire 49

Capitolul 5 Campul Relevan s fie completat cu o valoare diferit de irul gol OpC3: Verificarea operaiei de desenare. Aceast operaie apare n cadrul oricrei adugri de elemente n pagin. Dup nceperea operaiei, se ateapt efectuarea unui click de ctre utilizator n interiorul scenei. n cazul n care se efectueaz click n afara scenei nu se ntpl nimic. Mrimea scenei variaz n funcie de pagina pe care se deseneaz. n cazul n care se vorbete despre o component exterioar, exemplu Facebook, Twitter, etc, mrimea scenei este definit de ctre poziia x,y, lungime, lime a paginii. Cordonatele paginii sunt preluate din model: getCurentPageZ(), unde Z este coordonata cerut. n cazul n care se vorbete despre o pagin normal, parametrii paginii sunt prestabilii. Dac click-ul este realizat n scen i butonul stnga a mouse-ului este apsat, se trimite ctre model deseneazaComponentaTemporara(). Cnd butonul stnga a mouse-ului este lsat, se va desena componenta cerut de ctre utilizator. Componenta temporar principal este un dreptunghi de culoare 0x999999. n cazul adugrii unei imagini, componenta temporara desenat este imaginea care urmeaz a fi introdus. n cazul n care coordonatele mouse-ului ies din scen, se procedeaz la setarea parametriilor n limita scenei. Implementarea acestei verificri se realizeaz folosind o serie de instruciuni IF care verific dac a fost depit scena. Exemplu:
if (x<minScena) x = minScena; if (x>maxScena) x = maxScena:

Limitele elementelor adugate n scen: Pagina normala: o X [220,920]; o Y [80,605]; Component exterioar: o X [getCurentPageX() , getCurentPageX()+getCurentPageW()]; o Y [getCurentPageY() , getCurentPageY()+ getCurentPageH()]; OpC4: Verificarea operaiei de adugare component text. Componenta text este adugat n dou etape. Prima etap ncepe n momentul efecturii operaiei de click pe butonul Text. Acum se ateapt operaia de desenare a componentei text. Controlorul asigur desenarea textului pe scen prin operaia OpC3. Dup desenarea elementului text, se trimite ctre model afiarea dialogului pentru noua component. Acum se ateapt introducerea unor informaii legate de noua component creeat. La efectuarea unui click pe butonul OK, controlorul va verifica dac informaiile sunt introduse corect, dac nu va afia o eroare, codul erorii este 3. n cazul n care informaiile sunt afiate corect se va trimite ctre model operaia de adugareComponentaText mpreun cu parametrii citii de la utilizator. Verificrile realizate de controler: Controlerul verific poziia mouse-ului, dac n momentul nceperii desenrii componentei, Unicitatea campului denumire Valoarea campului relevan s fie diferit de valoarea nul.

50

Capitolul 5 OpC5: Verificarea operaiei de adugare component imagine. Spre deosebire de componenta anterioar, la efectaurea operaiei de click pe butonul Image, se va cere destinaia imaginii, mpreun cu cteva informaii legate de imagine. Dup efectuarea unui click pe butonul OK se va verifica dac informaiile introduse sunt corecte, apoi se va trimite ctre model instruciunea de nceput de operaie de desenare. n cazul n care o informaie este introdus greit se va afia eroarea numrul 4. La sfritul operaiei de desenare, se va aduga componenta cerut prin notificarea modelului prin metoda adaugaComponentaImagine. Urmtorul pas este redesenarea scenei redrawStage(). OpC6: Verificarea operaiei de creeare component facebook. Elementele facebook i twitter sunt Componente Exterioare. Ele urmeaz s fie adugate n interiorul unei pagini, n structura definit de ctre utilizator. Dar nainte de adugare, ele trebuie s fie definite. Operaia de definire ncepe prin desenarea mrimii componentei. Dup desenare, scena este limitat la zona desenat anterior. Se va afia un dialog care va cere introducerea unei denumiri. Dac denumirea este unic, controlorul va dispune, ctre Model, de creearea unei pagini component facebook denumit FB_X, unde X este denumirea introdus. Controlorul va notifica Modelul de existena unei scene a unei pagini Component Exterioar. Aceeai implementare este folosit i n cazul operaiei de creeare component twitter(OpC7), dar este rescris specific acestei componente. OpC8: Verificarea operaiei de adugare component facebook. Componenta facebook poate fi desenat doar n interiorul unei pagini, astfel dup efecturea unui click pe butonul Add FB Component, se va verifica dac se afl pe o pagin normal. Aceast operaie este realizat de metoda verifyOnPage(). n cazul n care ntoarce true, se va proceda la afiarea dialogului de adugare, altfel nu se va executa nimic. Controlorul poate primi de la model, n orice moment, instana paginii care este afiat pe scen folosind operaia getCurrentPage() a Modelului. Controlorul verific dac acest obiect este de tipul Component Exterioar, n caz afirmativ raspunsul este false, altfel True. Aceast abordare pare ciudat, dar ComponentaExterioar extinde Pagin, astfel, verificarea dac obiectul este de tipul Pagin este inutil, Flash poate recunoate ComponentExterioar ca fiind de tipul Pagin. O alt verificare efectuat de ctre Controlor este unicitatea unui tip de component pe pagin. O pagin poate conine o singur component facebook. Dialogul afiat va prezenta, ntr-o list, toate componentele disponibile. Utilizatorul alege componenta, apoi, dup efectuarea unui click pe butonul OK, va desena zona care s conin componenta. Aceast o a doua desenare se dovedete a fi util datorit posibilitii de reutilizare a componentei n diferite contexte. Dup operaia de desenare, se trimite ctre model addComponentaFacebook, mpreun cu parametrii generai pn acum. n cazul verificrii operaiei de adugare component twitter, se procedeaz la o implementare asemntoare, doar clasele instaniate difer. (OpC9). OpC9: Verificarea adugrii componentelor FBInput, FBHistory, FBPicture, TWInput, TWHistory, TWPicture. Toate verificrile efectuate asupra acestor componente sunt realizate n acelai mod cu adugarea unei componente text, singurul lucru care difer ntre componente sunt clasele instaniate i coninutul TextField-ului care le reprezint. OpC10: Verificarea operaiei de adugare component other. n momentul efecturii unui click pe Add Componenta Other se va apela metoda showAddOtherDialog(). Aceast metod va afia dialogul de creeare a unei alte componente, dect cele descrise pn acum. n cadrul acestui dialog, se va introduce codul care urmeaz s fie adugat direct n pagin. 51

Capitolul 5 Dup efectuarea unui click pe butonul OK, se va desena locul ocupat de ctre component n pagin. La sfritul desenului se va trimite ctre model addComponentOther mpreun cu parametrii cerui de aceast metod. n cazul acestui dialog, se poate impune o verificare a coninutului nscris. OpC11: Verificarea operaiei de stergere pagina. n momentul n care se dorete o tergere de pagin, se efectueaz operaia de click dreapta n aplicaie. Se va afia meniul Flash mpreun cu dou opiuni: Modific/Sterge Pagin sau Modific/Sterge Component. n cazul seleciei Modific/Sterge Pagin, se va trimite ctre model showModificaStergePagina(). Se va afisa un dialog care va conine dou liste: Prima list conine operaia aleas, a doua list va conine paginile asupra croroa se executa operaia. Dup alegerea operaiei/ paginii, se verific i celelalte intrri i n cazul unei erori se afieaz eroarea cu codul 2, dac nu se vor efectua intruciunile descrise prin notificarea modelului a alegerii fcute. OpC12: Verificarea operaiei de stergere componenta. Se realizeaz n mod asemntor cu OpC11, difer doar condiiile descrise de input-ul disponibil acestui tip de operaie. Codul de eroare este 6. OpC13: Verificarea operaiei specifice butonului Site Map. La efectuarea unui click pe butonul Site-map, se vor afia dou componente. Prima component prezint link-urile descrise n o pagin aleas de ctre utilizator. De aici ele pot fi terse, la nevoie. Pagina aleas va fi prezentat ntr-o list n partea stng a componentei, linkurile disponibile n partea dreapt. Toate aceste informaii sunt afiate prin apelarea funciei showSiteMap() a Modelului. A doua component a dialogului ofer posibilitatea setrii unei publicitii a paginilor creeate. Dac o pagin este public, ea poate fi afiat oricnd. Dac o pagin este privat, ea este disponibil doar administratorului, iar dac este setat ca fiind logat, coninutul poate fi vizionat doar de ctre utilizatorilor logai pe o reea de socializare. Dac aceast opiune este activat, toate paginile sunt de tipul php. Operaia de setare a publicitii este realizat n model folosind operaia setAccesPage(). Aceast metod primete ca parametrii numele paginii i opiunea aleas. OpC14: Verificarea operaiei de setare a textului. n cadrul acestei operaii sunt introduse toate funciile care verific orice opiuni legate de particularizarea elementelor text. Aceste verificri sunt realizate prin citirea poziiei de nceput i sfrit a selecie textului, apoi notificarea Modelului a schimbrilor realizate. Ele sunt descrise n Tabelul 5.4. Denumire Buton B I U AlignCenter AlignLeft AlignRight AlignCenter ColorPicker Atribut al textului Bold Italic Underline Align:center Align:left Align:right Align:center Color Metoda apelat Model setBold(start, end) setItalic(start, end) setUnderline(start, end) setAlign(center) setAlign(left) setAlign(right) setAlign(center) setColor(color,begin,end) Informaii suplimentare Align influeeaz tot textul Align influeeaz tot textul Align influeeaz tot textul Align influeeaz tot textul 52

Capitolul 5 Create Hyperlink setHyperlink(linkTo,begin,end) Tabelul 5.4 Elementele componentei Text Seteaz un hyperlink

n cazul elementelor hyperlink, dup ce sunt adugate, controlorul asigur existena hyperlinkului, pn n clipa n care tot textul linkul-ui este ters. Aceasta se realizeaz prin o metod a controlorului care se activeaz de fiecare dat cnd o tast este apsat. Dac se adaug caractere n hyperlink, acesta va crete n lungime, dac se terg acesta va fi sczut pn nu va mai conine nici un caracter. n cazul unei introduceri greite a informaiilor legate de hyperlink, se efectueaz eroarea 5. OpC15: Verificarea operaiei de drag. Dac se efectueaz o operaie de CTRL+CLICK pe orice element al oricrei pagini, se ncepe operaia de drag a componentei. Controlerul notific Modelul de existena unui startDrag(). Componenta este modificat, la nivelul obiectului care l reprezint, abia dup finalul operaiei de desenare, folosind metoda updatePositionElement(). Pe parcursul repoziionrii, se vor respecta condiiile impuse n cadrul operaiei OpC2. OpC16: Verificarea operaiei de resize. Aceast operaie este valabil asupra oricrei element n oricare tip de pagin. Ea este realizat n momentul execuiei unei operaii de tipul SHIFT+CLICK n colul dreapta jos a unei componente. Implementarea acestor operaii se realizeaz ntr-un mod asemntor cu OpC15, diferena const n existena unei limite de redimensionare. Metoda apelat de ctre controler la sfritul operaiei de desenare : updateResizeElement(); OpC17: Operaiile de Generare XML/LoadXML. Operaia oferit de ctre controlor este una minimal, se trimite ctre Model poziia de unde se ncarc/salveaz fiierul XML. Fiecare element al paginii va conine un set de EventListener, specific tipului su. Controlerul reprezint totalitatea de funcii care sunt apelate n cazul, unui Event, el transmite mai departe ctre Model ce trebuie schimbat n scen, sau ce operaii trebuie realizate, dup cum ablonul Model-View-Controler cere. Nu exist pre condiii legate de editare, fiecare intrare este verificat de platforma Flash, nu se pot trimite obiecte null ctre Controlor. Post-condiiile controler-ului se refer la totalitatea de schimbri realizate de controler. 5.2.1.6 Modelul Aplicaia implementeaz o serie de funcionaliti prevzute n capitolul de analiz. Acestea sunt puse n practic prin intermediul unor operaii. Operaiile implementate de ctre aplicaia Flash sunt: Adaugare/eliminare componente text Adaugare/eliminare componente imagine Adaugare/eliminare componente exterioare Adaugare/eliminare pagini 5.2.1.6.1 Operaii legate de pagini Site-ul conine un numr maxim de 42 de pagini. Aceast constrngere este aleatoare, mrirea numrului maxim de pagini se poate realiza oricnd prin modificarea unei singure variabile. Variabila se numete nMaxPagini:int, variabil global. Mrirea numrului maxim de pagini atrage o problem la nivelul elementelor vizuale. Butoanele tab nu sunt suficiente pentru 53

Capitolul 5 acoperirea afirii tuturor paginilor, se poate creea o list care nlocuiete butoanele tab, si cuprinde toate paginile aplicaiei. OpM1: Opeaia de adugare pagina. Fiecare pagin adugat va primi o denumire, mpreun cu o relevan fa de ntregul site. Dup definire, atributele paginii pot fi modificate printr-o funcie special. Implementarea acestei operaii primete o abordare simpl. Controlerul a verificat consistena valorilor trimise, acum urmeaz operaia de creeare a unei noi pagini folosind clasa Pagina. Obiectul nou creat este adugat n Array-ul dedicat tuturor paginilor, intitulat pagini. Dup adugare, pagina nou creat va primi focus, adic va fi n prim plan, prin setarea variabilei paginaSelectata = paginaNoua. Variabila paginaSelectat pstreaz obiectul de tipul Pagina specific paginii afiate pe ecran. Benificile acestei abordri sunt motivate n momentul adugrii elementelor n pagin. n loc s se execute o cutare la fiecare adugare, se pstreaz obiectul i este prelucrat direct. OpM2: Clonarea Paginilor. O opiune important n creeare paginilor este posibilitatea de clonare a unei pagini deja existente. Cand se creeaz o nou pagin, exist o opiune care permite clonarea unei pagini din rndul de pagini existente. Rezultatul va fi o pagin care va conine clone ale elementelor din pagina surs. Fiecare obiect de tipul Pagin ofer o metod de clonare. n clipa generrii unei noi pagini, pagina nou va fi refereniat ctre clona obiectului Pagina, apoi se vor modifica parametrii obiectului clon conform informaiilor oferite de utilizator. Urmtoarele etape sunt aceai cu operaia de adugare pagin. OpM3: Adaugare/stergere pagini. Paginile pot fi adugate/terse la cerere, cu excepia paginii index. Stergerea unei pagini nu afecteaz logica aplicaiei. Singurul impediment care poate aprea n o operaie de tergere este de consisten linkurilor paginilor exterioare ctre pagina care urmeaz a fi tears. Utilizatorul trebuie s verifice coninutul fiecrei pagini n parte, dac exist vreo legtur. Aceast verificare poate fi realizat n mod automat, tergerea find de asemenea automat. Implementarea operaiei de tergere pagin este realizat prin eliminarea paginii din Array-ul pagini. Dup verificarea existenei paginii de ctre controler, ea va fi trimis spre eliminare n model. 5.2.1.6.2 Operaii legate de componente Fiecare pagin va conine componente text, imagine i componente exterioare. Acestea sunt adugate n pagin prin poziionarea lor de ctre utilizator. Ele pot fi editate, repoziionate sau redimensionate. Controlorul verific dac aceste operaii sunt realizate corect, dar logica de modificare a elementelor paginii este descris n model. OpM4: Operaia de poziionare/ adugare element text este realizat n mai multe etape: dup selectarea operaiei se alege poziia din colul stnga sus al elementului text n timp ce mouse-ul este apsat se deseneaz un dreptunghi care simbolizeaz aspectul viitoarei componente n pagin la lsarea click-ului se va deschide un meniu care va cere introducerea unor informaii legate de noua component la selectarea butonului OK se trimite spre generare noua component

54

Capitolul 5 Generarea noii componente este fcut n model folosind metoda generateText. Dup generearea obiectului de tipul ComponentaText, el este adugat n componentele paginii selectate folosind instrunciunea: paginaSelectata.addComponenta(newComponentaText). Operaiile de verificare a poziionrii corespunztoare a componentei text este realizat de ctre Controler: OpC2 Operaia de desen a dreptunghiului este realizat la cererea Controlerului. OpM5: Modelul conine doar operaia de generare/modificare a dreptunghiului. Aceast operaie se realizeaz folosind o variabil global drawDreptunghi. Aceasta este redesenat de ctre model, de fiecare dat cnd Controlerul o cere. Modelul cunoate doar de existena dreptunghiului i desenarea acestuia, nu ce face utilizatorul. Implementarea acestei operaii este realizat n mai multe etape. Iniial se elimin dreptunghiul din scen folosind operaia removeChild(drawDreptunghi). Acesta este regenerat folosind parametrii trimis de ctre Controler, apoi adugat n scen folosind addChild(). OpM6: Operaia de poziionare/ adugare element imagine este realizat n mai multe etape: spre deosebire de operaia anterioar, informaiile legate de imaginea selectat sunt cerute nainte de adugare dup specificarea informaiilor, imaginea este ncrcat in model, urmnd s se repete operaia de desenare a imaginii intr-un mod asemntor componentei text; n loc de dreptunghi se va afia imaginea dup desenare imaginea rmne pe scen. Adugarea componentei de tipul ComponentaImage se realizez la sfritul operaiei de desen. Implementarea adugrii ComponentaImagine n paginaSelectat este la fel. OpM7: Operaia de ncrcare a unei imagini este realizat n mai multe etape. Aceste etape vor conine i informaii legate de codul de adugare: Imaginea este ncrcat folosind operaia de load() a unei instane a clasei FileReference. Aceast operaie cere utilizatorului s aleag un fiier, apoi ncarc informaia n formatul de tipul ByteArray. Dup ncrcare, informaia este introdus ntr-o instan a obiectului Loader. n procesul de desenare a elementului de imagine, se va afia imaginea desenat, redimensionat n funcie de preferinele utilizatorului. Dup finalizarea procesului de desenare se creeaz o nou instan a clasei ComponentaImage,se adaug componenta Loader n obiectul de tipul ComponentaImage, se seteaz parametrii imaginii, apoi este adugat n arrayul de componente a paginii Parametrii componentei Loader sunt ncrcaii folosind un addEventListener n cazul evenimentului de iniializare. Aceast abordare este considerat standard n implementriile care conin loader. OpM8: Editarea textului, operaia de setare font, marime, align, bold, italic, underline i culoare. Fiecare component text poate fi modificat de ctre utilizator. Modelul primete de la Controlor prin operaia OpC14 ce dorete s fie modificat n scen. Metodele oferite de ctre Model sunt introduse n Tabelul 5.4. Aici sunt descrise care metode se apeleaz i parametrii trimii. Implementarea acestor operaii este realizat folosind setTextFormat(myFormat), unde myFormat este un obiect de tipul TextFormat, care conine toate tipurile de atribute specifice unui TextField. Aceast metod poate fi folosit la nivelul ntregului text, sau doar n zone specificate de utilizator. 55

Capitolul 5 Pre-condiii: nu exist, selecia este trimis de ctre Flash. Dac nu a fost efectuat o selecie, opiunea se aplic pe tot textul. Post-Condiii: Textul s fie modificat. OpM9: Adugare de link-uri. Operaia de adugare de linkuri conine dou etape. Prima etap creeaz un obiect de tipul Hyperlink i l insereaz n irul de obiecte Hyperlink a ComponenteiText. A doua etap deseneaz textul s se asemene unui hyperlink specific HTML. Post-condiii: creearea unui obiect valid Hyperlink, post-condiiile de la OpM9. OpM10: Operaia de tipul drag a componentelor. Controlorul trimite ctre Model operaia de update n cadrul OpC15, folosind metoda updatePositionElement(). Aceast metod va schimba coordonatele x,y a obiectului de tipul ComponentaX, unde X este tipul de element. Implementarea acestei operaii se bazeaz pe parametrii trimii de ctre Controlor. Metoda updatePositionElementTemp() primete trei parametrii: x,y:int repezint poziia elementului n sistemul cartezian Oxy, i elementul care urmeaz s fie modificat. Aceast metod schimba valoarea xy a elementului vizual. Modelul schimb valoarea xy a obiectului ComponentaX la sfritul operaiei de desenare, cnd este apelat metoda updatePositionElement(). Pre-condiii:nu exist, controlorul este verificat de post-condiii. Post-Condii: Elementul s aib noua valoare xy diferit de vechea valoare, noua valoare s corespund elementului vizual, iar celelate s rmn la fel. OpM11: Operaia de tipul resize a componentelor. Aceast operaie se aseamn cu cea de tipul drag, elementele schimbate sunt w i h, adic lungime(w) i nlime(h). Metoda se denumete updateResizeElement()/upateResizeElementTemp(), iar operaia din Controlor care apelez metoda este OpC16. Valorile noi sunt transmise de ctre Controlor. Pre/post-condiiile sunt cele de la OpM10. OpM12: Adugarea de component exterioar facebook.com. Controlorul trimite ctre model metoda addComponentaFB(). Aceast metod adaug n pagina afiat, paginaSelectata, noua component. Adugarea este fcut prin instanarea unui obiect de tipul ComponentaExternaFB, i adugarea acesteia la pagin folosind instruciunea addComponent. Legtura dintre ComponentaExternaFB i pagina de tipul Componenta Exterioara este fcut prin valoarea unui atribut comun nume. Obs: nu se poate aduga mai mult de un tip de componentFB n pagin. Post-condiii: componenta exterioar s fie inserat n pagin. OpM13: Adugarea de component twitter.com. Implementarea este realizat n acelai fel ca n cazul OpM12. Aceeai post-condiie ca OpM12. OpM14: Adugarea de component other. Cotrolorul trimite ctre Model, prin operaia OpC10, textul care urmeaz s fie adugat n pagin. Modelul creeaz un nou obiect de tipul ComponentaExterioaraOther i atributul coninut primete valoarea trimis de Controlor. n urmtorul pas, Modelul adaug componenta n paginaSelectat apoi deseneaz componenta pe scen. Componenta desenat va fi de tipul TextField, iar marimea acesteia este definit de ctre Controler. Post-condiii: obiectul de tipul ComponentaExterioaraOther s nu fie null; obiectul s fie desenat pe scen. OpM15: Stergerea unei componente. Implementarea operaiei de tergere se realizeaz prin eliminarea obiectului component din obiectul de tipul Pagin, folosind metoda removeComponent. Eleminarea obiectului din scena aplicaiei se realizeaz prin apelarea funciei redrawStage, care redeseneaz paginaSelectat.

56

Capitolul 5 5.2.1.6.3 Operaii speciale OpM16: Generare SiteMap. Aceast operaie prezint o serie de etape. Prima etap este de update. Acum se ncarc listele paginilor i a linkurilor. La cererea Controlorului, se face operaia de update list link folosind metoda updateListLink(pagina). Acest lucru se realizeaz prin parcurgerea tuturor componentelor paginii, iar n cazul componentelor text, se va afia linkul i pagina ctre care face referire. A doua etap reprezint setarea publicitii site-ului. Aceast operaie este acoperit de OpM16. Nu avem post-condiii. OpM17: Publicitatea site-ului. Operaia de publicitate este realizat prin afiarea/modificarea accesului la o pagin. Controlorul apeleaz Modelul prin operaia OpC13. Implementarea acestei operaii se realizeaz prin setarea atributului access a obiectului de tipul Pagina a crui nume este trimis de ctre Controlor. Se parcurge tabloul pagini, iar n cazul n care atributul nume a unui obiect Pagina este egal cu cel oferit de Controlor, atributul acces a acestui obiect primete valoarea trimis de ctre Controlor. Pre-condiii:nu exist, parametrii sunt verificai de post-condiia Controlorului. Postcondiii: s fie modificat valoarea. OpM18: Logica de afiare a erorilor generate de Controler. Afiarea dialogului de eroare este realizat prin funcia showErrorNo. Aceast funcie afieaz textul erorii primite de la Controler i atribuie butonului OK un comportament. Numrul fiecrei erori a fost specificat n cadrul Controlorului. Selecia dialog-ului care urmeaz a fi afiat se realizeaz prin operaia case asupra variabilei care conine eroarea. Post-condiii: Verificarea operaiei de tergere prin parcurgearea tabloului pagini. OpM19: Operaia de generare XML. Aceast operaie transform obiectele de tipul Pagina n formatul XML. Implementarea este realizat prin parcurgerea tuturor paginilor din tabloul uni-dimensional. n cadrul fiecrei pagini se vor aduga componentele n variabila de tipul String XML . Coninutul imaginilor jpg este adugat ntr-o alt variabil. La sfritul parcurgerii se transforma XML n formatul byte i este adugat n variabila result. n urmtorul pas se adaug coninutul imaginilor n result. Rezultatul este scris ntr-un fiier n locaia trimis de ctre Controlor. OpM20:Operaia de ncrcare XML este asemntoare cu cea de ncrcare XML a aplicaiei Generator. Se parcurge tot fiierul, se transform tablul citit n String. Descrierea transformrii din String n obiecte de tipul Pagin este fcut n acelai mod ca operaia OpG3. Toate operaiile dein o post-condiie comun: afiarea dialogului/scenei n mod corespunztor.

5.2.2 Standardul XML

Formatul general al fiierului XML este de tipul Extensible Markup Language. Fiecare element este descris folosind simbolulrile: < / >, unde <componenta> reprezint nceputul descrierii elementului componenta , iar </componenta> descrie sfritul elementului component. Aplicaia Flash conine o serie de obiecte care urmeaz a fi codificate n formatul XML. Atributele acestor obiecte urmeaz s fie declarate ca sub-elemente a obiectului. Un exemplu n acest sens ar fi: 57

Capitolul 5
<obiectX> <atribut>valoare1 </atribut> <atribut2>valoare2</atribut2> </obiectX> Oiectul ObiectX are dou atribute, iar fiecare atribut are are valoarea descris n interior.

Respectnd modelul de clase definit anterior n Figura 5.3, se va defini un tag principal denumit XML, iar n interiorul acestuia se vor defini obiectele de tipul Pagina. Un exemplu tipic al schemei generale a standarduluil XML:
<XML v=1 info="Site Generator Format"> <Pagina1> <atribut1>valoareAtribut1</atribut1> <atribut2>valoareAtribut2</atribut2> <atribut3> <atribut3.1>valoareAtribut3.1</atribut3.1> <atribut3.2>valoareAtribut3.2</atribut3.2> </atribut3> </Pagina1> <Pagina2> < atribut1> < atribut1.1>valoareAtribut1.1</ atribut1.1> < atribut1.2>valoareAtribut1.2</ atribut1.2> </ atribut1> <atribut2>valoareAtribut2</atribut2> </Pagina2> <ComponentaExterioara> <atribut1>valoareAtribut1</atribut1> <atribut2> < atribut2.1>valoareAtribut2.1</ atribut2.1> < atribut2.2>valoareAtribut2.2</ atribut2.2> </ atribut2> </ComponentaExterioara> </XML>

Din acest exemplu se poate vedea modul de organizare a standardului XML prin introducerea ca elemente a tag-ului <XML> a paginilor Pagina1, Pagina2, ComponentaEterioar. Acest fiier mai conine o serie de tag-uri. Aceastea sunt de tipul <jpg> i conin dou elemente. Primul este intitulat <end> i conine lungimea coninutului elementului, urmat de coninutul fiierului jpg n formatul tablou unidimensional de tipul byte. Tag-urile <jpg> sunt adugate la sfritul fiierului, n ordinea invocrii lor n descrierea paginilor web. Fiierul nu trebuie codificat, o codificare ar schimba coninutul fiierului jpg prin reorganizarea informaiei. Orice aplicaie care va citi fiierul trebuie s il citeasc ca un ir de byte, nu ca un ir de caractere. Exemplu: transformarea fiierului n caracrere unicode nu va permite afiarea imaginilor.

58

Capitolul 5

5.2.3 Aplicaia JSP

Operaiile efectuate de ctre aceast aplicaie sunt minimale. Aplicaia JSP se conecteaz la Generator, trimite fiierul i primete rezultatul n formatul ZIP. Al doilea tip de operaie este de afiare a fiierelor generate 5.2.3.1 Platforma Aplicaiei Aplicaia este scris n NetBeans o platform pentru aplicaii desktop Java, medii integrate de developement (IDE), javaScript, php, etc. Aceast aplicaie este scris n limabjul Java i funcioneaz pe orice mediu care permite instalarea JDK i JVM. Aceast platform este folosit att n dezvoltarea aplicaiei JSP, ct i n dezvoltarea Generatorului Web. Motivele seleciei acestei platforme: ofer o implementare pentru dezvoltarea aplicaiilor WebService permite debug la orice nivel al aplicaiei multitudinea de limbaje implementate (proiectul folosete JSP i php) mediu uor de folosit 5.2.3.2 Implementarea operaiilor Aplicaia JSP va conine trei pagini de tipul JSP, specifice operaiilor oferite. I. Prima pagin, create.JSP, va conine Aplicaia Flash mpreun cu cteva informaii afiate n formatul HTML. Un fiier de tipul SWF poate fi adugat ntr-o pagin HTML folosind fie metode statice, scrise ca obiecte HTML, fie dinamice, scrise n javaScript. Aplicaia Flash este adugat static, astfel nct aplicaia s funcioneze i n cazul unui browser care nu implementeaz javaScript. Codul general de afiare:
<object width="800" height="600"> <param name="movie" value=" AplicatieFlash .swf"> <embed src="AplicatieFlash.swf" width="800" height="600" /> </object>

Aceast abordare afieaz coninutul Flash, fr s verifice dac aplicaia Flash Player este instalat. Aceast ipotez este rezolvat prin adugarea unui element de tipul div n care se va aduga urmtorul cod HTML:
<div> <h1>Alternative content</h1> <p><a href="http://www.adobe.com/go/getflashplayer"><img src="http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif" alt="Get Adobe Flash player" /></a></p> </div>

Acesta afieaz butonul pentru instalare a aplicaiei Flash Player. Pe lng acest coninut, se adaug elementele de fundal mpreun cu cteva informaii text. II. A doua pagin este cea de generare, generate.JSP. n cadrul acestei pagini se ncarc fiierul XML trimis i se trimite ctre Generatorul Web. Dup returnarea rezultatului se va rencrca pagina, oferind dou opiuni: a. Vizualizare Rezultat b. Download Fiier ZIP 59

Capitolul 5 Opiunea de vizualizare va trimite ctre ultima pagin a aplicaiei. A doua opiune va downloada fiierul pe maina local. Pagina generate.JSP va conine dou stri. Prima stare reprezint starea iniial n care se va afia dialogul de ncrcare fiier. A doua stare va afia dialogul cu opiunile prezentate mai sus, mpreun cu dialogul afiat n prima stare. Pagina se va pstra n aceast stare pn la ntampinarea unei erori, cnd se va rentoare n starea iniial prin afiarea unui mesaj de eroare, sau cnd se consoder conexiunea cu utilizatorul terminat. Starea afiat este definit de o variabil de tipul boolean n logica de operaii a paginii JSP afiseazaDialogDownload. Dac valoarea este false, se va afia doar dialogul specific strii iniiale. Dac valoare este true, se va afia i dialogul pentru download/vizualizare. n caz de eroare la citire/trimitere, se va afia un mesaj de eroare pe pagina Erori.JSP, apoi se va face redirect ctre generate.JSP n starea iniial. Tot aceast pagin prezint logica de conexiune ctre un serviciu Web. Aplicaia JSP cunoate de existena Generatorului mpreun cu fiierul WSDL al Generatorului. Generate.JSP trebuie s se conecteze la servici, s trimit fiierul XML. Rezultatul oferit de ctre serviciu este trimis napoi ctre Generate.JSP n formatul ZIP. Conexiunea este realizat folosind Clientul Web Service oferit de ctre NetBeans. Acest client implemeneaz codul cerut pentru transmitere/recepie mesaje de tipul SOAP. Singurul pas n realizarea de transmisie/primire este realizat de ctre urmtoarea porinue de cod:
try { servici.GeneratorWS_Service service = new servici.GeneratorWS_Service(); servici.GeneratorWS port = service.getGeneratorWSPort(); byte[] XML = XMLInputStream; result = port.generate (XML); out.println("S-a realizat generarea "); } catch (Exception ex) { out.println("exception" + ex); }

Obiectul Array de tipul Byte result va conine arhiva zip a site-ului. Fiierul XML trebuie codificat n forma de tipul Array de Byte. Motivul folosirii coleciilor array de tipul byte este dat de necesitatea unei lipse de codificare, care s permit re-generarea diferitelor tipuri de fiiere incluse. Array Byte este un tip primitiv care nu codific coninutul n nici o form. III. Ultima pagin afieaz coninutul generat afisare.JSP. Operaia de afiare este realizat n interiorul unui internal frame. Astfel, orice operaie realizat n interiorul frame-ului nu va influena funcionarea Aplicaiei JSP. Prima etap este decodificarea fiierului de tipul ZIP. Java ofer o librarie de arhivare/dezarhivare a fiierului de tipul ZIP denumit java.util.zip. Prin dezarhivare, Aplicaia va genera fiierele cerute n interiorul aplicaiei jsp. Urmtoarea etap afieaz coninutul generat de ctre aplicaie n internal frame-ul paginii afisare.JSP. Se va afia pagina index.html.

60

Capitolul 5

5.3 Site Web 3.0

Rezultatul generatorului este Site-ul Web 3.0. Acesta conine paginile generate de ctre Serviciul Web. Site-ul conine trei tipuri de pagini: pagini generate de ctre utilizator, pagini specifice fiecrui site generat i pagina de social dashboard.

5.3.1 Pagini specifice fiecrui site

Seturile de pagini specifice fiecrui site generat sunt: logare, indexAdmin, adaugar Pagina, eliminare Pagina i schimbare parola. Fiecare conine un set de operaii generalizate, oferite doar administratorului site-ului. Toate aceste pagini sunt scrise folosind limbajul php. OpS1:Pagina logare permite logarea administratorului n partea dedicat a site-ului. Aceste pagini sunt definite n operaia de generare. Accesul n cadrul acestor pagini este realizat folosind contul default admin cu parola admin. Parola acestui cont poate fi schimbat n interiorul paginii indexAdmin prin accesarea paginii schimbarePagina. Implementarea acestei pagini este realizat folosind limbajul php. Elementele afiate sunt creeate folosind limbajul HTML. Logica pentru logare va fi coninut n o nou pagina loginTry care va verifica dac elementele trimise sunt corecte. Dac logarea este reuit se face redirecionare ctre indexAdmin, dac nu se afileaz o eroare n fiierul logareError, apoi se trimite ctre logare.php. Pagina indexAdmin prezint o serie de opiuni: Modificare parol Adugare pagina Modificare/Eliminare pagin Download backup (XML) OpS2:Modificarea parolei este realizat n o nou pagin denumit schmbareParola. Aceast pagin citete vechea parol o singur dat i noua parol de 2 ori. Dup confirmare, se va rescrie fiierul loginTry ca s conin noua parol. Aceast abordare este folosit pentru a evita folosirea unei baze de date. Logica folosit n rescrierea paginii loginTry este format din o citire a fiierului ntr-o variabil; parcurgerea variabilei pn n zona de cod dedicat parolei; apoi, inserarea noii parole. Dup modificarea variabilei, aceasta este salvat ca fiind o nou pagin loginTry. Pagina LoginTry va conine parola care trebuie verificat dar nu va fi oferit la citirea paginii prin vizualizarea codului scris, ea este inserat n poriunea de cod server-side. n cadrul acestei operaii se pot introduce conturile aplicaiilor Web 2.0. OpS3:Operaia de adugare de pagin din site este realizat folosind metoda de clonare a unui site deja existent. Implementarea acestei operaii se realizeaz ntr-un mod asemntor cu operaia de resciere a parolei. Iniial se va citi fiierul care urmez a fi clonat, se va crea un nou fiier de acest tip, apoi va fi scris ca o nou pagin n interiorul site-ului. Urmtorul pas n creearea noi pagini este modificarea coninutului su folosind operaia de modificare pagin. Pre-condiii: Numele paginii sa nu existe n aplicaie; Post-condiii: Pagina sa existe. OpS4:Operaia de modificare pagin este realizat folosind o parcurgere a paginii. Dup formarea obiectului se va folosi un algoritm de transformare n format XML, urmnd a fi modificate elementele dorite. Algoritmul de transformare const n o parcurgere a paginii, verificare dac s-a citit un tag, apoi inserare n xml a tagului.
if (substr(i-5,i) ==/den>) //logic de adugare element in xml

61

Capitolul 5 Dup generare, pagina va conine o serie de elemente HTML input, care conin elementele din pagin. Administratorul va vedea doar o list de elemente ale paginii mpreun cu coninutul lor. Dup finalizarea editrii elementelor, va folosi metoda de update care va modifica coninutul paginii. Coninutul este modificat folosind operaia de rescriere a fiierului. Implementarea funciilor de citire i de scriere se realizeaz folosind file_get_contents/file_write_contents. Pre-Condiii: s nu existe limbaj html n pagin. Post-Condiii: creearea unui fiier HTML. OpS5:Operaia de Eliminare a unei pagini se realizeaz prin tergerea ei folsind umtorul cod: $fisier = locatie.php; unlink($fisier); Metoda unlink () terge fiierul i returneaz true dac fiierul a fost ters cu succes, false dac nu. Robusteea aplicaiei este asigurat prin folosirea instruciunii try-catch asupra operaiei de tergere, dei accesul ctre fiierul care urmeaz a fi ters este garantat. Post-Condiie: operaie realizat cu succes. OpS6:Operaia de download fiier XML ofer posibilitatea de download a copiei n formatul standard a Generatorului. Implementarea operaiei este realizat prin citirea fiierului backup.XML, apoi este scris acolo unde dorete utilizatorul. Metodele folosite n citirea/scrierea fiierului sunt aceleai ca n cazul operaiei de adugare pagin. Post-Condiie: operaie realizat cu succes.

5.3.2 Paginile generate de utilizator

Aceste pagini sunt generate de ctre aplicaia Generator i pot fi modificate la cerere. Ele sunt scrise n Limbajul HTML, pentru elementele HTML, i JavaScript/php, pentru elemente ale aplicaiei exterioare. Elementele HTML sunt de forma: text, imagine. Elementele Exterioare: facebook, twitter, alte componente exterioare. Elementele text sunt adugate n tag-uri specifice denumirii elementului text. n interior se va introduce textul oferit de utilizator, mpreun cu tag-urile <b> - bold <i> - italic <u> underline. Fiecare element text va conine un corespondent CSS care va conine tipul de font, marime i alte opiuni specifice elememtului adugat. Exemplu:
<head> <style type=text/css> denumireText {font-family:Times New Roman; color:#00ff00:} </style> </head> <body> <denumireText>text inserat <b>de <i>catre</i></b> utilizator </denumireText> </body>

Implementarea Semantic web este asigurat folosind o logic RDF. Documentul asociat paginii se va denumi NUME.rdf i va conine logica de argumentare a legturii dintre pagin i componenta text. Un exemplu RDF:
<?xml version="1.0"?>

62

Capitolul 5
<rdf:RDF> <rdf:Description rdf:about=paginaCareConineElementulText> <contine>denumireElementText</contine> <relevanta >relevantaFataDePagina</relevanta> </rdf:Description> </rdf:RDF>

n acest exemplu se stabilesc dou fapte legate de pagina nou creat. Subiectul la amndou este paginaCareConineElementulText. Predicatul primei propoziii este: conine, obiectul este: denumireElementText. Propoziia format n limbaj natural este: paginaCareConineElementulText conine denumireElementText. A doua propoziie format: Relevana elementului fa de paginaCareConineElementulText este relevantaFataDePagina. mpreun formeaz urmtoarea fraz: Pagina paginaCareConineElementulText conine denumireElementText a crui relevan fa de paginaCareConineElementulText este relevantaFataDePagina. Aceai abordare este folosit n cadrul implementrii tuturor elementelor n pagin. Singurul lucru care poate fi diferit ntre tipurile de elemente sunt predicatele asociate legturii de tipul RDF. Elementul imagine este adugat folosind parametrul <img>. Src este sursa imagini, paramterii alt, link sunt introdui de ctre utilizator. Poziionarea n pagin ct i nlimea/lungimea sunt oferite prin folosirea CSS. Exemplu CSS:
.clasa{ Position=absolute; Left = x; Top = y; Width = w; Height = h; }

n cadrul definirii fiecrui element, se va preciza class=clasa, astfel elementul adugat va respecta regula CSS stabilit pentru clas. Aceeai abordare este folosit i n cazul celorlalte elemente ale paginii. Asemntor cu componenta anterioar, denumirea imaginii se va pstra prin adugarea unui tag nainte de inserarea imaginii, astfel imaginea este atribuir n formatul CSS folosind denumirea din TAG. Elementele exterioare sunt adugate dup tip. n cazul Componentei Exterioare Other se va aduga codul direct n pagin. Acest lucru poate s creeze erori n pagin, dar sintaxa codului este verificat de ctre Editor. n cazul n care nu funcioneaz componenta, browserul va afia simbolul broken, administratorul poate rescrie/elimina componenta din pagina de administrare. Adugarea n pagina HTML este realizat n mod asemntor cu celelalte elemente prin tagul special. Tag-ul va fi de forma: <ComponentaOther>. Componenta Facebook este adugat n site folosind codul oferit de ctre Graph API de pe site-ul facebook developers. Pentru a putea folosi Graph API n interiorul unui site, este nevoie de un Facebook App, aplicaie n care utilizatorii i dau consimmntul asupra procesului de primire/prelucrare informaii primite de la facebook. Graph API ofer informaiile cerute de utilizator prin folosirea linkului https://graph.facebook.com mpreun cu o serie de parametrii. Spre exemplu: https://graph.facebook.com/me/friends?access_token=XXX va ntoarce lista de prieteni a unui utilizator cu access_token = XXX. Lista parametriilor i modul lor de funcionare sunt descrise n linkul numrul [55]. 63

Capitolul 5 Folosind un Facebook App, utilizatorul facebook permite acces de citire i adugare de informaii componentei Site, din interiorul unui app. Acest acces este concretizat prin setarea unui privilegiu ctre access_token-ul Facebook App. Site-ul se poate conecta la facebook i poate cere informaii, exemplu: poza, nume, wall, like, etc, sau poate trimite informaii, exemplu :publicare pe wall, publicare pe o pagin, etc. Aceast component cunoate dou stri: login i logedin. Starea de login va afia butonul de logare folosind facebook. Operaia de afiare buton logare mpreun cu operaia de logare sunt standarde oferite de facebook.com. Acestea sunt definite n linkul [56] i se folosesc n acelai mod n cadrul oricrei aplicaii care permite logare prin facebook. Implementarea va conine doar o copie a acestul cod. Odat realizat logarea, pagina va fi renprosptat trecnd n starea logedIn. Acum utilizatorul vede componenta desenat de ctre Administrator. Aici utilizatorul poate s adauge coninut sub forma de comment Facebook n Facebook App, rezultatul fiind vizibil doar pe paginia Site-ului. Implementarea acestei funcionaliti este realizat folosind Graph API, iar paginile afiate vor parcurge rezultatul primit de la graph.facebook.com, urmnd s afieze doar infromaia relevant la pagin. Pagina de social dashboard se comport n acelai fel ca paginile de logare, difer doar operaiile apelate. Componenta twitter.com are un alt comportament fa de Componenta Facebook. Comunicarea cu aplicaia twitter este realizat folosind un serviciu web de tipul REST. Modul de conectare, mpreun operaiile utilizate n implementare sunt prezentate n linkul [57]. Implementarea componentei twitter.com ofer dou stri: logIn i logedIn. Prima prezint un buton care permite logarea folosind contul de twitter. Acest buton este implementat de ctre cei de la twitter, inserarea lui n pagin se face parcurgnd o serie de etape, linkul [58]. A doua stare este desenat de ctre utilizator, iar logica de adugare tweet pe pagin este realizat prin arhitectura de tipul REST.

5.3.3 Pagina Social Dahsboard

Capitolul 3, cel dedicat Studiului Bibliografic, prezint cteva criterii de analiz a reelelor de socializare. Selecia celor dou aplicaii Web 2.0 se bazeaz pe aceast analiz. Facebook.com Data Hub Activities adugare coninut n interiorul paginii personale, oferit spre vizualizare i comentare a celorlali utilizatori Social Network permite adugare de coninut n interiorul altor aplicaii Social Source Referral nu este realizat Social Source & Action aciune de adugare coninut; adugare comentarii asupra coninutului altora; logare n diferite site-uri; jocuri sociale; posibilitate de citire/modificare din exterior Social Entity facebook.com/ developers.facebook.com Social Type socializare prin adugare coninut/ jocuri sociale Twitter.com Data Hub Activities adaugarea coninut pe site-ul personal; raspuns la coninutul adugat de ali utilizatori; Social Network permite adugare de coninut n interiorul altor aplicaii Social Source Referral nu este realizat 64

Capitolul 5

Social Source & Action adugare de coninut scurt tweets , logare n diferite site-uri; posibilitate de citire/modificare din exterior Social Entity twitter.com/ developers.twitter.com Social Type socializare prin citirea coninutului afiat de un target de utilizatori

Analiza scurt descris mai sus prezint o serie de concluzii: 1. aplicaiile permit adugarea de coninut n interiorul altor pagini, fapt urmrit de ctre aplicaie 2. existena unei ramuri de developers care descrie, n detaliu, modul de conectare la aplicaii 3. adugarea este menionat n interiorul aplicaiilor web 2.0, consecin benefic prin prezentare coninutului i n cadrul platformelor 4. ambele permit logarea n diferite site-uri se poate urmrii cine adaug coninut i cand; elimin necesitatea creeari unei logici de logare, ea este implementat de aplicaiile Web 2.0 5. posibilitatea de control a aplicaiilor Web 2.0 din exterior Aceste cinci avantaje reprezint motivul seleciei celor dou aplicaii n implementarea ramurii de Social Dashboard. Ramura social dashboard permite citirea coninutului aplicaiilor Web 2.0, apoi permite adugarea de coninut n interiorul aplicaiei. Citirea este fcut prin afiarea elementelor de wall i a notificaiilor. Scrierea se face prin adugarea coninut pe wall. Implementarea operaiilor de citire din aplicaii Web 2.0/scriere n aplicaii Web 2.0 se realizeaz folosind metodele oferite de platforme Web 2.0. Legturile ctre metode au fost prezentate n subcapitolul 5.3.2. Metodele apelate de ctre Site: login afiare poz afiare adugare comment/tweet adaug comment/tweet

5.4 Generatorul Web

Aceast aplicaie transform formatul trimis de ctre Editor (XML) n formatul de tipul ZIP. Aceast funcionalitate este realizat n mai multe etape. Prima etap transform XML n obiecte specifice componentei Editor. Aceast transformare este necesar pentru stabilirea elementelor fiecrui site. Se pstreaz diagrama de clase prezentat n figura 5.3. A doua etap codific obiectele n limbajul HTML/javaScript/php. Fiecare component este adugat att n poriunea de head ct i de body a fiierului HTML. Transformarea se face la fel pentru fiecare tip de component. Ultima etap este arhivarea. Toate fiierele sunt adugate ntr-o arhiv zip, apoi trimise ctre utilizator spre download/verificare. Motivele arhivrii n formatul ZIP: Economisire spaiu Transmitere rapid Toate fiierele sunt puse ntr-o singur arhiv, nu este necesar trimiterea mai multor fiiere Citirie/scrierea n formatul ByteArray[] pstrareaz lipsa de codificre a coninutului fiierelor, pentru a nu modifica fiierele/datele din interiorul site-ului. Exemplu: Citirea i 65

Capitolul 5 scrierea n formatul String va schimba codificarea fiierelor JPG, ele nu pot fi citite dup conversia n UTF-8 , specific Java String. Soluia aparent este folosirea unui conversii spre Base64String; elementele jpg vor fi afiate, dar alte elemente, exemplu video, nu vor funciona.

5.4.1 Tehnologia Web Service

Modul de funcionare a unui serviciu web a fost detaliat n cadrul capitolului de fundamentare teoretic, n subcapitolul 3.3. Tehnologia folosit n implementarea acestui serviciu web este JAX-WS 2.2 oferit de ctre Java, implementat de aplicaia NetBeans. Folosind aceast implementare, utilizatorul trebuie s specifice tipul de operaie folosit(statefull sau stateless), mpreun cu logica de implementare a operaiilor, restul logicii este realizat de ctre NetBeans. Fiierul de tipul WSDL poate fi oricnd preluat folosind instruciunea Generate and Copy WSDL a platformei NetBeans. Aplicaia generator conine o clas serviciu web i o clas n care sunt detaliate operaiile efectuate n procesul de generare. Clasa serviciu web este intitulat Generator WS, este de tipul stateless nu ptreaz stare, i prezint operaiile de afiare i generare. OpG1: Operaia de afiare a unei documentaii a intrrilor se numete getInfo. Aceast funcie nu primete nici un parametru i ntoarce un String care conine documentaia. Acest String se afl n a doua clas i poate fi accesat folosind operaia getInfo. Aceast ieire joac rolul documentaiei prezentate n capitolul 4. Pre-condiii: nu exist; Post-condiii:rezultatul s nu fie de tipul null. OpG2: Operaia de generare. Aceast operaie se desfoar dup etapele descrise mai sus. Ele sunt exemplificate n exemplul de cod: Codul serviciului web Java:
@WebService @Stateless Public class WebService{ Public String getInfo(){ Return Operatii.getInfo(); } Public byte[ ] generateSite(Byte[ ] XML){ Pagina[] pagini = transformXmlToPages(XML); // logica de transformaren pagini String[] paginiHTML = generateCode(pagini); //logic de generare cod pagini Byte[][] componenteFisiere = transformXmlToComponents(XML); //logica de generarecomponentesunet, imagine, etc Retrun generateZip(pagini, paginiHTML, componenteFisiere); //ntoarce produsul arhivat n formatul byte[] } }

Pre-condiii: XML s fie n formatul cerut. Post-condiii: fiierul arhivat s fie de tipul ZIP. Clasa care implementeaz operaiile efectuate se numete Operaii i este prezentat individual.

66

Capitolul 5

5.4.2 Operaiile Generatorului web

Aceast aplicaie transform din formatul XML n fromatul de tipul ZIP. Formatul XML cuprinde informaia general legat de fiecare pagin, mpreun cu elementele cuprinse de aceasta. Pe baza informaiilor oferite aplicaia trebuie s fie capabil s genereze codul HTML/javaScript necesar realizrii acestor operaii. Clasa care conine toat logica de transformare este intitulat Operatii i conine o serie de metode statice puse la dispoziia clasei serviciului web. Aceast clas conine metodele descirse n codul serviciului web. Acestea sunt prezentate n ordinea etapelor de generare a aplicaiei: OpG3: Prima operaie a acestei clase transform XML n obiectele descriese n Componenta Editor. Transformarea este realizat prin parcurgerea tuturor elementelor din XML. La ntalnirea unor componente, exemplu: <aaa>, se creaz un obiect aaa, se citete pn la ntalnirea </aaa>, apoi se atribuie lui aaa obiectul specific componentei interioare. Datorit structurii fixe ale fiierului XML, numrul de atribute specifice obiectului aaa este cunoscut. Astfel, generarea se rezum la o citire i verificare a elementelor citite ntr-o ordine predefinit n fiierul XML. Unde este cazul, se face conversie. Algoritmul de generare a unei ComponentaText, privit funcional:
For (int i=0; i<byteArray.length;i++){ If (byteArray[i].toString == >) // avem un potenial nceput/sfarit de componenta if (ByteArray[i-5,i] == <text>) //logic de nceput de adugare text, creeare obiectText if (ByteArray[i-5,i] == /text>) // logic de atribuire text }

Implementarea este realizat folosind o serie de condiii, rezolvate folosind instruciunea if, care se ocup de logica apartenenei unui caracter la o component. Nu este folosit instruciunea case datorit lungimii variabile a denumirilor. Exemplu <jpg> - 5 caractere, <image> - 7 caractere. Logica de nceput de adugare, notific nceputul procesului de creearea unui obiect text prin atribuirea variabilei obiectText cu o valoare nou. Se vor citi parametrii componentei tot n aceast parcurgere, iar n cadrul logicii de atribuire text, obiectul obiectText va fi adugat n componentele paginii folosind instruciunea addComponent. n urmtorul pas, obiectText va primi valoarea null, s nu mai conin referina spre obiectul creat, adugat n array-ul de componente a paginii. Aceast operaie este realizat de ctre metoda static transformXmlToPages() a clasei Operaii. Pre-condiii: nu exist, a fost verificat de ctre metoda generateSite a clasei GeneratorWS; Post-condiii: Fiecare element a rezultatului s nu conin valori nule sau 0. OpG4: Dup creearea structurii pagini, genernd paginile codificate. generateCode() i primete ca parametru unidimensional de tipul String; fiecare parcurgere privit funcional: necesare generrii, se ncepe o parcurgere a fiecrei Aceast operaie este realizat de ctre metoda paginile generate anterior, oferind ca rezultat un tablou String corespunde unei pagini codificate. Metoda de

For each (pagina:ComponentaPagina in pagini){ String body =<body>\n; //iniializarea elementului body String head= <html>\n <head>\n // iniializarea elementului head For each (componenta in pagina.getComponente()){ If (if component aparine de head)

67

Capitolul 5
Head = head + logica generare component Else Body = body + logic de adugare elemente body logic generare element semantic web } Body = body + <\body>\n Head = head + <\head>\n Return head + body + <\html> }

Pre-condiii: nu exist, verificarea a fost realizat de operaia anterioar; Post-condiii: rezultatul s fie valid XML. OpG5: Urmtoarea operaie transpune imaginile n formatul byte[]. Dup cum a fost definit standardul XML, aceast operaie citete din fiierul XML valoarea informaiei imaginii JPG. Parcurgerea imaginii se realizeaz folosind instruciunea for, unde indicele pleac de la 15, lungimea minim a unui XML, pn la lungimea fiierului. Pentru o parcurgere optim, fiierul XML conine un tag specific fiecrei imagini n care se reine numrul de byte a imaginii. Astfel, aplicaia nu citete tot fiierul, ci doar poziia din fiier unde ncepe i unde se termin imaginea, urmnd ca indicele ciclului for s fie mrit cu lungimea imaginii. Aceast operaie este realizat de ctre metoda: transformXmlToComponents(). Implementarea este asemntoare parcurgerii XML pentru definirea obiectelor specifice paginii, cu diferena c se verific alte tag-uri. Pre-conditii: nu exist, XML este deja verificat; Post-condiii: rezultatul s nu conin elemente null. OpG6: Adugarea de pagini specifice fiecrui site. Aceste pagini se ocup de setul de funcionalitii, descrise n subcapitolul 4.2.1, specifice operaiilor de logare, stergere pagina, adugare pagin i dashboard. Acestea sunt scrise n limbajul php. Toate aceste fiiere sunt adugate ntr-un folder n interiorul serverului JSP. Generatorul copiaz toate fiierele din folder i le adaug n arhiva ZIP. Aceast abordare este folosit datorit posibilitii de modificare/adugare/tergere a fiierelor, fr ca generatorul s fie modificat. Paginile sunt returnate la apelarea metordi generatePhpFiles() din interiorul clasei Operaii. Implementarea acestei clase prezint o citire a directorului unde se afl filierele i o scriere n formatul byte a rezultatului. Aceste pagini sunt detaliate individual n subcapitolul 5.3.1. Pre-condiii: nu exist. Post-condiii: rezultatul s nu fie null. OpG7: Convertirea fiierelor formate n arhiva ZIP. Toate paginile sunt adugate n variabila String[] de pagini. Acestea sunt adugate n colecia de fiiere de tipul Byte[]. n aceast etap se adaug fiierele n cadrul aceluiai array, urmnd s fie scrise ntr-un byte[]. Pentru creearea unei arhive n formatul ZIP sunt necesare dou tablouri unidimensionale: unul care informaia care urmeaz adugat n fiecare fiier i un al doi-lea tablou care conine denumirea fiecrui fiier. Dup definirea acestor elemente, se adaug individual n elemente de tipul ZipEntry. Fiecare element de tipul ZipEntry este introdus ntr-un OutputStream, iar rezultatul final este transformat n byteArray. Acest rezultat este trimis ctre instana clasei GeneratorWS, apoi ctre clientul care a cerut site-ul web. Pre-condiii: nu exist. Post-condiii:rezultatul s nu fie null. 68

Capitolul 6

Capitolul 6.

Testare i validare

Acest capitol va prezenta variantele de testare ale aplicaiei. Asemntor capitolului anterior, se vor prezenta metodele de testare specifice proiectului n ansamblu, apoi metodele de testare/validare specifice fiecrei componente. Testarea tuturor componentelor este efectuat manual. Testarea automat este realizat pe baza pre/post condiiilor stabilite n capitolul dedicat implementrii, capitolul 5. Fiecare condiie este motivat acolo. Validarea va fi extecutat fie automat, fie manual in funcie de componente.

6.1. Ansamblul proiectului

Arhitectura proiectului este o arhitectur bazat pe componente, astfel testarea proiectului se rezum, n general, la testarea componentelor. Asigurarea bunei funcionri a proiectului, eliminnd testarea componentelor, se rezum la o serie de teste manuale i validri automate asupra comportamentului general al aplicaiei. Aceste teste/validri asigur funcionarea corespunztoare a transmiterii informaiei ntre componente. Validarea intrrilor oferite de utilizator este realizat de ctre: Controlorul aplicaiei Editor, paginile speciale ale Site-ului i de ctre intrrile Generatorului. Aceste operaii valideaz intrrile oferite de ctre utilizator iar n cazul unei poteniale erori, fie dispune spre model de afiarea erorii n cauz Editor, fie afieaz o eroare pe o pagin individual Site, fie afieaz un mesaj de eroare - Generator. Implementarea validrii de ctre controlor este descris n cadrul subcapitolului dedicat Controlorului: 5.2.1.5. Implementarea validrii prin paginile speciale se realizeaz prin redirecionarea ctre o pagin denumit errX, unde X este sursa errorii, urmnd ca apoi s se fac o nou redirecionare ctre pagina care a gsit eroarea n validare. Intrrile serviciului web ale generatorului verific dac variabilele trimise sunt de tipul ateptat. n cazul negativ, se va afia un mesaj. Rezultate: controlorul funcioneaz corespunztor, validarea paginilor speciale arat funcionare corect, afiarea mesajului de la generator este realizat corespunztor. Acestea sunt validri. Nu se verific rezultatul final. n cazul fiierului XML, oferit de ctre utilizator, aplicaiile Editor i Generator valideaz fiierul XML primit prin parcurgerea acestuia. n cazul n care exist erori n sintaxa fiierului XML, se va opri execuia operaiei i se va afia eroarea mpreun cu locaia unde a aprut. Aceast validare este implementat folosind instruciunea for, care parcurge tot fiierul. Se numr apariia unor tag-uri prin incrementarea unei variabile specifice tagului cu 1. n cazul apariiei sfritului de tag se va decrementa variabila cu 1. Dup parcurgere, dac vreo variabil este diferit de 0, suntem n prezena unui tag nedefinit corespunztor. Verificarea este realizat n acelai mod cu verificarea Editorului (subcapitolul 7.2). Rezultate: Aplicaia necesit mai mult timp de execuie din cauza testului. Testele primesc fiiere XML formate corect i fiiere XML formate greit. Testele au funcionat corect mai puin n cazul unei ipoteze: dac sunt amestecate tag-urile n aa fel nct s nu respecte standardul XML (exemplu: pagina n pagin, component n exteriorul unei pagini) paginile nu vor fi generate corect. Acest caz va fi cuprins n capitolul dedicat nbuntirilor (capitolul 8.2) Arhiva ZIP, care conine Site-ul Web 3.0, este verificat de ctre Editor dup ce este primit de la Generator. n cazul unei erori se va afia un mesaj corespunztor. Implementarea acestei validri este realizat folosind instruciunea try-catch. n cazul unei erori n parcurgerea 69

Capitolul 6 arhivei, se va opri parcurgerea i se va afia erroarea. Prin aceast abordare se asigur verificarea oricrei inconsistene a fiierului trimis spre vizualizare.

6.2.Editor
Verificrile/testele realizate n cadrul Aplicaiei Flash, sunt realizate manual. Adobe ActionScript 3.0, folosit n dezvoltarea Aplicaiei Flash, permite un singur mod de verificare a variabilelor/intrrilor/ieirilor, instruciunea trace(). Aceast intruciune afieaz n terminalul Flash mesajul trimis ca parametru. Testarea tuturor funciilor (intrri/ieiri) este realizat prin trimiterea unor intrri care pot cauza erori dar care verific pre-condiiile, apoi se verific dac ieirea respect post-condiiile. n cazul n care nu se repsect o precondiie, nu se va mai executa operaia i se va afia mesajul tipic erorii att n terminalul Flash ct i sub forma unei Erori generate de ctre Model. Dac nu este respectat o postcondiie, se va proceda la afiarea erorii n terminalul Flash, se va dispune la afiarea erorii de ctre Model i se vor retrage modificrile realizate de ctre metod. Implementarea verificriilor asupra precondiiilor se realizeaz prin inserarea unor instruciuni if n interiorul metodei invocate, nainte de logica de executare a metodei. n cazul n care se gsete o pre-condiie fals, se va afia n terminal folosind instruciunea trace(Eroare Pre-Conditie: + textEroare), apoi se va afia eroarea de ctre Model - doErrorPreCon(). Dup aceste dou instruciuni se va realiza instruciunea break;. Operaia de verificare asupra post-condiiilor se realizeaz ntr-un mod asemntor cu verificarea pre-condiiilor. Post condiiile const n o serie de verificri realizate folosind instruciunea if, poziionate la sfritul metodei, dup logica de executare. n cazul n care o condiie nu este verificat, se va afia n terminal, se va executa eroarea doErrorPostCon(), se vor schimba toate variabilele/atributele la valorile iniiale, apoi se va executa operaia de break;. Exemplu:
function f(param1,param2){ if (cond1){ trace(Mesaj Eroare); doErrorPreCon(); break; } //declarare variabile auxiliare specific variabilelor care urmeaz s fie modificate //logica functie f if (cond2){ //logic de schimbare variabile la valorile iniiale trace(Mesaj Eroare); doErrorPostCon(); break; } }

Rezultatele sunt positive, nu s-a reclamat existena unei erori n utilizarea fireasc a aplicaiei; nu s-a afiat nici un mesaj de eroare n terminalul aplicaiei flash. Valorile trimise greit ca pre condiie au produs erori, dar nu au existat erori de post-condiii.

70

Capitolul 6

6.3. Generator
Testarea realizat n cadrul generatorului se dezvolt folosind JUnit. Se va creea o nou clas de tipul JUnit n care se vor verificata toate metodele clasei Operaii. Fiecare metod, a clase Operaii, cuprinde o serie de pre-condiii i post-condiii. Acestea sunt verificate de ctre metodele unei clase JUnit, iar n cazul unor erori se va folosi metoda AssertFalse, mpreun cu un mesaj care specific ce condiie nu este verificat. Implementarea acestei verificri se realizeaz folosind pre-condiiile i post-condiiile definite n cadrul capitolului 5. Metodele de test sunt scrise folosind o clas JUnit, generat de pe baza clasei Operaii. Variabilele trimise ca parametrii vor primi valori specifice, fie null, i sunt verificate cu ce valoare ar trebui s primeasc. Exemplu:
@Test public void testZipBytes() throws Exception { System.out.println("zipBytes"); int nrComponents = 0; String[] filenames = null; byte[][] input = null; byte[] result = Operatii.zipBytes(nrComponents, filenames, input); assertTrue(result != null); }

n exemplul prezentat, chiar dac valorile trimise sunt null, se va ntoarce o arhiva goal. S-a testat fiecare metod, prin trimiterea diverselor valori ca parametrii i s-a verificat dac valorile oferite rspuns sunt corecte; parametrii trimii variaz n funcie de metoda apelat. Rezultatele testelor arat c aplicaia genereaz i creeaz elementele corespunztor.

6.4. Site
Funcionarea corespunztoare a paginilor din site este garantat de ctre Generatorul Web. Codul generat trebuie s funcioneze n orice medii. Din acest motiv, nu trebuie s existe o testare a codului produs, ci doar a modului de generare. Site-urile personalizate generate de ctre utilizator conin limbaj HTML, Semantic, componente other i componente facebook/twitter. Corectitudinea codului HTML i Semantic este verificat de ctre Editor i Generator, corectitudinea componentelor facebook/twitter este realizat de ctre aplicaiile Web 2.0 specifice. Implementrile tuturor verificrilor au fost descrise n capitolul 5. Singura problem care poate s apar este la nivelul componentei other. Aceasta poate fi supus unor verificri asemntoare cu cea realizat asupra componentei XML. Paginile specifice fiecrui site sunt verificate n etapa de dezvoltare. Implemenatarea verificrilor se realizeaz prin testarea rezultatelor paginilor n diferite cazuri. Fiecare set de instruciuni, specifice unei pagini, au fost testate manual prin introducerea unor date care pot cauza erori. Datorit folosirii instruciunii try-catch, nu au fost ntampinate cazuri care provocau o eroare de sistem. Validarea tuturor paginilor a fost realizat folosind validatorul RDF i HTML oferit de ctre W3C. Rezultatele validrii sunt pozitive, fiierele sunt realizate corect.

71

Capitolul 7

Capitolul 7.

Manual de instalare si utilizare

Prezentarea manualului de instalare/utilizare este realizat la nivelul fiecrei componente ale proiectului. Se vor preciza adresele URL unde se afl manualul de instalare/utilizare a platformelor pe care s-a dezvoltat aplicaia mpreun cu o descriere a modului de folosin a aplicaiei.

7.1 Instructiuni de instalare

Cele trei componente ale aplicaiei(Editorul, Generatorul i Site-ul) nu trebuie instalate pe maina local, ele ruleaz din interiorul unui broweser web. Totui, pentru rularea aplicaiei n interiorul unui browser, este nevoie instalarea unor aplicaii care afieaz coninutul specific fiecrei componente. Un alt set de instruciuni de instalare const n instruciunile specifice operaiei de instalare ale platformei de dezvoltare a aplicaiilor.

7.1.1 Editorul
Componenta editor este lansat pe un server JSP n paralel cu un server apache/PHP. Serverul php este folosit doar pentru afiarea paginilor speciale generate. Pe lng cele dou servere, este nevoie de aplicaia Adobe Flash Player/Adobe Flash. Acestea vor fi prezentate mpreun cu linkul unde se afl manualul de utilizare oficial. Java JDK o trebuie instalat mpreun cu Java EE portul 8080 o folosit pentru afiarea/dezvoltarea paginilor JSP o Manual: http://docs.oracle.com/javase/7/docs/webnotes/install/index.html NetBeans o trebuie instalat versiunea care conine implementarea pentru Java EE o folosit pentru dezvoltarea aplicaiei o Manual: http://netbeans.org/community/releases/69/install.html Adobe Flash CS5 o compatibil cu orice versiunea de la CS5 n sus o folosit n dezvoltarea Aplicaiei Flash o Manual: http://helpx.adobe.com/download-install.html Adobe Flash Player o compatibil cu versiunea 10 sau orice versiune ulterioar o folosit n afiarea Aplicaiei Flash o Manual: http://get.adobe.com/flashplayer/ Server HTTP Apache 2.2 o Instalarea se realizeaz pe portul 80 o Folosit n afiarea paginilor HTML o Manual: http://httpd.apache.org/docs/2.2/ Server PHP o folosit n afiarea paginilor speciale ale Site-ului/componentele facebook o Manual: http://php.net/manual/en/install.php Browser web o Orice browser web: Internet Explorer, Mozilla Firefox, Google Chrome, etc. 72

Capitolul 7 Componenta Editor este accesat prin intermediul Internetului, astfel nu necesit instalare. Fiierele componentei Editor sunt: Aplicaia Flash: o AplicaieFlash.swf Aplicaia JSP: o Afisare.jsp o Download.jsp o SendTo.jsp o Generate.jsp Toate aceste fiiere se poziioneaz ntr-un folder n interiorul serverului.

7.1.2 Generatorul
Componenta generator este rulat n interiorul unui browser, fr s fie nevoie de instalarea unei alte aplicaii. Generatorul este dezvoltat pe platforma NetBeans sub forma unei aplicaii web Java; manualul de instalare este specificat n subcapitolul 7.1.1. Fiierele componentei Generator: Index.jsp Operatii.java Fiierele claselor java folosite n generarea paginilor web o Componenta.java o ComponentaExterioara.java o ComponentaExternaFB.java o ComponentaExternaOther.java o ComponentaFBHistoryInput.java o ComponentaFBInput.java o ComponentaFBPicture.java o ComponentaImagine.java o ComponentaText.java o Hyperlink.java o Pagina.java Paginile sunt adugate n interiorul unui proiect Web Application oferit de NetBeans. Se creeaz un proiect folosind surse existene, apoi se ncarc sursele din proiectul Generator. Urmtorul pas este rularea proiectului. Surse proiectului Generator se afl pe discul aplicaiei.

7.1.3 Site
Componenta site nu necesit s fie instalat, ea epoate fi vizualizat fr instalare. Pentru viuzalizarea Site-ului este necesar un browser web, un server php(doar pentru paginile speciale) i aplicaia WinZIP. WinZip o folosit n dezarhivarea site-ului generat o manual: http://kb.winzip.com/kb/5/ Fiierele Site-ului se afl n arhiva ZIP generat. Pentru rularea aplicaiei, se copiaz toate fiierele n interiorul unui server, apoi sunt accesate prin intermediul unui browser.

73

Capitolul 7

7.2 Manual de utilizare

Manualul de utilizare arat modul de funcionare a componentelor. Fiecare funcionalitate va fi descris, apoi se vor prezenta paii necesari realizrii acestora.

7.2.1 Editorul
Aplicaia Flash conine o serie de butoane care efectueaz diverse operaii. Titlul fiecrei operaii va corespunde funcionalitii realizate de ctre editor. I. 1. 2. 3. 4. 5. 6. 7. 8. II. 1. 2. 3. 4. 5. Creeare pagin: click pe butonul Pagina completare cmpuri dialog Informaii Generale Pagin Nou selecteaz opiunea de clonare click pe butonul OK,n cazul unei erori treci la pasul 5, dac nu la pasul 8 se afieaz o eroare specific cmpului neselectat, click pe butonul OK completare camp cu valoare nou click pe butonul OK, n caz de eroare se trece la pasul 5 pagina nou a fost creeat dup parametrii introdui tergere pagin: click dreapta scen click pe Rename/Delete Pagin se selecteaz opiunea tergere se selecteaz pagina din meniul din partea dreapt click OK, n cazul unei erori se va face selecia pe campul cerut

Butoane

Scen

Figura 7.1 Scena Aplicaiei

74

Capitolul 7 III. 1. 2. 3. 4. 5. 6. IV. 1. 2. 3. 4. 5. 6. V. Redenumire pagin: click dreapta scen click pe Rename/Delete Pagin se selecteaz opiunea Rename se selecteaz pagina din meniul din partea dreapt se completeaz camp Denumire click OK, n cazul unei erori se va face selecia pe campul cerut Modific elemente pagin click dreapta scen click pe Rename/Delete Pagin se selecteaz opiunea Modific Elemente se selecteaz pagina din meniul din partea dreapt se completeaz camp Denumire/Scop click OK, n cazul unei erori se va face selecia pe campul cerut

Adugare component text: 1. click pe butonul Text 2. deseneaz elementul: a. click pe scen n locul care urmeaz s devin colul stnga sus al textului b. se ine click-ul apsat i se deseneaz mrimea componentei text c. se las click-ul 3. completare dialog 4. click OK, n cazul unei erori, se va modifica campul notificat prin eroare

Operaia de desenare Dialog de creeare

Componente Exterioare Activate

Figura 7.2 stnga Operaia de desenare; dreapta Dialogul de afiare; componentele Exterioare Activate VI. Modificare element text 1. Click pe elementul care urmeaz a fi modificat 2. Se pot face una din urmtoarele opiuni: a. adugare/tergere caractere 75

Capitolul 7 b. setare text bold i. se selecteaz textul care urmeaz a fi schimbat ii. se efectueaz click pe butonul B c. setare text italic i. se selecteaz textul care urmeaz a fi schimbat ii. se efectueaz click pe butonul I d. setare text underline i. se selecteaz textul care urmeaz a fi schimbat ii. se efectueaz click pe butonul U e. setare align i. se selecteaz unul dintre butoanele align, efectul este la nivelul componentei f. setare font i. se alege un tip de font; selecia este la nivelul componentei g. setare mrime i. se scrie o mrime n campul Size, mrimea este la nivelul componentei h. setare culoare text i. se selecteaz textul care urmeaz s fie colorat ii. se alege o culoare din colormixerul afiat i. setare hyperlink i. se alege texult care va conine un hyperlink ii. se efectueaz click pe butonul Hyperlink iii. se alege din lista de linkuri un link, dac este n interiorul site-ului se trece la pasul v. iv. se completeaz campul Hyperlink cu locaia ctre care se face redirecionarea v. se efectueaz click pe Create j. stergere hyperlink i. se sterg toate caracterele care aparin n hyperlink

Meniu Hyperlink Element Text

Meniu Element Text

Figura 7.3 Meniul Elementului Text 76

Capitolul 7 VII. 1. 2. 3. 4. 5. VIII. 1. 2. 3. 4. 5. 6. IX. 1. 2. 3. 4. 5. tergere component text: click dreapta scen click pe Rename/Delete Component se selecteaz opiunea terge se selecteaz componenta din meniul din partea dreapt click OK, n cazul unei erori se va face selecia pe campul cerut Adugare imagine: click pe butonul Image completare campuri dialog click browse se selecteaz imaginea de pe discul local click OK, n cazul unei erori se va schimba campul completat greit deseneaz elementul (V.2.) tergere imagine: click dreapta scen click pe Rename/Delete Component se selecteaz opiunea terge se selecteaz componenta din meniul din partea dreapt click OK, n cazul unei erori se va face selecia pe campul cerut

Figura 7.4 Dialog Redenumire/tergere pagin X. Creeare component Facebook. 1. se efectueaz click pe opiunea Facebook 2. se efectueaz click pe butonul Create Custom FB Component 3. se deseneaz zona componentei 77

Capitolul 7 4. se completeaz dialogul cu o valoare unic 5. se efectueaz click pe butonul OK 6. se pot aduga componente FBInput; FBInput Text; FBPicture n mod asemntor cu o component text XI. 1. 2. 3. 4. XII. 1. 2. 3. 4. XIII. Adugare component Facebook se efectueaz click pe butonul Add FB Component se selecteaz componenta care urmeaz s fie adugat se efectueaz click pe butonul OK se deseneaz componenta Adugare component Other Se efectueaz click pe opiunea Other Se efectueaz click pe butonul Create Other Component Se scrie codul care urmeaz a fi inserat Se efectueaz click pe butonul OK.

Generare XML 1. se selecteaz locul unde va fi salvat fiierul 2. se efectueaz click pe save ncrcare XML 1. se selecteaz fiierul care urmeaz a fi ncrcat 2. se efectueaz click pe save 1. 2. 3. 4. Opiuni Site-Map schimb acces la pagin se efectueaz click pe butonul Site Map se selecteaz pagina se selecteaz accesul se efectueaz click pe butonul Set.

XIV.

XV.

7.2.2 Generatorul
Pentru afiarea generatorului se va accesa pagina indexGenerator.jsp. Acolo se vor afia informaiile legate de serviciul web. Toi utilizatorii vor gsi acolo o opiune de download WSDL i generare Site.

Figura 7.5 Opiuni Generator 78

Capitolul 7 I. Download WSDL 1. se efectueaz click pe butonul download WSDL 2. se alege locaia/nuleme fiierului 3. se efectueaz click pe butonul OK Upload XML 1. se efectueaz click pe butonul Generate Site 2. se alege locaia/nuleme fiierului 3. se efectueaz click pe butonul Ok Download ZIP 1. se efectueaz click pe butonul download ZIP 2. se alege locaia/nuleme fiierului 3. se efectueaz click pe butonul OK

II.

III.

7.2.3 Site
Fiecare site generat conine un meniu. Acest meniu ofer accesul n interiorul paginilor generate. Pentru accesarea paginilor speciale, specifice fiecrui site, este nevoie de accesarea paginii login.php. Dup introducerea numelui i parolei contului de administrator (user/parol implicit admin/admin), se vor afia opiunile de schimbare a structurii site-ului:

Figura 7.6 Meniu Administrator tergerea unei pagini se efectueaz click pe butonul terge pagin n noua pagin se selecteaz pagina care urmeaz s fie tears se efectueaz click pe butonul ok se va afia un dialog care noptific dac operaia a fost realizat cu succes II. Modificarea unei pagini 1. se efectueaz click pe butonul de modificare pagin 2. se modific coninutul elementului care se dorete a fi modificat 3. se efectueaz click pe butonul Salvare III. Adugarea unei pagini 1. 2. 3. 4. 79 I.

Capitolul 7 1. 2. 3. 4. 5. IV. 1. 2. 3. 4. 5. V. 1. se efectueaz click pe butonul adaugare pagin se selecteaz modelul de pagin dup care se dorete efectuarea unei clone se efectueaz click pe butonul OK se modific coninutul elementului care se dorete a fi modificat se efectueaz click pe butonul Adaug Schimbare parol se efectueaz click pe butonul Schimbare Parol se introduce vechea parol n cmpul parol veche se introduce noua parol n cmpul parol nou se introduce noua parol n cmpul repetare parol nou se efectueaz click pe butonul Schimba Parol Delogare Se efectueaz click pe butonul Logout

80

Capitolul 8

Capitolul 8.

Concluzii

Aplicaia ndeplinete obiectivele generale propuse. Generatorul creeaz un site Web 3.0 funcional, care poate fi folosit oricnd de ctre utilizator. Editorul ajut utilizatorul n dezvoltarea unui site, oferind un set de operaii de tipul CAD. Site-ul generat este personalizat dup preferinele utilizatorului. De asemenea, aplicaia respect majoritatea cerinelor prezentate n capitolul dedicat analizei, capitolul 4. Totui exist anumite aspecte care trebuie nbuntite, reevaluate sau modificate.

Calitatea obiectivelor realizate

Majoritatea obiectivelor propuse au fost realizate. Cele trei componente ndeplinesc operaiile generale cerute. Singura problem care mai poate fi ridicat este legat de calitatea funcionalitiilor implementate. Ansamblul de componente care alctuiesc Generatorul de Site-uri Web 3.0, poate fi verificat, calitativ, printr-o analiz comparativ cu orice alt produs software care realizeaz un scop asemntor. Aplicaia prezint o serie de avantaje i o serie de dezavantaje, acestea vor fi detaliate la rndul lor. Analiza este realizat prin comparaie cu dou aplicaii generatoare de pagini HTML: Adobe Dreamweaver, W3C Amaya. Motivul seleciei celor dou aplicaii are la baz numrul ridicat de utilizatori care folosesc aplicaiile. Criteriu Text Toate opiunile HTML Imagini Sunet Generator Web3.0 Dreamweaver CS4 Web 1.0 Parial cele mai Da importante Da Da Partial poate fi adugat ca o Da component other Partial poate fi adugat ca o Da component other Web 2.0 Foarte uor Da Nu Da Mediu Nu Da Parial poate fi scris codul de conexiune Nu Web 3.0 81 Amaya Da Da Da

Video

Da

Uurin n utilizare Acces de oriunde Release-cycle Reele de socializare Adugare de coninut de ctre utilizator

Uor Nu Da Nu

Da

Nu

Capitolul 8 Partial trebuie definit de utilizator Partial trebuie Da definit de utilizator Aspecte Generale Partial trebuie definit de utilizator Nu

Semantic Web

Da

SVG

Editare Parial Da componente Inserare cod Parial Da server-side component other Modificare cod Nu Da pagin Complexitate Redus Foarte Ridicat opiuni disponibile Pagini speciale Da Nu Optimizare Mediu Performant Resurse utilizate Minim Mediu/Avansat de ctre client Arhivare ZIP Da Nu Elemente grafice Minimal Bogat Tabelul 8.1 Comparaie Proiect/Dreamweaver/Amaya

Da Nu Da Mediu Nu Mediu Mediu Nu Mediu

Avantajele Aplicaiei Generator Web 3.0: Proiectul permite o dezvoltare mai uoar i complet a caracteristicilor Web 2.0/3.0 dect celelalte dou aplicaii. Uurina n utilizare se datoreaz i uurinei de manipulare a aplicaiei. Fr s fie suprancrcat cu diverse opiuni, utilizatorul completeaz doar elementele cele mai importante ale paginii. Procesul de generare necesit o serie de citiri/scrieri repetate. Acestea pot ocupa foarte mult din memorie/timp de execuie. Aplicaia conine o serie de constrngeri i citiri speciale care duce la executarea optim a operaiilor. Aplicaia folosete mai puine resurse ca oricare dintre celelate dou aplicaii. Dezavantajele Aplicaiei: Proiectul nu prezint o posibilitate de modificare a codului HTML care urmeaz a fi generat. Acest dezavantaj nu prezint o importan deosebit, aplicaia este destinat celor care nu au cunotiine de programare. Un alt dezavantaj al aplicaiei este legat de elementele grafice ale componentelor. Aplicaia conine un nivel minimal de elemente grafice. Proiectul este centrat pe funcionalitate, nu pe elemente grafice. Ele pot fi adugate oricnd n aplicaie, logica din spatele fiecrei componente rmne la fel. Pe baza Tabelului 8.1, mpreun cu avantajele prezentate de ctre Aplicaia Generator Web 3.0, se poate observa un probabil nivel ridicat de competivitate cu celelalte dou aplicaii. Aceast competivitate se reflect fa de inta de utilizatori urmrit de aplicaie.

82

Capitolul 8 n cazul utilizatorilor experimentai, este nevoie de dezvoltarea unor funcionaliti care s permit modificarea codului HTML din interiorul Editorului. Aceste cerine, mpreun cu cteva nbuntiri, fac obiectul subcapitolului dedicat dezvoltrii/nbuntirii - 8.2.

Posibile dezvoltri/nbuntiri
Fiecare component poate fi nbuntit fie prin adugarea de funcionaliti, fie prin nbuntirea unor funcionaliti deja existente, fie prin rezolvarea unor probleme care au aprut n etapa de testare. Este util o prezentare a unor nbuntirilor generale, urmate de nbuntirile propuse la nivelul fiecrei componente n parte. Prin aceast abordare se evit repetarea unor cerine specifice mai multor componente.

8.2.1 Dezvoltri/nbuntiri generale

Majoritatea dezvoltrilor/nbuntirilor descrise n acest subcapitol sunt legate de funcionaliti care pot fi adugate n site-ul generat. Aceste funcionaliti pot fi fcute la nivelul unei singure componente, dar este recomandabil modificarea tuturor componentelor. adugarea de culoare/poz background n site adugare de elemente sunet i video adugarea de mai multe tipuri de reele de socializare adugarea unor componente meniu adugarea unor opiuni suplimentare legate de afiarea textului adugarea unei logici de utilizare conturi de utilizator in site Observaie: Componentele sunt independente, astfel, adugarea funcionalitiilor n cadrul oricrei componente este realizat independent, iar efectuarea modificrilor trebuie realizat n aa fel nct s nu creeze erori n utilizare: orice funcionalitate nou a Editorului nu va fi vzut de ctre Generator sau Site, doar dac Generatorul schimba standardul XML, Editorul va schimba formatul generat schimbarea modului de generare a site-ului nu este vizibil (perpetual beta) schimbarea formatului XML nu trebuie s fac formatul vechi XML neutilizabil(nu se elimin tag-uri, doar se adaug)

8.2.2 Editor
Componenta Editor necesit cele mai multe dezvoltri/nbuntiri. Aceast afirmaie se bazeaz pe calitatea de component Front End al proiectului. Dac se dorete includerea utilizatorilor experimentai n targetul de utilizatori ai aplicaiei, este necesar dezvoltarea unei alternative vizuale, dedicat utilizatorilor expert. Acest alternativ va trebui s conin opiuni complexe de editare a codului, mpreun cu opiuni de particularizare a elementelor inserate n pagin. Forma normal, dedicat utilizatorilor necunosctori de programare, trebuie nbuntit prin adugarea unor opiuni generale de editare HTML. Aceste opiuni mpreun cu opiunile formei alternative se rezum la: adugare elemente grafice n cadrul aplicaiei JSP adugare elemente grafice n cadrul aplicaiei Flash mai multe opiuni de vizualizare/verificare 83

Capitolul 8

validator a paginilor HTML generate creearea posibilitii de salvare template posibilitate de scriere/modificare cod HTML mai multe opiuni legate de elementele HTML nbuntiri 8.2.1

8.2.3 Generator
Modificrile realizate n interiorul generatorului sunt minimale. Ele se rezum la adugarea unor tag-uri la citire i scriere. Fiecare component/element/atribut adugat n interiorul fiierului XML trebuie manipulat de ctre Generator. O potenial modificare a generatorului const n includerea aplicaiei Flash n interiorul Generatorului. Componenta generator va conine o metod care ntoarce, n formatul byte[], fiierul swf. Exist mai multe avantaje ale acestei abordri: nu mai trebuie salvat Aplicaia Flash n interiorul unui site, modificarea ulterioar a Aplicaiei Flash este realizat la toi clienii Generatorului; dar i o serie de dezavantaje: suprancrcarea Generatorului cu cereri, componentele Editor i Generator nu mai sunt independente. Alegerea rmne la nivelul dezvoltatorului. Pe lng aceaste nbuntiri, se mai poate aduga cteva opiuni suplimentare: posibilitatea accesrii pe baza unei arhitecturi REST XML-ul format greit s fie reconstruit nbuntiri 8.2.1

8.2.4 Site
Modificrile componentei Site izvoresc din modificrile Generatorului i Editorului. Orice opiune adugat n aceste dou componente este vizibil n site-ul generat. O alt potenial modificare const n adugarea de cod javaScript, folosit n redimensionarea paginii. n cazul n care se va face resize la browser, acest cod s repoziioneze i s miceasc/mreasc elementele paginilor, n funcie de mrimea ferestrei browserului. Cteva nbuntiri ulterioare care pot fi adugate: adugarea unei logici de resize a paginilor mai multe pagini specifice fiecrui site, care ndeplinesc diferite sarcini elemente grafice n paginile specifice fiecrui site nbuntiri 8.2.1

84

Anexa

Anex
Prezenta anex conine o serie de informaii legate unele particulariti ale aplicaiei. Fiecare component fi prezentat individual.

A1 Editor
Anexa prezint elementele vizuale i funciile realizate de componenta editor.

A1.1 Elementele vizuale ale aplicaiei

n cadrul capitolului 5 s-au prezentat o serie de elemente vizuale temporare. Ele sunt prezentate n tabelul A1. Modul de generare a elementelor vizuale:
var okBtnPage:SimpleButton = GenerateButton("OK",0xD4D4D4,100,40); // se instaniaz un obiect de tipul buton okBtnPage.x = 570; okBtnPage.y = 500; // se poziioneaz n scen okBtnPage.visible = false; // este setat ca fiind vizibil addChild(okBtnPage); //este desenat n Aplicaia Flash.

Nume okBtnPage cancelBtnPage okBtnError okBtnRightPage cancelBtnRightPage okBtnRightComponent cancelBtnRightComponen t okBtnNewTextFieldPage cancelBtnNewTextFieldP age cancelBtnNewImage okBtnNewImage browseBtnNewImage okBtnSiteMap okBtnCreateCustomFBCo mponent cancelBtnCreateCustomF BComponent setAccessBtnPage

Tip SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton

Nume fundalPagina fundalEroare paginaLabel denumirePaginaLabel denumirePaginaInput scopPaginaLabel scopPaginaInput clonaPaginaLabel listPagina eroarePaginaLabel paginaRenameDeleteLab el paginaRenameDeleteLab elOperatie paginaRenameDeleteLab elPagina listOperatiiPagina listaComponentePagina paginaRenameDeleteLab

Tip Shape Shape TextField TextField TextField TextField TextField TextField TextField TextField TextField TextField TextField List List TextField 87

Anexa elDenumire paginaRenameDeleteLab elDenumireInput paginaRenameDeleteLab elDenumireInput paginaRenameDeleteLab elScop paginaRenameDeleteLab elScopInput scopNewTextFieldInput newImageLabel denumireNewImageLabe l denumireNewImageInput relevantaNewImageLabel relevantaNewImageInput altNewImageLabel altNewImageInput linkNewImageLabel siteMapDenumireLabel

okBtnAddFBComponent cancelBtnAddFBCompon ent okBtnAddOtherCompone nt cancelBtnAddOtherComp onent componentLabelDelete componentRenameDelete Label listaComponente componenteRenameDelet eLabel componenteRenameDelet eInput paginaRenameDeleteLabe l newTextFieldPaginaLabel denumireNewTextFieldLa bel denumireNewTextFieldIn put scopNewTextFieldLabel

SimpleButton SimpleButton SimpleButton SimpleButton TextField TextField List TextField TextField TextField TextField TextField TextField TextField

TextField TextField TextField TextField TextField TextField TextField TextField TextField TextField TextField TextField TextField TextField

Tabelul A1:Elementele Vizuale Temporare

A1.2 Controlerul
Orice element vizual prezint un comportament. Exemplu de adugare comportament:
sizeInpuInstance.addEventListener(Event.CHANGE,setSizeTextField); sizeInpuInstance.addEventListener(FocusEvent.FOCUS_OUT,setSizeTextFieldDefault); sizeInpuInstance.border = true; setSizeTextField(e:Event):void{ selectedTextField.setMarime(int(e.target.text)); updateChangedTextField(); } setSizeTextFieldDefault(e:Event):void{ if (e.target.text == "") { selectedTextField.setMarime(32); } }

Fiecare funcie trebuie s conin paramterul e:Event.

88

Anexa

A1.3 Modelul
Componenta model conine un numr de funcii care ndeplinesc anumite funcionaliti. Un exemplu de funcie:
createNewExteriorPage(x:int,y:int,w:int,h:int,titlu:String,scop:String):ComponentaExterioara{ var pagina = new ComponentaExterioara(x,y,w,h,titlu,scop); pagina.setID(pagini.length); var paginaAux:Pagina = Pagina(pagina); pagini.push(paginaAux); return pagina; }

Antet funcie GenerateButton(textVar,culoare,w,h): SimpleButton GenerateLabel(textVal,x,y,w,h) : TextField GenerateInput(x,y,w,h): TextField GenerateList(x,y,w,h) : List GenerateTextArea(textVar,x,y,w,h) : TextArea GenerareFundalDialog(culoare, x, y, w, h, eW, eH):Shape GenerateInputSite(x,y,w,h): TextField updateListaPagina():void updateListaOperatiiPagina():void updateListaComponentePagina():void updateListaComponente():void errorMessege(messege:String):void updateAfisarePagini():void updateTextBtnPagina(denumirePagina:String,noulText:Stri ng):void createNewPage(titlu:String,scop:String):Pagina createNewExteriorPage(x:int,y:int,w:int,h:int,titlu:String,sc op:String):ComponentaExterioara createBtnPagina():void setFocusOnPagina(pagina:Pagina):void textFieldStartDrag() addTextField(x:int,y:int,x2:int,y2:int,denumireGenerica:Stri ng,relevanta:String):void updateTextFieldForm()

Funcionalitate Genereaz un buton Genereaz un label Genereaz un input Genereaz o list Genereaz un text Area Genereaz un fundal Genereaz un Input Realizeaz un update a listei paginilor Realizeaz un update a listei Operaii Pagin Realizeaz un update a listei Componente Pagin Realizeaz un update a listei deComponente a paginii vizualizate Creeaz o eroare Realizeaz un update a paginilor afiate Realizeaz un update a butonului unei pagini Creeaz o pagin nou Creeaz o pagin nou exterioar Creeaz o un buton a unei Pagini Afieaz o pagin n scen Iniializeaz nceputul operaiei de drag Adaug un Element TextField n pagin Realizeaz operaia de sincronizare ntre obiect i 89

Anexa Antet funcie updateStringFromTextFieldDown() Funcionalitate elementul vizual Realizeaz operaia de sincronizare ntre obiect i elementul vizual n cazul unei taste apsate Realizeaz operaia de sincronizare ntre obiect i elementul vizual n cazul unei taste eliberate Afieaz dialogul de opiuni a unui text Iniializeaz o posibil operaie de drag a unei componente Text Concluzioneaz operaia de drag a unei componente text Iniializeaz operaia de drag a unei componente Text Operaia de drag a unei componente Text Concluzioneaz operaia de drag a unei componente Text Deseneaz un dreptunghi folosit n desenarea unei componente Elibereaz scena de componentele paginii Insereaz n scen componentele paginii Genereaz pagina de index terge o pagin Schimb scopul unei pagini Iniializeaz operaia de drag a unei componente Imagine Realizeaz operaia de sincronizare ntre componenta Text i elementul vizual TextField n urma operaiei de resize Creaz un nou obiect de tipul TextFormat care 90

updateStringFromTextFieldUp()

showTextOptionsDialog():void initPossibleDragText(e):void disablePossibleDragText():void strtDragTextField():void dragTextField():void stpDragTextField():void drawContinousShape() clearStage() redrawStage() generateIndexPage() deletePagina(denumirePagina:String):void schimbaScop(denumirePagina:String, scopNou:String) imageFieldStartDrag():void updateResizedTextFiled(textField:TextField)

newFormatBIU(fontType:String,size:int,align:String):TextF

Anexa Antet funcie ormat loadXML() onFileSelected1() onFileComplete1() onInitBitmapLoad():void strtDragBitmap():void dragBitmap():void stpDragBitmap():void onInitBitmap():void initPossibleResize() initPosibleDrag():void disablePosibleDrag() addBitmapToScene(x:int,y:int,h:int,w:int,alt:String,link:Stri ng,location:String,denumire:String, relevanta:String) drawTemporalBitMap(x:int,y:int,h:int,w:int) onInitBitmap2():void Tabelul A2: Funciile realizate de Model Funcionalitate conine elementele de Bold Italic i Underline ncarc XML n scen Operaia realizat la selecia unei imagini Operaia realizat la ncrcarea unei imagini Operaia realizat dup adugarea unei imagini n Loader Iniializeaz operaia de drag a unei componente Imagine Operaia de drag a unei componente Imagine Concluzioneaz operaia de drag a unei componente Imagine Operaia realizat dup adugarea unei imagini n scen Iniializeaz o posibil operaie de resize unei componente Imagine Iniializeaz o posibil operaie de drag unei componente Imagine Concluzioneaz operaia de drag a unei componente Imagine Adaug o imagine n scen Deseneaz o imagine temporar Operaie realizat asupra imaginii temporare

A2. Generator
Componenta Generator conine o clas Operaii care realizeaz toate operaiile specifice generatorului. Ele sunt prezentate n tabelul A3. Funcia de transformare a fiierului XML n arhiva ZIP:
public static byte[] transform(byte[] XML){ Pagina[] pagini = Operatii.transformXmlToPages(XML); byte[][] componenteFisiere = null;

91

Anexa
try { componenteFisiere = transformXmlToComponents(XML); } catch (IOException ex) { Logger.getLogger(Operatii.class.getName()).log(Level.SEVERE, null, ex); } String[] paginiHTML = generateCode(pagini); return generateZip(pagini, paginiHTML,componenteFisiere,XML); }

Antet Funcie public static byte[] generateZip(Pagina[] pagini, String[] paginiHTML, byte[][] componenteFisiere,byte[] XML) public static String fbInputCode() public static String fbPictureCode() public static String fbHistoryCode() public static String[] generateCode(Pagina[] pagini) private static byte[][] generatePhpFiles() public static Pagina[] transformXmlToPages(byte[] XML) public static byte[][] transformXmlToComponents(byte[] XML) public static byte[] zipBytes(int nrComponents, String[] filenames, byte[][] input) Tabelul A3: Funciile Generatorului

Funcionalitate Creeaz tipurile de obiecte necesare unei arhivri, apoi trimite ctre operaia zipBytes spre arhivare. Fiierul arhivat este oferit ca rezultat al funciei Genereaz codul componentei facebook input Genereaz codul componentei facebook picture Genereaz codul componentei facebook history input Genereaz codul HTML pe baza obiectelor Pagina Genereaz codul paginilor specifice oricrui site Transform fiierul XML n obiecte de tipul Pagin Transform imaginile din interiorul fiierului XML n elemente de tipul byte. Arhiveaz paginile generate

92

Anexa

A3. Site
Site-ul generat conine paginile desenate de ctre utilizator i un set de pagini specifice oricrui site. Acestea sunt prezentate n taelul A4. Pagina Funcionalitate adaugare_pagina Adauga o pagin cloneaza Cloneaza o pagin existent dashboard Pagina de social dashboard downloadXML Pagina de download a fiierului XML sterge_pagina Sterge o pagin login Logare ca administrator Menu Meniul administatorului logout Delogare schimbare_parola Schimb parola administratorului modifica_pagina Modific o pagin existent Tabelul A4: Paginile specifice oricrui site

93