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 informații ................................................................ 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 Cerințe funcționale ................................................................................ 30 4.2.1.2 Cerințe ne-funcționale: .......................................................................... 31 4.2.1.3 Cerințe specifice domeniului problemei: ............................................... 32

4.2.2 Generatorul Web........................................................................................... 32

4.2.2.1 Cerințe funcționale ................................................................................ 32 4.2.2.2 Cerințe ne-funcționale ........................................................................... 32

4.2.3 Editorul de Site-uri ....................................................................................... 33

4.2.3.1 Cerințe funcționale ................................................................................ 33 4.2.3.2 Cerințe ne-funcționale ........................................................................... 34 4.2.3.3 Cerințe 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 Aplicația Flash .............................................................................................. 39

5.2.1.1 Platforma Aplicației ............................................................................... 39 5.2.1.2 Șablon de proiectare .............................................................................. 40 5.2.1.3 Elemente generale ale implementării .................................................... 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 Operații legate de pagini ................................................................. 53 5.2.1.6.2 Operații legate de componente ....................................................... 54

5.2.2 Standardul XML ........................................................................................... 57

5.2.3 Aplicația JSP ................................................................................................ 59

5.2.3.1 Platforma Aplicației ............................................................................... 59 5.2.3.2 Implementarea operațiilor ..................................................................... 59

5.3 Site Web 3.0 ........................................................................................................ 61

5.3.1 Pagini specifice fiecărui 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 Operațiile 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 dezvoltări/înbunătățiri .................................................................................. 83

8.2.1 Dezvoltări/înbunătățiri 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 aplicației .................................................................. 87

A1.2 Controlerul .................................................................................................... 88

A1.3 Modelul ......................................................................................................... 89

A2. Generator ............................................................................................................ 91

A3. Site ...................................................................................................................... 93

Capitolul 1

7

Capitolul 1. Introducere – Contextul proiectului

Pentru o introducere corespunzatoare în contextul problemei este indispensabilă o prezentare a evoluției Internetului, a modificării structurii sale. Necesitatea unei astfel de prezentări este motivată de evoluția legăturii între Internet și om, de satisfacerea nevoilor utilizatorului și modul prin care Internetul a răspuns acestor cereri.

Fenomen complex care, mai mult ca niciodata, are un rol important în viața omului, Internetul a parcurs o serie de etape pentru a deveni ceea ce este astăzi. Aceast capitol va prezenta succint etapele de dezvoltare, atât tehnologică cât și privită din punct de vedere al raportului author – user, apoi va continua cu o ramura a Internetului și anume socializarea on-line cât și o prezentare a viitorului.

Descrierea fiecărei etape va fi limitativă, dar va conține suficientă informație pentru ințelegerea unui concept sau fenomen, împreună cu surse bibliografice care prezintă conceptul în profunzime.

1.1 Internet și Web 1.0

Internetul este o rețea globală de caluclatoare, o „rețea de rețele”[1], care „oferă o varietate largă de informații, resurse și servicii” [1] miliardelor de utilizatori care îl folosesc. Acest schimb de informații se realizează printr-un standard denumit „Internet protocol suite”[2] - IP (cunoscut în special sub denumirea generică de TCP/IP, deși nu toate protocolurile folosesc TCP) prin care utilizatorii comunică unii cu alții diferite tipuri de informații 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 operațional de schimb pe o scală largă a apărut abia în 1968 cand ARPANet a pus în aplicare primul proiect de rețea de calculatoare, denumit generic astăzi “bunicul internetului”. Deși modelul pentru o scala mare a apărut așa târziu, rețele de calculatoare existau și la începutul anilor 1960 dar acestea conțineau un număr limitat de calculatoare și resurse.

Prima teoretizare a ceea ce urma sa devină Internetul a fost făcută în 1962 de J.C.R. Licklider, cercetător MIT, care propunea conceptul de „Galactic Network”. Acest concept prezenta o rețea globală de calculatoare interconectate prin care oricine putea să acceseze informații și programe din orice locație.[3]

Deși conceptualizat, Internetul s-a născut odată cu standardizarea “Internet Protocol Suite” [2] în 1982. Pînă atunci rețelele de calculatoare erau facute doar la nivel local și doar acei utilizatori care aveau un nivel mediu de cunoștiință a calculatoarelor puteau sa opereze cu aceasta. Introducerea acestui protocol a făcut conectarea și transmiterea de date mai ușor de înțeles și practicat.

Odată cu trecerea timpului, un serviciu al internetului denumit “World Wide Web” începe să devină din ce în ce mai popular, aducând noi utilizatori datorită mas-mediei, circulatiei rapide printre adolescenți cat și ușurinței cu care se putea face schimbul de informații.

Transferul de informații se realiza printr-o aplicație denumită “web browser” prin care un utilizator cu un nivel minim de cunoștiință a calculatoarelor putea sa vizualizeze pagini hypertext.

Până la sfârșitul anilor 1990, WWW era format din o serie de pagini statice pe care utilizatorul putea doar să le vizualizeze (Web 1.0), fără a putea modifica sau adauga ceva. În fapt, autorii paginilor expuneau informații într-un mod asemănător afișelor.

Acest lucru se dovedea a fi prea puțin pentru un mediu cu asemenea potențial, un mediu care putea atat sa trimită cît și să primească informații. Astfel se naște un internet de tipul „read/write”[4], un Internet în care “fiecare utilizator poate să dețină propriul spațiu în care să scrie” – Web 2.0.

Capitolul 1

8

1.2 Web 2.0, Web 3.0 și HTML5

Conceptul Web 2.0 reprezintă o serie de caracteristici specifice unei aplicații web prin care se facilitează partajarea de informații, interoperabilitatea, design bazat pe utilizator în WWW[5]. Acum utilizatorii nu mai sunt doar consumatori ci și producători, colaborând într-o societate virtuală în care “ne putem întâlnii cu toții unde să citim și să scriem”[4]

Deși termenul pare a sugera un update la WWW, o altă specificație, el defapt arata o schimbare in modul în care software developeri si utilizatorii finali folosesc și creează pe Internet. Vorbim despre o „arhitectură de participație”[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 schimbări încep să apară diverse noi tehologii cât ș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ă interacționeze cu utilizatorul și să îl integreze în sine, arhitecturi web oriented – aplicațiile Web 2.0 își expun funcționalitățiile pentru ca alte aplicații să se poată folosi de ele, aplicații “rich internet”[5] – aplicații usor accesibile cât și bogate din punct de vedere vizual.

În clipa de față există suficiente astfel de posibilităti de dezvoltare. Ele devin din ce in ce

mai performante și îți oferă tot mai multe dar viitorul nu constă în mai multe rețele de socializare sau mai multe metode de comunicare. Viitorul constă într-un Web în care calculatorul cunoaste ceea ce face și ajută utilizatorul în experiența sa on-line.

În prezent aplicațiile web nu se deosebesc de un calculator de mână care primește informații și apoi le afișează pe un ecran. O aplicație web afisează, dar nu întelege defapt ceea ce este scris. Este nevoie de aplicații care procesează informațiile primite de la utilizator în așa fel încât contentul primit să fie generat de calculator în funcție de preferințe. Un Web în care aplicațiile să caute, pentru utilizator, on-line – Web 3.0.

Aplicația va întelege atât ceea ce dorești cât și preferințele tale. O aplicație Web 3.0 va cauta în istoricul utilizatorului preferințele sale și le va raporta cu ceea ce dorește. Spre exemplu, dacă se introduce: “Vreau sa mă duc la un restaurant cu specific chinezesc. Unde propui să mă duc?” , aplicația îmi va propune o listă în ordinea probabilelor mele preferințe. În Web 2.0 trebuie sa cauți în mai multe pagini o alternativă, să citești user review-uri și în cele din urmă te hotărești. Web 3.0 face asta pentru tine la prima căutare. Dacă Web 2.0 folosește internetul să conecteze oamenii, Web 3.0 conectează cu informații.[7]

Această direcție de dezvoltare pare a fi acceptată și de către cei de la World Wide Web Consortium prin propunerea unui nou mod de interacțiune între aplicații denumit Semantic Web. Acesta cuprinde un framework comun care permite informației să fie împărțită și reutilizată în mai multe aplicații 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 informației din pagina web, relațiile dintre acele informații și o anumită tipologie. Astfel un agent Web 3.0 nu va mai căuta doar cuvinte cheie în conținutul documentelor ci și modul cum relaționează cu restul paginii.

Capitolul 1

9

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 aplicații on-line care se fundamentează pe ideologia Web 2.0 și care permit creația și schimbul de documente generate de utilizatori”[11]. Aparent corectă, definiția nu pare a fi suficientă datorită lipsei scopului principal, interacținea socială.

Aplicațiile Social Media se fundamenteaază pe accesibilitate și scalabilitate a unei pseudo-comunicări on-line, fundament care a schimbat modul în care comunitățile, organizațiile și indivizii comunică.

Formele principale de comunicare cuprind: internet forums, webblogs, blog social, microblogging, wikis, podcast, social bookmarking, etc. Internetul prezintă un număr mare de tehnologii și aplicații care oferă aceste servicii. Aparenta problemă pare a fi o relativă unificare a acestora.

Datorită cantității mari de aplicații și a utilizatoriilor care le folosesc, se dovedea dificilă o comunicare optimă. Pentru fiecare aplicație trebuie efectuată comunicarea separat. Astfel un utilizator trebuia să se conecteze la toate aplicațiile folosite și sa le urmărească individual. Această nevoie urma să fie satisfăcută rapid, iar începând cu anul 2008 apar aplicațiile denumite Social Dashboard care uneasc toate aceste aplicații sub o singură platformă.

1.4 Motoare de cautare și Web

Influența Web 2.0 a pătruns și în domeniul motoarelor de căutare. Până la începutul anului 2010, autorii de Web Search Engine Optimization ca Brian Solis vorbeau despre importanța aplicațiilor Web 2.0 în mediul căutarii on-line[13], deși giganții motoarelor de căutare nu pareau a respecta această regulă.

Abia în decembrie 2010, Google, pe Vlogul său de Webmasters, a confirmat importanța aplicațiilor web[14]. Ele au devenit “semnale” pentru căutare, în special în domeniul blog, singura problema pare a fi accesibilitatea acestor informații.

1.5 Contextul Problemei

În prezent se pune problema trecerii de la Web 2.0 la Web 3.0 în cadrul aplicațiilor sociale existente. Există platforme de unificare dar ele nu fac altceva decât să publice informațiile nu să le și interpreteze.

Următorul pas este oferit de o aplicație care preia activitatea utlizatorului, observă interesele sale, activitatea de socializare și păstreaza informațiile importante. Această aplicație trebuie să fie conectată la tot ceea ce face utilizatorul astfel trebuie să unifice toate aplicațiile folosite de utilizator, pe scurt un amestec între Web 3.0 și Social Dashboard.

Răspunsul este oferit de o aplicație specifică fiecăruia, o aplicație care dedublează personalitatea utilizatorului. Având un istoric de socializare, ea poate prezuma interesul utilizatorului și să îl ajute în experiența on-line. Acestă aplicație trebuie generată la nivelul fiecărui 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 aplicație care generează site-uri Web 3.0, site specific fiecărui utilizator. Trebuie să unifice toate aplicațiile Web 2.0, să proceseze aceste informații, apoi să ajute utilizatorul la o căutare on-line.

Capitolul 2

10

Capitolul 2. Obiectivele proiectului

Problema procesării tuturor informațiilor Web 2.0 sub o singură platformă se poate realiza printr-o aplicație independentă . Această aplicație trebuie să înțeleagă ceea ce doreste utilizatorul, să poată fi utilizată de oriunde, să păstreze „personalitatea utilizatorului”, să păstreze legătura cu aplicațiile Web 2.0 și să ajute utlizatorul în experiența on-line. Soluția propusă constă într-un site care îndeplinește toate condițiile de mai sus.

Proiectul oferă un generator de site-uri web, unul specific fiecărui 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 informațiilor primite - Web 3.0.

Realizarea obiectivului propus se efectuează printr-un proiect ce constă în trei părți principale:

• un serviciu on-line care generează site-uri – Generator Web 3.0, • un consumator de servicii care citește preferințele 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, independența produsului final și a serviciului, posibilitatea de reutilizare a serviciului cât și alte particularități care vor fi prezentate în subcapitolele următoare.

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ă funcționalități care satisfac necesarul unei dezvoltări de site-uri.

Prima funcționalitate este una de informare a clientului în ceea ce privește operațiile oferite de serviciu. Se vor afișa:

• totalitatea funcțiilor publice • intrările și ieșirile funcțiilor • descriere a acestor funcții.

A doua funcționalitate constă într-un set de operații de interpretare a unor intrări, oferind răspuns fie produsul final Web 3.0, fie diferite structuri ale acestuia, în funcție de cerințele clientului.

Impreună cu aceste funcționalități principale, este util a se specifica și câteva obiective suplimentare, într-o listă care cuprinde toate obiectivele serviciului:

• independența de client, specific serviciilor web[15] • creeare/modificare site-uri web • afisează standarde de intrare/ieșire • set relativ redus de operații, limitate la generare totala/parțială

Capitolul 2

11

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 către alte aplicații Web 3.0. • în ceea ce privește parcurgerea altor aplicații Web 3.0 de către site, se va propune

un model rudimentar de căutare. Propunerea oferită are un rol exemplificativ, prezintă un nivel minim a ceea ce poate să

facă site-ul cu ceea ce a învățat. O altă caracteristică a site-ului este reutilizarea codului prin care a fost creeat. Odată

generat, site-ul va conține o copie a sa în formatul dat serviciului de interpretare. Această caracteristică are două consecințe importante.

• în primul rând utilizatorul poate să încarce formatul în aplicația de client serviciu spre modificare, apoi spre generarea produsului actualizat.

• a doua consecință se bazează pe existența unei copii de siguranță a produsului actual.

În ceea ce privește celelalte obiective, pentru o prezentare corespunzătoare a fiecărei funcționalități, obiectivele au fost împărțite în trei tipuri, în funcție de apartenența lor la un topic specific:

• obiective de Personalizare site, • obiective legate de platforme Web 2.0 și • obiective legate de memorarea/manipularea informațiilor.

2.2.1 Personalizare site

Site-ul are la bază identitatea utilizatorului, astfel aproape tot ce va conține va fi creat după preferințele sale.

• utilizatorul va decide asupra aspectelor vizuale, • site-ul va conține tipuri de formate generale, specificate în informațiile oferite de

serviciu. Aplicația de generare va citi preferințele utilizatorului, generând site-ul, dar activitatea de

personalizare este făcută în aplicația Editor. Cu toate acestea, produsul final va fi modificat, el va reflecta efortul creator al utilizatorului, astfel, capacitatea de a fi personalizat aparține site-ului, nu clientului. Utilizatorul va specifica:

• numărul de pagini, • cum sunt legate paginile între ele • conținutul paginilor • nivelul de acces al utilizatorilor externi la produs.

Este indicat ca orice modificare asupra conținutului site-ului, după generare, să fie făcută folosind serviciul de generare, pe baza copiei de siguranță oferită. Deși modificările 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

Capitolul 2

12

2.2.2 Platforme Web 2.0

Un al doilea obiectiv este unificarea aplicațiilor Web 2.0. Produsul final va trebui: • să permită conectarea la aplicațiile Web 2.0 folosite de către utilizator, • să păstreze o legătură 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 când și ce va apărea în conținutul site-ului. Odată accesate, informațiile provenite de la aplicațiile exterioare vor:

• intra în baza de date, • fi accesibile utilizatorului spre vizualizare/adaugare/stergere și • în urma unor prelucări, utilizatorul publică pe conținutul site-ului informația care o

consideră importantă. Conexiunea nu se rezumă doar la operația de citire, ci și la operația de scriere.

• utilizatorul va avea posibilitatea de a crea direct din cadrul site-ului. • aplicația posedă un număr minim de funcții de creeare/modificare/ștergere a

conținutului din aplicațiile exterioare. Controlul este foarte scăzut datorită nivelului strict al accesului oferit de către aplicațiile

Web 2.0. De asemenea site-ul trebuie să conțină opțiuni de conectare, permițând modificări

ulterioare. Acest caz este valabil pentru toate aplicațiile introduse în site. Dacă se urmărește o adăugare de aplicație, este necesar o nouă generare a site-ului pe baza copiei de siguranță.

Spre deosebire de caracterul de personalizare, platformele pot fi modificate fără o generare a conținutului întregului site. Atât site-ul cât și aplicațiile Web 2.0 își păstrează caracterul de independență.

Obiectivele care decurg din caracterul de unificare a aplicațiilor web sunt: • independența site – aplicații Web 2.0 • unificarea tuturor aplicațiilor Web 2.0 sub o singură platformă • posibilitatea de editare (creeare/modificare/stergere) în cadrul aplicațiilor Web 2.0

din site

2.2.3Memorare / Manipulare informații

Operația de memorare se realizează prin procesarea informațiilor primite de la aplicațiile Web 2.0. Se vor prelua informațiile principale și vor fi memorate într-o bază de date. Procesul de selectare se va face printr-un algoritm de selecție.

Operația de manipulare a informațiilor este mai complexă. Ea presupune două seturi de funcții:

• primul set este cel de citire a informației, preluare a ceea ce pare a fi relevant pentru utilizator, apoi ordonarea informațiilor în funcție de trecutul utilizatorului. Se va propune un mod de ierarhizare a importanței.

• al doilea set de funcții sunt cele care se preocupă cu prelucrarea informației. Acum site-ul va trebui să proceseze ceea ce primește iar, luand în calcul rezultatul primului set, să producă conținut relevant utilizatorului. Aplicația va consta în un ajutor de căutare on-line.

Capitolul 2

13

O caracteristică esențială a acestei funcționalități constă în caracterul permanent al acestei baze de date. În momentul schimbării /actualizării site-ului, conținutul bazei de date nu se va schimba.

Operațiile esențiale oferite de acestă funcționalitate se rezumă la: • prelucrare Web 2.0, memorare informații relevante • manipulare informației spre generarea unui conținut relevant utilizatorului • persistența bazei de date odată generate

2.3 Editor

Aplicația Editor are două funcționalități principale. • prima funcționalitate este de manipulare. Aplicația primește intrările de la

utilizator, le transformă într-un format pe care aplicația Generator le recunoaște și apoi afișează răspunsul acesteia.

• a doua funcționalitate este una de testare. Prin aplicația Editor se poate verifica disponibilitatea serviciului, se limitează intrările la Generator la cele pe care acesta le poate procesa și testează conținutul decurs din procesul de creeare.

Datorită celor două funcționalități, Editorul poate fi încadrat în tipul de aplicație 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 cunoștiințe despre web, mediul de dezvoltare trebuie să respecte conceptul “usability” – aplicația să fie folosită într-un mod ușor și de plăcut[18].

Mediul trebuie să permită importul de fișiere multimedia, dar nu prezintă un editor al acestora. Fișierele sunt atașate paginilor web prin poziționarea acestora în cadrul pagini.

Obiectivele principale se rezumă la: • ajutor creeare/editare/modificare pagini • apelare serviciu web/ verificare disponibilitate serviciu • publicarea unui rezultat parțial • respectă conceptele Web 3.0 / Semantic web

Capitolul 3

14

Capitolul 3. Studiu bibliografic

Parcurgerea obiectivelor din capitolul anterior, a relevat o serie de concepte și principii care au la bază studii bibliografice. Documentarea corespunzătoare asupra acestor principii și tot ceea ce reprezintă, este esențială în dezvoltarea corespunzătoare 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 importanța studiului bibliografic pentru proiect. Fiecare subcapitol va prezenta o serie de concepte, părerile unor experți în domeniu, exemple practice ale conceptelor, apoi legătura 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 desfășurat pe o perioadă îndelungată de timp, interval în care atât destinația sa cât și tipicul utilizatorilor săi s-a schimbat.

Unii experți au încercat să facă unele descrieri vizuale ale evoluției Internetului, ca Tim Burners-Lee – inventator WWW, el aseamănă evoluția Internetului unui om aflat în continuă creștere[4]. Alți autori, și nu puțini, aseamănă Internetul ca o evoluție 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 evoluția Internetului, dar nici una nu a fost la fel de bine acceptată ca teoria Web X.0. Deșii propusă de către Darcy DiNucci în articolul [19], ea a luat amploare după ce a fost promovată de către Tim O’Reilly în diversele sale publicații de la O’Reilly Media, exemplu articolul [6].

Secțiunile următoare vor prezenta câteva 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

Asemănător oricărui concept/teorie, nu toți specialiștii sunt partizani ai acestei noțiuni, dar pentru a putea expune părerile, trebuie întâi prezentată o definiție.

Conceptul Web X.0 cuprinde totalitatatea de stadii existente (Web 1.0, Web 2.0) și propuse (Web 3.0, Web 4.0) de către experții susținători ai acestui concept. El privește evoluția Internetului din punct de vedere al modului de folosință, nu din punct de vedere istoric. Tim O’Reilly definea în articolul său [20] „Web 2.0 este un set de tendințe economice, sociale și tehnologice care formează baza generației următoare a Internetului – un mediu caracterizat prin participația utilizatorului și deschidere”.

Pe parcursul promovării conceptului, au existat păreri care excludeau existența fenomenului Web 2.0. Majoritatea acestor păreri au o bază tehnologică. În clipa în care se pronunța 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 gândit de la bun început să fie un mediu colaborativ, astfel Web 2.0 pare a fi același lucru cu Web 1.0. Mai mult, Directorul de la W3C califica în anul 2006, într-un interviu către DeveloperWorks – IBM [22], Web 2.0 ca o „bucată de jargon, nimeni nici nu știe ce înseamnă exact”. Această părere parea a fi împărțită și de W3C.

Capitolul 3

15

O altă părere 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 săi. Alte păreri opuse Web 2.0, exemplu articolul [23], motivează inexistența conceptului datorită spectrului mult prea larg de aplicabilitate.

Susținătorul Web 2.0, Tim O’Reilly a răspuns în articolul [24] prin prezentarea conceptului în 7 capitole. El a cuprins ideile principale corespunzătoare noului concept prin comparație cu predecesorul său; articolul descrie diferențele dintre elementele Web 1.0 și Web 2.0, reliefând ideile specifice conceptului Web 2.0.

Un argument suplimentar și decisiv legat de existența și aplicabilitatea conceptului Web X.0, este dat de însuși 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 toți practicienii cât și de toți teoreticienii. Însuși Tim Berners-Lee, cel care a denumit Web 2.0 „o bucată de jargon”, a recunoscut la Conferința 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

Naşterea conceptului Web 1.0 este legat de Web 2.0. Înainte de teoritizarea făcută de Nancy DiNucci în articolul [19] a conceptului Web 2.0, nu se poate spune de existenţa lui Web 1.0. Într-adevăr, aplicaţiile Web 1.0 existau de mult timp, dar nimeni nu le-a calificat corespunzător.

Principiul Web 1.0 descrie aplicații de tipul top-down. Administratorii site-urilor publicau conținutul, utilizatorii doar vizualizau conținutul, nu puteau contribui în nici un fel. În articolul [26] Cormode G. descrie acest raport în următorul fel: “creatorii de conținut web erau puțini în Web 1.0, majoritatea utilizatoriilor jucau rolul unor simpli consumatori ai conținutului”.

O altă caracteristică este subliniată de Tim O’Reilly. El descria în articolul [24] aplicațiile Web 1.0 dependente de Software Release Cycle. Aplicațiile se modificau doar împreună cu un nou release, “softul nu se va ridica la aceeași performanță dacă nu este întreținut în fiecare zi” [24].

În cadrul aceluiași articol [24], Tim O’Reilly descrie targetul de site-uri folosite de tipul “head”: doar site-urile mari, sau cu trafic mare, primeau importanța. Acest efect s-a simțit în cadrul economic al WWW, exemplu paralela DoubleClick - Google AdSense.

O ultimă caracteristică esențială constă în pagini sărace din punct de vedere vizual. Site-urile 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 afișelor web pe suportul PC. În general conținutul Web 1.0 era destinat calculatoarelor.

Cateva elemente Web 1.0: • Scopul principal: expunerea informației • Arhitectură de tipul top-down • Software release cycle • Experiența utilizatorilor redusă la câte click-uri și mail

Cateva elemente constatate din practica Web 1.0:

• Pagini statice, lipsa de conținut dinamic • Practică de codificare specifica HTML prin: frameset-uri, butoane imagini GIF, elemente

ca <blink>,<marque> • Poziționarea elementelor în pagină folosind tabele HTML

Capitolul 3

16

3.1.3 Web 2.0

În opoziție cu Web 1.0 vine Web 2.0. Conținutul expus on-line nu mai este in mâna ofertanților ci în mâna consumatorului. Tim O’Reilly în articolul [6] descrie această trecere prin arhitectura în participație – 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 O’Reilly prezintă o lucrare de tipul magna carta a aplicațiilor 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 aplicațiile web nu mai trebuie să fie platforme bazate pe release cycle, ci aplicații serviciu care se modifică odată cu contentul oferit de utilizatori. Această părere este susținută în prezent de W3C. Într-unul dintre tutorialele sale, W3C susține “serviciile web duc aplicațiile web-based la următorul nivel”[27]. Această teză va fi prezentată în detaliu într-un alt subcapitol.

Valorificarea informației colective reprezintă al doilea tiltlu(capitol). Prin Web 2.0, utilizatorii creează o cantitate mai mare de informație, comparativ cu cea publicată de developeri. “[..]Contribuțiile utilizatorului [..]sunt cheia spre succes in era Web 2.0”[24]. Tim Berners-Lee pare a susține aceeași idee în interviul [22]. El susține un internet în care toată lumea contribuie, internetul așa cum a fost gândit de la început. Deși nu numește a fi cheia de succes, fondatorul WWW susține colaborarea utilizatorilor în produsul web.

A treia parte denumită generic: “Informația este următorul Intel Inside” se poate rezuma la citatul “SQL este noul HTML”[24]. Importanța unei baze de date care să conțină cât mai multe informații, fie ele adăugate de creatori, fie de utilizatori, este crucială în Web 2.0. Cu cât baza de date este mai completă, mai greu de reconstruit sau conține informații greu de găsit, cu atât 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 până acum, reprezintă punctul de plecare. Acestea vor fi modificate primind „semnificație”, aplicațiile vor înțelege conținutul ,nu vor vedea doar un set de date .

Titlul al patrulea vorbește despre finalul erei software release cycle. Acum aplicațiile trebuie să privească “utilizatori [asemenea unor] co-developeri” [24], numărul lor fiind mult mai mare ca developerii, cantitatea de conținut generat va crește proportional. Pentru a realiza acest scop este nevoie de aplicații care sunt într-o continuă schimbare, fără ca utilizatori să realizeze aceasta. Operațiile țin de nucleul aplicației. Acesta se modifică atât de developeri cât și de conținutul publicat de utilizatori. Exemplu Google Page Rank.

Următoarea parte vorbește despre modele de programare lightweight. Aceste modele consistă din componente vag legate între ele. Scopul acestei legături slabe este simplitatea cât și interoperabilitatea. Un exemplu oferit este REST în comparație cu SOAP.

Web 1.0 era gândit doar pentru calculatoare, titlul șase propune un software aplicabil mai multor dispozitive. Exemplu citat este iTunes. Această aplicație este specifică dispozitivelor Apple, care au în spate o aplicație masivă web.

Titlul final vorbește despre experiențe bogate ale utilizatorilor. Aceast concept se bazează pe un design mai atractiv, limbaje care permit o interactivitate mărită. Spre deosebire de predecesorul său, mediul vizual primește o imortanță deosebită.

Web 2.0 Design Patterns:

Capitolul 3

17

• The Long Tail[24] – site-urile mici reprezintă cea mai mare parte a internetului, astfel orice aplicație să se concentreze la site-urile mari și la cele mici

• Aplicațiile sunt data-driven – este importantă deținerea unei baze de date unice, o bază de date greu de recreat

• Utilizatorii adaugă valoare – utilizatori trebuie să se implice în adăugarea conținutului

• Drepturi rezervate – soft reutilizabil care aparține oricui • The perpetual Beta – aplicații î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ă înbunătățită: JavaScript, Ajax, Flash • Socializarea internetului prin interoperabilitatea aplicațiilor Web 2.0, Servicii Web • Necesitatea de generare cod reutilizabil oferit utilizatorului, exemple YouTube; Flickr;

sau chiar opțiuni de manipulare: Facebook, Twitter, etc • Limbaje predominante: HTML, XHTML, PHP, ASP, JSP

În secțiunea următoare se vor prezenta câteva 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ă comparație între Web 1.0 și Web 2.0 - Tabelul 3.1. Această prezentare simplistă prezintă esențialul diferențelor Web 1.0 – 2.0.

Tabelul 3.1 Web 1.0 Web 2.0

One–way Two–way Autoritar Democratic

Pasiv Activ Static Dinamic Închis Colaborativ

Toate comparațiile se bazează pe diferența din perspectiva utilizatorului. Prima prezintă cele două concepte asemănător comunicarii dintre două persoane. One way - sunt aplicațiile în care utilizatorul nu poate adăuga conținut, doar să vizualizeze – asemănător unui monolog. Two-way este dialogul Web, utilizatorul poate citi și adăuga conținut.

Celelalte comparații sunt legate de prima. Web 1.0 este autoritar și static datorită rigidității sale, pe când Web 2.0 este democratic și dinamic, permite și utilizatorului să participe la creearea conținutului.

Choise Media Group,Vovici, într-un webcast[29], a prezentat clasificarea după Tabelul 3.2. Această comparație repetă și completează cea făcută de Jeffrey Henning.

Tabelul 3.2. Web 1.0 Web 2.0

Conținut Read-Only Conținut generat de utilizator Ochi Maini

Stickiness Syndication Editor Buzz

Pagini Personale Blog Centralizat Croudsourcing

Capitolul 3

18

Prima comparație, împreună cu doua, repetă prezentarea diferențelor dintre concepte din prisma utilizatorului, singura diferență constă în modul de exprimare. A doua comparație prezintă într-o manieră artistică ceea ce a fost expus în prima comparație.

Raportul Stickiness/Syndication reprezintă caracterul Rigid/Flexibil corespunzător celor două concepte. Stickiness reprezintă inflexibilitatea aplicațiilor Web 1.0 în opoziție cu flexibilitatea aplicațiilor Web 2.0. Aici Syndication nu se referă la RSS feed.

Diferența Editor/Buzz se rezumă la modul de publicare a conținutului a două aplicații specifice conceptelor din care faceau parte. Editor – publica informațiile oferite de autor, dar nu permitea adăugarea de conținut din o sursă exiterioară. Buzz(Google) era o rețea de socializare în carea utilizatorii puteau face schimb de informații. Ambele servicii nu mai sunt disponibile astăzi.

Diferența pagini personale/blog este una de conținut. Ambele permit unui utilizator să publice informații, diferența este din perspecitva cititorului. Asemănător cu deosebirea principală intre Buzz/Editor, utilizatorii pot adăuga păreri legate de articolele publicate doar pe Blog, nu și în cadrul Paginilor personalizate.

Este importantă următoarea mențiune: paginile personalizate, din comparația 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 comparație este la nivelul dezvoltatorilor. În Web 1.0 dezvoltatorii conținutului aplicațiilor Web erau doar programatorii care publicau aplicația. Spre deosebire de predecesorul său, acum consumatorii produsului Web 2.0 devin și ei dezvoltatori ai conținutului (co-developeri)[24].

Croudsourcing înseamnă externalizarea unui serviciu către un grup de specialiști sau comunitate sub forma unei competiții de dezvoltare. Diferența croudsourcing/outsourcing constă în publicul la care este predat. Croudsourcing se aplică unui public nedefinit.

Tim O’Reilly, în lucrarea sa [24], a formulat câteva exemple Web 1.0 – Web 2.0. Aceste exemple stau la baza celor șapte principii enunțate. Tabelul 3.3 corespunde lucrării [24] și conține exemple de aplicații 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 informației algoritmice trebuie să se întindă peste tot web-ul, până la margini, nu doar la centru, la coada sa lungă, nu doar la cap”[24]. DoubleClick era un model care susținea: cei care făceau promovarea făceau regulile, iar publicitatea era dedicată doar celor mari. Vizitatorii se orientau în general spre aceste pagini.

Capitolul 3

19

Succesul Adsense a constat în posibilitatea de a publica pe orice pagină advertisements și spre deosebire de predecesorul său, nu necesita un contract de vânzări. Acum publicitatea nu apare doar pe site-uri mari, ci poate apărea pe orice site.

Diferența Akamai/BitTorrent este una crucială. Ambele servicii se ocupă de transferul de fișiere către utilizatori. Diferența între cele două era modul de transmisie. Akamai oferea fișierele de pe serverele lor, pe când BitTorrent se folosea de arhitecturi în participație [6]. BitTorrent se folosea de ideea lui Tim Berners-Lee, o aplicație devine mai bună cu cât mai mulți utilizatori participă la ea. În cazul în care serverele devin suprasolicitate, cei de la Akamai trebuiau să adauge alte servere, pe când la BitTorrent o supraîncărcare pare greu posibilă datorită participației utilizatorilor atât la download cât și la upload. Același argument este revelator în comparația Mp3.com/Napster.

Comparația între cele două enciclopedii Online Britannica Online/Wikipedia este asemănătoare cu cea Akamai/BitTorrent. Deși Britannica produce articole mai relevante/prețioase decât Wikipedia, Britannica nu va putea niciodată produce o cantitate mai mare de articole ca Wikipedia, datorită numărului de editori/utilizatori. Comparația dintre cele două e asemănătoare cu One-Way/Two Way a lui Jeffrey Henning.

În această comparație Web 2.0 pare a fi în dezavantaj datorită raportului cantitate/calitate. La o primă vedere așa este, dar cu un număr tot mai mare de contribuitori la mediul Wikipedia, calitatea începe să crească odată cu cantitatea. Nivelul de utilizatori/creatori de conținut Wikipedia este în continuă creștere. Site-ul [40] conține informații suplimentare pe acest subiect.

Diferențele între publishing/participation; personal websites/blogs; Ofoto/Flickr; Screen Scraping/WebServices, sunt parcurse în mare în paragrafele anterioare. Diferențele 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, mulți experți au propus diverse opinii în ceea ce privește 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 greșită. Primele două stadii nu se rezumă doar la un singur concept sau idee de dezvoltare. Web 3.0 trebuie să fie asemănător predecesorilor lui, asimilând o serie de concepte sub o singură siglă.

Dintre toate aceste teorii, cele mai des întâlnite 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) Informația ș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 lângă aceste opinii, există și alte speculări, cum ar fi [35] în care Web este văzut în

