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 1. 0....................................................... ......................................................................................................... .................................................. 15 3.1.3 Web 2.0 2. 0....................................................... ......................................................................................................... .................................................. 16 3.1.3.1 Web 1.0 – Web 2.0 ................................................................................ 17 3.1.4 Web 3.0 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 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 comp onente ............................................... ..................................................................... ...................... 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 Ser vice ...................................................... ............................................................................ ...................... 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
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. 7
Capitolul 1
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.
8
Capitolul 1 1.3 Social Media și Social Dashboards
Andreas Kaplan și Michael Haenlein definesc Social Media în lucrarea lor „Users of the world, unite!” ca „un grup de 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 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.
9
Capitolul 2
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ă
10
Capitolul 2 2.2 Site Web 3.0
Produsul final al generatorului Web este Site-ul Web 3.0: respecta conceptul Web 3.0 - va fi scris într-o manier ă care va permite o • parcurgere optimă de 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 p rimul rând utilizatorul poate p oate 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
11
Capitolul 2 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 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.
12
Capitolul 2 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
13
Capitolul 3
Capitolul 3.
Studiu bibliografic
Parcurgerea obiectivelor din capitolul anterior, a relevat o serie de concepte și principii care au la bază studii bibliografice. Documentarea 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. 14
Capitolul 3 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. Siteurile se rezumau la un set de imagini și, foarte rar, unele sunete de acompaniere. De asemenea,Web 1.0 prezenta un nivel interactiv redus. Web 1.0 reprezintă era 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
, Poziționarea elementelor în pagin ă folosind tabele HTML
15
Capitolul 3
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: 16
Capitolul 3 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. Twoway 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 Ochi Stickiness Editor Pagini Personale Centralizat
Conținut generat de utilizator Maini Syndication Buzz Blog Croudsourcing
17
Capitolul 3 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 (codeveloperi)[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 Croudsourcin g 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 Ofoto Akamai Mp3.com Britannica Online Personal websites evite Domain name speculation Page views Screen scraping Publishing Content management systems Directories (taxonomy)
GoogleAdSense Flickr BitTorrent Napster Wikipedia Bloging Upcoming.org și EVDB Search engine optimization Cost per click Web services Participation Wikis 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. 18
Capitolul 3 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, lor, pe când BitTorrent 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.
19
Capitolul 3 Directorul W3C Tim Berners-Lee a descris Web 3.0: „un amestec între o grafică formată din vectori scalari, cu un acces la un Web semantic integrat pe un 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 20
Capitolul 3 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 21
Capitolul 3 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: are
Subiect
Ana
mere
Obiect
Descriere Exemplu 3.1, Tripla: Ana are mere, XML:
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 - 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 dintrun 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. 22
Capitolul 3 Trust reprezintă nivelul de încredere în resursa respectivă. Acesta se pot prelua din diverse servicii on-line. Nivelul de încredere favorizează o 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 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. 23
Capitolul 3 Din 1996, cei de la W3C lucrează spre a propune un generator/editor de site-uri. Acest efort a luat denumirea de Amaya. Scopul acestei 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 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: Service Broker WSDL
Service Requester
WSDL
SOAP
Service Provier
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. 24
Capitolul 3 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: 25
Capitolul 3 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 • 26
Capitolul 3 Î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.
27
Capitolul 4
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 28
Capitolul 4 portabilitate – posibilitatea de a utiliza aplica ap licaț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 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: 29
Capitolul 4 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 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 obiectiv memorare/manipulare informații o 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: 30
Capitolul 4 •
•
•
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: 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
31
Capitolul 4 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 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 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 online, fiind accesibilă prin intermediul Internetului disponibilitate – aplica ția să fie disponibilă oricând utilizatorul dorește să o folosească 32
Capitolul 4 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 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: 33
Capitolul 4 trebuie să permită introducerea de componente Web 2.0 • trebuie să asigure respectarea formatului Semantic Web 3.0 • trebuie să respecte conceptul SVG – Web 3.0 • trebuie să permită 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 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 34
Capitolul 4 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 ComponentBased 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 35
Capitolul 4 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: Intrare utilizator
Editor
Trimite format standard
Publicat Site Web 3.0 pentru testare Figura 4.1 Scenariul general al proiectului -abstract
Serviciu Web
Generează Site
36
Capitolul 4 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. Editor -
Intrare Utilizator - mouse - tastatura - fișier XML
-
creeare pagina/pagini desenare pagina/pagini desenare componente: o text imagini o exterioare o definire elemente semantice generare XML
-
afișare pagini generate salvare arhiva zip pe ma șina locală
Serviciu web -
Intrare Utilizator - getInfo() - genereaza()
afișeză informații serviciu generează site web: HTML o text imagine CSS Semantic Web o PHP Pagini speciale facebook twitter
T r i m i t e X M L c ă t r e S e r v i c i u
G e n e r e a z ă
Site Web 3.0 -
Intrare Utilizator - mouse - tastatura
-
pagini HTML text/imagini o Semantic Web o pagini PHP o facebook/twitter o pagini speciale imagini standard XML
Trimis către Editor Figura 4.2 Arhitectura Proiectului - aspect general 37
Capitolul 5
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. Intrare utilizator
Editor JSP/Flash Publicat pentru testare ZIP
Trimite XML
Serviciu WebService Java Generează Site Format: HTML/php
Site Web HTML/php 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, 38
Capitolul 5 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 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 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.
39
Capitolul 5 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 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;
40
Capitolul 5 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. •
User utilizează
vede
View
Controler
update Model
manipulează
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ă
Pagina
Extinde
MovieClip
Implem etează
Atribute
Metode
-
-id* : int -titlu* : String -scop : String -componente : Array +w : int +h : int
+constructor +setter/getter +addComponenta +deleteCompone nta
41
Capitolul 5 Nume clasă
Extinde
Implem etează
ComponentaExteriora
Pagina
-
ComponentaPagina
-
Clonable
Atribute
Metode
-x : int -y : int -relatiePagina : String -nume* : String -h : int -w : int -continut:TextField -relevanta : String -text : String -font : String -marime : String -align : String -hyperlinks : Array -relevanta : String -alt : String -lnk : String -src : String -loader : Loader -imageData : ByteArray
+constructor
ComponentaText
Componenta Pagina
ComponentaImage
Componenta Pagina
Clonable
ComponentaExternaFB
Componenta Pagina
Clonable
-continut : TextField
ComponentaExternaOth Componenta er Pagina
Clonable
-continut : TextField -linkTo : String
ComponentaFBHistoryI Componenta nput Pagina
Clonable
-continut : TextField
ComponentaFBInput
Componenta Pagina
Clonable
-continut : TextField
ComponentaFBPicture
Componenta Pagina
Clonable
-continut : TextField
-
-beginInt :int -endInt : int -link : String -descriere : String
HyperLinkPage
-
Clonable
+constructor +setter/getter +clone +consturctor +setter/getter +addHyperLink +removeHyperLi nk +clone
+constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +constructor +setter/getter +clone +consturctor +setter/getter
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. 42
Capitolul 5 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.
43
Capitolul 5 Pagina Componenta Exterioara
ComponentaPagina
Componenta Image
Componenta Text
HyperLinkPage
ComponentaFB Input
Componenta ExternaFB
ComponentaExterna Other
ComponentaFB HistoryInput
ComponentaFB Input
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 siteului, 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 44
Capitolul 5 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 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: 45
Capitolul 5 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 46
Capitolul 5 •
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.
Meniu Hyperlink
Adaugare Componenta Meniu XML
Pagini
Meniu Componenta Facebook
Meniu TextField
Figura 5.4 Componenta Editor în cazul de utilizare adăugare text Lista elementelor vizuale permanente și comportamentul lor: Denumire Element
Tip
Comportament
Elemente Text Image Pagina Generate Load Text Options Font FontComboBox Size
Label Buton Buton Buton Buton Buton Label Label ComboBox Label
Adaugă un TextField in site Adaugă o imagine in Site Creează o pagină nouă Generează XML unde dorește utilizatorul Încarcă XML exterior Permite alegerea unui tip de font -
47
Capitolul 5 SizeText Align AlignLeft AlignRight AlignCenter AlignJustified Color Bold Italic Underline Hyperlink Tab Pagina 1..6 - X Site Map Index* Descriere Legatura Descriere Legatura Hyperlink Hyperlink Create Create Custom FB Component Create Other Component Add Fb Component
Input Label Buton Buton Buton Buton ColorPicker Buton Buton Buton Buton Label Buton Buton Buton Label Input Label Input Buton
Valoarea introdusă reprezintă mărimea fontului textului Setează align la text Setează align la text Setează align la text Setează align la text Setează culoarea Selecția din text devine boldata Selecția din text devine inclinat ă Selecția din text devine subliniat ă Setează selecția ca fiind hyperlink Afișează paginile nr x*7-(x+1)*7 Afișează meniu Site Map Afișează pagina Index pe scenă Descrie legătura într-un mod semantic Conține site-ul c ătre care se face link Adauga un hyperlink în zona selectată către Hyperlink Input
Buton
Creează o nouă componentă FB
Buton Buton
Creează o nouă componentă Other Adaugă o componentă fb definită
Tabel 5.2 Comportamentul elementelor vizuale permanente
Elemente Componenta FB
Scena Componenta FB
Figura 5.5 Componenta Editor în cazul de utilizare 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 48
Capitolul 5 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 49
Capitolul 5 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 (xmaxScena) 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ă. •
50
Capitolul 5 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ă. 51
Capitolul 5 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 Bold Italic Underline
Metoda apelată Model setBold(start, end) setItalic(start, end) setUnderline(start, end)
Align:center
setAlign(“center”)
AlignLeft
Align:left
setAlign(“left”)
AlignRight
Align:right
setAlign(“right”)
AlignCenter
Align:center
setAlign(“center”)
ColorPicker
Color
setColor(color,begin,end)
B I
U AlignCenter
Informații suplimentare Align influețează tot textul Align influețează tot textul Align influețează tot textul Align influețează tot textul 52
Capitolul 5 Create Hyperlink setHyperlink(linkTo,begin,end) Tabelul 5.4 Elementele componentei Text
Setează un hyperlink
În cazul elementelor hyperlink, după ce sunt 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 Acestea sunt puse în practică prin intermediul unor operații. Operațiile implementate de către aplicația Flash sunt: • • • •
prevăzute în capitolul de analiz ă.
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 53
Capitolul 5 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ă
54
Capitolul 5 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. 55
Capitolul 5 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ă.
56
Capitolul 5 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. Postcondiț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 reprezintă începutul descrierii elementului „componenta” , iar 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: 57
Capitolul 5 valoare1 valoare1 valoare2 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: valoareAtribut1 valoareAtribut2 valoareAtribut3.1 valoareAtribut3.2 < atribut1> < atribut1.1>valoareAtribut1.1 atribut1.1> < atribut1.2>valoareAtribut1.2 atribut1.2> atribut1> valoareAtribut2 valoareAtribut1 < atribut2.1>valoareAtribut2.1 atribut2.1> < atribut2.2>valoareAtribut2.2 atribut2.2> atribut2>
Din acest exemplu se poate vedea modul de organizare a standardului XML prin introducerea ca elemente a tag-ului a paginilor Pagina1, Pagina2, ComponentaEterioară. Acest fișier mai conține o serie de tag-uri. Aceastea sunt de tipul și conțin două elemente. Primul este intitulat și conține lungimea conținutului elementului, urmat de conținutul fișierului jpg în formatul tablou unidimensional de tipul byte. Tag-urile 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.
58
Capitolul 5 5.2.3 Aplica ț ia 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 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 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: 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: Alternative Alternative content
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 59
Capitolul 5 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 reîntoar e î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 servici.GeneratorWS_Service service = new servici.GeneratorWS_Service(); servici.GeneratorWS port = service.getGeneratorWSPort(); service.getGeneratorWSPort(); byte[] XML = XMLInputStream; result = port.generate (XML); out.println("S-a realizat generarea "); } catch (Exception ex) { out.println("exception" 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.
60
Capitolul 5 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
61
Capitolul 5 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 elementului text. În interior se va introduce textul oferit de utilizator, împreună cu tag-urile - bold - italic 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: text text inserat de catre utilizator
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:
62
Capitolul 5 denumireElementText relevantaFataDePagina >relevantaFataDePagina
Î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 . 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: . 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]. 63
Capitolul 5 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ă • 64
Capitolul 5 •
• •
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 65
Capitolul 5 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. ășoară după etapele descrise mai sus. OpG2: Operația de generare. Această operație se desf ăș 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); transformXmlToPages(XML); // logica de transformareîn transformareîn pagini String[] paginiHTML = generateCode(pagini); generateCode(pagini); //logică de generare cod pagini Byte[][] componenteFisiere = transformXmlToComponents(XML); transformXmlToComponents(XML); //logica de generarecomponentesunet, generarecomponentesunet, imagine, etc Retrun generateZip(pagini, paginiHTML, componenteFisiere); //întoarce produsul produsul arhivat în formatul byte[] 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.
66
Capitolul 5 5.4.2 Opera ț iile 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 or dinea 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: , se crează un obiect aaa, se citește până la întalnirea , 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”) // avem un poten țial început/sfar șit de componenta if (ByteArray[i-5,i] (ByteArray[i-5,i] == “”) //logică de început de ad ăugare text, creeare obiectText if (ByteArray[i-5,i] (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 - 5 caractere,
- 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:ComponentaPagin (pagina:ComponentaPaginaa in pagini){ String body =”\n”; //ini țializarea elementului body String head= “\n \n” // ini țializarea elementului head For each (componenta in pagina.getComponente()){ pagina.getComponente()){ If (if component aparține de head)
67
Capitolul 5 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. 68
Capitolul 6
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 69
Capitolul 6 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 variabile auxiliare specific specific variabilelor care urmeaz urmeaz ă să fie modificate //logica functie 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.
70
Capitolul 6 6.3. Generator Testarea realizată în cadrul generatorului se dezvoltă folosind JUnit. Se va creea o nouă clasă de tipul JUnit în care se vor verificata toate metodele clasei 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, Operatii.zipBytes(nrComponents, filenames, input); assertTrue(result 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.
71
Capitolul 7
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 Manual: http://docs.oracle.com/javase/7/docs/webnotes/install/index.html o NetBeans • o trebuie instalată versiunea care conține implementarea pentru Java EE o folosit pentru dezvoltarea aplicației Manual: http://netbeans.org/community/releases/69/install.html o Adobe Flash CS5 • o compatibil cu orice versiunea de la CS5 în sus o folosit în dezvoltarea Aplicației Flash Manual: http://helpx.adobe.com/download-install.html o Adobe Flash Player • o compatibil cu versiunea 10 sau orice versiune ulterioară folosit în afișarea Aplicației Flash o o Manual: http://get.adobe.com/flashplayer/ Server HTTP Apache 2.2 • o Instalarea se realizează pe portul 80 Folosit în afișarea paginilor HTML o o Manual: http://httpd.apache.org/docs/2.2/ Server PHP • o folosit în afișarea paginilor speciale ale Site-ului/componentele facebook Manual: http://php.net/manual/en/install.php o Browser web • o Orice browser web: Internet Explorer, Mozilla Firefox, Google Chrome, etc. 72
Capitolul 7 Componenta Editor este accesată prin intermediul Internetului, astfel nu necesită instalare. Fișierele componentei Editor sunt: • Aplicația Flash: o AplicațieFlash.swf Aplicația JSP: • o Afisare.jsp Download.jsp o 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 ComponentaExterioara.java o o ComponentaExternaFB.java o ComponentaExternaOther.java o ComponentaFBHistoryInput.java o ComponentaFBInput.java o ComponentaFBPicture.java o ComponentaImagine.java ComponentaText.java o 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. 73
Capitolul 7 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. 1. 2. 3. 4. 5. 6. 7. 8. II. 1. 2. 3. 4. 5.
Creeare pagină: click pe butonul Pagina completare câmpuri dialog Informații Generale Pagină Nouă selectează opțiunea de clonare click pe butonul OK,în cazul unei erori treci la pasul 5, dacă nu la pasul 8 se afișează o eroare specifică câmpului neselectat, click pe butonul OK completare camp cu valoare nouă click pe butonul OK, în caz de eroare se trece la pasul 5 pagina nouă a fost creeată după parametrii introduși Ștergere pagină:
click dreapta scenă click pe Rename/Delete Pagină se selectează opțiunea Ștergere se selectează pagina din meniul din partea dreaptă click OK, în cazul unei erori se va face selecția pe campul cerut
Scenă
Butoane
Figura 7.1 Scena Aplicației
74
Capitolul 7 III. 1. 2. 3. 4. 5. 6.
Redenumire pagină: click dreapta scenă click pe Rename/Delete Pagină se selectează opțiunea Rename se selectează pagina din meniul din partea dreaptă se completează camp Denumire click OK, în cazul unei erori se va face selecția pe campul cerut
IV. 1. 2. 3. 4. 5. 6.
Modifică elemente pagină click dreapta scenă click pe Rename/Delete Pagină se selectează opțiunea Modifică Elemente se selectează pagina din meniul din partea dreaptă se completează camp Denumire/Scop 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
Operația de desenare
Dialog de creeare
Componente Exterioare Activate
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 75
Capitolul 7 b. setare text bold i. se selectează textul care urmează a fi schimbat ii. se efectuează click pe butonul B c. setare text italic i. se selectează textul care urmează a fi schimbat ii. se efectuează click pe butonul I d. setare text underline i. se selectează textul care urmează a fi schimbat ii. se efectuează click pe butonul U e. setare align i. se selectează unul dintre butoanele align, efectul este la nivelul componentei f. setare font i. se alege un tip de font; 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
Meniu Hyperlink Element Text
Meniu Element Text
Figura 7.3 Meniul Elementului Text 76
Capitolul 7 VII. 1. 2. 3. 4. 5. VIII. 1. 2. 3. 4. 5. 6. IX. 1. 2. 3. 4. 5.
Ștergere componentă text: click dreapta scenă
click pe Rename/Delete Component se selectează opțiunea Șterge se selectează componenta din meniul din partea dreaptă click OK, în cazul unei erori se va face selecția pe campul cerut Adăugare imagine: click pe butonul Image completare campuri dialog click browse se selectează imaginea de pe discul local click OK, în cazul unei erori se va schimba campul completat greșit desenează elementul (V.2.) Ștergere imagine:
click dreapta scenă click pe Rename/Delete Component se selectează opțiunea Șterge se selectează componenta din meniul din partea dreaptă click OK, în cazul unei erori se va face selecția pe campul cerut
Figura 7.4 Dialog Redenumire/ Ștergere pagină X. 1. 2. 3.
Creeare componentă Facebook. se efectuează click pe opțiunea Facebook se efectuează click pe butonul Create Custom FB Component se desenează zona componentei 77
Capitolul 7 4. se completează dialogul cu o valoare unică 5. se efectuează click pe butonul OK 6. se pot adăuga componente FBInput; FBInput Text; FBPicture în mod asemănător cu o componentă text XI. 1. 2. 3. 4. XII. 1. 2. 3. 4.
Adăugare componentă Facebook se efectuează click pe butonul Add FB Component se selectează componenta care urmează să fie adăugată se efectuează click pe butonul OK se desenează componenta Adăugare componentă Other Se efectuează click pe opțiunea Other Se efectuează click pe butonul Create Other Component Se scrie codul care urmează a fi inserat 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. 1. 2. 3. 4.
Opțiuni Site-Map – schimb acces la pagină se efectuează click pe butonul Site Map se selectează pagina se selectează accesul se efectuează click pe butonul Set.
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 78
Capitolul 7 I. 1. 2. 3.
Download WSDL se efectuează click pe butonul download WSDL se alege locația/nuleme fișierului se efectuează click pe butonul OK
II. 1. 2. 3.
Upload XML se efectuează click pe butonul Generate Site se alege locația/nuleme fișierului se efectuează click pe butonul Okâ
III. 1. 2. 3.
Download ZIP se efectuează click pe butonul download ZIP se alege locația/nuleme fișierului 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. 1. 2. 3. 4.
Ștergerea unei pagini se efectuează click pe butonul șterge pagină în noua pagină se selectează pagina care urmează să fie ștearsă se efectuează click pe butonul ok se va 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 79
Capitolul 7 1. 2. 3. 4. 5. IV. 1. 2. 3. 4. 5. V. 1.
se efectuează click pe butonul adaugare pagină se selectează modelul de pagină după care se dorește efectuarea unei clone se efectuează click pe butonul OK se modifică conținutul elementului care se dorește a fi modificat se efectuează click pe butonul Adaugă Schimbare parolă se efectuează click pe butonul Schimbare Parolă se introduce vechea parolă în câmpul parolă veche se introduce noua parolă în câmpul parolă nouă se introduce noua parolă în câmpul repetare parolă nouă se efectuează click pe butonul Schimba Parolă Delogare Se efectuează click pe butonul Logout
80
Capitolul 8
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 Text – Toate opțiunile HTML Imagini Sunet
Video
Ușurință în utilizare Acces de oriunde Release-cycle
Generator Web3.0 Dreamweaver CS4 Web 1.0 Parțial – cele mai Da importante Da Da Partial – poate fi adăugat ca o Da componentă other Partial – poate fi adăugat ca o Da componentă other Web 2.0
Amaya Da Da Da
Da
Foarte ușor
Mediu
Ușor
Da Nu
Nu Da Parțial – poate fi scris codul de conexiune
Nu Da
Rețele de socializare
Da
Adăugare de conținut de către utilizator
Da
Nu
Nu
Nu
Web 3.0
81
Capitolul 8 Semantic Web
SVG
Editare componente Inserare cod server-side Modificare cod pagină Complexitate opțiuni disponibile Pagini speciale Optimizare Resurse utilizate de către client Arhivare ZIP Elemente grafice
Partial – trebuie Da definită de utilizator Partial – trebuie Da definită de utilizator Aspecte Generale
Partial – trebuie definită de utilizator Nu
Parțial
Da
Da
Parțial – componentă other
Da
Nu
Nu
Da
Da
Redus
Foarte Ridicat
Mediu
Da Mediu
Nu Performant
Nu Mediu
Minim
Mediu/Avansat
Mediu
Da Nu Minimal Bogat Tabelul 8.1 Comparație Proiect/Dreamweaver/Amaya
Nu Mediu
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. 82
Capitolul 8 Î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 ăț iri
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 • 83
Capitolul 8 • • • • •
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 •
84
Anexa
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 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 Aplicația Flash. Nume
okBtnPage cancelBtnPage okBtnError okBtnRightPage cancelBtnRightPage okBtnRightComponent cancelBtnRightComponen t okBtnNewTextFieldPage cancelBtnNewTextFieldP age cancelBtnNewImage okBtnNewImage browseBtnNewImage okBtnSiteMap okBtnCreateCustomFBCo mponent cancelBtnCreateCustomF BComponent setAc setAcce cessB ssBtn tnPag Pagee
Tip
SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton SimpleButton
Nume
fundalPagina fundalEroare paginaLabel denumirePaginaLabel denumirePaginaInput scopPaginaLabel scopPaginaInput
Tip
Shape Shape TextField TextField TextField TextField TextField
SimpleButton clonaPaginaLabel SimpleButton listPagina
TextField TextField
SimpleButton eroarePaginaLabel SimpleButton paginaRenameDeleteLab el SimpleButton paginaRenameDeleteLab elOperatie SimpleButton paginaRenameDeleteLab elPagina SimpleButton listOperatiiPagina
TextField TextField
SimpleButton listaComponentePagina
List
Simpl SimpleB eBut utto tonn pagi paginaR naRen enam ameDe eDele leteL teLab ab
TextField TextField List
TextF TextFie ield ld 87
Anexa okBtnAddFBComponent
SimpleButton
cancelBtnAddFBCompon ent okBtnAddOtherCompone nt cancelBtnAddOtherComp onent componentLabelDelete componentRenameDelete Label listaComponente
SimpleButton
componenteRenameDelet eLabel componenteRenameDelet eInput paginaRenameDeleteLabe l newTextFieldPaginaLabel denumireNewTextFieldLa bel denumireNewTextFieldIn put scopNewTextFieldLabel
SimpleButton SimpleButton TextField TextField List
elDenumire paginaRenameDeleteLab elDenumireInput paginaRenameDeleteLab elDenumireInput paginaRenameDeleteLab elScop paginaRenameDeleteLab elScopInput scopNewTextFieldInput newImageLabel
TextField TextField TextField TextField TextField TextField TextField
TextField
denumireNewImageLabe l denumireNewImageInput
TextField
relevantaNewImageLabel
TextField
TextField
relevantaNewImageInput
TextField
TextField TextField
altNewImageLabel altNewImageInput
TextField TextField
TextField
linkNewImageLabel
TextField
TextField
siteMapDenumireLabel
TextField
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 sizeInpuInstance.addEventListener(FocusEvent.FOCUS_OUT,setSizeTextFieldDefault) .FOCUS_OUT,setSizeTextFieldDefault);; sizeInpuInstance.border 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.
88
Anexa 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 createNewExteriorPage(x:int,y:int,w:int,h:int,titlu:String,scop:Stri ,titlu:String,scop:String):ComponentaExterioara ng):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
GenerateButton(textVar,culoare,w,h): SimpleButton GenerateLabel(textVal,x,y,w,h) : TextField GenerateInput(x,y,w,h): TextField GenerateList(x,y,w,h) : List GenerateTextArea(textVar,x,y,w,h) : TextArea GenerareFundalDialog(culoare, x, y, w, h, eW, eH):Shape GenerateInputSite(x,y,w,h): TextField updateListaPagina():void updateListaOperatiiPagina():void updateListaComponentePagina():void updateListaComponente():void errorMessege(messege:String):void updateAfisarePagini():void updateTextBtnPagina(denumirePagina:String,noulText:Stri ng):void createNewPage(titlu:String,scop:String):Pagina createNewExteriorPage(x:int,y:int,w:int,h:int,titlu:String,sc op:String):ComponentaExterioara createBtnPagina():void setFocusOnPagina(pagina:Pagina):void textFieldStartDrag()
Funcționalitate Generează un buton Generează un label Generează un input Generează o listă Generează un text Area Generează un fundal Generează un Input Realizează un update
a
listei paginilor Realizează un update a listei Operații Pagină Realizează un update a listei Componente Pagină Realizează un update a listei deComponente a paginii vizualizate Creează o eroare Realizează un update a paginilor afișate Realizează un update a butonului unei pagini Creează o pagină nouă Creează o pagină nouă exterioară Creează o un buton a unei Pagini Afișează o pagină în scenă Inițializează începutul operației de drag
addTextField(x:int,y:int,x2:int,y2:int,denumireGenerica:Stri Adaugă un Element ng,relevanta:String):void TextField în pagin ă updateTextFieldForm() Realizează operația de sincronizare între obiect și 89
Anexa 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 și componenta Text elementul vizual TextField în urma operației de resize Crează un nou obiect de newFormatBIU(fontType:String,size:int,align:String):TextF tipul TextFormat care 90
Anexa Antet funcție
ormat loadXML() onFileSelected1() onFileComplete1() onInitBitmapLoad():void strtDragBitmap():void dragBitmap():void stpDragBitmap():void onInitBitmap():void initPossibleResize() initPosibleDrag():void disablePosibleDrag() addBitmapToScene(x:int,y:int,h:int,w:int,alt:String,link:Stri ng,location:String,denumire:String, relevanta:String) drawTemporalBitMap(x:int,y:int,h:int,w:int) onInitBitmap2():void
Funcționalitate conține elementele de Bold Italic și Underline Încarcă XML în scenă Operația realizată la selecția unei imagini Operația realizată la încărcarea unei imagini Operația realizată după adăugarea unei imagini în
Loader Inițializează operația de drag a unei componente Imagine Operația de drag a unei componente Imagine Concluzionează operația de drag a unei componente Imagine Operația realizată după adăugarea unei imagini în scenă Inițializează o posibilă operație de resize unei componente Imagine Inițializează o posibilă operație de drag unei componente Imagine Concluzionează operația de drag a unei componente Imagine Adaugă o imagine în scenă Desenează o imagine temporară 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); Operatii.transformXmlToPages(XML); byte[][] componenteFisiere = null;
91
Anexa try { componenteFisiere componenteFisiere = transformXmlToComponents(XML); transformXmlToComponents(XML); } catch (IOException ex) { Logger.getLogger(Operatii.class.getName()).log Logger.getLogger(Operatii.class.getName()).log(Level.SEVERE, (Level.SEVERE, null, ex); } String[] paginiHTML = generateCode(pagini); return generateZip(pagini, paginiHTML,componenteFisiere,XML); paginiHTML,componenteFisiere,XML); } Antet Funcție
public static byte[] generateZip(Pagina[] pagini, String[] paginiHTML, byte[][] componenteFisiere,byte[] XML) public static String fbInputCode() public static String fbPictureCode() public static String fbHistoryCode() public static String[] generateCode(Pagina[] pagini) private static byte[][] generatePhpFiles() public static Pagina[] transformXmlToPages(byte[] XML) public static byte[][] transformXmlToComponents(byte[] XML) public static byte[] zipBytes(int nrComponents, String[] filenames, byte[][] input)
Funcționalitate 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 Generează codul componentei
facebook input Generează codul componentei facebook picture Generează codul componentei facebook history input Generează codul HTML pe baza obiectelor Pagina Generează codul paginilor specifice oricărui site Transformă fișierul XML în obiecte de tipul Pagină Transformă imaginile din interiorul fișierului XML în elemente de tipul byte. Arhivează paginile generate
Tabelul A3: Funcțiile Generatorului
92
Anexa 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 Adauga o pagină
adaugare_pagina 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
93