rolul unui nou TV. Sti International, în proiectele sale aflate sub sigla „The Future of the Internet” [36], vorbește despre un internet în care toate dispozitivele sunt interconectate între ele (PC,TV, aparate electrocasnice, etc.), un internet al lucrurilor. Există și alte concepte susținute de alte înterprinderi sau alți academicieni, dar cele enumerate mai sus sunt cele mai citate.

Capitolul 3

20

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 spațiu imens de informații, în care vei avea acces la o cantitate incredibilă de resurse”.

Această părere este împărtășită și de alți experți, în prezent, majoritatea practicienilor cât și teoreticienilor susțin aceeași 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 direcții 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 aplicațiilor web. SVG este o familie de specificații, bazate pe XML, pentru descrierea imaginilor, statice sau dinamice, într-un spațiu 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. Apartenența lui la Web 3.0 se explică prin abundența în practică a acestui format, spre deosebire de predecesorii săi Web.

Inteligența artificială va avea o importanță majoră în experiența online. Aplicațiile Web

3.0 trebuie să fie capabile să efectueze seturi de sarcini specifice utilizatorului. Fie aplicația va citi profilul utilizatorului [7], fie va face operații pentru utilizator, fie aplicația va genera content[31], domeniul de aplicabilitate va fi foarte mare. Un lucru este sigur, web 3.0 va introduce Inteligența 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 aplicații care localizează și generează modele 3D. Unele păreri merg mai departe, Internetul va fi în 3D. Această părere pare plauzibilă datorită efortului interprins de dezvoltare a unei alternative OpenGL, denumită WebGL[36]. Această platformă scrisă în AJAX permite aplicațiilor care folosesc OpenGL să ruleze în interiorul browserului.

Informația și modul său de foloisință. Reid Hoffman, cofondator LinkedIn, a prezentat

într-o conferință [37] importanța informației și modul cum va circula on-line. Web 3.0 va conține toată informația produsă de 2.0, împreună cu informații analitice[37]. Această informație trebuie clasificată după importanța sa, procesată, iar din ea se va genera noul conținut. Acum aplicațiile vor contribui la conținutul 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 aplicațiile web nu doar afișează informații ci și interpretează. Tim Berners-Lee descrie Semantic web în cartea sa [38] – “un web de informații care poate fi procesat direct sau indirect de către mașini”.

James Hendler în articolul [39] descrie Semantic Web: “scopul acestei noi tehnologii este dezvoltarea comunicării între oameni, folosind diferite terminologii care extind interoperabilitatea bazelor de date, care să furnizeze instrumente pentru interactivitatea cu colecțiile multimedia și să asigure noi mecanisme pentru suport al științei”. Tot în acest articol el scrie: “Pentru a ajunge la acest potențial, oamenii de știință și inginerii tehnologiei informației

Capitolul 3

21

trebuie să creeze noi modele de cooperare[…] pentru noua generație de instrumente științifice pe Web”.

Semantic Web propune un internet care se bazează pe cunoștințe – collection of knowledge[38]. El va permite utilizatorilor să adauge ceea ce cunosc, aplicațiile să înțeleagă și să răspundă la diferite întrebări.

W3C definește, pe site-ul oficial [42], Semantic Web ca “o extensie a World Wide Web, care permite utilizatorilor să împartă informații dincolo de limitele aplicațiilor și website-urilor”. El este descris ori ca un “web of data”, fie un “salt spre o paradigmă naturală în folosința 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 către Web 2.0 vor fi utile în dezvoltarea noului Internet. Pe baza unor legături semantice, se va genera conținut nou din cel vechi. Informația generată trebuie să fie într-o formă structurată de date, va fi editată în așa fel încât să poată fi citită atât de utilizatori cât și de aplicații.

Tot în site-ul [42], Semantic Web primește 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 definește [...] 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 păreri 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 așa cum a fost prezentat de Tim Berners-Lee în 2000 Structura prezentată de Arhitectura Semantic Web trebuie analizată bottom-up. Prima

parte conține unicode și URI împreună cu XML și xmlschema. Descrierea elementelor specifice acestui nivel se bazează pe definițiile 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 rețea. Aceste două componente se ocupă de identificarea elementelor pe Web printr-o codificare adecvată.

XML este un limbaj de descriere a datelor, ușor inteligibil atât aplicațiilor cât ș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 corespunzător

Capitolul 3

22

pentru codificarea semanticii, datorită practicii asociate cât și ușurinței de manipulare a formatului.

RDF – Resource Description Framework se bazează pe o triplă de informație, formată din: un subiect, un obiect și verbul/predicatul care leagă cele două. Subiectul și Obiectul reprezintă resurse care dețin propria identitate. Această identitate este descrisă individual în resurse descriptive, printr-un URI.

Legătura dintre resurse este realizată printr-o descriere. Aceasta este un container care conține câteva afirmații despre resursă.

Exemplu 3.1,Tripla: Ana are mere, grafic:

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 definește un namespace pentru relația

„are”; se specifică legătura cu resursa „mere”. Subiectul și descrierea (predicatul) sunt de regulă reprezentate prin URI. Obiectul este fie

un alt URI, fie un string sau un număr. 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 definește clase, obiecte și predicate împreună cu anumite reguli specifice fiecăruia.

RDF + rdfschema reprezintă setul de reguli care trebuie respectate, oferind o structură de siguranță pentru dezvoltarea semanticii.

Ontologia este un model folosit pentru repezentarea informației, un set de concepte dintr-un domeniu, și modul cum relaționează reprezentările. 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 condiție este unicitatea termenilor descriși în clase.

Scopul ontologiei este de a crea relații din schemele descrise de RDF, împreună cu crearea altor relații (subiecte/predicate/obiecte). Ontologia prezintă următoarele caracteristici:

• formate din triple, asemănător cu RDF • ușor de extins – definirea unei triple noi formează o relație nouă • prin modificarea semnificației subiectelor/predicatelor/obiectelor nu se modifică

ontologia • alternative excelente la cod sursă – ontologia este mai ușor de modificat • adaptabilitate

Logica se formează din ontologie și conține toate relațiile formate. Proof reprezintă totalitatea de legături formate la cerere sub forma unei query.

Ana mere

are

Subiect Obiect

Descriere

Capitolul 3

23

Trust reprezintă nivelul de încredere în resursa respectivă. Acesta se pot prelua din diverse servicii on-line. Nivelul de încredere favorizează o legătură semantică față de alta.

Scopul Semanticii Web este de a oferi un înțeles, din perspectiva dispozitivelor/aplicațiilor, a datelor publicate. În urma realizării acestui concept, aplicațiile vor fi capabile să răspundă la întrebările formulate în limbaj natural.

În prezent, W3C susține un efort de promovare și recomandare Semantic Web.

3.1.5 Web 4.0

Deși o discuție 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 adăugate.

Web 4.0 poate fi doar un subiect de speculație. Din acest motiv orice direcție de dezvoltare propusă este fie una progresistă, în care se prezintă aplicații web în curs de dezvoltare, ca fiind parte din o nouă generație, fie una tenedentială, o direcție î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 rețea, o placă video care să proceseze semnalul trimis împreună cu un porcesor care să efectueze un set minim de operații. Un astfel de sitem de operare va înlătura necesitatea schimbării PC-ului datorită creșterii criteriului de performanță. Această părere este susținută de Ray Kurzweil[45] și Nova Spivack[46].

Web 4.0, pe criteriu tendențial, arată dezvoltarea internetului într-o anumită direcție. O astfel de părere este un Web inteligent, capabil de reasoning. Stadiul Web 3.0 face aplicațiile web capabile să gândească. 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 conține „un web al lucrurilor” în care toate operațiile vor fi făcute cu comenzi vocale în limbajul natural uman, prin intermediul Internetului.

Legătura Concept Web X.0 – Proiect este una evidentă. Aplicația 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 aplicații conțin mecanisme care generează cod pentru utilizator [47]. În general, astfel de practici sunt asociate unor aplicații care au la bază segmente de cod reutilizabil.

James Wilcox, în articolul [48], descrie - generative programming ca „un stil de programare care folosește cod sursă automat, generic, bazat pe frame-uri, clase, prototip, template-uri care să înbunătățească productivitatea programatorului”.

Generatoarele de site-uri sunt undeva la mijloc între aceste două tipuri de dezvoltare. Aplicațiile generatoare de cod trebuie să dezvolte, prin programare automatică, site-uri, folosindu-se de codul sursă generat prin generative programming.

Tipicul de utilizator care folosește aplicații scrise după cele două modele de programare sunt dezvoltatorii. Aplicația generatoare de site-uri, deși oferă suport și pentru cunoscători, este dedicată unui mediu mai larg, unor profani în domeniul programării.

Numărul de lucrări 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, operațiile oferite, etc.

Capitolul 3

24

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 aplicații a fost, de la bun început, unirea câtor mai multe standarde W3C sub un singur editor.

Legătura 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 aplicații independete, create cu scopul de a rezolva taskuri specifice, oferite către alte aplicații la cerere. Aceste servicii reprezintă o modalitate standard de integrare a diferitelor aplicații 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 aplicațiilor web folosind web service. Această metodă permite conversia aplicațiilor statice în aplicații Web-based folosite prin intermediul Internetului, LAN sau WAN.

Tim O’Reilly descrie, în articolul [24], Aplicațiile web service ca fiind parte dintr-un nou Internet. Spre deosebire de Web 1.0, aplicațiile 2.0 se vor folosii de operații oferite de servicii web pentru a prezenta compusul final.

Modul de folosire a Serviciilor Web este descris prin Service Oriented Arhitecture (SOA). Această arhitectură conține principiile și metodologiile pentru proiectarea și dezvoltarea softului în forma unor aplicații interoperabile. Arhitectura SOA nu se reduce doar la dezvoltarea serviciilor Web, ci conține principii privind integrarea lor în diferite aplicații.

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 reprezentării resurselor Web bazate pe XML, folosind un set uniform de operații stateless. A doua variantă este denumită Arbitrary Web Service în care serviciul expune un set de operații arbitrare” [49].

Arhitectura de funcționare a unui Web Service Arbitrar:

Serviciile Web arbitrare prezintă trei actori: Service Brooker, Service Provider și Service

Requestor. Fiecare dintre actori comunică unul cu celălalt 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 funcționare a arhitecturii Serviciilor Web:

Service Broker are un singur scop, publicarea existenței serviciilor. Service Provider descrie funcționalitățiile sale Brokerului în formatul WSDL. Service Broker va publica informațiile specifice serviciului în format UDDI, Universal Description, Discovery and Integration, dar interogarea Service Requestor-lui este realizată prin WSDL.

Service Requester

Service Provier

Service Broker

SOAP

WSDL WSDL

Capitolul 3

25

Service provider este Serviciul Web. El oferă informații către Broker despre funcționalitățile sale. După tipul de descriere UDDI, aceste informații conțin trei componente[50]:

• White Pages – oferă informații 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 hotărât să utilizeze serviciul oferit de Provider, Requestorul va face schimb de mesaje de tip SOAP cu Providerul. Aceste mesaje vor conține informațiile specifice intrărilor/ieșirilor serviciului.

Mesajul SOAP – Simple Object Access Protocol reprezintă o modalitate de codificare a obiectelor/variabilelor/intrărilor/ieșirilor în formatul XML. Structura sa prezintă un Envelope care conține doi copii: Header și Body.

SOAP header, opțional, este folosit pentru descrierea unor informații legate de aplicație, exemplu: informații legate de calea de transmitere. SOAP body, obligatoriu, conține informații pentru destinatarul mesajului. SOAP fault, aparține 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 simplității modelului arhitectural.

Arhitecturile REST comunică prin resurse stateless. Ele folosesc protocolul HTTP, interfața mesajelor este constrânsă în formatul operațiilor standard HTTP (GET,PUT,DELETE, etc.). Spre deosebire de arhitecturile care folosesc SOAP sau WSDL, arhitectura REST nu folosește neaparat formatul WSDL.

Aplicațiile 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 aplicații - comunică folosind protocoluri deschise - self-contained, self-describing, independente - se descoperă folosind UDDI - pot fi folosite de către alte aplicații - XML este baza Serviciilor Web Serviciile web, arhitectura SOA și variantele de arhitecturi de implementare a serviciilor

web sunt recomandări W3C din anul 2003. Necesitatea fundamentării Web Service – Proiect este bazată pe o componentă descrisă în

capitolul anterior – Serviciul Generator Web 3.0.

3.4 Social Dashboards

Unificarea tuturor aplicațiilor Web 2.0 de socializare, sub o singură platformă, este realizată de aplicații denumite „Social Dashboards”. Utilitatea acestor platforme constă în ușurința de manipulare a informațiilor primite de la diferitele aplicații Web 2.0, elmininând factorul de conectare și verificare individuală.

Pentru construcția unui dashboard este nevoie de parcurgerea anumitor informații oferite de către produsele Web 2.0. Justin Cutroni, membru Google Analytics a expus, în prezentarea sa [52], câteva „dimensiuni și metrici” specifice aplicațiilor dashboard:

Capitolul 3

26

• Data Hub Activities – totalitatea activitățiilor din rețelele sociale reprezintă o platformă deschisă de informații; conține totalitatea activitățiilor pentru un site

• Social Network – totalitatea rețelelor de socializare care permit transmiterea traficului către un site

• Social Source Referral – verificarea informațiilor primite dacă provin de la o sursă de trafic socială

• Social Source & Action – acțiunile specifice rețelei de socializare • Social Entity – URL-ul împărțit pe social media • Social Type – tipul de site social

Aceste informații trebuie luate în vedere în momentul integrării unei aplicații de socializare în Dashboard.

În ceea ce privește activitatea oferită de un dashboard, prezentată tot în articolul [52], există o clasificare în trei tipuri de activități: activitate off-site, activitate on-site și conversații/rezultate.

Activitatea off-site reprezintă setul de funcționalități disponibile utilizatorului în clipa lipsei de conexiuni cu servicul Web 2.0, împreună cu funcționalitățiile exterioare manipulării acestor aplicații.

Scopul principal al aplicației dashboard este activitatea on-site. Operațiile de creeare/modificare/ștergere a conținutului aplicațiilor web 2.0 reprezintă funcționalitățile on-site.

Conversații/rezultate reprezintă acea parte a aplicației în care se leagă diversele platforme împreună. Conținutul din o aplicație 2.0 trebuie să poată fi publicat în interiorul altei aplicațiii 2.0.

Necesitatea prezentării unor elemente teoretice despre social dashboard este folositoare în

analiza necesară alegerii aplicațiilor incluse în aplicația dashboard.

3.5 Data mining

Cunoscută sub denumirea de Knowledge Discovery in Databases, Data Mining este o disciplină a științei calculatoarelor care procesează informații din seturi de date. ACM – Special Interest Group on Knowledge Discovery and Data Mining, în curiculum său[53], descrie această disciplină: „se află la intersecția inteligenței artificiale, machine learning, statistici și a bazelor de date” .

Scopul acestei științe este extragera informației dintr-un set de date. În articolul [54] Procesul de Knlowledge Discovery în baze de date este definit a avea 5

etape: • Selecție • Preprocesare • Transformare • Data Mining • Interpretare/Evaluare

În etapa de selecție se alege aplicația și informația din cadrul aplicației. Pre-pocesarea este succesivă selecției, în care se alege o cantitate de informație care

urmează să fie supusă procesului de Mining. În această etapă se elimină informațiile care „conțin zgomore sau prezintă informații incomplete”.

Transformarea este etapa în care datele specific unui limbaj sunt transpuse în mediul limbajului de data mining.

Data Mining conține șase seturi de clase[54]: • Detectarea de anomali – date care pot fi considera neobișnuite sau prezintă erori

Capitolul 3

27

• Învățarea bazată pe reguli – caută legături între variabile • Clustering – se caută grupuri și structuri de informații. • Clasificare – metodă prin care se aplică structura învățată în seturi noi de date • Regresie – etapa în care se caută o funcție specifică setului de date • Sumarizare – generarea reprezentării setului de date în diferite formate cerute de

utilizator Ultima etapă, de interpretare/evaluare este una de testare finală. În funcție de ce s-a

generat prin procesul de Data Mining, se vor testa rezultatele pe seturi mari de date.

Necesitatea prezentării unor elemente fundamentale legate de data mining este una de informare. Aplicația va propune un algoritm de căutare fundamentat în prezentul sub-capitol.

Capitolul 4

28

Capitolul 4. Analiză şi fundamentare teoretica

Capitolele anterioare prezintă obiectivele urmarite de proiect, apoi cateva studii care stau la baza dezvoltării prezentei aplicații. Prezentul capitol va oferi o analiză a cerințelor funcționale și non-funcționale împreună cu o descriere a arhitecturii proiectului.

Cerințele funcționale și non-funcționale vor fi prezentate la nivelul fiecărei componente a proiectului. Dacă este cazul, se vor face mențiuni referitoare la conceptul Web care fundamentează o cerință. Cerințele vor fi clasificate după modelul propus de Ian Sommerville în prezentarea [55].

Arhitectura aplicației va fi prezentată pe baza celor trei componente descrise anterior, împreună cu motivul separației proiectului în trei aplicații 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 cerințe impuse. Capitolul 3 a prezentat conceptele care sunt invocate în analiza și dezvoltarea proiectului, urmând ca acum să fie prezentată tema proiectului în detaliu împreună cu analiza proiectului.

Tema proiectului cuprinde patru cerințe principale, descrise în forma unei cerințe utilizator[55] în limbaj natural :

• proiectul este o aplicație Web care oferă mijloace de creeare/editare a unui site • aplicația trebuie să prezinte un minim de instrumente prin care se permite

conectarea la rețelele de socializare. • site-ul generat permite adăugare de conținut în cadrul paginilor prin rețelele de

socializare • aplicația trebuie să respecte standardele Semantic Web cu posibilitate de stocare

de date Pe lângă aceste cerințe utilizator, se mai adaogă câteva cerințe sistem legate de aplicația

Web descrisă de proiect: • trebuie să aibă la baza conceptele Web 2.0 și 3.0 • trebuie să suporte fișiere standard HTML • trebuie definit un standard de codificare

Împreună cu aceste cerințe, este util specificarea unor cerințe non-funcționale suplimentare, specifice proiectului în ansamblu:

• robustețe – aplicația trebuie să se facă față probabilelor erori generate, tehnici care asigură folosirea intrărilor corespunzătoare

• accesibilitate – aplicația să fie accesibilă unui număr mare de utilizatori • disponibilitate – aplicația să fie disponibilă oricând utilizatorul dorește să o

folosească • backup – aplicația prezintă metode care ajută la restabilirea într-un stadiu

precedent, în caz de nefolosire • extensibilitate – principiu de design, implementarea este creată în așa fel încât să

fie pregătită pentru o probabilă modificare viitoare • mentenabilitatea – ușurință în determinarea unor defecte, îndeplinirea unor noi

sarcini • compatibilitate cu un număr mare de platforme

Capitolul 4

29

• portabilitate – posibilitatea de a utiliza aplicația în mai multe medii • posibilitatea de executare în cazul unor resurse limitate

Aceste cerințe se aplică pe ansablul proiectului, urmând a fi enunțate la nivelul fiecărei componente.

4.2. Analiza componente

Pe baza cerințelor funcționale afișate, împreună cu alte motive prezentate în prezentul subcapitol, se observă trei categorii de cerințe:

a) cerințe legate de site-ul generat b) cerințe de procesare a intrărilor în cod c) cerințe legate de editarea site-ului

Urmărind fiecare set de cerințe, se poate observa independența fiecărui set, astfel, există posibilitatea dezvoltării aplicației în trei componente independente. Prima componentă reprezintă produsul generat – Site-ul Web 3.0. A doua componentă este o aplicație care prelucrează intrările oferite de către utilizator și produce prima componenta - Generator. A treia componentă joacă rolul unui editor care manipulează intrările utilizatorului și trimite informația spre generare/creearea/modificare a site-ului - Editor.

Separația proiectului în componente se dovedește a fi utilă din mai multe motive: 1. Componentele sunt creeate în așa fel încât să respecte conceptele Web X.0.

Exemplu: Web 2.0: • arhitectura în participație – Site; • software oriented arhitecture – Generator, Editor; • aplicații data-driven: Site, Generator; • perpetual beta: Site,Generator,Editor; • limbaje orientate spre o grafică înbunătățită: Site,Generator,Editor; • cod reutilizabil:Site,Editor; • caracter democratic al conținutului 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. Cerințele non-funcționale ale componentelor: • Certificare – acreditarea aplicației de către o sursă exterioară –Site • Conformitate – definirea unor standarde de intrare specifice doar în procesul de

editare – Editor • Independența – fiecare componentă este independentă de cealalaltă • Mentenabilitatea – fiecare componentă este mai ușor de verificat/modificat • Extensibilitate – componentele se pot modifica fără ca utilizatorul să cunoască,

principiu legat de perpetual beta Web 2.0; • Documentare – doar o componentă are intrări stabilite pe baza unei documentații,

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 mărite fără ca celelalte să fie modificate

3. Cerințele funcționale:

Capitolul 4

30

• Fiecare componentă prezintă un set specific de cerințe funcționale • Componentele sunt dezvoltate/verificare independent • Independența componentelor; ele pot fi folosite și de către alte aplicații în cadrul

setului de cerințe specificate Fiecare din aceste cerințe funcționale/non-funcționale vor fi prezentate la nivelul fiecărei

componente. Următoarea etapă în dezvoltarea proiectului este analiza, în detaliu, a componentelor prin prezentarea tuturor cerințelor specifice.

4.2.1 Site-ul web

Produsul final a Generatorului și Editorului este Site-ul Web 3.0. El trebuie să realizeze un număr sarcini limitate la operații de scriere/afișare a conținutului și ar trebui să prezinte operații de manipulare a informațiilor.

Sarcinile sunt definite la nivelul fiecărei pagini Web, în cadrul operației de editare de către utilizator. Autorul va creea un număr de pagini particulare, apoi va adauga posibilități de editare a conținutului din surse exterioare.

Site-ul va conține și o zonă rezervată autorului în care va putea edita numarul de pagini. Operația de ștergere este limitată la nivelul paginii sau a conținutului din pagina; operația de adaugare este limitată la clonarea unei pagini, urmată de o modificare a acesteia; operația de modificare este limitată la modificarea conținutului text/poze/video din pagina.

Acestea sunt aspectele principale ale componentei Site-ului descrise sub forma unor cerințe generale. Cerințele specifice care decurg din analiza cerinței generale vor fi prezentate în subcapitole individuale.

4.2.1.1 Cerințe funcționale

Izvoarele cerințelor funcționale pot fi grupate după mai multe criterii: cerințe utilizator – cerințe propuse de potențialul utilizator, cerințe conceptuale – cerințe care pornesc din conceptele Web X.0 și cerințe sistem – reguli/constrângeri legate de modul de execuție a aplicației ,

Cerințe utilizator : • trebuie să afișeze informațiile pe care utilizatorul le oferă • trebuie să ofere un suport de fișiere minimal • ar trebui să permită verificarea/editarea conținutului de pe alte pagini/servicii Web

2.0 • trebuie să conțină o copie de bază în formatul folosit pentru generator • trebuie să permită o clasificare a publicității informațiilor

Cerințe conceptuale: • trebuie să permită adăugare de conținut de către utilizatorii externi - pagina în

participație Web 2.0 – caracter opțional la nivelul fiecărei pagini • trebuie să respecte conceptul Semantic Web • grafică superioară formatului Web 1.0 – Web 2.0 • trebuie să rețină informații primite de la aplicațiile exterioare, apoi să genereze

anumite informații suplimentare – data-driven Web 2.0/3.0 o obiectiv memorare/manipulare informații o obiectiv platforme Web 2.0

• perpetual beta: site-ul este în continuă modificare prin adaugare/editare de pagini de către utilizator

Cerințe sistem:

Capitolul 4

31

• permite logare prin surse exterioare; doar deținătorul site-ului are posibilitatea de logare

• editarea conținutului este limitat; conținutul adaugat de către proprietarul site-ului se poate modifica doar de către proprietar, restul de orice persoană

• cerințe generale legate de paginare în cadrul site-ului:

4.2.1.2 Cerințe ne-funcționale:

În categoria acestor cerințe se vor prezenta cerințele ne-funcționale împreună cu exemplificarea rolului fiecărui concept. Cerințele vor fi prezentate după caracterul global sau particular în relație cu proiectul.

Cerințe ne-funcționale globale: • robustețe – intrările se rezumă la conținutul adaugat de către utilizatorii externi

împreună cu conținutul adăugat de către proprietar. Erorile sunt verificate la nivelul utilizatorului extern prin filtrarea conținutului; erorile de intrare a proprietarului sunt limitate de către operația de generare

• accesibilitate – aplicația este accesibilă unui număr mare de utilizatori datorită postării sale pe Internet

• disponibilitate – aplicația este disponibilă atât timp cât hostul este disponibil; relativ 99,8%, standard de hosting

• backup – site-ul va conține o copie a sa în formatul trimis către generator, accesibil doar proprietarului

• extensibilitate – aplicația este în continuă modificare datorită adăugării de conținut de către utilizatori

• mentenabilitatea – ușurință în îndeplinirea unor noi sarcini, determinarea unor defecte; se realizează datorită partajării informației în pagini Web

• compatibilitate cu un număr mare de platforme – orice browser care implementează standardele cerute de cerințele funcționale

• portabilitate – aplicația se poate folosi de pe orice mediu care suportă un browser de internet

• posibilitatea de executare în cazul unor resurse limitate – aplicația folosește un număr limitat de resurse

Cerințe ne-funcționale particulare:

• Certificare – acreditarea este realizată de către standardul W3C • Independența – odată generat, site-ul nu va mai folosi celelate componente în buna

sa funcționare • Mentenabilitatea – site-ul este ușor de modificat de către proprietar fie prin o nouă

generare, fie prin editare a fișierelor particulare • Inter-operabilitate – aplicația nu este legată de celelalte componente dar este inter-

operabilă cu aplicațiile Web 2.0 folosite • Scalabilitate – parțial adevărată în cadrul site-ului, adevărat în cadrul conținutului

adăuga de către exterior, fals legat de conținutul adăugat de proprietar; se prezumă un nivel redus de cunoștiințe în programare pagini web a proprietarului, este recomandabilă o nouă generare în cazul de adăugare pagini

Capitolul 4

32

4.2.1.3 Cerințe specifice domeniului problemei:

Acest tip de cerințe sunt legate de caracterul on-line al aplicației. Spre deosebire de cerințele prezentate anterior, acestea au la bază factorul uman de eroare sau intenție de modificare a conținutului într-un mod abuziv

• aplicația ar trebui să prezinte o posibilitate de eliminare a activității de tip spam • site-ul ar trebui să ofere o posibilitate de ștergere a conținutului de către utilizatorii

externi • alte cerințe care pot face aplicația să fie folosită în scopuri abuzive

4.2.2 Generatorul Web

Scopul aceste aplicații este transformarea intrarilor oferite de utilizator în site-ul Web. Intrările vor fi verificate, pe baza standardului cerut în documentație, apoi transpuse în tipurile de fișiere cerute. Ieșirea va fi formată dinr-un set de pagini Web 3.0 împreună cu resursele cerute.

Această componentă este încadrată în tipul de aplicație “Generatoare de Site-uri” descrisă în capitolul anterior. Apartenența în această categorie prezintă o serie de cerințe suplimentare. Acestea sunt prezentate împreună cu cerințele generale în următoarele subcapitole.

4.2.2.1 Cerințe funcționale

Asemănător cu capitolul anterior, cerințele funcționale vor fi clasificate după izvorul lor: cerințe utilizator, cerințe conceptuale, cerințe sistem.

Cerințe utilizator: • transformă dintr-un format prestabilit în fișierele corespondete ale site-ului • trebuie să ofere opțiuni de dezvoltare • aplicația prezintă un set de operații de afișare și unul de generare • trebuie să poată să fie folosită din mai multe medii

Cerințe conceptuale: • arhitectura orientată pe servicii – Web 2.0 • componentă refolosită de către diversele aplicații exterioare – Web 2.0 • arhitectură în participație – posibilitate de participare la dezvoltarea aplicației prin

notificarea de către utilizatorii exteriori de eventuale soluții la diverse erori apărute – Web 2.0

Cerințe sistem: • sistemul permite oricui apelarea funcției de generare • sistemul permite opțiuni de feedback prin un set de funcții specifice • doar administatorul are drepturi de vizualizare feedback • trebuie să existe o posibilitate de notificare a schimbărilor către utilizatorul care o

cere

4.2.2.2 Cerințe ne-funcționale

Cerințe ne-funcționale generale: • robustețe – standardul de intrare asigură lipsa posibilității unei erori exterioare;

erorile interioare sunt tratate înainte de publicare a serviciului • accesibilitate – asemănător cu cumponenta anterioară, generatorul este postat on-

line, fiind accesibilă prin intermediul Internetului • disponibilitate – aplicația să fie disponibilă oricând utilizatorul dorește să o

folosească

Capitolul 4

33

• backup – aplicația 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 – independența față de orice alte componente ceează posibilitatea unei corectări permanente

• compatibilitate cu un număr mare de platforme • portabilitate –componenta trebuie să folosească un protocol care să permită un

spectru larg de aplicații care o pot apela • posibilitatea de executare în cazul unor resurse limitate

Cerințe ne-funcționale particulare: • Independența – fiecare componentă este independentă de cealalaltă • Documentare – această componentă oferă o documentație asupra intrărilor și

ieșirilor; standardul de intrare • Inter-operabilitate – aplicația trebuie să fie interoperabilă cu orice componentă

care o aplează • Scalabilitate – aplicația este gândită pentru un număr mare de utilizatori

4.2.3 Editorul de Site-uri

Această componentă preia informațiile oferite de către utilizator și le transpune în formatul cerut de către generator. Asemănător unei aplicații de tipul editor, ea trebuie să permită adăugarea/editarea de componente suportate de către generator. La sfârșitul operației de creeare a utilizatorului, aplicația va oferi fișierul de tipul standard al componentei generatoare.

A doua funcționalitate a Editorului constă în afișarea rezultatului oferit de către generator. Aceast set de funcții este unul cu caracter opțional; rezultatul Generatorului este oferit utilizatorului. El nu este obligat să verifice conținutul fișierelor prin intermediul Editorului, deși un astfel de comportament este recomandat.

O ipoteză suplimentară legată de caracterul aplicației Editor este formată în urma analizei obiectivelor proiectului, efectuată în capitolul anterior, Editorul poate fi calificat asemenea unei aplicații de tipul CAD, un mediu front end în dezvoltarea site-ului.

Cele două funcționalități alături de caracterizarea oferită, prezintă o serie de cerințe specifice acestei componente. Ele sunt descrise folosind modelul de clasificare folosit asupra componentei anterioare.

4.2.3.1 Cerințe funcționale

Acestă categorie de cerințe se nasc din mai multe surse: cele două funcționalități prezentate, caracterizarea oferită în capitolul anterior, cerințe născute din aplicarea conceptelor prezentate în capitolul anterior împreună cerințele care se nasc din consecințele tuturor cerințelor puse la un loc.

Cerințe utilizator: • trebuie să conțină operații de editare • trebuie să ofere operații de generare format • trebuie să permită adăugarea de conținut HTML/cod embeded • trebuie să verifice corectitudinea informațiilor adăugate • trebuie să ofere un set de instrucțiuni care afișează produsul generat

Cerințe conceptuale:

Capitolul 4

34

• 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ă adăugarea de componente data-driven

Cerințe sistem: • trebuie să ofere opțiuni de publicitate a site-urilor • trebuie să constrângă intrările la cele acceptate de către editor • trebuie să permită adăugare de componente particularizate • trebuie să verifice posibilitatea de conexiune cu Generatorul • ar trebui să ofere un mod de vizualizare a conținutului generat de utilizator

4.2.3.2 Cerințe ne-funcționale

Cadrul cerințelor nefuncționale este analizată pe baza cerințelor specifice întregului proiect – cerințe generale, împreună cu cele specifice componentei Editor – cerințe particulare.

Cerințe ne-funcționale generale: • robustețe – componenta joacă rolul unui parser al intrărilor oferite de utilizator,

eliminând posibile erori la generare; aplicația trebuie să fie pregătită de orice greșeală de input a utlizatorului

• accesibilitate – aplicația este accesibilă celor care doresc să o folosească prin intermediul Internetului; ea nu este obligatorie pentru generare, ci o recomandare

• disponibilitate – editorul este disponibil atât on-line cât și offline, generarea standardului Generatorului este realizată și fără ajutorul internetului

• backup – aplicația poate fi salvată oricând 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 opțiuni de editare suplimentare

• mentenabilitatea – defectele se pot detecta în cadrul aplicației la nivelul fiecărei operații oferite pe baza standardului generat

• compatibilitate cu un număr mare de platforme • portabilitate – posibilitatea de a fi folosită pe orice mediu ce suportă un browser • posibilitatea de executare în cazul unor resurse limitate – aplicația prezintă un

nivel minim de operații de creeare/editare Cerințe ne-funcționale particulare:

• Independența – scopul componente este generarea de standard specific Generatorului – aplicația funcționează fără necesitatea unei alte componente; datorită calității generatorului de perpetual beta, păstrarea aceluiași standard în cadrul editorului nu va creea probleme în procesul generator.

• Mentenabilitatea – site-ul este ușor de modificat de către proprietar fie prin o nouă generare, fie prin editare a fișierelor particulare

• Inter-operabilitate – aplicația nu este legată de celelalte componente dar este inter-operabilă cu aplicațiile Web 2.0 folosite

• Conformitate – aplicația trebuie să fie conformă stadiului existent sau unui stadiu anterior de standard a componentei Generator

• Extensibilitate – componentele se pot modifica fără ca utilizatorul să cunoască, principiu legat de perpetual beta Web 2.0

Capitolul 4

35

4.2.3.3 Cerințe specifice domeniului problemei

Acest tip de cerințe sunt legate de domeniul editoarelor web. În general, ele sunt legate de intrările utilizatorului, în special cele de codificare:

• aplicația trebuie să ofere un set de funcții care permite adăugarea de conținut exterior; acesta ar trebui verificat înainte de trimitere către Generator

• editorul ar trebui să ofere o verificare suplimentară a fișierelor externe introduse în cadrul aplicației,

• este recomandată salvarea fișierelor externe în cadrul aplicației, în loc de încărcarea lor prin link

Cerințele prezentate la nivelul fiecărei componente se nasc din asumarea obiectivelor

prezentate în cadrul Capitolului 2 a prezentei lucrări. Scopul acestor cerințe este de a califica funcțiile sistemului fără a repeta ceea ce s-a menționat 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 funcții, urmând ca produsul final să apeleze aceste componente în executarea unor sarcini specifice.

Motivul selecției acestei arhitecturi este parțial motivată în analiza componentelor efectuată în subcapitolul anterior. Aceste argumente prezintă avantajele arhitecturii Component-Based la nivel local, fără 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ă operațiile în forma unor componente distincte, formate din seturi de preocupări funcționale independente.

Din această definiție, se poate observa rolul central ocupat de componenta software. Ea este o entitate independenta, formată dintr-un set de operații, care realizează o serie de funcționalități de interes comun.

Stabilirea interesului comun al funcționalitățiilor se realizează în analiza aplicației. În urma parcurgerii cerințelor, se stabilesc grupuri de funcționalități care fie sunt dependente una de alta, fie realizează o operație complexă. Motivul acestei grupări reprezintă interesul comun al funcționalitățiilor și stă la baza separării în componente.

Această arhitectura, ca oricare altă arhitectură, prezintă o serie de avantaje/dezavantaje. Acestea vor fi prezentate la nivel general, specifice oricărui proiect, împreună cu o serie de avantaje particulare, specifice prezentului proiect.

Avantajele generale ale arhitecturii:

� managementul complexității � separarea funcționalitățiilor în grupuri cu interes comun; aceste grupuri se bazează pe legătura dintre funcționalități

� separarea sarcinilor în componente individuale � ușurință în dezvoltare datorită preocupării cu un anumit set de

funcționalități care prezintă un interes comun � ușurința în detectarea erorilor la nivelul aplicației � ușurință în modificarea/extinderea componentelor

Capitolul 4

36

� componente refolosiblie � componentele pot fi folosite și de alte aplicații � componentele pot fi reutilizate prin folosirea unei sau mai multor funcționalități

� creearea/modificarea aplicațiilor prin utilizarea componentelor cere mai puțin timp pentru dezvoltare

� datorită funcționalitățiilor cuprinse în interiorul componentei și a interesului lor comun, noua funcționalitate este catalogată în apartenența unei componente; în dezvoltarea noii funcționalități, aceasta poate apela funcții care prezintă un interes comun din intermediul componentei

� efectul imediat este creșterea productivității � timpul de dezvoltare este redus

� spre deosebire de dezvultarea iterativă, Avantajele specifice proiectului:

� aplicarea unor concepte cerute în cadrul obeictivelor/cerințelor proiectului � exemplu: lightweight programming – format folosind arhitectura bazată pe

componente – este recomnadarea oferită pentru arhitectura aplicațiilor Web 2.0

� separarea în componente poate fi exinsă la separare în aplicații

Dezavantaje generale ale arhitecturii: � sensibilitatea la schimbări

� componentele trebuie gândite în așa fel încât să fie pregătite pentru schimbări

� control redus asupra stării sistemului � deși nu este valabil în cazul proiectului, în cazul în care sistemul, în

ansamblul său, păstrează diferite stări, este foarte greu de creeat o logică de păstrare/încărcare a stării

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 funcționalitate a componentelor a fost descrisă, dar se poate observa lipsa unei descrieri a modului de interacționare între componente.

Următoarea etapă în descrierea arhitecturii proiectului este prezentarea modului de relaționare a componentelor pe baza funcționalitățiilor sale.

Scenariul general al proiectului – privit abstract:

Figura 4.1 Scenariul general al proiectului -abstract

Intrare utilizator

Serviciu Web

Site Web 3.0

Editor Trimite format

standard

Generează Site

Publicat pentru testare

Capitolul 4

37

Pe langă scenariul general propus, fiecare aplicație prezintă un scenariu particular format din intrări/ieșiri specifice fiecărei funcționalități. Ele trebuie prezentate și calificate în implementarea arhitecturii.

Figura 4.2 prezintă funcționalitățiile aplicațiiei privite la nivel global.

Figura 4.2 Arhitectura Proiectului - aspect general

Editor - creeare pagina/pagini - desenare pagina/pagini - desenare componente:

o text o imagini o exterioare

- definire elemente semantice - generare XML

- afișare pagini generate - salvare arhiva zip pe mașina locală

Intrare Utilizator - mouse - tastatura - fișier XML

Serviciu web - afișeză informații serviciu - generează site web:

o HTML � text � imagine � CSS � Semantic Web

o PHP � Pagini speciale � facebook � twitter

Trim

ite XM

L către S

erviciu Intrare Utilizator - getInfo() - genereaza()

Site Web 3.0 - pagini HTML

o text/imagini o Semantic Web

- pagini PHP o facebook/twitter o pagini speciale

- imagini - standard XML

Generează

Trimis către Editor

Intrare Utilizator - mouse - tastatura

Capitolul 5

38

Capitolul 5. Proiectare de detaliu si implementare

Fiecare implementare prezentată conține soluția unei funcționalități, motivarea soluției împreună cu descrierea tehnologiei folosite. Suplimentar, se precizează, dacă este cazul, modul în care implementarea afectează arhitectura proiectului.

Prezentarea implementării începe cu nivelul global, adică maparea arhitecturii cu tehnologiile invocate, urmată de prezentarea implementării fiecărei componente.

5.1 Arhitectura proiectului implementat

Scopul acestui subcapitol este de a prezenta modul de funcționare a aplicației, oferind o introducere în implementarea proiectului și a componentelor sale. Prezentarea în detaliu a fiecărei componente, împreună cu motivarea implementării propuse, se va face separat.

Între modelul arhitectural propus și schema generală a aplicației implementate nu există diferențe. Fiecare componentă respectă conceptele propuse în capitolul anterior. Schema generală a aplicației nu face altceva decât să prezinte, în mod practic, ceea ce a fost descris teoretic.

Figura 5.1 Schema generală a aplicației; procesul tipic de generare

Intrarea de la utilizator constă în editarea unor elemente HTML în cadrul aplicației editor.

Utilizatorul adaugă conținut elementelor stabilite de editor, urmând ca aplicația să verifice conținutul generat.

La sfârșitul procesului creator, editorul procesează intrările utilizatorului și formează fișierul de tipul XML specific intrării Serviciului de generare. Componenta Editor apelează, prin aritectura de tipul Web Service, Generatorul. Acesta primește fișierul și transformă intrarea în Site-ul Web 3.0. Produsul final este arhivat și întors către utilizator spre vizualizare. Utilizatorul are de ales între vizualizarea conținutului generat în interiorul Editorului sau preluarea conținutului spre testare particulară.

Schema prezentată în figura 5.1 prezintă modulul general de funcționare.

5.2 Editor Site

Funcționalitățiile oferite de către această aplicație acoperă totalitatea cerințelor de lucru direct cu utilizatorul. Componenta Editor permite creearea/modificarea modelului de site, apoi afișează rezultatul final.

Operația de generare de cod este transparentă pentru utilizator, doar Editorul cunoaște existența generatorului. Această abordare este motivată datorită targetului de utilizatori ai aplicației. Ei nu doresc să cunoască aceste detalii, scopul aplicației este doar generarea de cod,

Intrare utilizator

Serviciu WebService

Java

Site Web HTML/php

Editor JSP/Flash

Trimite XML

Generează Site

Format: HTML/php

Publicat pentru testare

ZIP

Capitolul 5

39

astfel operațiile efectuate nu contează. Totuși, pentru a respecta conceptul Web X.0, informațiile legate de procesul de generare sunt oferite la cerere.

Astfel, componenta Editor își păstrează calitatea de aplicație de tipul Front End, operațiile Back End sunt predate spre componenta Generator.

O altă observație leagtă de Editor, identifică trei tipuri de funcționalități: • operații folosite în modelarea Site-ului; • operații de vizualizare; • operații de comunicare Generator/Editor

Această observație se dovedește a fi utilă în implementarea aplicaței. Fiecăre set de operații se dezvoltă individual, economisind timp de dezvoltare. Editorul urmează să fie partajat în două aplicații interdependente, în funcție de setul de operații realizat.

Aplicația Flash se ocupă de întaia parte a procesului creator, modelarea Site-ului. Ea oferă un set de operații de adăugare/editare conținut Web, asemănător unui mediu CAD. A doua aplicație, JSP, se ocupă de ultima parte a procesului creator – verificarea produsului generat. Tot a doua aplicație va conține logica de comunicare datorită legăturii intime cu procesul de verificare.

5.2.1 Aplicația Flash

Scopul și cerințele 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 Aplicație Flash:

• modelarea Site-ului care urmează generat • generarea standardului de intrare a Generatorului.

Modelarea site-ului presupune o serie de funcționalități creeate cu scopul de adaugare/editare/stergere elemente. Site-ul va fi scris în limbajul HTML, astfel elementele generale supuse editării vor fi standarde ale acestui limbaj.

Pe langă aceste elemente, există o serie de componente care sunt specifice unei aplicații web, în special aplicațiile Web 2.0. Aplicația Flash trebuie să descrie operații pentru adăugare/editare/stergere de elemente pentru aceste componente.

Analiza componentelor care vor fi supuse adăugării va fi realizată în subcapitolul dedicat implementării Site-ului Web. Aplicațiile Web 2.0 care vor fi adăugate în componența 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 către Generator, apoi oferită utilizatorului.

Spre rezolvarea implementării componentei se va folosi paternul Model View Controler descris pe platforma Adobe Flash CS5.

5.2.1.1 Platforma Aplicației

Cunoscut și sub denumirea de Macromedia Flash, Adobe Flash este o platformă multimedia, oferită de către Adobe Systems, folosită în creearea unor pagini bogate vizual, prin utilizarea animaților, formatelor video și a interactivității.

Flash creează animații folosind grafică vectorială împreună cu elemente de tipul RASTER. El suportă streaming bidirecțional al formatelor video și audio; poate citi intrări primite de la mouse, tastatura, microfon sau cameră web. Flash conține un limbaj orientat obiect, denumit ActionScript, care oferă un mod de manipulare animațiilor/elementelor adăugate.

Capitolul 5

40

Structura mediului de dezvoltare conține trei entități principale. Prima entitate se numește scenă și permite creearea unor elemente vizuale. Aici se pot adauga/defini elemente text, video, imagini prin operații de tipul drag and drop sau desenare. Această parte nu necesită cunoașterea vreunui limbaj de programare, Flash joacă rolul unei aplicații de editare de imagini.

A doua componentă se numește Timeline și permite animarea scenei create în entitatea anterioară. Bazat pe frame-uri, Flash se aseamănă unui editor video care redă un număr de imagini pe secunda (fps).

Ultima componentă se intitulează acțiuni. În această entitate se definesc elementele desenate în scene, împreună cu comportamentul acestora, folosind limbajul de programare ActionScript.

Cele trei entități sunt legate între ele, existând posibilitatea creeări unor operații complexe, prin manipularea evenimentelor/componentelor în diferite frame-uri/scene.

Selecția platformei Flash pentru dezvoltarea aplicației Editor se motivează pe avantajele oferite în dezvoltărea unei aplicații de tipul CAD, împreună cu câteva avantaje generale ale platformei. Aceste motive vor fi prezentate împreună cu conceptul/cerința care o respectă:

• dezvoltarea unei aplicații bogate web – conceptul Web 2.0 o procesarea elementelor vizuale (butoane, imagini, text, etc) o definirea unor funcții bazate pe interactivitate o încărcare/salvare fișiere

• aplicații SVG – Web 3.0; • aplicația Flash Player, folosită în redarea conținutului Flash, este gratuită și se

găsește oricând, pentru instalare, pe site-ul oficial – accesibilitate; • formatul flash poate fi accesat atât prin intermediul unui browser, cat și stand

alone – disponibilitate; • compatibilitate cu un număr mare de platforme; • portabilitate, aplicațiile 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 operații complexe în funcție de evenimente

diferite; • permite adăugare de diferite standarde specifice formatului HTML; exemplu:

imagini, video, sunet, etc; • oferă posibilitatea dezvoltării unui mediu mai usor de folosit – useability;

5.2.1.2 Șablon de proiectare

Problema implementării componentei Flash este realizată folosind design-pattern-ul Model-View-Controler. Această descriere permite separarea operațiilor specifice elementelor vizuale de operațiile de procesare.

Patternul MVC conține trei componente: Model – descrie operațiile efectuate prin interactionarea cu elementul visual, reține starea aplicației; View – descrie elementele vizuale, poziția lor, contextul, etc; Controlor – interpretează intrările oferite în componenta View și notifică Modelul ce operații să execute; Controlorul trimite intrările către Model spre procesare.

Acest design patern prezintă o serie de avantaje: • claritate în design: separarea operațiilor după scopul lor; • eficiență prin modularizare: permite modificarea/adaugarea/stergerea

componentelor cu ușurintă; • multitudine de componente vizuale; ușurința de manipulare a componentelor

vizuale;

Capitolul 5

41

• ușurința în adăugarea de funcționalități noi; O abordare simplistă a modului de funcționare a Patternului MVC este oferită în figura

5.2. Modelul este nucleul aplicației. Cand există schimbări în Model, se notifică View. Controlerul reprezintă modalitatea de interacțiune cu Modelul a utilizatorului. View afișează informațiile oferite de Model.

Figura 5.2 Prezentarea paternului MVC

Acest pattern a fost ales datorită avantajelor care le prezintă la dezvoltarea implementării cât și datorită tipicității aplicației (de tipul CAD).

5.2.1.3 Elemente generale ale implementării

Înainte de prezentarea implementării componentelor paternului, se va prezenta modul de organizare a codului în interiorul aplicației. Scena este împărțită pe nivele denumite layer. Acestea sunt poziționate asemănător paginilor într-o carte, una deasupra celeilalte. Nivelele pot fi grupate în directoare (folders).

Codul fiecărei componente este separat în mai multe nivele, dar toate sunt adăugate în cadrul aceluiași folder. Astfel Folderul View conține mai multe layere, specifice fiecărui caz de vizualizare, modelul va conține mai multe layere specifice anumitor operații, etc.

Denumirea acestor layere va cuprinde tipul de componentă a paternului urmat de o denumire generică a operațiilor/țintei. Exemplu: ModelImage – layer care aparține de model și ținta operațiilor sunt cele de prelucrare imagine.

Aplicația rulează într-un singur cadru (frame), astfel fiecare layer va conține pe respectivul frame o secțiune de cod ActionScript.

Un alt element general al implementării reprezintă modul de reprezentare a conținutului Site-ului generat în interiorul Modelului. Se vor folosi clasele ActionScript descrise în tabelul 5.1.

Toate pre-condițiile și post-condițiile sunt menționate în prezentul capitol, impreuna cu operația pe care o validează, dar sunt prezentate în capitolul dedicat testării/validării.

Nume clasă Extinde Implem

etează Atribute Metode

Pagina MovieClip -

-id* : int -titlu* : String -scop : String

-componente : Array +w : int +h : int

+constructor +setter/getter

+addComponenta +deleteCompone

nta

User

Controler View

Model update

vede utilizează

manipulează

Capitolul 5

42

Nume clasă Extinde Implem

etează Atribute Metode

ComponentaExteriora Pagina - - +constructor

ComponentaPagina - Clonable

-x : int -y : int

-relatiePagina : String -nume* : String

-h : int -w : int

+constructor +setter/getter

+clone

ComponentaText Componenta

Pagina Clonable

-continut:TextField -relevanta : String

-text : String -font : String

-marime : String -align : String

-hyperlinks : Array

+consturctor +setter/getter

+addHyperLink +removeHyperLi

nk +clone

ComponentaImage Componenta

Pagina Clonable

-relevanta : String -alt : String -lnk : String -src : String

-loader : Loader -imageData : ByteArray

+constructor +setter/getter

+clone

ComponentaExternaFB Componenta

Pagina Clonable -continut : TextField

+constructor +setter/getter

+clone

ComponentaExternaOther

ComponentaPagina

Clonable -continut : TextField

-linkTo : String

+constructor +setter/getter

+clone

ComponentaFBHistoryInput

ComponentaPagina

Clonable -continut : TextField +constructor +setter/getter

+clone

ComponentaFBInput Componenta

Pagina Clonable -continut : TextField

+constructor +setter/getter

+clone

ComponentaFBPicture Componenta

Pagina Clonable -continut : TextField

+constructor +setter/getter

+clone

HyperLinkPage - -

-beginInt :int -endInt : int -link : String

-descriere : String

+consturctor +setter/getter

Tabelul 5.1: Clasele utilizate în dezvoltarea aplicației După cum se observă din citirea tabelului, fiecare clasă deține un constructor,

settere/gettere (mutatori) și operația de clonare. Constructorul fiecărei clase primește parametrii atributele definite de clasă. Metoda de clonare nu are pre-condiție; post-condiția este făcută prin verificarea egalității între obiecte.

ActionScript3.0 nu cunoaște interfața de clonare, astfel aceasta trebuie definită, apoi fiecare clasă trebuie să prezinte o implementare a acestuia.

Capitolul 5

43

Mutatori sunt folosiți în setarea/întoarcerea valorii unei variabile private. Pre-condițiile și post-condițiile sunt tipice unor mutatori.

Clasa principală a aplicației este cea de tipul Pagina. Ea corespunde unei pagini generate. Atributele acestei clase se rezumă la

• un număr de identificare – id; • denumirea paginii – titlu; • relevanța față de conținutul site-ului, semantic Web – scop; • elementele html/facebook/twitter – componente; • înalțime – h; lungime – w; • atribute primite de la superclasa: x,y : pozitia față de colțul stânga al aplicației

Operațiile de adaugare/deleteComponenta adaugă sau șterg o componentă din atributul de tipul Array, primesc un singur paramentru de tipul ComponentaPagina.

Pre-condiția adaugării este validitatea elementului adăugat: prin existența acestuia (diferit de null), să nu existe în componente și să fie de tipul corespunzător. Post-condiția adăugării se rezumă la o verificare dacă elementul a fost adaugat corect.

Pre-condiția ștergerii: existența elementului în listă, să nu fie null, post-condiția ștergerii constă în verificarea array-ului după ștergere.

Aceeași condiții se aplică și în cadrul operațiilor de add/removeHyperLink ale clasei ComponentaText.

Clasa ComponentaExterioara definește o componenta de tipul facebook sau twitter. Ea este tratată în mod asemănător unei pagini datorită condițiilor speciale de edităre ale acestei componente. Ele se comporta ca pagini la nivel vizual, dar rezultatul lor este refolosit sub forma de ComponentăPagina. Motivarea acestui fapt este făcut după prezentarea elementelor vizuale.

Clasa ComponentaPagina reprezintă elementul HTML/facebook/twitter. Atributele acestei clase sunt generale oricărui tip de componente. Metodele sunt creeate în mod asemănător cu cele prezentate mai sus.

Clasele ComponentaText, ComponentaImage, CoponentaExternaFB, ComponentaExternaOther extind clasa ComponentaPagina și reprezintă particularizarea clasei ComponentaPagina. Fiecare din aceste sub-clase conțin parametrii specifici elementului care îl reprezintă, iar toate sunt vazute de către Pagina ca fiind ComponentePagina - polimorfism.

Ultimul set de clase reprezintă clasele care pot fi adăugate doar în contextul unei ComponenteExterioara. Clasele ComponentaFBHistoryInput, ComponentaFBInput, ComponentaFBPicture, definesc elemente ale unei componente FB. Ele vor fi adaogate dacă utilizatorul dorește acest lucru.

Capitolul 5

44

Figura 5.3 Diagrama de clase Clasa HyperLinkPage conține informații referitoare la un hyperlink in interiorul unei

componente text. El păstrează informații legate de poziția de început și sfârșit a linkului impreună cu pagina către care se face linkul. În cazul în care se face link către o pagină în interiorul site-ului, linkul va conține un prefix : „SITE:” împreună cu denumirea paginii.

O informație suplimentară oferită de tabelul 5.1 este unicitatea anumitor parametrii în diferite colecții în care poate să apară. Fiecare atribut care trebuie să fie unic îi este atașat simbolul *.

5.2.1.4 View

Componenta View reprezintă elementul vizual al aplicației. Aici sunt definite totalitatea elementelor care urmează a fi afișate. Aceste elemente primesc, dacă este cazul, o referință spre operațiile, din Controler, apelate în cazul anumitor evenimente.

Un eveniment constă într-o acțiune efectuată asupra unui element vizual, de către utilizator. Acțiunile se rezumă la operații provenite fie de la tastatură fie de la mouse.

Exemplu 5.1: componentaView.addEventListener(event,funcțieControler) În exemplul 5.1, se arată modul de atribuire a unei funcții Controler: funcțieControler 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 Aplicației Flash: a. forme geometrice b. desen fundal

Pagina

ComponentaPagina

ComponentaImage

ComponentaText

ComponentaExternaFB

ComponentaExternaOther

ComponentaExterioara

ComponentaFBInput

ComponentaFBHistoryInput

ComponentaFBInput

HyperLinkPage

Capitolul 5

45

c. text label/input d. butoane e. liste f. comboBox g. Loader

Toate elementele prezentate sunt adăugate în scena aplicației. Flash descrie scena sub forma unei implementări a clasei MovieClip, denumită stage. În interiorul acestuia se pot adăuga variante ale clasei DisplayObject.

Toate elementele enumerate mai sus extind clasa DiplayObject, dar nu direct. Flash conține o ierarhie de clase specializate pentru fiecare formă vizuală care se poate defini în spațiul tridimensional.

Adăugarea unui element se realizează folosind operația addChild(DisplayObject). În cazul în care se dorește adăugarea unui elemend la o anumită adâncime, se utilizează operația addChildAt(DisplayObject, depth).

Eliminarea unui element de pe scenă se realizează folosind operația removeChild(DisplayObject). Există o altă metodă de ascundere a elementelor aflate pe scenă. Fiecare obiect de tipul DisplayObject conține atributul visible. În cazul în care nu se dorește eliminarea obiectului de pe scenă, dar se dorește ascunderea lui, se setează parametrul visible de tipul false. În cazul în care visible estre true, se afișează elementul.

Descrierea elementelor viuzale folosite de Aplicația Flash: a. Formele geometrice conțin majoritatea figurilor geometrice elementare. Ele sunt

definite în pachetul flash.display, oferind o serie de operații de desenare și adaugare în scenă. Ele sunt folosite la desenarea de conținut dinamic prin intermediul ActionScript3.0.

În cadrul implementării, ele sunt folosite în operațiile de generare de conținut. Forma geometrică desenată joacă rolul unei umbre temporare a viitoarei componente. Exemplu: în clipa în care se cere adăugarea uni element text, sistemul așteaptă poziționarea și desenarea respectivului element. Până în momentul finalizării desenului, se va afișa o formă dreptunghiulară, apoi se va afișa 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 adăugate într-un container de tipul Shape. Acest container permite poziționarea, redimensionarea cât și definirea unui comportament în cazul evenimentelor.

b. Elementul Desen Fundal reprezintă fundalul static al aplicației. Acesta nu se modifică

pe parcursul rulării aplicației. Fie că el face parte din scena principală, fie din butoane, acestă componentă are un scop pur vizual și nu funcțional.

c. Text label reprezintă un element text care nu poate fi modificat. Acestea sunt adăugate

în scenă pentru a oferi informație către utilizator. Elementele label, în limbajul ActionScript 3.0, sunt de tipul TextField. Operațiile asupra acestor elemente sunt cele generale ale unui TextField.

Text input reprezintă un element text a cărui conținut se poate modifica. Scopul acestor elemente este de a prelua informații de utilizator in format text. În limbajul ActionScript 3.0, aceste elemente sunt de tipul TextField.

Operațiile principale, oferite de către limbajul ActionScript3.0, asupra unui TextField sunt:

Capitolul 5

46

• poziționare TextField, prin setarea atributelor publice: +x, +y, +width, +height; valori întregi

• modificare text prin setarea atributului public +text; • setare de format text: se folosește o clasă TextFormat care primește atribute legate

de mărime, font, align, etc. Operația de atribuire TextFormat implică mai multe etape

Pe langă cazurile expuse mai sus, elementul Text input/label se mai folosește și în cazul definirii unui element al site-ului. Aceste operații sunt acoperite în domeniul Modelului.

d. Butoanele reprezintă o particularizare a clasei MovieClip. Clasa SimpleButton

definește trei frame-uri, fiecare având un scop specific în raport cu evenimentele realizate cu mouse-ul.

Frame-ul Up reprezintă comportamentul aplicației î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 apăsare a butonului stanga a mouse-ului, MouseMove – eveniment definit de mișcarea 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 operație de click.

Fiecare buton deține o serie de parametrii de poziționare : +x:int, +y:int cât și parametrii care oferă lungimea/lățimea butonului, +width/+height. Implementarea comportamentului de buton este realizat în Controler în mai multe operații.

e. Listele sunt elemente predefinite care afișează o serie de opțiuni, urmând ca

utilizatorul să selecteze una. Lista este o extensie a clasei DislayObject, astfel încât poate fi aădugată în scenă, conține atribute folosite în poziționare și permite adăugarea de comportament în cazul evenimentelor.

Citirea elementului unei liste se realizează folosind operația getSelectedLabel(). Aceasta întoarce indexul elementului selectat, urmând ca denumirea elementului selectat din listă să fie returnat de operația getLabelAt(index).

f. ComboBox sunt asemănătoare listelor, singura diferență constă în modul de afișare a

conținutului. În cadrul elementelor ComboBox, se afișează doar elementul selectat. Dacă se dorește modificarea elementului, se va face click pe săgeata din partea stângă. Elementul ComboBox va afișa opțiunile posibile, apoi utilizatorul alege opțiunea dorită.

Implementarea acestui element se face în mod asemănător cu elementul Listă. g. Loader – element grafic care poate conține orice imagine sub formă de bitmap. Este

folosit în diverse cazuri care cer afișarea de figuri geometrice sau imagini. Elementul loader prezintă o serie de metode de adăugare de conținut, exemplu adăugare

de imagine: loadByteArray(), load() , etc.

5.2.1.4.2 Tipuri de componente

Aplicația Flash conține două tipuri de componente View. Clasificarea este realizată după criteriul importanței elementelor în dezvoltarea site-urilor. Cele două tipuri sunt:

• componente care sunt păstrate vizibile fie permanent, fie o perioadă îndelungată; denumite generic : elemente vizuale permanente

Capitolul 5

47

• componente care sunt folosite doar în cazul unui anumit eveniment; elemente vizuale temporare

I. Elementele vizuale permanente sunt desenate la începutul dezvoltării aplicației.

Ele sunt vizibile pe parcursul dezvoltării aplicației, astfel, legătura 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 operația de atribuire a unui comportament în cazul unui eveniment.

Elementele vizuale permanente ale Componenta Editor prezintă două stări: adăugare componenta text/imaginie și adăugare componenta FB. Figura 5.4 prezintă elementele vizuale permanente specifice stării de adăugare elemente imagine/text. Comportamentul acestor elemente este descris în Tabelul 5.2 Figura 5.5 descrie elementele vizuale în cazul adăugării unei componente FB, iar Tabelul 5.3 este o continuare a Tabelului 5.2.

Figura 5.4 Componenta Editor în cazul de utilizare adăugare text

Lista elementelor vizuale permanente și comportamentul lor:

Denumire Element Tip Comportament

Elemente Label - Text Buton Adaugă un TextField in site

Image Buton Adaugă o imagine in Site Pagina Buton Creează o pagină nouă

Generate Buton Generează XML unde dorește utilizatorul Load Buton Încarcă XML exterior

Text Options Label - Font Label -

FontComboBox ComboBox Permite alegerea unui tip de font Size Label -

Pagini

Adaugare Componenta

Meniu Hyperlink

Meniu Componenta

Facebook Meniu XML

Meniu TextField

Capitolul 5

48

SizeText Input Valoarea introdusă reprezintă mărimea fontului textului Align Label -

AlignLeft Buton Setează align la text AlignRight Buton Setează align la text AlignCenter Buton Setează align la text

AlignJustified Buton Setează align la text Color ColorPicker Setează culoarea Bold Buton Selecția din text devine boldata Italic Buton Selecția din text devine inclinată

Underline Buton Selecția din text devine subliniată Hyperlink Buton Setează selecția ca fiind hyperlink Tab Pagina Label -

1..6 - X Buton Afișează paginile nr x*7-(x+1)*7 Site Map Buton Afișează meniu Site Map Index* Buton Afișează pagina Index pe scenă

Descriere Legatura Label - Descriere Legatura Input Descrie legătura într-un mod semantic

Hyperlink Label - Hyperlink Input Conține site-ul către care se face link

Create Buton Adauga un hyperlink în zona selectată către Hyperlink Input Create Custom FB

Component Buton Creează o nouă componentă FB

Create Other Component Buton Creează o nouă componentă Other Add Fb Component Buton Adaugă o componentă fb definită

Tabel 5.2 Comportamentul elementelor vizuale permanente

Figura 5.5 Componenta Editor în cazul de utilizare adăugare text

Denumire Element Tip Comportament

FBPicture Buton Adăugare componenta imagine utilizator FB FB Input Text Buton Adăugare componenta input utilizator FB

FB History Input Buton Adăugare componenta istoric utilizatori FB Tabel 5.3 Comportamentul elementelor vizuale permanente

Elemente Componenta FB

Scena Componenta FB

Capitolul 5

49

Implementarea componentelor vizuale premanente se rezumă la desenarea fiecărei

componente în parte, apoi atribuirea unui comportament fiecărui 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 operațiilor asociate cu elementele temporare.

Inițializarea elementelor vizuale temporare este realizată în componenta View. Ele sunt generate de către 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 păstrată în Anexă. 5.2.1.5 Controlorul (Controller)

Controlorul verifică informațiile trimise de către utilizator, iar dacă acestea sunt corecte, apelează modelul spre modificarea stării de view și efectuarea operațiilor. În cazul unei intrări formate greșit, controlerul trimite spre afișarea erorii întampinate.

Fiecare operație de verificare conține o descriere a tuturor verificărilor care se cer înainte de apelarea Modelului împreună cu funcțiile apelate, sursa din View care apelează la acest comportament împreună cu, dacă este cazul, particularități ale implementării.

OpC1: Afișarea erorilor. Pe parcursul prezentării tuturor operațiilor se vor descrie cazurile

în care se trimite către model o execuție și cazurile în care se trimite către Model afișarea unei erori. La notificarea modelului, el va dispune afișarea dialogului specific erorii, împreună cu un buton OK pentru întoarcere la pagina anterioară.

Dialogul specific errori va afișa Erroare: TextEroare, unde TextEroare este un Label care notifică utilizatorul ceea ce a completat greșit. Acest text este generat de către Model în funcție de tipul erorii notificate de către controler prin apelarea metodei doErrorNo. Aceasta funcție specifică și comportamentul butonului OK. Aceast comportament împreună cu detalii suplimentare legate de operațiile Modelului sunt parcurse în operația OpM17.

OpC2:Verificarea operației de adăugare pagină. La efectuarea unui click pe butonul Pagină, controlorul trimite către model operația de curățare scena: clearStage(); apoi se inițializează procedura de creeare a unei noi pagini showNewPageDialog(). Se va deschide un dialog care va cere introducerea unor informații legate de noua pagină care urmează creată.

La efectuarea unui click pe butonul OK se va verifica dacă informațiile sunt introduse corect, apoi se vor trimite către model parametrii folosiți în creearea unei noi pagini, împreună cu operația de setFocusOnNewPage(), care afișează elementele ultimei pagini create. Observație: mai există o metodă care afișează o pagină specifică, ea se numește setFocusOnPage(pagina), care afișează o pagină specifică.

În cazul în care există intrări 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 afișat.

Dacă se efectuează click pe butonul Cancel, se va trimite către model operația de redesenare a scenei: redrawStage().

Implementarea acestei componente se realizează prin verificarea următoarelor cerințe: • Campul Denumire să fie completat cu o valoare unica; nu pot exista două pagini

cu aceeași denumire

Capitolul 5

50

• Campul Relevanță să fie completat cu o valoare diferită de șirul gol OpC3: Verificarea operației de desenare. Această operație apare în cadrul oricărei

adăugări de elemente în pagină. După începerea operației, se așteaptă efectuarea unui click de către utilizator în interiorul scenei. În cazul în care se efectuează click în afara scenei nu se întâplă nimic.

Mărimea scenei variază în funcție de pagina pe care se desenează. În cazul în care se vorbește despre o componentă exterioară, exemplu Facebook, Twitter, etc, mărimea scenei este definită de către poziția x,y, lungime, lățime a paginii. Cordonatele paginii sunt preluate din model: getCurentPageZ(), unde Z este coordonata cerută. În cazul în care se vorbește despre o pagină normală, parametrii paginii sunt prestabiliți.

Dacă click-ul este realizat în scenă și butonul stânga a mouse-ului este apăsat, se trimite către model deseneazaComponentaTemporara(). Când butonul stânga a mouse-ului este lăsat, se va desena componenta cerută de către utilizator.

Componenta temporară principală este un dreptunghi de culoare 0x999999. În cazul adăugării 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 verificări se realizează folosind o serie de instrucțiuni IF care verifică dacă a fost depășită scena. Exemplu:

if (x<minScena) x = minScena;

if (x>maxScena) x = maxScena:

Limitele elementelor adăugate î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 operației de adăugare componentă text. Componenta text este adăugată

în două etape. Prima etapă începe în momentul efectuării operației de click pe butonul Text. Acum se așteaptă operația de desenare a componentei text. Controlorul asigură desenarea textului pe scenă prin operația OpC3.

După desenarea elementului text, se trimite către model afișarea dialogului pentru noua componentă. Acum se așteaptă introducerea unor informații legate de noua componentă creeată. La efectuarea unui click pe butonul OK, controlorul va verifica dacă informațiile sunt introduse corect, dacă nu va afișa o eroare, codul erorii este 3.

În cazul în care informațiile sunt afișate corect se va trimite către model operația de adăugareComponentaText împreună cu parametrii citiți de la utilizator.

Verificările realizate de controler: • Controlerul verifică poziția mouse-ului, dacă în momentul începerii desenării

componentei, • Unicitatea campului denumire • Valoarea campului relevanță să fie diferită de valoarea nulă.

Capitolul 5

51

OpC5: Verificarea operației de adăugare componentă imagine. Spre deosebire de componenta anterioară, la efectaurea operației de click pe butonul Image, se va cere destinația imaginii, împreună cu câteva informații legate de imagine.

După efectuarea unui click pe butonul OK se va verifica dacă informațiile introduse sunt corecte, apoi se va trimite către model instrucțiunea de început de operație de desenare. În cazul în care o informație este introdusă greșit se va afișa eroarea numărul 4.

La sfârșitul operației de desenare, se va adăuga componenta cerută prin notificarea modelului prin metoda adaugaComponentaImagine. Următorul pas este redesenarea scenei redrawStage().

OpC6: Verificarea operației de creeare componentă facebook. Elementele facebook și twitter sunt Componente Exterioare. Ele urmează să fie adăugate în interiorul unei pagini, în structura definită de către utilizator. Dar înainte de adăugare, ele trebuie să fie definite.

Operația de definire începe prin desenarea mărimii componentei. După desenare, scena este limitată la zona desenată anterior. Se va afișa un dialog care va cere introducerea unei denumiri. Dacă denumirea este unică, controlorul va dispune, către Model, de creearea unei pagini componentă facebook denumită FB_X, unde X este denumirea introdusă. Controlorul va notifica Modelul de existența unei scene a unei pagini Componentă Exterioară.

Aceeași implementare este folosită și în cazul operației de creeare componentă twitter(OpC7), dar este rescrisă specific acestei componente.

OpC8: Verificarea operației de adăugare 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ă operație este realizată de metoda verifyOnPage(). În cazul în care întoarce true, se va proceda la afișarea dialogului de adăugare, altfel nu se va executa nimic.

Controlorul poate primi de la model, în orice moment, instanța paginii care este afișată pe scenă folosind operația 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 recunoaște ComponentăExterioară ca fiind de tipul Pagină.

O altă verificare efectuată de către Controlor este unicitatea unui tip de componentă pe pagină. O pagină poate conține o singură componentă facebook.

Dialogul afișat va prezenta, într-o listă, toate componentele disponibile. Utilizatorul alege componenta, apoi, după efectuarea unui click pe butonul OK, va desena zona care să conțină componenta. Această o a doua desenare se dovedește a fi utilă datorită posibilității de reutilizare a componentei în diferite contexte.

După operația de desenare, se trimite către model addComponentaFacebook, împreună cu parametrii generați până acum.

În cazul verificării operației de adăugare componentă twitter, se procedează la o implementare asemănătoare, doar clasele instanțiate diferă. (OpC9).

OpC9: Verificarea adăugării componentelor FBInput, FBHistory, FBPicture, TWInput, TWHistory, TWPicture. Toate verificările efectuate asupra acestor componente sunt realizate în același mod cu adăugarea unei componente text, singurul lucru care diferă între componente sunt clasele instanțiate și conținutul TextField-ului care le reprezintă.

OpC10: Verificarea operației de adăugare componentă other. În momentul efectuării unui click pe Add Componenta Other se va apela metoda showAddOtherDialog(). Această metodă va afișa dialogul de creeare a unei alte componente, decât cele descrise până acum. În cadrul acestui dialog, se va introduce codul care urmează să fie adăugat direct în pagină.

Capitolul 5

52

După efectuarea unui click pe butonul OK, se va desena locul ocupat de către componentă în pagină. La sfârșitul desenului se va trimite către model addComponentOther împreună cu parametrii ceruți de această metodă.

În cazul acestui dialog, se poate impune o verificare a conținutului înscris. OpC11: Verificarea operației de stergere pagina. În momentul în care se dorește o ștergere

de pagină, se efectuează operația de click dreapta în aplicație. Se va afișa meniul Flash împreună cu două opțiuni: Modifică/Sterge Pagină sau Modifică/Sterge Componentă.

În cazul selecției Modifică/Sterge Pagină, se va trimite către model showModificaStergePagina(). Se va afisa un dialog care va conține două liste: Prima listă conține operația aleasă, a doua listă va conține paginile asupra căroroa se executa operația.

După alegerea operației/ paginii, se verifică și celelalte intrări și în cazul unei erori se afișează eroarea cu codul 2, dacă nu se vor efectua intrucțiunile descrise prin notificarea modelului a alegerii făcute.

OpC12: Verificarea operației de stergere componenta. Se realizează în mod asemănător cu OpC11, diferă doar condițiile descrise de input-ul disponibil acestui tip de operație. Codul de eroare este 6.

OpC13: Verificarea operației specifice butonului Site Map. La efectuarea unui click pe butonul Site-map, se vor afișa două componente. Prima componentă prezintă link-urile descrise în o pagină aleasă de către utilizator. De aici ele pot fi șterse, la nevoie. Pagina aleasă va fi prezentată într-o listă în partea stângă a componentei, linkurile disponibile în partea dreaptă. Toate aceste informații sunt afișate prin apelarea funcției showSiteMap() a Modelului.

A doua componentă a dialogului oferă posibilitatea setării unei publicității a paginilor creeate. Dacă o pagină este publică, ea poate fi afișată oricând. Dacă o pagină este privată, ea este disponibilă doar administratorului, iar dacă este setată ca fiind logat, conținutul poate fi vizionat doar de către utilizatorilor logați pe o rețea de socializare. Dacă această opțiune este activată, toate paginile sunt de tipul php.

Operația de setare a publicității este realizată în model folosind operația setAccesPage(). Această metodă primește ca parametrii numele paginii și opțiunea aleasă.

OpC14: Verificarea operației de setare a textului. În cadrul acestei operații sunt introduse toate funcțiile care verifică orice opțiuni legate de particularizarea elementelor text. Aceste verificări sunt realizate prin citirea poziției de început și sfârșit a selecție textului, apoi notificarea Modelului a schimbărilor realizate. Ele sunt descrise în Tabelul 5.4.

Denumire

Buton Atribut al textului

Metoda apelată Model

Informații suplimentare

B Bold setBold(start, end) - I Italic setItalic(start, end) - U Underline setUnderline(start, end) -

AlignCenter Align:center setAlign(“center”) Align influețează tot

textul

AlignLeft Align:left setAlign(“left”) Align influețează tot

textul

AlignRight Align:right setAlign(“right”) Align influețează tot

textul

AlignCenter Align:center setAlign(“center”) Align influețează tot

textul ColorPicker Color setColor(color,begin,end) -

Capitolul 5

53

Create Hyperlink setHyperlink(linkTo,begin,end) Setează un hyperlink Tabelul 5.4 Elementele componentei Text În cazul elementelor hyperlink, după ce sunt adăugate, controlorul asigură existența

hyperlinkului, până în clipa în care tot textul linkul-ui este șters. Aceasta se realizează prin o metod a controlorului care se activează de fiecare dată când o tastă este apăsată. Dacă se adaugă caractere în hyperlink, acesta va crește în lungime, dacă se șterg acesta va fi scăzut până nu va mai conține nici un caracter. În cazul unei introduceri greșite a informațiilor legate de hyperlink, se efectuează eroarea 5.

OpC15: Verificarea operației de drag. Dacă se efectuează o operație de CTRL+CLICK pe orice element al oricărei pagini, se începe operația de drag a componentei. Controlerul notifică Modelul de existența unui startDrag().

Componenta este modificată, la nivelul obiectului care îl reprezintă, abia după finalul operației de desenare, folosind metoda updatePositionElement(). Pe parcursul repoziționării, se vor respecta condițiile impuse în cadrul operației OpC2.

OpC16: Verificarea operației de resize. Această operație este valabilă asupra oricărei element în oricare tip de pagină. Ea este realizată în momentul execuției unei operații de tipul SHIFT+CLICK în colțul dreapta jos a unei componente.

Implementarea acestor operații se realizează într-un mod asemănător cu OpC15, diferența constă în existența unei limite de redimensionare. Metoda apelată de către controler la sfârșitul operației de desenare : updateResizeElement();

OpC17: Operațiile de Generare XML/LoadXML. Operația oferită de către controlor este una minimală, se trimite către Model poziția de unde se încarcă/salvează fișierul XML.

Fiecare element al paginii va conține un set de EventListener, specific tipului său.

Controlerul reprezintă totalitatea de funcții care sunt apelate în cazul, unui Event, el transmite mai departe către Model ce trebuie schimbat în scenă, sau ce operații trebuie realizate, după cum șablonul Model-View-Controler cere.

Nu există pre condiții legate de editare, fiecare intrare este verificată de platforma Flash, nu se pot trimite obiecte null către Controlor. Post-condițiile controler-ului se referă la totalitatea de schimbări realizate de controler.

5.2.1.6 Modelul

Aplicația implementează o serie de funcționalități prevăzute în capitolul de analiză. Acestea sunt puse în practică prin intermediul unor operații.

Operațiile implementate de către aplicația Flash sunt: • Adaugare/eliminare componente text • Adaugare/eliminare componente imagine • Adaugare/eliminare componente exterioare • Adaugare/eliminare pagini

5.2.1.6.1 Operații legate de pagini

Site-ul conține un număr maxim de 42 de pagini. Această constrângere este aleatoare,

mărirea numărului maxim de pagini se poate realiza oricând prin modificarea unei singure variabile.

Variabila se numește nMaxPagini:int, variabilă globală. Mărirea numărului maxim de pagini atrage o problemă la nivelul elementelor vizuale. Butoanele tab nu sunt suficiente pentru

Capitolul 5

54

acoperirea afișării tuturor paginilor, se poate creea o listă care înlocuiește butoanele tab, si cuprinde toate paginile aplicației.

OpM1: Opeația de adăugare pagina. Fiecare pagină adăugată va primi o denumire, împreună cu o relevanță față de întregul site. După definire, atributele paginii pot fi modificate printr-o funcție specială.

Implementarea acestei operații primește o abordare simplă. Controlerul a verificat consistența valorilor trimise, acum urmează operația de creeare a unei noi pagini folosind clasa Pagina. Obiectul nou creat este adăugat în Array-ul dedicat tuturor paginilor, intitulat „pagini”. După adăugare, pagina nou creată va primi focus, adică va fi în prim plan, prin setarea variabilei paginaSelectata = paginaNoua.

Variabila paginaSelectată păstrează obiectul de tipul Pagina specific paginii afișate pe ecran. Benificile acestei abordări sunt motivate în momentul adăugării elementelor în pagină. În loc să se execute o căutare la fiecare adăugare, se păstrează obiectul și este prelucrat direct.

OpM2: Clonarea Paginilor. O opțiune importantă în creeare paginilor este posibilitatea de clonare a unei pagini deja existente. Cand se creează o nouă pagină, există o opțiune care permite clonarea unei pagini din rândul de pagini existente. Rezultatul va fi o pagină care va conține clone ale elementelor din pagina sursă.

Fiecare obiect de tipul Pagină oferă o metodă de clonare. În clipa generării unei noi pagini, pagina nouă va fi referențiată către clona obiectului Pagina, apoi se vor modifica parametrii obiectului clonă conform informațiilor oferite de utilizator. Următoarele etape sunt aceași cu operația de adăugare pagină.

OpM3: Adaugare/stergere pagini. Paginile pot fi adăugate/șterse la cerere, cu excepția paginii index. Stergerea unei pagini nu afectează logica aplicației. Singurul impediment care poate apărea în o operație de ștergere este de consistență linkurilor paginilor exterioare către pagina care urmează a fi ștearsă. Utilizatorul trebuie să verifice conținutul fiecărei pagini în parte, dacă există vreo legătură. Această verificare poate fi realizată în mod automat, ștergerea find de asemenea automată.

Implementarea operației de ștergere pagină este realizată prin eliminarea paginii din Array-ul pagini. După verificarea existenței paginii de către controler, ea va fi trimisă spre eliminare în model.

5.2.1.6.2 Operații legate de componente

Fiecare pagină va conține componente text, imagine și componente exterioare. Acestea

sunt adăugate în pagină prin poziționarea lor de către utilizator. Ele pot fi editate, repoziționate sau redimensionate.

Controlorul verifică dacă aceste operații sunt realizate corect, dar logica de modificare a elementelor paginii este descrisă în model.

OpM4: Operația de poziționare/ adăugare element text este realizată în mai multe etape:

• după selectarea operației se alege poziția din colțul stânga sus al elementului text • în timp ce mouse-ul este apăsat se desenează un dreptunghi care simbolizează

aspectul viitoarei componente în pagină • la lăsarea click-ului se va deschide un meniu care va cere introducerea unor

informații legate de noua componentă • la selectarea butonului OK se trimite spre generare noua componentă

Capitolul 5

55

Generarea noii componente este făcută în model folosind metoda generateText. După generearea obiectului de tipul ComponentaText, el este adăugat în componentele paginii selectate folosind instruncțiunea:

paginaSelectata.addComponenta(newComponentaText). Operațiile de verificare a poziționării corespunzătoare a componentei text este realizată de

către Controler: OpC2 Operația de desen a dreptunghiului este realizată la cererea Controlerului. OpM5: Modelul conține doar operația de generare/modificare a dreptunghiului. Această operație se realizează folosind o variabilă globală drawDreptunghi. Aceasta este

redesenată de către model, de fiecare dată când Controlerul o cere. Modelul cunoaște doar de existența dreptunghiului și desenarea acestuia, nu ce face utilizatorul.

Implementarea acestei operații este realizată în mai multe etape. Inițial se elimină dreptunghiul din scenă folosind operația removeChild(drawDreptunghi). Acesta este regenerat folosind parametrii trimis de către Controler, apoi adăugat în scenă folosind addChild().

OpM6: Operația de poziționare/ adăugare element imagine este realizată în mai multe etape:

• spre deosebire de operația anterioară, informațiile legate de imaginea selectată sunt cerute înainte de adăugare

• după specificarea informațiilor, imaginea este încărcată in model, urmând să se repete operația de desenare a imaginii intr-un mod asemănător componentei text; în loc de dreptunghi se va afișa imaginea

• după desenare imaginea rămâne pe scenă. Adăugarea componentei de tipul ComponentaImage se realizeză la sfârșitul operației de

desen. Implementarea adăugării ComponentaImagine în paginaSelectată este la fel. OpM7: Operația de încărcare a unei imagini este realizată în mai multe etape. Aceste

etape vor conține și informații legate de codul de adăugare: Imaginea este încărcată folosind operația de load() a unei instanțe a clasei FileReference.

Această operație cere utilizatorului să aleagă un fișier, apoi încarcă informația în formatul de tipul ByteArray.

După încărcare, informația este introdusă într-o instanță a obiectului Loader. În procesul de desenare a elementului de imagine, se va afișa imaginea desenată, redimensionată în funcție de preferințele 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 adăugată în arrayul de componente a paginii

Parametrii componentei Loader sunt încărcații folosind un addEventListener în cazul evenimentului de inițializare. Această abordare este considerată standard în implementăriile care conțin loader.

OpM8: Editarea textului, operația de setare font, marime, align, bold, italic, underline și culoare. Fiecare componentă text poate fi modificată de către utilizator. Modelul primește de la Controlor prin operația OpC14 ce dorește să fie modificat în scenă.

Metodele oferite de către Model sunt introduse în Tabelul 5.4. Aici sunt descrise care metode se apelează și parametrii trimiși.

Implementarea acestor operații este realizată folosind setTextFormat(myFormat), unde myFormat este un obiect de tipul TextFormat, care conține toate tipurile de atribute specifice unui TextField. Această metodă poate fi folosită la nivelul întregului text, sau doar în zone specificate de utilizator.

Capitolul 5

56

Pre-condiții: nu există, selecția este trimisă de către Flash. Dacă nu a fost efectuată o selecție, opțiunea se aplică pe tot textul. Post-Condiții: Textul să fie modificat.

OpM9: Adăugare de link-uri. Operația de adăugare de linkuri conține 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-condiții: creearea unui obiect valid Hyperlink, post-condițiile de la OpM9. OpM10: Operația de tipul drag a componentelor. Controlorul trimite către Model operația

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 operații se bazează pe parametrii trimiși de către Controlor. Metoda updatePositionElementTemp() primește trei parametrii: x,y:int – repezintă poziția 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 sfârșitul operației de desenare, când este apelată metoda updatePositionElement().

Pre-condiții:nu există, controlorul este verificat de post-condiții. Post-Condiți: Elementul să aibă noua valoare xy diferită de vechea valoare, noua valoare să corespundă elementului vizual, iar celelate să rămână la fel.

OpM11: Operația de tipul resize a componentelor. Această operație se aseamănă cu cea de tipul drag, elementele schimbate sunt w și h, adică lungime(w) și înălțime(h). Metoda se denumește updateResizeElement()/upateResizeElementTemp(), iar operația din Controlor care apeleză metoda este OpC16. Valorile noi sunt transmise de către Controlor.

Pre/post-condițiile sunt cele de la OpM10. OpM12: Adăugarea de componentă exterioară facebook.com. Controlorul trimite către

model metoda addComponentaFB(). Această metodă adaugă în pagina afișată, paginaSelectata, noua componentă. Adăugarea este făcută prin instanțarea unui obiect de tipul ComponentaExternaFB, și adăugarea acesteia la pagină folosind instrucțiunea addComponent.

Legătura dintre ComponentaExternaFB și pagina de tipul Componenta Exterioara este făcută prin valoarea unui atribut comun nume. Obs: nu se poate adăuga mai mult de un tip de componentăFB în pagină.

Post-condiții: componenta exterioară să fie inserată în pagină. OpM13: Adăugarea de componentă twitter.com. Implementarea este realizată în același

fel ca în cazul OpM12. Aceeași post-condiție ca OpM12. OpM14: Adăugarea de componentă other. Cotrolorul trimite către Model, prin operația

OpC10, textul care urmează să fie adăugat în pagină. Modelul creează un nou obiect de tipul ComponentaExterioaraOther și atributul „conținut” primește valoarea trimisă de Controlor. În următorul pas, Modelul adaugă componenta în paginaSelectată apoi desenează componenta pe scenă.

Componenta desenată va fi de tipul TextField, iar marimea acesteia este definită de către Controler.

Post-condiții: obiectul de tipul ComponentaExterioaraOther să nu fie null; obiectul să fie desenat pe scenă.

OpM15: Stergerea unei componente. Implementarea operației de ștergere se realizează prin eliminarea obiectului componentă din obiectul de tipul Pagină, folosind metoda removeComponent. Eleminarea obiectului din scena aplicației se realizează prin apelarea funcției redrawStage, care redesenează paginaSelectată.

Capitolul 5

57

5.2.1.6.3 Operații speciale OpM16: Generare SiteMap. Această operație prezintă o serie de etape. Prima etapă este

de update. Acum se încarcă listele paginilor și a linkurilor. La cererea Controlorului, se face operația de update listă link folosind metoda updateListLink(pagina). Acest lucru se realizează prin parcurgerea tuturor componentelor paginii, iar în cazul componentelor text, se va afișa linkul și pagina către care face referire.

A doua etapă reprezintă setarea publicității site-ului. Această operație este acoperită de OpM16.

Nu avem post-condiții. OpM17: Publicitatea site-ului. Operația de publicitate este realizată prin

afișarea/modificarea accesului la o pagină. Controlorul apelează Modelul prin operația OpC13. Implementarea acestei operații se realizează prin setarea atributului access a obiectului de tipul Pagina a cărui nume este trimis de către 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 primește valoarea trimisă de către Controlor.

Pre-condiții:nu există, parametrii sunt verificați de post-condiția Controlorului. Post-condiții: să fie modificată valoarea.

OpM18: Logica de afișare a erorilor generate de Controler. Afișarea dialogului de eroare este realizată prin funcția showErrorNo. Această funcție afișează textul erorii primite de la Controler și atribuie butonului OK un comportament. Numărul fiecărei erori a fost specificat în cadrul Controlorului.

Selecția dialog-ului care urmează a fi afișat se realizează prin operația case asupra variabilei care conține eroarea.

Post-condiții: Verificarea operației de ștergere prin parcurgearea tabloului pagini. OpM19: Operația de generare XML. Această operație transformă obiectele de tipul

Pagina în formatul XML. Implementarea este realizată prin parcurgerea tuturor paginilor din tabloul uni-dimensional. În cadrul fiecărei pagini se vor adăuga componentele în variabila de tipul String XML . Conținutul imaginilor jpg este adăugat într-o altă variabilă.

La sfârșitul parcurgerii se transforma XML în formatul byte și este aduăgat în variabila result. În următorul pas se adaugă conținutul imaginilor în result.

Rezultatul este scris într-un fișier în locația trimisă de către Controlor. OpM20:Operația de încărcare XML este asemănătoare cu cea de încărcare XML a

aplicației Generator. Se parcurge tot fișierul, se transformă tablul citit în String. Descrierea transformării din String în obiecte de tipul Pagină este făcută în același mod ca operația OpG3.

Toate operațiile dețin o post-condiție comună: afișarea dialogului/scenei în mod

corespunzător.

5.2.2 Standardul XML

Formatul general al fișierului XML este de tipul Extensible Markup Language. Fiecare element este descris folosind simbolulrile: < / >, unde <componenta> reprezintă începutul descrierii elementului „componenta” , iar </componenta> descrie sfârșitul elementului componentă.

Aplicația Flash conține 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:

Capitolul 5

58

<obiectX> <atribut>valoare1 </atribut> <atribut2>valoare2</atribut2> </obiectX> Oiectul ObiectX are două atribute, iar fiecare atribut are are valoarea descrisă în interior. Respectând 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 fișier mai conține o serie de tag-uri. Aceastea sunt de tipul <jpg> și conțin două

elemente. Primul este intitulat <end> și conține lungimea conținutului elementului, urmat de conținutul fișierului jpg în formatul tablou unidimensional de tipul byte.

Tag-urile <jpg> sunt adăugate la sfârșitul fișierului, în ordinea invocării lor în descrierea paginilor web.

Fișierul nu trebuie codificat, o codificare ar schimba conținutul fișierului jpg prin reorganizarea informației. Orice aplicație care va citi fișierul trebuie să il citească ca un șir de byte, nu ca un șir de caractere. Exemplu: transformarea fișierului în caracrere unicode nu va permite afișarea imaginilor.

Capitolul 5

59

5.2.3 Aplicația JSP

Operațiile efectuate de către această aplicație sunt minimale. Aplicația JSP se conectează la Generator, trimite fișierul și primește rezultatul în formatul ZIP. Al doilea tip de operație este de afișare a fișierelor generate

5.2.3.1 Platforma Aplicației

Aplicația este scrisă în NetBeans – o platformă pentru aplicații desktop Java, medii integrate de developement (IDE), javaScript, php, etc. Această aplicație este scrisă în limabjul Java și funcționează pe orice mediu care permite instalarea JDK și JVM.

Această platformă este folosită atât în dezvoltarea aplicației JSP, cât și în dezvoltarea Generatorului Web.

Motivele selecției acestei platforme: • oferă o implementare pentru dezvoltarea aplicațiilor WebService • permite debug la orice nivel al aplicației • multitudinea de limbaje implementate (proiectul folosește JSP și php) • mediu ușor de folosit

5.2.3.2 Implementarea operațiilor

Aplicația JSP va conține trei pagini de tipul JSP, specifice operațiilor oferite.

I. Prima pagină, create.JSP, va conține Aplicația Flash împreună cu câteva informații afișate în formatul HTML.

Un fișier de tipul SWF poate fi adăugat într-o pagină HTML folosind fie metode statice, scrise ca obiecte HTML, fie dinamice, scrise în javaScript. Aplicația Flash este adăugată static, astfel încât aplicația să funcționeze și în cazul unui browser care nu implementează javaScript.

Codul general de afișare: <object width="800" height="600">

<param name="movie" value=" AplicatieFlash .swf"> <embed src="AplicatieFlash.swf" width="800" height="600" />

</object> Această abordare afișează conținutul Flash, fără să verifice dacă aplicația Flash Player

este instalată. Această ipoteză este rezolvată prin adăugarea unui element de tipul div în care se va adăuga următorul 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 afișează butonul pentru instalare a aplicației Flash Player. Pe lângă acest conținut, se adaugă elementele de fundal împreună cu câteva informații

text.

II. A doua pagină este cea de generare, generate.JSP. În cadrul acestei pagini se încarcă fișierul XML trimis și se trimite către Generatorul Web. După returnarea rezultatului se va reîncărca pagina, oferind două opțiuni:

a. Vizualizare Rezultat b. Download Fișier ZIP

Capitolul 5

60

Opțiunea de vizualizare va trimite către ultima pagină a aplicației. A doua opțiune va downloada fișierul pe mașina locală.

Pagina generate.JSP va conține două stări. Prima stare reprezintă starea inițială în care se va afișa dialogul de încărcare fișier. A doua stare va afișa dialogul cu opțiunile prezentate mai sus, împreună cu dialogul afișat în prima stare. Pagina se va păstra în această stare până la întampinarea unei erori, când se va reîntoare în starea inițială prin afișarea unui mesaj de eroare, sau când se consoderă conexiunea cu utilizatorul terminată.

Starea afișată este definită de o variabilă de tipul boolean în logica de operații a paginii JSP – afiseazaDialogDownload. Dacă valoarea este false, se va afișa doar dialogul specific stării inițiale. Dacă valoare este true, se va afișa și dialogul pentru download/vizualizare.

În caz de eroare la citire/trimitere, se va afișa un mesaj de eroare pe pagina Erori.JSP, apoi se va face redirect către generate.JSP în starea inițială.

Tot această pagină prezintă logica de conexiune către un serviciu Web. Aplicația JSP cunoaște de existența Generatorului împreună cu fișierul WSDL al Generatorului. Generate.JSP trebuie să se conecteze la servici, să trimită fișierul XML. Rezultatul oferit de către serviciu este trimis înapoi către Generate.JSP în formatul ZIP.

Conexiunea este realizată folosind Clientul Web Service oferit de către NetBeans. Acest client implemenează codul cerut pentru transmitere/recepție mesaje de tipul SOAP.

Singurul pas în realizarea de transmisie/primire este realizat de către următoarea porținue 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 conține arhiva zip a site-ului. Fișierul XML trebuie

codificat în forma de tipul Array de Byte. Motivul folosirii colecțiilor array de tipul byte este dat de necesitatea unei lipse de

codificare, care să permită re-generarea diferitelor tipuri de fișiere incluse. Array Byte este un tip primitiv care nu codifică conținutul în nici o formă.

III. Ultima pagină afișează conținutul generat – afisare.JSP. Operația de afișare este

realizată în interiorul unui internal frame. Astfel, orice operație realizată în interiorul frame-ului nu va influența funcționarea Aplicației JSP.

Prima etapă este decodificarea fișierului de tipul ZIP. Java oferă o librarie de arhivare/dezarhivare a fișierului de tipul ZIP denumită java.util.zip. Prin dezarhivare, Aplicația va genera fișierele cerute în interiorul aplicației jsp.

Următoarea etapă afișează conținutul generat de către aplicație în internal frame-ul paginii afisare.JSP. Se va afișa pagina index.html.

Capitolul 5

61

5.3 Site Web 3.0

Rezultatul generatorului este Site-ul Web 3.0. Acesta conține paginile generate de către Serviciul Web. Site-ul conține trei tipuri de pagini: pagini generate de către utilizator, pagini specifice fiecărui site generat și pagina de social dashboard.

5.3.1 Pagini specifice fiecărui site

Seturile de pagini specifice fiecărui site generat sunt: logare, indexAdmin, adaugar Pagina, eliminare Pagina și schimbare parola. Fiecare conține un set de operații 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 operația 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 afișate sunt creeate folosind limbajul HTML. Logica pentru logare va fi conținută în o nouă pagina loginTry care va verifica dacă elementele trimise sunt corecte. Dacă logarea este reușită se face redirecționare către indexAdmin, dacă nu se afișlează o eroare în fișierul logareError, apoi se trimite către logare.php.

Pagina indexAdmin prezintă o serie de opțiuni: • Modificare parolă • Adăugare pagina • Modificare/Eliminare pagină • Download backup (XML)

OpS2:Modificarea parolei este realizată în o nouă pagină denumită schmbareParola. Această pagină citește vechea parolă o singură dată și noua parolă de 2 ori. După confirmare, se va rescrie fișierul loginTry ca să conțină 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 fișierului într-o variabilă; parcurgerea variabilei până î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 conține parola care trebuie verificată dar nu va fi oferită la citirea paginii prin vizualizarea codului scris, ea este inserată în porțiunea de cod server-side.

În cadrul acestei operații se pot introduce conturile aplicațiilor Web 2.0. OpS3:Operația de adăugare de pagină din site este realizată folosind metoda de clonare a

unui site deja existent. Implementarea acestei operații se realizează într-un mod asemănător cu operația de resciere a parolei. Inițial se va citi fișierul care urmeză a fi clonat, se va crea un nou fișier de acest tip, apoi va fi scris ca o nouă pagină în interiorul site-ului. Următorul pas în creearea noi pagini este modificarea conținutului său folosind operația de modificare pagină.

Pre-condiții: Numele paginii sa nu existe în aplicație; Post-condiții: Pagina sa existe. OpS4:Operația de modificare pagină este realizată folosind o parcurgere a paginii. După

formarea obiectului se va folosi un algoritm de transformare în format XML, urmând 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 adăugare element in xml

Capitolul 5

62

După generare, pagina va conține o serie de elemente HTML input, care conțin elementele din pagină. Administratorul va vedea doar o listă de elemente ale paginii împreună cu conținutul lor. După finalizarea editării elementelor, va folosi metoda de update care va modifica conținutul paginii. Conținutul este modificat folosind operația de rescriere a fișierului.

Implementarea funcțiilor de citire și de scriere se realizează folosind file_get_contents/file_write_contents.

Pre-Condiții: să nu existe limbaj html în pagină. Post-Condiții: creearea unui fișier HTML. OpS5:Operația de Eliminare a unei pagini se realizează prin ștergerea ei folsind umătorul

cod: $fisier = ‘locatie.php’; unlink($fisier); Metoda unlink () șterge fișierul și returnează true dacă fișierul a fost șters cu succes, false

dacă nu. Robustețea aplicației este asigurată prin folosirea instrucțiunii try-catch asupra operației de ștergere, deși accesul către fișierul care urmează a fi șters este garantat.

Post-Condiție: operație realizată cu succes. OpS6:Operația de download fișier XML oferă posibilitatea de download a copiei în

formatul standard a Generatorului. Implementarea operației este realizată prin citirea fișierului backup.XML, apoi este scris acolo unde dorește utilizatorul.

Metodele folosite în citirea/scrierea fișierului sunt aceleași ca în cazul operației de adăugare pagină.

Post-Condiție: operație realizată cu succes.

5.3.2 Paginile generate de utilizator

Aceste pagini sunt generate de către aplicația Generator și pot fi modificate la cerere. Ele sunt scrise în Limbajul HTML, pentru elementele HTML, și JavaScript/php, pentru elemente ale aplicației exterioare.

Elementele HTML sunt de forma: text, imagine. Elementele Exterioare: facebook, twitter, alte componente exterioare.

Elementele text sunt adăugate î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 conține un corespondent CSS care va conține tipul de font, marime și alte opțiuni specifice elememtului adăugat.

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 conține logica de argumentare a legăturii dintre pagină și componenta text. Un exemplu RDF:

<?xml version="1.0"?>

Capitolul 5

63

<rdf:RDF> <rdf:Description rdf:about=paginaCareConțineElementulText> <contine>denumireElementText</contine> <relevanta >relevantaFataDePagina</relevanta> </rdf:Description>

</rdf:RDF> În acest exemplu se stabilesc două fapte legate de pagina nou creată. Subiectul la

amândouă este paginaCareConțineElementulText. Predicatul primei propoziții este: „conține”, obiectul este: „denumireElementText”.

Propoziția formată în limbaj natural este: paginaCareConțineElementulText conține denumireElementText. A doua propoziție formată: Relevanța elementului față de paginaCareConțineElementulText este relevantaFataDePagina. Împreună formează următoarea frază: Pagina paginaCareConțineElementulText conține denumireElementText a cărui relevanță față de paginaCareConțineElementulText este relevantaFataDePagina.

Aceași abordare este folosită în cadrul implementării tuturor elementelor în pagină. Singurul lucru care poate fi diferit între tipurile de elemente sunt predicatele asociate legăturii de tipul RDF.

Elementul imagine este adăugat folosind parametrul <img>. Src este sursa imagini, paramterii alt, link sunt introduși de către utilizator. Poziționarea în pagină cât și înălțimea/lungimea sunt oferite prin folosirea CSS.

Exemplu CSS: .clasa{ Position=”absolute; Left = x; Top = y;

Width = w; Height = h;

} În cadrul definirii fiecărui element, se va preciza class=”clasa”, astfel elementul adăugat

va respecta regula CSS stabilită pentru clasă. Aceeași abordare este folosită și în cazul celorlalte elemente ale paginii.

Asemănător cu componenta anterioară, denumirea imaginii se va păstra prin adăugarea unui tag înainte de inserarea imaginii, astfel imaginea este atribuiră în formatul CSS folosind denumirea din TAG.

Elementele exterioare sunt adăugate după tip. În cazul Componentei Exterioare Other se va adăuga codul direct în pagină. Acest lucru poate să creeze erori în pagină, dar sintaxa codului este verificat de către Editor. În cazul în care nu funcționează componenta, browserul va afișa simbolul broken, administratorul poate rescrie/elimina componenta din pagina de administrare.

Adăugarea în pagina HTML este realizată în mod asemănător cu celelalte elemente prin tagul special. Tag-ul va fi de forma: <ComponentaOther>.

Componenta Facebook este adăugată în site folosind codul oferit de către Graph API de pe site-ul facebook developers. Pentru a putea folosi Graph API în interiorul unui site, este nevoie de un Facebook App, aplicație în care utilizatorii își dau consimțământul asupra procesului de primire/prelucrare informații primite de la facebook.

Graph API oferă informațiile 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 funcționare sunt descrise în linkul numărul [55].

Capitolul 5

64

Folosind un Facebook App, utilizatorul facebook permite acces de citire și adăugare de informații componentei Site, din interiorul unui app. Acest acces este concretizat prin setarea unui privilegiu către access_token-ul Facebook App. Site-ul se poate conecta la facebook și poate cere informații, exemplu: poza, nume, wall, like, etc, sau poate trimite informații, exemplu :publicare pe wall, publicare pe o pagină, etc.

Această componentă cunoaște două stări: login și logedin. Starea de login va afișa butonul de logare folosind facebook. Operația de afișare buton

logare împreună cu operația de logare sunt standarde oferite de facebook.com. Acestea sunt definite în linkul [56] și se folosesc în același mod în cadrul oricărei aplicații care permite logare prin facebook. Implementarea va conține doar o copie a acestul cod.

Odată realizată logarea, pagina va fi reînprospătată trecând în starea logedIn. Acum utilizatorul vede componenta desenată de către Administrator. Aici utilizatorul poate să adauge conținut sub forma de comment Facebook în Facebook App, rezultatul fiind vizibil doar pe paginia Site-ului.

Implementarea acestei funcționalități este realizată folosind Graph API, iar paginile afișate vor parcurge rezultatul primit de la graph.facebook.com, urmând să afișeze doar infromația relevantă la pagină.

Pagina de social dashboard se comportă în același fel ca paginile de logare, diferă doar operațiile apelate.

Componenta twitter.com are un alt comportament față de Componenta Facebook. Comunicarea cu aplicația twitter este realizată folosind un serviciu web de tipul REST. Modul de conectare, împreună operațiile utilizate în implementare sunt prezentate în linkul [57].

Implementarea componentei twitter.com oferă două stări: logIn și logedIn. Prima prezintă un buton care permite logarea folosind contul de twitter. Acest buton este implementat de către cei de la twitter, inserarea lui în pagină se face parcurgând o serie de etape, linkul [58].

A doua stare este desenată de către utilizator, iar logica de adăugare tweet pe pagină este realizată prin arhitectura de tipul REST.

5.3.3 Pagina Social Dahsboard

Capitolul 3, cel dedicat Studiului Bibliografic, prezintă câteva criterii de analiză a

rețelelor de socializare. Selecția celor două aplicații Web 2.0 se bazează pe această analiză. Facebook.com

• Data Hub Activities – adăugare conținut în interiorul paginii personale, oferit spre vizualizare și comentare a celorlalți utilizatori

• Social Network – permite adăugare de conținut în interiorul altor aplicații • Social Source Referral – nu este realizată • Social Source & Action – acțiune de adăugare conținut; adăugare comentarii

asupra conținutului 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 adăugare conținut/ jocuri sociale

Twitter.com • Data Hub Activities – adaugarea conținut pe site-ul personal; raspuns la conținutul

adăugat de alți utilizatori; • Social Network – permite adăugare de conținut în interiorul altor aplicații • Social Source Referral – nu este realizată

Capitolul 5

65

• Social Source & Action – adăugare de conținut 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 conținutului afișat de un target de utilizatori

Analiza scurtă descrisă mai sus prezintă o serie de concluzii:

1. aplicațiile permit adăugarea de conținut în interiorul altor pagini, fapt urmărit de către aplicație

2. existența unei ramuri de developers care descrie, în detaliu, modul de conectare la aplicații

3. adăugarea este menționată în interiorul aplicațiilor web 2.0, consecință benefică prin prezentare conținutului și în cadrul platformelor

4. ambele permit logarea în diferite site-uri – se poate urmării cine adaugă conținut și cand; elimină necesitatea creeari unei logici de logare, ea este implementată de aplicațiile Web 2.0

5. posibilitatea de control a aplicațiilor Web 2.0 din exterior Aceste cinci avantaje reprezintă motivul selecției celor două aplicații în implementarea

ramurii de Social Dashboard. Ramura social dashboard permite citirea conținutului aplicațiilor Web 2.0, apoi permite adăugarea de conținut în interiorul aplicației.

Citirea este făcută prin afișarea elementelor de wall și a notificațiilor. Scrierea se face prin adăugarea conținut pe wall. Implementarea operațiilor de citire din aplicații Web 2.0/scriere în aplicații Web 2.0 se realizează folosind metodele oferite de platforme Web 2.0. Legăturile către metode au fost prezentate în subcapitolul 5.3.2.

Metodele apelate de către Site: • login • afișare poză • afișare adăugare comment/tweet • adaugă comment/tweet

5.4 Generatorul Web

Această aplicație transformă formatul trimis de către Editor (XML) în formatul de tipul ZIP. Această funcționalitate este realizată în mai multe etape. Prima etapă transformă XML în obiecte specifice componentei Editor. Această transformare este necesară pentru stabilirea elementelor fiecărui site. Se păstrează diagrama de clase prezentată în figura 5.3.

A doua etapă codifică obiectele în limbajul HTML/javaScript/php. Fiecare componentă este adăugată atât în porțiunea de head cât și de body a fișierului HTML. Transformarea se face la fel pentru fiecare tip de componentă.

Ultima etapă este arhivarea. Toate fișierele sunt adăugate într-o arhivă zip, apoi trimise către utilizator spre download/verificare.

Motivele arhivării în formatul ZIP: • Economisire spațiu • Transmitere rapidă • Toate fișierele sunt puse într-o singură arhivă, nu este necesară trimiterea mai

multor fișiere Citirie/scrierea în formatul ByteArray[] păstrarează lipsa de codificăre a conținutului

fișierelor, pentru a nu modifica fișierele/datele din interiorul site-ului. Exemplu: Citirea și

Capitolul 5

66

scrierea în formatul String va schimba codificarea fișierelor JPG, ele nu pot fi citite după conversia în UTF-8 , specific Java String. Soluția aparentă este folosirea unui conversii spre Base64String; elementele jpg vor fi afișate, dar alte elemente, exemplu video, nu vor funcționa.

5.4.1 Tehnologia Web Service

Modul de funcționare 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 către Java, implementat de aplicația NetBeans.

Folosind această implementare, utilizatorul trebuie să specifice tipul de operație folosit(statefull sau stateless), împreună cu logica de implementare a operațiilor, restul logicii este realizat de către NetBeans. Fișierul de tipul WSDL poate fi oricând preluat folosind instrucțiunea Generate and Copy WSDL a platformei NetBeans.

Aplicația generator conține o clasă serviciu web și o clasă în care sunt detaliate operațiile efectuate în procesul de generare. Clasa serviciu web este intitulată Generator WS, este de tipul stateless – nu pătrează stare, și prezintă operațiile de afișare și generare.

OpG1: Operația de afișare a unei documentații a intrărilor se numește getInfo. Această

funcție nu primește nici un parametru și întoarce un String care conține documentația. Acest String se află în a doua clasă și poate fi accesat folosind operația getInfo. Această ieșire joacă rolul documentației prezentate în capitolul 4.

Pre-condiții: nu există; Post-condiții:rezultatul să nu fie de tipul null. OpG2: Operația de generare. Această operație se desfășoară 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 transformareîn 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-condiții: XML să fie în formatul cerut. Post-condiții: fișierul arhivat să fie de tipul

ZIP. Clasa care implementează operațiile efectuate se numește Operații și este prezentată

individual.

Capitolul 5

67

5.4.2 Operațiile Generatorului web

Această aplicație transformă din formatul XML în fromatul de tipul ZIP. Formatul XML cuprinde informația generală legată de fiecare pagină, împreună cu elementele cuprinse de aceasta. Pe baza informațiilor oferite aplicația trebuie să fie capabilă să genereze codul HTML/javaScript necesar realizării acestor operații.

Clasa care conține toată logica de transformare este intitulată Operatii și conține o serie de metode statice puse la dispoziția clasei serviciului web. Această clasă conține metodele descirse în codul serviciului web. Acestea sunt prezentate în ordinea etapelor de generare a aplicației:

OpG3: Prima operație 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 citește până la întalnirea </aaa>, apoi se atribuie lui aaa obiectul specific componentei interioare.

Datorită structurii fixe ale fișierului XML, numărul de atribute specifice obiectului aaa este cunoscut. Astfel, generarea se rezumă la o citire și verificare a elementelor citite într-o ordine predefinită în fișierul XML. Unde este cazul, se face conversie.

Algoritmul de generare a unei ComponentaText, privit funcțional: For (int i=0; i<byteArray.length;i++){ If (byteArray[i].toString == “>”) // avem un potențial început/sfarșit de componenta if (ByteArray[i-5,i] == “<text>”)

//logică de început de adăugare text, creeare obiectText if (ByteArray[i-5,i] == “/text>”)

// logică de atribuire text } Implementarea este realizată folosind o serie de condiții, rezolvate folosind instrucțiunea

if, care se ocupă de logica apartenenței unui caracter la o componentă. Nu este folosită instrucțiunea case datorită lungimii variabile a denumirilor. Exemplu <jpg> - 5 caractere, <image> - 7 caractere.

Logica de început de adăugare, 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 adăugat în componentele paginii folosind instrucțiunea addComponent. În următorul pas, obiectText va primi valoarea null, să nu mai conțină referința spre obiectul creat, adăugat în array-ul de componente a paginii.

Această operație este realizată de către metoda statică transformXmlToPages() a clasei Operații. Pre-condiții: nu există, a fost verificat de către metoda generateSite a clasei GeneratorWS; Post-condiții: Fiecare element a rezultatului să nu conțină valori nule sau 0.

OpG4: După creearea structurii necesare generării, se începe o parcurgere a fiecărei

pagini, generând paginile codificate. Această operație este realizată de către metoda generateCode() și primește ca parametru paginile generate anterior, oferind ca rezultat un tablou unidimensional de tipul String; fiecare String corespunde unei pagini codificate. Metoda de parcurgere privită funcțional:

For each (pagina:ComponentaPagina in pagini){ String body =”<body>\n”; //inițializarea elementului body String head= “<html>\n <head>\n” // inițializarea elementului head For each (componenta in pagina.getComponente()){ If (if component aparține de head)

Capitolul 5

68

Head = head + logica generare component Else Body = body + logică de adăugare elemente body logică generare element semantic web } Body = body + “<\body>\n” Head = head + “<\head>\n” Return head + body + “<\html>” } Pre-condiții: nu există, verificarea a fost realizată de operația anterioară; Post-condiții:

rezultatul să fie valid XML. OpG5: Următoarea operație transpune imaginile în formatul byte[]. După cum a fost

definit standardul XML, această operație citește din fișierul XML valoarea informației imaginii JPG.

Parcurgerea imaginii se realizează folosind instrucțiunea “for”, unde indicele pleacă de la 15, lungimea minimă a unui XML, până la lungimea fișierului. Pentru o parcurgere optimă, fișierul XML conține un tag specific fiecărei imagini în care se reține numărul de byte a imaginii. Astfel, aplicația nu citește tot fișierul, ci doar poziția din fișier unde începe și unde se termină imaginea, urmând ca indicele ciclului for să fie mărit cu lungimea imaginii.

Această operație este realizată de către metoda: transformXmlToComponents(). Implementarea este asemănătoare parcurgerii XML pentru definirea obiectelor specifice paginii, cu diferența că se verifică alte tag-uri.

Pre-conditii: nu există, XML este deja verificat; Post-condiții: rezultatul să nu conțină elemente null.

OpG6: Adăugarea de pagini specifice fiecărui site. Aceste pagini se ocupă de setul de funcționalității, descrise în subcapitolul 4.2.1, specifice operațiilor de logare, stergere pagina, adăugare pagină și dashboard. Acestea sunt scrise în limbajul php.

Toate aceste fișiere sunt adăugate într-un folder în interiorul serverului JSP. Generatorul copiază toate fișierele din folder și le adaugă în arhiva ZIP. Această abordare este folosită datorită posibilității de modificare/adăugare/ștergere a fișierelor, fără ca generatorul să fie modificat.

Paginile sunt returnate la apelarea metordi generatePhpFiles() din interiorul clasei Operații. Implementarea acestei clase prezintă o citire a directorului unde se află fișlierele și o scriere în formatul byte a rezultatului.

Aceste pagini sunt detaliate individual în subcapitolul 5.3.1. Pre-condiții: nu există. Post-condiții: rezultatul să nu fie null. OpG7: Convertirea fișierelor formate în arhiva ZIP. Toate paginile sunt adăugate în

variabila String[] de pagini. Acestea sunt adăugate în colecția de fișiere de tipul Byte[]. În această etapă se adaugă fișierele în cadrul aceluiași array, urmând să fie scrise într-un

byte[]. Pentru creearea unei arhive în formatul ZIP sunt necesare două tablouri unidimensionale: unul care informația care urmează adăugat în fiecare fișier și un al doi-lea tablou care conține denumirea fiecărui fișier.

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 către instanța clasei GeneratorWS, apoi către clientul care a cerut site-ul web.

Pre-condiții: nu există. Post-condiții:rezultatul să nu fie null.

Capitolul 6

69

Capitolul 6. Testare şi validare

Acest capitol va prezenta variantele de testare ale aplicației. Asemănător capitolului anterior, se vor prezenta metodele de testare specifice proiectului în ansamblu, apoi metodele de testare/validare specifice fiecărei componente.

Testarea tuturor componentelor este efectuată manual. Testarea automată este realizată pe baza pre/post condițiilor stabilite în capitolul dedicat implementării, capitolul 5. Fiecare condiție este motivată acolo.

Validarea va fi extecutată fie automat, fie manual in funcție 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 funcționări a proiectului, eliminând testarea componentelor, se rezumă la o serie de teste manuale și validări automate asupra comportamentului general al aplicației. Aceste teste/validări asigură funcționarea corespunzătoare a transmiterii informației între componente.

Validarea intrărilor oferite de utilizator este realizată de către: Controlorul aplicației Editor, paginile speciale ale Site-ului și de către intrările Generatorului. Aceste operații validează intrările oferite de către utilizator iar în cazul unei potențiale erori, fie dispune spre model de afișarea erorii în cauză – Editor, fie afișează o eroare pe o pagină individuală – Site, fie afișează un mesaj de eroare - Generator.

Implementarea validării de către controlor este descrisă în cadrul subcapitolului dedicat Controlorului: 5.2.1.5. Implementarea validării prin paginile speciale se realizează prin redirecționarea către o pagină denumită errX, unde X este sursa errorii, urmând ca apoi să se facă o nouă redirecționare către pagina care a găsit eroarea în validare. Intrările serviciului web ale generatorului verifică dacă variabilele trimise sunt de tipul așteptat. În cazul negativ, se va afișa un mesaj.

Rezultate: controlorul funcționează corespunzător, validarea paginilor speciale arată funcționare corectă, afișarea mesajului de la generator este realizată corespunzător. Acestea sunt validări. Nu se verifică rezultatul final.

În cazul fișierului XML, oferit de către utilizator, aplicațiile Editor și Generator validează fișierul XML primit prin parcurgerea acestuia. În cazul în care există erori în sintaxa fișierului XML, se va opri execuția operației și se va afișa eroarea împreună cu locația unde a apărut.

Această validare este implementată folosind instrucțiunea for, care parcurge tot fișierul. Se numără apariția unor tag-uri prin incrementarea unei variabile specifice tagului cu 1. În cazul apariției sfârșitului de tag se va decrementa variabila cu 1. După parcurgere, dacă vreo variabilă este diferită de 0, suntem în prezența unui tag nedefinit corespunzător. Verificarea este realizată în același mod cu verificarea Editorului (subcapitolul 7.2).

Rezultate: Aplicația necesită mai mult timp de execuție din cauza testului. Testele primesc fișiere XML formate corect și fișiere XML formate greșit. Testele au funcționat corect mai puțin în cazul unei ipoteze: dacă sunt amestecate tag-urile în așa fel încât 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 înbunătățirilor (capitolul 8.2)

Arhiva ZIP, care conține Site-ul Web 3.0, este verificată de către Editor după ce este primită de la Generator. În cazul unei erori se va afișa un mesaj corespunzător. Implementarea acestei validări este realizată folosind instrucțiunea try-catch. În cazul unei erori în parcurgerea

Capitolul 6

70

arhivei, se va opri parcurgerea și se va afișa erroarea. Prin această abordare se asigură verificarea oricărei inconsistențe a fișierului trimis spre vizualizare.

6.2.Editor

Verificările/testele realizate în cadrul Aplicației Flash, sunt realizate manual. Adobe ActionScript 3.0, folosit în dezvoltarea Aplicației Flash, permite un singur mod de verificare a variabilelor/intrărilor/ieșirilor, instrucțiunea trace(). Această intrucțiune afișează în terminalul Flash mesajul trimis ca parametru.

Testarea tuturor funcțiilor (intrări/ieșiri) este realizată prin trimiterea unor intrări care pot cauza erori dar care verifică pre-condițiile, apoi se verifică dacă ieșirea respectă post-condițiile.

În cazul în care nu se repsectă o precondiție, nu se va mai executa operația și se va afișa mesajul tipic erorii atât în terminalul Flash cât și sub forma unei Erori generate de către Model. Dacă nu este respectată o postcondiție, se va proceda la afișarea erorii în terminalul Flash, se va dispune la afișarea erorii de către Model și se vor retrage modificările realizate de către metodă.

Implementarea verificăriilor asupra precondițiilor se realizează prin inserarea unor instrucțiuni if în interiorul metodei invocate, înainte de logica de executare a metodei. În cazul în care se găsește o pre-condiție falsă, se va afișa în terminal folosind instrucțiunea trace(”Eroare Pre-Conditie:” + textEroare), apoi se va afișa eroarea de către Model - doErrorPreCon(). După aceste două instrucțiuni se va realiza instrucțiunea break;.

Operația de verificare asupra post-condițiilor se realizează într-un mod asemănător cu verificarea pre-condițiilor. Post condițiile constă în o serie de verificări realizate folosind instrucțiunea if, poziționate la sfârșitul metodei, după logica de executare. În cazul în care o condiție nu este verificată, se va afișa în terminal, se va executa eroarea doErrorPostCon(), se vor schimba toate variabilele/atributele la valorile inițiale, apoi se va executa operația 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 inițiale trace(“Mesaj Eroare”); doErrorPostCon(); break; } } Rezultatele sunt positive, nu s-a reclamat existența unei erori în utilizarea firească a

aplicației; nu s-a afișat nici un mesaj de eroare în terminalul aplicației flash. Valorile trimise greșit ca pre condiție au produs erori, dar nu au existat erori de post-condiții.

Capitolul 6

71

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 Operații. Fiecare metodă, a clase Operații, cuprinde o serie de pre-condiții și post-condiții. Acestea

sunt verificate de către metodele unei clase JUnit, iar în cazul unor erori se va folosi metoda AssertFalse, împreună cu un mesaj care specifică ce condiție nu este verificată.

Implementarea acestei verificări se realizează folosind pre-condițiile și post-condițiile definite în cadrul capitolului 5. Metodele de test sunt scrise folosind o clasă JUnit, generată de pe baza clasei Operații. 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 răspuns sunt corecte; parametrii trimiși variază în funcție de metoda apelată.

Rezultatele testelor arată că aplicația generează și creează elementele corespunzător.

6.4. Site Funcționarea corespunzătoare a paginilor din site este garantată de către Generatorul Web.

Codul generat trebuie să funcționeze î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 către utilizator conțin limbaj HTML, Semantic, componente other și componente facebook/twitter. Corectitudinea codului HTML și Semantic este verificată de către Editor și Generator, corectitudinea componentelor facebook/twitter este realizată de către aplicațiile Web 2.0 specifice. Implementările tuturor verificărilor au fost descrise în capitolul 5.

Singura problemă care poate să apară este la nivelul componentei other. Aceasta poate fi supusă unor verificări asemănătoare cu cea realizată asupra componentei XML.

Paginile specifice fiecărui site sunt verificate în etapa de dezvoltare. Implemenatarea verificărilor se realizează prin testarea rezultatelor paginilor în diferite cazuri. Fiecare set de instrucțiuni, specifice unei pagini, au fost testate manual prin introducerea unor date care pot cauza erori. Datorită folosirii instrucțiunii 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 către W3C. Rezultatele validării sunt pozitive, fișierele sunt realizate corect.

Capitolul 7

72

Capitolul 7. Manual de instalare si utilizare

Prezentarea manualului de instalare/utilizare este realizat la nivelul fiecărei componente ale proiectului. Se vor preciza adresele URL unde se află manualul de instalare/utilizare a platformelor pe care s-a dezvoltat aplicația împreună cu o descriere a modului de folosință a aplicației.

7.1 Instructiuni de instalare Cele trei componente ale aplicației(Editorul, Generatorul și Site-ul) nu trebuie instalate pe

mașina locală, ele rulează din interiorul unui broweser web. Totuși, pentru rularea aplicației în interiorul unui browser, este nevoie instalarea unor aplicații care afișează conținutul specific fiecărei componente.

Un alt set de instrucțiuni de instalare constă în instrucțiunile specifice operației de instalare ale platformei de dezvoltare a aplicațiilor.

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 afișarea paginilor speciale generate.

Pe lângă cele două servere, este nevoie de aplicația 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 afișarea/dezvoltarea paginilor JSP o Manual: http://docs.oracle.com/javase/7/docs/webnotes/install/index.html

• NetBeans o trebuie instalată versiunea care conține implementarea pentru Java EE o folosit pentru dezvoltarea aplicației 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 Aplicației 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 afișarea Aplicației Flash o Manual: http://get.adobe.com/flashplayer/

• Server HTTP Apache 2.2 o Instalarea se realizează pe portul 80 o Folosit în afișarea paginilor HTML o Manual: http://httpd.apache.org/docs/2.2/

• Server PHP o folosit în afișarea 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.

Capitolul 7

73

Componenta Editor este accesată prin intermediul Internetului, astfel nu necesită instalare. Fișierele componentei Editor sunt:

• Aplicația Flash: o AplicațieFlash.swf

• Aplicația JSP: o Afisare.jsp o Download.jsp o SendTo.jsp o Generate.jsp

Toate aceste fișiere se poziționează într-un folder în interiorul serverului.

7.1.2 Generatorul

Componenta generator este rulată în interiorul unui browser, fără să fie nevoie de instalarea unei alte aplicații. Generatorul este dezvoltat pe platforma NetBeans sub forma unei aplicații web Java; manualul de instalare este specificat în subcapitolul 7.1.1.

Fișierele componentei Generator: • Index.jsp • Operatii.java • Fișierele 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 adăugate în interiorul unui proiect Web Application oferit de NetBeans. Se

creează un proiect folosind surse existene, apoi se încarcă sursele din proiectul Generator. Următorul pas este rularea proiectului.

Surse proiectului Generator se află pe discul aplicației.

7.1.3 Site

Componenta site nu necesită să fie instalată, ea epoate fi vizualizată fără instalare. Pentru viuzalizarea Site-ului este necesar un browser web, un server php(doar pentru paginile speciale) și aplicația WinZIP.

• WinZip o folosit în dezarhivarea site-ului generat o manual: http://kb.winzip.com/kb/5/

Fișierele Site-ului se află în arhiva ZIP generată. Pentru rularea aplicației, se copiază toate

fișierele în interiorul unui server, apoi sunt accesate prin intermediul unui browser.

Capitolul 7

74

7.2 Manual de utilizare Manualul de utilizare arată modul de funcționare a componentelor. Fiecare funcționalitate

va fi descrisă, apoi se vor prezenta pașii necesari realizării acestora.

7.2.1 Editorul

Aplicația Flash conține o serie de butoane care efectuează diverse operații. Titlul fiecărei operații va corespunde funcționalității realizate de către editor.

I. Creeare pagină:

1. click pe butonul Pagina 2. completare câmpuri dialog Informații Generale Pagină Nouă 3. selectează opțiunea de clonare 4. click pe butonul OK,în cazul unei erori treci la pasul 5, dacă nu la pasul 8 5. se afișează o eroare specifică câmpului neselectat, click pe butonul OK 6. completare camp cu valoare nouă 7. click pe butonul OK, în caz de eroare se trece la pasul 5 8. pagina nouă a fost creeată după parametrii introduși

II. Ștergere pagină:

1. click dreapta scenă 2. click pe Rename/Delete Pagină 3. se selectează opțiunea Ștergere 4. se selectează pagina din meniul din partea dreaptă 5. click OK, în cazul unei erori se va face selecția pe campul cerut

Figura 7.1 Scena Aplicației

Scenă Butoane

Capitolul 7

75

III. Redenumire pagină: 1. click dreapta scenă 2. click pe Rename/Delete Pagină 3. se selectează opțiunea Rename 4. se selectează pagina din meniul din partea dreaptă 5. se completează camp Denumire 6. click OK, în cazul unei erori se va face selecția pe campul cerut

IV. Modifică elemente pagină 1. click dreapta scenă 2. click pe Rename/Delete Pagină 3. se selectează opțiunea Modifică Elemente 4. se selectează pagina din meniul din partea dreaptă 5. se completează camp Denumire/Scop 6. click OK, în cazul unei erori se va face selecția pe campul cerut

V. Adăugare componentă text:

1. click pe butonul Text 2. desenează elementul:

a. click pe scenă în locul care urmează să devină colțul stânga sus al textului b. se ține click-ul apăsat și se desenează mărimea componentei text c. se lasă click-ul

3. completare dialog 4. click OK, în cazul unei erori, se va modifica campul notificat prin eroare

Figura 7.2 stânga – Operația de desenare; dreapta – Dialogul de afișare; componentele Exterioare Activate

VI. Modificare element text 1. Click pe elementul care urmează a fi modificat 2. Se pot face una din următoarele opțiuni:

a. adăugare/ștergere caractere

Operația de desenare

Dialog de creeare

Componente Exterioare Activate

Capitolul 7

76

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; selecția este la nivelul componentei

g. setare mărime i. se scrie o mărime în campul Size, mărimea este la nivelul

componentei h. setare culoare text

i. se selectează textul care urmează să fie colorat ii. se alege o culoare din colormixerul afișat

i. setare hyperlink i. se alege texult care va conține 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 locația către care se face

redirecționarea v. se efectuează click pe Create

j. stergere hyperlink i. se sterg toate caracterele care aparțin în hyperlink

Figura 7.3 Meniul Elementului Text

Meniu Hyperlink

Element Text

Meniu Element

Text

Capitolul 7

77

VII. Ștergere componentă text:

1. click dreapta scenă 2. click pe Rename/Delete Component 3. se selectează opțiunea Șterge 4. se selectează componenta din meniul din partea dreaptă 5. click OK, în cazul unei erori se va face selecția pe campul cerut

VIII. Adăugare imagine:

1. click pe butonul Image 2. completare campuri dialog 3. click browse 4. se selectează imaginea de pe discul local 5. click OK, în cazul unei erori se va schimba campul completat greșit 6. desenează elementul (V.2.)

IX. Ștergere imagine:

1. click dreapta scenă 2. click pe Rename/Delete Component 3. se selectează opțiunea Șterge 4. se selectează componenta din meniul din partea dreaptă 5. click OK, în cazul unei erori se va face selecția pe campul cerut

Figura 7.4 Dialog Redenumire/Ștergere pagină

X. Creeare componentă Facebook. 1. se efectuează click pe opțiunea Facebook 2. se efectuează click pe butonul Create Custom FB Component 3. se desenează zona componentei

Capitolul 7

78

4. se completează dialogul cu o valoare unică 5. se efectuează click pe butonul OK 6. se pot adăuga componente FBInput; FBInput Text; FBPicture în mod asemănător

cu o componentă text

XI. Adăugare componentă Facebook 1. se efectuează click pe butonul Add FB Component 2. se selectează componenta care urmează să fie adăugată 3. se efectuează click pe butonul OK 4. se desenează componenta

XII. Adăugare componentă Other

1. Se efectuează click pe opțiunea Other 2. Se efectuează click pe butonul Create Other Component 3. Se scrie codul care urmează a fi inserat 4. Se efectuează click pe butonul OK.

XIII. Generare XML 1. se selectează locul unde va fi salvat fișierul 2. se efectuează click pe save

XIV. Încărcare XML

1. se selectează fișierul care urmează a fi încărcat 2. se efectuează click pe save

XV. Opțiuni Site-Map – schimb acces la pagină

1. se efectuează click pe butonul Site Map 2. se selectează pagina 3. se selectează accesul 4. se efectuează click pe butonul Set.

7.2.2 Generatorul

Pentru afișarea generatorului se va accesa pagina indexGenerator.jsp. Acolo se vor afișa informațiile legate de serviciul web. Toți utilizatorii vor găsi acolo o opțiune de download WSDL și generare Site.

Figura 7.5 Opțiuni Generator

Capitolul 7

79

I. Download WSDL

1. se efectuează click pe butonul download WSDL 2. se alege locația/nuleme fișierului 3. se efectuează click pe butonul OK

II. Upload XML

1. se efectuează click pe butonul Generate Site 2. se alege locația/nuleme fișierului 3. se efectuează click pe butonul Okâ

III. Download ZIP

1. se efectuează click pe butonul download ZIP 2. se alege locația/nuleme fișierului 3. se efectuează click pe butonul OK

7.2.3 Site

Fiecare site generat conține un meniu. Acest meniu oferă accesul în interiorul paginilor generate. Pentru accesarea paginilor speciale, specifice fiecărui site, este nevoie de accesarea paginii login.php.

După introducerea numelui și parolei contului de administrator (user/parolă implicită admin/admin), se vor afișa opțiunile de schimbare a structurii site-ului:

Figura 7.6 Meniu Administrator

I. Ștergerea unei pagini

1. se efectuează click pe butonul șterge pagină 2. în noua pagină se selectează pagina care urmează să fie ștearsă 3. se efectuează click pe butonul ok 4. se va afișa un dialog care noptifică dacă operația a fost realizată cu succes

II. Modificarea unei pagini 1. se efectuează click pe butonul de modificare pagină 2. se modifică conținutul elementului care se dorește a fi modificat 3. se efectuează click pe butonul Salvare

III. Adăugarea unei pagini

Capitolul 7

80

1. se efectuează click pe butonul adaugare pagină 2. se selectează modelul de pagină după care se dorește efectuarea unei clone 3. se efectuează click pe butonul OK 4. se modifică conținutul elementului care se dorește a fi modificat 5. se efectuează click pe butonul Adaugă

IV. Schimbare parolă 1. se efectuează click pe butonul Schimbare Parolă 2. se introduce vechea parolă în câmpul parolă veche 3. se introduce noua parolă în câmpul parolă nouă 4. se introduce noua parolă în câmpul repetare parolă nouă 5. se efectuează click pe butonul Schimba Parolă

V. Delogare 1. Se efectuează click pe butonul Logout

Capitolul 8

81

Capitolul 8. Concluzii

Aplicația îndeplinește obiectivele generale propuse. Generatorul creează un site Web 3.0

funcțional, care poate fi folosit oricând de către utilizator. Editorul ajută utilizatorul în dezvoltarea unui site, oferind un set de operații de tipul CAD. Site-ul generat este personalizat după preferințele utilizatorului.

De asemenea, aplicația respectă majoritatea cerințelor prezentate în capitolul dedicat analizei, capitolul 4. Totuși există anumite aspecte care trebuie înbunătățite, reevaluate sau modificate.

Calitatea obiectivelor realizate

Majoritatea obiectivelor propuse au fost realizate. Cele trei componente îndeplinesc operațiile generale cerute. Singura problemă care mai poate fi ridicată este legată de calitatea funcționalitățiilor implementate.

Ansamblul de componente care alcătuiesc Generatorul de Site-uri Web 3.0, poate fi verificat, calitativ, printr-o analiză comparativă cu orice alt produs software care realizează un scop asemănător.

Aplicația prezintă o serie de avantaje și o serie de dezavantaje, acestea vor fi detaliate la rândul lor. Analiza este realizată prin comparație cu două aplicații generatoare de pagini HTML: Adobe Dreamweaver, W3C Amaya. Motivul selecției celor două aplicații are la bază numărul ridicat de utilizatori care folosesc aplicațiile.

Criteriu Generator Web3.0 Dreamweaver CS4 Amaya

Web 1.0

Text – Toate

opțiunile HTML

Parțial – cele mai

importante Da Da

Imagini Da Da Da

Sunet

Partial – poate fi

adăugat ca o

componentă other

Da Da

Video

Partial – poate fi

adăugat ca o

componentă other

Da Da

Web 2.0

Ușurință în

utilizare Foarte ușor Mediu Ușor

Acces de oriunde Da Nu Nu

Release-cycle Nu Da Da

Rețele de

socializare Da

Parțial – poate fi

scris codul de

conexiune

Nu

Adăugare de

conținut de către

utilizator

Da Nu Nu

Web 3.0

Capitolul 8

82

Semantic Web Da

Partial – trebuie

definită de

utilizator

Partial – trebuie

definită de

utilizator

SVG Da

Partial – trebuie

definită de

utilizator

Nu

Aspecte Generale

Editare

componente Parțial Da Da

Inserare cod

server-side

Parțial –

componentă other Da Nu

Modificare cod

pagină Nu Da Da

Complexitate

opțiuni disponibile Redus Foarte Ridicat Mediu

Pagini speciale Da Nu Nu

Optimizare Mediu Performant Mediu

Resurse utilizate

de către client Minim Mediu/Avansat Mediu

Arhivare ZIP Da Nu Nu

Elemente grafice Minimal Bogat Mediu

Tabelul 8.1 Comparație Proiect/Dreamweaver/Amaya Avantajele Aplicației Generator Web 3.0: Proiectul permite o dezvoltare mai ușoară și completă a caracteristicilor Web 2.0/3.0

decât celelalte două aplicații. Ușurința în utilizare se datorează și ușurinței de manipulare a aplicației. Fără să fie

supraîncărcată cu diverse opțiuni, 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 execuție. Aplicația conține o serie de constrângeri și citiri speciale care duce la executarea optimă a operațiilor. Aplicația folosește mai puține resurse ca oricare dintre celelate două aplicații.

Dezavantajele Aplicației: Proiectul nu prezintă o posibilitate de modificare a codului HTML care urmează a fi

generat. Acest dezavantaj nu prezintă o importanță deosebită, aplicația este destinată celor care nu au cunoștiințe de programare.

Un alt dezavantaj al aplicației este legat de elementele grafice ale componentelor. Aplicația conține un nivel minimal de elemente grafice. Proiectul este centrat pe funcționalitate, nu pe elemente grafice. Ele pot fi adăugate oricând în aplicație, logica din spatele fiecărei componente rămâne la fel.

Pe baza Tabelului 8.1, împreună cu avantajele prezentate de către Aplicația Generator

Web 3.0, se poate observa un probabil nivel ridicat de competivitate cu celelalte două aplicații. Această competivitate se reflectă față de ținta de utilizatori urmărită de aplicație.

Capitolul 8

83

În cazul utilizatorilor experimentați, este nevoie de dezvoltarea unor funcționalități care să permită modificarea codului HTML din interiorul Editorului. Aceste cerințe, împreună cu câteva înbunătățiri, fac obiectul subcapitolului dedicat dezvoltării/ânbunătățirii - 8.2.

Posibile dezvoltări/înbunătățiri

Fiecare componentă poate fi înbunătățită fie prin adăugarea de funcționalități, fie prin înbunătățirea unor funcționalități deja existente, fie prin rezolvarea unor probleme care au apărut în etapa de testare.

Este utilă o prezentare a unor înbunătățirilor generale, urmate de înbunătățirile propuse la nivelul fiecărei componente în parte. Prin această abordare se evită repetarea unor cerințe specifice mai multor componente.

8.2.1 Dezvoltări/înbunătățiri generale

Majoritatea dezvoltărilor/înbunătățirilor descrise în acest subcapitol sunt legate de funcționalități care pot fi adăugate în site-ul generat. Aceste funcționalități pot fi făcute la nivelul unei singure componente, dar este recomandabil modificarea tuturor componentelor.

• adăugarea de culoare/poză background în site • adăugare de elemente sunet și video • adăugarea de mai multe tipuri de rețele de socializare • adăugarea unor componente meniu • adăugarea unor opțiuni suplimentare legate de afișarea textului • adăugarea unei logici de utilizare conturi de utilizator in site

Observație: Componentele sunt independente, astfel, adăugarea funcționalitățiilor în

cadrul oricărei componente este realizată independent, iar efectuarea modificărilor trebuie realizată în așa fel încât să nu creeze erori în utilizare:

• orice funcționalitate nouă a Editorului nu va fi văzută de către 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 dezvoltări/înbunătățiri. Această afirmație se bazează pe calitatea de componentă Front End al proiectului. Dacă se dorește includerea utilizatorilor experimentați în targetul de utilizatori ai aplicației, este necesară dezvoltarea unei alternative vizuale, dedicată utilizatorilor expert. Acestă alternativă va trebui să conțină opțiuni complexe de editare a codului, împreună cu opțiuni de particularizare a elementelor inserate în pagină.

Forma normală, dedicată utilizatorilor necunoscători de programare, trebuie înbunătățită prin adăugarea unor opțiuni generale de editare HTML. Aceste opțiuni împreună cu opțiunile formei alternative se rezumă la:

• adăugare elemente grafice în cadrul aplicației JSP • adăugare elemente grafice în cadrul aplicației Flash • mai multe opțiuni de vizualizare/verificare

Capitolul 8

84

• validator a paginilor HTML generate • creearea posibilității de salvare template • posibilitate de scriere/modificare cod HTML • mai multe opțiuni legate de elementele HTML • înbunătățiri 8.2.1

8.2.3 Generator

Modificările realizate în interiorul generatorului sunt minimale. Ele se rezumă la adăugarea unor tag-uri la citire și scriere. Fiecare componentă/element/atribut adăugat în interiorul fișierului XML trebuie manipulat de către Generator.

O potențială modificare a generatorului constă în includerea aplicației Flash în interiorul Generatorului. Componenta generator va conține o metodă care întoarce, în formatul byte[], fișierul swf.

Există mai multe avantaje ale acestei abordări: nu mai trebuie salvată Aplicația Flash în interiorul unui site, modificarea ulterioară a Aplicației Flash este realizată la toți clienții Generatorului; dar și o serie de dezavantaje: supraîncărcarea Generatorului cu cereri, componentele Editor și Generator nu mai sunt independente. Alegerea rămâne la nivelul dezvoltatorului.

Pe lângă aceaste înbunătățiri, se mai poate adăuga câteva opțiuni suplimentare: • posibilitatea accesării pe baza unei arhitecturi REST • XML-ul format greșit să fie reconstruit • înbunătățiri 8.2.1

8.2.4 Site

Modificările componentei Site izvoresc din modificările Generatorului și Editorului. Orice opțiune adăugată în aceste două componente este vizibilă în site-ul generat.

O altă potențială modificare constă în adăugarea de cod javaScript, folosit în redimensionarea paginii. În cazul în care se va face resize la browser, acest cod să repoziționeze și să micească/mărească elementele paginilor, în funcție de mărimea ferestrei browserului.

Câteva înbunătățiri ulterioare care pot fi adăugate: • adăugarea unei logici de resize a paginilor • mai multe pagini specifice fiecărui site, care îndeplinesc diferite sarcini • elemente grafice în paginile specifice fiecărui site • înbunătățiri 8.2.1

Anexa

87

Anexă

Prezenta anexă conține o serie de informații legate unele particularități ale aplicației. Fiecare componentă fi prezentată individual.

A1 Editor Anexa prezintă elementele vizuale și funcțiile realizate de componenta editor.

A1.1 Elementele vizuale ale aplicației

Î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 instanțiază un obiect de tipul buton okBtnPage.x = 570; okBtnPage.y = 500; // se poziționează în scenă okBtnPage.visible = false; // este setat ca fiind vizibil addChild(okBtnPage); //este desenat în Aplicația Flash.

Nume Tip Nume Tip

okBtnPage SimpleButton fundalPagina Shape cancelBtnPage SimpleButton fundalEroare Shape okBtnError SimpleButton paginaLabel TextField okBtnRightPage SimpleButton denumirePaginaLabel TextField cancelBtnRightPage SimpleButton denumirePaginaInput TextField okBtnRightComponent SimpleButton scopPaginaLabel TextField cancelBtnRightComponent

SimpleButton scopPaginaInput TextField

okBtnNewTextFieldPage SimpleButton clonaPaginaLabel TextField cancelBtnNewTextFieldPage

SimpleButton listPagina TextField

cancelBtnNewImage SimpleButton eroarePaginaLabel TextField okBtnNewImage SimpleButton paginaRenameDeleteLab

el TextField

browseBtnNewImage SimpleButton paginaRenameDeleteLabelOperatie

TextField

okBtnSiteMap SimpleButton paginaRenameDeleteLabelPagina

TextField

okBtnCreateCustomFBComponent

SimpleButton listOperatiiPagina List

cancelBtnCreateCustomFBComponent

SimpleButton listaComponentePagina List

setAccessBtnPage SimpleButton paginaRenameDeleteLab TextField

Anexa

88

elDenumire okBtnAddFBComponent SimpleButton paginaRenameDeleteLab

elDenumireInput TextField

cancelBtnAddFBComponent

SimpleButton paginaRenameDeleteLabelDenumireInput

TextField

okBtnAddOtherComponent

SimpleButton paginaRenameDeleteLabelScop

TextField

cancelBtnAddOtherComponent

SimpleButton paginaRenameDeleteLabelScopInput

TextField

componentLabelDelete TextField scopNewTextFieldInput TextField componentRenameDeleteLabel

TextField newImageLabel TextField

listaComponente List denumireNewImageLabel

TextField

componenteRenameDeleteLabel

TextField denumireNewImageInput TextField

componenteRenameDeleteInput

TextField relevantaNewImageLabel TextField

paginaRenameDeleteLabel

TextField relevantaNewImageInput TextField

newTextFieldPaginaLabel TextField altNewImageLabel TextField denumireNewTextFieldLabel

TextField altNewImageInput TextField

denumireNewTextFieldInput

TextField linkNewImageLabel TextField

scopNewTextFieldLabel TextField siteMapDenumireLabel TextField Tabelul A1:Elementele Vizuale Temporare

A1.2 Controlerul

Orice element vizual prezintă un comportament. Exemplu de adăugare 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 funcție trebuie să conțină paramterul e:Event.

Anexa

89

A1.3 Modelul

Componenta model conține un număr de funcții care îndeplinesc anumite funcționalități. Un exemplu de funcție:

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 funcție Funcționalitate

GenerateButton(textVar,culoare,w,h): SimpleButton Generează un buton GenerateLabel(textVal,x,y,w,h) : TextField Generează un label GenerateInput(x,y,w,h): TextField Generează un input GenerateList(x,y,w,h) : List Generează o listă GenerateTextArea(textVar,x,y,w,h) : TextArea Generează un text Area GenerareFundalDialog(culoare, x, y, w, h, eW, eH):Shape Generează un fundal GenerateInputSite(x,y,w,h): TextField Generează un Input updateListaPagina():void Realizează un update a

listei paginilor updateListaOperatiiPagina():void Realizează un update a

listei Operații Pagină updateListaComponentePagina():void Realizează un update a

listei Componente Pagină updateListaComponente():void Realizează un update a

listei deComponente a paginii vizualizate

errorMessege(messege:String):void Creează o eroare updateAfisarePagini():void Realizează un update a

paginilor afișate updateTextBtnPagina(denumirePagina:String,noulText:String):void

Realizează un update a butonului unei pagini

createNewPage(titlu:String,scop:String):Pagina Creează o pagină nouă createNewExteriorPage(x:int,y:int,w:int,h:int,titlu:String,scop:String):ComponentaExterioara

Creează o pagină nouă exterioară

createBtnPagina():void Creează o un buton a unei Pagini

setFocusOnPagina(pagina:Pagina):void Afișează o pagină în scenă textFieldStartDrag() Inițializează începutul

operației de drag

addTextField(x:int,y:int,x2:int,y2:int,denumireGenerica:String,relevanta:String):void

Adaugă un Element TextField în pagină

updateTextFieldForm() Realizează operația de sincronizare între obiect și

Anexa

90

Antet funcție Funcționalitate

elementul vizual updateStringFromTextFieldDown() Realizează operația de

sincronizare între obiect și elementul vizual în cazul unei taste apăsate

updateStringFromTextFieldUp() Realizează operația de sincronizare între obiect și elementul vizual în cazul unei taste eliberate

showTextOptionsDialog():void Afișează dialogul de opțiuni a unui text

initPossibleDragText(e):void Inițializează o posibilă operație de drag a unei componente Text

disablePossibleDragText():void Concluzionează operația de drag a unei componente text

strtDragTextField():void Inițializează operația de drag a unei componente Text

dragTextField():void Operația de drag a unei componente Text

stpDragTextField():void Concluzionează operația de drag a unei componente Text

drawContinousShape() Desenează un dreptunghi – folosit în desenarea unei componente

clearStage() Eliberează scena de componentele paginii

redrawStage() Inserează în scenă componentele paginii

generateIndexPage() Generează pagina de index deletePagina(denumirePagina:String):void șterge o pagină schimbaScop(denumirePagina:String, scopNou:String) Schimbă scopul unei

pagini imageFieldStartDrag():void Inițializează operația de

drag a unei componente Imagine

updateResizedTextFiled(textField:TextField) Realizează operația de sincronizare între componenta Text și elementul vizual TextField în urma operației de resize

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

Crează un nou obiect de tipul TextFormat care

Anexa

91

Antet funcție Funcționalitate

ormat conține elementele de Bold Italic și Underline

loadXML() Încarcă XML în scenă onFileSelected1() Operația realizată la

selecția unei imagini onFileComplete1() Operația realizată la

încărcarea unei imagini onInitBitmapLoad():void Operația realizată după

adăugarea unei imagini în Loader

strtDragBitmap():void Inițializează operația de drag a unei componente Imagine

dragBitmap():void Operația de drag a unei componente Imagine

stpDragBitmap():void Concluzionează operația de drag a unei componente Imagine

onInitBitmap():void Operația realizată după adăugarea unei imagini în scenă

initPossibleResize() Inițializează o posibilă operație de resize unei componente Imagine

initPosibleDrag():void Inițializează o posibilă operație de drag unei componente Imagine

disablePosibleDrag() Concluzionează operația de drag a unei componente Imagine

addBitmapToScene(x:int,y:int,h:int,w:int,alt:String,link:String,location:String,denumire:String, relevanta:String)

Adaugă o imagine în scenă

drawTemporalBitMap(x:int,y:int,h:int,w:int) Desenează o imagine temporară

onInitBitmap2():void Operație realizată asupra imaginii temporare

Tabelul A2: Funcțiile realizate de Model A2. Generator

Componenta Generator conține o clasă Operații care realizează toate operațiile specifice generatorului. Ele sunt prezentate în tabelul A3.

Funcția de transformare a fișierului XML în arhiva ZIP: public static byte[] transform(byte[] XML){ Pagina[] pagini = Operatii.transformXmlToPages(XML); byte[][] componenteFisiere = null;

Anexa

92

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 Funcție Funcționalitate

public static byte[] generateZip(Pagina[] pagini, String[] paginiHTML, byte[][] componenteFisiere,byte[] XML)

Creează tipurile de obiecte necesare unei arhivări, apoi trimite către operația zipBytes spre arhivare. Fișierul arhivat este oferit ca rezultat al funcției

public static String fbInputCode() Generează codul componentei facebook input

public static String fbPictureCode() Generează codul componentei facebook picture

public static String fbHistoryCode() Generează codul componentei facebook history input

public static String[] generateCode(Pagina[] pagini)

Generează codul HTML pe baza obiectelor Pagina

private static byte[][] generatePhpFiles() Generează codul paginilor specifice oricărui site

public static Pagina[] transformXmlToPages(byte[] XML)

Transformă fișierul XML în obiecte de tipul Pagină

public static byte[][] transformXmlToComponents(byte[] XML)

Transformă imaginile din interiorul fișierului XML în elemente de tipul byte.

public static byte[] zipBytes(int nrComponents, String[] filenames, byte[][] input)

Arhivează paginile generate

Tabelul A3: Funcțiile Generatorului

Anexa

93

A3. Site Site-ul generat conține paginile desenate de către utilizator și un set de pagini specifice

oricărui site. Acestea sunt prezentate în taelul A4.

Pagina Funcționalitate

adaugare_pagina Adauga o pagină cloneaza Cloneaza o pagină existentă dashboard Pagina de social dashboard downloadXML Pagina de download a fișierului 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 oricărui site